This is pretty horrible from a relational model point of view, and also from the point of view of having the schema enforce the business rules through its structure (ie normalisation).

One way to do this properly is to have a separate link table for each parent type, so for example you would have

CREATE TABLE ManagerPhoneLink (

ManagerID int not null references Managers(ManagerID)

, PhoneID int not null references PhoneNumbers(PhoneID)

, Constraint ManagerPhone Primary Key (ManagerID,PhoneID)

) ;

and another one like that for each kind of parent you have. That way there's no need for a ParentType at all.

There's an alternative approach which you keep on saying you want to treat as not possible; but you already have invented the required abstraction, Parent so I don't understand the refusal to countenance a table for it. This way you have a Parent table and a ParentTypes table which look like

CREATE TABLE ParentTypes (

ParentTypeID int primary key,

ParentTypeName varchar(48) not null unique

) ;

CREATE TABLE Parents(

ParentID int primary key

, ParentTypeID int not null references ParentTypes (ParentTypeID)

) ;

CREATE TABLE ParentPhoneLink (

ParentID int not null references Parents(ParentID)

, PhoneID int not null references PhoneNumbers(PhoneID)

, Constraint ParentPhone Primary Key (ParentID,PhoneID)

) ;

-- and individual tables for each parent typelike

CREATE TABLE Managers (

ParentID int primary key references Parents(ParentID)

-- and columns for all the rest of a manager's attributes

) ;

This of course is the way that pretty well everyone has been telling you is best, and I agree with them. It is of course ridiculous to ask us, as you have several times, to assume that an abstraction can't be discovered which you have already invented and assigned an attribute(ParentType) or to assume that it is impossible to have a table representing the instances of this abstraction.

As to the height of some putative tower of abstractions, that is of course up to you. You can do it with the individual kinds of parent at the base level and teh single Parent abstraction above it. If you want to you can invent intermediate layers - as many as you like. The problem you have asked for guidance on requires only the top and bottom levels. Adding extra levels in beteen is a non-trivial excercise, and it may not be a useful one - or you may have proposed 5 levels as a limit because you can see uses in some cases for 3 levels above the bottom and below the top (presumably the depth of the tree doesn't need to be uniform once you introduce intermediate levels) in which case the excercise may be useful.