Это отличие... не следует приписывать различию между собственно реляционной и объектными моделями... В основном, эти различия обусловлены [особенностями реализации].

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

Подобная, но более обширная, тестовая программа 007 описана в [24.10].

Является ли объектная СУБД действительно СУБД?

Замечание. В данном подразделе излагаются суждения и наблюдения, которые, в основном, взяты из [24.18]. В этой работе, помимо всего прочего, утверждается, что различия между объектными и реляционными системами гораздо сушественнее, чем это обычно представляется.

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

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

1. Совместный доступ со стороны нескольких приложений.

2. Физическая независимость данных.

3. Возможность выполнения произвольных запросов.

4. Поддержка представлений и логической независимости данных.

5. Поддержка декларативных ограничений целостности, независимых от приложений.

6. Поддержка прав владения данными и гибкий механизм обеспечения их защиты.

7. Управление совместным доступом.

8. Каталог общего назначения.

9. Возможность проектирования базы данных независимо от приложений.

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

Для сравнения рассмотрим следующие замечания.

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

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

Кроме того, отмети.м, что результат подгонки такой базы будет специфическим для конкретных приложений. Эта система может подходить, например, д.пя приложений САПР/АСУТП, но быть совершенно непригодной, например, для медицинских приложений. Иначе говоря, она все еще не стала СУБД общего назначения в том смысле, в котором реляционная СУБД является СУБД общего назначения.

В той же статье [24.18] оспаривается так называемая идея устойчивой нечувствительности к типам из [24.2], в соответствии с которой в базу данных можно включать (изменяемые) объекты произвольной сложности.

Для объектной модели требуется поддержка [большого количества] генераторов типа... Например, таких типов, как структура (STRUCT), кортеж (TUPLE), список (LIST), массив (ARRAY), набор (SET), пакет (BAG) и т.д... В.месте с идентификаторами объектов наличие таких генераторов типов означает, что любая структура данных, которая может быть создана в программе приложения, может быть также создана как объект в объектной базе данных, и, кроме того, такая структура объектов видна пользователю. Например, рассмотрим объект (скажем, ЕХ), который является (или обозначает) коллекцией служащих в отделе. Тогда объект EX.может быть реализован как связанный список или как .массив, и пользователи должны будут знать, как именно реализован этот объект, поскольку соответствующие операторы доступа отличаются.

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

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

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

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

24.6. Резюме

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

Классы объектов. Классы объектов соответствуют типам данных и, безусловно, очень важны. По существу, это наиболее фундаментальная концепция из всех.

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

Идентификаторы объектов. Не нужны и даже вредны (на уровне модели), поскольку по существу это указатели. См. [24.19], где этот вопрос рассматривается подробно.

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

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

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