Craig Larmans bok "Applying UML with Patterns" beskriver de 3 vanliga lösningarna på detta problem.
Dina exempel är inte särskilt användbara - det finns ingen logisk anledning att ha tre olika sätt att hantera en persons namn i din databas (även om detta regelbundet händer på grund av konstigheter med dataimport/export).
Det är dock mycket vanligt att det finns en "person"-enhet som kan vara en anställd (med anställd_id), en kontakt (med en länk till tabellen för potentiella kunder) eller en kund (med ett kund_id och länk till ordertabellen) .
I Larmans bok ger han 3 lösningar.
En tabell för att styra dem alla Här skapar du en enda tabell med alla kända kolumner. Detta skapar en rörig tabell och förskjuter ansvaret för att känna till reglerna för att bevara varje underklass till applikationslagret - databasen kommer inte att upprätthålla behovet för kunder att ha ett customer_id. Det gör dock sammanfogningarna mycket enklare - vilken tabell som helst som behöver länka till en person kan bara, ja, länka till persontabellen.
Superklassbord Detta rensar upp saker genom att extrahera de vanliga attributen i en enda tabell - t.ex. "person" - och skjuter de underklassspecifika fälten till underklasstabeller. Så du kan ha "person" som superklasstabell och "kontakt", "anställd" och "kund"-tabeller med specifika underklassdata. Underklasstabellerna har en kolumn "person_id" för att länka tillbaka till superklasstabellen. Det här är mer komplext - det kräver vanligtvis en extra join när du hämtar data - men också mycket mindre felbenägen - du kan inte av misstag korrumpera datamodellen med en bugg som skriver ogiltiga attribut för "anställd".
Tabell per underklass - Det här är vad du har beskrivit. Det introducerar en hel del duplicering i datamodellen, och du har ofta villkorliga joins - "join on table x if person type =y", vilket kan göra dataåtkomstkoden knepig.