• Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами, возможно, с примерами.

• Пример:

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

• 6.2.3. Нормальные формы er-схем

• 11.5. Проектирование базы данных с помощью метода er-моделирования

• В определенном смысле построенная в соответствии с описанными выше правилами ER-диаграмма является проектом базы данных. Если попытаться отобразить подобный проект4 на некоторую формальную схему, соответствующую требованиям конкретной СУБД, то станет ясно, что обычная ER-диаграмма для этого недостаточно точна и в ней отсутствует описание множества важных деталей (особенно тех, которые относятся к целостности данных). Для иллюстрации этого утверждения рассмотрим, что происходит при попытке отобразить проект базы данных, показанный на рис. 11.6, на набор определений компонентов реляционной базы данных.

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

• На рис. 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-диаграмме.

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

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

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

• ON DELETE CASCADE

• ON UPDATE CASCADE

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

• VAR DEPENDENT BASE

• RELATION { ЕМР# ..., ...

• }

• FOREIGN KEY ( EMP# ) REFERENCES

• EMP ON DELETE CASCADE ON

• UPDATE CASCADE ;

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

• PRIMARY KEY { EMP#, DEP_NAME }

• Здесь DEP_NAME — имя иждивенца данного работника.

• Свойства

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

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

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

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

• ■ Подтип PROGRAMMER отображается на другую базовую переменную отношения, например PGMR, с таким же первичным ключом, что и у переменной отношения ее супертипа, но с другим набором атрибутов, соответствующим свойствам, которые применяются для описания только работников, являющихся программистами (в нашем примере — LANG).

• VAR PGMR BASE RELATION { EMP#

• ..., LANG ... } PRIMARY KEY {

• EMP# } ... ;

• Более того, первичный ключ переменной отношения PGMR является также внешним ключом, который ссылается на переменную отношения ЕМР. Следовательно, приведенное выше определение необходимо соответствующим образом расширить (в частности, обратите внимание на определение правил удаления и обновления).

• VAR PGMR BASE RELATION {

• ЕМР# ..., LANG ... }

• PRIMARY KEY { EMP# }

• FOREIGN KEY { EMP# } REFERENCES EMP

• ON DELETE CASCADE ON UPDATE

• CASCADE ;

• ■ Нам также потребуется представление, например, с именем EMP_PGMR, являющее ся соединением переменных отношения супертипа и подтипа.

• VAR EMP_PGMR VIEW

• ЕМР JOIN PGMR ;

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

• работниках, являющихся программистами.

• Такая структура позволяет выполнять описанные ниже действия.

• ■ С помощью базовой переменной отношения ЕМР можно получить доступ к тем свойствам, которые являются общими для всех работников (например, для вы борки данных или для их применения в некоторых ограничениях целостности).

• ■ С помощью базовой переменной отношения PGMR МОЖНО получить доступ к свой ствам, характерным только для программистов.

• ■ С помощью представления EMP_PGMR можно получить доступ ко всему набору свойств программистов.

• 1 В базовую переменную отношения ЕМР можно вставлять сведения о работниках, которые не являются программистами.

• ■ Сведения о работниках-программистах можно вставлять в базу данных с помощью представления EM7P_PGMR.

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

• ■ Свойства, общие для всех работников, можно обновлять в базовой переменной отношения ЕМР, а свойства только работников-программистов — обновлять и с помощью представления EMP_PGMR.

• ■ Свойства, характерные только для программистов, можно обновлять в базовой переменной отношения PGMR.

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

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

• Предлагаем читателю самостоятельно рассмотреть другие типы сущностей, показанные на рис. 11.7 (APPLICATION_PROGRAMMER ИSYSTEM_PROGRAMMER).

43. Построение таблиц по ER диаграммам