4. Оптимизация запросов к ообд

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

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

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

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

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

6. Особенности управления транзакциями в системах ообд

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

Какой-либо подход, в котором предлагался бы полный набор средств управления транзакциями, полностью согласующийся с парадигмой объектной ориентированностью, нам неизвестен. Одна из наиболее продвинутых работ, проводимых в этом направлении в рамках германского проекта VODAK, описывается в [93].

В основе управления транзакциями в системе VODAK находится разработанный ранее в контексте инженерных СУБД механизм транзакций со вложенными подтранзакциями [109]: вызов любого действия в объекте равносилен образованию новой подстранзакции. В отличие от традиционного механизма вложенных подтранзакций в данном случае заранее не определена максимальная вложенность транзакций. При синхронизации транзакций используется знание о семантике объектов, в том числе информация о коммутативности операций. (Аналогичный подход описан в[110].)

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

45