Связи идентифицирующие и неидентифицирующие

Связи

Атрибуты

Сущности

Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address (рис. 31).

Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели) щелкнуть на кнопке на панели инструментов ERwin Toolbox, затем щелкнуть по тому месту диаграммы, где планируется расположить новую сущность. Затем, щелкнув правой кнопкой мыши по сущности и выбрав из контекстного меню пункт Entity Properties, можно вызвать диалог Entities, в котором определяются имя, описание и комментарии сущности (рис. 32).

Рис. 32. Закладка Definition диалога Entities.

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В ранних версиях ERwin закладкам Note2 и Note3 соответствовали окна Query и Sample.

Закладка Definition (рис. 32) используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы базы данных и использовать в реальной базе данных (При соответствующих настройках генерации схемы ERwin DM автоматически сгенерирует скрипт CREATE COMMENT on entity_name).

Закладка Volumetrics (рис. 33) позволяет на логическом уровне вводить информацию о приблизительном размере соответствующих таблиц. Для оценки размера таблицы следует ввести следующую информацию:

· Initial Rows – начальное количество строк в таблице,

· Max Rows – максимальное число (лимит) строк в таблице,

· Grow By – скорость увеличения таблицы (строк в месяц).

Рис. 33. Закладка Volumetrics диалога Entities.

Закладка Note позволяет вносить дополнительные замечания о сущности, которые не были отражены в определении, введенном в закладке Definition. В закладке Note можно ввести полезное замечание, описывающее бизнес-правило или соглашение по организации диаграммы.

В закладке Note 2 можно задокументировать возможные запросы, которые, как ожидается, будут использоваться по отношению к данной сущности в базе данных. При переходе к физическому проектированию записанные в закладке Note 2 примеры запросов помогут сделать базу данных более эффективной.

Закладка Note 3 позволяет вводить примеры экземпляров сущности (в произвольной форме).

Применение свойств, определяемых пользователем (UDP), аналогично использованию в AllFusion Process Modeler (см. часть I пособия). Для определения UDP служит диалог User Defined Properties (меню Model/UDP Dictionary) (рис. 34). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т. д.), и тип данных. Для внесения нового свойства следует ввести имя, тип данных, значение по умолчанию и описание. Следующая строка таблицы появляется автоматически.

ERwin DM поддерживает для UDP шесть типов данных:

· Date. Дата. Используется формат MM/DD/YY. Для выбора значения даты можно использовать контекстный календарь.

· Int. Целое число.

· Real. Действительное число.

Рис. 34. Диалог User Defined Properties

· Text. Строка (ASCII).

· List. Список. При задании списка в диалоге User Defined Property значения следует разделять запятой, значение по умолчанию выделяется символом ~ (тильда) (рис. 34).

· Command. Команда - выполняемая строка. На рис. 34 свойство Документ имеет тип Command.

Рис. 35. Закладка UDP диалога Entities.

Значение свойств, определяемых пользователем, задается в закладке UDP диалога Entities (рис. 35). Если пользовательскому свойству Документ присвоить значение «D:\Проект\Проект0.doc», то в модели из закладки UDP можно редактировать файл «Проект0.doc» (кнопка в строке свойства Документ). Если у сущности требуется изменить значение свойства типа List, например, свойство Важность (рис. 35), можно, либо ввести одно из допустимых значений в строке ввода, либо просто выбрать значение из списка допустимых значения. В последнем варианте следует сначала щелкнуть мышкой по строке ввода значения свойства, затем щелкнуть по появившемуся значку и выпавшем списке выбрать требуемое значение свойства.

С помощью закладки Icon каждой сущности можно поставить в соответствие картинку, которая будет отображаться в режиме просмотра модели на уровне иконок. В этой закладке можно задать как большую иконку, которая будет отображаться на уровне Icon, так и малую иконку, которая может отображаться на всех уровнях просмотра модели. Для связывания изображения с сущностью необходимо щелкнуть по кнопке , в появившемся диалоге Icons щелкнуть по кнопке Import и выбрать соответствующий файл формата BMP. После выбора иконки она отображается во вкладке Icon диалога Entities (рис. 36).

Рис. 36. Закладка Icon диалога Entities.

ERwin DM автоматически сохраняет историю всех изменений, связанных с объектами (сущностями, атрибутами, таблицами, колонками и т.д.). В закладке History диалога Entities (рис. 37) отображается список изменений. Каждому изменению в окне Comment можно дать комментарий.

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

Рис. 37. Закладка History диалога Entities.

Рис. 38. Закладка General диалога Attributes.

Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Для атрибутов первичного ключа в закладке General диалога Attributes необходимо сделать пометку в окне выбора Primary Key. Для наглядности диаграммы каждый атрибут можно связать с иконкой из выпадающего списка Icon в закладке General. Если имеющихся в списке графических изображений недостаточно, следует воспользоваться кнопкой , расположенной справа от списка выбора. В результате откроется диалог Icons (рис. 39). Щелкнув по кнопке Import, можно добавить в список необходимую иконку. Чтобы отобразить на диаграмме иконки атрибутов следует, во-первых, перейти на уровень атрибутов (меню Format/Display Level/Attribute), во-вторых, установить режим отображения иконок для атрибутов (меню Format/Entity Display/Attribute Icon).

Рис. 39. Диалог Icons.

Закладка Definition диалога Attributes позволяет записывать определения отдельных атрибутов. Определения атрибутов можно также автоматически сгенерировать как часть схемы (CREATE COMMENT on entity_name.attribute name).

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

В закладке History отображается история создания и изменения атрибутов.

Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User Defined Property как свойства атрибутов.

Закладка Key Group (рис. 40) позволяет включить атрибут в состав первичного, альтернативного или инверсного ключа.

Рис. 40. Закладка Key Group диалога Attributes.

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

Рис. 41. Отображение сущности и атрибутов.

Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны Сотрудника противоречит требованиям нормализации, т.к. атрибут должен быть атомарным, т.е. не содержать множественных значений. Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!); следовательно, новый атрибут, если его имя совпадает с уже существующим, должен быть переименован. На практике такое переименование не всегда удобно, поэтому по умолчанию эта опция выключена, однако в случае необходимости ее можно включить.

Для настройки правил уникальности имен модели (не только имен атрибутов) используют закладку Duplicate Names диалога Model Naming Options (меню Tools/Names/Model Naming Options) (рис. 42) Можно задать следующие режимы именования:

Рис. 42. Диалог Model Naming Options.

Allow duplicate name – позволить использование одинаковых имен (опция по умолчанию).

Automatically Rename duplicate names – автоматически переименовывать атрибут (сущность) при попытке внесения уже существующего имени атрибута, при этом к имени атрибута добавляется число. Например, если атрибут Имя уже существует в модели, то при добавлении новых атрибутов Имя в ту же или в другую сущность они будут автоматически переименованы: Имя_2, затем Имя_3 и т.д.

Ask – запрашивать возможные действия каждый раз при внесении одноименных атрибутов (сущности). ERwin DM будет показывать на экране диалог Unique Name каждый раз, когда вводится неуникальное имя сущности или атрибута. В диалоге Unique Name можно ввести другое имя или разрешить дублирование (рис. 43). Новое имя уже не прове­ряется на уникальность.

Disallow duplicate names – запретить внесение одинаковых имен. При попытке использовать уже существующее имя ERwin DM сам производит переименование, чтобы обеспечить уникальность имен в модели.

Рис. 43. Диалог Unique Name.

Кроме общепринятых правил именования атрибутов часто требуется следовать правилам, разработанным внутри организации - корпора­тивным стандартам. Настроить правила именования можно с помощью диалогов Model Naming Option и Edit Naming Standards (меню Tools/Names).

Каждый атрибут должен быть определен в закладке Definition, при этом следует избегать циклических определений, например когда термин 1 опре­деляется через термин 2, термин 2 - через термин 3, а термин 3, в свою оче­редь, - через термин 1. Иногда определение атрибута легче дать через описание области значений. Например, Оценка школьника - это число, принимающее значения 2,3,4 или 5.

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

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

Связь является логическим отношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 44). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:

· Каждый КЛИЕНТ <размещает> ЗАКАЗы;

· Каждый ЗАКАЗ <выполняется> СОТРУДНИКом.

Рис. 44. Пример именования связей (Relationship Verb Phrases).

Связь показывает, какие именно заказы разместил клиент и какой именно сотрудник выполняет заказ. По умолчанию имя связи на диаграмме не показывается. Для отображения имени связи следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Relationship Display и затем включить опцию Verb Phrase.

На логическом уровне можно установить идентифицирующую связь "один ко многим", связь "многие ко многим" и неидентифицирующую связь "один ко многим" (см. табл. 11).

В IDEF1X и в IE различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin DM автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 45). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 45 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (Foreign Key - FK) (рис. 45). В дальнейшем, при генерации схемы базы данных, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.

Рис. 45. Идентифицирующая связь.

При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родитель­ской сущности мигрируют в состав неключевых компонентов дочерней сущности. Неидентифицирующая связь служит для связывания независи­мых сущностей. На рис. 46 экземпляр сущности Сотрудник может существовать безотносительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организации, не числясь в каком-либо отделе.

Рис. 46. Неидентифицирующая связь.

Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (рис. 45), неидентифицирующая - пунктирной (рис. 46).

Рис. 47. Диалог Relationships.

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

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

· щелкнуть сначала по родительской, а затем по дочерней сущности.

Размещение фрагментов линии связи можно изменить: левой кнопкой мышки захватить нужный фрагмент линии связи и перенести его в другую позицию.

Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по линии связи и выбрать в контекстном меню пункт Relationship Properties.

В появившемся диалоге Relationships в закладке General можно задать имя связи (раздел Verb Phrase), мощность (раздел Cardinality), тип связи (раздел Relationship Type) (рис. 47).

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один ко многим" (иденти­фицирующей или неидентифицирующей) достаточно указать имя, характе­ризующее отношение от родительской к дочерней сущности (Parent-to-Child) (рис. 45, 46). Для связи "многие ко многим" следует указывать имя как Parent-to-Child, так и Child-to-Parent.

Мощность связи (Cardinality) служит для обозначения отношения чис­ла экземпляров родительской сущности к числу экземпляров дочерней. Различают 4 типа мощности, которые были рассмотрены в разделе «Особенности методологий IDEF1X и IE». По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для его отображения следует в контекстном меню, кото­рое появляется, если щелкнуть правой кнопкой мыши по любому месту диа­граммы, не занятому объектами модели, выбрать пункт Relationship Display и затем включить опцию Cardinality.

Тип связи ( Relationship Type ). Можно изменить тип связи: идентифицирующая или неидентифицирующая. Для неиден­тифицирующей связи в разделе Nulls можно выбрать переключатель обязательности связи:

· No Nulls – обязательная неидентифицирующая связь. При генерации схемы базы данных атрибут внеш­него ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности.

· Nulls Allowed – необязательная неидентифицирующая связи. Внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис 46).

В закладке Definition диалога Relationships можно дать более полное определение связи. В закладке RI Actions определяют правила ссылочной целостности (referential integrity), о которых будет рассказано позднее. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User Defined Property (меню Model/UDP Dictionary) как свойства связи (Relationship). В закладке Rolename (рис.48) можно задать имя роли.

Рис. 48. Закладка Rolenameдиалога Relationships.

Имя роли (функциональное имя) - показывает, какую роль играет мигрировавший атрибут в дочерней сущности. В примере, приведенном на рис. 49, в сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя " Где работает ", которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полно­го имени атрибута (имя роли + имя мигрировавшего атрибута) в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, следует вы­брать пункт Entity Display и затем включить опцию Rolename/Attribute. Полное имя показывается как имя роли, имя мигрировавшего атрибута, разде­ленные точкой (рис. 49).

Рис. 49. Пример имен ролей внешних ключей.

Обязательным является применение имен ролей в том случае, когда два или более атрибута одной и той же сущности имеют одинаковую область значений, но разный смысл. На рис. 50 сущность Продажа валюты содержит информацию об акте обмена валюты, в котором участвуют две валюты - проданная и купленная. Информация о валютах содержится в сущности Валюта. Следовательно, сущности Продажа валюты и Валюта должны быть связаны дважды, и первичный ключ Номер валюты должен дважды мигрировать в сущность Продажа валюты в качестве внешнего ключа. Требуется различать два атрибута, мигрировавших из сущности Валюта: один содержит номер проданной валюты, а другой содержит номер купленной валюты,- они имеют общую область значений и ссылаются на одну и ту же сущность Валюта. В примере на рис. 50 атрибутам присвоены разные имена ролей: Проданная и Купленная.

Рис. 50. Пример обязательного использования имен ролей.

Другим примером обязательности присвоения имен ролей являются ре­курсивные связи, когда одна и та же сущность является и родительской и дочерней од­новременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущно­сти. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 49 сущность Сотрудник содержит атрибут первичного ключа Табельный но­мер. Информация о руководителе сотрудника содержится в той же сущно­сти, поскольку руководитель работает в той же организации. Чтобы со­слаться на руководителя сотрудника, следует создать рекурсивную связь (на рис. 49 связь Руководит/Подчиняется) и присвоить имя роли (Руко­водитель). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в со­став первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева под­чиненности должен быть корень - сотрудник, который никому не подчиняется. ­Связь руководит/подчиняется на рис. 49 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчинен­ный имеет только одного руководителя (рис. 51 слева).

Рис. 51. Подчиненность экземпляров сущности в рекурсии.

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

На рис. 52 рассмотрен пример реализации сетевой рекурсии. Струк­тура моделирует родственные отношения между членами семьи любой сложности. Атрибут Типотношения может принимать значения "отец-сын", "мать-дочь", "дед-внук", "свекровь-невестка", "тесть-зять" и т. д. По­скольку родственное отношение связывает всегда двух людей, от сущности Родственник к сущности Родственное отношение установлены две иден­тифицирующие связи с именами ролей "Старший" и "Младший". Каждый член семьи может быть в родственных отношениях с любым другим членом семьи, более того, одну и ту же пару родственников могут связывать разные типы родственных отношений.

Рис. 52. Пример реализации сетевой рекурсии.

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более - только имя роли. На рис. 53 изображена структура данных, которая содержит сущность Команда, сущность Игрок, в которой хранится информация об игроках каждой команды, и сущность Гол, содержащая информацию о голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли В какой команде играет. На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).

Рис. 53. Пример миграции имен ролей.

Правила ссылочной целостности (RI - referential integrity) – правила определяющие, что произойдет в случае, если будут произведены изменения в родительской или дочерней сущности: добавление (INSERT), обновление (UPDATE), удаление (DELETE). Правила ссылочной целостности позволяют избежать «висячих» данных и позволяют придерживаться бизнес правил.

ERwin DM автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем доба­вить ее в диаграмму. В закладке RI Actions диалога Model Properties (меню Model/Model Properties) можно изменить правила ссылочной целостности по умолчанию. На основе этих правил при генерации схемы базы данных будут сгенерированы:

· правила деклара­тивной ссылочной целостности для ка­ждой связи,

· триггеры, обеспечивающие ссылочную целостность.

Переопределить правила ссылочной целостности для конкретной связи можно в закладке RI Actions диалога Relationships (рис. 54).

Рис. 54. Закладка RI Actionsдиалога Relationships.

Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления. По умолчанию ERwin DM генерирует триггеры, дублирующие декларативную ссылочную целостность.

Для связей в модели ERwin DM можно определить следующие типы действий триггеров ссылочной целостности (в зависимости от выбранной СУБД и ее версии этот список может быть короче):

· Restrict. Не разрешает удалять, обновлять или редактировать экземпляр в родительской или дочерней сущности (таблице), если существует один или более связанных с ним экземпляров в дочерней или родительской сущности (таблице).

· Cascade. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то каждый связанный экземпляр в дочерней сущности (таблице) также удаляется, вставляется или обновляется.

· Set null. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждого связанного экземпляра дочерней сущности (таблице) устанавливается в Null.

· Set default. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждому связанному экземпляру дочерней сущности (таблице) назначается определенное значение по умолчанию.

· No Action. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то во всех связанных экземплярах дочерней сущности никакие действия не производятся.

· None. Не требуются действия по поддержанию ссылочной целостности.

Для отображения на диаграмме установленных правил ссылочной целостности следует в меню Format выбрать пункт Relationship Display, затем Referential Integrity.

В таблице 13 приведены примеры правил ссылочной целостности при удалении строки родительской таблицы.

Таблица 13. Примеры правил ссылочной целостности при удалении строки родительской таблицы.

№	Название	Пример
	Parent Delete RESTRICT - удаление с ограничением	На рис. 53 между сущностями Команда и Игрок существует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без Команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать зна­чение NULL). Правило запрещает удаление команды, по­ка в ней числится хотя бы один игрок (для удаления команды сначала нуж­но удалить всех игроков). При попытке выполнить удаление строки из родительской таблицы Команда, в которой есть хотя бы один игрок, сервер реляционной СУБД возвратит ошибку.
	Parent Delete CASCADE - удаление каскадом	На рис. 53 между сущностями Команда и Игрок существует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать зна­чение NULL). Согласно правилу вместе с командой удаляются сразу все ее игроки. Примечание. Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки этой команды и все голы, которые они забили. Выполнение команды на удаление одной строки фактически может привести к удалению тысяч строк в базе дан­ных, поэтому использовать правило удаления каскадом следует с осторож­ностью.
	Parent Delete SET NULL - удаление с установкой в Null	На рис. 46 установлена необязательная неидентифицирующая связь между сущностями Отдел и Сотрудник. Экземпляр сущности Сотрудник может существовать без ссылки на отдел (атрибут внешнего ключа Где ра­ботает. Номер отдела может принимать значение NULL). Согласно правилу при удале­нии отдела атрибут внешнего ключа сущности Сотрудник - Где работает. Номер отдела примет значение NULL. Это означает, что при удалении от­дела сотрудник остается работать в организации, не будучи приписан к ка­кому-либо отделу, и информация о нем сохраняется.
	Parent Delete SET DEFAULT - удаление с установкой значений по умолчанию	На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок. Согласно правилу атрибут внешнего ключа получит значение по умолчанию. Т.е. при удалении команды атрибут первичного ключа в сущности Игрок (В какой команде играет. Номер команды)получит значение по умолчанию. Например, при удалении команды ее игроки могут быть переведены в другую команду.
	Parent Delete NONE - простое удаление	На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок. Согласно правилу при удалении значение атрибута внешнего ключа не меняется. Запись об игроке "повисает в воздухе", т. е. ссылается на несуществующую уже команду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2017-02-01