Craig Larman's boek "Applying UML with Patterns" beschrijft de 3 veelvoorkomende oplossingen voor dit probleem.
Uw voorbeelden zijn niet bijzonder nuttig - er is geen logische reden om 3 verschillende manieren te hebben om de naam van een persoon in uw database te beheren (hoewel dit regelmatig gebeurt vanwege de raarheid van het importeren/exporteren van gegevens).
Het is echter heel gebruikelijk dat er een "persoon" -entiteit is die een werknemer kan zijn (met werknemer_id), een contactpersoon (met een link naar de prospectentabel) of een klant (met een klant_id en een link naar de besteltabel) .
In Larmans boek geeft hij 3 oplossingen.
Eén tafel om ze allemaal te regeren Hier maakt u een enkele tabel met alle bekende kolommen. Dit creëert een rommelige tabel en verschuift de verantwoordelijkheid voor het kennen van de regels voor het behouden van elke subklasse naar de applicatielaag - de database dwingt niet tot de noodzaak voor klanten om een customer_id te hebben. Het maakt de joins echter veel gemakkelijker - elke tabel die naar een persoon moet linken, kan gewoon, nou ja, linken naar de persoonstabel.
Superklasse tafel Dit ruimt de zaken op door de algemene attributen in een enkele tabel te extraheren - b.v. "person" - en duwt de subklasse-specifieke velden naar subklassetabellen. U kunt dus "persoon" hebben als de superklassetabel, en "contact", "werknemer" en "klant"-tabellen met de specifieke subklassegegevens. De subklassetabellen hebben een kolom "person_id" om terug te linken naar de superklassetabel. Dit is complexer - het vereist meestal een extra join bij het ophalen van gegevens - maar ook veel minder foutgevoelig - u kunt het gegevensmodel niet per ongeluk beschadigen met een bug die ongeldige attributen schrijft voor "werknemer".
Tabel per subklasse - dit is wat je hebt beschreven. Het introduceert een behoorlijke hoeveelheid duplicatie in het datamodel, en je hebt vaak voorwaardelijke joins - "join on table x if person type =y", wat de datatoegangscode lastig kan maken.