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

В качестве примера вернемся к незаконченным исследованиям из раздела 24.1 главы 24 и покажем подходящее реляционное решение задачи о прямоугольниках. Прежде всего следует определить тип прямоугольника (назовем его RECT).

ТУРЕ RECT POSSREP { XI RATIONAL, Yl RATIONAL,

X2 RATIONAL, Y2 RATIONAL ) ... ;

Предполагается, что физическое представление данных основывается на одном из типов структур хранения, которые позволяют весьма эффективно сохранять такие пространственные структуры данных, как Q-деревья, R-деревья т.д. [25.27].

Далее нужно определить оператор для проверки, не пересекаются ли два прямоугольника.

OPERATOR OVERLAP ( Rl RECT, R2 RECT ) RETURNS ( BOOLEAN ) ; RETURN ( THE X1(R1) < THE X2(R2) AND THE Y1(R1) < THE Y2(R2) AND THE X2(R1) > THE X1(R2) AND THE Y2(R1) > THE Y1(R2) ) ; END OPERATOR ;

В этом операторе используется эффективная краткая формулировка (см. главу 24) условия пересечения прямоугольников для эффективной структуры хранения.

Теперь пользователь может создать базовую переменную-отношение с атрибутом типа RECT.

VAR RECTANGLE RELATION { R RECT, ... } KEY { R } ;

В таком случае формулировка запроса Найти все прямоугольники, которые пересекают данный единичный квадрат значительно упрощается.

RECTANGLE WHERE OVERLAP ( R, RECT (0.0, 0.0, 1.0, 1.0 )) ;

Это решение позволяет устранить все недостатки, которые обсуждались в главе 24 в связи с предыдущим запросом.

ном, просто числа, строки, даты и время] [24.38], Объектно-реляционные модели расширяют реляционную модель данных, предоставляя более богатую систему типов [17.61 ]; и т.д.

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

25.2. Первая грубейшая ошибка

Начнем с цитаты из [3.3].

[Прежде] чем подробно обсуждать вопрос об интеграции объектов и отношений, необходимо ответить на ключевой вопрос:

Какая из концепций в реляционной модели соответствует концепции объектного класса в объектной модели?

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

домен - объектный класс;

переменная-отношение = объектный класс;

Далее мы приведем строгое обоснование того, что первое из уравнений верное, а второе - нет.

На самом деле очевидно, что первое уравнение верно, поскольку и объектные классы, и домены являются просто типами. Поэтому из того, что переменная-отношение - это переменная, а класс - это тип, также непосредственно ясно, что второе уравнение не верно (переменные и типы - это не одно и то же). По указанным причинам в работе The Third Manifesto [3.3] категорически утверждалось, что переменные-отношения - это не домены. Тем не менее во многих работах и в некоторых продуктах фактически используется второе уравнение, что мы и называем грубейшей ошибкой, а точнее - первой грубейшей ошибкой, поскольку далее будет рассмотрена еще одна. Очень поучительно было бы более внимательно присмотреться ко второму уравнению, что мы и сделаем ниже.

Замечание. Далее в этом разделе почти дословно повторяется [3.3].

Почему же может быть допущена такая грубая ошибка? Рассмотрим определение простого класса, написанное на гипотетическом объектном языке, который не совсем (что сделано преднамеренно) совпадает с тем языком, который использовался в разделе 24.3, хотя и похож на него.

CREATE OBJECT CLASS ЕМР

( ЕМР# CHAR(5),

ENAME CHAR(20),

SAL NUMERIC,

HOBBY CHAR(20),

WORKS FOR CHAR(20) ) ... ;

(Здесь EMPi и ENAME - открытые переменные экземпляра.) Сравним это определение с определением базовой переменной-отношения на языке SQL.

CREATE TABLE ЕМР

( EMPI CHAR(5),

ENAME CHAR(20),

SAL NUMERIC,

HOBBY CHAR(20),

WORKS FOR CHAR(20) ) ... ;

Эти выражения, несомненно, очень похожи, и, конечно же, очень велико искушение их приравнять. И как отмечалось выше, в некоторых системах именно так и было сделано. Рассмотрим этот вопрос подробнее. Возьмем, например, показанный выше оператор CREATE TABLE и ряд возможных его расширений, которые, как может показаться, делают его более объектно-подобным .

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

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

CREATE TABLE ЕМР

( EMPI CHAR(5),

ENAME CHAR(20), SAL NUMERIC,

HOBBY ACTIVITY, WORKS FOR COMPANY ) ;

CREATE TABLE ACTIVITY ( NAME CHAR(20), TEAM INTEGER ) ;

CREATE TABLE COMPANY

( NAME CHAR(20), LOCATION CITYSTATE ) ;

CREATE TABLE CITYSTATE ( CITY CHAR(20), STATE CHAR(2) ) ;

Пояснения. Для атрибута HOBBY (Хобби) в переменной-отношении ЕМР объявлен тип ACTIVITY (Деятельность), который, в свою очередь, является атрибутом, состоящим из двух атрибутов- NAME (Название команды) и TEAM (Команда), где TEAM представляет