- •1. Базовые определения и соглашения
- •1.1. Определение и описание сущности
- •1.2. Определение и описание связи
- •1.3. Действительные и недействительные связи
- •1.4. Атрибуты
- •1.5. Уникальный (ключевой) идентификатор
- •1.6. Правила оформления er-диаграммы
- •1.7. Резюме
- •2. Дополнительные определения и соглашения
- •2.1. Подтипы сущностей
- •2. Дополнительные определения и соглашения 25
- •2. Дополнительные определения и соглашения 27
- •2.2. Дополнительные соглашения для сущностей
- •2. Дополнительные определения и соглашения 29
- •2.3. Исключающая дуга
- •2. Дополнительные определения и соглашения 31
- •2. Дополнительные определения и соглашения 33
- •2.4. Дополнительные соглашения для связей
- •2. Дополнительные определения и соглашения 35
- •2.5. Домены
- •2. Дополнительные определения и соглашения 37
- •2.6. Резюме
- •3. Классические структуры и общие образцы
- •3.1. Классические иерархические структуры
- •3. Классические структуры и общие образцы 39
- •3. Классические структуры и общие образцы 41
- •3. Классические структуры и общие образцы 43
- •3. Классические структуры и общие образцы 45
- •3.2. Сетевые структуры
- •3. Классические структуры и общие образцы 47
- •3.3. Изменения во времени
- •3. Классические структуры и общие образцы 49
- •3.4. Накладная на материалы
- •3. Классические структуры и общие образцы 51
- •3.5. Классификации и категории
- •3. Классические структуры и общие образцы 53
- •3.6. Типы сущности
- •3. Классические структуры и общие образцы 55
- •3.7. Общая модель для Заказов
- •3. Классические структуры и общие образцы 57
- •3.8. Общая модель для ролей и работ
- •3. Классические структуры и общие образцы 59
- •3.9. Продукция
- •3. Классические структуры и общие образцы 61
- •3. Классические структуры и общие образцы 63
- •3. Классические структуры и общие образцы 65
- •4. Нормализация данных 67
- •4. Нормализация данных
- •4. Нормализация данных 69
- •4. Нормализация данных 71
- •5. Оценка качества модели "Сущность-Связь" 73
- •5.1. Качество er-модели в конце этапа стратегии
- •5. Оценка качества модели "Сущность-Связь" 75
- •5. Оценка качества модели "Сущность-Связь" 77
- •5.2. Качество er-модели в конце этапа анализа
- •5. Оценка качества модели "Сущность-Связь" 79
- •5. Оценка качества модели "Сущность-Связь" 81
2. Дополнительные определения и соглашения 33
─────────────────────────────────────────────────────────────────
2.4. Дополнительные соглашения для связей
* Разрешение связей типа "многие ко многим"
Связи типа "многие ко многим" могут применяться в течение
этапов СТРАТЕГИИ и АНАЛИЗА ЖЦ ПО. К концу этапа АНАЛИЗА они долж-
ны быть разрешены, т.е. устранены неточности, которые имеются в
этих слишком обобщенных связях. Разрешение связей типа "многие ко
многим" происходит путем вставки новой сущности между двумя кон-
цами связи, как показано на рис.2.8.
Перед
┌─────────────┐ ┌─────────────┐
│ ├┐обслуживается ┌┤ АГЕНСТВО │
│ САМОЛЕТ ├┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼┤ ПО │
│ ├┘ отвечать за└┤ ОБСЛУЖИВАНИЮ│
└─────────────┘ обслуживание└─────────────┘
После
┌─────────────┐
│ │ ┌─────────────┐
│ ОБСЛУЖИВАНИЕ├┐выполняться │ АГЕНСТВО │
│ ├┼──────────── ─ ─ ─ ─ ─ ─ ─┤ ПО │
│# * дата ├┘ отвечать│ ОБСЛУЖИВАНИЮ│
│ o результат│ за └─────────────┘
└─────┬┬┬─────┘
для└┼┘
│
│
│
проходить
┌──────┴──────┐
│ │
│ САМОЛЕТ │
│ │
└─────────────┘
Рис.2.8. Разрешение связи "многие ко многим"
с помощью интерсекции
Вновь созданная сущность должна быть именована; имя часто
подсказывается существительным из имен концов первоначальной свя-
зи как на рис.2.8. Преобразованная модель теперь дает возможность
проследить когда и как обслуживается самолет.
* Степень связности
Иногда может быть важна более точная информация о степени
связности множественного конца связи. Она может уточняться путем
указания предельного количества сущностей, участвующих в связи.
Информационно-логическое моделирование.
34 Модель "Сущность-Связь"
─────────────────────────────────────────────────────────────────
Для этого используются символы =, >, <, <=, >=. Следующие рисунки
показывают примеры изображения таких ограничений на ER-диаграммах.
┌─────────────┐ ┌─────────────┐
│ ├┐включаться в │ │
│ МЕСЯЦ ├┼──────────── ─ ─ ─ ─ ─ ─ ─┤ ГОД │
│ ├┘<=12 состоять│ │
└─────────────┘ из └─────────────┘
Рис.2.9. Пример 1
1Каждый ГОД может состоять из одного до двенадцати МЕСЯЦЕВ.
┌─────────────┐ ┌─────────────┐
│ ├┐принадлежать <=2 ┌┤ │
│ СЧЕТ ├┼──────────── ─ ─ ─ ─ ─ ─ ┼┤ ЛИЧНОСТЬ │
│ ├┘ быть └┤ │
└─────────────┘ собствеником└─────────────┘
Рис.2.10. Пример 2
1Каждый СЧЕТ может принадлежать от одного до двух ЛИЧНОСТЕЙ.
* Лишние связи
ER-диаграмма не должна иметь связей, которые, при всех обс-
тоятельствах, могут быть получены из других связей.
Заметим, что при работе с БД лишние связи могут повысить
производительность, но это должно решаться проектировщиком БД, а
не аналитиком.
ER-диаграмма на рис.2.11, на первый взгляд, производит впе-
чатление правдоподобной, и, конечно, отражает данные, необходимые
для печати билета; однако, связь БИЛЕТ на ПОЛЕТ однозначно опре-
деляет и АВИА РЕЙС, и АВИА ЛИНИЮ для БИЛЕТА. Следовательно, две
другие связи от сущности БИЛЕТ являются лишними.
.
