Синтаксис и семантика моделей IDEF1X

Одним из методов моделирования данных является метод IDEF1. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X, которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin).

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

Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Зависимые сущности обозначаются прямоугольниками с закругленными углами (см. рис.П5.2).

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

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

В IDEF1X могут быть выражены следующие мощности связей:

каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

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

При установлении неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют (переносятся автоматически) в состав неключевых атрибутов дочерней сущности. Так на рис.П5.1 первичный ключ «Номер отдела» родительской сущности «Отдел» мигрировал в состав неключевых атрибутов дочерней сущности «Сотрудник».

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

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

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в состав первичного ключа дочерней сущности. На рис.П5.2 показана идентифицирующая связь между независимой сущностью «Клиент» (родительская сущность) и зависимой сущностью «Заказ» (дочерняя сущность). При установлении данной связи первичный ключ «Номер клиента» мигрировал в состав первичного ключа дочерней сущности.

Мигрировавшие при установлении связи атрибуты помечаются как внешние ключи буквами FK (Foreign Key) в скобках (см. рис. П5.1, П5.2).

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

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

Рассмотрим правила ссылочной целостности на примерах. В модели данных, представленной на рис. П5.3, экземпляр сущности «Игрок» не может существовать без соответствующего экземпляра сущности «Команда». То есть значение атрибута «Номер команды» в экземпляре сущности «Игрок» не может принимать пустое значение (NULL).

В этом случае удаление экземпляра сущности «Команда» (удаление команды) можно организовать по двум правилам:

1.Запретить удаление команды, пока в ней числится хотя бы один игрок, т.е. пока есть экземпляры сущности «Игрок», имеющие внешний ключ «Номер команды», совпадающий с первичным ключом «Номер команды» в удаляемом экземпляре сущности «Команда». При таком запрете для удаления команды сначала нужно удалить всех ее игроков.

2.Вместе с командой удалить всех ее игроков.

Первое правило удаления называется ограничением (RESTRICT), второе - каскадом (CASCADE).

Обратите внимание, что сущности «Игрок» и «Гол» в свою очередь тоже связаны идентифицирующей связью. Если для этой связи установлено правило удаления CASCADE, то при удалении команды будут удалены все игроки и все голы, которые они забили.

Теперь обратимся к рис. П5.1а (см. выше). На рис. П5.1а представлена модель, в которой установлена необязательная неидентифицирующая связь между сущностями «Отдел» и «Сотрудник». В этом случае экземпляр сущности «Сотрудник» может существовать без ссылки на отдел, т.е. внешний ключ «Номер отдела» в сущности «Сотрудник» может принимать значение NULL. В этом случае в качестве правила удаления отдела можно использовать правило установки в нуль (SET NULL). При использовании этого правила после удаления отдела всем сотрудникам данного отдела в качестве значения атрибута «Номер отдела» присваивается значение NULL. Другими словами, после удаления отдела информация о сотрудниках данного отдела сохраняется, но теперь сотрудники не приписаны ни к какому отделу.

Иногда более удобно считать, что при удалении отдела, все сотрудники переведены в некоторый отдел по умолчанию. В этом случае вместо правила SET NULL нужно использовать правило установки по умолчанию SET DEFAULT.

Иногда в качестве правила ссылочной целостности применяют правило NONE. В этом случае при удалении экземпляра родительской сущности значение внешнего ключа в экземплярах дочерней сущности не меняется.

При использовании правила NONE в рассматриваемом примере (рис.П5.1а) после удаления отдела у всех сотрудников, которые относились к данному отделу, значение атрибута «Номер отдела» не изменится. Таким образом, появляются экземпляры сущности «Сотрудник», которые ссылаются на несуществующий отдел.

Правило NONE используется в настольных или файл-серверных БД. В таких БД правила ссылочной целостности реализуются в клиентском приложении.

Итак, мы рассмотрели на двух простых примерах правила поддержания ссылочной целостности при удалении (DELETE) экземпляра сущности. Аналогично определяются правила вставки (INSERT) и обновления (UPDATE). Например, можно установить правило, которое разрешает вносить новую команду только тогда, когда в нее зачислен хотя бы один игрок. Такое правило можно реализовать следующим образом:

1. Задать мощность связи между сущностями «Команда» и «Игрок» типа «один или более» (One or more).

2.Действию INSERT присвоить правило CASCADE. В этом случае при создании нового экземпляра сущности «Команда» автоматически будет создаваться новый связанный экземпляр сущности «Игрок».

3.Действию DELETE присвоить правило CASCADE для того, чтобы при удалении экземпляра сущности «Команда» удалялись все связанные экземпляры сущности «Игрок».

Иерархия наследования

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

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

Иерархия наследования подразделяется на две категории: полная и неполная.

В полной категории одному экземпляру родового предка обязательно соответствует экземпляр в каком-либо потомке. В рассмотренном примере (рис.П5.4а) иерархия наследования относится к полной категории.

Если иерархия еще не полностью определена и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая иерархия относится к неполной категории. Пример неполной категории иерархии наследования показан на рис. П5.4б. Сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность «Консультант» еще не внесена в данную иерархию наследования.

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

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