Обычные сущности

На рис. 11.6 показаны следующие обычные типы сущностей.

■ DEPARTMENT.

■ EMPLOYEE.

■ SUPPLIER.

■ PART.

■ PROJECT.

Каждый обычный тип сущности отображается на базовую переменную отношения.

Следовательно, рассматриваемая база данных будет содержать пять базовых переменных отношения, например, DEPT, EMP, s, P и J, соответствующих этим пяти типам сущности.

Более того, каждое из базовых отношений будет иметь потенциальный ключ (DEPT#, ЕМР#, s#, Р# и J#), соответствующий указанным на ER-диаграмме ключевым свойствам.

Для определенности допустим, что в каждой из создаваемых переменных отношения соответствующий потенциальный ключ определяется как первичный. В качестве примера ниже приводится определение переменной отношенияБЕРТ (в сокращенном виде).

VAR DEPT BASE RELATION

{ DEPT#...,... }

PRIMARY KEY { DEPT#

};

Читателю предлагается в качестве упражнения записать определения остальных четырех переменных отношения.

Примечание. Безусловно, в документации также должны быть зафиксированы определения доменов и допустимых множеств значений. Однако подробности здесь не даны, поскольку, как уже отмечалось, множества значений на ER-диаграммах не отображаются.

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

В рассматриваемом примере присутствуют следующие связи типа "многие ко многим" (или "многие ко многим и ко многим" и т.д.).

􀂃 PROJ_WORK (между работниками и проектами).

■ SUPP_PART (между поставщиками и деталями).

■ SUPP_PART_PROJ (между поставщиками, деталями и проектами).

■ PART_STRUCTURE (между деталями-узлами и деталями, входящими в их состав)

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

VAR SP BASE RELATION SP

{ S#..., P#...,... }

FOREIGN KEY { S# } REFERENCES

S FOREIGN KEY { P# } REFERENCES

P;

Ясно, что такая переменная отношения должна включать два внешних ключа (s# и Р#), соответствующих двум участникам связи (сущностям SUPPLIER и PART), и эти внешние ключи должны ссылаться на соответствующие переменные отношения s и р.

Более того, для каждого из внешних ключей должен быть задан подходящий набор правил внешних ключей, т.е. правило обновления UPDATE и правило удаления DELETE.

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

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

VAR SP BASE RELATION SP

{ S#..., Р#...,... }

FOREIGN KEY { S# } REFERENCES S

ON DELETE RESTRICT

ON UPDATE CASCADE

FOREIGN KEY { P# } REFERENCES

P

ON DELETE RESTRICT

ON UPDATE CASCADE;

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

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

В данном примере будет использован первый из двух описанных выше вариантов. Таким образом, в определение SP необходимо добавить следующее предложение.

PRIMARY KEY { S#, P# }

В качестве упражнения читателю предлагается самостоятельно рассмотреть связи

PROJ_WORK, PART_STRUCTURE И SUPP_PART_PROJ.

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

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

■ PROJ_MANAGER (между проектами и их руководителями).

■ DEPT_EMP (между работниками и отделами).

■ EMP_DEP (между иждивенцами и работниками).

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

VAR EMP BASE RELATION

{ ЕМР#..., DEPT#...,

... } PRIMARY KEY { EMP#

}

FOREIGN KEY (DEPT#) REFERENCES

DEPT ON DELETE... ON UPDATE

...;

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

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