Datalog

Features, limitations and extensions

Unlike in Prolog, statements of a Datalog program can be stated in any order. Furthermore, Datalog queries on finite sets are guaranteed to terminate, so Datalog does not have Prolog's cut operator. This makes Datalog a fully declarative language.

In contrast to Prolog, Datalog

1. disallows complex terms as arguments of predicates, e.g., p (1, 2) is admissible but not p (f (1), 2),
2. imposes certain stratification restrictions on the use of negation and recursion,
3. requires that every variable that appears in the head of a clause also appears in a nonarithmetic positive (i.e. not negated) literal in the body of the clause,
4. requires that every variable appearing in a negative literal in the body of a clause also appears in some positive literal in the body of the clause^[5]

Query evaluation with Datalog is based on first-order logic, and is thus sound and complete. However, Datalog is not Turing complete, and is thus used as a domain-specific language that can take advantage of efficient algorithms developed for query resolution. Indeed, various methods have been proposed to efficiently perform queries, e.g., the Magic Sets algorithm,^[6] tabled logic programming^[7] or SLG resolution.^[8]

Some widely used database systems include ideas and algorithms developed for Datalog. For example, the SQL:1999 standard includes recursive queries, and the Magic Sets algorithm (initially developed for the faster evaluation of Datalog queries) is implemented in IBM's DB2.^[9] Moreover, Datalog engines are behind specialised database systems such as Intellidimension's database for the semantic web.^{[citation needed]}

Several extensions have been made to Datalog, e.g., to support aggregate functions, to allow object-oriented programming, or to allow disjunctions as heads of clauses. These extensions have significant impacts on the definition of Datalog's semantics and on the implementation of a corresponding Datalog interpreter.

Fragments

Datalog programs may or may not use negation in rule bodies: Datalog programs with negation are often required to use it as stratified negation to ensure that the semantics are well-defined. Datalog programs may or may not use inequalities between variables in rule bodies.

Some syntactic fragments of Datalog have been defined, such as the following (from most restricted to least restricted):

• linear Datalog, where rule bodies must consist of a single atom
• guarded Datalog, where for every rule, all the variables that occur in the rule bodies must occur together in at least one atom, called a guard atom
• frontier-guarded Datalog, where for every rule, all the variables that are shared between the rule body and the rule head (called the frontier variables) must all occur together in a guard atom

Another restriction concerns the use of recursion: nonrecursive Datalog is defined by disallowing recursion in the definition of Datalog programs. This fragment of Datalog is as expressive as unions of conjunctive queries, but writing queries as nonrecursive Datalog can be more concise.

Expressiveness

The boundedness problem for Datalog asks, given a Datalog program, whether it is bounded, i.e., the maximal recursion depth reached when evaluating the program on an input database can be bounded by some constant. In other words, this question asks whether the Datalog program could be rewritten as a nonrecursive Datalog program. Solving the boundedness problem on arbitrary Datalog programs is undecidable,^[10] but it can be made decidable by restricting to some fragments of Datalog.

Example

These two lines define two facts, i.e. things that always hold:

parent(xerces, brooke).
parent(brooke, damocles).

This is what they mean: xerces is a parent of brooke and brooke is a parent of damocles. The names are written in lowercase because strings beginning with an uppercase letter stand for variables.

These two lines define rules, which define how new facts can be inferred from known facts.

ancestor(X, Y) :- parent(X, Y).
ancestor(X, Y) :- parent(X, Z), ancestor(Z, Y).

meaning:

• X is an ancestor of Y if X is a parent of Y.
• X is an ancestor of Y if X is a parent of some Z, and Z is an ancestor of Y.

This line is a query:

?- ancestor(xerces, X).

It asks the following: Who are all the X that xerces is an ancestor of? It would return brooke and damocles when posed against a Datalog system containing the facts and rules described above.

More about rules: a rule has a :- symbol in the middle: the part to the left of this symbol is the head of the rule, the part to the right is the body. A rule reads like this: <head> is known to be true if it is known that <body> is true. Uppercase letters in rules stand for variables: in the example, we don't know who X or Y are, but some X is the ancestor of some Y if that X is the parent of that Y. The ordering of the clauses is irrelevant in Datalog, in contrast to Prolog, which depends on the ordering of clauses for computing the result of the query call.

Datalog distinguishes between extensional predicate symbols (defined by facts) and intensional predicate symbols (defined by rules).^[11] In the example above ancestor is an intensional predicate symbol, and parent is extensional. Predicates may also be defined by facts and rules and therefore neither be purely extensional nor intensional, but any Datalog program can be rewritten into an equivalent program without such predicate symbols with duplicate roles.

Syntax

A Datalog program consists of a list of facts and rules (Horn clauses).^[12] If constant and variable are two countable sets of constants and variables respectively and relation is a countable set of predicate symbols, then the following grammar expresses the structure of a Datalog program:

<program> ::= <fact> <program> | <rule> <program> | ɛ
<fact> ::=  <relation> "(" <constant-list> ")." 
<rule> ::= <atom> ":-" <atom-list> "."
<atom> ::= <relation> "(" <term-list> ")"
<atom-list> ::= <atom> | <atom> "," <atom-list>
<term> ::= <constant> | <variable>
<term-list> ::= <term> | <term> "," <term-list>
<constant-list> ::= <constant> | <constant> "," <constant-list>

Atoms are also referred to as literals in the literature.

Semantics

There are three widely-used approaches to the semantics of Datalog programs: model-theoretic, fixed-point, and proof-theoretic.

Model Theory

A fact or rule is called ground if all of its subterms are constants. A ground rule R₁ is a ground instance of another rule R₂ if R₁ is the result of a substitution of constants for all the variables in R₂.

The Herbrand base (see Herbrand Universe) of a Datalog program is the set of all ground atoms that can be made with the constants appearing in the program. An interpretation (also known as a database instance) is a subset of the Herbrand base. A ground atom is true in an interpretation I if it is an element of I. A rule is true in an interpretation I if for each ground instance of that rule, if all the clauses in the body are true in I, then the head of the rule is also true in I.

A model of a Datalog program P is an interpretation I of P which contains all the ground facts of P, and makes all of the rules of P true in I. Model-theoretic semantics state that the meaning of a Datalog program is its minimal model (equivalently, the intersection of all its models).^[13]

Fixpoint Semantics

Let I be the set of interpretations of a Datalog program P (i.e. I = P(H) where H is the Herbrand base of P and P is the powerset operator. Define a map from I to I as follows: For each ground instance of each rule in P, if every clause in the body is in the input interpretation, the add the head of the ground instance to the output interpretation. Then the fixed point of this map is the minimal model of the program. The fixpoint semantics suggest an algorithm for computing the minimal model: Start with the set of ground facts in the program, then repeatedly add consequences of the rules until a fixpoint is reached.^[14]

Evaluation

There are many different ways to evaluate a Datalog program, with different performance characteristics.

Bottom-Up Evaluation Strategies

Bottom-up evaluation strategies start with the facts in the program and repeatedly apply the rules until the either some goal or query is established, or until the complete minimal model of the program is produced.

Naïve Evaluation

Naïve evaluation mirrors the fixpoint semantics for Datalog programs. Naïve evaluation uses a set of "known facts", which is initialized to the facts in the program. It proceeds by repeatedly enumerating all ground instances of each rule in the program. If each atom in the body of the ground instance is in the set of known facts, then the head atom is added to the set of known facts. This process is repeated until a fixed point is reached, and no more facts may be deduced. Naïve evaluation produces the entire minimal model of the program.^[15]

Systems implementing Datalog

Here is a short list of systems that are either based on Datalog or provide a Datalog interpreter:

Free software/open source

Non-free software

• Datomic is a distributed database designed to enable scalable, flexible and intelligent applications, running on new cloud architectures. It uses Datalog as the query language.
• FoundationDB provides a free-of-charge database binding for pyDatalog, with a tutorial on its use.^[41]
• Leapsight Semantic Dataspace (LSD) is a distributed deductive database that offers high availability, fault tolerance, operational simplicity, and scalability. LSD uses Leaplog (a Datalog implementation) for querying and reasoning and was create by Leapsight.^[42]
• LogicBlox, a commercial implementation of Datalog used for web-based retail planning and insurance applications.
• Profium Sense is a native RDF compliant graph database written in Java. It provides Datalog evaluation support of user defined rules.
• .QL, a commercial object-oriented variant of Datalog created by Semmle for analyzing source code to detect security vulnerabilities.^[43]
• SecPAL a security policy language developed by Microsoft Research.^[44]
• Stardog is a graph database, implemented in Java. It provides support for RDF and all OWL 2 profiles providing extensive reasoning capabilities, including datalog evaluation.
• StrixDB: a commercial RDF graph store, SPARQL compliant with Lua API and Datalog inference capabilities. Could be used as httpd (Apache HTTP Server) module or standalone (although beta versions are under the Perl Artistic License 2.0).

See also

• Answer set programming
• Conjunctive query
• DLV
• Flix
• SWRL
• Tuple-generating dependency (TGD), a language for integrity constraints on relational databases with a similar syntax to Datalog

References

Bibliography

Further reading

• Grädel, Erich; Kolaitis, Phokion G.; Libkin, Leonid; Maarten, Marx; Spencer, Joel; Vardi, Moshe Y.; Venema, Yde; Weinstein, Scott (2007), Finite model theory and its applications, Texts in Theoretical Computer Science. An EATCS Series, Berlin: Springer-Verlag, ISBN 978-3-540-00428-8, Zbl 1133.03001