Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 43
Текст из файла (страница 43)
Если доступ к объектам внешней БД в языках программирования ООБД носит в основном навигационный характер, то для языков запросов более удобен декларативный стиль. Как известно, декларативные языки запросов менее развиты, чем языки программирования. 15.3. Языки программирования обьектно-ориентированных баз данных К настоящему моменту неизвестен какой-либо язык программирования ООБД, который был бы спроектирован целиком заново, начиная с нуля. Естественным подходом к построению языков программирования ООБД было использование (с необходимыми расширениями) некоторого существующего объектно-ориентированного языка.
Одним из первых созданных для реализации объектно-ориентированного и функционального подходов к программированию является язык Лисп (Сопппоп 1.1зр). Потребность более эффективной реализации заставляет в качестве основы объектно-ориентированного языка использовать известные языки программирования Ваз)с и Си+~-. Потребность в поддержании в объектно-ориентированной СУБД не только языка (или семейства языков) программирования ООБД, но и развитого языка запросов в настоящее время признается практически всеми разработчиками. Система должна поддерживать легко осваиваемый интерфейс, прямо доступный конечному пользователю в интерактивном режиме.
Наиболее распространенный подход к организации интерактивных интерфейсов с объектно-ориентированными системами баз данных основывается на использовании так называемых обходчиков. В этом случае конечный интерфейс обычно является графическим. На экране отображается схема (или подсхема) ООБД, и пользователь осуществляет доступ к объектам в навигационном стиле. Некоторые исследователи считают, что в этом случае разумно игнорировать принцип инкапсуляции объектов и предъявлять пользователю свойства объектов. В большинстве существующих систем ООБД подобный интерфейс существует, но всем понятно, что навигационный язык запросов — это в некотором смысле 215 шаг назад по сравнению с языками запросов даже реляционных систем. Неиавигациониые языки запросов. В настоящее время существует три подхода к разработке таких языков. Первый лодход заключается в расширении языков запросов реляционных систем.
Наиболее распространены языки с синтаксисом, близким к языку Я)(. Это связано, конечно, с общим признанием и чрезвычайно широким распространением этого языка. Второй подход основывается на построении полного логического объектно-ориентированного языка исчисления. Третий подход основывается на применении декларативного и объектно-ориентированного методов программирования. Независимо от применяемого при создании языка запросов подхода перед разработчиками встает одна концептуальная проблема, решение которой не укладывается в традиционный объектноориентированный подход. Исходя из концепции ООБД основой для формулирования запроса должен служить класс, представляющий в ООБД множество однотипных объектов.
Но что может представлять собой результат запроса? Набор основных понятий объектно-ориентированного подхода не содержит подходящего к данному случаю ответа. Обычно из положения выходят, расширяя базовый набор концепций множества объектов и полагая, что результатом запроса является некоторое подмножество объектов — экземпляров класса.
Это довольно ограниченный подход, поскольку автоматически исключается возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения. Проблемы оптимизации запросов. Основной целью оптимизации запроса в системе ООБД является создание оптимального плана его выполнения с использованием доступа к внешней памяти данной БД. Оптимизация запросов хорошо исследована и разработана в контексте реляционных БД. Известны методы синтаксической и семантической оптимизации на уровне непроцедурного представления запроса, алгоритмы выполнения элементарных реляционных операций, методы оценок стоимости планов запросов.
Конечно, объекты могут иметь существенно более сложную структуру, чем кортежи плоских отношений, но не это различие является наиболее важным. Основная сложность оптимизации запросов к ООБД следует из того, что условия выборки формулируются в терминах внешних атрибутов объектов (методов), а для реальной оптимизации (т.е. для выработки оптимального плана) требуются условия, определенные внутренними атрибутами (переменными состояния). Похожая ситуация существует и в реляционных СУБД при оптимизации запроса к БД.
В этом случае условия также формулиру- 216 ются в терминах внешних атрибутов (атрибутов представления), и в целях оптимизации запроса эти условия должны быть преобразованы в условия, определенные атрибутами хранимых отношений, Хорошо известным методом такой предоптимизации является подстановка представлений, что часто (хотя и не всегда в случае использования языка Я;>ь) обеспечивает требуемые преобразования. В системах ООБД ситуация существенно усложняется двумя обстоятельствами. Во-первых, методы предоптимизации обычно программируются на некотором процедурном языке и могут иметь параметры, т.е.
в общем случае тело метода представляет собой не просто арифметическое выражение, как в случае определения атрибутов представления, а параметризованную программу, содержащую ветвления, вызовы функций и методы описания других объектов. Во-вторых, точная реализация метода и даже структура объекта могут быть неизвестны во время компиляции запроса. Одним из подходов к упрощению проблемы оптимизации является открытие видимости некоторых (наиболее важных для этого) внутренних атрибутов объектов.
В этом случае достаточно открыть некоторые внутренние атрибуты только для компилятора запросов, т.е. фактически запретить переопределять эти переменные в подклассах. С точки зрения пользователя открытые атрибуты имеют вид переменных без параметров, возвращающих значение соответствующего типа.
Однако лучше было бы сохранить строгую вложенность объектов (чтобы избавить приложение от критической зависимости от реализации) и обеспечить возможность тщательного проектирования схемы ООБД с учетом потребностей оптимизации запросов. Общий подход к предоптимизации условий выборки для одного класса объектов может быть следующим. 1. Преобразовать логическую формулу условия выборки в коньюнктивную нормальную форму (КНФ). Не будем останавливаться на способе выбора конкретной КНФ, но, естественно, она должна быть хорошей (например, содержащей максимальное число атомарных конъюнктов). 2. Для каждого конъюнкта, включающего в себя методы с известным во время компиляции телом, заменить вызовы методов на их тела с подставленными параметрами.
(Будем предполагать, что параметры не содержат вызовов функций или методов других объектов.) 3. Для каждого конъюнкта произвести все возможные упрощения, т.е. вычислить все, что можно вычислить в статике. 4. Если получены конъюнкты, представляющие собой простые предикаты сравнения на основе переменных состояния и констант, следует использовать их для выработки оптимального пла- 217 на выполнения запроса. Если же такие конъюнкты получить не удалось, единственным способом удаления класса объектов является его последовательный просмотр с полным вычислением логического выражения для каждого объекта. Указанные ограничения не вызывают зависимости прикладной программы от особенностей реализации ООБД.
Это обусловлено тем, что объекты БД могут быть определены семантически. Контрольные вопросы 1. Назовите принципы объектно-ориентированного подхода к созданию баз данных. 2. Какие объектно-ориентированные модели данных вы знаете? 3. Какие языки программирования применяют для разработки объектно-ориентированных баз данных? ГЛА ВА Гб ОБЪБКТНО-ОРИБНТИРОВАННАЯ СУБД САСНБ 16.1. Структура СУБД Сас)зе СУБД СасЛе относится к постреляционным объектно-ориентированным системам. Термин посгяреляииониая СУБД означает принадлежность к системам нового поколения.
Имеется в виду не столько аспект времени (СУБД появилась после своих основных реляционных конкурентов), сколько ряд технологических новшеств, таких как единая архитектура данных и полная поддержка объектно-ориентированных технологий. В соответствии с принципами проектирования объектно-ориентированных баз данных система СасЛе: ° содержит объект — элемент БД, в котором хранятся не только данные, но и методы их обработки; ° позволяет обрабатывать мультимедийные данные и предоставляет пользователям возможность создавать собственные структуры данных любой сложности; ° допускают работу на высоком уровне абстракции. Отличительной особенностью СУБД является независимость хранения данных от способа их представления, что реализуется с помощью так называемой единой архитектуры данных.
В рамках данной архитектуры существует единое описание объектов и таблиц, отображаемых непосредственно в многомерные структуры ядра базы данных, ориентированных на обработку транзакций. Как только определяется класс объектов, автоматически генерируется реляционное описание данных этого класса в формате Я;>1.; как только в Словарь данных поступает язык определения данных (ЯОД)— описание в формате реляционной базы данных, автоматически генерируется реляционное и объектное описание данных, т.е. устанавливается доступ к ним в формате объектов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
