Relational Knowledge Graph is a term that is coming to be known as a database that can be viewed as a Relational Database and/or a Graph Database, akin to muli-model databases. FactEngine sees all databases as Relational Knowledge Graphs.

The merger of graph databases and relational databases is becoming more pronounced in the industry and terminology is changing to suit the environment.

The presence of the Property Graph Schema Working Group signals the maturation of the graph database market to bring features commonly found in relational databases to graph databases and knowledge graphs, for example.

The group, an amalgam of researchers and graph database vendors, has coalesced on the realisation that extant graph databases lack the finesse of the formality underpinning relational databases and a conscious effort to bring a 21st century phenomenon into the 21st century. An internet search of the group’s name returns a manifesto of sorts and supports the same.

Albeit that you would likely not hear the group tout the groups impetus as being the lead in standards in the relational database sphere, FactEngine suspects that like a scene out of Animal Farm, the grand announcement will be that ‘now that we have these standards, some databases are more equal than others’.

Adopting a vision of Relational Knowledge Graphs provides a different view altogether, that any database can be viewed as a graph database, even a relational database, and if you adopt an architecture that supports that view then you can have the best of both worlds.

Graph database vendors have long touted that graph databases are speedier than relational databases in certain queries. FactEngine finds this claim dubious when you consider Microsoft touting that it has the fastest database in the world, SQL Server, an otherwise relational database supporting graph structures/queries.

At a theoretical level, the claim that the way data is stored at the hardware level in many graph databases expediting speedier graph queries is also dubious. For example, even if a relational database is stored at the hardware level as a set of column delimited fixed structure rectangular/table looking structures, there is nothing to stop that hardware level data being loaded into memory as a graph structure and queries run against the in-memory graph structure, all things pagination aside and where a graph database that needs to revert queries to data still on disk currently suffer the same problem…getting the graph structure into memory in a graph fashion to perform these speedy queries.

So what holds relational databases back from adopting this architecture and beating graph databases at their own game? Is there really a conceptual difference between graph databases and relational databases at the metamodel level?

Enter Relational Knowledge Graphs

The metamodel of run-of-the-mill relational databases holds them back from graph queries of the same elegance of a run-of-the-mill graph database. For example, foreign key relationships lack natural language predicates that tell you such things as “Employee works for Company”, where Employee and Company are tables/nodes and where graph database vendors might have a structure that reads “Employee WORKS_FOR Company”.

As far back as 1985, ORACLE’s Richard Barker’s, “Case Method, Entity Relationship Modelling” allowed for this in the Entity Relationship Diagrams describing relational databases, but with the lack of a graph query language over relational databases, this was never (to my knowledge) actually implemented for query use at the metamodel level of relational databases because the query language of relational databases, Structure Query Language (SQL), never supported the use of natural language predicates in its syntax anyway.

Stylised Barker Entity Relationship Diagram with natural language predicates, Image by FactEngine.

Relational knowledge graphs are databases or architecture over databases where the database/s can be viewed as a graph database or a relational database.

We get an intuitive understanding of how this works when we consider an actual schema variously morphing between a classical relational view (Entity Relationship Diagram) and a graph view (Property Graph Schema):

Graph database proponents are oft heard to say “there is no such thing as a many-to-many table in a graph database” (as the PersonLikesFilm table above in the ERD view). This presupposes that the data of the otherwise relational database is not stored as a graph in-memory for query purposes, and discounts that ‘yes’ there kind of is in a graph database but the ‘many-to-many table data’ is often stored as a linked list (a flattened table) at the hardware level and conceptualised as a graph at the conceptual in-memory level.

The view also presupposes that there is no conceptual way of having both a many-to-many (or to many…again) relationship that also has effective edges. This is overcome by adopting the likes of object-role modeling:

Object-Role Model and its Property Graph Schema counterpart. Image by FactEngine.

Object-Role Model and its corresponding Property Graph Schema and Entity Relationship Diagram. Image by FactEngine.

And we arrive at our destination: A relational knowledge graph allows you to conceptualise your database as either a relational database or a graph database. The choice is yours.

This means you get to write SQL queries or graph queries over your database. The choice is yours.

“Well haven’t we already got this? Doesn’t the likes of SQL Server already cater for SQL and graph queries?”

The short answer is, mostly no, because all of the relational databases that incorporate graph features that add special table types to manage graph queries, ending up with a confused polyglot of a database likely to equally confuse anyone using it. I.e. Many relational database vendors still treat graphs as separate from table relationships.

How the concept of a relational knowledge graphs differs is that there is no need to adopt a different set of tables for graph queries over your otherwise relational database, you merely need to have a semantic layer over your existing database structure which caters for the writing of graph queries…and let the database management system worry about how those queries are handled over the underlying database structure.

Which is all to say, relational knowledge graphs could be equally called graph knowledge relations. I.e. Relational knowledge graphs do not presuppose how the data is stored at the hardware layer and where this-or-that database claims to have the fastest database in the world anyway, regardless of how they store data at the hardware level.

What are the advantages of a relational knowledge graph?

The primary advantages of a relational knowledge graph are that:

1. The hardware level implementation of your database need only be a consideration when deciding over what database to use for your project and its speed of query execution when that is a prerequisite;
2. At the conceptual level you get to choose how you picture your database; as a graph database or a relational database;
3. Natural language semantics is built into the semantic layer that operates over the database’s core metamodel, helping you to understand the model;
4. Depending on how you implement your relational knowledge graph, you get to choose the database you work with. Relational knowledge graphs can be database management system agnostic. I.e. Conceptually, you are not tied into one database technology or another when it comes to implementation. Relational knowledge graph vendors may limit you to one underlying database however;
5. Entities/node types can have a multi-column/property primary key, rather than just a single object-id or property as common on current graph databases; and
6. In the case of FactEngine, you can write controlled natural language queries over your database. FactEngine feels this will come to be standard on relational knowledge graphs;

"Relational Knowledge Graph" is a term that is likely to be on your radar in the near future by sheer weight of the new players involved in promoting the term.

Industry trends are heading to where graph databases are adopting structure and rigour of relational databases in a way that will invariably lead to a conceptual merger of relational database theory and graph database theory;

Relational knowledge graphs allow you to conceptually step away from how your database is stored at the hardware level; and relational knowledge graph, or graph knowledge relations adequately emphasise that the impetus is on knowledge added to the database by adopting a semantic layer that describes what data is stored rather than how it is stored.

All views expressed that of FactEngine. This article provided as news on the state of the art of database theory as part of FactEngine's Conceptual Modeling series.