12.4. Диаграммы объект/отношение

Как уже объяснялось в предыдущем разделе, в [12.3] не только введена сама модель объект/отношение, но также и представлена концепция диаграммы объект/отношение (0/0-диаграмма). Такая диаграмма (также называется схемой) является методом пред­ставления логической структуры базы данных в графическом виде для более простого и понятного выражения основных компонентов макета базы данных (рисунок порой сто­ит тысячи слов). Действительно, популярность применения модели объект/отношение для проектирования баз данных скорее всего объясняется именно наличием диаграмм­ной техники, чем какой-либо другой причиной. Далее правила создания 0/0-диаграмм разъясняются на примерах, приведенных на рис. 12.2 и 12.3.

Замечание. Так же, как и сама модель объект/отношение, диаграммная техника постоянно совершенствуется, поэтому в этом разделе будет описана ее версия, кото­рая в некоторых важных отношениях отличается от оригинальной методики, предло­женной Ченом [12.3].

Объекты

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

• Правильные объекты:

DEPARTMENT

EMPLOYEE

SUPPLIER

PART

PROJECT

• Слабые объекты:

DEPENDENT

Свойства

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

Примеры (см. рис. 12.2).

• Для EMPLOYEE:

ЕМР# (ключевое свойство)

ENAME (составное, состоящее из свойств FIRST, MI и LAST)

SALARY

• Для SUPPLIER:

S# (ключевое свойство)

SNAME

STATUS

CITY

• Для SUPP_PART_PROJ:

QTY

• Для PART_STRUCTURE:

QTY

Для экономии места другие свойства на рис. 12.2 не показаны.

Отношения

Каждый тип отношения показан в виде ромба с названием отношения внутри. Ромб окружен двойной линией, если отношение задано между слабым типом объекта и ти­пом объекта, от существования которого находится в зависимости слабый тип объек­та. Участники каждого отношения присоединены к соответствующему отношению сплошными линиями. Каждая такая линия содержит надпись "1" или "М" для обозна­чения типа отношения, один-к-одному, один-ко-многим и т.д. Двойная линия обозна­чает полное участие.

Примеры (см. рис. 12.2).

• DEPT_EMP (отношение типа один-ко-многим между объектами DEPARTMENT и EMPLOYEE)

• EMP_DEP (отношение типа один-ко-многим между объектом EMPLOYEE и объ­ектом слабого типа DEPENDENT)

• PROJ_WORK и PROJ_MANAGER (оба отношения между объектами EMPLOYEE и PROJECT, первое имеет тип многие-ко-многим, а второе — один-ко-многим)

• SUPP_PART_PROJ (отношение многие-ко-многим-ко-многим, включающее объ­екты SUPPLIER, PART и PROJECT)

• SUPP_PART (отношение многие-ко-многим между объектами SUPPLIER и PART)

• PART_STRUCTURE (отношение многие-ко-многим между объектами PART и PART)

Обратите внимание, что в последнем случае две линии от PART к PART_STRUCTURE отличаются своими надписями с указанием различных выполняемых "ролей" (ЕХР и IMP, которые обозначают соответственно "раскладывание товара по компонентам" и "складывание товара по компонентам"). Отношение PART_STRUCTURE является типич­ным примером рекурсивного отношения.

Подтипы и супертипы

Пусть У является подтипом X, тогда от У к Х можно провести сплошную линию со стрелкой на конце для представления математического "подмножества" оператора (поскольку множество всех У является подмножеством множества вcex X.

Примеры (см. рис. 12.3, хотя стрелки на нем не показаны).

• Тип PROGRAMMER является подтипом типа EMPLOYEE.

• Типы APPLICATION_PROGRAMMER и SYSTEM_PROGRAMMER являются подтипами типа PROGRAMMER.