CSE 880. Advanced Database Systems. Active Database Design Issues

Transcription

1 CSE 880 Advanced Database Systems Active Database Design Issues S. Pramanik 1

2 Design Principles for Active Databases 1. Problems: Complex interactions due to cascading of triggers. Unknown side effects of inserting, deleting and modifying rules. 2. Cascading can be recursive or nested. Recursive trigger: A trigger TR1 is recursive when an application updates table T1, which fires trigger TR1 updating table T1. This is a direct recursion. Recursion can be indirect as well where an application updates table T1, which fires trigger TR1 updating table T2. Trigger TR2 defined on table T2 then updates table T1. Nested triggers: If a trigger changes a table on which there is another trigger, the second trigger is then activated and can then call a third trigger, and so on. Maximum number of cascading allowed in Oracle is 32; When it exceeds 32, all database changes as a result of original SQL are rolled back. 2

3 Example of recursive rules: If average salary of employees exceed 100, reduce salary of each employee by 10% CREATE TRIGGER SalaryControl AFTER INSERT, DELETE, UPDATE ON Salary OF EMP WHEN (Select AVG(Salary) From EMP>100) THEN Update EMP Set Salary=.9*Salary Table EMP: Name Salary john 90 David 100 Insert tuple (Rick, 200) How many times the trigger is invoked? If Set Salary=.9*Salary changed to Set Salary=1.1*Salary it goes into an infinite loop. 3

4 Correctness of Evaluation of Interacting Rules: 1. Termination: for any user defined transaction triggering a set of rules, processing of the rules eventually terminates, producing a f inal state. 2. Confluence: for any user defined transaction termination holds and produces a unique final state. 3. Observable Determinism: for any user defined transaction confluence holds and all visible actions performed by the rules are also the same. 4

5 Example of Non-Termination 1. Triggering Graph: It is a directed graph where each node corresponds to a rule and a directed edge from node A to node B implies that the rule corresponding to node A has an action invoking the rule corresponding to node B. Example: R1: SalaryControl (defined earlier) R1< A cycle in the triggering graph provides a necessary condition for non-termination but an existence of a cycle is not a sufficient condition. 3. The triggering graph above has a cycle and if Sal=1.1*Sal in rule R1 then non-termination may occur when average salary exceeds Several Techniques based on semantic reasoning exist for improving rule analysis for detecting nontermination. 5

6 Termination and Design Issues 1. Lack of understanding of side effects of adding, dropping and modifying rules in a large system. 2. Similarity to side effects of changing large software systems. 3. Divide and Conquer by modularizing. 4. Modularize rule set: (a) Partition the entire rule set into components so that termination can be determined by reasoning only within components. (b) Rules within a component correspond to some shared properties (e.g., rules invoked by similar events). (c) Side effects primarily contained within a component. 5. Stratification: (a) Ordering evaluation of rules by strata. Each stratum contains rules of a component. Thus, if stratum S1 has higher priority than stratum S2 then all rules in S1 are evaluated before those in S2. 6

7 (b) The ordering of rules by strata is defined at design time (ORACLE does not have this). 7

8 Three Types of Stratification 1. Behavioral Stratification: Associates rules to a stratum based on a particular application task. Local termination implies evaluation of rules leading to termination within a stratum. Global termination requires interleaving evaluation of rules between strata following priority order between strata. 2. Assertional Stratification: Associates each rule of a stratum to an assertion. Global termination requires that interleaved executions of rules from different strata do not compromise the assertions established for each stratum. 3. Event-based Stratification: Associates events of rules to strata. Events are: input events (Events used in the CONDITION clause): all events that trigger a rule in the stratum output events (Events used in the ACTION clause): all operations performed by the action of a rule. Each stratum forms a node of a graph and the ordering of input and output events of strata give a directed edge. Global termination corresponds to acyclicity of the graph. 8

9 Design based on Behavioral Stratification 1. A metric for each stratum. It is a function that maps database state to a natural number. 2. The metric is monotonically decreasing and converges to a minimum value (fixpoint) relating to termination. 9

10 Example: Order Processing Database Application Using Chimera: A company receives Orders from Clients. Orders are created and the Status is pending. Pending Orders are processed and Status modified to accepted if appropriate conditions are satisfied. When the orders are created or modified, a set of triggers processes the Orders as follows (note triggers themselves execute modif y): Class definition class Order attributes: OrderNumber: integer, Issuer: Client, Amount: integer, Status: (accepted,pending,rejected) class Client attributes: Name: string, Credit: integer, Trusted: boolean 10

11 Implementation of Triggers: Trigger T1 monitors the creation of orders from trusted clients and immediately accepts the order. Trigger T2 monitors the changes to orders from trusted clients and immediately accepts it. Trigger T3 monitors the creation of orders from all other clients and accepts it when credit is positive. Trigger T4 monitors the changes to orders from all other clients and accepts it when credit is positive. Need to modify Status of Order. Need to modify Credit of Client. Order processing triggers: create trigger T1 for Order events create condition Order(O),Client(C), holds(create,o), O.Status=pending, O.Issuer=C, C.Trusted=true actions modify(order.status, O,"accepted"), modify(client.credit,c,c.credit-o.amount) end; 11

12 create trigger T2 for Order events modify(amount), modify(status) condition Order(O),Client(C), holds(modify,o), integer(i),i=o.amount-old(o.amount), C.Trusted=true, C=O.Issuer actions modify(order.status, O,"accepted"), modify(client.credit,c,c.credit-i) end; create trigger T3 for Order events create condition Order(O),Client(C), holds(create,o), C.Credit>O.Amount actions modify(order.status, O,"accepted"), modify(client.credit,c,c.credit-o.amount) end; create trigger T4 for Order events modify(amount), modify(status) condition Order(O),Client(C), C=O.Issuer, holds(modify,o), integer(i), I=O.Amount-old(O.Amount), C.Credit>I actions modify(order.status, O,"accepted"), modify(client.credit,c,c.credit-i) end; 12

13 holds: similar to Occurred which binds only the objects affected by the event to local variables. holds binds to subset of the objects affected by the events based on the evaluation of net effect (resulting from several modify on the same object within a transaction). 13

14 1. Metric: Metric and Stratification Guarantee termination. The rules convert pending orders into accepted orders. After execution of each rule the number of remaining orders is monotonically decreasing Terminates when the value of the metric is minimum. 2. Startification: All the rules T1,T2,T3,T4 correspond to the applicative task which is to convert pending orders to accepted orders. 3. T1,T2,T3,T4 form a stratum 4. The following function satisfies the metric property with respect to the rules T1,T2,T3,T4: Metric for the above stratum: count(orders)-count(acceptedorders) 14

15 Example Continued Assume a change in the company policy due to recession: Orders are suspended if client credit goes below 50K (i.e., goes negative below 50K). Rule implementation: create trigger T5 for Client events modify(credit) condition Client(C), holds(modify(client.credit),c), C.Credit<-50K,Order(O), O.Issuer=C actions modify(order.status, O,"pending"), before T1, T2, T3, T4 Problem: T5 executes first. T5 s modify(order.status) invokes both T2 and T4. But there is a non-termination because of T2 and T5. One solution: change Client.Status to false. This changes the application itself. Can we solve the problem without changing the application? create trigger T5 for Client events modify(credit) 15

16 condition Client(C), holds(modify(client.credit),c), C.Credit<-50K,Order(O), O.Issuer=C actions modify(order.status, O,"pending"), modify(client.trusted,c,false) before T1, T2, T3, T4 Two strata: S1: (T5), S2: (T1,T2,T3,T4) Stratum of (T5) is higher than that of (T1,T2,T3,T4) Metric for stratum S1: count(trustedclients) Metric for stratum S2: count(orders)-count(acceptedorders) Action of T5 still triggers T4 but not T1, T2, T3 16