What Is a Relational Knowledge Graph? | by Victor Morgante | Jun, 2022
Exploring the future of graph databases and knowledge graphs
If the term Relational Knowledge Graph is not on your radar, I suspect it soon will be. Bob Muglia, former CEO of Snowflake is now a board director of a startup that is promoting the new paradigm.
My earlier thinking of nomenclature gravitated towards introduction of the term graphational databases with my work at FactEngine, where I was looking for a term that adequately described the merger of graph and relational databases, beyond the term multi-model database.
Whichever way you look at it, the merger of graph databases and relational databases is becoming more pronounced and I believe the term relational knowledge graph will be here to stay.
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 the 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, I suspect 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’.
Relational Knowledge Graphs adopt 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. This claim is 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.
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 level.
The view also presupposes that there is not 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:
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.
Experienced players say quickly: “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 I have looked at have adopted adding special table types to manage graph queries, ending up with a confused polyglot of a database likely to equally confuse anyone using it. I wrote about this a couple of years ago. I.e. Many relational database vendors still treat graphs as separate from relationships.
How relational knowledge graphs differ 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. I wrote about that on Towards Data Science a little while back.
Which is all to say, relational knowledge graphs could be equally called graph knowledge relations, but it probably would not sound as cool with the current state of the knowledge graph hype cycle. 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:
- 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;
- At the conceptual level you get to choose how you picture your database; as a graph database or a relational database;
- Natural language semantics is built into the semantic layer that operates over the databases core metamodel, helping you to understand the model;
- 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;
- Entities/node types and can have a multi-column/property primary key, rather than just a single object-id or property as common on current graph databases; and
- In the case of FactEngine, you can write controlled natural language queries over your database. I feel this will come to be standard on relational knowledge graphs;
In summary
- 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 the relational databases and graph databases;
- 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.
Thanks for reading. As time permits I will write more on knowledge graphs, graph databases, semantic modelling and relational databases.
— — — — — — — — — — End — — — — — — — — —
Exploring the future of graph databases and knowledge graphs
If the term Relational Knowledge Graph is not on your radar, I suspect it soon will be. Bob Muglia, former CEO of Snowflake is now a board director of a startup that is promoting the new paradigm.
My earlier thinking of nomenclature gravitated towards introduction of the term graphational databases with my work at FactEngine, where I was looking for a term that adequately described the merger of graph and relational databases, beyond the term multi-model database.
Whichever way you look at it, the merger of graph databases and relational databases is becoming more pronounced and I believe the term relational knowledge graph will be here to stay.
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 the 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, I suspect 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’.
Relational Knowledge Graphs adopt 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. This claim is 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.
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 level.
The view also presupposes that there is not 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:
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.
Experienced players say quickly: “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 I have looked at have adopted adding special table types to manage graph queries, ending up with a confused polyglot of a database likely to equally confuse anyone using it. I wrote about this a couple of years ago. I.e. Many relational database vendors still treat graphs as separate from relationships.
How relational knowledge graphs differ 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. I wrote about that on Towards Data Science a little while back.
Which is all to say, relational knowledge graphs could be equally called graph knowledge relations, but it probably would not sound as cool with the current state of the knowledge graph hype cycle. 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:
- 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;
- At the conceptual level you get to choose how you picture your database; as a graph database or a relational database;
- Natural language semantics is built into the semantic layer that operates over the databases core metamodel, helping you to understand the model;
- 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;
- Entities/node types and can have a multi-column/property primary key, rather than just a single object-id or property as common on current graph databases; and
- In the case of FactEngine, you can write controlled natural language queries over your database. I feel this will come to be standard on relational knowledge graphs;
In summary
- 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 the relational databases and graph databases;
- 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.
Thanks for reading. As time permits I will write more on knowledge graphs, graph databases, semantic modelling and relational databases.
— — — — — — — — — — End — — — — — — — — —
Denial of responsibility! Techno Blender is an automatic aggregator of the all world’s media. In each content, the hyperlink to the primary source is specified. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials, please contact us by email – [email protected]. The content will be deleted within 24 hours.