Стандарты объектных запросов

Поскольку объектные технологии нашли применение в программных системах для анализа и проектирования, языках, графических пользовательских интерфейсах (GUI) и инструментальных программных средах, сообщество специалистов в области баз данных также активизировалось в направлении поддержки объектов и создания соответствующих стандартов. Ключевое преимущество объектной технологии состоит в способности различных объектов и объектных инструментальных средств к интероперабельности, поэтому крайне необходимо, чтобы такие объектные стандарты в области СУБД могли бы использоваться совместно со стандартами остального объектного мира. Содержание данной работы охватывает ряд тем - от обсуждения вновь возникших дискуссионных вопросов, связанных с объектами, и до стандартизации запросов. Мы представляем здесь усилия различных групп, относящиеся к этой сфере, в том числе ODMG, OMG, ANSI X3H2 (SQL), а также предпринимаемые с недавних пор усилия по объединению их идей, поддерживаемые в SQL3.

В данной работе обсуждается, в частности, следующее.

1. Каковы отличительные черты объектов?
2. Объектный язык запросов OQL ODMG.
3. Служба запросов в предложениях OMG.
4. Объектные расширения SQL3.
5. Усилия, направленные на объединение.

1. Каковы отличительные черты объектов?

Введение объектов в стандарты, связанные с базами данных, породило ряд новых дискуссионных вопросов. Фактически оно вызвало необходимость новых видов интерфейсов. В дополнение к привычному декларативному языку запросов объектный подход представляет возможность интеграции интерфейса с объектным языком, так что используемые в этом языке объекты автоматически поддерживаются средствами базы данных. Это позволяет программистам работать полностью в объектном языке и исключить преобразования между структурами базы данных и структурами языка. Вместе с тем декларативный язык для определения типов объектов может быть значительно более широким, допуская многие другие виды структур. Наконец, язык запросов может также предоставлять доступ к другим структурам. Таким образом, потенциально имеются интерфейсы для определения типов, для формулирования запросов и для интеграции с объектными языками программирования, и все они обладают более широкими многообразиями типов.

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

• инкапсуляция: операции;
• индивидуальность (identity);
• ссылки (references);
• коллекции (collectons).

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

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

Мы упоминали выше, что пользователь объекта осуществляет доступ к видимым извне атрибутам и операциям, но имеются также и другие видимые извне характеристики - связи объектов. Для бинарных связей простая связь вида "один-к-одному" может рассматриваться как атрибут со значением-объектом (object-valued) в каждом из двух связанных объектов. Связи вида "многие-ко-многим" могут рассматриваться как атрибуты с каждой стороны с множественными значениями-объектами или с коллекциями значений-объектов. Интерфейс определения типов должен поддерживать средства для объявления таких связей, а интерфейсы языка запросов и объектного языка¹⁾ должны предоставлять средства для их создания, удаления и навигации по ним (traverse). Могут представлять также интерес и N-арные связи.

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

2. ODMG

ODMG (The Object Database Management Group) - консорциум поставщиков программного обеспечения объектно-ориентированных систем баз данных - создал все три описанные выше интерфейса с тем, чтобы совместно предложить их OMG (Object Management Group), ANSI (American National Standards Institute), ISO (International Organization for Standardization), а также другим заинтересованным организациям пользователей. В частности, в публикации стандарта ODMG-93²⁾ представлены спецификации следующих интерфейсов:

• языка определения объектов (Object Definition Language - ODL);
• языка объектных запросов (Object Query Language - OQL);
• спецификаций связывания с C++;
• спецификаций связывания со Smalltalk.

Для обеспечения интерфейса с объектными языками ODMG был выбран вариант использования уже существующих языков C++ и Smalltalk, которые связываются с объектной моделью базы данных таким образом, чтобы программисты могли нормальным образом определять объекты в этих двух языках и эти объекты автоматически поддерживались бы в базе данных.

В части определения объектов ODMG был применен в качестве стартовой платформы разработанный OMG язык определения интерфейсов IDL. Этот язык был расширен дополнительными возможностями, необходимыми для объектных баз данных, в том числе средствами объявления коллекций, двунаправленных связей вида "многие-ко-многим", ключей и (факультативных) экстентов. В сочетании с имеющимися в IDL возможностями определения атрибутов и операций эти средства позволяют определять любые объекты. К тому же, поскольку все указанные дополнения к IDL определяются как семантически эквивалентные генерируемым методам (например методам навигации для связей) и все объекты ODL непосредственно продуцируют IDL-интерфейсы, то они являются доступными в мире стандартов OMG, включающем Общую Архитектуру Брокера Объектных Заявок (CORBA, диспетчер методов), а также объектные службы и общие средства³⁾.

Что касается запросов, то ODMG исходил из основного средства спецификации запросов в языке SQL-92 (иногда называемом SQL2) - оператора SELECT - и ввел дополнительно возможности для формирования запросов к любому объекту или коллекции объектов. Все это определяется с помощью простого, замкнутого типизированного функционального языка. Тип результата обработки запроса может быть скаляром (в том числе кортежем), объектом или коллекцией объектов, в соответствии с правилами комбинации типов, специфицирующими, какие операции над какими типами продуцируют другие типы и какие именно. Вызов операции синтаксически представляет собой то же самое, что и ссылка на атрибут с факультативным добавлением параметров. Навигация в связях специфицируется с помощью синтаксической конструкции (a.b) с точкой. Добавлены также синтаксические средства для спецификации коллекций, таких как списки (list), множества (set), мультимножества (bag) и массивы (array).

Ниже приводятся примеры операторов предложенного ODMG языка запросов OQL.

1) Select x from x in faculty 
where x.salary > x.dept.chair.salary

2) sort s in (select struct (name:x.name, s:x.ssn) from x in faculty
where for all y in x.advisees:y.age<25) by s.name

3) Chair.salary

4) Student except TAs

5) list (1,2) + list (count (jse.advisees), 1+2)

6) exists x in faculty [1:n]: x.spouse.age<25

Если не считать указанных добавлений (навигационная точка, параметры операции и обозначения коллекций), то спецификации запросов на языке OQL выглядят весьма похожими на запросы только на чтение (read only) в SQL2 (оператор SELECT). В самой последней версии 1.2 спецификаций ODMG предпринял попытку сделать OQL полностью совместимым с SQL2 в том смысле, что любой запрос в языке SQL2 был бы допустимым запросом в OQL с теми же самыми синтаксисом, семантикой и результатом. Хотя это и было в значительной степени достигнуто (по некоторым предположениям, на 90%), указанные языки совместимы не во всех случаях. Имеются случаи, когда запрос в OQL и запрос, синтаксически идентичный SQL2, будут продуцировать результаты различных типов. В то время как SQL2 всегда работает в терминах типов таблиц, OQL может продуцировать коллекции. Так, например, запрос в SQL2:

select f(x) from R x where p(x)

возвращает таблицу типа

multiset(row(type(f(x))))4)

в то время, как в OQL он возвратит

multiset(type(f(x))).4)

SQL2 содержит длинный и сложный список специальных случаев, в то время как OQL имеет краткое простое определение. Пока что ODMG решительно прекратил добавление всех этих специальных случаев и обращений к таблицам.

3. OMG

OMG (Object Management Group) - это консорциум по программному обеспечению, разрабатывающий спецификации интерфейсов, которые позволяют обеспечить интероперабельность между объектами, а также между объектными инструментальными средствами. Начальным результатом его деятельности стал CORBA, механизм для пользователя, позволяющий вызывать операции на удаленных объектах. Каждый объект регистрирует с помощью диспетчера CORBA те операции, которые он поддерживает, средствами IDL (см. выше). Далее, OMG были предложены определения в терминах IDL для интерфейсов нескольких объектных служб, в том числе служб:

• именования (Naming);
• долговременного хранения (Persistence);
• связей (Relationships);
• транзакций (Transactions);
• запросов (Query)

и т. д.

В настоящее время OMG сотрудничает с ISO Open Distributed Processing (ODP) с тем, чтобы инициировать формальный процесс стандартизации своих интерфейсов CORBA.

Некоторые объектные службы OMG частично покрывают сферу систем управления базами данных. Фактически СУБД может рассматриваться как предоставление нескольких подобного рода служб в одном пакете таким образом, что этот пакет включает также и средства восстановления, общей буферизации и индексирования для повышения производительности и т. д. Другой способ - рассматривать взаимосвязь между OMG и СУБД с позиций архитектурных уровней. Например, служба транзакций OMG совместима с протоколом X/Open X/A для двухфазной фиксации, который широко используется программными продуктами - менеджерами транзакций для координации атомарных транзакций, инициированных несколькими СУБД, и другими менеджерами ресурсов.

Служба долговременного хранения предоставляет интерфейс, который позволяет клиенту направить заявку с тем, чтобы некоторый объект стал долговременно хранимым, и благодаря этому обеспечить сохранение текущего состояния объекта, а также восстановление предыдущего сохраненного состояния. Он значительно отличается от непосредственных интерфейсов объектных языков или интерфейсов запросов, обсуждаемых выше и применяемых в объектных СУБД, но может однако быть реализован в терминах СУБД. Служба долговременного хранения включает, в частности, менеджер долговременно хранимых объектов (Persistent Object Manager, POM), который предоставляет интерфейс для клиента и для сохраняемого объекта, сервис поддержки индивидуальности долговременно хранимых объектов (Persistent Identity Service, PID), который генерирует идентификаторы, используемые клиентом, для того, чтобы позднее восстанавливать состояние, и, наконец, хранилища долговременно хранимых данных (Persistent Data Stores, PDS), где сохраняется состояние. Внутренний протокол (Backend Protocol) между POM и PDS может быть любым из трех различных протоколов, определенных в этой спецификации. Два из них предназначены для того, чтобы формировать плоское представление состояния объекта в линейных потоках, которое может сохраняться в файлах (последовательный поток байтов) или в записе-ориентированной базе данных, в то время, как третий вызывает интерфейс ODMG-93 для непосредственного сохранения объектов как объектов в СУБД, поддерживающей такой объектный интерфейс.

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

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

• специфицированное подмножество SQL2 (грубо говоря, состоящее из операторов SELECT, INSERT, UPDATE и DELETE);
• OQL;
• подмножество OQL, ограниченное простыми запросами и множествами, но включающее операции.



Рисунок 3.
Архитектура службы запросов OMG.

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

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

4. SQL3

В настоящее время ANSI X3H2⁵⁾ совместно с ISO/IEC JTC1/SC21/WG3⁶⁾ DBL работает над следующей версией стандарта языка SQL, иногда называемой SQL3. Текущий проект включает много новых возможностей, в том числе два весьма значительных дополнения: объектные функциональные возможности и средства, обеспечивающие вычислительную полноту языка (Управление хранимыми процедурами - Procedure Storage Management, далее для краткости PSM). В этот проект пока еще вносятся изменения, однако уже достигнуты существенные результаты.

Благодаря дополнению PSM обеспечивается полный язык с управляющими структурами, процедурными операциями и разрешением функций. Это - иной подход по сравнению с подходами, избранными OMG и ODMG, которые вместо создания своих собственных языков выбрали путь отображения в другие языки (пока только C++ и Smalltalk у ODMG, эти же языки, а также C и Ada - у OMG). Однако здесь нет какого-либо противоречия. Как OMG, так и ODMG намерены в будущем добавлять спецификации связывания с другими языками. Таким образом, как только PSM примет его окончательную форму, для OMG и ODMG будет, видимо, достаточно просто и почти наверняка возможно разработать спецификации отображения в (или связывания с) SQL3 PSM точно так же, как это было сделано ранее для других языков, и будет, весьма вероятно, делаться для еще большего числа языков в дальнейшем.

В составе добавленных объектных возможностей предусмотрены средства определения абстрактных типов данных (Abstract Data Type, или для краткости ADT) и доступа к ним, которые обеспечивают в большой мере те же функции, что и объекты OMG и ODMG, в том числе видимые извне атрибуты и операции. В SQL3 используются собственные языковые средства (PSM) для реализации свойств этих объектов - как состояний, так и операций. Намерение заключается в том, чтобы дополнительно обеспечить "объектно-ориентированность" для строк в таблицах, в отличие от общего объектного подхода OMG и ODMG. Такие строки могут содержать ADT. Существует механизм для ссылок на ADT в других строках, обеспечивающий средства уникальной идентификации такой строки (но не поиск ее по содержащимся в ней значениям). Это - основа концепции индивидуальности, подобной PID в подходе OMG и объектным ссылкам (Ref<>) у ODMG.

Некоторые из связанных с этими аспектами вопросов, в частности обновление и авторизация, пока еще дебатируются комитетами, занимающимися SQL3. Хотя операции над ADT представляют собой естественный объектный подход к изменению состояния объекта, в SQL2 требуется, чтобы обновление данных выполнялось с помощью явного запроса, например UPDATE.

Один из возможных подходов заключается в использовании семантики "копирования" (copy). При этом пользователь извлекает объект (или, возможно, множество объектов) в некоторое приватное пространство, выполняет над ним операции, применяя методы ADT, а затем обновляет базу данных, вызывая явный оператор UPDATE. Такой подход имеет преимущества сходства с подходом SQL2 и предоставляет естественное место для проверки полномочий пользователя во время выполнения оператора UPDATE. Он, однако, неестественен, с точки зрения объектного пользователя, и, как представляется, требует от пользователя повторной спецификации всех изменений в операторе UPDATE. Это последнее может даже оказаться невозможным в некоторых ситуациях. После таких обновлений, кроме того, требуется явно заданный оператор COMMIT, позволяющий сохранить осуществленные изменения и сделать их видимыми для других пользователей.

Другой подход основан на использовании семантики "ссылок" (reference). При этом операции ADT рассматриваются как непосредственно изменяющие объекты в базе данных. Никаких дополнительных операторов UPDATE не требуется. Такой подход более естественен для объектных пользователей и вместе с тем является более легким для них, поскольку он исключает повторение всех операций, но требует, однако, какого-либо иного решения для проверки полномочий пользователей. Хотя SQL3 уже включает проверку допустимости оператора EXECUTION, предоставление полномочий на уровне объекта или таблицы потребовало бы некоторого дополнительного механизма, такого как охранные функции (guard functions), которые вызываются во время вызова требуемой операции.

Средства спецификации запросов SQL3 включают в точности аналогичные средства SQL2, что не удивительно, вместе с дополнительными возможностями вызова методов и навигации по связям. И снова это весьма похоже на запросы ODMG (которые используются также OMG). Однако там, где запросы ODMG могут применяться к объектам и вырабатывать в результате объекты и коллекции, запросы SQL3 ограничиваются таблицами. Имеются также синтаксические различия. Например, там, где в спецификациях ODMG для указания навигации используется точка, в SQL3 применяется пара точек (a..b) с тем, чтобы исключить конфликты с использованием точки в конструкциях SQL2, служащих для именования (catalogue.table).

5. Усилия по объединению

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

Именно в этом состоит цель рабочей группы, совместно сформированной X3H2 и ODMG. Небольшая группа ведущих технических сотрудников из обеих организаций, работая совместно, пытается продвинуться в решении рассматриваемой проблемы. Как показано на рисунке 4, цель состоит не в том, чтобы вынудить какую-либо модель или какой-либо стандарт стать такими же, как другие, а, скорее, в том, чтобы найти общий язык запросов, используемый только для чтения. SQL3, несомненно, обогатится благодаря включению PSM так же, как и несомненно обогатился подход ODMG благодаря включению ODL и спецификациям связывания с традиционными языками программирования.

К настоящему времени объединенной рабочей группой уже достигнут значительный прогресс. В разработанный ODMG язык OQL внесено несколько изменений с тем, чтобы обеспечить такое объединение. Эти изменения, опубликованные теперь в версии 1.2, включают:

• добавление типа данных null (неопределенное значение);
• добавление табличного типа данных;
• некоторые уточнения в деталях синтаксиса.

Хотя в версии 1.2 была поставлена цель добиться абсолютной (100%) совместимости со средствами спецификации запросов SQL2, эта цель не была в полной мере достигнута (как уже отмечалось, некоторые оценивают степень совместимости в 90%). Различия обусловлены, главным образом, типизированным подходом, принятым в OQL (см. выше). В то время как запросы SQL имеют дело только с таблицами и возвращают только кортежи, запросы OQL оперируют любыми объектами и коллекциями, а возвращают кортежи, объекты или коллекции. Имеется также множество специальных случаев, накопленных и поддерживаемых в SQL за годы процесса стандартизации.

Группа специалистов, занимающихся объединением, рассмотрела также SQL3, проанализировала различия объектных моделей и пришла к тому выводу, что необходимо заниматься только двумя из них для достижения цели создания общего языка запросов. Первое заключалось в том, чтобы связать OID с объектом, а не оставлять его связанным с местоположением таблицы, что могло бы привести к изменению OID объектов, когда они перемещаются. Это было сделано путем исключения отдельного понятия объекта и включения ссылок на ADT (абстрактные типы данных) в строках (LHR77⁷⁾).

Для того чтобы справиться со вторым различием и добавить в SQL3 способность запрашивать объекты и коллекции, группа пришла к согласию относительно следующего подхода и приступила к его реализации.

• Выявить те элементы BNF⁸⁾ в OQL, которые могут вырабатывать в результате скаляры, объекты и коллекции.
• В BNF-спецификациях SQL3 всякий раз, когда встречаются скаляры, объекты и коллекции, вставить вместо них выражения OQL.
• Выявить и разрешить все синтаксические конфликты.
• Выявить и устранить все случаи синтаксической избыточности.

Полученный в результате синтаксис OQL занимает около двух страниц спецификаций в BNF. Относящиеся к делу части BNF-спецификаций SQL3 после удаления не являющихся необходимыми терминальных символов также занимают всего лишь несколько страниц. Таким образом, рассматриваемая задача представляется разрешимой. Конечно, потребуется внести некоторые изменения в синтаксис, но, как можно надеяться, после решения модельных вопросов синтаксические проблемы не будут непреодолимыми.

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

Литература

1. Документы SQL

Стандарт SQL-92 (ISO/ANSI SQL) представлен в документе

Database Language SQL, International Standard ISO/IEC 9075:1992, American National Standards Institute, November 1992.

Свободно распространяемые документы рабочего проекта SQL3 могут быть доступны из любой национальной организации по стандартизации, активно участвующей в деятельности ISO/IEC JTC1. Список документов, доступных в оперативном режиме, можно найти по адресу: ftp://speckle.ncsl.nistgov/isowg3/dbl/doclog.txt.

Следующие документы являются рабочими проектами, представленными в марте 1995 г., для расширений к документу Database Language SQL, ISO/IEC 9075:1992:

Части документа SC21 N9443 Description of Status of SQL93:

• SC21 N9462 SQL3 Part 1: Framework
• SC21 N9463 SQL3 Part 2: Foundation
• SC21 N9464 SQL3 Part 3: Call Level Interface
• SC21 N9465 SQL3 Part 4: Persistent Stored Modules
• SC21 N9466 SQL3 Part 5: Language Bindings
• SC21 N9467 SQL3 Part 6: XA Specialization

Части 3 и 4 являются наиболее продвинутыми, а часть 5 - эквивалентна материалам из SQL-92. Все объектные возможности SQL представлены в части 2.

2. ODMG

R.Cattell, Ed., The Object Database Standard: ODMG-93, ISBN 1-55860-302-6. - Morgan Kaufmann Publishers, San Francisco, California, 1993. Тел.: (800) 745-7323.

В Европе доступны из Автерхурста (Afterhurst): +44-273-748427, +44-273-722180 - факс.

Заказы можно сделать также через Internet по адресам: orders@mkp.com, http://www.mkp.com, http://www.omg.org.

3. OMG

Вводную информацию можно получить в Internet по адресу: http://www.omg.org, а список документов - по ftp://ftp.omg.org/pub/docs/doclist.txt.

Перечисленные ниже материалы опубликованы также OMG:

• Object Management Group, Framingham Corporate Center, 492 Old Connecticut Path Framingham, MA 01701, (508) 820-4300, факс: (508) 820-4303.
• Persistent Object Service, ftp://ftp.omg.org/pub/docs/1994/94-10-07.ps
• Query Service, ftp://ftp.omg.org/pub/docs/../1995/95-01-01.ps

¹⁾ Под объектным языком здесь понимается язык программирования с возможностями поддержки объектов. Такие языки часто называют объектно-ориентированными. - Прим. пер.

²⁾ Краткий обзор и анализ основных идей стандарта ODMG-93 представлен в работе

• Калиниченко Л.А. Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния. - СУБД, # 1, 1996. - Прим. пер.

³⁾ Обзор основных принципов и компонентов стандарта CORBA читатель может найти в работах:

• Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С. Интероперабельные информационные системы: архитектуры и технологии. СУБД, # 4, 1995.
• Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте CORBA 2.0. СУБД, # 3, 1996.

Спецификации языка IDL и концепции объектной модели OMG, на которой он базируется, обсуждаются в обзоре:

• Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД, # 2, 1996. - Прим. пер.

⁴⁾ Поскольку в синтаксисе OQL для обозначения мультимножества используется ключевое слово "bag", было бы более уместно применять здесь в выражениях для обозначения результирующего типа именно это ключевое слово вместо "multiset". - Прим. пер.

⁵⁾ X3 - комитет по разработке стандартов в области информационных технологий, аккредитованный при Американском национальном институте стандартов (ANSI). X3H2 - комитет по стандартам в области синтаксиса и семантики языков баз данных, действующий в составе X3. Важное направление деятельности X3H2 - разработка стандарта языка SQL. Эта работа проводится в тесном взаимодействии с ISO и ODMG.- Прим. пер.

⁶⁾ Аббревиатура ISO/IEC JTC1/SC21/WG3 здесь означает следующее. ISO/IEC JTC1 - Объединенный комитет Международной организации по стандартизации и Международной электротехнической комиссии, задача которого - создание стандартов в области информационных технологий. SC21 - подкомитет этого комитета, занимающийся стандартами в области взаимосвязей открытых систем, управления данными и открытой распределенной обработки. Наконец, WG3 - это рабочая группа по базам данных указанного подкомитета. - Прим. пер.

⁷⁾ Автор ссылается на подготовленный в рамках разработки проекта стандарта SQL3 документ "Introducing Reference Types and Cleaning up SQL3's Object Model. K.Kulkarni, M.Carey et al. LHR77. December 18, 1995". - Прим. пер.

⁸⁾ Здесь BNF - аббревиатура от Backus Normal Form. Язык нормальных форм Бэкуса - это метаязык, широко используемый для описания синтаксиса различных языков программирования, языковых средств систем баз данных, а также языков другого рода. Был разработан специально для описания языка Алгол-60 одним из его создателей - Дж. Бэкусом. - Прим. пер.

Переведено и опубликовано с разрешения АСМ.

(c) 1996 АСМ, Inc.

(c) Пер. с англ. Когаловского М.Р. В переводе без специальных оговорок исправлены опечатки, обнаруженные переводчиком в оригинале.