Relational 🆚 Document 🆚 Graph — Part 3
Here we are with the last part of this saga where we analyze which is the best data model/structure for our data application.

In this article, we will discover the Graph model (NoSQL plus a bit of Relational).

I strongly suggest reading previous articles about the Relational Model and NoSQL Databases to have a better understanding of what we are talking about, previous articles include also content that is very often cited in this reading.

So, read the previous articles if you didn’t! 😉

Score Recap:

Space complexity — Redundancy Consideration, Support data, Elaboration space …

Time complexity — Join complexity, Indexing, Parallel computing, …

Modelling Easiness— Concepting your database, model entities and relationship, projections, …

Querying Easiness— Query size, Think to Text steps, ORM, …

Scalability — Vertical, Horizontal, CAP Theorem, …

Consistency — BASE, ACID, CAP Theorem, PACELC Theorem, Concurrency, …

Worst Score: 1 — Best Score: 10

The Graph model

We discussed a lot about databases in previous articles, so in this one, I will not dig through some concepts that are transversal among all database paradigms.

In this article, we will examine another NoSQL paradigm: the Graph Model. The objective of this approach is to take advantage of the representation of data as a graph trying to mashup all advantages of the relational model and the document one.

A few definitions

Class or Entity: Something that we consider in our domain

Node or Vertex: An instance of an entity or a class

Relation or Edge: An association (directed or undirected) between two Nodes

Property: information associated with a Node or a Relation (the entity class and the relation name are properties)

Graph model

If we consider the Relational and the Document model, we may not see find big differences: in both of those paradigms, we can reconstruct the same database in the image above. Why should we use a graph database then?

The answer is Edges. Previous paradigms have an implicit representation for a relation, to manage cross entity dependency they use the foreign key strategy. The graph model represents those relations explicitly in memory by linking data together and from any point of view.

So, we take the advantage of the relational model for the ability to represent our domain from any point of view (the entity decomposition is very similar) and we want to add the concept of the document database to have unstructured or semi-structured data.
['Gabor Galazzo']
['Neo4j', 'Analitycs', 'Big Data Engineering', 'Database', 'Graph']