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

Slides:



Advertisements
Similar presentations
DB glossary (focus on typical SQL RDBMS, not XQuery or SPARQL)
Advertisements

Active database concepts
1 Term 2, 2004, Lecture 2, Normalisation - IntroductionMarian Ursu, Department of Computing, Goldsmiths College Normalisation Introduction.
RDFTL: An Event-Condition- Action Language for RDF George Papamarkos Alexandra Poulovassilis Peter T. Wood School of Computer Science and Information Systems.
Lecture 11: Datalog Tuesday, February 6, Outline Datalog syntax Examples Semantics: –Minimal model –Least fixpoint –They are equivalent Naive evaluation.
CS4432: Database Systems II
CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS240A: Databases and Knowledge Bases Temporal Applications and SQL:1999 Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS240A: Databases and Knowledge Bases Introduction Carlo Zaniolo Department of Computer Science University of California, Los Angeles WINTER 2002.
1 Advanced Database Technology Anna Östlin Pagh and Rasmus Pagh IT University of Copenhagen Spring 2004 February 19, 2004 INDEXING I Lecture based on [GUW,
CS240A: Databases and Knowledge Bases Fixpoint Semantics of Datalog Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS 240A: Databases and Knowledge Bases Analysis of Active Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS240A: Databases and Knowledge Bases A Taxonomy of Temporal DBs Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
Using Relational Databases and SQL Steven Emory Department of Computer Science California State University, Los Angeles Lecture 1: Introduction to Relational.
Introduction to CSE 591: Autonomous agents - theory and practice. Chitta Baral Professor Department of Computer Sc. & Engg. Arizona State University.
CS240A: Databases and Knowledge Bases Applications of Active Database Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Using Definite Knowledge Notes for Ch.3 of Poole et al. CSCE 580 Marco Valtorta.
CS240A: Databases and Knowledge Bases From Deductive Rules to Active Rules Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
Data Warehouse View Maintenance Presented By: Katrina Salamon For CS561.
Functional Dependencies CS 186, Spring 2006, Lecture 21 R&G Chapter 19 Science is the knowledge of consequences, and dependence of one fact upon another.
What Are File Maintenance Techniques and Validation Techniques?
CS240A: Databases and Knowledge Bases Introduction Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS 240A: Databases and Knowledge Bases Introduction to Active Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
1 PHP and MySQL. 2 Topics  Querying Data with PHP  User-Driven Querying  Writing Data with PHP and MySQL PHP and MySQL.
Chapter 15 Recursion INTRODUCTION Recursion is a program-solving technique that expresses the solution of a problem in terms of the solutions of.
Department of Computer Science and Engineering, HKUST 1 More on Isolation.
1 Context “Updating Union, Intersection and Difference views” - introduces a systematic approach to updating a view formed specifically by using  Union.
Database Systems Microsoft Access Practical #3 Queries Nos 215.
ARTIFICIAL INTELLIGENCE DR. ABRAHAM AI a field of computer science that is concerned with mechanizing things people do that require intelligent.
Unit III. Views A table that is derived from other tables Considered as a virtual table Does not store data.
CS240A: Databases and Knowledge Bases Recursive Queries in SQL 1999 Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
Devina DesaiF r a m e P r o b l e m What is a Frame Problem Environment for an agent is not static Identifying which things remain static in changing word.
CS 240A: Databases and Knowledge Bases Introduction to Active Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS240A: Databases and Knowledge Bases Temporal Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS 240A: Databases and Knowledge Bases Analysis of Active Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
Riyadh Philanthropic Society For Science Prince Sultan College For Woman Dept. of Computer & Information Sciences CS 340 Introduction to Database Systems.
2/16/2016Lecture 31 CS 222 Database Management System Spring Lecture 3 b Korra Sathya Babu Department of Computer Science NIT Rourkela.
CS542 1 Schema Refinement Chapter 19 (part 1) Functional Dependencies.
CS240A:A sample LDL++ Session Carlo Zaniolo Department of Computer Science University of California, Los Angeles December, 2001.
CS240A: Databases and Knowledge Bases Recursive Queries in SQL 2003 Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
Database Management COP4540, SCS, FIU Database Trigger.
CS240A: Databases and Knowledge Bases TSQL2 Carlo Zaniolo Department of Computer Science University of California, Los Angeles Notes From Chapter 6 of.
Chapter 13 Triggers. Trigger Overview A trigger is a program unit that is executed (fired) due to an event Event such as updating tables, deleting data.
Chapter 13 Triggers. Trigger Overview A trigger is a program unit that is executed (fired) due to an event Event such as updating tables, deleting data.
Copyright © 2004 Pearson Education, Inc.. Chapter 24 Enhanced Data Models for Advanced Applications.
April 20022/CS/3X1 Database Design Design method John Wordsworth Department of Computer Science The University of Reading Room.
CS240A: Databases and Knowledge Bases Introduction Carlo Zaniolo Department of Computer Science University of California, Los Angeles.
CS4222 Principles of Database System
CS240A: Databases and Knowledge Bases Introduction
Creating Database Triggers
CS422 Principles of Database Systems Normalization
CS480 Cryptography and Information Security
CS422 Principles of Database Systems Normalization
CS522 Advanced database Systems
Web Design and Development
A SIMPLE GUIDE TO FIVE NORMAL FORMS (See the next slide for required reading) Prof. Ghandeharizadeh 2018/11/14.
CST221: Database Systems (III)
Functional Dependencies and Normalization
Advanced SQL: Views & Triggers
Business Application Development
CS122 Using Relational Databases and SQL
Normalization cs3431.
CS 405G: Introduction to Database Systems
Logic Based Query Languages
Relational Database Design
Chapter 19 (part 1) Functional Dependencies
CS122 Using Relational Databases and SQL
CS240A: Databases and Knowledge Bases TSQL2
CS240A: Databases and Knowledge Bases A Taxonomy of Temporal DBs
Advanced Topics: Indexes & Transactions
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  + 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).