Объектные СУБД

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

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

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

 

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

Список современных коммерческих объектно-ориентированных систем включает в себя следующие продукты:5

• Objectivity/DB компании Objectivity, Inc. (последняя версия – 2.1) идеально, по заявлениям фирмы, подходит для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, а также нуждаются в высокой производительности и работы с большими объемами данных. Objectivity обеспечила интеграцию инструментария СУБД и разработки приложений с такими средствами программирования, как SoftBench и C++ SoftBench. Благодаря интегрированному графическому интерфейсу разработки схемы БД и инструментам отладки и анализа упрощается задание модели базы данных и, соответственно, разработки приложений для Objectivity/DB.
• СУБД GemStone корпорации GemStone Systems, Inc. известна в последней редакции под номером 5.0. GemStone традиционно сосредоточена на рынке Smalltalk (хотя не так давно и была выпущена версия для С++) и имеет заказчиков, способных продемонстрировать на производстве крупномасштабные, целевые применения ее продуктов.
• ONTOS Corp., разработчик СУБД ONTOS, по традиции занимается развитием сервера объектно-ориентированной СУБД, но в последнее время придает особое значение своим Службам Интеграции Объектов (Object Integration Services).
• Построенная на основе реляционной СУБД AllBase, система OpenODB фирмы Hewlett-Packard также, как и Objectivity/DB, интегрирована с системой SoftBench и существует в версии для С++. Благодаря глубокой интеграции, SoftBench распознает файлы приложений OpenODB для установки оптимальной конфигурации, может создавать базы данных формата OpenODB из своей интегрированной среды, обеспечивает оперативную помощь из среды разработки и т. д.
• Object Design Inc. со своей СУБД ObjectStore занимает лидирующее положение в отрасли, осуществляя около 33% поставок на рынке объектно-ориентированных СУБД и последняя модернизация системы (клиент языка SQL и шлюз к реляционной СУБД) должны только укрепить положение фирмы. Object Design поддерживает версии своей СУБД как для С++, так и для Smalltalk.
• Versant Object Technology, Inc. (СУБД Versant) проводит двойную стратегию, предлагая средство обеспечения объектно-ориентированной СУБД высокого класса для телекоммуникаций и инструментальные средства Smalltalk для более общих случаев разработки приложений. Используя разработанный фирмой интерфейс VERSANT Smalltalk Language Interface, СУБД совместима как с версией языка Smalltalk компании ParcPlace-Digitalk, так и с Visual Age for Smalltalk корпорации IBM.
• СУБД UniSQL компании UniSQL Inc. – хорошо устоявшаяся система, позволяющая пользователям осуществлять запросы и модификацию базы при помощи разработанного компанией языка SQL/X (подобные языки, носящие условное название Object SQL, разработаны и некоторыми другими поставщиками). Вся БД UniSQL может состоять одновременно из связей в локальных РСУБД и классов в локальных объектных базах UniSQL. Благодаря механизму каталогов, СУБД передает запросы и модификации данных в локальные базы данных и, обработав (перевод в другой формат, группирование, сортировка и т. д.) полученный от них результат, возвращает его пользователю.

Кроме того ООСУБД предлагают: Object Database, Inc. (Object Database), Itasca Systems Inc. (Itasca) O2 Technology (O2) и некоторые другие компании.

 

 

 

 

 

3. Объектно-реляционные СУБД

 

3.1 История появления объектно-реляционных СУБД

 

Два весьма известных специалиста в области технологии баз данных – Майкл Стоунбрейкер и Вон Ким – оспаривают пальму первенства в направлении  объектно-реляционных СУБД (ОРСУБД). Стоунбрейкер начал работать в области баз данных в начале 70-х гг. прошлого века в университете Беркли. Его первым всемирно известным проектом была СУБД Ingres, которая существует и используется до сих пор в двух ипостасях – как свободно распространяемая система (университетская Ingres; код поддерживается в Беркли) и как коммерческая СУБД, принадлежащая компании Computer Associates. В исходном варианте СУБД  Ingres отсутствовала поддержка языка SQL (поддерживался собственный язык запросов QUEL ), но система уже обладала некоторыми уникальными чертами, которые, с некоторой натяжкой, можно было бы назвать объектными (например, в СУБД Ingres допускалось определение пользовательских процедур, выполняемых на стороне сервера). Кроме того, в проекте Ingres очень большое внимание уделялось управлению правилами. 6

В 80-е годы Майкл Стоунбрейкер возглавлял проект Postgres (вариант этой системы под названием PostgreSQL до сих пор является весьма популярным свободно доступным продуктов). В Postgres были реализованы многие интересные средства: поддерживалась темпоральная модель хранения и доступа к данным, и в связи с этим был абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивался мощный механизм ограничений целостности; поддерживались ненормализованные отношения (работа в этом направлении началась еще в среде Ingres), хотя и довольно странным способом: в поле отношения может храниться динамически выполняемый запрос к БД.

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

В 90-е гг. Стоунбрейкер создал компанию Illustra , основной целью которой был выпуск коммерческого варианта СУБД Postgress , получившего название Illustra.  В этой системе поддерживались основные идеи Postgres, но уже присутствовала и поддержка языка SQL . В конце 1995 г. компания Illustra была поглощена компанией Informix , и это привело к выпуску в 1996 г. СУБД Informix Universal Server .

Имя Вона Кима стало широко известно во второй половине 70-х гг., когда он примкнул к участию в экспериментальном проекте компании IBM System R . Наиболее известная ранняя работа доктора Кима была посвящена преобразованию SQL -запросов с целью превращения запросов с вложенными подзапросами в запросы с соединениями.

В 80-е гг. Вон Ким работал в компании MCC , где успешно выполнил реализацию серии прототипов ООСУБД  Orion . В этих прототипах были опробованы многие идеи объектно-ориентированных СУБД. Одной из интересных особенностей проекта было то, что в качестве основного языка программирования использовался объектный вариант известного функционального языка Lisp . 7

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

UniSQL обеспечивает возможность построения  так называемых федеративных систем баз данных. При этом предоставляется единое представление данных, которые могут храниться либо в базе данных, непосредственно управляемой UniSQL , либо в какой-либо из реляционных баз данных, управляемой СУБД Oracle , Informix , Sybase и т.д., либо в какой-либо дореляционной базе данных. Сервер UniSQL обеспечивает интегрированный доступ к данным, управляемым разными СУБД.

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

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

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

3.2 Объектно-реляционные методы.

Несмотря на недостатки реляционных баз данных, они обладают рядом достоинств:

• разделение таблиц разными программами;
• развернутый “код возврата” при ошибках;
• высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);
• сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения;
• относительно высокая скорость при работе с большими объемами данных.9

Кроме того, во всем мире значительные средства уже инвестированы в реляционные СУБД. Многие организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся.

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

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

Некоторые объектные СУБД, например, GemStone компании GemStone Systems, могут сами исполнять роль мощного объектно-реляционного адаптера, позволяя объектно-ориентированным приложениям обращаться к реляционным БД.

Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например, в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.

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

Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД. Еще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версиях СУБД ввести поддержку объектов. Подобные разработки намерены вести и независимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствами СУБД Oracle8.

Заключение

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

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

В настоящий момент ощущается настоятельная потребность в интеграции ООСУБД с существующими инструментальными средствами. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или Delphi, поддерживающие ООСУБД. Большинство продуктов для создания приложений в той или иной мере являются объектно-ориентированными, но работают по-прежнему с реляционными БД. Специалисты считают, что партнерство производителей ООСУБД и средств программирования способно привести к появлению столь необходимого инструментария.

 

 

Глоссарий

№ п/п		Понятие	Определение
1		Объектно-реляционные методы	Object-relational Approaches). Подходы, позволяющие воспользоваться преимуществами объектных баз данных, не отказываясь полностью от реляционных БД.
2		Транзакция	(Transaction) – обработка запроса. Выполнение  элементарной целостной операции  над данными, в течение которой база данных находится в неустойчивом состоянии.
3	4GL		(4th Generation Language) – Язык программирования четвертого  поколения. Язык программирования, при создании которого используются  языки программирования третьего  уровня (3GL)–процедурные языки типа C и Pascal. 4GL проще в использовании, чем 3GL, им обычно отдают предпочтение при составлении программ обслуживания баз данных и применяют в сочетании с соответствующими средствами разработки.
4	Blob		(Binary Large Object) – Двоичный большой объект. Длинный линейный блок данных (например, цифровое изображение или видеоклип), который наиболее подходит для хранения в ООСУБД
5	DBMS		(Database Management System) – Система управления  базами данных
6	ODBMS		(Object Database Management System) – Объектно-ориентированная СУБД – ООСУБД.  СУБД, хранящая данные и взаимосвязи между ее элементами непосредственно в самой базе данных в виде объектов, содержащих, как правило, алгоритмы обработки этих данных.
7	ODMG		(Object Database Management Group) -Консорциум производителей объектных баз данных для выработки стандартов (ODMG-93, ODMG-95).
8	OMG		(Open Management Group) -Консорциум поставщиков в сфере  объектной технологии для выработки  стандартов межкомпонентного взаимодействия. Объединяет практически всех ведущих производителей (более чем 500).
9	OQL		(Object Query Language) -Язык объектных запросов. Разработанный консорциумом ODMG язык описания запросов, за основу которого был принят SQL-92.
10	RDBMS		(Relational Database Management System) – Реляционная СУБД – СУБД, хранящая взаимосвязи между элементами в виде двумерных таблиц и использующая для запросов языкSQL.
11	SQL		(Structured Query Language) – Язык структурированных запросов. Интерпретируемый язык, описывающий  операции (создание, обработка и  извлечение) над реляционными базами данных.
12	Архитектура клиент-сервер		Client-server architecture). Архитектура, обеспечивающая распределение нагрузки между клиентом и сервером. Обычно эти функции выполняют два разных компьютера, объединенных при помощи сети.