Программирование >>  Хронологические базы данных 

1 ... 319 320 321 [ 322 ] 323 324 325 ... 348


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

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 00 Research (опубликовано в [24.36]). В этой статье также подтверждается высказанная автором настоящей книги мысль об отсутствии единства мнений в области объектных подходов: ...разногласия существуют по самым основным понятиям, например: Что такое объект?.. . Однако причин для беспокойства нет, поскольку нестрогие определения неизбежны, а порой они даже крайне желательны во время динамичного развития научных исследований. Они должны стать и неизбежно станут строгими спустя некоторое время . Однако объектные концепции известны уже более 30 лет! - фактически они предшествовали реляционной модели.

24.49.Ullman J.D. А 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 Kaufmann, 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 Kaufmann, 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, т.е.



1 ... 319 320 321 [ 322 ] 323 324 325 ... 348

© 2006 - 2024 pmbk.ru. Генерация страницы: 0.001
При копировании материалов приветствуются ссылки.
Яндекс.Метрика