Investment ownership structures database design (M-to-M): hierarchy? graph?

Hi all,

I am designing a database for my job that would be collecting information on:

• (1) financial flows related to investments in specific types of projects, gathering information along the way on
• (2) the investors in such projects,
• (3) the investors in the investors that invest in such projects,
• (4) the investors that invest in the investors that invest in such projects,
• (5) and so on. :shocked:

I. Simplified structure of the tables
The simple way I represented this with a pencil and a paper was to have the following tables

___________ _____ ______ ___________ _____ ___________
ProjectActor1 Actor1 Actor2 Actor1Actor2 Actor3 Actor2Actor3
------------- ------ ------- ------------ ------ ------------
junction table junction table junction table
______
Project
-------

II. Project and investors/actors
The relationship between a given project and its providers of capital:
"Project" 1-to-M link "ProjectActor1" M-to-1 link to "Actor1"

• A project can have a multiple investors
• An investor can invest in multiple projects
• so that's a M-to-M relationship that I broke down with a junction table using the 2 FKs

III. Multiple layers of investors/actors
The relationship between a given actor and another actor:
"Actor1" 1-to-M link "Actor1Actor2" M-to-1 link to "Actor2"
"Actor2" 1-to-M link "Actor2Actor3" M-to-1 link to "Actor3"
and so on

• An actor can have multiple shareholders
• An actor can have multiple stakes in other actors
• so that's a M-to-M relationship that I broke down with a junction table using the 2 FKs

IV. The problem with III
This artificial breakdown of structure forces me to create an unknown number of ownership layers (it can go up to 10 layers in rather complex cases for instance so this is not unrealistic). This is cumbersome and also causes some problems. So here are my doubts - concerns - questions in relation to this:

• What if a given investor (say a corporate group) in Actor3 invests directly in a project? I don't have an Actor3Project table and so on. This is very real so I should be able to capture such relationships.
• Plus I'm pretty sure that having multiple ActorX tables with possibly overlapping / redundant is in breach of one of the normalization rules.
• I would ideally like to have a single Actor table for the sake of simplicity for subsequent queries in the database
• I believe we are dealing with a hierarchical structures here. Given the M-to-M nature of what happens in the investor side, are we dealing with a graph (I saw this in a forum or a blog) rather than a tree structure? If so, how could I deal with this or more simply make it work? I am a bit lost to be honest here.

(FYI: This is will be implemented later on in MySQL.)
Many thanks for your help!

Cheers