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

8.1.3. Преобразование реляционного подхода к организации баз данных в объектно-реляционный подход

Мы уже отмечали в начале этого раздела, что радикальным решением всех проблем, свойственных реляционным системам, был бы революционный переход к объектно-ориентирован- ной организации как баз данных, так и систем управления ими. Мы перечислили ряд причин, по которым массовых потребителей баз данных не устроила эта возможная революция. Но дело не только в этом. В конце 1989 г. группа ведущих специалистов в области объектно-ори- ентированных баз данных опубликовала "Манифест объектно-ориентированных баз данных" (перевод на русский язык опубликован в журнале "СУБД", N 4, 1995 г.).

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

Объектно-реляционный подход возник как эволюционная альтернатива революционному объектно-ориентированному подходу. Заметим, что термин "объектно-реляционные СУБД" вошел в обиход далеко не сразу, и даже сейчас системы соответствующего класса часто характеризуются другими терминами. Точкой отсчета можно считать опубликование в 1990 г. "Манифеста систем баз данных третьего поколения" (перевод на русский язык опубликован в журнале "СУБД", N 2, 1995 г.). В этом манифесте выдвигалась идея и обосновывались преимущества эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения. Частично требования к системам следующего поколения включали просто необходимость реализации давно известных свойств, которые отсутствовали в большинстве текущих реляционных СУБД (ограничения целостности общего вида, триггеры, модификация БД через представления и т.д.). В число новых требований входили полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.

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

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

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

8.1.4. Первые серверные продукты, поддерживающие объектно-реляционный подход

С конца 1996 г. три компании объявили о выпуске серверных продуктов, соответствующих названию "универсальный сервер": Oracle с продуктом Oracle 8, Informix с продуктом InformixUniversalServer и IBM с продуктом DB2 UniversalDatabase. Далее мы приведем краткие характеристики этих систем.

8.1.4.1. Oracle 8

Компания Oracle заявляла, что Oracle 8 будет уметь делать с объектами все, что умеет делать InformixUniversalServer, и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был официально объявлен 24 июня 1997 г.). В фокусе Oracle 8 находятся расширенная система типов и поддержка бизнес-объектов; появление других возможностей расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации своей сетевой вычислительной архитектуры (NCA - NetworkComputingArchitecture), и в Oracle 8 вносятся улучшенные возможности производительности, масштабируемости, доступности, репликации, разделения дан- ных и т.д.

NCA - это трехзвенная архитектурная структура, основанная на CORBA (CommonObjectRequestBrokerArchitecture - Общая архитектура брокера объектных заявок). В NCA используются расширяющие компоненты, называемые "картриджами", которые могут разрабатываться Oracle или сторонними поставщиками. Впервые использование картриджей приложений и картриджей баз данных потребовалось в OracleWebApplicationServer для организации связи на основе CORBA. В контексте расширяемой среды данных Oracle обеспечивает компоненты на уровне промежуточного программного обеспечения приложений (например, компонент управления транзакциями в WebApplicationServer) и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8 поддерживает объектные представления данных с использованием новых объектных типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает объектный кэш на стороне клиентов и навигацию между объектами по ссылкам. Транслятор объектных типов отображает объекты базы данных в соответствующие конструкции языка Си.

Далее приводится сводка свойств, имеющихся в Oracle 8 и ожидаемых в версии 8.1:

Расширяемая система типов. Поддерживаются объектные типы, типы коллекций (массивы переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип может применяться либо к столбцу, либо к строке и может быть семантически эквивалентен именованному строчному типу SQL-3. Кроме того, Oracle 8 явно связывает с объектными типами методы. Пока поддерживается только один уровень вложенности таблиц (в 8.0) и не реализована полная инкапсуляция определяемых пользователями типов данных. В версии 8.1 будет поддерживаться одиночное наследование. Не предполагается возможность репликации расширенных данных. Определяемые пользователями функции. Скалярные функции, перегрузка и разрешение имени на основе типов параметров, параллельное выполнение функций с определенными пользователями агрегатами (функции столбцов) находятся в стадии обсуждения. Расширяемая система индексации. Поддержка определяемых пользователями индексных структур и индексов на выражениях появится вместе с компонентом DatabaseExtensibilityServices. Расширяемый оптимизатор. Возможность указывать стоимость выполнения определенных пользователями функций и обеспечивать статистику об использовании определенных пользователями данных ожидается с появлением компонента DatabaseExtensibilityServices. К расширенным типам пока не применяются параллельные операции. Большие объекты и внешние данные. LOB могут храниться внутри базы данных или во внешних файлах. Oracle 8 не поддерживает доступа по записи к внешним данным и не гарантирует их целостность. Большие объекты могут быть реплицированы, но таблицы с LOB реплицировать нельзя. Расширяемая языковая поддержка. Определяемые пользователями типы данных и хранимые процедуры пишутся на PL/SQL или Си/Си++, причем подпрограммы на Си/Си++ выполняются вне адресного пространства сервера. Поддержка Java в сервере будет обеспечиваться в DatabaseExtensibilityServices (версия 8.1). Предопределенные расширения. Сервер Oracle 8 поддерживает хранение текстовых, пространственных и видео данных; ожидается появление нового типа данных для хранения графической информации. Компания работает также с несколькими партнерами для тестирования и формализации API для DatabaseExtensibilityServices и разработки картриджей данных.

Как видно, в Oracle 8 компания главным образом сосредоточилась на реализации собственных расширений, которых может оказаться достаточно для начала моделирования бизнес-объектов. Возможности реализации расширений сторонними компаниями менее развиты, чем в продуктах Informix и IBM. Это означает, что пользователи Oracle будут вынуждены более долго ожидать наличия полных наборов строительных блоков для построения новых или улучшения существующих приложений. С другой стороны, развитие продуктов Oracle происходит на основе единой архитектуры NCA, которая закладывает базу расширяемости.