Переход к реляционной модели данных

Рассмотрим правила преобразования ER-модели в реляционную:

1. Каждой сущности ставится в соответствие таблица реляционной модели данных. При этом имена сущности и таблицы могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена таблиц могут быть ограничены требованиями конкретной СУБД. Например, сущность может быть названа "Книжный каталог", а соответствующая ей таблица желательно назвать, например, BOOKS (без пробелов и латинскими буквами).
2. Каждый атрибут сущности становится атрибутом соответствующей таблицы. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование таблиц в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).

Рис. 8. Преобразование сущности Преподаватель к таблице TEACHER

1. Первичный ключ сущности становится PRIMARY KEY соответствующей таблицы. Атрибуты, входящие в первичный ключ таблицы, автоматически получают свойство обязательности (NOT NULL).
2. В каждую таблицу, соответствующую подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В таблице, соответствующей подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).
3. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).
4. Для отражения категоризации сущностей при переходе к реляционной модели возможны несколько вариантов представления. Можно создать только одну таблицу для всех подтипов одного супертипа (включают все атрибуты всех подтипов). Однако тогда для ряда экземпляров часть атрибутов не будет иметь смысла. Потребуются дополнительные правила различения одних подтипов от других. Достоинством такого представления является то, что создается всего одна таблица.

Рис. 9. Преобразование взаимосвязанных сущностей «Студент» и «Преподаватель» к взаимосвязанным таблицам STUDENT и TEACHER

1. При втором способе для каждого подтипа и для супертипа создаются свои отдельные таблицы. Недостатком такого способа представления является то, что создается много таблиц, однако достоинств у такого способа больше, так как работаем только со значимыми атрибутами подтипа. Для возможности переходов к подтипам от супертипа необходимо в супертип включить идентификатор связи.
2. Дополнительно при описании таблицы между типом и подтипами необходимо указать тип дискриминатора. Дискриминатор может быть взаимоисключающим (M/E, mutually exclusive) или нет. Если установлен данный тип дискриминатора, то это значит, что один экземпляр сущности супертипа связан только с одним экземпляром сущности подтипа и для каждого экземпляра сущности супертипа существует потомок. Кроме того, необходимо указать для второго способа, наследуется ли только идентификатор супертипа в подтипы или наследуются все атрибуты супертипа.
3. Если мы зададим наследование только идентификатора, то мы получим следующее преобразование (см. Рис. 10).

Рис. 10. Модель с наследованием только идентификатора суперсущности