Semantics Based Implementation of Flexible

Semantics Based Implementation of Flexible Execution Models for Active Database Systems Thierry Coupayey  [email protected]

Christine Colletz [email protected]

EMBL Outstation, The European Bioinformatics Institute, Wellcome Trust Genome Campus, Hinxton, Cambridge CB10 1SD, U.K. z IMAG-LSR, BP 72 38402 Saint-Martin d'H eres, France. y

Resume

Cet article presente notre approche pour la construction de modeles d'execution de regles pour bases de donnees actives. Il introduit un cadre a la fois informel et formel pour la conception et le developpement de moteurs d'execution de regles adaptes a des utilisations particulieres des regles dans les applications (par exemple pour la veri cation de contraintes, le calcul de valeurs, la gestion de versions, etc.). Le coeur de notre approche est un modele d'execution parametrique et sa semantique fonctionnelle qui peut ^etre utilisee eectivement comme une speci cation implantable (une sorte de standard) de moteurs d'execution

exibles et portables car independants des modeles de donnees et d'evenements proposes. Le modele denomme FL'ARE est base sur des dimensions caracterisant l'execution de chacune des regles considerees isolement et de modules de regles. Les dimensions sont organisees en constantes et parametres selon trois niveaux d'utilisation (pour une regle, pour les regles d'un module, pour divers modules). Une telle approche apporte la exibilite en autorisant l'integration de dierents modules dans la m^eme application chacun d'entre eux ayant sa propre semantique d'execution liee a l'utilisation que l'on souhaite pour ses regles. : Bases de Donnees Actives, Regles Actives, Decomposition des fonctions actives, Moteur d'execution de regles.

Mots-cles

Abstract

This article presents an approach to build generic rule execution models for active databases. It introduces a framework that provides both informal and formal supports to design and develop rule execution engines well adapted to dierent uses of rules and to predict and understand the resulting behaviour of active applications. The framework may be seen as an implementable speci cation (a standard). The core of our approach is a parametric execution model and its functional semantics that can be used as a speci cation for the implementation of exible and portable execution engines whatever the data models and the event models of the underlying DBMS are. The model called FL'ARE is based on dimensions characterizing the execution of rules and rule modules. Dimensions have been organized as constants and parameters into three layers. Such an approach allows the integration of heterogeneous rule modules within the same application, each of them having its own semantics based on the service it is intended to support. Key words:

Active Databases, Active Rules, Unbundling Active capabilities, Rules Execution Engines.



The work presented here was done while the author was at the IMAG-LSR, Grenoble, France.

1 Introduction Active Database Systems are able to execute automatically prede ned actions in reaction to speci c events when some conditions are satis ed. Most of active systems are based on the concept of active rules of the form Event-Condition-Action (ECA). The basic semantics of an ECA rule is: \when an event of type E occurs, if conditions C is true then execute action A". Events are generated internally or externally to the system itself and detected in some way by the system. Conditions are generally predicates on database states expressed with a query language. Actions can be any sequence of operations on the database or outside the database. Generally speaking, the processing of rules is handled in a speci c environment de ned as an active database application including transactions. Potential application domains for active rules are numerous. They range from classical database applications (management application, nancial and banking applications) to cooperative work or process (document editing), software engineering, process control, multimedia or real-time applications, etc. Potential and actual active database applications have been investigated ([CW90, CW91, BCMP94, CS94, CW94, CFPT94, WC96]). As a consequence to these various uses of active rules, many active database systems models or prototypes have been proposed ([Da86, SHH87, DBB+ 88, AG89, Han89, WF90, BM91, DPG91, BBKZ92, SKM92, CAM93, CCS94, KRRV94, CFPT95a]). Database products ([Ing92, Ora92, Syb92]) and standards ([MM95]) proposals include similar mechanisms. Active rule languages and integration of rules in various data models (relational, NF2, object-oriented) have motivated numerous works. Events represent a research domain in themselves in the active database eld ([GJS92, NG92, GGD93, GD94, CM93, MPC96, CC96]) { but also in other elds (real-time systems, arti cial intelligence, etc.). However, if most active systems dier on these aspects, they mainly dier on their behaviour. Large scale applications making intensive use of active rules are very few because the use of rules is still problematic. First there is, for the time being, a crucial lack of design and conception methods dedicated to the use of active rules albeit some works are now emerging ([FRG96, CF97]). Second, use of active rules represent a new programming style very distinct from procedural, functional or logical programming. The third and main reason is that it is very dicult for programmers to understand the overall behaviour of the rule system, i.e., when and how a set of inter-related rules (rules triggered simultaneously by a same event or by several events, cascading rules, etc.) will be executed within the framework of the classical management of transactions. The latter aspect, described by the rule execution model, is especially important when looking at dierent active rule systems as it actually de nes the power and relevance of the proposed active capabilities. [DGG95] discusses which functionality an active system should exhibit in order to meet given requirements of certain types of applications. Such proposals give general guidelines for de ning adhoc execution models for speci c active applications. However, one cannot develop a new execution model every time rules are adopted for encoding some functionality of a new type of application. Furthermore, dierent kinds of rules with their own semantics would probably have to coexist in the same application. None of the existing systems matches these needs. We thus claim that there is a need for a framework that allows to build exible active rule execution models. The aim of such a framework is not to provide a ready-to-use implementation of a rule execution engine but more an implementation speci cation (a sort of standard). Only such a speci cation will be able to t any kind of use in any kind of application. For the time being, only very few works have appeared in this direction, proposing a framework to develop rule execution engines and to understand the resulting behaviour of active applications. Providing such a core execution model is a base

for comparing active database systems and may help commercial systems to adopt the technology. The work presented here contributes precisely to provide such a framework. It is based on a parametric execution model and its functional semantics that can be used as a speci cation for the implementation of exible and portable execution engines. By \portability", we mean that the model is independent from the data/rules/events models and languages of the underlying DBMS. The remainder of this paper is organized as follows. Section 2 gives an overview of our approach. It describes how the model was constructed and introduces in a very informal way its general features. Section 3 details the constants and parameters characterizing the behaviour of one rule. Section 4 describes the execution policies for rules in a module (i.e. a set of rules). Section 5 discusses the interaction between rule modules or intermodule executions. Section 6 introduces the formal semantics of the model. Section 7 compares our proposal with other existing works. Finally, Section 8 concludes this paper and introduces some future research directions.

2 Overview of the Approach 2.1 Methodology

We rst de ned a taxonomy [CC97, CC98] that uses dimensions as in [PDW+ 93, Dia95, FT95] for characterizing and comparing execution models of existing active DBMS. We proposed an exhaustive set of dimensions and consistent values for each dimension. At least, to our knowledge, it is the richest taxonomy (21 dimensions, 52 values) existing at the date the work ([Cou96]) was done. Compared to existing works [PDW+ 93, Dia95, CFPT95b, FT95], using also the dimension concept, we concentrate on the execution of rules and we do not consider characteristics of the event detection process. Furthermore, we structured the resulting dimensions into two main classes: dimensions characterizing the behaviour of one rule and dimensions characterizing the behaviour of a set of rules. We have also provided a graphical representation of active database execution models in order to facilitate the use of our taxonomy [CC98]. Most active rule database systems1 have been studied using our framework (taxonomy and graphical representation). This study showed that there exists a great diversity of approaches. Basically, each system oers a subset of the set of possible dimensions and values and above all it only oers some combinations of values for these dimensions. This means that a same set of rules, or rule base, would have a completely dierent behaviour when executing on each system and the user has no means to have control over this behaviour. Current rule execution engines are in some sense too rigid: they appear well adapted for some kind of rule uses and active applications, but not for others. This result incited us to propose a generic framework to provide some exibility in the behaviour (execution model) of active database systems so that they could t any kind of use in any kind of application. Further we wanted this framework to be as portable and formal as possible for standardization reasons. To achieve this objective we propose the (core) Flexible Active Rule Execution (FL'ARE) model that provides the basic concepts for describing the execution of rules. We also provide a formal description of this model. 1 A-RDL [SKM92], Ariel [Han89], Beeri & Milo [BM91], Chimera [CFPT95a], EXACT [DPG91], HiPAC [DBB+ 88], Informix, NAOS [CCS94, Col98], Ode [AG89], Oracle [Ora92], Postgres [SHH87], REACH

[BBKZ92], SAMOS [Da86], Sentinel [CAM93], Starburst [WF90], TriGS [KRRV94].

2.2 The FL'ARE Model

FL'ARE is not yet another rule execution model but might be considered as a proposal of standard for active rule execution models. To de ne this model we turned the dimensions of our taxonomy into constants and parameters. Parameters can take values only within a set of prede ned values. Parameters are independent: all combinations of values are valid and all lead to deterministic executions. The model is exible since it is parametric and modular. You can de ne many dierent execution models simply by giving values to parameters. It is modular since it allows to structure rules into modules that can be heterogeneous: rules within a module may have dierent behaviours and processed according to several policies. FL'ARE is structured into three layers:

 layer I manages the execution of a rule; it consists of eight constants and ve pa-

rameters whose actual values specify the execution of each rule.  layer II manages interactions between rules of a module or intra-module executions; it consists of a parameter which may take a value among four values, each of them representing an execution policy for the module.  layer III manages global or inter-modules executions, i.e., interactions between different rules belonging to several modules.

By its generic nature, FL'ARE allows to support dierent rule systems in one active database. Assume for instance having two distinct active databases with two rule bases. Then, one wishes to merge the two databases but to keep the same behaviour for the two rule bases so that rules do not have to be rewritten. FL'ARE can then be used as the execution engine and tuned in order that the two rule bases behave in the same way as previously { by de ning dierent modules. The other way round, FL'ARE allows to have the same execution engine in dierent DBMS. In an heterogeneous environment, rule bases de ned in an active relational DBMS and an object-oriented DBMS could have exactly the same behaviour if the two DBMS use FL'ARE as their rule execution engine. To pursue the goal of portability, we focus our work on behaviour of active systems and we make minimal assumptions about all components of an active DBMS other than the execution model. Concerning the knowledge model: the data model (relational, objectoriented, etc.), the rule model and language, the event model and language, are all indierent. Concerning rule model and language, we assume that rules are ECA rules and there exists a way to specify rule modules so that each rule belongs to exactly one module. Concerning the event model and language, we assume that events are typed but the nature of events are indierent. The only important matters with respect to the execution model are couples (event type, rule). Besides, for the time being { and this is our most restrictive hypothesis { our model is intended for a classical transaction model only. Thus, the triggering transaction is the events production unit and rules execution unit.

2.3 Formal Semantics

Building sophisticated execution models without formal foundations would very likely lead up to inconsistent or incomprehensible semantics { whatever care you take in an informal description. Thus, to prove that FL'ARE is consistent { i.e., that it is de ned completely, with no ambiguities nor contradictions { we formally de ne our model. We chose denotational semantics because a denotational de nition is more abstract and general than an operational one, for it does not specify computation steps. Further, we

think that such a semantic gives a language-independent framework of semantical concepts that would help to standardize active database execution models. The formal semantics of FL'ARE actually expresses the execution model, i.e., the mechanics of rule execution. It is a function ModelExec that: 1. takes as arguments: a database state, a set of rule modules and a set of events produced by the execution of an operation of a transaction; 2. builds the list of rules to be processed; 3. describes state changes of rules and rule modules due to (cascaded) rule executions; 4. nally returns the database state that results from these executions. A formal description makes a model usable both by implementors and end-users. As already explained, we tend to be most concerned by implementors since our goal is to provide a framework suited for implementing rules execution engines. Thus the functional semantics can be used completely or partially to implement exible rule execution engines and also to clarify similarities and dierences between active database execution models.

3 Execution of a Single Rule

In this section, we are interested in the behaviour of one rule. Figure 1 exhibits the three steps and the ve states of the execution of a rule2:

 the triggering is the process by which a rule goes from a triggerable state, to a

triggered state, after some events have happened, one of them being a triggering event for the rule;

 the evaluation step corresponds to the evaluation of the Condition part of the rule.

If the condition is satis ed then the rule goes to an evaluated state, otherwise it comes back to the triggerable state (we assume as in most active systems that there is not side eect in the evaluation of a rule: the evaluation of a rule cannot generate events and thus triggers rules);  the A-execution is the process in which the execution of the Action part of the rule takes place. At the end of the execution the rule comes back to the triggerable state. Execution stands for the complete process triggering/evaluation/A-execution. The end of the A-execution is thus also the end of the rule execution. evaluation (to false)

events

signal

triggerable rule

triggering triggered rule

evaluable rule

evaluation (to true)

evaluated rule A-executable rule

production

A-execution

Figure 1: Execution of a rule A triggerable rule becomes triggered as soon as a triggering event occurs. However, as suggested in Figure 1, a triggered rule is not necessarily evaluated immediately. In the 2 The diagram can be seen as a kind of nite state automaton in which there is no really accepting state;

or in which all states are accepting states. Also not all transitions are represented.

same way, an evaluated rule is not necessarily A-executed immediately. Transitions { that could be quali ed as \hidden transition" { from states triggered and evaluated to states evaluable and A-executable respectively, depend precisely on the values of the parameters described hereafter (mostly the sf execution mode).

3.1 Parameters

Parameters that act upon the execution of one rule are given in Table 1.

Parameter 1 The execution mode speci es when a rule is evaluated and A-executed with

respect to the triggering transaction. If the rule is an immediate rule, it is evaluated and A-executed immediately after it has been triggered. If the rule is a deferred one, it is evaluated and A-executed at the end of the triggering transaction (just before its validation). If the rule is a delayed one, it is evaluated immediately but A-executed at the end of the triggering transaction. Parameter 2 The event processing mode speci es how events are considered with respect to (the number of) rule executions. If a rule has an instance-oriented-semantics, it is executed for each triggering event. If a rule has a set-oriented-semantics, it is executed once for the set of triggering events. Considered events are those produced since the beginning of the triggering transaction or since the last execution of the rule in this triggering transaction. parameter

1 2 3 4 5

value immediate execution mode deferred delayed instance-oriented event processing mode set-oriented event consumption mode consummation preservation pre-emption pre-emption mode no pre-emption yes net eect no

Table 1: Parameters of the execution of one rule

Parameter 3 The event consumption mode speci es how an event ei that has caused the

execution of a rule is handled. If the rule consumes events, ei is taken into account just for one execution of the rule. If the rule preserves events, ei is taken into account for all executions of the rule occurring after ei until the end of the triggering transaction. Parameter 4 The pre-emption mode speci es the relationship between a rule R and a rule R' triggered by the execution of R. If R' has a pre-emptive right, the execution of R will be suspended until the end of the execution of R'. If R' has no pre-emptive right, triggering events of R' are stored until the end of the execution of R, and then are considered for the execution of R'. Parameter 5 The net eect of a sequence of operations is the result of these operations that persist at the end of the sequence. For instance, if a sequence of operations creates and then destroys an object, the net eect is null. If a sequence creates two objects a and b and then destroys a, the net eect is the creation of b. In our model, one can specify if the net eect must be taken into account or not, for the execution of each rule. When the net

eect is considered, it is both for rule triggering and construction of event environments (i.e., data associated with triggering events).

3.2 Constants

Constants of the execution model of one rule are given in Table 2. There are two major reasons for having turned the eight dimensions (scope of events, instant of events consumption, substitution of triggering operation, etc. given into Table 2) into constants. The rst reason is that we want to provide parameters independence (orthogonality): constants 1 to 3. The second reason is that we assume a classical transaction model: constants 4 to 8. constant value 1 scope of events consumption local 2 instant of events consumption evaluation 3 substitution of triggering op. no 4 transaction mode same trans. 5 synchronism mode synchronous 6 dependency mode dependent 7 fail of Triggering Trans. TT abort TT 8 fail of Rule Trans. abort TT Table 2: Constants of the execution of one rule

Constant 1 The dimension scope of events consumption has two values: local and global. Consider a rule R executed for a triggering event e. If R has a local events consumption, e will not be visible in later executions of R but it still can trigger some others rules. If R has a global events consumption, e will be ignored in later executions of R but also in later executions of all other rules (thus e will have caused the execution of only one rule). If this dimension was considered as a parameter with global as a possible value, parameters of layer I and II of our model would not be independent anymore since a global event consumption by a given rule R has an impact on the execution of a rule set (rules triggered by the events that have triggered R). Constant 2 In our model, the events consumption always takes place at Evaluation: a rule triggered by an event set se is executed once. Consumption of events at the execution of the Action { as in early papers on Starburst [WF90] { means that a rule whose condition has been evaluated to false could be considered several times for the same triggering event set. The problem is then to determine when the rule has to be considered again. Intuitively, one shall consider that the answer would be \when the Condition is evaluated to true". This sounds very much like production (in deductive systems) rules semantics { not active rule semantics: an active system reacts to some events and not to predicates on database states. Also, consumption of events at the Execution stage would imply that some rules may be triggered, but never executed and thus stay triggered until the end of the triggering transaction { causing a non termination of the rule execution process. Finally, as mentioned above, only one system, namely Starburst, proposed the events consumption at the Execution but did not implement it, mainly because it is extremely dicult to de ne the precise semantics associated to this events consumption policy. For all these reasons and as [Pic95] we consider this possibility as cosmetic and we have not integrated it into our model. Constant 3 We do not oer the possibility of executing a rule by substituting the triggering operation as in Postgres or NAOS (INSTEAD clause) because if we did it our model would

not be independent from data and events models. Substituting the triggering operation is feasible only for some kinds of events, mainly data manipulation events, but not for temporal, external and composite events. The system would have to cancel { undo or not execute at all the triggering operation { which is strongly related to the data model and more generally to the underlying DBMS. Besides, parameters of layer I and II would not be independent since the substitution of the triggering operation by a rule can have an impact on the triggering of some other rules. Constants 4 to 8 The interaction between active rules and the underlying transaction model is an important aspect of rule execution model. For the time being, FL'ARE only considers classical transactions with ACID properties; nested or separated transactions are not considered. Constants 4 to 8 follow that hypothesis. Rules Ri triggered in a triggering transaction are executed in that same transaction (constant 4), in a synchronous and dependent way (constant 5 and 6). The failure of a triggering transaction TT (constant 7) or a \rule transaction" (constant 8) causes the abortion of TT. Rules triggered during TT (and not yet executed) will never be executed.

4 Interactions Between Rules This section details the behaviour of a module of rules, more precisely, the interactions between these rules (intra-module executions). It introduces the general execution process of a module and presents the four proposed execution strategies. evaluated rules A-executable rules

events

signal

triggerable rules

evaluable rules triggering

evaluation (to true)

rule to be treated

selection

triggered rules evaluation (to false) A-execution

production

Figure 2: Execution of a module Figure 2 depicts the execution of a rule module. The triggering step is identical as the one described in Section 3 except that this time n (n  1) rules are triggerable, and consequently, m (m  n) rules among them become triggered. Then, at each execution point the rule execution engine has to determine { by a scheduling process { when and how the m rules will be executed. Basically, an execution point is a point (in time) of the triggering transaction at which the active rule execution engine is woke up for executing rules. The scheduling process considers the set of evaluable and A-executable rules in order to select the next rule to treat. Once a rule is selected, it is evaluated or A-executed:  a rule in the evaluable state is evaluated. If the result of the evaluation is false then the rule comes back to the triggerable state (dashed arrow in Figure 2) and its execution stops. If the rule is evaluated to true, it goes to the evaluated state;  a rule in the A-executable state is executed and comes back to the triggerable state. Then, its execution stops.

The selection/evaluation/A-execution general process iterates on the set of evaluable and A-executable rules. It is described by the generic algorithm given here after. 1. build up the list L of rules to be processed (evaluable and A-executable rules) 2. select in L the next rule R that has to be processed; process R; insert in L (and eventually process) rules triggered by the execution of R 3. remove R from L 4. if L is not empty then go back to 2

Parameters introduced in Section 3 are taken into account in steps 1 and 2 of the algorithm through the actions build up and process. select is the action through which interactions between rules are managed. Note also, that there can be several occurrences of the same rule in the list L (for instance, rules with the instance-oriented event processing mode triggered several times in a same transaction). There are dierent ways of selecting the next rule to process and consequently dierent module execution strategies. We consider the following four strategies (see Table 3). parameter

value priorities ( at execution) (FIFO) 6 execution strategy pipelines depth rst (LIFO) cycles (width rst) Table 3: Intra-module execution strategies The triggering instant of rules, the priorities between rules and the execution cycles are used as foundations of the proposed strategies. They provide four orders:  the triggering order is based on the triggering instant of each rule3 . This order is partial since several rules (or rule occurrences) may have the same triggering instant;  the reverse triggering order (also partial);  the priorities order: we assume there exists a total ordering between rules belonging to a module; it may be speci ed by the programmer or by the system (see [WCL91, CCS94]);  the execution cycles order: an execution cycle is a logical unit of processing in which are executed the triggering transaction (cycle 0) and one or several rules. A rule triggered in a cycle n will be handled in a distinct cycle n+1. All rules of cyle n are executed before rules of cycle n+1. Inside a cycle, rules are processed according to their priorities. Table 4 shows how the execution strategies take into account these orders for building a deterministic execution model (a total order between rules). The strategy by priorities considers (1) the priorities between rules and then (2) the triggering order if there are several occurrences of the same rule. The strategy by pipelines 3 The triggering instant of each rule is itself based on the instant of occurrence of triggering events and also depends on the event processing mode. Due to lack of space, we do not discuss these points more deeply.

order strategies priorities trigg. rev. trigg. cycles priorities 1 2 pipelines 2 1 depth rst 2 1 cycles 2 3 1

Table 4: Construction of execution strategies (respectively in depth rst) considers (1) the triggering order of rules (the reverse triggering order) and then (2) the order of priorities if several rules have the same triggering instant. The execution by cycles considers (1) the cycles order then (2) the order of priorities between rules and, then (3) the triggering order if there are several occurrences of the same rule in a given cycle. The following section gives an illustrative example of two strategies: in depth rst and by cycles.

5 Interactions Between Rule Modules This section presents the mechanism we proposed for managing inter-module executions (or global executions). It also shows how to use the FL'ARE model to obtain a speci c execution model. Execution of modules by priorities is in fact the only conceivable strategy since the notions of triggering instant and execution cycle used to build the proposed strategies have a meaning only when considering single rules { as opposed to rule modules for which these notions are irrelevant. The following explains the Inter-modules execution strategy. Let us consider Ms, a set of rule modules. Ms = fMi g where 1  i  n and each Mi is a module, i.e., a totally ordered set of rules to which is associated one of the four execution strategies. Ms is also completely ordered by priorities between modules.

Principle At each execution point, a rule is selected in each module Mi and the one with the highest priority is nally selected and processed.

Use of the model Let us consider two rule modules I = f I1, I2, ... , Ing and D = f D1, D2, ... , Dmg such that: 1. all rules of I have the same rule execution model given in Table 5. 1 2 3 4 5

parameter execution mode event processing mode event consumption mode net eect pre-emption mode

value immediate instance-oriented consumption yes pre-emption

Table 5: Parameter values for Module I 2. all rules of D share an other rule execution model given in Table 6. 3. module I is executed with the in depth rst strategy;

1 2 3 4 5

parameter execution mode event processing mode event consumption mode net eect pre-emption mode

value diered set-oriented consumption yes no pre-emption

Table 6: Parameter values for Module D 4. module D is executed with the by cycles strategy; 5. module I has a higher priority than D. Let N be a rule module such that N = I [ D. Furthermore, let us assume that in each module, rules priorities are represented by their numbers. For instance in I (resp. D), the rule with the highest priority is I1 (resp. D1), the rule with the lowest priority is In (resp. Dm). cycle 0

TD 1

2

I1

cycle 1

D1 I2

D2

4

D4

6

I3

5

cycle 2

D5

7

I4

3

D3

8

Figure 3: Global execution of rules Consider now rules of Figure 3. At the end of a transaction TD, two rules D1 and D2 are triggered, the rule execution processing starts. D1 is selected because it has the highest priority. Its execution triggers I1, I2 and D4. Rules selected in each module are: I1 for I and D2 for D. I1 is then selected because I has a higher priority than D. The global execution order of N is depicted in Figure 3 by dashed arrows. At a given point of the execution, all rules of I have been executed. D2, D4 and D3 have to be processed (they have been triggered in that order). D2 is processed rst because it belongs to cycle 1 . Afterwards D3 is selected because it is the rule with the highest priority in cycle 2 (all rules of cycle 1 have been already processed). Note that D3, D4 and D5 belong to the same cycle because cycles are computed (for each module using this strategy) transitively with respect to the global triggering tree. Thus we consider that D3 and D4 are both triggered by D1. Note that under the hypothesis we made, the execution model of N built using FL'ARE is the one of the existing active rule system NAOS [CCS94, Col98]. We show ([Cou96]) in the same way that most functionalities of most existing active systems can be covered by FL'ARE4 . This shows the power and genericic nature of the model. 4 See footnote in page 3 for a complete list of these systems.

6 Formal Semantics of the Model The formal foundation of our work is a denotational semantics of FL'ARE. Basically, a denotational semantics [Sto77] of a language or a system is de ned as a set of algebras and a set of valuation functions on these algebras. The complete denotational semantics of FL'ARE exhibit 8 domains and 25 functions. Due to space limitations, the complete formal de nition of the model cannot be given here (interested readers may refer to [Cou96]). However, we give in the following an outline of domains and functions that formally de ne FL'ARE. We also discuss the important role of formal semantics in our work.

6.1 Domains

An algebra is a domain (de ned as a set in our case) and a set of operations on this domain. Operations we de ned on our domains are few and generally simple. Also, in the following, we speak about domains rather than algebras. Domains represent the knowledge model of an active DBMS. They express informations about database states, operations that constitute transactions, events and rules. Our domains can be divided into two categories. Static domains remain unchanged by rule execution: these are domain of rules and domain of rule modules. Dynamic domains evolve with rule executions: domain of treated rules (or to be treated) and domain of modules of treated rules. As an example we give hereafter the de nition of the two latter domains. Let RT be the domain of treated rules: RT = R  P (E )  IN  IN  STATE with STATE = fwaiting, executedg, E the set of events and P the powerset operator. Let rt =< r; es; t; c; s > be a rule in RT , rt is a triggered rule waiting to be evaluated or/and executed (s=waiting) or a rule already executed (s=executed). es is the set of triggering events taken into account for the evaluation and the execution of the rule r. t is the triggering instant of r. c is the identi er of the cycle in which r will be treated. This cycle is relevant only if the module which rule r belongs is executed with the strategy by cycles. Let MT be the domain of modules of treated rules: MT = P (RT ), P is the powerset operator. Let mt be a module in MT : mt = frt1; rt2; :::; rtng = f< r1 ; es1; t1; c1; s1 >; < r2; es2 ; t2; c2; s2 >; :::; < rn ; esn ; tn ; cn; sn >g Let EDB the set of database states.

6.2 Valuation Functions

Functions actually express the execution model, i.e., the mechanics of rule execution. The denotational de nition of FL'ARE is a function ModelExec which:

1. takes as arguments: a database state, a set of rule modules and a set of events produced by the execution of an operation of a transaction; 2. builds the list of rules to be processed; 3. describes state changes of rules and rule modules due to (cascaded) rule executions; 4. nally returns the database state that results from these executions. Of course, for readability and modularity, the function ModelExec is de ned from more elementary functions that express precise and distinct tasks. The higher level decomposition ModelExec exhibits the three general steps in a rule execution process:

 triggering of rules: the function Trigger constructs the sets of rules that have to be

executed according to incoming triggering events;  selection of rules: functionsProcessModules, SelectModule and SelectRule select a rule at each step of the execution according to the priorities between modules, the execution policy for the selected module, and nally the execution model of each rule in this module;  processing of a rule: functions ProcessRule and ExecRule take care of the actual processing (evaluation or evaluation and A-execution) of the selected rule. These functions are themselves decomposed into even more elementary functions in order to take into account all dimensions of rule execution: event processing mode, event consumption mode, preemption mode, execution mode and net eect. The execution and premption modes are the most complex to deal with for they in uence the synchronisation between (1) the triggering transaction and the rule execution process and (2) between rules. We use some \operation counters" that model the steps of rule processing, i.e., the sequential execution of the operations of the triggering transaction and/or Action part of rules. Functions are expressed using the Church -calculus (Lambda-calculus) [Hin86]. We describe hereafter the main functions we cite above. Due to lack of space, we omit the triggering phase and focus on the selection and processing of rules. The overall process of rule selection and execution is expressed by the function ProcessModules:

ProcessModules :P (M )  OM  OR ! EBD  P (MT )  P (MT )  IN  P (E ) ! (EBD  P (MT )  P (MT )  P (E )) _ f?g ProcessModules[ms; oM ; oR] = pppf (CM:  < ebd; mts; mtsftd; tc; estd; ftd > : if (Triggered(ms; mts) = ;) then < ebd; ;; mtsftd; ; > else let rt = SelectRule(oR)(SelectModule(oM )(mts)) in CM(ProcessRule(rt; ebd; mts; mtsftd; tc; estd))) elsif 2 The function ProcessModules takes as arguments (1) a set of modules ms, (2) an ordering over modules oM and (3) an ordering over rules oR . It returns the least xed point pppf (the function ProcessModules is in fact a recursive function) of a function CM. CM takes (1) a database state ebd, (2) a set of modules mts to be processed \immediately", i.e. during the triggering transaction TD, (3) a set of modules mtsftd to be processed at the end of TD, (4) an integer tc which is the current operation counter, and (5) a set of events estd which contains the set of all events produced since the beginning of TD. If no rule is (still) to be processed in mts or mtsftd then CM returns < ebd; ;; mtsftd; ; > otherwise CM selects a rule rt in the module with the highest priority and applies itself on (1) the new database state, (2) the new set of modules to be processed during sf TD, (3) the new set of modules to be processed at the end of TD and (4) the new set of events produced since the beginning of TD.

The function SelectModule expresses the inter-module (global) execution model as described in section 5. The rst step in the process consists of choosing the module with the highest priority: SelectModule : OM ! P (MT ) ! MT SelectModule [oM ] = fmt1 ; mt2; : : :; mtn g: mti where 1  i  n ^ fmtj j 1    n ^ mti M mtj g = ;g

2

The function SelectModule take as arguments (1) an ordering over modules oM and (2) a set of modules to be processed fmt1; mt2 ; : : :; mtn g. It returns the module with the highest priority in the given set (such a module always exists since we consider (M; M ) is a chain, i.e., a total ordering). The next step is to choose a rule belonging to the selected module. This is expressed by the function SelectRule: SelectRule : OR ! MT ! RT SelectRule[oR] = mt: case (mt # Strategy) between priorities : FirstTriggered(HighestPriorities(oR)(mt)) pipelines : HighestPriorities(oR)(FirstTriggered(mt))) depth rst : HighestPriorities(oR)(LastTriggered(mt)) cycles : FirstTriggered(HighestPriorities(oR)(LowestCycle(mt))) endcase

2

The SelectRule function selects the next rule to be treated in a given module according to its execution strategy (denoted by mt # Strategy ) (see Section 4. Given an ordering OR on rules of the module, SelectRule takes as argument a module of rules to be processed mt and returns the next rule in mt that will be treated (evaluation of the Condition or/and execution of the Action). Then the selected rule is actually processed: ProcessRule : P (M )! RT  EBD  P (MT )  P (MT )  IN  P (E ) ! EBD  P (MT )  P (MT )  P (E ) ProcessRule[ms] =  < r; es; t; c; e >; ebd; mts; mtsftd; tc; estd: case (r(ebd; es; ) # ExecutionMode) between immediate : ExecRule(ms)(< r; es; t; c; e >; 1; ebd; mts; mtsftd; tc; cc; estd) delayed : EvalRule(ms)(< r; es; t; c; e >; mts; mtsftd)

2

endcase

The function ProcessRule takes as arguments (1) a set ms of modules, (2) a rule to be processed rt, (3) a database state ebd , (4) a set mts of modules of rules to be processed during the triggering transaction TD, (5) a set mtsftd of modules of rules to be processed at the end of TD, (6) an integer tc which is the current operation counter and (7) a set of events estd which contains all events produced since the beginning of TD. If the rule r is immediate (r( ; ; ) #ExecutionMode=immediate), it is evaluated and executed. If r is delayed, it is simply evaluated. We assume that the evaluation of rule Conditions has no side eect, i.e., it does not modify the database state nor generate events. The evaluation of a delayed rule by the

function EvalRule thus simply consist in \transferring" this rule from the set of modules of rules to be processed during the triggering transaction to the set of modules of rules to be processed at the end of the triggering transaction. The actual execution of a rule is expressed by the function ExecRule. As one could guess, this function is the most complex one { because of the synchronization between the triggering transaction and the execution of rules and between rules (rules interrupted by other rules). We give here a simpli ed description of ExecRule. The function takes as arguments a set of rule modules ms and returns the least xed point of a function ER. ER takes as arguments (1) the rule rt =< r; es; t; c; e > to be executed, (2) the operation of the Action part of r to be processed (3) a database state ebd, (4) a set of rule modules mts to be processed during the triggering transaction TD, (5) a set of rule modules mtsftd to be processed at the end of TD, (6) an integer tc which is the current counter and (7) a set of events estd which is the set of events produced since the beginning of TD. If the execution of r is terminated (op is the last operation of the Action part of r), ER returns a triplet formed of (1) the new database state resulting from the execution of the operation op, (2) the new rule modules resulting from inserting the rules triggered by the events produced by op5 and (3) the new set of events estd which results from inserting the events produced by op. If the execution of r is not terminated, ER treats all preemptive rules triggered by the execution of op. Then ER applies itself to treat the next operation op + 1 at step tc + 1 of the Action part of r on the new database state, new set of events, etc. resulting from the execution of op and preemptive rules triggered (and executed) by op. Note that the function ProcessRule is never applied on a diered rule since no processing at all is done for deferred rules during the transaction (all processing is done at the very end of the transaction). This is why the case deferred is not considered in the function. More generally, as we have seen in previous sections, the rule processing is quite dierent during the triggering transaction and at the end of the triggering transaction. This duality is represented in the formal semantics by a duplication of the most important functions: ProcessModules and ProcessModulesETD (ETD for End Triggering Transaction), SelectRule and SelectRuleETD, ProcessRule and ProcessRuleETD, etc..

6.3 Contributions of Formal Semantics

Some works have eventuelly appeared on formal semantics of active rule execution models: some ([Zan93, Beh94, PV95, FT95, GMS96]) use more or less operational semantics (evolving algebras, relational machines, etc.). Others ([Wid92, CC95]) use denotational semantics. Besides, [PCFW95] is a comparative study of formalisms used to specify active DBMS. In our work the formal semantics has three main contributions. First, it provides a description that is complete, precise and without ambiguities. This cannot be done with a natural language because of the several possible combinations of parameters. Second, this work provided a feedback on our model. For instance, we discovered some inconsistencies in early versions of FL'ARE, like the ones introduced by the strategy Choice of one rule (used by Postgres and most commercial DBMS including triggers or rules). This is why this strategy is not proposed in FL'ARE. Finally, and this was our major goal, it suggests solutions for the implementation of the model. This is also why we chose denotational semantics. From our experience, denotational semantics seemed laborious at the beginning but it quickly became natural and nally easy to use because there are only two concepts used: domains (that are basically sets) and functions. It provides compact and 5 A single operation may generate several events in case of composite and temporal events.

shorts descriptions { which is not the case with operational semantics descriptions in which there are often an explosion of the number of states and transitions. It provides elegant descriptions like the functions given above and an algorithm directly implementable in a functional language (LISP, ML, etc.) or easily implementable in an imperative language.

7 Related Works 7.1 Heraclitus

The goal of the Heraclitus project [HJ91, SGJ93] is to develop a Database Programming Language (DBPL) and other techniques in order to specify and implement interchangeable execution models for active relational DBMS. The Heraclitus language is an extension of the C language that supports the relational algebra and novel constructs related to the speci cation of the semantics of active systems. The core of the approach is the delta. A delta is a value in the language that represents a potential update, i.e., a transition from a virtual state of the database to another. Deltas can be used directly or combined to create new deltas. With the proposed algebra, it is possible to implement (or at least simulate) some of the dimensions of our model: events processing mode, events consumption mode, net eect and execution mode. Yet it is quite dicult to do so because Heraclitus does not provide neither a default execution model or any methodology to create new ones. Also, it is only intended for relational active systems in which active capabilities are based on the notion of transition.

7.2 EXACT

The goal of the EXACT (EXtensible approach to ACTive object-oriented DBMS) [DJ94, DP94] is to provide an active DBMS which is heterogeneous (dierent rule modules may have dierent semantics); extensible: (EXACT provides a standard execution model than can be extended by rede ning or adding new functionalities); and declarative (execution models are speci ed by giving values to some parameters { and not through a language as in Heraclitus). EXACT is very powerful but suers from three drawbacks. Some dimensions characterizing the execution of a module appear in the expression of rules themselves (rule objects) { this can be at least confusing for the rule programmer, lead to redundancies or even inconsistencies; Also the standard (or default) execution model is rather simplistic (for instance, there is only one execution strategy for a rule module) and the programmer has to code methods to implement the desired execution model { which is not a trivial task ! Finally, as Heraclitus is intended only for relational DBMS, EXACT is intended only for object-oriented systems.

7.3 ACTO

ACTO [MFLS96] is \An active rule system with a parametric semantics" developed at the INRIA Rocquencourt, France. As suggested by the title, the proposed approach is quite near from ours. The model provides some xed semantics components that look like our constants and some parameters. The model is also structured in three layers concerning the execution of one rule, the execution of a rule module and the execution of a set of modules. There are however some deep dierences between FL'ARE and ACTO, mostly coming from the general appraoches they represent. ACTO is focused on the architecture and implementation of a portable execution engine while FL'ARE proposed a more general framework composed of a taxonomy and a generic execution model based

on a formal approach { this framework can then be used as a guideline for implementing execution engines. However, as far as the execution model only is concerned, it is quite dicult to understand the choice of the proposed parameters in ACTO. Some parameters (e.g. granularity) do not be belong to the execution model in FL'ARE but to the event detection and production model. Some others (e.g. CA coupling mode) are associated to rule modules in ACTO while they are associated to rules in FL'ARE. We thus think that modules in ACTO are less heterogeneous and thus that the model in less exible than FL'ARE.

7.4 IDEA

In [CFPT95b, CFPT95a], authors propose a formal framework intended to specify the semantics of several active database systems. Note that this work is quite dierent from other works presented in this section since its goal is to compare existing active systems { and not to propose new execution models with the objective to implement them as execution engines. It is however interesting to presents this work here because it uses a formal approach that can be compared to ours. [FT95] proposes a taxonomy of execution models made of of 12 dimensions and not so structured than the one related to FL'ARE. The taxonomy is used in [CFPT95b, CFPT95a] to compare several systems (SQL3, Starburst, Postgres and Chimera) in a generic way using an informal semantics in natural language in which all systems are situated according to the taxonomy; a semi-formal semantics called Extended Event-Condition-Action (EECA) formalism which is a syntax allowing to represent all dimensions of the taxonomy { even though all dimensions are not taken into account by all systems; and a formal (operational) semantics called core format is then given for each system.

7.5 Lactive

In contrast [FT95], authors of Lactive [CB97] propose a declarative formalism for specifying rule execution models either for relational or object systems. The key feature of this formalism is a transition function which generates the evolution of the active database states when a sequence of actions is executed. This approach looks like ours. However, the speci cation of an active database system or the encoding of the behaviour of an existing system using this formalism needs to learn the speci c Lactive language. Like with the Heraticlus language [HJ91, SGJ93], it is possible to implement some of dimensions of our model using the Lactive language. However, it is not easy to see the dimensions that are considered and how they are structured. Furthermore, understanding the behaviour of the resulting rule system needs rst to understand the operational semantics of Lactive . Also, including the notion of event in the active database state leads on a dependence between the event model and the rule model. This approach does not seem well adapted for supporting exibility in active database systems, and mainly for providing separate active components (event detectors and rule execution engines). Note also that it is more dicult to express the net eect and execution strategy of a set of rules with the operational semantics. Such a strategy has not been described in Lactive .

8 Conclusions and Future Works This paper presented our approach to build exible active rule execution models. Our framework is an informal and a formal speci cations of a parametric execution model called FL'ARE. It is structured in three layers. Layer I is concerned with the execution of

a single rule while layer II handles the interaction between rules of a module and, nally, layer III manages interaction between modules. In FL'ARE the concept of rule module is essential { each module being intended to a speci c use of rules. The behaviour of each rule of a module can be speci ed and then the execution strategy of each module is de ned. In order to do that, the programmer simply has to choose a value for each proposed parameter among a set of already de ned values. Concerning modularity, our model diers from others proposals { Heraclitus, EXACT and ACTO { by providing heterogeneous modules: rules of a module can have the same semantics or not. We think that our approach is to a certain extent more important or innovative than the proposed model itself. Parameters and values could easily be added or suppressed. However, it is of prime importance to make a judicious choice of parameters and values in order to design a generic and exible model, but also to make a model that is easy to understand and easy to use. Some combinations may not be consistent and generate incomprehensible execution models. Detecting inconsistencies is not a trivial task. This is a major reason why we have formally de ned our model using the denotational semantics formalism. The fact that FL'ARE is de ned in a formal way makes also a dierence with other works on exible active systems { mainly EXACT and ACTO { that are not formally described at the time of this writing. FL'ARE is the rst execution model { intended to be implemented as an execution engine { that integrates both generic and formal aspects in the eld of active databases. Our framework allows for the comparison of systems and emulate most of their functionalities from their behavioural point of view. As a way for demonstrating the usefulness of our approach, we used FL'ARE for encoding the NAOS rule execution engine: this engine has been replaced with FL'ARE by using its denotational semantics as an implementable speci cation. This experiment underlined the generic nature of our model since the event detection process, the communication protocol between the event manager and the execution engine and between the execution engine and the underlying DBMS were used without any modi cation. Nevertheless, if we would like to extend NAOS in using all the prowerful capabilities of the FL'ARE model, we would have to provide an adequate rule de nition language or interface. A textual rule language might be a quite complex language and writing FL'ARE rules might then be a quite unpleasant and repetitive task. We think that a graphic interface based on forms might be suitable. However, building such an interface is not a trivial task because of the description of events environment. Also Conditions and Actions might not be independent from the execution model. Some works have to be done in this direction. Further research directions also includes investigating the introduction of new dimensions in the model, related to transaction processing and considering the distribution of data, programs, events and rules. We are currently specifying and developing a reaction service that extends the approach proposed here and that allows for the execution of rules in a global information system. Of course such a reaction service has to be coupled with a (data base) distributed event service. Such an event service is currently under development.

Acknowledgements Thanks to P. Carter (EMBL-EBI) for his careful reading. Thanks also to C. Esculier, P. Habraken, C. Roncancio (IMAG-LSR); and N. Bidoit, E. Simon for useful discussions about our work.

References [AG89]

R. Agrawal and N. Gehani, Ode (Object Database and Environment): The Language and the Data Model, Proc. of the ACM SIGMOD Int. Conf. on Managment of Data (Portland, USA) (J. Cliord (B. Lindsay) and D. Maier, eds.), June 1989. [BBKZ92] A. P. Buchman, H. Branding, T. Kudrass, and J. Zimmermann, REACH: A REal-time, ACtive and Heterogeneous mediator system, IEEE Bulletin of the Technical Committee on Data Engineering 15 (1992), no. 1-4. [BCMP94] E. Baralis, S. Ceri, G. Montelone, and S. Parboschi, An intelligent database system application: the design of EMS, Proc. of the First International Conference on Applications of Databases, LNCS 851 (Vadstena - Sweden), SpringerVerlag, June 1994. [Beh94] H. Behrends, Simulation-based debugging of active databases, Proc. of the 4th International Workshop on Research Issues in Data Engineering: Active Database Systems (Houston, Texas), 1994. [BM91] C. Beeri and T. Milo, A model for active object oriented database, Proc. of the 17th Int. Conf. on Very Large Data Bases (Barcelona - SP), September 1991, pp. 337{349. [CAM93] S. Chakravarthy, E. Anwar, and L. Maugis, Design and Implementation of Active Capability for an Object-Oriented Database, Tech. Report UF-CIS-TR93-001, University of Florida, Gainesville, January 1993. [CB97] G. Trajcevski C. Baral, J. Logo, Formal Characterizations of Active Databases: part II, Proc. of the 5th Int. Conf. Deductive and Object-Oriented Databases (Montreux - Switzerland) (K. Ramamohanarao F. Bry, R. Ramakrishnan, ed.), December 1997, pp. 247{264. [CC95] T. Coupaye and C. Collet, Denotationnal semantics for an active rule execution model, Proc. of the 2nd Int. Workshop on Rules in Database Systems, RIDS'95 Lecture Notes in Computer Science 985 (Athens, Greece) (T. Sellis, ed.), Springer Verlag, Athens, Greece, September 1995, pp. 36{50. [CC96] C. Collet and T. Coupaye, Composite Events in NAOS, Proc. of the 7th Int. Conf. on Database and Expert Systems Applications(DEXA'96) (Zurich Switzerland), September 9-13 1996. [CC97] T. Coupaye and C. Collet, Detailed Sketch of a Parametric Execution Model for Active Database Systems, Rapport de recherche RR 981-I-LSR 5, LSR { IMAG, Universite Joseph Fourier, Grenoble, fevrier 1997, 33 pages. [CC98] T. Coupaye and C. Collet, Modeles de comportement des SGBD actifs : caracterisation et comparaison, Technique et Science Informatiques (TSI) 17, Bases de Donnees (1998), no. 3. [CCS94] C. Collet, T. Coupaye, and T. Svensen, NAOS ecient and modular reactive capabilities in an object-oriented database system, Proc. of the 20th Int. Conf. on Very Large Data Bases (Santiago, Chile), September 1994, pp. 132{143. [CF97] S. Ceri and P. Fraternali, Designing Database Applications with Objects and Rules - The IDEA Methodology, Addison-Wesley, ISBN 0-201-403692-1, 1997. [CFPT94] S. Ceri, P. Fraternali, S. Paraboschi, and L. Tanca, Automatic Generation of Production Rules for Integrity Maintenance, ACM Transactions on Database Systems 19 (1994), no. 3, 367{422.

[CFPT95a] S. Ceri, P. Fraternali, S. Paraboschi, and L. Tanca, Active Rule Management in Chimera, Active Database Systems (San Mateo, CA, USA) (Morgan Kaufmann, ed.), S. Ceri and J. Widom, San Mateo, CA, USA, August 1995. [CFPT95b] S. Comai, P. Fraternali, G. Psaila, and L. Tanca, A Customizable Model for the Semantics of Active Databases, Proc. of the 6th IFIP Tc-2 Working Conference on Data Semantics, DS-6 (Stone Mountain, Atlanta, Georgia, USA) (R. Meersman and L. Mark, eds.), Chapman and Hall, June 1995. [CM93] S. Chakravarthy and D. Mishra, Snoop: An Expressive Event Speci cation Language For Active Databases, Tech. Report UF-CIS-TR-93-007, University of Florida, Gainesville, March 1993. [Col98] C. Collet, NAOS, Active Rules for Databases (Norman W. Paton, ed.), Springer Verlag, 1998, to be published. [Cou96] T. Coupaye, Un modele d'execution parametrique pour systemes de bases de donnees actifs (a parametric execution model for active database systems), Ph.D. thesis, Universite Joseph Fourier, Grenoble, France, November 1996. [CS94] R. Chandra and A. Segev, Active Databases for Financial Applications, Proc. of the 4th Workshop on Research Issues In Data Engineering - Active Database Systems (Houston, Texas - USA) (Jennifer Widom and Sharma Chakravarthy, eds.), IEEE, February 1994, pp. 46{52. [CW90] S. Ceri and J. Widom, Deriving Production Rules for Constraint Maintenance, Proc. of the 16th Int. Conf. on Very Large Data Bases (Brisbane - Australia), Morgan Kaufman, September 1990, pp. 567{577. [CW91] S. Ceri and J. Widom, Deriving Production Rules for Incremental View Maintenance, Proc. of the 17th Int. Conf. on Very Large Data Bases (Barcelon Spain), Morgan Kaufman, September 1991, pp. 577{589. [CW94] S. Ceri and J. Widom, Deriving Production Rules for Deductive Data, Information Systems 19 (1994), no. 6, 467{490. [Da86] K. Dittrich and al., An event/trigger mechanism to enforce complex consistency constraints in design databases, SIGMOD Record 15 (1986), no. 3. + [DBB 88] U. Dayal, B. Blaustein, A. Buchmann, U. Chakravarthy, M. Hsu, R. Ledin, D. McCarthy, A. Rosenthal, and S. Sarin, The HIPAC Project: Combining Active Databases and Timing Constraints, SIGMOD Record 17 (1988), no. 1, 51{69. [DGG95] K. R. Dittrich, S. Gatziu, and A. Geppert, The Active Database Management System Manifesto: A Rulebase of ADBMS Features, Proc. of the 2nd Int. Workshop on Rules in Database Systems, RIDS'95 Lecture Notes in Computer Science 985 (Athens, Greece) (T. Sellis, ed.), Springer Verlag, Athens, Greece, September 1995, pp. 3{17. [Dia95] O. Diaz, Dimensions of Active Database Systems, Actes des 10emes Journees Bases de Donnees Avancees (Nancy, France), September 1995, pp. 3{22. [DJ94] O. Daz and A. Jaime, EXACT: an EXtensible approach to ACTive objectoriented databases, Tech. report, Workshop on Active DBMS, Dagsthul - Allemagne, March 1994. [DP94] O. Diaz and N. Paton, Making Object-Oriented Databases Extensible through Metaclasses: an experience, IEEE Software (94).

[DPG91]

O. Diaz, N. Paton, and P. Gray, Rule Management in Object Oriented Databases: A Uniform Approach, Proc. of the 17th International Conference on Very Large Data Bas (Barcelona, Spain), September 1991, pp. 317{326. [FRG96] A. Front, C. Roncancio, and J.-P. Giraudin, Behavioral situations and active databases systems, Workshop on Databases: Active and Real-Time (Concepts meet Practice) (Rockville, Maryland, USA) (ACM SIGART & SIGIR, ed.), november 1996, pp. 59{62. [FT95] P. Fraternali and L. Tanca, A Structured Approach for the De nition of the Semantics of Active Databases, ACM Transactions on Database Systems 20 (1995), no. 4, 414{471. [GD94] S. Gatziu and K. Dittrich, Detecting composite events in active database systems using petri nets, Proc. of the 4th Int. Workshop on Research Issues in Data Engineering: Active Database Systems (Houston), IEEE, Houston, February 1994. [GGD93] S. Gatziu, A. Geppert, and K. Dittrich, Events in an Active Object-Oriented Database System, Proc. of the 1stWorkshop on Rules in Database Systems (Edinburg), August 1993. [GJS92] N. Gehani, H.V. Jagadish, and O. Shmueli, Event Speci cation in an Active Object-Oriented Database, Proc. of the 1992 ACM SIGMOD Int. Conf. on Management of Data (San Diego, California), 1992, pp. 81{90. [GMS96] G. Gottlob, G. Moerkotte, and V. S. Subrahmanian, The PARK Semantics for Active Rules, Proc. of the 5th International Conference on Extending Database Technology, EDBT'96Lecture Notes in Computer Science 1057 (Avignon, France) (P. Apers, M. Bouzeghoub, and G. Gardarin, eds.), Springer Verlag, Avignon, France, march 1996, pp. 35{55. [Han89] E. Hanson, An initial report on the design of Ariel a DBMS with an integrated production rule system, SIGMOD Record 18 (1989), no. 3, 12{19. [Hin86] J. R. Hindley, Introduction to Combinators and -Calculus, Cambridge University Press, Cambridge, England, 1986. [HJ91] R. Hull and D. Jacobs, Language Constructs for Programming Active Databases, Proc. of the 17th International Conference on Very Large Data Bases (Barcelona, Spain), 1991, pp. 455{467. [Ing92] Ingres, INGRES / SQL Reference Manual, Version 6.4. ASK Computer Co., 1992. [KRRV94] G. Kappel, S. Rausch-Schott, W. Retschitzegger, and S. Vieweg, TriGS Making a Passive Object-Oriented Database System Active, JOOP (1994). [MFLS96] M. Matulovic, F. Fabret, F. Llirbat, and E. Simon, Architecture d'un Systeme de Regles a la Semantique Parametrable, Actes des 12iemes Journees Bases de Donnees Avancees (Cassis - France), September 1996, pp. 291{310. [MM95] J. Melton and N. Mendocca Mattos, An Overview of the Emerging ThirdGeneration SQL Standard, Proc. of the 1995 ACM SIGMOD Int. Conf. on Management of Data (San Jose, California - USA), May 23-25 1995, p. 468. [MPC96] R. Meo, G. Psaila, and S. Ceri, Composite Events in Chimera, Proc. of the 5th International Conference on Extending Database Technology, EDBT'96Lecture Notes in Computer Science 1057 (Avignon, France) (P. Apers, M. Bouzeghoub, and G. Gardarin, eds.), Springer Verlag, Avignon, France, march 1996, pp. 56{78.

[NG92]

O. Shmueli N.H. Gehani, H.V. Jagadish, Composite event speci cation in active databases: model & implementation, Proc. of the 18th Int. Conf. on Very Large Data Bases, September 1992. [Ora92] Oracle, Oracle 7 reference manual, Oracle corporation, 1992. [PCFW95] N.W. Paton, J. Campin, A.A.A. Fernandes, and M.H. Williams, Formal Speci cation of Active Database Functionality: A Survey, Proc. of the 2nd Int. Workshop on Rules in Database Systems, RIDS'95 Lecture Notes in Computer Science 985 (Athens, Greece) (T. Sellis, ed.), Springer Verlag, Athens, Greece, September 1995, pp. 21{35. [PDW+93] N. Paton, O. Daz, M.H. Williams, J. Campin, A. Dinn, and A. Jaime, Dimensions of Active Behaviour, Proc. of the 1stWorkshop on Rules in Databases Systems (RIDS-93) (Edinburgh - Scotland) (N. Paton et M. Williams, ed.), Springer Verlag, September 1993. [Pic95] P. Picouet, Puissance d'expression et consistance semantique des bases de donnees actives, Ph.D. thesis, E cole Nationale Superieure des Telecommunications, Paris, December 1995. [PV95] P. Picouet and V. Vianu, Semantics and Expressinveness Issues in Active Databases, Proc. of the 14th ACM Symposium on Principles of Database Systems (San Jose, CA, USA), May 1995, pp. 126{138. [PW93] N. Paton and M. Williams, First Workshop on Rules in Databases Systems, (RIDS-93), Proc. of the 1stWorkshop on Rules in Databases Systems (Edinburgh - Scotland) (N. Paton et M. Williams, ed.), Springer Verlag, September 1993. [SGJ93] R. Hull S. Ghandeharizadeh and D. Jacobs, On Implementing a Language for Specifying Active Database Execution Models, Proc. of the 19th International Conference on Very Large Data Bases (Dublin, Ireland), 1993, pp. 441{454. [SHH87] M. Stonebraker, E. Hanson, and C. H. Hong, The design of the Postgres rule system, Proc. of the 3rdInt. IEEE Conf. on Data Engineering, 1987. [SKM92] E. Simon, J. Kiernan, and C. Maindreville, Supporting Deductive and Active Rules on Top of a Relational DBMS, Rr1580, INRIA - Rocquencourt (France), January 1992. [Sto77] J. E. Stoy, Denotational Semantics: The Scott-Strachey Approach to Programming Language Theory, The MIT Press, Cambridge, Massachussets, 1977. [Syb92] Sybase, Transact-sql user's guide, Sybase Inc., 1992. [WC96] J. Widom and S. Ceri, Active Database systems - Triggers and Rules for Advanced Database Processing, Morgan Kaufmann Publishers, San Francisco, California, 1996. [WCL91] J. Widom, R.J. Cochrane, and B.G. Lindsay, Implementing Set-Oriented Production Rules as an Extension to Starburst, Proc. of the 17th Int. Conf. on Very Large Data Bases (Barcelona, Spain), September 1991, pp. 275{285. [WF90] J. Widom and S. J. Finkelstein, Set Oriented Production Rules in Relationnal Database Systems, Proc. of the 1990 ACM SIGMOD Int. Conf. on Management of Data, SIGMOD Record, ACM Press, May 1990, pp. 259{270. [Wid92] J. Widom, A Denotational Semantics for the Starburst Production Rule Language, SIGMOD Record 21 (1992), no. 3, 4{9. [Zan93] C. Zaniolo, A uni ed semantics for active and deductive databases, in [PW93], 1993.