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

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

В этом разделе мы кратко обсудим, каким образом объектные расширения реализованы в трех ведущих РСУБД – Oracle , IBM Informix и DB 2. Заметим, что компания Microsoft решила не внедрять объектные расширения в свой основной продукт управления базами данных – Microsoft SQL Server . Аналогичное замечание относится и к основному продукту компании Sybase .

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

Как появились ОРСУБД?

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

В 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 -запросов с целью превращения запросов с вложенными подзапросами в запросы с соединениями [29].

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

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

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

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

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

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

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

Informix Universal Server (IUS)

Informix Universal Server (IUS ) представлял собой реализацию объектно-ориентированной технологии на основе встраивания механизма абстрактных типов данных и механизма наследования в популярный и надежный сервер реляционных баз данных Informix Dynamic Server .⁷⁸

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

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

В IUS -SQL операторы работают не с самими большими объектами, а с их описателями⁸⁰. Эти описатели помещаются в столбцы таблиц, передаются подпрограммам, написанным с использованием встроенного SQL и т.д. Прикладная программа, получив описатель интеллектуального большого объекта, может работать с ним примерно так же, как и с файлом операционной системы. В частности, программисту, пишущему на ESQL /C (варианту языка C со встроенным SQL , поддерживаемому в Informix ), доступны следующие функции:

• ifx_lo_read – чтение;
• ifx_lo_readwithseek – чтение с предварительным позиционированием;
• ifx_lo_write – запись;
• ifx_lo_writewithseek – запись с предварительным позиционированием);
• ifx_lo_seek – позиционирование и т.д.⁸¹

CREATE DISTINCT TYPE usd AS MONEY;

CREATE DISTINCT TYPE euro AS MONEY; 

CREATE FUNCTION usd_to_euro (v usd) RETURNS euro; . . . 

CREATE FUNCTION euro_to_usd (v euro) RETURNS usd; . . . 

CREATE IMPLICIT CAST (usd AS euro WITH usd_to_euro);

CREATE IMPLICIT CAST (euro AS usd WITH euro_to_usd); 

После этого можно сравнивать значения типов usd и euro , полученные из разных таблиц, не вызывая явно функцию преобразования. Такое решение существенно снижает возможность внесения ошибок, связанных с преобразованием значений.⁸²

Другой причиной, по которой может возникнуть необходимость во введении нового базового типа данных – это принципиальное отсутствие такого типа. Для этого поддерживается механизм определения типов со скрытой структурой (Opague Types ). Типы со скрытой структурой являются абстрактными в строгом смысле этого слова. IUS лишен какой-либо информации о внутреннем устройстве этих типов и может манипулировать соответствующими значениями только посредством предоставленных разработчиком функций. Чтобы определить тип со скрытой структурой, необходимо выполнить следующую последовательность действий:

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

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

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

Например, значениями следующего типа данных являются ФИО человека:

CREATE ROW TYPE fio_t 
       ( last_name   CHAR(40), 
         first_name  CHAR(40), 
         second_nameCHAR(40) )

 

Определенный таким образом составной тип может использоваться наравне и с предопределенными типами для определения столбцов таблицы. Для доступа к отдельным полям значений типа записи используется традиционная “точечная” нотация.

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

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

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

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

Наследование типов и таблиц

В IUS механизм наследования может применяться к типам записей и таблицам. Поддерживается только одиночное наследование. Все функции, определенные для супертипа, автоматически распространяются на все его подтипы. В то же время для подтипов могут определяться свои функции, как новые, дополняющие функциональность, так и модифицированные, изменяющие функциональность, унаследованную от предшественника. В последнем случае имеет место перекрытие функций. Значения подтипов могут использоваться почти везде, где разрешено употребление значений их супертипов. Единственное (и вполне естественное) ограничение возникает при отведении памяти и хранении значений. Здесь соответствие типов должно быть точным. Например, если предположить, что тип programmer   является подтипом типа employee , и столбец таблицы имеет тип employee , то храниться в нем могут только значения данного типа, но не значения типа programmer .

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

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

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

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

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

Oracle 8

По мнению автора этой статьи, после выпуска в 1997 г. системы Oracle 8 ⁸⁸, которая действительно претендовала на статус объектно-реляционной системы, впоследствии корпорация Oracle не стала уделять большого внимания развитию именно этих свойств своей системы. Лишь в системе Oracle 9 i (2002 г.) появились существенные дополнения. Поэтому в своем кратком описании мы в основном ограничимся свойствами Oracle 8, но в заключение подраздела обозначим и возможности, появившиеся в Oracle 9 i .

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

Объектные типы в Oracle8 являются аналогом типа записи в IUS. Как и в IUS , для доступа к отдельным полям значений объектного типа используется “точечная” нотация.

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

Любой метод объектного типа попадает в одну из трёх категорий:

• методы-члены
• статические методы
• методы сравнения.

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

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

имеют неявный параметр SELF и могут обращаться к значениям атрибутов объекта⁹⁰.

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

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

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

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

на значение одного из встроенных типов.

Метод типа ORDER сравнивает два объекта и возвращает –1, если первый объект

меньше второго, 0,  если объекты равны, и 1, если первый объект больше второго.

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

Каждый объектный тип имеет определяемый системой метод-конструктор, который

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

конструктора – с именами и типами атрибутов объектного типа.

Объектной таблицей в Oracle 8 называется таблица, строки которой имеют объектный тип. В Oracle 8 не поддерживалось наследование (ни типов, ни таблиц), но уже в Oracle 8 i появилась возможность наследования таблиц почти в той же форме, как это делалось в IUS , но без поддержки параллельной иерархии наследования объектных типов ⁹¹.

К объектным представлениям можно обращаться так же, как и к объектным таблицам (по крайней мере, по выборке данных). Можно определять объектные представления на основе других представлений (возможно, объектных).

Использование ссылочных типов

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

Типы коллекций в Oracle 8

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

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

Например, при наличии определения объектного типа EMP _ T можно было бы определить табличный тип DEPENDENTS _ T следующим образом:

CREATE TYPE DEPENDENTS_T AS TABLE OF EMP_T;

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

CREATE TABLE BOSSES

   ( boss       EMP_T,
     dependentsEMP_T,

     PRIMARY KEY ( boss.EMP_NO ) )

     Nested TABLE DEPENDENTS STORE AS DEPENDENTS_TAB;

В результате выполнения этой операции в базе данных будут созданы две таблицы – таблица верхнего уровня BOSSES и вложенная таблица DEPENDENTS _ TAB , содержащая все строчные объекты, которые соответствуют сотрудникам-подчиненным. Конечно, если в таблице верхнего уровня имелось бы несколько столбцов табличного типа, то для каждого из этих столбцов потребовался бы свой раздел Nested TABLE . П родемонстрируем возможность выборки из таблицы с вложенной подтаблицей на примере.

Пример 3.7. Выбрать из таблицы BOSSES все пары “начальник-подчиненный”.

SELECT B.boss.EMP_NO, D.EMP_NO

FROM BOSSES B, TABLE ( B.dependents) D

Должно быть понятно, что этот запрос в сокращенной форме выражает естественное соединение таблиц BOSSES и DEPENDENTS _ TAB . Поэтому в результате не появятся данные о служащих, данные о которых включены в таблицу BOSSES и которые не имеют подчиненных. Чтобы получить данные обо всех сотрудниках, данные о которых включены в таблицу BOSSES , в синтаксисе SQL Oracle 8 требуется задать следующий запрос:

SELECT B.boss.EMP_NO, D.EMP_NO

FROM BOSSES B, TABLE ( B.dependents ) (+) D

Этот запрос соответствует требованию правого внешнего естественного соединения. Во встроенном SQL Oracle 8 имеются и другие способы доступа к вложенным таблицам, которые мы не будем обсуждать в этой статье.

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

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

Дополнительные объектно-реляционные возможности Oracle 9 i

Основные расширения объектно-реляционных возможностей Oracle 8, появившиеся в Oracle 9i , касаются наследования объектных типов и представлений. Эти расширения (в особенности, наследование объектных типов) очень близки к спецификациям SQL :1999.

Объектное представление может определяться в виде подпредставления другого объектного представления с порождением иерархии представлений. При этом множество строк любого наследуемого объектного представления включает все строки всех подпредставлений.

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

· объектный тип суперпредставления должен являться непосредственным супертипом типа наследуемого представления;

· подпредставление наследует объектный идентификатор у своего суперпредставления.

Заметим, что, конечно, механизм наследования представлений, реализованный в Oracle 9i , является гораздо более гибким, чем механизм наследования таблиц в IUS . Понятно также, что при реализации механизма наследования представлений не должны были возникать особые трудности. Но, как кажется автору этой статьи, этот механизм не слишком удобен для использования.

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

IBM DB2 Universal Database (UDB)

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

Точка зрения компании IBM относительно ОРСУБД

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

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

Обе указанные возможности позволяют повысить ценность хранимых данных за счет расширения их семантического содержимого. Тенденция к повышению роли семантического содержимого хранимых данных является наиболее важной в современном управлении базами данных. В соответствии с этой тенденцией реляционные системы баз данных расширяются в двух направлениях: (1) добавлении “объектной инфраструктуры” к самой системе баз данных в виде поддержки определяемых пользователями типов данных, функций и правил; (2) построении поверх этой инфраструктуры “реляционных расширителей”, которые поддерживают специализированные приложения, такие как выборка изображений, развитый текстовый поиск, географические приложения. Система, которая обеспечивает объектную инфраструктуру и набор реляционных расширителей, называется “объектно-реляционной”.

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

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

В DB 2 поддерживаются три типа данных для хранения больших объектов: BLOB для бинарных объектов, CLOB для символьных строк и DBCLOB для строк, в которых используются двухбайтовые наборы символов. Когда большие объекты сохраняется в столбце таблицы, то на самом деле столбец содержит “дескриптор” каждого такого значения; сами же большие объекты хранятся вне таблицы.

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

В среде DB 2 прикладная программа может объявить переменную-“локатор”, которая представляет значение большого объекта, но реально его не содержит. Локатор может быть использован для представления значения большого объекта в любом выражении SQL , и операции над локаторами очень эффективны, поскольку при их выполнении происходит работа с “предписаниями” по материализации, а не с сами значениями больших объектов. При использовании локаторов прикладная программа может выполнить серию действий над значением большого объекта, откладывая его материализацию до последнего момента.

DB 2 дает возможность прикладным программам обмениваться значениями больших объектов между базой данных и файлом без перемещения значений через буфера программы. В программе может быть объявлена переменная “ссылка на файл”, которая содержит имя нужного файла. Ссылка на файл может использоваться в операторах SQL как входная или выходная переменная, представляющая содержимое файла, которое интерпретируется как большой объект. Совместно локаторы и ссылки на файл часто дают возможность обработки больших объектов без их реального считывания в память программы.

Определяемые пользователями функции

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

Поддерживается соглашение о передаче параметров UDF в поставляемую пользователем программу реализации функции. Создатель функции должен откомпилировать реализующую ее программу и поместить выполняемый файл в каталог, доступный серверу баз данных. После этого пользователь должен зарегистрировать UDF в каждой базе данных, где предполагается ее использование, путем выполнения оператора CREATE FUNCTION . Описание функции помещается в таблицы системного каталога. При каждом вызове функции ее реализация будет динамически загружаться и выполняться.  DB 2 SQL позволяет “перегружать” имя функции, т.е. определять несколько функций с одним именем и разными типами параметров. При обработке вызова функции DB 2 вызывает функцию, сигнатура которой строго соответствуют типам аргументов вызова.

Определяемые пользователями типы

В DB 2 определяемые пользователями типы данных называются “индивидуальными типами” (“distinct type ”). В каждом из индивидуальных типов используется общее представление одного из встроенных типов (называемых “базовыми типами”), но может иметься собственный набор допустимых операций. Легко указать, какие из операций базового типа являются осмысленными для созданного на его основе индивидуального типа. Каждый встроенный оператор, такой как “+ ”, реализуется функций с тем же именем, что и оператор. Чтобы сделать этот оператор применимым к индивидуальному типу, нужно просто создать функцию с тем же именем, что и оператор, принимающую параметры и/или возвращающую результат индивидуального типа данных. Функция, реализующая оператор, может основываться на функции, реализующей встроенный оператор.

Активные данные

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

• В DB2 поддерживаются следующие виды ограничений : NOT NULLS , UNIQUE ,  PRIMARY KEY , CHECK ,  WITH CHECK OPTION ,  FOREIGN KEY . 

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

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

Синергия

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

Поскольку отсутствует предопределенный тип данных “многоугольник”, то прежде всего нужно понять, каким образом многоугольники будут представляться в базе данных. Поскольку многоугольники потенциально могут быть довольно большими, для их представления должен использоваться тип больших объектов BLOB . Но хотелось бы отличить это представление от других объектов типа BLOB , и поэтому мы создадим индивидуальный тип POLYGON :

CREATE DISTINCT TYPE POLYGON AS BLOB(1M);

Можно выбрать различные реальные представления многоугольников внутри большого объекта. Например, это может быть последовательность чисел, первое из которых задает число вершин многоугольника, а следующие содержат координаты вершин. После создания индивидуального типа желательное поведение многоугольников может быть указано путем создания набора соответствующих UDF . По крайней мере, одна из этих функций должна быть “конструктором”, создающим многоугольник на основе более простых типов, таких как POINT или DOUBLE . Работа функции-конструктора состоит в упаковке примитивных частей многоугольника в BLOB с последующим преобразованием типа BLOB к типу POLYGON (для этого следует использовать сгенерированную системой функцию преобразования типов POLYGON ( BLOB )) . Ниже перечислены некоторые из UDF , задающие поведение типа POLYGON . Эти функции могут быть написаны, например, на языках C или C ++.

degree(Polygon) returns Integer;

area(Polygon) returns Double;

perimeter(Polygon) returns Double;

rotate(Polygon, Double) returns Polygon;

intersect(Polygon, Polygon) returns Polygon;

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

CREATE TABLE properties
   (taxid      Char(6) PRIMARY KEY,

    owner      Varchar(32),

    assessment Dollars,

    parcel      Polygon );

Для нахождения собственников больших участков можно использовать следующий запрос на языке SQL :

SELECT owner, area(parcel)

   FROM   properties

   WHERE  area(parcel) > 20000;

Наиболее эффективный способ выполнения этого запроса мог бы базироваться на использовании индекса, обеспечивающего прямой доступ к участкам по значению их площади. Поддержка индексов на UDF находится в планах развития DB 2, но пока ее нет. Но возможно другое решение, позволяющее выполнить запрос с той же эффективностью. Добавим к таблице PROPERTIES новый столбец, который должен содержать заранее вычисленный размер площади, и создадим триггеры для поддержки корректных значений этого столбца. Для добавления столбца можно использовать оператор SQL

ALTER TABLE properties

   ADD COLUMN area Double;

Теперь определим триггеры, которые активируются при выполнении над таблицей PROPERTIES операторов INSERT и UPDATE . Вот как могло бы выглядеть определение триггера для INSERT :

CREATE TRIGGER insertprop

   NO CASCADE

   BEFORE INSERT ON properties

   REFERENCING NEW AS newrow
   FOR EACH ROW MODE DB2SQL

       SET newrow.area = area(newrow.area);

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

CREATE INDEX proparea ON  properties(area);

Теперь перепишем запрос в форме, которая даст возможность DB 2 использовать этот индекс:

SELECT owner, area

   FROM   properties

   WHERE   area > 20000;

Размышления о будущем

Все возможности, описанные в статье [11], были доступны в DB 2 for Common Servers с июля 1995 г. IBM планировала распространить те же возможности и на других членов семейства DB 2. Особенно важно то, что через год после выпуска компанией IBM ее первой объектно-реляционной системы в лабораториях IBM производилась интенсивная разработка дополнительных объектно-реляционных средств, включая следующее:

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

Промежуточные замечания

По мнению автора этой статьи, основной интерес в статье Дона Чемберлина представляет то, что в ней показана возможность создания нетрадиционных приложений при наличии минимальных объектных расширений в DB 2 for Common Servers . В частности, статья заставляет задуматься о том, нужны ли на самом деле дальнейшие расширения.

Тем не менее, компания IBM выполнила практически все свои обещания, и ниже мы кратко обсудим дополнительные объектные расширения, реализованные в следующих версиях DB 2 UDB .

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

Для некоторых типов данных имеет смысл трактовать объект как именованный набор атрибутов. Этот вид определяемого пользователями типа в терминологии IBM называется структурным типом. Его поддержка появилась в DB 2 UDB Version 5.2 в 1998. Механизм структурных типов с самого начала включал не только возможность определения типов со структурой, но и средства определения иерархий типов и иерархий таблиц. Кроме того, допускалось использование “ссылок” для определения связей между объектами и навигации от одного объекта к другому.

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

Любая объектно-реляционная возможность DB 2 может быть использована в традиционном SQL . Чем дальше, тем увереннее можно говорить, что “традиционным” SQL в контексте DB 2 является SQL :1999. В одном приложении может потребоваться всего лишь поддержка LOB , а в другом могут понадобиться структурные типы, методы и наследование. Возможно даже использование объектно-ориентированного моделирования реляционных данных на основе объектных представлений.

Синтаксис оператора создания определяемого пользователем структурного типа очень поход на синтаксис оператора определения таблицы – указываются имя типа, имена его атрибутов и типы данных этих атрибутов. При создании подтипов структурного типа эти подтипы автоматически наследуют атрибуты супертипа.

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

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

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

Объектные представления

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

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

Заключение подраздела

Разработчики  DB 2 UDB собирались включить в систему и средства работы с типами коллекций, однако, насколько это известно автору, пока это не произошло. Вообще, следует заметить, что в настоящее время IBM и Oracle предлагают объектно-реляционные расширения, обеспечивающие практически одинаковую функциональность. Системы Informix , став частью IBM , теперь подчиняются общей стратегии этой компании. Помимо прочего, эта стратегия включает отказ от дальнейшего развития собственной линии объектно-реляционных расширений Informix .

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