Связи более высокого порядка

Пусть концептуальная модель представлена следующим фрагментом (рисунок 7.6):

Рисунок 7.6 – n-арная связь

В этом случае для получения 3НФ необходимо создать 4 отношения:

ПРЕПОДАВАТЕЛЬ (Табельный номер, ФИО, Кафедра);

ДИСЦИПЛИНА (Код дисциплины, Название дисциплины);

СПЕЦИАЛЬНОСТЬ (Код специальности, Название специальности);

ОБУЧАЕТ (Табельный номер, Код дисциплины, Код специальности).

Правило. Если связь n-арная, то строится по одному отношению для каждой сущности и одно отношение для связи; отношение для связи содержит ключи всех сущностей, первичным ключом отношения для связи является ключ, состоящий из ключей всех сущностей; отношение для связи может иметь собственные описывающие атрибуты.

Классы и подклассы

Переход от иерархии сущностей к отношениям реляционной модели может быть осуществлён по следующему правилу:

для каждой сущности в иерархии строится отдельное отношение.

Рассмотрим пример (рисунок 7.7).

Рисунок 7.7 – Классы и подклассы

Создадим следующие отношения:

РАБОТАЮЩИЙ (Табельный номер, ФИО, Дата рождения);

МАСТЕР (Табельный номер мастера, Оклад, Телефон);

РАБОЧИЙ (Табельный номер рабочего, Тарифная ставка, табельный номер мастера).

Полученные отношения находятся в 3НФ, в них отсутствует избыточность.

На практике полученная модель имеет ряд недостатков.

Предположим, необходимо реализовать следующий запрос: вывести сведения о сотруднике Иванове И.И.

Алгоритм выполнения этого запроса в случае, когда должность сотрудника неизвестна, требует предварительного объединения всех отношений и применения к полученному отношению операции селекции. Если количество подклассов в иерархии велико, то запрос будет выполняться медленно.

Для ускорения поиска можно в отношении РАБОТАЮЩИЙ предусмотреть поле Должность. Значение в этом поле точно определит, в каком отношении необходимо продолжить поиск. Предположим, в результате запроса к отношению РАБОТАЮЩИЙ установлено, что атрибут Должность у Иванова И.И. имеет значение "Мастер", тогда поиск необходимо провести в отношении МАСТЕР. Такой алгоритм нельзя реализовать средствами реляционной алгебры.

Вывод. Реляционная алгебра не поддерживает операции над классами и подклассами. Окончательное решение по способу реализации иерархий сущностей принимается на физическом этапе проектирования.

Физическая модель данных

Исходные данные для физического проектирования

Исходные данные включают:

- результаты логического этапа проектирования;

- особенности СУБД.

К началу физического проектирования логическая модель представляет собой полностью нормализованные сущности:

- каждая сущность имеет первичный ключ для идентификации;

- все атрибуты каждой сущности атомарны, неделимы и не являются частью списка значений (нет повторяющихся групп);

- каждая сущность содержит атрибуты, которые применяются только для этой сущности и зависят только от полного первичного ключа этой сущности.

Рассмотрим характеристики СУБД, знание которых необходимо при физическом проектировании БД:

- объекты базы данных, физические структуры данных и файлов, поддерживающих эти объекты;

- способы поддержки индексации, ссылочной целостности, ограничений;

- типы данных;

- параметры конфигурирования СУБД;

- язык определения данных (Data Definition Language - DDL) для преобразования физического проекта в реальные объекты базы данных и др.

8.2 Возможная методика перехода к физической модели на примере реляционной модели

8.2.1 Преобразование отношений в таблицы

Каждому отношению логической модели ставится в соответствие таблица физической модели.

Отступление от этого правила возможно, если для повышения производительности проводится денормализация базы. Процедура денормализации будет рассмотрена позднее.

Имя таблицы может совпадать с именем отношения, если оно не противоречит требованиям СУБД и корпоративным правилам формирования имён объектов базы данных.

8.2.2 Преобразование атрибутов в поля (столбцы) таблиц

Каждому атрибуту должен соответствовать аналогичный столбец таблицы.

На этом этапе не рекомендуется объединять столбцы в один составной столбец. Имена столбцов формируются аналогично именам таблиц.

8.2.3 Преобразование доменов в типы данных

В зависимости от СУБД могут быть доступны следующие средства описания доменов:

- с помощью типов данных с возможными ограничениями на значение;

- с помощью типов данных, определяемых пользователем;

- средства создания физических доменов.

Рассмотрим проблемы, с которыми можно столкнуться при описании доменов с помощью стандартных типов СУБД.

Проблема 1. Для домена не подходит ни один из встроенных типов данных, например, нет денежного типа данных.

Проблема 2. Для домена применимы несколько типов данных.

Например, логический домен задан множеством {1, 2, … ,10}. Для этого домена подходят все целые типы данных, вещественные с нулевой дробной частью и символьный тип с длиной в 2 байта (если с данными не проводятся никакие вычисления).

Для правильного выбора необходимо знать, как каждый тип хранится на физическом уровне, и как эти данные будут использоваться в приложениях.

Проблема 3. Обычно данные символьного (текстового) типа могут иметь фиксированную или переменную длину. Необходимо сделать выбор для таких данных.

Поля с переменной длиной потребуют меньше памяти, но - больше усилий при выполнении вставок новых строк.

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

После выбора типа и описания ограничений, если они есть, для каждого атрибута необходимо указать возможность принимать неопределённое значение (NULL - значение) (см. концептуальный уровень проектирования).

Для атрибута можно задать значение по умолчанию.

Первичные ключи

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

Если ключ состоит из нескольких столбцов, если в ключе использованы нестандартные типы данных и ключ имеет большую длину, то в таблицу можно добавить, так называемый, "суррогатный" ("свёрнутый") первичный ключ.

Большинство СУБД предоставляет средства для создания таких ключей, например, тип Счётчик в СУБД Access. В некоторых СУБД для целей автоматического формирования значения ключа используется специальное свойство "Идентичность" стандартного целого типа или специальный объект, генерирующий такие значения.

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