CS6005 Advanced Database System UNIT II

Ch2 Active Database Systems {1{
SC
Active Database Systems
An integrated facility for creating and executing production

rules from within a database system
A typical database production rule:
when event
if condition
then action
Powerful and uniform mechanism for:
{ Constraint enforcement
{ Derived data maintenance
{ Alerting
{ Authorization checking
{ Version management
{ Resource management
{ Knowledge management
Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Advanced Database Systems Morgan Kaufmann Copyright c 1997
SC
Outline of Slides
Chapter 2: Syntax and Semantics

{ A Relational Prototype: Starburst
{ Two Relational Systems: Oracle and DB2
{ An Object-Oriented Prototype: Chimera
{ Features and Products Overview
Chapter 3: Applications
{ Applications of Active Rules
{ Deriving Active Rules for Constraint Management
{ Deriving Active Rules for View Maintenance
{ Rules for Replication
{ Rules for Work ow Management
{ Business Rules
Chapter 4: Design Principles

{ Properties of Active Rules and Rule Analysis
{ Rule Modularization
{ Rule Debugging and Monitoring
{ Rule Design: IDEA Methodology (pointer)
{ Conclusions

SC
A Relational Example: Starburst
Done at IBM Almaden

Chief Engineer: Jennifer Widom
Syntax based on SQL
Semantics is set-oriented
{ Triggering based on (arbitrary)
sets of changes
{ Actions perform (arbitrary) sets
of changes
{ Conditions and actions can refer to
sets of changes
Instructions: create, drop,
alter, deactivate, activate

SC
Rule Creation
<Starburst-rule> ::=CREATE RULE <rule-name>

ON <table-name>
WHEN <triggering-operations>
[ IF <SQL-predicate> ]
THEN <SQL-statements>
[ PRECEDES <rule-names> ]
[ FOLLOWS <rule-names> ]
<triggering-operation> ::= INSERTED j DELETED j

UPDATED [ ( <column-names> ) ]
Triggering operations:
{ inserted, deleted, updated,
updated(c1,..,cn )
Condition: arbitrary SQL predicate

Actions: any database operations
insert, delete, update, select,
rollback, create table, etc.
Precedes and Follows: for rule ordering

SC
Example Rules
Salary control rule
CREATE RULE SalaryControl ON Emp
WHEN INSERTED, DELETED, UPDATED (Sal)
IF (SELECT AVG (Sal) FROM Emp ) > 100
THEN UPDATE Emp
SET Sal = .9 * Sal
High paid rule

CREATE RULE HighPaid ON Emp
WHEN INSERTED
IF EXISTS (SELECT * FROM INSERTED
WHERE Sal > 100)
THEN INSERT INTO HighPaidEmp
(SELECT * FROM INSERTED
WHERE Sal > 100)
FOLLOWS AvgSal

SC
Transition Tables
Logical tables storing changes that triggered rule

Can appear anywhere in condition and action
References restricted to triggering operations:
inserted
deleted
new-updated
old-updated

SC
Rule Execution Semantics
Rules processed at commit point of each transaction

Transaction's changes are initial triggering transition
Rules create additional transitions which may trigger other
rules or themselves
Each rule looks at set of changes since last considered
When multiple rules triggered, pick one based on partial or-
dering

SC
Example of rule execution
Initial state:
Employee Sal
Stefano 90
Patrick 90
Michael 110
Transaction inserts tuples (Rick,150) and (John,120)
Employee Sal
Stefano 90
Patrick 90
Michael 110
Rick 150
John 120
Rule SalaryControl runs:
Employee Sal
Stefano 81
Patrick 81
Michael 99
Rick 135
John 108

SC
Rule Execution Semantics (2)

Rule SalaryControl runs again:
Employee Sal
Stefano 73
Patrick 73
Michael 89
Rick 121
John 97
Rule HighPaid runs eventually, and inserts into HighPaid only
one tuple:
Employee Sal
Rick 122

SC
Oracle
Supports general-purpose triggers, developed according to

preliminary documents on the SQL3 standard.
Actions contain arbitrary PL/SQL code.
Two granularities: row-level and statement-level.
Two types of immediate consideration: before and after.
Therefore: 4 Combinations:
BEFORE ROW
BEFORE STATEMENT
AFTER ROW
AFTER STATEMENT

SC
Syntax
<Oracle-trigger> ::= CREATE TRIGGER <trigger-name>

f BEFORE j AFTERg <trigger-events>
ON <table-name>
[ [ REFERENCING <references> ]
FOR EACH ROW
[ WHEN ( <condition> ) ] ] <PL/SQL block>
<trigger event> ::= INSERT j DELETE j UPDATE

[ OF <column-names> ]
<reference> ::= OLD AS <old-value-tuple-name> j

NEW AS <new-value-tuple-name>

SC
Trigger Processing
1. Execute the BEFORE STATEMENT trigger.

2. For each row aected:
(a) Execute the BEFORE ROW trigger.
(b) Lock and change the row.
(c) Perform row-level referential integrity and assertion check-
ing.
(d) Execute the AFTER ROW trigger.
3. Perform statement-level referential integrity and assertion check-
ing.
4. Execute the AFTER STATEMENT trigger.

SC
Example Trigger in Oracle
Reorder rule
CREATE TRIGGER Reorder
AFTER UPDATE OF PartOnHand ON Inventory
WHEN (New.PartOnHand < New.ReorderPoint)
FOR EACH ROW
DECLARE NUMBER X
BEGIN
SELECT COUNT(*) INTO X
FROM PendingOrders
WHERE Part = New.Part;
IF X=0
THEN
INSERT INTO PendingOrders
VALUES (New.Part, New.OrderQuantity, SYSDATE)
END IF;
END;

SC
Example of execution
Initial state of Inventory:

Part PartOnHand ReorderPoint ReorderQuantity
1 200 150 100
2 780 500 200
3 450 400 120
PendingOrders is initially empty
Transaction (executed on October 10, 1996):
T1: UPDATE Inventory
SET PartOnHand = PartOnHand - 70
WHERE Part = 1
After the execution of trigger Reorder, insertion into Pendin-
gOrders of the tuple (1,100,1996-10-10)
Another transaction (executed on the same day)
T2: UPDATE Inventory
SET PartOnHand = PartOnHand - 60
WHERE Part >= 1
The trigger is executed upon all the tuples, and the condition
holds for parts 1 and 3, but a new order is issued for part 3,
resulting in the new tuple (3,120,1996-10-10).

SC
DB2
Triggers for DB2 Common Servers dened at the IBM Al-
maden Research center in 1996.
In uential on the SQL3 standard.
As in Oracle: either BEFORE or AFTER their event, and
either a row- or a statement-level granularity.
Syntax:
<DB2-trigger> ::= CREATE TRIGGER <trigger-name>
f BEFORE j AFTER g <trigger-event>
ON <table-name>
[ REFERENCING <references> ]
FOR EACH f ROW j STATEMENT g
WHEN ( <SQL-condition> )
<SQL-procedure-statements>
<trigger-event> ::= INSERT j DELETE j UPDATE

[ ON <column-names> ]
<reference> ::= OLD AS <old-value-tuple-name> j

NEW AS <new-value-tuple-name> j
OLD TABLE AS <old-value-table-name> j
NEW TABLE AS <new-value-table-name>

SC
Semantics of DB2 Triggers

Before-triggers:
{ Used to detect error conditions and to condition input
values (assign values to NEW transition variables).
{ Read the database state prior to any modication made
by the event.
{ Cannot modify the database by using UPDATE, DELETE,
and INSERT statements (so they do not recursively acti-
vate other triggers).
Several triggers (with either row- or statement-level granular-
ity) can monitor the same event.
A system-determined total order takes into account the trig-
gers' denition time; row- and statement-level triggers are
intertwined in the total order.
General trigger processing algorithm after statement A:
1. Suspend the execution of A, and save its working stor-
age on a stack.
2. Compute transition values (OLD and NEW) relative
to event E .
3. Consider and execute all before-triggers relative to event
E , possibly changing the NEW transition values.
4. Apply NEW transition values to the database, thus
making the state change associated to event E eec-
tive.

SC
5. Consider and execute all after-triggers relative to event

E . If any of them contains an action A that activates i
other triggers, then invoke this processing procedure

recursively for A . i
6. Pop from the stack the working storage for A and con-
tinue its evaluation.
Revised trigger processing with integrity checking:
4. Apply the NEW transition values to the database, thus

making the state change associated to event E eec-
tive. For each integrity constraint IC violated by the
current state, consider the action A that compensates
j
the integrity constraint IC .

a. Compute the transition values (OLD and NEW)
relative to A . j
b. Execute the before-triggers relative to A , possibly j
changing the NEW transition values.

c. Apply NEW transition values to the database, thus
making the state change associated to A eective. j
d. Push all after-triggers relative to action A into a j
queue of suspended triggers.

Until a quiescent point is reached where all the in-
tegrity constraints violated in the course of the com-
putation are compensated.

SC
Examples of triggers
Supplier rule
CREATE TRIGGER OneSupplier
BEFORE UPDATE OF Supplier ON Part
REFERENCING NEW AS N
FOR EACH ROW
WHEN (N.Supplier IS NULL)
SIGNAL SQLSTATE '70005'
('Cannot change supplier to NULL')
Audit rule
CREATE TRIGGER Audit
AFTER UPDATE ON Parts
REFERENCING OLD TABLE AS OT
FOR EACH STATEMENT
INSERT INTO AuditSupplier
VALUES(USER, CURRENT DATE,
(SELECT COUNT(*) FROM OT))

SC
An Object-Oriented System: Chimera
Structure of the IDEA Consortium:

{ Prime Contractor: BULL
{ Partners: Politecnico, ECRC, INRIA, TxT (Italy), SEMA
(Spain)
{ Associate Partners: Univ. Bonn, BIM (Belgium), PTT
(Holland)
Objectives of the IDEA Project:

{ Designing and implementing prototypes of Active DOOD
systems
{ Producing a methodology and tools for helping the use of
Active DOOD technology
{ Transferring experience to ADS (Bull)

SC
Chimera: the Conceptual Interface
Chimera [the Oxford Dictionary of Current English]:

1. Greek myth: monster with a lion's head, a goat's body,
and a serpent's tail.
2. Comp.Sc.: new generation database language integrating
the paradigms of object-oriented, deductive, and active
databases.
Relatives of Chimera:
{ Elisa Bertino = OO = lion
{ Stefano Ceri = ACT = serpent
{ Rainer Manthey = DED = goat
Features:
{ Object-oriented conceptual model (data + operations)
{ Declarative rule language
{ Reactive processing (triggers)
More information in www.elet.polimi.it/idea

SC
Alternatives in Reactive Processing
Issues in reactive processing:

{ Choice of event types.
{ Complexity of event calculus.
{ Execution modes.
{ Event eect composition modes.
{ Event consumption modes.
{ Binding of database objects to events.
{ Binding between rule components.
{ Priorities.

SC
The Designers' Dilemma
Choosing a semantics for active rules.

Alternatives:
{ One semantics: which one?
{ Multiple, parametric semantics: how feasible?
The designers' beliefs:

{ One semantics is too limited (cannot cover all applica-
tions).
{ Alternatives should be limited and under control.
{ Triggers could be system-generated to implement declar-
ative aspects of Chimera.

SC
Trigger's Syntax
<dene-trigger> ::= dene <option> trigger <trigger-name>

[ for <class-name> ]
events <triggering-events>
condition <formula>
actions <procedural-expression>
[ f before j after g <trigger-names> ]
end
<triggering-event> ::= create j delete j

modify [ ( <attr-name> ) ]
<option> ::= [ <consumption-opt> ] [ <execution-opt> ]

<consumption-opt> ::= event-consuming j event-preserving
<execution-opt> ::= deferred j immediate

SC
Features of Triggers in Chimera
Trigger options:
{ immediate / deferred
{ consuming / event-preserving
Events:
{ create, create tmp, delete,
make persistent, generalize,
modify, specialize, query
Condition:
{ An arbitrary declarative formula of the language
Actions:
{ Update primitives, operations, display queries, externally
dened procedures, rollback command

SC
Trigger Processing
A rule is triggered when one of its triggering events has

occurred.
Trigger processing (either immediate or deferred) consists of:
{ Ordering triggered rules according to priorities.
{ Selecting one of the highest priority rules (nondetermin-
istically).
{ Then, this rule is considered by evaluating its condition
(becomes untriggered).
{ If the condition is true or it produces some bindings, then
the reaction is executed; Actions composing the reaction
are executed in sequence.
Until a xpoint is reached where no rule is triggered.

SC
Execution Modes
Immediate: after the completion of the raising event.

Deferred: at the end of a transaction (default).
Each trigger has its own execution mode.
Transaction commands can change modes, setting all triggers
to immediate or deferred.
Event Formulas
Syntax: occurred(event,variable).
Semantics: binds OIDs of objects which were aected by the
event, according to several modes.
Every binding represents an \event instance".

SC
Event Consumption Modes
Consuming: Every event instance is

considered by each rule at the rst possible rule consideration,
then disregarded.
Preserving: All event instances are
considered by each rule at all rule considerations.
Net Eect of Event Instances

Net eect: Some event instances disappear due to event
combinations, such as insert, delete of the same object.

SC
Examples of triggers
Adjust salary rule
dene trigger AdjustSalary for Employee
events create, modify(Salary)
condition Self.Salary > Self.Mgr.Salary
actions modify(Employee.Salary,Self,Self.Mgr.Salary)
end;
Immediate adjust salary rule

dene immediate trigger ImmAdjustSalary for Employee
events create, modify(Salary)
condition occurred(create, modify(Salary),Self)
Self.Salary > Self.Mgr.Salary
actions modify(Employee.Salary,Self,Self.Mgr.Salary)
end;

SC
Examples of triggers (2)

Special employee rule
dene immediate event-preserving trigger SpEmp for Employee
events modify(Salary)
condition occurred(modify(Salary),Self)
Self.Salary - old(Self.Salary) > 5000
actions create(specialEmp, [Self.name], Z)
before AdjustSalary
end;
Excessive salary rule

dene trigger ExcessiveSalary
events create(Employee), modify(Employee.Salary),
modify(Department.Employees)
condition Department(Y), Y.Name="toys", Employee(X),
X in Y.Employees, sum(X.Salary) > 500000
action rollback
end;

SC
Features of Active Databases
Events
{ Database state changes
{ Retrievals
{ Time-related
{ Application-dened (external)
Condition
{ Database predicate
{ Database query
{ Application procedure (external?)
Actions
{ Database modications
{ Database retrieval operations
{ Other database commands
{ Application procedures

SC
Consideration
Immediate:
Individual update primitives of the
Data Manipulation Language
(e.g.: Insert, Delete, Update)
{ Before
{ After
{ Instead of
Deferred:
{ User-dened points

{ End transaction
Detached:
Executed as separate transaction
May have causal dependencies on spawning transaction

SC
Granularity and Transition Values
Granularity of DB state change

{ Record (tuple-level)
{ Set of records(statement-level)
Transition Values
{ Single tuple's OLD and NEW values
{ Collective changes:
INSERTED, DELETED
{ Updates treated:
Explicitly OLD/NEW UPDATED
As deleted followed by inserts

SC
Priorities, Commands, Structuring
Prioritization
{ None
{ Partial Order
{ Total Order
Rule activation and deactivation

{ None
{ Under DBA Control
{ Under User Control
{ Performed by rules
With rule sets (grouping)

and set-level commands

SC
Informix (see: Widom-Ceri's book)
Available since Version 6.

Multiple triggers, single rule.
Syntax:
<Informix trigger> ::=

CREATE TRIGGER <trigger name>
<trigger event> ON <table name>
[BEFORE [<condition>] (<actions>)]
[[REFERENCING <references>]
FOR EACH ROW [<condition>] (<actions>)]
[AFTER [<condition>] (<actions>)]
<trigger event> ::= INSERT | DELETE |

UPDATE [OF <column names>]
<reference> ::=
OLD AS <old value tuple name> |
NEW AS <new value tuple name>
<condition> ::= WHEN (<predicate>)
<action> ::= <insert statement>

| <delete statement>
| <update statement>
| <procedure call>

SC
Example Trigger in Informix
CREATE TRIGGER up price

UPDATE OF unit price ON stock
REFERENCING OLD AS pre,
NEW AS post
FOR EACH ROW WHEN
(post.unit price >
pre.unit price * 2)
INSERT INTO warn tab VALUES
(pre.stock num, pre.order num,
pre.unit price, post.unit price,
CURRENT)

SC
Ingres (see: Widom-Ceri's book)
Available in Knowledge
Management Extension.
Semantics: AFTER, tuple-level.
Syntax:
<Ingres rule> ::=

CREATE RULE <rule name>
AFTER <rule events> ON <table name>
[REFERENCING <references>]
WHERE <predicate>
EXECUTE PROCEDURE <procedure call>
<rule event> ::= INSERT | DELETE |

UPDATE [(<column name>)]
<reference> ::=

SC
Example Trigger in Ingres
CREATE RULE emp delete

AFTER DELETE FROM EMPLOYEE
EXECUTE PROCEDURE manager emp track
(ename = OLD.name,
mname = NEW.manager)
CREATE PROCEDURE manager emp track
(ename VARCHAR (30),
mname VARCHAR (30)) AS
BEGIN
UPDATE manager
SET employees = employees - 1
WHERE name = :mname;
INSERT INTO mgrlog VALUES
(:mname, :ename);
END;

SC
RDB (see: Widom-Ceri's book)
Semantics:
{ Both BEFORE and AFTER
{ Both Statement and Tuple Level
Syntax:
<Rdb trigger> ::=

{BEFORE | AFTER} <trigger event>
ON <table name>
[REFERENCING <references>]
WHEN <predicate> (<statement>)
[FOR EACH ROW]
<trigger event> ::= INSERT | DELETE |

UPDATE [OF <column names>]
<reference> ::=

SC
Example Trigger in RDB
CREATE TRIGGER
code cascade update
BEFORE UPDATE OF code
ON work status
REFERENCING OLD AS old work status
NEW AS new work status
(UPDATE employee E
SET E.code = NEW.code
WHERE E.code = OLD.code)

SC
Sybase (see: Widom-Ceri's book)

Since Sybase SQL Server Release 10.0.
Each table may have at most three
triggers (insert, delete, update).
Semantics: AFTER, Statement-level
Syntax:
<Sybase trigger1> ::=

ON <table name>
FOR <trigger events>
AS <SQL statements>
<trigger event> ::= INSERT | DELETE | UPDATE
Variant:
<Sybase trigger2> ::=
ON <table name>
FOR <trigger restricted-events>
AS [IF <trig-upd-exp>] <SQL statements>
<trigger restricted-events> ::= INSERT | UPDATE
<trig-upd-exp> ::= UPDATE(<column name>) |

<trig-upd-exp> AND <trig-upd-exp> |
<trig-upd-exp> OR <trig-upd-exp>

SC
Example Trigger in Sybase
CREATE TRIGGER delcascadetrig

ON titles
FOR deletes
AS
DELETE titleauthor
FROM titleauthor,deleted
WHERE titleauthor.title id =
deleted.title id
DELETE salesdetail
FROM salesdetail,deleted
WHERE salesdetail.title id =
deleted.title id
DELETE roysched
FROM roysched,deleted
WHERE roysched.title id =
deleted.title id

SC
Feature Comparison
(see: Widom-Ceri's book)
SQL3 Oracle Infor Ingres RDB Sybase All Inter

mix base base
Multiple events N Y Y Y Y Y Y Y
BEFORE clause Y Y Y Y Y Y Y Y
AFTER clause Y Y Y Y Y Y Y Y
INSTEAD OF clause Y N N N N N N N
Condition present Y Y Y Y Y N Y N
Tuple-level granularity Y Y Y Y Y N Y Y
Tuple-level references Y Y Y Y Y N Y Y
Statement-level granularity Y Y Y N N Y N N
Table-level references Y N N N N Y N N
Priorities Y N N N N N N Y
Cascade allowed Y Y Y Y Y Y Y Y
Loop allowed N Y Y Y N Y Y Y
Max recursion depth 32 61 20 8 20 ?
Explicit authorization Y Y Y N N Y N N

SC
Applications of Active Rules
Internal to the database:

{ Integrity constraint maintenance
{ Support of data derivation
(including data replication).
Extended functionalities:
{ Work ow management systems
{ Version managers
{ Event tracking and logging
{ Security administration
Business Rules:
{ Trading rules for the bond market
{ Warehouse and inventory management
{ Energy management rules

SC
Internal and Extended Rules
Perform classicalDBMS functions

Can be approached with structured
approaches and techniques
Can be automatically or
semi-automatically generated
Can be declaratively specied

SC
Declarative Design of Active Rules

for Integrity and View Maintenance
Internal applications of active databases are:

{ Static
{ Declarative
{ High-level, easy to understand
Approach
{ User species application at
declarative (high) level
{ System derives low-level rules
that implement it (automatically
or semi-automatically)

SC
Framework
Rules should be programmed by DBA

Rule programming should be
assisted by rule design tools
Rule derivation can be:
{ Completely automatic
(for few well-dened problems)
{ Partially automatic
(interactive system)

SC
Integrity Constraint Maintenance
Constraints are static conditions

{ Every employee's department exists
{ Every employee's salary is between 30 and 100
Rules monitor dynamic database
changes to enforce constraints
{ when change to employees or departments
if an employee's department doesn't exist
then x the constraint
{ when change to employee salaries
if a salary is not between 30 and 100
then x the constraint
Generalizing:
{ when potentially invalidating operations
if constraint violated
then x it
{ Constraint consistency points =
Rule processing points

SC
Integrity-Preserving Rules
Constraint: condition C
Rules(s):
when operations that could make
C become false
if C is false
then make C true
or abort transaction
Example:
C = every employee's department exists
Operations = insert into emp,
delete from dept,
update to emp.deptno,
update to dept.dno
Condition:
{ There is some employee violating C (due to above ops)
Action: make C true
{ Rollback insertion of emp
{ Rollback deletion of dept
{ Put emp into a dummy dept

SC
Example: Referential Integrity

Constraint:
EXISTS (SELECT * FROM Dept
WHERE Dno = Emp.Deptno)
Denial form:
NOT EXISTS (SELECT * FROM Dept
Abort Rules
CREATE RULE DeptEmp1 ON Emp

WHEN INSERTED, UPDATED(Deptno)
IF EXISTS (SELECT * FROM Emp
WHERE NOT EXISTS
(SELECT * FROM Dept
WHERE Dno = Emp.DeptNo))
THEN ROLLBACK
CREATE RULE DeptEmp2 ON Dept

WHEN DELETED, UPDATED(Dno)
IF EXISTS (SELECT * FROM Emp
WHERE NOT EXISTS
(SELECT * FROM Dept
THEN ROLLBACK

SC
Example: Repair Rules for EMP

WHEN INSERTED
IF EXISTS ( SELECT * FROM INSERTED
WHERE NOT EXISTS
(SELECT * FROM Dept
THEN UPDATE Emp
SET DeptNo = NULL
WHERE EmpNo IN
(SELECT EmpNo FROM INSERTED)
AND NOT EXISTS
(SELECT * FROM Dept

SC
Example: Repair Rules for EMP (2)

WHEN UPDATED(Deptno)
IF EXISTS (SELECT * FROM NEW-UPDATED
WHERE NOT EXISTS
(SELECT * FROM Dept
THEN UPDATE Emp
SET DeptNo = 99
WHERE EmpNo IN
(SELECT EmpNo FROM NEW-UPDATED)
AND NOT EXISTS
(SELECT * FROM Dept

SC
Example: Repair Rules for DEPT

Repair rules on table Dept
WHEN DELETED
IF EXISTS (SELECT * FROM Emp WHERE EXISTS
(SELECT * FROM DELETED
THEN DELETE FROM Emp
WHERE EXISTS
(SELECT * FROM DELETED

WHEN UPDATED(Dno)
IF EXISTS (SELECT * FROM Emp WHERE EXISTS
(SELECT * FROM OLD-UPDATED
WHERE Dno = Emp.Deptno))
THEN DELETE FROM Emp
WHERE EXISTS
(SELECT * FROM OLD-UPDATED
WHERE Dno = Emp.DeptNo)

SC
View Maintenance
Logical tables derived from base tables

{ Portion of database specied by retrieval query
{ Used to provide dierent abstraction levels (or: external
schemas)
Referenced in retrieval queries
Virtual views
{ Not physically stored
{ Implemented by query modication
Materialized views
{ Physically stored
{ Kept consistent with base tables

SC
Virtual Views
Views dene derived data by static database queries

Table high-paid =
All employees with high salaries
Virtual views are not stored in the database
Rules dynamically detect queries on
virtual views and transform into
queries on base tables
when retrieve from high-paid
then retrieve from emp
where sal > X

SC
Materialized Views
View: V = query Q
Rules(s): when operations that can change
the result of Q
then modify V
How to generate rule(s) from view?
Generate triggering operations by analyzing Q
V = all employees with high salaries
Ops = insert into emp,

delete from emp,
update emp.sal
Generate action to modify V
{ Evaluate query Q, set V = result
{ Evaluate Q using changed values,
update V
{ Determine which by analyzing Q

SC
Materialized Views and Rules
SQL select expressions

dene view V as
select Cols from Tables where Predicate
Materialized initially, stored in database
\Refreshed" at rule processing points
Changes to base tables !
Production rules modify view

SC
View-Maintaining Rules
Recomputation approach (easy but bad)

when changes to base tables
then recompute view
Incremental approach (good but hard)
when changes to base tables
then change view
Incremental rules is complicated for:
{ Views with duplicates
{ Certain base table operations

SC
Example
Relational view selecting departments with one employee who
earns more than 50,000
DEFINE VIEW HighPaidDept AS
(SELECT DISTINCT Dept.Name
FROM Dept, Emp
WHERE Dept.Dno = Emp.Deptno
AND Emp.Sal > 50K)
Critical events
1. insertions into Emp
2. insertions into Dept
3. deletions from Emp
4. deletions from Dept
5. updates to Emp.Deptno
6. updates to Emp.Sal
7. updates to Dept.Dno

SC
Refresh Rules written in Starburst

Refresh rules CREATE RULE RefreshHighPaidDept1 ON Dept
WHEN INSERTED, DELETED,
UPDATED(Deptno), UPDATED(Sal)
THEN DELETE * FROM HighPaidDept;
INSERT INTO HighPaidDept:
FROM Dept, Emp
AND Emp.Sal > 50K)
CREATE RULE RefreshHighPaidDept2 ON Emp

WHEN INSERTED, DELETED, UPDATED(Dno)
THEN DELETE * FROM HighPaidDept;
INSERT INTO HighPaidDept:
FROM Dept, Emp
AND Emp.Sal > 50K)

SC
Incremental Rule for Insert on Dept

Incremental refresh rule
CREATE RULE IncrRefreshHighPaidDept1 ON Dept
WHEN INSERTED
THEN INSERT INTO HighPaidDept:
FROM INSERTED, Emp
WHERE INSERTED.Dno = Emp.Deptno
AND Emp.Sal > 50K)

SC
Replication
A special case of data derivation (identical copies).

Main application: distributed systems (copies on dierent
servers).
Typical approach: asynchronous.
{ Capture Step: Active rules react to changes on one
copy and collect changes into deltas.
{ Apply step: Deltas are propagated to other copies at
the appropriate time.
Alternatives:
{ Primary-Secondary
{ Symmetric

SC
Active Rules for Replication

Capture rules CREATE RULE Capture1 ON Primary
WHEN INSERTED
THEN INSERT INTO PosDelta
(SELECT * FROM INSERTED)
CREATE RULE Capture2 ON Primary

WHEN DELETED
THEN INSERT INTO NegDelta
(SELECT * FROM DELETED)
CREATE RULE Capture3 ON Primary

WHEN UPDATED
THEN INSERT INTO PosDelta
(SELECT * FROM NEW-UPDATED);
INSERT INTO NegDelta
(SELECT * FROM OLD-UPDATED)

SC
Work ow Management
A new paradigm for organizing the working activities within

enterprise.
Intrinsecally reactive: work ow managers monitor events and
perform the required event management activities.
Events are:
{ Internal: generated from within the work ow manager
while work ows are progressing.
{ External: representing the interaction of the work ow
manager with the external world.
The most signicant application of rules: expressing excep-
tions to the normal ow.

SC
Examples of Active Rules for Work ow

Management
dene trigger WF1 for Agent
events modify(Agent.Availability)
condition Agent(A), occurred(modify(Agent.Availability),A),
A.Availability=FALSE, task(T), T.Responsible=A,
T.Type='Urgent', Agent(B), A.Substitute=B,
B.Availability=TRUE
actions modify(Task.Responsible, T, B)
end;
dene trigger WF2 for Accident

events create(Accident)
condition Accident(A), occurred(create, A),
Booking(B), B.Car = A.DamagedCar,
actions create(Warning,[B.Number,B.Agent],X)
end;

SC
Business Rules
Performing a part of the application-specic business.

Examples:
{ Stock and bond trading in nancial applications.
{ Airway assignment to ights in air trac control systems
{ Order management in inventory control systems.
Key design principle:
knowledge independence.
{ Factoring knowledge out
of the applications.
{ Rules automatically shared
by all applications.
{ Rules logically part
of the database schema
(designed by \DBA").
{ Knowledge evolution feasible and
controllable (changing rules
without changing applications)).

SC
Energy Management System
The ENEL Energy Management System uses a "radial topol-

ogy" network ( forest), each "user" connected to a single
"distributor" through a network of intermediate "nodes".
The purpose of the network is to transfer the exact power from
distributors to users through nodes and (directed) branches
connecting pairs of nodes.
A transaction changes the user's prole, then the system nds
the appropriate layout and power supply.

SC
Active Rules
R1: If a new user requires power, connect it to the closest node
R2: If a user or a node requires less power, change the power of the
user or node and propagate the change to its input branch
R3: If a branch requires less power, change the power of the branch
and propagate the change to its input node
R4: If the power required from a distributor is decreased, change its
output power accordingly
R5: If a user or node requires more power, change the power of the
user or node and propagate the change to its input branch
R6: If a branch requires more power, change the power of the branch
and propagate the change to its input node
R7: If the power required from a distributor is increased, change its
output power accordingly
R8: If a distributor's power exceeds its maximum, rollback the
entire transaction
R9: If a branch's power is changed, change the power of some of its
wires accordingly
R10: If a wire's power is above its threshold, change wire type
R11: If there's no suitable wire type, add another wire to the branch
R12: If a wire is not included into a tube, add a tube around it
R13: If a tube is too small to fit all its wires, change it into a
larger tube
R14: If a wire inside a tube is high voltage and the tube is not
protected, change it into a protected tube
R15: If there's no suitable tube, split the branch into two branches

SC
Properties of rule execution
Termination:
For any legal transaction, the subsequent rule execution ter-
minates.
Con uence:
For any legal transaction, the subsequent rule execution ter-
minates in the same nal state.
Identical observable behavior:
For any legal transaction, the subsequent rule execution is
con uent and produces the same output sequence.

SC
Analysis of Termination
An active database has Non-Terminating Behavior i

there exists at least one transaction which produces non-
terminating rule processing.
Triggering Graph (TG):
{ Directed graph fV; E g
{ Node vi 2 V correspond to rule ri 2 R.
{ Arc hrj ; rk i 2 E means that the action of rule rj gener-
ates events which trigger rule rk .
Acyclicity of the triggering graph implies the absence of non-
terminating behaviors.
Two rules creating an arc:
CREATE RULE T1 FOR Table1
WHEN . . .
IF . . .
THEN UPDATE Table1.Attr1 . . .
CREATE RULE T2 FOR Table1

WHEN UPDATED(Attr1)
IF . . .
THEN . . .

SC
Cyclic Rule
With termination:
CREATE RULE SalaryControl ON Emp
THEN UPDATE Emp
SET Sal = .9 * Sal
Without termination:
CREATE RULE SalaryControl2 ON Emp
THEN UPDATE Emp
SET Sal = 1.1 * Sal

SC
Improving Rule Analysis

Eliminate edge < ri; rj > between two rules when:
{ The condition of rj is guaranteed to be false after the
execution of ri.
{ The new data produced by ri do not satisfy the condition
of rj .
Example of second case:
Grade range rules CREATE TRIGGER CheckGradeDomain1
AFTER UPDATE OF Exam ON Grade
FOR EACH ROW
WHEN (N.Grade > 30)
UPDATE Exam
SET Grade = NULL
WHERE ExamNumber = N.ExamNumber
CREATE TRIGGER CheckGradeDomain2

AFTER UPDATE OF Exam ON Grade
FOR EACH ROW
WHEN (N.Grade < 18)
THEN UPDATE Exam
SET Grade = NULL
WHERE ExamNumber = N.ExamNumber

SC
Con uence
Set-oriented Rules
{ Total ordering and termination imply con uence.
Tuple-oriented Rules
{ Con uence is much harder to ensure; it requires that the
nal state does not depend on the system's controlled
order in which tuples are accessed.
{ Con uence is not necessary or desirable in many cases.
{ Mutating table exception, when a table that is currently
being updated also needs to be changed by a rule; may
reveal lack of con uence.
Sucient condition for con uence: Commutativity of two
rules ri and rj if for any database state, considering rule ri
and then rule rj produces the same database as considering
rule rj and then rule ri.

SC
Commutative Rules
create trigger T1 for C1
events modify(A1)
condition C1(X), X.A1=7
actions modify(C1.A2,X,A2+1)
end;

events modify(A1)
actions modify(C1.A2,X,A2+2)
end;

SC
Observable Determinism
Prescribes that, for any input application, rule processing exe-

cution terminates in the same nal state with the same output
sequence (messages, display activities, reports).
Observable determinism is not necessary or desirable in many
cases.
Rules may be con uent but not provide observable determin-
ism:
events modify(A1)
actions modify(C1.A2,X,A2+1),
display(I where integer(I), I=X.A2)
end;

events modify(A1)
actions modify(C1.A2,X,A2+2),
display(I where integer(I), I=X.A2)
end;

SC
Modularization Techniques
for Active Rule Design
The main problem with rules:

understanding their interaction.
This is not just a design issue,
but rather a maintenance problem.
{ Understanding rules after their design
is quite hard.
{ Adding one rule to a rule set
may lead to unexpected behaviors.
The main reason: lack of modularization
devices for active rules.

SC
Rule Stratication
Stratication:
partitioning of rules into disjoint strata
such that each strata includes \uniform" rules.
Consequence:
Rule behavior can be abstracted by:
{ Reasoning \locally" on each individual stratum
{ Reasoning \globally" of the behavior across strata
A key design principle for providing rule modularization
and control.

SC
Stratication Approaches
Stratication can be:

{ Behavioral:
active rules of a stratum have given
behavior (e.g., they try to achieve
a specic objective).
{ Assertional:
active rules of a stratum establish the
truth of given predicates (called
stratum post-condition).
{ Structural:
events of active rules of strata
are globally acyclic.
The rst case subsumes the other ones.
We concentrate on behavioral stratication.

SC
Behavioral Stratication
Intuition:
{ For each stratum S , introduce
a metric mS (integer nite function).
{ mS measures the distance from
the current database state to a
stratum xpoint, the quiescent
state produced by rules of a
stratum running in isolation.
{ Strata are ordered by priority.
{ The execution of rules belonging to
lower priority strata does not
perturbate the metric of strata
at higher priority.

SC
Local Convergence,
Metric Conservation
Metric mS of stratum S is a nite

function on N dened for
every database state: mS : DB ! N .
Stratum S locally converges:
{ Rules of S , considered in isolation,
from any initial state D1
always reach a quiescent state,
denoted by D2.
{ If any rule executes its action part,
(D2 6= D1), then mS (D2) < mS (D1).
Sj conserves the metrics of Si :
{ I, whenever any rule of Sj is executed
and transforms a database state D1
into a database state D2,
then it is mi(D2) mi(D1).

SC
Behavioral Stratication
S = fS1 [ S2 [ ::Sng is a behavioral stratication:

{ All strata Si locally converge.
{ A total order < is dened on S
such that, if Si < Sj , then:
All rules of Si have greater
priority than rules of Sj .
Sj conserves the metrics of Si .

SC
Example: Order Management
A company receives and then processes client orders; or-

der processing tranforms pending orders into accepted orders
when certain conditions on client's credit and trusting are
met. Order processing is automatically performed by active
rules: orders are accepted if they are within the allocated
credit of clients, or if a client is trusted.
Database:
dene object class Order

attributes OrderNumber: integer,
Issuer: Client,
Amount: integer,
Status: (accepted, pending, rejected)
end;
dene object class Client

attributes Name: string,
Credit: integer,
Trusted: boolean
end;

SC
Active Rules (Single Stratum)

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;

events modify(Amount), modify(Status)
condition Order(O), Client(C), holds(modify,O),
integer(I), I=O.Amount-old(O.Amount),
C.Trusted=true
modify(Client.Credit, C, C.Credit - I)
end;

SC
Active Rules (Single Stratum)

events create
condition Order(O), Client(C), holds(create,O),
C.Credit > A.Amount
modify(Client.Credit, C, C.Credit - O.Amount)
end;

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
modify(Client.Credit, C, C.Credit - I)
end;
Metric : count(Orders) - count(AcceptedOrders)

SC
Active Rules Modication
Assume now a change of politics of the company, due to reces-

sion. When clients' credit falls below 50K, then their orders
are suspended.
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
end;
T5 violates the metrics of the stratum.
With inserts or update of orders of
trusted clients:
rule T5 loops with rules T2.

SC
Correction of the Modication
An obvious correction is to delete the fact that a

client is trusted as part of the rule's action.
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),
modify(Client.Trusted, C, false)
before T1, T2, T3, T4
end;
Stratum S1 T5
metric m1: count(trusted-clients)
Stratum S2: T1 through T4
metric m2: count(orders) - count(accepted-orders)
T5 is at a higher stratum than T1..T4:
S2 preserves the metrics of S1.

SC
Mapping Applications to Stratications
Assertional and event-based

stratications (not covered)
are most suited to internal and
extended applications.
Behavioral stratication is
most suited to business rules.
Applications Suggested
Stratication
Constraint Assertional
Internal maintenance stratication
applications Derived data Event-based
maintenance stratication
Replication Assertional
management stratication
Version Event-based
Extended management stratication
applications Event-based
Work ow stratication and
management assertional
stratication
External Business Behavioral
applications rules stratication

SC
Design Strategy with Modularization
1. Identify applicative tasks for active rules.

2. Associate each applicative task to a module.
3. Associate each task to the condition under which the task
should be executed.
4. Describe the task: \if condition, then action".
5. Detect for each task the events which cause the task to be
executed.
6. Identify for each task a metric which indicates the \progress"
towards the solution of the task.
7. Dene the \natural order" of tasks so that tasks which not
require the execution of other tasks have priority.
8. Generate active rules responding to the events which are as-
sociated to the task.
9. Check that when rules execute their action they improve the
metric and thus \progress" towards the task's solution.
10. Check that when rules execute they do not decrease the met-
rics of any task preceding the current task in the natural order
dened at step 7.

SC
Large Example: EMS
The ENEL Energy Management System uses a "ra-

dial topology" network ( forest), each "user" con-
nected to a single "distributor" through a network
of intermediate "nodes".
The purpose of the network is to transfer the exact
power from distributors to users through nodes and
(directed) branches connecting pairs of nodes.
Triggers belong to 4 strata:
S1 reacts to new requests, S2 to node/branch un-
balance,
S3 to wire requirements (they should carry power
at given voltage),
S4 to tube requirements (they should encapsulate
wires with given size/protection requirements).
A transaction changes the user's prole, then the
system nds the appropriate layout and power sup-
ply.

SC
Active Rules, Strata 1 and 2
Stratum 1
R11: If a new user requires power, connect it to the
closest node
Stratum 2
R21: If a user or a node requires less power, change
the power of the user or node and propagate the change
to its input branch
R22: If a branch requires less power, change the power of the
branch and propagate the change to its input node
R23: If the power required from a distributor is decreased,
change its output power accordingly
R24: If a user or node requires more power, change the power
of the user or node and propagate the change to its
input branch
R25: If a branch requires more power, change the power of
the branch and propagate the change to its input node
R26: If the power required from a distributor is increased,
change its output power accordingly
R27: If a distributor's power exceeds its maximum, rollback
the entire transaction
Priorities in S2 (partial order):

{R21,R22,R23} precede {R24,R25,R26,R27}

SC
Active Rules, Strata 3 and 4

Stratum 3
R31: If a branch's power is changed, change the power of
some of its wires accordingly
R32: If a wire's power is above its threshold, change
wire type
R33: If there's no suitable wire type, add another wire
to the branch
Stratum 4
R41: If a wire is not included into a tube, add a tube
around it
R42: If a tube is too small to fit all its wires, change
it into a larger tube
R43: If a wire inside a tube is high voltage and the tube
is not protected, change it into a protected tube
R44: If there's no suitable tube, split the branch into
two branches

SC
Metrics and Prioritization

Metrics:
m1: count(disconnected new users)
m2: count(nodes with unbalanced
power distribution)
m3: count(wires which are inappropriate
to carry the required power)
m4: count(wires which are not contained
into the appropriate tubes)
Priorities:
1. S1<S2 (S2<S1 excluded:
S1 may generate a user
with unmatched power)
S2 may generate wrong
wire types)
S3 may generate a wire
not included into tube)

SC
Rule Debugging and Monitoring
Purpose: run-time debugging and monitoring for tuning ac-

tive rules' behavior.
Commercial systems lack of debugging and monitoring tools.
Minimum requirement: trace facility - but often unavailable.
Some research prototypes oer powerful debuggers.

SC
Debugging in Chimera
A debugging environment is started before rule processing or
activated by spy points in the rules.
Interactive execution:
{ At the rule step level (halt+inspection after each rule
execution)
{ At the intra-rule step level (halt+inspection after each
step of triggering, condition evaluation, and action execu-
tion).
Available functionalities (in both modes):
{ Information on rules (including their source code, trigger-
ing time, and event consumption mode)
{ Commands for rule activation and deactivation
{ Inspection of the con ict set (immediate or deferred)
{ Inspection of the trace
{ Information on occurred events (event type, OIDs of the
objects aected by the event)
Available functionalities only in intra-rule step mode:
{ Display of the processing status
{ Detection of the next executable rule
{ Dynamic modication of priorities
{ Information on bindings produced by the condition

SC
IDEA Methodology
Methodology: www.elet.polimi.it/idea
(More than 250 slides available in HTML)
Web-Laboratory: www.txt.it/idea
(Java-based implementations of IADE, ARACHNE, and PAN-
DORA)

SC
Conclusions
Database production rules are:

{ Very powerful
{ Very widespread (on almost all relational products)
{ Very dicult to program
Active rule products must be enhanced:
{ Although SQL3 is not yet published, many products are
\implemented", with severe limitation and sometimes ill-
dened semantics
Stratication will hopefully soon become a widespread notion
for improving design
Declarative interfaces are possible for many active database
applications: integrity constraints, materialized views, virtual
views, authorization, dependency control, deduction, versions,
work ow management, resource management, ....


CS6005 Advanced Database System UNIT II

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS6005 Advanced Database System UNIT II

Uploaded by

Copyright:

Available Formats

Ch2 Active Database Systems {1{

Active Database Systems

 An integrated facility for creating and executing production

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

 Chapter 2: Syntax and Semantics

 Chapter 4: Design Principles

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

A Relational Example: Starburst

 Done at IBM Almaden

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

<Starburst-rule> ::=CREATE RULE <rule-name>

<triggering-operation> ::= INSERTED j DELETED j

 Condition: arbitrary SQL predicate

 Precedes and Follows: for rule ordering

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

High paid rule

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

 Logical tables storing changes that triggered rule

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Rule Execution Semantics

 Rules processed at commit point of each transaction

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Example of rule execution

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Rule Execution Semantics (2)

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

 Supports general-purpose triggers, developed according to

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

<Oracle-trigger> ::= CREATE TRIGGER <trigger-name>

<trigger event> ::= INSERT j DELETE j UPDATE

<reference> ::= OLD AS <old-value-tuple-name> j

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

1. Execute the BEFORE STATEMENT trigger.

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Example Trigger in Oracle

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

 Initial state of Inventory:

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

<trigger-event> ::= INSERT j DELETE j UPDATE

<reference> ::= OLD AS <old-value-tuple-name> j

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Semantics of DB2 Triggers

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

5. Consider and execute all after-triggers relative to event

other triggers, then invoke this processing procedure

4. Apply the NEW transition values to the database, thus

the integrity constraint IC .

b. Execute the before-triggers relative to A , possibly j

changing the NEW transition values.

d. Push all after-triggers relative to action A into a j

queue of suspended triggers.

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

An Object-Oriented System: Chimera

 Structure of the IDEA Consortium:

 Objectives of the IDEA Project:

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Chimera: the Conceptual Interface

 Chimera [the Oxford Dictionary of Current English]:

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

Alternatives in Reactive Processing

 Issues in reactive processing:

Zaniolo|Ceri|Faloutsos|Snodgrass|Subrahmanian| Zicari|All Rights Reserved

The Designers' Dilemma

An integrated facility for creating and executing production

Chapter 2: Syntax and Semantics

Chapter 4: Design Principles

Done at IBM Almaden

Condition: arbitrary SQL predicate

Precedes and Follows: for rule ordering

Logical tables storing changes that triggered rule

Rules processed at commit point of each transaction

Supports general-purpose triggers, developed according to

Initial state of Inventory:

Structure of the IDEA Consortium:

Objectives of the IDEA Project:

Chimera [the Oxford Dictionary of Current English]:

Issues in reactive processing:

Choosing a semantics for active rules.

The designers' beliefs:

<dene-trigger> ::= dene <option> trigger <trigger-name>

A rule is triggered when one of its triggering events has

Immediate: after the completion of the raising event.

Consuming: Every event instance is

Net Eect of Event Instances

{ User-dened points

Granularity of DB state change

Rule activation and deactivation

With rule sets (grouping)

Available since Version 6.

Internal to the database: