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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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