Моделирование физической базы данных

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

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

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

Как правило, применяется одна из трех следующих стратегий или их комбинация:

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

· Подъем. Цепочка наследования свертывается, так чтобы все реализации любого класса в иерархии имели одно и то же состояние. Недостаток этого подхода состоит в том, что во многих экземплярах хранится избыточная информация;

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

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

· простые операции создания, выборки, обновления и удаления реализуются стандартными средствами SQL или ODBC;

· более сложное поведение (например, бизнес-правила) отображаются на триггеры или хранимые процедуры.

С учетом указанных выше соображений моделирование физической базы данных осуществляется следующим образом:

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

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

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

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

На рис. 2.31 показано несколько таблиц базы данных, взятых из вузовской информационной системы. Вы видите одну базу (school.db, изображенную в виде артефакта со стереотипом database), которая состоит из пяти таблиц: course, department, instructor, school и student

Рис.2.31 Моделирование базы данных

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

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