Paradigm  Logic, Declarative 

Family  Prolog 
First appeared  1986 
Typing discipline  Weak 
Dialects  
Datomic, .QL, Soufflé, XTDB, etc.  
Influenced by  
Prolog 
Datalog is a declarative logic programming language. While it is syntactically a subset of Prolog, Datalog generally uses a bottomup rather than topdown evaluation model. This difference yields significantly different behavior and properties from Prolog. It is often used as a query language for deductive databases. Datalog has been applied to problems in data integration, networking, program analysis, and more.
A Datalog program consists of facts, which are statements that are held to be true, and rules, which say how to deduce new facts from known facts. For example, here are two facts that mean xerces is a parent of brooke and brooke is a parent of damocles:
parent(xerces, brooke).
parent(brooke, damocles).
The names are written in lowercase because strings beginning with an uppercase letter stand for variables. Here are two rules:
ancestor(X, Y) : parent(X, Y).
ancestor(X, Y) : parent(X, Z), ancestor(Z, Y).
The :
symbol is read as "if", and the comma is read "and", so these rules mean:
The meaning of a program is defined to be the set of all of the facts that can be deduced using the initial facts and the rules. This program's meaning is given by the following facts:
parent(xerces, brooke).
parent(brooke, damocles).
ancestor(xerces, brooke).
ancestor(brooke, damocles).
ancestor(xerces, damocles).
Some Datalog implementations don't deduce all possible facts, but instead answer queries:
? ancestor(xerces, X).
This query asks: Who are all the X that xerces is an ancestor of? For this example, it would return brooke and damocles.
The nonrecursive subset of Datalog is closely related to query languages for relational databases, such as SQL. The following table maps between Datalog, relational algebra, and SQL concepts:
Datalog  Relational algebra  SQL 

Relation  Relation  Table 
Fact  Tuple  Row 
Rule  n/a  Materialized view 
Query  Select  Query 
More formally, nonrecursive Datalog corresponds precisely to unions of conjunctive queries, or equivalently, negationfree relational algebra.
Schematic translation from nonrecursive Datalog into SQL


s(x, y).
t(y).
r(A, B) : s(A, B), t(B).
CREATE TABLE s (
z0 TEXT NONNULL,
z1 TEXT NONNULL,
PRIMARY KEY (z0, z1)
);
CREATE TABLE t (
z0 TEXT NONNULL PRIMARY KEY
);
INSERT INTO s VALUES ('x', 'y');
INSERT INTO t VALUES ('y');
CREATE VIEW r AS
SELECT s.z0, s.z1
FROM s, t
WHERE s.z1 = t.z0;

A Datalog program consists of a list of rules (Horn clauses).^{[1]} 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 BNF grammar expresses the structure of a Datalog program:
<program> ::= <rule> <program>  ""
<rule> ::= <atom> ":" <atomlist> "."
<atom> ::= <relation> "(" <termlist> ")"
<atomlist> ::= <atom>  <atom> "," <atomlist>  ""
<term> ::= <constant>  <variable>
<termlist> ::= <term>  <term> "," <termlist>  ""
Atoms are also referred to as literals. The atom to the left of the :
symbol is called the head of the rule; the atoms to the right are the body. Every Datalog program must satisfy the condition that every variable that appears in the head of a rule also appears in the body (this condition is sometimes called the range restriction).^{[1]}^{[2]}
There are two common conventions for variable names: capitalizing variables, or prefixing them with a question mark ?
.^{[3]}
Note that under this definition, Datalog does not include negation nor aggregates; see § Extensions for more information about those constructs.
Rules with empty bodies are called facts. For example, the following rule is a fact:
r(x) : .
The set of facts is called the extensional database or EDB of the Datalog program. The set of tuples computed by evaluating the Datalog program is called the intensional database or IDB.
Many implementations of logic programming extend the above grammar to allow writing facts without the :
, like so:
r(x).
Some also allow writing 0ary relations without parentheses, like so:
p : q.
These are merely abbreviations (syntactic sugar); they have no impact on the semantics of the program.
Main article: Syntax and semantics of logic programming 
Herbrand universe, base, and model of a Datalog program 

Program: edge(x, y).
edge(y, z).
path(A, B) :
edge(A, B).
path(A, C) :
path(A, B),
edge(B, C).

Herbrand universe: x , y , z 
Herbrand base: edge(x, x) , edge(x, y) , ..., edge(z, z) , path(x, x) , ..., path(z, z) 
Herbrand model: edge(x, y) , edge(y, z) , path(x, y) , path(y, z) , path(x, z) 
There are three widelyused approaches to the semantics of Datalog programs: modeltheoretic, fixedpoint, and prooftheoretic. These three approaches can be proven equivalent.^{[4]}
An atom is called ground if none of its subterms are variables. Intuitively, each of the semantics define the meaning of a program to be the set of all ground atoms that can be deduced from the rules of the program, starting from the facts.
A rule is called ground if all of its atoms (head and body) are ground. A ground rule R_{1} is a ground instance of another rule R_{2} if R_{1} is the result of a substitution of constants for all the variables in R_{2}. The Herbrand base of a Datalog program is the set of all ground atoms that can be made with the constants appearing in the program. The Herbrand model of a Datalog program is the smallest subset of the Herbrand base such that, for each ground instance of each rule in the program, if the atoms in the body of the rule are in the set, then so is the head.^{[5]} The modeltheoretic semantics define the minimal Herbrand model to be the meaning of the program.
Let I be the power set of the Herbrand base of a program P. The immediate consequence operator for P is a map T from I to I that adds all of the new ground atoms that can be derived from the rules of the program in a single step. The least fixed point semantics define the least fixed point of T to be the meaning of the program; this coincides with the minimal Herbrand model.^{[6]}
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. This algorithm is called naïve evaluation.
The prooftheoretic semantics defines the meaning of a Datalog program to be the set of facts with corresponding proof trees. Intuitively, a proof tree shows how to derive a fact from the facts and rules of a program.
One might be interested in knowing whether or not a particular ground atom appears in the minimal Herbrand model of a Datalog program, perhaps without caring much about the rest of the model. A topdown reading of the proof trees described above suggests an algorithm for computing the results of such queries. This reading informs the SLD resolution algorithm, which forms the basis for the evaluation of Prolog.
There are many different ways to evaluate a Datalog program, with different performance characteristics.
Bottomup 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 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.^{[7]}
Seminaïve evaluation is a bottomup evaluation strategy that can be asymptotically faster than naïve evaluation.^{[8]}
Naïve and seminaïve evaluation both evaluate recursive Datalog rules by repeatedly applying them to a set of known facts until a fixed point is reached. In each iteration, rules are only run for "one step", i.e., nonrecursively. As mentioned above, each nonrecursive Datalog rule corresponds precisely to a conjunctive query. Therefore, many of the techniques from database theory used to speed up conjunctive queries are applicable to bottomup evaluation of Datalog, such as
Many such techniques are implemented in modern bottomup Datalog engines such as Soufflé. Some Datalog engines integrate SQL databases directly.^{[13]}
Bottomup evaluation of Datalog is also amenable to parallelization. Parallel Datalog engines are generally divided into two paradigms:
SLD resolution is sound and complete for Datalog programs.
Topdown evaluation strategies begin with a query or goal. Bottomup evaluation strategies can answer queries by computing the entire minimal model and matching the query against it, but this can be inefficient if the answer only depends on a small subset of the entire model. The magic sets algorithm takes a Datalog program and a query, and produces a more efficient program that computes the same answer to the query while still using bottomup evaluation.^{[19]} A variant of the magic sets algorithm has been shown to produce programs that, when evaluated using seminaïve evaluation, are as efficient as topdown evaluation.^{[20]}
The decision problem formulation of Datalog evaluation is as follows: Given a Datalog program P split into a set of facts (EDB) E and a set of rules R, and an interpretation A, is A in the minimal model of P? In this formulation, there are three variations of the computational complexity of evaluating Datalog programs:^{[21]}
With respect to data complexity, the decision problem for Datalog is Pcomplete. With respect to program complexity, the decision problem is EXPTIMEcomplete. In particular, evaluating Datalog programs always terminates; Datalog is not Turingcomplete.
Some extensions to Datalog do not preserve these complexity bounds. Extensions implemented in some Datalog engines Datalog engines, such as algebraic data types, can even make the resulting language Turingcomplete.
Several extensions have been made to Datalog, e.g., to support negation, aggregate functions, inequalities, to allow objectoriented programming, or to allow disjunctions as heads of clauses. These extensions have significant impacts on the language's semantics and on the implementation of a corresponding interpreter.
Datalog is a syntactic subset of Prolog, disjunctive Datalog, answer set programming, DatalogZ, and constraint logic programming. When evaluated as an answer set program, a Datalog program yields a single answer set, which is exactly its minimal model.^{[22]}
Many implementations of Datalog extend Datalog with additional features; see § Datalog engines for more information.
Datalog can be extended to support aggregate functions.^{[23]}
Notable Datalog engines that implement aggregation include:
Further information: Syntax and semantics of logic programming § Extending Datalog with negation 
Adding negation to Datalog complicates its semantics, leading to whole new languages and strategies for evaluation. For example, the language that results from adding negation with the stable model semantics is exactly answer set programming.
Stratified negation can be added to Datalog while retaining its modeltheoretic and fixed point semantics. Notable Datalog engines that implement stratified negation include:
Unlike in Prolog, statements of a Datalog program can be stated in any order. Datalog does not have Prolog's cut operator. This makes Datalog a fully declarative language.
In contrast to Prolog, Datalog
p(x, y)
is admissible but not p(f(x), y)
,This article deals primarily with Datalog without negation (see also Syntax and semantics of logic programming § Extending Datalog with negation). However, stratified negation is a common addition to Datalog; the following list contrasts Prolog with Datalog with stratified negation. Datalog with stratified negation
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,^{[27]} but it can be made decidable by restricting to some fragments of Datalog.
Further information: Draft:List of Datalog engines 
Systems that implement languages inspired by Datalog, whether compilers, interpreters, libraries, or embedded DSLs, are referred to as Datalog engines. Datalog engines often implement extensions of Datalog, extending it with additional data types, foreign function interfaces, or support for userdefined lattices. Such extensions may allow for writing nonterminating or otherwise illdefined programs.
Datalog is quite limited in its expressivity. It is not Turingcomplete, and doesn't include basic data types such as integers or strings. This parsimony is appealing from a theoretical standpoint, but it means Datalog per se is rarely used as a programming language or knowledge representation language.^{[28]} Most Datalog engines implement substantial extensions of Datalog. However, Datalog has a strong influence on such implementations, and many authors don't bother to distinguish them from Datalog as presented in this article. Accordingly, the applications discussed in this section include applications of realistic implementations of Datalogbased languages.
Datalog has been applied to problems in data integration, information extraction, networking, security, cloud computing and machine learning.^{[29]}^{[30]} Google has developed an extension to Datalog for big data processing.^{[31]}
Datalog has seen application in static program analysis.^{[32]} The Soufflé dialect has been used to write pointer analyses for Java and a controlflow analysis for Scheme.^{[33]}^{[34]} Datalog has been integrated with SMT solvers to make it easier to write certain static analyses.^{[35]} The Flix dialect is also suited to writing static program analyses.^{[36]}
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.^{[37]}
The origins of Datalog date back to the beginning of logic programming, but it became prominent as a separate area around 1977 when Hervé Gallaire and Jack Minker organized a workshop on logic and databases.^{[38]} David Maier is credited with coining the term Datalog.^{[39]}