Языки программирования объектно-ориентированных баз данных

К настоящему моменту неизвестен какой-либо язык програм­мирования ООБД, который был бы спроектирован целиком за­ново, начиная с нуля. Естественным подходом к построению языков программирования ООБД было использование (с необ­ходимыми расширениями) некоторого существующего объект­но-ориентированного языка.

Одним из первых созданных для реализации объектно-ориен­тированного и функционального подходов к программированию является язык Лисп (Common Lisp).

Потребность более эффективной реализации заставляет в ка­честве основы объектно-ориентированного языка использовать известные языки программирования Basic и Си++.

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

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

Ненавигационные языки запросов. В настоящее время существует три подхода к разработке таких языков.

Первый подход заключается в расширении языков запросов ре­ляционных систем. Наиболее распространены языки с синтакси­сом, близким к языку SQL. Это связано, конечно, с общим при­знанием и чрезвычайно широким распространением этого языка.

Второй подход основывается на построении полного логиче­ского объектно-ориентированного языка исчисления.

Третий подход основывается на применении декларативного и объектно-ориентированного методов программирования.

Независимо от применяемого при создании языка запросов под­хода перед разработчиками встает одна концептуальная пробле­ма, решение которой не укладывается в традиционный объектно-ориентированный подход.

Исходя из концепции ООБД основой для формулирования запроса должен служить класс, представляющий в ООБД мно­жество однотипных объектов. Но что может представлять собой результат запроса? Набор основных понятий объектно-ориенти­рованного подхода не содержит подходящего к данному случаю ответа. Обычно из положения выходят, расширяя базовый набор концепций множества объектов и полагая, что результатом зап­роса является некоторое подмножество объектов — экземпляров класса. Это довольно ограниченный подход, поскольку автома­тически исключается возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения.

Проблемы оптимизации запросов. Основной целью оптимиза­ции запроса в системе ООБД является создание оптимального плана его выполнения с использованием доступа к внешней па­мяти данной БД.

Оптимизация запросов хорошо исследована и разработана в контексте реляционных БД. Известны методы синтаксической и семантической оптимизации на уровне непроцедурного представ­ления запроса, алгоритмы выполнения элементарных реляцион­ных операций, методы оценок стоимости планов запросов.

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

Похожая ситуация существует и в реляционных СУБД при оп­тимизации запроса к БД. В этом случае условия также формулиру­ются в терминах внешних атрибутов (атрибутов представления), и в целях оптимизации запроса эти условия должны быть преобра­зованы в условия, определенные атрибутами хранимых отноше­ний. Хорошо известным методом такой предоптимизации являет­ся подстановка представлений, что часто (хотя и не всегда в слу­чае использования языка SQL) обеспечивает требуемые преобра­зования.

В системах ООБД ситуация существенно усложняется двумя об­стоятельствами.

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

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

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

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

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

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

3. Для каждого конъюнкта произвести все возможные упроще­ния, т.е. вычислить все, что можно вычислить в статике.

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

Указанные ограничения не вызывают зависимости приклад­ной программы от особенностей реализации ООБД. Это обуслов­лено тем, что объекты БД могут быть определены семантически.

ГЛАВА 16.ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СУБД CACHE

Дата добавления: 2014-01-07