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

В определенном смысле построенная в соответствии с описанными выше правилами ER-диаграмма является проектом базы данных. Если попытаться отобразить подобный проект на некоторую формальную схему, соответствующую требованиям конкретной

СУБД⁸, то станет ясно, что обычная ER-диаграмма для этого недостаточно точна и в ней отсутствует описание множества важных деталей (особенно тех, которые относятся к це­лостности данных). Для иллюстрации этого утверждения рассмотрим, что происходит при попытке отобразить проект базы данных, показанный на рис. 13.2, на набор опреде­лений элементов реляционной базы данных.

Сильные сущности

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

DEPARTMENT

EMPLOYEE

SUPPLIER

PART

PROJECT

Каждый сильный тип сущности отображается в базовую переменную-отношение. Следовательно, рассматриваемая база данных будет содержать пять базовых перемен­ных-отношений, например DEPT. EMP, S, Р и J, соответствующих этим пяти типам сущ­ности. Более того, каждое из базовых отношений будет иметь потенциальный ключ (DEPTi, EMPi, Si, Pi и Ji), соответствующий указанным на ER-диаграмме ключевым свойствам. Для определенности допустим, что в каждой из создаваемых переменных-отношений соответствующий потенциальный ключ определяется, как первичный. В качестве примера ниже приводится определение переменной-отношения DEPT (в со­кращенном виде).

VAR DEPT BASE RELATION { DEPTi ... ) PRIMARY KEY ( DEPT* ) ;

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

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

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

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

PR0J_W0RK (между работниками и проектами) SUPP PART (между поставщиками и деталями) SUPP_PART_PROJ (между поставщиками, деталями и проектами) PART_STRUCTURE (между деталями-узлами и деталями, входящими в их состав)

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

VAR SP BASE RELATION

{ S# ... , Pt ... , ... }

FOREIGN KEY { Sf } REFERENCES S FOREIGN KEY { Pt } REFERENCES P ;

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

VAR SP BASE RELATION

{ Sf ... , Pt ... , ... }

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

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

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

PRIMARY KEY { St, PI }

В качестве упражнения читателю предлагается самостоятельно рассмотреть связи PR0J_W0RK, PART_STRUCTURE _и SUPP_PART_PROJ.

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

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

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

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

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

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

VAR EMP BASE RELATION

{ EMPt ... , DEPTt ... , ... }

PRIMARY KEY { EMPt }

FOREIGN KEY { DEPTi } REFERENCES DEPT

ON DELETE ...

ON UPDATE ... ;

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

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

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

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

ON DELETE CASCADE ON UPDATE CASCADE

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

VAR DEPENDENT BASE RELATION { EMPI ... }

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

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

PRIMARY KEY { EMPf, DEP_NAME }

Свойства

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

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

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

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

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

VAR PGMR BASE RELATION { EMPt ... , LANG, ... } PRIMARY KEY { EMPt } ... j

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

VAR PGMR BASE RELATION { EMPt ... , LANG, ... } PRIMARY KEY ( EMPt ) ; FOREIGN KEY ( EMPt ) REFERENCES EMP

ON DELETE CASCADE

ON UPDATE CASCADE ;

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

VAR EMP_PGMR VIEW EMP JOIN PGMR ;

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

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

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

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

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

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

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

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

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

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

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

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

Читателю предлагается самостоятельно разобраться в других типах сущностей, пока­занных на рис. 13.2 (APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER).