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

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

     Дедуктивные базы данных
      По определению, дедуктивная БД состоит из двух частей: экстенциональной,
содержащей факты, и интенциональной, содержащей правила для логического вывода
новых фактов на основе экстенциональной части и запроса пользователя.
      Легко видеть, что при таком общем определении SQL-ориентированную
реляционную СУБД можно отнести к дедуктивным системам. Действительно, что есть
определенные в схеме реляционной БД представления, как не интенциональная часть БД.
В конце концов не так уж важно, какой конкретный механизм используется для вывода
новых фактов на основе существующих. В случае SQL основным элементом определения
представления является оператор выборки языка SQL, что вполне естественно, поскольку
результатом оператора выборки является порождаемая таблица. Обеспечивается и
необходимая расширяемость, поскольку представления могут определяться не только над
базовыми таблицами, но и над представлениями.
      Основным отличием реальной дедуктивной СУБД от реляционной является то, что и
правила интенсиональной части БД, и запросы пользователей могут содержать рекурсию.
Можно спорить о том, всегда ли хороша рекурсия. Однако возможность определения
рекурсивных правил и запросов дает возможность простого решения в дедуктивных базах
данных проблем, которые вызывают большие проблемы в реляционных системах
(например, проблемы разборки сложной детали на примитивные составляющие). С другой
стороны, именно возможность рекурсии делает реализацию дедуктивной СУБД очень
сложной и во многих случаях неразрешимой эффективно проблемой.
      Мы не будем здесь более подробно рассматривать конкретные проблемы,
применяемые ограничения и используемые методы в дедуктивных системах. Отметим
лишь, что обычно языки запросов и определения интенциональной части БД являются
логическими (поэтому дедуктивные БД часто называют логическими). Имеется прямая
связь дедуктивных БД с базами знаний (интенциональную часть БД можно рассматривать
как БЗ). Более того, трудно провести грань между этими двумя сущностями; по крайней
мере, общего мнения по этому поводу не существует.
      Какова же связь дедуктивных БД с реляционными СУБД, кроме того, что
реляционная БД является вырожденным частным случаем дедуктивной? Основным
является то, что для реализации дедуктивной СУБД обычно применяется реляционная
система. Такая система выступает в роли хранителя фактов и исполнителя запросов,
поступающих с уровня дедуктивной СУБД. Между прочим, такое использование
реляционных СУБД резко актуализирует задачу глобальной оптимизации запросов.
      При обычном применении реляционной СУБД запросы обычно поступают на
обработку по одному, поэтому нет повода для их глобальной (межзапросной)

                                                                                  99