На этом шаге рассмотрим моделирование логической схемы базы данных в UML.
Многие системы, которые вам предстоит моделировать, будут иметь в своем составе сохраняемые объекты. Это значит, что они могут быть помещены в базу данных для последующего извлечения. Чаще всего вы будете использовать для хранения реляционные и объектно-ориентированные базы данных либо гибридные объектно-реляционные базы. UML хорошо подходит для моделирования как логических, так и физических схем баз данных.
Диаграммы классов UML представляют собой надмножество диаграмм "сущность-связь" (entity-relationship, E-R) – общего инструмента моделирования, используемого в логическом проектировании баз данных. В то время как классические E-R диаграммы сосредоточены только на данных, диаграммы классов идут на шаг вперед, позволяя также моделировать поведение. В физической базе данных эти логические операции обычно представлены в виде триггеров и хранимых процедур.
Чтобы смоделировать схему, необходимо:
- Идентифицировать те классы в модели, состояние которых не должно быть зависимым от времени жизни работающего приложения.
- Создать диаграмму классов, содержащую классы, выявленные на первом этапе. Вы можете определить ваш собственный набор стереотипов и помеченных значений, чтобы представить специфичные для базы данных детали.
- Раскрыть структурные подробности этих классов. В основном это означает необходимость подробно специфицировать их атрибуты, а также ассоциации с указанием множественности, которые связывают данные классы.
- Выявить общие образцы, которые усложняют физическое проектирование базы данных, например циклические ассоциации и ассоциации "один-к-одному". При необходимости создать промежуточные абстракции для упрощения логической структуры.
- Рассмотреть поведение классов, отмеченных на первом этапе, раскрыв операции, существенные для доступа к данным и обеспечения их целостности. Вообще, чтобы четче разграничить различные аспекты системы, следует инкапсулировать бизнес-правила, описывающие манипуляции наборами этих объектов, в слое, находящемся над данными устойчивыми классами.
- Там, где возможно, использовать инструментальные средства, которые помогут трансформировать логический дизайн в физический.
На рис. 1 показан набор классов, описывающих информационную систему учебного заведения. Этот рисунок развивает диаграмму классов, которую мы рассматривали ранее (см. рис. 3 шаг 53), и показывает детали классов, существенных для конструирования физической схемы базы данных. Начиная с нижнего левого угла диаграммы вы найдете классы Студент (Student), Курс (Course) и Преподаватель (Instructor). Существует ассоциация между Студент и Курс, указывающая, что студенты посещают курсы. Более того, каждый студент может выбирать неограниченное число курсов; каждый курс может посещать множество студентов.
Рис.1. Моделирование схемы базы данных
Эта диаграмма раскрывает атрибуты всех шести классов. Отметим, что все атрибуты – примитивных типов. Когда вы моделируете схему базы, обычно связи с непримитивными типами моделируются в виде явных ассоциаций, а не атрибутов.
Два класса – Учебное заведение (School) и Факультет (Department) – включают несколько операций, предназначенных для манипулирования их частями. Эти операции важны для поддержания целостности данных: например, добавление и удаление факультетов может повлечь за собой некоторые недоразумения. Есть много других операций, которые стоит рассмотреть для этих и других классов (скажем, запрос определенной информации перед записью студента на курс). Такие функции можно трактовать скорее как бизнес-правила, а не операции, призванные обеспечивать целостность данных, поэтому их лучше поместить на более высокий уровень абстракции.
На следующем шаге рассмотрим прямое и обратное проектирование.
