Examples of Statement-Level Active Rules

26.1.3 Examples of Statement-Level Active Rules

in STARBURST

We now give some examples to illustrate how rules can be specified in the STAR- BURST experimental DBMS. This will allow us to demonstrate how statement-level rules can be written, since these are the only types of rules allowed in STARBURST.

The three active rules R1S , R2S , and R3S in Figure 26.5 correspond to the first three rules in Figure 26.2, but they use STARBURST notation and statement-level seman- tics. We can explain the rule structure using rule R1S . The CREATE RULE statement specifies a rule name— Total_sal1 for R1S . The ON clause specifies the relation on which the rule is specified— EMPLOYEE for R1S . The WHEN clause is used to spec-

ify the events that trigger the rule. 8 The optional IF clause is used to specify any conditions that need to be checked. Finally, the THEN clause is used to specify the actions to be taken, which are typically one or more SQL statements.

In STARBURST, the basic events that can be specified for triggering the rules are the standard SQL update commands: INSERT , DELETE , and UPDATE . These are speci- fied by the keywords INSERTED , DELETED , and UPDATED in STARBURST nota- tion. Second, the rule designer needs to have a way to refer to the tuples that have been modified. The keywords INSERTED , DELETED , NEW-UPDATED , and OLD- UPDATED are used in STARBURST notation to refer to four transition tables (rela- tions) that include the newly inserted tuples, the deleted tuples, the updated tuples before they were updated, and the updated tuples after they were updated, respec- tively. Obviously, depending on the triggering events, only some of these transition tables may be available. The rule writer can refer to these tables when writing the condition and action parts of the rule. Transition tables contain tuples of the same type as those in the relation specified in the ON clause of the rule—for R1S , R2S , and R3S , this is the EMPLOYEE relation.

In statement-level semantics, the rule designer can only refer to the transition tables as a whole and the rule is triggered only once, so the rules must be written differ- ently than for row-level semantics. Because multiple employee tuples may be

26.1 Active Database Concepts and Triggers 941

R1S: CREATE RULE Total_sal1 ON EMPLOYEE WHEN INSERTED

IF EXISTS ( SELECT * FROM INSERTED WHERE Dno IS NOT NULL ) THEN UPDATE

DEPARTMENT AS D

SET

D.Total_sal = D.Total_sal + ( SELECT SUM (I.Salary) FROM INSERTED AS I WHERE D.Dno = I.Dno )

WHERE

D.Dno IN ( SELECT Dno FROM INSERTED );

R2S: CREATE RULE Total_sal2 ON EMPLOYEE WHEN UPDATED ( Salary )

IF EXISTS ( SELECT * FROM NEW-UPDATED WHERE Dno IS NOT NULL ) OR EXISTS ( SELECT * FROM OLD-UPDATED WHERE Dno IS NOT NULL ) THEN UPDATE

DEPARTMENT AS D

SET

D.Total_sal = D.Total_sal + ( SELECT SUM (N.Salary) FROM NEW-UPDATED AS N

WHERE D.Dno = N.Dno ) – ( SELECT SUM (O.Salary) FROM OLD-UPDATED AS O

WHERE D.Dno = O.Dno )

WHERE D.Dno IN ( SELECT Dno FROM NEW-UPDATED ) OR D.Dno IN ( SELECT Dno FROM OLD-UPDATED );

R3S: CREATE RULE Total_sal3 ON EMPLOYEE WHEN UPDATED ( Dno ) THEN UPDATE

DEPARTMENT AS D

SET

D.Total_sal = D.Total_sal + ( SELECT SUM (N.Salary) FROM NEW-UPDATED AS N

WHERE D.Dno = N.Dno )

WHERE

D.Dno IN ( SELECT Dno FROM NEW-UPDATED );

UPDATE

DEPARTMENT AS D

SET

D.Total_sal = Total_sal – ( SELECT SUM (O.Salary) FROM OLD-UPDATED AS O

WHERE D.Dno = O.Dno )

WHERE

D.Dno IN ( SELECT Dno FROM OLD-UPDATED );

Figure 26.5

Active rules using statement-level semantics in STARBURST notation.

inserted in a single insert statement, we have to check if at least one of the newly inserted employee tuples is related to a department. In R1S, the condition

EXISTS (SELECT * FROM INSERTED WHERE Dno IS NOT NULL ) is checked, and if it evaluates to true, then the action is executed. The action updates

in a single statement the DEPARTMENT tuple(s) related to the newly inserted employee(s) by adding their salaries to the Total_sal attribute of each related depart-

942 Chapter 26 Enhanced Data Models for Advanced Applications

department, we use the SUM aggregate function to ensure that all their salaries are added.

Rule R2S is similar to R1S , but is triggered by an UPDATE operation that updates the salary of one or more employees rather than by an INSERT . Rule R3S is triggered by an update to the Dno attribute of EMPLOYEE , which signifies changing one or more employees’ assignment from one department to another. There is no condition in

R3S , so the action is executed whenever the triggering event occurs. 9 The action updates both the old department(s) and new department(s) of the reassigned employees by adding their salary to Total_sal of each new department and subtract- ing their salary from Total_sal of each old department.

In our example, it is more complex to write the statement-level rules than the row- level rules, as can be illustrated by comparing Figures 26.2 and 26.5. However, this is not a general rule, and other types of active rules may be easier to specify when using statement-level notation than when using row-level notation.

The execution model for active rules in STARBURST uses deferred consideration. That is, all the rules that are triggered within a transaction are placed in a set— called the conflict set—which is not considered for evaluation of conditions and execution until the transaction ends (by issuing its COMMIT WORK command). STARBURST also allows the user to explicitly start rule consideration in the middle of a transaction via an explicit PROCESS RULES command. Because multiple rules must be evaluated, it is necessary to specify an order among the rules. The syntax for rule declaration in STARBURST allows the specification of ordering among the rules to instruct the system about the order in which a set of rules should be consid-

ered. 10 Additionally, the transition tables— INSERTED , DELETED , NEW-UPDATED , and OLD-UPDATED —contain the net effect of all the operations within the transac- tion that affected each table, since multiple operations may have been applied to each table during the transaction.