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

Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Обычно проектировщики не создают бизнес-модель процесса проектирования базы данных. А напрасно! Бизнес-модель процесса проектирования позволяет:

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

Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.

Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

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

Могут быть представлены и другие документы.

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

На выходе процесса проектирования базы данных формируются следующие результаты:

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

По требованию может быть разработана и другая документация.

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

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

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

Такими задачами (этапами) являются:

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-07