Data Modeling in The Era of Knowledge Graphs

Originally data modeling was business oriented. But with the advent of the relational model and normalization, data modeling became a more technical part of software engineering.
In parallel with this, psychologists developed concept mapping and cognitive computing. Adding psychology to the equation means that data modeling is not a done deal. If you are looking for a modern approach to data modeling, keep reading!
Graph data modeling is a technique superior to traditional data modeling for both relational and graph, document, key-value, leveraging cognitive psychology as well as AI to improve data designs.
Stacks Image 259

"The Tightrope" by JK Rofling, https://www.jkrofling.com

Aside: There are a number of signals that indicate the changes in this space:
  • Agile everything
  • The rise of Knowledge Graphs
  • SQL has added a property graph extension
  • Soon a new ISO graph query language will be published
  • The tried and trusted RDF / OWL stack is being extended in the direction of property graphs
  • GraphQL
All of the above, and more, is put in perspective on this website.

Kick-start Your Knowledge Graph!

Knowledge Graphs are traditionally used for information management (ontologies etc.), but today more and more organizations implement knowledge graphs as part of data platforms. The typical role is often called "semantic layer", and the semantics based integrations support data platforms such as data mesh, data fabrics and data lake houses. See more here

A Brief Explainer of Property Graph Data Modeling

In the graph world the “property graph” style of graphing makes it possible to rethink the representation of data models. Graph Data Modeling sets a new standard for visualization of data models based on the property graph approach. Property graphs are graph data models consisting of nodes and relationships. The properties can reside with the nodes and / or the relationships.
This data model is very close to what people - by intuition - draw on whiteboards. Rather than modeling data as formal logic, we should focus on the psychology of the end user. If we do so, then engineering could be replaced with relevant business processes. In short, to achieve more logical and efficient results, we need to return to data modeling’s roots:
Whiteboard data model

Graph Data Modeling is for You, if You …

  • need to model data for graph databases, or, for that matter, SQL (yes, indeed)
  • work in analytics, big data and/or data science and must visualize data structures
  • develop data models as you go
  • think “There must be a better way than classic data modeling"

Here follow 3 slightly more detailed explainers about graph and database:

This website gives you an introduction only and is organized in three parts:

How to explore the business context and map the meaning and the structure.

Business Concept Modeling explained.

Business / conceptual level.

Visualizing structure.

Graph Data Modeling explained.

Logical and physical levels.


The History of Data Modeling
- with and w/o graphs

Key Take-away: Why Graph Data Models are Good for You!

There are two popular attractions of graph data models, which many people are taking advantage of:
  • Knowledge Graphs, and
  • Schema-less Development.
Knowledge Graphs are traditionally used for information management (ontologies etc.), but today more and more organizations implement knowledge graphs as part of data platforms. The typical role is often called "semantic layer", and the semantics based integrations support data platforms such as data mesh, data fabrics and data lake houses. See more here

Many leading property graph database products offer “
schema-less” development. Meaning that no schema is necessary for loading data. Inspections, using graph queries, of the data contents lead to – over some iterations, probably, a better understanding of the data model; sort of a prototyping approach to data modeling.

The structures of the graph data model might be iteratively changed (no schema to change). A canonical form of the inner graph structure is easy to derive (inside your head) from the graph elements, including edges / relationships and the structures they represent. The canonical form can remain the same, even after structural changes such as rearranging the allocation of properties to nodes and edges / relationships are performed.

This is in contrast to the relational / SQL model, where a canonical form is not that easy to visualize just by looking at the structure (not all dependencies need to be explicit). And, if the SQL data model undergoes deeper normalization, denormalization or combinations of both, keeping mentally up with an intuitive understanding of the semantics will grow more and more complex.

It is all about the
distance between the logical data model and a corresponding conceptual data model – which in graph models is easy to grasp, even without visualization. This makes graph data models both more robust and more flexible.

Online learning plan from Dataversity;
Stacks Image 251
A book covering most aspects of modern data modeling
Book Graph Data Modeling

The guy behind this site is Thomas Frisendal:

Stacks Image 245
RapidWeaver Icon

Made in RapidWeaver