cancel
Showing results for 
Search instead for 
Did you mean: 

Modelling multiple hierarchies and inter-relationships

tim_reynolds
Node Link

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:

2X_9_9903cd32a680923ef1f75b38be9e6ae8e4ae75da.png

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?

Thanks

1 ACCEPTED SOLUTION

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

View solution in original post

2 REPLIES 2

ameyasoft
Graph Maven

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

Result:

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
Nodes 2022
Nodes
NODES 2022, Neo4j Online Education Summit

All the sessions of the conference are now available online