Detecting Composite Events

in Active Database Systems Using Petri Nets

Stella Gatziu, Klaus R. Dittrich

Database Technology Research Group
Institut f?r Informatik, Universit?t Z?rich
Email: {gatziu, dittrich}@ifi.unizh.ch

Abstract

The detection of events in an active database system turns out to be a difficult problem due to the expressive event specification languages proposed in the recent past which include, among others, complexly defined events (composite events). Therefore, a mechanism is required that is suitable to model the semantics of composite events and to implement the event detector. In this extended abstract we demonstrate how Petri nets can be used as the basis of such a mechanism in the context of the SAMOS active database system prototype.

1 Introduction

Active database systems (aDBS) aim at the representation of more real-world semantics in the database by supporting event-condition-action rules (ECA-rules; [3]). ECA- rules can be interpreted as ?when the specified event occurs and the condition holds, execute the action?. An event indicates the point in time when some sort of reaction is required from the DBMS. Thus, in an aDBS various ways are needed to specify those points in time which are really of interest in the context of a set of ECA-rules. All constructs used for the specification of events are combined in an event specification language; their variety determines the expressiveness of this language and is crucial for the support of more sophisticated applications from various areas. Thus, the development of event specification languages is one main research area in active databases. It also includes issues like the detection of events (by a socalled event detector).

Looking at existing work, some proposals have been made for expressive event specification languages ([2, 8, 9]). Most of them provide two kinds of events: those where the event of interest is immediately the specified one (primitive events), and those where the event of interest results from a combination of other events (composite events). Still, many questions concerning the efficient de-

tection of composite events need to be investigated, otherwise an expressive event specification language would be meaningless.

In order to be able to support the detection of composite events, first of all, a detector for primitive events is required. Then, whenever a primitive event is detected, it has to be checked which composite events occur as a consequence. This is the task of the event detector for composite events. A straightforward but very inefficient way to detect composite events proceeds as follows:

? determine to which composite events the primitive event ?contributes?

? for each of the determined composite events, check, whether all other participating events have already occurred (and, if required, in the correct order).

This means that information about all (primitive) events that already occurred in the past needs to be maintained and repeatedly inspected. These steps have to be done each time a primitive event occurs.

A more efficient way is step-by-step (or incremental) detection. In this case, the event detector needs to know for each composite event the ordered sequence of all primitive events that have to occur in order for the composite one to occur. Thus, each time a primitive event occurs, the detector can check if a ?step forward? in any of these ordered sequences can be made. If yes, it ?marks? the attained positions in these sequences. As a consequence, we can talk about the actual state of detection processes which is represented by the marked positions. The event detector can signal the occurrence of a composite event as soon as the last element of the appropriate sequence order gets marked.

The step-by-step detection requires a model which allows the representation of ordered sequences of primitive events in the system. A first attempt using automata has been made in ODE [10] based on the observation that event expressions are equivalent to regular expressions if they are not parameterized. This means that automata are not sufficient in case of event parameters have to be supported. They have to be extended with a data structure that ?remembers? the event parameters of the primitive events

to appear in:
Proc. of the 4th Intl. Workshop on Research
Issues in Data Engineering: Active Database
Systems, Houston, Texas, February 1994.