Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Uml Book (Rus).doc
Скачиваний:
15
Добавлен:
11.08.2019
Размер:
58.74 Mб
Скачать

Логическая схема базы данных

Многие моделируемые системы содержат устойчивые объекты, то есть такие, которые можно сохранять в базе данных и впоследствии извлекать при необходи­мости (см. главу 23). Для этого чаще всего используют реляционные, объектно-ориентированные или гибридные объектно-реляционные базы данных. UML по­зволяет моделировать логические схемы баз данных, равно как и сами физические базы (см. главу 29).

Диаграммы классов UML включают в себя, как частный случай, диаграммы «сущность-связь» (E-R диаграммы), которые часто используются для логичес­кого проектирования баз данных. Но если в классических E-R диаграммах вни­мание сосредоточено только на данных, диаграммы классов - это шаг вперед:

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

Моделирование схемы производится следующим образом:

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

2. Создайте содержащую эти классы диаграмму классов и характеризуйте их как устойчивые с помощью стандартного помеченного значения persistent (устой­чивый). Для работы со специфическими деталями базы данных вы можете определить и свои собственные помеченные значения.

3. Раскройте структурные особенности классов. В общем случае это означает, что надо детально специфицировать их атрибуты и обратить особое внима­ние на ассоциации и их кратности.

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

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

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

Примечание Рассмотрение логического проектирования базы данных выходит за рамки данной книги, цель которой состоит только в том, чтобы по­казать, как моделировать схемы с помощью языка UML. На прак­тике все сводится к применению стереотипов (см. главу 6), настро­енных на конкретный тип используемой базы данных (реляционной или объектно-ориентированной).

На рис. 8.3 показана совокупность классов, взятых из информационной системы вуза. Этот рисунок является расширением приведенной ранее диаграммы классов

и содержит достаточное количество деталей для конструирования физической базы данных. В левой нижней части диаграммы расположены классы Студент, Курс и Преподаватель. Между классами Студент и Курс есть ассоциация, по­казывающая, что студенты могут посещать курсы. Более того, каждый студент может посещать любое количество курсов и на каждый курс может записаться любое число студентов.

Все шесть классов на диаграмме помечены как устойчивые (persistent), то есть их экземпляры должны содержаться в базе данных или каком-то ином хранили­ще. Приведены также атрибуты всех шести классов. Обратите внимание, что все атрибуты являются примитивными типами (см. главу 4). Моделируя схему, отно­шения с непримитивными типами лучше всего представлять с помощью явного агрегирования (см. главы 5 и 10), а не с помощью атрибутов.

Два класса (Вуз и Факультет) содержат несколько операций, позволяющих манипулировать их частями. Эти операции включены из-за их важности для под­держания целостности данных (например, добавление или удаление Факульте­та затрагивает целый ряд других объектов).

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]