Ситуация, когда при удалении значение атрибута внешнего ключа не меняется (режим Parent Delete NONE) характерна для «плоских» таблиц. Например, если информация об игроках и командах хранится в dbfфайлах, можно удалить запись о команде, при этом файл игроков «ничего не будет знать» о том, что соответствующей команды не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.

Правила удаления управляют тем, что будет происходить в базе данных при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с базой данных, если строки изменяются или добавляются. Например, можно установить правило, которое разрешает вносить новую команду только в том случае, когда в нее зачислен хотя бы один игрок. Желаемое поведение может быть достигнуто следующими действиями:

Задать мощность связи между сущностями Команда и Игрок, равную 1 или более (тип Р). Предполагается, что установлена идентифицирующая связь.

Присвоить действие RI-триггера Parent Insert-CASCADE для того, чтобы при создании новой строки в таблице Команда автоматически создавалась хотя бы одна строка в дочерней таблице Игрок. (рис. 54)

Присвоить связи действие RI-триггера Parent Delete-CASCADE для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись (рис. 54).

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

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

Рис. 55. Пример связи «многие ко многим».

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

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

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

59

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

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

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

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

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

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

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

60

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

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

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

Рис. 58. Пример характеристической сущности «Хобби».

Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является Посещение на рис. 57.

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

Категориальная - дочерняя сущность в иерархии наследования (см. ниже).

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

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

IDEF1X и IE».

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

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

ния, Должность) имеет одинаковый смысл.

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

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

61

Б) Создание неполной структуры категорий. Создается категориальная связь от новой сущности - родового предка к старым сущностямпотомкам. Новая сущность дополняется атрибутом-дискриминатором категории (Тип) (рис. 60).

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

Рис. 61. Диалог Subtype Properties.

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

левой кнопкой мышки щелкнуть по кнопке (см. табл. 11);

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

62

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

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

дискриминатор категории Тип (список Discriminator) и тип категории - Incomplete – неполная (раздел Type: опции Complete/Incomplete -

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

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

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

категории устанавливается в диалоге Subtype RelationРис. 62. Дополниship (в разделе Type следует выбрать опцию Complete). тельная сущность.

Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае

консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущно-

сти-потомки Постоянный сотрудник и Совместитель или может быть принято решение о том, что для консультанта также требуется указывать должность (рис. 63).

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

Г) Пример комбинации полной и неполной категорий показан на рис.64. Согласно представленному на рисунке фрагменту модели сотрудник может быть совместителем или постоянным сотрудником (неполная категория, т.к. не отображены сотрудники-консультанты), а постоянный сотрудник является любо мужчиной либо женщиной (полная категория).

63