WHAT MAKES A GOOD DATAMODEL? — POINT 1: NON-HIERARCHICAL
The problem with hierarchies is they are subjective and only relevant to a certain viewpoint or problem. For example, what is the hierarchy of equipment on an industrial facility? Should it be based on area or on equipment size, or on position in the process?
If my data model is based on one particular hierarchy being right, then it will not work very well for all the alternative views of the world. It will work brilliantly for some use cases and not at all well for others.
Graph databases solve this problem by letting you create a network of objects and relationships. Data can be extracted from a graph as if it were a hierarchy by following certain relationships but it doesn’t have to be stored this way. That means you can model all the different hierarchies at the same time. It’s a bit like Scrabble — the hierarchies intersect each other
Lets take a look at a quick example. Here’s my simple model from the film “Finding Nemo”
Using this model we could extract the following hierarchies:
The great thing about this is that I can add objects and relationships over time as I discover them. Things I have built based on the starting structure will still work, but now more advanced functions can be made.
However, a graph alone will not solve all of the challenges. What if I want to simultaneously represent the following hierarchies:
This is where you also need a Class Library and a pragmatic approach to objects and properties which I’ll talk about in the subsequent blogs.
