Распределенная обработка данных. Найханова Л.В. - 94 стр.

представляет из себя не просто арифметическое выражение, как в случае определения
атрибутов представления, а параметризованную программу, включающую ветвления,
вызовы функций и методов других объектов. Вторая сложность связана с возможным и
распространенным в ООП поздним связыванием: точная реализация метода и даже
структура объекта может быть неизвестна во время компиляции запроса.
     Одним из подходов к упрощению проблемы является открытие видимости
некоторых (наиболее важных для оптимизации) внутренних атрибутов объектов. В этом
контексте достаточно было бы открыть видимость только для компилятора запросов, т.е.
фактически запретить переопределять такие переменные в подклассах. С точки зрения
пользователя такие атрибуты выглядели бы как методы без параметров, возвращающие
значение соответствующего типа. С нашей точки зрения лучше было бы сохранить
строгую инкапсуляцию объектов (чтобы избавить приложение от критической
зависимости от реализации) и обеспечить возможности тщательного проектирования
схемы ООБД с учетом потребностей оптимизации запросов.
     Общий подход к предоптимизации условия выборки для одного (супер)класса
объектов может быть следующим (мы предполагаем, что условия формулируются с
использованием логики предикатов первого порядка без кванторов; в предикатах могут
использоваться методы соответствующего класса, константы и операции сравнения):
     Шаг А: Преобразовать логическую формулу условия к конъюнктивной нормальной
форме (КНФ). Мы не останавливаемся на способе выбора конкретной КНФ, но
естественно, должна быть выбрана "хорошая" КНФ (например, содержащая максимальное
число атомарных конъюнктов).
     Шаг B: Для каждого конъюнкта, включающего методы с известным во время
компиляции телом, заменить вызовы методов на их тела с подставленными параметрами.
(Для простоты будем предполагать, что параметры не содержат вызовов функций или
методов других объектов.)
     Шаг C: Для каждого такого конъюнкта произвести все возможные упрощения, т.е.
вычислить все, что можно вычислить в статике. Хотя в общем виде эта задача является
очень сложной, при разумном проектировании ООБД в число методов должны будут
войти методы с предельно простой реализацией, задавать условия на которых будет очень
естественно. Такие условия будут упрощаться очень эффективно.
     Шаг D: Если теперь появились конъюнкты, представляющие собой простые
предикаты сравнения на основе переменных состояния и констант, использовать эти
конъюнкты для выработки оптимального плана выполнения запроса. Если же такие
конъюнкты получить не удалось, единственным способом "отфильтровать" (супер)класс
объектов является его последовательный просмотр с полным вычислением (возможно
упрощенного) логического выражения для каждого объекта.
     Понятно, что возможности оптимизации будут зависеть от особенностей языка
программирования, который используется для программирования методов, от
особенностей конкретного языка запросов и от того, насколько продуманно
спроектирована схема ООБД. В частности, желательно, чтобы используемый язык
программирования      стимулировал     максимально      дисциплинированный      стиль
программирования методов объектов. Язык запросов должен разумно ограничивать
возможности пользователей (в частности, в отношении параметров методов, участвующих
в условиях запросов). Наконец, в классах схемы ООБД должны содержаться простые
методы, не переопределяемые в подклассах и основанные на тех переменных состояния,
которые служат основой для организации методов доступа.
     Заметим, что указанные ограничения не влекут зависимости прикладной программы
от особенностей реализации ООБД, поскольку объекты остаются полностью
инкапсулированными. Использование в условиях запросов простых методов должно
стимулироваться не требованиями реализации, а семантикой объектов.


94