## Search in the document preview

1

Datalog

Rules Programs Negation

docsity.com

2

Review of Logical If-Then Rules

h(X,…) :- a(Y,…) & b(Z,…) & …

head

body

subgoals

“The head is true if all the subgoals are true.”

docsity.com

3

Terminology

Head and subgoals are atoms. An atom consists of a predicate (lower case) applied to zero or more arguments (upper case letters or constants).

docsity.com

4

Semantics

Predicates represent relations. An atom is true for given values of its variables iff the arguments form a tuple of the relation. Whenever an assignment of values to all variables makes all subgoals true, the rule asserts that the resulting head is also true.

docsity.com

5

Example

We shall develop rules that describe what is necessary to “make” a file. The predicates/relations: source(F) = F is a “source” file. includes(F,G) = F #includes G. create(F,P,G) = F is created by applying process P to file G.

docsity.com

6

Example --- Continued

Rules to define “view” req(X,Y) = file Y is required to create file X : req(F,F) :- source(F) req(F,G) :- includes(F,G) req(F,G) :- create(F,P,G) req(F,G) :- req(F,H) & req(H,G)

G is required for F if there is some process P that creates F from G.

G is required for F if there is some H such that H is required for F and G is required for H.

docsity.com

7

Why Not Just Use SQL?

1. Recursion is much easier to express in Datalog.

Viz. last rule for req.

2. Rules express things that go on in both FROM and WHERE clauses, and let us state some general principles (e.g., containment of rules) that are almost impossible to state correctly in SQL.

docsity.com

8

IDB/EDB

A predicate representing a stored relation is called EDB (extensional database). A predicate representing a “view,” i.e., a defined relation that does not exist in the database is called IDB (intesional database). Head is always IDB; subgoals may be IDB or EDB.

docsity.com

9

Datalog Programs

A collection of rules is a (Datalog) program. Each program has a distinguished IDB predicate that represents the result of the program.

E.g., req in our example.

docsity.com

10

Extensions

1. Negated subgoals. 2. Constants as arguments. 3. Arithmetic subgoals.

docsity.com

11

Negated Subgoals

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. Example:

cycle(F) :- req(F,F) & NOT source(F)

docsity.com

12

Constants as Arguments

We use numbers, lower-case letters, or quoted strings to indicate a constant. Example:

req(“foo.c”, “stdio.h”) :-

Note that empty body is OK. Mixed constants and variables also OK.

docsity.com

13

Arithmetic Subgoals Comparisons like < may be thought of as infinite, binary relations.

Here, the set of all tuples (x,y) such that x<y.

Use infix notation for these predicates. Example:

composite(A) :- divides(B,A) & B > 1 & B != A

docsity.com

14

Evaluating Datalog Programs

1. Nonrecursive programs. 2. Naïve evaluation of recursive

programs without IDB negation. 3. Seminaïve evaluation of recursive

programs without IDB negation. Eliminates some redundant computation.

docsity.com

15

Safety

When we apply a rule to finite relations, we need to get a finite result. Simple guarantee: safety = all variables appear in some nonnegated, relational (not arithmetic) subgoal of the body.

Start with the join of the nonnegated, relational subgoals and select/delete from there.

docsity.com

16

Examples: Nonsafety

p(X) :- q(Y)

bachelor(X) :- NOT married(X,Y)

bachelor(X) :- person(X) &

NOT married(X,Y)

X is the problem Both X and Y are problems

Y is still a problem

docsity.com

17

Nonrecursive Evaluation

If (and only if!) a Datalog program is not recursive, then we can order the IDB predicates so that in any rule for p (i.e., p is the head predicate), the only IDB predicates in the body precede p.

docsity.com

18

Why?

Consider the dependency graph with: Nodes = IDB predicates. Arc p -> q iff there is a rule for p with q in the body.

Cycle involving node p means p is recursive. No cycles: use topological order to evaluate predicates.

docsity.com

19

Applying Rules

To evaluate an IDB predicate p : 1. Apply each rule for p to the current

relations corresponding to its subgoals. “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).

2. Take the union of the result for each p- rule.

docsity.com

20

Example

p(X,Y) :- q(X,Z) & r(Z,Y) & Y<10

Q = {(1,2), (3,4)}; R = {(2,5), (4,9), (4,10), (6,7)} Assignments making the body true:

(X,Y,Z) = (1,5,2), (3,9,4) So P = {(1,5), (3,9)}.

docsity.com

21

Algorithm for Nonrecursive

FOR (each predicate p in topological order) DO

apply the rules for p to

previously computed relations

to compute relation P for p;

docsity.com

22

Naïve Evaluation for Recursive

make all IDB relations empty;

WHILE (changes to IDB) DO

FOR (each IDB predicate p) DO

evaluate p using current

values of all relations;

docsity.com

23

Important Points

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. Since relations are finite, the loop must eventually terminate. Result is the least fixedpoint (minimal model ) of rules.

docsity.com

24

Seminaïve Evaluation

Key idea: to get a new tuple for relation P on one round, the evaluation must use some tuple for some relation of the body that was obtained on the previous round. Maintain ∆P = new tuples added to P on previous round. “Differentiate” rule bodies to be union of bodies with one IDB subgoal made “∆.”

docsity.com

25

Example (“make files”)

r(F,F) :- s(F)

r(F,G) :- i(F,G))

r(F,G) :- c(F,P,G)

r(F,G) :- r(F,H) & r(H,F)

Assume EDB predicates s, i, c have relations S, I, C.

docsity.com