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” 

A close up of a map

Description automatically generated

Using this model we could extract the following hierarchies: 

– Marlin 
– Nemo 
– Dory 

– Nemo


Great Barrier Reef
– Fish
– Coral

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: 

FISH  and 
– Marlin  
– Nemo 
– Dory

– Clown Fish 
          – Marlin 
          – Nemo
– Blue Tang
          – Dory 

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. 

written by

Murray Callander

posted on

June 25, 2020

you may also like...