Craig Larmans Buch „Applying UML with Patterns“ beschreibt die 3 gängigen Lösungen für dieses Problem.
Ihre Beispiele sind nicht besonders hilfreich - es gibt keinen logischen Grund, den Namen einer Person in Ihrer Datenbank auf drei verschiedene Arten zu verwalten (obwohl dies aufgrund der Verrücktheit des Datenimports / -exports regelmäßig vorkommt).
Es ist jedoch sehr üblich, dass es eine „Person“-Entität gibt, die ein Mitarbeiter (mit employee_id), ein Kontakt (mit einem Link zur Tabelle mit potenziellen Kunden) oder ein Kunde (mit einer customer_id und einem Link zur Tabelle mit den Bestellungen) sein kann. .
In Larmans Buch gibt er 3 Lösungen an.
Ein Tisch für alle Hier erstellen Sie eine einzelne Tabelle mit allen bekannten Spalten. Dies erzeugt eine unordentliche Tabelle und verschiebt die Verantwortung dafür, die Regeln für die Beibehaltung jeder Unterklasse zu kennen, auf die Anwendungsschicht - die Datenbank erzwingt nicht die Notwendigkeit, dass Kunden eine Kunden-ID haben müssen. Es macht jedoch die Verknüpfungen viel einfacher - jede Tabelle, die mit einer Person verknüpft werden muss, kann einfach mit der Personentabelle verknüpft werden.
Superklasse-Tisch Dies bereinigt die Dinge, indem die gemeinsamen Attribute in eine einzige Tabelle extrahiert werden - z. "person" - und schiebt die unterklassenspezifischen Felder in Unterklassentabellen. Sie haben also möglicherweise „Person“ als Oberklassentabelle und „Kontakt“, „Mitarbeiter“ und „Kunde“ Tabellen mit den spezifischen Unterklassendaten. Die Unterklassentabellen haben eine "person_id"-Spalte, um sie mit der Oberklassentabelle zu verknüpfen. Dies ist komplexer - normalerweise ist beim Abrufen von Daten ein zusätzlicher Join erforderlich -, aber auch weitaus weniger fehleranfällig - Sie können das Datenmodell nicht versehentlich mit einem Fehler beschädigen, der ungültige Attribute für "Mitarbeiter" schreibt.
Tabelle pro Unterklasse - das hast du beschrieben. Es führt eine ziemliche Menge an Duplizierung in das Datenmodell ein, und Sie haben oft bedingte Joins - "join on table x if person type =y", was den Datenzugriffscode schwierig machen kann.
