    Глава 25 

    Совместное использование реляционного и объектно-ориентированного подходов 

    25.1, Введение 

    В предыдущих главах рассматривались основные аспекты 
объектно-ориентированных систем, а также отмечалось, что современные 
реляционные продукты не адекватны по целому ряду причин. Затем подчеркивалось, 
что отдельные новые свойства, которые несомненно пригодились бы в СУБД, долгие 
годы использовались в объектно-ориентированных языках программирования. 
Поэтому было бы совершенно естественно исследовать возможность создания 
объектно-ориентированной системы управления базами данных. К сожалению, это не 
значит, что объектно-ориентированные системы могут заменить реляционные. 
Наоборот, следовало бы найти некоторый способ их совместного использования, 
сочетающий лучшие черты этих двух подходов. Пути достижения именно этой цели и 
обсуждаются в данной главе. 
    По мнению автора, сближение двух подходов следует выполнять на основе 
реляционной модели (которая, как объяснялось ранее в этой книге, помимо 
прочего, служит основой всей современной области изучения баз данных). Это 
значит, что следует таким образом изменить реляционную систему, чтобы в нее 
вошли, по крайней мере самые лучшие черты объектно-ориентированных систем. При 
этом не следует полностью исключать реляционные элементы, а также не нужно 
создавать излишнюю конкуренцию между двумя абсолютно разными системами, 
реляционной и объектно-ориентированной. Это мнение разделяется многими 
специалистами, включая авторов манифеста СУБД третьего поколения "Third 
Generation Database System Manifesto" [25.10], Они в весьма категоричной форме 
заявляют, что СУБД третьего поколения должны включать СУБД второго поколения. 
Где под СУБД второго поколения подразумеваются реляционные системы, а под СУБД 
третьего поколения — системы будущего. Очевидно, что это мнение не разделяют 
разработчики объехтно-ор иентированных систем, и в подтверждение этого можно 
привести следующее высказывание из [25.4]: 
    "Развитие информатики сопровождалось появлением многих поколений методов 
управления данными, начиная с индексных файлов, затем сетевых и иерархических 
СУБД... и заканчивая более современными реляционными СУБД... Теперь мы 
наблюдаем появление еще одного поколения СУБД... в которых обеспечивается 
управление объектами, поддерживаются гораздо более сложные виды данных". 
    Здесь четко выражена мысль, что, как реляционные системы в свое время 
заменили иерархические и сетевые, так и объектно-ориентированные системы 
заменят реляционные. 
    Причина несогласия автора настоящей книги с этим мнением состоит в том, 
что реляционный подход значительно отличается от объектно-ориентированного, 
так как в нем предусмотрено выполнение незапланированных запросов (запросов 
типа ad hoc). 

    650	Часть VI, Объектно-ориентированные системы 

    Так, в более старых системах, существовавших до появления первых 
реляционных систем, было предусмотрено выполнение незапланированных запросов. 
Причем они позволяли решать важные текущие задачи, но не имели прочного 
теоретического обоснования.1 К сожалению, приверженцы реляционного подхода (и 
автор этой книги в том числе) в начальный период оказали в некотором роде 
"медвежью" услугу, восхваляя реляционные достоинства как реляционных систем, 
так и их предшественников. Эти похвалы были уместны в свое время, но 
впоследствии благодаря им у многих сложилось впечатление, что реляционные и 
предшествующие им системы, по сути, одинаковы. И это ошибочное представление, 
в свою очередь, привело к процитированному выше выводу из [25.4] о замене 
реляционных систем объектно-ориентированными. 
    Далее в качестве аксиомы будет принято, что реляционные системы будут 
улучшены за счет добавления в них самых лучших черт объектно-ориентированных 
систем. При этом не следует полностью отвергать реляционные системы, 
перечеркивая 25-летний опыт исследований и разработки реляционного подхода. 
    В следующем разделе приводится характеристика основных концепций 
объектно-ориентированных систем, как положительных, так и отрицательных. Далее 
обсуждаются способы дополнения реляционных систем положительными свойствами. 
Затем предлагается описание доменов и отношений. Потом обсуждаются выгоды, 
полученные от совместного использования разных подходов. И наконец, приводится резюме. 

    25.2. Обзор "объектно-ориентированной модели" 

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

    1 Можно ли в объектно-ориентированных системах выполнять незапланированные 
запросы? В этом отношении можно привести интересную цитату из манифеста 
объектно-ориентированных СУБД "The Object-Oriented Database System Manifesto" 
[25.1]: "В отношении объектно-ориентированных систем следует применить принцип 
естественного отбора по Дарвину, т.е. наиболее пригодная 
объектно-ориентированная модель появится на основе некоторого множества 
экспериментальных прототипов, причем методика воплощения этой модели также 
будет эволюционировать одновременно с развитием модели". 

    Глава 25. Совместное использование...	651 

    •   Методы, Безусловно, эта концепция весьма существенна (хотя названию 
"метод" следовало бы предпочесть более привычные термины "функция" или 
"оператор"). Размещение определений методов внутри объектных классов не 
существенно и к тому же может привести к некоторым проблемам. Для управления 
доступом к внутренней структуре классов следовало бы использовать инструменты 
обеспечения безопасности, 
    •   Сообщения. Эта концепция также существенна, хотя для ее обозначения 
предпочтительнее было бы использовать более привычные термины "вызов" или 
"обращение", учитывая, что такие вызовы и обращения не всегда могут быть синхронными. 
    •   Иерархия классов. Понятие иерархии классов и связанное с ним понятие 
наследования весьма существенны, хотя в данном случае нет необходимости 
различать структурное и поведенческое наследование (всякое наследование по 
определению становится поведенческим), поскольку не вводится понятие 
общедоступных экземпляров переменных. Понятие полиморфизма также существенно 
наряду с производным от него понятием связывания во время исполнения. Однако 
последнее относится к способам воплощения, а потому не будет рассматриваться 
как часть абстрактной объектно-ориентированной модели. 
    •   Множественное наследование. Это понятие второстепенно. (Действительно, 
доказательство этой концепции, вероятно, является очень важным, но, по мнению 
автора, сначала необходимо рассмотреть некоторые другие более важные концепции 
и определения. Лишь затем в абстрактную объектно-ориентированную модель с 
определенной степенью доверия следует включать понятие множественного 
наследования. Однако для этого потребуется изучить данный вопрос более детально.) 
    •   Класс, экземпляр, семейство. Можно достаточно четко указать 
существующие между этими понятиями различия, но они касаются не только 
объектно-ориентированного подхода (здесь достаточно сказать, что эти концепции различаются). 
    •   Язык программирования базы данных. Полезный компонент, который имеет 
отношение не только к объектно-ориентированному подходу. 
    •   Принадлежность к языкам третьего поколения, По сути, это гигантский 
шаг назад. 
    •   Версии. Полезная концепция, имеющая отношение не только к 
объектно-ориентированному подходу. То же самое относится к родственному 
понятию конфигурации. 
    •  Длительные и вложенные транзакции. Полезные концепции, которые имеют 
отношение не только к объектно-ориентированному подходу. 
    •   Эволюция макета, Полезная концепция, имеющая отношение не только к 
объектно-ориентированному подходу, 
    Теперь можно привести перечень понятий, которые обычно не поддерживаются в 
объектно-ориентированной модели. 
    •  Незапланированные запросы. Как объяснялось в главе 24, в ранних версиях 
объектно-ориентированной модели обычно не предусматривалась поддержка 
незапланированных запросов, поскольку в той среде, в которой появились 
объектно-ориентированные системы, в них не было особой необходимости; кроме 
того, для такой поддержки предполагается либо специально заданная структура 
объектов, либо необходимость преодоления инкапсуляции такими запросами. 
    •   Замыкание. Такие операторы (объектно-ориентированного уровня), как 
объединение, соединение, проекция и т.д., не поддерживаются. В общем случае 
производные объекты также не поддерживаются. 

    652	Часть VI. Объектно-ориентированные системы 

    •  Симметричная обработка. Не поддерживается; все запросы на осуществление 
доступа выполняются на основе заранее заданных процедурных методов. 
    •   Внешние ключи. В объектно-ориентированной модели предусмотрено 
несколько разных методов поддержки целостности на уровне ссылок, ни один из 
которых не похож на более однородный метод внешних ключей, используемый в 
реляционной модели. Такие понятия, как ограниченное (DELETE RESTRICTED) или 
каскадное (DELETE CASCADES) удаление, обычно реализуются с помощью 
процедурного кода (размещенного либо в методах, либо в коде приложений). 
    •  Декларативные ограничения целостности. В настоящее время не 
поддерживаются (по тем же причинам, что и обработка незапланированных запросов). 
    •   Представления. В настоящее время не поддерживаются (по тем же 
причинам, что и обработка незапланированных запросов). 
    •   Каталог. Должен создаваться специалистом для того, чтобы адаптировать 
и оптимизировать объектно-ориентированную СУБД для узкоспециализированного 
применения. Поэтому не существует понятия универсального "каталога общего 
назначения" (до появления стандарта языка SQL/92 такого каталога общего 
назначения не было и в реляционных системах). 
    Подытожив сказанное выше, можно отметить полезные (существенные) понятия и 
концепции объектно-ориентированной модели, которые рекомендуется включить в 
реляционную систему. 
    •   Объекты и объектные классы, а также соответствующие 
функции-конструкторы (которые бы возвращали объекты, а не идентификаторы; 
подробнее это описано ниже в главе), функции осуществления доступа и поддержки 
с соблюдением четкого различия между классами, экземплярами и семействами. 
    •   Иерархии классов с (поведенческим) наследованием, а также 
полиморфизмом и связыванием во время исполнения (хотя полиморфизм не является 
частью модели как таковой). 

    Замечание об инкапсуляции 

    Выше было отмечено, что в рассматриваемой системе должна поддерживаться 
инкапсуляция объектов, т.е. доступ к объектам должен осуществляться только на 
основе соответствующих функций доступа (а значит, в этих объектах не должно 
быть никаких "общедоступных экземпляров переменных"). Преимущество 
инкапсуляции такого типа состоит в том, что благодаря ей обеспечивается 
независимость от данных. (Фактически в объектно-ориентированных системах 
обеспечивается частичная строгая форма независимости от данных [22.7]. Однако 
важно понимать, что, по крайней мере в принципе, в объектно-ориентированных 
системах независимость от данных не может осуществляться в большей степени, 
чем в реляционных системах. Например, не существует абсолютно никаких причин, 
по которым базовое отношение POINT с декартовыми координатами X и Y нельзя 
было бы отобразить на хранимое отношение, в котором точки представлены 
координатами R и б. Однако, как отмечалось ранее в этой книге, к сожалению, в 
современных реляционных проду ктах независимость от данных обеспечивается не 
настолько, насколько этого бы хотелось или теоретически было возможно в 
реляционной системе.) 
    Тем не менее, следует отметить, что идея инкапсуляции может завести 
чрезмерно далеко. Дело в том, что всегда будет существовать необходимость 
такого способа доступа к данным, который совершенно не предвиделся на этапе 
разработки базы данных. В такой ситуации составление новой процедуры для 
каждого нового способа доступа было бы неприемлемо. Действительно, такая 
ситуация имела место для нереляционных систем, и именно это привело к их исчезновению. 

    Глава 25. Совместное использование...	653 

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

    25.3. Домены и объекты 

    В этом разделе будет обоснована решающая роль реляционного понятия доменов 
в достижении взаимодействия двух подходов, что уже упоминалось в главе 19. Для 
этого следует рассмотреть приведенные ниже понятия. 
    •  Фундаментальной основой объектно-ориентированных систем является 
объектный класс — определенный пользователем инкапсулированный тип данных с 
произвольной внутренней сложностью. 
    •   Фундаментальной основой реляционных систем, к сожалению в основном не 
реализованной в современных реляционных продуктах, является домен — также 
определенный пользователем инкапсулированный тип данных с произвольной 
внутренней сложностью. 
    Иначе говоря, домен и объектный класс — это одно и то же! Таким образом, 
реляционная система, в которой воплощены домены, в принципе могла бы решить 
все задачи, выполнимые в объектно-ориентированной системе и не выполнимые в реляционной. 
    Еще раз перечислим основные свойства доменов, которые рассматривались в 
главе 19. 
    •  Домены являются типами данных произвольной сложности. 
    •  "Скалярные" значения в таком домене могут иметь произвольную внутреннюю структуру. 
    •   Эти значения являются инкапсулированными и ими можно управлять только 
с помощью предопределенных функций. 
    Кроме того, также рассматривались некоторые другие моменты. 
    •   Отказ от размещения определений функций внутри определений доменов. 
    •  Концепция "строгого назначения типов", заимствованная из языков программирования. 
    •  Идеи наследования и полиморфизма в применении к доменам. 
    Действительно, домены и объектные классы — это, по сути, одно и то же. 
Таким образом, домены (и, следовательно, реляционные атрибуты) могут содержать 
абсолютно все — массивы, списки, стеки, документы, фотографии, карты, 
инструкции и т.д. Иначе говоря, домены могут быть инкапсулированы, а отношения нет. 

    654	Часть VI. Объектно-ориентированные системы 


    Еще раз о задаче с прямоугольниками 

    Теперь можно предложить "улучшенное" решение задачи с прямоугольниками (из 
главы 22). Прежде всего администратору базы данных следует определить домен прямоугольников: 

    CREATE DOMAIN RECTANGLE REP   (   ...   )   ; 

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

    CREATE FUNCTION RECTANGLE 
    ( A FLOAT, В FLOAT, С FLOAT, D FLOAT) 
    RETURNS ( RECTANGLE ) AS BEGIN ; 
    DECLARE R RECTANGLE ; R.X1 := A ; R.X2 := В ; R.Y1 := С ; R.Y2 := D ; 
RETURN ( R ) ; END ; 

    Теперь предположим, что переменная R.X1 относится к х-координате нижнего 
левого угла прямоугольника R и т.д., а также что прямоугольник может быть 
определен с помощью этих четырех координат. Обратите внимание, что в данном 
"объектном классе" (домене) RECTANGLE нет определения функции RECTANGLE. 
    Для проверки, не пересекаются ли два прямоугольника, следует также 
определить функцию 

    CREATE FUNCTION OVERLAP 
    ( Rl RECTANGLE, R2 RECTANGLE } 
    RETURNS ( BOOLEAN ) AS BEGIN ; 
    . . . код ... ; END ; 

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

    CREATE TABLE RECTANGLES 
    ( RECTID ... , R RECTANGLE ... , ... , UNIQUE ( RECTID ) , UNIQUE ( R ) } ; 

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

    SELECT	... 
    FROM	RECTANGLES 
    WHERE	OVERLAP ( R, RECTANGLE (0,1,0,1) ) ; 

    Обратите внимание, что выражение RECTANGLE(0,1, о, 1) в данном запросе 
представляет собой некий "литерал-прямоугольник". 

    Заключение 

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

    Глава 25. Совместное использование...	655 

    идентификаторы объектов, поскольку согласно реляционной модели требуется, 
чтобы отношения содержали сами объекты (по крайней мере концептуально), а не 
указатели на объекты. Таким образом, например, функция RECTANGLE (которая для 
прямоугольников является реляционным аналогом функции NEW) возвратит не 
идентификатор прямоугольника, а сам прямоугольник (по крайней мере концептуально). 
    Что касается различий между понятиями "класс", "экземпляр" и "семейство", 
то здесь можно привести следующие замечания: 
    •  Класс является доменом, 
    •  Экземпляр является элементом домена. До сих пор такие экземпляры 
существовали только внутри позиций атрибутов внутри кортежей внутри отношений. 
Однако теперь всегда можно создать новые экземпляры "литералов" для 
использования их в качестве аргументов операций или функций, которые заданы 
для этого домена. 
    •   Семейство является набором значений любого атрибута, определенного на 
данном домене. Причем доступ к одному экземпляру со стороны нескольких 
семейств может быть достигнут с помощью внешних ключей. Действительно, 
размещение двух копий одного и того же экземпляра в двух разных базовых 
отношениях на самом деле не является истинным обеспечением совместного доступа 
(фактически это противоречит принципам дальнейшей нормализации). Замечание. 
Один и тот же экземпляр может, конечно, совместно использоваться одним базовым 
отношением и любым числом других (именованных) отношений, если эти отношения 
являются представлениями. 
    В заключение необходимо отметить, что разработчикам и поставщикам 
реляционных систем следовало бы в максимальной степени внедрить в свои системы 
соответствующую поддержку доменов. Аргументом в поддержку этого довода мог бы 
служить тот факт, что объектно-ориентированные системы пользуются такой 
большой популярностью именно благодаря неадекватности реляционных систем. 
Однако это не основание для отказа от использования реляционных систем целиком 
(или полностью). 

    25.4, Отношения и объекты 

    В предыдущем разделе сравнивались классы и домены, однако во многих 
прототипах и программных продуктах вместо них часто сравниваются объектные 
классы и отношения. (Для разрешения проблемы сравнения двух концепций А и В, 
например отношений или объектных классов, т.е. для выяснения вопроса, являются 
ли эти концепции "одним и тем же" и можно ли их сравнивать, следует 
воспользоваться простым принципом. Он был впервые приведен автором этой книги 
в [4.12] и формулируется так: "Является ли каждый экземпляр А экземпляром В" 
или "Является ли каждый экземпляр В экземпляром А". А и В будут идентичны, 
только если ответ будет положительным в обоих случаях.) В этом разделе 
приводятся объяснения, почему сравнение объектных классов и отношений не корректно. 
    Рассмотрим простой пример, который является несколько измененной версией 
примера создания объектного класса, приведенного в главе 22. 

    CREATE OBJECT CLASS EMP PUBLIC   (   EMPff     CHAR, 
    ENAME CHAR, 
    SAL      NUMERIC  )    ...   ; 

    Аналогичное выражение на реляционном языке (SQL) выглядит следующим образом: 

    CREATE TABLE EMP { ЕМР# CHAR, 
    ENAME; CHAR, 
    SAL     NUMERIC )  ... ; 

    Несомненно, очень велико искушение приравнять оба выражения! Именно так и 
было сделано во многих системах, например в системе Iris [25.3, 25.7], 
POSTGRES [25.13-25.16], UniSQL [25.11] и др, В системе UniSQL, например, поддерживается 

    656	Часть VI. Объектно-ориентированные системы 

    расширенная форма языка SQL под названием SQL/X, которая будет 
проиллюстрирована на следующем примере (этот пример приводится в руководстве 
пользователя SQL/X [25.11]). Сначала рассмотрим обычное и простое выражение 
CREATE TABLE, записанное на языке SQL: 

    CREATE TABLE EMP 
    ( EMP#     CHAR(5), ENAME    CHAR(20), SAL      NUMERIC, HOBBY    
CHAR(20), WORKS_FOR CHAR (20) } ; 

    Сразу же нужно отметить два важных момента. 
    1.   В языке SQL/X в настоящее время не поддерживаются инструкции PRIMARY 
KEY и FOREIGN KEY. Более того, поскольку здесь преследуется цель сравнить 
выражение создания таблицы CREATE TABLE с выражением создания объектного 
класса CREATE OBJECT CLASS, то в языке SQL/X фактически допускается замена 
ключевого слова TABLE в выражении CREATE TABLE ключевым словом CLASS. Хотя 
последствия добавления такой поддержки не совсем ясны, так как первичные и 
внешние ключи не являются частью концепции объектного класса. 
    2.   В языке SQL/X также не поддерживаются домены. Действительно, при 
записи равенства "отношение = объектный класс" обычно никогда не упоминаются 
домены. Это упущение возникает, вероятно, из-за того, что разработчики и 
распространители не воплотили в своих программных продуктах концепцию доменов, 
а она, в свою очередь, не была воплощена прежде всего потому, что домены не 
были включены в состав исходного стандарта языка SQL. 
    В любом случае, возвращаясь к рассматриваемому примеру, следует отметить, 
что первое расширение языка SQL/X заключается в добавлении поддержки сложных 
столбцов. Таким образом, например, можно заменить исходное выражение CREATE 
TABLE выражением, приведенным ниже (рис. 25.1). 

    ЕМР 
    ЕМР#	ENAME	SAL	HOBBY		WORKS TOR 
    
    NAME | TEAM |		NAME	LOCATION 
    
    | CITY | STATE | 
    
    
    
    
    Рис. 25.1. Таблица со сложными столбцами, созданная согласно стандарту 
языка SQL/X 

    CREATE TABLE EMP 
    ( ЕМР#     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) ) ; 


    Глава 25. Совместное использование... 657 

    Пояснения: 
    •  Для столбца HOBBY (хобби) в таблице ЕМР объявлен тип ACTIVITY 
(деятельность), который, в свою очередь, является таблицей, состоящей из двух 
столбцов — NAME (название) и TEAM (команда), где TEAM представляет число 
игроков в соответствующей команде; например, "деятельность" может быть такого 
типа: (Футбол, 11), Каждое значение HOBBY в действительности является заданной 
парой значений, т.е. значением переменной NAME и значением переменной TEAM. 
(Точнее, это упорядоченная пара значений, которая в данный момент находится в 
таблице ACTIVITY.) Между прочим, эти значения HOBBY не инкапсулированные 
(несмотря на схему, представленную на рис. 25.1). Таким образом, "выражение 
пути" вида EMP.HOBBY.NAME допустимо (подробнее это описывается ниже). 
    •  Аналогично, для столбца WORKS_FOR (место работы) в таблице ЕМР объявлен 
тип COMPANY (компания), который, в свою очередь, является таблицей, состоящей 
из двух столбцов, причем один из них (столбец CITYSTATE (город, штат)) также 
является таблицей из двух столбцов и т.д. 
    Иначе говоря, таблицы ACTIVITY, COMPANY и CITYSTATE рассматриваются либо 
как типы, либо как таблицы (то же правило, конечно же, верно для таблицы ЕМР). 
Таким образом, первое расширение языка SQL/X, грубо говоря, аналогично 
разрешению объектам содержать другие объекты (вариант поддержки иерархии 
контейнеров в языке SQL/X). 
    Следующим расширением является добавление столбцов, содержащих табличные 
значения. Предположим, что сотрудники могут иметь не одно, а произвольное 
число увлечений (рис. 25.2). 


    ЕМР 
    ЕМР#	ENAME	SAL	НС	BBIES			WO	RKS FOR 
    
    NAME	TEAM			NAME	LO	CATION ' 
    CITY | STATE | 
    
    
    Рис, 25.2. Таблица со столбцами, содержащими табличные значения, созданная 
согласно стандарту языка SQL/X 

    CREATE TABLE ЕМР 
    ( ЕМР#     CHAR(S), ENAME    CHAR{20), SAL      NUMERIC, HOBBIES  SET OF ( 
ACTIVITY ), WORKS_FOR COMPANY ) ; 

    Пояснение: 
    •   Теперь значение переменной HOBBIES внутри данной строки таблицы ЕМР 
концептуально является множеством одной или нескольких пар значений (NAME, 
TEAM) таблицы ACTIVITY. Это второе расширение, таким образом, приблизительно 
аналогично разрешению объектам содержать "агрегативные" объекты, что, по сути, 
является более сложной версией иерархии контейнеров. Замечание. 
"Агрегативными" объектными типами, поддерживаемыми в стандарте языка SQL/X, 
являются множества, последовательности и мультимножества. 

    658 Часть VI, Объектно-ориентированные системы 

    В качестве третьего расширения выступает разрешение таблицам иметь 
связанные с ними методы: 

    CREATE TABLE EMP 
    ( ЕМР#     CHAR(5) , 
    ENAME    CHAR(20) , 
    SAL      NUMERIC, 
    HOBBIES  SET OF ( ACTIVITY ), 
    WORKS_FOR COMPANY ) METHOD RETIREMENT_BENEFITS ( ) : NUMERIC ; 

    Пояснения: 
    •   В этом примере RETIREMENTJBENEFITS является функцией (методом), 
которая содержит в качестве аргумента данный экземпляр таблицы ЕМР и выдает 
результат типа NUMERIC. Замечание. В данном случае скобки обязательны, 
поскольку они окружают список (в рассматриваемом примере он пуст) спецификаций 
типа данных для дополнительных аргументов этой функции. 
    •   Код, на основе которого воплощен этот метод, написан на языке С и 
встроенном языке SQL/X и размещается в файле операционной системы. (Имя этого 
файла может быть задано явно как часть утверждения CREATE TABLE. Если это не 
так, то предполагается принятое по умолчанию имя, которое является производным 
от имени метода.) 
    •   Этот метод вызывается с помощью приведенной ниже инструкции CALL. 
    CALL метод (список_аргументов_через__залятую)   ON переменная INTO 
переменная ; 
    •   Например, в приведенном ниже выражении Е и F являются переменными, Е 
содержит идентификатор некоторого частного экземпляра ЕМР, а идентификатор 
результата исполнения этого метода присваивается переменной F. 

    CALL RETIREMENT_BENEFITS   (   )   ON Е INTO F ; 

    •   Здесь, между прочим, следует отметить, что RETIREMENT_BENEFITS не 
является "производным столбцом". В настоящий момент в языке SQL/X не 
поддерживаются столбцы (хотя о наличии такой поддержки в будущем уже было объявлено). 
    Наконец,    последнее    расширение    заключается    в    разрешении    
определять подклассы (рис. 25.3). 

    PERSON 
    SS# 
    BIRTHDATE 
    ADDRESS 
    ЕМР 
    является 
    ЕМР#	ENAME	SAL	HOBBIES				WORKS TOR 
    
    
    NAME	TEAM			NAME	LOCATION 
    
    
    CITY	STATE 
    
    
    Рис. 25.3. Пример суперклассов и подклассов, созданных согласно стандарту 
языка SQL/X 

    CREATE TABLE PERSON 
    ( SS#      CHAR(9), BIRTHDATE DATE, ADDRESS  CHAR(50) ) ; 
    CREATE TABLE EMP 

    Глава 25. Совместное использование... 659 

    AS SUBCLASS OF' PERSON ( EMP#     CHAR(5), ENAME    CHAR(20), SAL      
NUMERIC, HOBBIES  SET OF { ACTIVITY ), WOKKS_FOR COMPANY ) METHOD 
RETIREMENT_BENEFITS ( ) : NUMERIC ; 
    Пояснение'. 
    Таблица ЕМР имеет три дополнительных столбца (SS#, BIRTHDATE, ADDRESS), 
которые наследуются из таблицы PERSON. Если таблица PERSON обладает какими-то 
методами, то эти методы также наследуются. 
    Наряду с описанными вкратце расширениями, касающимися определения данных, 
также потребуются расширения, связанные с манипулированием этими данными. 
    Выражения пути (например, ЕМР.WORKS_FOR.LOCATION.STATE), которые являются 
новым типом скалярного выражения. 

    SELECT ENAME,   WORKS_FOR. NAME 
    FRCM      EMP 
    WHERE WORKS_FOR.LOCATION.STATE = 'CA' ; 

    Следует отметить, что выражения пути записываются в порядке снижения 
иерархии контейнеров. 
    Расширенный вариант выражения пути, который заключается в замене 
однозначного выражения многозначным (например, EMP.HOBBIES.NAME). 

    SELECT ENAME, WORKS_FOR.NAME 
    FRCM  EMP 
    WHERE  { 'Soccer', 'Bridge' } SUBSETEQ HOBBIES.NAME ; 

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

    (   'EOOl',   'Smith',   $50000, 
    {   (   'Soccer',   11  ),   (   'Bridge',   4  )     }, 
    (   'IBM',    (   'San Jose',   'CA'   )   )   ) 

    Операторы сравнения таблиц SUBSET, SUBSETEQ, SETEQ и т.д. (выше приводился 
пример их использования). 
    Операции по отслеживанию иерархии классов. 

    SELECT SS#,   ENAME FROM      EMP ; 

    С помощью инструкции "FRCM f пользователь может обращаться ко всем 
столбцам таблицы Т, включая столбцы, унаследованные от суперкласса (любого 
уровня) этой таблицы Т. И наоборот, с помощью инструкции "FRCM ALL f 
пользователь может обращаться ко всем столбцам таблицы Т, включая столбцы, 
унаследованные от подкласса (любого уровня) этой таблицы Т, 

    SELECT SS#, BIRTHDATE, ENAME FRCM  ALL PERSON ; 

    Замечание. Не совсем ясно, какого типа объекты будут получены в результате 
оценки выражения ALL PERSON, может набор таблиц? 

    Способность вызывать методы в инструкциях WHERE для организации условных 
запросов (во время создания этой книги они не поддерживались). 

    660	Часть VI. Объектно-ориентированные системы 


    •   Способность осуществлять доступ (извлечение и обновление) к отдельным 
значениям внутри многозначных значений. 

    UPDATE EMP 
    SET   HOBBIES = HOBBIES - { 'Soccer', 11 } 
    WHERE ENAME = 'Smith' ; 

    (Сравните это с обсуждением вопроса реляционных операций присвоения и 
обновления, рассмотренных в главе 6.) 
    Теперь рассмотрим некоторые последствия изложенного выше. Прежде всего, 
хотелось бы дать понять, что все приведенные ниже замечания не следует 
рассматривать как критические нападки на язык SQL/X. Скорее, они применимы к 
любой системе или языку, в котором сравниваются отношения и объектные классы. 
Здесь язык SQL/X используется всего лишь в качестве примера. 
    1. Прежде всего, рассматриваемая система не является истинно 
объектно-ориентированной системой. (В качестве дополнительного замечания 
следует отметить, что из-за аспектов, описанных в пунктах 4 и 5, она не 
является системой с "вложенным отношением" или RVA-атрибутом, т.е. атрибутом, 
значениями которого являются отношения). Точнее всего она может быть 
охарактеризована как расширенная SQL-система, а это прежде всего означает, что 
она является SQL-системой. 

    Замечание. Этот комментарий имеет скорее не критический, а разъяснительный 
характер, поскольку, зная об этой особенности, читатель может легко понять 
излагаемый ниже материал. 

    2.  "Объекты" SQL/X являются строками таблиц (таким образом, они полностью 
инкапсулированы), а соответствующие "экземпляры переменных" — столбцами. 
(Вновь хочется отметить, что эти комментарии являются скорее не критикой, а наблюдениями.) 
    3.  Обратите внимание, однако, что в то время как истинно 
объектно-ориентированный класс имеет методы и не имеет общедоступных 
экземпляров переменных, "класс" в языке SQL/X имеет общедоступные экземпляры 
переменных и не обязательно имеет методы. Таким образом, сравнение "отношение 
= класс" выглядит несколько подозрительно. 
    4.  Следует отметить, что существует некоторое различие в определении столбцов 

    ENAME CHAR(20) 

    И 

    WORKS_FOR COMPANY. 

    Причем тип CHAR(20) является истинным типом данных (т.е. он эквивалентен 
истинному, хотя и примитивному, домену), накладывающим постоянное ограничение 
на значения, которые появляются в столбце ENAME. А тип COMPANY, наоборот, не 
является истинным типом данных и накладывает зависящее от времени ограничение 
на значения столбца WORKS_FOR (которое, безусловно, зависит от набора 
значений, находящихся в таблице COMPANY). Фактически здесь стерты все различия 
между "классами", "экземплярами" и "семействами", а концепция истинных доменов 
утрачивается. Однако все последствия такого положения дел остаются невыясненными. 
    5.  Объекты в языке SQL/X могут (в общем случае) содержать другие объекты, 
т.е. они образуют иерархию контейнеров. Однако практически доступ к 
подчиненным объектам осуществляется с помощью указателей (идентификаторов), и 
это нужно четко понимать. Рассмотрим снова объекты ЕМР, содержащие объекты 
COMPANY. Предположим, что пользователь обновляет один из объектов ЕМР, 
например изменяя значение NAME объекта COMPANY. Тогда это изменение немедленно 
распространяется на все объекты ЕМР для всех сотрудников этой же компании. 

    Глава 25. Совместное использование...	661 

    Этот аспект требует некоторых пояснений, 
    • Можно ли вставить новый экземпляр объекта ЕМР и задать значение для 
содержащегося в нем экземпляра объекта COMPANY, которое в данный момент еще не 
существует в таблице COMPANY? Если ответ будет положительным, то задание типа 
COMPANY для столбца WORKS_FOR не будет значить практически ничего, поскольку 
при этом на операцию вставки INSERT не накладывается никаких ограничений. А 
если ответ будет отрицательным, то операция вставки INSERT становится очень 
сложной, так как пользователь должен указать не только допустимый "внешний 
ключ" COMPANY.NAME (как следовало бы поступить в аналогичной ситуации в 
реляционной системе), но и весь допустимый объект COMPANY. Более того, в 
лучшем случае при указании всего объекта COMPANY системе будет повторно 
передана информация, которая ей уже известна, А в худшем — при совершении 
пользователем ошибки определения объекта COMPANY в целом корректная операция 
INSERT не будет выполнена, 
    • Предположим, что для таблицы COMPANY необходимо реализовать правило 
ограниченного удаления DELETE RESTRICTED (т.е. запретить удаление объекта 
компании, если в этой компании работают какие-либо сотрудники). Допустим, что 
это правило может быть реализовано с помощью метода М, Более того, допустим, 
что операции DELETE языка SQL могут быть выполнены только посредством метода 
Л/. Как реализовать это требование? 
    • Аналогичное замечание можно также высказать в отношении правила 
каскадного удаления (DELETE CASCADES), но не в отношении правила удаления 
DELETE NULLIFIES. 
    • При выполнении операции DELETE для таблицы ЕМР предполагается, что 
объект COMPANY не удаляется, несмотря на то что он содержится внутри объекта ЕМР. 
    • Из сказанного выше следует, что речь идет вовсе не о реляционной модели 
и фундаментальным объектом данных является не отношение, содержащее значения, 
а таблица со значениями и указателями. Вследствие этого такие операторы, как 
проекция и соединение, должны быть интерпретированы с особой аккуратностью. 
Однако это довольно обширный вопрос, и ниже он рассматривается отдельно. 
    6.   Упростим приведенную таблицу ЕМР следующим образом: 

    ЕМР (ЕМР#, SAL, WORKS_FOR (NAME, LOCATION (CITY, STATE) ) ) 

    Если теперь выполнить операцию проекции этой таблицы ЕМР по зарплате 
служащего (SAL) и городу (CITY), соответствующему компании где он работает, то 
в каком виде следует получать результат? Будет ли он иметь вид 

    (  SAL,    (   (  CITY  )   )   ) 

    или несколько другой 

    (  SAL,   CITY  )? 

    Оба варианта схематически показаны на рис, 25.4, 
    • Если выбрать первый из двух представленных вариантов (он показан на рис. 
25.4 слева), то какое имя будет иметь столбец, содержащий отношение с 
названиями городов CITY? А также какое имя имеет столбец, который содержит 
упомянутый только что столбец, содержащий, в свою очередь, отношение с 
названиями городов CITY? Замечание. Допустим, что читатель предложит для них 
имена LOCATION.CITY и WORKS_FOR.LOCATION.CITY соответственно. К сожалению, эти 
конструкции не годятся для названий столбцов и не могут быть использованы в 
выражении CREATE TABLE. 

    662	Часть VI, Объектно-ориентированные системы 

    • Если выбрать второй из двух представленных вариантов (он показан на рис. 
25.4 справа), то можно ли в таком случае заключить, что иерархические объекты 
имеют смысл только на уровне "базового объекта" и что при создании любых 
производных объектов фактически происходит возврат в мир реляционных систем? 
Если так, то зачем нужно было отказываться от реляционных систем? 
    
    
    SAL	99	9979999			SAL         CITY 
    $50000   Rome 
    999999 
    
    
    $50000 
    
    
    Рис. 25.4. Какая из этих проекций правильная? 

    • Предполагая, что результат, приведенный на рисунке слева и обозначенный 
выражением (SAL, ( (CITY) )), корректен, как выполнить операцию соединения 
этого результата со всеми городами таблицы CITYSTATE, т.е. допустимо ли сравнение 

    CITY =   (   (  CITY  )   )? 

    Обратите внимание, что значения городов в правой части рис. 25.4 будут по 
крайней мере дважды вложены до выполнения операции действительного сравнения 
(иначе при сравнении либо будет получен ложный результат, либо возникнет 
ошибка сравнения типов). 
    Приведенная выше дискуссия демонстрирует две важных особенности: если 
операция соединения применяется для иерархических объектов, то для них 
потребуется очень строгое определение; даже если это определение будет 
предложено в достаточно аккуратной форме, результирующий оператор будет иметь 
весьма сложный вид. В частности, правила, определяющие характер операции 
соединения, будут очень сложными. Читателю предлагается самому рассмотреть все 
подробности этого вопроса. 
    7.   Вновь возвращаясь к рассматриваемому выше примеру с операцией 
проекции, допустим, что получен некий корректный результат. Что в таком случае 
является классом, а что методами? 
    В рассматриваемом случае объекты ЕМР имеют только один метод, а именно 
RETIREMENT_BENEF1TS, который не применяется к результату этой проекции. 
Практически вряд ли было бы разумно, чтобы любые методы, которые применяются 
для таблицы ЕМР, применялись также к результату проекции. Тем более это 
касается всех остальных методов. Таким образом получается, что никакие методы 
не могут применяться для результата выполнения операции проекции, т.е. каким 
бы ни был результат, он на самом деле не является объектным классом. (Его 
можно так назвать, но при этом он не станет объектным классом, поскольку может 
иметь экземпляры переменных, но не будет содержать методов, тогда как ранее 
уже отмечалось, что истинный объектный класс обладает методами, но не имеет 
экземпляров переменных.) 
    Совершенно ясно, что при сравнении отношений и объектных классов на самом 
деле имеются в виду базовые отношения. (Или, по крайней мере, именованные 
отношения. В языке SQL/X не поддерживаются представления, которые 
рассматриваются как "виртуальные классы". Однако виртуальные классы не 
наследуют

    Глава 25. Совместное использование... 663 

методов, которые содержатся в их родительских классах.) Объектные классы не 
обладают реляционным свойством замыкания, присущим реляционным таблицам. 
    8.  Из предыдущего пункта можно сделать следующий вывод. Предположим, дано 
некоторое базовое отношение R, для которого выполняется операция проекции по 
всем его столбцам. Согласно реляционной алгебре, описанной в главе 6, 
синтаксис для каждой такой проекции будет иметь очень простой вид — R. Таким 
образом, данное выражение "Я" становится двусмысленным! Если под ним понимать 
базовое отношение R, то оно обозначает объектный класс с методами. А если под 
ним понимать проекции по всем столбцам базового отношения R, то оно не 
обозначает объектного класса и не имеет методов. Как в таком случае их можно различить? 
    9.   Наконец, следует отметить, что язык SQL/X устроен гораздо сложнее 
стандартной версии SQL. Такая дополнительная сложность является неизбежным 
следствием выполнения неправильного отождествления (т.е. использования 
сравнения "отношение = объектный класс" вместо "домен = объектный класс"). 
    25.5. Выгоды от совместного использования реляционного и 
объектно-ориентированного подходов 
    В этом разделе подведен краткий итог выгодам от совместного использования 
реляционного и объектно-ориентированного подходов (т.е. метода, при котором 
должным образом используется реляционная концепция доменов и не 
отождествляются ошибочно отношения и объектные классы). 
    Прежде всего, такая система все еще остается реляционной, так что ей 
присущи все обычные преимущества реляционных систем [3.2]. В частности, 
остается в силе преимущество преемственности, т.е. все 
объектно-ориентированные черты представляют собой естественное "расширение" 
(на самом деле это даже не расширение) реляционной модели. 
    Такая система является также объектно-ориентированной системой, которая 
обладает следующими преимуществами. 
    •   Открытая архитектура (расширяемость). Пользователи больше не 
ограничены предопределенными и встроенными типами данных. Такая система может 
быть организована и расширена произвольным образом для удовлетворения всех 
потребностей, возникающих в разных прикладных областях. 
    •   Определенные пользователем типы данных и функции с наследованием. Эти 
преимущества присущи именно объектно-ориентированным системам. 
    •   Строгое определение типов. При должной организации доменов, как 
обсуждалось в главе 19, обеспечивается надежная основа для обнаружения 
нарушений при сравнении типов (чаще всего на этапе компиляции). 
    •   Увеличение быстродействия. Быстродействие повышается, поскольку методы 
выполняются сервером, а не клиентом. (К моменту написания книги эта 
возможность в языке SQL/X еще не была реализована, но в последующих версиях 
будет предложена опция, благодаря которой администратор базы данных может 
указать для каждого метода место его исполнения.) В качестве простейшего 
примера рассмотрим запрос "Найти все книги, в которых содержится более 20 
глав". В традиционной реляционной системе книги могут быть представлены в виде 
базового большого объекта, который, по сути, является строкой байтов 
произвольной длины. При такой организации системы клиент вынужден извлекать 
каждую книгу и проверять, не содержит ли она более 20 глав. Однако при наличии 
должной объектно-ориентированной поддержки сервером может быть выполнен 
некоторый специализированный метод "число глав", а затем клиенту будут 
переданы все требуемые книги. 

    664	Часть VI, Объектно-ориентированные системы 


    Замечание. Все приведенное выше на самом деле является аргументом не в 
пользу объектно-ориентированных систем, а в пользу хранимых процедур 
(подробнее это описано в главе 21). Традиционная реляционная система с 
хранимыми процедурами будет обладать таким же быстродействием, как и 
объектно-ориентированная система с методами. 

    •   Улучшенная производительность. Если определены соответствующие 
объектные классы (домены), пользователи этих классов могут достичь намного 
большей производительности как при создании приложений, так и при их 
использовании, что, вероятно, гораздо важнее. 
    •  Восстановление, параллелизм и безопасность на уровне объектов. Как 
указывалось в главе 22, объекты, т.е. индивидуальные объекты, а не объектные 
классы, являются элементарной единицей для выполнения восстановления, 
управления параллелизмом и обеспечения безопасности в объектно-ориентированной 
системе (при соблюдении ограничений целостности). 
    • Доступность. Сложные объекты теперь становятся доступными для 
пользователей благодаря наличию реляционного языка запросов (возможно, языка SQL). 
    Более того, все критические замечания, высказанные в отношении 
объектно-ориентированных систем в предыдущих главах, могут не приниматься во 
внимание. Конкретнее говоря, в такой системе выполнение перечисленных ниже 
функций не вызовет особых затруднений. 
    •	Незапланированные запросы. 
    •	Двухрежимный доступ (т.е. с использованием одного и того же языка 
программирова	ния как для программируемого, так и для интерактивного доступа к 
базе данных). 
    •	Связи между тремя и более объектами. 
    •	Методы, которые охватывают несколько классов. 
    •	Симметричная обработка. 
    •	Декларативные ограничения целостности. 
    •	Ограничения целостности, которые охватывают несколько классов. 
    •	"Правила внешних ключей" (каскадное удаление и т.д.). 
    •	Семантическая оптимизация. 
    Кроме того, следует также упомянуть и другие преимущества. 
    •  Поиск указателей и идентификаторов объектов теперь полностью скрыт от пользователя. 
    •  "Сложных" вопросов (например, что означает соединение двух объектов), 
связанных с объектно-ориентированной концепцией, более не возникает. 
    •   Преимущества инкапсуляции остаются в силе (для внутренней структуры 
отношений, но не для самих отношений). 
    •   Реляционные системы теперь могут использоваться для "сложных" 
прикладных областей, например для систем САПР/АСУП. 
    В концептуальном отношении этот подход достаточно строгий. 

    25.6. Резюме 

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

    Глава 25. Совместное использование...	665 

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

    Список литературы 

    Здесь следует также упомянуть работы, перечисленные в списках литературы к 
главам 19, 22-24. 
    25.1. Atkinson M. et al. The Object-Oriented Database System Manifesto // 
Proc. First Intern. Conf. on Deductive and Object-Oriented Databases. — Kyoto, 
Japan, 1989; New York, N.Y.: Elsevier Science, 1990. 
    Одна из первых попыток добиться согласия относительно понятия 
"объектно-ориентированная модель". Следующая попытка была предпринята в [25.10]. 
    25.2. Bancilhon F. A Logic-Programming/Object-Oriented Cocktail // ACM 
SIGMOD. — 1986. — 15, № 3. 
    Цитата из введения: "Объектно-ориентированный подход... кажется наиболее 
приемлемым для управления такими новыми типами приложений, как САПР, для 
разработки программного обеспечения и для исследований в области 
искусственного интеллекта. Однако естественное расширение до реляционной 
методики управления базами данных является... логической программной 
парадигмой, а не объектно-ориешпрованной. В этой статье рассматривается 
возможность совмещения этих двух парадигм". 
    25.3. Beech D. A Foundation for Evolution from Relational to Object 
Databases // Schmidt, Ceri, Missikof. Extending Database Technology. — New 
York, N.Y.: Springer-Verlag, 1988. 
    Это одна из многих статей, в которых обсуждались возможности расширения 
языка SQL до некоторой разновидности "объектного SQL" (object SQL — OSQL). 
Более подробно этот вопрос рассматривается также в [25.7]. В целом в подобных 
работах очень мало или почти ничего не говорится о доменах, замыкании или 
таких реляционных операторах, как соединение, и это опять способствует 
возникновению ошибочного отождествления "отношение = класс". При этом сделано 
несколько спорных утверждений о возможности "мягкой адаптации" языка SQL. Ниже 
приводится пример утверждения CREATE FUNCTION на языке OSQL, взятого из [25.7]. 

    CREATE FUNCTION RaiseAllSalaries (Integer incr) AS UPDATE Salary(e) = newsal 

    666	Часть VI, Объектно-ориентированные системы 

    FOR EACH Employee e, Integer newsal WHERE newsal = Salary(e) + incr ; 
    Может показаться, что это выражение написано в стиле стандарта языка SQL: 
    CREATE FUNCTION RaiseAllSalaries (Integer incr) AS UPDATE Employee SET 
Salary = Salary + incr ; 
    Так же как и в стандарте языка SQL/X, типы (таблицы) не являются инкапсулированными. 
    Замечание. Одним интересным аспектом языка OSQL является то, что, в 
отличие от объектно-ориентированных языков, методы (т.е. функции) сами по себе 
рассматриваются как объекты. 
    25.4. Cattell R.G.G. What Are Next-Generation DB Systems? // CACM. — 
1991.— 34, № 10. 
    25.5. Goodman N. Object Oriented Database Systems // InfoDB. — 1989. — 4, 
№ 3. 
    Приведем цитату из этой статьи: "На данном этапе не имеет смысла 
сравнивать реляционный и объектно-ориентированный подходы. Следует сравнивать 
лишь подобные понятия: например, яблоки с яблоками, мечты с мечтами, теорию с 
теорией и зрелые продукты со зрелыми продуктами". 
    Эту мысль можно развить следующим образом: "Оставляя в стороне мечты, 
следует отметить, что некоторое время реляционный подход использовался потому, 
что имел строгий теоретический базис и лежал в основе большого количества 
добротных программных продуктов. Объектно-ориентированный подход, наоборот, 
является новым (по крайней мере в области создания баз данных), он не обладает 
той теоретической основой, которая сравнилась бы с реляционной моделью, и 
немногие программные продукты, созданные на его основе, могут быть 
охарактеризованы как добротные. Таким образом, прежде чем заявить об 
объектно-ориентированном подходе как об альтернативе реляционному подходу, 
придется выполнить очень большой объем работы." 
    Несмотря на то что большая часть высказанных здесь замечаний еще остается 
в силе, все же со времени предыдущего издания этой книги некоторые неясные 
прежде понятия несколько прояснились. Во многих сравнениях реляционные и 
объектно-ориентированные системы уже могут рассматриваться как "яблоки и 
апельсины". Как отмечалось в главе 24, реляционная СУБД готова к употреблению, 
а объектно-ориентированная СУБД является лишь некой разновидностью набора 
инструментов для создания СУБД специализированного назначения. 
    25.6. Kifer M., Kirn W., Sagiv Y. Querying Object-Oriented Databases // 
Proc. ACM Intern. Conf. on Management of Data. — San Diego, Calif, 1992. 
    В работе предлагается еще один "объектный вариант языка SQL" под названием XSQL. 
    25.7. Lyngbaek P. et al. OSQL: A Language for Object Databases // 
Technical Report HPL-DTD-91-4. — Hewlett-Packard Company, 1991. 
    См. комментарий к [25.3]. 
    25.8. Shaw G.M., Zdonik S.B. A Query Algebra for Object-Oriented Databases 
// Proc. 6th Intern. Conf. on Data Engineering.— 1990. (Опубликована также в 
виде технического отчета: Technical Report TR CS-89-19, Dept. of Computer 
Science. — Providence, R.I.: Brown University, 1989.) 
    Эта статья подтверждает мнение автора данной книги о том, что "любая 
объектно-ориентированная алгебра" является сложной из-за сложной

    Глава 25. Совместное использование...	667 

организации самих объектов. В частности, для выполнения операции сравнения 
иерархических объектов с произвольной сложностью вложенных уровней потребуется 
очень тщательная организация всего этого процесса. Основная идея статьи 
заключается в том, что каждый оператор алгебры запросов приводит к созданию 
отношения, каждый кортеж которого содержит идентификаторы некоторых объектов 
базы данных. В случае операции соединения, например, каждый кортеж будет 
содержать идентификаторы объектов, которые соответствуют друг другу для 
заданного условия соединения. Эти кортежи не наследуют никаких методов объектов-компонентов. 
    25.9. Shipman D.W. The Functional Data Model and the Data Language DAPLEX 
// ACM TODS. — 1981. — 6, № I. (Переиздано: М. Stonebraker (ed.). Readings in 
Database Systems, — San Mateo, Calif: Morgan Kaufmann, 1988.) 
    Существует несколько попыток создания систем, в основе которых вместо 
отношений используются функции, и среди них наиболее известной является 
система DAPLEX. Функциональные подходы обладают некоторыми чертами, 
характерными для объектно-ориентированных систем, включая, в частности, стиль 
адресации объектов (с помощью указания пути), которые функционально относятся 
к другим объектам (которые, в свою очередь, также относятся к другим объектам 
и т.д.). Обратите внимание, однако, что термин "функция" в этих так называемых 
функциональных моделях вовсе не имеет никакого отношения к математической 
функции. Например, такая функция вполне может быть многозначной. Практически 
традиционное понятие функции должно претерпеть значительные изменения для 
того, чтобы удовлетворить всем требованиям, которые предъявляются в контексте 
"функциональной модели данных". В таком состоянии, в котором они здесь 
представлены, функциональный и объектно-ориентированный подходы, по мнению 
автора данной книги, являют ся разными названиями одного и того же понятия. 
    25.10. Stonebraker M. et al. Third Generation Database System Manifesto // 
ACM SIGMOD.— 1990. — 19, № 3. 
    Отчасти эта работа противопоставляется работе [25.1], Цитата: "Системы 
второго поколения внесли большой вклад в развитие непроцедурного доступа к 
данным и независимости от данных, и этим вкладом нельзя пренебрегать при 
разработке систем третьего поколения". Приведенные ниже положения являются, по 
сути, требованиями (в некоторой степени перефразированными), которые 
предъявляются к "СУБД третьего поколения". 
    1.  Обеспечение традиционных служб базы данных, а также более развитых 
объектных структур и правил. 
    • Система с более развитыми типами. 
    • Наследование. 
    • Функции и инкапсуляция. 
    • Назначаемые системой по мере необходимости идентификаторы кортежей 
(здесь может возникнуть некоторая путаница между идентификаторами объектов и 
идентификаторами кортежей). 
    • Правила (например, правила целостности), не связанные с некоторыми объектами. 
    2.  Преемственность СУБД второго поколения. 
    • Использование путей для адресации объектов только в крайнем случае. 
    • Определения интенсиональных и экстенсиональных множеств (которые 
означают семейства, автоматически поддерживаемые со стороны системы, и 
семейства, поддерживаемые вручную пользователем). 

    668	Часть VI. Объектно-ориентированные системы 

    • Обновляемые представления. 
    • Кластеризация, индексирование и т.д., скрытые от пользователя. 3.   
Поддержка открытых систем. 
    • Поддержка нескольких языков. 
    • Поддержка языка SQL. 
    • Запуск запросов и вывод результатов, осуществляемые на самом низком 
уровне общения между клиентом и сервером. 
    По мнению автора этой книги, поддержка языка SQL для "сложных объектов" 
может быть выполнена в истинной абстрактной объектно-ориентированной системе, 
только если объектная структура также является существенной частью этой модели. 
    При этом можно было бы заложить основу для декларативного задания 
ограничений целостности и обеспечения декларативной поддержки представлений. 
    25.11. UniSQL Inc. UniSQL/X Database Management System User's Manual: 
Release 1.2.— 1991. 
    Довольно подробно этот программный продукт (UniSQL/X) рассматривался выше 
в этой главе. Следует отметить, что поскольку СУБД UniSQL/X действительно 
является расширенной версией системы на основе SQL, а не истинной 
объектно-ориентированной СУБД, то представленные ранее критические замечания 
по поводу объектно-ориентированных систем не относятся к системе на основе 
UniSQL. Более точно это можно сформулировать следующим образом. 
    • В UniSQL поддерживаются представления ("виртуальные классы"). Они имеют 
свои собственные методы, т.е. они не наследуют методы из родительских таблиц 
(классов). Между прочим, в этом руководстве термины "классы" и "виртуальные 
классы" используются в том смысле, что виртуальные классы не являются 
классами. Эта ситуация напоминает известную проблему "таблиц и представлений" 
для стандарта языка SQL, которая предполагает, что представления не являются таблицами. 
    • В UniSQL предусмотрена поддержка производных объектов, т.е. в нем 
поддерживаются все реляционные операторы: соединения, объединения и т.п. 
Однако эти производные объекты не рассматриваются как классы, а потому не 
совсем ясно, какого типа объекты будут получены в результате выполнения этих операций. 
    • Продукт UniSQL содержит также язык SQL/X для программного и 
интерактивного доступа к базе данных. Более того, этот язык функционирует на 
уровне множеств, а потому созданные с помощью SQL/X запросы могут быть 
оптимизированы. К тому же в нем поддерживается симметричная обработка. 
    • В UniSQL поддерживается обработка отсутствующей информации, так как 
предусмотрена обработка отсутствующих значений в стиле языка SQL, a также 
(ограниченная) обработка значений, которые заданы пользователем по умолчанию. 
    • В нем также поддерживается предопределенный системный каталог. 
    • Наконец, в нем предусмотрена отдельная инструкция для создания кластера 
CREATE CLUSTER, которая означает, что в отличие от некоторых 
объектно-ориентированных систем независимость от данных не будет существенно 
нарушена, если логическое определение базы данных будет определять характер 
физической кластеризации. 

    Глава 25. Совместное использование...	669 

    25.12. Zaniolo С. The Database Language GEM // Proc. 1983 ACM SIGMOD 
Intern, Conf. on Management of Data.— San Jose, Calif., 1983. (Переиздано: М. 
Stonebraker. Readings in Database Systems. — San Mateo, Calif: Morgan 
Kaufmann, 1988.) 
    Сокращение GEM (General Entity Manipulator) обозначает расширение языка 
QUEL, в котором поддерживаются отношения, не находящиеся в первой нормальной 
форме (т.е. отношения с атрибутами, значениями которых являются множества), и 
отношения с альтернативными атрибутами (например, одни объекты сотрудников ЕМР 
имеют атрибут постоянной зарплаты SALARY, а другие объекты сотрудников ЕМР 
имеют атрибут почасовой оплаты HOURLY_WAGE и атрибут сверхурочной оплаты 
OVERTIME). Кроме того, в нем также поддерживается объектно-ориентированная 
идея о том, что одни объекты концептуально содержат другие объекты (они 
используются вместо внешних ключей, которые ссылаются на другие объекты). 
Причем привычная запись с использованием точки расширена для ссылок на 
атрибуты таких объектов (хотя на самом деле при этом неявно просматриваются 
некоторые предпочтительные пути соединения). Например, выражение 
ЕМР.DEPT.BUDGET может быть использовано для обращения к бюджету отдела, в 
котором работает определенный сотрудни к. Многие другие системы, включая 
POSTGRES [25.13-25.16] и UniSQL [25.11], либо адаптированы к восприятию этой 
идеи, либо построены на ее основе. 

    Расширяемые системы 

    В последние годы предпринималось множество попыток создания систем, 
которые являются реляционными и все еще способны (как объектно-ориентированные 
системы) к расширению, т.е. они позволяют высококвалифицированным 
пользователям (называемым "настройщиками баз данных") настроить систему 
заданным образом, например определить собственные типы данных, собственные 
функции, собственные структуры хранения и т.д. Среди них наиболее известны 
система POSTGRES, разработанная в университете штата Калифорния в Беркли, и 
система Starburst, разработанная в фирме IBM. Ниже приводится краткий список 
литературы об этих системах. Обратите внимание, что ни одна из этих систем не 
может быть отнесена к разряду систем, в которых допускается отождествление 
"домен = объектный класс", рассматриваемое в этой главе. 
    25.13. Stonebraker М., Rowe L.A. The Design of POSTGRES // Proc. ACM 
SIGMOD Intern. Conf. on Management of Data. — Washington, D.C., 1986. 
    В работе приведены основные цели создания системы POSTGRES. 
    1.  Обеспечение усовершенствованной поддержки сложных объектов. 
    2.   Обеспечение расширяемости типов данных, операторов и методов доступа. 
    3.  Обеспечение активных инструментов базы данных (аварийных и пусковых), 
а также поддержка логических выводов. 
    4.  Упрощение кода СУБД для восстановления после краха системы. 
    5.  Проектирование СУБД с учетом преимуществ оптических дисков, 
многопроцессорных рабочих станций и специальных чипов на основе сверхбольших 
интегральных схем. 
    6.   Минимальное количество изменений реляционной модели (а может быть, 
даже никаких изменений). 
    25.14. Stonebraker М. The Design of the POSTGRES Storage System // Proc. 
13th Intern. Conf. on Very Large Data Bases. — Brighton, England, 1987. 
    25.15. Rowe L.A., Stonebraker M.R. The POSTGRES Data Model // Ibid. 

    670	Часть VI. Объектно-ориентированные системы 

    25.16. Stonebraker M., Kemnitz G. The POSTGRES Next Generation Database 
Management System // CACM. — 1991. — 34, № 10. 
    25.17. Lindsay В., McPherson J., Pirahesh H. A Data Management Extension 
Architecture // Proc. ACM SIGMOD Intern. Conf. on Management of Data. — San 
Francisco, Calif., 1987. 
    В работе описана архитектура прототипа системы Starburst, который 
"воплощает расширение управления данными для реляционных СУБД". Описаны два 
типа такого расширения: на основе определенных пользователем структур хранения 
и методов доступа, а также на основе определенных пользователем ограничений 
целостности и включаемых процедур. Однако "помимо этих существуют также другие 
направления расширения СУБД, включая определенные пользователем абстрактные 
типы данных и технологии оценки запросов". Подробнее это описано в [25.18]. 
    25.18. Haas L.M., Freytag J.C., Lohman G.M., Pirahesh H. Extensible Query 
Processing in Starburst // Proc. ACM SIGMOD Intern. Conf. on Management of 
Data. — Portland, Ore., 1989. 
    В работе представлены цели расширенного проекта Starburst [25.17]: "В 
Starburst предусмотрено добавление новых методов хранения таблиц, новых типов 
доступа и ограничений целостности, новых типов данных, функций и новых 
операций с таблицами". При этом система делится на два основных компонента— 
Core и Corona, которые соответствуют компонентам RSS и RDS оригинальной 
системы System R [8.12-8.16]. В компоненте Core поддерживаются функции 
расширения, описанные в [25.17], а в компоненте Corona — язык запросов 
Hydrogen, который является диалектом языка SQL. В этом диалекте исключено 
большинство ограничений воплощения языка SQL, принятого в системе System R, он 
более ортогонален, поддерживает рекурсивные запросы и может быть расширен 
пользователем. В статье содержится интересное обсуждение проблемы 
переписывания запросов, т.е. правила трансформации языка Hydrogen, которые 
используются оптимизатором для преобразования ^запросов в семантически 
эквивалентную, но более эффективную форму (см. глав у 18). Об этом также можно 
прочесть в [18.44]. 
    25.19. Lohman G.M. et al. Extensions to Starburst: Objects, Types, 
Functions and Rules //CACM.— 1991. —34, № 10. 

    Глава 25. Совместное использование,..	671 

