Property Graph Schema and Entity Relationship Diagrams share the same MetaSchema/MetaModel
Graph Databases are essentially Relational Databases unless ‘native’
Graph Databases are often described as quite different from Relational Databases and better at managing relationships.
So, what are the facts?
The facts are that Graph Databases, depending on how they are built and operate under the hood, are only different in how they are built and operate but are conceptually exactly the same as a Relational Database.
I have had conversations along these lines at a high level in the industry, and when faced with “no…no…noes” I have quietly gone about my business and built the software to share a viewpoint.
The facts are very simple. Conceptually Property Graph Schemas (PGSs) and Entity Relationship Diagrams (ERDs) look quite different, however, to the initiated and better informed, they represent the same thing conceptually, and can be stored in the same MetaModel.
Depending on how an otherwise Graph Database is built, under the hood, they may handle some queries faster than this-or-that Relational Database. What we would like to look at is the metaschema of Graph Databases and Relational Databases and examine if they share the same metamodel.
What is needed is a pure and simple demonstration of the realities and the facts from a conceptual level, and to let others battle out which individual database is better at this-and-that, and let computer scientists who share a viewpoint share a reality.
So, let us do that.
The Science Say It, The Market Demands It
The International Standards Organisation (ISO) has published the ISO GQL Standard (ISO/IEC 39075:2024) which aims to bring a graph query language, stemming from the likes of Cypher and openCypher to all Relational Databases, so graph database proponents are saying it themselves. Relational Databases and Graph Databases are conceptually the same thing.
So, let this article also be where my business, FactEngine, stands on the matter, and as it will become, I feel, more evident as time goes by (ISO GQL only released in 2023) that Property Graph Schema and Entity Relationship Diagrams share the same conceptual metamodel, with only one minor difference.
Mapping a Morphism between Property Graph Schema and Entity Relationship Diagrams
Looking again closely at the opening image of this article, the animated gif below demonstrates a morphism between the Nodes/Vertexes of a Property Graph Schema to their corresponding Entity in an Entity Relationship Diagram, and a morphism between the Edge Types of the PGS and the corresponding relationships or table within the corresponding Entity Relationship Diagram.
The model itself represents a database to store Bookings for Seats to watch a Film for a Session at a Cinema and where the Booking is for a Person, and a Seat is in a Row in that Cinema, and within a named Section.
Those familiar with meta-modelling will realise that for the models (PGS and ERD) to exist in the first place, they need reside as data within a metamodel.
If you click on the image below to enlarge it, and notice what is going on, a few things happen:
- We view the metamodel storing the Entity Relationship Diagram;
- We change the language of interpretation of the ERD model to a Property Graph Schema interpretation; and
- Re-open the model and the software then presents the model as a Property Graph Schema, from the same metamodel.
There are three premises that allow this to happen:
- Foreign Key Relationships in the Entity-Relationship Diagram (ERD) become Edge Types in the Property Graph Schema view; and
- Many-to-Many Tables/Relationships in the ERD view become Edge Types in the Property Graph Schema view (except for those that fit in category 3); and
- Many-to-Many Tables (e.g. Session, above), become Node Types in the Property Graph Schema view, when they are referenced by other tables/node-types.
We demonstrate premises/rules 1 and 2 pictorially, below:
A Foreign Key Relationship becomes and Edge Type:
A Many-to-Many (join) Table becomes an Edge Type:
Notice that the Entity named, Session, is a many-to-many table between Film and Cinema, however it remains as a Node Type, rather than Edge Type in the Property Graph Schema view because it is referenced from the Booking Entity/Node-Type with an IS_FOR relationship.
Homomorphism approaching Isomorphism
When I say that a Property Graph Schema has the same metamodel as an Entity Relationship Diagram, this is true in this respect:
The metamodel of a Property Graph Schema is the same as an Entity Relationship Diagram to the extent that it is a homomorphism approaching an isomorphism.
A homomorphism is where two structures share a partial morphism. I.e. Not every point of structure is the same.
An isomorphism is where two structures are exactly the same. Each point of structure can be mapped to the other.
So, does that mean I am wrong in saying that a Property Graph Schema share the same metamodel as an Entity Relationship Diagram?
No. Because the Property Graph Schema metamodel has one (just one) difference to the metamodel of an Entity Relationship Diagram, otherwise Property Graph Schema share exactly the same metamodel structure as an Entity Relationship Diagram.
So, what is that one point of difference?
In a Property Graph Schema, we have choice
Property Graph Schemas come with a choice. We can either create an Edge Type/Relationship with Properties, or create a Node Type with those Properties having to Relationships to compensate for the otherwise one relationship.
Let us have a look at that.
Consider the relationship between Booking and Seat:
This relationship can otherwise be expressed as a Node Type, with two relationships, representing the many-to-many relationship:
NB In the Boston conceptual modelling software Edge Types need not be directed, as the most appropriate representation of a many-to-many relationship is to have arrows on both sides of the Edge Type. I.e. e.g. A Booking may have (be for) many Seats and a Seat may have many Bookings. This should not be controversial because even with graph query languages like Cypher, the direction of an Edge Type is only token. I call for an upgrade of the Property Graph Schema standard [here].
Within the common metamodel for Property Graph Schema and Entity Relationship Diagrams this dipole is represented by a flag that says whether and Entity represents a PGS Relation/ship or not.
Within an Entity Relationship Diagram we always have an Entity/Table for a many-to-many relationship:
And that is that. Property Graph Schema and Entity Relationship Diagrams share the same metamodel.
Thank you for reading. As time permits, I will write more on Property Graph Schema, Entity Relationship Diagrams, metamodelling and sharing of metamodels between conceptual modelling languages.
=========
Addendum: (2025–01–12): Architect Joshua Cornejo rightly points out that within the metamodel a “Edge Type Label” on Many-to-Many tables in the metamodel must also exist. E.g. A “HAS” Edge Type Label on the BookingHasSeat Entity (above) such that when it transitions to an Edge Type the “HAS” label is visible. This is a valuable insight into a second point of difference exists between an otherwise shared metamodel. I write about this [here]: openCypher* against any Relational Database | by Victor Morgante | Towards Data Science
============End===========
