2015 International Conference on Computational Science and Computational Intelligence

Deductive Graph Database – Datalog in Action

Kornelije Rabuzin
Faculty of organization and informatics
University of Zagreb
Varazdin, Croatia
kornelije.rabuzin@foi.hr

Abstract—In recent years many NoSQL systems, including
graph databases, have become available. For large amounts of
interconnected data, these systems represent a good choice.
Deductive databases have been used in order to deduce new
pieces of information based on a database that containes large
amounts of data. But it is important to keep in mind that such
databases were mostly relational, i.e., relations were used to store
data upon which deductive mechanisms were used. In this paper,
deductive graph databases are proposed. In deductive graph
databases, data are stored in a graph database, and Datalog is
used for reasoning purposes on a relational representation of a
graph database.
Keywords—databases, SQL, NoSQL, graph databases, Datalog
I. INTRODUCTION
The relational data model has been widely used in the past
40 years. Many databases were implemented in order to store
large amounts of important data. As it turns out, Dr. Codd’s
vision to store data into relations turned out to be crucial and,
because of its ideal properties, the relational data model has
survived. Although the term “relation” is used in the theory,
users that use databases on a daily basis usually claim that a
database is, in fact, a set of tables. In order to implement a
database, certain database management systems (DBMS) are
required. The rich query interface (Structured Query Language
– SQL) that DBMS supports can be used to work with
databases. The ability to store and efficiently manage large
amounts of data has turned database management systems into
significant parts of many applications and information systems
that were developed over the time.
SQL is a standardized language that is used to work with
databases. All database management system vendors support
SQL which is declarative and typically, not complex. However,
sometimes queries do get quite complex. Furthermore,
different databases management systems do not support all the
statements in the same form and some differences may exist.
For more information on SQL, see [8] and [9].
• Document oriented databases
• Column oriented databases
• Key value databases
• Graph databases
Graph databases store information in nodes and
relationships. Each node does not have to contain the same
number of properties (attributes) and the same applies for
relationships between the nodes. For large amounts of
interconnected data graph databases represent a good choice.
They are especially suitable for social network analysis. In the
next chapter a small graph database is implemented (Neo4j
system is used) and more about graph databases will be
discussed. For additional information on graph databases see
[6]. In this paper, we primarily discuss graph databases (other
types are not discussed).
A deductive database uses rules to produce new pieces of
knowledge based on facts, which are stored in the database.
The next definition can be found in [11]: “A deductive DBD is
a triple D = (F, DR, IC), where F is a finite set of ground facts,
DR a finite set of deductive rules, and IC a finite set of
integrity constraints. The set F of facts is called the extensional
part of the DB (EDB), and the sets DR and IC together form
the so-called intensional part (IDB)”. A small example is
borrowed from [11]:
Facts
Father(John, Tony)
Mother(Mary, Bob)
Father(Peter, Mary)
Deductive Rules
Parent(x,y) ←Father(x,y)

But, in recent years, the NoSQL movement has become Parent(x,y) ← Mother(x,y)
popular. Namely, the relational data model is starting to reveal
its weaknesses, and, for some problems, new solutions have to GrandMother(x,y) ← Mother(x,z) ∧ Parent(z,y)
be found. The amounts of data that relational databases have to
store today are beyond their capabilities. Furthermore, a fixed Ancestor(x,y) ← Parent(x,y)
database schema is no longer an option. Because of this, many Ancestor(x,y) ← Parent(x,z) ∧ Ancestor(z,y)
NoSQL systems have been developed, and, generally speaking,
we distinguish: Nondirect-anc(x,y) ← Ancestor(x,y) ∧ ¬Parent(x,y)

978-1-4673-9795-7/15 $31.00 © 2015 IEEE 114

DOI 10.1109/CSCI.2015.60
 Integrity Constraints
IC1(x) ← Parent(x,x)
IC2(x) ← Father(x,y) ∧ Mother(x,z)
Thus, there are three facts and several rules used to define
different relationships (parent, grandmother, etc.). Two
integrity constraints prevent someone from being parent of his
self and preventing a person from being both mother and father
at the same time. For more information on deductive databases
see [11] or [14].
However, some things that initially occurred in deductive
databases are used in SQL today: for example, recursive
queries. Some books that cover databases in general are [1],
[2], [3], [5] and [12]; other book are available as well.
In the next section if this paper, graph databases are
defined. Then the Deductive Graph Database is presented and a
few Datalog queries are written. Afterward, the discussion is
Figure 1. Graph database
given and the conclusion is presented.
This example stores data about courses and their
II. GRAPH DATABASES prerequisites. To list courses and their prerequisites (first
level), it is enough to read the graph database. Cypher is used
Unlike relational databases, which store data in tables, as a language to read the data from the database. MATCH
graph databases use nodes and relationships between nodes. clause is used to start the query; it finds two courses that are
Storing data in such a way has certain benefits and it is more connected by means of a relationship, which is called PREREQ
natural for large amounts of interconnected data (for example, and then their names are returned in the result:
social network analysis). Thus, one cannot say that graph
databases are always better or that relational databases are MATCH (n:Course)-[:PREREQ]->(m:Course)
always better; it depends on one’s needs.
RETURN n.name, m.name
Nodes and relationships have properties. In the next
n.name m.name
section, we define a small graph database (the Neo4j system is
used for implementation purposes): Mathematics Programming I
CREATE (p1:Course {name: "Mathematics", ects: 7}), Mathematics Databases I
(p2:Course {name: "Informatics"}), Informatics Databases I
(p3:Course {name: "Programming I", ects: 7}), Databases I Databases II
(p4:Course {name: "Databases I"}), Databases II Data warehouses I
(p5:Course {name: "Databases II", ects: 6}),
(p6:Course {name: "Data warehouses I", ects: 5}), On the second level (as well as on any other level), it is
enough to reread the graph database. Now we are looking for
(p1)-[:PREREQ]->(p3),
three nodes and two relationships between them:
(p1)-[:PREREQ]->(p4),
MATCH (n:Course)-[:PREREQ]->(m:Course)-
(p2)-[:PREREQ]->(p4), [:PREREQ]->(o:Course)
(p4)-[:PREREQ]->(p5), RETURN n.name, o.name
(p5)-[:PREREQ]->(p6) n.name o.name
Mathematics Databases II
The visual interpretation of the database defined above is Informatics Databases II
shown below:
Databases I Data warehouses I

Now we are looking for four nodes and three relationships

between them:

115
 MATCH (n:Course)-[:PREREQ]->(m:Course)-
[:PREREQ]->(o:Course)-[:PREREQ]->(p:Course)
RETURN n.name, p.name
n.name p.name
Mathematics Data warehouses I
Informatics Data warehouses I
The first problem is that no recursion is supported in Neo4j
and we have the same problem as in SQL before the recursion
was added into the SQL standard. In order to merge all the
queries (listed above) and to find all courses and their
prerequisites, we should use the UNION clause (the result is
obvious):
MATCH (n:Course)-[:PREREQ]->(m:Course)
RETURN n.name AS c, m.name AS p
UNION
MATCH (n:Course)-[:PREREQ]->(m:Course)-
[:PREREQ]->(o:Course)
RETURN n.name AS c, o.name AS p
UNION
MATCH (n:Course)-[:PREREQ]->(m:Course)-
[:PREREQ]->(o:Course)-[:PREREQ]->(p:Course)
RETURN n.name AS c, p.name AS p
Recursive queries are supported in Datalog (deductive
databases), however, and we could use them on a graph
database in order to more easily find courses and their
prerequisites. Deductive databases also provide views. One can
define a view; in this way, queries may be posed much easier.
Furthermore, hypothetical queries are supported in Datalog as
well. Because we see that Cypher has certain problems while
querying data, in the next section deductive graph databases are
defined. It is also shown how Datalog can be used to work with
data.
III. DEDUCTIVE GRAPH DATABASE
As previously noted, deductive databases use rules to
produce new pieces of information based on the facts that are
stored in the database. The definition was given above; thus,
we know what components one such database should contain.
When one talks about graph databases, facts are stored in nodes
and relationships.
In normal deductive databases, facts are stored in tables.
Thus, for now one can say that this is a crucial distinction. In
order to be able to use Datalog on graph databases, facts that
are stored as nodes and relationships have to be stored in a
more suitable form in order to enter new pieces of information.
So, let us transform the graph database into a set of facts so that
Datalog rules could be utilized. Nodes can be translated easily
(for each node a new fact is added):
116
course(mathematics, 7).
course(informatics, null).
course('programming I', 7).
course('databases I', null).
course('databases II', 6).
course('data warehouses I', 5).
However, one has to keep in mind that nodes do not have to
have the same properties. Here, we see that not all courses have
the number of ECTS points and, because of that, null is used.
Relationships are stored as facts as well:
prereq(mathematics, 'programming I').
prereq(mathematics, 'databases I').
prereq(informatics, 'databases I').
prereq('databases I', 'databases II').
prereq('databases II', 'data warehouses I').
Regarding the translation, one may ask why perform the
translation at all? But the answer may be surprising. Namely,
graph databases use different methods to store data [6]:
“Some graph databases use native graph storage that is
optimized and designed for storing and managing graphs. Not
all graph database technologies use native graph storage
however. Some serialize the graph data into a relational
database, an object-oriented database, or some other general-
purpose data store.”
Thus, we see that the underlying storage model can rely on
relational databases as well as on some other types, but this
underpins the idea of translating the graph database into a set of
facts that can be stored in tables in order to use Datalog on such
a database. For some graph databases, this may be a native
solution. Now, when we have the set of facts, we can add two
rules:
comes_before(X,Y):- prereq(X,Y).
comes_before(X,Y):- prereq(X,Z), comes_before(Z,Y).
Course X comes before the course Y if X is prerequisite for
Y, or if it is a prerequisite for Z and Z comes before Y. For
testing purposes, the Datalog Educational System (DES) was
used:
DES> comes_before(X,Y).
{
comes_before('databases I','data warehouses I'),
comes_before('databases I','databases II'),
comes_before('databases II','data warehouses I'),
comes_before(informatics,'data warehouses I'),
 comes_before(informatics,'databases I'),
comes_before(informatics,'databases II'),
comes_before(mathematics,'data warehouses I'),
comes_before(mathematics,'databases I'),
comes_before(mathematics,'databases II'),
comes_before(mathematics,'programming I')
}
Info: 10 tuples computed.
We see that Datalog rules (and recursion) can be used to
determine courses and their prerequisites. In Cypher, one has to
use the UNION clause (as it was shown above), and this is
something that people were doing in SQL a decade ago. So, for
now, Datalog can be used to solve the problems, as it was used
to solve the problems that SQL had before the recursion was
supported.
Using Datalog has other benefits as well. Let us look at the
following rule:
tough(X):-course(X,Y), Y>6.
This is, in fact, a rule that is added to the database and
executed as a query. Such rules are called views. As a result,
we obtain all the courses that have more than six ECTS points,
which are considered to be tough:
DES> tough(A).
{
tough(mathematics),
tough('programming I')
} In the future, one should look at how to automatically
Info: 2 tuples computed.
Thus, it is easy to use views in Datalog. More importantly,
views are not supported in Neo4j as such.
Now let us assume that our graph database contains
information about people and relationship, KNOWS (“knows”
means that person A knows person B). We could translate that
database in the following set of facts:
person(tom).
person(john).
person(mary).
person(peter).
knows(tom,john).
knows(john,mary).
For example, this is a well-known fact; if A is a friend of B,
and B is a friend of C, in the future it is most likely that A will
117
become a friend of C as well. In Datalog, this is easy to
express:
fknow(A,C):- knows(A,B),knows(B,C).
DES> fknow(A,B).
{
fknow(tom,mary)
}
Info: 1 tuple computed.
We see that it is likely that Tom and Mary will become
friends in the future.
But one could also use hypothetical queries for such
purposes. If A knew B, is it likely that A becomes a friend of
C?
Interesting papers that deal with queries in graph databases
are [4], [10] and [13]. This research was inspired by [7] and
[15].
CONCLUSION
Deductive databases were used in the past; some methods
used in deductive databases were so interesting that they even
found a way into other fields as well. For example, recursive
queries in SQL have roots in deductive databases. In this paper,
it is shown how recursion can be used on a graph database
(perhaps one day graph databases will support the recursion) as
well as views and hypothetical queries.
In this paper, the idea of deductive graph database has been
presented. On a few examples, it was shown how Datalog
could be used to work with data. It was shown that views are
interesting as well as recursion which simplifies the process of
posing queries.
transform nodes and relationships into a form upon which
Datalog could be used directly. Furthermore, materialized
views could be considered as well as hypothetical queries that
were only mentioned in the paper.
REFERENCES
[1] C. Date, An Introduction to Database Systems. Boston, USA: Addison-
Wesley, 2004.
[2] C. Date, Database Design and Relational Theory: Normal Forms and All
That Jazz. Sebastopol, USA: O’Reilly Media, 2012.
[3] E. Redmond and J. R. Wilson, Seven Databases In Seven Weeks. Dallas,
USA: Pragmatic Programmers, 2012.
[4] G. Butler, L. Chen, X. Chen, And L. Xu, Diagrammatic Queries and
Graph Databases, Workshop on Managing and Integrating Biochemical
Data, Retrieved March 15, 2015, from
http://users.encs.concordia.ca/~gregb/home/PDF/eml-digrammatic.pdf
[5] H. Garcia-Molina, J. Ullman and J. Widom, Database Systems: The
Complete Book. London, UK: Pearson Education, 2009.
[6] I. Robinson, J. Webber, E. Eifrem, Graph Databases. Sebastopol, USA:
O'Reilly Media, 2013.
[7] K. Rabuzin, Deductive Data Warehouses, International journal of data
warehousing and mininig, vol. 10(1), 2014.
[8] K. Rabuzin, SQL – napredne teme, akovec, Croatia: Zrinski, 2014.
[9] K. Rabuzin, Uvod u SQL, akovec, Croatia: Zrinski, 2011.
[10] K. T. Yar and K. M. L. Tun, Predictive Analysis of Personnel
Relationship in Graph Database, International Journal of Engineering
Research & Technology, vol. 3(9), 2014. Retrieved March 12, 2015,
from http://www.ijert.org/view-pdf/11117/predictive-analysis-of-
personnel-relationship-in-graph-database
[11] M. Piattini and O. Diaz, Advanced Database Technology and Design.
Boston, USA: Artech House, 2000.
[12] N. W. Paton, Active Rules in Database Systems. New York, USA:
Springer, 1998.
118
[13] P. T. Wood, Graph Views and Recursive Query Languages, BNCOD,
1990, pp. 124-141.
[14] R. M. Colomb, Deductive Databases and Their Applications. London,
UK: Taylor & Francis, 2005.
[15] V. Nigam, L. Jia, A. Wang, B. T. Loo and A. Scedrov, An Operational
Semantics for Network Datalog, Retrieved March 10, 2015, from
https://www.andrew.cmu.edu/user/liminjia/research/papers/ndlogsemans
-tr.pdf