Static Analysis Techniques for. Predicting the Behavior of Database Production Rules. Alexander Aiken. Jennifer Widom. Joseph M.

Transcription

1 tatic Analysis Techniques for Predicting the Behavior of Database Production Rules Alexander Aiken Jennifer Widom Joseph M. Hellerstein IBM Almaden Research Center 650 Harry Road an Jose, CA Abstract Methods are given for statically analyzing sets of database production rules to determine if the rules are (1) guaranteed to terminate, (2) guaranteed to produce a unique nal database state, and (3) guaranteed to produce a unique stream of observable actions. If the analysis determines that one of these properties is not guaranteed, it isolates the rules responsible for the problem and determines criteria that, if satised, guarantee the property. The analysis methods are presented in the context of the tarburst Rule ystem. 1 Introduction Production rules in database systems allow specication of data manipulation operations that are executed automatically whenever certain events occur or conditions are met, making the database system active [DW92]. Database production rules provide a general and powerful mechanism for many database features, including integrity constraint enforcement, derived data maintenance, triggers, alerters, authorization checking, and versioning. In addition, active database systems provide a convenient platform for large and ecient knowledge-bases and expert systems. A signicant drawback of active database systems, however, lies in the development of correct rule applications: it can be very dicult in general to predict how a set of database production rules will behave. Rule processing occurs as a result of arbitrary database changes; certain rules are triggered initially, and their execution can trigger additional rules or trigger the same rules additional times. The unstructured, unpredictable, and often nondeterministic behavior of rule processing can become a nightmare for the database rule programmer. A signicant step in aiding the database rule programmer is to provide a facility that statically analyzes sets of rules, providing information about the following three properties of rule behavior: Termination: Is rule processing guaranteed to terminate after any set of changes to the database in any state? Current address: Computer ciences Department, University of Wisconsin, Madison, WI

2 Conuence: Can the execution order of non-prioritized rules make any dierence in the nal database state? That is, if multiple rules are triggered at the same time during rule processing, can the nal database state at termination of rule processing depend on which is considered rst? If not, the rule set is conuent. Observable Determinism: If a rule action is visible to the environment (e.g., if it performs data retrieval or a rollback statement), then we say it is observable. Can the execution order of non-prioritized rules make any dierence in the order or appearance of observable actions? If not, the rule set is observably deterministic. These properties can be very dicult or impossible to decide in the general case. However, we have developed conservative static analysis algorithms that: guarantee that a set of rules will terminate or say that it may not terminate; guarantee that a set of rules is conuent or say that it may not be conuent; guarantee that a set of rules is observably deterministic or say that it may not be observably deterministic. Furthermore, when the answer is \may not" for any of these properties, the analysis algorithms isolate the rules responsible for the problem and determine criteria that, if satised, guarantee the property. Hence the analysis can form the basis of an interactive environment where the rule programmer invokes the analyzer to obtain information about rule behavior. If termination, conuence, or observable determinism is desired but not guaranteed, then the user may verify that the necessary criteria are satised or may modify the rule set and try again. Our analysis methods have been developed and are presented in the context of the tarburst Rule ystem [WCL91], a production rules facility integrated into the tarburst extensible relational DBM prototype at the IBM Almaden Research Center [H + 90]. Although some aspects of the analysis are dependent on tarburst rules, we have tried to remain as general as possible, and our methods certainly can be adapted to other database rule languages. 1.1 Related Work Most previous work in static analysis of production rules [HH91,Ras90,ZH90] diers from ours in two ways. First, it considers simplied versions of the OP5 production rule language [BFKM85]. OP5 has a quite dierent model of rule processing than most active database systems, including tarburst. econd, the goal of previous work is to impose restrictions and/or orderings on OP5 rule sets such that unique xed points are guaranteed. Our goal, on the other hand, is to permit arbitrary rule sets and provide useful information about their behavior in the database setting. In ection 11 we make some additional, more technical, comparisons, and we explain how our analysis techniques subsume results in [HH91,Ras90,ZH90]. In [KU91], the issue of rule set termination is discussed, along with the issue of conicting updates determining when one rule may undo changes made by a previous rule. Although models 2

3 and a problem-solving architecture for rule analysis are proposed, no algorithms are given. [CW90] we presented preliminary methods for analyzing termination in the context of deriving production rules for integrity constraint maintenance; these methods form the basis of our approach to termination in this paper. An initial presentation of our analysis methods appears in [AWH92]; in this paper we provide additional intuition, rene and extend the methods in [AWH92], include numerous examples, and provide proofs for all lemmas and theorems. 1.2 Outline of Paper As an introduction to active databases and to establish a basis for our analysis techniques, in ection 2 we give a syntax and semantics for the tarburst production rule language; ection 3 then motivates the termination, conuence, and observable determinism properties in the context of this language. In ection 4 we provide examples of tarburst production rules, illustrating rule sets that do and do not satisfy termination, conuence, and observable determinism. In ection 5 we introduce notation and denitions needed for rule analysis and we dene some straightforward preliminary analysis techniques. In ection 6 we present a model of rule processing to be used as the formal basis for our analysis algorithms. Termination analysis is covered in ection 7 and conuence in ection 8. In ection 9 we give methods for analyzing partial conuence, which species that a rule set is conuent with respect to a portion of the database. Observable determinism is covered in ection 10. Finally, in ection 11 we draw conclusions and discuss future work. In 2 The tarburst Rule ystem We provide a brief overview of the tarburst database production rule language. Examples are given in ection 4; additional examples and further details appear in [WCL91,WF90]. tarburst production rules are based on the notion of transitions. A transition is a database state change resulting from execution of a sequence of data manipulation operations. Rules consider only the net eect of transitions, meaning that: (1) if a tuple is updated several times, only the composite update is considered; (2) if a tuple is updated then deleted, only the deletion is considered; (3) if a tuple is inserted then updated, this is considered as inserting the updated tuple; (4) if a tuple is inserted then deleted, this is not considered at all. A formal theory of transitions and their net eects appears in [WF90]. The syntax for dening a rule is: create rule name on table when triggering-operations [ if condition ] then action [ precedes rule-list ] [ follows rule-list ] The triggering-operations are one or more of inserted, deleted, and updated(c 1 ; : : : ; c n ), where c 1 ; : : : ; c n are columns of the rule's table. The rule is triggered by a given transition if at least 3

4 one of the specied operations occurred in the net eect of the transition. The optional condition species an QL predicate. 1 The action species an arbitrary sequence of database operations to be executed when the rule is triggered and its condition is true; these operations may be QL data modication operations (insert, delete, update), QL data retrieval operations (select), and transaction abort (rollback). The optional precedes and follows clauses are used to induce a partial ordering on the set of dened rules. If a rule r 1 species a rule r 2 in its precedes list, or if r 2 species r 1 in its follows list, then r 1 is higher than r 2 in the ordering. (We also say that r 1 has precedence or priority over r 2.) When no direct or transitive ordering is specied between two rules, their order is arbitrary. 2 A rule's condition and action may refer to the current state of the database through top-level and nested QL select operations. In addition, rule conditions and actions may refer to transition tables, which are logical tables reecting the changes to the rule's table that have occurred during the triggering transition. At the end of a given transition, transition table inserted in a rule refers to those tuples of the rule's table that were inserted by the transition, transition table deleted refers to those tuples that were deleted, and transition tables new-updated and old-updated refer to the new and old values (respectively) of the updated tuples. A rule may refer only to transition tables corresponding to its triggering operations. Rules are activated at rule processing points. There is an automatic rule processing point at the end of each transaction, and there may be additional user-specied rule processing points within a transaction. We describe the semantics of rule processing at an arbitrary point. The state change resulting from the user-generated data modication operations executed since the last rule processing point (or start of the transaction) creates the rst relevant transition, and some rules are triggered by this transition. As rule actions are executed, additional transitions are created which may trigger additional rules or trigger the same rules additional times. Rule processing follows an iterative algorithm in which: 1. A triggered rule r is selected for consideration such that no other triggered rule has precedence over r. 2. r's condition is evaluated. 3. If r's condition is true then r's action is executed. For step 1 in this algorithm, a rule is triggered if one or more of its triggering operations occurred in the composite transition since the last time the rule was considered, or since the start of the transaction if the rule has not yet been considered. (The eect of this semantics is that each rule 1 In the current implementation rule conditions are QL select statements, where the condition is true i the select statement produces one or more tuples. In the context of rule conditions and for the purposes of rule analysis, predicates and select statements are equivalent [WCL91]. 2 The system actually orders non-prioritized rules using an algorithm based on rule creation time [ACL91], but this is an implementation feature separate from the semantics of the rule language. 4

5 sees each modication exactly once.) Rule processing terminates when a rollback operation is executed or when there are no more triggered rules. User-invoked rule processing may specify that only a subset of the dened rules should be considered for execution, rather than all rules [Wid92]. Hence, the rule programmer may want to predict the behavior of a subset of the rules. The semantics of rule processing for rule subsets is identical to rule processing in the general case, so our analysis methods can be applied directly to arbitrary rule subsets. The analysis techniques we present are based on the tarburst rule language and rule processing semantics, but with modications the methods also could apply to other similar languages; see ection Termination, Conuence, and Observable Determinism uppose a set of tarburst rules has been dened using the language described in ection 2. Further suppose that arbitrary data modication operations have been performed, creating an initial triggering transition, and then rule processing is invoked. From the algorithm given in ection 2 it is clear that rule processing may not terminate rules could trigger each other forever. A set of tarburst rules has the termination property if, for any initial triggering transition, rule processing is guaranteed to terminate, i.e. eventually rollback is executed or there are no more triggered rules. In step 1 of the rule processing algorithm, a rule r is selected such that no other triggered rule has precedence over r. ince the precedence of rules may be only a partial order (indeed, no ordering is required), many rules may be eligible for selection in this step. A set of tarburst rules has the conuence property if, for any initial triggering transition, there is some database state D such that if rule processing terminates it terminates with the database in state D, regardless of which eligible rule is selected each time step 1 is performed. Finally, when rule actions are executed (step 3 in the rule processing algorithm), these actions may be visible to the environment in which the transaction is executing. For example, actions may perform data retrieval, or they may abort the transaction. A set of tarburst rules has the observable determinism property if, for any initial triggering transition, the sequence of select and rollback operations executed during rule processing (including the values returned by select operations) is identical, regardless of which eligible rule is selected each time step 1 is performed. 4 Examples For examples we consider a simple database schema with three tables: emp(id, rank, salary) bonus(emp-id, amount) sales(emp-id, month, number) Table emp records each employee's rank and salary, table bonus records a bonus amount to be awarded to each employee, and table sales records each employee's number of sales on a monthly 5

6 basis. Because our example rules are quite simple, none includes an if clause; this does not detract from illustrating the salient points of termination, conuence, and observable determinism. Example 4.1 (nonterminating) Nontermination is illustrated with two (admittedly contrived) rules. The rst rule, bonus-rank, states that whenever an employee's bonus is increased by more than 100, that employee's rank is increased by 1: create rule bonus-rank on bonus when updated(amount) then update emp set rank = rank + 1 where id in (select emp-id from new-updated, old-updated where new-updated.emp-id = old-updated.emp-id and new-updated.amount - old-updated.amount > 100) The second rule, rank-bonus, states that whenever an employee's rank is modied, that employee's bonus is increased by 10 times the new rank: create rule rank-bonus on emp when updated(rank) then update bonus set amount = amount + 10 * (select rank from new-updated where emp-id in (select id from new-updated) where new-updated.id = bonus.emp-id) With these two rules, whenever an employee's rank is modied to greater than 10, or whenever an employee with rank at least 10 receives a bonus greater than 100, rule processing does not terminate the rules trigger each other forever. 2 Example 4.2 (terminating, non-conuent) This is the most subtle and interesting of our examples. We specify three rules that are guaranteed to terminate. We suggest an ordering for the rules that appears to guarantee conuence, then we explain how this ordering is in fact insucient for conuence. The rst rule, good-sales, increases an employee's salary by 10 whenever that employee posts sales greater than 50 for a month: create rule good-sales on sales when inserted then update emp set salary = salary + 10 where id in (select emp-id from inserted where number > 50) The second rule, great-sales, increases an employee's rank by 1 whenever that employee posts sales greater than 100 for a month: create rule great-sales on sales when inserted then update emp set rank = rank + 1 where id in (select emp-id from inserted where number > 100) 6

7 Although rules good-sales and great-sales may be triggered at the same time, their actions cannot aect each other, so no relative ordering between the rules is needed for conuence. The third rule, rank-raise, increases an employee's salary by 10% whenever that employee's rank reaches 15 (we assume that ranks do not decrease): create rule rank-raise on emp when updated(rank) then update emp set salary = 1.1 * salary where id in (select id from new-updated where rank = 15) For conuence it is clear that a relative ordering is required between rule rank-raise and rule good-sales since, if both rules are triggered at the same time, the order in which their actions execute inuences the nal salary. We specify that rank-raise has priority over good-sales, so the 10% increase given by rank-raise does not reect the increase of 10 given by good-sales. It also is clear that a relative ordering is required between rule rank-raise and rule great-sales since, if both rules are triggered at the same time, executing great-sales rst could increase an employee's rank to 16 before rank-raise awards the 10% increase. Hence, we add the following clause to rule rank-raise: precedes good-sales, great-sales It turns out that these orderings still are insucient for conuence. uppose rules good-sales and great-sales are triggered at the same time, and there is an employee whose newly posted sales exceeds 100, whose salary is 60, and whose rank is 14. uppose rule good-sales is executed rst. Then good-sales increases the employee's salary to 70, great-sales increases the employee's rank to 15, and nally rank-raise is triggered and increases the employee's salary to 77. Now suppose instead that rule great-sales is executed rst. Then great-sales increases the employee's rank to 15, rank-raise is triggered and increases the employee's salary to 66, and nally good-sales increases the employee's salary to 76. Hence there are two possible nal values for the employee's salary, and the rules are not conuent. The important property to observe here is that there are two rules (good-sales and greatsales) that appear to be unrelated and therefore appear to need no relative ordering. However, the existence of a third rule (rank-raise) that is related to both of the rst two rules means that the rst two rules must be ordered to achieve conuence. 2 Example 4.3 (terminating, conuent, not observably deterministic) Consider rules goodsales and rank-raise from Example 4.2, ordered so that rank-raise precedes good-sales. Now add a third rule, new-rank, that displays an employee's ID, rank, and salary, along with a \newrank" message, whenever that employee's rank is modied: create rule new-rank on emp when updated(rank) then select id,rank,salary,"new-rank" from new-updated 7

8 These three rules are guaranteed to terminate and they are conuent the nal database state is guaranteed to be unique. However, the rules are not observably deterministic. uppose all three rules are triggered at the same time. Then the salaries displayed by rule new-rank may take on three dierent values, depending on whether new-rank is executed before rank-raise, after rank-raise but before good-sales, or after good-sales. 2 Example 4.4 (terminating, conuent, observably deterministic) Consider rule bonus-rank from Example 4.1, rule good-sales from Example 4.2, and rule new-rank from Example 4.3, with new-rank specied to follow bonus-rank and good-sales. This set of rules exhibits all three properties: termination, conuence, and observable determinism. 2 5 Denitions and Preliminary Analysis Let R = fr 1 ; r 2 ; : : : ; r n g denote an arbitrary set of tarburst production rules to be analyzed. Analysis is performed on a xed set of rules when the rule set is changed, analysis must be repeated. (Incremental methods are certainly possible; see ection 11.) Let P denote the set of user-dened priority orderings on rules in R (as specied by their precedes and follows clauses), including those implied by transitivity. P = fr i > r j ; r k > r l ; : : :g, where r i > r j denotes that rule r i has precedence over r j. Let T = ft 1 ; t 2 ; : : : ; t m g denote the tables in the database schema, and let C = ft i :c j ; t k :c l ; : : :g denote the columns of tables in T. Finally, let O denote the set of database modication operations: O = fhi; ti j t 2 T g [ fhd; ti j t 2 T g [ fhu; t:ci j t:c 2 Cg hi; ti denotes insertions into table t, hd; ti denotes deletions from table t, and hu; t:ci denotes updates to column c of table t. The following denitions are computed using straightforward preliminary analysis of the rules in R: Triggered-By takes a rule r and produces the set of operations in O that trigger r. Triggered- By is trivial to compute based on rule syntax. Performs takes a rule r and produces the set of operations in O that may be performed by r's action. Performs is trivial to compute based on rule syntax. Triggers takes a rule r and produces all rules r 0 that can become triggered as a result of r's action (possibly including r itself). Triggers(r) = fr 0 2 R j Performs(r) \ Triggered-By(r 0 ) 6= ;g. Uses takes a rule r and produces all columns in C that may be referenced when evaluating r's condition or executing a data modication operation in r's action. Uses(r) contains every t:c referenced in r's condition, every t:c referenced in the where clause of a delete or update operation in r's action, and every t:c referenced in a nested select expression in an insert, delete, or update operation in r's action. In addition, for every htransi:c referenced in 8

9 this same way, where htransi is one of inserted, deleted, new-updated, or old-updated, t:c is in Uses(r) for r's triggering table t. (Recall from ection 2 that inserted, deleted, new-updated, and old-updated are transition tables based on changes to t.) Can-Untrigger takes a set of operations O 0 O and produces all rules that can be \untriggered" as a result of operations in O 0. A rule is untriggered if it is triggered at some point during rule processing but not chosen for consideration, then subsequently no longer triggered because all triggering changes were undone by other rules. 3 Can-Untrigger(O 0 ) = fr 2 R j hd; ti 2 O 0 and hi; ti or hu; t:ci 2 Triggered-By(r) for some t 2 T; t:c 2 Cg. Choose takes a set of triggered rules R 0 R and produces a subset of R 0 indicating those rules eligible for consideration (based on priorities). Choose(R 0 ) = fr i j r i 2 R 0 and there is no r j 2 R 0 such that r j > r i 2 P g. Rollback takes a rule r and indicates whether executing r's action is guaranteed to abort the transaction. In tarburst, Rollback(r) is true i one of the operations comprising r's action is rollback. Observable takes a rule r and indicates whether r's action may be observable. In tarburst, a rule's action may be observable i it includes rollback or a top-level select statement. 6 Execution Model We now dene a formal model of execution-time rule processing. The model is based on execution graphs and accurately captures the semantics of rule processing described in ection 2. Note that execution graphs are used to discuss and to prove the correctness of our analysis techniques, but these graphs are never actually constructed and they are not part of the analysis itself. A directed execution graph has a distinguished initial state representing the start of rule processing (at any processing point) and zero or more nal states representing termination of rule processing. The paths in the graph represent all possible execution sequences during rule processing; branches in the graph result from choosing dierent rules to consider when more than one is eligible. (Hence any graph for a totally ordered rule set has no branches.) The graph may have innitely long paths (possibly but not necessarily due to cycles in the graph); these paths represent nontermination of rule processing. More formally, a state (node) in an execution graph has two components: (1) a database state D; (2) a set TR containing each triggered rule and its associated transition tables. We denote this state as = (D; TR). The initial state I is created by an initial transition, which results from a sequence of user-generated database operations. Hence, I = (D I ; TR I ) where D I is a database state and there is some set of operations O 0 O such that: 3 As an example, a rule r1 might be triggered by insertions, but another rule r2 might delete all inserted tuples before r1 is chosen for consideration. Untriggering is rare in practice. 9

10 TR I = fr 2 R j O 0 \ Triggered-By(r) 6= ;g O 0 is the set of operations producing the initial transition, and TR I contains the rules triggered by those operations. A nal state F is some (D F ; ;), since no rules are triggered when rule processing terminates. Note that a nal state F may correspond to normal termination or it may correspond to termination due to a rollback statement; in the latter case F = (D T ; ;), where D T is the database state at the start of the transaction. Each directed edge in an execution graph is labeled with a rule r and represents the consideration of r during rule processing. (This includes determining whether r's condition is true and, if so, executing r's action.) Using denitions from ection 5, the following lemma states certain properties that hold for all execution graphs. The lemma is stated without proof it follows directly from the semantics of rule processing described in ection 2. Lemma 6.1 (Properties of Execution Graphs) state (D 1 ; TR 1 ) to a state (D 2 ; TR 2 ) labeled with a rule r. Then: r 2 Choose(TR 1 ) Either: (1) Rollback(r), D 2 = D T, and TR 2 = ;; or Consider any execution graph edge from a (2) There is some (possibly empty) set of operations O 0 Performs(r) such that the triggered rules in TR 2 can be derived from the triggered rules in TR 1 by: (a) removing rule r (b) removing some subset of the rules in Can-Untrigger(O 0 ) (c) adding all rules r 0 2 R such that O 0 \ Triggered-By(r 0 ) 6= ; 2 Case (1) corresponds to the situation in which r's condition is true and its action includes rollback. Case (2) corresponds to the situation in which r's condition is false, or r's condition is true and its action does not include rollback. In case (2), the operations in O 0 are those executed by r's action, where O 0 is empty if r's condition is false. If r's condition is true then O 0 still may be a proper subset of Performs(r) since, by the semantics of QL, for most operations there are certain database states on which they have no eect. Finally, note that although rule r is removed in step (a), r may be added again in step (c) if O 0 \ Triggered-By(r) 6= ;. The properties in Lemma 6.1 are guaranteed for all execution graphs. By performing more complex analysis on rule conditions and actions, by incorporating properties of database states, and by considering a variety of special cases, we probably can identify additional properties of execution graphs. ince our analysis techniques are based on execution graph properties, more accurate properties may result in more accurate rule analysis. We believe that the properties used here, although somewhat conservative, are suciently accurate to yield strong analysis techniques. 10

11 7 Termination We want to determine whether the rules in R are guaranteed to terminate. That is, we want to determine if for all user-generated operations and initial database states, rule processing always reaches a point at which there are no triggered rules to consider. We take as an assumption that individual rule actions terminate. Hence, in terms of execution graphs, the rules in R are guaranteed to terminate i all paths in every execution graph for R are nite. As suggested in [CW90], termination is analyzed by constructing a directed triggering graph for the rules in R, denoted TG R. The nodes in TG R represent all rules r 2 R such that Rollback(r) is false; the edges in TG R represent the Triggers relationship. That is, there is an edge from r i to r j in TG R i r j 2 Triggers(r i ). We exclude a rule r i from the graph if Rollback(r i ), since if r i contains rollback then it will not trigger any other rule r j, even if technically r j 2 Triggers(r i ). 4 Theorem 7.1 (Termination) If there are no cycles in TG R then the rules in R are guaranteed to terminate. Proof: We must prove that all paths in every execution graph for R are nite. uppose, for the sake of a contradiction, that there are no cycles in graph TG R but there is an innite path p in some execution graph for R. Then, since there are only nitely many rules, some rule r must appear on innitely many edges on path p. By the properties of execution graphs in Lemma 6.1, r must be added to set TR of triggered rules (by step 3) innitely many times. Hence there must be some operation o 2 Triggered-By(r) that is performed innitely many times. ince o is in Performs(r 1 ) for only a nite number of rules r 1, there must be some rule r 1 such that o 2 Performs(r 1 ) and r 1 appears on innitely many edges on path p. Note that, by denition, r 2 Triggers(r 1 ), so there is an edge from r 1 to r in TG R. ince r 1 appears on innitely many edges, r 1 must be added to set TR innitely many times. By the same reasoning as above, there is some rule r 2 such that r 1 2 Triggers(r 2 ) (so there is an edge from r 2 to r 1 in TG R ) and r 2 appears on innitely many edges on path p. This reasoning continues, generating rules r 3, r 4, etc. ince, by assumption, there are no cycles in graph TG R, this reasoning generates innitely many rules, a contradiction. 2 Hence, to determine whether the rules in R are guaranteed to terminate, triggering graph TG R is constructed and checked for cycles. As an example, consider the triggering graph TG R for rules R = fbonus-rank, rank-bonusg of Example 4.1. There are two nodes in TG R, one representing rule bonus-rank (call the node br) and one representing rule rank-bonus (call the node rb). ince rank-bonus 2 Triggers(bonus-rank), there is an edge in TG R from node br to node rb. imilarly, since bonus-rank 2 Triggers(rank-bonus), there is an edge in TG R from node rb to node br. Therefore, there is a cycle in TG R, and our analysis determines that this set of rules may not terminate. In Examples 4.2, 4.3, and 4.4, the triggering graphs are acyclic, so our analysis determines that the rules are guaranteed to terminate. 4 If Rollback(ri) and rj 2 Triggers(ri), then ri must include both a data modication operation and a rollback operation in its action. This is allowed syntactically, but semantically it makes little sense the eect of the data modication operation always will be undone when the rollback operation is executed. 11

12 Although our approach to termination may appear to be very conservative, by considering only the known properties of our execution graph model (Lemma 6.1), we see that whenever there is a cycle in the triggering graph, our analysis cannot rule out the possibility that there is an execution graph with an innite path. Clearly, however, there are a number of special cases in which there is a cycle in the triggering graph but other properties (not captured in Lemma 6.1) guarantee termination. Examples are: The action of some rule r on the cycle only deletes from a table t, and no other rules on the cycle insert into t. Eventually r's action has no eect. The action of some rule r on the cycle only performs a \monotonic" update (e.g. increments values), guaranteeing that the condition of some rule r 0 on the cycle eventually becomes false (e.g. some value is less than 10). Although some such cases may be detected automatically, for now we assume that they are discovered by the user through the interactive analysis process: Once the analyzer has built the triggering graph for the rules in R, the user is notied of all cycles (or strong components). If the user is able to verify that, on each cycle, there is some rule r such that repeated consideration of the rules on the cycle guarantee that r's condition eventually becomes false or r's action eventually has no eect, then the rules in R are guaranteed to terminate. As part of a case study, we used this approach to establish termination for a set of rules in a power network design application [CW90]. 8 Conuence Next we want to determine whether the rules in R are conuent. That is, we want to determine if the nal database state at termination of rule processing can depend on which rule is chosen for consideration when multiple non-prioritized rules are triggered. In terms of execution graphs, the rules in R are conuent if every execution graph for R has at most one nal state. (Recall that all nal states in an execution graph have an empty set of triggered rules, so two dierent nal states cannot represent the same database state.) Conuence for production rules is a particularly dicult problem because, in addition to the standard problems associated with conuence [Hue80], we must take into account the interactions between rule triggering and rule priorities. For example, it is not sucient to simply consider the combined eects of two rule actions; it also is necessary to consider all rules that can become triggered, directly or indirectly, by those actions, and the relative ordering of these triggered rules (recall Example 4.2). These issues are discussed further as we develop our requirements for conuence in ection 8.3. As preliminaries, we rst introduce the notion of rule commutativity, and we make a useful observation about execution graphs. 12

13 r i r r j@@r r i 0 Figure 1: Commutative rules 8.1 Rule Commutativity We say that two rules r i and r j are commutative (or r i and r j commute) if, given any state in any execution graph, considering rule r i and then rule r j from state produces the same execution graph state 0 as considering rule r j and then rule r i ; this is depicted in Figure 1. If this equivalence does not always hold, then r i and r j are noncommutative (or r i and r j do not commute). Each rule clearly commutes with itself. Based on the denitions of ection 5, we give a set of conditions for analyzing whether pairs of distinct rules commute. Lemma 8.1 For distinct rules r i and r j, if any of the following conditions hold then r i and r j may be noncommutative; otherwise they are commutative: 1. r j 2 Triggers(r i ), i.e. r i can cause r j to become triggered 2. r j 2 Can-Untrigger(Performs(r i )), i.e. r i can untrigger r j 3. hi; ti, hd; ti, or hu; t:ci is in Performs(r i ) and t:c is in Uses(r j ) for some t:c 2 C, i.e. r i 's operations can aect what r j uses 4. hi; ti is in Performs(r i ) and hd; ti or hu; t:ci is in Performs(r j ) for some t 2 T or t:c 2 C, i.e. r i 's insertions can aect what r j updates or deletes 5 5. hu; t:ci is in both Performs(r i ) and Performs(r j ), i.e. r i 's updates can aect r j 's updates 6. any of 1{5 with r i and r j reversed 2 It is straightforward to verify that if a pair of rules does not satisfy any of 1{6 then the rules are guaranteed to commute. As illustration, consider the examples from ection 4: Example 4.1 { Rules bonus-rank and rank-bonus are noncommutative according to condition 1 of Lemma 8.1, because rank-bonus 2 Triggers(bonus-rank). 5 In QL it is possible to delete from or update a table without referencing columns of the table, which is why cases 4 and 5 are distinct from case 3. 13

14 Example 4.2 { Rules good-sales and great-sales are commutative. Rules good-sales and rank-raise are noncommutative according to condition 5, because hu; emp:salaryi is in both Performs(good-sales) and Performs(rank-raise). Rules great-sales and rank-raise are noncommutative according to condition 3, because hu; emp:ranki is in Performs(greatsales) and emp.rank is in Uses(rank-raise). (Recall from ection 5 that emp.rank is in Uses(rank-raise) because new-updated.rank is referenced and emp is the triggering table.) Rules great-sales and rank-raise are noncommutative also according to condition 1, because rank-raise 2 Triggers(great-sales). Example 4.3 { Rules good-sales and rank-raise are noncommutative as in Example 4.2. Rules good-sales and new-rank are commutative; rules rank-raise and new-rank also are commutative. (Rule new-rank commutes with rules good-sales and rank-raise because, although new-rank does access column emp.salary, this column is not in Uses(newrank) it is not used in the rule's condition or in a data modication action.) Example 4.4 { Rules bonus-rank and good-sales are commutative. Rules bonus-rank and new-rank are noncommutative according to condition 1, because new-rank 2 Triggers(bonusrank). Rules good-sales and new-rank are commutative. The conditions in Lemma 8.1 are somewhat conservative and probably could be rened by performing more complex analysis on rule conditions and actions and by considering a variety of special cases. As two examples of this, consider rules r i and r j such that 1. r i inserts into a table t and r j deletes from t, but the tuples inserted by r i never satisfy the delete condition of r j 2. r i and r j update the same table and column but never the same tuples In the rst example, r i and r j are noncommutative according to condition 4 of Lemma 8.1, but they do actually commute. In the second example, r i and r j are noncommutative according to condition 5 but do commute. Although some such cases may be detected automatically, for now we assume that they are specied by the user during the interactive analysis process: We allow the user to declare that pairs of rules that appear noncommutative according to Lemma 8.1 actually do commute. The analysis algorithms then treat these rules as commutative. 8.2 Observation We say that two rules r i and r j are unordered if neither r i > r j nor r j > r i is in P. (imilarly, we say two rules r i and r j are ordered if r i > r j or r j > r i is in P.) Based on our execution graph model, we make the following observation about possible states, which is used in the next section to develop our criteria for conuence. Observation 8.2 Consider any two unordered rules r i and r j in R. It is very likely that there is an execution graph with a state that has (at least) two outgoing edges, one labeled r i and one 14

15 labeled r j. (Informally, there is very likely a scenario in which both r i and r j are triggered and eligible for consideration. Recall that a triggered rule r is eligible for consideration i there is no other triggered rule with precedence over r.) Justication: Let O 0 = Triggered-By(r i ) [ Triggered-By(r j ). Consider an execution graph for which the operations in O 0 are the initial user-generated operations, so that r i and r j are both triggered in the initial state. Consider any path of length 0 or more from the initial state to a state = (D; TR) in which there are no rules r 2 TR such that r > r i or r > r j is in P, i.e. there are no triggered rules with precedence over r i or r j. 6 tate has at least two outgoing edges, one labeled r i and one labeled r j Analyzing Conuence We now return to the question of conuence. We want to determine if every execution graph for R is guaranteed to have at most one nal state. For two execution graph states i and j, let i! j denote that there is an edge in the execution graph from state i to state j and let i! j denote that there is a path of length 0 or more from i to j. (! is the reexive-transitive closure of!.) Our rst Lemma establishes conditions for conuence based on!: Lemma 8.3 (Path Conuence) Consider an arbitrary execution graph EG and suppose that for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0 (Figure 2a). Then EG has at most one nal state. 7 Proof: uppose, for the sake of a contradiction, that EG has two distinct nal states, F 1 and F 2. Let I be the initial state, so I! F 1 and I! F 2. Then, by assumption, there must be a fourth state such that F 1! and F2!. ince F1 and F 2 are both nal states, = F 1 and = F 2, contradicting F 1 6= F 2. 2 It is quite dicult in general to determine when the supposition of Lemma 8.3 holds, since it is based entirely on arbitrarily long paths. The following Lemma gives a somewhat weaker condition that is easier to verify and implies the supposition of Lemma 8.3; it does, however, add the requirement that rule processing is guaranteed to terminate: Lemma 8.4 (Edge Conuence) Consider an arbitrary execution graph EG with no innite paths. uppose that for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0 (Figure 2b). Then for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0. Proof: Classic result; see e.g. [Hue80]. 6 uch a path does not exist if ri or rj is untriggered along all potential paths, or if rules with precedence over ri or rj are considered indenitely along all potential paths. These are highly unlikely (and probably undesirable) circumstances, but are why this is an observation rather than a theorem. 7 ometimes the term conuence is used to denote the supposition of this Lemma [Hue80], which then implies conuence in the sense that we've dened it. 15

16 i j 0 (a) Based on paths r i r j 0 (b) Based on edges Figure 2: Conditions for conuence We use Lemma 8.4 as the basis for our analysis techniques. Based on this Lemma (along with Lemma 8.3), we can guarantee conuence for the rules in R if we know 1. there are no innite paths in any execution graph for R (i.e., the rules in R are guaranteed to terminate), and 2. in any execution graph for R, for any three states, i, and j such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0. We assume that the rst condition has been established through the analysis techniques of ection 7; we focus our attention on analysis techniques for establishing the second condition. Consider any execution graph for R and any three states, i, and j such that! i and! j. This conguration is produced by every state that has at least two unordered triggered rules that are eligible for consideration. Let r i be the rule labeling edge! i and r j be the rule labeling edge! j, as in Figure 2b. We want to prove that there is a fourth state 0 such that i! 0 and j! 0. It is tempting to assume that if r i and r j are commutative, then r j can be considered from state i and r i from j, producing a common state 0 as in Figure 1. Unfortunately, this is not always possible: If r i causes a rule r with precedence over r j to become triggered, then r j is not eligible for consideration in state i (similarly for r i in state j ). ince the new triggered rule r must be considered before rule r j, r must commute with r j. Furthermore, r may cause additional rules with precedence over r j to become triggered. With this in mind, we motivate the requirements for the existence of a common state 0 that is reachable from both i and j. We do this by attempting to \build" valid paths from i and j towards 0 ; call these paths p 1 and p 2, respectively. From state i, triggered rules with precedence over r j are considered until r j is eligible; call these rules R 1. imilarly, from j triggered rules with precedence over r i are considered until r i is eligible; call these rules R 2. After this, r j can be considered on path p 1 and r i can be considered on path p 2. Paths p 1 and p 2 up to this point are depicted in Figure 3. Now suppose that from state 0 i we can continue path p 1 by considering the rules in R 2 (in the same order), i.e. suppose the rules in R 2 are appropriately triggered and eligible. imilarly, suppose 16

17 r i r j r j r i?? i 0 j 0 R 1 R 2?? Figure 3: Paths towards common state 0 that from 0 j we can consider the rules in R 1. Then the same rules are considered along both paths. Consequently, if each rule in fr i g [ R 1 commutes with each rule in fr j g [ R 2, then the two paths are equivalent and reach a common state 0 ; this is depicted in Figure 4. Unfortunately, even this scenario is not necessarily valid: There is no guarantee that the rules in R 2 are triggered and eligible from state i 0; similarly for R 1 and j 0. (For example, a rule in may not be eligible from state i 0 because r j triggered a rule with higher priority.) We can R 2 guarantee this, however, if we extend the rules originally considered in R 1 to include all eligible rules with precedence over rules in R 2, and extend the rules in R 2 similarly. Using this mutually recursive denition of R 1 and R 2, the pairwise commutativity of rules in fr i g [ R 1 with rules in fr j g [ R 2 guarantees the existence of state 0, and consequently guarantees conuence. To establish conuence for the rules in R, then, we must consider in this fashion every pair of rules r i and r j such that some state in some execution graph for R may have two outgoing edges, one labeled with r i and one with r j. Recall Observation 8.2: For any two unordered rules r i and r j, it is very likely that there is an execution graph with a state that has two outgoing edges, one labeled r i and one labeled r j. Consequently, we consider every pair of unordered rules, and our analysis requirement for conuence is stated as follows. Denition 8.5 (Conuence Requirement) Consider any pair of unordered rules r i and r j in R. Let R 1 R and R 2 R be constructed by the following algorithm: R 1 R 2 fr i g fr j g repeat until unchanged: R 1 R 1 [ fr 2 R j r 2 Triggers(r 1 ) for some r 1 2 R 1 and r > r 2 2 P for some r 2 2 R 2 and r 6= r j g R 2 R 2 [ fr 2 R j r 2 Triggers(r 2 ) for some r 2 2 R 2 and r > r 1 2 P for some r 1 2 R 1 and r 6= r i g For every pair of rules r 1 2 R 1 and r 2 2 R 2, r 1 and r 2 must commute. 2 17

18 r i r j r j r i?? i 0 j R 2@@R R 1 0 R 1 R 2?? Figure 4: Paths reaching common state 0 The following lemma and theorem formally prove that the requirement of Denition 8.5 indeed guarantees conuence. Lemma 8.6 (Conuence Lemma) uppose the Conuence Requirement (Denition 8.5) holds for R. Then in any execution graph EG for R, for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0. Proof: ee Appendix A.1. (The formal proof parallels the motivation shown in Figure 4, although the full construction is slightly more complex.) Theorem 8.7 (Conuence Theorem) uppose the Conuence Requirement holds for R and there are no innite paths in any execution graph for R. Then any execution graph for R has exactly one nal state, i.e. the rules in R are conuent. Proof: Let EG be any execution graph for R. By Conuence Lemma 8.6, for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0. Therefore, by Edge Conuence Lemma 8.4, for any three states, i, and j in EG such that! i and! j, there is a fourth state 0 such that i! 0 and j! 0. By Path Conuence Lemma 8.3, EG has at most one nal state, hence (since there are no innite paths) EG has exactly one nal state. 2 Thus, analyzing whether the rules in R are conuent requires considering each pair of unordered rules r i and r j in R: ets R 1 and R 2 are built from r i and r j according to Denition 8.5, and the rules in R 1 and R 2 are checked pairwise for commutativity. 8.4 Examples Consider Example 4.2 in which there are three rules: good-sales, great-sales, and rank-raise. The only pair of unordered rules is good-sales and great-sales. Letting r i = good-sales and 18

19 r j = great-sales, we construct sets R 1 and R 2 of Denition 8.5. R 1 = fgood-salesg, since there are no rules in Triggers(good-sales). R 2 = fgreat-sales, rank-raiseg, since rank-raise 2 Triggers(great-sales) and rank-raise > good-sales. Now, since good-sales 2 R 1 and rankraise 2 R 2 do not commute (recall ection 8.1), then according to Denition 8.5 we cannot conclude that this set of rules is conuent. To see this in terms of execution graphs, consider a state in which good-sales and great-sales are both triggered. If good-sales is considered rst, then path p 1 from to a nal state considers rules good-sales, great-sales, and rank-raise, in that order. If great-sales is considered rst, then path p 2 from to a nal state considers rules greatsales, rank-raise, and good-sales, in that order. Although rules good-sales and great-sales do commute, rules good-sales and rank-raise do not. Hence paths p 1 and p 2 may lead to dierent nal states. Now consider Example 4.3 in which there are three rules: good-sales, rank-raise, and newrank. There are two pairs of unordered rules: good-sales/new-rank and rank-raise/new-rank. For both pairs, sets R 1 and R 2 of Denition 8.5 contain only the rules themselves, and the rules commute. Hence by Theorem 8.7 the rules are conuent. Finally consider Example 4.4 in which there are three rules: bonus-rank, good-sales, and new-rank. The only pair of unordered rules is bonus-rank and good-sales. Letting r i = bonus-rank and r j = good-sales, we construct sets R 1 and R 2 of Denition 8.5; consider R 2 rst. R 2 = fgood-salesg, since there are no rules in Triggers(good-sales). R 1 = fbonus-rankg, since although new-rank 2 Triggers(bonus-rank), there is no rule r 2 2 R 2 such that new-rank > r 2. ince good-sales and bonus-rank commute, the rules are conuent. 8.5 Using Conuence Analysis If our analysis determines that the rules in a set R are not conuent, it can be attributed to pairs of unordered rules r i and r j that generate sets R 1 and R 2 such that rules r 1 2 R 1 and r 2 2 R 2 do not commute. (In the most common case, r 1 and r 2 are r i and r j themselves; see Corollary 8.8 below.) With this information, it appears that the user has three possible courses of action towards conuence (short of modifying the rules themselves): 1. Certify that rules r 1 and r 2 actually do commute 2. pecify a user-dened priority between rules r i and r j so they no longer must satisfy the Conuence Requirement 3. Remove user-dened priorities so r 1 or r 2 is no longer part of R 1 or R 2 Approach 1 is clearly the best when it is valid. Approach 3 is non-intuitive and in fact useless: removing orderings to eliminate r 1 or r 2 from R 1 or R 2 simply produces a corresponding violation to the Conuence Requirement elsewhere. Hence, if Approach 1 is not applicable (i.e. rules r 1 and r 2 do not commute) then Approach 2 should be used. Note, however, that adding an ordering 19