Database dilemma: actors - mysql

Question

I have different kind of actors:
Parents;
Subsidiaries;
Insurers;
Brokers;
for each of the actors, there will be users with a personal account and user role.
I need to register the address and other (entity specific, including foreign keys) info into a table, which could be done by defining one "actor_tbl" and specifying the type of actor with an id.
However, the four types of actor have interrelations, which means that one parent can have multiple subsidiaries, one insurer can have multiple subsidiaries, one broker can have multiple parents, etc...
From this point of view, it would make more sense for me to create a separate table for each of the actor types, and create many-to-many relationships to make the right combinations. It think that it may also increase general readability and reduce the possibility for errors (all entities would be clearly separated from one another).
However, doing so takes away the principle of storing all entities with similar characteristics into a single table.
How would you take on this problem? What is the most recommended way to implement this structure?

Answer 1

You can see a superclass/subclass relationship between Actor and the four kinds of actors. The first point here is to clarify the constraints on this relationship. From your description, I'm assuming the participation is mandatory (every Actor will be also a member of a subclass) and the subclasses are disjoint (e.g. a Parent cannot be a Broker, and so on).
In this case, you'll need four relations, one for each subclass.
If instead the participation is optional (some Actor may not be a member of any subclass), you'll need a relation Actor(ActorID, ...) to store all the attributes in common between the subclasses (e.g. address), then one relation for each subclass, which will look like:
Parent(ActorID, ...)
Subsidiary(ActorID, ...)
Insurer(ActorID, ...)
Broker(ActorID, ...)
For these four relations, ActorID will be both primary key and foreign key referencing Actor(ActorID). The dots represent the attributes which are peculiar to the specific entity (as mentioned before, the common attributes will be in the Actor relation).
For Actors which are not member of any subclass, you just store the record in the Actor relation. For Actors which are instead member of a subclass, you'll store the record in Actor and in the specific subclass relation.
In all cases, relationships between the subclasses will be modelled depending on their cardinality.
If the disjointness between subclasses is different, i.e. non-disjoint subclasses, then the story is different.