На этом этапе осуществляется отображение элементов полученных ранее моделей классов в элементы моделей базы данных и приложений:
классы отображаются в таблицы;
атрибуты - в столбцы;
типы - в типы данных используемой СУБД;
ассоциации - в связи между таблицами (ассоциации «многие-ко-многим» преобразуются в ассоциации «один-ко-многим» посредством создания дополнительных таблиц связей);
приложения - в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами.
Поскольку модели базы данных и приложений строятся на основе единой логической модели, автоматически обеспечивается связность этих проектов ( рис. 12.12 ).
Рис. 12.12. Связь между проектами базы данных и приложений
В модель базы данных отображаются только перманентные классы, из которых удаляются атрибуты, не отображаемые в столбцах (например, атрибут типа «Общий объем продаж», который получается суммированием содержимого множества полей базы данных). Некоторые атрибуты (например, АДРЕС) могут отображаться в множество столбцов (СТРАНА, ГОРОД, УЛИЦА, ДОМ, ПОЧТОВЫЙ ИНДЕКС).
Для каждого простого класса в модели базы данных формируется отдельная таблица, включающая столбцы, соответствующие атрибутам класса.
Отображение классов подтипов в таблицы осуществляется одним из стандартных способов:
одна таблица на класс;
одна таблица на суперкласс;
одна таблица на иерархию.
В первом случае для каждого из классов создается отдельная таблица, между которыми затем устанавливаются необходимые связи. Во втором случае создается таблица для суперкласса, а затем в каждую таблицу подклассов включаются столбцы для каждого из атрибутов суперкласса. В третьем - создается единая таблица, содержащая атрибуты как суперкласса, так и всех подклассов ( рис. 12.13 ). При этом для выделения исходных таблиц подклассов в результирующую таблицу добавляется один или более дополнительных столбцов (на рисунке показан курсивом).
Рис. 12.13. Преобразование иерархии в таблицу
Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включает следующие основные компоненты диаграмм:
таблица - набор записей базы данных по определенному объекту;
столбец - элемент таблицы, содержащий значения одного из атрибутов таблицы;
первичный ключ (РК) - атрибут, однозначно идентифицирующий строку таблицы;
внешний ключ (FK) - один или группа атрибутов одной таблицы, которые могут использоваться как первичный ключ другой таблицы;
обязательная связь - связь между двумя таблицами, при которой дочерняя таблица существует только вместе с родительской;
необязательная связь - связь между таблицами, при которой каждая из таблиц может существовать независимо от другой;
представление - виртуальная таблица, которая обладает всеми свойствами обычной таблицы, но не хранится постоянно в базе данных;
хранимая процедура - функция обработки данных, выполняемая на сервере;
домен - множество допустимых значений для столбца таблицы.
На рис. 12.14 представлен фрагмент модели базы данных - две таблицы, соответствующие классам «пациент» ( рис. 12.3 , рис. 12.6 ) и «минимальный набор данных» ( рис. 12.8 ). Связь между ними обязательная, поскольку «минимальный набор данных» не может существовать без «пациента».
Рис. 12.14. Фрагмент модели базы данных
На диаграммах указываются дополнительные характеристики таблиц и столбцов:
ограничения - определяют допустимые значения данных в столбце или операции над данными (ключ (PK,FK) - ограничение, определяющее тип ключа и его столбец; проверка (Check) - ограничение, определяющее правило контроля данных; уникальность (Unique) - ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);
триггер - программа, выполняющая при определенных условиях предписанные действия с базой данных;
тип данных и пр.
Результатом этапа является детальное описание проекта базы данных и приложений системы.