Schema for storing historical transaction data in Neo4J? - neo4j

Question

I have around 200 entities that have invested in a company over the last 30 years. I have been tracking how much money they contributed over time. My database will be in Neo4J.
So far on my graph I have (1) 200 nodes representing the 200 entities that have invested and (2) 1 node representing the single company they invested in.
I see two options for me to represent the capital infusions:
I explicitly create 1,500 nodes representing each of the initial capital infusion, capital increase, etc. The nodes captures information on changes in dollar amounts, etc. Then my graph is roughly this (e:Entity)-[:PROVIDES]->(f:Financing {amount: {value}, year: {2010}})-[:PROVIDES]->(t:Target). In some way, I find this much cleaner and easier for analysis down the road but this will be a larger graph and the PROVIDES relationships are not particularly insightful.
I represent those 1,500 financing rounds much more directly as relationships between the 200 entities and the target company
(e:Entity)-[:FINANCING {amount: {value}, year: {2010}}]->(t:Target). In that case, I'm a bit unsure about how to handle the analysis afterwards or whether it makes sense to have say 50 FINANCING relationships between Entity X and the target company.
The type of analysis I'd like to do would include (1) generating the target entity ownership say in year 2004, (2) generating the evolution over time of shareholding in the target company by entity X, etc.
What would you recommend as a solution for the schema? I know Neo4J is schema-optional but I suspect this choice between nodes and relationships matters.
Many thanks!
Cheers

Answer 1

For data that is going to be frequently queried but has a limited, finite number of possible values (like years, especially for only 30 years) a lot of times you'll see better performance if you move that year property onto a separate node, so that you can quickly group all of the nodes that attach to it and fetch its year property once, instead of essentially re-creating a property index for it. That necessitates adding a :Financing node in this case, so that you can hook up :Entity, :Target, and the :Year nodes all to the same transaction record.
So your data model would be like:
(:Entity) - [:PROVIDES] -> (:Financing {amount: x}) - [:PROVIDES] -> (:Target)
(:Financing) - [:OCCURRED_IN] -> (:Year {year: 1999})
thereby allowing you to slice your data by Year value without having to scan all of your nodes for properties. You could also put a property index on :Financing(year), but modelling limited, discrete properties like year as a separate path allows you to more easily extend your graph, and makes good query performance easier to achieve.
Either way, though, you will definitely want a :Financing node in the middle. Properties on relationships should rarely be used for anything except being returned in a result; they can't be indexed, so they are always going to require a property scan to get a result, and if you have a lot of relationships, that can add up fast.
Starter queries (assuming that ownership is % of total amount provided up to a given point), to get % ownership by entity at the end of 2004:
MATCH (t:Target {id: 1})
WITH t
MATCH (y:Year)
WHERE y.year <= 2004
WITH t, y
MATCH (y) <- [:OCCURRED_IN] - (f:Financing) - [:PROVIDED] -> (t)
WITH f, f.amount as amt
WITH COLLECT({f: f, amt: amt}) AS rows, SUM(amt) AS total
UNWIND rows AS row
WITH row.f as f, row.amt as amt, total
MATCH (e:Entity) - [:PROVIDED] -> (f)
WITH e, SUM(amt) AS part, total
RETURN e, part/total * 100 AS percentage
And to get Entity 2 (arbitrary identifier)'s proportion of financing provided each year:
MATCH (t:Target {id:1})
WITH t
MATCH (y:Year)
WITH t, y
MATCH (y) <- [:OCCURRED_IN] - (f:Financing) - [:PROVIDED] -> (t)
WITH y, f, f.amount as amt
WITH y, COLLECT({f: f, amt: amt}) AS rows, SUM(amt) AS total_per_y
UNWIND rows AS row
WITH y, row.f as f, row.amt as amt, total_per_y
MATCH (f) <- [:PROVIDED] - (:Entity {id:2})
WITH y, total_per_y, SUM(amt) AS part_per_y
RETURN y.year, part_per_y/total_per_y*100 AS percentage