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

С.Д. Кузнецов
Институт системного программирования РАН

Назад   Оглавление   Вперед

3. Первые реализации

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

3.1 Informix Universal Server

Итак, первой системой, выпущенной на рынок в качестве РСУБД крупной софтверной компанией, стал Informix Universal Server (IUS). Это произошло в конце декабря 1996 г. – начале января 1997 г. и является основным поводом для отмечания 10-летнего юбилея подхода. IUS было посвящено много публикаций, в том числе, очень содержательные статьи [4-5]. Однако здесь я не буду следовать порядку изложения, принятому в этих статьях, а напишу так, как мне представляется правильным сегодня.

3.1.1 Интеллектуальные большие объекты

Интеллектуальные большие объекты (smart large objects), поддерживаемые в IUS, позволяли снять неприятные реализационные ограничения, характерные для трактовки больших объектов (BLOB или CLOB) реляционными СУБД. Интеллектуальные большие объекты могли подвергаться журнализации и откату, что важно для сохранения целостности и доступности данных.

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

3.1.2 Определение новых базовых типов данных

СУБД IUS позволяла вводить новые базовые типы данных. При этом можно использовать встроенные в IUS методы доступа и хранения, а также определять новые.

Индивидуальные типы

В IUS можно было определить новый базовый тип данных (индивидуальный тип данных, distinct type), основанный на существующем типе, но обеспечивающий автоматическое преобразование к нужному значению (за счет явного определения соответствующих функций). В очень близкой форме средства определения индивидуальных типов позже были введены в стандарт SQL.

Типы со скрытой структурой

В соответствии с идеологией IUS, потребность во введении нового базового типа данных может возникать и по причине принципиального отсутствия нужного типа. Для этого поддерживался механизм определения типов со скрытой структурой (opague type). Типы со скрытой структурой являлись абстрактными в строгом смысле этого слова. СУБД IUS была лишена какой-либо информации о внутреннем устройстве этих типов и могла манипулировать соответствующими значениями только посредством предоставленных разработчиком функций.

Чтобы определить новый тип данных со скрытой структурой, требовалось выполнить следующую последовательность действий:

• описать на языке C (или другом внешнем языке) структуру определяемых объектов;
• написать на языке C (или другом внешнем языке) вспомогательные функции, вызываемые сервером СУБД;
• зарегистрировать определяемый тип в базе данных посредством оператора CREATE OPAQUE TYPE;
• зарегистрировать вспомогательные функции посредством операторов CREATE FUNCTION и CREATE CAST;
• предоставить права доступа к определяемому типу и его вспомогательным функциям посредством оператора GRANT;
• написать требующиеся для приложения дополнительные функции, которые можно вызывать средствами SQL, и зарегистрировать их;
• если нужно, реализовать специфические для определяемого типа вторичные методы доступа (функции для работы с индексами).

После определения нового типа со скрытой структурой его можно было использовать наравне с другими базовыми типами. Для хранения, поиска и индексирования можно было использовать стандартные механизмы IUS.

Специальные методы хранения, поиска и индексации

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

Заметим, что какая-либо поддержка типов данных со скрытой структурой в других реализациях ОРСУБД или в стандарте SQL отсутствует. Это первый пример уникальных возможностей IUS, связанных, по моему мнению, с архитектурными особенностями линии СУБД Ingres-Postgres-Illustra.

3.1.3 Составные типы данных

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

Тип данных со структурой записи

В SQL IUS тип данных со структурой записи определялся с использованием оператора

CREATE ROW TYPE <имя типа> ( <имя поля> <тип поля>, …)

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

CREATE TABLE <имя таблицы> OF TYPE <имя типа>;

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

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

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

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

Наследование таблиц являлось развитием концепции наследования типов. В иерархии наследования могли участвовать только типизированные таблицы, типы которых (типы записи) образуют параллельную иерархию. Однако, кроме столбцов супертаблиц, подтаблицы наследовали ограничения целостности (первичные ключи, уникальность, ссылочные ограничения), опции хранения, триггеры, индексы и методы доступа.

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

В IUS операции SELECT, UPDATE и DELETE, примененные к супертаблице, распространяются также и на все ее подтаблицы. Если требовалось ограничить запрос ровно одной супертаблицей, следовало употребить в запросе конструкцию ONLY.

Типы коллекций

В SQL IUS имелась возможность определения трех видов типов коллекций: множеств, мультимножеств и списков (иными словами, имелись конструкторы, или генераторы этих типов). Тип множества определялся с помощью конструкции

CREATE TYPE <имя типа> SET <тип элементов> NOT NULL

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

Типы мультимножеств определялись с помощью конструкции

CREATE TYPE <имя типа> MULTISET <тип элементов> NOT NULL;

Хотя по определению среди элементов мультимножества могут содержаться дубликаты, в IUS значения типа мультимножества, как и значения-множества не могли содержать неопределенных значений.

Значения типа множества и мультимножества можно было использовать после предиката IN в разделе WHERE оператора SELECT. К этим значениям была применима функция CARDINALITY, возвращающая число элементов. Средствами прямого SQL можно было осуществлять доступ к значениям-множествам (и мультимножествам) только как к единому целому. Доступ к элементам множества был возможен только при использовании встраиваемого SQL IUS или языка определения хранимых процедур (SPL). Основная идея состояла в том, что множество представлялось в виде производной таблицы, каждая строка которой содержала один элемент множества. Любую операцию над множествами можно было выразить в терминах реляционных операций над производными таблицами.

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

CREATE TYPE <имя типа> LIST <тип элементов> NOT NULL

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

3.1.4 Модули DataBlade

Модуль DataBlade – это функционально законченное расширение сервера IUS, рассчитанное на определенное приложение или класс приложений. C модулями DataBlade не были связаны какие-то особые возможности сервера или языковые конструкции. Такие модули строились из компонентов, описанных выше, то есть из определяемых разработчиком подпрограмм, типов и структур данных, методов доступа и других объектов, хранящихся в базах данных. Создание и сопровождение модулей DataBlade в IUS поддерживалось путем предоставления соответствующего инструментария – среды разработки, «упаковщика» модулей, утилиты регистрации, прикладного программного интерфейса.

3.2 Oracle8

Компания Oracle выпустила свою первую ОРСУБД Oracle8 в июне 1997 г. Эта система во многом базировалась на возможностях СУБД Oracle 7.3, которая, по моему мнению, была одним из наиболее удачных продуктов компании Oracle. Существенные дополнения к объектно-реляционным возможностям Oracle8 появились лишь в системе Oracle 9i (2002 г.). Здесь мы ограничимся обсуждением свойств Oracle8. Заметим, что Oracle8 было посвящено не слишком много публикаций, доступных на русском языке. Пожалуй, можно рекомендовать только [6].

3.2.1 Объектные типы и объектные таблицы

Объектные типы в Oracle8 являлись аналогом типа записи в IUS. Объектный тип данных определялся в следующем синтаксисе:

CREATE TYPE <имя типа> AS OBJECT ( <имя поля> <тип поля>, …);

Как и в IUS, для доступа к отдельным полям значений объектных типов использовалась точечная нотация.

Методы объектных типов

В Oracle 8i при определении объектного типа, помимо спецификации структуры значений этого типа, можно было определить и набор методов данного типа. Методы представляли собой функции, написанные на PL/SQL, Java, C или другом языке и сохраненные в базе данных или вне ее (при наличии регистрации в базе данных).

Методы объектного типа разбивались на три категории: методы-члены, статические методы и методы сравнения.

Методы-члены вызывались в нотации

<имя_объекта>.<имя_метода> ( список_параметров ).

У них имелся неявный параметр SELF, и они могли обращаться к значениям атрибутов объекта. Под термином объект здесь понимается строка объектной таблицы. Как правило, именем объекта являлось имя объектной таблицы или ее псевдонима, используемые в операторе выборки SQL.

Статические методы вызывались в нотации

<имя_объектного_типа>.<имя_метода> ( список_параметров )

и не могли обращаться к значениям атрибутов конкретных объектов.

Методы сравнения служили для сравнения экземпляров объектов. Сравнение объектов могло производиться с помощью методов вида MAP или вида ORDER. Метод типа MAP принимает в качестве параметра объект некоторого объектного типа, а возвращает значение одного из встроенных типов, которое может использоваться в операциях сравнения и сортировки. Таким образом, этот метод выполняет отображение объекта на значение одного из встроенных типов. Метод типа ORDER сравнивает два объекта и возвращает –1, если первый объект меньше второго, 0, если объекты равны, и 1, если первый объект больше второго.

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

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

Объектные таблицы, ссылочные типы

Объектной таблицей в Oracle8 называлась таблица, строки которой имеют объектный тип. Синтаксис определения был близок к синтаксису определения типизированных таблиц в IUS.

В Oracle8 не поддерживалось наследование (ни типов, ни таблиц), однако уже в Oracle8i (начало 1998 г.) появилась возможность наследования таблиц почти в той же форме, как это делалось в IUS, но без поддержки параллельной иерархии наследования объектных типов.

В Oracle8 строки объектных таблиц назывались строчными объектами (row objects). Для всех строчных объектов обеспечивалась возможность уникальной идентификации. Использовалось понятие объектного идентификатора, и столбец любой таблицы можно было определить на встроенном типе REF. Значения этого столбца являлись своего рода указателями на строчные объекты той же самой или другой объектной таблицы.

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

Считается, что REF-значение, указывающее на некоторый строчный объект, и сам этот строчный объект имеют разные, хотя и связные типы данных. Система не брала на себя ответственность за согласование ссылок; за это отвечали пользователи. В SQL Oracle8 поддерживалась встроенная функция REF, позволяющая получить значение объектного идентификатора указанной строки. Наличие в объектной таблице столбцов ссылочного типа позволяло в ряде случаев упрощать формулировку запросов (в духе путевых выражений ODMG). Кроме того, как утверждает компания Oracle, при явном использовании объектных идентификаторов (т.е. RowID) удается повысить эффективности выполнения ряда запросов.

3.2.2 Типы коллекций в Oracle8

В Oracle8 поддерживались две разновидности типов коллекций: табличные типы (table types) и типы массивов (array types). Значениями каждого типа коллекции являлись коллекции (таблицы или массивы) элементов одного и того же типа (типа элемента). Тип элемента мог быть встроенным или объектным типом, но не типом коллекции.

Табличный тип

Табличный тип создавался конструкцией следующего вида:

CREATE TYPE <имя типа> AS TABLE OF <тип элемента>;

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

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

Тип массива

Вторая, менее привязанная к особенностям реализации, разновидность типов коллекций в Oracle8 называлась VARRAY, что вполне соответствует стандарту SQL:1999 и означает массив переменного размера (varying-length array). При определении типа массива указываются имя типа, тип элементов и максимальное число элементов, которые может содержать значение определяемого типа. В отличие от значений табличного типа, для элементов значений типа массива поддерживается порядок. Для определения типа массива использовалась следующая синтаксическая конструкция:

CREATE TYPE <имя типа> AS VARRAY ( <литеральное натуральное число> ) OF <тип элемента>;.

Как и в случае с множествами (и мультимножествами) в IUS, на уровне прямого SQL Oracle8 можно было работать только с массивами целиком. Однако существовала возможность привести в запросе (или другом операторе SQL) тип массива к табличному типу.

Как уже говорилось, в Oracle8 отсутствовала поддержка наследования, и запрещалось определение типов коллекций с использованием ранее определенных типов коллекций. Соответствующие возможности появились только в Oracle 9i (2002 г.).

3.3 DB2 Universal Database

Компания IBM последней, после Informix и Oracle, объявила свой объектно-реляционный продукт (в конце 1998 г.) и назвала его DB2 Universal Database (UDB). Однако, как стало ясно немного позже, базовые идеи объектно-реляционных расширений были заложены еще в продукте компании IBM DB2 for Common Servers, выпущенном в 1995 г. Эти идеи описаны в статье [7]. Насколько мне известно, первой публикацией на русском языке, посвященной непосредственно DB2 Universal Database, является [8].

3.3.1 Базовые идеи объектно-реляционных расширений DB2

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

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

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

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

Система, которая обеспечивает объектную инфраструктуру и набор реляционных расширителей, называется объектно-реляционной.

Объектная инфраструктура

В DB2 поддерживались три типа данных для хранения больших объектов: BLOB для бинарных объектов, CLOB для символьных строк и DBCLOB для строк, в которых используются двухбайтовые наборы символов. Для каждого из этих типов данных можно было хранить объекты объемом до 2 Гбт. Подсистема восстановления DB2 давала возможность создателю таблицу выключать обычную журнализацию изменений столбцов с большими объектами. При выключенной журнализации по отношению к таким столбцам гарантировалась согласованность транзакций, но столбец не мог участвовать в процедуре прямого восстановления.

Пользователи DB2 имели возможность создания собственных функций с использованием языков C, C++ и Basic. Вызовы определяемых пользователями функций (User-Defined Functions, UDF) могли использоваться в любом выражении SQL, где предполагалось наличие скалярного значения. В SQL DB2 можно было перегружать имя функции, т.е. определять несколько функций с одним именем и разными типами параметров. При обработке вызова функции DB2 вызывала функцию, сигнатура которой строго соответствовала типам аргументов вызова.

В DB2 определяемые пользователями типы данных назывались индивидуальными типами (distinct type). В каждом из индивидуальных типов использовалось общее представление одного из встроенных типов (называемых базовыми типами), но мог иметься собственный набор допустимых операций. При создании индивидуального типа DB2 генерировала функции, преобразующие значение индивидуального типа в значение его базового типа и наоборот.

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

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

Реляционные расширители

На основе представленной выше объектной инфраструктуры можно было создавать реляционные расширители (extender) для поддержки конкретных прикладных областей. Еще до выпуска DB2 UDB поддерживались расширители Text Extender для быстрого контекстного поиска в больших текстовых документах; Image Extender для хранения и выборки изображений, представленных в разных форматах; Video Extender для хранения и выборки видео-последовательностей; Audio Extender для хранения и выборки аудио-клипов и т.д.

Все эти возможности были доступны в DB2 for Common Servers с июля 1995 г. В течение следующих двух лет в лабораториях IBM производилась интенсивная разработка дополнительных объектно-реляционных средств, включая абстрактные типы данных с наследованием; UDF с телом, написанным на SQL; UDF, результатом которых являются таблицы; возможность обращаться со строкой таблицы как с объектом, возможно содержащим ссылки на другие строки-объекты; дополнительные расширители для таких специализированных типов данных, как временные ряды и географические данные.

3.3.2 Дополнительные объектно-реляционные возможности DB2 UDB

Структура, поведение, наследование

Для некоторых типов данных имеет смысл трактовать объект как именованный набор атрибутов. Этот вид определяемого пользователями типа в терминологии IBM называется структурным типом. Механизм структурных типов с самого начала включал не только возможность определения типов со структурой, но и средства определения иерархий типов и иерархий таблиц. Кроме того, допускалось использование «ссылок» для определения связей между объектами и навигации от одного объекта к другому.

С самого начала для определения поведения структурного типа можно было использовать UDF. Однако в DB2 Version 7 появилась возможность определения методов объектов. Методы могут быть написаны на SQL или на внешнем языке, например, на Java или C. Но методы всегда ассоциируются с некоторым структурным типом, и их вызовы производятся в синтаксисе, отличном от синтаксиса вызова UDF.

Создание иерархий типизированных таблиц

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

При определении типизированной таблицы (аналог типизированной таблицы IUS или объектной таблицы Oracle8) нужно явно специфицировать дополнительный столбец, в котором будут храниться значения объектных идентификаторов (OID) каждого объекта (строки), содержащейся в таблице. Значения OID в DB2 могут как генерироваться системой (в DB2 это совсем не RowID, как в Oracle8, а некоторые абстрактные идентификаторы), так и задаваться пользователями при занесении строки в типизированную таблицу. Столбец OID создается как первый столбец таблицы, и за ним следуют столбцы, соответствующие атрибутам типа таблицы. Объектные идентификаторы используются в операциях разыменования (dereference), т.е. обеспечивают возможность добраться до строки по ссылке и преобразовать ее в экземпляр (значение) структурного типа.

В иерархии таблиц поддерживается семантика включения, т.е. все строки подтаблиц доступны через запрос, адресуемый к их супертаблице. Естественно, запрос к супертаблице может выдать только значения столбцов, определенных в этой супертаблице. Однако имеется возможность формулировки запроса к супертаблице с внешним объединением строк всех подтаблиц. Имеется и обратная возможность. Используя в запросе ключевое слово ONLY, можно ограничить оператор выборки набором строк, непосредственно принадлежащих супертаблице. Как и в Oracle, в запросах на DB2 SQL можно использовать путевые выражения, но не в «точечной», а в «стрелочной» нотации.

Заметим, что когда-то разработчики DB2 UDB собирались включить в систему и средства работы с типами коллекций, однако, насколько это известно автору, этого не произошло до сих пор.

Назад   Оглавление   Вперед