Модель данных 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

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

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

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

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

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

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

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