Проектирование баз данных. Проектирование БД зависит от типа используемой для хране­ния данных СУБД - объектной или реляционной

Проектирование БД зависит от типа используемой для хране­ния данных СУБД - объектной или реляционной. Для объектных БД никакого проектирования не требуется, поскольку классы-сущности непосредственно отображаются в БД. Для реляцион­ных БД классы-сущности объектной модели должны быть отоб­ражены в таблицы реляционной БД. Совокупность таблиц и свя­зей между ними может быть представлена, в виде диаграммы классов, которая по существу является ER-диаграммой. Набор правил, применяемых при отображении классов в таблицы БД, фактически совпадает с правилами преобразования сущностей и связей, описанными в подразд. 4.1. В технологии RUP, в частнос­ти, для такого отображения используется специальный инстру­мент — Data Modeler. Он выполняет преобразование классов-сущностей в классы-таблицы с последующей генерацией описа­ния БД на SQL.

Для описания схемы БД применяется следующий набор элементов языка UML со своими стереотипами (профиль UML):

· таблица представляется в виде класса со стереотипом «Table»;

· представление изображается в виде класса со стереотипом «View»;

· столбец таблицы представляется в виде атрибута класса с соответствующим типом данных;

· обычная ассоциация и агрегация представляются в виде ас­социации со стереотипом «Non-Identifying» (в терминоло­гии IDEF1X — неидентифицирующей связи);

· композиция представляется в виде ассоциации со стереоти­пом «Identifying» (в терминологии IDEF1X — идентифици­рующей связи);

· схема БД представляется в виде пакета со стереотипом «Schema», содержащего классы-таблицы;

· контейнер хранимых процедур представляется в виде класса со стереотипом «SP Container»;

· ограничения целостности, индексы и триггеры представля­ются в виде операций классов-таблиц со стереотипами «РК» (Primary key), «FK» (Foreign key), «Unique», «Check», «Index» и «Trigger»;

· физическая база данных представляется в виде компонента со стереотипом «Database».

Рис. 4.36. Пример неидентифицирующих связей

Примеры преобразования, выполненного для классов вари­анта использования «Зарегистрироваться на курсы» средствами Data Modeler, приведены на рис. 4.36 - 4.38.

На рис. 4.36 ассоциации-классы, представляющие свойства связей между классами Schedule и CourseOffering (см. рис. 4.16), преобразованы в таблицы в соответствии с правилом преобразо­вания бинарных связей типа «многие-ко-многим».

Идентифицирующая связь между таблицами T_Student и T_Schedule на рис. 4.37 соответствует связи композиции между классами Student и Schedule на рис. 4.34.

На рис. 4.38 показано преобразование связи обобщения, изображенной на рис. 4.35. Здесь используется отдельная табли­ца для каждого подтипа (в соответствии с правилом из подразд. 4.1). Достоинства и недостатки различных способов преобразо­вания обсуждались в подразд. 4.1). Преимуществом способа, применяемого в данном случае, является простота алгоритма ав­томатического преобразования, выполняемого средствами Data Modeler.

Рис. 4.37. Пример идентифицирующей связи

Рис. 4.38. Пример преобразования обобщения

! Следует запомнить

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