Физическая база данных

Логическая схема базы данных (см. главу 8) описывает словарь хранимых дан­ных системы, а также семантику связей между ними. Физически все это хранится в базе данных - реляционной, объектно-ориентированной или гибридной объект­но-реляционной. UML вполне пригоден для моделирования физических баз дан­ных, равно как и их логических схем. (Обсуждение проектирования физических баз данных выходит за рамки книги; здесь эта тема затрагивается только для того, чтобы продемонстрировать, как при помощи UML можно моделировать базы дан­ных и таблицы.)

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

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

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

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

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

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

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

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

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

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

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

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

На рис. 29.4 показано несколько таблиц базы данных, взятых из вузовской ин­формационной системы. Вы видите одну базу (school. db, изображенную в виде компонента со стереотипом database), которая состоит из пяти таблиц: course, department, instructor, school и student (все они изображены в виде ком­понентов со стереотипом interface - одним из стандартных элементов UML, см. «Приложение В»). В соответствующей логической схеме не было наследования, поэтому отображение на физическую базу данных не вызвало затруднений.

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

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