Объектно-ориентированные СУБД
из тех внутренних функций и механизмов, которые столь привычны и необходимы в реляционных БД.
Например, при небольшом числе пользователей, длинных транзакциях и незначительной загрузке сервера объектные СУБД не нуждаются в поддержке сложных механизмов
резервного копирования/восстановления (исторически сложилось так, что первые ООБД проектировались для поддержки небольших рабочих групп – порядка десяти
человек – и не были приспособлены для обслуживания сотен пользователей). Тем не менее технология БД определенно созрела для крупных проектов.
Для
иллюстрации первой категории рассмотрим механизм кэширования объектов. Большинство объектных СУБД помещают код приложения непосредственно в то же
адресное пространство, где работает сама СУБД. Благодаря этому достигается повышение производительности часто в 10‑100
раз по сравнению с раздельными адресными пространствами. Но при такой модели объект с ошибкой может повредить объекты и разрушить базу данных.
Существуют два подхода к организации реакции СУБД для предотвращения потери данных.
Большинство систем передают приложению указатели на объекты, и рано или поздно такие указатели обязательно становятся неверными. Так, они всегда неправильны
после перехода объекта к другому пользователю (например, после перемещения на другой сервер). Если программист, разрабатывающий приложение, пунктуален, то
ошибки не возникает. Если же приложение попытается применить указатель в неподходящий для этого момент, то в лучшем случае произойдет крах системы, в
худшем – будет утеряна информация в середине другого объекта и нарушится целостность базы данных.
Есть метод, лучший, чем использование прямых указателей (Рисунок 3). СУБД добавляет
дополнительный указатель и при необходимости, если объект перемещается, система может автоматически разрешить ситуацию (перезагрузить, если это необходимо,
объект) без возникновения конфликтной ситуации.
Существует еще одна причина для применения косвенной адресации: благодаря этому можно
отслеживать частоту вызовов объектов для организации эффективного механизма свопинга.
Это необходимо для реализации уже второго необходимого свойства баз данных – масштабируемости. Опять следует упомянуть организацию
распределенных компонентов. Классическая схема клиент-сервер, где основная нагрузка приходится на клиента (такая архитектура называется еще “толстый
клиент-тонкий сервер”), лучше справляется с этой задачей, чем мэйнфреймовая структура, однако ее все равно нельзя масштабировать до уровня предприятия.
Благодаря многозвенной архитектуре клиент-сервер (N-Tier architecture) происходит равномерное
распределение вычислительной нагрузки между сервером и конечным пользователем. Нагрузка распределяется по трем и более звеньям, обеспечивающим дополнительную
вычислительную мощность. К чему же еще ведет такая практика? “Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой, постепенно
превратилась в исключительно сложную среду. Почему? Благодаря ускоренному переходу к использованию систем клиент-сервер нескольких звеньев” (PCMagazine).
Разработчикам приходится расплачиваться дополнительными сложностями, большими затратами времени и множеством проблем, связанных с интеграцией. Оставим
очередное упоминание распределенных компонентов на этой не лишенной оптимизма ноте.
Рисунок 3 Прямая и косвенная адресации.
|
Третье необходимое качество базы данных – это отказоустойчивость. Именно это свойство отличает программный
продукт от “прилады”. Существуют несколько способов обеспечения отказоустойчивости:
резервное копирование и восстановление;
распределение компонентов;
независимость компонентов;
копирование.
Руководствуясь первым принципом, программист определяет потенциально опасные участки кода и вставляет
в программу некоторые действия, соответствующие началу транзакции – сохранение информации, необходимой для восстановления после сбоя, и окончанию транзакции –
восстановление или, в случае невозможности, принятие каких-то других мер, например, отправка сообщения администратору. В современных СУБД этот механизм
обеспечивает восстановление в случае возникновения практически любой ошибки системы, приложения или компьютера, хотя, конечно, нельзя говорить об идеальной
защите от сбоев.
В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ. При переходе к распределенной многозвенной организации
ошибки могут вызывать не только компьютеры, включенные в сеть, но и коммуникационные каналы. В многозвенной архитектуре при сбое одного из звеньев
без специальных мер результаты работы других окажутся бесполезными. Поэтому при разработке распределенных систем обеспечивается принципиально более высокий
уровень обеспечения отказоустойчивости. Назовем обязательные для современных распределенных СУБД свойства:
прозрачный доступ ко всем объектам независимо от их
местоположения, благодаря чему пользователю доступны все сервисы СУБД и может производиться перераспределение компонентов без нежелательных последствий.
так называемый “трехфазный монитор транзакций” (third-party transaction monitor), благодаря которому
транзакция выполняется не в два, а в три этапа – сначала посылается запрос о готовности к транзакции.
Что произойдет, если один из компонентов выйдет из строя? Система, созданная в соответствии только с вышеизложенными доводами,
приостановит работу всех пользователей и прервет все транзакции. Поэтому важно такое свойство СУБД, как независимость компонентов.
При сетевом сбое сеть разделяется на части, компоненты каждой из которых не могут сообщаться с компонентами другой части. Для того,
чтобы сохранить возможность работы внутри каждой такой части, необходимо дублирование критически важной информации внутри каждого сегмента. Современные
системы позволяют администратору базы данных динамически определять сегменты сети, варьируя таким образом уровень надежности всей системы в целом.
И, наконец, о копировании (replication) данных. Простейшим способом является добавление к каждому (основному) серверу резервного. После каждой
операции основной сервер передает измененные данные резервному, который автоматически включается в случае выхода из строя основного. Естественно, такая
схема не лишена недостатков. Во-первых, это приводит к значительным накладным расходам при дублировании данных, что не только сказывается на
производительности, но и само по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя, повлекшего за собой разрыв соединения между двумя
серверами, каждый из них должен будет работать в своем сегменте сети в качестве основного сервера, причем изменения, сделанные на серверах за время работы в
таком режиме, будет невозможно синхронизовать даже после восстановления работоспособности сети.
Более совершенным является подход, когда создается необходимое (подбираемое в соответствии с требуемым уровнем надежности) число
копий в сегменте. Таким образом увеличивается доступность копий и даже (при распределении нагрузки между серверами) повышается скорость чтения. Проблема
невозможности обновления данных несколькими серверами одновременно в случае их взаимной недоступности решается за счет разрешения проведения модификаций
только в одном из сегментов, например имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования затраты на накладные расходы при
дублировании модифицированных данных близки к нулю.
5.3 Стандарты
объектных баз данных.
Для обеспечения переносимости приложений (приложение может работать на разных СУБД) и совместимости с СУБД (может взаимодействовать с
разными СУБД), естественно, необходима выработка стандартов. Сразу заметим, что установление стандартов лишает производителя в некоторой степени свободы в
принятии решений и увеличивает стоимость продукта за счет лицензионных отчислений и больше не будем обсуждать целесообразность (прямо скажем,
очевидную) стандартизации.
В области объектных СУБД в настоящее время выработаны стандарты для:
объектной модели;
языка описания объектов;
языка организации запросов (Object Query Language – OQL);
“связующего” языка (C++ и, конечно же, Smalltalk);
администрирования;
обмена (импорт/экспорт);
интерфейсов инструментария и др.
Хотя у Microsoft и свое мнение на этот счет, организацией, выработавшей наиболее используемые на
сегодня и устоявшиеся стандарты, является консорциум поставщиков ООСУБД ODMG (ООСУБД), которого поддерживают
практически все действующие лица отрасли. В сотрудничестве с OMG, ANSI, ISO и другими
организациями был создан стандарт ODMG-93. Этот стандарт включает в себя средства для построения
законченного приложения, которое будет работать (после перекомпиляции) в любой совместимой с этой спецификацией ООСУБД. В книгу ODMG-93 входят следующие разделы:
Язык определения объектов (Object Definition Language – ODL);
Язык объектных запросов (Object Query Language – OQL);
Рисунок 4 Схема использования ODL для построения приложения.
|
Связывание с C++;
Связывание со Smalltalk.
ODL. В качестве языка определения объектов (ODL) ODMG был выбран существующий язык IDL
(Interface Definition Language – язык описания интерфейсов), который был дополнен такими необходимыми для
объектных БД свойствами, как определение коллекций, двунаправленных связей типа “многие-ко-многим”, ключей и др. В сочетании со средствами языка IDL определения атрибутов и операций, это позволяет определять практически любые объекты. Все дополнения реализованы в виде
доопределения методов, что обеспечивает совместимость со стандартами OMG, например стандартом CORBA.
Рисунок 4 показывает работоспособную схему для построения приложения на стандартных языках программирования, в процессе которой автоматически
генерируются метаданные, заголовочные файлы и методы. Приведем также пример на языке ODL из “белой книги” компании Objectivity, который
иллюстрирует связи типа “один-ко-многим”, объявленные между преподавателем и студентами:
interface professor : employee {
attribute string name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set
teaches inverse taught_by; . . . operations . . .
{
interface section :>
. . . taught_by: professor . . . ;
. . .
}
OQL. За основу языка OQL была взята команда SELECT языка SQL2 (или SQL-92) и добавлены возможность
направлять запрос к объекту или коллекции объектов и возможность вызывать методы в рамках одного запроса. Данные, полученные в результате запроса, могут
быть скалярными (включая кортежи), объектами или коллекциями объектов. Некоторые примеры на
языке OQL (тот же источник):
• Select x from x in faculty where x.salary >
x.dept.chair.salary
•
sort s in (select struct (name: x.name, s:x.ssn) from
x in faculty where for all y in
x.advisees:y.agename="Smith";
prof->age+prof->age+1;
На этом, пожалуй, чувство благодарности компании Objectivity в значительной мере ослабеет, так как примеров на языке Smalltalk найти не удалось.
Smalltalk. ODMG-93 поддерживает ту же объектную модель для Smalltalk, что и для С++, IDL и запросы на языке OQL; это позволяет разделять
один и тот же объект пользователям С++ и Smalltalk. Спецификация поддерживает типы (возможны бестиповые поля) и синтаксис оригинальной версии Smalltalk.
Рисунок 5 ООСУБД, построенная на основе стандартов ODMG во взаимодействии с CORBA.
|
Взаимодействие с другими стандартами. Многие стандарты совместимы с объектными базами данных, например STEP, CFI,
TINA-C, ISO ODP, ANSI X3H7, OpenGIS и др. Сейчас они могут напрямую взаимодействовать с любой стандартной ООСУБД, хотя в некоторые из них и были
внесены изменения для обеспечения совместимости. Два других стандарта заслуживают более детального описания – OMG
и SQL.
Стандарты OMG. Первым результатом деятельности OMG стало утверждение (OMG не создает стандартов, а
принимает одну из существующих реализаций) Архитектуры Брокера Объектных Запросов (Common Object Request Broker Architecture – CORBA) –
средства диспетчеризации запросов между объектами и пользователями; в дальнейшем были добавлены некоторые сервисы. Интерфейс ODMG сейчас полностью
адаптирован к спецификации Persistence Object Service консорциума OMG, что позволяет пользователям систем, основанных на архитектуре
CORBA, пользоваться преимуществами от ООСУБД, которые могут содержать объекты, отвечающие стандарту OMG и используемые так же, как и любые другие (“мелкие”)
объекты спецификации OMG (Рисунок 5). Объекты OMG в свою очередь доступны через интерфейс ODMG.
Язык SQL. Из-за распространенности SQL был заложен в основу OQL,
который был дополнен средствами поддержки объектной модели. В настоящее время разрабатывается версия языка SQL,
известная под названием SQL3, в которой будут реализована поддержка объектов и SQL будет приведен в соответствие современным понятиям о полноценном языке
программирования. В отличие от ODMG, в SQL не планируется привязка к ODL, а также C++ и Smalltalk, которые
важны для пользователей ООСУБД. Несмотря на это, возможности SQL3 в организации запросов совпадают с возможностями OQL. Когда SQL3 будет готов (разработки ведутся сейчас на ранней
стадии обсуждения основных вопросов относительно объектной модели), ODMG, вероятно, дополнит его, как это уже сделано для С++ и Smalltalk.
5.4
Поставщики ООСУБД.
Рисунок 6 Современный рынок СУБД.
|
Список современных коммерческих объектно-ориентированных систем включает в себя следующие продукты:
Objectivity/DB компании Objectivity, Inc. (последняя версия – 2.1) идеально, по
заявлениям фирмы, подходит для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, а также
нуждаются в высокой производительности и работы с большими объемами данных. Вероятно, все компании, производящие ООСУБД, ставят своей целью сложить такое
впечатление относительно собственных разработок у читателей распространяемых ими документов (хотя некоторые и делают это в более деликатной форме). Более
содержательно, Objectivity обеспечила интеграцию инструментария СУБД и разработки приложений с такими
средствами программирования, как SoftBench и C++ SoftBench. Благодаря интегрированному графическому интерфейсу разработки схемы БД и инструментам
отладки и анализа упрощается задание модели базы данных и, соответственно, разработки приложений для Objectivity/DB.
СУБД GemStone корпорации GemStone Systems, Inc. известна
в последней редакции под номером 5.0. GemStone традиционно сосредоточена на рынке Smalltalk (хотя не так давно и была выпущена версия для С++) и имеет
заказчиков, способных продемонстрировать на производстве крупномасштабные, целевые применения ее продуктов. К сожалению, списком этих заказчиков объем
информации, которую компания хочет донести до интересующихся (WWW), ограничивается.
ONTOS Corp., разработчик СУБД ONTOS (кто бы
подумал), по традиции занимается развитием сервера объектно-ориентированной СУБД, но в последнее время придает особое значение своим Службам Интеграции
Объектов (Object Integration Services).
Построенная на основе реляционной СУБД AllBase, система OpenODB фирмы Hewlett-Packard также, как и Objectivity/DB,
интегрирована с системой SoftBench и существует в версии для С++. Благодаря глубокой интеграции, SoftBench распознает файлы приложений OpenODB для установки оптимальной
конфигурации, может создавать базы данных формата OpenODB из своей интегрированной среды, обеспечивает оперативную помощь из среды разработки и т. д.
Object Design Inc. со своей СУБД ObjectStore занимает
лидирующее положение в отрасли, осуществляя около 33% поставок на рынке объектно-ориентированных СУБД и последняя модернизация системы (клиент языка
SQL и шлюз к реляционной СУБД) должны только укрепить положение фирмы. Object Design поддерживает версии
своей СУБД как для С++, так и для Smalltalk.
Versant Object Technology, Inc. (СУБД Versant) проводит двойную
стратегию, предлагая средство обеспечения объектно-ориентированной СУБД высокого класса для телекоммуникаций и инструментальные средства Smalltalk для
более общих случаев разработки приложений. Используя разработанный фирмой интерфейс VERSANT Smalltalk Language Interface, СУБД совместима как с версией
языка Smalltalk компании ParcPlace-Digitalk, так и с Visual Age for Smalltalk корпорации IBM.
СУБД UniSQL компании UniSQL Inc. – хорошо
устоявшаяся система, позволяющая пользователям осуществлять запросы и модификацию базы при помощи