Comparing Graql to SQL — Part 1/2

Since the 1970s, SQL has been the de facto language to work with databases. As a declarative language, it’s straightforward to write queries and build powerful applications. However, relational databases struggle when working with interconnected and complex data. When working with such data in SQL, challenges arise especially in the modelling and querying of the data.

Graql is the query language used in Grakn. Just as SQL is the standard query language in relational databases, Graql is Grakn’s query language. Both SQL and Graql are declarative query languages that abstract away lower-level operations. Both are:

• Languages that attempt be readable and understandable
• Languages that attempt to enable asking questions at a higher-level
• Languages where the system figures out how to do lower-level operations

In practical terms, this means the languages become accessible to groups of people who would have otherwise not been able to access them. In this article, while we look at specific common concepts, we focus on comparing and exploring the differences between the two languages.

The Origin of SQL and the Relational Model

In 1970, a paper was published by an Oxford-educated mathematician called Edgar Codd, known as “Ted”, and in it, he introduced two languages — a relational algebra and a relational calculus to express extremely complex queries. When they came out, they were considered to be a strange kind of mathematical notation. To build these ideas out into a database management system, Ted created a research group called System R, based out of the IBM research facilities in San Jose.

Back then, databases were mainly based on navigational, network and hierarchical models, where we needed to know the physical data layer before we could write a navigational plan to describe our query. Ted, however, saw the inherent complexity in this and wanted to make it easier to write database queries.

However, as Ted’s ideas were based on mathematical notation and mathematical symbolism, they were difficult to understand and not very accessible to most people, so two System R members addressed this issue by creating a simple query language — SEQL. As this new language was based exclusively on English words, this became the breakthrough that made it so much easier for people to understand the simplicity of Ted’s ideas.

By the late 1970s, relational databases had grown in popularity, and the world came to accept just how superior SQL and the relational model were to its predecessors. The story since then is well known — relational databases have become the standard for building software as the world was ushered into the digital revolution.

The Essence of SQL and Graql

In understanding Graql, it’s useful to look at the underlying ideas that created SQL, as they are conceptually closely related. The essence of both Graql and SQL can be summarised as such:

1. A language that can be read and understood intuitively. We say a language fulfils these criteria when it appears simple, maintainable and has a degree of similarity to natural text.
2. A language that enables asking questions at a higher-level. Here we refer to a language that allows the user to describe operations at a new and higher semantic level.
3. A language where the system figures out how to do lower-level operations. As the user describes higher-level operations, the system takes care of operations without the user having to think of them.

In this sense, both SQL and Graql are languages that abstract away lower-level operations. In practical terms, this means the languages become accessible to groups of people who would have otherwise not been able to access them. This means they become enabled to create value, while those who could already use them can now do things much faster. A similar thing can be said about Python, for example, a high level programming language that has enabled millions of programmers to build software without having to worry about lower-level operations that are abstracted away.

Modelling and Defining Schema

First, let’s look at how data modelling compares between SQL and Graql. We use the Entity Relationship Diagram (ER Diagram) as it’s the most common modelling tool in use. A basic model is composed of entity types and the relationships that can exist between them. Below is an example ER Diagram. We call this the conceptual model.

ER Diagram Example. Squares are entities, diamonds are relations and circles are attributes.

Modelling in SQL

If we are implementing this model in a relational database, we first go through a normalisation process. We begin at First Normal Form (1NF) and by looking for things such as functional dependencies and transitive dependencies, we eventually get to our desired Third Normal Form (3NF).

Normalising from 1NF to 3NF.

After this normalisation process, we get to our logical model in 3NF and implement it in a relational database. We have gone from our conceptual model (ER diagram) to the logical model (3NF), without ever needing to go down to the physical level of the database. This was precisely the breakthrough that the relational model brought us — abstracting away the physical level. We call this the physical independence of data.

SQL gives us the Physical Independence of Data.

Modelling in Graql

Now let’s look at how this compares to Graql. We can map any ER Diagram directly to how we implement it in Graql, which means we don’t need to go through a normalisation process. Below we can see how a specific part of the earlier ER Diagram is modelled. We avoid the need to do any normalisation, as Graql enables us to create a direct mapping of the ER Diagram with entities, relations, attributes and roles to how we are implementing it later in code. This is different to SQL, where we need to impose a tabular structure over our model as a logical layer (as described above).

ER diagram (left) to Graql model (right).

This means we entirely skip out the normalisation process required in SQL, and we keep working at the conceptual model. In other words, Graql abstracts away both the logical and physical model. In this sense, where SQL gave us the physical independence of data, Graql gives us the logical independence of data.

By modelling at the conceptual level, Graql gives us an abstraction over the logical model.

Defining Schemas in SQL and Graql

Now let’s look at some real data. Anyone who has studied SQL is probably familiar with the Northwind dataset. It contains sales data for Northwind Traders, a fictitious specialty foods export-import company.

The Northwind schema.

How do we go about defining the products table shown above in Graql and SQL? Below we see the Graql syntax that defines the product entity, and the corresponding relation. This also shows the SQL statements that create the new table and the corresponding attributes.

define 
product sub entity, 
  key product-id, 
  has product-name, 
  has quantity-per-unit, 
  plays product-assignment; 
product-id sub attribute, datatype double; 
product-name sub attribute, datatype string; 
quantity-per-unit sub attribute, datatype double;
assignment sub relation, 
  relates assigned-category, 
  relates product-assignment;

Graql

CREATE TABLE products (
	  product_id smallint NOT NULL PRIMARY KEY,
	  product_name character varying(40) NOT NULL,
	  category_id smallint,
	  quantity_per_unit character varying(20),
	  FOREIGN KEY (category_id) REFERENCES categories
);

SQL

A few important points:

• Here we can see that the SQL table has three attributes, each with their own datatype, which we can define in Graql as well. One of these attributes is a primary key, which we define in Graql using the key keyword.
• In the SQL statement, there is also a foreign key, which depending on our model, we model as a related relation in Graql. We do this by connecting the product entity to the assignment relation using the role product-assignment.
• In Graql, there is no concept of null values. If a concept does not have an attribute, it really does not have it. This is because in a graph context a null attribute is simply omitted from the graph.
• Finally, an important point is that in the Graql model, attributes are first-class citizens, unlike in SQL.

To summarise:

• Modeling an ER diagram into SQL involves a normalisation process from 1NF to 3NF
• The ER diagram maps naturally to Graql, and there is no need to perform any kind of normalisation

In Part 2 (coming soon!), we look at how to read/write data, and how we should model at a higher-level in Graql leveraging the Hypergraph and Automated Reasoning.