Craig Larmans bog "Applying UML with Patterns" beskriver de 3 almindelige løsninger på dette problem.
Dine eksempler er ikke særlig nyttige - der er ingen logisk grund til at have 3 forskellige måder at administrere en persons navn på i din database (selvom dette ofte sker på grund af dataimport/eksport underlige).
Det er dog meget almindeligt, at der er en "person"-enhed, der kan være en medarbejder (med ansat_id), en kontaktperson (med et link til kundeemnetabellen) eller en kunde (med et kunde_id og link til ordretabellen) .
I Larmans bog giver han 3 løsninger.
Én tabel til at styre dem alle Her opretter du en enkelt tabel med alle kendte kolonner. Dette skaber en rodet tabel og skubber ansvaret for at kende reglerne for at vedholde hver underklasse til applikationslaget - databasen vil ikke håndhæve behovet for, at kunder skal have et customer_id. Det gør dog sammenkædningen meget nemmere - enhver tabel, der skal linke til en person, kan bare, ja, linke til persontabellen.
Superklassebord Dette rydder op i tingene ved at udtrække de fælles attributter i en enkelt tabel - f.eks. "person" - og skubber de underklassespecifikke felter til underklassetabeller. Så du kan have "person" som superklassetabellen og "kontakt", "medarbejder" og "kunde"-tabeller med de specifikke underklassedata. Underklassetabellerne har en "person_id" kolonne for at linke tilbage til superklassetabellen. Dette er mere komplekst - det kræver typisk en ekstra join ved hentning af data - men også langt mindre fejltilbøjelig - du kan ikke ved et uheld ødelægge datamodellen med en fejl, der skriver ugyldige attributter til "medarbejder".
Tabel pr. underklasse - det er det, du har beskrevet. Det introducerer en del duplikering i datamodellen, og man har ofte betingede joinforbindelser - "join på tabel x hvis persontype =y", hvilket kan gøre dataadgangskoden vanskelig.