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

1.

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

2.

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

3.

IDEF1x. Базовые определения
Логическая модель.
Физическая модель.
Сущность (Entity).
Атрибут (Attribute).
Связь (Realtionship).
Ключ.

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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