Проектирование баз данных 2 (стр. 2 из 4)

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

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

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

3. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных

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

Рис. 3.3. Диаграмма декомпозициии процесса проектирования базы данных: второй уровень. Сбор и анализ входных данных

Такими задачами являются:

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

· контроль качества результатов анализа предметной области базы данных;

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

· подготовка плана проектирования базы данных.

В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной модели предметной области. На основании ER-диаграмм создается логическая модель реляционной базы данных; на основании диаграмм функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных.

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

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

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

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

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

· нормализация сущностей предметной области:

· получить список атрибутов сущности;

· определить функциональные зависимости (ФЗ) в сущности;

· определить детерминанты сущности;

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

· выполнить нормализацию сущности (преобразовать сущность в отношение);

· для полученного отношения назначить первичные ключи;

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

· сформировать бизнес-правила поддержки целостности сущности, если необходимо;

· нормализация отношений логической модели базы данных:

· определить степень связи сущностей;

· определить класс принадлежности сущности к связи;

· нормализовать отношение (разрешить связи);

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

· определить атрибуты связывающих отношений, если необходимо;

· сформировать бизнес-правила поддержки целостности связей;

· проверка правильности логической модели реляционной базы данных:

· проверка отношений на соответствие нормальной форме Бойса-Кодда;

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

· предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;

· проверка на отсутствие незамкнутых связей;

· проверка на отсутствие одиночных отношений;

· формулировка части исходных данных для решения задачи управления ссылочной целостностью;

· документирование логической модели реляционной базы данных;

· принятие решения о реализуемости построенной логической модели реляционной базы данных;

· принятие решения о разработке физической модели реляционной базы данных.

·

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

На рис. 3.4-рис. 3.6 представлены бизнес-модели процессов создания логической модели базы данных, нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.

Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных

Рис. 3.5. Бизнес-модель процесса нормализации сущности

Рис. 3.6. Бизнес-модель процесса нормализации отношения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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