Лекция 23. Системы баз от данни, основанные на правилах

23.2. Активные базы от данни

Легко видеть, что основа этой идеи съдържалась в езике SQL времени System R. На самом деле, что есть определение тригера или условного воздействия, как не введение в БД правила, в съответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то, что на самом деле тригеры не были напълно реализованы ни в одной из известных систем, даже и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна, накладна и не напълно понятна.

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

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

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

23.3. Дедуктивные базы от данни

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

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

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

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

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