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 transclosure1 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 transclosure2 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.
2.
3.
4.
+ 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.
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
DB:
+Station(city, state).
Rules: r1. Route(c1,c2) :-
+Train(city1, city2).
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:
r1i.
+Route(c1,c2) :-
+ Train(c1,c2).
r2i1.
+Route(c1,c2) :-
+ Route(c1,c3), Route(c3,c1).
r2i2.
+Route(c1,c2) :-
Route(c1,c3), +Route(c3,c2).
r3i.
+ReachCal(c) :-
+Station(c,s), s = ''California''
r4i1.
+ReachCal(c) :-
+ Route(c,c1), ReachCal(c1).
r4i2.
+ReachCal(c) :-
Route(c,c1), +ReachCal(c1).
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
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
DB: - Station(city, state).
Rules: r1. Route(c1,c2) :-
- Train(city1, city2).
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).
r1d.
- Route(c1,c2) :-
-Train(c1,c2)
r2d1.
- Route(c1,c2) :-
-Route(c1,c3), OLD_Route(c3,c2)
r2d2.
- Route(c1,c2) :-
OLD_Route(c1,c3), - Route(c3,c2)
r3d.
- ReachCal(c) :-
- Station(c,s), s = ''California''
r4d1. - ReachCal(c) :-
- Route(c,c1), OLD_ReachCal(c1)
r4d2. - ReachCal(c) :-
OLD_Route(c,c1), - ReachCal(c1)
Reinsert Rules: using the new_Station and
new_Train and the rules with the - magic
new_DB:
Station(city, state).
Rules: r1. Route(c1,c2) :-
Train(city1, city2).
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).
r1r.
+ Route(c1,c2) :
-Route(c1,c2), Train(c1,c2)
r2r.
+ Route(c1,c2) :
-Route(c1,c2),
Route(c1,c3), Route(c3,c2).
r3r.
+ ReachCal(c) : -ReachCal(c),
Station(c,s), s = ''California''
r4r.
+ ReachCal(c) : - ReachCal(c),
Route(c,c1),ReachCal(c1).