Database Systems Research and Development Center
Computer and Information Sciences Department
University of Florida, Gainesville, FL 32611
Mapping Science Division
Huntsville, AL 35894
March 8, 1993
Making a database system active to meet the requirements of a wide range of applications
entails developing an expressive event specification language and its efficient implementation.
Extant systems support only database events and in some cases a few predefined events.
This paper discusses a model independent event specification language (termed Snoop) and
algorithms for detecting events expressed in Snoop. We define an event, distinguish between
events and conditions, classify events into a class hierarchy, identify primitive events, and intro-
duce a small number of event operators for constructing composite (or complex) events. Snoop
supports temporal, explicit, and composite events in addition to the traditional database events.
The novel aspect of our work lies not only in supporting a rich set of events and event expres-
sions, but also in the notion of parameter contexts. Essentially, parameter contexts augment
the semantics of composite events for computing their parameters. For concreteness, we present
parameter computation and event detection algorithms for the relational model. Finally, in the
appendix, we show how a contingency plan that includes time constraints can be supported
without stepping outside of the framework proposed in this paper.
Index Terms: Event specification, Primitive and composite events, Contingency plan, Param-
eter contexts, Event detection algorithm, Active databases
*This work was supported, in part, by the National Science Foundation Research Initiation Grant IRI-9011216
and in part by the Office of Naval Research and the Navy Command, Control and Ocean Surveillance Center RDT&E
Over the last five years research on active databases has been addressing the needs of a variety of
non-traditional applications that are not readily met by traditional database management systems
(DBMSs). These applications -network management, Air Traffic Control, program trading, Com-
puter Integrated Manufacturing (CIM), and engineering design, to name a few -need to, as part of
their application semantics, continually monitor changes to the database state and initiate appro-
priate actions, preferably, without user or application intervention. Timeliness of event detection
and action execution as well as the ability to execute alternate (or contingency) plans if the desired
action cannot be executed within a prescribed time, is equally important for a number of these
applications. For example, in a manufacturing environment, if re-routing of components cannot be
accomplished within a specified time, the assembly line may have to be stopped or slowed down as
a contingency measure.
Consensus seems to be emerging in the database community about utilizing rules for supporting
active functionality. A rule consists primarily of three components: an event, a condition, and an
action. A rule consisting of these components is termed an ECA or event-condition-action rule in the
literature [4, 25, 13]. Once rules are declared, the system continuously monitors occurrences of the
events, evaluates the condition when the event is signaled, and executes the action if the condition
evaluates to true. A significant amount of research has been conducted on how to incorporate rules
into a DBMS. In fact several active systems, including both relational and object-oriented, have
been proposed. However, a closer examination of these systems reveals that the event component
of rules has received little attention and perhaps is the least understood. This is in contrast to
the condition and action components which are better understood as they correspond to queries
(which are side-effect free) and transactions, respectively.
A survey of current active databases reveals that these systems have three main limitations: i)
support a small number of events ii) provide few operators to express composite events, and iii)
do not address parameter computation of complex events. For an active DBMS to meet most of
the requirements of non-traditional applications, it must provide an expressive event specification
language and support efficient detection of events. In other words, support for rule execution needs
to be complemented with an expressive event specification language. A myopic view of supporting
only a small number of events (e.g. database events such as insert, delete and modify) will severely
limit the ability to model complex applications where temporal and external events need to be
combined with database events.
Although it is possible to provide a set of predefined events, this approach will be too restrictive
and difficult to extend. Instead, identifying primitive events and providing a set of useful constructs
for building composite events will provide a richer set of event expressions. This paper proposes
an event specification language that not only supports primitive events of several types but also
operators for constructing complex events needed for a large class of applications. Moreover, we
introduce the notion of parameter contexts which are used to model the semantics of parameter
computation of complex events.
This paper discusses a model independent event specification language (termed Snoop) and
algorithms for detecting events expressed in Snoop. We clearly distinguish between events and
conditions, classify the types of events required, identify primitive events, and introduce event
modifiers as well as a small number of event operators for constructing composite (or complex or
abstract) event expressions. Snoop supports temporal, explicit, and composite events in addition
to the traditional database events. It is shown how a contingency plan that includes time con-
straints can be supported using one of the event operators proposed in this paper. Snoop is also
shown to subsume current efforts on event specification languages. Finally, we introduce the no-
tion of parameter contexts as a mechanism for disambiguating parameters computed for a complex
event. For concreteness, we present parameter computation and event detection algorithms for the
The rest of this paper is structured as follows. Section 2 defines an event in the context of active
databases. In Section 3, we classify events and discuss primitive events. In Section 4, we highlight
the need for event operators and introduce a few operators and discuss their semantics and usage.
Section 5 discusses the expressive power of Snoop, parameter computation for the relational model,
and the parameter contexts. In Section 6, we discuss event detection and present an algorithm for
the detection of a complex event for one of the parameter contexts. Section 7 contains a comparison
of Snoop with related work along with conclusions. In the appendix, we outline the transformation
of a contingency plan into two ECA rules whose execution is equivalent to the original contingency
2 Events and Event Modifiers
Before elaborating on the notion of an event and defining it, we introduce the notion of time that
is appropriate for the rest of the discussion.
2.1 Notion of Time
Although time in real world may be continuous and dense (having unlimited precision), in a digital
computer which is discrete and finite, time is represented discretely and with limited precision.
Hence, for the purposes of this discussion, we assume an equi-distant discrete time domain (termed
the integer time domain, as shown in Figure 1) having "0" as the origin and each time point
represented by a non-negative integer. Under the assumption that time has a fixed origin, an
instant in any absolute time system can be one-to-one mapped onto the time-axis. Thus, the
integer time domain is isomorphic to the (absolute) Gregorian calendar time. Therefore, without
the loss of generality, we use the integer time and the calendar time interchangeably in this paper.
The granularity of the time line, however, is determined by the system/application.
Further, we adopt two indefinite time constants: Now and oo (infinity). Now is a moving time
point that keeps track of the current time. Now can also be deemed as a macro which is expanded
to the current time either at rule specification or rule activation time. In other words, Now is
substituted with a value of the current time. oo is used to represent an indefinite time interval,
such as (Now to oo) or an indefinite time point which is greater than the current time. Below, we
provide some definitions.
2.2 Event Definition
In this paper, we make a distinction between an event expression and an event. Informally, an event
expression is an expression that defines an interval on the time line shown in Figure 1. Typically,
O1ur approach to event specification is applicable to any data model. However, for concreteness, we illustrate the
parameter computation and event detection for the relational model.
0 1 2 3 Now 00
I I I I --- I I I
Figure 1: Time line
most of the operations that are of interest to the application take a finite amount of time for their
execution. For example, a database operation, function, or a transaction can be viewed as an
event expression. An absolute point on the time line (corresponding to an absolute time) can also
be viewed as a degenerate event expression where a point is a special case of an interval. The
interest in event expressions comes from the fact that one needs to choose a point on the time line,
within the closed interval defined by an event expression, to denote the occurrence of that event.
In other words, an event expression needs to be associated with a point that can be declared as an
event corresponding to that event expression. As we shall elaborate in Section 2.4, we introduce
the notion of an event modifier to transform an event expression to one or more events which
correspond to various points of interest on the time line for that event expression.
Event An event is an atomic (happens completely or not at all) occurrence.
We distinguish between logical events (e.g., end-of-insert operation) and physical/internal events
(e.g., the point in code after the last operation but before the return from insert). Both conform
to the above definition; however, logical events correspond to the specification of an event at the
conceptual level and does not specify the physical or internal event to which it will be mapped.
Events at the conceptual level are mapped to the physical/internal events either using a mapping
specification or choosing an implementation that corresponds to mapping depending upon whether
it is done by a compiler or manually. This approach to the formulation of events is consistent
with the conceptual and internal levels of a DBMS and clearly distinguishes implementation from
the specification. We shall use the term event, in the rest of the paper, to refer to events at the
conceptual level where the usage is not ambiguous. Logical events are mapped uniquely to physical
events whereas a physical event may correspond to one or more logical events. Physical events are
the ones actually detected by the system.
In database applications, the interest in events mostly comes from the state changes that are
produced by database operations. In other words, state changes are concomitant with operation
execution and hence event occurrences corresponding to these operations are of interest. State
changes are effected by using parameters associated with the operations. Hence, events are asso-
ciated with operations (i.e., event expressions) of interest and their parameters are viewed as the
parameters of the event corresponding to the operation; these operations take a finite amount of
time. Or a seemingly instant event may be viewed as a long term one if the time granularity is
A logical event is defined to be conceptually atomic (e.g., abort transaction tl, insert tuple tl
into relation R). In contrast, physical events can be viewed as occurrences that are fast compared
to the granularity of the time scale chosen. We associate time of occurrence tcc (a point on the
time line) with every event instance. The time of occurrence associated with a logical event is the
same as the time of occurrence associated with the physical event corresponding to it, which is
detected by the system. Occurrences of an event are expressed using the granularity of the time
scale chosen and hence, are mapped to distinct points on the time line. For example, any event
that actually occurs at some point to which lies between two consecutive points t, and ts,+l will
be considered to have occurred at t,,+l. Most often an event such as 'insert tuple tl into R' has
multiple occurrences at different points (on the time line) at which the insertion executed. Hence
multiple event occurrences of a given event can be grouped into a class whose instances correspond
to actual event occurrences of a particular event. Each event class in the system has a unique event
type which identifies the class.
An event may precede or follow another, or events may be unrelated. For example, the two
events abort transaction T1 and rollback transaction T1 must follow one another and are causally
related causallyy dependent). Whereas the events begin transaction T1 and begin transaction T2
are causally independent and are said to be unrelated. It may not be useful to establish ordering
on unrelated events.
Causally precedes Event el causally precedes event e2 if and only if the existence of event el
will definitely cause the occurrence of event e2 in the future.
The above ordering is transitive, irreflexive, and anti-symmetric.
Simultaneous occurrence Event el occurs simultaneously with event e2 if and only if the time
of occurrence of el is the same as the time of occurrence of e2.
In a uniprocessor environment, we assume that events cannot occur simultaneously in the
absence of explicit and temporal events2. However, in a distributed/multiprocessor environment or
in the presence of explicit events, it is possible to have more than one event occur simultaneously.
This adds to the complexity of event detection and parameter computation. This problem is similar
to the time-stamp synchronization problem in distributed databases.
Detecting the occurrence of an event itself is a problem as there is likely to be some delay
between the time of occurrence and the time of detection.3 Thus, it may be useful to redefine
simultaneous occurrence in terms of a time window (which is application dependent) within which
it is meaningful to consider two events to have occurred simultaneously. The upper bound on
the delay in detecting an event will be an important characteristic of a system that is capable of
detecting simultaneous events. We shall not address simultaneous event occurrences in this paper
as it is beyond the scope of the work presented here.
Definite event An event e is definite if and only if it is guaranteed to occur.
For example, an event that corresponds to a pre-determined point on the time line is a definite
event. If el causally precedes e2 and el occurs, then e2 is a definite event.
In summary, event modifiers are used to transform an event expression to a logical event.
Furthermore, a correspondence is established between a conceptual event and its physical event.
Event modifiers are elaborated further in 2.4. Furthermore, three distinct aspects (in the temporal
order in which they occur) to processing an event can be outlined:
'.. elaborate on temporal and explicit events later in the paper; for the present explicit events are external events
not detected by the DBMS.
3One way to visualize this is to assume that event occurrences are logged using a high priority interrupt so as to
not miss an event; but the log is processed using a different priority to detect event occurrences and invoke associated
1. Event occurrence: When an event occurs, its formal parameters are instantiated (or bound)
with the values of actual parameters,
2. Event detection: When an event is detected, the parameters are collected and recorded by the
event detector, and finally
3. Event signaling: the event is -'.,11.J.1 by sending an interrupt/message to the condition
evaluator indicating that the event has occurred and passing the actual parameters.
2.3 Event/Condition Differences
It is important to distinguish between the semantics of conditions and events. A condition is a
boolean function of data values, such as 'the salary of John is greater than .;IK'. A condition does
not produce any side effects, i.e., change the database state. A condition may be valid over an
interval of time, while an event is atomic by definition. For example, 'the salary remains the same
during the academic year' is a condition. A database state of interest can be defined in terms of a
condition; conversely, being in a state is a condition. Conditions define 'states' and hence are used
in ECA rules as guards on transitions. A guarded transition fires when its event occurs but only
if the guard condition is also true. For example, when one withdraws from an account (event), if
the balance minus the amount being withdrawn (a parameter of the event) is below the minimum
amount required (condition), then indicate the amount that can be withdrawn (action which may
lead to another state).
In Ode  conditions are treated as masks that are associated with event specification. Al-
though conditions are likely to be formed on the parameters that are computed for a particular
event instance (in addition to other shared data), the separation of event and condition specifi-
cations provides both extensibility and a clear understanding of --. (," (an event) from "-- .,1"
(a condition), and lI..-" (action). The system, as part of its optimization, can combine events,
conditions, and actions in the best possible way for implementing that rule. Furthermore, the
granularity at which coupling modes can be specified (see  for details) is restricted when event
and conditions are combined as proposed in . For a discussion of motivations for the separation
of event and condition specification, see ; conditions are allowed to reference the parameters
generated by the associated event specification.
2.4 Event Modifiers
Most of the operations, including database operations such as insert, delete, and as we shall see later
some of the complex event expressions, are meaningful over a time interval. Therefore, they cannot
be treated as instantaneous occurrences unless the event corresponds to some pre-determined point
in that closed interval. Event modifiers provide a mechanism for: i) creating logical events at the
conceptual level that correspond to points of interest in a closed interval and ii) mapping those
points of interest to physical events in the system (i.e., -i:-:-. -I a feasible implementation).
We define two event modifiers begin-of and end-of to transform an arbitrary interval on the time
line into two logical events. These two modifiers make the corresponding events instantaneous and
precisely map the point of the occurrence of an event onto the physical level. For example, the end-
of event for a function F (i.e., end-of- F) can be mapped to the point after the last statement in the
function F before control is returned to the calling function. The begin-of event can be similarly
defined. The above modifiers can be used to map any operation or interval to two well-defined
events. In fact, begin-of and end-of correspond to pre (or before) and post(or after), respectively,
events provided by systems such as Interbase , Rdb/VMS and OSAM* . However, the
semantics of an event modifier, in our approach, is user defined including the mapping to a physical
event. The implementation can be changed (i.e., the mapping) without affecting the logical event or
the rule specification thereby providing encapsulation. Additional event modifiers can be defined
and mapped to physical events. Currently, in Snoop only two event modifiers are pre-defined.
Whenever an attempt is made to execute an operation, a corresponding begin-of event occurs. On
successful execution of the operation, the corresponding end-of event occurs.
As part of the mapping of event modifiers, the parameters computed also need to be specified.
Parameters computed for any event in Snoop consists of: parameters of the event class, parameters
of the event-expression, and parameters associated with the event modifier. Event-type and time-
stamp are parameters associated with the event class, event-exp-id is a parameter associated with
the event expressions (transaction-id when the event expression is a transaction or block-id when the
operation is a labeled block of code), and the parameters of the operation (or event expression) itself.
Typically, parameters of an begin-ofevent include the input parameters whereas the parameters of
an end-of event include both the input and output parameters of that operation. block-id is the
parameter that identifies the type of operation such as insert, delete or the name of the procedure.
begin-of end-of .
Figure 2: Event modifiers
As a generalization, event modifiers can be applied uniformly to any expression in Snoop as
some of the composite event expressions define an interval. The default event specification (in the
absence of an explicit modifier) is assumed to be end-of. That is, an event expression corresponds
to the event end-of-event_expression. For example, an insert without a modifier is the same as
end-of-insert. For event expressions that correspond to degenerate form of an interval (e.g., a
point on the time line), both begin-of and end-of have identical semantics. Figure 2 shows the two
pre-defined event modifiers in Snoop.
3 Event Classification
On the basis of structure and behavior, events can be organized into a hierarchy of event classes.
Each event class has a unique event type and instances of a class are identified by their class type
and time of occurrence. The term event is used to refer to both an event instance and an event
class. However, the intent is usually clear from the context. We associate a number of attributes
with each event class. These attributes are instantiated at run time when the event actually occurs.
These attributes are also inherited by the subclasses in the event hierarchy. Event-type and time of
occurrence (toe) are attributes of all events. For example, in a relational database, end-of-insert
is an event class and each insert operation is an event instance of this class, which may have
parameters such as the relation name and the tuples inserted in addition to other class parameters.
Events can be broadly classified into: i) primitive events -events that are pre-defined in the
system (using primitive event expressions and event modifiers); for each of them a mechanism for
its efficient detection is likely to be embedded in the system and ii) composite or complex events
-events that are formed by applying a set of operators to primitive and composite events. This
classification is shown in Figure 3.
Primitive Events Composite Events
Database Events Explicit Events Temporal Events
Transaction/ Access Insert Delete Update
Figure 3: Event Classification
Primitive events are further classified into database events, temporal events, and explicit events.
Database events are related to database operations such as transaction, and in the relational model,
retrieve, insert, update and delete. Temporal events are related to time and are of two types:
absolute and relative. Absolute events map to discrete points along the time line (e.g., at 5 p.m.)
whereas relative events are defined with respect to an explicit reference point (e.g., 5 seconds after
an event e occurs, where e is either a primitive or a composite event). Explicit events are those
events that are detected and signaled along with their parameters by application programs and
are only managed by the system. Prior to their usage, explicit events and their formal parameters
need to be registered with the system. Each event (primitive or otherwise) has a well-defined set
of parameters that are instantiated for each occurrence of that event.
3.1 Database events
Database events correspond to the operations (transformed into events using the modifiers) used for
manipulating data. For the relational model, they correspond to the begin-of and end-of variations
of insert, delete, modify, retrieve, and transaction operations.
Although most of the examples in this paper are drawn from the relational model, the generality
of the approach must be clear by now. At least two events (begin-of and end-of) can be associated
with any arbitrary function (or any expression in Snoop) and the parameters for the begin-of and
end-of events correspond to what is visible/bound at the points where the logical events are mapped
to corresponding physical events. It should be obvious that using the approach presented in this
paper, any arbitrary labeled block can be transformed into at least two events. This generalization
of events to arbitrary functions can handle any function that is recognized by the system. This is
especially useful for the object-oriented model where the number of data manipulation operations
are not fixed as is the case in the relational model.
3.2 Temporal Events
A temporal event is an instance of the temporal event class. A temporal event is defined by
specifying a point on the time line. Essentially, there are two ways of specifying a point on the
time line: using an absolute value and using an offset from a well-defined point on the time line.
We use a string having the format (hh:mm:ss)mm/dd/yy to define a point on the time line. The
same format is used for representing both absolute and relative temporal events.
To accommodate the above two ways of specifying time, the temporal event class is specialized
into: absolute and relative event subclasses.
Absolute event: An absolute temporal event is specified with an absolute value of time and
is represented as: < timestring >. For example, 2 p.m. on March 15th, 1994 is specified as
< (14 : 00 : 00)03/15/1994 >. We use an intuitive notation for examples to improve readability.
Absolute temporal events are useful in many situations. For example, in a university database
students are required to pay the fees by a deadline and if they fail to do so, they are charged with
a late fee. In such a database, the ECA rule that reports or adds a late fee needs to be defined
using an absolute event as part of the ECA rule specification. The condition part may even check
for some exceptions. In the action part, the rule will charge a late fee to the account of those
students who missed the deadline and perhaps generate a notification statement to that effect. In
the specification of an absolute temporal event, a field in the time string may contain a wild card
notation, which is denoted by '*' and matches any valid value for that field. This is especially
useful in the specification of events that match many time points on the time line. For example, in
a banking application, to print the local branch report at 5 p.m. each day, one can specify an event
using the wild card notation as follows: < (17 : 00 : 00) / /* >4. In addition, a wild card can
be used as a method for increasing the granularity of the time line by pre-specified amounts (e.g.,
seconds, minutes, days). An empty field is not allowed in the time string representing an absolute
event in order to avoid ambiguities.
The notion of current time is specified by the indefinite variable Now. Absolute events that
have the value less than Now are not meaningful. Absolute events whose values are greater than
Now at the specification or activation time are considered meaningful.
Relative event: A relative event also corresponds to a unique point on the time line but in this
case both the reference point and the offset are explicitly specified. The reference point may be
any event that can be specified in Snoop including an absolute temporal event. The syntax for
a relative event is event + [timestring]. In the representation of an offset, an empty field in the
time string is substituted with the minimum value for that field. For example, consider an airline
4As we show later, the use of wild card notation provides special types of periodic events.
reservation system in which an offset of 24 hours from the time of booking a ticket needs to be
enforced. This can be specified as an ECA rule using the relative temporal event.
Although the representations of absolute time and offset have the same format, they have slightly
different interpretations. For example, the start of the year 1994 may be specified as an absolute
value < (00 : 00 : 00)01/01/1994 >. The same when specified as a relative time has the offset
[(00 : 00 : 00)00/00/1993], because in a < timestring >, (yy/mm/dd) fields denote the current
year, month and day in progress and (hh:mm:ss) shows the amount of time that has elapsed on
that particular day. The syntax for a relative event is purposely made different (one using square
brackets and the other angle brackets) to highlight this difference.
Observe that a relative event subsumes an absolute event; hence a relative event is a primitive
event. However, the absolute version is retained for practical reasons. Note also that an absolute
event is a definite event. A relative event E + [t] is a definite event provided E is definite.
3.3 Explicit/External events
Explicit (also called external or abstract) events are events which are not part of the Snoop language,
but are defined by users or application programs and registered with the system. The parameters
are also explicitly specified and supplied at the time an external event is signaled to the DBMS. For
consistency, we stipulate that parameters of explicit events must include event-type and the time
of occurrence. Explicit events are assumed to be detected outside of the system but are signaled to
the system along with their parameters. Thus these events are accepted and processed (but are not
detected) by the system. For example, atm-has-nomoney(atm-ID, time, location, replenish-amount)
can be viewed as an external event which will be signaled to the system. In fact, this mechanism
can also be used to signal any non-explicit event without that event actually occurring. In other
words, when executing an application, it may be necessary to signal a non-explicit event explicitly.
The only difference between the detection of an event and the signaling of an event explicitly is
that in the former case parameters are computed by the system whereas in the latter case they are
supplied. We use this mechanism for implementing contingency plans which are discussed in the
appendix. This mechanism can also be used for simulating hypothetical or -- l.i-if" scenarios in
planning, which is heavily event driven.
4 Event Operators
Various categories of primitive events discussed so far are useful for modeling a number of applica-
tions requiring active functionality. However, it is not possible to specify combinations of primitive
events needed to model a number of other applications. Most of the active databases support only
database events and very little attention has been paid to modeling events for complex applica-
tions. For example, it is not possible to model any of the following using a single ECA rule with
the primitive events defined so far:
1. Sample IBM stock every 30 minutes from 8 a.m. to 5 p.m. each working day and compute
the maximum value over a day,
2. When 4 withdrawals are made on an account in a day, flag it and do not allow any more
3. When the DowJones average changes by 211'. in any 2 hour interval, execute your portfolio
model to determine what to buy,
4. Check a referential integrity constraint either when an object is inserted or deleted,
5. Compute the new DowJones average when any two of IBM, DEC, or Boeing stock prices
change during the day
6. A withdrawal following a deposit is permitted for a fixed amount irrespective of the account
Some of the above (for instance the last two) can be modeled by multiple ECA rules or chaining
rules and specifying control information (and using explicit events, if need be) as part of the rule.
The last example can be expressed as:
R1: ON deposit
ACTION set deposit:= true;
R2: ON withdraw
CONDITION deposit == true
ACTION set deposit:= false;
Specifying control information as part of a rule can be avoided to a large part by providing a
language for constructing event expressions to suit the application requirements. This will not only
help the rule designer to concentrate on the semantics of his/her application, but also enables the
system to optimize event expressions and detect them efficiently.
We define a composite event as an event obtained by the application of an event modifier to
a complex event expression. By default, the end-of event modifier is assumed to be applied. We
define a composite event expression, recursively, as an event expression formed by using a set of
primitive events, event operators, and composite events constructed so far. Figure 4 shows the event
operators supported in Snoop. Below, we describe each of these operators and their semantics.
We use the above examples to illustrate the applicability and expressiveness of the event operators
introduced in this paper. In Section 5.1, we discuss parameter computation for Snoop expressions
in the relational context using relational algebraic operators.
In the following an arbitrary Snoop event expression can be substituted wherever an event is
used. The semantics of the event operators is well defined when the operands are event expressions
in Snoop. Furthermore, event modifiers are assumed to be applied to any event expression, that
has an interval, to transform it to an event, end-of is assumed to be the default event modifier. We
will use E (upper case alphabets) to represent an event expression as well as an event and e (lower
case alphabets) to represent an instance of the event E.
'In fact, in production rule systems (e.g., OPS5 [10, 11]), programs are written by incorporating a lot of control
information as part of rules which have a form similar to an ECA rule. Specifically, in an OPS5 rule, events are not
explicitly specified but are inferred for the worst case scenario.
Disjunction of two events El and E2, denoted El V E2 occurs when El occurs or E2 occurs. This
operator is useful when the occurrence of one or more (i.e. exclusive-Or under the assumption that
simultaneous events cannot occur; otherwise it is an inclusive-Or) events out of a set of events may
cause a rule to fire. For example, a constraint that needs to be checked either for an insertion or
for the deletion of a tuple can be specified using this operator. A composite event end-of-insert
V end-of-delete specifies the required semantics. Although an event modifier can be used on this
expression as a whole, both expressions have identical semantics.
Or Any Sequence Aperiodic Periodic
A A* P P*
Figure 4: Event Operators
In this paper, we have assumed that no two events can occur simultaneously. However this
assumption is not realistic in a multiprocessor (or a distributed) environment. Moreover, explicit
events can occur simultaneously with non-explicit events. In case of concurrent occurrences, it is
necessary to gather the parameters of all the events and then signal the composite event only once.
How long the system should wait for detecting and computing the parameters of a disjunction is
not clear. It may be meaningful to include a time window for dealing with simultaneous event
occurrences. However, this discussion is beyond the scope of this paper.
Sequence of two events El and E2 is a composite event, which is denoted E1;E2, and occurs
when E2 occurs provided El has already occurred. This implies that the time of occurrence of
El is guaranteed to be less than the time of occurrence of E2. This constructor is useful when
a predefined order has to be imposed over the occurrences of events. For example, in a banking
application, special consideration might be given for the sequence of events deposit; withdraw.
This will distinguish a periodic withdrawal from the one that relates to a specific deposit followed by
a withdrawal. As another example, the checking of an integrity constraint can be postponed until
the end of the transaction by using the event ((end-of-insert V end-of-delete) ; end-of-transaction).
Again, El and E2 can be Snoop event expressions. The event modifiers can be used to signal the
start or the end of this event expression.
It is possible that after the occurrence of El, E2 does not occur at all. To avoid this situation,
it is desirable that every expression having ';' include definite events (defined earlier) such as end-
of-transaction or an absolute temporal event. The event, end-of-transaction6, is a natural choice
for a definite event (as it always occurs when there is no starvation and irrespective of whether a
transaction aborts or commits) in database applications.
Conjunction (Any, All)
The conjunction event, denoted Any(I,El, E2, ... En) where I <= n, occurs when any I events
out of the n events (corresponding to n distinct events specified) occur, ignoring the order of their
occurrence. Conjunction of events is useful in situations where firing of a rule depends upon the
occurrence of a number of events and not necessarily their order. It is possible to simulate the
'Any' operator with a combination of ';' and 'Or'. For example; Any(2,El, E2) can be written
equivalently as ((El; E2) V (E2; El)). However this rewriting results in long event expressions
that may be difficult to comprehend. All is a shorthand for Any(n, El, ..., En) or Any(m, El, ...,
En), where m > n. Again, it is desirable that this event be used along with a definite event (as in
Any(2, El, E2) V end-of-transaction). Note that multiple occurrences of the same event does not
count in the above (except for the parameter computation).
A closure operator was introduced in HiPAC [8, 4] denoted E* where E is an event. Closure, as
introduced in HiPAC, essentially specifies zero or more occurrences of the same event. As there is
no terminating event, a definite event is recommended to be used with the closure operator. The
closure operator of HiPAC can be expressed as Any(oo, E*). However, a more useful construct
which does not require a definite event, can be expressed, in Snoop, as Any(n, E*) where an upper
bound for I is specified as a pre-determined constant. Of course, E in the above connotes distinct
occurrences of the same event E as opposed to the event types in the previous case. Using this
variation, 4 occurrences of a withdrawal event can be expressed as Any(4, end-of-withdrawal*).
This variation of Any can also be used to specify interesting events, such as Any(2, El, (Any(2,
E2*), Any(2, E3*))). This expression is equivalent to (El;Any(2, E2*)) V (El;Any(2, E3*)) V
(Any(2, E2*);Any(2, E3*)). Later, we illustrate how this variation of Any can be used along with
the Aperiodic operator.
Aperiodic Event Operators (A, A*)
The Aperiodic operator A allows one to express the occurrence of an periodic event bounded by
two arbitrary events (for providing an interval). There are two variations of this event specification.
The non-cumulative variation of an periodic event is expressed as A(E1, E2, E3), where El, E2
and E3 are arbitrary events allowed in Snoop. The event A is signaled each time E2 occurs during
the closed interval defined by the occurrences of El and E3. A can occur zero or more times (zero
times either when E2 does not occur in the interval or when no interval exists for the definitions
of El and E3). This operator is useful when a rule has to be associated for each occurrence of
E2 within a prescribed interval expressed by events. For example, the event corresponding to
example 5 above can be expressed as A(8 a.m., Any(2, modify-IBM, modify-DEC, modify-Boeing)
5 p.m.) and the DowJones average is recomputed for each occurrence of A which corresponds to
the occurrence of any two of the three stock price changes.
6The advantage of the event modifier approach proposed in this paper should be clear by now. One can define an
event modifier, say before-commit or ift, r-abort that is meaningful for database applications without stepping outside
of the framework presented in this paper.
There are situations when a given event is signaled more than once during a given interval
(e.g. within a transaction), but rather than firing the rule every time the event occurs, the rule
has to be fired only once. To meet this requirement, we provide an operator A*(E1, E2, E3) that
occurs only once when E3 occurs and accumulates the parameters for each occurrence of E2. This
constructor is especially useful for integrity checking because the constraints need to be checked
only at the end of the transaction. This is also useful to collect the parameters of an event over
an interval to compute .--'.--*.il. values. As an example, highest or lowest stock price can be
computed over an interval using this operator. The event can accumulate stock price changes over
the specified interval and the condition or the action can use .-:-:. -.il. operators in the language
over the parameters computed to obtain the highest or the lowest value. The connotes zero or
more occurrences of the periodic event of interest (E2 in the above). This also implies that as long
as E3 is a definite event A* is a definite event. A occurs if E2 occurs at least once in the specified
interval and A* occurs if El occurs and E3 is definite.
One can also formulate the E* operator of HiPAC when used with definite events by using A*
as follows: A*(definite-eventl, E2, definite-event2) which occurs only when definite-event2 occurs
(provided definite-event1 has occurred) and expresses zero or more occurrences of E2.
Periodic Event Operator (P, P*)
We define a periodic event as an event E that repeats itself within a constant and finite amount
of time. Only a time specification is meaningful for E. From this definition, it is obvious that a
periodic event can be represented by a triplet, consisting of an event El, the time period t after
which a temporal event takes place and a terminating event E3 that marks the end of the periodic
event. Events El and E3 may each be any event in Snoop including absolute temporal event. The
interval t is specified as a time string. Note that t corresponds to an offset.
The notation used for expressing a periodic event is P(E1, [t], E3) where El and E3 are events
and t is the time specification. It is important to note that t is a constant and cannot be replaced
by a wild card specification in all fields because this will result in continuous (i.e., for each point on
the time line) occurrences of P (i.e., for each point on the time line). Terminating event E3 marks
the end of the time interval, that begins at the occurrence of El, over which occurrences of periodic
event is detected. For example, report generation at the end of each quarter is a periodic event
which can be specified as -P((00:00:00)01/01/1992, [(00:00:00)03/00/00], (*:*:*)01/01/1993).
Note that the event of interest in P is the middle event which is always a time specification
and hence does not include any state change operation. To make the event more practical and
meaningful for real-life applications, it may be useful to allow a parameter specification along with
the periodicity specification. With this in mind, we define a cumulative variation of P (denoted
P*) which includes a parameter for each occurrence of the periodic event. For example, in order
to sample IBM stock price every 30 minutes, the value of the stock price needs to be included as a
parameter as shown in P*(8 a.m., [30 min]:IBM-stock-price, 5 p.m.) or as P(8 a.m., [30 min]:IBM-
stock-price, 5 p.m.). This variation is analogous to A* when the periodic event of A* is an offset
and a parameter is associated. As a matter of fact, this variation is meaningful for P as well.
For both periodic and periodic specification, a time interval is marked by the occurrences
of two distinct events El and E3 which can either be primitive or composite. Furthermore, the
semantics of using event modifiers on A (or P) is equivalent to that of the semantics of using them
on E2 (t with or without a parameter). For A* (or P*), the semantics is equivalent to that of the
semantics of using them on E3. To form meaningful events, time of occurrence of El must always
be less than the time of occurrence of E3. However, it is possible to have multiple occurrences of
El before E3 (or E2) occurs. We shall discuss this further in the section on expressiveness as it has
a bearing on parameter computation.
Using the operators introduced so far, we illustrate how the event component of the following
examples can be modeled in Snoop. We use a simplified syntax to make the rules readable.
1. Sample IBM stock every 30 minutes from 8 a.m. to 5 p.m. each working day and compute
the maximum value over a day
P*(8 a.m., [30 mins]: IBM-stock-price, 5 p.m.)
compute maximum using the parameters collected
2. When 4 withdrawals are made on an account in a day, do not allow further withdrawals
A(8 a.m., Any(4, withdraw-on-an-account*), 5 p.m.)
block further withdrawals
3. When the DowJones changes by 211' in any 2 hour interval, execute your portfolio model to
determine what to buy
A*(DowJones-changes, DowJones-changes, DowJones-changes + 2hrs)
if the change is more than 20%
execute your portfolio model
CONTINUOUS /* explained in the next section */
In the above, all the changes to the DowJones value in any two hour interval will be included
as part of the parameter. The above rule can also be expressed as:
On (DowJones-changes; P(DowJones-changes + [e], [2hrs.]: DowJones-value,
DowJones-changes + 2hrs))
if the change is more than 20%
execute your portfolio model
CONTINUOUS /* explained in the next section */
In the above, c corresponds to the least time granularity of the application to make sure the
semantics of the sequence operator is obeyed.
4. Check a referential integrity constraint either when an object is inserted or when an object
On A*(begin-of-transaction, (end-of-insert V end-of-delete),
Action abort the transaction
5. Compute the new DowJones average when any two of IBM, DEC, or Boeing stock prices
change during the day
On Any(2, modify-IBM, modify-DEC, modify-Boeing)
Action compute DowJones average
6. A withdrawal following a deposit is permitted for a fixed amount irrespective of the account
On (deposit ; withdraw)
Action allow one withdraw not exceeding the deposit amount
5 Expressiveness of Snoop
To provide an unambiguous way of composing event expressions in Snoop, we have given a default
precedence for event operators. Operator precedence is used by the detection algorithm for building
the event graph discussed later. The grammar for Snoop is shown below:
E ::= begin-of El end-of El El
El ::= El V E2 E2
E2 ::= E2 ;E3 E3
E3 ::= Any(Value, E4) E5 Any(Value, E5*)
E4 ::= E4, E5 | E5
E5 ::= A(E1,E1,E1)
A*(E1, E, El)
P*(E1, [tinmestring] : parameter, El)
< timestring >
(El) + [timestring]
L:(E1) /* Where L is a label */
Value ::= integer oo
Event expressions generated by the above BNF are left associative. An event expression can
either be primitive or composite. A label associated with an event expression identifies that prim-
itive or composite event. Rule-id is considered to be the label for the entire event expression of an
ECA rule. Labels are used for expressing interest in a sub-expression and their presence determines
the parameter attributes computed for that expression. A label acts as an identification for the
subexpression in a complex event expression. A label is also interpreted as the event type for the
sub-expression with which it is associated; for each such event a 'time of occurrence' attribute is
generated as a parameter. Without label association it would not be possible to distinguish the
occurrence of an event corresponding to a sub-expression and to access, if need be, the time of its
occurrence from the parameter object.
A generalized version of the closure operator introduced in HiPAC is included in Snoop in
addition to periodic and periodic operators. Only the periodic cumulative (A*) operator can
be expressed using a regular expression using the closure and sequence operators. The periodic
and periodic operators A and P essentially provide a mechanism for supporting a set of event
occurrences taken either individually or collectively. The notion of parameter contexts (described
in Section 5.2) make the interpretation of composite events precise.
Although we have proposed a number of event operators, not all of them are primitive. As
noted earlier, the absolute time event and Any are not primitive and have been added to make the
rule specification simpler. Although, it seems that P can be obtained by stipulating that E2 in A
is always a time specification, the periodicity aspect of P does not apply to A. All other operators
are primitive and together are more expressive than a language defined by a regular expression.
5.1 Parameter Computation
The event specification language presented so far is application and model independent. However,
for concreteness, we use the relational model to show the computation of parameters. By stipulating
that the parameters computed for any valid expression in Snoop be in the form of a relation, all
relational algebraic operators become applicable on the parameter relation. The parameter relation
can then be used in both the condition and action components of the rule as if it were a relation
available as part of the database. We assume that for a given rule whose name is rule_id, Pruleid
represents the parameter relation computed for the event of that rule. Below, we describe how
the schema for an event is computed using the rule specification. Of course, the extension of the
relation Pruleid is computed at run time.
The attributes associated with a primitive event form the attributes of its parameter relation
Prule-id. Parameter relation of each primitive event has at least two attributes: event-type and
time of occurrence. An Event type is a value that uniquely identifies an event class. For example
it may be the name of the event class. The time of occurrence of an event is a value along the
time line. Other attributes are event specific. For example, a begin-of-insert database event may
have the relation name and the attributes of the relation as additional attributes of the parameter
relation. When the event occurs, its parameters relation extension is computed and stored in the
parameter relation and is passed to the condition evaluator.
Parameters of an absolute temporal event are event-type and time of occurrence. Parameters
of a relative event E = El + [time] consist of event-type and the time of occurrence. Parameters
of El which act as an explicit reference point are not included as a parameter of E as E is treated
strictly as a temporal event7.
The schema of the parameter relation for each event operator is as follows. For disjunction,
There are situations in which parameters of El are relevant and need to be included in the parameter relations
of E. For such cases, the 'sequence' operator needs to be used as in: E = El; (El + [time]).
conjunction, and sequence, the schema is formed by taking the outerunion of the attributes of the
participating events. The event type is composite for all non-primitive and non-explicit event types.
Parameters of the periodic event A(E1, E2, E3) are nothing but the parameters of the event
expression E2 and the event type. Parameter relation of A is passed to the condition evaluator
each time E2 occurs within the closed interval defined by the occurrences of events El and E3. For
event A*(E1, E2, E3) the parameters of E2 are accumulated in parameter relation and passed to
the condition evaluator only at the occurrence of E3. Of course, the time of occurrence of A* is
the time of occurrence of E3. Parameter relation of a periodic event has two attributes: event type
and time of occurrence. Event type for the periodic event is taken as I'. ...i.l. to differentiate
it from temporal event type. For P*, the parameter is explicitly specified and is included in the
parameter relation along with other relevant parameters.
The schema of the parameter relation associated with an arbitrary event E is computed by
taking the outerunion of the attributes of the participating events. The time of occurrence of
a composite event is the time of occurrence of the last component event that makes the entire
composite event happen (by default) if an event modifier is not explicitly associated with the
expression. If a subexpression in a complex event expression is preceded by a label, then an
additional time of occurrence attribute (L:toc,) is inserted in the parameter relation to represent
the time of occurrence of that component event.
5.2 Parameter Contexts
We introduce the notion of parameter contexts (analogous to the notion of coupling modes in-
troduced in HiPAC [16, 4]) for the purpose of capturing application semantics for computing the
parameters (of composite events) when they are not unique. The notion of parameter contexts
is primarily introduced to both disambiguate the parameter computation and at the same time
accommodate a wide range of application requirements.
The detection of an event corresponding to an event expression may require detection of one
or more events in its detection event set. Situations requiring multiple event occurrences to be
included in the parameter set give rise to alternate ways of computing parameters as the events
are likely to occur over an interval. Furthermore, the parameters may have to be computed in a
way that suits the the semantics of the application which may vary from one class of application
Composite events are expressed in Snoop by the language generated by the BNF given earlier.
A composite event may be comprised of several primitive events. The occurrence of a composite
event is marked by, in the default case, the occurrence of the last event that makes the composite
event occur (end-of event expression semantics). A sequence of event occurrences (over a period
of time) makes this happen. Hence, the composite event detector needs to record the occurrence
of each event and save its parameters so that they can be used to compute the parameter set of
the composite event. We adopt the notation E(Ei, E2,... E,) to represent an event expression E,
where Ei=1..n are its parameter event set. When the occurrences of several primitive events con-
stitute a composite event, different possibilities for detecting composite events exist. To illustrate
this, consider the following event expressions:
A = Any(2,E1, E2) ; E3
B = El V E2 V E3 and
C = El; Any(2,E2, E3)
where El, E2, and E3 are primitive events. Figure 5 shows the occurrences of different instances
of event El, E2 and E3 as well as the event graph for A and C.
Event A is signaled at the point where at least one instance of all the three events has occurred
with E3 being the last occurrence. Event B is signaled each time an instance of any of the three
events El, E2 or E3 occurs. Parameters of event A (as well as C) include parameters of all the
three events El, E2 and E3 whereas the parameters of event B include only the parameters of one
of its events (under the assumption events do not occur simultaneously).
The parameter contexts proposed below are motivated by a careful analysis of several classes of
applications. We have identified four parameter contexts that cover a wide range of applications.
Briefly, we indicate the characteristics of the applications that motivated our choices of parameter
1. Applications where the events are happening at a fast rate and multiple occurrences of an
event only refine the previous data value. This is typical of sensor applications (e.g., hospital
monitoring, global position tracking),
2. Applications where there is a correspondence between the occurrence of events and this cor-
respondence needs to be maintained. Applications that exhibit causal dependency (e.g., be-
tween aborts, rollbacks, and other operations; between bug reports and releases) come under
3. Trend analysis and forecasting applications (e.g., securities trading, stock market, after-the-
fact diagnosis) where composite event detection along a moving time window needs to be
supported; for example, compute change of more than 211'. in DowJones average in any one
day over the given period, and
4. Applications where it is not clear as to how parameters need to be packaged. In this case all
parameters collected are passed.
We introduce the following contexts for the classes of applications described above:
Recent: In this context, only the most recent occurrence of each Ei that has started the
parameter computation is taken into account for computing the parameters of E. When E
occurs, the composite event is signaled and all the occurrences that are used in the parameter
relation are deleted. For example, in the recent context, parameters of event A will include
parameters of event instances el5, e24 and e36 (A is detected when e36 occurs). In this
context, not all occurrences of a primitive event will be used in computing the parameters of
a composite event. In the recent context, the parameters of C will be and
not as it will be wrong. el3 is the most recent occurrence of El that started
the parameter computation and not el5 (or el2).
Chronicle: In this context, instances of component events are taken into account in the
chronological order in which they occur for computing the parameters of the composite event
E. When E is signaled, its parameters are computed by using the oldest instance of each
component event and then parameters of these instances are deleted. For example, parameters
of event A in the chronicle context will be computed by using event instances el2, e21 and
e36. When the next E3 type event occurs at e38, then the A will be signaled with the
parameters . The buffer is flushed once the event is signaled. When the rule
Figure 5: Event Occurrences
is deactivated the entire set of partial buffers are flushed. In this context, the same primitive
event occurrence is used at most once for computing the parameters of the composite event.
Continuous: In this case, each occurrence of an event that marks the beginning of the
interval of an event expression is considered a potential candidate for starting a parameter
set computation. This is especially useful for tracking trends of interest on a sliding time
window. For example, one of the examples that computed 211'. change in DowJones in any
2 hour interval can be elegantly modeled using this parameter context. For example, in
Figure 5, each of the occurrences e12, e13, and el5 (as well as e21 and e24) would start
the detection of the event A. The first occurrence of A will have as parameters
e36>. The parameters of the second occurrence of A will consist of . The
parameters of the third occurrence of A are . In this context, an occurrence
of a primitive event will be used at least once for computing the parameters of the composite
There is a subtle difference between the chronicle and the continuous contexts. In the former,
pairing is with respect to the event that detects the composite event (end of the interval)
whereas in the latter pairing is with respect to the event that begins the interval for the
composite event. For clarification, consider the event expression C and the event occurrences
shown in Figure 5. The event C is initiated by one of the events e12 or e13 or e14 but not
e21 and e24 as is the case for the composite event A. Parameters computed for the event C
in the chronicle context are whereas the parameters computed for the event
C in the continuous context are , . In the recent context, the
parameters computed for C are .
Cumulative: In this context, parameters of E include the parameters of all the occurrences
of each Ei. Whenever E is signaled, all the entries in the parameter relations associated with
each Ei are deleted. For example, parameters of event A will include all the instances of
each event up to e36 when it occurs. The entire table shown in Figure 5 (except e38) is the
parameter relation. Unlike the continuous context, an event occurrence does not participate
in two parameter computations in the cumulative context.
case for the continuous context.
Event expressions can broadly be classified into two categories. The first category consists of
expressions consisting of primitive events and only the operators P, A and V A context specification
to these expressions does not affect the semantics of the corresponding composite events. The
second category consists of event expressions that involve operators Any, Sequence, and cumulative
versions of P and A. These composite events are characterized by a time interval during which
the occurrences of primitive events need to be monitored. Context specification does affect the
semantics of these operators.
Currently, a context can be specified only to the top-level event expression. The need and the
implications of associating parameter contexts (even different ones) for the sub-expressions of an
event expression are being investigated further.
5.3 Equivalence of Snoop Expressions
It is possible to express an event in different ways using the operators in Snoop. Furthermore,
rewriting events and event expressions into equivalent forms may uncover common subexpressions
or allow rule level optimizations that were not possible earlier. However, this also shifts the onus of
detecting equivalent expressions and performing transformations to the rule (or the event) processor.
We define different types of equivalences of expressions in Snoop. The following can be used for
rewriting and optimizing event expressions by using transformations that can be shown to preserve
various types of equivalence of event expressions.
Parameter event set The parameter event set of an event E is defined as the set of primitive
events that participate in the computation of schema for the parameter relation for the event E.
Detection event set The detection event set of an event E is defined as the set of primitive
events that are actually used in the detection of event E according to its defined semantics.
For example, for A(E1, E2, E3), the parameter event set consists of the primitive events in E2
whereas the detection event set consists of primitive events in El, E2, and E3.
Schema equivalence Two event expressions El and E2 are schema equivalent if and only if they
have identical parameter relation schemas. In other words, El and E2 have the same parameter
The above definitions only deal with the schema components of the parameter relation for events.
Given an event expression, one can construct a partial order depicting the causal dependency among
primitive events of the composite event. The actual occurrences of events, in the interval defined by
an event expression, that obey this partial order are used for the parameter computation although
the time of occurrences of all the primitive events are not explicitly stored. In other words, for two
events A and B to be equivalent, the partial orders of A and B depicting the causal dependency
among events need to be equivalent as well as the parameters extensions they compute. For
example, the equivalence of A: All(E1, E2) and B: E1;E2 depends upon the order of occurrence of
component events El and E2 after both have been activated. Whereas for the event expressions A:
All(E1, E2) and B: ((E1;E2) V (E2;E1)) the partial order for A is equivalent to one of the partial
orders of B (B has a non-deterministic component). Also, parameter contexts need to be taken
into account in determining the equivalence of two events.
Semantic Equivalence Two event expressions El and E2 are semantically equivalent if and only
if they have identical parameter and detection event sets and in addition the partial orders of their
primitive events are equivalent.
Equivalence Two event expressions A and B are equivalent if and only if the partial orders of
their primitive events are equivalent and they compute the same parameter relation (modulo event
For example, event expressions
All(E1, E2) and (E1;E2) V (E2;E1) are equivalent assuming the same pa-
Also, All(E1, All(E2, E3)) is equivalent to All(E1, E2, E3) assuming the same parameter
As another example, A*(E3, E1;E2, E4) and All(E1, E2) are schema equivalent but not se-
mantically equivalent as their detection event sets are not the same. However, El + time and
El; (El + [time]) are not semantically equivalent although they have the same detection event set
as they are not schema equivalent. Finally, El V (El + [time]) and El; (El + [time]) are schema
equivalent and semantically equivalent but are not equivalent as their extensions will always be
It is sometimes possible to transform an event expression into its equivalent form to facilitate
its detection and/or optimization of the rule as a whole. For example, commonality among event
subexpressions may be discovered when expressions are transformed using equivalence definition.
Detailed optimization of event expressions are currently being investigated.
5.4 Not, Complement, and Exceptions
Our formulation of the event specification language does not include the commonly found operator
not or complement. The semantics of a not operator especially in the context of events can be tricky.
It is difficult to express and detect the non-occurrence of a happening. This can only be done in
a well-bounded, finite interval without leading to unsafe expressions (similar to unsafe expressions
of relational calculus).
In Ode , the complement operator (denoted !) is introduced and this is applicable to both
primitive and composite events. Unlike , we do not have a complement operator specifying
the complement of the universe of primitive events. Nor do we use not for specifying the non-
occurrence of a primitive event. The utility of the not operator as a complement of the universe of
primitive events is not clear; furthermore, both the detection and parameter computation will be
extremely difficult and inefficient for the not operator with the complement of the universe seman-
tics; for complex events the not semantics is even more difficult to comprehend (notwithstanding
the detection and computation of parameters). However, the interpretation of a not operator as
the non-occurrence of primitive (or complex) events within a well-defined interval is meaningful
and is used for transforming contingency plans using the .---:. *-.il. operator count as shown in the
It seems possible to define a Non-occurrence or not operator N using the event expression
N(E1, E2, E3), which occurs either when E2 occurs or when E3 occurs if E2 has not occurred
in the closed interval defined by El and E3. The main problem is that there are two events E2
and E3 that terminate the composite event N. Whether N occurs or not is based on a condition
if then else disguised in the form of an event which is actually a condition. This differs from
the philosophy used in Snoop in having a single event occurrence terminate a complex event (in
other words, unique semantics) by essentially including if then else semantics as part of the event
semantics. Also, the semantics of N gets complicated further when parameter contexts are used.
Furthermore, we recognize the need for one type of exception as part of the event specification
language: the need to ignore a subset of event occurrences from a given set. For example, if one
wants to specify, in a banking application, the rule "Generate a report on all withdrawals greater
than $1000.00 each working day", neither our formulation nor  can express it. The difficulty
is that currently, it is not possible to ignore specific instances (event occurrences corresponding
to the weekend) from a pre-defined set. This feature can also be used for non-cumulative event
specifications (e.g., A, and P) to ignore when exceptions occur rather than removing them from
the set of events detected. Currently, we are investigating language features to support the above
6 Event Detection
Event detection is the process of recognizing the occurrence of an event, collecting and recording
the parameters of the event including the time of occurrence. The process of detection takes a finite
amount of time (depending on the architecture and the techniques used) and as a consequence, there
may be a lag between the time of occurrence of an event and its detection. Assuming the time line
shown in Figure 1, if To is the point of occurrence and Td is the point of detection of an event,
then TL = Td To is called the delay of event detection. Value of this delay, in a sense, quantifies
the timeliness of the detection of an event by the DBMS. In order to avoid the risk of missing the
timeliness window, it is desirable to keep the value of TL as small as possible. In applications that
have contingency plans to accommodate timing constraints (discussed in the appendix), the lower
bound the DBMS can guarantee on TL plays a critical role.
An event detector is that component of the system which records the occurrences of events by
collecting their parameters and makes this information available to condition evaluator. Detection
of events expressed in Snoop entails: detection of primitive events and detection of composite
In order to detect a primitive event (except, explicit events) a detection mechanism is assumed
to be embedded within the system. For example, the system clock and interrupts are used to
detect temporal events. Similarly, database events are detected by using code embedded within the
system component responsible for reading and writing the data on the disk or by using lower level
6.1 Event Graph Construction
Again, consider the events:
A = Any(2,El, E2); E3 and
B = El V E2 V E3
where El, E2, and E3 are primitive events. Figure 5 shows the occurrences of different instances
of events El, E2 and E3. A parameter context is assumed to be specified for composite events (the
default is the recent context).
A rule processor accepts rule definitions as input and converts the event expressions contained
in them into an appropriate structure which is used in the actual detection process. If the rule
contains an 'otherwise' part (i.e., a contingency plan), the rule processor transforms it into two
rules (as shown in the appendix) by using explicit events and the ..-.-:.-' .l. operator count. The
rule processor also accepts definitions of explicit events along with the parameter specifications.
Rules and events are transformed using the equivalences discussed in Section 5.3 before converting
an event into a collection of event graphs.
The main data structure used by the rule processor for compiling individual event is an event
graph. Event expressions in each rule is translated into an event tree with the outermost operator
of the event expression as the root of the tree. In order to exploit commonalities (same or common
subexpressions) among the event expressions of rules, individual event trees are coalesced. Figure 5
is an example of an event graph showing some common subexpressions. Both control and data flow
from leaf nodes to root nodes in the event graph.
An event graph comprises of non-terminal nodes (N-nodes), terminal nodes (T-nodes) and edges.
Each node represents either a primitive event or a composite event. N-nodes represent composite
events and may have several incoming and several outgoing edges. T-nodes represent primitive
events and have one incoming and possibly several outgoing edges. Parameters are propagated
to the nodes using the edges. When a primitive event occurs, it activates the terminal node that
represents the event. This in turn activates all nodes attached to it via outgoing edges. When a
node is activated, it executes a procedure which evaluates the incoming data (using the operator
semantics of that node and the parameter context) and if necessary, activates one or more nodes
connected to it by propagating the parameters of the event. If the node is marked with the rule-id,
it also signals the corresponding event to the condition evaluator.
Algorithm for building an event graph:
if the rule has a contingency plan /* see Appendix */
Define rules corresponding to ruleidl and ruleid2;
Modify 'action' part of the original rule;
For all event expressions
Mark the top node with rule-id;
merge the event graphs with the collection of event graphs;
/* this algorithm is not shown in this paper */
6.2 Composite Event Detection Algorithm
The event detector begins monitoring a composite event E, represented by the event expression
E(E1, E2,..., En), at a point tbhein on the time line, which corresponds to the time when the rule
containing the event E is last activated. The event detector maintains parameter relations for all
component events in the composite event. At time tbe,,, which is specific to each composite event,
parameter relation of all component events El, E2, ... En are cleared. Whenever an event Ei
occurs, its parameters are recorded in its parameter relation. In case of multiple occurrences of
the same event, its parameters are accumulated in the same parameter relation. When the last
component event needed to evaluate the event expression occurs, the expression is evaluated by
using the event algebra and if true, the composite event is signaled along with its parameters. Also,
when an event is deactivated (i.e., it's made dormant and not detected till it is explicitly activated
again), all unused occurrences of its component events are discarded.
The algorithm given below detects composite events in the recent context.
On the occurrence of a primitive event
store its parameter in the corresponding terminal node 't';
For all rule-ids attached to the node n'
For all outgoing edges i from 'n'
propagate parameters in node 'n' to the nodei connected by edge i
Delete propagated entries in the parameter relation at n'
case nodei of
'Or' : store the parameters in the relation;
'Any': store/replace the parameters in the relation;
If n component events have occurred
;: If left event
mark it as occurred;
else if ,'.i /I event and left event is marked as occurred
'A': If left event
mark it as occurred;
else if middle event and left event is marked as occurred
else if '-il / event
mark left and "'i1l events as not occurred.
'A*' : If left event
mark it as occurred;
else if middle event and left event is marked as occurred
else if I '1,1 event
mark left and i ".;ld events as not occurred.
'P': If left event
mark it as occurred;
else if middle event and left event is marked as occurred
else if I '-li/ event
mark left and "';,1d events as not occurred.
'P*': If left event
mark it as occurred;
else if middle event and left event is marked as occurred
accumulate parameters for the specification;
else if i'./il event
mark left and i ",'d1 events as not occurred.
As an example, consider the following composite event:
C = El; All(E2, E3)
Given the occurrences of events as shown in Figure 5, Figure 6 shows the detection of E using the
recent context Event eij indicates the occurrence of event type Ei at time tj in Figure 5.
Algorithms for detecting composite events in other parameter contexts and coupling modes are
currently under development.
6.3 Storage Requirements
Parameter contexts introduce additional complexity for event detection as well as the computation
of parameters. Some of the parameter contexts, such as continuous and cumulative, impose heavy
storage requirements. The recent parameter context can be implemented using a fixed size buffer
at each node in the event graph where only the parameter for the most recent occurrence of an
event is stored. For the chronicle context, a queue is required and the amount of storage needed
is dependent upon the duration of the interval of the composite event and the frequency of event
occurrences within that interval. Similarly, for the continuous context, the storage requirements
can be excessive implying that the choice of the parameter context for each rule needs to be
made judiciously. When there are overlapping event sub-expressions among several rules, it may
be possible to have shared data structures for parameters to reduce the storage requirements. For
cumulative context also the storage requirements can be excessive. However, based on the semantics
rule-id el3 e24 e36 Signal Event
E Time E2 E3
t 5 el5
Figure 6: Detection of the Composite Event C in recent context
of the parameter contexts, the storage requirement increases monotonically from recent to chronicle
to cumulative to continuous.
Additional research is required for analyzing the performance by using the language and the
system being developed (Sentinel [5, 2]) in real-life applications.
In this paper, we have defined an event, event modifiers and developed a language that supports
several types of events needed to model non-traditional applications. We have, as part of the
language, supported database, temporal, explicit, periodic and periodic events and have proposed
a technique for implementing contingency plans required for time-constrained applications. We
have, for the first time, introduced the notion of parameter contexts for detecting and computing
parameters for composite events. We have given an algorithm for detecting composite events and
computing their parameters in the recent parameter context.
Our language subsumes the events supported in the extant active database systems including
Ariel [15, 5], Interbase (), Postgres ( , ), Starburst , , HiPAC (,), ADAM
(), Ode , and Samos (), OSAM* ([19, 22]). Table 7 compares Snoop with the events
supported in various sy-,. ii--'. The emphasis in Snoop [20, 6] and Sentinel [5, 2] is quite different
from that taken in  and , respectively; Snoop extends the event specification language in a
model independent manner and Sentinel integrates active capability into an object-oriented DBMS
in a seamless manner and does not take the layered approach.
Although  has operators that are similar to the ones in Snoop, there are some fundamental
8We are aware of related work in office automation, AI, and temporal logic. To keep the table manageable and to
the point, this comparison is limited to only those that are categorized under active databases.
Feature Primitive Event Types Expressiveness Efficiency and Modularity
System Database Temporal Explicit Complex Events Event Modifiers Parameter Contexts Independent Transformations
set of time
Ariel Yes values No No Post No No No
Interbase Yes No No Disjunction Pre, Post No No No
Postgres Yes Time() No Disjunction equivalent No No No
Starburst Yes No No Disjunction Post No No No
HiPAC Yes Absolute, Yes Disjunction, Pre, Post No No No
Ode Yes Yes Yes Sequence, Before, After No No No
fa, faAbs, !
ADAM Yes Timed No No Before, After No No No
Samos Yes specifica- Yes Conjunction, Pre, Post No No No
tion Sequence, Not
OSAM* Yes No No Disjunction before, after No No No
Figure 7: Comparison of Snoop with other event specification efforts
differences between the two approaches to event specification. We use ECA rules whereas Ode uses
EA (event-action) rules and conditions are specified as part of events (as masks). The separation of
when to fire a rule (by the event), what to check (by the condition), and how to react (by the action),
in our opinion, provides greater flexibility from the user specification viewpoint than that of a EA
rule. Of course, as part of our optimization, we can rewrite rules using the equivalence, coupling
modes, and parameter contexts and internally implement the event detection and condition testing
in alternative ways. Furthermore, merging conditions into events severely restricts extensibility
of the system. Event detection is usually embedded in the system and adding or deleting them
requires recompilation of the system. On the other hand, conditions and actions can be modified,
recompiled and can then be dynamically loaded into the system. This provides great end user
Snoop is model independent and is intended to be so; we have successfully mapped both the
specification and detection of Snoop events onto the relational model in this paper and to an
object-oriented data model in [1, 2]. The notion of parameter contexts is new. We have clearly
distinguished between events and conditions as well as between event expressions, events, and
physical events. The notion of event modifiers is novel in that it enables one to provide a mapping of
events at the conceptual level to physical (or internal) events without changing the rule specification.
This paper represents our initial attempt at defining an expressive language for event specification.
Below, we identify a number of issues that were not addressed in this paper but are critical to the
area of active databases:
Snoop as well as Ode  cannot express exceptions that exclude certain events from a set.
For example, we cannot express a rule that requires reports to be generated only for working
days. That is, we cannot exclude specific events computed by a cumulative event expression.
Currently we are trying to enhance the expressiveness of Snoop to accommodate these.
Efficient event detection in various parameter contexts and the persistence and recoverability
aspects of event detection has not been addressed at all in this paper. Also, reliable event
detection mechanisms for different architectures (e.g., client/server, distributed) need to be
While discussing Or operator we have ignored the possibility of simultaneous occurrence of
events. However, explicit and temporal events may take place with other primitive events at
the same time. Moreover, simultaneous occurrences are natural in a multiprocessor environ-
ment. Related problems associated with multiprocessor and distributed architectures need to
Although we have proposed an operator-tree based approach to event detection, certain other
formalisms (e.g., Petri Nets) may be useful for the external specification as well as for detecting
composite events. The motivation for this is that Petri Nets provide I I.-" concurrency unlike
CSP (communicating sequential processes) and Milner's CCS both of which provide only
interleaving semantics. Also, this may help in providing a mechanism for the specification as
well as detection of simultaneous event occurrences. We are currently studying alternative
approaches to efficient detection of events.
We would like to thank Ms. Eman Anwar for her critical comments on an initial draft of this
paper and for helping us in formulating the comparison table. Her suggestions have substantially
improved the readability of this paper.
 E. Anwar. Supporting complex events and rules in an oodbms: A seamless approach. Master's thesis,
Database Systems R&D Center, CIS Department, University of Florida, E470-CSE, Gainesville, FL
32611, November 1992.
 E. Anwar, L. Maugis, and S. Chakravarthy. A new perspective on rule support for object-oriented
databases. Technical Report UF-CIS TR-92-042, Database Systems R&D Center, CIS Department,
University of Florida, E470-CSE, Gainesville, FL 32611, November 1992. (To appear in sigmod 93).
 S. Ceri and J. Widom. Deriving Production Rules for Incremental View Maintenance. In Proceedings
17th International Conference on Very Large Data Bases, pages '.;-589, Barcelona (Catalonia, Spain),
 S. Chakravarthy et al. HiPAC: A Research Project in Active, Time-Constrained Database Management,
Final Report. Technical Report XAIT-89-02, Xerox Advanced Information Technology, Cambridge, MA,
 S. Chakravarthy, E. Hanson, and S.Y.W. Su. Active Data/Knowledge Base Research at the University
of Florida. in IEEE Quarterly Bulletin on Data Engineering, 15(1-4):35-39, December 1992.
 S. Chakravarthy and D. Mishra. An event specification language (snoop) for active databases and
its detection. Technical Report UF-CIS TR-91-23, Database Systems R&D Center, CIS Department,
University of Florida, E470-CSE, Gainesville, FL 32611, Sep. 1991.
 M. Colton. Replicated data in a distributed environment, January 19931. Presentation at the PDIS-2
Conference, San Diego, CA.
 U. Dayal, A. Buchmann, and D. McCarthy. Rules are Objects Too: A Knowledge Model for an Active,
Object-Oriented Database Management System. In Proceedings ',.1 International Workshop on Object-
Oriented Database Systems, Bad Muenster am Stein, Ebernburg, West Germany, Sept. 1988.
 O. Diaz, N. Paton, and P. Gray. Rule Management in Object-Oriented Databases: A Unified Approach.
In Proceedings 17th International Conference on Very Large Data Bases, Barcelona (Catalonia, Spain),
 C. L. Forgy. RETE: A Fast Algorithm for the Many Pattern/\1 NI Object Pattern Matching Problem.
Artificial Intelligence 19, pages 17-37, 1982.
 C. L. Forgy and J. McDermott. Domain-Independent Production System Language. In Proceedings
Fifth International Conference on Artificial Intelligence, Cambridge, MA, 1 '.
 S. Gatziu and K. R. Dittrich. SAMOS: an Active, Object-Oriented Database System. in IEEE Quarterly
Bulletin on Data Engineering, 15(1-4):23-26, December 1992.
 N. H. Gehani and H. V. Jagadish. Ode as an Active Database: Constraints and Triggers. In Proceedings
17th International Conference on Very Large Data Bases, pages 327-336, Barcelona (Catalonia, Spain),
 N. H. Gehani, H. V. Jagadish, and O. Shmueli. Event Specification in an Object-Oriented Database.
In Proceedings International Conference on Management of Data, pages 81-90, San Diego, CA, June
 Eric N. Hanson. An Initial Report on the Design of Ariel: a DBMS with an integrated production rule
system. AC if SIC. fOD RECORD, 18(3):12-19, Sep. 1989.
 M. Hsu, R. Ladin, and D. McCarthy. An Execution Model for Active Data Base Management Systems.
In Proceedings 3rd International Conference on Data and Knowledge Bases, Jun. 1988.
 R. Hull and D. Jacobs. Language constructs for programming active databases. In Proceedings 17th
International Conference on Very Large Data Bases, pages 455-468, Barcelona (Catalonia, Spain), Sept.
 InterBase Software Corporation, Bedford, MA. InterBase DDL Reference Manual, InterBase Version
 H. Lam, S.Y.W. Su, and A. M. Alashqur. Integrating the Concepts and Techniques of Semantic Mod-
eling and the Object-Oriented Paradigms. In Proceedings 13th International Computer Software and
Applications Conference, Orlando, Florida, Sep. 1989.
 D. Mishra. Snoop: An event specification language for active databases. Master's thesis, Database
Systems R&D Center, CIS Department, University of Florida, E470-CSE, Gainesville, FL 32611, Aug.
 U. Schreier et al. Alert: An architecture for transforming a passive dbms into an active dbms. In Pro-
ceedings 17th International Conference on Very Large Data Bases, pages II.'i I, Barcelona (Catalonia,
Spain), Sept. 1991.
 Madhulika Singh. Transaction Oriented Rule Processing in An Object-Oriented Knowledge Base Man-
agement System. Master's thesis, University of Florida, Database Systems R&D Center, Gainesville,
 M. Stonebraker et al. On Rules, Procedures, Cashing and Views in Database Systems. In Proceedings
of AC \1- If( OD, pages 281-290, May 1990.
 M. Stonebraker and Lawrence Rowe. The Postgres Papers. Technical Report UCB/ERL M86/85, Dept.
of Electrical Engineering and Computer Science, Univ. of California, University of California, Berkeley,
C'.\'i I -'l Jun. 1 I;.
 J. Widom and S. Finkelstein. Set-Oriented Production Rules in Relational Database Systems. In Proc.
of AC I!- [(, OD, pages 1'",*1 270, May 1990.
A Contingency Plans
A number of applications require time-constrained processing of actions and if these cannot be
carried out within pre-specified time, alternative actions need to be scheduled. Such rules are
termed contingency plans. For example, in a replicated distributed database, after the data has
been requested from a remote primary site, the requester must wait for the data and if it does
not arrive within a prescribed time, then a "store and forward" mode of operation may have to be
To model such contingency plans, it is necessary to recognize the non-occurrence of an event
(e.g., the end of the action execution) within a specified interval. Below, we propose a pragmatic so-
lution to the above by using explicit events and the .--'--. *.-.il operator count to determine whether
an event of interest has occurred or not without changing the semantics of event operators or intro-
ducing a new event operator. For example, if 'S' is the event that corresponds to the transmission
of message for a 3 phase commit and 'Ack' is the event that represents the receipt of the acknowl-
edgment from the remote site then the event and condition parts for the rule that retransmit the
data if the acknowledgment does not arrive within t units of time after the transmission can be
expressed by using A* operator as follows.
Ack_rule: ON A*(S, Ack, S + [t])
IF count('Ack' in P_ackrule) = 0
The event of this rule occurs t time units after the occurrence of event 'S'. We assume that param-
eters of the event of a rule are recorded in a relation P_rule-id. "Count" is a function that returns
the number of tuples corresponding to the occurrences of event 'Ack' in the parameter relation of
A* event. Above rule executes its action if the acknowledgment is not received within the specified
Many other time-constrained applications require monitoring specified situations and executing
corresponding actions, subject to some timing constraints. Contingency plans are alternate actions
which should be executed if the specified action cannot be realized within the specified time limit.
Contingency plans can easily be implemented using the 'A*' event operator and the count function.
The rule compiler converts a rule that has contingency plans into two rules. The first rule contains
the same event, condition and action as that of the main rule and signals a "Rule_Event" explicitly
at the beginning and at the end of the .,. ii..ii". In this case, rule_events are essentially begin-of
and end-ofthat correspond to the .,. I ..i," part of the rule. These two rule_events form the event
part of the second rule. For example, the following contingency rule9