Объектно-ориентированные СУБД

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

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

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

 

2.5.2. Проект O2

 

 Проект O2 выполнялся французской компанией  Altair, образованной специально для  целей проектирования и реализации объектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был рассчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. После успешного завершения проекта для сопровождения системы и ее дальнейшего развития была организована новая чисто коммерческая компания O2.

 Прототип  системы функционировал в режиме  клиент/сервер в локальной сети  рабочих станций SUN c соответствующим  разделением функций между сервером  и клиентами.

 Основными  компонентами системы (не считая  развитого набора интерфейсных  средств) являются интерпретатор  запросов и подсистемы управления  схемой, объектами и дисками. Управление  дисками, т.е. поддержание базовой  среды постоянного хранения обеспечивает система WiSS, которую разработчики O2 перенесли в окружение ОС UNIX.

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

управление  сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;

управление  передачей сообщений между объектами;

управление  транзакциями;

управление  коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

отслеживание  долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней  памяти до тех пор, пока достижим из какого-либо долговременно хранимого  объекта);

управление буферами оперативной памяти (аналогично ORION, представление объекта в оперативной памяти отличается от его представления на диске);

управление  кластеризацией объектов во внешней  памяти;

управление  индексами.

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

 

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

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

 

3. Языки программирования и языки запросов объектно-ориентированных СУБД

 

1. Языки программирования объектно-ориентированных баз данных

 

 

 

 

Рис.2.  Современный  рынок СУБД

 

Список современных  коммерческих объектно-ориентированных  систем включает в

себя следующие продукты:

-  Objectivity/DB компании Objectivity, Inc. (последняя версия – 2.1) идеально, по заявлениям фирмы, подходит для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, а также нуждаются в высокой производительности и работы с большими объемами данных. Вероятно, все компании, производящие ООСУБД, ставят своей целью сложить такое впечатление относительно собственных разработок у читателей распространяемых ими документов (хотя некоторые и делают это в более деликатной форме). Более содержательно, Objectivity обеспечила интеграцию инструментария СУБД и разработки приложений с такими средствами программирования, как SoftBench и C++ SoftBench. Благодаря интегрированному

графическому интерфейсу разработки схемы БД и инструментам отладки и анализа

упрощается задание модели базы данных и, соответственно, разработки приложений

для Objectivity/DB.

-  СУБД GemStone корпорации GemStone Systems, Inc. известна в последней редакции под номером 5.0. GemStone традиционно сосредоточена на рынке Smalltalk (хотя не так давно и была выпущена версия для С++) и имеет заказчиков, способных продемонстрировать на производстве крупномасштабные, целевые применения ее продуктов. К сожалению, списком этих заказчиков объем информации, которую компания хочет донести до интересующихся (WWW), ограничивается.

-  ONTOS Corp., разработчик  СУБД ONTOS (кто бы подумал), по традиции  занимается развитием сервера  объектно-ориентированной СУБД, но  в последнее время придает  особое значение своим Службам  Интеграции Объектов (Object Integration Services).

- Построенная на основе  реляционной СУБД AllBase, система OpenODB  фирмы Hewlett-Packard также, как и  Objectivity/DB, интегрирована с системой SoftBench и существует в версии  для С++. Благодаря глубокой  интеграции, SoftBench распознает файлы приложений OpenODB для установки оптимальной конфигурации, может создавать базы данных формата OpenODB из своей

интегрированной среды, обеспечивает оперативную помощь из среды разработки и т. д.

- Object Design Inc. со своей СУБД ObjectStore занимает лидирующее положение в отрасли, осуществляя около 33% поставок на рынке объектно-ориентированных СУБД и последняя модернизация системы (клиент языка SQL и шлюз к реляционной СУБД) должны только укрепить положение фирмы. Object Design поддерживает версии своей СУБД как для С++, так и для Smalltalk.

- Versant Object Technology, Inc. (СУБД Versant) проводит двойную стратегию, предлагая средство обеспечения объектно-ориентированной СУБД высокого класса для телекоммуникаций и инструментальные средства Smalltalk для более общих случаев разработки приложений. Используя разработанный фирмой интерфейс VERSANT Smalltalk Language Interface, СУБД совместима как с версией языка Smalltalk компании ParcPlace-Digitalk, так и с Visual Age for Smalltalk корпорации IBM.

-  СУБД UniSQL компании UniSQL Inc. – хорошо устоявшаяся система, позволяющая пользователям осуществлять запросы и модификацию базы при

помощи разработанного компанией языка SQL/X (подобные языки, носящие условное название Object SQL, разработаны  и некоторыми другими поставщиками). Вся БД UniSQL может состоять одновременно из связей в локальных РСУБД и классов в локальных объектных базах UniSQL. Благодаря механизму каталогов, СУБД передает запросы и модификации данных в локальные базы данных и, обработав (перевод в другой формат, группирование, сортировка и т. д.) полученный от них результат, возвращает его пользователю.

Кроме того ООСУБД предлагают: Object Database, Inc. (Object Database), Itasca

Systems  Inc. (Itasca) O2 Technology (O2) и некоторые другие компании.

 

2. Языки запросов объектно-ориентированных баз данных

 

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

 

3.2.1. Явная навигация  как следствие преодоления потери  соответствия

 

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

 

3.2.2. Ненавигационные  языки запросов

 

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

 

 Второй подход основывается  на построении полного логического  объектно-ориентированного исчисления. По поводу построения такого  исчисления имеются теоретические работы, но законченный и практически реализованный язык запросов нам неизвестен. Видимо к этому же направлению строго теоретически обоснованных языков запросов можно отнести и работы, основанные на алгебраической теории категорий.

 

 Наконец, третий подход основывается на применении дедуктивного подхода. В основном это отражает стремление разработчиков к сближению направлений дедуктивных и объектно-ориентированных БД.

 

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

 

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