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

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

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

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

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

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

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

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

Основу функционально-объектного подхода к разработке базы данных составляет осознание потребностей пользователей системы в выполнении отдельных функциональных задач, которые, как из кирпичиков, составляют комплексную функциональную среду деятельности пользователя. Этот подход, выделяя отдельные функции предметной области и разделяя их на основные и вспомогательные, дает возможность разработчику подходить к процессу проектирования, рассматривая функции в виде самостоятельных блоков (черный ящик) и объединяя их в «строение», именуемое «информационная система». В результате использования данного подхода процесс проектирования информационной системы представляется последовательностью, показанной на рис. 2.36.

Рис. 2.36. Процесс разработки информационной системы.

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

Если рассматривать этот процесс в рамках использования инструментальных средств разработки баз данных (например, IBM InfoSphere Data Architect), то создается одна область моделирования логической модели базы данных и в рамках этой модели для каждой функции создастся отдельная диаграмма. В результате получается, что все созданные в рамках одной диаграммы сущности будут доступны для других диаграмм этой же логической модели базы данных. Аналогично данный процесс представляется в других средствах моделирования баз данных с возможным изменением названий отдельных элементов, например: в СА ERWin Data Modeler для построения диаграмм по функциям используются элементы, называемые «рабочая область» .

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

Рис. 2.37. Процесс моделирования базы данных при функционально-объектном подходе.

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

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

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

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