Лекция Проектирование реляционных баз данных с использованием семантических моделей: ER-диаграммы

Введение

1. Ограниченность реляционной модели при проектировании баз данных

2. Семантические модели данных

3. Семантическая модель Entity-Relationship (Сущность-Связь)

3.1. Основные понятия ER-модели

3.2. Уникальные идентификаторы типов сущности

4. Нормальные формы ER-диаграмм

4.1. Первая нормальная форма ER-диаграммы

4.2. Вторая нормальная форма ER-диаграммы

4.3. Третья нормальная форма ER-диаграммы

5. Более сложные элементы ER-модели

5.1. Наследование типов сущности и типов связи

5.2. Взаимно исключающие связи

6. Получение реляционной схемы из ER-диаграммы

6.1. Базовые приемы

6.2. Представление в реляционной схеме супертипов и подтипов сущности

6.3. Представление в реляционной схеме взаимно исключающих связей

Заключение

Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования разнообразных предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами в двух предыдущих лекциях механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.

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

С практической точки зрения наибольшую пользу могут принести рассмотренные приемы перехода от ER-диаграмм к схеме реляционной базы данных. Особенно могут пригодиться рекомендации по представлению в реляционной схеме связей «многие ко многим», подтипов и супертипов сущности и взаимно исключающих связей.

Как отмечалось в начале лекции 7, вопросы определения индексов и других вспомогательных структур данных относятся к этапу физического, а не логического проектирования данных. Конечно, на практике эти этапы часто перекрываются во времени. Заметим, кстати, что в SQL-ориентированных СУБД индексы для всех возможных и внешних ключей, как правило, создаются системой автоматически.

Этот аспект тоже относится к этапу физического проектирования, поскольку связан с особенностями реализации конкретной СУБД.

Хотя в большинстве SQL-ориентированных СУБД хранение неопределенных значений вызывает минимальные накладные расходы.