Технология объектно-ориентированных баз данных

Будущие проблемы

Архитектуры унификации
Унификация моделей данных
Запросы и манипуляция данными
Навигация по обьектам, резидентным в памяти
Взаимодействие с реляционными базами данных

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

Определения

Сегодняшние объектно-ориентированные технологии включают объектно-ориентированные языки программирования (например, С++ и Smalltalk), объектно-ориентированные системы баз данных, объектно-ориентированные интерфейсы пользователя (например, оконные системы Macintosh и Microsoft, настольные издательские системы Frame и Interleaf) и т.д. Объектно-ориентированная технология делает возможным использование "объектно-ориентированных концепций". Чтобы определить их, мы должны сначала понять, что такое "объект".

Термин "объект" означает комбинацию "данных" и "программы", представляющих некоторую сущность реального мира. "Данные" состоят из компонентов произвольного типа, называемых "атрибутами". Каждая программа в программной части называется "методом". Часто говорят: объект "инкапсулирует" данные и программу. Другими словами, пользователи не могут увидеть, что у объекта внутри, но могут им пользоваться, обращаясь к его программной части. Это немногим отличается от обычного вызова процедуры, когда пользователи обращаются к ней, подставляя значения входных параметров и получая результаты в виде выходных параметров.

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

Сила объектно-ориентированных концепций проистекает из объединения инкапсуляции и наследования.

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

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

Потенциал объектно-ориентированных баз данных

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

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

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

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

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

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

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

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

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

Состояние современных объектно-ориентированных продуктов баз данных и прогноз

Имеется ряд коммерческих объектно-ориентированных систем баз данных. В их числе GemStone (от Servio Corporation), ONTOS (ONTOS), Object Store (Object Design, Inc.), Objectivity/DB (Objectivity,Inc.), Versant (Versant Object Technology, Inc.), Object Database (Object Database, Inc.), Itasca (Itasca Systems, Inc.), 02 (02 Technology). Все эти продукты поддерживают объектно-ориентированную модель данных. Они позволяют пользователю создавать новый класс с атрибутами и методами, определять наследование атрибутов и методов у суперклассов, создавать экземпляры поодиночке или группами, загружать и выполнять методы.

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

Ограничения

Ограничения систем постоянного хранения. Одна из целей современных ООБД - унификация языков программирования и баз данных в одном языке (например, С++ или Smalltalk). Эта цель вызвана текущим положением дел, когда прикладные программы пишутся на универсальном языке программирования (в основном, COBOL, FORTRAN, PL/I, С), а встроенные в приложение функции управления базой данных - на языке базы данных (например, SQL). Универсальный язык программирования и язык базы данных весьма различны по синтаксису и модели данных (структурам и типам данных), и необходимость изучать и использовать два разных языка при разработке приложений баз даннь~х часто рассматривается как главный недостаток. Поскольку C++ и Smalltalk уже включают средства для определения классов и их иерархии (т.е. определения данных), эти языки являются хорошей основой для унификации. Первый шаг, предпринятый производителями ранних ООБД, заключался в том, чтобы сделать постоянными кроссы и экземпляры кроссов, то есть поместить их во вторичную память и дать возможность доступа к ним даже после завершения программ, которые их определили и создали.

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

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

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

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

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

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

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

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

Будущие проблемы

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

В качестве примера рассмотрим модернизацию языка запросов ООБД.

1. Язык запросов надо спроектировать - очень трудная задача.

2. Нужно реализовать процедуру синтаксического разбора запросов.

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

4. Для вычисления сложных запросов (соединения, операции над множествами, вложенные подзапросы) надо реализовать различные алгоритмы обработки запросов.

5. Реализовать, по крайней мере, несколько методов доступа (структур для сохранения и извлечения данных), таких как универсальная сортировка, индексное B+-дерево, расширяемая хэш-таблица.

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

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

8. Аналогично, с механизмами контроля одновременного доступа и восстановления после сбоев должны быть интегрированы алгоритмы обработки запросов.

9. Нуждается в модификации компонент управления рабочим пространством,поскольку оно будет задействовано в обработке запросов. Так как рабочее пространство может содержать обновленные версии объектов, отличные от тех, которые находятся в базе, это необходимо учитывать при обработке.

Рассмотрим еще один пример - то, как потребуется перетрясти средства динамического изменения схемы современных ООБД.

1. Нужно спроектировать полную семантику всех доступных изменений схемы.

2. В систему надо добавить (и интегрировать со всеми остальными ее гостями) компонент управления схемой.

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

4. Так как класс наследует атрибуты и методы у суперклассов, он наследует и эффект изменения схемы, затронувшего суперклассы. Например, если атрибут удален из суперкласса, хорошо бы его удалить и из подклассов. Другими словами, компонент управления схемой должен учитывать семантику наследования при изменениях схемы.

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

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

Мифы, связанные с ООБД

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

ООБД в 10 (в 1000) раз бьсстрее, чем РБД

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

Современные РБД допускают в качестве доменов только примитивные типы данных. Поэтому значение атрибута кортежа может быть числом или символьной цепочкой, но не другим кортежем. Если кортеж Y отношения R2 логически является значением атрибута А в кортеже Х отношения К1, фактическое значение, занесенное в атрибут А, - это значение некоторого атрибута В кортежа У. Если приложение извлекло кортеж Х и теперь нуждается в извлечении кортежа У, система должна выполнить запрос, который просканирует отношение R2, используя значение атрибута А кортежа Х. Рис. 1б содержит представление средствами РБД объектно-ориентированной базы, изображенной на рис. 1а. Если для атрибута В (Name) отношения R2 (Company) индекс не поддерживается, должно быть последовательно просмотрено все отношение. Если индекс есть, кортеж Y может быть извлечен почти так же быстро, как в ООБД с хэш-таблицей, но медленнее, чем в ООБД, использующей в качестве идентификатора объекта его физический адрес.

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

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

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

ООБД устраняют необходимость в соединениях

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

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

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

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

В ООБД не может быть непроцедурного языка запросов

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

Обработка запросов будет нарушать иннапсуляцию

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

ООБД - это всего лишь перевоплощение старых иерархинесних и сетевых баз данных

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

ООБД могут поддерживать версии и длинные транзакции

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

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

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

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

ООБД могут поддерживать данные мультимедиа

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

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

ООБД не имеют теоретичесного основания

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

1. Домен атрибута отношения может быть произвольного типа, а не обязан принадлежать маленькому набору примитивных типов. Это приводит к возможности агрегирования и создания вложенных объектов.

2. Свойства отношения расширяются: к атрибутам и ограничениям на атрибуты добавляются методы.

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

4. Классы организуются в иерархию, исходя из соотношения обобщение/спецификация между парами классов.

5. Разрешается рекурсивно наследовать свойства класса всем его подклассам, унаследованные свойства можно модифицировать в подклассах, кроме того, к подклассу можно добавить дополнительные атрибуты и методы.

6. Допускается доступ к атрибутам и методам класса только посредством сообщений, использующих явно определенный набор интерфейсов класса. Если сообщение, посланное экземпляру класса, неопределенно для этого класса, оно направляется иерархии классов,чтобы найти класс, для которого оно определено: это называется поздним связыванием сообщений.

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

Необходима дальнейшая формализация в нескольких областях, таких как свойства методов и разрешения конфликтов при множественном наследовании. Однако важно отметить, что РБД были разработаны на основе минимальной реляционной модели данных и реляционных исчислений и алгебре, предложенных Е.Р. Коддом. Теории управления транзакциями, контроля за одновременным доступом восстановления, представлений, оптимизации запросов, авторизации, методов доступа - все разработаны независимо от реляционного исчисления Кодда.

Унификация реляционной и обьектно-ориентированной технологий

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

Архитектуры унификации

Производители некоторых ООБД готовятся предложить "SQL-подобные" языки (не обязательно надмножество SQL ), обобщенно называемые Object SQL и включающие средства для определения и формирования запросов к объектно-ориентированным базам данных, и добавить их к своим ООБД. В этом отражается главное изменение в их стратегии. Всего несколько лет назад эти производители просто пытались обеспечить шлюзы между их ООБД и некоторыми из РБД. Недавно на рынке баз данных появились две системы баз данных, поддерживающие объектные расширения SQL UniSQL/X от UniSQL, Inc. и OpenODB от Hewlett-Packard. UniSQL/Х реализована с нуля, а OpenODB реализована на основе реляционной системы баз данных HP A11Base.

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

При подходе, основанном на объектно-ориентированном слое (например, HP OpenODB), пользователь взаимодействует с системой, иснользуя язык ООБД (в случае OpenODB -ObjectSQL), а слой выполняет все трансляции объектно-ориентированных аспектов языка базы данных в их реляционные эквиваленты. Затраты на трансляцию могут быть существенными, что значительно снизит производительность архитектуры. РБД состоит из двух слоев: менеджера данных и менеджера хранения. Менеджер данных обрабатывает SQL-утверждения, а менеджер хранения отображает данные в базу. Объектно-ориентированный слой может взаимодействовать как с менеджером данных (разговаривая с ним в терминах SQL), так и с менеджером хранения (используя для общения низкоуровневые процедурные вызовы). Интерфейс уровня данных намного медленнее интерфейса уровня хранения. (OpenODB использует интерфейс менеджера данных.) Поскольку этот подход предполагает, что нижележащая РБД не будет модифицироваться, чтобы лучше соответствовать объектно-ориентированному слою, возможны серьезные проблемы с производительностью и с поддержкой сложных средств баз данных. Например, если надо заблокировать большое число классов в иерархии классов (например, чтобы поддержать динамическое изменение схемы), объектно-ориентированный слой должен либо устанавливать по одной целую серию блокировок (резко снижая производительность и рискуя попасть в тупиковую ситуацию), поскольку РБД не имеет средств для автоматической блокировки иерархии классов, либо блокировать сразу всю базу (потенциально препятствуя доступу к любой части базы данных для всех остальных пользователей). Далее, поскольку объектно-ориентированный слой должен поддерживать обновления объектов в памяти и автоматически передавать обновленные объекты в базу данных, когда транзакция завершена, отдельные объекты должны вставляться в базу данных по одному, используя интерфейс РБД.

Обоснованием такого подхода является возможность портировать объектно-ориентированный слой на множестве уже существующих РБД. Гибкость приобретается за счет производительности. Данный подход служит основой такой системы баз данных, которая позволяет представить для прикладных программ множество баз данных (в частности, как ООБД, так и РБД) в виде единой базы. Такую систему называют "системой мультибаз данных". Отмечу, что OpenODB в настоящий момент не является мультибазой данных. Ее объектно-ориентированный слой может взаимодействовать только с одной РБД.

Унифицированный подход помещает объектноориентированный слой и РБД на единый фундамент. При этом необходимые изменения вносятся как в менеджер данных, так и в менеджер хранения РБД. Разработка UniSQL/Х потребовала разрешения значительных технических проблем.

- Реляционная и объектно-ориентированная модели должны были быть скомбинированы в единой согласованной унифицированной модели.

- Надо было спроектировать SQL/X - надмножество языка баз данных ANSI SQL, языка, включающего полные средства определения данных, запросов (соединения, операции над множествами и т.д.) и обновления.

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

- Система должна была обладать высокой производительностью, сравнимой, в частности, с производительностью РБД и с производительностью ООБД.

- Кроме унификации технологий ООБД и РБД, UniSQL/X предлагает решения для управления данными мультимедиа и темпоральными данными. Поскольку эти вопросы не относятся к ООБД или РБД, здесь я не буду их рассматривать .

Далее я перейду к обсуждению расширений модели данных, вводимых в UniSQL/X с целью унификации реляционной и объектно-ориентированной моделей. Унифицированная модель дает возможность пользователям естественным образом представлять сложные данные. Я проиллюстрирую язык запросов и манипуляции данными UniSQL/X и затем рассмотрю, как UniSQL/X поддерживает навигацию по объектам в памяти.

Унификация моделей данных

Реляционная база данных состоит из множества отношений (таблиц), а отношение, в свою очередь, состоит из строк (кортежей) и столбцов. В пересечении строки и столбца указывается некоторое значение, принадлежащее одному из заданного системой множества типов (целый, цепочка символов, вещественный, дата, время, денежные единицы). Пользователь может накладывать дополнительные условия, называемые ограничениями целостности (например, целое значение возраста работника может быть ограничено между 18 и 65). Пользователь может использовать непроцедурные запросы для извлечения из отношений только тех кортежей, значения атрибутов которых удовлетворяют указанным пользователями условиям. Наконец, пользователь может связывать два или несколько отношений посредством их соединения, сопоставляя значения в указанных им (пользователем) столбцах.

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

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

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

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

Третье расширение отражает концепцию наследования. UniSQL/X позволяет организовать все отношения в базе данных в иерархию. Для пары отношений Р и С предком С является Р, если С наследует все столбцы и процедуры, определенные для Р, и добавляет некоторые другие. Допускается более одного предка (это называется множественным наследованием). Иерахия отношений - направленный ациклический граф (а не дерево) с выделенным, заданным системой корнем. Между отношением-потомком и отношениемпредком устанавливается взаимосвязь IS-А (обобщение и специализация). В четвертом по счету операторе CREATE TABLE на Рис. 4 отношение Employee определяется как CHILD OF отношения Person. Employee автоматически наследует три столбца отношения Person (имеются в виду столбцы Name, SSN и DOB) даже без спецификации их в определении отношения.

Иерархия отношений обладает двумя преимуществами над привычной реляционной моделью. Во-первых, пользователь может создать новое отношение, опираясь на уже существующие. Во-вторых, система может поддерживать явно специфицированную взаимосвязь между парами отношений IS-А. РБД заставляют пользователей управлять этой взаимосвязью вручную.

В действительности, UniSQL/X предлагает одно еще более важное расширение реляционной моделью. Отмечу, что оно не связано с объектной ориентированностью, но вызвано фундаментальным ограничением реляционной модели. Именно UniSQL/X допускает использование в качестве элементов отношений множество, а не только одиночные значения. Более того, во множество можно включать значения, принадлежащие к различным типам. Ограничение реляционной модели заставляет пользователей создавать лишние приложения и/или дублировать кортежи в отношении, если в клетку надо поместить более одного значения.

Итак, UniSQL/X содержит четыре важных расширения реляционной модели. Хотя каждое из расширений по отдельности может выглядеть малым, их совокупность оказывается существенной с точки зрения простоты моделирования данных приложения и увеличения эффективности обработки запросов.

Теперь давайте заменим реляционные термины следующим образом. Заменим "отношение" на "класс", "кортеж отношения" на "экземпляр класса", "столбец" на "атрибут", "процедуру" на "метод", "иерархию отношений" на "иерархию классов", "отношение-потомок" на "подкласс", "отношение-предок" на "суперкласс". Описанная выше модель данных UniSQL/X - это объектно-ориентированная модель! Объектно-ориентированная модель данных может быть получена расширением реляционной модели! Термины "объектно-ориентированная модель данных", "расширенная реляционная модель данных", "унифицированная реляционная и объектно-ориентированная модель данных (для краткости - просто унифицированная)" становятся синонимами, если эта модель данных получена посредством добавления к привычной реляционной модели первых трех из описанных выше расширений. Однако расширенная реляционная модель (система) не является объектно-ориентированной, если она не включает всех трех расширений. Кроме того, важно отметить, что основанная на такой модели система баз данных, благодаря своему реляционному фундаменту, может опереться на все теоретические результаты, полученные в технологии реляционных баз данных за последние два десятилетия.

Запросы и манипуляция данными

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

Язык запросов UniSQL/X, в отличие от "SQL-подобных" объектных языков запросов, является надмножеством ANSI SQL - если расширения из него удалить, он превратится в ANSI SQL. Под SQL-подобным языком я подразумеваю язык базы данных, который либо является помножеством SQL, либо не поддерживает семантику, тождественную SQL. SQL-подобный язык будет подмножеством SQL, если он, например, не поддерживает вложенные запросы в конструкции WHERE или функции агрегирования в конструкции SELECT либо если не включает средства для определения или использования представлений, для динамического изменения схемы, спецификации ограничений NULL или UNIQUE, наделения и лишения полномочий и так далее. SQL-подобный язык, не поддерживающий точную семантику SQL, - это, например, такой язык, который трактует значения NULL не так, как SQL, или отказывается фиксировать транзакцию после нормального завершения всех запросов пользователя на чтение или обновление, или вводит ограничение, которого не было в SQL (например, не позволяет выполнить команду DROP TABLE, если не удалены все объекты из этого класса, - соответствующая команда SQL вызывает удаление таблицы и всех ее записей) и так далее.

Если множество классов определено в точности так же, как отношения в обычных реляционных базах данных, пользователи UniSQL /Х могут работать с ними при помощи всех средств ANSI SQL. Рассмотрим простой пример. Класс Employee определен как подкласс класса Person, а класс Activity является доменом атрибута Hobby класса Employee. Первый запрос находит всех сотрудников старше 30 лет, получающих более 50 тысяч, и, группируя их в соответствии с выполняемой работой, вычисляет средний заработок. Второй запрос - это соединение, которое находит имена всех сотрудников, получающих больше своих менеджеров.

SELECT Job, Avg (Salary)
FROM Employee
WHERE Salary < 50000 AND
DOB > 3/5/53
GROUP BY Job;
SELECT Employee
FROM Employee
WHERE Employee.Salary >
Employee.Manager.Salary;

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

Запрос к иерархии классов может заключаться в извлечении экземпляров из класса и всех его подклассов. В следующем запросе ключевое слово ALL означает, что он будет применим к классу Person и его подклассу Employee.

SELECT Name, SSN
FROM ALL Person
WHERE Age > 50; (Age here is а method!)

Пример запроса-маршрута: "Найти имена всех сотрудников и их работодателей, которые получают более 50 тысяч долларов и увлекающихся теннисом".

SELECT *
FROM Емр1оуее
WHERE Salary > 50000 AND
Hobby.Name "Tennis";

Точечная нотация в предикате (Hobby.Name = "Tennis") расширяет стандартный синтаксис предикатных выражений, позволяя обращаться к атрибутам вложенных объектов.

Навигация по обьектам, резидентным в памяти

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

В отличие от большинства ООБД, также обеспечивающих средства управления рабочим пространством, UniSQL/X поддерживает полные средства запросов и динамического изменения схемы. Поскольку в каждый момент времени объект может находиться и в базе данных, и в рабочем пространстве, а "копия" в рабочем пространстве может быть обновлена, запрос должен быть применен к копии из рабочего пространства для тех объектов, которые туда загружены, и к копии из базы данных для объектов, отсутствующих в рабочем пространстве. Если же пользователь изменяет схему (например, удаляет атрибут из класса или добавляет новый), "копии" объектов в рабочем пространстве могут стать некорректными. В UniSQL/Х все эти обстоятельства учтены.

Средства управления рабочим пространством важны и с точки зрения превращения объектов, сгенерированных прикладными программами на объектно-ориентированных языках, в постоянные. Хотя UniSQL/Х не привязан ни к какому конкретному языку, его изощренные средства управления рабочим пространством вполне достаточны; чтобы реализовать над UniSQL/X простой транслирующий слой, поддерживающий любой объектно-ориентированный язык программирования.

Взаимодействие с реляционными базами данных

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

Система мультибаз данных (СМБД) - логически полное обобщение идеи шлюза. Фактически, это система баз данных, контролирующая несколько шлюзов. Она не имеет собственной базы данных, а просто управляет удаленными базами как "виртуальной" базой данных. Поскольку реальная база данных отсутствует, некоторые из традиционных средств, такие как методы доступа и настройка параметров производительности, становятся бессмысленными.

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

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

Посмотрим, как локальные базы данных можно было бы отобразить в глобальную. На Рис. 8 изображены схемы трех локальных баз данных (ЛБД). ЛБД1 и ЛБД2 - реляционные, а ЛБДЗ - объектно-ориентированная. Рис. 7 показывает одну из многих возможных схем глобальной ООБД, которую можно создать из этих локальных баз.

В рамках UniSQL/X это можно сделать средствами системы мультибаз данных UniSQL/M, которая интегрирует многие UniSQL/X базы данных, а также многие реляционные базы данных. Это полноценная система баз данных. Пользователи UniSQL/M могут работать с глобальной базой данных средствами языка SQL/X. UniSQL/М рассматривает глобальную базу как набор представлений, определенных над отношениями в локальных РБД и над классами локальных баз данных UniSQL/Х. Поддерживается также каталог отношений и классов локальных баз данных, их атрибутов, типов данных и методов, интегрированных в глобальную базу данных. Используя эту информацию, UniSQL/M транслирует "глобальные" запросы в эквивалентные запросы, которые могут быть обработаны локальными базами данных, управляющими соответствующей порцией данных. Драйверы передают транслированные запросы и обновления в локальные базы данных, а также возвращают результаты в UniSQL/M, где они форматируются, сливаются и подвергаются произвольной постобработке.

Производители РБД предлагают шлюзы, уровни возможностей которых сильно различаются. Некоторые шлюзы позволяют всего лишь передавать SQL-запросы иерархической системе баз данных или файловым системам. Другие в состоянии поддерживать управление распределенными транзакциями. Однако ни один из этих шлюзов не может передавать SQL-запросы в ООБД. UniSQL/M обладает тремя важными отличиями от шлюзов, предлагаемых другими производителями РБД и ООБД. Во-первых, UniSQL/М - это полноценная система баз данных, а не просто шлюз. Во-вторых, она поддерживает "распределенную обработку транзакций", то есть позволяет включать в одну UniSQL/M-транзакцию группу обновлений, относящихся к различным локальным базам данных. Наконец, UniSQL/M расширяет локальные РБД возможностями UniSQL/X, конвертируя кортежи, извлеченные из локальных баз в объекты. Таким образом, UniSQL/M делает косвенно доступными в локальных РБД основные объектно-ориентированные возможности UniSQL/X.