Property Graph Schema and Entity Relationship Diagrams share the same MetaSchema/MetaModel

Graph Databases are essentially Relational Databases unless ‘native’

Victor Morgante
6 min readJan 9, 2025
Property Graph Schema and Entity Relationship Diagram sharing the same MetaModel. Image by author.

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.

Morphing between a Property Graph Schema and its Corresponding Entity Relationship Diagram. Image by author.

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:

  1. We view the metamodel storing the Entity Relationship Diagram;
  2. We change the language of interpretation of the ERD model to a Property Graph Schema interpretation; and
  3. Re-open the model and the software then presents the model as a Property Graph Schema, from the same metamodel.
Click to enlarge. ER Diagram and Property Graph Schema sharing the same metamodel. Image by author.

There are three premises that allow this to happen:

  1. Foreign Key Relationships in the Entity-Relationship Diagram (ERD) become Edge Types in the Property Graph Schema view; and
  2. 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
  3. 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:

Foreign Key Relationship becoming and Edge Type. Image by author.

A Many-to-Many (join) Table becomes an Edge Type:

A Many-to-Many (join) Table becomes and Edge Type. Image by author.

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:

Many-to-Many Relationship in a Property Graph Schema. Image by author.

This relationship can otherwise be expressed as a Node Type, with two relationships, representing the many-to-many relationship:

Node Type Representing a Many-to-Many Relationship. Image by author.

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.

Flagging whether an Entity represents a Property Graph Schema relationship or not. Image by author.

Within an Entity Relationship Diagram we always have an Entity/Table for a many-to-many relationship:

Many-to-Many Entity in an Entity Relationship Diagram. Image by author.

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===========

--

--

Victor Morgante
Victor Morgante

Written by Victor Morgante

@FactEngine_AI. Manager, Architect, Data Scientist, Researcher at www.factengine.ai and www.perceptible.ai

Responses (1)