3. Преобразование концептуальной модели в реляционную
Следующим шагом нашей работы станет построение логической модели хранения данных на основании концептуального проектирования.
Модель данных есть формальная теория, определяющая фундаментальные свойства хранения и обработки данных. Классическими примерами моделей данных являются иерархическая, сетевая, реляционная и объектная.
Доминирующей на данный момент моделью данных является реляционная. Исторически она пришла на смену иерархической и сетевой моделям в широком применении, начиная приблизительно с 1970-х годов. Преимуществами этой модели являются чёткая и простая логическая структура, мощная теоретическая база, поддержка целостности данных, существование широкого спектра качественных языковых и программных средств.
Важной составляющей реляционной модели является теория нормальных форм. Нормальные формы представляют собой определенные состояния отношений, характеризующие их избыточность. Существуют нормальные формы от первой до шестой включительно, с некоторыми промежуточными состояниями, не имеющими номера. Каждая последующая нормальная форма дополняет требования к предыдущей.
Процесс приведения реляционной базы данных в соответствие с нормальными формами называется нормализацией. Этот процесс является рекомендуемым этапом при проектировании структур реляционных баз данных. Применение нормализации позволяет исключить избыточность, построить чёткую и логичную взаимосвязь данных, заложить фундамент их целостности. На начальном этапе достаточной глубиной нормализации считается доведение до третьей нормальной формы включительно. Исходя из практических соображений, на последующих этапах проектирования и реализации возможна дальнейшая нормализация или денормализация.
Первая нормальная форма требует, чтобы каждый атрибут каждого кортежа содержал единственное значение. Данное требование выполняется в реляционной модели всегда по определению.
Вторая нормальная форма требует неприводимой зависимости каждого неключевого атрибута от потенциального ключа отношения. На практике это означает, что в отношениях с составным ключом все неключевые атрибуты должны зависеть от каждого атрибута составного ключа. Также данное требование вносит ограничение на существование независимых от потенциального ключа неключевых атрибутов.
Третья нормальная форма требует отсутствия транзитивной зависимости неключевых атрибутов от потенциального ключа. На практике при существовании таких транзитивных зависимостей для достижения третьей нормальной формы необходимо разбивать одно отношение на несколько с отсутствием таких зависимостей.
Создадим все необходимые ключевые атрибуты, определим отношения между ними. После выполнения работ по преобразованию концептуальной модели в логическую получим следующую структуру логических сущностей.
Сущность «Страны» (табл. 1).
Таблица 1
Структура сущности «Страны»
|
Название атрибута |
Ключ |
Обязательное |
|
Код страны |
Главный |
Да |
|
Название страны |
|
Да |
Сущность «Города» (табл. 2).
Таблица 2
Структура сущности «Города»
|
Название атрибута |
Ключ |
Обязательное |
|
Код города |
Главный |
Да |
|
Код страны |
Внешний |
Да |
|
Название города |
|
Да |
Поле «Код страны» сущности «Города» ссылается на перечень значений «Код страны» сущности «Страны»
Сущность «Виды транспорта» (табл. 3).
Таблица 3
Структура сущности «Виды транспорта»
|
Название атрибута |
Ключ |
Обязательное |
|
Код вида транспорта |
Главный |
Да |
|
Название вида транспорта |
|
Да |
Сущность «Туристы» (табл. 4).
Таблица 4
Структура сущности «Туристы»
|
Название атрибута |
Ключ |
Обязательное |
|
Код туриста |
Главный |
Да |
|
ФИО туриста |
|
Да |
|
Возраст туриста |
|
Да |
Сущность «Туры» (табл. 5).
Таблица 5
Структура сущности «Туры»
|
Название атрибута |
Ключ |
Обязательное |
|
Код тура |
Главный |
Да |
|
Название тура |
|
Да |
|
Продолжительность |
|
Да |
|
Описание |
|
Нет |
|
Код вида транспорта |
Внешний |
Да |
Поле «Код вида транспорта» сущности «Туры» ссылается на перечень значений «Код вида транспорта» сущности «Вида транспорта»
Сущность «Отели» (табл. 6).
Таблица 6
Структура сущности «Отели»
|
Название атрибута |
Ключ |
Обязательное |
|
Код отеля |
Главный |
Да |
|
Название отеля |
|
Да |
|
Класс обслуживания |
|
Нет |
|
Суточная плата за проживание |
|
Да |
|
Код города |
Внешний |
Да |
Поле «Код города» сущности «Отели» ссылается на перечень значений «Код города» сущности «Города».
Сущность «Путевки» (табл. 7).
Таблица 7
Структура сущности «Путевки»
|
Название атрибута |
Ключ |
Обязательное |
|
Код путевки |
Главный |
Да |
|
Дата вылета на отдых |
|
Да |
|
Код тура |
Внешний |
Да |
|
Код отеля |
Внешний |
Да |
|
Код туриста |
Внешний |
Да |
Поле «Код тура» сущности «Путевки» ссылается на перечень значений «Код тура» сущности «Туры».
Поле «Код отеля» сущности «Путевки» ссылается на перечень значений «Код отеля» сущности «Отели».
Поле «Код туриста» сущности «Путевки» ссылается на перечень значений «Код туриста» сущности «Туристы».
При помощи инструмента моделирования Sybase Power Designer создадим реляционную модель информационной системы (рис. 4).
Рис. 4. Реляционная модель информационной системы
На этой модели присутствуют обозначения:
<pk> - главный ключ;
<fk> - внешний ключ;
null/not null – обязательное/ не обязательное поле.