Введение

В этой рекомендации приведено описание методов преобразования постоянных классов проектирования модели проекта в таблицы модели данных.  

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

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

Преобразование постоянных классов в таблицы

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

В реляционной базе данных, составленной в третьей нормальной форме, каждый ряд таблицы (каждый "кортеж") рассматривается как объект. Столбец таблицы представляет постоянный атрибут или класс. (Помните, что постоянный класс может содержать временные атрибуты.) Поэтому в простом случае, когда нет ассоциаций с другими классами, преобразование выполняется очень легко. Тип данных атрибута соответствует одному из допустимых типов данных из столбцов.

Пример

Класс Пользователь:

при моделировании с помощью реляционной СУБД (RDBMS) будет преобразован в таблицу с названием Пользователь, состоящую из столбцов ИД пользователя, Имя и Адрес.

Ниже приведен пример такой таблицы:

Постоянные атрибуты и ключи

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

• Может ли этот постоянный атрибут служить ключом или частью ключа? Пример: "Атрибут X вместе с атрибутом Z служит уникальным идентификатором объекта". В таблице Пользователь столбец ИД пользователя содержит первичный ключ.
• Каково минимальное и максимальное значение атрибута?
• Можно ли при поиске использовать этот атрибут вместо ключа? Например, он может быть частью фильтра в следующем операторе выбора: "Обычно производится поиск всех экземпляров, где Y>1000."
• Есть ли у атрибута подобное описание: "Атрибут X - это количество повторных передач на 100 000 переданных элементов"?
• Может ли атрибут принимать цифровые значения и существуют ли правила для этих значений?
• Кто обладает правом обновлять атрибут? Пример: "Объект T могут изменять только пользователи с полномочиями класса nn."
• Кто обладает правом считывать атрибут? Примеры: "Объект P могут считывать пользователи с полномочиями классов yy и zz" или "Объект P включен в панели Vi и Vj."
• Существует ли достаточная информация об объеме или повторяемости? Примеры: "Существует не более 50 000 вариантов объекта A" или "В среднем в день изменяются 2000 объектов A".
• Является ли атрибут уникальным? Пример: Номер каждого водительского удостоверения уникален.

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

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

Пример:

Предположим, что существует следующая ассоциация между Заказом и Покупателем:

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

Преобразование ассоциаций типа агрегации в модель данных

Агрегацию также можно моделировать с помощью внешних ключей.

Пример:

Предположим, что существует следующая ассоциация между Заказом и Каталогом:

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

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

Моделирование отношений обобщения в модели данных

Стандартная реляционная модель данных напрямую не поддерживает моделирование наследования. Для моделирования наследования можно применять различные стратегии, а именно:

• Представление родительских и дочерних классов в отдельных таблицах. Таблица дочерних классов должна содержать внешние ключи, ссылающиеся на таблицу родительских классов. Для создания объекта дочернего класса необходимо объединить эти таблицы. Этот подход теоретически прост и облегчает процесс изменения модели, но его неудобно использовать из-за обилия дополнительных действий.
• Создание копии всех унаследованных атрибутов и ассоциаций в отдельных столбцах таблицы дочерних классов. Эта стратегия повторяет процесс денормализации стандартной реляционной модели данных.

Моделирование ассоциаций многие-ко-многим в модели данных

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

Пример:

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

Уточнение модели данных

После преобразования классов проектирования в таблицы и отношения модели данных эту модель при необходимости можно уточнить для обеспечения целостности ссылок и настройки доступа к данным через панели или с помощью хранимых процедур. Дополнительная информация приведена в разделе Рекомендация: Модель данных.

Прямое проектирование модели данных

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

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