Базовые приемы

Получение реляционной схемы из ER-диаграммы

Опишем типовую многошаговую процедуру преобразования ER-диаграммы в реляционную (более точно, в SQL-ориентированную) схему базы данных.

Каждый простой тип сущности превращается в таблицу. (Простым типом сущности является тип сущности, не являющийся подтипом и не имеющий подтипов.) Имя сущности становится именем таблицы. Экземплярам типа сущности соответствуют строки соответствующей таблицы.

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

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

Связи “многие-к-одному” (и “один-к-одному”) становятся внешними ключами, т.е. образуется копия уникального идентификатора сущности на конце связи “один”, и соответствующие столбцы составляют внешний ключ таблицы, соответствующей типу сущности на конце связи “многие”. Необязательные связи соответствуют столбцам внешнего ключа, допускающим наличие неопределенных значений; обязательные связи – столбцам, не допускающим неопределенных значений. Если между двумя типами сущности A и B имеется связь “один-к-одному”, то соответствующий внешний ключ по желанию проектировщика может быть объявлен как в таблице A, так и в таблице B. Чтобы отразить в определении таблицы то ограничение, что степень конца связи равняется единице, соответствующий (возможно, составной) столбец должен быть дополнительно специфицирован как возможный ключ таблицы (в случае использования языка SQL для этого служит спецификация UNIQUE – см. Лекцию 12).

Для поддержки связи “многие-ко-многим” между типами сущности A и B создается дополнительная таблица AB с двумя столбцами, один из которых содержит уникальные идентификаторы экземпляров сущности A, а другой – уникальные идентификаторы экземпляров сущности B. Обозначим через УИД(с) уникальный идентификатор экземпляра некоторого типа сущности C. Тогда, если в экземпляре связи “многие-ко-многим” участвуют экземпляры a₁, a₂, …, a_n типа сущности A и экземпляры b₁, b₂, …, b_m типа сущности B, то в таблице AB должны присутствовать все строки вида < УИД(a_i), УИД(b_j)> для i = 1, 2, …, n, j = 1, 2, …, m. Понятно, что, используя таблицы A, B и AB, с помощью стандартных реляционных операций можно найти все пары экземпляров типов сущности, участвующих в данной связи.

Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.*

Дата добавления: 2014-01-03