9.3. Модель данных odmg и язык oql

Модель данных ODMG и язык OQL сформированы по идеям первого манифеста БД и деятельности консорциума ODMG. Модель данных ODMG соответствует ООБД (языкам программирования, в которые добавлена перманентность объектов).

Составные части модели данных ODMG:

• Объектная модель ODMG (на нее опирается язык ограничений OCL, входящих в UML). Для БД, схем и подсхем обеспечивается набор встроенных объектных типов. Модель включает ряд встроенных структурных типов, позволяющих применять традиционные методы моделирования БД. Модель одновременно включает понятия объектов и литералов. В модели связи между объектами отличаются от атрибутов объектов (аналогично тому, как это делается в ER -модели).

• Язык определения объектов ODL, он используется также в технологиях ActiveX и CORBA.

• Язык объектных запросов OQL.

• Язык манипулирования объектами OML (интеграция с языками программирования за счет позднего связывания).

В модели ODMG , подобно ER -модели, различаются два вида свойств – атрибуты и связи, хотя и несколько другим образом. Атрибутами называются свойства объекта, значение которых можно получить по OID объекта, но не наоборот. Значениями атрибутов могут быть и литералы, и объекты, но только тогда, когда не требуется обратная ссылка. Связи – это инверсные свойства. В этом случае значением свойства может быть только объект, поскольку литеральные значения не обладают свойствами.

Объектный тип состоит из интерфейса и одной или нескольких реализаций. Интерфейс описывает внешний вид типа: какими свойствами он обладает, какие в нем доступны операции и каковы параметры у этих операций. В реализации определяются структуры данных, реализующие свойства, и программный код, реализующий операции. Интерфейс составляет общедоступную (public) часть типа, а в реализации при необходимости могут вводиться дополнительные частные (private) свойства и операции. Все объектные типы (системные или определяемые пользователем) образуют решетку (lattice) типов, в корне которой находится предопределенный объектный тип Object .

Интерфейс объектного типа состоит их следующих компонентов:

• имя;

• набор супертипов;

• имя поддерживаемого системой экстента - таблицы, хранящей экземпляры класса;

• один или более ключей для ассоциативного доступа;

• набор атрибутов, каждый из которых может быть объектом или литеральным значением;

• набор связей, каждая из которых указывает на некоторый другой объект;

• набор операций.

Язык OQL обеспечивает исключительно мощные возможности для определения литеральных типов. Можно определить четыре разновидности типов коллекций. Типы категории set – это обычные типы множеств. Типы категории bag – эти типы мультимножеств (в значениях которых допускается наличие элементов-дубликатов). Значениями типов категории list являются упорядоченные списки значений (среди них допускаются дубликаты). Значениями типы dictionary являются множества пар <ключ, значение> , причем все ключи в этих парах должны быть различными. Определения типов имеют рекурсивную природу. Например, можно определить тип множества структур, элементами которых будут являться списки мультимножеств и т.д.

Объектная модель ODMG не поддерживает полноценного множественного наследования. В ней возможно наследование от одного класса и нескольких интерфейсов – классов, в которых нет свойств, а есть одни методы. Механизм наследования от интерфейсов называется в ODMG наследованием IS - A, а механизм наследования от классов – extends. Пример наследования приведен на Рис. 31.

Рис. 31. Пример иерархии объектных типов и их экстентов

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

В модели ODMG поддерживаются только бинарные связи, т.е. связи между двумя типами. Связи могут быть разновидностей “один-к-одному”, “один-ко-многим” и “многие-ко-многим”.

Рассмотрим примеры кода на языке OQL (Лист. 61 - Лист. 69). На Лист. 61 приведены примеры двух классов: отдел и сотрудник, связанных связями «один ко многим», и «один к одному» соответствующие Рис. 30. Связь реализована в виде инверсных свойств в обоих классах с помощью ключевых свойств relationship и inverse, множественность обозначается с помощью set. DEPARTMENTS и EMPLOYEES являются именами экстентов классов, приведенных на Лист. 61.

Лист. 61. Связи между классами

class DEPT {

     ...      relationship set <EMP> consists_of           inverse EMP :: works

relationship EMP managed_by inverse EMP :: manager_of      ... }

class EMP {

     ...      relationship DEPT works           inverse DEPT :: consists_of

relationship DEPT manager_of inverse DEPT :: managed_by      ... }

Селекция в OQL такая же, как и в SQL. Пример: найти даты рождения служащих, зарплата которых превышает 20000 руб – приведен на Лист. 62.

Лист. 62. Селекция в OQL

SELECT DISTINCT E.EMP_BDATE    FROM EMPLOYEES E    WHERE E.EMP_SAL > 20000.00

Результат селекции может быть помещен в структуру (см. Лист. 63).

Лист. 63. Помещение результата запроса в структуру

SELECT DISTINCT STRUCT (name: E.EMP_NAME, bdate: E.EMP_BDATE)    FROM EMPLOYEES E   WHERE E.EMP_SAL > 20000.00

Пример на Лист. 64: получить номера менеджеров отделов и тех сотрудников их отделов, зарплата которых превышает 20000 руб – более сложный. В нем создается структура с вложенной структурой (DHS - сотрудники), причем во вложенном запросе выборка идет из таблицы D.CONSISTS_OF AS E, которая формируется путем перехода по связи CONSISTS_OF из внешней таблицы DEPARTMENTS D.

Лист. 64. Выборка из таблицы, полученной переходом по связи

SELECT DISTINCT STRUCT ( mng: D.DEPT_MNG,                         DHS: ( SELECT E   FROM D.CONSISTS_OF AS E WHERE E.EMP_SAL > 20000.00 ) ) FROM DEPARTMENTS D

Результаты запросов можно помещать не только в структуры, но и в объекты. На Лист. 65. Создаются два объекта – множество (оператор SET)и мультимножество (оператор BAG), последнее от пользовательского класса persinfo. В эти объекты записываются результаты запросов.

Лист. 65. Объекты как результаты запросов

typedef Set <interval> ages;

class persinfo {     attribute string <20> n;     attribute date b; };

typedef Bag <persinfo > info;

ages ( SELECT DISTINCT E.age          FROM EMPLOYEES E          WHERE E.EMP_SAL > 20000.00 );

info ( SELECT persinfo (n: E.EMP_NAME, b: E.EMP_BDATE)      FROM EMPLOYEES E      WHERE E.EMP_SAL > 20000.00 );

Путевые выражения (переходы по связям от одной таблицы к другой) возможны только в направлениях от «одного к одному» и от «многих к одному», но не от «одного ко многим». Например, для получения объекта типа EMP, соответствующего менеджеру отдела main_department достаточно написать выражение main_department.managed_by. Если же требуется получить имя менеджера отдела main_department, то можно воспользоваться путевым выражением main_department.managed_by.EMP_NAME. Если нам нужно получить имена всех сотрудников отдела main_department, то выражение main_department.consists_of.EMP_NAME не подходит, так как в этом случае идет переход в направлении от «одного ко многим». Правильный запрос приведен на Лист. 66

Лист. 66. Путевое выражение в OQL

SELECT E.EMP_NAME      FROM main_department.consists_of AS E

Когда соединяются две таблицы, причем одна из них формируется с помощью первой и путевого выражения, то для групповой операции над записями второй таблицы не требуется GROUP BY. Пример: получить номера отделов и имена сотрудников отделов, с размером зарплаты, большим 10000 руб., работающих в отделах с числом сотрудников, большим 40 человек, и со средним размером зарплаты, большим 20000 руб – приведен на Лист. 67. Особенность данного запроса также в том, что в нем с помощью AND соединяются два условия над одним и тем же полем E.EMP_SAL, причем в одном условии оно с агрегирующей функцией, а в другом – нет.

Лист. 67. Особенности группировок и условий в OQL

SELECT STRUCT (DEPT_NO : D.DEPT_NO, EMP_NAME : E.EMP_NAME )

     FROM DEPARTMENTS D,

          D.CONSISTS_OF E      WHERE D.DEPT_EMP_NO > 40 AND            AVG (E.EMP_SAL) > 20000.00 AND

           E.EMP_SAL > 10000.00

В модели ODMG допускаются методы, вырабатывающие результат в виде сложных объектов или коллекций литеральных значений или объектов. Например, пусть, что в классе EMP определена операция HIGHER_PAID, которая для данного объекта-служащего производит множество объектов-служащих того же отдела с большим размером зарплаты. Тогда возможен следующий запрос: найти названия проектов, в которых участвуют коллеги сотрудника с номером 632, получающие зарплату больше этого сотрудника (Лист. 68).

Лист. 68. Вызов метода в путевом выражении

SELECT DISTINCT E.HIGHER_PAID.participate_in.PRO_NAME

     FROM EMPLOYEES AS E      WHERE E.EMP_NO = 632

Объектная модель ODMG поддерживает полиморфизм. Так, возможен вызов свойств и методов, которые определены в подклассах у объекта, принадлежащего суперклассу. Например, пусть у нас будет подкласс программисты у класса служащие. Нужно выбрать любимый язык программирования у сотрудника с номером 632 (см. Лист. 69).

Лист. 69. Полиморфизм в OQL

SELECT DISTINCT ((PROGRAMMERS)E).favorite_language

     FROM EMPLOYEES AS E      WHERE E.EMP_NO = 632

Д/З . Представьте предметную область из Д/З в виде ООБД (классы, экстенты). Приведите пример объекта как результата запроса на OQL, в котором должны быть выборки, путевые выражения в select и from, вызов методов, возвращающих коллекции объектов, селекцию с использованием агрегирующей операции и без.

Вопросы для самопроверки:

1. В чем отличия трех манифестов БД?

2. Где возможны путевые выражения вида: имя1.имя2.имя3 – в традиционном SQL, ОРБД, OQL?

3. В какой из моделей данных связи реализуются как инверсные свойства?

4. Можно ли, обращаясь к одной таблице, получить также строки из другой таблицы без указания путевого выражения или прописывания соединения в запросе?

5. Можно ли в OQL в where использовать агрегирующие функции? А в SQL?