Преобразование ER-модели в реляционную модель

Дано: ER-модель.

Получить: набор таблиц (отношений) вида

Таблица (Ключ, Атрибут1, Атрибут2, …, АтрибутN)

Ключ может быть составным.

Удобно имена атрибутов в масштабе ER-модели сделать уникальными, тогда при построении реляционной модели их (почти никогда) не придется переименовывать.

Для краткости в примерах пропущены несущественные неключевые атрибуты.

I. Преобразование сущностей

1.

Преобразование обычной сущности

Обычная сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности:

Сущность (Ключ, Атрибут1, Атрибут2)

2. Преобразование слабой сущности

Слабая сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности плюс ключевые атрибуты всех сущностей, с помощью которых данная слабая сущность идентифицируется.

Ключевые поля всех родительских таблиц войдут в ключ дочерней таблицы.

Для дочерней таблицы они будут называться внешними ключами.

Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2)

3.
Преобразование подтипов сущностей.

1 способ) Создается одна таблица, в которую помещают все атрибуты. Для того, чтобы указать, к какому подтипу относится объект, приходится вводить дополнительное поле-признак.

Сущность1(Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак)

Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 – атрибуты 2 и 3 останутся пустыми.

2 способ) Создается отдельная таблица для каждого подтипа. В нее включаются все атрибуты этого подтипа и все атрибуты надтипа.

Подтип1(Ключ, Атрибут1, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут1, Атрибут4, Атрибут5)

Недостатком этого подхода является то, что подтипы теперь никак не связаны друг с другом.

3 способ) Создается одна таблица для надтипа, и по одной таблице для каждого подтипа, в которую включаются ключевые поля надтипа:

Сущность1(Ключ, Атрибут1)

Подтип1(Ключ, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут4, Атрибут5)

Недостатком этого подхода является то, что информация о каждом объекте теперь раскидана по двум таблицам.

II. Преобразование связей

Для связей-двойных ромбов ничего делать не нужно, вся информация уже хранится в таблице слабой сущности.

1.

Связь М:М

Создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи, и собственные атрибуты связи, если таковые имеются. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи.

Сущ1Сущ2(Ключ1, Ключ2, Атрибут1).

2. Связь 1:М

1 способ) Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи.

Ключом будет ключ второй сущности.

(Этот способ предпочтительнее использовать в том случае, если связь не является “ровно к одному”, то есть не все экземпляры сущностей участвуют в связи.)

Сущ1Сущ2(Ключ1, Ключ2).

2 способ) Новая таблица не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в ключ дочерней сущности они входить не будут!). Ключевые поля родительской сущности представляют собой внешний ключ (foreign key) для дочерней сущности.

(Этот способ предпочтительнее использовать в том случае, если связь является связью “ровно к одному”, то есть все экземпляры сущностей участвуют в связи. В этом случае поле внешнего ключа никогда не будет пустым.)

Таблица дочерней сущности: Сущность2(Ключ2, Атрибут1, Ключ1).

3.

Связь 1:1

1 способ) Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи.

Ключом будет ключ любой сущности.

(Этот способ предпочтительнее использовать в том случае, если связь не является “ровно к одному”, то есть не все экземпляры сущностей участвуют в связи.)

Сущ1Сущ2(Ключ1, Ключ2) или Сущ1Сущ2(Ключ1, Ключ2).

2 способ) Точно так же, как и во 2 случае 1:М, новая таблица не создается, а в таблицу одной из сущностей (будем считать ее дочерней) добавляют ключевые поля другой сущности (будем считать ее родительской).

(Если связь не является связью “ровно к одному” по отношению к родительской таблице, то есть не все экземпляры сущностей участвуют в связи, поле внешнего ключа в некоторых записях может быть пустым.)

Таблица дочерней сущности: Сущность1(Ключ1, Атрибут1, Ключ2),

или Сущность2(Ключ2, Атрибут2, Ключ1).

3 способ) Две таблицы для сущностей, связанных 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь “ровно к одному”, то ключ этой сущности можно считать ключом объединенной таблицы.

Таблицы Сущность1(Ключ1, Атрибут1) и

Сущность2(Ключ2, Атрибут2)

заменяются на

Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2)

[или, возможно, Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2),

или Сущ1Сущ2(Ключ1, Атрибут1, Ключ2, Атрибут2)].

Примечание 1:

Для связи сущности с самой собой применяются те же правила, но так как одна и та же сущность участвует в связи дважды, ключевые поля должны войти в одну и ту же таблицу два раза. Поэтому приходится переименовывать один из ключей.

Рассмотрим связь 1:M, способ 2. Переименован внешний ключ.

Сущность1(Ключ1, Атрибут1, ЕщеОдинКлюч1 ).

Примечание 2:

Для связей с арностью более 2 обычно применяется тот же способ, что и для бинарной связи M:M – создается новая таблица, содержащая ключевые поля всех связанных таблиц.

Сущ1Сущ2Сущ3(Ключ1, Ключ2, Ключ3).

Пример реляционной модели: КОНТОРА “РОГА И КОПЫТА”

Таблицы удобнее называть существительными во множественном числе.

В модель добавлены дополнительные неключевые атрибуты для того, чтобы задача была более интересной. На остальные поля они не влияют.

Отделы(Ном_отд, Полное_назв_отд, Краткое_назв_отд, Ном_сотр)

Поле Ном_сотр содержит номер сотрудника-руководителя отдела – преобразование связи 1:1 ”Руководит”.

Сотрудники (Ном_сотр, ФИО, Должность, Дата_приема, Срок, Ном_отд)

Ном_отд появился в результате преобразования связи М:1 ”Работает”, в ключ он не входит.

Предприятия (Ном_пред, Наз_пред, Адрес)

Название предприятия неудобно использовать в качестве ключа, добавим новое поле Ном_пред.

Договоры(Ном_дог, Дата_дог, Тип_дог, Ном_сотр)

Ном_сотр появился в результате преобразования связи М:1 ”Курирует”, в ключ он не входит.

Счета(Ном_сч, Дата_сч, Срок_сч, Сумма_сч, Ном_дог, Пени)

Ном_дог появился в результате преобразования связи М:1 ”Выставлен”, в ключ он не входит.

Платежи(Ном_пл, Ном_сч, Дата_пл, Сумма_пл)

Ном_сч появился в результате преобразования слабой сущности ”Платеж”, это поле входит в ключ!

Товары/услуги(Ном_ту, Назв_ту, Цена_ту)

Название товара неудобно использовать в качестве ключа, добавим новое уникальное поле Ном_ту.

Протоколы_счетов(Ном_сч, Ном_ту, Количество, Цена)

Эта таблица появилась в результате преобразования бинарной связи М:М “Включает”, ключ состоит из ключевых полей обеих сущностей.

Задание для индивидуальной работы 2

Преобразуйте вашу ER-модель в реляционную модель.

SQL (Structured Query Language)

Дата добавления: 2015-05-09