3. Объектно-ориентированные базы данных

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

3.1. История ООСУБД

Область ООСУБД возникла на основе ранее существовавшей области языков программирования баз данных. В этой области было выполнено множество исследований, и был разработан ряд интересных экспериментальных систем, включающих Атлант [34], DBPL [35] и PS-algol [36]. В 1990-е гг. консорциум ODMG разработал несколько стандартов объектно-ориентированной модели данных, последним среди которых был опубликован стандарт ODMG 3.0 [37]. В конце 1980-х – начале 1990-х гг. было создано несколько интересных ООСУБД, к которым относятся GemStone, Objectivity, Versant, Object Store и т.д. [1]. Коротко обсудим основные архитектурные особенности этих систем.

3.1.1. ООСУБД GemStone

ООСУБД GemStone была одной из первых коммерчески доступных ООСУБД. Система была разработана компанией Servio-Logic совместно с OGI. В исходном варианте системы разработчики GemStone опирались на язык Smalltalk. Хотя в первых выпусках системы ее основной язык назывался Opal, было видно, что в действительности это Smalltalk с поддержкой стабильного хранения объектов, и вскоре название языка было заменено на GemStone Smalltalk. Впоследствии в GemStone была обеспечена поддержка языков C и C++, но во все времена базовым языком оставался Smalltalk, а все остальные интерфейсы строились поверх базового интерфейса. И серверная, и клиентская части системы могут работать под управлением всех основных ветвей ОС UNIX и всех развитых вариантов Windows. В настоящее время продукт поддерживается, развивается и распространяется компанией GemStone Systems Inc. [38].

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

Архитектура поддерживается рядом системных взаимодействующих процессов, среди которых доминирующими являются процессы Stone и Gem. Процесс Stone координирует доступ к хранилищу объектов, состоящему из нескольких областей внешней памяти, которые могут представлять собой файлы или разделы дисков, а также могут быть разнесены по нескольким машинам. Процесс Stone синхронизирует другие процессы и обеспечивает согласованность данных при фиксации транзакций. Кроме того, процесс отвечает за распределение идентификаторов объектов, объектных страниц и объектных блокировок.

Объекты делаются стабильными (т.е. сохраняются в базе данных) путем использования своего рода стабильного корня, называемого коннектором. Все объекты, прямо или косвенно достижимые по объектным ссылкам от коннектора, являются стабильными. В GemStone для каждого класса, в котором существует хотя бы один стабильный объект, поддерживается эквивалентная серверная версия класса. Другими словами, один вариант класса служит классом в контексте программирования, а другой – в контексте базы данных. Такие пары поддерживаются автоматически: если создается класс в смысле Smalltalk, и некоторый объект этого класса становится стабильным, то автоматически создается серверный класс этого объекта (класс в смысле GemStone). Создание коннектора приводит к появлению экземпляра класса GemStone, эквивалентного классу объекта, который должен быть сделан стабильным. Аналогично, любой объект, достижимый от коннектора, автоматически становится стабильным.

3.1.2. ООСУБД Objectivity/DB

Компания Objectivity [39] была образована в 1988 г. В 1990 г. была выпущена первая версия системы, которая представляла собой распределенную СУБД, основанную на использовании объектной технологии, высокопропускных локальных сетей и симметричных мультипроцессоров. Система работает на всех основных UNIX-платформах и в среде Windows.

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

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

В системе поддерживаются языки C++ и Smalltalk, но способы использования языков сильно различаются. Это относится и к механизмам стабильности, и к средствам определения данных. В среде C++ стабильными являются объекты всех классов, являющихся наследниками специального системного класса. В среде Smalltalk стабильными являются все объекты, достижимые от именованных корневых объектов-словарей. Соответственно, в Smalltalk для удаления объектов используется механизм сборки мусора, а в C++ – явные операции.

3.1.3. ООСУБД Versant

С 1988 г. компания Versant [40] предлагает решения, основанные на хорошо масштабируемой объектно-ориентированной архитектуре и проприетарном алгоритме кэширования. ООСУБД Versant является одной из немногих объектно-ориентированных систем, допускающих масштабирование уровня любого предприятия. Решения на базе Versant применяются в телекоммуникациях, обороне, на транспорте и т.д. Система работает как на основных UNIX-платформах, так и в среде Windows.

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

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

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

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

Для программирования можно использовать языки C++ и Smalltalk, причем безо всяких расширений. Поддерживаются возможности, специфичные для работы с базами данных. Например, имеется средство автоматической генерации схемы базы данных прямо по файлам заголовков C++. Это позволяет обойтись без использования специализированных препроцессоров или компиляторов. Специальные системные классы позволяют работать со всеми разновидностями типов коллекций, специфицированными в стандарте ODMG. Любой объект, созданный в среде C++, доступен в среде Smalltalk и наоборот.

3.1.4. ООСУБД ObjectStore

Компания Object Design была основана в 1988 г. с целью ускоренной разработки и вывода на рынок ООСУБД, которую стали называть ObjectStore. В конце 90-х у Object Design установились тесные партнерские отношения с IBM, что позволило привлечь к созданию ObjectStore тысячи разработчиков приложений. На основе технологии ObjectStore компанией был разработана одна из первых коммерческих СУБД – Excelon, ориентированная на управление XML-данными. С начала 2003 г. компания является подразделением компании Progress Software [41].

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

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

В ObjectStore стабильность хранения объектов поддерживается за счет наличия именованных корневых стабильных объектов класса база данных. База данных создается с помощью вызова метода new этого класса. Имеются методы для открытия и закрытия базы данных. Кроме того, в классе содержатся методы для создания стабильных корневых объектов, обычно являющихся коллекциями, в которых размещаются стабильные объекты.

3.2. Современное состояние дел и перспективы

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

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

Во-вторых, в конце 1990-х гг. в СУБД компаний IBM, Oracle и Informix была обеспечена поддержка «объектных» расширений языка SQL. В действительности, это была совсем не та поддержка объектно-ориентированного подхода, которая предлагалась в ООСУБД (см., например, [42]), но наличие схожих по названию возможностей в СУБД, поддерживаемых крупными производителями, наверняка отвлекло многих пользователей и разработчиков приложений от использования ООСУБД.

В последние годы наблюдается повышение интереса к этой области. Об этом свидетельствует появление в 2005 г. неформального консорциума ODBMS.ORG [43]. Как отмечается на сайте этого консорциума, ODBMS.ORG был создан для поддержки студентов, преподавателей и специалистов исследовательских институтов, в также разработчиков объектно-ориентированного программного обеспечения из сообщества open source и коммерческих компаний в связи с возрастающей потребностью в информационных ресурсах, посвященных технологии объектных баз данных и интеграции объектно-ориентированного программирования и баз данных. Одним из основных членов ODBMS.ORG является молодая компания db4objects [44], работающая в соответствии с принципами движения open source и поставляющая встраиваемую в приложения ООСУБД, ориентированную исключительно на язык Java.

В 2008 г. после долгого перерыва была проведена (пока еще небольшая) специализированная конференция, посвященная проблемам ООСУБД [45]. Под эгидой ODBMS.ORG начата работа по созданию нового стандарта объектно-ориентированной модели данных [46]. Пока непонятно, приведет ли эта активность к новому витку популярности ООСУБД.

4. Объектно-реляционные отображения

Большая часть современных производственных приложений, связанных с потребностью в обработке больших объемов данных, разрабатывается на различных объектно-ориентированных языках (C++, C#, Java и т.д.). Разработчики приложений работают в терминах прикладной объектной модели данных, и им удобнее и проще представлять в той же модели внешние данные. Хотя теоретически можно было бы воспользоваться объектными расширениями SQL или средствами ООСУБД, разработчики часто предпочитают использовать промежуточное программное обеспечение (middleware) «объектно-реляционного» отображения (object/relational mapping) для манипулирования прикладными объектами, размещаемыми в традиционных таблицах SQL-ориентированных СУБД.

4.1. История проблемы impedance mismatch и подходы к ее решению

В языках программирования и языках баз данных традиционно поддерживаются разные системы типов, разные способы доступа к данным и т.д. Возникает «потеря соответствия» (impedance mismatch) между системами типов и средствами доступа к данным языка программирования и системы баз данных. Это затрудняет разработку приложений, которые по своей специфике вынуждены часто обращаться к базе данных для доступа к требуемым им данным [47].

Как отмечалось выше, проблему «потери соответствия» пытались решать разработчики языков программирования баз данных, создатели ООСУБД и объектных расширений языка SQL. Альтернативным путем к решению этой проблемы является создание средств промежуточного программного обеспечения объектно-реляционного отображения.

4.2. Почему объектно-ориентированных программистов не устраивают ни объектные расширения SQL-ориентированных баз данных, ни ООСУБД?

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

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

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

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

4.3. Подходы к обеспечению объектно-реляционного отображения

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

В другой форме для организации объектно-реляционного отображения требуется кодирование вручную с использованием инструментальных средств, таких как JDBC или ADO.NET, ориентированных на работу с реляционными базами данных. Эти средства обеспечивают доступ к реляционным данным и их извлечение «вручную» в форме, более привлекательной для объектных разработчиков.

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

4.4. Современное состояние и проблемы

Наиболее масштабным проектом, связанным с обеспечением расширяемых возможностей объектно-реляционного отображения для целого ряда языков программирования, является LINQ компании Microsoft [50]. Первые реализации были выполнены для языков C# и Visual Basic.NET. Это очень крупный проект, на результаты которого компания делает высокую ставку. Однако в литературе [48] отмечается ряд проблем, полностью решить которые вряд ли удастся и в этом проекте.

Назад Содержание Вперёд