Бизнес-модель этапа проектирования - создание физической модели реляционной базы данных

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

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

• Создание базовых таблиц. Они представляют основные блоки хранения данных и выводятся из сущностей логической модели данных. При создании каждой таблицы проектировщик должен рассмотреть и учесть ряд факторов:

  • определить список колонок в таблице. Колонки выводятся из атрибутов сущности логической модели данных;

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

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

  • определить ряд параметров, связанных с характером хранения таблицы в физической базе данных;

  • определить ограничения на значения колонок, исходя из ряда бизнес-правил.

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

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

  • идентифицировать первичные ключи каждой таблицы;

  • построить индексы первичного ключа;

  • определить внешние ключи в дочерних таблицах, если необходимо;

  • построить команды SQL, которые идентифицируют внешние ключи в дочерних таблицах и правила поддержки ссылочной целостности;

  • Если необходимо, построить представления внешней схемы базы данных.

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

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

Создание объектов для хранения данных

Создание таблиц

Идентифицировать таблицу

Определение типов данных колонок

Определение первичного ключа

Добавление ограничений

Создание таблиц для взаимосвязи "многие-ко-многим"

Создание индексов

Создание представлений

Создание других объектов базы данных

Проверка корректности созданной физической модели

На рис. 3.7 ниже представлена модель бизнес-процессов первой итерации физической модели базы данных, а на рис. 3.8 - декомпозиция работы по созданию базовой таблицы.

Рис. 3.7. Декомпозиция этапа проектирования - создание первой итерации физической модели базы данных: внутренняя схема

Рис. 3.8. Декомпозиция работы по созданию базовой таблицы

На этом мы заканчиваем рассмотрение задач проектировщика базы данных по созданию первой итерации физической модели реляционной базы данных - внутренней схемы. Главная цель этапа - создать последовательность команд SQL для создания объектов хранения данных. Также опционально можно создавать другие объекты, такие как синонимы, представления и индексы. Можно принять решение о поддержки ссылочной целостности базы данных программными механизмами СУБД и создать соответствующий набор команд SQL. В следующей лекции мы продолжим работу над созданием физической модели базы данных.