Объектно-ориентированные базы данных - основные концепции
Объектно-ориентированные базы данных - основные концепции,
организация и управление: краткий обзор
1. Введение
Направление объектно-ориентированных баз данных (ООБД)
возникло сравнительно давно. Публикации появлялись уже в
середине 1980-х (например, [96]). Однако наиболее активно это
направление развивается в последние годы. С каждым годом
увеличивается число публикаций и реализованных коммерческих и
экспериментальных систем.
Возникновение направления ООБД определяется прежде всего
потребностями практики: необходимостью разработки сложных
информационных прикладных систем, для которых технология
предшествующих систем БД не была вполне удовлетворительной.
Конечно, ООБД возникли не на пустом месте. Соответствующий
базис обеспечивают как предыдущие работы в области БД, так и
давно развивающиеся направления языков программирования с
абстрактными типами данных и объектно-ориентированных языков
программирования.
Что касается связи с предыдущими работами в области БД, то на
наш взгляд наиболее сильное влияние на работы в области ООБД
оказывают проработки реляционных СУБД и следующее
хронолигически за ними семейство БД, в которых поддерживается
управление сложными объектами [52-56]. Кроме того,
исключительное влияние на идеи и концепции ООБД и, как
кажется, всего объектно-ориентированного подхода оказал подход
к семантическому моделированию данных (например, [57-59], хотя
общее число публикаций по семантическому моделированию
поистине безгранично). Достаточное влияние оказывают также
развивающиеся параллельно с ООБД направления дедуктивных и
активных БД [10, 42, 82, 84].
Среди языков и систем программирования наибольшее первичное
влияние на ООБД оказал Smalltalk [34, 36]. Этот язык сам по
себе не является полностью поинерским, хотя в нем была введена
новая терминология, являющаяся теперь наиболее
распространенной в объектно-ориентированном программировании.
На самом деле, Smalltalk основан на ряде ранее выдвинутых
концепций. Хороший обзор идей и подходов
объектно-ориентированного программирования представлен,
например, в [3].
Большое число работ не означает, что все проблемы ООБД
полностью решены. Как отмечается в Манифесте группы ведущих
ученых, занимающихся ООБД, [8] современная ситуация с ООБД
напоминает ситуацию с реляционными системами середины 1970-х.
При наличии большого количества экспериментальных проектов (и
даже коммерческих систем) отсутствует общепринятая
объектно-ориентированная модель данных, и не потому, что нет
ни одной разработанной полной модели, а по причине отсутствия
общего согласия о принятии какой-либо модели. На самом деле,
имеются и более конкретные проблемы (например, [5, 7]),
связанные с разработкой декларативных языков запросов,
выполнением и оптимизацией запросов, формулированием и
поддержанием ограничений целостности, синхронизацией доступа и
управлением транзакциями и т.д.
Тематика ООБД очень широка, объем настоящего обзора не
позволяет рассмотреть все вопросы. Тем не менее, мы
постараемся в систематической манере проанализировать наиболее
важные аспекты ООБД (критерии отбора тем и источников
полностью субъективны). Обзор построен по следующему плану:
Первый раздел - настоящее введение. Во втором разделе
излагаются основные понятия объектно-ориентированного подхода
и их специфическое преломление в контексте ООБД. В третьем
разделе рассматриваются основные понятия
объектно-ориентированного моделирования данных. Четвертый
раздел посвящен языкам программирования и языкам запросов
ООБД. В пятом разделе кратко обозреваются характерные
представители объектно-ориентированных СУБД - ORION и O2.
Шестой раздел посвящается проблематике выполнения и
оптимизации запросов к ООБД. В седьмом разделе рассматриваются
вопросы синхронизации доступа и управления транзакциями в
ООБД. Восьмой раздел касается связи ООБД и дедуктивных и
активных БД. Наконец, девятый раздел - краткое заключение.
2. Общие понятия объектно-ориентированного подхода и их
Если в языке или
системе поддерживается единичное наследование классов, набор
классов образует древовидную иерархию. При поддержании
множественного наследования классы связаны в ориентированный
граф с корнем, называемый решеткой классов. Объект подкласса
считается принадлежащим любому суперклассу этого класса.
Одной из более поздних идей объектно-ориентированного подхода
является идея возможного переопределения атрибутов и методов
суперкласса в подклассе (перегрузки методов). Эта возможность
увеличивает гибкость, но порождает дополнительную проблему:
при комплиляции объектно-ориентированной программы могут быть
неизвестны структура и программный код методов объекта, хотя
его класс (в общем случае - суперкласс) известен. Для
разрешения этой проблемы применяется так называемый метод
позднего связывания, означающий, по сути дела,
интерпретационный режим выполнения программы с распознаванием
деталей реализации объекта во время выполнения посылки
сообщения к нему. Введение некоторых ограничений на способ
определения подклассов позволяет добиться эффективной
реализации без потребностей в интерпретации [97].
Как видно, при таком наборе базовых понятий, если не принимать
во внимание возможности наследования классов и соответствующие
проблемы, объектно-ориентированный подход очень близок к
подходу языков программирования с абстрактными (или
произвольными) типами данных [77].
С другой стороны, если абстрагироваться от поведенческого
аспекта объектов, объектно-ориентированный подход весьма
близок к подходу семантического моделирования данных [58]
(даже и по терминологии). Фундаментальные абстракции, лежащие
в основе семантических моделей, неявно используются и в
объектно-ориентированном подходе. На абстракции агрегации
основывается построение сложных объектов, значениями атрибутов
которых могут быть другие объекты. Абстракция группирования -
основа формирования классов объектов. На абстракциях
специализации/обобщения основано построение иерархии или
решетки классов.
Видимо, наиболее важным новым качеством ООБД, которое
позволяет достичь объектно-ориентированный подход, является
поведенческий аспект объектов. В прикладных информационных
системах, основывавшихся на БД с традиционной организацией
(вплоть до тех, которые базировались на семантических моделях
данных), существовал принципиальный разрыв между структурной и
поведенческой частями. Структурная часть системы
поддерживалась всем аппаратом БД, ее можно было моделировать,
верифицировать и т.д., а поведенческая часть создавалась
изолированно. В частности, отсутвовали формальный аппарат и
системная поддержка совместного моделирования и гарантирования
согласованности этих структурной (статической) и поведенческой
(динамической) частей. В среде ООБД проектирование, разработка
и сопровождение прикладной системы становится процессом, в
котором интегрируются структурный и поведенческий аспекты.
Конечно, для этого нужны специальные языки, позволяющие
определять объекты и создавать на их основе прикладную систему
[70].
Специфика применения объектно-ориентированного подхода для
организации и управления БД потребовала уточненного толкования
классических концепций и некоторого их расширения [6]. Это
определяется потребностями долговременного хранения объектов
во внешней памяти, ассоциативного доступа к объектам,
обеспечения согласованного состояния ООБД в условиях
мультидоступа и тому подобных возможностей, свойственных базам
данных [8]. В [6] выделяются три аспекта, отсутствующие в
традиционной парадигме, но требующиеся в ООБД.
Первый аспект касается потребности в средствах спецификации
знаний при определении класса (ограничений целостности, правил
дедукции и т.п.) Второй аспект - потребность в механизме
определения разного рода семантических связей между объектами
вообще говоря разных классов. Фактически это означает
требование полного распространения на ООБД средств
семантического моделирования данных. Потребность в
использовании абстракции ассоциирования отмечается и в связи с
использовании ООБД в сфере автоматизированного проектирования
и инженерии [66]. Наконец, третий аспект связан с пересмотром
понятия класса. В контексте ООБД оказывается более удобным
рассматривать класс как множество объектов данного типа, т.е.
одновременно поддерживать понятия и типа и класса объектов.
Как мы отмечали во введении, в сообществе исследователей ООБД
и разработчиков систем отсутствует полное согласие, но в
большинстве практических работ используется некоторое
расширение объектно-ориентированного подхода.
3. Объектно-ориентированные модели данных
Первой формализованной и общепризнанной моделью данных была
реляционная модель Кодда [98]. В этой модели, как и во всех
следующих, выделялись три аспекта - структурный, целостный и
манипуляционный. Структуры данных в реляционной модели
основываются на плоских нормализованных отношениях,
ограничения целостности выражаются с помощью средств логики
первого порядка и, наконец, манипулирование данными
осуществляется на основе реляционной алгебры или равносильного
ей реляционного исчисления. Как отмечают многие исследователи,
своим успехом реляционная модель данных во многом обязана
тому, что опиралась на строгий математический аппарат теории
множеств, отношений и логики первого порядка. Разработчики
любой конкретной реляционной системы считали своим долгом
показать соответствие своей конкретной модели данных общей
реляционной модели, которая выступала в качестве меры
"реляционности" системы.
Основные трудности объектно-ориентированного моделирования
данных проистекают из того, что такого развитого
математичекого аппарата, на который могла бы опираться общая
объектно-ориентированная модель данных, не существует. В
большой степени поэтому до сих пор нет базовой
объектно-ориентированной модели. С другой стороны, в [63] со
ссылкой на недоступную нам работу Майера [99] утверждается,
что общая объектно-ориентированная модель данных в
классическом смысле и не может быть определена по причине
непригодности классического понятия модели данных к парадигме
объектной ориентированности.
Не приводя доводов в пользу этого утверждения Майера, но и не
оспаривая его, Беери [63] предлагает в общих чертах формальную
основу ООБД, далеко не полную и не являющуюся моделью данных в
традиционном смысле, но позволяющую исследователям и
разработчикам систем ООБД по крайней мере говорить на одном
языке (если, конечно, предложения Беери будут развиты и
получат поддержку). Независимо от дальнейшей судьбы этих
предложений мы считаем полезным кратко их пересказать.
Во-первых, следуя практике многих ООБД, предлагается выделить
два уровня моделирования объектов: нижний (структурный) и
верхний (поведенческий). На структурном уровне поддерживаются
сложные объекты, их идентификация и разновидности связи "isa".
База данных - это набор элементов данных, связанных
отношениями "входит в класс" или "является атрибутом". Таким
образом, БД может рассматриваться как ориентированный граф.
Важным моментом является поддержание наряду с понятием объекта
понятия значения (позже мы увидим, как много на этом построено
в одной из успешных объектно-ориентированных СУБД O2 [29]).
Важным аспектом является четкое разделение схемы БД и самой
БД. В качестве первичных концепций схемного уровня ООБД
выступают типы и классы. Отмечается, что во всех системах,
использующих только одно понятие (либо тип, либо класс) это
понятие неизбежно перегружено: тип предполагает наличие
некоторого множества значений, определяемого структурой данных
этого типа; класс также предполагает наличие множества
объектов, но это множество определяется пользователем. Таким
образом, типы и классы играют разную роль, и для строгости и
недвусмысленности требуются одновременное поддержание обоих
понятий.
Автор [63] не представляет полной формальной модели
структурного уровня ООБД, но выражает уверенность, что
текущего уровня понимания достаточно, чтобы формализовать
такую модель. Что же касается поведенческого уровня, предложен
только общий подход к требуемому для этого логическому
аппарату (логики первого уровня недостаточно).
Важным, хотя и недостаточно обоснованным предположением Беери
является то, что двух традиционных уровней - схемы и данных
для ООБД недостаточно. Для точного определения ООБД требуется
уровень мета-схемы (см. также [65]), содержимое которой должно
определять виды объектов и связей, допустимых на схемном
уровне БД. Мета-схема должна играть для ООБД такую же роль,
какую играет структурная часть реляционной модели данных для
схем реляционых баз данных.
Имеется достаточное количество других публикаций, отноcящихся
к теме объектно-ориентированных моделей данных [61-62, 64,
65-68], но они либо затрагивают достаточно частные вопросы,
либо используют слишком серьезный для этого обзора
математический аппарат (к числу последних относится работа
Леллани и Спиратоса [68], в которой объектно-ориентированная
модель данных определяется на основе теории категорий).
Для иллюстрации текущего положения дел мы кратко рассмотрим
особенности конкретной модели данных, применяемой в
объектно-ориентированной СУБД O2 [29, 32] (это, конечно, тоже
не модель данных в классическом смысле).
В O2 поддерживаются объекты и значения. Объект - это пара
(идентификатор, значение), причем объекты инкапсулированы,
т.е. их значения доступны только через методы - процедуры,
привязанные к объектам. Значения могут быть атомарными или
структурными. Структурные значения строятся из значений или
объектов, представленных своими идентификаторами, с помощью
конструкторов множеств, кортежей и списков. Элементы
структурных значений доступны с помощью предопределенных
операций (примитивов).
Возможны два вида организации данных: классы, экземплярами
которых являются объекты, инкапсулирующие данные и поведение,
и типы, экземплярами которых являются значения.
Каждому классу
сопоставляется тип, описывающий структуру экземпляров класса.
Типы определяются рекурсивно на основе атомарных типов и ранее
определенных типов и классов с применением конструкторов.
Поведенческая сторона класса определяется набором методов.
Объекты и значения могут быть именованными. С именованием
объекта или значения связана долговременность его хранения
(persistency): любые именованные объекты или значения
долговременны; любые объект или значение, входящие как часть в
другой именованный объект или значение, долговременны.
С помощью специального указания, задаваемого при определении
класса, можно добиться долговременности хранения любого
объекта этого класса. В этом случае система автоматически
порождает значение-множество, имя которого совпадает с именем
класса. В этом множестве гарантированно содержатся все объекты
данного класса.
Метод - программный код, привязанный к конкретному классу и
применимый к объектам этого класса. Определение метода в O2
производится в два этапа. Сначала объявляется сигнатура
метода, т.е. его имя, класс, типы или классы аргументов и тип
или класс результата. Методы могут быть публичными (доступными
из объектов других классов) или приватными (доступными только
внутри данного класса). На втором этапе определяется
реализация класса на одном из языков программирования O2
(подробнее языки обсуждаются в следующем разделе нашего
обзора).
В модели O2 поддерживается множественное наследование классов
на основе отношения супертип/подтип. В подклассе допускается
добавление и/или переопределение атрибутов и методов.
Возможные при множественном наследовании двусмысленности (по
именованию атрибутов и методов) разрешаются либо путем
переименования, либо путем явного указания источника
наследования. Объект подкласса является объектом каждого
суперкласса, на основе которого порожден данный подкласс.
Поддерживается предопределенный класс "Оbject", являющийся
корнем решетки классов; любой другой класс является неявным
наследником класса "Object" и наследует предопределенные
методы ("is_same", "is_value_equal" и т.д.).
Специфической особенностью модели O2 является возможность
объявления дополнительных "исключительных" атрибутов и методов
для именованных объектов. Это означает, что конкретный
именованный объект-представитель класса может обладать типом,
являющимся подтипом типа класса. Конечно, с такими атрибутами
не работают стандартные методы класса, но специально для
именованного объекта могут быть определены дополнительные (или
переопределены стандартные) методы, для которых дополнительные
атрибуты уже доступны. Подчеркивается, что дополнительные
атрибуты и методы привязываются не к конкретному объекту, а к
имени, за которым в разные моменты времени могут стоять вообще
говоря разные объекты. Для реализации исключительных атрибутов
и методов требуется развитие техники позднего связывания.
В [29] приводится достаточно формализованное описание модели
O2, мы для простоты изложения и понимания следовали [32], где
модель описывается на содержательном уровне. В следующем
разделе мы среди прочего рассмотрим особенности языков
программирования и запросов системы O2, которые, конечно,
тесно связаны со спецификой модели данных.
4. Языки программирования систем ООБД и языки запросов
Как отмечают многие исследователи и разработчики (например,
[8, 70]), объектно-ориентированная система БД представляет
собой объединение системы программирования и СУБД
(альтернативная, но не более проясняющая суть дела точка
зрения состоит в том, что объектно-ориентированная СУБД - это
СУБД, основанная на объектно-ориентированной модели данных
[8]).
Мы уже говорили, что основная практическая надобность в ООБД
связана с потребностью в некоторой интегрированной среде
построения сложных информационных систем. В этой среде должны
отсутствовать противоречия между структурной и поведенческой
частями проекта и должно поддерживаться эффективное управление
сложными структурами данных во внешней памяти. С этой точки
зрения языковая среда ООБД - это объектно-ориентированная
система программирования, естественно включающая средства
работы с долговременными объектами. "Естественность" включения
средств работы с БД в язык программирования означает, что
работа с долговременными (хранимыми во внешней БД) объектами
должна происходить на основе тех же синтаксических конструкций
(и с той же семантикой), что и работа со временными,
существующими только во время работы программы объектами.
Эта сторона ООБД наиболее близка родственному направлению
языков программирования БД [77]. Языки программирования ООБД и
БД во многих своих чертах различаются только терминологически;
существенным отличием является лишь поддержание в языках
первого класса подхода к наследованию классов. Кроме того,
языки второго класса, как правило, более развиты как в
отношении системы типов, так и в отношении управляющих
конструкций.
Другим аспектом языкового окружения ООБД является потребность
в языках запросов, которые можно было бы использовать в
интерактивном режиме. Если доступ к объектам внешней БД в
языках программирования ООБД носит в основном навигационный
характер, то для языков запросов более удобен декларативный
стиль. Декларативные языки запросов к ООБД менее развиты, чем
языки программирования ООБД, и при их реализации возникают
существенные проблемы. Ниже мы рассмотрим имеющиеся подходы и
их ограничения более подробно. Но начнем с языков
программирования ООБД.
К моменту написания данного обзора нам неизвестен какой-либо
язык программирования ООБД, который был бы спроектирован
целиком заново, начиная с нуля. Естественным подходом к
построению такого языка было использование (с необходимыми
расширениями) некоторого существующего
объектно-ориентированного языка. Начало расцвета направления
ООБД совпало с пиком популярности языка Smalltalk-80.
локальной сети рабочих станций; ORION-2 - полностью
распределенная объектно-ориентированная СУБД. Реализация всех
систем производилась с использованием языка Common Lisp на
рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС
Genera 7.0 и SUN-3 в среде ОС UNIX. Описание реализации
ORION-2 пока не опубликовано, поэтому мы рассмотрим только
ORION-1 и ORION-1SX.
Основными функциональными компонентами системы являются
подсистемы управления памятью, объектами и транзакциями. В
ORION-1 все компоненты, естественно, располагаются в одной
рабочей станции; в ORION-1SX - разнесены между разными
рабочими станциями (в частности, управление объектами
производится в рабочей станции-клиенте). Применение в
ORION-1SX для взаимодействия клиент-сервер механизма
удаленного вызова процедур позволило использовать в этой
системе практически без переделки многие модули ORION-1.
Сетевые взаимодействия основывались на стандартных средствах
операционных систем.
В число функций подсистемы управления памятью входит
распределение внешней памяти, перемещение страниц из буферов
оперативной памяти во внешнюю память и наоборот, поиск и
размещение объектов в буферах оперативной памяти (как принято
в объектно-ориентированных системах, поддерживаются два
представления объектов - дисковое и в оперативной памяти; при
перемещении объекта из буфера страниц в буфер объектов и
обратно представление объекта изменяется). Кроме того, эта
подсистема отвественна за поддержание вспомогательных
индексных структур, предназначенных для ускорения выполнения
запросов.
Подсистема управления объектами включает подкомпоненты
обработки запросов, управления схемой и версиями объектов.
Версии поддерживаются только для объектов, при создании
которых такая необходимость была явно указана. Для схемы БД
версии не поддерживаются; при изменении схемы отслеживается
влияние этого изменения на другие компоненты схемы и на
существуующие объекты. При обработке запросов используется
техника оптимизации, аналогичная применяемой в реляционных
системах (т.е. формируется набор возможных планов выполнения
запроса, оценивается стоимость каждого из них и выбирается для
выполнения наиболее дешевый) [102].
Подсистема управления транзакциями обеспечивает традиционную
сериализуемость транзакций, а также поддерживает средства
журнализации изменений и восстановления БД после сбоев. Для
сериализации транзакций применяется разновидность двухфазного
протокола синхронизационных захватов с различной степенью
гранулированности [103]. Конечно, при синхронизации
учитывается специфика ООБД, в частности, наличие иерархии
классов. Журнал изменений обеспечивает откаты индивидуальных
транзакций и восстановление БД после мягких сбоев (архивные
копии БД для восстановления после поломки дисков не
поддерживаются).
Проект O2 реализуется французской компанией Altair,
образованной специально для целей проектирования и реализации
объектно-ориентированной СУБД. Начало проекта датируется
сентябрем 1986 г., и он был расчитан на пять лет: три года на
прототипирование и два года на разработку промышленного
образца. Текущий прототип системы функционирует в режиме
клиент/сервер в локальной сети рабочих станций SUN c
соответствующим разделением функций между сервером и
клиентами.
Основными компонентами системы (не считая развитого набора
интерфейсных средств) являются интерпретатор запросов и
подсистемы управления схемой, объектами и дисками. Управление
дисками, т.е. поддержание базовой среды постоянного хранения
обеспечивает система WiSS [104], которую разработчики O2
перенесли в окружение ОС UNIX.
Наибольшую функциональную нагрузку несет компонент управления
объектами. В число функций этой подсистемы входит:
- управление сложными объектами, включая создание и
уничтожение объектов, выборку объектов по именам, поддержку
предопределенных методов, поддержку объектов со внутренней
структурой-множеством, списком и кортежем;
- управление передачей сообщений между объектами;
- управление транзакциями;
- управление коммуникационной средой (на базе транспортных
протоколов TCP/IP в локальной сети Ethernet);
- отслеживание долговременно хранимых объектов (напомним, что
в O2 объект хранится во внешней памяти до тех пор, пока
достижим из какого-либо долговременно хранимого объекта);
- управление буферами оперативной памяти (аналогично ORION,
представление объекта в оперативной памяти отличается от его
представления на диске);
- управление кластеризацией объектов во внешней памяти;
- управление индексами.
Несколько слов про управление транзакциями. Различаются
режимы, когда допускается параллельное выполнение транзакций,
изменяющих схему БД, и когда параллельно выполняются только
транзакции, изменяющие внутренность БД. Первый режим обычно
используется на стадии разработки БД, второй - на стадии
выполнения приложений. Средства восстановления БД после сбоев
и откатов транзакций также могут включаться и выключаться.
Наконец, поддерживается режим, при котором все постоянно
хранимые объекты загружаются в оперативную память при начале
транзакции для увеличения скорости работы прикладной системы.
Компонент управления схемой БД реализован над подсистемой
управления объектами: в системе поддерживаются несколько
невидимых для программистов классов и в том числе классы
"Class" и "Method", экземплярами которых являются,
соответственно, объекты, определяющие классы, и объекты,
определяющие методы. (Как видно, ситуация напоминает
реляционные системы, в которых тоже обычно поддерживаются
служебные отношения-каталоги, описывающие схему БД.) Удаление
класса, который не является листом иерархии классов или
используется в другом классе или сигнатуре какого-либо метода,
запрещено.
Даже приведенное краткое описание особенностей двух
объектно-ориентированных СУБД показывает прагматичность
современного подхода к организации таких систем. Их
разработчики не стремятся к полному соблюдению чистоты
объектно-ориентированного подхода и применяют наиболее простые
решения проблем, которые на самом деле еще не решены. Пока в
сообществе разработчиков объектно-ориентированных систем БД не
видно работы, которая могла бы сыграть в этом направлении
роль, аналогичную роли System R [105] по отношению к
реляционным системам. Правда, и проблемы ООБД гораздо более
сложны, чем решаемые в реляционных системах.
6. Проблемы выполнения и оптимизации запросов к ООБД
В этом разделе мы остановимся на проблемах выполнения запросов
к ООБД, сформулированных на каком-либо декларативном языке.
Каким бы не был этот язык, в конечном счете потребуется по
внешнему представлению запроса сформировать план его
выполнения, который минимизировал бы общие накладные расходы
системы, требующиеся для выполнения запроса. Другими словами,
до выполнения запроса необходимо выполнить его оптимизацию,
учитывая в общем случае необходимость обменов с внешней
памятью.
Публикации, касающиеся оптимизации запросов к ООБД,
практически отсутствуют. Это свидетельствует о недостаточной
развитости каких-либо оригинальных подходов.
Как мы видели на примерах конкретных систем в предыдущем
разделе, в них по сути дела применяется тот же подход к
оптимизации запросов, который использовался в реляционных
системах: формируется набор альтернативных планов, оценивается
стоимость каждого из них и выбирается план с наименьшей
стоимостью. (Подробный обзор современных методов оптимизации
запросов в реляционных СУБД и нерешенных проблем можно найти в
[106].) Возможность применения такого подхода в СУБД ORION и
O2 (да и в других) опирается на то, что объекты в этих
системах не полностью инкапсулированы. Наряду с методами, в
объектах видны и некоторые атрибуты, и если условие выборки
задано через эти атрибуты, оптимизатор запросов, которому
известны внутренняя структура объектов и набор существующих
индексов, получает возможность выбора. Если же условие выборки
можно формулировать только через методы, при подходах ORION и
O2 единственным возможным способом выборки объектов класса
будет последовательный просмотр всех объектов этого класса.
Здоник [7] отмечает, что основная проблема с оптимизацией
запросов к ООБД связана с расширяемостью набора типов в такой
БД. Каждый новый тип вводит собственную алгебру, неизвестную
оптимизатору запросов. Например, оптимизатор не имеет
информации о возможной коммутативности двух операций типа и
т.д. Здоник полагает, что возможному решению проблемы
оптимизации могло бы способствовать формальное определение
алгебраических свойств операций типа при его разработке.
Примерно такой подход применяется в оптимизаторах, основанных
на наборе правил, применяемых в расширяемых СУБД (например,
[107]).
Как кажется, из последних публикаций, затрагивающих проблемы
оптимизации запросов, наибольшее влияние на оптимизаторы
систем ООБД может оказать [108]. Эта работа не связана
непосредственно со спецификой ООБД, но преимущество
предлагаемого подхода связано как раз с максимальной
независимостью от особенностей организации БД. Предлагается не
оценивать план выполнения запроса, а учитывать реальную
стоимость уже использованного плана и на этой основе изменять
критерии выбора оптимизатора. Может быть, таким образом
удастся справиться с неизвестной оптимизатору алгеброй
определяемых пользователями типов.
По нашему мнению, если в системе для программирования методов
применяется язык достаточно высокого уровня (во всяком случае,
не Си), то при компиляции запроса могло бы производиться
частичное вычисление вызываемых в нем методов с последующим
преобразованием запроса к виду, когда условия определены на
атрибутах хранимых классов. После этого можно было производить
обычную оптимизацию запроса. Заметим, что это не было бы
нарушением инкапсуляции объектов, поскольку оптимизатор
является частью системы, для которой внутренняя организация
объектов БД открыта.
7. Особенности управления транзакциями в системах ООБД
Дела с управлением транзакциями в системах ООБД обстоят
примерно аналогично ситуации с оптимизацией запросов: как
правило, используются слегка модифицированные традиционные
методы сериализации транзакций, журнализации изменений
объектов, индивидуальных откатов транзакций и восстановления
состояния БД после сбоев. Фактически, как и в случае
оптимизации запросов, такое управление транзакциями
предполагает частичное нарушение инкапсуляции объектов:
синхронизация основывается на знании внутренней структуры
объектов, журнализация и восстановление - на знании природы
методов, изменяющих состояние объекта и т.д.
Какой-либо подход, в котором предлагался бы полный набор
средств управления транзакциями, полностью согласующийся с
парадигмой объектной ориентированностью, нам неизвестен. Одна
из наиболее продвинутых работ, проводимых в этом направлении в
рамках германского проекта VODAK, описывается в [93].
В основе управления транзакциями в системе VODAK находится
разработанный ранее в контексте инженерных СУБД механизм
транзакций со вложенными подтранзакциями [109]: вызов любого
действия в объекте равносилен образованию новой
подстранзакции. В отличие от традиционного механизма вложенных
подтранзакций в данном случае заранее не определена
максимальная вложенность транзакций. При синхронизации
транзакций используется знание о семантике объектов, в том
числе информация о коммутативности операций. (Аналогичный
подход описан в [110].)
Не очень понятно, как при таком подходе поступать с
журнализацией изменений. В принципе только сам объект знает,
какая информация может понадобиться для его восстановления, и
только сам объект может выполнить такое восстановление. Может
быть, следует применять технику темпоральных БД, и при каждом
изменении состояния объекта заводить его новую версию. В
общем, как нам представляется, проблема журнализации и
восстановления в ООБД пока остается открытой.
8. Связь ООБД с дедуктивными и активными базами данных
Связь направления ООБД с направлением дедуктивных БД носит
двоякий характер. Во-первых, для структуризации дедуктивных (и
вообще логических) БД в последнее время стремятся использовать
парадигму объектной ориентированности [83-84]. Это отдельная
тема, для ее рассмотрения было бы необходимо предварительное
введение в концепции дедуктивных БД, что находится за
пределами данного обзора.
Во-вторых, некоторые механизмы дедуктивных БД пытаются
использовать в контексте обычных (может быть, несколько
расширенных семантически) ООБД. Это прежде всего относится к
языкам запросов [82] (как мы отмечали в разд. 4, одно из
направлений развития декларативных языков запросов к ООБД -
дедуктивные языки). На логическом выводе основываются в ряде
проектов доказательство корректности схемы ООБД и динамический
контроль целостности [85-86]. Видимо, в будущих системах ООБД
логика будет играть еще большую роль.
Работы по интеграции объектно-ориентированных и активных БД
находятся в начальной стадии. Известно, что основной проблемой
систем активных БД является построение эффективного механизма
вычисления на основе поступающих событий условий и вызова при
необходимости соответствующих действий. В [42] описывается
экспериментальная работа, выполненная на базе
объектно-ориентированной СУБД PROBE, в которой активность ООБД
обеспечивается с помощью определения двух специальных классов
объектов "active-object" и "activelist-object". При
возникновении одного из предопределенных в системе событий
вызывается один из методов соответствующего объекта класса
"active-object", в котором в зависимости от состояния и
предписанного набора правил принимается решение о дальнейших
действиях. Основной вывод, который можно сделать на основании
изложенного в [42] материала, - это пригодность основных
средств типовой ООБД и для обеспечения ее активности.
9. Заключение
В этом обзоре мы рассмотрели (очень кратко) далеко не все
вопросы, связанные с ООБД. Совсем не были рассмотрены проблемы
проектирования ООБД и вообще объектно-ориентированного
проектирования БД [59], вопросы поддержания разнородной
(multi-media) информации в ООБД [12], подходы к интеграции
неоднородных БД на основе объектно-ориентированного подхода
[87-88], проблемы поддержания различных представлений ООБД
[89] и т.д.
Мы стремились показать общее состояние дел (насколько это
возможно в таком кратком обзоре) в наиболее важных областях,
связанных с управлением ООБД. По нашему мнению, практически во
всех этих областях имеется масса нерешенных проблем, и
потребность в развитых объектно-ориентированных СУБД
стимулирует решение этих проблем.
Литература:
1. Mattbew Rapaport. Object-Oriented Data Bases: The Next Step
in DBMS Evolution // Comp. Lang.- 5, N 10.- 1988.- 91-98
2. Michael Stonebraker. Future Trends in Database Systems //
IEEE Trans. Knowledge and Data Eng.- 1, N 1.- 1989.- 33-44
3. Oscar Nierstrasz. A Survey of Object-Oriented Concepts //
In Object-Oriented Concepts, Databases and Applications, ed.
W. Kim, F. Lochovski, ACM Press and Addison-Wesley, 1989.-
3-21
4. M. A. Garvey, M. S. Jackson. Introduction to
Object-Oriented Databases // Inf. and Software Technol.- 31, N
10.- 1989.- 521-528
5. Fereidoon Sadri. Object-Oriented Database Systems //
COMPSAC'89 13th Annu. Int. Comput. Software and Appl. Conf.,
Orlando, Fla, Sept. 20-22, 1989.- 195-196
6. Stanley Y. W. Su. Extensions to the Object-Oriented
Paradigm // COMPSAC'89 13th Annu. Int. Comput. Software and
Appl. Conf., Orlando, Fla, Sept. 20-22, 1989.- 197-199
7. Stanley Zdonik. Directions in Object-Oriented Databases //
COMPSAC'89 13th Annu. Int. Comput. Software and Appl. Conf.,
Orlando, Fla, Sept. 20-22, 1989.- 200
8. Malkolm Atkinson, Francois Bansilhon, David DeWitt, Klaus
Dittrich, David Maier, Stanley Zdonik. The Object-Oriented
Database System Manifesto // 1st Int. Conf. Deductive and
Object-Oriented Databases, Kyoto, Japan, Dec. 4-6, 1989
9. The Committee for Advanced DBMS Function (Michael
Stonebraker, Bruce Lindsay, Jim Gray, Make Carey, David
Beech). Third Generation Data Base System Manifesto // Proc.
ACM SIGMOD Int. Conf. Manag. Data, Atlanta City, NJ, USA, May
23-25, 1990, ACM SIGMOD Record.- 19, N 2.- 1990.- 34-43
10. R. P. van de Riet. Introduction to the Special Issue on
Deductive and Object-Oriented Databases // Data and Knowledge
Eng.- 5.- 1990.- 255-261
11. Won Kim. Object-Oriented Databases: Definition and
Research Directions // IEEE Trans. Data and Knowledge Eng.- 2,
N 3.- 1990.- 327-341
12. D. Woelk, W. Kim. Multimedia Information Management in a
Object-Oriented Database System // 13th Int. Conf. Very Large
Data Bases, Brighton, England, Sept. 1-4, 1987.- 319-330
13. Won Kim, Nat Ballou, Hong-Tai Chou, Jorge F. Garza,
Darrell Woelk. Integrating an Object-Oriented Programming
System with a Database System // Proc. OOPCLA'88, San Diego,
Calif., USA, Sept. 25-30, 1988.- 142-152
14. Kyung-Chang Kim, Won Kim, Darrell Woelk. Acyclic Query
Processing in Object-Oriented Databases // Entity-Relationship
Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,
1988.- 329-346
15. Elisa Bertino, Won Kim. Indexing Techniques for Queries on
Nested Objects // IEEE Trans. Knowledge and Data Eng.- 1, N
2.- 1989.- 196-214
16. B. Paul Jenq, Darrell Woelk, Won Kim, Wan-Lik Lee. Query
Processing in Distributed ORION // Advances in Database
Technology - EDBT'90.- Lecture Notes in Computer Science.-
416, 1990.- 169-187
17. Won Kim, Jorge F. Garza, Nathaniel Ballou, Darrell Woelk.
Architecture of the ORION Next-Generation Database System //
IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 109-124
18. D. H. Fishman. An Overview of the Iris Object-Oriented
DBMS // Digest of papers, 33rd CompCon, Spring 1988, Feb. 29 -
Mar. 4, USA.- 177-180
19. Peter Lyngbaek, Kevin Wilkinson, Waqar Hasan. The Iris
Kernel Architecture // Advances in Database Technology -
EDBT'90.- Lecture Notes in Computer Science.- 416, 1990.-
348-362
20. Kevin Wilkinson, Peter Lyngbaek, Waqar Hasan. The Iris
Architecture and Implementation // IEEE Trans. Knowledge and
Data Eng.- 2, N 1.- 1990.- 63-75
21. David Maier, Jacob Stein, Allen Otis, Alan Purdy.
Development of an Object-Oriented DBMS // Proc. OOPCLA'86,
Portland, Oreg., USA, Sept. 29 - Oct. 2, 1986.- 472-482
22. D. Jacob Penney, Jacob Stein. Class Modification in the
GemStone Object-Oriented DBMS // Proc. OOPCLA'87, Orlando,
Fla, USA, Oct. 4-8, 1987.- 111-117
23. Won Kim, Jay Banerjee, Hong-Tai Chou, Jorge F. Garca,
Darrell Woelk. Composite Object Support in an Object-Oriented
Database System GemStone Object-Oriented DBMS // Proc.
OOPCLA'87, Orlando, Fla, USA, Oct. 4-8, 1987.- 118-125
24. Tomothy Andrews, Craig Harris. Combining Language and
Database Advances in an Object-Oriented Development
Environment GemStone Object-Oriented DBMS // Proc. OOPCLA'87,
Orlando, Fla, USA, Oct. 4-8, 1987.- 430-440
25. Michael Stonebraker, Jeff Anton, Eric Hanson. Extending a
Database System with Procedures // ACM Trans. Database Syst.-
12, N 3.- 1987.- 350-376
26. L. Rowe, M. Stonebraker. The POSTGRES Data Model // 13th
Int. Conf. Very Large Data Bases, Brighton, England, Sept.
1-4, 1987.- 83-96
27. M. Stonebraker. The Design of the POSTGRES Storage System
// 13th Int. Conf. Very Large Data Bases, Brighton, England,
Sept. 1-4, 1987.- 289-300
28. Michael Stonebraker, Lawrence A. Rowe, Machael Hirohama.
The Implementation of POSTGRES // IEEE Trans. Knowlwdge and
Data End.- 2, N 1.- 1990.- 125-141
29. Christophe Lecluse, Philippe Richard, Fernando Velez. O2,
an Object-Oriented Data Model // Proc.
ACM SIGMOD Int. Conf.
Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD
Record.- 17, N 3.- 1988.- 424-433
30. F. Velez, G. Bernard, V. Darnis. The O2 Object Manager: An
Overview // 15th Int. Conf. Very Large Data Bases, Amsterdam,
Aug. 22-25, 1989.- 357-366
31. C. Lecluse, P. Richard. The O2 Database Programming
Language // 15th Int. Conf. Very Large Data Bases, Amsterdam,
Aug. 22-25, 1989.- 411-422
32. O. Deux et al. The Story of O2 // IEEE Trans. Knowledge
and Data Eng.- 2, N 1.- 1990.- 91-108
33. O. Niestrasz, D. Tsichritzis. An Object-Oriented
Environment for OIS Applications // 11th Int. Conf. Very Large
Data Bases, Stockholm, Aug. 21-23, 1985.- 83-96
34. D. Decouchart. Design of a Distributed Object Manager for
the Smalltalk-80 System // Proc. OOPCLA'86, Portland, Oreg.,
USA, Sept. 29 - Oct. 2, 1986.- 444-452
35. Karen E. Smith, Stanley B. Zdonik. Intermedia: A Case
Study of the Differences Between Relational and
Object-Oriented Database Systems // Proc. OOPCLA'87, Orlando,
Fla, USA, Oct. 4-8, 1987.- 452-465
36. Andrew Straw, Fred Mellender, Steve Riegel. Object
Management in a Persistent Smalltalk System // Software Pract.
and Exper.- 19, N 8.- 1989.- 719-737
37. Nick Roussopoulus, Hyun Soon Kim. ROOST: A Relational
Object-Oriented System // Lect. Notes Comput. Sci.- 367.-
1989.- 404-420
38. T. F. Keefe, W. T. Tsai, M. B. Thuraisingham. SODA: A
Secure Object-Oriented Database System // Computers and
Security.- 8, N 6.- 1989.- 517-533
39. Prasun Dewan, Ashish Vikram, Bharat Bhargava. Engineering
the Object-Oriented Database Model in O-Raid // Lect. Notes
Comput. Sci.- 367.- 1989.- 389-403
40. Scott E. Hudson, Roger King. Cactis: A Self-Adaptive,
Concurrent Implementation of an Object-Oriented Database
Management System // ACM Trans. Database Syst.- 14, N 3.-
1989.- 291-321
41. Gilles Barbedette. LISPO2: A Persistent Object-Oriented
LISP // Advances in Database Technology - EDBT'90.- Lecture
Notes in Computer Science.- 416, 1990.- 332-347
42. Sharma Chakravarthy, Susan Nesson. Making an
Object-Oriented DBMS Active: Design, Implementation, and
Evaluation of a Prorotype. // Advances in Database Technology
- EDBT'90.- Lecture Notes in Computer Science.- 416, 1990.-
393-406
43. R. Agrawal, N. H. Gehani, J. Srinivasan. OdeView: The
Graphical Interface to Ode // Proc. ACM SIGMOD Int. Conf.
Manag. Data, Atlanta City, NJ, USA, May 23-25, 1990, ACM
SIGMOD Record.- 19, N 2.- 1990.- 34-43
44. Stefano Ceri, Stafano Crespi-Reghizzi, Roberto Zicari,
Gianfranco Lamperti, Luigi A. Lavazza. Algres: An Advanced
Database System for Complex Applications // IEEE Software.- 7,
N 4.- 1990.- 68-78
45. Michael L. Nelson, J. Michael Moshell, Ali Orooji. A
Relational Object-Oriented Management System // 9th Annu. Int.
Phoenix Conf. Comput. and Commun.- Scottsdale, Aris., USA,
March 21-23, 1990.- 319-323
46. Stefan Bottcher. Attribute Inheritance Implemented on Top
of a Relational Database System // 6th Int. Conf. Data Eng.,
Los Angeles, Calif., USA, Febr. 5-9, 1990.- 503-509
47. Simon Gibbs, Vassilis Prevelakis. Xos: An Overview // In
Object Management, Ed. D. Tsichritzis, Centre Universitaire
d'Informatique, Universite de Geneve, 1990.- 37-61
48. M.J. Carey, D.J. DeWitt et al. Object and File Management
in the EXODUS Extensible Database System // 12th Int. Conf.
Very Large Data Bases, Kuoto, Japan, Aug. 1986.- 91-100
49. D. S. Batory, J. R. Barnett, J. F. Garza, K. P. Smith, K.
Tsukuda, T. E. Wise. GENESIS: An Extensible Database
Management System // // IEEE Trans. on Software Eng.- 14, N
11.- 1988.- 1711-1730
50. Hans-Joerg Schek, Heinz-Bernhard Paul, Marc H. Scholl,
Gerhard Weikum. The DASDBS Project: Objectives, Experiences,
and Future Prospects // IEEE Trans. Knowledge and Data Eng.-
2, N 1.- 1990.- 25-43
51. Laura M. Haas, Walter Chang, Guy M. Lohman et al.
Starburst Mid-Flight: As the Dust Clears // IEEE Trans.
Knowledge and Data Eng.- 2, N 1.- 1990.- 143-159
52. Raymond Lorie, Won Kim, Dan McNabb, Wil Plouffe.
Supporting Complex Objects in a Relational System for
Engineering Databases // In Query Processing in Database
Systems, ed. Won Kim, David S. Reiner, Dan. S. Batory,
Springer-Verlag, 1985.- 145-155
53. Raymond A. Lorie, Jean-Jacques P. Daudenarde. On Extending
the Realm of Application of Relational Systems // In
Information Processing 86, ed. H.-J. Kugler, Elsevir Science
Publishers, 1986.- 889-894
54. Won Kim, Hong-Tai Chou, Jay Banerjee. Operations and
Implementation of Complex Objects // IEEE Trans. on Software
Eng.- 14, N 7.- 1988.- 985-996
55. Mohammad A. Ketabchi, Valdis Berzins. Mathematical Model
of Composite Objects and Its Application for Organizing
Engineering Databases // IEEE Trans. on Software Eng.- 14, N
1.- 1988.- 71-84
56. Anant Jhingran, Michael Stonebraker. Alternatives in
Complex Object Representation: A Performance Persrective //
6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9,
1990.- 94-102
57. Serge Abiteboul, Richard Hull. IFO: A Formal Semantic
Database Model // ACM Trans. Database Syst.- 12, N 4.- 1987.-
525-565
58. Joan Peckham, Fred Maryanski. Semantic Data Models // ACM
Comp. Surv.- 20, N 3.- 1988.- 153-189
59. Shamkant B. Navathe, Mohan K. Pillalamarri. OOER: Toward
Making the E-R Approach Object-Oriented // Entity-Relationship
Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,
1988.- 185-206
60. Craig Damon, Gordon Landis. Abstract Types and Storage
Types in an OO-DBMS // Digest of papers, 33rd CompCon, Spring
1988, Feb. 29 - Mar. 4, USA.- 172-176
61. Richard Hull, Katsumi Tanaka, Masatoshi Yoshikawa.
Behavior Analysis of Object-Oriented Databases: Method
Structure, Execution Trees, and Reachibility // Lect.
Notes
Comput. Sci.- 367.- 1989.- 372-388
62. Mojtaba Mozaffari, Yuzuri Tanaka. ODM: An Object-Oriented
Data Model // New. Generat. Comp.- 7, N 1.- 1989.- 4-35
63. Catriel Beeri. A Formal Approach to Object-Oriented
Databases // Data and Knowledge Eng.- 5.- 1990.- 353-382
64. Roberto Zicari. Incomplete Information in Object-Oriented
Databases // ACM SIGMOD Record.- 19, N 3.- 1990.- 5-16
65. Shuguang Hong, Fred Maryanski. Using a Meta Model to
Represent Object-Oriented Data Models // 6th Int. Conf. Data
Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 11-19
66. A. Cornelio, Shamkant B. Navathe, Keith L. Doty. Extending
Object-Oriented Concepts to Support Engineering Applications
// 6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr.
5-9, 1990.- 220-227
67. Gunter Saake. Descriptive Specification of Database Object
Behaviour // Data and Knowledge Eng.- 6, N 1. 1991.- 47-73
68. S. K. Lellani, N. Spiratos. Towards a Categorical Data
Model Supporting Structured Objects and Inheritance // Proc.
1st Int. East/West Database Workshop, Kiev, Oct. 1990, Lect.
Notes Comput. Sci.- 540.- 1991
69. Michael Caruso, Edward Sciore. Meta-Functions and Contexts
in an Object-Oriented Database Language // Proc. ACM SIGMOD
Int. Conf. Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM
SIGMOD Record.- 17, N 3.- 1988.- 56-65
70. Francois Bancilhon. Query Languages for Object-Oriented
Database Systems: Analysis and Proposal // Datanbanksyst.
Buro, Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3,
1989.- 1-18
71. W. Kim. A Model of Queries for Object-Oriented Databases
// 15th Int. Conf. Very Large Data Bases, Amsterdam, Aug.
22-25, 1989.- 423-432
72. A. M. Alashqur, S. Y. W. Su, H. Lam. OQL: A Query Language
for Manipulating Object-Oriented Databases // 15th Int. Conf.
Very Large Data Bases, Amsterdam, Aug. 22-25, 1989.- 433-442
73. E. Laenens, F. Staes, D.
Vermeir. Browsing a la carte in
Object-oriented Databases // Computer J.- 32, N 4.- 1989.-
333-340
74. Sophie Cluet, Claude Delobel, Christophe Lecluse, Philippe
Richard. RELOOP: An Algebra Based Query Language for an
Object-Oriented Database System // Data and Knowledge Eng.-
5.- 1990.- 333-352
75. Simon Gibbs. Querying Large Class Collections // In Object
Management, ed. D. Tsichritzis, Centre Universitaire
d'Informatique, Universite de Geneve, 1990.- 63-77
76. Gail M. Shaw, Stanley B. Zdonik. A Query Algebra for
Object-Oriented Databases // 6th Int. Conf. Data Eng., Los
Angeles, Calif., USA, Febr. 5-9, 1990.- 154-162
77. А. В. Замулин. Системы программирования баз данных и
знаний // Новосибирск: Наука, 1990.- 352 с.
78. Andrea H. Skarra, Stanley B. Zdonik. The Management of
Changing Types in an Object-Oriented Database // Proc.
OOPCLA'86, Portland, USA, Sept. 29 - Oct. 2, 1986.- 483-495
79. J. Banerjee, W. Kim, H.-J. Kim, H. F. Korth. Semantics and
Implementation of Schema Evolution in Object-Oriented Database
// Proc. ACM SIGMOD 1987 Annu. Conf., San Francisco, Calif.,
USA, May 27-29, 1987.- 311-322
80. W. Kim, H. Chou. Versions of Schema for Object-Oriented
Databases // 14th Int. Conf. Very Large Data Bases, Los
Angeles, USA, Aug. 29 - Sept. 1, 1988.- 148-159
81. David Beech. Intensional Concepts in an Object Database
Model // Proc. OOPCLA'88, San Diego, Calif., USA, Sept. 25-30,
1988.- 164-175
82. Serge Abiteboul. Towards a Deductive Object-Oriented
Database Language // Data and Knowledge Eng.- 5.- 1990.-
263-287
83. Kyuchul Lee, Sukho Lee. An Object-Oriented Approach to
Data/Knowledge Modelling Based on Logic // 6th Int. Conf. Data
Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 289-294
84. A. M. Alashqur, S. Y. W. Su, H. Lam. A Rule-based Language
for Deductive Object-Oriented Databases // 6th Int. Conf. Data
Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 58-67
85. Lois M. L. Delcambre, Karen C. Davis. Automatic Validation
of Object-Oriented Database Structures // 5th Int. Conf. Data
Eng., Los Angeles, Calif., USA, Febr. 6-10, 1989.- 2-9
86. Susan Darling Urban, Lois M. L. Delcambre. Constraint
Analysis for Specifying of Class Objects // 5th Int. Conf.
Data Eng., Los Angeles, Calif., USA, Febr. 6-10, 1989.- 10-17
87. Kyu-Young Whang. A Seamless Integration in Object-Oriented
Database Systems // 5th Int. Conf. Data Eng., Los Angeles,
Calif., USA, Febr. 6-10, 1989.- 675-676
88. M. Kaul, K. Drosten, E. J. Neuhold. ViewSystem:
Integrating Heterogeneous Information Bases by Object-Oriented
Views // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA,
Febr. 5-9, 1990.- 2-10
89. Sandra Heiler, Stanley Zdonic. Object Views: Extending the
Vision // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA,
Febr. 5-9, 1990.- 84-93
90. Jorge F. Garza, Won Kim. Transaction Management in an
Object-Oriented Database System // Proc. ACM SIGMOD Int. Conf.
Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD
Record.- 17, N 3.- 1988.- 37-45
91. M. A. Rauft, S. Rehm, K. R. Dittrich. How to Share Work on
Shared Objects in Design Databases // 6th Int. Conf. Data
Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 575-583
92. Michele Cart, Jean Ferrie. Integrating Concurrency Control
into an Object-Oriented Database System // Advances in
Database Technology - EDBT'90.- Lecture Notes in Computer
Science.- 416, 1990.- 363-377
93. Thomas C. Rakow, Junzhong Gu, Erich J. Neuhold.
Serializability in Object-Oriented Database Systems // 6th
Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9,
1990.- 112-120
94. Kyung-Chang Kim. Parallelism in Object-Oriented Query
Processing // 6th Int. Conf. Data Eng., Los Angeles, Calif.,
USA, Febr. 5-9, 1990.- 209-217
95. Sushit Jajodia, Boris Kogan. Integrating an
Object-Oriented Data Model with Multilevel Security // IEEE
Symp. Res. Secur. and Privacy, Oacland, Calif., USA, May 7-9,
1990.- 76-85
96. IEEE Database Engineering, special issue on
Object-Oriented Databases, F. Lochovski, ed., Dec. 1985
97. B. Stroustrup. The C++ Programming Language //
Addison-Wesley, Reading, Mass., 1986
98. E. F. Codd. A Relational Model of Data for Large Shared
Data Banks // Commun. ACM.- 26, N 1.- 1970.- 377-387
99. D. Maier. Why isn't there an Object-Oriented Data Model?
// Technical Report, Oregon Graduate Center, May 1989
100. D. D. Chamberlin, R. F. Boyce. SEQUEL: A Structured
English Query Language // ACM SIGMOD Workshop Data Descr.,
Access, Contr., Ann Arbol, Mich., USA, May 1974.- 249-264
101. M. Kifer, G. Lausen. F-Logic: A Higher-Order Language for
Reasoning about Objects, Inheritance, and Scheme // Proc. ACM
SIGMOD Int. Conf. Manag. Data, Portland, Oreg., USA, 1989, ACM
SIGMOD Record.- 18, N 2.- 1989.- 134-146
102. P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A.
Lorie, T. G. Price. Access Path Selection in a Relational
Database Management System // Proc. ACM SIGMOD Int. Conf.
Manag. Data, Boston, Mass., USA, May 30 - Jun. 1, 1979.- 23-34
103. Gray J.N., Lorie R.A., Putzolu G.R., Traiger I.L.
Granularity of Locks in a Large Shared Data Base // 1st Int.
Conf. Very Large Data Bases, Framingham, Mass., Sept. 1975.-
C.428-451
104. H.-T. Chou, D. J. DeWitt, R. H. Katz, A. C. Klug. Design
and Implementation of the Wisconsin Storage System // Software
Pract. Exper.- 15, N 10.- 1985.- 943-962
105. D. D. Chamberlin, M. M. Astrahan et al. A History and
Evaluation of System R // Commun. ACM.- 24, N 10.- 1982.-
632-646
106. С. Д. Кузнецов. Методы оптимизации выполнения запросов в
реляционных СУБД // "Вычислительные науки. Т.1 (Итоги науки и
техники ВИНИТИ АН СССР)". М., ВИНИТИ АН СССР, 1989.- 76-153
107. J. C. Freytag. A Rule-Based View of Query Optimization //
Proc. ACM SIGMOD Int. Conf. Manag. Data, San Francisco,
Calif., USA, May 27-29, 1987.- 173-180
108. F. W. M. Tompa, J. I. Icaza. Adaptive Selection of Query
Execution Strategies by Learning Automata // Inf. Sci. (USA).-
50, N 3.- 1990.- 219-240
109. F. Bancilhon, W. Kim, H. Korth. A Model for CAD
Transactions // 11th Int. Conf. Very Large Data Bases,
Stockholm, Aug. 21-23, 1985.- 25-33
110. Alan Fekete, Nancy Lynch, Machael Merritt, William Weihl.
Commutativity-Based Locking for Nested Transactions // 6th ACM
Symp. Princ. Database Syst., San Diego, Calif, USA, March
25-27, 1987, J. Comput. and Syst. Sci.- 41, N 1.- 1990.-
65-156
