сустановкой по умолчанию., т. е. при удалении команды атрибут первичного

Связь «многие ко многим»

Связь «многие ко многим» может быть создана только на уровне логической модели. Пример связи «многие ко многим» показан на рис. 1.31. Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя точками на концах.

Рис. 1.31. Связь «многие ко многим»

Для внесения связи следует установить курсор на кнопке на панели инструментов ERwin, щелкнуть по одной, затем по другой сущности.

Связь «многие ко многим» должна именоваться двумя фразами – в обе стороны (в примере «лечит/лечится у»). Это облегчает чтение диаграммы. Связь на рис. 1.31 следует читать так: Врач <лечит> Пациента,

Пациент <лечится у> Врача.

На физическом уровне связь «многие ко многим» должна быть преобразована. По умолчанию при переходе к физическому уровню ERwin DM автоматически не преобразует связь «многие ко многим», и на физическом уровне диаграмма выглядит так же, как и на логическом. Однако при генерации схемы такая связь игнорируется.

Для преобразования связи «многие ко многим» необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт меню Create

Association Table или выбрать связь и щелкнуть по инструменту на

43

панели трансформаций ERwin Transform Toolbar (подробнее операции преобразования будут рассмотрены разделе «Трансформации»). Появится Мастер трансформаций – Many-To-Many Transform Wizard, состоящий из 4 шагов-диалогов. Для перехода к следующему шагу нужно щелкнуть по кнопке Next (Далее). На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования. Преобразование связи включает создание новой таблицы и двух новых связей «один ко многим» от старых к новой таблице (рис. 1.32). При этом имя новой таблице присваивается как Имя1_Имя2.

Рис. 1.32. Автотрансформация связи «многие ко многим»

Описанного выше решения проблемы связи «многие ко многим» не всегда оказывается достаточно. В примере таблица Врач_Пациент имеет смысл визита к врачу, поэтому согласно бизнес-логике ее следует переименовать в Посещение. Один и тот же пациент может много раз посещать врача, поэтому для того, чтобы идентифицировать визит, необходимо в состав первичного ключа таблицы Посещение добавить дополнительную колонку, например, дату и время посещения

(Дата_Время_Посещения, рис. 1.33).

Следует заметить, что после переименования таблицы на физическом уровне представление модели на логическом уровне не изменится, диаграмма будет выглядеть так, как на рис. 1.32.

Рис. 1.33. Дополнение физического уровня модели после трансформации связи «многие ко многим»

Типы зависимых сущностей

Как было указано выше, связи определяют, является ли сущность независимой или зависимой. Различают несколько типов зависимых сущностей.

44

Характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности (рис. 1.34).

Рис. 1.34. Характеристическая сущность «Хобби»

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Содержит информацию о связях сущностей. В качестве примера можно привести Посещение (см. рис. 1.33).

Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Примером является Врач_Пациент

(см. рис. 1.32).

Категориальная – дочерняя сущность в иерархии наследования.

Иерархия категорий (иерархия наследования)

Представление об иерархиях категорий, их типах, отображении в нотациях IDEF1X и IE было дано в разделе «Особенности методологий

IDEF1X и IE».

Рассмотрим возможные стадии построения иерархии наследования. 1. Определение сущностей с общими (но определению) атрибутами. Предположим, что в процессе проектирования созданы сущности

Постоянный сотрудник и Совместитель (рис. 1.35). Можно заметить, что часть атрибутов у этих сущностей (Фамилия, Имя, Отчество, Дата рождения, Должность) имеет одинаковый смысл.

Рис. 1.35. Сущности с общими по смыслу атрибутами

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

2. Создание неполной структуры категорий. Создается категориальная связь от новой сущности – родового предка к старым

45

сущностям-потомкам. Новая сущность дополняется атрибутомдискриминатором категории (Тип) (рис. 1.36).

Рис. 1.36. Пример неполной иерархии категорий

Для создания категориальной связи:

щелкнуть левой кнопкой мыши по кнопке ; щелкнуть сначала по родовому предку, а затем по потомку;

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

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Properties. В диалоге Subtype Properties (рис. 1.37) можно указать атрибутдискриминатор категории Тип (список Discriminator) и тип категории –

Incomplete – неполная (раздел Type: опции Complete/Incomplete –

полная/неполная).

1. Создание полной структуры категорий. Проводится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность Консультант.

Общие атрибуты переносятся в родового предка, и категория преобразуется в полную. Признак полной категории устанавливается в диалоге Subtype Relationship (в разделе Type следует выбрать опцию

Complete).

Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность переносится обратно из родового предка в сущности-потомки Постоянный сотрудник и Совместитель или принимается решение о том, что для консультанта также требуется указывать должность (рис. 1.38).

46