Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Плещёв Тюмень РСПСИТ 2010-12-14 Послан в Тюмень....doc
Скачиваний:
18
Добавлен:
24.04.2019
Размер:
5.82 Mб
Скачать

3.2.3. Связи

Имя связи между объектами (глагол или глагольная фраза) по умол­ча­нию не показывается на диаграмме; для ее отображения нужно выпол­нить команду Relationship Display/Verb Phrase из контекстного меню диаг­рам­мы. В IDEF1X различаются зависимые и независимые сущности.

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

И дентифицирующая связь устанавливается между независимой (родитель­ский конец связи) и зависимой (дочерний конец связи) сущ­ностя­ми. Экземпляр дочерней сущности (изображается прямоугольни­ком со ск­руг­­ленными углами) не может существовать без родительского экзем­пля­ра. Первичный ключ автоматически переносится (мигрирует) в дочернюю сущ­ность в состав ее первичного ключа и помечается в круглых скобках символами FK (рисунок 3.2.3.1).

Рисунок 3.2.3.1. Идентифицирующая связь между сущностями

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

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

Р иc. 3.2.3.2. Неидентифицирующая связь между сущностями

Редактирование связи реализуется командой Relationship Properties из контекстного меню линии связи (рисунок 3.2.3.3).

Рисунок 3.2.3.3. Окно настройки свойств связи

Рассмотрим основные свойства и страницы связи.

Cardinality – мощность связи (отношение числа экземпляров родительской сущности к числу экземпляров дочерней): ни одного (Zero), один (One), более одного (More), указанное число (Exactly). Мощность свя­зи между сущностями по умол­ча­нию не показывается на диаграмме, и для ее отображения нужно выпол­нить команду Relationship Display/Car­di­na­lity из контекстного меню диаг­рам­мы.

Ver Phase – имя связи от родительской к дочерней сущности (Pa­rent‑to‑Chi­ld), и наоборот, для связи «многие‑ко‑многим» (Child‑to‑Parent).

Relationship Type идентифицирующая/неиндентифицирующая связь (Iden­­­tifying/Non‑Identifying).

Null – обязательная/необязательная связь (No Nulls/Nulls Allowed). Не­обя­за­тель­ная неидентифицирующая связь помечается прозрачным ром­би­ком со стороны родительской сущности (рисунок 3.2.3.2).

Definition – на странице задается полное определение связи для возмож­ности ссылки на эту связь.

R olename ­– на странице в поле Rolename задается имя роли (функ­циональ­ное имя – си­но­ним атрибута) внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности (рисунок 3.2.3.4).

Риc. 3.2.3.4. Страница имен ролей

По умол­ча­нию в списке атрибутов показывается только имя роли. Если выпол­нить команду Entity Display/Rolename/Attribute из контекстного меню диаг­рам­мы, то будет показываться полное имя в виде:

<имя роли>.<базовое имя атрибута> (рисунок 3.2.3.5).

Имена ролей обязательны, если несколько атрибутов имеют одина­ко­вую область значений, но разный смысл (рисунок 3.2.3.5).

Рисунок 3.2.3.5. Пример обязательности имен ролей

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

Рисунок 3.2.3.6. Пример иерархической рекурсивной связи

Связь вида Руководит/Подчиняется, позволяющая хранить древо­видную ие­рар­хию подчиненности сотрудников, называется иерархической ре­кур­сией.

С етевая рекурсия (рисунок 3.2.3.7) предполагает отношение «мно­гие‑ко‑мно­гим». Для разрешения такой связи создается новая сущ­ность.

Рисунок 3.2.3.7. Пример сетевой рекурсивной связи

Правила ссылочной целостности устанавливаются на странице RI Actions (рисунок 3.2.3.8).

Рисунок 3.2.3.8. Установка правил ссылочной целостности связи

Контроль целостности связей осуществляется автоматически СУБД согласно правилам, которые устанавливаются при проектиро­ва­нии БД.

Правила задаются следующими параметрами.

CASCADE/RESTRICT – разрешает/запрещает каскадные операции.

Ввод данных. Если добавляется новая запись в дочерний объект, для которого отсутствует запись из родительского объекта, то такой ввод мо­жет быть заблокирован (CASCADE).

Пример. Блокировка ввода записи дочернего объекта «СОТРУД­НИК», ес­ли указывается значение атрибута «Код подразде­ле­ния», отсут­ствую­ще­го в родительском объекте «ПОДРАЗДЕЛЕНИЕ».

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

Пример. После изменения в родительском объекте «ПОДРАЗДЕЛЕ­НИЕ» значения атрибута «Код подразделения» с 2 на 202 автоматически из­ме­нят­ся в дочернем объекте «СОТРУДНИК» все записи со значением атрибута «Код подразделения», равным 2, на новое значение 202 (все сотрудники из подразделения с кодом 2 переведутся в подразделение с новым кодом 202). Если такой перевод не может быть реальным, то можно установить правило блокировки корректировки, что не позволит изменить код под­раз­де­ления в объекте «ПОДРАЗДЕЛЕНИЕ» на новое значение, если есть сот­руд­ники в данном подразделении.

Удаление записей. Если удаляется запись ро­ди­тель­ского объекта, то автоматически удаляются все соответ­ст­вую­щие записи дочернего объекта (CASCADE) или удаление нужно заблокировать (RESTRICT).

Пример. После удаления в родительском объекте «ПОДРАЗДЕЛЕ­НИЕ» записи со значением атрибута «Код подразделения», равным 201, авто­матически удаляются в дочернем объекте «СОТРУДНИК» все записи со значением атрибута «Код подразделения», равным 201 (все сотрудники из подразделения с кодом 201 увольняются). Если такого расфор­миро­ва­ния подразделения не может быть, то устанавливают правило блокировки каскадного удаления записей. Это не позволит удалить запись с кодом под­раз­де­ления в объекте «ПОДРАЗДЕЛЕНИЕ», равным значению 201 (снача­ла нужно удалить все записи из объекта «СОТРУДНИК» со значением атри­бута «Код под­раз­де­ле­ния», равным 201, а затем удалить запись в ро­ди­тельском объекте «ПОД­РАЗДЕЛЕНИЕ» со значением атри­бута «Код подразделения», равным 201).

NONE – отмена контроля ссылочной целостности. Значение внешнего клю­ча не меняется при соответствующих операциях (для дочерних записей могут отсутствовать родительские записи).

SET NULL/DEFAULT – при удалении родительской записи зна­чения внеш­­них ключей в до­чер­них записях примут значения NULL/умал­чи­ва­е­мые (дочерние записи будут автоном­ными/переподчинены другой роди­тель­ской записи со значением ключа, равным умалчиваемому значению).

Эти правила можно отобразить в диаграмме командой Format/Rela­ti­on­­ship Display/Referential Integrity.

Связь «многие‑ко‑многим» допускается только на логическом уровне.

Р ассмотрим пример такой связи (рисунок 3.2.3.9).

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

При переходе к физическому уровню командой Create Accosiation Table из контекстного меню этой связи она преоб­ра­зу­ет­ся в две связи «один‑ко‑мно­гим» к новой созданной таблице-связке (рисунок 3.2.3.10) .

Рисунок 3.2.3.10. Связь «многие‑ко‑многим» на физическом уровне

Имя этой сущности можно изменить, например на Визит. Первич­ные ключи мигрируют в эту сущность. Первич­ный ключ этой сущ­нос­ти можно дополнить, например, датой визита пациента (рисунок 3.2.3.11).

Вне­сен­ные изменения на физическом уровне не изменяют представление на ло­ги­ческом уровне (рисунок 3.2.3.9).

Рисунок 3.2.3.11. Дополнение физической модели со связью «многие‑ко‑многим»