Описание методологий IDEF1X и IE

Уровни моделирования данных делятся на общие модели, изображающие сущности в общем не детализированном виде, содержащем сущности важные для рассматриваемой предметной области и модели, детально изображающие взаимосвязи между сущностями предметной области в терминах конкретной СУБД, выбранной для реализации модели данных. Таким образом, на самом нижнем уровне представления модели в значительной степени зависят от выбранной реализации (СУБД) и, следовательно, модель, созданная для использования в СУБД Access будет значительно отличаться от SQL Server и тем более Oracle. Модели верхнего уровня технологически независимы и могут содержать информацию об элементах, физически не сохраняемых в БД.

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

Рис. Уровни создания моделей данных

Модели верхнего уровня делятся на две категории.

1. ERD (Entity Relationship Diagram) диаграммы Сущность-связь содержат наиболее общие для рассматриваемой предметной области сущности и связи между ними.
2. KB (Key Based) Models) – ключевые модели (модели, основанные на ключах) устанавливают границы требований к информации предметной области и содержат все ее сущности. В KB моделях начинают проявляться детали и особенности строения данных.

Модели нижнего уровня также делятся на две категории.

1. FA (Fully Attributed) модель с полным набором атрибутов, все отношения которой приведены к третьей нормальной форме, содержащая все необходимые элементы для полной реализации базы данных.
2. TM (Transformation Model) модель, представляющая собой трансформационную модель из реляционной в модель, предназначенную для реализации в конкретной СУБД с учетом ее особенностей. TM модель в большинстве случаев не удовлетворяет условиям третьей нормальной формы, т.к. она оптимизирована для использования в рамках конкретной СУБД с учетом ее особенностей и возможностей.

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

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

Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Рис. 2.30. Сущности

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.

Мощность связи. Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей:

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

Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается, как показано на рис. 2.31 (мощность по умолчанию - N).

Рис. 2.31. Мощность связи

Типы связей. В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Различают идентифицирующую и неидентифицирующую связи.

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

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

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

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

Может ли в идентифицирующей связи FK принимать NULL-значения? Так как он входит в состав ключа, то ответ однозначный – нет. А в неидентифицирующей связи?

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

Рис. 2.34. Атрибуты и первичные ключи

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

Сущности могут иметь также внешние ключи (Foreign Key – FK), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рисунок 2.35).

Рис. 2.35. Примеры внешних ключей

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