Du kanske vill överväga en Type/SubType-datamodell. Detta påminner mycket om klass/underklasser i objektorienterad programmering, men mycket besvärligare att implementera, och ingen RDBMS (som jag är medveten om) stöder dem inbyggt. Den allmänna idén är:
- Du definierar en typ (byggnad), skapar en tabell för den, ger den en primärnyckel
- Du definierar två eller flera undertyper (här, sjukhus, klinik, skola, universitet), skapar tabeller för var och en av dem, gör primärnycklar... men primärnycklarna är också främmande nycklar som refererar till byggnadstabellen
- Din tabell med en "ObjectType"-kolumn kan nu byggas med en främmande nyckel på Building-tabellen. Du måste gå med i några tabeller för att avgöra vilken typ av byggnad det är, men du måste göra det ändå. Det, eller lagra redundant data.
Du har märkt problemet med den här modellen, eller hur? Vad är för att hindra en byggnad från att ha poster i två eller flera av undertypstabellerna? Kul att du frågade:
- Lägg till en kolumn, kanske "BuildingType", till Building, säg char(1) med tillåtna värden för {H, C, S, U} som indikerar (duh) typ av byggnad.
- Bygg en unik begränsning på BuildingID + BuildingType
- Ha kolumnen BulidingType i undertabellerna. Sätt en kontrollbegränsning på den så att den bara kan ställas in på värdet (H för tabellen Hospitals, etc.) I teorin kan detta vara en beräknad kolumn; i praktiken kommer detta inte att fungera på grund av följande steg:
- Bygg den främmande nyckeln för att relatera tabellerna med båda kolumnerna
Voila:Med tanke på en byggnadsraduppsättning med typ H, kan en post i SCHOOL-tabellen (med typ S) inte ställas in för att referera till den byggnaden
Du kommer ihåg att jag sa att det var svårt att implementera.
I själva verket är den stora frågan:Är detta värt att göra? Om det är meningsfullt att implementera de fyra (eller fler, med tiden) byggnadstyper som typ/undertyp (ytterligare normaliseringsfördelar:en plats för adress och andra attribut som är gemensamma för varje byggnad, med byggnadsspecifika attribut lagrade i deltabellerna), det kan mycket väl vara värt den extra ansträngningen att bygga och underhålla. Om inte, då är du tillbaka till ruta ett:en logisk modell som är svår att implementera i den genomsnittliga moderna RDBMS.