Правила ссылочной целостности
При генерации схемы базы данных на основе опций логической модели, задаваемых во вкладке Rolename/RI Actions, будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность.
Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT,UPDATEилиDELETE).
Например, между сущностями АГЕНТ и ФИЛИАЛ существует идентифициующая связь. Что будет, если удалить филиал? Экземпляр сущности АГЕНТ не может существовать без филиала (атрибут первичного ключа «В каком филиале работает/Номер филиала» не может принимать значениеNULL); следовательно, нужно либо запретить удаление филиала, пока в ней числится хотя бы один агент.
Возможна установка следующих правил удаления (если таковые поддерживаются СУБД):
SET DEFAULT— при удалении атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении филиала фирмы все агенты могут быть переведены в другой филиал.
NONE— при удалении значение атрибута внешнего ключа не меняется. Запись об агенте «повисает в воздухе», т. е. ссылается на несуществующий филиал. Такая ситуация характерна для «плоских» таблиц. Например, если информация об агентах и филиалах фирмы хранится в dbf-файлах, можно удалить запись о филиале, при этом файл агентов «ничего не будет знать» о том, что соответствующего филиала не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.
RESTRICT — для удаления записи необходимо удалить все дочерние записи с внешним ключом, равным первичному ключу удаляемой записи. Например, для удаления филиала сначала нужно удалить всех агентов этого филиала.
CASCADE. — при удалении опорного экземпляра сущности (соответствующего концу связи «один») нужно удалить и все экземпляры сущности, соответствующие концу связи «многие». Например, вместе с филиалом фирмы будут удаляться все агенты данного филиала.
Правила удаления управляют тем, что будет происходить в базе данных при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с базой данных, если строки изменяются или добавляются.
Зависимые и независимые сущности.
При построении модели, основанной на ключах, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей внешний ключ является частью первичного ключа дочернего объекта.
Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.
Рис. П7. Пример зависимых сущностей
В примере на рис. П7 сущность «СЕАНС» является зависимой сущностью потому, что его идентификация зависит от сущностей «ЗРИТЕЛЬ» и «ФИЛЬМ». В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.
Зависимые сущности далее классифицируются на
сущности, которые не могут существовать без родительской сущности
сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации).
Сущность Сеанс принадлежит к первому типу зависимых сущностей, так как сеанс не может существовать без фильма.
Рассмотрим две сущности: «СТРАХОВАНИЕ», в процессе которого могут учитываться «Страховые факторы», снижающие страховые риски. Связь между этими двумя сущностями может быть выражена в виде «ФАКТОР РИСКА» <снижает риск> в одном или нескольких «СТРАХОВАНИЯХ». Но существуют такие страхования (страховки), для которых нет факторов, снижающих страховой риск. В этом случае, «СТРАХОВАНИЕ» может быть идентифицировано с использованием нулевого ключа родителя («ФАКТОР РИСКА»), но без экземпляра родительской сущности.
Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущности Зритель и Фильм можно считать независимыми. В IDEF1X независимые сущности представлены в виде прямоугольников.