Why Model?

It is tempting today to model the data as you go. Schema-less or self-describing data helps a piece of the way. But you are still at risk of using bad assumptions and create flaws. For example not realizing that you are looking at a many-to-many relationship can be a difficult structural flaw to change two months down the line. Spending time on a design stage helps you avoid refactoring code once you realize that you must change the data model.
You can quote me for:
Data Modeling on the fly moulds like putty, but it sets like concrete
Thomas Frisendal

Graph Your Data Model!

Since a data model is meant to communicate to people, you must be as visually mesmerizing as you can.

Using graphs to represent data models really changes the way we look at data models.
Instead of looking like this:
Stacks Image 59
… or this:
Stacks Image 63
… it will look like this:
Stacks Image 67
Visualizing structure and meaning is the goal; because that focus greatly improves the communication to business stakeholders as well as IT developers.

Furthermore this representation (the property graph model) is agnostic of the physical data store and is capabilities.

Data Modeling in the complete Picture

The visual approach to data modeling is described in detail in this book:
Stacks Image 105
The architect:ure of a new solution for data modeling follows these lines:
Stacks Image 75
A 3-layer architecture for the whole of the data modeling space is still the name of the game. But the layer names have changed a bit:
  • Business Concept Model - is the business facing concept model
  • Solution Data Model - takes the place of the "logical" data model, which most of the time is not very logical
  • Physical Data Model - continues to be a precise term.
The Business Concept Model is described at the "Explore" pages. Here we deal with the solution and physical model issues in this manner:
  • Structure discusses the issue of functional dependencies a.k.a. normalization, which used to be the key "trade secret" of the data modeling paradigm
  • Visualization shows how concept maps can be transformed into property graphs at the solution model level
  • Requirements is a compilation of the 35 real requirements of a data modeling platform
  • NoSQL discusses the physical data modeling opportunities offered by the property graph approach
  • Graph Data Modeling is an overview of the whole approach, as described in the accompanying book.
And don't forget to visit our Data Model History page for an overview of the important events and products on the database scene.
You may follow the sequence or explore the site as you wish: