# CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles.

## Presentation on theme: "CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles."— Presentation transcript:

CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles

Maintenance  Every time the database is changed re-compute the concrete view, or  Perform delta maintenance using techniques similar to the differential fixpoint of deductive databases  Things are more complex here because you can have both additions (  + ) an subtractions (  - )

Positive Delta Rules prnt(X, Y) :- father(X, Y). prnt(X, Y) :- mother(X, Y). gprnt(X, Y) :­ prnt(X, Z), prnt(Z, Y). Assume that some new tuples are added to mother: 1.  + prnt(X,Y) :­  + mother(X,Y). 2.  + gprnt(X,Y) :­  + prnt(X,Z), prnt(Z,Y). 3.  + gprnt(X,Y) :­ prnt(X,Z),  + prnt(Z,Y). Finite differentiation w.r.t. all changing predicates

Closure is the TC of base, and new records are inserted into base(fr, to)  Deductive rules for transitive closure of base(fr, to): closure(X,Y) :­ base(X,Y) closure(X,Y) :­ closure(X,Z), base(Z,Y). 1.  + closure(X,Y) :­  + base(X,Y). 2.  + closure(X,Y) :­  + closure(X,Z), base(Z,Y). …a careful analysis shows that we need a third rule: 3.  + closure(X,Y) :­ closure(X,Z),  + base(Z,Y). Example: assume that at time t1 we have the following facts: base(a,b). closure(a,b). Then insertion of  + base(b,c) yields  + closure(b,c) by rule 1. But rule 2 produces nothing: we need rule 3 to get:  + closure(a,c)

Rule 2 and 1. 1.  + closure(X,Y) :­  + base(X,Y). 2.  + closure(X,Y) :­  + closure(X,Z), base(Z,Y). 3.  + closure(X,Y) :­ closure(X,Z),  + base(Z,Y).  We can emulate rules 1 and 3 create rule trans­closure1 on base when inserted then insert into closure (select * from inserted ) union select closure.fr, inserted.to from inserted, base where closure.to=inserted.fr  Then use triggers to finish the closure computation: create rule trans­closure2 on closure when inserted then insert into closure (select inserted.fr, closure.to from inserted, base where inserted.to=base.from) This second rule will trigger itself recursively

Computing Transitive Closure: non-recursive trigger!  Deductive rules for transitive closure of base(fr, to): closure(X,Y) :­ base(X,Y) closure(X,Y) :­ closure(X,Z), closure(Z,Y). One new tuple at the time.  + base only contains one tuple 1.  + closure(X,Y) :­  + base(X,Y). 2.  + closure(X,Y) :­ closure(X,Z),  + base(Z,Y). 3.  + closure(X,Y) :­  + base(X,Z), closure(Z,Y). 4.  + closure(X,Y) :­ closure(X,Z),  + base(Z,W), closure(W,Y). Proposition: If  + base only contains one tuple, these rules only need to be execute once! Or,  + contains many rows but we use the “for each row” semantics. … in fact if they are executed sequentially we no longer need rule 4.

Delta Maintenance  In general, in addition to addition  We need to consider deletions and updates. Deletions are mor

Delta Maintenance after Deletion Discount concrete view defined as follows: discount(X)<- member(X). discount(X) <- senior(X). Let us add new members:  + discount(X)<-  + member(X).... Done! Remove old members:  - discount(X)<-  - member(X). Not Done...  + discount(X)<- senior(X). Is also needed! or  + discount(X)<-  - member(X), senior(X). Better! These are called re-insert rules

More general programs  Database: Station(city, state). Train(city1, city2).  Deductive rules: r1. Route(c1,c2) :-Train(c1,c2). r2. Route(c1,c2) :­ Route(c1,c3), Route(c3,c2). r3. ReachCal(c) :­ Station(c,s), s = ''California'‘. r4. ReachCal(c) :­ Route(c,c2), ReachCal(c2).

Addition to DB tables:  + Rules Here the delta occur in the base relations: r1­i.  + Route(c1,c2) :-  + Train(c1,c2). r2­i1.  + Route(c1,c2) :-  + Route(c1,c3), Route(c3,c1). r2­i2.  + Route(c1,c2) :- Route(c1,c3),  + Route(c3,c2). r3­i.  + ReachCal(c) :-  + Station(c,s), s = ''California'' r4­i1.  + ReachCal(c) :-  + Route(c,c1), ReachCal(c1). r4­i2.  + ReachCal(c) :- Route(c,c1),  + ReachCal(c1). DB:  + Station(city, state).  +Train(city1, city2). Rules: r1. Route(c1,c2) :-Train(c1,c2). r2. Route(c1,c2) :­ Route(c1,c3), Route(c3,c2). r3. ReachCal(c) :­ Station(c,s), s = ''California'‘. r4. ReachCal(c) :­ Route(c,c2), ReachCal(c2).

Delete Rules  With concrete views, we need to consider the situation where tuples are deleted from database relations  Updates can be treated by combining insert rules and delete rules  Delete rules are more complex than insert rules: for insertion. Eg. Add-to vs delete-from b1.  + c (X,Y) :­  + b1(X,Y).  - c (X,Y) :­  - b1(X,Y). c (X,Y) :­ b2(X,Y). Positive  : second rule cannot change the  + of the first rule c (X,Y) :­ b2(X,Y). Negative  : The second rule can neutralize the  - of the first rule

Delete Rules: Students taking a Class, dropping the class--Negative Delta in (P, Cno). %P means professor tk(Cno, St). grds(P, St) :- in(P, Cno), tk(Cno, St). %concrete view Assume that the pairs in  - are deleted from tk:  - grds(P, St) :- in(P, Cno),  - tk(Cno, St). (1) These are the tuples that we should consider for elimination from the concrete view. But this is a necessary but not sufficient condition for elimination. Why? … the student could be taking more than one course from the same instructor. Solution: reinsert rules—the original rules constrained by  - grds  + grds(P, St) :­  - grads(P, St), in(P, Cno), tk(Cno, St). (2) Thus we first delete and then reinsert. Or we could delete those in (1) who are not in (2): the difference between  - and  +.

Delta Maintenance after Deletion Discount concrete view defined as follows: discount(X)<- member(X). discount(X) <- senior(X). Let us add new members:  + discount(X)<-  + member(X).... Done! Remove old members:  - discount(X)<-  - member(X). Not Done...  + discount(X)<- senior(X). Is also needed! or  + discount(X)<-  - member(X), senior(X). Better! These are called re-insert rules

Delete Rules after some trains and stations are eliminated r1­d.  - Route(c1,c2) :-  - Train(c1,c2) r2­d1.  - Route(c1,c2) :-  - Route(c1,c3), OLD_Route(c3,c2) r2­d2.  - Route(c1,c2) :- OLD_Route(c1,c3),  - Route(c3,c2) r3­d.  - ReachCal(c) :-  - Station(c,s), s = ''California'' r4­d1.  - ReachCal(c) :-  - Route(c,c1), OLD_ReachCal(c1) r4­d2.  - ReachCal(c) :- OLD_Route(c,c1),  - ReachCal(c1) DB:  - Station(city, state).  - Train(city1, city2). Rules: r1. Route(c1,c2) :-Train(c1,c2). r2. Route(c1,c2) :­ Route(c1,c3), Route(c3,c2). r3. ReachCal(c) :­ Station(c,s), s = ''California'‘. r4. ReachCal(c) :­ Route(c,c2), ReachCal(c2).

Reinsert Rules: using the new_Station and new_Train and the rules with the  - magic r1­r.  + Route(c1,c2) :­  - Route(c1,c2), Train(c1,c2) r2­r.  + Route(c1,c2) :­  - Route(c1,c2), Route(c1,c3), Route(c3,c2). r3­r.  + ReachCal(c) :­  - ReachCal(c), Station(c,s), s = ''California'' r4­r.  + ReachCal(c) :­  - ReachCal(c), Route(c,c1),ReachCal(c1). new_ DB: Station(city, state). Train(city1, city2). Rules: r1. Route(c1,c2) :-Train(c1,c2). r2. Route(c1,c2) :­ Route(c1,c3), Route(c3,c2). r3. ReachCal(c) :­ Station(c,s), s = ''California'‘. r4. ReachCal(c) :­ Route(c,c2), ReachCal(c2).

Download ppt "CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles."

Similar presentations