• TABLE OF CONTENTS
HIDE
 Title Page
 Table of Contents
 Main






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Anatomy of a composite event detector
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095207/00001
 Material Information
Title: Anatomy of a composite event detector
Alternate Title: Department of Computer and Information Science and Engineering Technical Report ; TR-93-039
Physical Description: Book
Language: English
Creator: Chakravarthy, Sharma
Krishnaprasad, V.
Anwar, E.
Kim, S. K.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: December, 1993
Copyright Date: 1993
 Record Information
Bibliographic ID: UF00095207
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1993121 ( PDF )


Table of Contents
    Title Page
        Page i
    Table of Contents
        Page ii
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
Full Text















University of Florida
Computer and Information Sciences


Anatomy


of a Composite Event
Detector


S. Chakravarthy
V. Krishnaprasad
E. Anwar
S.-K Kim
email: sharma@snapper.cis.ufl.edu

Tech. Report UF-CIS-TR-93-039
December 1993
(Submitted for publication)


.. -* Department of Computer and Information Sciences
f_ Computer Science Engineering Building
SUniversity of Florida
Gainesville, Florida 32611










Contents


1 Introduction 1


2 Summary of Snoop 3

2.1 Prim itive Events ... ... ... .. ... ... ... ... ... .. ... ... ... 4

2.2 Composite Events ................... . . . . . .... 4

2.2.1 Operator Semantics ................ . . . . . .... 5


3 Histories and Event Logs 8

3.1 The General Context ................... . . . . . ...... 10


4 Composite Event Detection 12

4.1 Parameter Contexts ................... . . . . . ...... 14

4.2 Illustration of Composite Event Detection .................. .... .. .. 17

4.3 Storage Requirements .................. . . . . . ...... 20


5 Architecture and Implementation 20

5.1 Proposed Architecture .................. . . . . . ...... 23


6 Conclusions 24


Appendix A. Details of Event Detection 27


Appendix B. Composite Event Detection Algorithms 28














Anatomy of a Composite Event Detector *


S. Chakravarthy V. Krishnaprasad E. Anwar S.-K Kim
Database Systems Research and Development Center
Computer and Information Sciences Department
University of Florida, Gainesville, FL 32611
email: {sharma, vk, emsa, skk}@cis.ufl.edu



December 1993




Abstract

Making a database system active entails developing an expressive event specification language
with well-defined semantics, algorithms for the detection of composite events, and an architecture
for an event detector along with its implementation. This paper presents Snoop as the event
specification language along with the semantics of composite events over a global event-history
(or a global event-log). Parameter contexts are introduced for meaningfully restricting the
detection of composite events. In addition, algorithms for the detection of composite events
in various parameter contexts are presented. Finally, an architecture and implementation of a
composite event detector is analyzed in the context of an object-oriented active DBMS.


1 Introduction


Consensus is emerging in the database community about the structure of 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 [3, 19, 12]. Once rules are declared, the database management system (DBMS)
is responsible for detecting the occurrences of the events, evaluating the condition when the event
is signaled, and executing the action if the condition evaluates to true. A significant body of
work exists on rules and rule processing in a DBMS. However, the event component of rules has
received attention only recently [4, 5, 14, 10] and perhaps is the least understood compared to the
condition and action components. Conditions and actions can be viewed as side-effect free queries
and transactions, respectively.

*This work is supported, in part, by the National Science Foundation IRI-9011216, by the Office of Naval Research
and the Navy Command, Control and Ocean Surveillance Center RDT&E Division, and by the Rome Laboratory.










Although event specification has been addressed in the literature primarily in the context of
active databases, its applicability is not limited to active databases. An expressive event specifi-
cation language and its detection can be used for analyzing event histories (or event logs) [16] in
applications, such as stock trading, trend/demographic profile computation, and auditing (either
as events occur or over stored occurrences). Some aspects of knowledge discovery (e.g., determin-
ing events that lead to the stock market crash, understanding sequences of events leading to an
earthquake) involves analyzing event patterns and their effect on various recorded observations. In
other words, applications that examine cause-effect relationships need to specify and detect complex
event occurrences.

From the above, it is evident that support for rules needs to be complemented with an expressive
event specification language. As an example, management of portfolios for various customers in
a stock-trading application may require a rule of the form --. ,, the DowJones average changes
by 21'. in any 2 hour interval, after reaching the value 3750, execute Trump's portfolio model to
determine what to buy or 11". This rule requires not only the database events, but also temporal
and composite events; this rule requires an expressive event specification language for modeling its
events. As another example, detecting periodic occurrences of a pattern of events may indicate a
potential money laundering scheme.

This paper describes an event specification language that supports several types of primitive
events and a small set of operators for constructing composite (also termed complex in the literature)
events. We introduce primitive event sequences as ordered occurrences of a primitive event (termed
primitive event-history/event-log), and composite event-history/event-log as a partial order of the
merged primitive event-histories. We define the semantics of primitive and composite events over
an event-history. Moreover, we argue that the detection of composite events over a composite
event-history needs to be restricted in meaningful ways to make it relevant to application classes as
well as for its use in active databases. To accommodate this, we introduce the notion of parameter
contexts as a mechanism for precisely restricting the occurrences that make a composite event occur
as well as for computing its parameters.

Ode [14, 13] and Samos [10, 11] address event specification and detection in the context of
active databases. Although there are some differences between Snoop, Ode, and Samos in the event
specification language (for example, Samos has a Times operator for defining the occurrence of n
events in an interval and Ode has a complement operator), they differ primarily in the mechanism
used for event detection. Ode uses a finite automaton and Samos uses a labeled Petri Net. In
contrast, we use an event graph where event occurrences (both primitive and composite) flow
bottom-up from the nodes to their parents. In addition, the notion of parameter contexts is unique
to Snoop.










The rest of this paper is structured as follows. Section 2 summarizes the operators of Snoop [15]
along with their semantics. In Section 3, we define global, primitive, and composite event-histories
and define the computation of composite events using the event-history. In section 4, we introduce
parameter contexts and illustrate event detection for all contexts. Section 5 provides an architecture
for composite event detection in an object-oriented DBMS and highlights implementation issues.
Section 6 contains conclusions. Appendix A has detailed illustrations of event detection algorithms
and appendix B has algorithms for detecting composite events in various contexts.


2 Summary of Snoop


For the purpose of this paper, we assume an equi-distant discrete time domain having "0" as the
origin and each time point represented by a non-negative integer. In this paper, we distinguish
between an event, an event expression, and an event modifier. Briefly, an event expression defines
an interval on the time line. The notion of an event expression is needed to model operations
that take a finite amount of time for their execution. For example, a method, a function, or a
transaction can be viewed as an event expression. 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 an occurrence of that event. In other words, an event expression needs
to be mapped to a point that can be declared as an event occurrence corresponding to that event
expression. The notion of event modifiers were introduced in [6] to transform an event expression
to one or more events, each of which corresponds to a point of interest within the closed interval
defined by that event expression. For example, begin-of and end-of are two event modifiers that
transform an arbitrary interval on the time line into corresponding event occurrences.

An event is an instantaneous, atomic (happens completely or not at all) occurrence. In database
applications, the interest in events comes mostly from the state changes that are produced by
database operations. That is, 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 associated with operations (i.e.,
event expressions) of interest and operation's parameters are viewed as the parameters of the event
associated with that operation. For simplicity, we assume that two occurrences of the same event are
not simultaneous1 Moreover, we assume that no two event types occur simultaneously. Furthermore,
an event may precede or follow another, or events may be unrelated. For example, the two events
end-of-abort T1 and begin-of-rollback T1 must follow one another and are causally related causallyy
dependent). Whereas the events begin-of T1 and begin-of T2 are causally independent and are said

1This may not be true in multiprocessor and distributed environments. Furthermore, we do not differentiate
between the time-of-occurrence (t_occ) and the time of detection (t_det).










to be unrelated. An event is definite if and only if it is guaranteed to occur.


2.1 Primitive Events

Events are classified into: i) primitive events -events that are pre-defined in the system (using
primitive event expressions and event modifiers). A mechanism for the detection is assumed to be
available (refer to [1] for details) and ii) composite events -events that are formed by applying
a set of operators to primitive and composite events. Primitive events are further classified into
database, temporal, and explicit events.

Database events correspond to database operations, such as retrieve, insert, update and delete
(in the relational model) and methods (in the object-oriented model). Temporal events are either
absolute or relative. 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 >, using the format < (hh/mm/ss)mm/dd/yy >. In the specification of an
absolute temporal event, a field in the time string may contain a wild card notation, which is denoted
by '*' which matches any valid value for that field. This is especially useful in the specification
of events that match many 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) / /* >. 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). 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. Observe that a relative event subsumes an
absolute event. However, the absolute version is retained for practical reasons. Explicit events are
those events that are detected along with their parameters by application programs (i.e., outside
the DBMS) and are only managed by the DBMS. Once registered with the system, they can be
used as primitive events.


2.2 Composite Events

Primitive events form the basic building blocks for developing an expressive and useful event specifi-
cation language. In the absence of event operators, several rules are required to specify a composite
event. Furthermore, some control information needs to be made a part of a rule specification 2. We
In fact, in production rule systems (e.g., OPS5 [8, 9]), 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










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.

We define a composite event expression, recursively, as an event expression formed by using a
set of primitive event expressions, event operators, and composite event expressions constructed
up to that point. Below, we describe each of these operators and their semantics. We will use E
(upper case alphabets) to represent an event expression as well as an event type and e (lower case
alphabets) to represent an instance of the event E. We use superscripts to denote the relative time
of occurrence with respect to events of the same type. Subscripts denote the event types.


2.2.1 Operator Semantics

An event E (either primitive or composite) is a function from the time domain onto the boolean
values, True and False.

E: T {True, False}

given by
E { ( T(rue) if an event of type E occurs at time point t
S F(alse) otherwise

We denote the negation of the boolean function E as ~ E. Given a time point, it computes the
non-occurrence of an event at that point.

The Snoop event operators 3 and the semantics of composite events formed by these event
operators are as follows :


1. OR (V): Disjunction of two events El and E2, denoted E1VE2 occurs when El occurs or
E2 occurs. Formally,

(EVE2)(t) = EI(t) V E(t)


2. AND (A): Conjunction of two events El and E2, denoted El A E2 occurs when both El
and E2 occur, irrespective of their order of occurrence. Formally,

(EL AE)(t) = {(E(t) A E2(t)) V ((E(t) A E2(tI))

and t1 < t}

explicitly specified but are inferred for the worst case scenario.
3We denote the i-j.... i;.. "...ij..... i;..G and "not" event operators as V, A, and -, respectively. The symbols
V, A, and ~ represent the or, and, and not boolean operators, respectively.









Note that the OR and AND operators are commutative and associative :


(ELVE2)(t)
(EIA(E2LE3))(t)


(E2VEI)(t)
((ElAE2)AE3)(t)
(ElA(EAE3))(t)
(E ALE2AE3)(t)


3. ANY: The conjunction event, denoted by Any(m, El, E2, ... E,) where m <= n, occurs
when m events out of the n distinct events specified occur, ignoring the relative order of their
occurrence. Formally,


ANY(m, E1, E2, -, E,)(t)


For example, ANY(3, E1, E2, E,)(t)


(Ei(tl) A E,(t2) A.. A Ek(tm))
and t1 < t2 < . < tm = t
for some distinct i,j, --, k, each < n


(Ei(t1) A E,(t2) A Ek(tm))
and (t1 < t) and (t2 < t)
and tt = t and (i j k)
and (i < n) and (j < n) and (k < n)


To specify m distinct occurrences of an event El :


ANY(m, E)(t)


(Ei(tP) A El(t2) A .. A Ek(tm))


and t1 < t2 < < tm =t



4. Seq (;) Sequence of two events El and E2, denoted E1;E2 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. Formally,


(EL; E2)(t)


(E2(t) A EI(t))
and ti < t


It is possible that after the occurrence of El, E2 does not occur at all. To avoid this situation,
it is desirable that definite events, such as end-of-transaction or an absolute temporal event,
are used appropriately.










5. Aperiodic Operators (A, A*):


The Aperiodic operator A allows one to express the occurrence of an periodic event in the
half-open interval formed by El and E24. 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. The event A is signaled each time E2 occurs during the
half-open interval defined by 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). Formally,

A(E1, E2, E3)(t) = (EI(t)A E3(t2) A E2(t))

and t1 < t2 < t or

t1 < t2 < t


There are situations when a given event is signaled more than once during a given interval
(e.g. within a transaction), but rather than detecting the event and 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
occurrences of E2 in the half-open interval formed by El and E3. This constructor is useful
for integrity checking in databases and for collecting parameters of an event over an interval
for computing ..'--i. -:.,l. As an example, highest or lowest stock price can be computed over
an interval using this operator. Formally,

A*(El, E2, E3)(t) = (El(tP) A E3(t)) and t1 < t

In this formulation E2 (there can be 0 or more occurrences of it) is not included because we
are concerned with occurrence of the composite event A* which coincides with the occurrence
of E3 and is not constrained by the occurrence of E2.

6. Periodic Event Operators (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. The notation used for expressing a
periodic event is P(Ei, [t], E3) where El and E3 are events and t is the time specification.
P occurs for every t in the half-open interval (El, E3]. t is assumed to be positive. It is
important to note that t is a constant and preferably not contain wild card specification in all
fields because this will result in continuous (i.e., for each point on the time line) occurrences
of P. Formally,
4The interval can either be (t_occ(E1), t_occ(E2)] or [t_occ(E1), t_occ(E2)).












P(E1,[TI],E3)(t) = (EI(t)A ~ E(t2))

and t1 < t2 < t

and t1 + i TI = t for 0 < i < t

where TI is a time specification.

Note that the event of interest in P is the middle event which is a time specification. To
make the event more practical and meaningful for real-life applications, it may be useful to
allow a parameter along with the frequency specification. To accommodate this, we define a
cumulative variation of P (denoted P*) which includes a parameter for each occurrence of the
periodic event. In the absence of this parameter, the cumulative operator just accumulates
time of occurrences of the periodic event as the parameter object. Formally,



P*(E1, [TI], E3)(t) = (E(t) A E3(t))

and tI + TI < t


7. Not (-): The not operator, denoted -(E2)[E2, E3] detects the non-occurrence of the event
E2 in the closed interval formed by El and E3. Note that this operator is different from that
of !E a unary operator in Ode [14] which detects the occurrence of any event other than E.



-(E2)[E1, E3](t) = (EI(tl)A ~ E2(t) A E3(t))

and t1 < t2 < t


We believe that the above set of event operators define an event specification language that meets
the requirements of a large class of applications. Periodic and periodic operators were introduced
to meet the requirements of process control, network management, and CIM applications.


3 Histories and Event Logs


So far, we have defined the semantics of event operators over the time line in which only the time
of event (primitive or composite) occurrences were recorded. However, detection of a composite
event entails detecting not only the time at which the composite event occurs, but also the specific
constituent event occurrences that make the composite event occur. In this section, we formally
express the occurrence of a composite event E with respect to its constituent events that form









part of the occurrence of E. A constituent event of an event are its sub-events. At some level, the
constituent events are primitive events.

Gaining a sound understanding of this paper depends on fully comprehending the following
sentences. Recall that event occurrences are denoted by ej where j denotes the event type and i
denotes the relative time of occurrence with respect to events of the same type. Composite events
are represented as a set of constituent event occurrences within which the order of event occurrences
is preserved for non-repeating primitive events. Furthermore, the last event in the set is one whose
occurrence made the composite event occur. The time of occurrence of a composite event is the
time of occurrence of the last primitive event in the set.


Global Event-History/Event-Log is a set of all primitive event occurrences and is denoted by
H. Each primitive event occurrence is represented as a set in the log.

H = {{e} for all j, the primitive event ej has occurred at instance i}


Primitive Event-History/Event-Log of the primitive event type E is a set of the occurrences
of E present in the Global History H and is denoted by E[H].

Ej[H] = {{e}} for all i, {e'} E H}.


Composite Event-History/Event-Log of a composite event E that has n constituent events
El, E, is a mapping from the global event-history H to a subset of El[H] ... E,[H]
where U is an operator that computes the cross product of two sets (whose elements are sets) and
merges the elements of the cross product using the union operator.

For example, Ecomposite[H] y E2[H], given the event histories,

Ecomposite[H]= {{el, e4}, {e2}} and E2[H] = {{e}, {el}}

is given by

Ecomposite[H] HE2[H] ={ {el,, e, }, {e, e, e}, {e e}, {e e2}}


Primitive Event Collection is a collection of all primitive events occurrences of a particular
type within a specified time interval. It is denoted by the function p.

p(E, starttime, endtime) = {e | {ej} E E[H] and start_time < i < end_time}

Given a global event-history, the event-history for an arbitrary composite event formulated us-
ing the operators defined in section 2.2 can be computed. Below, we define these computations









formally. This formulation will compute all occurrences of a composite event (along with partic-
ipating constituent event occurrences) for a finite H. This is termed the General Context. The
operators t, V, A are all left associative.

3.1 The General Context

1.


(EIVE2)[H]


(EIAE2)[H]


ANY(m, El, E2, -, E. )[H]


{e E E E[H]U E[H]}


f{{e, e} {e, eG E [H] HE2[H] U
E2[H] JEi[H] and
and t_occ(ei) < t_occ(e )}



{{ei, ej, } tocc(i) < tocc(eC) < < tocc(ek) and
| {ei, e3, ek} | = m {e ,e ,- ,e} (EI[H] HE2[H] -...- Et,[H])}


where P is the power set.


ANY(m, E*)[H]


{{ei,e. .,ek}


t_occ(i) < t_occ(e5) < < t_occ(ek) and
I{ei, ej, .. ek} I= m n and
{ei, ., } C k, E P(E[H])}


t_occ(e) < tocc(ed) and
{ez,e } e Ei[H] tE2[H]}


{ {e, e} t_occ(e) < t occ(e ) and
{ei,eJ,e } E1[H] E2[H] HE3[H]}


P(E, [t], E3)[H] = {{e, tj}


t_occ(e) < t_occ(ed) and
V{ei,ek} e Ei[H] E3[H]
all t = i+ jt< k andj >0}


(E; E2)[H] = {{e, ej}}


A(E1, E2, E3)[H]











-(E2)[E1, E3][H]


{{ei,e} {I e} e E1[H] JE3[H] and
p(E2, tocc(e), t_oc(ek) = 1}


The definition of the cumulative operators include the accumulation of event occurrences over
an interval. This requires the function p to collect the appropriate occurrences. A* and P* are
defined below using p :

8.


A*(E, E2,E3)[H]


{{e, p(E2, t_occ(e), t_occ(ek)), e |k {I } e El[H] and
{ek E3[H]}


P*(El, [t], E3)[H]


{{ei, p(t, t_occ(ei), t_occ(ek)), ek I


{e'} E1[H],
returns timepoints and {ek} E E3[H]


V{eC, ek} E1[H] JE3[H]
allt = i +jt < k andj > 0}

Below, we illustrate the computation of the composite event X on the global history according to
the above definitions of operators. We call this the general context. As can be visualized, there are
16 occurrences of the event X for the given history. It is not clear whether all these occurrences will
be useful in all applications. We strongly believe that an application would be interested in a subset
of these events that are meaningful to the semantics of that application. Furthermore, different
applications may be interested in different subsets. In the next section, we propose parameter
contexts as a way of imposing meaningful restrictions of the composite event history generated for
an event.



H = { {}, {{ 2}, {e}, {e


El[H]
E2[H]
E3[H]
E4[H]


{{et}, {e}}
{{e}, ,{e}}
{{e }, {el}}

{{e}, {e}}
fc41~~1









X = ((EiAE2); E3; (E2AE4))
X[H] = ((EiAE2); E3; (E2ZE4))[H]

= ((EIAE2)[H]; E3[H]; (E2E4)[H[H])[H
= (((EAE2)[H]; E3[H])[H]; (E2E4)[H])[H]


(EIAE2)[H] = {{el,},{,e I },{e, },{e, }}
(E2, E4)[H] = 4{e6, e},{e, e4, 4e 4}, ", {eJ 6}}

X[H] 4{{4e24eee ee ee ee { e1, 2 4
X[H] = { e, c3, e c ee, {e {e e 3, e ~, {ef 6, e1, ,e},
1 1 1 1 2,1},{ 1 1 1 2 1 22 3 2 1 2 2 2},
c 12, 1, 2 2, c 1,cc 23,c2, {e1 2, c 2,

{6e,e6,e6, e6, },{6e,6e ,6 6 6},{6,6,6,6,6 },{e,e,6,6, }}
12, 3 2 14 1 2 3 2 42 2 3 2 421 2 3 2 2,4
e2 c1 2, 1 21, e 2, c1, c3, c2, c 1, f c c c c 2, e c c c2, c 21


4 Composite Event Detection


Events can always be detected and parameters computed using the general context presented in
the previous section. However, the general context produces a large number of event occurrences
and not all occurrences may be meaningful from the point of view of an application. Moreover,
the computation and space overhead associated with the detection of events in this context can be
substantial.

In this section, we introduce parameter contexts for the purpose of reducing the space and
computation overhead associated with the detection of composite events and providing a mechanism
for choosing a meaningful subset of event occurrences generated by the general context. Parameter
contexts serve the purpose of detecting and computing the parameters of composite events in
different ways to match the semantics of classes of applications. Parameter contexts essentially
delimit the events detected, parameters computed, and accommodate a wide range of application
requirements. The choice of a parameter context also suggests the complexity of event detection
and storage requirements for a given application.

The detection of a composite event may require the detection of one or more constituent events
as well as one or more occurrences of a constituent event type. Events requiring multiple event
occurrences (either of the same type or of different types) for the detection of a composite event,
give rise to alternate ways of computing the history as well as parameters, as the events are likely
to occur over an interval.











The occurrence of any composite event X is marked by the occurrence of a constituent event
that makes the composite event occur (using the end-of event expression semantics). Recursive

application of this definition will yield a primitive event that marks the end of a given composite

event. This primitive event is termed the terminator of the composite event X. Several primitive
events can act as terminators, but there is at least one terminator event for a given composite event.

Analogously, there is always a primitive event that initiates the occurrence of a composite event.

This primitive event is termed the initiator of the composite event. There is at least one initiator

for a composite event but there could be more than one. For a primitive event the terminator is
the same as the initiator.

A sequence of primitive event occurrences (over a period of time) makes a composite event
occur. 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 X(E1, E2, - -, En) to represent an event expression X, where Ei5, i = l..n are
its constituent events. Consider the following event expressions:

A = Any(2,El, E2) ; E36 B = E1VE2VE3 and C = El; Any(2,E2, E3)

where El, E2, and E3 are primitive events. Event A is detected when at least one instance of

all 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. Both El and E2 can be initiators of A and E3 is the only

terminator. For C, El is the initiator and both E2 and E3 can be terminators. Figure 1 shows the
occurrences of different instances of event El, E2 and E3 as well as the event graph for A.


A


I I I I I I I I tim e
1 2 1 1 2 1 2 2
e e e e e e e e
1 1 2 3 2 4 3 4
S E3

El E2


Figure 1: Global event history

5E, and Ei have been used interchangeably from this point
6This is a constituent event of the composite event X used in the previous section.










4.1 Parameter Contexts


The parameter contexts proposed below are motivated by a careful analysis of several classes
of applications. We have identified four parameter contexts that are useful for a wide range of
applications. Below, we indicate the characteristics of the applications that motivated our choice
of parameter contexts:

1. Applications where the events are happening at a fast rate and multiple occurrences of the
same type of event only refine the previous data value. In other words, the effect of the
occurrence of several events of the same type is subsumed by the most recent occurrence.
This is typical of sensor applications (e.g., hospital monitoring, global position tracking,
multiple reminders for taking an action),

2. Applications where there is a correspondence between different types of events and their
occurrences and this correspondence needs to be maintained. Applications that exhibit causal
dependency (e.g., between aborts, rollbacks, and other operations; between bug reports and
releases; start of a transaction and its end) come under this category,

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, computing change of more than 211'. in DowJones average in any 2
hour period requires each change to initiate a new occurrence of an event. This corresponds
to the initiation of the detection of an event for each distinct occurrence, and

4. Applications where multiple occurrences of a constituent event needs to be grouped and used
in a meaningful way when the event occurs. For example, this context is useful in applications
where an event is terminated by a deadline-event and all occurrences of constituent events
are meaningful to that occurrence of the event.

We introduce the following contexts for the classes of applications described above. These
contexts are precisely defined using the notion of initiator and terminator events. We explain the
contexts using the composite event A which is a constituent event of the event X (example used in
the previous section). We are not concerned with the primitive occurrences el and e2 as primitive
event E4 is not part of the event expression of A. Note that the semantics of the various contexts
is the same for a primitive event.


Recent: In this context, only the most recent occurrence of the initiator for any event that
has started the detection of that event is used. When an event occurs, the event is detected
and all the occurrences of events that cannot be the initiators of that event in the future are










deleted (or flushed). For example, in the recent context, parameters of event A will include
the event instances {e e{, el} (A is detected when el occurs) and {e2, e2, e2} (when A is
detected again when e3 occurs). In this context, not all occurrences of a constituent event
will be used in detecting a composite event. Furthermore, an initiator of an event (primitive
or composite) will continue to initiate new event occurrences until a new initiator occurs.

Chronicle: In this context, for an event occurrence, the initiator, terminator pair is unique.
The oldest initiator is paired with the oldest terminator for each event (i.e., in chronological
order of occurrence). When X is detected, its parameters are computed by using the oldest
initiator and the oldest terminator of E. However, the constituent events of an event X cannot
occur in any other detection of the occurrence of E. For example, parameters of event A in
the chronicle context will be computed by using event instances {e{, e{ and e4}. When the
next E3 type event occurs at e2, then the A will be detected with the instances {e2, e2,e}.

Continuous: In this context, each initiator of an event starts the detection of that event.
A terminator event occurrence may detect one or more occurrences of the same event. This
context is especially useful for tracking trends of interest on a sliding time point governed by
the initiator event. In Figure 1, each of the occurrences el and e2 (as well as el and e2) would
start the detection of the event A. The first occurrence of A will have the instances {el, e{,
e3}. The second occurrence of A will consist of {e2, el, el}. In this context, an initiator will
be used at least once for detecting that event.

There is a subtle difference between the chronicle and the continuous contexts. In the former,
pairing of the initiator is with respect to the terminator of the event whereas in the latter
multiple initiators are paired with a single terminator of that event.

Cumulative: In this context, all occurrences of an event type are accumulated as instances
of that event until the event is detected. Whenever an event is detected, all the occurrences
that are used for detecting that event are deleted. For example, parameters of event A will
include all the instances of each event up to el when it occurs. The entire instances shown in
Figure 1 (except e2, and e ) is the set of occurrences that make the composite event A. Unlike
the continuous context, an event occurrence does not participate in two distinct occurrences
of the same event in the cumulative context.


Observe that the cumulative context described above cannot be generated as a subset of the
event-history generated by the general context. The notion of accumulation of event occurrences is
not present in the general context. For this reason, the definitions of A* and P* used the function
p which accumulates a set of event occurrences of a specific type over a given interval.




























n n n n I


n I


n n


n I


1
1

Recent

1.

2.

Chronicle

3. [

4.

Continuous

5. u

6.

7.

8.


Cumulative

9.


Figure 2: Illustration of
E2 A E4)


Time interval over which X is detected

Initiator I Terminator

Participating primitive events in the detection of X


Event detection in various contexts for the expression X = (El A E2 ; E3;


time


H H

H H HEI

H H H

H H H HEI





H H H HEI










Although contexts described above restrict the set of event occurrences generated, they are
based on the use of initiator, terminator pair in different ways. In addition to the above contexts,
it may be useful to detect composite events over non-overlapping time intervals. That is for any
two occurrences of an event X, the t_occ of the initiator is greater than the t_occ of the terminator
of the immediately preceding occurrence of X. This notion of the use of non-overlapping intervals
can be applied to any of the contexts described in this paper, including the general context. This
can be easily seen from the Figure 2. For instance, all events detected in recent, chronicle, and
continuous contexts are not disjoint. If disjoint detection of event occurrences were to be specified
for the example shown in Figure 2, only the first occurrences of events in each context (i.e, 1, 3, 5,
and 9) would be detected.

Based on the above definitions of contexts, several observations can be made. Disjoint contin-
uous context is the same as disjoint chronicle context. Also, cumulative context always generates
occurrences that satisfy the disjoint specification. In other words, disjoint cumulative context is
equivalent to cumulative context.


4.2 Illustration of Composite Event Detection

The approach taken for composite event detection in this paper is different from the approaches
taken in Ode and Samos. We use an event tree for each composite event and these trees are merged
to form an event graph for detecting a set of composite events. This will avoid the detection of com-
mon sub-events multiple times thereby reducing storage requirements. Primitive event occurrences
are injected at the leaves and flow upwards analogous to a data-flow computation. Furthermore,
the commonality of representation between event detection and query optimization using operator
trees allow us to combine both, and optimize a situation (event-condition pair) as a unit. This
is certainly possible in the relational model as transformations can be applied to push predicates
from conditions to and apply them during event detection as part of the optimization (in contrast,
event masks are specified in Ode by the user). Finally, the combination of event-condition trees
will allow conditions to be evaluated on a demand basis avoiding unnecessary computations. In
summary, our formulation of event detection readily lends itself to optimization techniques used in
databases.

The introduction of parameter contexts adds another perspective to the detection of composite
events. The appendix includes detailed illustration of each of the parameter contexts through an
example. From the example it is easier to understand how each parameter context detects different
instances of the same composite event for a given sequence of primitive event occurrences. In
this section we will use one event graph and discuss how we compute the constituent events of a
composite event for each of the parameter contexts. The time line indicates the relative order of









the primitive events with respect to their time of occurrences. All event propagations are done in
a bottom-up fashion. The leaves of the graphs have no storage and hence pass the primitive events
directly to their parent nodes. The operator nodes have separate storage for each of their children.
The graphs shown in Figure 3 for the various contexts are at a time point when primitive event e
is detected. The different instances of the same event are stored as separate entries and are shown
in separate lines in the figure. Since the leaves do not have any storage the primitive event e is
passed to the parent of leaf E4. The arrows pointing from the child node to its parent in the graph
indicates the detection and flow of the events. The event instances that will be deleted after this
instant of time are expressed in bold letters.

In the recent context {e, e} is sent to node A since eC and el are the most recent initiator
and terminator of the AND operator (node C). Since the terminator el can serve as an initiator for
node C (according to the semantics of AND), it is not discarded. At node A the initiator is already
present and {ef, e} serves as the terminator. So event E is detected with {e2 e, el, e ej}. Here
since the terminator cannot serve as the initiator it is discarded and only {e e{, el} which is the
most recent initiator of E is retained at node A.

In the case of Chronicle context, el is the oldest initiator of node C and it is at the head
of the initiator list. Hence e\ is paired with e{ and {e{, e} is passed to node A. Once they are
passed, unlike the recent context, both the initiator and the terminator are discarded. Hence node
C retains only e after AND is detected. Event E is detected with {e eI, e1, e, e4} at node A and
both {e e{, e} and {e, el} are deleted.

Continuous context involves lot of storage overhead for event detection. As in the chronicle
context we retain all the initiators signalled so far in each of the nodes. But unlike chronicle
context the terminator is paired with each of the initiators present and all the initiators are deleted
after the detection of the composite event. We retain the terminator only if it can serve as an
initiator for future detection of the composite event. At any point of time the terminator of the
composite event expression E in all the other contexts will signal only one occurrence of event E
whereas in the continuous context it will generate multiple occurrences of E. In our example eC, e2
are the initiators at node C. Both of them are paired with the e4 to generate two occurrences of the
AND at the same point of time namely {ef, C}, {ef, e}. Since el can serve as an initiator for node
C in the detection of a new occurrence of the constituent event, we retain it and both the initiators
eC, e2 that have been paired are deleted. At node A there are two initiators already present and
the two terminators signalled from node C lead to 4 instances of the detection of event E with the
same time of occurrence. Among the 4 contexts presented, continuous context generates a larger
subset of the event occurrences identified by the general case.

In the cumulative context, unlike the continuous context, all the initiator occurrences available


























I I I
2 1 1
e e e
1 2 3


E3 E2 E4


El E2


Recent context


Chronicle context


detect X


1 11
e e e
123
1 2 3
2 1 1
e e e
1 2 1


E3 E2 E4


El E2


El E2


Continuous context


Cumulative context


Figure 3: Event detection in various contexts


I I
2 1
e e
2 4


time











1 1
ele2 e3







1
e
4



E4


El E2










so far are combined with the terminator and only one occurrence of E is detected. In our example
e{, e are combined together as one initiator and {e{, e, el} is sent to parent node A. Similarly
node A detects E with {e{, e2, eI eI, e el}. Once detected the unified initiator and terminator
is discarded.


4.3 Storage Requirements

Parameter contexts introduced here simplify the event detection as well as the computation of
parameters as compared to the general context.

Some of the parameter contexts, such as continuous and chronicle, impose more storage require-
ments than the recent and cumulative contexts. The recent parameter context can be implemented
using a fixed size buffer for each event (i.e., at each node of the event graph). This is because
only the parameters for the most recent occurrence of an event is stored and hence requires the
least amount of storage. 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 require-
ments can be excessive implying that the choice of the parameter context for each rule needs to
be made judiciously. The cumulative context, unlike the continuous and chronicle contexts, com-
bines all initiators and hence at each node there is only one whole initiator combination. Though
continuous and chronicle both maintain a list of initiators, only continuous can signal more than
one occurrence of a composite event for a single terminator. Since this composite event might be
a constituent event of another larger expression, the continuous parameter context requires a lot
of storage compared to any other parameter context. The storage requirements can be excessive
for the cumulative context also. However, based on the semantics of the parameter contexts, the
storage requirement increases monotonically from recent to cumulative to chronicle to continuous
to general. This is because all the event occurrences used in the detection of a composite event
are deleted when the event is detected in the cumulative context whereas in the chronicle context,
initiator and terminator event occurrences are paired in the order of occurrences and hence more
events are stored for longer duration. Application of the disjoint modifier, on any context (except
the cumulative), further reduces the storage requirements by allowing events to be discarded earlier.


5 Architecture and Implementation


In this section, we analyze the requirements of a rule processing subsystem for an object-oriented
active DBMS and provide an architecture in terms of the functional modules interacting with a
composite event detector. Our implementation will use the Open OODB Toolkit (Alpha release










0.2) from Texas Instruments [18], Dallas as the underlying platform for adding composite event
detection and rule processing. In this paper, we are delimiting our discussion to the detection
and parameter computation of composite events and assume that primitive events are detected
by the underlying DBMS. Support for primitive events in Open OODB is discussed in [1]. Both
primitive and composite events can be signaled as soon they are detected. However, the detection
of a composite event may span a time interval as it involves the detection and grouping of its
constituent events in accordance with the parameter context specified. A clean separation of the
detection of primitive events (as an integral part of the database) from that of composite events
allows one to: i) implement a composite event detector as a separate module and ii) introduce
operators without having to change the detector of primitive events.

It is useful to examine the requirements of rule processing in active databases before presenting
an architecture. Broadly, the requirements are :


1. Support coupling modes: The immediate, deferred, and detached coupling modes introduced
in HiPAC [7] offer different semantics for the execution of the condition and action with
respect to the triggering application when an event is detected,

2. Support inter-application rules: In addition to rules based on events from within an appli-
cation, it is useful to allow composite events whose constituent events come from different
applications. This is especially useful for cooperative transactions and enterprise integra-
tion. This means that events have to be detected globally, spanning several applications that
provide constituent events,

3. Parameter computation: When a composite event is detected, the parameters need to be
collected and recorded by the event detector. Furthermore, these parameters need to be
passed on to the rule,

4. Multiple and nested rules: An event may potentially trigger several rules. Hence, it is nec-
essary to support a rule execution model that supports concurrent rule execution. Also, a
rule may signal events to the event detector triggering additional rules to an arbitrary level
of nesting, and finally,

5. The composite event detector needs to support detection of events dynamically as they happen
(as in active databases) or over a stored event-log.


The above requirements as well as the data model under consideration affect the design of both
the rule processing subsystem and the event detector. Below, the issues involved in each of the
above requirements are analyzed to derive the architecture presented.










Using our event specification language, we can readily model the deferred coupling mode as
an immediate coupling mode by using the sequence and cumulative operators. Hence, we need to
implement the immediate and detached coupling modes only. The detached independent coupling
mode requires that a new transaction be started for rule execution. This has severe ramifications
in the object-oriented model where the rule's condition and action could be arbitrary functions
requiring the specification of all classes. Unlike the relational model, creating an independent
transaction for a rule, in the object-oriented case, may be limited by the environment (e.g., objective
C vs. C++). The causally dependent detached mode has an abort dependency between the
triggering transaction and the rule's execution. The rule's execution has to be aborted if the
triggering transaction is aborted. This can be accomplished by using events that span applications,
i.e., by using the inter-application rules mentioned above. Each transaction can signal a pre-commit
and abort event which can be used by the global event detector to enforce abort dependencies
between two top-level transactions.

Supporting inter-application rules requires not only the detection of global events spanning
several applications, but also dealing with address space issues. In the relational model, it is
easier to handle this as the data dictionary has the types of all objects and furthermore attributes
values are atomic. In the object-oriented model, inter-operability across applications is extremely
complicated on account of the component objects, pointers, and virtual functions. These issues are
currently being addressed by OMG and Corba [17]. For our purposes, we are assuming that only
the event type and atomic values are passed by value across address spaces. The interpretation of
the parameters is left to the application executing the rule. Of course, shared database objects can
be accessed as part of the rule evaluation.

Parameter computation for composite objects raises additional problems in the object-oriented
framework. The lack of a single data structure (such as a relation) makes it extremely difficult
to identify and manage parameter computation. As a first cut, we are including the identification
of the object (i.e., oid) as one of the event parameters and other atomic values. However, no
assumptions are made about the state of the object (when the oid is passed as part of a composite
event) as the detection of a composite event is over a time interval.

Support for multiple rule execution and nested rule execution entails that the event detector
be able to receive events detected within a rule's execution in the same manner it receives events
detected in a top level transaction. This can be accomplished relatively easily by separating the
event detection from the application as detailed in the architecture proposed below. Finally, support
for both dynamic and after-the-fact detection of composite events can be accomplished using the
same mechanism used for supporting nested rule execution.










5.1 Proposed Architecture


In order to satisfy the above requirements in an object-oriented framework, we propose the archi-
tecture shown in Figure 4 which is being refined to extend the Open OODB Toolkit developed at
Texas Instruments. Our proposed architecture relies on the use of threads (or a light weight pro-
cesses) for separating event detection from application execution in a transparent manner. Threads
offer the following advantages in contrast to a separate process: 1) threads communicate via shared
memory rather than a file system, thus allowing applications to share the same address space, 2)
the overhead involved in creating threads is low, and 3) it is easy to control the scheduling and
communication of threads. Each application will have a composite event detector implemented as
a thread (a local event detector) In addition each application will have a thread that handles the
execution of rules whose events span applications (a global event-handler thread). Each primitive
event is sent to the local event detector and the application waits for the signaling of a composite
event that is detected in the immediate mode. For multiple rule execution, a number of nested
sub-transaction are spawned as part of the application process (see [2] for details of nested trans-
action support using threads). For detached execution of rules, a separate application is started
with the rule as the body of a top-level transaction. For detached mode with causal dependency,
an inter-application event is created to be detected by the global event detector. This is used to
enforce the abort dependency between the two top-level transactions. These are highlighted in
Figure 4 by indicating control and data flow.

The architecture presented in this paper offers the following features. There is a clean separation
between the events detected by the local and global event detectors, and events detected by the
system. All primitive events are detected by the system (as they have to be embedded within the
system, and explicit events are detected by the application and signaled to the local event detector).
Other events are detected by the local and global event detectors. As the event detector can receive
event occurrences either dynamically or statically (e.g., from a file), it can be used for after-the-fact
analysis of events as well as part of an active database. Furthermore, this approach will allow one
to extend the event specification language without having to change the primitive events detected
by the underlying system.

Immediate and deferred rule execution take place in the same address space as that of the
triggering transaction. Furthermore, rules (executed as subtransactions) continue to communicate
with the same local event detector thereby supporting nested rule execution. The order of rule
execution can be controlled by assigning appropriate priorities to each thread. Detached rule
execution is done in a separate address space with the assumption that all class specifications are
available in the new address space. Also, the abort dependency is enforced through the detection











Global Event Detector


Figure 4: Local and Global Event Detector Architecture


of events spanning applications. The global event detector communicates with the local event

detectors for receiving events detected locally and with the application's global event handler for

signaling the detection of global events for executing tasks based on global events. Again there is

a clean separation between the events detected by the local event detector and the global event

detector.

Finally, as the local event detector and the application share the same address space and our

event detection uses an event graph similar to operator trees, it is possible to combine rule evaluation

with event detection (when the coupling mode permits) and perform optimize the entire tree as a

whole.



6 Conclusions


In this paper, we have presented an expressive event specification language that supports database,

temporal, external, and composite events. We have precisely defined the semantics of each operator

and its detection over a global event-history. We have introduced parameter contexts to contain

the problem of composite event detection to a meaningful subset of a potentially very large set.

Finally, we have illustrated the detection of composite events in various contexts and proposed an


I I I end end IL
Local Event Transaction Transaction Local Event
Detector Application 1 Application N Detector

1- Primitive Event signaled 2 Composite event detection for immediate rules
3 pre-commit and abort signaled 4 Causally dependent commit signaled
5- Inter-application events detected 6 Rules executed as subtransactions










architecture for its implementation in an object-oriented framework along with a discussion of the
various issues involved. Algorithms for all parameter contexts (including the general context) have
been developed as shown in Appendix B. Currently, these algorithms are being implemented using
the architecture shown in this paper. Although the event specification language is presented in
the context of an active database, this language along with the parameter contexts detailed in this
paper can be adapted for other event-driven applications, such as robotics, planning, and trend
analysis.

Finally, in this paper, we are assuming that the parameters of an event can be computed once
the event occurrences are known. It is useful, however, to explicitly introduce (as a minimum)
the identification of the object (i.e., oid) for which the primitive event is applicable. This can
be done by specifying, for each primitive event, a parameter which is either a constant or a vari-
able representing the oid. For example, the primitive event Change_price(IBM) indicates that the
event occurs when the method Change_price is executed for the IBM object. As another example,
Change_price(X);Change_price(X) refers to the sequence of events on the same oid X. And finally,
Change_price(X);Change_price(Y) refers to the sequence of events on two different oid's. Detailed
discussion of parameter computations are beyond the scope of this paper. Some of these issues
have been discussed in section 5. All the event detection algorithms presented in this paper extend
readily when the oid is allowed as an explicit parameter of a primitive event.


References

[1] E. Anwar, L. Maugis, and S. Chakravarthy. A New Perspective on Rule Support for Object-Oriented
Databases. In Proceedings, International Conference on Management of Data, pages 99-108, Washing-
ton, D.C., May 1993.
[2] R. Badani. Nested transactions for concurrent execution of rules: Design and implementation. Master's
thesis, Database Systems R&D Center, CIS Department, University of Florida, E470-CSE, Gainesville,
FL 32611, October 1993.
[3] 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,
Aug. 1989.
[4] S. Chakravarthy and D. Mishra. An event specification language (snoop) for active databases and its
detection. Technical Report UF-CIS TR-91-23, University of Florida, E470-CSE, Gainesville, FL 32611,
Sep. 1991.
[5] S. Chakravarthy and D. Mishra. Snoop: An expressive event specification language for active databases.
Technical Report UF-CIS-TR-93-007, University of Florida, E470-CSE, Gainesville, FL 32611, March
1993. (Revised and extended version of UF-CIS-TR-91-23; Submitted for publication.).
[6] S. Chakravarthy and D. Mishra. Towards an expressive event specification language for active databases.
In Proc. of the 5th International Hong Kong Computer Society Database Workshop on Next generation
Database Systems, Kowloon Shangri-La, Hong Kong, February 1994. (Invited Paper).










[7] U. Dayal, M. Hsu, and R. Ladin. A transaction model for long-running activities. In Proceedings 17th
International Conference on Very Large Data Bases, pages 103-112, Barcelona (Catalonia, Spain), Sept.
1991.
[8] C. L. Forgy. RETE: A Fast Algorithm for the Many Pattern/\I N- Object Pattern Matching Problem.
Artificial Intelligence 19, pages 17-37, 1982.
[9] C. L. Forgy and J. McDermott. Domain-Independent Production System Language. In Proceedings
Fifth International Conference on Artificial Intelligence, Cambridge, MA, 1 I7.
[10] 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.
[11] S. Gatziu and K. R. Dittrich. Detecting composite events in active databases using petri nets. In Proc.
of the 4th International Workshop on Research Issues in data Engineering: Active Database Systems,
February 1994. (To Appear).
[12] 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),
Sep. 1991.
[13] N. H. Gehani, H. V. Jagadish, and O. Shmueli. COMPOSE A System For Composite Event Specification
and Detection. Technical report, AT&T Bell Laboratories, Murray Hill, NJ, December 1992.
[14] 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
1992.
[15] 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.
1991.
[16] A. Prasad Sistla and O. Wolfson. Temporal Triggers in Active Databases. Technical report, University
of Illinois at Chicago, Chicago, IL, July 1992.
[17] S. Vinoski. Distributed object computing with corba. C++ Report, pages 33-38, July-August 1993.
[18] D. Wells, J. A. Blakeley, and C. W. Thompson. Architecture of an open object-oriented database
management system. IEEE Computer, 25(10), October 1992.
[19] J. Widom and S. Finkelstein. Set-Oriented Production Rules in Relational Database Systems. In Proc.
of AC i1- [, iOD, pages '.",'* 270, May 1990.










Appendix A. Details of Event Detection


In this appendix, we illustrate the event detection algorithms on the event expression X = ((El
A E2) ; E3 ; (E2 A E4)) shown in the body of the paper. The time line indicates the relative
order of the primitive events with respect to their time of occurrences. Events are propagated in
a bottom-up fashion. The sequence of the graphs are from left to right and top to bottom. Leaf
nodes of the graph correspond to primitive events and pass the events as they occur to their parent
nodes. The operator nodes have separate storage for each of their children. The different instances
of the same event are stored as separate entries and are given in separate lines in the figure. A small
arrow indicates the primitive event detected at that point of time. The arrows pointing from the
child to its parent in the graph indicates the detection of a composite event and flow of the detected
events. The event instances that are deleted after a composite event is detected and propagated
are indicated in bold letters. A walk-through example of each context on a single graph instance
has been discussed in the body of the paper.
The detection of the composite event X in recent context is shown in Figure 5. The detection
of the same event X in chronicle context is shown in Figure 6. Figures 7 and 8 show the detection
of the composite event X in continuous and cumulative contexts, respectively.










Appendix B: Composite Event Detection Algorithms

Assumptions

All complex events are represented as a tree.

The leaves are primitive events.

The nodes of the tree are event operators.

The leaves of the tree have no memory.

There is a function "FLUSH" which will release all the memory held by a complex event tree.
Operator trees for all event operators are shown in Figure 9.

Primitive event parameters include

Time of occurrence (t_occ)

Event name

Method name

Parameter values passed to the method

Object ID

Transaction ID

Database operation performed

The first two parameters are mandatory and the rest depends on the type of primitive event
and/or the application involved.


Parameter Contexts The algorithms given below cover these parameter contexts

Recent

Chronicle

Continuous

Cumulative

We can apply the restriction of DISJOINT complex event detection to each of the parameter
contexts. Each of these parameter contexts are discussed in detail in the previous sections. The
appendix includes detailed illustration of each of the parameter contexts through an example.
NOTE: P & A and P* & A* are the same in all parameter contexts if we assume a primitive
event is generated at every time [t] specified in the event expression.










ALGORITHM Composite Event Detection


Construct an event graph for each rule with nodes as operators and
primitive events. The primitive event nodes are source and the rule nodes
are sinks. Edges are from constituent events to composite event.

Initialize counters (e.g., num_events) and flags.

For each occurrence of a primitive event
store its parameter in the corresponding terminal node 't';
activate_terminal_node(t);

PROCEDURE activate_terminal_node(n)
For all rule-ids attached to the node n'
signal event;
For all outgoing edges i from 'n'
propagate parameters in node 'n' to the nodei connected by edge i
activate_operatornode(node;);
Delete propagated entries in the parameter list at n'



PROCEDURE activate_operatormode(node;) /* Recent Context */
/* a primitive or composite event is signalled to node; */


CASE nodei is of type
AND(E1, E2):


OR(E1, E2):

ANY(m,E1,E2,...,En):










SEQ(E1, E2):


if left event el is signalled
if E2's list is not empty
Pass to the parent
Replace el in El's list.

if right event e2 is signalled
if El's list is not empty
Pass to the parent
Replace e2 in E2's list


For any event signalled Pass to the parent

When an event ek is signalled
Replace ek in it's event list Ek.
Increment the counter num_events only if Ek list was empty previously
if num_events >= m
Find all event tuples (taken from their respective event lists)
such that
they are the most recent m distinct occurrences of events.
Pass the tuple to the parent; change num_events appropriately

if left event el is signalled










Replace el in El's list


if right event e2 is signalled
if El list is not empty
Pass to parent


if left event el is signalled
Replace el (only t_occ & event name) in El's list


if middle event e2 is signalled
if El's list is not empty
Pass to parent

if right event e3 is signalled
FLUSH El's buffer


A*(E1,E2,E3)|P*(E1,[t],E3)


if left event el is signalled
Replace el (t_occ & event name) in El's list
FLUSH E2's buffer


if middle event e2 is signalled
if El's list is not empty
Append e2 to E2's list

if right event e3 is signalled
if E2's list is not empty
Pass to parent
FLUSH El and E2's buffers
else
Pass to parent
FLUSH El's buffer


NOT(E2)[E1, E3):


if left event el is signalled
Replace el (only t_occ & event name) in El's list


if middle event e2 is signalled
if El's list is not empty
FLUSH El's buffer

if right event e3 is signalled
if El's list is not empty
Pass to parent
FLUSH El's buffer


At] 1 ,E2 E3)jP(EI,[t],E;3):










PROCEDURE activate_operatormode(node;) /* Chronicle Context */
/* a primitive or composite event is signalled to node; */


CASE nodei is of type
AND(E1, E2):


OR(E1, E2):

ANY(m,E1,E2,...,En):











SEQ(E1, E2):


A(E1,E2,E3)|P(E1,[t[,E3):


if left event el is signalled
if E2's list is not empty
Pass to the parent
Delete head of E2's list
else
Append el to El's list

if right event e2 is signalled
if El's list is not empty
Pass to the parent
Delete head of El's list
else
Append e2 to E2's list


For any event signalled Pass to the parent

When an event ek is signalled
Append ek in it's event list Ek.
Increment the counter num_events only if Ek list was empty previously
if numevents L= m
Find all event tuples (taken from their respective event lists)
such that
they are the oldest (head) m distinct occurrences of events
Pass the tuple to the parent and delete them from
their respective event lists; change num_events appropriately

if left event el is signalled
Append el to El's list

if right event e2 is signalled
if El list is not empty
Pass to parent
Delete head of El's list


if left event el is signalled
Append el (only t_occ & event name) to El's list


if middle event e2 is signalled
if El's list is not empty
Pass to parent
Delete head of El's list

if right event e3 is signalled










FLUSH El's buffer


A*(E1, E2, E3)|P*(El,[t],E3)rf left event el is signalled
Append el (t_occ & event name) to El's list

if middle event e2 is signalled
if El's list is not empty
Append e2 to E2's list

if right event e3 is signalled
if E2's list is not empty
Pass to parent
Delete head of El's list
Delete all e2's in E2's list whose t_occ
is less than the El's head t_occ
If El's list is empty FLUSH E2's buffer
else
Pass to parent
Delete head of El's list

NOT(E2)[E1, E3): if left event el is signalled
Append el (only t_occ & event name) to El's list

if middle event e2 is signalled
if El's list is not empty
FLUSH El's buffer

if right event e3 is signalled
if El's list is not empty
pass to parent
Delete head of El's list










PROCEDURE activate_operatormode(node;) /* Continuous Context */
/* a primitive or composite event is signalled to node; */


CASE nodei is of type
AND(E1, E2):


OR(E1, E2):


if left event el is signalled
if E2's list is not empty
For every event e2 in E2's list
Pass to the parent
FLUSH E2's list
else
Append el to El's list

if right event e2 is signalled
if El's list is not empty
For every event el in El's list
Pass to the parent
FLUSH El's list
else
Append e2 to E2's list

For any event signalled Pass

When an event ek is signalled
Append ek in it's event list Ek.
Increment the counter num_events only if Ek list was empty previously
if num_events = m
Find all event tuples (taken from their respective event lists)
such that
they form m distinct occurrences of events
Pass the tuple to the parent
FLUSH all El, E2, ..., En buffers; Set num_events to 0


SEQ(E1, E2):


if left event el is signalled
Append el to El's list


if right event e2 is signalled
if El list is not empty
For every event el in El's list
Pass to parent
FLUSH El's list


if left event el is signalled
Append el (only t_occ & event name) to El's list


if middle event e2 is signalled
if El's list is not empty
For every event el in El's list


ANY(m, El, E2, ..., En):


At] 1 ,E2 E3)jP(E1,[t],E;3):










Pass to parent


if right event e3 is signalled
FLUSH El's list

A*(E1, E2, E3)|P*(El,[t],E3)rf left event el is signalled
Append el (t_occ & event name) to El's list

if middle event e2 is signalled
if El's list is not empty
Append e2 to E2's list

if right event e3 is signalled
if E2's list is not empty
For each el in El's list
Pass to p;
FLUSH El's and E2's buffers
else
For each el in El's list
Pass to parent
FLUSH El's buffers

case NOT(E2)[E1, E3):
if left event el is signalled
Append el (only t_occ & event name) to El's list

if middle event e2 is signalled
if El's list is not empty
FLUSH El's buffer

if right event e3 is signalled
if El's list is not empty
For each el in El's list
Pass to parent
FLUSH El's buffer










PROCEDURE activate_operatormode(node;) /* Cumulative Context */
/* a primitive or composite event is signalled to node; */


CASE nodei is of type
AND(E1, E2):


OR(E1, E2):

ANY(m, El, E2, ..., En):











SEQ(E1, E2):


if left event el is signalled
if E2's list is not empty
Pass to the parent
FLUSH E2's buffer
else
Append el to El's list

if right event e2 is signalled
if El's list is not empty
Pass to the parent
FLUSH El's buffer
else
Append e2 to E2's list


For any event signalled Pass
When an event ek is signalled
Append ek in it's event list Ek.
Increment the counter num_events only if Ek list was empty previously
if num events = m
Find all event tuples (taken from their respective event lists)
such that
they are the m distinct occurrences of events
Pass the tuple to the parent and
FLUSH all El, E2, ... En buffers; Set num_events to 0

if left event el is signalled
Append el to El's list

if right event e2 is signalled
if El list is not empty
Passto parent
FLUSH El's buffer


if left event el is signalled
if El's list is empty
Store el (only t_occ & event name) in El's list


if middle event e2 is signalled
if El's list is not empty
Pass to parent
FLUSH El's buffer


A(El, E2, E3)IP(Et,[t],E3):










if right event e3 is signalled
FLUSH El's buffer

A*(E1,E2,E3)|P*(E1,[t],E3): if left event el is signalled
if El's list is not empty
Store el (t_occ & event name) in El's list

if middle event e2 is signalled
if El's list is not empty
Append e2 to E2's list

if right event e3 is signalled
if E2's list is not empty
Pass to parent
FLUSH El and E2's buffer
else
Pass to parent
FLUSH El's buffer

NOT(E2)[E1, E3]: if left event el is signalled
if El's list is not empty
Store el (t_occ & event name) in El's list

if middle event e2 is signalled
if El's list is not empty
FLUSH El's buffer

if right event e3 is signalled
if El's list is not empty
Pass to parent
FLUSH El's buffer
























I I I
2 1 1
e e e
1 2 3


I I
2 1
e e
2 4


E3 E2 E4


El E2


E 2 E3 E2



El E2


time


A E3 E2



El E2
e,


E3 E2 E4


El E2


detect X

I 1


E3 E2 E4


El E2


E3 E2 E4


El E2


Figure 5: Detection of X in recent mode


E3 E2 E4


El E2


E3 E2 E4


El E2


E3 E2 E4


El E2

























I I I
2 1 1
e e e
1 2 3


E3 E2 E4


El E2


El E2


Figure 6: Detection of X in chronicle mode


I I
2 1
e e
2 4


time


El E2


E3 E2 E4


El E2


El E2


El E2


E3 E2 E4


El E2


























I I I
2 1 1
e e e
1 2 3


E3 E2 E4


El E2


E3 E2 E4


I I
2 1
e e
2 4


E3 E2 E4


\2 E3 E2



El E2


e/ 2 E3 E2



El E2
17


E3 E2 E4


El E2


E3 E2 E4


Figure 7: Detection of X in continuous mode


time


E3 E2 E4


El E2


El E2


1 11
e e e
123
1 2 3
2 1 1
1 2 3


El E2


El E2


E3 E2 E4


El E2

























I I I
2 1 1
e e e
1 2 3


E3 E2 E4


E3 E2 E4


El E2


E3 E2 E4


El E2


E3 E2 E4


A 2 E3 E2 E4



El E2


E3 E2 E4


El E2


Figure 8: Detection of X in cumulative mode


I I
2 1
e e
2 4


time


El E2


El E2


El E2


E3 E2 E4


El E2

















Operator Trees


Figure 9: Operator trees




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs