In the last lesson, you learned how a set of data is organized into a domain model for human understanding, and then mapped to an application domain model. In some cases, the application domain model also needs to be mapped to a database model.
While this can be a one-to-one mapping where all three models are the same, it often isn’t. This is because each model must fit the constraints of the system it is designed for. The human domain model must be easily translatable to stakeholders, business analysts, and developers. The application domain model must fit the constraints of the chosen programming language. The database model must fit the constraints of data types, relationship syntax, and efficient storage and query retrieval.
Graph Data Model for the Win
Graphs help us to bridge the gap between data models. The graph data model is an excellent fit for the human model because it is flexible and naturally represents data as it exists in the real world, making it more easily understandable across technical and non-technical realms.
A graph data model is also a good fit for the application domain model because the entities and relationships found in the graph model also translate well into the object-oriented world of Java and Spring. Finally, the Neo4j graph database was designed around the graph data model, so there is no mapping required between the original human graph model and the database model.
The best way to grasp this concept is to see it in action.
Lesson Summary
In this lesson, you got an overview of different data models and how they may not all match due to different constraints on design, understanding, language, and technical restrictions. However, the graph data model can create a single, unified version that satifies many of the constraints of each model.
Next, you will walk through an example of modeling for a coffee shop domain.