Интеграция и интероперабельность

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

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

1.2.Постреляционные системы

Здесь мы кратко рассмотрим основные направления исследований и разработок в области так называемых постреляционных систем, т.е. систем, относящихся к следующему поколению (хотя термин next-generation DBMS зарезервирован для некоторого подкласса современных систем). Эти исследования, в основном, производятся в университетах, хотя известны и исследования, производящиеся в лабораториях коммерческих компаний.

Активные бд

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

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

Здесь существуют вопросы, ответы на которые до сих пор не получены.

• Как эффективно определить набор вспомогательных действий, вызываемых прямым действием пользователя?

• Каким образом распознавать циклы в цепочке действие-условие-действие-... и что делать при возникновении таких циклов?

• В рамках какой транзакции выполнять дополнительные условные действия и к бюджету какого пользователя относить возникающие накладные расходы?

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

Вместе с тем, гораздо важнее в практических целях реализовать в реляционных СУБД аппарат триггеров.