Ри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/Relationship 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. Дополнение физической модели со связью «многие‑ко‑многим»