Объектно-ориентированные базы данных: достижения и проблемы

Разработка систем объектно-ориентированных баз данных (так называемые технологии баз данных пятого поколения) началась в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных (технология баз данных четвертого поколения). Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (computer aided design, CAD); автоматизированное производство (computer aided manufacturing, CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных (РБД). В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-ориентированных баз данных (ООБД).

Предлагалось много определений объектной ориентации и объектно-ориентированных баз данных [2, 20, 32, 8, 9, 19, 24], но мы будем определять объектно-ориентированные базы данных как базы, в которых объектная ориентация сочетается с возможностями баз данных. Объектная ориентация дает возможность более непосредственно представлять и моделировать проблемы реального мира, а функциональность баз данных требуется для обеспечения стабильности данных и многопользовательского параллельного доступа к информации приложений.

В настоящее время на рынке представлено свыше 25 систем ООБД. Среди них — система GemStone компании Servio, ONTOS компании Ontos, ObjectStore компании Object Design и многие другие [26]. Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора десятилетий разработки они все еще не вступили в пору зрелости; в этом — одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД. Среди современных ООБД почти нет полностью оперившихся систем, сопоставимых с современными системами реляционных баз данных. Обсудим основные достижения и проблемы, связанные с нынешним состоянием ООБД.

Модель ООБД

Причиной появления систем объектно-ориентированных баз данных была потребность в более адекватном представлении и моделировании сущностей реального мира, поскольку ООБД обеспечивают гораздо более развитую модель данных, нежели традиционные — реляционные базы данных. Парадигма ООБД основывается на ряде базовых понятий, таких как объект, идентифицируемость, класс, наследование, перегрузка и отложенное связывание [2, 3, 23, 31, 36].

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

У каждого объекта имеется определяемый системой уникальный идентификатор. Объекты, обладающие одними и теми же свойствами и поведением, группируются в классы. Объект может быть экземпляром только одного класса [5, 6] или нескольких классов [11, 13].

Классы организуются в иерархии классов. Подкласс наследует свойства и методы суперкласса; кроме того, подклассы могут обладать индивидуальными свойствами и методами. В некоторых системах, например, ORION [4], у класса можется более одного суперкласса (множественное наследование), тогда как в других системах число суперклассов ограничено одним (одиночное наследование).

В большинстве моделей допускается перегрузка унаследованных свойств и методов. Перегрузка состоит в замене домена свойств новым доменом или в замене одной реализации метода другой его реализацией [7].

Достоинства модели ООБД

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

Определение пользовательских абстракций

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

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

Примером пакета ООБД, обладающего всеми упомянутыми возможностями, может служить ENCORE [37]. Модель данных в ENCORE базируется главным образом на абстракции данных. ENCORE допускает подтипизацию (наследование), инкапсуляцию, сложные структуры, идентификацию объектов и отложенное связывание методов. Кроме того, ENCORE обеспечивает возможность связывания объектов с помощью свойств. В системе ENCORE свойство p связывает объект x с набором объектов S без какого-либо указания того, каким образом вычисляется эта связь. Ее можно вычислить путем прямого указания идентификатора набора S (или идентификаторов его членов) или с помощью установления соответствий значений других свойств, как в соединении.

Облегченное проектирование некоторых связей

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

Отсутствие потребности в определяемых пользователями ключах

В модели ООБД имеется понятие идентификаторов объектов, автоматически генерируемых системой и гарантированно уникальных для каждого объекта. Это обстоятельство в сочетании с тем, что в модели ООБД устраняется потребность в определяемых пользователями ключах, дает объектно-ориентированным базам данных и другие преимущества. Во-первых, идентификатор объекта не может быть модифицирован приложением. Во-вторых, понятие идентифицируемости объекта влечет отдельное и согласованное понятие идентичности, не зависимое от того, каким образом производится доступ к объекту или как объект моделируется с помощью описательных данных [22, 36]. Следовательно, два объекта не являются идентичными, если они имеют различные идентификаторы объектов; при этом объекты могут иметь одинаковые структуры, а все их свойства — одни и те же значения. В модели РБД, где идентификация объектов осуществляется через определяемые пользователями ключи, такие объекты считались бы одним и тем же объектом [7].

Наличие предикатов сравнения

В РБД сравнение всегда базируется лишь на значениях. В этой модели два кортежа являются одной сущностью, если все их ключевые атрибуты имеют одинаковые значения. Однако в модели ООБД были разработаны и определены иные типы сравнения [36, 7].

1. Равенство объектов на основе их идентичности. Два объекта, S1 и S2 равны, если они являются одним и тем же объектом (т.е. имеют один и тот же идентификатор объекта).
2. Равенство объектов на основе значений. Это можно определить в два захода — (a) два примитивных объекта равны, если имеют одно и то же значение; (b) два не примитивных объекта равны, если они имеют одинаковое число свойств, и для каждого свойства pi объекта S1 существует свойство pj объекта S2, равное ему по значению.
3. Равенство свойств на основе значений.
4. Равенство свойств на основе их идентичности.

Меньшая потребность в соединениях

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

Но, как уже отмечалось, поддержка путевых выражений может существенно сократить потребность в соединении классов по сравнению с ситуацией в РБД [25]. Имеются даже ситуации, в которых потребность в реляционном объединении может быть полностью устранена. Например, когда доменом атрибута класса A является класс B, выборка идентификаторов объектов некоторого класса, которые хранятся как значения атрибута другого класса, устраняет потребность в неявном соединении объектов.

Таким образом, в объектно-ориентированных базах данных неявные соединения, порождаемые иерархической вложенностью объектов, отличаются от явных объединений. Последние напоминают реляционные соединения: два объекта сравниваются явным образом по значениям атрибутов или объектных идентификаторов. Более того, все явные соединения (основанные на сравнении значений или идентификаторов) не могут быть выражены на реляционном языке запросов, поскольку в РБД любой предикат может содержать только атомарные атрибуты [7].

Выигрыш в производительности

Современные ООБД не являются полностью оперившимися системами баз данных по сравнению с современными РБД, ООБД обладают несколькими особенностями, обеспечивающими их выигрыш в производительности.

1. В ООБД значение атрибута объекта X, доменом которого является другой объект Y, — это идентификатор объекта Y. Следовательно, если приложение уже извлекло объект X и теперь хотело бы извлечь объект Y, то СУБД может извлечь объект Y, отыскав его идентификатор. Если этот идентификатор представляет собой физический адрес объекта, то данный объект может быть извлечен непосредственно; если же идентификатор является логическим адресом, то объект путем нахождения соответствующего элемента хэш-таблицы (в предположении, что в системе поддерживается хэш-таблица, отображающая идентификатор объекта в физический адрес). В РБД это могло бы не получиться так просто, поскольку в РБД не поддерживаются идентификаторы объектов.
2. Вторая особенность ООБД, обеспечивающая выигрыш в производительности, состоит в том, что в большинстве ООБД при загрузке объекта в память хранимые в этом объекте идентификаторы объектов преобразуются в указатели по памяти. Поскольку в РБД не хранятся идентификаторы объектов, в них невозможно сохранять указатели по памяти на другие кортежи. Отсутствие возможности навигации по объектам, содержащимся в памяти, является принципиальным свойством РБД, и вытекающее из этого снижение производительности не может быть компенсировано простым увеличением объема буферной памяти. Так что при выполнении приложений, которые предполагают многократную навигацию по загруженным в память связанным объектам, ООБД могут существенно превзойти РБД по производительности [25].
3. Кроме того, даже если ООБД не проиндексированы, может оказаться удобным выполнять произвольные запросы, соответствующие структуре объектов, путем последовательного сканирования, т.е. использовать ссылочные пути между объектами. Когда запрос формулируется в направлении, не поддерживаемом ссылками, этот запрос будет обрабатываться путем последовательного сканирования [14]. Однако запросы, формулируемые на основании таких связей объектов, которые не моделируются напрямую с помощью ссылок, выполняются неэффективно.

Поддержка версий и длительных транзакций

В РБД не поддерживаются ни работа с версиями, ни длительные транзакции. Такая поддержка имеется в некоторых ООБД, хотя и с ограниченными возможностями [25].

Объектная алгебра

Объектная алгебра не столь подробно разработана и не является столь же зрелой, как реляционная алгебра. Но как бы то ни было, такая алгебра существует, и в ней определяются пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map [29]. На основе этих фундаментальных операций могут быть определены другие операции, например, intersection. Правила преобразований для логической оптимизации выражений объектной алгебры с сохранением эквивалентности выводятся в [33] и [34]. В то время как операции union, difference и map производят, главным образом, отображение «один к одному», операции select и generate производят отображение «один ко многим». Сохранение объектов означает, что алгебраические операции возвращают объекты, принадлежащие к ранее определенным классам базы данных, и не создают новых объектов. Оператор union возвращает объекты, содержащиеся во множестве P или во множестве Q, или в обоих множествах. Оператор difference возвращает набор объектов, принадлежащих множеству P, но не множеству Q. select возвращает подмножество введенного множества. generate генерирует объекты из тех, что принадлежат входному множеству. map возвращает множество объектов, образующихся в результате каждого применения последовательности методов [34].

Недостатки модели ООБД

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

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

Отсутствие интероперабельности между РБД и ООБД

Чтобы ООБД смогли оказать значительное влияние на рынок баз данных, необходимо выполнить ряд условий.

1. Превратить ООБД в полностью оперившиеся системы баз данных, обладающих достаточной совместимостью с РБД. Требуется некий путь миграции, чтобы обеспечить сосуществование существующих ныне и новых продуктов, а также плавный переход от первых ко вторым.
2. Предложить средства разработки приложений и средства доступа к объектно-ориентированным базам данных.
3. Унифицировать архитектуры РБД и ООБД.
4. Унифицировать модели данных РБД и ООБД.

Недостаточность средств для оптимизации запросов

Одной из самых значительных проблем в ООБД является оптимизация декларативных запросов. Оптимизацию запросов к ООБД затрудняет дополнительная сложность самой объектно-ориентированой модели данных [15]. Эта дополнительная сложность обусловлена рядом факторов.

1. Возможность определения пользователями новых типов и классов с помощью наследования и облегчает, и осложняет оптимизацию запросов. Примером, в котором эта возможность помогает оптимизации, может служить запрос, включающий пересечение множеств Employees («сотрудники») и Supervisors («инспекторы»). Если Employee является суперклассом класса Supervisor, то оптимизатор может исходить из того, что Supervisors является собственным подмножеством Employees и упростить процедуру пересечения множеств. Пример, в котором дополнительные типы данных ограничивают возможности оптимизации, может служить объединение множеств Students и Employees; суперклассом для обоих классов является класс Person. Если бы мы захотели найти всех инспекторов студентов и служащих, мы бы сначала произвели объединение, а применили бы supervisor() [15].
2. Запросы могут базироваться на операциях над коллекциями, но виды оптимизации, затрагивающие множества (или мультимножества, или списки и т.п.), нужно сочетать с оптимизацией над типами объектов, содержащихся в этих множествах. Объектно-ориентированный оптимизатор запросов должен быть в состоянии применять процедуры оптимизации, характерные для данных типов, а также процедуры оптимизации, учитывающие связи между объектами разных типов [27].
3. Сложность обработки запросов в ООБД усугубляется наличием сложных объектов, методов и инкапсуляции. Сложные объекты порождают путевые выражения, которые усложняют обработку запросов. Создание индексов для путевых выражений, особенно при наличии в выражениях произвольных методов, усложняет обработку запросов. Проблема еще более осложняется, если методы обладают побочными эффектами. Еще одна проблема, связанная с путевыми выражениями, состоит в том, что они навязывают порядок вызовов методов путевого выражения, и этот порядок может быть весьма неэффективным. Например, путевое выражение Orders.part.name лучше вычислять справа налево, если имеется много заказов (Orders) и мало деталей (Parts), но если деталей много, а заказов мало — выражение лучше вычислять слева направо. Кроме того, иногда путевые выражения более эффективно обрабатываются с использованием Join. Рассмотрим, например, запрос с путевым выражением s.comp.name, где s принадлежит множеству Students (студенты). Могло бы оказаться более эффективно (если число компаний, comp, невелико) сначала вычислить название (Name) для каждой компании (Company) и сохранить результат в кортеже. Тогда вычисление выражения от студента до названия компании включало бы соединение множества Students с множеством кортежей путем сопоставления свойства comp класса student со значением атрибута Company некоторого кортежа.
4. В языках запросов к ООБД поддерживается использование вложенных структур, которые опять-таки могут существенно усложнить процесс оптимизации, поскольку превращают его из локальной проблемы в проблему глобальную, поскольку требуется глобальное знание всего выражения запроса.
5. Когда объекты обладают идентифицируемостью, возникает вопрос, а что же понимается под равенством двух объектов [27]. Этот вопрос переносится в язык, где операции сравнения по равенству используются в предикатах, и где необходимо принимать решение о создании новых объектов при выполнении запроса. Оптимизатор объектно-ориентированных моделей должен быть в состоянии решать проблемы, связанные с созданием новых объектов и с альтернативными определениями равенства.

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

Отсутствие стандартной алгебры запросов

Еще один серьезный недостаток ООБД состоит в отсутствии стандартов алгебры запросов. Это обстоятельство тоже затрудняет оптимизацию запросов. Для ООБД было предложено несколько разных формальных языков запросов, основанных на алгебрах и исчислениях [35, 34, 16, 26, 17]. Эти алгебры и исчисления отличаются в нескольких отношениях, и по выразительности, и по поддержке оптимизирующих правил перезаписи. Почти все эти алгебры базируются на переменных, т.е. используют переменные для хранения промежуточных результатов. KOLA, один из пакетов ООБД, является чисто функциональным продуктом; переменные в нем не используются. В [10] автор утверждает, что именно благодаря отсутствию переменных алгебра KOLA позволяет строить более мощные системы правил.

В РБД существует близкое соответствие между алгебраическими операциями и низкоуровневыми примитивами физической системы [30]. Это строгое соответствие достигается за счет отображений между отношениями и файлами, а также между кортежами и записями. Однако в ООБД нет аналогичного интуитивного соответствия между операциями объектной алгебры и примитивами физических систем. При всяком обсуждении генерации плана выполнения тоже необходимо, прежде всего, определить низкоуровневые примитивы манипулирования объектами [34].

Отсутствие средств обеспечения запросов

В большинстве ООБД не хватает средств обеспечения запросов [25]. В тех же немногих системах, где имеются достаточные соответствующие средства, язык запросов не совместим с ANSI SQL. Среди этих средств обеспечения запросов нет вложенных подзапросов, запросов с множествами (union, intersection, difference), агрегатных функций и GROUP BY, соединения нескольких классов — возможностей, полностью поддерживаемых в РБД [25].

Кроме того, отсутствует стандарт для объектных запросов, хотя надо сказать, что предпринимались попытки разработать объектный язык SQL [14]. SQL3, вероятно, задерживается на несколько лет [25].

Отсутствие поддержки представлений

В ООБД не поддерживаются представления. Хотя по этому поводу было выдвинуто несколько предложений [1, 13, 18, 12, 28], не удалось придти к единому мнению относительно того, как механизм представлений должен функционировать в ООБД. Разработка объектно-ориентированного механизма представлений осложняется такими свойствами модели, как идентифицируемость объектов. Что такое идентификатор объекта в представлении? С другой стороны, высказывается точка зрения, согласно которой возможность инкапсуляции данных и наследования позволяет обойтись без явных определений представлений [14].

Проблемы с безопасностью

В РБД поддерживается авторизация, тогда как в большинстве ООБД она отсутствует [25]. РБД предоставляют пользователям передавать и изымать права на чтение или изменение определений и кортежей в отношениях и представлениях. ООБД смогут получить более широкое распространение в области бизнеса лишь в том случае, если эта функция в них будет усовершенствована.

В некоторых системах ООБД пользователи должны явным образом устанавливать и снимать блокировки. Системы РБД автоматически устанавливают и снимают блокировки при обработке пользовательских запросов и операторов обновления.

Отсутствие поддержки динамических изменений определений классов

В дополнение к тому, что для ООБД до сих пор не разработана единая стандартная модель данных, в большинстве ООБД не допускаются динамические изменения схемы баз данных, таких как добавление к классу нового атрибута или метода, добавление к классу нового суперкласса, удаление суперкласса класса, добавление нового класса и удаление класса. РБД позволяют пользователю динамически изменять схему базы данных с помощью команды ALTER; к отношению может быть добавлен новый столбец, отношение может быть удалено, а в некоторых случаях имеется возможность удаления столбца из отношения [25].

В большинстве ООБД отсутствует и автоматическое управление расширениями классов. Если требуется расширение класса, пользователь должен определить для него коллекцию и следить за тем, чтобы в ней своевременно фиксировались все вставки и удаления [14].

Ограниченная поддержка ограничений целостности

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

Ограниченные возможности настройки производительности

В большинстве ООБД имеются лишь ограниченные средства параметризованной настройки производительности. В РБД инсталляторам предоставляется возможность настраивать производительность системы путем задания большого числа параметров, устанавливаемых системным администратором. Эти параметры включают число буферов памяти, объем свободного пространства, резервируемого в странице данных для будущей вставки данных и т.д. [25].

Недостаточная поддержка сложных объектов

Полная функциональность сложных объектов все еще не поддерживается. Можно осуществлять навигацию по ссылкам и кодировать операции с применением этих ссылок, но отсутствуют предопределенные родовые операции, в которых используются различные виды семантики ссылок. Считается, что все ссылки указывают на независимые объекты, а семантика особых связей внутри сложных объектов скрыта в операциях, предоставляемых пользователями [14].

Ограниченная интеграция с объектно-ориентированными системами программирования

Трудно переписывать объектно-ориентированные программы для управления стабильными данными. Здесь возникает ряд проблем: конфликты по именам; необходимость переделывать иерархии классов; склонность ООБД к перегрузке системных операций [14].

Ограниченный выигрыш в производительности

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

В числе средств, пока что не поддерживаемых в ООБД, также можно назвать триггеры, средства управления метаданными [14], а также ограничения целостности, такие как UNIQUE и NULL [25].

***

Из-за указанных слабостей ООБД не смогли оправдать возлагавшихся на них ожиданий: обеспечить все важные средства, желательные для целевых приложений. Применительно к большинству современных систем термин «ООБД» используется неправильно. Почти все современные ООБД — не столько системы баз данных, сколько системы стабильного хранения данных для некоторого объектно-ориентированного языка программирования [25]. Так что, хотя объектно-ориентированная модель данных во многих отношениях богаче реляционной модели, объектно-ориентированная модель еще не вполне вступила в период зрелости. На сегодняшний день недостатков в системах ООБД явно больше, чем достоинств.

Литература

1. S. Abiteboul, A. Bonner, «Objects and views». ACM SIGMOD Int. Conf. On Management of Data, 1991.
2. M. Atkinson, et al., «Object-Oriented Database System Manifesto». Building an Object-Oriented Database System: The Story of O2. Morgan Kaufman, 1992.
3. F. Bancilhon, «Object oriented database systems». 7th ACM SIGART/SIGMOD Conf., 1988.
4. J. Banerjee, et al., «Data model issues for object oriented applications». ACM Trans. On Office Information Systems, Jan 1987.
5. J. Banerjee, W. Kim, K.C. Kim, «Queries in object oriented databases». IEEE Data Engineering Conf., Feb. 1988.
6. D. Beech, «Foundation for evolution and relational to object databases». Proc. Extended Data Base Technology, Mar. 1988.
7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, «Object-Oriented Query Languages: Notion and Issues». IEEE Transactions on Knowledge and Data Engineering, Mar. 1992.
8. A.W. Brown, Object-Oriented Databases, Applications in Software Engineering. New York: McGraw-Hill, 1991.
9. R.G.G. Cattell, Object Data Management, Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1991.
10. M. Cherniack, «Form(ers) over Function(s): KOLA Query Algebra». Technical Report, Brown University, Dec. 1995.
11. S. Cluet, et al., «Reloop, Algebra based query language for an object-oriented database system». 1st Int. Conf. On Deductive and Object Oriented Databases, Dec. 1989.
12. I.F. Cruz, DOODLE: Visual language for object-oriented databases. ACM SIGMOD Int. Conf. On Management of Data, 1992.
13. U. Dayal, «Queries and views in object-oriented data model». 2nd Int. Work. On Database Programming Languages, June 1989.
14. K.A. Dittrich, K.R. Dittrich, «Where Object-Oriented DBMSs Should Do Better: A Critique Based on Early Experiences». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
15. U. Erlingsson, «Object-Qriented Query Optimization», unpublished manuscript.
16. L. Fegaras, D. Maier, «Towards an Effective Calculus for Object Query Languages». ACM SIGMOD Int. Conf. on Management of Data, San Jose, California, May 1995.
17. L. Fegaras, D. Maier, T. Sheard, «Specifying Rule-based Query Optimizers in a Reflective Framework». 3rd Int. Conf. on Deductive and Object-Oriented Databases, Phoenix, Arizona, Dec. 1993.
18. S. Heiler, S. Zdonik, «Object Views: Extending the vision». 6th Int. Conf. On Data Engineering, 1990.
19. J.G. Hughes, Object-Oriented Databases. New York: Prentice-Hall, 1991.
20. S. Khoshafian, «Insight Into Object-Oriented Databases». Information and Software Technology, Apr. 1990.
21. S. Khoshafian, Object-Oriented Databases, New York: John Wiley & Sons, 1993.
22. S. Khoshafian, G. Copeland, «Object identity». 1st Int. Conf. On Object-Oriented Programming Systems, Languages, and Applications, Oct. 1986.
23. W. Kim, «Foundation for object-oriented databases». MCC Tech. Rep., N. ACA-ST-248-88, Aug. 1988.
24. W. Kim, Introduction to Object-Oriented Databases. MIT Press, 1991.
25. W. Kim, «Object-Oriented Database Systems: Promises, Reality, and Future». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
26. T.W. Leung, et al, «Aqua Data Model and Algebra». Technical Report CS-93-09, Brown University, Mar. 1993.
27. G. Mitchell, S.B. Zdonik, U. Dayal, «Object-Oriented Query Optimization — What?s the Problem?» Technical Report CS-91-41, Brown University, June 1991.
28. E.A. Rudensteiner, «Multiview: Methodology for supporting multiple views in object-oriented databases». 18th Int. Conf. On Very Large Databases, 1992.
29. M. Scholl, H. Schek, «Relational object model». 3rd Int. Conf. On Database Theory, LNCS, vol. 470, Springer Verlag, 1990.
30. P.G. Selinger, et al, «Access path selection in a relational database management system». ACM SIGMOD Int. Conf. On Management of Data, 1979.
31. M. Stefik, D.G. Bobrow, «Object-oriented programming: Themes and variations». The AI Mag., Jan. 1986.
32. M. Stonebraker, et al, «Third-Generation Data Base System Manifesto». Committee for Advanced DBMS Function, University of California, Berkeley, 1990.
33. D.D. Straube, M.T. Ozsu, «Queries and query processing in object-oriented database systems». ACM Transactions on Information Systems, Oct. 1990.
34. D.D. Straube, M.T. Ozsu, «Execution Plan Generation for Object-Oriented Data Model». 2nd Int. Conf. on Deductive and Object-Oriented Databases, Munich, Germany, Dec. 1991.
35. S.Y.W. Su, M. Guo, H. Lam, «Association Algebra: Mathematical Foundation for Object-Oriented Databases». IEEE Transactions on Knowledge and Data Engineering, Oct. 1993.
36. S.B. Zdonik, D. Maier, eds., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
37. S.B. Zdonik, P. Wegner, «Language and Methodology for Object-Oriented Database Environments». Hawaii Int. Conf. on System Sciences, Jan. 1986.

Сиха Багуи (bagui@uwf.edu) — лектор факультета компьютерных наук университета Западной Флориды. Соавтор трех книг, посвященных базам данных: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) и Database Design Using Entity Relationship Diagrams (CRC Press).

Translated from «Achievements and Weaknesses of Object-Oriented Databases» by Sikha Bagui in Journal of Object Technology (JOT), vol. 2, no. 4, July-August 2003, pages 29-41. Translated into Russian for Otkrytye Systemy under special permission of the original publisher. Copyright JOT, 2003. Original article at http://www.jot.fm/issues/issue_2003_07/column2.

От редактора перевода

ООБД — зрелость или упадок?

Сергей Кузнецов

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

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

Статья основывается на анализе 36 публикаций, посвященных объектно-ориентированным базам данных и изданных в период 1986-1995 годов. Поэтому часто используемая характеристика «современные» ООБД не совсем справедлива. Цитаты, иногда подаваемые в настоящем времени, порой выглядят довольно подозрительно.

Конечно же, в многочисленных источниках использовалась разная терминология, и в этом отношении их обзор обладает исключительной пестротой. Кроме того, многие из статей достаточно сложны с технической точки зрения, и их цитирование без обеспечения контекста только затрудняет понимание. Наиболее яркий пример — подраздел про разработку объектной алгебры. Первые три «фундаментальные» операции — union, difference, select — интуитивно понятны (хотя в действительности у авторов оригинальной статьи допускается не очень очевидный вариант выборки в форме полусоединения), но две последние — generate и map — являются сложно определяемыми и неочевидными операциями.

Хочу отметить еще одну странную особенность статьи Багуи. До 2001 года существовал международный консорциум Object Data Management Group, который опубликовал три версии предложений по стандартизации объектно-ориентированной модели данных; последняя версия — ODMG 3.0 была опубликована в 2000 году [1]. Это единственный документ, в котором предлагается сравнительно согласованная терминология и, в некоторой степени, объектно-ориентированная модель данных. Жаль, что Багуи не пользуется этим материалом.

Заметим, что в журнале «СУБД» публиковались статья, посвященная первому варианту стандарта, ODMG-93 [2]. Краткий обзор стандарта ODMG 3.0 можно найти в [3]. Также можно рекомендовать перевод Манифеста систем объектно-ориентированных баз данных [4] и очень симпатичный обзор технологии ООБД [5].

Литература

1. The Object Data Standard: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
2. Л.А. Калиниченко, «Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния». // СУБД, № 1, 1996.
3. С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests.
4. М. Аткинсон и др., «Манифест систем объектно-ориентированных баз данных», // СУБД, № 4, 1995.
5. Арк Андреев, Дмитрий Березкин, Роман Самарев, «Внутренний мир объектно-ориентированных СУБД». // Открытые системы, № 3, 2001.