Общее представление о базе данных (стр. 7 )

Примеры

* обучение языку программирования Лисп в системе "Учитель Лиспа";

* система PROUST – обучение языку Паскаль и др.

В общем случае все системы, основанные на знаниях, можно подразделить на системы, решающие задачи анализа, и на системы, решающие задачи синтеза. Основное отличие задач анализа от задач синтеза заключается в следующем: если в задачах анализа множество решений может быть перечислено и включено в систему, то в задачах синтеза множество решений потенциально строится из решений компонентов или подпроблем. Задача анализа – это интерпретация данных, диагностика; к задачам синтеза относятся проектирование, планирование. Комбинированные задачи: обучение, мониторинг, прогнозирование.

Классификация по связи с реальным временем:

Статические ЭС разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны.

Диагностика неисправностей в автомобиле.

Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.

Микробиологические ЭС, в которых снимаются лабораторные измерения с технологического процесса один раз в 4 – 5 ч (производство лизина, например) и анализируется динамика полученных показателей по отношению к предыдущему измерению.

Динамические ЭС работают в сопряжении с датчиками объектов в режиме реального времени с непрерывной интерпретацией поступаемых данных.

Управление гибкими производственными комплексами, мониторинг в реанимационных палатах и т. д. Пример инструментария для разработки динамических систем – G2[5].

Классификация по типу ЭВМ

На сегодняшний день существуют:

* ЭС для уникальных стратегически важных задач на суперЭВМ (Эльбрус, CRAY, CONVEX и др.);

* ЭС на ЭВМ средней производительности (типа ЕС ЭВМ, mainframe);

* ЭС на символьных процессорах и рабочих станциях (SUN, APOLLO);

* ЭС на мини– и супермини–ЭВМ (VAX, micro–VAX и др.);

* ЭС на персональных компьютерах (IBM PC, MAC II и подобные).

Классификация по степени интеграции с другими программами:

Автономные ЭС работают непосредственно в режиме консультаций с пользователем для специфически "экспертных" задач, для решения которых не требуется привлекать традиционные методы обработки данных (расчеты, моделирование и т. д.).

Гибридные ЭС представляют программный комплекс, агрегирующий стандартные пакеты прикладных программ (например, математическую статистику, линейное программирование или системы управления базами данных) и средства манипулирования знаниями. Это может быть интеллектуальная надстройка над ППП или интегрированная среда для решения сложной задачи с элементами экспертных знаний.

Несмотря на внешнюю привлекательность гибридного подхода, следует отметить, что разработка таких систем являет собой задачу, на порядок более сложную, чем разработка автономной ЭС. Стыковка не просто разных пакетов, а разных методологий (что происходит в гибридных системах) порождает целый комплекс теоретических и практических трудностей.

86. Представление знаний в ЭС. Сетевое представление знаний.

Представление знаний. Первый и основной вопрос, который надо решить при представлении знаний, – это вопрос определения состава знаний, т. е. определение того, "ЧТО ПРЕДСТАВЛЯТЬ" в экспертной системе. Второй вопрос касается того, "КАК ПРЕДСТАВЛЯТЬ" знания. Необходимо отметить, что эти две проблемы не являются независимыми. Действительно, выбранный способ представления может оказаться непригодным в принципе либо неэффективным для выражения некоторых знаний.

По нашему мнению, вопрос "КАК ПРЕДСТАВЛЯТЬ" можно разделить на две в значительной степени независимые задачи: как организовать (структурировать) знания и как представить знания в выбранном формализме.

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

Итак, в круг вопросов, решаемых при представлении знаний, будем включать следующие:

* определение состава представляемых знаний;

* организацию знаний;

* представление знаний, т. е. определение модели представления.

Состав знаний ЭС определяется следующими факторами:

* проблемной средой;

* архитектурой экспертной системы;

* потребностями и целями пользователей;

* языком общения.

В соответствии с общей схемой статической экспертной системы для ее функционирования требуются следующие знания:

* знания о процессе решения задачи (т. е. управляющие знания), используемые интерпретатором (решателем);

* знания о языке общения и способах организации диалога, используемые лингвистическим процессором (диалоговым компонентом);

* знания о способах представления и модификации знаний, используемые компонентом приобретения знаний;

* поддерживающие структурные и управляющие знания, используемые объяснительным компонентом.

Для динамической ЭС, кроме того, необходимы следующие знания:

* знания о методах взаимодействия с внешним окружением;

* знания о модели внешнего мира.

Зависимость состава знаний от требований пользователя проявляется в следующем:

* какие задачи (из общего набора задач) и с какими данными хочет решать пользователь;

* каковы предпочтительные способы и методы решения;

* при каких ограничениях на количество результатов и способы их получения должна быть решена задача;

* каковы требования к языку общения и организации диалога;

* какова степень общности (конкретности) знаний о проблемной области, доступная пользователю;

* каковы цели пользователей.

Состав знаний о языке общения зависит как от языка общения, так и от требуемого уровня понимания.

С учетом архитектуры экспертной системы знания целесообразно делить на интерпретируемые и неинтерпретируемые. К первому типу относятся те знания, которые способен интерпретировать решатель (интерпретатор). Все остальные знания относятся ко второму типу. Решатель не знает их структуры и содержания. Если эти знания используются каким–либо компонентом системы, то он не "осознает" этих знаний. Неинтерпретируемые знания подразделяются на вспомогательные знания, хранящие информацию о лексике и грамматике языка общения, информацию о структуре диалога, и поддерживающие знания. Вспомогательные знания обрабатываются естественно–языковой компонентой, но ход этой обработки решатель не осознает, так как этот этап обработки входных сообщений является вспомогательным для проведения экспертизы. Поддерживающие знания используются при создании системы и при выполнении объяснений. Поддерживающие знания выполняют роль описаний (обоснований) как интерпретируемых знаний, так и действий системы. Поддерживающие знания подразделяются на технологические и семантические. Технологические поддерживающие знания содержат сведения о времени создания описываемых ими знаний, об авторе знаний и т. п. Семантические поддерживающие знания содержат смысловое описание этих знаний. Они содержат информацию о причинах ввода знаний, о назначении знаний, описывают способ использования знаний и получаемый эффект. Поддерживающие знания имеют описательный характер.

Интерпретируемые знания можно разделить на предметные знания, управляющие знания и знания о представлении. Знания о представлении содержат информацию о том, каким образом (в каких структурах) в системе представлены интерпретируемые знания.

Предметные знания содержат данные о предметной области и способах преобразования этих данных при решении поставленных задач. Отметим, что по отношению к предметным знаниям знания о представлении и знания об управлении являются метазнаниями. В предметных знаниях можно выделить описатели и собственно предметные знания. Описатели содержат определенную информацию о предметных знаниях, такую, как коэффициент определенности правил и данных, меры важности и сложности. Собственно предметные знания разбиваются на факты и исполняемые утверждения. Факты определяют возможные значения сущностей и характеристик предметной области. Исполняемые утверждения содержат информацию о том, как можно изменять описание предметной области в ходе решения задач. Говоря другими словами, исполняемые утверждения – это знания, задающие процедуры обработки. Однако мы избегаем использовать термин "процедурные знания", так как хотим подчеркнуть, что эти знания могут быть заданы не только в процедурной, но и в декларативной форме.

Управляющие знания можно разделить на фокусирующие и решающие. Фокусирующие знания описывают, какие знания следует использовать в той или иной ситуации. Обычно фокусирующие знания содержат сведения о наиболее перспективных объектах или правилах, которые целесообразно использовать при проверке соответствующих гипотез. В первом случае внимание фокусируется на элементах рабочей памяти, во втором – на правилах базы знаний. Решающие знания содержат информацию, используемую для выбора способа интерпретации знаний, подходящего к текущей ситуации. Эти знания применяются для выбора стратегий или эвристик, наиболее эффективных для решения данной задачи.

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

1)метазнания в виде стратегических метаправил используются для выбора релевантных правил ;

2)метазнания используются для обоснования целесообразности применения правил из области экспертизы;

3)метаправила используются для обнаружения синтаксических и семантических ошибок в предметных правилах;

4)метаправила позволяют системе адаптироваться к окружению путем перестройки предметных правил и функций;

5)метаправила позволяют явно указать возможности и ограничения системы, т. е. определить, что система знает, а что не знает.

Вопросы организации знаний необходимо рассматривать в любом представлении, и их решение в значительной степени не зависит от выбранного способа (модели) представления.

Выделим следующие аспекты проблемы организации знаний:

* организация знаний по уровням представления и по уровням детальности;

* организация знаний в рабочей памяти;

* организация знаний в базе знаний.

** Сетевая модель

Совокупность взаимосвязанных понятий образует семантическую сеть понятий. Эта сеть состоит из понятий различных категорий: объектов, свойств, операций, событий и т. д.

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

ПО в любой момент времени может быть представлена в виде совокупностей сущностей, понятий и ситуаций, называемой ее состоянием. Каждой ситуации можно поставить в соответствие некоторое утверждение или суждение об ее истинности или ложности.

Основа семантической сети – события, атрибуты, комплексы признаков и процедуры.

События – это суждения, факты, результаты наблюдений, рекомендации. Могут представляться словосочетаниями и числами. Группируются тематически или функционально в разделы. Делятся на характеризуемые и характеризующие (события–признаки, например, «идет дождь» для события «дождливая погода»).

Атрибут – это характеризующее событие, имеющее несколько значений. (Например, «погода» атрибут «времени года»).

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

Процедура – это специфический компонент сети, выполняющий преобразование информации. Она позволяет вычислять значения одних атрибутов на основании других, оперируя как с числами, так и с символами.

Для вывода знания события в сетевой модели делятся на исходные(признаки) и целевые(гипотезы).

87. Представление знаний в ЭС. Фреймовая модель представление знаний.

Фреймовая модель

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

Фреймовая модель основана на принципе фрагментации знаний.

Основа фреймовой модели – слот, который состоит из имени некоторого признака, значений этого признака и связи с другими слотами.

Например, описание ситуации «Студент Иванов получил книгу «100 компонентов Delphi» в библиотеке ТГПУ им. в г. Туле» может быть представлено следующим образом:

ПОЛУЧЕНИЕ:

ОБЕКТ (КНИГА: (Автор, ), (Название, 100 компонентов Delphi));

АГЕНТ (СТУДЕНТ: (Фамилия, Иванов));

МЕСТО: (БИБЛИОТЕКА: (Название, ТГПУ), (Расположение, Тула)).

Здесь ОБЪЕКТ, АГЕНТ и МЕСТО – это роли, которые играют слоты КНИГА, СТУДЕНТ и БИБЛИОТЕКА в рамках фрейма ПОЛУЧЕНИЕ.

Фреймовую модель можно представить в виде таблицы, у которой в отличие от реляционной модели данных есть ряд особенностей:

возможность смешанного заполнения слотов константами и переменными;

возможность наличия пустых слотов;

размещение в слотах указателей на другие фреймы для создания сети;

размещение в слотах имен выполняемых процедур.

88. Представление знаний в ЭС. Продукционная модель знаний. Стратегия управления

Продукционная модель представления знаний является развитием логических моделей в направлении эффективности представления и вывода знания.

Продукция – это выражение, содержащее ядро, интерпретируемое фразой «Если А, то В», имя, сферу применения, условие применимости ядра и постусловие, представляющее собой процедуру, которую следует выполнить после успешной реализации ядра. Все части, кроме ядра, являются необязательными.

Взаимосвязанный набор продукций образует систему. Основная проблема вывода знания в системе продукций является выбор для анализа очередной продукции. Конкурирующие продукции образуют фронт.

Преимущества продукционной модели:

простота и ясность основной единицы – продукции;

независимость продукций и легкость модификации БЗ;

строгость, простота и изученность механизма логического вывода.

Недостатки:

малая степень стуктуризации БЗ;

неясность взаимных отношений продукций;

неуниверсальность.

Наибольшее применение для реализации продукционных моделей получил язык ПРОЛОГ

В общем случае продукционную модель можно представить в следующем виде:

, где:

– описание класса ситуаций;

– условие, при котором продукция активизируется;

– ядро продукции;

– постусловие продукционного правила.

89. Методология разработки ЭС.

В ходе работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть следующих этапов: идентификация, концептуализация, формализация, выполнение, тестирование, опытная эксплуатация.

РИС

На этапе идентификации определяются задачи, которые подлежат решению, выявляются цели разработки, ресурсы, эксперты и категории пользователей.

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

На этапе формализации определяются способы интерпритации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решения, средств представления и манипулирования знаниями.

На этапе выполнения осуществляется наполнение экспертом БЗ системы. Процесс приобретения знаний разделяют на извлечение знаний из эксперта, организацию знаний, обеспечивающую эффективную работу системы, и представление знаний в виде, понятном ЭС.

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

На этапе опытной эксплуатации проверяется пригодность ЭС для конечных пользователей. По результатам этого этопа может потребоваться существенная модификация ЭС.

Процесс создания ЭС не сводится к строгой последовательности перечисленных выше этапов. В ходе разработки приходится неоднократно возвращаться на более ранние этапы и пересматривать принятые там решения.

90. Понятие объектно – ориентированной БД.

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

Вместе с тем, несмотря на существование ряда коммерческих реализаций ООСУБД, доступных в настоящее время на рынке, уровень технологии таких систем существенно уступает уровню развитых реляционных систем. Это касается и модельных характеристик систем (например, языков запросов) и реализационных аспектов (например, оптимизации запросов).

Часто возникает впечатление, что хотя ограничения существующих систем пытаются объяснять некими принципиальными соображениями (например, что развитые возможности конструирования классов, подкрепленные средствами наследования классов позволяют ограничиться запросами только на одном классе объектов), на самом деле эти ограничения являются следствием недостаточно развитой технологии. Кажется, что в условиях отсутствия признанного лидера в области ООСУБД (каким была, например, компания IBM со своим проектом System R в области РСУБД), единственным путем к выработке такой технологии является продолжающаяся (иногда дублирующая) работа исследователей.

В предыдущих работах мы стремились к тому, чтобы показать принципиальную возможность построения ненавигационного языка запросов к ООБД на основе усиления теоретико–множественного смысла понятия класс [7] и предложить общую концепцию языка программирования ООБД, который естественно (без потери импеданса) включает в себя язык запросов [8]. В этих работах не содержались какие–либо детальные технические проработки, изложение велось на идейном уровне.

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

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

91. Языки программировния ООБД.

Две функции языка программирования ООБД

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

Естественно, что язык программирования ООБД сам должен быть объектно–ориентированным. Следовательно, в нем должны содержаться средства определения типов и классов с желательной поддержкой наследования. Но типы и классы, определяемые в прикладной программе, должны естественно сопрягаться с типами и классами ООБД. Поэтому вполне закономерно нагрузить язык программирования ООБД и функцией определения схемы ООБД, т. е. набора типов и классов, которые впоследствии станут внешней средой прикладных программ.

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

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

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

92. Языки запросов ООБД.

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

Существует мнение, что на практике языки запросов к ООБД требуются только в интерактивном режиме, а для приложений достаточна явная навигация в существующих классах объектов [4]. По нашему мнению, эта идея является неправильной. Она следует не из каких–либо теоретически обоснованных соображений, а лишь упрощает реализацию. Такой подход ограничивает программиста приложений и часто заставляет его включать в прикладную программу функции, свойственные языкам запросов. Это не только вызывает избыточное программирование, но и снижает эффективность программы.

Фактически, ограничение возможностей выполнения запросов к ООБД из прикладной программы является шагом назад по отношению к реляционным системам. Конечно, языки запросов реляционных БД не очень естественно сопрягаются с языками программирования. Конечно, программа на языке Си со встроенными операторами SQL выглядит несколько кустарно. Но тем не менее, имеется эффективный способ использования SQL из прикладной программы. На наш взгляд, эту возможность нельзя терять в новом поколении СУБД, особенно, если учитывать потенциальную возможность интеграции языка программирования и языка запросов ООБД без потери импеданса [6].

Оптимизация запросов в системах ООБД

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

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

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

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

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

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

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

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

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

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

Шаг D: Если теперь появились конъюнкты, представляющие собой простые предикаты сравнения на основе переменных состояния и констант, использовать эти конъюнкты для выработки оптимального плана выполнения запроса. Если же такие конъюнкты получить не удалось, единственным способом "отфильтровать" (супер)класс объектов является его последовательный просмотр с полным вычислением (возможно упрощенного) логического выражения для каждого объекта.

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

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