ERM (Entity-Relation Model) Анализ и проектирование структур данных с использованием CASEсредств

Стандарт IDEF1x. Общие сведения
Разработан в 1983 году в рамках проекта военного ведомства США "Интегрированные системы информационной поддержки" (ICAM).
Как методология семантического моделирования данных.
Cтал расширением методологии IDEF1.

IDEF1x. Базовые определения
Логическая модель.
Физическая модель.
Сущность (Entity).
Атрибут (Attribute).
Результат анализа исследуемой предметной области, в которой описаны основные сущности, их атрибуты, связи и другая необходимая информация.
Правильно спроектированная логическая модель может быть трансформирована в схему любой базы данных, поддерживающей реляционную модель.
Описание схемы данных СУБД в реляционной модели.
Помимо информации, полученной из логической модели, в физической модели присутствуют компоненты, специфичные для конкретной СУБД, связанные с физическим размещением данных на накопителях, особенностями реализации хранимых процедур и т.п.
Множество однотипных объектов предметной области, называемых экземплярами.
Каждый экземпляр индивидуален и должен отличаться от других экземпляров.
Связь (Realtionship).
Ключ.
ПРАВИЛА ИМЕНОВАНИЯ СУЩНОСТИ
Сущности должны именоваться существительным в единственном числе с чётко выраженным смысловым значением
Имя сущности даётся по имени её экземпляра, что облегчает считывание модели
Для сущности, описывающей множество студентов группы,
правильным наименованием будет: «студент»,
неправильными – «студенты», «группа».
Выражает определённое свойство экземпляра сущности.
Сущности сопоставляется множество имён атрибутов.
Экземпляру дополнительно сопоставляется множество конкретных значений этих атрибутов.
Так обеспечивается однотипность объектов одной сущности.
Индивидуальность объекта обеспечивается запретом наличия двух экземпляров сущности, значения всех атрибутов которых попарно совпадают.
Именованное отношение между сущностями.
При наименовании связей следует использовать глаголы, либо глагольные фразы.
Атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности
Не имеет имени.

Связи
Связь
Правила именования связей (Verb Phrase)
Выражает некоторое бизнес-правило, либо ограничение, например –
МЕНЕДЖЕР оформляет ДОГОВОР,
ПРЕДМЕТ изучается СТУДЕНТОМ.
Связи подписываются над линией и обозначаются, например,
1..N (читается «один-ко-многим»),
N..N (читается «многие-ко-многим»).
Имя связи указывают в направлении от родительской к дочерней сущности.
Для отношения «многие-ко-многим» используют имена в обоих направлениях.
Мощность связи (Cardinality)
Служит для обозначения отношения числа экземпляров родительской
сущности к числу экземпляров дочерней.
1..0 или более. Символ не предусмотрен.
1..1 или более. Символ «P».
1..0 или 1. Символ «Z».
1..const. Обозначается соответствующим числом.

Связи
Идентифицирующая связь.
Связь между зависимой (дочерняя сторона связи) и независимой (родительская сторона связи) сущностями.
Неидентифицирующая связь.
Необязательная
Обязательная

Ключи
Виды ключей.
Потенциальным ключом - атрибут или группа атрибутов, однозначно
идентифицирующих экземпляр сущности.
В общем случае у сущности может быть несколько потенциальных ключей,
хотя для целей однозначной идентификации достаточно одного.
Сложный ключ (составной) – ключ, содержащий более одного атрибута.
Первичный ключ - один из потенциальных ключей.
Альтернативный ключ - потенциальный ключ, не ставший первичным.
Суррогатный ключ - создаётся на основе искусственно созданного атрибута,
не имеющего аналогов в предметной области, это – автоинкрементный
столбец, уникальность значений которого поддерживается СУБД.

Ключи
Требования к первичному ключу.
Уникальность
Компактность
Простота
Полная определенность
Постоянство во времени
Два экземпляра сущности не должны иметь одинаковых значений атрибутов, образующих ключ
Сложный ключ не должен содержать ни одного атрибута, удаление которого не привело бы к потере уникальности.
При выборе первичного ключа предпочтение отдаётся более простым ключам, т.е. ключам, содержащим меньшее количество атрибутов.
Ни один из атрибутов, образующих ключ, не должен содержать значение с предопределённым значением NULL (пустой, неопределённый).
Значения атрибутов ключа не должны изменяться на протяжении всего времени его существования.

Пример ER диаграммы
Проектирование модели данных на примере Интернет магазина

Фазы жизненного цикла проектирования
Разработка логической модели данных
Разработка физической модели данных

Этапы разработки логической модели данных
Разработка
ER-diagram
Разработка
KB-model
Разработка
FA-model
Разработка диаграммы «сущность-связь» (Entity-Relation diagram, ER).
Разработка диаграммы, основанной на ключах (Key Based model, KB).
Разработка полно-атрибутивной модели (Fully Attributed model, FA).

Этапы разработки физической модели данных
Создание трансформационной модели
Разработка модели СУБД

Разработка диаграммы «сущность-свзяь» (ER)
Последовательность разработки
Выделение сущностей предметной области (ПО)
Описание сущностей
Формирование тематических областей данных
Определение ключей и основных атрибутов сущностей
Определение связей
Описание связей

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

Выделение тематических областей данных
Данные, описывающие пользователей.
Данные, описывающие заказы пользователей.
Данные, описывающие товары интернет магазина.

Разработка диаграммы, основанной на ключах (Key Based model, KB).
ID пользователь
ID заказ
ID статус заказа
ID права
ID товар
ID категория
Первичный ключ (Primary Key)
Первичный ключ (Primary Key)

Разработка полно-атрибутивной модели (Fully Attributed model, FA)
Порядок разработки FA Model
Формирование полных наборов атрибутов каждой из сущностей.
Использование доменов
Имя связи в направлении предок – потомок (только для связей типа N..N)
Нормализация
Рекомендации по приведению модели данных к нормальному виду
Для приведения модели к первой нормальной форме удалите повторяющиеся атрибуты, либо группы атрибутов сущности
Для приведения модели ко второй нормальной форме удалите атрибуты, зависящие только от части уникального идентификатора
Для приведения модели к третьей нормальной форме удалите атрибуты, значения которых зависят от атрибутов, не входящих в уникальный идентификатор.

Разработка полно-атрибутивной модели (Fully Attributed model, FA)
ID пользователь
ID заказ
ID статус заказа
ID права
ID товар
ID категория
ФИО
Логин
Пароль
E-mail
Телефон
Номер
Дата создания
Статус
Наименование
Наименование
Наименование
Описание
Количество
Цена
Наименование
Основные атрибуты сущности

Определение связей между сущностями ПО
Порядок определения связей
Классификация связи
Имя связи в направлении потомок – предок
Имя связи в направлении предок – потомок (только для связей типа N..N)
Мощность связи
Определение связи (по аналогии с определением сущности)

ID пользователь
ID заказ
ID статус заказа
ID права
ID товар
ID категория
ФИО
Логин
Пароль
E-mail
Телефон
ID права
Номер
Дата создания
Статус
ID пользователь
ID статус заказа
Наименование
Наименование
Наименование
Описание
Количество
Цена
ID категория
Наименование
Определение связей между сущностями ПО
создает
имеет
содержит
входит в
содержит
имеет
1
N
N
N
N
1
1
1
1
1
Связь «один ко многим»
Один пользователь может создать не ограниченное количество заказов.
мощность связи
Связь «один к одному»
Заказ имеет один определенный статус в определенный период времени.
Связь «один к одному»
Пользователь имеет права, закрепленные за одним идентификатором права.
Связь «многие ко многим»
Заказ содержит неограниченное количество товара. Единица товара может входить в неограниченное количество заказов
Связь «один ко многим»
Категория товара содержит неограниченное количество товара
Миграция атрибутов.
Внешний ключ.

Миграция атрибутов
При формировании связи между двумя сущностями атрибуты ПК родительской сущности мигрируют (копируются) в дочернюю сущность.
Процесс миграции характерен как для идентифицирующей, так и к неидентифицирующей связи, однако его реализация различна.
Атрибуты, мигрировавшие по идентифицирующей связи, входят в ПК дочерней сущности, а атрибуты, мигрировавшие по неидентифицирующей связи – нет.
В любом случае, совокупность атрибутов, появившаяся в дочерней сущности путём миграции, образует так называемый внешний ключ (FK).

Связь «многие ко многим» в схеме СУБД
ID заказ
ID товар
Номер
Дата создания
Статус
ID пользователь
ID статус заказа
Наименование
Описание
Количество
Цена
ID категория
содержит
входит в
N
N
Рассмотрим связь «многие ко многим» в приведенном примере.
Заказ может содержать большое количество товара и каждый товар, в свою очередь, может входить в несколько заказов.
Для практической реализации данной связи в схеме СУБД необходимо ввести таблицу связи, где каждому ID заказа будет соответствовать несколько ID товара.
ID заказ
ID товар
Номер
Дата создания
Статус
ID пользователь
ID статус заказа
Наименование
Описание
Количество
Цена
ID категория
1
N
1
N
ID заказ
ID товар
Таблица связи или вспомогательная таблица.

Создание трансформационной модели
Создаётся CASE-средством автоматически.
Содержит всю информацию, необходимую для генерации схемы данных в реляционной СУБД, поддерживающей стандарт SQL.
Инвариантна к конкретной реализации.