Modelling multiple hierarchies and inter-relationships

Some of the modelling topics have given me some hope, but I am hoping to sense-check my thinking about the use of Neo4J as a repository of information as follows:

I have a pre-existing relational model that is recursive in most dimensions, essentially an "Application" can be a group of "(sub)Applications" and a "Capability" can be a group of "(sub)Capabilities"

The data I have is quite patchy, but I want a graph driven application to be the method by which the hierarchies get extended and populated

The first iteration is simple:


As the available data evolves, the model I have in mind would expand thus:

As a newbie, and an old hand in the old tech, does anyone have any feedback to suggest progressing like this would be problematic

I am hoping to answer business use-cases such as:

  • what capabilities are affected by application failures?
  • which applications need to change to improve a capability?


1 Like

It appears that the three Application nodes combine to 100% of some entity. If this is true, then here is my suggestion.

Created the scenario:

merge (a:Application {name: "A1", hierarchy: "parent"})
merge (a1:Application {name: "A11", hierarchy: "child", parent: "A1"})
merge (a2:Application {name: "A12", hierarchy: "child", parent: "A1"})
merge (a3:Application {name: "A13", hierarchy: "child", parent: "A1"})

merge (a)-[:HAS_COMPONENT{comprises: "50%"}]->(a1)
merge (a)-[:HAS_COMPONENT{comprises: "40%"}]->(a2)
merge (a)-[:HAS_COMPONENT{comprises: "10%"}]->(a3)

merge (c:Capability {name: "c1", level: 1})
merge (c1:Capability {name: "c2", level: 2})
merge (c2:Capability {name: "c3", level: 2})
merge (c3:Capability {name: "c4", level: 1})

merge (a1)-[:CONTRIBUTES_TO {contribution: "100%"}]->(c)

merge (a2)-[:CONTRIBUTES_TO {contribution: "10%"}]->(c3)
merge (a2)-[:CONTRIBUTES_TO {contribution: "30%"}]->(c2)

merge (a3)-[:CONTRIBUTES_TO {contribution: "100%"}]->(c1)

return a, a1, a2, a3, c, c1, c2, c3


Hope this will help you!

Thank you - this helps hugely with the implementation.

I was also interested in whether or not this is a problem suited to a graph. Having today attended the Identifying Graph-Shaped Problems webinar, I am now assured that my problem space does meet many of the criteria mentioned in the webinar:

  1. Understanding relationships is important
  2. There are lots of self-referencing between the same types of entity
  3. The relationships have varying or unknown depth
  4. There are potentially different paths between entities