real-time event control in active databases

Real-time event control in active databases

Lars Bñkgaard a,*, Jens Christian Godskesen b,1

a Department of Information Science, The Aarhus School of Business, Fuglesangs Alle 4, DK-8210 Aarhus V, Denmarkb Roskilde Business College, Bakkesvinget 67, DK-4000 Roskilde, Denmark

Received 1 July 1997; received in revised form 1 November 1997; accepted 1 January 1998

Abstract

Most existing languages for the speci®cation of active rules are based on the ECA (event-condition-action) paradigm. Usually,

rules speci®ed by such languages are triggered by simple events like the update of a tuple in a relational database. We present a

speci®cation language that can be used to specify real-time triggering conditions in terms of complex event patterns. Our speci®ca-

tion language can be used to formulate complex, triggering conditions for active rules in terms of event patterns that involve se-

quences, alternations, iterations, and parallel compositions. Also, the language can be used to specify soft, real-time constraints

with respect to the minimum/maximum time required/allowed between pairs of events. Our language is designed to be ¯exible

and general in the sense that it can be combined with most ECA rule languages. We formally de®ne the syntax and semantics of

the language and we illustrate its use by means of examples. Ó 1998 Elsevier Science Inc. All rights reserved.

Keywords: Active rules; Real-time constraints; Event patterns; Event control

1. Introduction

Database design is a totality of structural and behav-ioral design. Traditionally, database behavior has beenspeci®ed in terms of update transactions (Brodie andRidjanovic, 1984), (Ceri et al., 1981). The emergenceof object-oriented data models and object-oriented data-bases has enabled a tightly coupled design of structureand behavior in terms of encapsulated objects (Kim,1995). The notion of active rules (or triggers) has at-tracted much research attention within the area of activedatabases (Dayal et al., 1995; Zaniolo et al., 1997).

Most languages for the speci®cation of active rulesare based on the ECA (event-condition-action) para-digm. An ECA rule is triggered by the occurrence ofan event of a speci®ed type and if the condition evalu-ates to true the action part is executed. Usually, the con-dition can be speci®ed in terms of an arbitrarily complexdatabase query. Typically, an active rule is triggered bythe occurrence of a simple event like the update of a tu-ple in a relational database or the invocation of a meth-od in an object-oriented database.

We present a language that can be used to specifycomplex, real-time triggering event patterns. Our majorcontributions are as follows.

First, our speci®cation language is a new real-timeCCS-like language (Milner, 1989) based on a languagecalled TCCS (Wang, 1990). Our language facilitatesthe synchronization of multiple objects whereas TCCSfacilitates the synchronization of object pairs only. Con-sequently, our language is well suited to model databaseevents like transactions and triggering events that in-volve multiple database objects. We de®ne the syntaxand semantics of our language and we illustrate its useby means of speci®cation examples.

Second, our language can be used to specify complextriggering event patterns. We specify such patterns interms of sequences, alternations, iterations, and parallelcompositions.

Third, our language can be used to specify soft real-time constraints on events in active databases. Our lan-guage can be used to formulate a combination of theminimum/maximum time required/allowed betweenevents (Dasarathy, 1985). Our language supports thespeci®cation of soft real-time constraints, i.e., con-straints that should be satis®ed but that may be violated.Also, the language supports the speci®cation of the ac-tion taken when a soft constraint is violated.

The Journal of Systems and Software 42 (1998) 263±271

* Corresponding author. Tel.: +45 8948 6695; fax: +45 8615 3992; e-

mail: [email protected] Tel.: +45 4635 5651; e-mail: [email protected].

0164-1212/98/$19.00 Ó 1998 Elsevier Science Inc. All rights reserved.

PII: S 0 1 6 4 - 1 2 1 2 ( 9 8 ) 1 0 0 1 4 - 6

Fourth, our language can be integrated with most ex-isting active rule languages because our event patternspeci®cations are separated from the active rule speci®-cations. Alternatively, we could have designed a new ac-tive rule language that itself supports the speci®cation ofcomplex triggering event patterns as an integrated partof ECA rules. However, such an approach would havedecreased the generality of our speci®cation language.

Our speci®cation language can be viewed as a lan-guage for the event-based speci®cation of dynamic data-base constraints. Most existing dynamic constraintspeci®cation approaches support the speci®cation ofstate-based constraints (Castilho et al., 1982; Cervasatoand Eick, 1992; Chomicki, 1992; Ehrick et al., 1984;Kung, 1985; Lipeck, 1986; Lipeck and Saake, 1987;Wieringa et al., 1989; Yang and Henschen, 1992; MuÈckand Vinek, 1989; Martin et al., 1992). A few languagesfor the speci®cation of event-based, dynamic constraintshave been proposed (Bñkgaard and Godskesen, 1995;Bñkgaard, 1997a, b; Kappel and Schre¯, 1991) but toour knowledge no such language has been customizedto the speci®cation of complex, real-time triggering con-ditions for ECA rules.

The paper is structured as follows. In Section 2 wedescribe the computational model on which our work isbased and we give an informal introduction to our speci-®cation language. In Section 3 we describe the syntaxand semantics of our speci®cation language. In Section 4we illustrate the use of the speci®cation language bymeans of an example. Finally, in Section 5 we concludethe paper and suggest directions for future research.

2. Objects, events, and active rules

In this section we give an informal presentation of alanguage for the speci®cation of complex, real-time trig-gering event patterns and we describe the underlying no-tions of database objects, events, and event-triggeredactive rules. In Section 3 we present the syntax and for-mal semantics of our language.

We assume that each database object has an immuta-ble and globally unique object identi®er and that eachdatabase object belongs to one or more named objectclasses. We do not make any assumptions about thestructural and dynamic characteristics of database ob-jects.

An event occurs at a speci®c point in time and it is anatomic occurrence of an event type that has the follow-ing form.

EventName�Parameter1:Class1; . . . ;Parametern:

Classn�For example, a Borrow event type may be de®ned by

the following expression where X and Y are formalparameters.

Borrow�X:Borrower;Y:Book�A Borrow event may be de®ned by the following ex-

pression where the actual parameters, o1 and o2, are ob-ject identi®ers.

Borrow�o1:Borrower;o2:Book�This Borrow event models the fact that the Borrowerobject with identi®er o1 and the Book object with iden-ti®er o2 have participated in a Borrow event. The classnames are included in event expressions because an ob-ject may belong to multiple classes. For example, aBorrower object may also be an Employee object.

In general, ECA rules have the following form.

Intuitively, the semantics of an active rule are as follows.When an event of the type speci®ed in the ON part occursthe rule is ®red. If the condition speci®ed in the IF partevaluates to true the action speci®ed in the THEN part isexecuted. Active rule semantics have been de®ned for re-lational models and for object-oriented models (Widomand Ceri, 1996).

In this paper we assume that active rules have the fol-lowing form.

Such a rule is triggered by the occurrence of an event ofthe type speci®ed in the ON part. If the condition speci-®ed in the IF part evaluates to true the speci®ed eventsequence is executed. Free variables in <condition>and <event sequence> are bound to parameters in<event type> or to the database schema.

The following rule implements an integrity constraintsaying that no employee can have a salary greater than200. The rule is triggered by a SetSalary event andwhenever the rule is ®red a SetSalary event and aPrint event occur.

The following rule prints a warning if a book is not re-turned within 30 days. We assume that the underlyingdatabase is a relational database.

ON <event>IF <condition>THEN <action>

ON <event type>

IF <condition>THEN <event sequence>

Rule 1 Salary check

ON SetSalary(Emp:Employee,Amount:In-

teger)

IF Amount > 200

THEN SetSalary(Emp,200)

Print(``The Employee'', Emp.Name,

``was assigned a high salary'',

Amount)

264 L. Bñkgaard, J.C. Godskesen / The Journal of Systems and Software 42 (1998) 263±271

The rule is triggered by the time event NewDay( ) ± anautomatically executed time event that occurs once aday. NOW is a function that returns the current time.The IF condition evaluates to true if and only if the an-swer set of the SQL query is not empty. The THEN eventis executed once for each tuple in the answer set.

In systems with large collections of active rules it maybe necessary and desirable to constrain the occurrencesof triggering events. We have designed a speci®cationlanguage that supports the speci®cation of such con-straints in terms of legal event patterns. The language fa-cilitates the speci®cation of complex triggering patterns.

Fig. 1 illustrates the basic event control function. Anevent request is valid if and only if there is a matchingevent enabler. In Fig. 1 the event control responds tothe event request Borrow?(. . .) by means of the eventenabler Borrow!(. . .).

The following example illustrates the use of our spec-i®cation language. It de®nes the legal behavior of a sim-ple library with one borrower and one book. We assumethat the Borrower and Book objects participate inBorrow and Return events and that the Book objectparticipates in Late events whenever it is not returnedin a timely fashion.

The behavior of each object is de®ned by a lifelongprocess that de®nes its role in the library. A dot (.) spec-i®es pre®xing (sequencing), a plus (+) speci®es non-de-terministic choice, and a vertical bar (j) speci®esparallel composition.

Environment ºBorrow?(x:Borrower,y:Book).Environ-

ment +

Return?(x:Borrower,y:Book).Environ-

ment

Late?(y:Book,30:Integer)).Environ-

ment

Borrower[x] ºBorrowx.Borrower[x] + Returnx.Borrow-

er[x]

Book[y] ºBorrowy.(Returny.Book[y] +

e(30).s.Late! (y: Book,30: Inte-

ger).Returny.Book[y])

Library º(Book[x] j Borrower[y] j Environment)

Library is a process that is de®ned as the parallelcomposition of the processes Environment, Borrow-er[x], and Book[y].

The process Environment is not part of the eventcontrol mechanism. Environment models the event re-quests of for example users, transactions, and activerules. Intuitively, Environment is continuously askingif one of the following events are enabled.

Borrow(x:Borrower,y:Book)

Return(x:Borrower,y:Book)

Late(y:Book,30:Integer)

The event control mechanism (see Fig. 1) is de®ned bythe expression (Book[x]jBorrower[y]), i.e., the par-allel composition of Borrower[x] and Book[y].

The process Borrower[x] de®nes the legal behav-ior of the Borrower object with object identi®er x.There is one such process for each Borrower object.The Borrower object x can participate in any sequenceof the simple events Borrowx and Returnx. A simpleevent represents the participation of one object in oneevent. For example, an execution of Borrowx representsthe participation of the Borrower object with identi®erx in a Borrow event.

The process Book[y] de®nes the legal behavior ofthe Book object with object identi®er y. There is onesuch process for each Book object. The Book objectwith identi®er y can participate in an alternating se-quence of the events Borrowy and Returny. The ®rstevent in such a sequence must be Borrowy.

Event enablers can be viewed as synchronizationpoints for simple events. For example, the event enablerReturn!(x:Borrower,y:Book) represents a syn-chronization point for Returnx and Returny. Thatis, the participation of the Borrower object with iden-ti®er x and the Book object with identi®er y in a Re-

turn event creates the event enablerReturn!(x:Borrower,y:Book) that will synchro-nize with the event request Return?(x:Borrow-

er,y:Book).Consequently, the composite events in the library

must occur as an alternating sequence of the followingevents.

Rule 2 Late books

ON NewDay( )

IF SELECT *

FROM Loan

WHERE (NOW - Loan.Date > 30)

THEN Print(``The book'', Loan.Book.Ti-

tle, ``has not been returned within

30 days.'')

Fig. 1. Event control.

L. Bñkgaard, J.C. Godskesen / The Journal of Systems and Software 42 (1998) 263±271 265

Borrow(x:Borrower,y:Book)

Return(x:Borrower,y:Book)

The ®rst event must be Borrow(x:Borrow-

er,y:Book). In between Late(y:Book,30:Inte-

ger) events will occur whenever a Book object hasnot participated in a Return event within 30 days afterits participation in a Borrow event.

The Book[y] process illustrates the real-time aspectof our language. The symbol e(30) denotes a delay eventthat delays the process Book for the object y for 30 timeunits (days). If a book has not been returned after 30days the s event forces Late(y:Book,30:Integer)to be enabled for the Book object y. The following ruleis triggered by the event Late and it prints a warningabout a book that has not been returned in a timelyfashion.

In general, triggering events can occur as a conse-quence of system events, user actions, transactions,and rule ®ring.

As indicated by Fig. 2 event requests from the THENparts of active rules are checked like all other events re-quests. The event control mechanism is speci®ed bymeans of our speci®cation language as illustrated inthe library example. In Section 3 we present the syntaxand formal semantics of our language.

3. Event patterns

In this section we present the syntax and semantics ofa language that supports the speci®cation of complex,real-time constraints and triggering conditions in termsof complex event patterns.

3.1. Syntax and informal semantics

In this section we de®ne the syntax and give an infor-mal presentation of the semantics of our speci®cation

language. The formal semantics are de®ned in the fol-lowing subsection by associating an operational inter-pretation to each expression of the language.

The syntax of the language is de®ned as follows. As-sume a set E of event names ranged over by a and let s bea distinct symbol not present in E. Assume a set of pro-cess names P ranged over by P. Finally, assume a set O

of object class names ranged over by X and assume a setI of object identi®ers ranged over by o.

De®ne the set of simple events A to be {aoja 2 E,o 2 I} [ {s}. An example of simple events are Borrowx

and Returnx which can be performed by the Borrow-er[x] process that we speci®ed in Section 2.

For all non-negative integers n, let Cn, the set of com-posite events of arity n, be:

fa?�o1: X1; . . . ; on: Xn�; a!�o1: X1; . . . ; on: Xn�ja 2 E; oj 2 I;

Xj 2 O; j � 1; . . . ; ngWe let the set of all composite events C be the union ofall Cn. Let a range over the set of events A [ C. Eventson the form a?�o1: X1; . . . ; on: Xn) are called event requestsand events on the form a!(o1: X1; . . . ; on: Xn) are calledevent enablers. We say that an event requesta?(o1: X1; . . . ; on: Xn) and its corresponding event enablera!(o1: X1; . . . ; on: Xn) are complementary.

Intuitively, an event request represents the request foran interaction between one or more objects. For in-stance, Borrow?(x:Borrower,y:Book) is an re-quest for object x and object y to participate in aborrow event. An event enabler on the contrary symbol-izes that one or more objects have interacted ± the eventenabler is the result of that interaction. For example,Borrow!(x:Borrower,y:Book) appears in case x

and y have participated in a borrow event.The set of regular processes R are de®ned by the fol-

lowing grammar.

R : :� nil j e�d�:R j a:R j R� R j X�o� j PThe symbol d denotes a positive real number.

The process expression nil speci®es a totally inactiveprocess which can do nothing except waiting. Intuitive-ly, the waiting of a process can be represented byR !e�d� R0 meaning that R can wait for d time units and be-come R0. For nil we have nil !e�d� nil for any d. The symbole(d) denotes a delay construct by means of which it ispossible to delay a process d time units. For example,the following equation speci®es that the book must be

Rule 3 Late books

ON Late(B:Book,N:Integer)

THEN Print(``The book'', B.Title, ``has

not been returned within'', N,

``days.'')

Fig. 2. Events and event control.


borrowed with at least a delay of one day (assuming thatthe time unit is one day).

Book�y� � Borrowy:Returny:e�1�:Book�y�In general, e(d).R speci®es a process that can do noth-

ing but wait for d time units after which it is supposed tobehave like speci®ed by R. Intuitively, we would writee�d�:R !e�d� R.

The process de®ned by the sequencing construct a.Rmust enable the event a immediately. After performinga, the process must behave as speci®ed by R. Moreover,if a ¹ s the process can wait passively while continu-

ously enabling a, that is a:R !e�d� a:R for any d, whenevera ¹ s. A process speci®ed by s.R is not allowed to wait.Therefore, s can be used as a time out construct.

To illustrate the semantics of the sequencing con-struct consider the following speci®cation.


e(30).s.Late!(y:Book,30:Integer).Re-turny.Book[y])

Here the book process must enable Borrowy immedi-ately and participate in a borrow event if required.While waiting, Book[y] continuously enables Bor-

rowy.Summation denotes alternative choice, i.e., the pro-

cess is supposed to behave as de®ned by the ®rst orthe second component. In the following example theborrower can choose to borrow or return a book.

Borrower[x] ºBorrowx.Borrower[x] + Returnx.Borrow-

er[x]

We require process names and object identi®ers to be de-®ned by a recursive equation system as illustrated in Sec-tion 2. For each P 2 P we write P º R where R is aregular process. An example of such an equation is theone for the process name Environment in Section 2.

For each object class name X we de®ne an equationX[o] º R for each object identi®er in the class. R is a reg-ular process and the only object identi®er that occurs insimple events in R is o.

Intuitively, P º R means that the dynamics of theprocess denoted by the process name P equals the dy-namics de®ned by R. Similarly, X[o] º R means thatthe dynamics of X[o] equals the dynamics of R. The pairof an object name and an object identi®er X[o] is sup-posed to denote the behavior of the object identi®edby o.

Notice, that it has been that required that for P º Ronly composite events or s are allowed to occur in R.Also, for X[o] º R it has been required that no other ob-ject identi®er than o is allowed to occur in simple events

in R. The reason is that all simple events performedshould be identi®able as originating from a speci®c ob-ject.

A composed process expression S is a parallel compo-sition of regular process expressions. The set of expres-sions S is generated by the following grammar whereM is a subset of E.

T : :� R j �RjT�S : :� T nM j T

Often we write PjRj for the parallel composition of reg-ular processes in {Rjjj 2 J}. Moreover we shall allowequations on the form P º S to belong to the equationsystem in case P does not occur in any right hand sidein any equation. An example of such an equation isthe speci®cation of the process Library in Section 2.

Whenever M is a subset of E, we write a 2 M in caseeither· a� ao for some a, o and a 2M, or· a� a?(o1: X1; . . . ; on: Xn) for some a, o1;X1; . . . ; on;Xn

and a 2M, or· a� a!(o1: X1; . . . ; on: Xn) for some a, o1;X1; . . . ; on, Xn

and a 2MLet R1 and R2 be two regular process expressions.

Then intuitively, a system S de®ned by R1jR2 is the par-allel composition of two objects o1 and o2 de®ned by R1

and R2 respectively. The dynamics of S is the interleav-ing of the dynamics of the two objects o1 and o2 pluspossible synchronization between the two. In Section 2we saw a system consisting of three objects: a borrower,a book and an environment. The objects can either syn-chronize, that is, engage mutually in borrowing or re-turning of books, or they may engage in externalsynchronization.

A system speci®ed by T\M behaves like T except thatevent names in M are restricted in the sense that theycannot engage in external synchronization. Again, inthe example in Section 2 we could use the following ex-pression to restrict all external synchronization.

Library � �Book�y� j Borrower�x� j Environment�nfBorrow;ReturngWe shall return to the semantics of parallel compositionin the next section. By convenience although we shall of-ten omit the restricting set of event names when it isclear from the context that all events in the speci®cationare restricted.

3.2. Formal semantics

In this section we present the formal semantics forour speci®cation language. We refer the interested read-er to (Wang, 1990) for a detailed presentation of the se-mantics for the language, TCCS, from which we havebeen inspired.


Semantically, speci®cations are given an operationalinterpretation by means of a labeled transition system.

De®nition 1. A labeled transition system is a structure(S, Act, ®) where Act � A [ C [ fe�d�jd 2 R�g and ®Í S x Act x S is a labeled transition relation.

A labeled transition system de®nes the dynamics ofeach valid speci®cation in S. The dynamics are de®nedby means of the labeled transition relation that preciselydetermines the enabled events that a speci®ed system isable to perform.

The transition relation ® is de®ned as the least rela-tion satisfying the inference rules in Figs. 3 and 4. Wewrite S!a S0 whenever (S, a, S0) 2® and S !e�d� S0 whenev-er (S, e(d), S0) 2®. The rules in Fig. 3 de®nes the en-abled transitions due to events whereas the rules inFig. 4 de®nes the semantics of delays. In Fig. 3 we letY denote either P or X[o]. We write o 2 X when the pro-cess for the object o is de®ned by means of an equation,X�o� � R, that involves X on its left-hand side. The equa-tion for Borrower[x] in Section 2 is an examplewhere the object identi®er x belongs to the object classnamed Borrower.

Most of the rules in Fig. 3 have already been infor-mally explained in the previous section. However, afew rules need some explanation.

(6) is concerned with parallel composition and itstates that if S is allowed to perform the event a and be-come S0, then SjT is allowed to perform a and becomeS0jT. (7) is symmetric and together the two rules de-scribes the interleaving of parallel composition.

(8) de®nes the generation of event enablers. Althoughevent enablers may be written explicitly in speci®cations,they may also be synthesized indirectly as a consequenceof multiple synchronization among objects. The idea isthat one or more regular process expressions put togeth-er in parallel composition all enable a simple event withthe same event name a, and with each simple event in-dexed with the corresponding object identi®er. In thatcase an event enabler a!(o1: X1; . . . ; on: Xn) is enabledfor the parallel composition where oi, i � 1; . . . ; n arethe object identi®ers involved and withoi 2 Xi; i � 1; . . . ; n.

(9) represent the fact that two complementary eventsmay engage in a synchronization. If such a synchroniza-

Fig. 3. Event rules.

Fig. 4. Delay rules (d; e 2 R�).


tion occurs the result is an event named s. Actually, thismeans that a synchronization between complementaryevents cannot be delayed because a s_event is unableto let time progress. In other words, synchronization be-tween complementary events has priority over time pro-gress. For more detail of this property inherent to ourspeci®cation language we refer the reader to (Wang,1990).

Most of the rules in Fig. 4 have already been ex-plained. However, the rules for alternative choice andparallel composition need a few comments. (14) de®nestime delay for alternative choice. It states that the twopossible choices are required to synchronize on timeprogress.

(15) de®nes time delay for parallel composition. Itstates that SjT is allowed to let time progress for d timeunits if S and T are allowed to let time progress for dtime units and provided the side condition C(S,T,d) issatis®ed. Intuitively, C(S,T,d) says that S and T arenot allowed to communicate in the interval [0,d). Thereason for this condition is that internal synchroniza-tion, i.e., s-events, has priority over time progress. If in-ternal synchronization may happen somewhere in theinterval [0,d) then time is not allowed to progress for dtime units. The formal de®nition of the conditionC(S,T,d) is out of the scope of this paper. The interestedreader is referred to (Wang, 1990) for a formal treatmentof the condition.

4. Speci®cation example

In this section we illustrate the use of our speci®ca-tion language by means of a speci®cation example froma library database. The following speci®cation de®nes asimple library with two borrowers and one book. The li-brary is speci®ed in terms of all the speci®c events thatcan occur. In (Bñkgaard and Godskesen, 1995) we haveshown how to generate such speci®cations from high-level speci®cations that use event types.

Environment ºBorrow?(x1:Borrow-

er,y:Book,z1:Card).Environment +

Borrow?(x2:Borrow-


Borrow?(x1:Borrow-


Borrow?(x2:Borrow-


Return?(x1:Borrower,y:Book).Envi-

ronment +

Return?(x2:Borrower,y:Book).Envi-

ronment +

Late?(y:Book,30:Integer).Environ-

ment +

Late?(y:Book,40:Integer).Environ-

ment +

Empty?(z1:Card).Environment +

Empty?(z2:Card).Environment

Borrower[x1] ºBorrowx1.Borrower[x1] + Returnx1.Bor-

rower[x1]

Borrower[x2] ºBorrowx2.Borrower[x2] + Returnx2.Bor-

rower[x2]

Card[z1] ºBorrowz1.Borrowz1.Borrowz1.Empty!

(z1:Card)

Card[z2] ºBorrowz2.Borrowz2.Borrowz2.Empty!

(z2:Card)


(e(30).s.Late!(y:Book,30:Integer).(Returny.Book[y] +

(e(40).s.Late!(y:Book,40:Integer).Returny.Book[y])))

Library º(Book[y] j Borrower[x1] j Card[z1] jBorrower[x2] j Card[z2] j Environ-

ment)

The following sequence of events illustrates one possiblebehavior scenario in the library.

Day 1: Borrow(x2:Borrow-

er,y:Book,z2:Card)

Day 30: Return(x2:Borrower,y:Book)


er,y:Book,z1:Card)

Day 61: Late(y:Book,30:Integer)



er,y:Book,z2:Card)



er,y:Book,z2:Card)



er,y:Book,z1:Card)



er,y:Book,z1:Card)


After Day 70 no events can occur in the library be-cause all borrowing cards are empty. Late is enabledon Day 61 because the book has not been returnedwithin 30 days. The following sequence of events illus-trates another possible behavior scenario in the li-brary.



er,y:Book,z2:Card)



er,y:Book,z1:Card)





er,y:Book,z2:Card)



er,y:Book,z2:Card)



er,y:Book,z1:Card)



er,y:Book,z1:Card)


Late is enabled on Day 71 because the book has notbeen returned within 30 days and it is enabled on Day81 because the book has not been returned within 40days. The event enabler Late!(y:Book,30:Inte-

ger) will trigger Rule 3.The processes Card[z1] and Card[z2] model bor-

rowing cards that enable the borrowing of three bookseach. A Borrow event must have a valid borrowing cardas participant. When a borrowing card has been usedthree times the event Empty is enabled. This event willtrigger Rule 4.

5. Conclusion

We have presented the syntax and semantics of aspeci®cation language that can be used to specify real-time triggering conditions for active rules in terms ofcomplex event patterns. Our language can be used tospecify soft real-time constraints in terms of the mini-mum/maximum time required/allowed between pairs oftransactions (Dasarathy, 1985).

We have used a speci®cation example from a libraryto illustrate the use of our language. The example showshow complex event patterns can be used to specify thesequencing of borrow and return events. Also, the exam-ple shows how soft real-time constraints can be used totrigger active rules when books are not returned in atimely fashion.

Our language is a CCS-like language (Milner, 1989)that facilitates the speci®cation of synchronization be-tween multiple database objects. Our language is basedon the language TCCS (Wang, 1990) that supports spec-i®cation of object pairs only.

Our examples indicate that the use of our speci®ca-tion language will decrease the need for IF conditionsand database queries in ECA rules. This is illustratedby Rule 2 and Rule 3 that both implements the actiontaken when a book is not returned in a timely fashion.Rule 2 uses a database query in the IF condition where-as Rule 3 uses no IF condition at all.

Future work includes implementation of an eventmonitor (Figs. 1 and 2) that controls the occurrencesof events based on a constraint speci®cation. Also, fu-ture work includes the use of our speci®cation languagein large-scale active databases.

References

Brodie, M.L., Ridjanovic, D., 1984. On the design and speci®cation of

database transactions. In: Brodie, M.L., Mylopoulos, J., Sch-

midt, J.W. (Eds.), Topics in Information Systems, On Conceptual

Modeling. Springer, Berlin, pp. 277±312.

Bñkgaard, L., 1997a. Conceptual modeling of events as information

objects and change agents. In: ER'97 Workshop on Behavioral

Modeling and Design Transformations, Los Angeles, USA.

Bñkgaard, L., 1997b. Transaction-based speci®cation of database

evolution. In: 16th International Conference on Conceptual

Modeling (ER'97), Los Angeles, California, USA.

Bñkgaard, L., Godskesen, J.C., 1995. Transaction-based speci®cation

and veri®cation of real-time dynamic database constraints. R-95-

2018, Aalborg University, Denmark.

Castilho, J.M.V.D., Casanova, M.A., Futardo, A.L., 1982. A Tem-

poral Framework for Database Speci®cations. In: Eighth Inter-

national Conference on Very Large Databases, Mexico City,

Mexico.

Ceri, S., Pelagatti, C., Bracchi, G., 1981. Structured methodology for

designing static and dynamic aspects of database applications.

Information Systems 1 (6), 31±45.

Cervasato, I., Eick, C.F., 1992. Speci®cation and Enforcement of

Dynamic Consistency Constraints. In: ISSM International Con-

ference on Information and Knowledge Management

(CIKM'92), Baltimore, Maryland, USA.

Chomicki, J., 1992. History-Less checking of dynamic integrity

constraints. In: Eighth International Conference on Data Engi-

neering, Tempe, Arizona, USA, Computer Society Press.

Dasarathy, B., 1985. Timing constraints of real-time systems: Con-

structs for expressing them, methods of validating them. IEEE

Transactions on Software Engineering SE±11 (1), 80±86.

Dayal, U., Hanson, E., Widom, J., 1995. Active database systems. In:

Kim, W. (Ed.), Modern Database Systems. The Object Model,

Interoperability, and Beyond. Addison±Wesley, Reading, MA.

Ehrick, H.-D., Lipeck, U.W., Gogolia, M., 1984. Speci®cation,

semantics, and enforcement of dynamic database constraints.

In: 10th International Conference on Very Large Databases,

Singapore.

Kappel, G., Schre¯, M., 1991. Object/Behavior diagrams. In: Seventh

International Conference on Data Engineering, Kobe, Japan,

Computer Society Press.

Kim, W. (Ed.), 1995. Modern Database Systems. The Object Model,

Interoperability, and Beyond. Addison±Wesley, Reading, MA.

Rule 4 Empty borrowing cardON Empty(C:Card)

THEN Print(``The borrowing card'', C,

``can not be used in the future.'')


Kung, C.H., 1985. On veri®cation of temporal database constraints.

In: International Conference on Management of Data (SIG-

MOD'85), Austin, Texas, USA.

Lipeck, U.W., 1986. Stepwise speci®cation of dynamic database

behaviour. In: International Conference on Management of Data

(SIGMOD'86), Washington, DC.

Lipeck, U.W., Saake, G., 1987. Monitoring dynamic integrity

constraints based on temporal logic. Information Systems 12

(3), 255±269.

Martin, H., Abida, M., Defude, B., 1992. Consistency checking in

object-oriented databases. A behavioral approach. In: ISSM

International Conference on Information and Knowledge Man-

agement (CIKM'92), Baltimore, Maryland, USA.

Milner, R., 1989. Communication and Concurrency. Prentice-Hall,

Englewood Cli�s, NJ.

M�uck, T., Vinek, G., 1989. Modeling dynamic constraints using

augmented place transition nets. Information Systems 14 (4),

327±340.

Wang, Y., 1990. Real-Time Behaviour of Asynchronous Agents,

CONCUR'90. Springer, Berlin.

Widom, J., Ceri, S., 1996. Active Database Systems. Morgan Kaufm-

ann, San Francisco, CA.

Wieringa, R., Meyer, J.-J., Weigand, H., 1989. Specifying dynamic and

deontic integrity constraints. Data & Knowledge Engineering 4,

157±189.

Yang, C.-M., Henschen, L.H., 1992. On the speci®cation of database

transition constraints using ®rst-order logic. In: ISSM Interna-

tional Conference on Information and Knowledge Management

(CIKM'92), Baltimore, Maryland, USA.

Zaniolo, C., Ceri, S., Falutsos, C., Snodgrass, R.T., Subrahmanian,

V.S., Zicari, R., 1997. Advanced Database Systems. Morgan

Kaufmann, Los Altos, CA.

Jens Chr. Godskesen received his M.S. and Ph.D. degrees in computerscience from Aalborg University, Denmark in 1988 and 1994, respec-tively. He was a research assistant at the Department of Mathematicsand Computer Science, Aalborg University in 1989. He was employedat TFL, a Danish telecommunications research laboratory from 1989to 1991. He worked for Tele Denmark Research and Developmentfrom 1991 to 1996. In 1996 he joined the school of Computer Scienceat Roskilde Business College. He has been employed as an externalassociate professor at Aalborg University at the Computer Sciencedepartment, since 1997. Dr. Godskesen has published research papersin international journals and proceedings from international confer-ences. He has been member of the Danish censor corps since 1994. Hiscurrent research interests include Databases, integrity constants, activedatabases, Process algebra, real-time process algebra, temporal logics,model checking.

Lars Bñkgaard received his M.S. and Ph.D. degrees in computer sci-ence from Aalborg University, Denmark in 1988 and 1993, respec-tively. He was a teaching assistant at the Department of ComputerScience at Aalborg University from 1988 to 1990, and he joined thefaculty as an assistant professor in 1992. Since 1996, he has been anassociate professor at Department of Information Science at TheAarhus School of Business, Denmark. Dr. Bñkgaard has publishedresearch papers in international journals and proceedings from inter-national conferences. He has been member of the Danish censor corpssince 1994. His current research interests include Databases, integrityconstraints, query languages, event modeling, active databases ande�ciency, Data warehousing, architectures and view maintenance,Knowledge discovery, data mining and ¯exible query-answering.


real-time event control in active databases

Documents