Oct 25, 1996 - email: [email protected] ... email: [email protected]. October ... A formal speci cation of an active database system can be used: 1. ..... The bulk of the functionality of Starburst is provided by the generic classes de ned.
Specifying Active Database Systems in an Object-Oriented Framework Jack Campin, Norman Paton and M. Howard Williams y
Department of Computing and Electrical Enginering Heriot-Watt University, Riccarton, Edinburgh EH14 4AS, UK email: [email protected] Department of Computer Sciencey University of Manchester, Manchester M13 9PL, UK email: [email protected]
October 25, 1996 Abstract This paper presents a framework for the formal speci cation of active database systems, and shows how the framework can be used to describe the functionality of three well known example systems, namely Starburst, POSTGRES and Ariel. The framework has been developed using Object-Z to structure speci cations in a way that emphasises commonalities and key di erences between the designs, and that is readily extensible to support new constructs and systems. Such a formal framework can be used to provide formal descriptions of systems that have previously been described only informally, to compare the functionalities of di erent systems by contrasting support for fundamental concepts, and as a basis for reasoning about rule bases in the context of di erent active rule systems. The paper also demonstrates the applicability of objectoriented formal methods to the speci cation of advanced database functionality.
1 Introduction Active database systems have been proposed to support database applications in which automatic responses are required to occurrences inside or outside the database system itself. Such active behaviour is expressed using either event-condition-action or condition-action rules. A number of designs and implementations of active databases now exist, and proposals have been made which build upon relational [33, 18], extended relational [31], deductive [34, 19] and object-oriented [10, 13, 17] data models. Active databases o er a number of advantages over their passive predecessors for a range of di erent categories of application, involving extensions to database systems [5, 12, 24], data intensive domains [8, 4] and control of external activities [3]. The run-time functionality of such rules is based upon monitoring and responding to events, which are stated explicitly in event-condition-action (ECA) rules, but which are implicit in condition-action (CA) rules. When an event takes place, the corresponding condition is evaluated to determine whether or not the context is suitable for the execution of the action. The condition is normally expressed as a database query, and the action normally involves some update, the sending of messages to users, or the control of some external device. However, the facilities supported by di erent active database systems are very diverse [25], and it can be dicult to ascertain exactly how speci c proposals di er, or the consequences of such diversity. This diculty derives in part from the informal descriptions that are normally used to present active database systems in the literature,
1
where functionality is often only partially described, or illustrated using examples. This paper presents a formal framework within which the active behaviour of di erent database systems can be speci ed both precisely and concisely. A formal speci cation of an active database system can be used: 1. To support implementors and users of active database systems by giving a precise and explicit description of the relevant active behaviour. 2. As a basis for the comparison of di erent systems, by describing key facilities in a uniform and unambiguous manner. 3. To underpin the development of rule analysis tools that assist the designers and implementors of rule bases by proving properties of collections of rules. The focus of this paper is on points (1) and (2) above, with an emphasis upon the execution models of di erent active systems. The speci cations provided here, like those of [32, 9], abstract over details of data models and query languages, as such features are to a signi cant extent orthogonal to the active aspects of a database system. Such features can also be speci ed using formalisms such as Z [7], but their inclusion within the framework would add signi cantly to the cost of incorporating additional systems. Most previous research on formal speci cation of active databases has dealt principally with rule analysis, has been system-speci c, and has not included a description of the execution model used to support active behaviour at runtime. For example, [2] uses relational algebra to reason about the safe termination of a set of rules, and both [1] and [35] use operational semantics to analyse nondeterminism in rule bases. However, no previous work has aimed at producing a general framework within which di erent and existing rule systems can be formally described, thereby addressing points (1) and (2) above. Formal speci cations have been developed for the Starburst [32] and NAOS [9] rule systems using denotational semantics, but these speci cations do not lend themselves to tailoring for the description of other rule systems. Other research has involved adapting the formal models of deductive [34, 19], functional [26] or temporal [11] databases to incorporate active behaviour, but such work does not lend itself to the speci cation of active databases built upon passive databases from di erent paradigms. One other proposal for specifying di erent active rule systems in a formal environment is presented in [16], which is based upon the event calculus [21]. That work, however, has not yet been applied to the speci cation of multiple existing systems, as is done here. For a survey of formal work on the speci cation of active database systems, see [23]. The framework presented in this paper uses Object-Z [15, 27, 22], an extension of Z [28] with object-oriented structuring facilities and temporal operations. Object-Z allows a general framework to be developed in an object-oriented manner, which is then specialised to describe speci c systems. This enables large parts of a speci cation to be reused when an additional system is to be described, and clari es both similarities and di erences between proposals. An additional contribution of this paper is to demonstrate the way in which object-oriented speci cation mechanisms can be applied to describing the behaviour of rule-based systems. The paper is structured as follows: section 2 presents an informal overview of the systems to be speci ed formally later, and introduces the Object-Z notation; section 3 presents the core Object-Z classes upon which the framework is built; section 4 demonstrates how this framework can be tailored to give a formal speci cation of three well known active systems, namely Starburst [33], Ariel [18], and POSTGRES [30]; section 5 identi es lessons that can be learned from the speci cations, and places the work in the wider context of research and development in active databases; section 6 presents some conclusions.
2
2 Background
2.1 Exemplar Active Databases
This subsection presents short informal descriptions of the three active database systems that are subsequently formally de ned in section 4, namely Starburst, Ariel and POSTGRES. These widely known systems have been chosen because they support signi cantly di erent execution models, thereby presenting a reasonable challenge to our framework.
2.1.1 Starburst
The Starburst active rule system supports a set-oriented execution model for ECA rules over a relational database. The basic structure of a rule is de ned using the following syntax: on
when if then
The event in this context is given by the on ... when construct, which is used to monitor changes to the named table. The occurrence of an event does not lead to the immediate processing of the rest of the rule, but rather to the logging of that particular change as having taken place. Subsequently, at a rule assertion point, which may be at the end of a transaction or at some other stage within the transaction, occurrences which have led to the creation of log entries are considered further. As a single event may have occurred more than once prior to a rule assertion point, there may be multiple entries in a log. In practice, the logs record the net e ect of a set of changes, so that, for example, an insert of a tuple followed by an update of the tuple is logged as an insert of the updated tuple. When the log associated with a rule is non-empty, and the rule is scheduled for processing after a rule assertion point, the condition of the rule is evaluated { a rule condition is an SQL query which can access the current state of the database together with the transition table(s) of the event(s) that the rule is monitoring. If the condition evaluates to true then the action of the rule is executed. The action is either a sequence of SQL update statements or a rollback command. It is possible that there is more than one rule with a non-empty transition table at a rule assertion point. If so, a scheduler examines the priorities of the di erent rules, and chooses one of the rules with highest priority for processing rst. It is also possible for the action of a rule to lead (directly or indirectly) to the occurrence of update operations which re-trigger the rule. In this situation, the rule is once again made available to the scheduler, with access to the transition tables which re ect changes to the database since the rule was last scheduled for processing. As a single ring of a rule may be used to respond to a set of events, the transition granularity of the Starburst rule system is set rather than tuple. As rules are not executed until rule assertion points, the coupling mode between an event and the rule(s) it triggers is deferred rather then immediate.
2.1.2 Ariel
The feature of the Ariel [18] active rule system which most clearly distinguishes it from both Starburst and POSTGRES is the optionality of events: [on ] [if ] then
Clearly every rule must give a speci cation of either the event or the condition or both. In Ariel, as in POSTGRES, a rule is activated by a tuple-level change, and thus each rule activation is associated with a single updated tuple (i.e. the transition granularity is tuple). However, the coupling mode is deferred, as rule assertion points are either at the end of a command or at the end of a sequence of commands which
3
are grouped together in a block. As in Starburst, the fact that a number of operations may have taken place prior to the scheduling of a set of activated rules is dealt with by considering the net e ect of the sequence of operations. A further characteristic of Ariel which distinguishes it from Starburst and POSTGRES, and which follows from the optionality of the event, is that the rule system is implemented using a discrimination network algorithm based upon TREAT [18]. While the formal speci cations of Starburst, Ariel, or POSTGRES could make use of the published descriptions of their implementations, in this paper the focus is upon describing the behaviour of a set of rules rather than on the details of any particular implementation strategy.
2.1.3 POSTGRES
There have been two proposals for active rule systems for POSTGRES, the most recent of which, commonly referred to as PRS2, is considered here [30, 29]. Unlike Starburst, PRS2 is tuple-oriented, although the basic structure of rules remains much the same: ON TO FROM WHERE THEN DO [instead]
The event speci cation is similar to that for Starburst, except that it is also possible to monitor the retrieval of information from a relation. The in the above syntax is either a relation name or a sequence of column references. POSTGRES has two alternative implementations of the rule system available: one (the tuple-level rule system) operates at execution time; the other (the query rewrite implementation) is applied at query compilation time, transforming queries into new versions that maintain the rule semantics. Only the former is considered here; the query rewrite implementation is a matter of query optimization rather than active behaviour. The principal feature which distinguishes PRS2 from Starburst is that rules are tuple based { when an event takes place, a rule is scheduled for execution with the notion of a single current tuple (for retrieve, replace and delete) and/or a single new tuple (for replace and append). The execution of an activated rule may occur either before further tuples are processed by the transaction or upon completion of the user's query { it is not clear in [30] how, or at what granularity, the user selects one of these functionalities. A feature of PRS2 which is not supported by Starburst or Ariel is the instead option associated with an action. This allows an active rule to replace the command which has caused the rule to be activated, and thus rules in PRS2 can be considered to be activated by an attempt to carry out some task, rather than the actual occurrence of the task.
2.2 Brief guide to Object-Z
This section gives a brief introduction to Object-Z, which should enable readers to obtain a reasonable understanding of the speci cations that follow. Additional information on Z and Object-Z can be obtained from [28] and [15], respectively. Object-Z speci cations are constructed from a number of classes that group together descriptions of related entities (constants, mutable state, functions, relations, operations, etc). Built in types, which are used to describe constants, states and operation signatures include: B for booleans, N for the natural numbers, N1 for the natural numbers excluding 0, and Zfor the integers. Names can be given to sets of values using P (powerset) and F ( nite set); operators associated with sets include # (cardinality), 2 (membership) and [ (union). Enumerated types are speci ed using ::=, as in the following examples which specify allowed module and student names: ModuleName ::= Maths j Computing j Physics StudentName ::= Jack j Norman j Howard
4
A short example will now be given to illustrate the features of Object-Z. The class Module represents the notion of a unit of taught material, and has a state consisting of a name and a level which is constrained to be less than 4. Module name : ModuleName level : N level < 4
Students are modelled using the class Student and its subclass Undergrad . The class Student has a state which represents the name and level of the student, to which Undergrad adds the set of Module s that the student takes . A constraint is de ned on takes , that all Modules taken by a student must have the same level as the student. The symbol means that all identi ers declared to the left of it are in scope in the body to its right. Undergrad also de nes two operation schemas: INIT , which contains constraints holding on initialization; and Enroll , which adds a Module to the set that the student takes . The operation Enroll has one input parameter m (denoted by the ?) and one output parameter n (denoted by the !). The operation makes explicit using the state variables that are updated by the operation, which in this case adds the input parameter m to the set of Module s in takes . The poststate of a variable is denoted by priming. The output parameter n ! returns the number of modules that the student takes . Student name : StudentName level : N level < 4 Undergrad Student takes : F Module 8 m : takes m :level = level INIT takes = ? Enroll (takes ) m ? : Module n! : N takes = takes [ fm ?g n ! = #takes 0
0
A number of additional facilities are used in the speci cation, and are outlined here. The temporal operators of Object-Z have the same semantics as in most temporal logics; 2p is true if p will always hold henceforth, and p is true if p will hold in the
5
state of the system immediately following the operation in which it occurs. As in Z, there are operators for composing schemas besides the strictly logical ones: o combines two schemas in temporal sequence, and > > (known as pipe) additionally 9 identi es the outputs of the rst operation with the inputs of the second. The notation name = b declarations j predicate
is used as a shorthand for the operation de nition: name declarations predicate
For example, the operation Enroll could have been de ned as: Enroll = b (takes ); m ? : Module ; n ! : N j takes = takes [ fm ?g ^ n ! = #takes 0
0
One issue that does not come up in the above example, or in the published ObjectZ speci cations cited here, is sharing of references between objects. This is required in several places in the active rule system speci cations; for example, to ensure that there is only one rulebase in the system, while each of the stores in the system refers to it. In the active rule speci cations, this is handled by using axioms to relate the elements shared by multiple classes.
3 Basic classes of the formal speci cation Common to the speci cation of the systems described here are a set of core classes and a library class. These classes are very general and provide a structural framework for describing active rule systems. The core classes are subsequently re ned to re ect the characteristics of individual systems. The library class is used to support certain aspects of active behaviour.
3.1 The core classes
The concepts common to all the active databases in this survey are as follows: objects: These are the basic mutable data items of the database { tuples in the case of the relational model, objects in an object-oriented one. The speci cations of active rule systems do not require much detail about the behaviour of individual data items. Each of the classes below has a reference to the active database ultimately enclosing it. This is to allow objects in the speci cation to be identi ed uniquely, as described in the previous section. Object adb :# ActiveDB state : State Read = b s ! : State Write = b s ? : State
The # symbol indicates that adb in an object of class Object is permitted to be of class ActiveDB or any of its subclasses.
6
stores: These are the entities that group objects. In a relational database each relation is a store. In an OODB each class extent is a store. Creation, modi cation and deletion of tuples or objects corresponds to appending, deleting or replacing values in the store. In the systems speci ed here, rules are triggered by operations on stores, so, to facilitate straightforward access to the rules monitoring a store, each Store maintains sets of rules monitoring append, delete and replace operations in aRules , dRules and rRules , respectively. Store adb :# ActiveDB aRules : F # Rule dRules : F # Rule rRules : F # Rule 8 r : aRules r 2 adb :rb :rules 8 r : dRules r 2 adb :rb :rules 8 r : rRules r 2 adb :rb :rule obs : F # Object INIT = b obs = ? Retrieve = b x ! : Object Append = b x ? : Object Delete = b x ? : Object Replace = b x ? : Object ; s ? : State
rules: All of the systems speci ed here make rules tripartite entities, with trigger-
ing events, a condition to be checked, and an action part to be executed if the condition holds. Although all the systems speci ed here can or must have explicit events, it turns out not to be necessary to model events directly in the speci cation. A Rule thus has a Condition and an Action , but no stored event property. Rule adb :# ActiveDB Condition go ! : B Action
Re nements of this will need to declare (as constants or instance variables) the environment of the rule { the part of the database it may examine or act on. In practice, conditions and actions are normally speci ed by the retrieval and update languages of the database; the speci cations presented here abstract over the semantics of such languages.
rule bases: All active databases have some notion of the collection of rules that may
act on the database. In most, the rules are given priorities, and thus the rulebase is in some way ordered. Operations are provided to insert and delete rules in this ordered structure; the formal speci cations of these operations are omitted here for reasons of space.
7
RuleBase adb :# ActiveDB rules : F Rule INIT = b obs = ?
active databases: The top level of the speci cation in each case is that of an active database, which represents some level of interface to the complete system. For comparative purposes, this is not necessarily the user or application programmer interface. An object of class ActiveDB contains a number of stores and a rulebase. ActiveDB stores : F # Store rb :# RuleBase INIT
8 s : stores stores :INIT rb :INIT
ChooseStore st ? : Store st ? 2 stores Retrieve = b ChooseStore st ?:Retrieve Append = b ChooseStore st ?:Append Delete = b ChooseStore st ?:Delete Replace = b ChooseStore st ?:Replace
The relationships between the core classes are presented in gure 1. aRules dRules rRules
Store
stores
ActiveDB
Rule
rules rb
RuleBase
Figure 1: Relationship between core classes. 8
3.2 The library class
A construct used in several places in the following speci cations is that of an evolving collection of entities of uniform type. One use of this is in describing a log of changes to a database, where new elements may be added by user operations and deleted when a transaction commit makes them irreversible. The class Log provided here supports the storage of a collection of data items using sets. The construct is polymorphic, in that the types of items stored using the log may vary. Log [T ] set : PT INIT = b set = ? Add = b (set ); x ? : T j set = set [ fx ?g Drop = b (set ); x ? : T j set = set n fx ?g 0
0
3.3 Overview of Speci cation Framework
The classes presented in the previous two subsections are very general, and provide a structural framework for describing active rule systems. In the section 4 it is shown how these classes can be re ned to describe systems with set-based and tuple based evaluation strategies. As more than one set-based system is de ned in this paper, there is an intermediate level of description shared by these set-based systems, as illustrated in gure 2. Core Functionality Set-Based
Functionality
Starburst Postgres
Ariel
Figure 2: Overview of speci cation framework.
4 Subclasses describing speci c systems
This section extends the core classes to describe speci c active database systems: Starburst and Ariel on the one hand as set-oriented systems, and Postgres as an exemplar tuple-oriented system.
4.1 Set-Based Systems
Both Starburst and Ariel group database operations together so that their net e ect triggers rules; both of these systems also have a distinct phase of rule processing during which normal user interaction is prevented. The aspects of this common functionality which can be shared by the speci cations of the individual systems are de ned in
9
section 4.1.1, with re nements for Starburst and Ariel in sections 4.1.2 and 4.1.3 respectively.
4.1.1 Features Common to Starburst and Ariel While the published descriptions of Starburst and Ariel give the impression that they are very di erent, the speci cations of their execution models reveal much common ground. This section speci es classes for rules, rule bases, stores and complete databases for behaviour shared by both Starburst and Ariel. The information that is central to the execution models of the set based systems is the log of events that have taken place to which rules must respond. In the speci cations, information on each event instance (represented here by the a ected Object ) that a rule is monitoring is stored with the rule. The class SetRule is de ned as follows: SetRule Rule a : Log [Object ] d : Log [Object ] r : Log [Object State ] emptylog : B emptylog , a :set = ? ^ d :set = ? ^ r :set = ? INIT emptylog Fire Condition ) Action SetRule has three logs, a (for append), d (for delete) and r (for replace). The attributes a and d respectively record the object that has been appended or deleted, while r records both the replaced object and its previous state. Note that, as an operation (e.g. an append) involving a single Object may be being monitored by multiple rules, a single Object may appear in multiple logs at the same time. SetRule s are in turn organised within a SetRuleBase , the principal operation of which, Candidates , returns a set of rules that have been triggered (i.e. that have non empty logs). The speci cations given here do not consider rule priorities, although these could easily be added. SetRuleBase rules : F # SetRule Candidates rs ! : F # SetRule 8 r 2 rs ! r 2 rules ^ : r :emptylog
The logs associated with SetRule s are updated by operations applied to the store, which is represented by the class SetStore . The update operations must take into account the fact that rules are triggered on the basis of the net changes to the store. This functionality is supported within the Append , Delete and Replace operations of SetStore , of which Delete is typical. Delete removes the object passed to it, as well as:
10
1. Informing all rules that monitor Delete operations on the store, unless the delete operation is undoing an Append that has taken place since the last rule assertion point. 2. Removing all yet-to-be-responded-to log entries for the deleted object associated with rules monitoring Append or Replace operations on the store. The operation used by replace is Z's de nite description operator; x : T Fx denotes the unique x of type T satisfying F . The operation fst retrieves the rst element from a pair.
SetStore Store Append x ? 62 obs x ? 2 obs 8 r : aRules ) r :a :Add 0
Delete x ? 2 obs x ? 62 obs 8 r : dRules @ar : aRules x ? 2 ar :a ) r :d :Add 8 r : aRules r :a :Drop 8 r : rRules r :r :Drop ( p : Object State fst p = x ?) 0
Replace x ? 2 obj x ?:Write (s ?) 8 r : aRules x ? 2 r :a ) r :a :Drop ^ r :a :Add [(x ?; s ?)=x ?] 8 r : rRules @ar : aRules x ? 2 ar :a ) r :r :Add [(x ?; s ?)=x ?]
The classes SetRule , SetRuleBase and SetStore maintain the information required by the execution model for set based rule processing. The behaviour of the rule processing algorithm is provided by the class SetActiveDB . The principal operations of SetActiveDB are Assert, Stabilize and PickAndRun, which are used to support the ring of all triggered rules at rule assertion points. The operation Assert initiates rule processing by identifying rules that have been triggered but not red, using Candidates from SetRuleBase . If such rules do exist, then this is recorded using the state variable stable. If the database is not stable, then the next operation to be invoked is Stabilize (as indicated by : stable ) op = Stabilize ). Each invocation of Stabilize uses PickAndRun to select rules for ring, until all triggered rules have been red, when the database is again held to be stable, and rule processing stops. PickAndRun , given a set of rules, res a randomly selected member of that set. The inclusion of the condition stable in the predicate sections of Retrieve, Append, Delete and Replace guarantees that no user interaction can take place during a rule processing cycle.
PickAndRun rs ? : F # Rule rs ! : F # Rule rs ? 6= ? ) 9 r 2 rs ? r :Fire rs ! = rs ? Stabilize (stable ) rb :Candidates >> PickAndRun >> CheckStability Assert (stable ) rb :Candidates >> CheckStability Retrieve = b st ? : Store j stable Append = b st ? : Store j stable Delete = b st ? : Store j stable Replace = b st ? : Store j stable
: stable ) op = Stabilize
4.1.2 Starburst The bulk of the functionality of Starburst is provided by the generic classes de ned in section 4.1.1. The feature that has not been speci ed by the generic classes is rule ring, which has to be handled separately for Starburst and Ariel, as each ring of a Starburst rule is associated with a set of updated Object s, whereas in Ariel each ring of a rule is associated with a single Object . Starburst rules are represented by the class SRule . The principal operation on SRule is Fire , which performs the changes relevant to a single execution of the rule following a set of triggering updates.
12
SRule SetRule ClearRuleLog (a ; d ; r ) a :INIT ^ d :INIT ^ r :INIT 0
4.1.3 Ariel In common with Starburst, Ariel rules can be triggered in response to the net e ect of a set of changes, although in Ariel a rule ring is associated with an update to a single object. An important characteristic of Ariel for rule programmers is support for conditionaction rules, where no event is explicitly stated. This feature, however, has little bearing on the speci cation, where it is assumed that the system derives the events that must be monitored from the condition part of condition-action rules. The class from section 4.1.1 that has to be re ned to support Ariel speci c behaviour is SetRule , where the de nition of Fire has to account for the fact that a single rule ring can only remove a single entry from a single log: ARule SetRule Fire (adb :stores ) Condition ) Action : Condition ) adb :stores = adb :stores ( 9 o : a a :Drop (o =x ?) _ 9 o : d d :Drop (o =x ?) _ 9 o : r r :Drop ( p : Object State fst p = o ) ) 0
In the de nitions of Fire for both Starburst and Ariel, the passing of parameters to the condition and action of the rule is not included in the speci cation, as the call interface to the query processor has been abstracted over.
4.2 A Tuple-Based System: POSTGRES
In POSTGRES, database operations directly trigger the rule mechanism; this is in contrast to Starburst and Ariel, where the changes are logged and rules are only triggered at rule assertion points. Some matters are left unclear in the published documentation on POSTGRES { where assumptions have been made in the construction of the speci cation, they are stated explicitly. For example, there is no concurrency control to prevent interleaving of the rule system and user operations since the documentation on the system does not describe it.
13
The POSTGRES speci cation builds upon the core classes from section 3, and re nes the de nitions provided there for rules and stores.
In the rule syntax of POSTGRES, a DO INSTEAD construct allows a rule to force an operation to be abandoned and replaced by a substitute; this is represented here as a boolean property of PRule , which is true only if the system should not execute the operation which triggered the rule.
In the particular case where the operation overridden by DO INSTEAD is a Retrieve, it is necessary to be able to specify an alternative value for retrieval. This is represented by the operation InsteadOp on the class PRule , which is assumed to be written using POSTQUEL, the query language of the database. PRule Rule instead : B Fire x ? : Object Condition ) Action InsteadOp x ! : Object
Much of the functionality of the POSTGRES rule system is associated with the class PStore , which is derived from Store . The principal operations of PStore support access to and update of tuples in a relation through the operations Retrieve, Append, Delete and Replace. Each such primitive operation may lead to the triggering of rules.
To consider a speci c example, Append is used to add a single tuple to the PStore . The Append operation res all rules associated with append operations on the store, and uses DoAppend to support the functionality associated with DO INSTEAD. DoAppend examines the triggered rules to see if any of the rules are DO INSTEAD rules. If not, then the object given as a parameter to Append is added to the store; if so, then no further action is taken { it is assumed that the actions of the triggered rules have carried out all the updates which are required.
14
PStore Store retRules : F # Rule 8 r : retRules r 2 adb :rb :rules DoRetrieve x ! : Object 9 r : retRules r :instead ) x ! = r :InsteadOp @r : retRulers r :instead ) x ! 2 obs 0
DoAppend (obs ) x ? : Object @r : aRules r :instead ) x ? 2 obs 9 r : aRules r :instead ) obs = obs 0
0
Retrieve
8 r : retRules r :Fire o9 DoRetrieve Append
8 r : aRules r :Fire o9 DoAppend The operations supporting Delete and Replace have been omitted, as they are very similar to Append .
A number of assumptions have been made in the above class de nition. The most important relates to the execution model of the rule system, which is slightly di erently described in di erent published papers; the approach followed is from [29]. The second concerns which value is returned where there are multiple alternative retrieve actions associated with DO INSTEAD rules; the approach adopted is that one such action is selected nondeterministically.
5 Context This section identi es some lessons that have been learned in developing the framework presented in this paper, and relates features of the speci cations to other work on active databases. Examination of the speci cations reveals features of execution models that will have a signi cant impact on implementations. In particular, the following can be observed: 1. The implementation of rules that are triggered immediately by single tuple level updates, as in POSTGRES, is very straightforward, with no need for auxiliary data storage. 2. The signi cant distinction at the language level between condition-action and event-condition-action rules seems to have little bearing on the resulting execution model. The execution models in Starburst (ECA) and Ariel (CA) maintain very similar intermediate data sets, and the information that must be held re ects execution model decisions that seem to be largely independent of whether CA or ECA rules are used. This similarity in the speci cation is emphasised here by making explicit the fact that CA rules are triggered by primitive operations in the same way as ECA rules, except that in CA rules the events are implicit.
15
Performance issues may lead to CA rule systems using additional data structures, but the underlying semantics remain very similar in the speci cations. 3. The intermediate information that must be stored depends more on the coupling mode than on the transition granularity of the execution model. This can be observed from the fact that the Starburst and Ariel speci cations log essentially the same information, even though Starburst rules are red by sets of updates, whereas Ariel rules are red by single updates. As is highlighted in gure 3, which shows how the execution model features captured in the speci cations in this paper relate to those of other systems, it is clear that Starburst, Ariel and POSTGRES between them support a signi cant range of execution model features. The other systems in gure 3 are ORACLE [20], Sentinel [6] and ROCK & ROLL [14]. The ORACLE rule system is quite restrictive, and could easily be modelled within the framework using facilities similar to those used with POSTGRES. The other two systems, Sentinel and ROCK & ROLL, are based upon object-oriented database systems, and, in common with other active object-oriented databases, support more sophisticated rule systems than the relational databases. Extending the framework to support Sentinel and ROCK & ROLL would require the introduction of classes to support the detection of composite events, and in the case of Sentinel, to model the complex transaction model that is closely linked to the rule system.
Table 1 { Execution Model Features In Active Databases System
Tuple Level Transitions Starburst p Ariel p POSTGRES p ORACLE p Sentinel ROCK & ROLL p
Set Level Immediate Deferred Nett E ect Transitions Coupling Coupling Policy p p p p p p p p p p p p p p
Figure 3: Execution model features in active database systems.
6 Conclusions This paper has presented a framework for the formal speci cation of active database rule systems. The framework, built using Object-Z, facilitates the development of concise speci cations of moderate size in modest periods of time. This is achieved by using the facilities of Object-Z to specify generic concepts that can subsequently be specialised, and by developing useful concepts in what amounts to a speci cation library. It has been shown how the framework can be used to specify the functionality of three well known active database systems, namely Starburst, POSTGRES and Ariel. This is a contribution in itself, as previously only Starburst had been formally speci ed [32]. However, the development of these speci cations within a common framework clari es the di erences between the three systems, and has identi ed some ambiguities in their published informal speci cations. Comparisons of the speci cations reveal several things about the execution models of the di erent proposals. For example, there is more overlap in the speci cations of Starburst and Ariel than is obvious from the original papers. Informal descriptions of Ariel emphasise the consequences of the optionality of events in rules and the algorithms which have been developed to support ecient condition checking. The speci cations, however, reveal that deferred rule processing in Ariel has much in
16
common with that supported by Starburst. The essential di erence between the two proposals lies in the directness of the link between individual operations and the rules they trigger. The Postgres speci cation is signi cantly di erent from that of Starburst or Ariel largely because of the lack of deferred rule processing. Because rules are triggered as soon as the events that they are monitoring have occurred, there is no need for intermediate storage of yet-to-be-responded-to updates, leading to a much more concise speci cation, and thus probably to a signi cantly more straightforward implementation. Extensions to the framework presented here to include additional systems is likely to lead to reuse of more than just the core classes presented in section 3. The speci cations of Starburst and Ariel exploit generic operations for supporting deferred rule processing, which the Starburst speci cation adapts to handle the set-based association of updates with rules, and which the Ariel speci cation adapts to handle the (net-e ect aside) 1-to-1 correspondence between update operations and rule rings; the Postgres speci cation includes support for the immediate ring of rules in response to events. Thus the framework already supports a wide range of execution models, which could be combined or re ned to match the functionality of other systems.
7 Acknowledgements This work is supported by the UK EPSRC Grant GR/H43847 and by the EU Human Capital and Mobility Network ACT-NET. We are grateful for the contribution of our colleagues Andrew Dinn and Alvaro Fernandes to our understanding of active databases and their speci cation, and for Andrew's comments on an earlier version of this paper.
References [1] L. Kersten A. Siebes, M. Van der Voort. Towards a design theory for database triggers. In I. Ramos A.M. Tjoa, editor, Database and Expert Systems Applications(DEXA), pages 338{344. Springer-Verlag, 1992. [2] E. Baralis and J. Widom. An algebraic approach to rule analysis in expert database systems. In J. Bocca, M. Jarke, and C. Zaniolo, editors, Proc. 20th VLDB, pages 475{486. Morgan-Kaufmann, 1994. [3] H. Branding, A. Buchmann, T. Kudrass, and J. Zimmermann. Rules in an Open System: The REACH Rule System. In N.W. Paton and M.H. Williams, editors, Rules in Database Systems, pages 111{126. Springer-Verlag, 1994. [4] C. Bussler and S. Jablonski. Implementing Agent Coordination for Work ow Management Systems Using Active Database Systems. In J. Widom and S. Charavarthy, editors, Proc. 4th Int. Workshop on Research In Data Engineering (RIDE -ADS), pages 53{59. IEEE, 1994. [5] S. Ceri and J. Widom. Deriving production rules for constraint maintenance. In 16th Intl. Conf. in Very Large Data Bases, Brisbane, pages 567{577. Morgan Kaufman, 1990. [6] S. Chakravarthy, E. Anwar, L. Maugis, and D. Mishra. Design of Sentinel: an object-oriented DBMS with event-based rules. Information and Software Technology, 36(9):555{568, 1994. [7] D.K.C. Chan and P.W. Trinder. An Object-Oriented Data Model Supporting Multi-Methods, Multiple Inheritance and Static Type Checking. In Proc. 8th Z User Meeting, pages 297{315. Springer-Verlag, 1994. [8] R. Chandra and A. Segev. Active Databases for Financial Applications. In J. Widom and S. Charavarthy, editors, Proc. 4th Int. Workshop on Research In Data Engineering (RIDE-ADS), pages 46{52. IEEE, 1994.
17
[9] T. Coupaye and C. Collet. Denotational Semantics for and Active Rule Execution Model. In T. Sellis, editor, Proc. 2nd Int. Workshop on Rules in Database Systems, pages 36{50. Springer-Verlag, 1995. [10] U. Dayal, A.P. Buchmann, and D.R. McCarthy. Rules are objects too: A knowledge model for an active object oriented database system. In K.R. Dittrich, editor, Proc. 2nd Intl. Workshop on OODBS, volume 334, pages 129{143. SpringerVerlag, 1988. Lecture Notes in Computer Science. [11] M. Deng, A.P. Sistla, and O. Wolfson. Temporal Conditions with Retroactive and Proactive Updates. In M. Berndtsson and J. Hansson, editors, Active and Real-Time Database Systems (ARTDB-95), pages 122{141. Springer-Verlag, 1996. [12] O. Diaz. Deriving rules for constraint maintenance in an object-oriented database. In I. Ramos A.M. Tjoa, editor, Proc. Intl. Conf. on Databases and Expert Systems DEXA, pages 332{337. Springer-Verlag, 1992. [13] O. Diaz, N. Paton, and P.M.D. Gray. Rule management in object oriented databases: a uniform approach. In G.M. Lohman, A. Sernadas, and R. Camps, editors, 17th Intl. Conf. on Very Large Data Bases, Barcelona, pages 317{326. Morgan Kaufmann, 1991. [14] A. Dinn, N.W. Paton, M.H. Williams, and A.A.A. Fernandes. An Active Rule Language for ROCK & ROLL. In Proc. 14th British National Conference on Databases. Springer-Verlag, 1996. [15] Roger Duke, Paul King, Gordon Rose, and Graeme Smith. The Object-Z Speci cation Language, version 1. Technical Report 91-1, Software Veri cation Research Centre, University of Queensland, 1991. [16] A.A.A. Fernandes, M.H. Williams, and N.W. Paton. A Logic-Based Integration of Active and Deductive Databases, 1996. to be published in New Generation Computing. [17] N.H. Gehani and H.V. Jagadish. ODE as an Active Database: Constraints and Triggers. In R. Camps G.M. Lohman, A. Sernadas, editor, 17th Intl. Conf. on Very Large Data Bases, Barcelona, pages 327{336. Morgan Kaufmann, 1991. [18] E.N. Hanson. Rule Condition Testing and Action Execution in Ariel. In Proc. SIGMOD, pages 49{58. ACM, 1992. [19] J.V. Harrison and S.W. Dietrich. Integrating active and deductive rules. In N.W. Paton and M.H. Williams, editors, Proc. 1st Int. Workshop on Rules In Database Systems, pages 288{305. Springer-Verlag, 1994. [20] G. Koch and K. Loney. ORACLE: The Complete Reference (3rd Edition). Osborne McGraw-Hill, 1995. [21] R. Kowalski. Database updates in the event calculus. Journal of Logic Programming, 12:121{146, 1992. [22] K. Lano and H. Haughton, editors. Object-Oriented Speci cation Case Studies. Prentice-Hall, 1993. [23] N.W. Paton, J. Campin, A.A.A. Fernandes, and M.H. Williams. Formal speci cation of active database functionality: A survey. In T. Sellis, editor, Proc. 2nd Int. Workshop on Rules In Database Systems, pages 21{35. Springer-Verlag, 1995. [24] N.W. Paton, O. Diaz, and M.L. Barja. Combining active rules and metaclasses for enhanced extensibility in object-oriented systems. Data and Knowledge Engineering, 10:45{63, 1993. [25] N.W. Paton, O. Diaz, M.H. Williams, J. Campin, A. Dinn, and A. Jaime. Dimensions of active behaviour. In N.W. Paton and M.H. Williams, editors, Proc. 1st Int. Workshop on Rules In Database Systems, pages 40{57. Springer-Verlag, 1994. [26] S. Reddi, A. Poulovassilis, and C. Small. Extending a Functional DBPL With ECA-Rules. In T. Sellis, editor, Proc. 2nd Int. Wshp. on Rules in Database Systems, pages 101{115. Springer-Verlag, 1995.
18
[27] G.A. Rose. Object-Z. In S. Stepney, R. Barden, and David Cooper, editors, Object-Orientation in Z, pages 59{77. Springer-Verlag, 1992. [28] J.M. Spivey. The Z Notation: a reference manual. Prentice-Hall, 2nd edition, 1992. [29] M. Stonebraker. The Integration of Rule Systems and Database Systems. IEEE Trans. on Knowledge and Data Engineering, 4(5):415{423, 1992. [30] M. Stonebraker, A. Jhingran, J. Goh, and S. Potamianos. On rules, procedures, caching and views in database systems. In Proc. ACM SIGMOD, pages 281{290, 1990. [31] M. Stonebraker, L. Rowe, and M. Hirohama. The implementation of postgres. IEEE Transactions on Knowledge and Data Engineering, 2(1), 1990. [32] J. Widom. A Denotational Senmantics for the Starburst Production Rule Language. ACM SIGMOD Record, 21(3):4{9, 1992. [33] J. Widom, R.J. Cochrane, and B.G. Lindsay. Implementing Set-Oriented Production Rules as an Extension to Starburst. In R. Camps G.M. Lohman, A. Sernadas, editor, 17th Intl. Conf. on Very Large Data Bases, Barcelona, pages 275{286. Morgan Kaufmann (ISBN 1-55860-150-3), 1991. [34] C. Zaniolo. A uni ed semantics for active and deductive databases. In N.W. Paton and M.H. Williams, editors, Rules in Database Systems. Springer-Verlag, 1994. [35] Y. Zhou and M. Hsu. A theory for rule triggering systems. In F. Bancilhon and et al., editors, Proc. Extending Database Technology (EDBT), pages 407{421. Springer-Verlag, 1990.
