Implementing ECA rules in an active database

C.W. Tan, A. Goh*

Division of Software Systems, School of Applied Science, Nanyang Technological University, Blk N4 2A-50, Nanyang Avenue, Singapore 639798, Singapore

Received 20 July 1998; received in revised form 11 March 1999; accepted 17 March 1999

Abstract

Traditional database systems are designed to manage large volumes of data, but rule support is generally not a strong feature. On the otherhand, expert systems have the deductive capability to manage rule processing. A coupling between these two systems to support advanceddatabase applications results in what is termed an active database. An approach to implementing active database systems is to representknowledge as Event–Condition–Action (ECA) rules. ECA rules determine when and how to react to different kinds of events. This paperfocuses on the different type of events supported by an active database CLOSE. A set of primitive and composite events is presented togetherwith examples of their application. Event detection in this system is also discussed.q 1999 Elsevier Science B.V. All rights reserved.

Keywords:Active database; Rules; Events

1. Introduction

For decades, databases have played an important role inensuring reliable management and easy retrieval of largeamounts of data in organisations ranging from hospitals tomanufacturing concerns. As the use of databases becomesmore widespread, there is a rise in the number of applica-tions that look beyond standard database functionalities.Examples of such application domains are real-time plantcontrol, air traffic control and office automation. The advan-tages offered by traditional databases to these applicationsinclude persistence, modelling, query processing, concur-rency control and access control [1]. However, runtimeperformance would be optimised if a certain amount ofautonomy were built into the underlying database. Thisimplies the need to detect specified events without the useof external applications and to possess intelligence in orderto evaluate conditions and perform actions in response tothose events. Many applications, including classical oneslike inventory control, would run much more efficiently.This would free the applications of the need to continuouslymonitor relevant events and as a result, the application codewould be less complex, more manageable and more reliable.

Over the past decade, several research groups havebuilt prototypes that try to incorporate such autonomyinto databases. Examples include SAMOS [2], ACOOD[3] and HiPAC [4]. Knowledge can be stored as

Event–Condition–Action (ECA) [4] rules. The databasesystem is able to monitor a special situation represented byan event and one or more conditions. When the event occursand the conditions evaluate to true, the corresponding actionsare executed. Hence, active database systems can recognisespecific situations and react to them without direct explicituser or application requests. Active databases are veryuseful for timely applications.

The emergence of Object-Oriented Database Systems(OODBMS) supplies traditional DBMSs with OO concepts.On the other hand, Expert Systems (ES) which are thehistorical domain of rule management, have a rule shell tosupport production rule processing and can deduce newknowledge or new data from them. Thus, one approach isto integrate the rule processing technology of expert systemsand the storage capability of database systems to produce arule management capability.

The work of making an OODB active through integrationwith an expert system has been carried out at the NanyangTechnological University. CLOSE is a prototype based onthe integration ofObjectStoreOODB and theCLIPSExpertSystem [5,6]. CLOSE is distinct from other active databaseprototypes in that it makes use of the powerful inferencemechanism of an expert system to implement its activefunctionalities. The expressiveness of an active databasecan be enhanced through its ability to detect a wide rangeof events provided by CLOSE. In the following section, anintroduction to the architecture of CLOSE is presented. Thisis followed by a description of primitive and compositeevents together with examples of their application. The

Knowledge-Based Systems 12 (1999) 137–144

0950-7051/99/$ - see front matterq 1999 Elsevier Science B.V. All rights reserved.PII: S0950-7051(99)00028-3

* Corresponding author. Tel:1 65-790-4929; fax:1 65-792-6559.E-mail address:asesgoh@ntu.edu.sg (A. Goh)

mechanism for implementating these events is discussed.Finally, an example application is used to illustrate the func-tionality of the system.

2. The architecture of a CLOSE

The architecture of a coupling between an OODB and anES is shown in Fig. 1. It is implemented on top of theObjectStore OODB and CLIPS ES.

ObjectStore [7] is a commercial OODBMS. It extendsC11 with database functionalities, such as persistence, aquery processor, indexing clustering, and transactionmechanisms. Therefore, it can provide the Rule Managerwith a basic DBMS ability and OO behaviour. In addition,it supplies mechanisms for long multi-user transactions,nested transactions, and version and evolution management.All of these make ObjectStore a suitable underlying plat-form for non-traditional applications. Moreover, Object-Store offers a Meta-Class management, making it ispossible to integrate with Expert System technology.

The expert system used in this prototype is CLIPS 6.0 (CLanguage Integrated Production System) which wasdeveloped in NASA Johnson Space Center. CLIPS waschosen over other inference languages such as Prologbecause CLIPS is very widely used, its source code is

readily available and it can be easily modified to be incor-porated with ObjectStore. The basic elements of CLIPS are:

• Fact_list: knowledgebase that contains global memorydata.

• Production Rules: contains all production rules that areconstructed by the CLIPS statements.

• Inference Engine: overall control of production ruleexecution based on the fact-list.

As there is no CLIPS interface to ObjectStore, an interface,which enables the two systems to communicate with eachother, had to be developed. This is achieved by usingObjectStore meta-classes and extending the CLIPSlanguage.

Due to the evolutionary nature of rules, it is necessary tosupport the dynamic specification of rules. By specifyingthe components of a rule as first-class objects, they can begrouped in a class-hierarchy and can be dynamicallyinserted, deleted and modified as with any other objects.The Rule Manager treats rules as complex objects of fourclasses: Rule, Event, Condition and Action. All theseobjects together constitute the RuleBase.

3. Primitive events

The ECA rule concept states that when an event occurs,the condition is evaluated and if the condition is satisfied,the action is executed. From the semantics of the ECA rule,it can be observed that the kinds of events that are supportedand monitored by the active database prototype would deter-mine how “active” the prototype is. The general form of anECA rule is illustrated in Fig. 2.

Some of the basic or primitive events supported by exist-ing database prototypes are time events, method events,transaction events and absolute events [8].

3.1. Time events

Time events are specified as explicit points in time [9]Active databases monitoring a specified time event with atime clause of say, “98.02.08.10:00”, would trigger therelevant rules when the system clock reaches 10 am on8th February 1998. Time events may be absolute, relativeor periodic. An absolute time event is one that specifies adate and time for the event to occur, as in the above

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144138

Fig. 1. The architecture of CLOSE.

Fig. 2. The general form of ECA rules.

example. A relative time event may be specified by provid-ing a time interval relative to another event. An example of aperiodic event would be one with the clause “every 5 days at20:00”. This would mean the event would occur at 8 pmevery 5 days.

3.2. Method events

In an object-oriented environment, users manipulate andaccess objects by sending messages to them. Each messagesent to an object requires the execution of a method (proce-dure). Execution of methods can trigger method events.There are two classifications of method events:beforeandafter method events.Beforemethod events occur before theexecution of a method procedure whileafter method eventsoccur after the execution of a method procedure.

3.3. Transaction events

Transaction events are events that are defined by the startor termination time of user-defined transactions. Assumingthat transaction programs are named, a transaction event canbe restricted to transactions executing this particular trans-action program.

3.4. Absolute events

Absolute events are external events that are defined inapplications. Such events are not detected by the activedatabase prototype but are explicitly raised by applications.Whenever an application requires the attention of the activedatabase, it would raise an absolute event predefined in thedatabase and this would cause the triggering of certain rulesin response to the absolute event.

4. Composite events

The active functionality of an active database prototype ismeasured by the ability of the database to monitor variousforms of primitive events. On the other hand, the expressivepower of the database can be augmented by the ability todetectcomposite events, which can made up of differentcombinations of primitive events. Composite events aremade up of combinations of primitive or other compositeevents. Event constructors are used to compose compositeevents. There are six different kinds of event constructorsthat can be used to construct composite events. Theseconstructors are: disjunction, conjunction, sequence,history, negativeandclosure[10].

4.1. Disjunction

A disjunctionof two events E1, E2 occurs when either E1or E2 occurs. This is illustrated by a typical monitoringapplication of a process plant. The monitoring sensorsensure that the safety operation level is adhered to bycontinuously monitoring the temperature and pressure in

the environment where a mixing process takes place.Although it is possible to implement the monitoring processat a hardware level, implementation at the software levelallows better reconfigurability of the temperature and pres-sure safety levels. The slower response of software techni-ques (in terms of milliseconds) is assumed to beinsignificant in this context.

The active database can store the temperature and pres-sure values as they are received from an analog-to-digitalconverter. At the same time, temperature and pressure read-ings are checked in accordance with predefined rules.Assume that E1 is defined as the event that occurs as soonas the temperature reaches 1508C and E2 as the event thatoccurs as soon as the pressure reaches 500 N/m2. Either ofthese occurrences would mean that the safety level of theprocess is exceeded and an alarm must be sounded at theconsole. Therefore a composite event C1 can be defined asthe disjunction of events E1 and E2.

4.2. Conjunction

A conjunctionof two events E1, E2 occurs when both E1and E2 occur, regardless of order. This is illustrated in aninventory application. Databases have been widely used ininventory applications for stock control. An active databasecan be used to monitor the stock level of the items. In thisexample, it is assumed that the maximum number of a partA that can be bought by customers is 20. An event E1 can bedefined to occur whenever the quantity of part A falls below20. Another event E2 can be defined as the receipt of anurgent sales order for part A that must be processed within 2weeks. The composite event C1 is defined as the conjunc-tion of E1 and E2. Whenever C1 is detected, an urgentreminder to send a purchase order to the supplier isdisplayed. It should be noted that the occurrence of eitherE1 or E2 alone does trigger off any action. The event historythat registers the occurrence of either E1 or E2 alone wouldonly fire actions that update the status of the database. C1would only occur when the event history registers the occur-rences of both E1 and E2 at some point of time.

4.3. Sequence

A sequenceof two events E1, E2 occurs when E1 occursfirst followed by E2. The use of asequencecomposite eventis illustrated in an automatic warehouse application. In anautomated warehouse, Automated Guided Vehicles (AGV)are used to load items from the storage racks of the ware-house and to transport items to be loaded to the outputstation. Events of interest can be defined as follows: E1occurs whenever the last item(s) to be loaded causes theAGV to be fully loaded; E2 occurs whenever the sensorsof the AGV inform that the way towards the output station isclear and the AGV is free to move on. The composite eventC1 can then be defined as the sequence of E1 followed byE2. Whenever the AGV is fully loaded and subsequentlywhen the AGV is told that the way towards the output

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144 139

station is clear of other AGVs, composite event C1 occurs totell the AGV to start moving. Note that if E2 occurs prior toany occurrence of E1, then the AGV should not move sinceit has not yet been fully loaded and hence C1 should notoccur.

4.4. History and negative

A historyof an event E refers to when E occurs a specifiedn times, within a specified time interval I. Thenegativeconstructor refers to a situation when an eventE does notoccur during a specified time interval I. The use ofhistoryand negativecomposite events is shown in an applicationwhere the rise and fall of the share prices is monitored. If anactive database is used to monitor the fluctuations of theshare prices, the need for additional monitoring applicationsis removed. In this example, the price of commodity A isbeing monitored. An active database is used to keep track ofthe price of item A at hourly intervals. An event of interestwould be the consecutive fall of the price of item A for 5times within 1 h. This corresponds to the usage of thehistory composite event. Another possible event of interestwould be there is no change of the price within 24 h. Thenegative event constructor can be used to compose such anevent. Both events serve to inform the user of such peculiaroccurrences through warning messages.

To monitor the first event of interest, the time intervalmust be properly defined. In this case, it is 1 h. Therefore,events E1 and E3 are time events and are defined to occur inintervals of 1 h. The monitored event is E2 that occurswhenever the price of item A falls. If E2 occurs 5 timesconsecutively in between occurrences of E1 and E3, thenthe composite event C1 occurs to inform the user of thissituation. Any further event occurrences of E1 after C1 hasoccurred or after the interval has elapsed, is taken as the startof another monitoring sequence.

To monitor the second event of interest that occurs whenthere is no change of the price of item A for 24 h, appro-priate events and actions need to be defined. Events E1 and

E3 are defined as the starting and ending time intervals forthe monitoring process. Event E2 is defined as the change ofprice of item A. Composite event C2 is defined using thenegative composite event constructor to occur when there isno occurrence of E2 within E1 and E3. Similar to the historyconstructor, any further event occurrences of E1 after C1has occurred or after the interval has elapsed, is taken as thestart of another monitoring sequence. However in this case,there must be an explicit ending time interval defined.

4.5. Closure

A closureof an event E refers to when E occurs at leastonce during a specific time interval. The use of theclosurecomposite event is illustrated in a conveyor belt application.The operation of the conveyor belt is as follows: items arepassed below a sensor that detects a fault in the item. Allinformation on the items on the moving belt are stored in anactive database to keep track of how many items, defectiveor non-defective, have passed through the particular stage.An event of interest can be defined in the active database torecord the total number of defective items during the entireoperation of the belt.

As with Section 4.4, a time interval, marked at both endsby time events, needs to be defined. These starting andterminating times are defined as E1 and E3, respectively.Event E2 occurs whenever the sensor detects a defect in theitem moving underneath it. Composite event C1 is definedas the event that occurs to inform the user of the totalnumber of defects that occur during the operation of theconveyor belt. Note that the occurrence of the terminatinginterval E3 is absolutely necessary unlike that of the historyevent constructor. If there are zero defective items (nooccurrence of E2), then composite event C1 does not occur.

5. Detection of events

The ability to automatically react to events in an activedatabase is based on the event detection. Three kinds of

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144140

Fig. 3. Rule detection process.

primitive events, namelymethod events, time eventsandabsolute eventsare supported. Composite events asdescribed in Section 4 are also supported. Several differentapproaches are used to detect these events respectively.

The Rule Manager is the main component responsible forthe active behavior in the CLOSE prototype. Fig. 3 showshow the components of CLOSE interact with one another.Whenever an event occurs, the Rule Controller is notifiedand the corresponding ECA rule objects are retrieved fromthe RuleBase. The Rule Controller then sends the relevantconditions and actions to the Condition Evaluator andAction Executor respectively. The Condition Evaluatorthen evaluates the conditions and if these conditions weresatisfied, the Action Executor would then execute theactions. The Rule Controller, upon the signalling of theevent, also invokes the Composite Event Detector to deter-mine if this event contributes to the occurrence of anycomposite event. If a composite event occurs, the RuleController is notified by the Composite Event Detector.The same process of sending conditions and actions to theCondition Evaluator and Action Executor is done. If thiscomposite event contributes to further composite events,the Composite Event Detector is invoked again. There istherefore a recursive relationship between the Rule Control-ler and the Composite Event Detector.

5.1. Primitive event detection

In OODBs, all operations are carried out by sending amessage to objects through methods. Any message sent toan object may be associated with amethod event. Hence,every method event is associated with a class name and amethod name. In order to detect a method event, a wrapperis used on the method at event definition time through theclass name and the method name. In the Rule Manager, atranslator (termedWrapper) to translate an original class toa wrapped class has been developed. This is done aftercreating a method event. Another translator (termedDeWrapper) to translate a wrapped class back to an originalclass has also been developed. This translator is alwaysinitialised after deletion of a method event.

An important issue in method events is the passing ofparameters of an event to a condition. Most active systemssolve this in a “static” way. The parameters in these systemsare usually bound with their events during the event crea-tion. In the Rule Manager, the CLIPS Fact_List is used toachieve parameter passing. The parameters of an event areinserted into the Fact_List when the event is triggered. Thecorresponding condition may use these parameters in thecondition evaluation time.

A time eventcan be triggered at a specified point of time.In order to detect a time event, an Application ProgramInterface (API) enableTimeDetection() is embedded intoeach application program. It is responsible for retrievingall time events from the RuleBase and enables them to

monitor the system clock in parallel with the applicationprograms.

Absolute events, which are defined by users according totheir specific semantics, need not be detected. These eventsnotify theRule Controllercomponent by explicitly raising amessage in application programs.

5.2. Composite event detection

For detecting composite events, a provision must be madeto manage an event history [11] and to notify a separatecomponent in charge of detecting composite events when-ever an event happens. This separate component is known asthe Composite Event Detector. This Composite EventDetector must work together with other existing compo-nents to ensure the proper detection of composite eventsand triggering of relevant rules. For example, wheneveran event occurs, the Composite Event Detector must beinformed of such an occurrence. The Detector would thendecide if any of the composite events has occurred. If so,control would then be passed to the rule execution compo-nents for triggering and execution of relevant rules.

A step-by-step approach for detecting composite eventoccurrences is adopted. In this approach, the CompositeEvent Detector needs to know the ordered sequence of allcomponent events that comprise the composite event. Oneway of implementing this approach is to use ExtendedSyntactic Tress (EST) [10]. Each composite event type isassigned a particular type of EST. Each event constructor isassigned an EST node that provides the link between a rootand the leaves.

In the Rule Controller, a token is created for a newlyoccurred event if the event is primitive. If the event is acomposite one, its token must already have been createdand stored in its EST before the event has occurred as theEST algorithm maintains all tokens of component eventswhich have already occurred. This algorithm also createsa new token for the composite event once the last compo-nent event that is needed to trigger the composite event hasoccurred. Therefore, if the Rule Controller is handling acomposite event, it gets the corresponding EST from theESTBase and retrieves its token.

The Rule Controller then passes the time and messageparameters to the Composite Event Detector. In turn, theComposite Event Detector passes the parameters to all thespecified composite events related to the triggered event. Itis therefore necessary to retrieve all the ESTs of the speci-fied composite events from the RuleBase. The ESTs wouldexecute their respective algorithms to determine whichcomposite event is to be triggered and correspondinglycall the Rule Controller to process the event.

Two features of the Composite Event Detector are high-lighted. The first feature is the support for parameter passingfrom various component events to the detected compositeevent. The second involves two distinct ways of composing

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144 141

component event parameters whenever two or more occur-rences of the same component event type exist.

6. A case study to demonstrate the functionality ofCLOSE

This section describes a test case used to demonstrate therunning of the CLOSE system. A simple robotic system asshown in Fig. 4, was chosen as a typical application requir-ing rule management. There are three resources, namelyMachine_A, Machine_Band aRobot. In order to producea final product, a part must be processed first byMachine_Aand then byMachine_B. TheRobotis responsible for load-ing and unloading both machines. A buffer area is used tostore intermediate parts. Only two intermediate parts areallowed to be stored in the buffer. The machine cannot beinterrupted once it starts work on a part.

In this model, there are four important entities:Part,Machine, BufferandRobot. These are simulated as continu-ously running processes. The six kinds ofactivities (orevents) that involve these four entities are listed in Table1. The processesMachine_Aor Machine_Bcontinuouslymonitor the queuesQ_Run_Aor Q_Run_B, respectively.If signals are received, the corresponding activitiesPart.Run_Machine_A() or Part.Run_Machine_B() areinvoked. At the end of each activity, a signal would be

sent to the queuesQ_UnLoad_Aor Q_UnLoad_Bto invokethe Robot.UnLoad(“A_Part”, “ Machine_A”) or Robot.Un-Load(“A_Part”, “ Machine_B”) activity. The processRobotis made up of four kinds of activities:Load_A, UnLoad_A,Load_B and UnLoad_B. These activities will be invokedwhen there are signals in the queuesQ_Load_A,Q_UnLoad_A, Q_Load_B, or Q_UnLoad_B, respectively.At the end of each activity, signals would again be sent tocorresponding queues. The processesMachine_A andMachine_Bwill be terminated after all parts have beenprocessed. After the last part passes through theMachine_Bprocess, a signal STOP will be raised to terminate theprocessRobot.

ECA rules governing this system are stored in CLOSE.These are shown in Fig. 5. Some important characteristics ofthe case are highlighted. Several activities need to beprocessed sequentially. A part must be processed one at atime. Therefore, for a given part,Machine_Bcan run onlyafter Machine_Ahas finished with it. Thus, each event canbe achieved or triggered by an existing situation. The Rules“R_RunA”, “ R_RunB”, “ R_LoadA”, “ R_LoadB”,“R_UnLoadA” and “R_UnLoadB” are defined as event-driven. For example, “R_RunA” may be triggered byevent “E_Load” which is defined before the method“Load” of the class “Robot”.

However, for different parts, concurrency may exist. Dueto this concurrency, resource constraints are noted. Activ-ities Robot.Load (“A_Part”, “ Machine_A”), Robot.Load(“A_Part”, “ Machine_B”), Robot.UnLoad (“A_Part”,“Machine_A”) and Robot.UnLoad (“A_Part”, “ Machi-ne_B”) are mutually exclusive since the robot can serviceonly one activity at a time. Moreover, since only one partcan be processed on a machine at a time,Robot.Load(“A_Part”, “ Machine_A”), Part.Run_Machine_A() andRobot.UnLoad(“A_Part”, “ Machine_A”) are also mutuallyexclusive. This case is similar to that ofRobot.Load(“A_Part”, “ Machine_B”), Part.Run_Machine_B() andRobot.UnLoad(“A_Part”, “ Machine_B”).

After an activity Robot.UnLoad (“A_Part”, “ Machi-ne_A”), the robot can load eitherMachine_Aor Machine_B.In order to ensure a part that has been processed by

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144142

Fig. 4. A simple robotics application.

Table 1The description of events

Activities (events) Description

Part.Run_Machine_A() The Machine_Ais processing a partPart.Run_Machine_B() The Machine_Bis processing a partRobot.Load(“A_Part”,“Machine_A”)

TheRobotloads a part to theMachine_A

Robot.UnLoad(“A_Part”,“Machine_A”)

The Robotunloads a part from theMachine_A

Robot.Load(“A_Part”,“Machine_B”)

TheRobotloads a part to theMachine_B

Robot.UnLoad(“A_Part”,“Machine_B”)

The Robotunloads a part from theMachine_B

Machine_Ais taken over byMachine_B, the activityRobot.-Load (“A_Part”, “ Machine_B”) is accorded a higher prior-ity than the activityRobot.Load (“A_Part”, “ Machine_A”).Therefore, in theRobotprocess, theQ_Load_Bis alwaysscanned first after an activityRobot.UnLoad (“A_Part”,“Machine_A”).

There are only six pairs of activities that can run in paral-lel. They arePart.Run_Machine_A() andPart.Run_Machi-ne_B (), Part.Run_Machine_A () and Robot.Load(“A_Part”, “ Machine_B”), Part.Run_Machine_A() andRobot.UnLoad (“A_Part”, “ Machine_B”), Part.Run_Ma-chine_B () and Robot.Load (“A_Part”, “ Machine_A”),Part.Run_Machine_B() and Robot.UnLoad (“A_Part”,“Machine_A”). If the state of a machine is “Rest”, thenthe machine cannot run the rules: “R_CheckA” and“R_CheckB”.

Some cases may cause deadlock. The system will bedeadlocked if there are two intermediate parts in the bufferand the robot is unloading a part fromMachine_AwhileMachine_Bis running somewhat later thanMachine_A.

7. Conclusion

In this paper, an active database, which is based on anintegration of an object-oriented database and an expertsystem, is presented. Knowledge is represented in ECArules. Since all components of ECA rules are first-classobjects of ObjectStore, the rules can be specified dynami-cally and independently of application programs. The RuleManager is able to detect primitive and composite events.The features of the Primitive and Composite Event Detectorhave been described. These include support for parameterpassing, consumption modes and new event constructors.By providing an active database with a rich set of eventconstructors, event specification can be enhanced. Theneed for a more expressive and powerful active database,as far as the event detection capability is concerned, is oftentranslated into the need for more composite events to besupported. Thus, the ability to specify and monitor a richset of events enhances the power of the active database tocater for a wider range of application domains.

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144 143

Fig. 5. The rules derived from the case study.

References

[1] S.B. Zdonik, D. Maier, Fundamentals of object-oriented databases,Readings in Object-oriented Database Systems, Morgan Kauffman,Las Altos, 1990.

[2] A. Geppert, S. Gatziu, K. Dittrich, Architecture and implementationof the active object-oriented database management system SAMOS,Computer Science Department, University of Zurich, 1995.

[3] M. Berndtsson, ACOOD: an approach to an active object-orientedDBMS, Department of Computer Science, University of Skovde,Sweden, 1991.

[4] U. Dayal, B. Blaustein, A. Buchmann, et al., The HiPAC project:combining active databases and timing constraints, ACM-SIGMODRecord 17 (1) (1998) 51–70.

[5] Y. Dong, A. Goh, An intelligent database for engineering applica-tions, Artificial Intelligence in Engineering 12 (1/2) (1998) 1–14.

[6] Y. Dong, C.F.Y. Chee, Y. He, A. Goh, Active database support forSTEP/EXPRESS models, Journal of Intelligent Manufacturing 8 (4)(1997) 251–261.

[7] C. Lamb, G. Landis, J. Orenstein, D. Weinred, The ObjectStore data-base system, Communications of the ACM 34 (10) (1991) 50–63.

[8] S. Gatziu, K. Dittrich, Events in an active object-oriented databasesystem, Rules in Database Systems, Workshops in Computing,Springer, Berlin, 1993.

[9] S. Gatziu, K. Dittrich, Time issues in active database systems, in:International Workshop on an Infrastructure for Temporal Databases,Arlington, Texas, June 1993.

[10] A. Deutsch, Method and composite event detection in the REACHactive database system, Technical University Darmstadt, July 1994.

[11] S. Gatziu, A. Geppert, K. Dittrich, The active database managementsystem manifesto: a RuleBase of ADBMS features, ACM SIGMODRecord 25 (3) (1996) 40–49.

C.W. Tan, A. Goh / Knowledge-Based Systems 12 (1999) 137–144144

Fig. 5. (continued)