Введение в системы БД (542480), страница 258
Текст из файла (страница 258)
978 Часть Л. Обьектные и объектно-реляционные базы данньп ° Подмена. Термин "подмена" (змчхх!!п8) означает процесс замены указателей наподобие идентификаторов объекта, в качестве которых обычно используются логические дисковые адреса, адресами оперативной памяти при считывании объектов в оперативную память (и наоборот, когда объекты записываются обратно в базу данных). Преимушества такого метода очевидны для приложений, в которых обрабатываются достаточно "сложные объекты", и поэтому необходимо часто осуществлять поиск указателей. ° Выполнение методов на сервере.
В качестве примера рассмотрим запрос "Найти все книги, в которых содержится более 20 глав". В традиционной реляционной системе книги могут быть представлены в виде объектов В).ОВ'4, которые, по сути, являются строкой байтов произвольной длины. Прн такой организации системы клиент вынужден извлекать каждую книгу и проверять, не содержит ли она более 20 глав. Однако при наличии должной объектной поддержки на сервере может быть выполнен некоторый специализированный метод "число глав", а затем клиенту булут переданы все требуемые книги!з. Замечание.
Приведенные выше преимушества на самом деле являются аргументом не в пользу объектных систем, а в пользу хранимых процедур (см. главы 8 и 21). Традиционная реляционная система с хранимыми процедурами будет обладать в этом случае таким же быстролействием, как и объектная система с методами. В [24,13! обсуждается тестовая программа ОО! для измерения производительности системы на основе базы данных, содержащей информацию о счетах и материалах. Эта программа выполняет следующие операции.
1. Случайное извлечение 1 000 деталей с применением заданного пользователем метода для каждой детали.. 2. Случайная вставка 1 000 деталей с присоединением каждой к трем другим. 3. Случайное разузлование деталей (до семи уровней) с применением заданного пользователем метода для каждой детали, подсчитывающего соответствующие вхождения в узлы. Согласно данным, опубликованным в [24.13], производительность некоторой (не сказано, какой) объектной системы на два порядка выше производительности некоторой (не сказано, какой) современной реляционной системы, особенно при условии, что кэш уже заполнен данными (так называемый "теплый" доступ).
Однако в той же работе отмечается следующее. ге Замечание относительно объектов В!.ОВ. Хотя такой тип данных не включен в стандарт 5Ь«1 '92, ЯЕ-продукты традиционно предоставляют возмолгности обработки данных типа ВьОВ в качестве основы для работы с "большичи двоичными объектами" (Ьгпагу!агбе оЬЗес!Ь Здесь обьект пои~чается в оби!епринятом смысле, а не в том, который вкладывается в это понятие в обьектных системах. Динные типа ВьОВ представляют собой по существу просто какую-то строку байтоа произвольной длины, для которой в системе предоставляется поддержка с целью организации ее хранения и извлечения; этим вся поддержка и ограничивается. Физически такие данные часто хранятся в специально отведенной для них области, отдельно от основной облисти .хранения данных тех отношений, которые логически содержанг эти динные. Данные типа ВДОВ могут занимать (и часто занимают) огролгные области дискового пространства.
Ы На сачам деле это сверхупрощение: методы, которые поддерживают интенсивный обмен данными, лучше выполняются на сервере; однико другие методы, т.е. те, которые преимущественно отображают данные, может быть, лучше выполнять на компьютере к«иента. 979 Глава 24. Объектные базы данных "Это отличие...
не следует приписывать различию между собственно реляционной и объектными моделями... В основном, зти различия обусловлены [особенностями реализации(." Это утверждение может быть подкреплено тем фактом, что различия в производительности становились заметно меньше при увеличении размера базы данных [когда в кэш нельзя было поместить всю базу данных). Подобная, но более обширная, тестовая программа 007 описана в [24.10).
Является ли объектная СУБД действительно СУБД? Замечание. В данном подразделе излагаются суждения и наблюдения, которые, в основном, взяты из [24.18). В этой работе, помимо всего прочего, утверждается, что различия между объектными и реляционными системами гораздо существеннее, чем это обычно представляется. "Объектные базы данных возникли благодаря желанию отдельных программистов объектных приложений (продиктованному самыми разнылт причинами) хранить созданные ими специализированные объекты в постоянной памяти При этом под такой "постоянной тииятью" могла подразумеваться и база данных, но, что особо следует подчеркнуть, база данных, предназначенная для специальных приложений; она не была разделяелюй и не являлась базой данных общего назначения, предназначенной для приложений, особенности которых во время определения базы данных еще нельзя предвидеть в полном объеме.
Потому многие воэможности, которые профессионалами по базам данных расцениваются как существенные, просто не считались необходимыми в объектном мире, по крайней мере изначально. "' На первых порах создания объектных баз данных не было достаточного понимания необходимости в том, чтобы базы данных предоставляли следующие возможности. 1. Совместный доступ со стороны нескольких приложений. 2. Физическая независимость данных. 3.
Возможность выполнения произвольных запросов. 4. Поддержка представлений и логической независимости данных. 5. Поддержка декларативных ограничений целостности, независимых от приложений. б. Поддержка прав владения данными и гибкий механизм обеспечения их зашиты. 7.
Управление совместным доступом. 8. Каталог общего назначения. 9. Возможность проектирования базы данных независимо от приложений. "Впоследствии, после представления основной идеи хранения объектов в базе данных, эти воэможности были рассмотрены и реализованы как усовершенствования и дополнения к исходной объектной.модели... Один из важных выводов... заключается в том, что объектная СУБД и реляционная СУБД вЂ” системы, которые различны по сути.
На самом деле можно было бы доказать, что обьектная СУБД фактически вовсе не является СУБД по крайней мере в том смысле, в котором это применимо к реляционной СУБД. " 980 Часть к7. Объектные и объектно-реляционные базы данных Для сравнения рассмотрим следующие замечания. ° Реляционные СУБД поступают от изготовителя готовыми к использованию.
Иными словами, как только система установлена, пользователи могут начать строить базы данных, писать приложения, запускать запросы и т.д. ° Объектную же СУБД можно считать лишь некоторого рода набором средств построения СУБД. После исходной установки объектная СУБД не готова к немедленному использованию. Сначала она должна быть подогнана опытными специалистами, которые определят необходимые классы и методы, и т.п.
Для этого предоставляется набор строительных блоков — средства для сопровождения библиотеки классов, компиляторы методов и т.д. Только после завершения такой подгонки систему можно использовать прикладным программистам и пользователям. Иными словами, результат такой подгонки уже будет больше походить на СУБД в привычном смысле этого термина.
"Кроче того, отметим, что резулыпат подгонки такой базы будет специфическим для конкретных приложений. Эта система может подходить, например, для приложений САПР)АСУТП, но быть совершенно непригодной, например, для медицинских приложений. Иначе говоря, она все еще не стала СУБД общего назначения в том смысле, в котором реляционная СУБД является СУБД общего назначения. " В той же статье 124.181 оспаривается так называемая идея устойчивой нечувствительности к типам из 124.21, в соответствии с которой в базу данных можно включать (изменяемые) объекты произвольной сложности.
"Для объектной модели требуется поддержка [большого количества) генераторов типа... Например, таких типов, как структура (ВТЯУСТ), кортеж (ТУРЬЕ), список (ЬТЕТ), массив (АЯЕАУ), набор (ВЕТ), пакет (ВАУ) и т.д... Вместе с идентификаторами объектов наличие таких генераторов типов означает, что любая структура данных, которая может быть создана в программе приложения, может быть также создана как объект в объектной базе данных, и, кроме того, такая структура объектов видна пользователю.
Например, рассмотрим объект (скажем, ЕХ), копюрый является (или обозначает) коллекцией служащих в отделе. Тогда объект ЕХ может быть реализован как связанный список или как массив, и пользователи должнгя будут знать, как именно реализован этот объект, поскачьку соответствующие операторы доступа отличаются. " Такая вседозволенность по отношению к типам данных, сохраняемых в базе данных, — главное отличие объектной модели от реляционной модели, По сути, подходы в двух моделях можно сформулировать так.
° В объектной модели можно сохранять все, что заблагорассудится, т.е. любые структуры данных, которые можно создать с помощью механизмов обычного языка программирования. ° В реляционной модели, по существу, также можно сохранять все что угодно, однако требуется, чтобы то, что сохраняется, было представлено для пользователя в строго реляционной форме. Глава 24. Объектные базы данных 981 "Выражаясь точнее, в реляционной.модели почти совсем ничего не говорится о том, как могут физически храниться данные... И следовательно, реляционная модель пе накчадывает никаких ограничений па структуры данных, которые допустимы на физическом уровне, Единственное требование заключается в таи, что, если какая-либо структура реачьио физически сохранена она дачжна отображаться в отношения па логическом уровне, а значит, быть скрытой от пользователя.
Таким образом, реляционные системы проводят четкую границу между яогическци и физическим представлениями, т.е. моделью данных и их реализацией, а обьектные систеиы этого не делают. И как следствие вопреки обычному здравому смыслу объектные системы могут обеспечить значительно меньшую независимость данных, чем реляционные системы.
Предположим, например, что в некоторой обьектпой базе данных реачизация упоминавшегося объекта ЕХ обозначающего коллекцию служащих в данном отдаче, изиеначась с массива на связанный список. Каковы будут последствия для существующего кода, с помощью которого осуществлялся доступ к объекту ЕХ?" 24.6. Резюме В завершение этой главы перечислим представленные в ией важнейшие понятия и возможности объектной модели, давая им свою субъективную оценку: какие из иих важны, какие "хороши", но ие сушествеины, какие "скверны", а каким безразлично, какая из систем используется — объектная или реляционная. Эти выводы будут служить мостиком для продолжения обсуждения обьектпо-реляционных систем в главе 25. ° Классы объектов. Классы обьектов соответствуют тилак данных и, безусловно, очень важны.
По сушеству, это наиболее фундаментальная концепция из всех. ° Объекты. Сами объекты, "изменяемые" и "неизменяемые", очевидно, составляют основу объектных систем, хотя мы предпочли бы их называть просто переменными и значениями соответственно. т Идентификаторы объектов. Не нужны и даже вредны (на уровне модели), поскольку по сушеству это указатели. См. ~24П91, где этот вопрос рассматривается подробно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
