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

Cm. комментарий к [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 СМ., Zdonik S.B. А 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 Kaufmann, 1994.) Сушествует несколько попыток создания систем, в основе которых вместо отношений используются функции, и среди них наиболее известной является система DAPLEX. Функциональные подходы обладают некоторыми чертами, характерными для объектных систем, включая, в частности, стиль адресации объектов (с помощью