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

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

24.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 М.Р. 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.

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

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

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

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

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

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

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

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

24.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 Kaufmann, 1994, a также в [24.52].)

24.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].

24.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].

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

24.8. Bjomerstedt A., Hulten C. Version Control in an Object-Oriented ArchitecЩre. (Опубликована в [24.36].)

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

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

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

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

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