24.6. Резюме

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

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

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

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

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

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

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

Замечание. Иерархия (некапсулированная), которая действительно включала бы объекты как таковые, могла бы быть возможной, хотя и противопоказанной. Это могло бы быть аналогом чему-то, подобному переменной-отношению, имеющей атрибуты, значением которых служат отношения (см. часть II и III этой книги).

■ Методы. Это, конечно, важное понятие, хотя мы предпочли бы более привычный термин операторы. Но объединение методов с операторами не является обяза­тельным и приводит к некоторым проблемам [3.3]. Раздельное определение "классов" (типов) и "методов" (операторов), как было показано в главе 5, позволя­ет обойтись без использования понятия объекта-получателя.

Существуют некоторые операторы, на включении которых мы бы настаивали: операторы выборки, которые, кроме всего прочего, предоставляют возможность записи литеральных значений соответствующего типа, операторы ТНЕ_, опера­торы присвоения и сравнения на эквивалентность, а также операторы проверки типа (см. главу 19).

Замечание. Однако мы бы отказались от функций-конструкторов. Конструкторы создают переменные. А поскольку для нас единственными необходимыми пере­менными в базе данных являются переменные-отношения, единственный "кон­структор", который нам нужен, — это оператор создания переменной-отношения, т.е. CREATE TABLE или CREATE VIEW (по терминологии языка SQL). Операторы вы­борки, наоборот, выбирают значения. Конечно, дополнительное отличие в том, что конструкторы возвращают указатели на созданные переменные, в то время как операторы выборки возвращают сами выбранные значения.

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

• Иерархия классов. С иерархией классов связаны такие понятия, как наследова­ние, полиморфизм, перегрузка, переопределение и т.д. Считаем, что понятие нуж­ное, но производное. Мы рассматриваем поддержку иерархии классов как состав­ляющую поддержки самих классов.

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

• Связи. В главе 13 (раздел 13.6) уже оспаривалась идея трактовки "связей" как формально отдельной конструкции (особенно если это лишь бинарная связь, ко­торая и заслужила такую специальную трактовку). Мы также не считаем удачной трактовку связанных ограничений ссылочной целостности, которая расходится с трактовкой ограничений целостности вообще (см. ниже).

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

Теперь перечислим возможности, которые в "объектных моделях" обычно не под­держиваются или поддерживаются не в полной мере,

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

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

Замечание. В некоторых объектных системах поддерживаются "производные" или "виртуальные" переменные экземпляра (обязательно открытые). Например, пере­менная экземпляра AGE (возраст) может наследоваться с помощью вычитания зна­чения переменной экземпляра BIRTH-DATE (дата рождения) от текущей даты. Од­нако такая возможность еще очень далека от возможностей, которые предостав­ляются с помощью механизма представлений; и кроме того, мы уже отказались от понятия открытой переменной экземпляра.

• Декларативные ограничения целостности. Обычно не поддерживаются (в ос­новном, по тем же причинам, что и представления и обработка незапланирован­ных запросов ). Более того, они обычно не поддерживаются даже теми системами, которые поддерживают незапланированные запросы.

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

• Замыкание. Сложно найти объектный аналог реляционному свойству замк­нутости.

• Каталог. Где же каталог в объектной системе? Как он выглядит? Есть ли какие-либо стандарты?

Замечание. Конечно, это вопросы риторические. Каков будет реальный ре­зультат, если такой каталог будет создан специалистом-профессионалом, ко­торому будет поручено выполнить подгонку объектной СУБД, устанавливае­мой для какого-либо приложения, как обсуждалось в разделе 24.5. (Такой ка­талог будет специфическим для данного приложения, как, впрочем, и вся на­строенная СУБД.)

Подытожив сказанное выше, можно отметить полезные (существенные, фундамен­тальные) понятия и концепции "объектной модели" (такие, которые желательно под­держивать).

Понятие

Предпочтительный термин

Замечания

Класс объекта

Неизменяемый объект Изменяемый объект Метод

Сообщение

Тип

Значение

Переменная

Оператор

Вызов оператора

Скаляр и нескаляр; может опре­деляться пользователем Скаляр и нескаляр Скаляр и нескаляр Включает операторы выборки, операторы "ТНЕ_", ":=", "=" и оператор проверки типа Никаких "целевых" операндов

Более кратко можно сказать, что единственная хорошая идея объектных систем в це­лом — это надлежащая поддержка типов данных (все остальное, включая понятия операторов, определяемых пользователем, следует из этой идеи)¹⁶. Но данную идею вряд ли можно назвать новой!

Упра^кнения

24.1. Дайте определения следующим терминам.

закрытая переменная экземпляра защищенная переменная экземпляра идентификатор объекта иерархия вложения иерархия классов инкапсуляция

класс

метод

обратная переменная

открытая переменная экземпляра

объект

объект, определяющий класс сообщение

функция конструктора

2. В чем заключаются недостатки и преимущества использования идентификаторов объектов? Каким образом можно реализовать идентификаторы?

3. В разделе 24.2 были представлены две формулировки SQL-запроса "Найти все пря­моугольники, которые покрывают какую-нибудь область квадрата (0, 0, 1, 1)". До­кажите, что эти формулировки эквивалентны.

4. Исследуйте любую доступную вам объектную СУБД. Какой язык программирова­ния поддерживается в этой системе? Поддерживается ли в ней язык запросов? Ес­ли поддерживается, то какой? Является ли он, по вашему мнению, более мощным, чем язык SQL? Как организован каталог системы? Как пользователь опрашивает каталог? Предусмотрена ли в этой системе поддержка представлений? Если преду­смотрена, то в какой степени (например, поддерживается ли в ней обновление представлений)? Как обрабатывается "отсутствующая информация"?

5. Составьте макет объектной версии используемой в этой книге базы данных по­ставщиков и деталей.

¹⁶ Кое-кто может возразить, что наследование типа — также хорошая идея. Мы против этого не возражаем, а лишь настаиваем на том, что поддержка наследования не относится ис­ключительно к поддержке объектов как таковых.

Замечание. Этот макет будет использоваться как основа для приведенных ниже упр. 24.6-24.8.

6. Составьте подходящий набор утверждений определения данных на языке OPAL для объектной версии базы данных поставщиков и деталей.

7. Схематически обрисуйте детали методов "пополнения базы данных" объектной версии базы данных поставщиков и деталей.

8. Составьте код на языке OPAL для реализации приведенных ниже запросов в объ­ектной версии базы данных поставщиков и деталей.

а) Выбрать сведения обо всех поставщиках, находящихся в городе ' London'.

б) Выбрать сведения обо всех деталях красного цвета ('Red').

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

а) Удаление слушателя

б) Удаление служащего

в) Удаление курса

г) Удаление класса слушателей

д) Удаление класса служащих

Подразумевается, что в каждом случае используется механизм автоматической сборки мусора языка OPAL. Приведите любые допущения, которые необходимо сделать относительно таких аспектов, как организация каскадного удаления и др. 24.10.Допустим, что база данных поставщиков, деталей и проектов организована с ис­пользованием простой объектной иерархии вложения. Сколько таких иерархий можно реализовать? Какая из них является наилучшей? 24.11. Рассмотрите вариант базы данных поставщиков, деталей и проектов, в котором вме­сто записей о том, что некоторые поставщики поставляют некоторые детали для не­которых проектов, содержатся записи о том, что некоторые поставщики поставляют некоторые детали, некоторые детали поставляются для некоторых проектов и неко­торые проекты обеспечиваются деталями от некоторых поставщиков. Сколько таких объектных макетов можно реализовать (с учетом или без учета иерархии вложения)? 24.12.0пишите основные факторы, оказывающие влияние на производительность объ­ектных систем и кратко обсуждавшиеся в разделе 24.5. Справедливо ли утвержде­ние, что они характерны только для объектных систем? Обоснуйте свой ответ. 24.13. В объектных системах ограничения целостности обычно поддерживаются процедур­но, т.е. с помощью методов, за исключением ограничений целостности на уровне ссылок, которые обычно поддерживаются, по крайней мере частично, декларативно. В чем состоит преимущество процедурного способа поддержки ограничений целост­ности? Почему ограничения целостности на уровне ссылок поддерживаются иначе?

24.14.0бъясните смысл концепции обратных переменных.

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

Публикации [24.5], [24.7], [24.11], [24.15], [24.26], [24.31], [24.38], [24.41] и [24.50] пред­ставляют собой книги по объектной тематике и связанным с ней вопросам. Публикации [24.35], [ 24.36] и [24.52] — это сборники научно-исследовательских работ, а [24.27], [ 24.28], [24.44] и [24.47] — учебные пособия. В работах [24.4], [24.9], [24.23] и [24.37] описываются конкретные системы.

24.1. Atkinson M.P. et al. The Object-Oriented Database System Manifesto // Proc. 1st Int. Conf. on Deductive and Object-Oriented Databases. — Kyoto, Japan, 1989. New York, N.Y.: Elsevier Science. — 1990.

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

1.	Коллекции	8. Типы, определяемые пользователем
2.	Объектные идентификаторы	9. Устойчивость
3.	Инкапсуляция	10. Поддержка больших баз данных
4.	Типы или классы	11. Параллельный доступ к данным
5.	Наследование	12. Восстановление
6.	Позднее связывание	13. Произвольные запросы
7.	Вычислительная полнота

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

Замечание. В [3.3] и [25.34] комментируется эта статья. Относительно коммента­риев в [3.3] необходимо отметить, что они основываются на предпосылке, что на­значение статьи — определить свойства лучших, настоящих СУБД общего назна­чения. Мы не отрицаем, что перечисленные выше свойства могут быть полезны для специализированных СУБД, которые связаны с конкретным приложением, на­пример САПР/ОАСУП, для которого не требуется, скажем, поддержка ограниче­ний целостности. Однако тогда возникает вопрос, является ли такая система сис­темой управления базами данных в полном смысле этого понятия.

24.2. Atkinson М.Р., Buneman О.Р. Types and Persistence in Database Programming Languages // ACM Сотр. Surv. — June, 1987. — 19, № 2.

Одна из ранних статей, если не самая ранняя, в которой формулируется точка зре­ния, согласно которой перманентность в языках программирования баз данных не должна зависеть от типов. Эта статья рекомендуется в качестве вводного пособия по изучению языков программирования баз данных в целом ("языки программиро­вания баз данных" многими воспринимались как необходимое условие объектных систем; см., например, [24.11], [24.12]).

24.3. Bancilhon F. A Logic-Programming/Object-Oriented Cocktail // ACM SIGMOD.— September, 1986. — 15, № 3.

Цитата из введения: "Объектно-ориентированный подход... кажется наиболее приемле­мым для управления такими новыми типами приложений, как САПР, для разработки программного обеспечения и для исследований в области искусственного интеллекта. Однако естественное расширение управления базами данных до реляционной методики является... не объектно-ориентированной, а логической программной парадигмой. В данной статье рассматривается возможность совмещения этих двух парадигм". Отсюда с некоторой долей предосторожности можно заключить, что они совместимы.

Замечание. В [24.49] предлагается противоположная точка зрения.

4. Banerjee J. et al. Data Model Issues for Object-Oriented Applications // ACM TOOIS (Transaction on Office Information Systems). — March, 1987. — 5, № 1. (Эта работа также опубликована в М. Stonebraker (ed.). Readings in Database Systems. — San Mateo, Calif: Morgan Kaufinann, 1994, а также в [24.52].)

5. Barry D.K, et al. The Object-Oriented Database Handbook: How to Select, Implement, And Use Object-Oriented Databases. —New York, N.Y.: John Wiley and Sons. — 1996. Основная мысль этой книги заключается в том, что если мы имеем дело со "сложными данными", необходима объектная система, а не реляционная. Сложные данные характеризуются как а) вездесущие, б) зачастую с недостаточной уникаль­ной идентификацией, в) с использованием многочисленных связей типа "многие ко многим" и г) часто требующие использования кодов типов "в реляционной схеме" (поскольку в современных SQL-продуктах имеется недостаточная непосредствен­ная поддержка для подтипов и супертипов).

Замечание. Автор является исполнительным директором группы Object Data Management Group (ODMG) [24.12].

6. Beech D. A Foundation for Evolution from Relational to Object Databases // Schmidt, Ceri, Missikoff. Extending Database Technology. — New York, N.Y.: Springer Verlag, 1988. Это одна из многих статей, в которых обсуждались возможности расширения язы­ка SQL до некоторой разновидности "объектного SQL" (необходимо предупредить читателя, что такой "объектный SQL" часто не очень похож на привычный SQL). Более подробно этот вопрос рассматривается также в [24.39].

7. Bertino Е., Martino L. Object-Oriented Database Systems: Concepts and Architectures. — Reading, Mass.: Addison-Wesley, 1993.

8. Bj6rnerstedt A., Hulten C. Version Control in an Object-Oriented Architecture. (Опубликована в [24.36].)

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

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

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

• Возможность удаления и, возможно, архивирования устаревших версий.

• Возможность запроса истории версий данного объекта.

Заметим, что, как показано на рис. 24.7, истории версий не обязательно связаны линейно (из версии V.2 образуются две разные версии, V.3a и V.3b, которые затем сливаются в версию V.4).

V.3a

V.1

V.2

V.4

►и т.д.

V.3b

Рис. 24.7. Типичная история версий объекта

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

• Возможность копирования версии объекта из одной конфигурации в другую (например, из "старой" конфигурации в "новую").

• Возможность перемещения версии объекта из одной конфигурации в другую (т.е. ее вставки в "новую" конфигурацию и удаления из "старой").

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

24.9. Butterworth P., Otis A., Stein J. The GemStone Object Database Management System // CACM. — October, 1991. — 34, № 10.

24.lO.Carey M.J., DeWitt D.J., Naughton J.F. The 007 Object-Oriented Databases Benchmark // Proc. 1993 ACM SIGMOD Int. Conf. on Management of Data. — Washington, DC, May, 1993.

24.11.Cattell R.G.G. Object Data Management (пересмотренное издание).— Reading, Mass.: Addison-Wesley, 1994.

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

это приведет к сложным проблемам оптимизации, и лишь некоторые исследовате­ли обладают необходимым опытом... объединенные [объектные] базы данных тре­буют более глубокого изучения". 24.12.Cattell R.G.G., Barry D.K. The Object Database Standard: ODMG 2.0. — San Francisco, Calif; Morgan Kaufrnann, 1997.

Термин ODMG, говоря нестрого, обозначает проекты группы Object Data Management Group, консорциума представителей "членов компаний, [охватывающих] почти всю от­расль объектных СУБД". Эти проекты включают объектную модель, объектный язык оп­ределений (ODL), объектный формат обмена (OIF), объектный язык запросов (OQL) и привязки этих возможностей к языкам С++, Smalltalk и Java. (Компонент "язык обработки объектов" отсутствует, а вместо него предоставляются возможности обработки объектов с помощью любого языка, для которого ODMG предоставляет привязку.) Детальный анализ и критику объектной модели ODMG можно найти в [3.3]; к это­му вопросу также имеет отношение [24.34]. 24.13.Cattell R.G.G., Skeen J. Object Operations Benchmark // ACM TODS. — March, 1992. — 17, № 1.

24.14.Copeland G., Maier D. Making Smalltalk a Database System // Proc. 1984 ACM SIGMOD Intern. Conf. on Management of Data.— Boston, Mass.,— June, 1984. (Переиздано: M. Stonebraker. Readings in Database Systems (2-е изд.). — San Mateo, Calif: Morgan Kaufrnann, 1994.)

В работе описаны некоторые усовершенствования и изменения, внесенные в язык Smalltalk [24.26] при создании СУБД GemStone и языка OPAL. 24.15.Сох B.J. Object Oriented Programming: An Evolutionary Approach. — Reading, Mass.: Addison-Wesley, 1986.

Учебное пособие по использованию объектных методов в области программирова­ния. Некоторое внимание в нем уделяется применению этих методов для разработ­ки программного обеспечения. 24.16.DahI O.J., Myhrhaug В., Nygaard К. The SIMULA 67 Common Base Language. Pub. S-22. — Oslo, Norway; Norwegian Computing Center, 1970.

Язык SIMULA 67 спроектирован специально для создания имитационных прило­жений. Именно на основе таких языков программирования и была создана объект­ная технология. Фактически язык SIMULA 67 был первым объектным языком.

24.17.Date C.J. An Optimization Problem // C.J. Date and Hugh Darwen. Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992.

24.18.Date C.J. Why the Object Model' Is Not a Data Model // Date C.J., Darwen H. and McGoveran D. Relational Database Writings 1994-1997.— Reading, Mass.: Addison-Wesley, 1998.

24.19.Date C.J. Object Identifiers vs. Relational Keys // Date C.J., Darwen H. and McGoveran D. Relational Database Writings 1994-1997. — Reading, Mass.: Addison-Wesley, 1998.

24.20.Date C.J. Encapsulation Is a Red Herring // DBP&D. — September, 1998. — 12, № 9. В этой главе уже упоминалось о том, что следствием инкапсуляции является неза­висимость данных. Но мы также указывали, что предпочли бы не использовать термин "инкапсуляция", а заменили бы его термином скаляр. С другой стороны, "инкапсулированные объекты" не могут предоставить дополнительную независи­мость по сравнению с той, которую могут предоставить не инкапсулированные от­ношения (по крайней мере, в принципе). Например, нет абсолютно никаких причин для того, чтобы базовое отношение, которое представляет точку в декартовой сис­теме координат X и Y, нельзя было хранить, используя полярные координаты R и 0. 24.21.Date CJ. Persistence Not Orthogonal to Type // DBP&D website wvw.dbpd.com.— October, 1998.

24.22.Date CJ. Decent Exposure // DBP&D website www.dbpd.com. —November, 1998. 24.23.Deux O. et al. The 02 System // CACM. — October, 1991. — 34, № 1. 24.24.Ferrandina F., Meyer Т., Zicari R., Ferran G., Madec J. Schema and Database Evolution

in the 02 Object Database System // Proc. 21st Int. Conf. on Very Large Data Bases. —

Zurich, Switzerland, September, 1995.

См. аннотацию к [24.43]. 24.25.Frohn J., Lausen G., Uphoff H. Access to Object by Path Expressions and Rules // Proc.

20th Int. Conf. on Very Large Data Bases. — Santiago, Chile, September, 1994. 24.26.Goldberg A., Robson D. Smalltalk-80: The Language and its Implementation. —

Reading, Mass.: Addison-Wesley, 1983.

Перечень передовых исследований специалистов из исследовательского цен­тра фирмы Xerox в Пало Альто, посвященных проектированию и созданию системы Smalltalk-80. В первой из четырех частей этой книги подробно опи­сывается язык программирования Smalltalk-80, на котором основаны язык OPAL и система GemStone.

24.27.Goodman N. Object Oriented Database Systems // InfoDB. — 1989. — 4, № 3.

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

24.28.Goodman N. The Object Database Debate, The Object Data Model, The Object Data Model in Action // InfoDB. — 1990-1991.— 5, №4; InfoDB. — 1990-1991.— 6, № 1; InfoDB. — 1991. — 6, №2.

24.29.Goodman N. Object Oriented DBMS War Story: Developing a Genome Mapping Database in С++ (опубликовано в [24.35]).

В статье поддерживаются многие критические замечания, которые были высказа­ны в этой главе. Далее приводится цитата из резюме статьи. "Вопреки распростра­ненному мнению, наш опыт подсказывает, что было бы ошибкой создавать слиш­ком интеллектуальные базы данных с помощью сложных программ в виде методов внутри объектов базы данных. Также наш опыт свидетельствует о том, что язык С++ — это язык, который подходит исключительно для реализации баз данных, с проблемами, связанными с механизмами определения атрибутов, механизмами ус­тановления ссылок на объекты систематическим путем, недостатками при "сборке мусора" и тонкими ловушками в модели наследования. Мы также считаем, что со­временным СУБД, основанным на С++, недостает некоторых важных функций баз данных, и чтобы это компенсировать, нам пришлось предоставлять собственные простые реализации стандартных функций СУБД: ведения журнала транзакций для прямого восстановления, отслеживания многопоточных транзакций, язык запросов и процессор запросов, а также структуры памяти. В результате мы использовали СУБД, основанную на С++, как объектно-ориентированный диспетчер памяти и, кроме того, встроили систему управления данными, предназначенную для широ­комасштабного геномного отображения."

24.30.Jagadish H.V., Xiaolei Q. Integrity Maintenance in an Object-Oriented Database // Proc 18th Int. Conf. on Very Large Data Bases. — Vancouver, Canada, August, 1992. В работе предлагается декларативный метод указания ограничений целостности для объектных систем. При этом описывается, как компилятор ограничений помещает в методы соответствующих объектных классов необходимый код проверки целостности.

24.31.Jordan D. С++ Object Databases: Programming with the ODMG Standard. — Reading, Mass.: Addison-Wesley, 1997. (Имеется русский вариант этой книги: Джордан Д. Обработка объектных баз данных в С++. Программирование с использованием стандарта ODMG.: Пер. с англ. — М.: Издательский дом "Вильяме", 2001.)

24.32.Kifer М., Kim W., Sagiv Y. Querying Object-Oriented Databases // Proc. ACM SIGMOD Int. Conf. on Management of Data. — San Diego, Calif, June, 1992. В работе предлагается еще один "объектный вариант языка SQL" под названи­ем XSQL.

24.33.Kim W. Object-Oriented Database Systems: Promises, Reality, and the Future // Proc.

19th Int. Conf. on Vary Large Data Bases. — Dublin, Areland, August, 1993. 24.34.Kim W. Observations on the ODMG-93 Proposal for an Object-Oriented Database

Language // ACM SIGMOD Record. — March, 1994. — 23, № 1. 24.35.Kim W. Modern Database Systems: The Object Model, Interoperability, and Beyond. —

New York, N.Y.: ACM Press/Reading, Mass.: Addison-Wesley, 1995. 24.36.Kim W., Lochovsky F.H. Object-Oriented Concepts, Databases and Applications. —

Reading, Mass.: Addison-Wesley, 1989. 24.37.Lamb C, Landis G., Orenstein J., Weinreb D. The ObjectStore Database System //

CACM. — October, 1991. — 34, № 10. 24.38.Loomis M.E.S. Object Databases: Essentials. — Reading, Mass.: Addison-Wesley, 1995. 24.39.Lyngbaek P. et al. OSQL: Language for Object Databases. — Technical Report HPL-

DTD-91-4. — Hewlett-Packard Company, January, 1991.

См. комментарий к [24.6].

24.40. Meyer В. The Future of Object Technology // IEEE Computer. — January, 1998. — 31, № 1. "Будущее [объектных] баз данных — это интересная тема для размышлений... Из­готовители реляционных баз данных с 1986 года старались подавить рост [объектных] баз данных с помощью упреждающих извещений... Десять лет спустя эксперты [объектных баз данных] будут говорить вам, что предложения от основ­ных производителей реляционных СУБД... еще далеки от реальных потребностей... Рынок объектных баз данных будет продолжать расти, но часть рынка традицион­ных баз данных останется."

24.41.Parsaye К., Chignell М., Koshafian S., Wong Н. Intelligent Databases.— New York, N.Y.: John Wiley & Sons, 1989.

24.42.Poulovassilis A., Small C. Investigation of Algebraic Query Optimisation for Database Programming Languages // Proc. 20th Int. Conf. on Vary Large Data Bases. — Santiago, Chile, September, 1994.

24.43.Roddick J.F. Schema Evolution in Database Systems— An Annotated Bibliography // ACM SIGMOD. — December, 1992. — Record 21, № 4.

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

В [24.4] обсуждается система ORION, которая служит прототипом объектной систе­мы, и приводится перечень основных возможных изменений макета. Отметим, что некоторые из них (какие?) вводят в заблуждение, не отличая модель от реализации.

■ Изменения объектного класса

1. Изменения переменной экземпляра:

• добавление переменной экземпляра;

• удаление переменной экземпляра;

• переименование переменной экземпляра;

• изменение принятого по умолчанию значения переменной экземпляра;

• изменение типа данных переменной экземпляра;

• изменение источника наследования переменной экземпляра.

2. Изменения метода:

• добавление метода;

• удаление метода;

• переименование метода; • изменение кода метода;

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

■ Изменения в иерархии классов (предполагается множественное наследование):

■ добавление класса А к списку суперклассов класса В; " удаление класса А из списка суперклассов класса В.

■ Изменения общего макета:

• добавление класса (в произвольном месте);

• удаление класса (в произвольном месте);

• переименование класса;

• разбиение класса;

• слияние классов.

Поскольку поддержка представлений обычно не включается в "объектную мо­дель", не совсем ясно, насколько сильным окажется влияние таких изменений на прозрачность системы. Возможность внесения изменений в макет системы пред­ставляет собой достаточно сложную проблему именно из-за того, что в объектных системах осуществляется последовательная обработка записей. Как отмечается в [24.34], если при внесении изменений индексы или данные распределены по раз­ным группам (кластерам), то никаких способов автоматически получить преиму­щества от таких изменений с помощью методов не существует. Более того, постепенное развитие схемы является еще одним требованием объект­ной системы, поскольку многие решения, которые могли бы быть решениями ад­министратора базы данных (или даже решениями СУБД!) в реляционной базе дан­ных, в объектной системе становятся решениями программиста приложения (см. [24.44]). В частности, приведение в соответствие производительности системы может также повлечь перепроектирование макета (опять же, см. [24.44]). 24.44.Saracco СМ. Writing an Object DBMS Application (в двух частях) // InfoDB. — 1993-1994. — 7, № 4; InfoDB. — 1994. — 8, № 1.

Приводятся несложные, но достаточно полные и информативные примеры программ. 24.45.Shaw G.M., Zdonik S.B. A Query Algebra for Object-Oriented Databases // Proc. 6th IEEE Int. Conf. on Data Engineering. — February, 1990. (Опубликована также в виде технического отчета: Technical Report TR CS-89-19, Dept. of Computer Science.— Providence, R.I.: Brown University, March, 1989.)

Эта статья подтверждает мнение автора данной книги о том, что "любая объектная алгебра" является сложной из-за сложной организации самих объектов. В частно­сти, для выполнения операции сравнения иерархических объектов с произвольной сложностью вложенных уровней потребуется очень тщательная организация всего этого процесса. Основная идея статьи заключается в том, что каждый оператор ал­гебры запросов приводит к созданию отношения, каждый кортеж которого содер­жит идентификаторы некоторых объектов базы данных. В случае операции соеди­нения, например, каждый кортеж будет содержать идентификаторы объектов, ко­торые соответствуют друг другу для заданного условия соединения. Эти кортежи не наследуют никаких методов объектов-компонентов. 24.46.Shipman D.W. The Functional Data Model and the Data Language DAPLEX // ACM TODS.— March, 1981.— 6, № 1. (Переиздано; M. Stonebraker (ed.). Readings in Database Systems (2-nd edition). — San Mateo, Calif.: Morgan Kaufrnann, 1994.) Существует несколько попыток создания систем, в основе которых вместо отноше­ний используются функции, и среди них наиболее известной является система DAPLEX. Функциональные подходы обладают некоторыми чертами, характерными для объектных систем, включая, в частности, стиль адресации объектов (с помощью указания пути), которые функционально относятся к другим объектам (которые, в свою очередь, также относятся к другим объектам, и т.д.)- Обратите внимание, одна­ко, что термин "функция" в этих так называемых функциональных моделях не имеет никакого отношения к математической функции. Например, такая функция вполне может быть многозначной. Практически традиционное понятие функции должно претерпеть значительные изменения для того, чтобы удовлетворить всем требовани­ям, которые предъявляются в контексте "функциональной модели данных". 24.47.Stein J., Maier D. Concepts in Object-Oriented Data Management // DBP&D. — April, 1988. — 1, ЛЬ 4.

Прекрасный учебный материал по объектным концепциям, представленный созда­телями системы GemStone.

24.48.Tsichritzis D.C., Nierstrasz О.М. Directions in OO Research (опубликовано в [24.36]). В этой статье также подтверждается высказанная автором настоящей книги мысль об отсутствии единства мнений в области объектных подходов: "...разногласия су­ществуют по самым основным понятиям, например: "Что такое объект?.. ". Однако причин для беспокойства нет, поскольку нестрогие определения неизбежны, а по­рой они даже крайне желательны во время динамичного развития научных иссле­дований. Они должны стать и неизбежно станут строгими спустя некоторое вре­мя". Однако объектные концепции известны уже более 30 лет! — фактически они предшествовали реляционной модели.

24.49.Ullman J.D. A Comparison between Deductive and Object-Oriented Database Systems // Proc. 2nd Int. Conf. on Deductive and Object-Oriented Databases. — Munich, Germany, December, 1991. Delober C, Kifer M., Masunaga Y. (eds). Lecture Notes in Computer Science 566. — New York, N.Y.: Springer Verlag, 1992.

Хотя мы и не согласны по многим отдельным вопросам, представленным в данной ста­тье, мы согласны с общим выводом, что "дедуктивная" (т.е. основанная на логике) сис­тема баз данных имеет большие перспективы по сравнению с объектными системами. В статье также затронут важный вопрос относительно возможностей оптимизации систем. Предположим, что мы определили "какой-то объектный класс, поведение кото­рого такое же, как поведение бинарных отношений, и... метод join (соединение) для этого класса, тогда можно записать, например, выражение R JOIN S JOIN Т. Его мож­но вычислять как (R JOIN S) JOIN Т или как R JOIN (S JOIN Т). Но сможем ли мы это сделать? Никто не определял, что означает метод join. Является ли он, например, ассоциативным?.. Отсюда можно сделать вывод, что если мы желаем программировать, используя объектную технологию, оставаясь на уровне отношений или выше, то необ­ходимо предоставить системе информацию в виде законов реляционной алгебры. Такая информация не может быть выведена системой, но может быть встроена в нее. Таким образом, ...единственной частью языка запросов, которая будет поддаваться оптимиза­ции, является фиксированное множество методов, для которых... соответствующая се­мантика предоставлена системе".

24.50.Vossen G. Data Models, Database Languages, and Database Management Systems. — Reading, Mass.: Addison-Wesley, 1991.

24.51. Zaniolo C. The Database Language GEM // Proc. 1983 ACM SIGMOD Int. Conf. on Management of Data. — San Jose, Calif, May, 1983. (Переиздано: M. Stonebraker. Readings in Database Systems (2-nd edition). — San Mateo, Calif: Morgan Kaufrnann, 1994.)

Аббревиатура GEM (General Entity Manipulator) обозначает расширение языка QUEL, в котором поддерживаются отношения, не находящиеся в первой нормальной форме (т.е. отношения с атрибутами, значениями которых являются множества), и отноше­ния с альтернативными атрибутами (например, одни объекты сотрудников ЕМР имеют атрибут постоянной зарплаты SALARY, а другие объекты сотрудников ЕМР имеют ат­рибут почасовой оплаты HOURLY_WAGE и атрибут сверхурочной оплаты OVERTIME). Кроме того, в нем поддерживается объектная идея о том, что одни объекты концеп­туально содержат другие объекты (они используются вместо внешних ключей, кото­рые ссылаются на другие объекты). Причем привычная запись с использованием точки расширена для ссылок на атрибуты таких объектов (хотя на самом деле при этом неявно просматриваются некоторые предпочтительные пути соединения). На­пример, выражение ЕМР.DEPT.BUDGET может быть использовано для обращения к бюджету отдела, в котором работает определенный сотрудник. Многие другие сис­темы либо адаптированы к восприятию этой идеи, либо построены на ее основе. 24.52.Zdonik S.B., Maier D. Readings in Object-Oriented Database Systems. — San Francisco, Calif.: Morgan Kaufrnann, 1990.

Ответы к некоторым упражнениям

24.1. Здесь мы объясним лишь термин объект. Ниже приведено несколько "определений", которые можно найти в литературе.

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

• "Объектом называется область закрытой памяти с открытым интерфейсом" [24.47].

• "Объектом называется абстрактная конструкция, определяющая протокол, с помощью которого пользователи этого объекта могут с ним общаться" (введение к [24.52]).

• "Объектом называется программная структура, которая содержит данные и про­граммы" [24.27].

" "...все что угодно является объектом... объект имеет закрытую память и откры­тый интерфейс" [24.50]. Отметим, что ни одно из этих "определений" не объясняет суть понятия, а имен­но — что объект является, по существу, просто значением (если он неизменяемый) или переменной (в противном случае).

Также стоит прокомментировать точку зрения, что "все что угодно является объек­том". Вот, например, конструкции, которые не являются объектами в большинстве объектных систем: переменная экземпляра, отношения (по крайней мере в ODMG [24.12]), методы, идентификаторы, программные переменные. А в некоторых системах (опять же, включая ODMG) значения также не являются объектами.

24.2. Ниже перечислены преимущества идентификаторов.

• Идентификаторы не характеризуются "разумностью". В [13.9] объясняется, по­чему такое "качество" идентификаторов полезно.

• Идентификаторы никогда не изменяются до тех пор, пока существуют объекты, которые они идентифицируют.

• Идентификаторы не являются сложными конструкциями. В [8.12], [13.10] и [18.8] объясняется, почему и это свойство идентификаторов полезно.

• Все объекты объектной базы данных идентифицируются одинаковым образом (в отличие от реляционных баз данных).

• При ссылке на объекты не нужно повторять пользовательские ключи, поэтому нет нужды в правилах обновления ON UPDATE.

Некоторые недостатки идентификаторов были кратко перечислены в разде­лах 24.2-24.4, например они не позволяют избежать необходимости в пользова­тельских ключах, следствием их применения является низкоуровневый стиль про­граммирования с "поиском указателей", их можно применять только для "базовых", т.е. не производных, объектов.

Среди возможных способов реализации идентификаторов нужно указать следующие.

• Физические дисковые адреса (это очень высокопроизводительный способ, но он характеризуется слабой независимостью данных).

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

• Искусственные идентификаторы (например, временные метки, номер по порядку; для такого способа требуется также дополнительное отображение на действи­тельные адреса).

24.3. См. [24.17].

24.5. Вместо подробного ответа здесь будет предложено несколько соображений по вопро­сам проектирования объектных баз данных в целом. Иногда можно услышать утвер­ждения, что объектные системы облегчают проектирование (и использование) баз дан­ных, поскольку они предоставляют высокоуровневые конструкции для моделирования и поддерживают эти конструкции в системе. (В реляционных же системах высший уро­вень используется косвенно, а именно: в процессе отображения объектов реального ми­ра в переменные-отношения, атрибуты, внешние ключи и т.д.) В этом утверждении есть доля истины. Однако позвольте прежде задать вопрос "Как выполнен проект объектной базы данных?". Действительно, "объектная модель", как это принято считать, имеет значительно больше степеней свободы (или, другими словами, больше выбора) по сравнению с реляционной моделью. Но автору этой книги неизвестно о существовании хотя бы одного стоящего пособия, которое помогло бы реализовать эти возможности. Например, как определить представление, скажем, множества всех служащих: как мас­сив, как список или как множество и т.д. и т.п. "Для мощной модели данных требуется мощная методология проектирования... и за это ответственна объектная модель дан­ных" (выдержки из [24.27]). Мы могли бы возразить, что характеристику "мощная" не­обходимо заменить характеристикой "сложная".

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

отсутствие значения). Частично проблемы могут возникнуть потому, что невозможно на основании одного только определения данных указать те объекты, которые содержат ссылку на объект X, или хотя бы даже сказать, сколько их существует. Рассмотрим, на­пример, объекты сотрудников и объектный класс ESET. В принципе, может существо­вать любое количество экземпляров класса ESET, и каждое подмножество экземпляров класса ESET может содержать ссылку на некоторого конкретного сотрудника. 24.10.Существует шесть возможных иерархий.

S содержит { Р содержит { J ) ) S содержит ( J содержит ( Р } ) Р содержит ( J содержит ( S ) ) Р содержит ( S содержит { J ) ) J содержит ( S содержит ( Р ) ) J содержит ( Р содержит ( S ) )

Без какой-либо дополнительной информации невозможно дать ответ на вопрос "Какой из вариантов является лучшим?", но можно почти с полной уверенностью сказать, что все они одинаково плохи. 24.11.Существует по . мере двенадцать "очевидных" макетов иерархии контейнеров. Ниже _ только четыре из них.

S содержит ( Р содержит ( J j ) S содержит ( J содержит ( Р j ) S содержит ( сначала Р, затем J ) S содержит ( сначала J, затем Р )

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

Можно также составить проект безо всяких иерархий из объектов SP, PJ и JS.

24.12. Среди основных факторов, оказывающих влияние на производительность, были пе­речислены следующие: кластеризация, кэширование, замена указателей и выполне­ние методов на сервере. Все эти способы обработки данных могут применяться в любой системе для обеспечения разумного уровня независимости от данных, поэто­му они характерны не только для объектных систем. На самом деле, идея использо­вания определения логической базы данных для выбора типа физической кластери­зации (используемой в той или иной объектной системе) может рассматриваться как некий фактор, потенциально подрывающий независимость от данных. Замечание. Следует отметить, что другой очень важный фактор, оказывающий влияние на производительность, а именно — оптимизация, обычно не учитывается в объектных системах.

24.13.По мнению автора, декларативная поддержка, если она возможна, всегда лучше процедурной (по многим причинам, а не только для создания ограничений целост­ности). Короче говоря, декларативная поддержка означает, что система выполняет некоторую работу вместо пользователя. Вот почему в реляционной системе под­держиваются декларативные запросы, декларативные определения представлений, декларативные ограничения целостности и т.д.

Глава

Объектно-реляционные базы данных