Что такое проектирование баз данных

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

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

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

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

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

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

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

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

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

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

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

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

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

• нормализация сущностей предметной области:
  • получить список атрибутов сущности;
  • определить функциональные зависимости (ФЗ) в сущности;
  • определить детерминанты сущности;
  • определить возможные ключи отношения, в частности, рассмотрев уникальный идентификатор сущности.
  • выполнить нормализацию сущности (преобразовать сущность в отношение);
  • для полученного отношения назначить первичные ключи;
  • сформировать список кандидатов на внешние ключи, если необходимо;
  • сформировать бизнес-правила поддержки целостности сущности, если необходимо;
• нормализация отношений логической модели базы данных:
• определить степень связи сущностей;
• определить класс принадлежности сущности к связи;
  • нормализовать отношение (разрешить связи);
  • назначить первичные ключи связывающих отношений, исходя из уникального идентификатора связи и процедуры миграции ключей при нормализации;
  • определить атрибуты связывающих отношений, если необходимо;
  • сформировать бизнес-правила поддержки целостности связей;
• проверка правильности логической модели реляционной базы данных:
  • проверка отношений на соответствие нормальной форме Бойса-Кодда;
  • проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;
  • предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
  • проверка на отсутствие незамкнутых связей;
  • проверка на отсутствие одиночных отношений;
• формулировка части исходных данных для решения задачи управления ссылочной целостностью;
• документирование логической модели реляционной базы данных;
• принятие решения о реализуемости построенной логической модели реляционной базы данных;
• принятие решения о разработке физической модели реляционной базы данных.

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

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

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

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

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

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