Upcoming SlideShare
×

# [ABDO] Logic As A Database Language

575 views

Published on

Published in: Technology
0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
575
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
0
0
Likes
0
Embeds 0
No embeds

No notes for slide

### [ABDO] Logic As A Database Language

1. 1. Databases: A Logical View Logic as a Database Language Integrity Constraints Query Containment
2. 2. Logic as a Database Language <ul><li>Base facts : represent the tuples stored in the database relations: </li></ul><ul><ul><ul><ul><li>father (john, tony) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>mother (mary, bob) </li></ul></ul></ul></ul><ul><li>Deductive rules : define which derived (view) facts can be inferred from base facts: </li></ul><ul><ul><ul><ul><li>parent ( X , Y )  father ( X , Y ) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>parent ( X , Y )  mother ( X , Y ) </li></ul></ul></ul></ul>
3. 3. Meaning of Deductive Rules “ The head is true if all the subgoals are true.” head body subgoals h ( X ,…)  a ( Y ,…)  b ( Z ,…)  …
4. 4. Meaning of Deductive Rules (cont.) <ul><li>Head and subgoals are atoms . </li></ul><ul><li>An atom consists of a predicate applied to zero or more arguments (variables or constants). </li></ul><ul><li>Predicates represent relations. </li></ul><ul><li>An atom is true for given values of its variables iff the arguments form a tuple of the relation. </li></ul><ul><li>Whenever an assignment of values to all variables makes all subgoals true, the rule asserts that the resulting head is also true </li></ul><ul><li>Although is seldom shown, all variables are assumed to universally quantified in the whole formula: </li></ul><ul><li> X  Y ( isHappy ( X )  married ( X , Y )  isRich ( Y ) ) </li></ul>
5. 5. IDB/EDB <ul><li>A predicate representing a stored relation is called EDB (extensional database). </li></ul><ul><li>A predicate representing a “view,” i.e., a defined relation that does not exist in the database is called IDB (intesional database). </li></ul><ul><li>Head is always IDB; subgoals may be IDB or EDB. </li></ul>
6. 6. Applying Rules <ul><li>To evaluate an IDB predicate p : </li></ul><ul><ul><li>Apply each rule for p to the current relations corresponding to its subgoals. </li></ul></ul><ul><ul><ul><li>“ Apply” = If an assignment of values to variables makes the body true, insert the tuple that the head becomes into the relation for p (no duplicates). </li></ul></ul></ul><ul><ul><li>Take the union of the result for each p -rule. </li></ul></ul>
7. 7. Computing IDB Relations: A Naïve Algorithm <ul><li>Notes: </li></ul><ul><ul><li>As long as there is no negation of IDB subgoals, then each IDB relation “grows,” i.e., on each round it contains at least what it used to contain. </li></ul></ul><ul><ul><li>Since relations are finite, the loop must eventually terminate. </li></ul></ul><ul><ul><li>Result is the least fixed point ( minimal model ) of rules. </li></ul></ul>make all IDB relations empty; REPEAT FOR (each IDB predicate p) DO evaluate p using current values of all relations; UNTIL (no IDB relation is changed)
8. 8. Computing IDB Relations: Example <ul><li>R#0: IDB 0 =  </li></ul><ul><li>R#1: IDB 1 = IDB 0  {parent(j,t), parent(p,m), parent(m,b)} </li></ul><ul><li>R#2: IDB 2 = IDB 1  {grandfather(p,b), ancestor(j,t), ancestor(p,m), ancestor(m,b)} </li></ul><ul><li>R#3: IDB 3 = IDB 2  {ancestor(p,b)} </li></ul><ul><li>R#4: IDB 4 = IDB 3 </li></ul>parent ( X , Y )  father ( X , Y ) parent ( X , Y )  mother ( X , Y ) grandfather ( X , Y )  father ( X , Z )  parent ( Z , Y ) ancestor ( X , Y )  parent ( X , Y ) ancestor ( X , Y )  parent ( X , Z )  ancestor ( Z , Y ) father (john, tony) mother (mary, bob) father (peter, mary) FACTS DEDUCTIVE RULES
9. 9. Comparative Expressive Power <ul><li>Logical (sub)languages </li></ul><ul><li>Conjunctive queries ( views ): a single deductive rule defining an IDB predicate with no IDB subgoals </li></ul><ul><li>Nonrecursive Datalog : </li></ul><ul><ul><li>≥ 1 rules for each IDB predicate </li></ul></ul><ul><ul><li>No head predicate appearing in the rule body </li></ul></ul><ul><li>Datalog : recursion allowed </li></ul><ul><li>Relational Algebra </li></ul><ul><li>Expressions with SELECT, PROJECT, JOIN operators </li></ul><ul><li>Expressions with SELECT, PROJECT, JOIN, UNION </li></ul><ul><li>Recursion not allowed (SQL: in a limited way) </li></ul>
10. 10. Datalog Extensions <ul><li>Negated subgoals. </li></ul><ul><ul><li>‘ ¬’ (NOT) in front of a subgoal means that an assignment of values to variables must make it false in order for the body to be true. </li></ul></ul><ul><ul><li>Closed world assumption (CWA): the facts that are not known to be true, are false. </li></ul></ul><ul><ul><li>Example: lucky ( X )  meets ( X , Y )  ¬ isMarried ( Y ) </li></ul></ul><ul><li>Arithmetic subgoals. </li></ul><ul><ul><li>Mostly, order and (in)equality comparisons: =, ≠, <, ≤ </li></ul></ul><ul><ul><li>Example: composite ( A )  divides ( B , A )  B > 1  B < A </li></ul></ul>
11. 11. Safe Rules <ul><li>When we apply a rule to finite relations, we need to get a finite result. </li></ul><ul><li>Simple guarantee: safety = all variables appear in some nonnegated, relational (not arithmetic) subgoal of the body </li></ul><ul><li>Nonsafety examples: </li></ul><ul><ul><ul><li>isHappy ( X )  isRich ( Y ) </li></ul></ul></ul><ul><ul><ul><li>bachelor ( X )  ¬ isMarried ( X ) </li></ul></ul></ul><ul><ul><ul><li>bachelor ( X )  male ( X )  ¬ married ( X , Y ) </li></ul></ul></ul><ul><ul><ul><li>isCheap ( X )  X < 10 </li></ul></ul></ul>Recall that every variable is universally quantified
12. 12. Rewriting Unsafe Rules <ul><li>Some unsafe situations can be mended: </li></ul><ul><ul><ul><li>bachelor ( X )  male ( X )  ¬ married ( X , Y ) </li></ul></ul></ul><ul><ul><ul><li>bachelor ( X )  male ( X )  ¬ isMarried ( X ) </li></ul></ul></ul><ul><ul><ul><li>isMarried ( X )  married ( X , Y ) </li></ul></ul></ul>
13. 13. Integrity Constraints <ul><li>Express conditions that every state of the database must satisfy </li></ul><ul><li>These conditions may be expressed as a general first order formulas: </li></ul><ul><li> E  D  S ( emp ( E , D , S )  dept ( D ) ) </li></ul><ul><li>“ If E is an emp of D for S, then D must be a dept” </li></ul><ul><li>In general , it is assumed that an integrity constraint is a formula in denial form: </li></ul><ul><li> emp ( E , D , S )  ¬ dept ( D ) </li></ul><ul><li>“ I cannot happen that E is an of at D for S and D is not a dept” </li></ul>
14. 14. Common Integrity Constraints <ul><li>Key Integrity Constraints ( primary keys ): </li></ul><ul><ul><li> married ( X, Y )  married ( X, Z )  Y ≠ Z </li></ul></ul><ul><li>Referential Integrity Constraints ( foreign keys ) </li></ul><ul><ul><li> married ( X, Y )  ¬ person ( X ) </li></ul></ul><ul><ul><li> married ( X, Y )  ¬ person ( Y ) </li></ul></ul><ul><li>“ Column Check” Constraints </li></ul><ul><ul><li> emp ( E, D, S )  S < 30000 </li></ul></ul>
15. 15. Deductive Databases DDB = { F, DR, IC } Extensional - base facts Intensional - deductive rules - integrity constraints EDB IDB
16. 16. Logic vs. SQL: View Definition <ul><li>Logic: </li></ul><ul><ul><li>grandfather ( X , Y )  father ( X , Z )  parent ( Z , Y ) </li></ul></ul><ul><li>SQL: </li></ul><ul><ul><li>CREATE VIEW grandfather AS </li></ul></ul><ul><ul><ul><li>SELECT father.asc, parent.desc </li></ul></ul></ul><ul><ul><ul><li>FROM father, parent </li></ul></ul></ul><ul><ul><ul><li>WHERE father.desc = parent.asc </li></ul></ul></ul><ul><ul><li>Negative literals can be handled by means of the NOT EXISTS sentence </li></ul></ul><ul><ul><li>Views defined by means of more than one rule are handled by the UNION operator </li></ul></ul><ul><ul><li>Recursion: in a restrictive way in SQL Standard (but not supported by most vendors) </li></ul></ul>
17. 17. Logic vs. SQL: Integrity Constraint Definition <ul><li>Logic: </li></ul><ul><ul><li> married ( X, Y )  married ( X, Z )  Y ≠ Z </li></ul></ul><ul><ul><li> married ( X, Y )  lives (Y, kabul) </li></ul></ul><ul><li>SQL: </li></ul><ul><ul><li>CREATE TABLE married( </li></ul></ul><ul><ul><ul><li>s1 CHAR(40) PRIMARY KEY, </li></ul></ul></ul><ul><ul><ul><li>s2 CHAR(40)) </li></ul></ul></ul><ul><ul><li>CREATE ASSERTION ic2 CHECK </li></ul></ul><ul><ul><li>(NOT EXISTS ( SELECT * FROM married, lives </li></ul></ul><ul><ul><li>WHERE married.s1 = lives.name </li></ul></ul><ul><ul><li>AND lives.loc = ‘Kabul’)) </li></ul></ul>Assertions are not broadly supported by DBMS vendors
18. 18. Logic vs. SQL: final remarks <ul><li>Wen using Logic as a Database language, we don’t take care of: </li></ul><ul><ul><li>NULL values </li></ul></ul><ul><ul><li>Bag semantics </li></ul></ul><ul><ul><li>Strong typing </li></ul></ul><ul><li>So, why use Logic instead of SQL? </li></ul><ul><ul><li>Deductive rules express things that go on in both FROM and WHERE clauses, and let us state some general principles and properties (e.g., containment of rules) that are almost impossible to state correctly in SQL. </li></ul></ul><ul><ul><li>We can take advantage of results, approaches, algorithms, … from Logic, Logic Programming and AI </li></ul></ul>
19. 19. Queries and Answers <ul><li>A query Q for a database D = ( EDB , DR , IC ) is a finite set of deductive rules that defines a dedicated n-ary query predicate q . </li></ul><ul><li>The answer to the query is the set of all ground facts about q obtained as a result of evaluating the deductive rules from both Q and DR on EDB : </li></ul><ul><li>{ q (a 1 ,…, a n ) | q (a 1 ,…, a n )  ( Q  DR )( EDB ) } </li></ul>
20. 20. Query Containment <ul><li>A query Q 1 is contained in another query Q 2 , Q 1 ⊑ Q 2 , when the answer that a query Q 1 obtains is a subset of the answer obtained by another Q 2 , for every database state. </li></ul>Q 1 is contained in Q 2 : Q 1 ⊑ Q 2 { q (a 1 ,…, a n ) | q (a 1 ,…, a n )  ( Q 1  DR )( EDB ) }   { q (b 1 ,…, b n ) | q (b 1 ,…, b n )  ( Q 2  DR )( EDB ) } for any EDB
21. 21. Query Containment under Constraints <ul><li>When considering the integrity constraints defined in a database, the containment relationship between two queries does not need to hold for any state (content) of the database but only for the consistent ones, i.e. those that satisfy the integrity constraints </li></ul>Q 1 is contained in Q 2 wrt. IC : Q 1 ⊑ IC Q 2 { q (a 1 ,…, a n ) | q (a 1 ,…, a n )  ( Q 1  DR )( EDB ) }   { q (b 1 ,…, b n ) | q (b 1 ,…, b n )  ( Q 2  DR )( EDB ) } for any EDB that does not violate IC
22. 22. Uses of Query Containment <ul><li>QC can be applied in several contexts: </li></ul><ul><ul><li>query optimisation </li></ul></ul><ul><ul><li>materialised view and cache reuse </li></ul></ul><ul><ul><li>query and predicate satisfiability checking </li></ul></ul><ul><ul><li>integrity constraints redundancy checking </li></ul></ul><ul><ul><li>queries independent of updates </li></ul></ul><ul><ul><li>constraints independent of updates </li></ul></ul><ul><ul><li>concept subsumption in Description Logics </li></ul></ul><ul><ul><li>Etc. </li></ul></ul><ul><li>... without accessing to the database contents in any case. </li></ul>
23. 23. Uses of QC: Example emp (joan, sales) emp (pere, sales) dept (sales) manager (pere, sales) em ( E , M )  emp ( E,D )  manager ( M , D ) Ic 1 :  emp ( E , D )  ¬ dept ( D ) Ic 2 :  manager ( M , D )  ¬ emp ( M , D ) Ic 3 :  manager ( M , D )  ¬ dept ( D ) Q 1 : q ( E , M )  em ( E , M )  emp ( E , D ) Q 2 : q ( M , D )  manager ( M , D )  ¬ emp ( M , D ) U 1 : { Insert dept (accounting)} <ul><li>emp ( E , D ) in Q 1 is redundant </li></ul><ul><li>em is independent of U 1 </li></ul><ul><li>Ic 3 is redundant according to Ic 1 and Ic 2 : </li></ul><ul><li>Ic 3 ⊑ Ic 1  Ic 2 </li></ul><ul><li>Q 2 is insatisfiable: Q 2 ⊑ IC Ø </li></ul><ul><li>Ic 1 , Ic 2 and Ic 3 are independent of U 1 </li></ul>
24. 24. Containment of Conjunctive Queries <ul><li>Recall that a CQ is a single deductive rule, with all subgoals assumed to be EDB. </li></ul><ul><li>Theorem : Q 1 ⊑ Q 2 if and only if t here is a containment mapping from Q 2 to Q 1 </li></ul><ul><li>A containment mapping from Q 2 to Q 1 is a mapping from the atoms of Q 2 to the atoms of Q 1 , such that: </li></ul><ul><ul><li>Each subgoal of Q 2 is mapped to some subgoal of Q 1 with the same predicate. </li></ul></ul><ul><ul><li>No variable in Q 2 mapped to two different variables in Q 1 . </li></ul></ul><ul><ul><li>The head of Q 2 is mapped to the head of Q 1 . </li></ul></ul>
25. 25. Containment of CQs: Examples <ul><li>Q1: p(X,Y)  r(X,Y)  g(Y,Z) </li></ul><ul><li>Q2: p(A,B)  r(A,B)  r(A,C) </li></ul><ul><li>Q3: p(U,V)  r(V,U)  r(U,W) </li></ul>Q 1 ⊑ Q 2 Q 2 ⋢ Q 3
26. 26. Complexity of Checking QC for CQ’s <ul><li>Testing Containment is NP-complete, but CQ’s tend to be small so here is one case of a NP problem that is “tractable” in general </li></ul><ul><li>Some special cases where QC is in P: </li></ul><ul><ul><li>Q1 (the contained query) has no more than one subgoal with the same predicate  straightforward </li></ul></ul><ul><ul><li>Q1 has no more than two subgoals with the same predicate  a more complex proof, based on a reduction to 2SAT. </li></ul></ul><ul><ul><li>Etc. </li></ul></ul>