Лекция 9. Проектирование баз данных

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

Основные понятия реляционной модели:

База данных – долговременное самодокументированное хранилище данных. Самодокументация = схема данных, хранящаяся в БД.

Система управления базами данных (СУБД) – ПО доступа к данным. Обеспечивает:

• защиту данных;

• эффективность;

• многопользовательский режим;

• разделение данных между несколькими приложениями;

• распределенность данных;

• безопасность.

Структура реляционных данных – совокупность таблиц. В любой таблице фиксированное количество столбцов и произвольное – строк. Совокупность значений ячеек одной строки – запись.

Оператор SQL – предложение SQL для манипуляции данными (выборка, изменение, добавление, удаление).

Ограничения – условия, являющиеся частью схемы БД. Если какая-либо добавляемая запись нарушает какое-то ограничение, то она не будет добавлена.

Виды ограничений:

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

Основной (первичный) ключ – возможный ключ, который предпочтительнее использовать для работы с таблицей. Есть у каждой таблицы.

Внешний ключ – ссылка из другой таблицы на возможный ключ.

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

Для обеспечения ссылочной целостности применяют триггеры – процедуры, описанные на языке SQL, которые автоматически запускаются при модификации таблиц, с которыми они связаны. Триггеры не только обеспечивают целостность, с их помощью удобно реализовывать и более сложные манипуляцию с данными (бизнес-логику).

Триггеры являются частным случаем хранимых процедур. Хранимая процедура – это процедура, работающая с таблицами, которая скомпилирована и хранится в виде кода в БД и может быть вызвана из клиентской программы. Хранимые процедуры выгоднее SQL-запросов, но они доступны всем приложениям, работающим с БД, что иногда нежелательно.

Реляционная схема данных и объектная модель оперируют разными понятиями, из‑за чего необходима специальная работа по объектно-реляционному отображению. Отображение возможно в обе стороны: в прямую (от классов к таблицам) и в обратную (от таблиц к классам). В лекции мы будем говорить о прямом отображении, но обратное отображение подразумевается.

Еще одно предваряющее замечание. Получаемая при отображении схема БД зависит не только от совокупности устойчивых классов и связей между ними, но и от практических соображений. Например, может оказаться, что решение хранить все устойчивые объекты в одной «толстой» ненормализованной таблице, вполне себя оправдывает тем, что делает приемлемой скорость большинства запросов к БД. Описывая объектно-реляционное отображение, мы будем рассматривать решения, тяготеющие к получению нормализованной БД.

Переводить модель классов в схему БД предлагается в 3 этапа: отобразить классы в таблицы, отобразить ассоциации и отобразить связи обобщения.

Отображение классов

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

2. Уникальный идентификатор устойчивого класса превращается в первичный ключ таблицы. Если имеется несколько альтернативных уникальных идентификаторов, выбирается наиболее используемый. Если в модели для устойчивого класса явно не указан идентификатор, то в таблицу добавляется столбец ID – первичный ключ.

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

Отображение бинарных ассоциаций:

• «1 к 1му» – возможны различные решения, лучше создать общую таблицу для 2х классов. Столбцы – совокупность атрибутов. Первичный ключ – любой ID (первого или второго класса). Достигается максимально возможная экономия: одна таблица представляет оба класса и ассоциацию между ними.

• «1 к 0..1» – внешний ключ добавляется к таблице необязательного класса.

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

• «0..1 к 0..1» – рекомендуется отдельная таблица для связи. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

• «* к *» – для ассоциации заводится отдельная таблица. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

Отображение классов связанных N-арной ассоциацией:

Требуется таблица для хранения связи. Например, в случае тернарной (N=3) связи формируются четыре таблицы, по одной для каждого класса и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи каждой из 3х других таблиц.

Отображение классов-ассоциаций:

Атрибуты класса-ассоциации добавляются либо в создаваемую для связи таблицу, либо (если дополнительная таблица не требуется) в ту таблицу, куда добавляется внешний ключ.

Отображение квалифицированных ассоциаций

Решение:

• Определить, какие мощности были бы у полюсов ассоциации без квалификатора.

• Применить решение для ассоциаций с полученными мощностями.

• Добавить квалификатор как столбец (или столбцы) в ту же таблицу, куда добавляются внешние ключи.

• Как правило, квалификатор становится частью возможного ключа таблицы, в которую он добавлен.

Отображение обобщения (наследования):

Стратегии:

• для каждого класса своя таблица;

• для всей иерархии наследования одна таблица;

• таблицы только для конкретных (не абстрактных) классов;

• таблицы только для различных конкретных классов.

Какой именно способ выбрать диктуют соображения эффективности (скорость в обмен на объем памяти). Рассмотрим на примере. Пусть класс Person – абстрактный.

При использовании 1-го подхода будут созданы 4 таблицы. У таблиц Person, Student, Employee будет дополнительный столбец – тип, в котором будет храниться реальный тип объекта. Для каждого экземпляра класса Student будут две записи, одна в таблице студентов, вторая – в таблице персон. Для экземпляра StudentEmployee – четыре записи, по одной в каждой таблице. При чем у всех их будет одинаковое значение первичного ключа. Дублирование записей позволит быстро находить всех персон, всех студентов и т. п.

При втором подходе используется общая разреженная таблица. В ней также для каждой записи хранится ее тип. Неудобство состоит в том, что для любой записи о персоне есть риск «залезть» в поля, принадлежащие подклассу.

Третий подход позволяет сэкономить одну таблицу – Person – для поиска всех персон в БД будет создан View, объединяющий записи 3-х созданных таблиц.

Четвертый путь дает две таблицы (студентов и служащих) и два View (один для персон, второй для студентов-служащих).

Для изображения схем БД в виде диаграмм классов применяется специализированный набор стереотипов – профиль.

Таблица изображается как класс со стереотипом <<table>>. SQL-запросы также изображаются классами со стереотипом <<view>>. Столбцы таблиц представлены атрибутами классов-таблиц. Используются стереотипы <<column>> (обычный столбец) <<PK>> (столбец, входящий в первичный ключ), <<FK>> (столбец, входящий во внешний ключ), <<PK/FK>> (столбец, входящий в первичный и во внешний ключ). "Операции" таблиц моделируют ограничения или хранимые процедуры. Классификация студента хранится в отдельной таблице T_Classification. Так как этот класс абстрактный, то в таблице единственный служебный столбец, являющийся и первичным и внешним ключом (<<PK/FK>>). В таблицу T_Classification добавлены два ограничения: первичного и внешнего ключа, ограничение индекса и ограничение уникальности, определяющее, что с каждой записью классификации связана ровно одна запись из одной из двух оставшихся таблиц. Эти две таблицы для подклассов FullTimeClassification и PartTimeClassification. Помимо собственных столбцов в них есть служебный, являющийся и первичным и внешним ключом (<<PK/FK>>). Для <<PK/FK>> в каждой таблице добавлены 3 "операции"-ограничения: индекс, первичный и внешний ключ. Все связи идентифицирующие, так как всюду первичный ключ входит во внешний. Бывают неидентифицирующие связи, если первичный ключ не содержится целиком во внешнем ключе. Мощности на полюсах связей показывают соотношения количеств записей связанных значением внешнего ключа. Композиции указывают на зависимость по существованию между связанными записями.

3