Каждая такая связь отображается и в базовую переменную-отношение. Таким образом, вводятся еше четыре базовые переменные-отношения, соответствуюшие четырем указанным связям. Допустим, что для связи SUPP PART такой базовой переменной-отношением является SP (уже знакомая нам переменная-отношение поставок). Временно отложим описание ее первичного ключа и обратимся к внешним ключам этой переменной-отношения, которые необходимы для идентификации участников данной связи.

VAR SP BASE RELATION

{ SI ... , PI ... , ... }

FOREIGN KEY { S } REFERENCES S FOREIGN KEY { Pi } REFERENCES P ;

Ясно, что такая переменная-отношение должна включать два внешних ключа (Si и Р), соответствующих двум участникам связи (сущности SUPPLIER и PART), и эти внешние ключи должны ссылаться на соответствуюшие переменные-отношения S и Р. Более того, для каждого из внешних ключей должен быть задан подходящий случаю набор правил внешних ключей, т.е. правило обновления UPDATE и правило удаления DELETE (за более подробными сведениями по этой теме обратитесь к главе 8). Ниже приведены правила, которые следует задать в случае базовой переменной-отношения SP. (Конечно, эти правила приведены лишь в качестве иллюстрации. В частности, обратите внимание на то, что их нельзя вывести или установить с помощью одной только ER-диаграммы.)

VAR SP BASE RELATION

{ SI ... , PI ... , ... }

FOREIGN KEY ( SI ) REFERENCES S ON DELETE RESTRICT ON UPDATE CASCADE

FOREIGN KEY ( P ) REFERENCES P ON DELETE RESTRICT ON UPDATE CASCADE ;

Что можно сказать о первичном ключе этой переменной-отношения? Одним из возможных способов его определения может быть комбинация внешних ключей, идентифицирующих участников соответствующей связи (в случае базовой переменной-отношения SP ими являются атрибуты Si и Р). Это возможно, если данная комбинация имеет уникальное значение для каждого экземпляра данной переменной-отношения (обычно так и бывает, хотя могут быть и обратные случаи) и если разработчик базы данных не возражает против использования составных первичных ключей (на практике это в равной степени возможно и невозможно). В качестве альтернативного варианта первичного ключа можно использовать новый несоставной суррогатный атрибут номер поставки (подробности приводятся в [13.10], [13.16]). В нашем примере будет использован первый из двух описанных выше вариантов. Таким образом, в определение SP необходимо добавить следующее предложение.

PRIMARY KEY { Si, Pi }

В качестве упражнения читателю предлагается самостоятельно рассмотреть связи PROJ WORK, PART STRUCTURE и SUPP PART PROJ.

Связи типа многие к одному

в рассматриваемом примере присутствуют три связи типа многие к одному .

PROJ MANAGER (между проектами и их менеджерами)

DEPT EMP (между работниками и отделами)

EMP DEP (между подчиненными и руководящими работниками)

Только в последней из трех связей участвует слабый тип сущности (DEPENDENT), тогда как в двух других участвуют только сильные типы сущностей. Связь со слабым типом сущности будет обсуждаться несколько позже, а сейчас рассмотрим какую-либо из двух других связей, например DEPT EMP. В данном случае не требуется вводить никаких новых переменных-отнощений. Вместо этого достаточно просто ввести приведенный ниже внещний ключ в переменную-отнощение, расположенную со стороны многие (ЕМР), который будет ссылаться на переменную-отнощение на стороне один (DEPT).

VAR ЕМР BASE RELATION

{ EMPi ... , DEPTi ... , ... }

PRIMARY KEY { EMP# }

FOREIGN KEY { DEPTi } REFERENCES DEPT

ON DELETE ...

ON UPDATE ... ;

В данном случае возможности определения правил удаления DELETE и обновления UPDATE точно такие же, как и в случае внещнего ключа, представляющего участника связи типа многие ко многим (в общем случае). Здесь вновь следует отметить, что они не показаны на данной ER-диаграмме.

Замечание. В рассматриваемом примере предполагается, что связи типа один к одному (которые не так уж часто встречаются на практике) следует рассматривать так же, как связи многие к одному . Подробное описание особенностей отображения связей типа один к одному приводится в [13.7].

Слабые сущности

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

ON DELETE CASCADE ON UPDATE CASCADE

Хотя, воз.можно, это имело бы некоторый смысл. Как указывалось в разделе 13.1, могут существовать веские причины для рассмотрения определенных связей типа многие к одному так, как будто на самом деле они имеют тип многие ко многим . Дополнительную информацию можно найти в последней части работы [18.20].

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

VAR DEPENDENT BASE RELATION { EMPi ... }

FOREIGN KEY ( EMPi ) REFERENCES EMP ON DELETE CASCADE ON UPDATE CASCADE ;

Что является первичным ключом данной переменной-отношения? Как и в случае со связью многие ко многим , здесь также возможен некоторый выбор. Одним из вариантов является комбинация внешнего ключа и ключевого свойства слабой сущности, представленного на ER-диаграмме, если, опять же, разработчик базы данных не возражает против использования составных первичных ключей. Альтернативным вариантом первичного ключа является введение нового несоставного суррогатного атрибута (подробности приводятся в [13.10], [13.16]). В рассматриваемом примере мы применим первый из двух приведенных выше вариантов, для чего добавим в определение переменной-отношения следующее предложение.

PRIMARY KEY { EMPi, DEP NAME }

Свойства

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

Супертипы и подтипы сущности

Поскольку на рис. 13.1 не содержится никаких супертипов или подтипов, далее речь пойдет о примере, представленном на рис. 13.2. Рассмотрим типы сущностей EMPLOYEE и PROGRAMMER. Предположим для простоты, что программисты обладают навыками работы только с одним языком программирования (т.е. свойство LANG является однозначным) *.

Супертип EMPLOYEE отображается в базовую переменную-отношение, например ЕМР, обычным образом (т.е. так, как уже обсуждалось выше).

Здесь, в частности, следует отметить, что мы не собираемся отображать типы сущностей EMPLOYEE и PROGRAMMER на какие-то супертабличные или подтабличные конструкции. В этом заключается концептуальная трудность или, по крайней мере, ловушка: из того, что на ER-диаграмме тип сущности Yявляется подтипом типа сущности X, не следует, что реляционный аналог сущности Yявляется подчиненным реляционного аналога сущности X, и это действительно так. Более подробно данная тема рассматривается в [13.12].