Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных
Перейдем ко второму уровню функциональной декомпозиции процесса проектирования базы данных в рамках его первого этапа - сбор и анализ входных данных. На рис. 3.3 представлена диаграмма декомпозиции процесса проектирования базы данных второго уровня, отражающая основные задачи этапа сбора и анализа входных данных.
Рис. 3.3. Диаграмма декомпозициии процесса проектирования базы данных: второй уровень. Сбор и анализ входных данных
Такими задачами являются:
сбор документации с результатами анализа предметной области базы данных в виде диаграмм, спецификаций и требований;
контроль качества результатов анализа предметной области базы данных;
систематизация требований и спецификаций заказчика к базе данных;
подготовка плана проектирования базы данных.
В ходе контроля качества основными моментами деятельности являются контроль ER-диаграмм и контроль диаграмм функциональной модели предметной области. На основании ER -диаграмм создается логическая модель реляционной базы данных; на основании диаграмм функциональной модели разрабатывается серверный код и проектируются модули приложений базы данных.
Систематизация требований заказчика к базе данных проводится с целью их адекватного распределения по этапам проектирования базы данных. Важным результатом систематизации является вывод о достаточности требований и реализуемости базы данных. Заказчик должен точно знать, что он получит и чего не получит в результате создания базы данных! Особенно важно указать, чего он не получит. Анализ требований на реализуемость базы данных в рамках конкретного ИТ-проекта служит основой для принятия решения менеджером проекта о возможности реализации проекта в целом.
Создав бизнес-модель проектирования базы данных, вы, фактически, составили план проектирования базы данных. Позициями рабочего плана являются работы бизнес-модели процесса проектирования базы данных, которые дополняются сведениями об ответственных исполнителях и сроках исполнения. Каждый уровень декомпозиции процесса уточняет этот план.
Настоящая бизнес-модель процесса проектирования базы данных представляет собой достаточно простой типичный пример бизнес-модели проектирования. В общем случае содержание бизнес-модели проектирования зависит от многих факторов: личности менеджера и состава команды проекта, объема проекта, проектных рисков и т.д.
В конце каждого модуля курса мы будем рассматривать диаграмму декомпозиции следующего этапа проектирования базы данных. Таким образом, к концу изучения курса у вас будет построена достаточно полная бизнес-модель процесса проектирования реляционной базы данных.
Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных
Продолжим функциональную декомпозицию процесса проектирования реляционной базы данных в рамках его второго этапа - создания логической модели базы данных.
Основной целью этапа создания логической модели базы данных является преобразование информационной модели предметной области базы данных в логическую модель реляционной базы данных. Создание логической модели базы данных предполагает решение следующих основных задач и выполнения операций в рамках таких задач:
нормализация сущностей предметной области:
получить список атрибутов сущности;
определить функциональные зависимости (ФЗ) в сущности;
определить детерминанты сущности;
определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.
выполнить нормализацию сущности (преобразовать сущность в отношение);
для полученного отношения назначить первичные ключи;
сформировать список кандидатов на внешние ключи, если необходимо;
сформировать бизнес-правила поддержки целостности сущности, если необходимо;
нормализация отношений логической модели базы данных:
определить степень связи сущностей;
определить класс принадлежности сущности к связи;
нормализовать отношение (разрешить связи);
назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
определить атрибуты связывающих отношений, если необходимо;
сформировать бизнес-правила поддержки целостности связей;
проверка правильности логической модели реляционной базы данных:
проверка отношений на соответствие нормальной форме Бойса-Кодда;
проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;
предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
проверка на отсутствие незамкнутых связей;
проверка на отсутствие одиночных отношений;
формулировка части исходных данных для решения задачи управления ссылочной целостностью;
документирование логической модели реляционной базы данных;
принятие решения о реализуемости построенной логической модели реляционной базы данных;
принятие решения о разработке физической модели реляционной базы данных.
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим". Иногда на этом этапе принимается решение о выборочной денормализации отношений.
На рис. 3.4-рис. 3.6 представлены бизнес-модели процессов создания логической модели базы данных, нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.
Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных
Рис. 3.5. Бизнес-модель процесса нормализации сущности
Рис. 3.6. Бизнес-модель процесса нормализации отношения
Представленные задачи составляют минимально необходимый набор задач, позволяющих спроектировать логическую модель базы данных, и могут рассматриваться как один из возможных способов организации работ в этой области.