ПБД_лабораторная_1

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

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

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

Рис. 8. Имя связи - Relationship Verb Phrases

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

Verb Phrase.

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

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

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

операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внеш- ний ключ - (FK).

Рис. 9. Идентифицирующая связь между независимой и зависимой таблицей

В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат

11

признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.

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

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

Экземпляр сущности Сотрудник может существовать безотносительно к ка- кому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организа- ции, не числясь в каком-либо отделе.

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

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

o установить курсор на нужной кнопке в палитре инструментов (идентифици- рующая или неидентифицирующая связь) и нажать левую кнопку мыши;

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

Форму линии связи можно изменить. Для этого нужно захватывать мышью нужную линию связи и переносить ее с места на место, пока линия не начнет выгля- деть лучше.

В палитре инструментов кнопка соответствует идентифицирующей связи,

кнопка связи многие-ко-многим и кнопка соответствуют неидентифици- рующей связи.

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

В закладке General появившегося диалога можно задать мощность, имя и тип связи (рис. 11).

Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают четыре типа мощности (рис. 11):

−общий случай, когда одному экземпляру родительской сущности соответст- вуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо

12

символом;

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

−символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

−символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множе- ственные значения);

−цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочер- ней сущности.

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

Cardinality.

Имя связи (Verb Phrase) - фраза, характеризующая отношение между роди- тельской и дочерней сущностями. Для связи «один-ко-многим» идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от

13

родительской к дочерней сущности (Parent-to-Child). Для связи «многие-ко-многим» следует указывать имена как Parent-to-Child так и Child-to-Parent.

Тип связи (идентифицирующая / неидентифицирующая). Для неиденти-

фицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного клю- ча дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис. 10).

Взакладке Definition можно дать более полное определение связи для того, чтобы в дальнейшем иметь возможность на него ссылаться.

Взакладке Rolename можно задать имя роли (рис. 12), в закладке RI Actions и правила ссылочной целостности.

3.3 Функциональные имена Имя роли (функциональное имя) - это синоним атрибута внешнего ключа,

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

Рис. 12. Имена ролей внешних ключей

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

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

14

связаны дважды и первичный ключ - Номер валюты должен дважды мигрировать в сущность Валюта в качестве внешнего ключа.

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

рибуты получили имена ролей Проданная и Купленная.

Рис. 13. Случай обязательности имен ролей

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

На рис. 12 сущность Сотрудник содержит атрибут первичного ключа Табельный номер. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на руко- водителя сотрудника следует создать рекурсивную связь (на рис. 12 связь руково- дит/подчиняется) и присвоить имя роли ("Руководитель"). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ

должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева подчиненности должен быть корень - сотрудник, который никому не подчиняется в рамках данной организации.

Связь руководит/подчиняется на рис. 12 позволяет хранить древовидную ие- рархию подчиненности сотрудников. Такой вид связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочер- ней сущности), но подчиненный имеет только одного руководителя (рис. 14).

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

Иерархическая рекурсия Сетевая рекурсия

15

3.4 Правила ссылочной целостности

Правила ссылочной целостности (referential integrity, RI) - логические конст- рукции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления.

При генерации схемы БД на основе опций логической модели, задаваемых в закладке RI Actions, будут сгенерированы правила декларативной ссылочной цело- стности, которые должны быть предписаны для каждой связи, и триггеры, обеспе- чивающие ссылочную целостность. Триггеры представляют собой программы, вы- полняемые всякий раз при выполнении команд вставки, замены или удаления

(INSERT, UPDATE или DELETE).

На рис. 16 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок (для удаления команды сначала нужно удалить всех игроков), либо сразу удалять вместе с коман- дой всех ее игроков. Такие правила удаления называются "ограничение" и "каскад" (Parent RESTRICT и Parent CASCADE, см. рис. 17).

Если бы между сущностями Отдел и Сотрудник (рис. 12) была установлена необязательная неидентифицирующая связь, то экземпляр сущности Сотрудник мог бы существовать без ссылки на отдел (атрибут внешнего ключа Где работает. Номер отдела мог принимать значение NULL). В этом случае возможно установле- ние правила установки в нуль - SET NULL. При удалении отдела атрибут внешнего

ключа сущности Сотрудник - Где работает. Номер отдела примет значение

NULL. Это означает, что при удалении отдела сотрудник остается работать в орга- низации не будучи приписан к какому-либо отделу и информация о нем сохраняет- ся.

Возможна установка еще двух правил удаления (если таковые поддерживают- ся СУБД):

SET DEFAULT - при удалении атрибуту внешнего ключа присваивается зна- чение по умолчанию.

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

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

уже команду.

Правила удаления управляют тем, что будет происходить в БД при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет проис- ходить с БД, если строки изменяются или добавляются.

17

Таблица 4. Значения RI, присваиваемые в ERwin no умолчанию, а также возможные

режимы для каждого типа связи

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

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

19

связь обозначается сплошной линией с двумя точками на концах.

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

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

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

3.6 Ключи

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

кладки General.

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

тенциальными ключами (candidate key).

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

Рассмотрим кандидатов на первичный ключ сущности Сотрудник (рис. 19). Здесь можно выделить следующие потенциальные ключи:

1.Табельный номер,

2.Номер паспорта;

3.Фамилия + Имя + Отчество.

Рис. 19. Определение первичного ключа для сущности "Сотрудник"

20