Объектные расширения реляционных СУБД. Язык SQL-3.

Попытки совместить средства манипулирования данными реляционной модели и способы описания внешнего мира объектно-ориентированной модели получили развитие в языке SQL-3. (см. статью Д.Бича К объектным базам данных, опубликованную в журнале "Открытые системы" N 4 за 1994 г.). Здесь мы рассмтотрим только предлагаемые способы определения данных.

Разработчики SQL-3 считают, что харакетристики объекта определяется описанием строки таблицы. Поэтому, вводится специальная возможность описания нового типа данных:

Create type Address (   number char (6),   street char (30),   aptno integer,   city char (30),   state char (2),   zip integer);

На основе нового типа могут быть определены таблицы, например:

   Create table Addresses of Address;

Новые типы допускается использовать и для определения столбцов (т.е. игнорируется требование атомарности атрибутов реляционной модели):

Сreate table People of new type Person (        name char (30),        address Address,        birthdate date,);

Наследование определяется с помощью фразы under.

Create type Employee under Person (    empno char(10),    dept ref(Department));

Здесь атрибут dept является ссылкой на объект, хранящийся в таблице Department. Т.е. в понятиях реляционной модели в этом столбце должен быть записан внешний ключ, указывающий на на одну из строк таблицы Department. На самом деле, в SQL-3 предполагается, что каждый объект имеет уникальный идентификатор - OID, именно он используется при создании ссылок на объекты.

Также в операторе CREATE TABLE можно определить и методы доступа к вновь созданным типам данных:

 Create table People of new type Person (name char(30), address Address, birthdate date function age(:р ref(Person)) return date; begin   current_age:=:р.birthdate-current_date;   return current_age; end;);

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

Здесь свойства SQL-3 рассмотрены весьма кратко. Более полное представление о них можно получить из указанной статьи Д.Бича, а также из литературы, посвященной возможностям СУБД Oracle 8, которая подерживает данный язык.

Заметим, что К.Дейт придерживается мнения, что областью определения объекта надо считать не строку, а столбец реляционной таблицы. Подробнее об этом см. в его книге.

Еще один подход к объединению свойств реляционной модели и объектно-оринетированного программирования обсуждается в следующем параграфе.

Литература:

• М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник Манифест систем объектно-ориентированных баз данных. СУБД N 4, 1995
• А. Ю. Медников Объектно-ориентированные базы данных сегодня или завтра? Открытые системы N 4, 1994
• Ким Вон Технология объектно-ориентированных баз данных. Открытые системы N 4, 1994
• В. Пржиялковский Новые одежды знакомых СУБД: Объектная реальность, данная нам. СУБД N4, 1997
• С. Кузнецов Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор.

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

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

1. Типы, операторы и методы доступа, определяемые пользователем. Вспомним пример с земельными участками из главы 6.1. Для решения этой задачи мы можем определить новый тип данных "участок", необходимые операции над ним (например, вычисление площади), а также метод доступа, поскольку с помощью B-дерева нельзя выполнить двумерный поиск в задаче о перекрывающихся многоугольниках. Здесь целесообразно использовать дерево более высокой размерности (R-дерево) или другие методы.

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

1. Перегрузка операторов манипулирования данными. Например, возможно создание такой конструкции

SELECT владелец FROM участки WHERE расположение_участка IN заданная_область

4. Создание функций, определяемых пользователем.

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

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

7. Использование массивов как значений полей кортежей. Это необходимо, например, для хранения ставки налога, изменяющейся в зависимости от времени года.

Реализация описанных свойств позволила М.Стоунбрейкеру так спозиционировать объектно-реляционные СУБД относительно реляционных и объектно-ориентированных систем:

	Простые данные	Сложные данные
Наличие средств запросов	Реляционные системы	Объектно-реляционные системы
Отсутствие средств запросов	Файловые системы	Объектно-ориентированные системы

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

Сейчас все вышеописанные функции развиваются в коммерческой СУБД Informix. Тем не менее, проект Postgres продолжается до сих пор, уже международной группой независимых разработчиков. К возможностям СУБД добавлены поддержка SQL (в перспективе планируется обеспечение совместимости со стандартом ANSI SQL-92), поэтому несколько было изменено название СУБД - теперь это PostgreSQL, оптимизатор запросов на основе генетических алгоритмов и многое другое. При этом PostgreSQL остается свободно распространяемой системой, причем бесплатно можно получить как исходный код, так и бинарные файлы, собранные для той или иной платформы (поддерживаются практически все разновидности ОС Unix). Более подробная информация находится на сервере www.postgresql.org.

Литература:

• М. Стоунбрейкер Объектно-реляционные системы баз данных. Открытые Системы N 4 1994
• Е. Булах Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95. СУБД N 2, 1997

 

 

[1] ANSI/SPARC (American National Standards Institute / Standards Planning and Requirements Committee – Американский национальный институт стандартов / Комитет планирования стандартов) – исследовательская группа в рамках Американского национального института стандартов. Архитектура ANSI/SPARC была предложена в 1975 году.