Л.А. Калиниченко

Институт проблем информатики РАН, Вавилова 30/6, Москва, В-334, 117900, leonidk@ipian23.ipian.msk.su

Архитектура СУОБД, согласно ODMG-93
Объектная модель ODMG-93, язык определения объектов
Язык объектных запросов ODMG
Связывание с языками программирования (С++)
Роль СУОБД в архитектуре OMG
Заключение
Литература
Благодарность

Исследования в области объектных баз данных, исключительно активно развивавшиеся в прошлом десятилетии, привели в конце 80-х к образованию промышленных компаний и рынка систем управления объектными базами данных (СУОБД). Эти продукты довольно быстро приобрели черты зрелых СУБД, зарекомендовавших себя в ряде важных областей - таких как: САПР, промышленность программного обеспечения, географические информационные системы, финансовая сфера, медицинские применения, телекоммуникации, мультимедиа, управляющие информационные системы.

Промышленность объектных баз данных остро нуждается в стандарте: фирмам-производителям СУОБД это давно и хорошо известно. Летом 1991 г. в США была образована Object Database Management Group (ODMG) - Группа Управления Объектными Базами Данных - как консорциум фирм-производителей СУОБД и других заинтересованных участников для разработки стандарта СУОБД. В конце 1993 г. группа завершила опубликованием Стандарт объектных баз данных ODMG-93 [11].

В состав ODMG во время разработки стандарта ODMG-93 входили: Object Design, Objectivity, Ontos, O2 Technology, SunSoft, Versant. Фирмы-члены ODMG, заявившие в 1993 г. о намерении следовать стандарту ODMG-93 (далее иногда просто ODMG-93), представляли 90% рынка СУОБД. Этот факт позволял считать ODMG-93 де-факто стандартом [15]. Более осторожно можно утверждать, что ODMG-93, несмотря на значительное число неточностей и недостаточно обоснованных решений, вводит начальный уровень достигнутого консенсуса, позволяющего устранить ненужные различия продуктов.

Главной целью ODMG-93 является достижение мобильности прикладных систем относительно различных СУОБД. С этой целью ODMG-93 определяет следующие компоненты систем баз данных: объектную модель, которая должна быть поддержана СУОБД, язык определения объектов (Object Definition Language - ODL), язык объектных запросов (Object Query Language - OQL), языки манипулирования данными, реализуемые погружением ODL в объектно -ориентированные языки программирования. Решения ODMG отражают намерение согласовать архитектуру ODMG-93 с архитектурой, разрабатываемой Object Management Group (OMG) [14,3]. В частности, объектная модель ODMG-93 является расширением объектной модели OMG [12]. Решения ODMG учтены при разработке некоторых компонентов архитектуры промежуточного слоя (middleware) интероперабельных информационных систем [3] - таких как Служба Долговременного Хранения Объектов, Служба Объектных Запросов.

В целом, ODMG-93 следует считать важным (хотя и первым) шагом в процессе разработки стандарта СУОБД. ODMG сотрудничает в его дальнейшем развитии с OMG и рядом групп стандартизации ANSI: X3H2 (SQL), X3J16 (C++), X3J20 (Smalltalk). Планируется издание следующей редакции стандарта, условно обозначаемой ODMG-95.

Решения стандарта ODMG-93 не являются неожиданными. Большинство решений было предсказано Манифестом объектно-ориентированных СУБД (ООСУБД), опубликованным в 1989 г. [1]. Основным постулатом Манифеста служило определение: ООСУБД = СУБД + ООЯП (Объектно-ориентированный язык программирования). Дополнительные черты СУБД и ООЯП в их соединении должны были привести к образованию ООСУБД. Согласно Манифесту, ООСУБД должны поддерживать сложные объекты, идентифицируемость объектов, инкапсуляцию, ведущую к четкому различию между спецификацией и реализацией, понятия типа и класса, включая иерархии типов, расширяемость, вычислительную полноту, поддержку языка запросов.

После опубликования стандарт ODMG-93 подвергся обоснованной критике в ряде публикаций, например [7,8,6,4]. К сожалению, некоторые прогнозы [8] сбылись. В частности, компании-члены ODMG обязались в течение 18 месяцев после опубликования стандарта выпустить совместимые с ним продукты. До сих пор этого не произошло, что и предвидел Вон Ким, считая, что полный язык ODMG слишком сложен, чтобы его можно было реализовать в течение предложенного времени. По-видимому, ближе всех к цели находится фирма Objectivity [9].

В настоящей статье1), продолжающей обсуждение компонентов архитектуры интероперабельных информационных систем [3], дан краткий неформальный обзор основных компонентов стандарта ODMG-93 - объектной модели, языка запросов, связывания с C++.

Архитектура СУОБД, согласно ODMG-93

ODMG-93 определяет СУОБД как СУБД, интегрирующую свойства баз данных и объектно-ориентированных языков программирования. СУОБД обеспечивает представление объектов базы данных как объектов языка программирования по отношению к одному или к ряду языков программирования. СУОБД расширяет язык программирования средствами долговременного хранения объектов, управления конкурентным доступом, восстановления данных, объектных запросов и другими средствами систем баз данных.

Основные компоненты архитектуры

Объектная модель. Объектная модель OMG используется в качестве основы объектной модели ODMG-93. Объектная модель-ядро архитектуры OMG спроектирована в качестве "общего знаменателя" брокеров объектных заявок, объектных систем баз данных, объектных языков программирования и других применений. В согласии с архитектурой OMG, ODMG-93 конструирует профиль СУОБД для модели-ядра OMG, вводя дополнительные компоненты (такие как, например, связи (relationships)).

Язык определения объектов (ODL). Основой языка определения объектов ODL является язык определения интерфейсов IDL архитектуры OMG.

Язык объектных запросов (OQL). Определен декларативный язык запросов для обращения к объектным базам данных и их обновления. В качестве синтаксической основы OQL используется стандарт языка SQL-2, хотя OQL обладает более мощной семантикой. Вопрос о сближении OQL с разрабатываемым стандартом языка SQL-3 остается открытым.

Связывание с языками программирования. Особое внимание уделено наиболее важному в настоящее время языку для связывания с СУОБД - языку C++. Связывание с C++ основано на определении версии ODL на базе синтаксиса C++. Связывание включает механизм вызова OQL, процедуры и операции над базами данных и транзакциями. Связывание с C++ определяет способы написания мобильных программ на C++ для манипулирования долговременно хранимыми объектами, а также общие принципы связывания с языком Smalltalk. В дальнейшем предполагается определение связывания с другими языками программирования. Существенно, что не предполагается фиксировать некоторый универсальный синтаксис языка манипулирования данными: он зависит от языка программирования.

Дополнительные компоненты

В дополнение к стандарту объектных баз данных определены следующие компоненты.

Профиль объектной модели OMG. Определены дополнительные компоненты объектной модели ODMG по отношению к объектной модели OMG.

Связывание с OMG ORB. Определены принципы использования объектов СУОБД в качестве объектов модели OMG и, наоборот, объектов модели OMG в качестве объектов СУОБД. Специальный адаптер позволяет посредством брокера объектных заявок (ORB) направлять вызовы к объектам по их идентификаторам, предоставляемым СУОБД.

Модель структуры компонентов СУОБД

На рис. 1 дано представление структуры типовой СУОБД. Программист использует определения схем баз данных на ODL или их отображение в некоторый язык программирования, например в C++ ODL. Прикладная программа представляется на этом же языке программирования, расширенном средствами манипулирования объектами. Определения схем баз данных и прикладная программа компилируются и обрабатываются редактором связей. В результате образуется исполняемая программа, готовая к взаимодействию с базами данных. Базы данных могут использоваться совместно с другими прикладными программами благодаря управлению транзакциями и блокировкам, поддерживаемым СУОБД.

Picture 1

Рисунок 1.
Структура СУОБД.

Объектная модель ODMG-93, язык определения объектов

Используемая объектная модель ODMG-93 является расширением объектной модели OMG, а язык определения объектов - расширением языка IDL OMG.

Согласно объектной модели ODMG-93, каждый объект имеет определенный, единственный тип. Поведение объектов определяется операциями, заданными для объектов этого типа. Операции определяются своими сигнатурами. Состояние объекта определяется значениями его свойств. Свойства могут быть либо атрибутами объекта либо его связями с другими объектами. Свойства и операции составляют характеристики типа. Тип определяется одним интерфейсом, которому может соответствовать одна или большее число реализаций. Типы в свою очередь являются объектами и могут иметь собственные свойства из следующего жестко ограниченного набора:

  • supertype - типы образуют ациклический граф на основе отношения подтип/супертип. Все операции и свойства супертипа наследуются подтипом. Множественное наследование возможно. Подтип может уточнять свойства и операции супертипа и вводить новые свойства и операции;
  • extent - множество экземпляров данного типа в базе данных (экстент). С экстентом система связывает индекс для эффективного доступа к экземплярам типа. Если тип A является экземпляром типа B то экстент A является подмножеством экстента B.
  • key - в некоторых случаях экземпляры типа можно однозначно идентифицировать значениями заданного набора свойств объекта (атрибутов и/или связей). Такие свойства могут быть объявлены ключевыми для типа.

Допускается спецификация абстрактных типов, которые не могут иметь экземпляров. Их характеристики наследуются подтипами. Ниже дан пример спецификации типа на ODL.

Interface Course{
extent courses;
keys name, number;
attribute string name;
attribute string number;
relationship
 List
 has_sections;
relationship
 Set has_perequisites
 inverse
  Course::is_perequisite_for;
relationship
 Set is
_perequisite_for
 inverse
  Course::has_perequisites;
offer(in Semester);
drop(in Semester)
}

Характеристики системы типов ODMG-93

Иерархия типов ODMG-93 имеет общую условную вершину, именуемую Denotable_Object (Обозначаемый объект). Различаются два основных подкласса типов обозначаемых объектов - изменчивые (mutable) и неизменчивые (immutable)2).

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

Итак, введены иерархии изменчивых и неизменчивых встроенных типов. В каждой иерархии различаются два подкласса типов: атомарные и структурированные. Важным атомарным типом объектов является тип Type - по существу, метатип, экземплярами которого являются любые типы. Атомарными литеральными типами являются традиционные скалярные типы целых, вещественных, символьных и логических литералов. Встроенными структурированными типами являются тип структуры (Structure) и типы коллекций - тип множества (Set), тип мультимножества (Bag), тип списка (List), тип массива (Array). Существенно, что структурированные типы объектов являются изменчивыми, а структурированные литеральные типы - неизменчивыми. Последние синтаксически так и объявляются, например Immutable_Set. Временные типы SQL-2 являются также встроенными литеральными подтипами типа Immutable_Structure.

Типы объектов могут быть объявлены как подтипы других типов объектов, например:

interface
объектов

Associate_Professor: Professor{...}

В подтипах операции супертипов могут перекрываться. Операции над объектами типа могут иметь побочные эффекты. Объектная модель ODMG-93 является строго типизированной. Совместимость типов объектов определяется отношением подтипа, заданным на иерархии типов объектов.

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

Атрибуты объекта имеют своими значениями литералы3).

Значения атрибутов инкапсулированы: доступ к ним реализуется встроенными операциями get_value, set_value. Атрибуты не являются "объектами первого класса": нельзя определить атрибуты атрибутов, связи между атрибутами, дополнительные операции на атрибутах.

Структуры и коллекции

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

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

Тип связи

Типы связей определяются между изменчивыми типами объектов. Поддерживаются бинарные связи вида 1:1, 1:n и n:m. Типу связи 1:n и n:m соответствует единственный экземпляр типа. Вместе с тем экземпляр типа n:m представляется двумя экземплярами типа 1:n, которые, в свою очередь, можно считать множествами экземпляров типа 1:1. Экземпляры типа связей не имеют уникальных идентификаторов. Тип связи 1:n напоминает тип набора модели данных КОДАСИЛ [16]. Семантика типа набора зависит от вида членства в наборе, которое специфицируется как OPTIONAL MANUAL, MANDATORY AUTOMATIC и др. Вид членства в наборе определяет семантику операций создания, удаления, модификации записи-члена (владельца) набора. Их семантика соответствует ссылочным ограничениям целостности, устанавливаемым видом членства в наборе. Смысл типа связи 1:n в модели ODMG-93, по-видимому, соответствует типу набора с видом членства OPTIONAL MANUAL: тип связи , где T1 и Tn - множества экземпляров типов объектов, участвующих в связи 1-n, представляет собой частичную (не тотальную!) функцию . Это означает, что удаление объекта типа T1 из связи или из базы данных не приводит к удалению связанных с ним объектов типа Tn, хотя связи с ними разрываются.

Связи не имеют имени. Вместо этого именуются навигационные пути (traversal paths) для каждого направления навигации, например профессор преподает (teaches) совокупность разделов курсов, инверсное направление определяется тем, что разделы курсов преподаются (is_taught_by) профессорами. Эти имена объявляются в определениях интерфейсов, соответствующих типам, участвующим в связи:

interface Professor { ... 
teaches: Set
 inverse Section::is_taught_by
}

и

interface Section { ... is_taught_by: Professor inverse Professor::teaches
}

Для типа связи 1-n определены следующие операции:

  • create(o1:Denotable_Object, s:Set);
  • delete ();
  • add_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
  • remove_one_to_one (o1:Denotable_Object, o2:Denotable_Object);
  • traverse (from:Denotable_Object) -> s: Set.

Графическое представление схемы на OQL показано на рис. 2. Типы объектов изображены прямоугольниками. Типы связей представлены стрелками. Кардинальности связей 1 соответствует обычная стрелка, кардинальности связей n соответствует двуглавая стрелка. Большие серые стрелки соответствуют отношению подтипа.

Рисунок 2.
Графическое представление схемы на ODL.

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

Первоначальная версия языка объектных запросов (OQL) определена в работе [11] относительно независимо от языка SQL: язык объектных запросов обладает более богатой семантикой. Так, OQL включает манипулирование данными произвольной сложности, вызов методов, полиморфизм типов на основе позднего связывания, введение выражений путей в композиционной структуре объектов, работу с произвольными объектами (независимо от их времени жизни). Впоследствии принято решение принять в OQL синтаксис SQL-92, не уменьшая его (OQL) семантической мощности. Здесь рассматривается именно эта, более поздняя, редакция языка OQL [10].

Итак, синтаксически OQL является расширением языка SQL. В частности, любое предложение select SQL, применимое к таблицам, используется без изменений над коллекциями объектов ODMG, состояние которых представляет строки таблиц. Вместе с тем OQL опирается на объектную модель ODMG-93 и является типизированным языком запросов. Результатом запроса на OQL могут быть одиночные значения (изменчивые или неизменчивые) любых типов, представимых на ODL, либо коллекции таких значений. OQL является функциональным языком в том смысле, что допускается произвольная композиция операторов, если только их операнды имеют требуемые типы. Поскольку результат любого запроса имеет тип, соответствующий ODL, к нему можно снова применить запрос. OQL - самостоятельный язык, который может использоваться динамически. Вместе с тем запросы на OQL могут вызываться из программы на любом языке программирования, для которого определено связывание с ODMG-93. В свою очередь из запросов на OQL могут вызываться программы, написанные на таких языках программирования. Запросы могут реализовать изменения базы данных, если они вызывают операции на объектах, явно или неявно реализующие такие изменения.

Далее на примерах кратко рассматриваются основные решения OQL, характерные для языков объектных запросов [10, 2].

Выражения для путей

В базу данных можно войти, используя имя объекта, или, в более общем случае, как только становится известным некоторый объект (например в результате выполнения программы на C++). После этого можно осуществить "навигацию" в базе данных для достижения требуемых данных. Например, пусть p-объект типа Person, и требуется определить название города, в котором живет супруг(а) этого человека. Для навигации используется точечная нотация, определяющая путь:

p.spouse.address.city.name

Этот запрос начинается с p, определяет супруга этого лица (которого снова представляет объект типа Person), забирается внутрь атрибута-структуры Address для определения объекта типа City, имя которого затем остается определить. Существенно, что компонентами пути могут быть операции объектов с параметрами или без них, если результатом операции является требуемый объект:

Doe.apply_course
("Math", Turing).number

Этот запрос применяет операцию apply_course к объекту Doe типа Student. Операция требует два параметра - строку и объект типа Professor. Операция возвращает объект типа Course, а запрос определяет номер курса.

Выражения путей достаточны для проникновения внутрь сложных объектов и прослеживания связей 1:1. В случае связей 1:n требуется применение фраз select-from-where SQL для определения коллекций объектов, связанных с объектом p. Например, множество имен детей p образуется посредством запроса:

select distinct c.name  
from p.children c

Фраза where может содержать произвольный предикат, служащий для отбора требуемых данных. Запросы, подразумевающие соединение (join) коллекций, формулируются обычно. Например, найти объекты типа Person, имена которых совпадают с названиями цветов:

select p  
from Person.p,
Flowers f  
where p.name = f.name

Полиморфизм

Существенной для объектной ориентации является возможность манипулирования полиморфными коллекциями, что, благодаря позднему связыванию, позволяет выполнять родовые операции над элементами таких коллекций. Пусть множество Persons содержит объекты типа Person, Employee, Student. Запросы к Persons имеют дело с объектами трех типов. Пусть activities - метод, который имеет различные представления в каждом из трех типов объектов. В зависимости от типа текущего объекта вызывается соответствующий метод activities:

select p.activities  
from Persons.p

Можно явно задать тип объектов, которые следует рассматривать в полиморфной коллекции. Например, если известно, что только студенты проводят свое время, изучая определенные курсы, можно извлечь таковых из множества Persons посредством явной типизации запроса:

select (Student)p.grade  
from Persons p  
where"course of study"
in p.activities

Произвольная композиция операторов

Операторы языка OQL допускают произвольную композицию, единственным ограничением для которой является правильная типизация операндов и результатов операторов. К подобным операторам языка относятся: множественные операторы (union, intersect, except), кванторы (for all, exists), операторы sort и group by, операторы аггрегации (count, sum, min, max, avg). В отличие от языка SQL, конструкции OQL являются полностью ортогональными. Там, где синтаксис языка SQL не является чисто функциональным OQL принимает эту трактовку SQL как допустимый синтаксический вариант.

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

first(select street, average_salary: avg(select e.salary from partition)  
from(select (Employee) p from Persons p  
where "has a job"
in p.activities) as e  
group by street: e.address.street  
order by average_salary).street

Оператор group by расщепляет совокупность Employee на подразделы (partitions) в соответствии с заданным критерием (в нашем случае по имени улицы, на которой живет сотрудник). Оператор order by приводит к образованию списка структур типа List, упорядоченного по возрастанию значений средней зарплаты. Наименьшая зарплата соответствует первой структуре в списке.

Связывание с языками программирования (С++)

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

1. Существует единая унифицированная система типов для языка программирования и базы данных. Экземпляры этих типов являются либо временно, либо постоянно хранимыми.

2. Связывание ODL с конкретным языком программирования должно удовлетворять синтаксису и семантике этого языка программирования.

3. Связывание реализуется посредством небольших расширений языка программирования.

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

Связывание ODL с C++ заключается в отображении объектной модели в C++ введением совокупности классов, которые могут иметь как постоянно, так и временно хранимые экземпляры. Такие классы называются классами базы данных. Эти классы отличаются от обычных классов C++, содержащих лишь временно хранимые экземпляры. Для каждого класса базы данных X образуется вспомогательный класс указателей Ref. В действительности Ref эквивалентен указателю (X*), благодаря чему манипулирование этими указателями идентично.

Стандарт ODMG-93 определяет отображение типов ODL в типы C++, образуя расширенный язык C++ ODL. Для манипулирования объектами предоставляется библиотека классов C++ и функций, реализующая манипулирование базой данных, поддержку классов C++, эквивалентных встроенным типам ODL (например типам коллекций, связей), поддержку транзакций, динамический вызов запросов на OQL и др.

Роль СУОБД в архитектуре OMG

Следует выделять роли СУОБД ближайшего и более отдаленного плана. Немедленно, в соответствии со стандартом ODMG-93, СУОБД поддерживают функции долговременного хранения, восстановления объектов, управления транзакциями и конкурентным доступом к объектам. В архитектуре CORBA при необходимости брокер может получить эти услуги с помощью СУОБД, используя интерфейсы, определенные ODMG-93. При этом СУОБД играет роль менеджера многих (быть может миллионов) объектов. При взаимодействии программ-клиентов со многими объектами посредством брокера проблема минимизации затрат является очень острой. Для этого СУОБД должны обладать способностью перемещения объектов в распределенной среде и локального кэширования их в адресном пространстве клиента.

Если брокер играет роль коммуникационного механизма, обеспечивающего распределенное, прозрачная для клиентов диспетчиризация заявок к объектам, то СУОБД играет роль менеджера коллекций объектов, большая часть которых не зарегистрирована среди объектов, известных брокеру. Очевидно, что, если каждый объект, нужный клиенту, будет доступен только через брокер, накладные расходы станут недопустимо большими. Поэтому СУОБД должны поддерживать объекты известные и неизвестные брокеру, совместно используя с ним подмножества объектных идентификаторов. Доступ к объектам, неизвестным брокеру, реализуется посредством обращения при помощи брокера к объекту-контейнеру (базе данных), предоставляющий нужные объекты клиенту. Доступ к объектам, известным брокеру, может реализоваться клиентом либо при помощи обычных механизмов CORBA, либо требования, чтобы брокер направлял заявку к этим объектам в СУОБД. Оба варианта реализации заявок должны производить один и тот же эффект и быть совместимыми с заявками других клиентов, релизующими оба механизма. Для обеспечения способности регистрации подмножества объектных идентификаторов совместно с брокером, ODMG вводит новый тип адаптера - Адаптера Объектных Баз Данных (ODA - Object Database Adaptor). С точки зрения клиента, объекты в зарегистрированном подмножестве выглядят подобно любым другим объектам, доступным при помощи брокера.

В более отдаленной перспективе роль СУОБД в архитектуре OMG выглядит иначе: прежде всего, функции СУОБД предлагается реализовать совокупностью объектных служб: долговременного хранения объектов, управления конкурентным доступом к объектам, транзакций, связей, запросов, изменений объектов и др. Интерфейсы этих служб специфицированы OMG [13]. В частности, служба долговременного хранения объектов определена так, что не существует требования, чтобы объекты должны были использовать единственный механизм долговременного хранения. Это означает, что архитектура OMG является открытой по отношению к различным сервисам хранения объектов и данных вообще: любые из них могут быть интегрированы в архитектуре. Нижний (наименее видимый извне) интерфейс архитектуры Службы долговременного хранения есть среда хранения данных (Datastore).

На этом уровне OMG определено несколько протоколов, одним из которых является протокол ODMG-93. Протокол предусматривает видение объектов в Datastore как объектов, соответствующих ODL и имеющих отображения в языки программирования. Предполагается, что объект базы данных ODMG-93 унаследует свойства более общего интерфейса прямого доступа, определенного в службе долговременного хранения и играющего в ней важную роль. Тем самым будет обеспечена реализация протокола прямого доступа посредством СУОБД, соответствующих ODMG-93, как среды долговременного хранения данных.

Заключение

Стандарт систем управления объектными базами данных ODMG-93 является важным этапом развития технологии объектных баз данных. Стандарт служит точкой консолидации усилий промышленности, стабилизирующим фактором, способствующим устранению ненужного разнообразия продуктов. Потребуются еще значительные усилия, чтобы устранить многие технические несовершенства стандарта и таким образом укрепить его влияние. В результате ожидается появление ряда СУОБД, удовлетворяющих стандарту.

Работа ODMG оказывает позитивное влияние на архитектуру OMG в области объектных служб (в частности Службы долговременного хранения, Службы объектных запросов). В ближайшие годы можно ожидать появления ряда продуктов, реализующих эту архитектуру, в которых функции управления долговременно хранимыми объектами будут реализованы на основе принципов модульности и ортогональности объектных служб архитектуры OMG.

Сегодня стандарт ODMG-93 используется не только промышленностью при разработке объектных СУОБД. Его применяют, в частности, при проектировании ряда систем управления неоднородными мультибазами данных в качестве канонической объектной модели. Наиболее известной работой такого рода в Европе является проект IRO-DB [5] программы ESPRIT III, который ориентирован на достижение интероперабельности объектных и реляционных баз данных в рамках общей парадигмы, основу которой составляет ODMG -93.

Литература

  1. Atkinson M., et al The object-oriented database system manifesto, DOOD"89, 1989, pp. 40-57.
  2. Bancilhon F., Ferran G. ODMG-93: the object database standard. Data Engineering Bulletin, December 1994, v. 17., N 4 .
  3. Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С. Интероперабельные информационные системы: архитектуры и технологии. СУБД, N 4, 1995.
  4. Chaban I., Kalinichenko L., Zadorozhny V. Could the OODB standards be better if more grounded? Proc. of the Second East/West Database Workshop, Klagenfurt, 1994, Springer, 1995.
  5. Huck G., Fankhauser P., Busse R., Klas W. IRO-DB: an object-oriented approach towards federated and interoperable DBMS. Proceedings of the International Workshop "Advances in Databases and Information Systems", Moscow, 1994.
  6. M. Kay. A peg in the ground: a review of the object database standard: ODMG-93. First Class. The OMG Newsletter, 2(4), 1994, pp. 13.
  7. W. Kim. Observations on ODMG-93. First Class. The OMG Newsletter, 2(4), 1994, pp. 14-15.
  8. W. Kim. Observations on ODMG-93 Proposal. SIGMOD Record, 23(1), 1994, pp. 4-9.
  9. Objectivity/DB: Technical Overview. Objectivity, Inc., December 1994.
  10. Object Query Language, ODMG, Document 94-12-50 of OMG.
  11. The Object Database Standard: ODMG-93. Ed. by R. G.G. Cattell, Morgan Kaufmann Publ., 1994, p. 169.
  12. Object Management Group, "The Common Object Request Broker: Architecture and Specification", OMG Document Number 91.12.1, December 1991.
  13. Object Management Group, "Object Services Architecture", Revision 8.0, 09 December 1994.
  14. Object Management Group, " Object Management Architecture Guide", OMG Document Number 92.11.1, September 1, 1992.
  15. ODMG Response to the ODMG-93 Commentary written by Dr. Won Kim of UniSQL, Inc., SIGMOD Record, v. 23, N 3, September 1994.
  16. Язык описания данных КОДАСИЛ, Москва, Статистика, 1981.

Благодарность

Автор выражает глубокую благодарность М.Р. Когаловскому за тщательное прочтение рукописи и высказанные замечания.

1)Настоящая работа выполнена при поддержке гранта 94-07-20453 Российского Фонда Фундаментальных Исследований