Data Modeling in The Era of Knowledge Graphs
Offers for this domain are welcome!
Do you offer graph data modeling tools or services? In that case you may be interested in buying this domain name? www.graphdatamodeling.com
I established the domain in 2016 to support my book on Graph Data Modeling (see a reference on this page). I was lucky to get such a dominating domain name back then.
If interested, send an email to thomasf at tf-informatik at dk. Your email must include your bid. Bids over € 1999 receiven no later then 1st of December 2024 are considered.
Looking forward to hearing from you!
(Reason: I am in the process of retiring - not completely though, see my profile on LinkedIn).
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.
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.
"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
- …
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:
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:
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.
- Knowledge Graphs, and
- Schema-less Development.
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;
A book covering most aspects of modern data modeling
The guy behind this site is Thomas Frisendal:
