What is a Graph anyway?

Many people associate “graph” with a line chart or similar. That is not what we are talking about here. “Graph” is a mathematical concept, which was first described in 1736 by Euler.
The picture in your head should look more like this:
Directed Graph
(Public Domain, https://commons.wikimedia.org/w/index.php?curid=614057)
The graph above is a directed (the arrowheads), acyclic (no recursive loops) graph, which is what we are interested in here.
What graphs do very well is represent connected data. What representing the real world is about is communicating these two perspectives:
• Structure (connectedness) and
• Meaning (naming and other definitions)
So, even if your physical target is not a graph database, borrowing the paradigms of the (property) graph to make platform independent representations of data models makes perfect sense.
At the bottom of this page you will find references to the theoretical background of property graphs. For now think about property graphs as being mathematically well-founded (graph theory). Just as the relational model (in the Dr. Ted Codd style) is based on mathematics (set theory). Going graph does not imply lack of precision.

Concepts of the Property Graph Model

The concept map below explains the most important concepts used in the property graph context:
Property Graph Concepts
Both Nodes and Relationships can (should) have “names” (formally called labels for nodes and types for relationships), just like concepts and their relationships have in the diagram above.
Relationships are directed, which is visualized by the arrowheads.
Both Nodes and Relationships may be associated with Properties, which are “key / value” pairs such as e.g. Color: Red. On the data model level, we call the key "Property Name".

SQL has Adopted Property Graph Queries!

Today (2023), the new SQL Property Graph Queries, ISO/IEC DIS 9075-16, Information technology — Database languages SQL — Part 16: Property Graph Queries (SQL/PGQ) is an international standard for making property graph queries on top of SQL databases! ISO still needs to publish the document, but Oracle has the first implementation now, in Oracle 23c!

Solution Level (Logical) Models

Here is an example of a directed graph representation of the good old Microsoft Northwind data model:
Northwind Graph Model
Together nodes and relationships explain the context very well. Nodes represent entity types, which I prefer to call types of business objects. Edges, better known as relationships, represent the connectedness and, because of their names, bring semantic clarity and context to the nodes. Named relationships is a great help when looking into functional dependencies, for example. And the graph representation communicates structure a lot better than an ER diagram.
Note that the properties are represented quite discretely in "parenthesis".
Property Graphs are similar to concept maps in that there is no normative style (like in UML, e.g.). The style used above is the preference of the author, so feel free to find your own style. If you communicate well with your readers, you have accomplished the necessary.
The labeled property graph model is the best general purpose data model paradigm that we have today.
The important things are the names and the structure (the nodes and the relationships). The properties supplement the solution structure by way of adding content. Properties are also basically just names, but they also can signify “identity” (the general idea of a key on the data model level). Identities may be shown in italics (or some other special effect to your liking). And uniqueness can be signaled using bold font, for example:
Employe Database Graph Data Model
For more details see the book about Graph Data Modeling.

Physical Models for Graph Databases

Obviously, since our solution data model is already a property graph, moving it to a property graph platform is very easy. There are some physical aspects, which should be taken into consideration:
  1. Uniqueness and identity
  2. Data types
  3. Properties on relationships
  4. A relationship may point to different types of business objects, like when “Part” and “Waste” are both “part of.” This is both a strength and a weakness. Strength because it reflects the way people think about the reality. And a weakness because people might get confused, if the semantics are unclear. These considerations are very good reasons for defining a solution data model, even if your physical data model is going to be based on a “flexible” or even non-existing schema.
  5. Ordered, linked lists; possibly including time-series, which can also be handled elegantly in a graph representation (such as e.g. a relationship of type “next” or “previous”).
The Graph Data Modeling book and Neo4J’s homepage (and several other graph database homepages) have lengthy discussions of these physical aspects of graph technology, which are actually rather difficult to accomplish in other technologies such as SQL tables. Good thing that there are room for solutions without tables, if you ask me.

Property Graph and Fact Modeling

Property Graphs are, actually, used for modeling business facing models. There is another "graphy" approach to modeling called Fact Modeling. To me property graphs are the day-to-day workhorses, whereas fact models gives you the full palette of semantic modeling tools, without being based on RDF and OWL. I recommend Fact Modeling for complex use cases, where semantic accuracy is of utmost importance. Read the Fact Modeling book above all:
See more about Fact Modeling here.

Graph Theoretical Background

On the Github site for the OpenCypher project you can find a good, formal definition based on mathematical graph theoretical concepts. Basically a property graph in the sense it is used here is a directed, vertex-labeled, edge-labeled multigraph with self-edges, where edges have their own identity. In the property graph paradigm, the term node is used to denote a vertex, and relationship to denote an edge. See Wikipedia’s definitions for reference:
Directed multigraph
Labeled multigraph
The Apache Tinkerpop ™ project is also based on very similar concepts.
There are several physical implementations of property graph technologies. One of the most well know is Neo4J from Neo Technologies, most of the rest of the companies are listed on the Tinkerpop site. Neo has a good introduction to property graphs over here: https://neo4j.com/developer/graph-database/

Using Property Graphs to Describe GraphQL APIs

Structure and meaning must always be right, also for GraphQL data APIs. GraphQL is indeed an attractive data API for applications (and people). However, even if you know the basics of GraphQL, you may run into issues about getting the API data structures right and in prettifying the data content to make it business friendly. See more here in my book about Visual Design of GraphQL. Or check out the background page here.
New: Online Training in Graph Data Modeling is now available! Click here:
Stacks Image 173
There is much more about property graphs for data modeling in the book about Graph Data Modeling:
Graph Data Modeling Book
You can actually auto-generate property graph database models from existing data models in UML, XML, XMI, ERD etc. This book contains all the tools you need:
Metadata Reuse Graph Models Neo4j
For more information: Contact the author at the email indicated at the bottom of the page.

Using Property Graphs on the Concept Level

Property Graphs are, actually, used for modeling business facing concept models in front of the development oriented solution models described on this page.
Steve Hoberman, the Data Model Rockstar, has written an excellent book about that:
The Rosedata Stone: Achieving a Common Business Language using the Business Terms Model, by Steve Hoberman, buy it using the coupon code: 'VizDataModeler' (worth 20 %), at Technics Pub.
I have developed a design thinking inspired approach, which is described here.

The guy behind this site is Thomas Frisendal:

Stacks Image 186
RapidWeaver Icon

Made in RapidWeaver