Active Databases

Temporal Triggers in Active Databases for Monitor and Control

Project Description

We are building a rule-processing component that can be incorporated into commercial-off-the-shelf Database Management Systems. The component will add monitor and control capabilities to existing DBMS's. The target applications consist of a continuously changing database that represents the status of a real system (e.g. a battlefield). Using the rule-system the user will be able to specify conditions that need to be monitored in real-time over the changing database, and actions to be taken upon occurrence of these conditions.

Our rule system is used for specifying triggers. Each rule is an independent trigger that monitors a separate condition. This is unlike existing AI/logic-programming systems, where all the rules comprise a program with an input and an output. An additional difference is that in our systems the database is updated by transactions external to the rule-system.

There are two novel aspects of our rule-processing component.

• First is the rule language which, in contrast to existing languages, allows the concise specification of temporal conditions (i.e., conditions on the way the database evolves over time) and temporal actions. This is achieved through the use of temporal logic (actually, our rule-language combines temporal logic with the underlying database query language). So, for example, the user will be able to specify that if the aircraft speed, a database variable, decreases by more than 50% in 3 seconds, then a certain action is to be taken. In contrast, in existing rule-languages the condition is specified on the current database state, rather than the way the state evolves. In our rule language the action part of a rule can also be temporal, e.g., it can invoke a certain program every 10 minutes, for one hour.
• The second novel aspect of our system is the use of incremental processing and parallel processing to meet the real-time performance requirements. Incremental processing means that instead of evaluating from scratch each rule-condition after each database update, the rule-processing component only checks whether or not the UPDATE could have made the condition true. It does so by saving intermediate results of previous evaluations. Performance enhancement is obtained since the size of the database-update and the intermediate results is usually much smaller than the size of the entire database. Performance is further enhanced by performing the incremental processing in parallel.