In my database I have a table that looks like this Master(ID, Name, Attr1…). Every ID will have at least 1 entry in additional tables that have additional attributes. Those tables specialize the master table.
Spec1(MasterID, Attr2,…)
Spec2(MasterID, Attr3,…)
…
So, not sure how to map this to object oriented design. If every ID could have just one specialization then it would be easy, master would be abstract class and specializations would be concrete inherited classes but in this scenario, single ID can have all specializations and they could be added or removed during his lifetime in the database. Each specialization has unique business rules ofc.
In most cases it not very useful to make modeling decisions with names like “Master” or “Spec1” (one has to see the actual names and have a notion about their intended semantics). But in your case it seems pretty obvious that you are looking for an aggregate relationship between the class/table “Master” and the classes/tables “Spec1”, “Spec2”. It may be either a “1 to {0,1}” or a “1 to {0,n}” relationship, which depends on how many Spec records/objects you want to allow per Master record/object.
Dont’ try to use “inheritance” for such cases. Inheritance is for static forms of specialization, not for specializations which can change at run time.
3