|
22.5. Примеры
объектно-ориентированных СУБД
В настоящее время ведется очень
много экспериментальных и
производственных работ в области
объектно-ориентированных СУБД.
Больше всего университетских
работ, которые в основном носят
исследовательский характер. Но уже
несколько лет назад отмечалось
существование по меньшей мере
тринадцати коммерчески доступных
систем ООБД. Среди них уже
упоминавшиеся в нашем обзоре
системы O2, ORION, GemStone и Iris.
Рассмотрим особенности
организации двух из них - ORION и O2.
Проект ORION осуществлялся с 1985 по
1989 г. фирмой MCC под руководством
известного еще по работам в проекте
System R Вона Кима. Под названием ORION на
самом деле скрывается семейство
трех СУБД: ORION-1 -
однопользовательская система;
ORION-1SX, предназначенная для
использования в качестве сервера в
локальной сети рабочих станций;
ORION-2 - полностью распределенная
объектно-ориентированная СУБД.
Реализация всех систем
производилась с использованием
языка Common Lisp на рабочих станциях (и
их локальных сетях) Symbolics 3600 с ОС Genera
7.0 и SUN-3 в среде ОС UNIX.
Основными функциональными
компонентами системы являются
подсистемы управления памятью,
объектами и транзакциями. В ORION-1 все
компоненты, естественно,
располагаются на одной рабочей
станции; в ORION-1SX - разнесены между
разными рабочими станциями (в
частности, управление объектами
производится на рабочей
станции-клиенте). Применение в ORION-1SX
для взаимодействия клиент-сервер
механизма удаленного вызова
процедур позволило использовать в
этой системе практически без
переделки многие модули ORION-1.
Сетевые взаимодействия
основывались на стандартных
средствах операционных систем.
В число функций подсистемы
управления памятью входит
распределение внешней памяти,
перемещение страниц из буферов
оперативной памяти во внешнюю
память и наоборот, поиск и
размещение объектов в буферах
оперативной памяти (как принято в
объектно-ориентированных системах,
поддерживаются два представления
объектов - дисковое и в оперативной
памяти; при перемещении объекта из
буфера страниц в буфер объектов и
обратно представление объекта
изменяется). Кроме того, эта
подсистема ответственна за
поддержание вспомогательных
индексных структур,
предназначенных для ускорения
выполнения запросов.
Подсистема управления объектами
включает подкомпоненты обработки
запросов, управления схемой и
версиями объектов. Версии
поддерживаются только для
объектов, при создании которых
такая необходимость была явно
указана. Для схемы БД версии не
поддерживаются; при изменении
схемы отслеживается влияние этого
изменения на другие компоненты
схемы и на существующие объекты.
При обработке запросов
используется техника оптимизации,
аналогичная применяемой в
реляционных системах (т.е.
формируется набор возможных планов
выполнения запроса, оценивается
стоимость каждого из них и
выбирается для выполнения наиболее
дешевый).
Подсистема управления
транзакциями обеспечивает
традиционную сериализуемость
транзакций, а также поддерживает
средства журнализации изменений и
восстановления БД после сбоев. Для
сериализации транзакций
применяется разновидность
двухфазного протокола
синхронизационных захватов с
различной степенью
гранулированности. Конечно, при
синхронизации учитывается
специфика ООБД, в частности,
наличие иерархии классов. Журнал
изменений обеспечивает откаты
индивидуальных транзакций и
восстановление БД после мягких
сбоев (архивные копии БД для
восстановления после поломки
дисков не поддерживаются).
Проект O2 выполнялся французской
компанией Altair, образованной
специально для целей
проектирования и реализации
объектно-ориентированной СУБД.
Начало проекта датируется
сентябрем 1986 г., и он был рассчитан
на пять лет: три года на
прототипирование и два года на
разработку промышленного образца.
После успешного завершения проекта
для сопровождения системы и ее
дальнейшего развития была
организована новая чисто
коммерческая компания O2.
Прототип системы функционировал
в режиме клиент/сервер в локальной
сети рабочих станций SUN c
соответствующим разделением
функций между сервером и клиентами.
Основными компонентами системы
(не считая развитого набора
интерфейсных средств) являются
интерпретатор запросов и
подсистемы управления схемой,
объектами и дисками. Управление
дисками, т.е. поддержание базовой
среды постоянного хранения
обеспечивает система WiSS, которую
разработчики O2 перенесли в
окружение ОС UNIX.
Наибольшую функциональную
нагрузку несет компонент
управления объектами. В число
функций этой подсистемы входят:
- управление сложными объектами,
включая создание и уничтожение
объектов, выборку объектов по
именам, поддержку
предопределенных методов,
поддержку объектов со
внутренней
структурой-множеством, списком
и кортежем;
- управление передачей
сообщений между объектами;
- управление транзакциями;
- управление коммуникационной
средой (на базе транспортных
протоколов TCP/IP в локальной
сети Ethernet);
- отслеживание долговременно
хранимых объектов (напомним,
что в O2 объект хранится во
внешней памяти до тех пор, пока
достижим из какого-либо
долговременно хранимого
объекта);
- управление буферами
оперативной памяти (аналогично
ORION, представление объекта в
оперативной памяти отличается
от его представления на диске);
- управление кластеризацией
объектов во внешней памяти;
- управление индексами.
Несколько слов про управление
транзакциями. Различаются режимы,
когда допускается параллельное
выполнение транзакций, изменяющих
схему БД, и когда параллельно
выполняются только транзакции,
изменяющие внутренность БД. Первый
режим обычно используется на
стадии разработки БД, второй - на
стадии выполнения приложений.
Средства восстановления БД после
сбоев и откатов транзакций также
могут включаться и выключаться.
Наконец, поддерживается режим, при
котором все постоянно хранимые
объекты загружаются в оперативную
память при начале транзакции для
увеличения скорости работы
прикладной системы.
Компонент управления схемой БД
реализован над подсистемой
управления объектами: в системе
поддерживаются несколько
невидимых для программистов
классов и в том числе классы
"Class" и "Method", экземплярами
которых являются, соответственно,
объекты, определяющие классы, и
объекты, определяющие методы. (Как
видно, ситуация напоминает
реляционные системы, в которых тоже
обычно поддерживаются служебные
отношения-каталоги, описывающие
схему БД.) Удаление класса, который
не является листом иерархии
классов или используется в другом
классе или сигнатуре какого-либо
метода, запрещено.
Даже приведенное краткое
описание особенностей двух
объектно-ориентированных СУБД
показывает прагматичность
современного подхода к организации
таких систем. Их разработчики не
стремятся к полному соблюдению
чистоты объектно-ориентированного
подхода и применяют наиболее
простые решения проблем. Пока в
сообществе разработчиков
объектно-ориентированных систем БД
не видно работы, которая могла бы
сыграть в этом направлении роль,
аналогичную роли System R по отношению
к реляционным системам. Правда и
проблемы ООБД гораздо более сложны,
чем решаемые в реляционных
системах.
Предыдущая
глава || Оглавление
|| Следующая глава
| 
