Объектные модели данных

10.1.2 UML как обобщённая объектная модель

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

Идею создания объектной модели данных можно упрощённо представить, как добавление персистентности и механики транзакций в объектный язык программирования. Объектные СУБД позволяют работать с очень сложно организованными данными, но в них до сих пор отсутствуют общепризнанные языки запросов.

В объектно-реляционных СУБД за основу берётся реляционная модель, которую расширяют системой объектных типов данных, конструируемых пользователем. Язык запросов представляет собой расширение SQL.

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

Возможностями, которые даёт использование процедурных компонент классов, мы будем заниматься в следующих разделах (10.2 и далее).

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

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

Рассмотрим язык UML (Unified Modeling Language) обладающий более широкими возможностями. Отметим, что термин "унифицированный" не означает претензий на универсальность. Просто UML был создан путем объединения как минимум трех языков концептуального моделирования.

Для построения реляционных, объектных и объектно-реляционных баз данных из определённых в UML-2 тринадцати видов диаграмм нам достаточно диаграмм классов. Это структурные диаграммы, определяющие наборы классов, их атрибуты, операторы и связи между ними.

Определение. Класс —это именованное описание совокупности объектов, имеющих одинаковые атрибуты, операции, связи и семантику. У класса имеется уникальное имя, изображаемое текстовой строкой, которую будем составлять из соединённых без разрыва имен существительных и прилагательных, начинающихся каждое с заглавной буквы.

Возможно четыре варианта обозначения класса, приведенные на рисунке 10.1.

Рис. 10.1. Изображения класса

В таблице 10.1 приведен пример класса.

Определение. Атрибут —это именованное свойство класса, описывающее множество значений этого свойства. Класс, в отличие от реляционной таблицы, может не иметь ни одного атрибута. Имена атрибутов рекомендуется составлять из существительных и прилагательных, записываемых без пробелов и соединителей. Первое слово в имени атрибута начинается с прописной буквы, а все следующие слова — с заглавной буквы.

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

В частности, с точки зрения объектно-реляционной модели рассматриваемой ниже (в разделе 10.3), реляционная таблица рассматривается как класс без операций. Вызов операции может обеспечить доступ к скрытым атрибутам (вспомните методы get() и set()) и изменять его состояние.

Вспомним, что активным называют объект способный создать управляющее воздействие. Четвёртая секция (рисунок 10.1), используемая в активных классах, представляет сигналы, управляющие поведением класса. В частности, сигналы — это исключительные ситуации.

Определение. Диаграмма классов — это набор классов и cвязей между ними.

Определение. Пакет. Все элементы моделей UML, в том числе классы, объединяются в пакеты. Каждый элемент принадлежит одному пакету, но пакет может быть вложен в другие пакеты.

Вернёмся к описанию классов.

Для записи атрибутов используется следующий синтаксис:

квантор_видимости имя_атрибута [кратность_атрибута]: тип_атрибута=нач_значение {строка_свойство}.

Области видимости атрибутов обозначаются знаками:

• + общедоступный (public),
• # защищенный (protected),
• - закрытый (private).

Область видимости protected может иметь разный смысл в различных языках. Например, защищённый атрибут может быть виден только внутри пакета.

Кратность атрибута характеризует наличие ни одного (0) или нескольких атрибутов данного типа. Например:

[0..1] — иногда есть, иногда нет

[5, 7..9]— любое из перечисленных чисел 5,7,8,9.

* — любая кратность

Примеры записей атрибутов: +получитьАдрес : Address #Цена : {$200}

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

квантор_видимости имя_операции(список_параметров): тип_возвращаемого_значения {строка_свойство}

Квантор видимости принимает те же значения + , — и #.

Строка-свойство в этом случае обозначает особые свойства операции. Например, {query} означает, что операция не может изменять данные, то есть является запросом.

Список параметров:

вид_параметра имя_параметра тип_параметра = значение_по_умолчанию
вид_параметра: {in, out, inout} — входной, выходной, входной и выходной

Для атрибутов и операций можно задавать область действия. Для свойств существует два варианта:

• instance — каждый экземпляр имеет своё значение свойства;
• static — для всех экземпляров одно значение. В UML различают следующие виды связей:
• зависимости (dependency relationship);
• ассоциации (association relationship);
• обобщения (generation relationship), это взгляд на наследование снизу вверх;
• реализации (realization relationship);
• агрегации (aggregation relationship);
• композиции (composition relationship).

Кратко рассмотрим связи за исключением реализации.

Определение. Связи-зависимости — это связи, заключающиеся в том, что первый класс использует объекты другого класса. При изменении второго класса, скорее всего, потребуются изменения в первом классе.

При проектировании реляционных баз связи-зависимости реализовать невозможно.

Зависимости изображаются штриховой линией со стрелкой, направленной к классу-источнику зависимости (рисунок 10.2).

Рис. 10.2. Пример связи-зависимости

Определение. Связи-ассоциации классифицируются по числу соединяемых классов. Обозначаются они сплошными линиями. Выделяют бинарные связи (соединяют два класса), тернарные (три класса) и N-арные. Для бинарных связей может быть указан порядок соединяемых классов. Так, в примере на рисунке 10.3 связь читается так: "Мама моет раму".

Рис. 10.3. Пример связи-ассоциации

Концы связи-ассоциации можно помечать именами ролей, для которых могут быть указаны кратности связи. Назначения ролей такие же, как в ER-диаграммах (см. раздел 2.2.6). Кратности роли указывают, сколько объектов с этой ролью могут участвовать в ассоциации. Так, кратность 1 указывает на обязательность связи, кратность 0..1 означает её необязательность. Задание диапазона 1..* говорит о том, что все объекты должны участвовать в каком-нибудь экземпляре ассоциации и что число объектов, участвующих в одном экземпляре ассоциации не ограничено.

В примере на рисунке 10.4 в показано, что работник обязательно работает равно в одном отделе, а отдел может существовать вообще без работников, но может иметь до 15 человек.

Рис. 10.4. Пример связи-ассоциации с кратностью

Как вы уже поняли, ассоциации реализуются в реляционной модели.

Определение. Связью-обобщением называется связь между более общим классом, называемым родителем или предком, и более специализированным классом, называемым потомком или подклассом.

Объекты подкласса можно считать объектами класса-родителя. Обозначаются обобщения сплошной линией с большой незакрашенной стрелкой (рисунок 10.5). Если предок не один, говорят о множественном наследовании.

Рис. 10.5. Пример связи-обобщения

Множественное наследование порождает проблему именования атрибутов и операций в подклассе. При совпадении имён атрибутов и операций у родительских классов, необходимо уточнить их семантику и либо переименовать одно из имён, либо запретить наследование от одного из родительских классов, либо унаследовать всё, а затем в потомке произвести переименование.

В Cache допускается множественное наследование. При совпадении имён элементов классов-предков действует определение элемента последнего класса в списке предков. Исключение составляют ключевые слова класса, наследуемые от первого предка в списке.

Поскольку обобщение в базах реляционного типа невозможно реализовать адекватным образом, используют представления родительского и дочерних классов одной, двумя или тремя таблицами (см. раздел 4.11).

Определение. Связи-агрегации позволяют объединить несколько классов одного концептуального уровня в класс более высокого концептуального уровня. Тем самым реализуется отношение "часть-целое". Графически связь агрегации изображается сплошной линией как ассоциация, но на стороне класса "агрегат" помещается незакрашенный ромб (рисунок 10.6).

Рис. 10.6. Пример связи-агрегации

В нашем примере предполагается, что столы и стулья могут существовать независимо от аудитории. Свои функции они могут исполнять, например, в коридоре.

Агрегатов в реляционной модели нет.

Определение. Связи-композиции — это агрегации, у которых связь компонентов и агрегата настолько сильна, что уничтожение агрегата приводит к уничтожению его составных частей (рисунок 10.7)

Рис. 10.7. Пример связи-композиции

В самом деле, трудно представить самостоятельное существование пола и потолка. Сложнее обосновать применение композиции для стены. Например, стену можно понимать как отдельное фортификационное сооружение. Но если, считать, что речь идёт о стенах, у которых, по крайней мере, одна сторона не приспособлена для существования в открытом пространстве, то связь стена — комната становится более похожей на композицию.

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

В объектных и объектно-реляционных моделях данных использование инструментария UML даёт значительно больший эффект.