CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules

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

2. 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 ( -)

3. 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

4. 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)

5. Rule 2 and 1. 1. +closure(X,Y) :­ +base(X,Y). • +closure(X,Y) :­ +closure(X,Z), base(Z,Y). • + closure(X,Y) :­ closure(X,Z), +base(Z,Y). • We can emulaterules 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. This second rule will trigger itself recursively

6. 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 • +closure(X,Y) :­ +base(X,Y). • +closure(X,Y) :­ closure(X,Z), +base(Z,Y). • +closure(X,Y) :­ +base(X,Z), closure(Z,Y). • +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.

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

8. 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 alsoneeded! or +discount(X)<- -member(X), senior(X). Better! These are called re-insert rules

9. 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).

10. Addition to DB tables: + Rules 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). 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).

11. 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). c (X,Y) :­ b2(X,Y). Positive : second rule cannot change the+ of the first rule Negative : The second rule can neutralize the - of the first rule

12. 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+ .

13. 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 alsoneeded! or + discount(X)<- - member(X), senior(X). Better! These are called re-insert rules

14. Delete Rules after some trains and stations are eliminated 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). 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)

15. Reinsert Rules: using the new_Station and new_Train and the rules with the - magic 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). 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).