Взаимно исключающие связи
Пример диаграммы из двух сущностей с взаимно исключающими связями показан на Рис. 39(a). Самолет может находиться в рабочем состоянии, и тогда у него имеется один и только один пилот. Или же самолет может находиться на ремонте на одном из нескольких возможных авиаремонтных предприятий (каждое предприятие может производить ремонт нескольких самолетов).
Рис. 39. Пример ER-диаграммы со взаимно исключающими связями
В данном случае для каждого экземпляра типа сущности САМОЛЕТдолжен существовать экземпляр одной из указанных связей. Для экземпляров типа сущностиСАМОЛЕТ, соответствующих исправным самолетам, должен существовать экземпляр связи «один к одному» с экземпляром типа сущностиПИЛОТ, а экземпляры, соответствующие неисправным самолетам, должны участвовать в экземпляре типа связи «многие к одному» c экземпляром типа сущностиАВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ.
Как показано на Рис. 39(b), диаграмма со взаимно исключающими связями из Рис. 39 (a) может быть преобразована к диаграмме без взаимно исключающих связей путем введения подтипов. Поскольку любой самолет может быть либо исправным, либо неисправным, можно корректным образом ввести два подтипа супертипа САМОЛЕТ–ИСПРАВНЫЙ САМОЛЕТиНЕИСПРАВНЫЙ САМОЛЕТ. На уровне супертипа сущности связи не определяются. Для подтипаИСПРАВНЫЙ САМОЛЕТопределяется обязательная связь «один к одному» с типом сущностиПИЛОТ, а для подтипаНЕИСПРАВНЫЙ САМОЛЕТопределяется обязательная связь «многие к одному» с типом сущностиАВИАРЕМОНТНОЕ ПРЕДПРИЯТИЕ.
Заметим, что для того чтобы описанная схема реализации механизма взаимно исключающих связей на основе механизма наследования действительно могла работать, в средствах манипулирования данными ER-модели должна быть предусмотрена возможность динамического изменения типа сущности у экземпляра. Конкретно для нашего случая требуется возможность изменения типа экземпляра сущности ИСПРАВНЫЙ САМОЛЕТна тип сущностиНЕИСПРАВНЫЙ САМОЛЕТ, и наоборот (исправный самолет может ломаться, неисправный самолет – приводиться в рабочее состояние). Конечно, при такой смене типа должен изменяться и экземпляр связи. Заметим, что в рассматриваемом случае мы имеем дело с ограниченным динамическим изменением типа экземпляра, поскольку и исправные, и неисправные самолеты являются экземплярами супертипаСАМОЛЕТ.
Получение реляционной схемы из er-диаграммы
Опишем типовую многошаговую процедуру преобразования ER-диаграммы в реляционную (более точно, в SQL-ориентированную) схему базы данных.
Базовые приемы
Каждый простой тип сущности превращается в таблицу. (Простым типом сущности называется тип сущности, не являющийся подтипом и не имеющий подтипов.) Имя сущности становится именем таблицы. Экземплярам типа сущности соответствуют строкисоответствующей таблицы.
Каждый атрибут становится столбцом таблицы с тем же именем; может выбираться более точный формат представления данных. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут.
Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификаторов, для первичного ключа выбирается наиболее характерный. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно, и в общем случае может привести к зацикливанию). Для именования этих столбцов используются имена концов связей и/или имена парных типов сущностей.
Связи «многие к одному» (и «один к одному») становятся внешними ключами, т. е. образуется копия уникального идентификатора сущности на конце связи «один», и соответствующие столбцы составляют внешний ключ таблицы, соответствующей типу сущности на конце связи «многие». Необязательные связи соответствуют столбцам внешнего ключа, допускающим наличие неопределенных значений; обязательные связи – столбцам, не допускающим неопределенных значений. Если между двумя типами сущности AиBимеется связь «один к одному», то соответствующий внешний ключ по желанию проектировщика может быть объявлен как в таблицеA, так и в таблицеB. Чтобы отразить в определении таблицы ограничение, которое заключается в том, что степень конца связи должна равняться единице, соответствующий (возможно, составной) столбец должен быть дополнительно специфицирован как возможный ключ таблицы (в случае использования языка SQL для этого служит спецификацияUNIQUE– см. лекцию 12).
Для поддержки связи «многие ко многим» между типами сущности AиBсоздается дополнительная таблицаABс двумя столбцами, один из которых содержит уникальные идентификаторы экземпляров сущностиA, а другой – уникальные идентификаторы экземпляров сущностиB. Обозначим черезУИД(с)уникальный идентификатор экземпляра некоторого типа сущностиC. Тогда, если в экземпляре связи «многие ко многим» участвуют экземплярыa1, a2, ..., anтипа сущностиAи экземплярыb1, b2, ..., bmтипа сущностиB, то в таблицеABдолжны присутствовать все строки вида< УИД(ai), УИД(bj)>дляi = 1, 2, ..., n, j = 1, 2, ..., m. Понятно, что, используя таблицыA,BиAB, с помощью стандартных реляционных операций можно найти все пары экземпляров типов сущности, участвующих в данной связи.
Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.