Du vil måske overveje en Type/SubType-datamodel. Dette er meget som klasse/underklasser i objektorienteret programmering, men meget mere akavet at implementere, og ingen RDBMS (som jeg er klar over) understøtter dem. Den generelle idé er:
- Du definerer en Type (Bygning), opretter en tabel til den, giver den en primær nøgle
- Du definerer to eller flere undertyper (her Hospital, Klinik, Skole, Universitet), opretter tabeller for hver af dem, laver primærnøgler... men de primære nøgler er også fremmednøgler, der refererer til bygningstabellen
- Din tabel med én "ObjectType"-kolonne kan nu bygges med en fremmednøgle på Building-tabellen. Du bliver nødt til at deltage i et par tabeller for at bestemme, hvilken slags bygning det er, men du bliver nødt til at gøre det alligevel. Det, eller gem redundante data.
Du har bemærket problemet med denne model, ikke? Hvad skal forhindre en bygning i at have indgange i to eller flere af undertypetabellerne? Godt du spurgte:
- Føj en kolonne, måske "BuildingType", til Building, sig char(1) med tilladte værdier for {H, C, S, U}, der angiver (duh) type bygning.
- Byg en unik begrænsning på BuildingID + BuildingType
- Har BulidingType-kolonnen i undertabellerne. Sæt en kontrolbegrænsning på den, så den kun nogensinde kan indstilles til værdien (H for tabellen Hospitaler osv.) I teorien kunne dette være en beregnet kolonne; i praksis vil dette ikke virke på grund af følgende trin:
- Byg fremmednøglen til at relatere tabellerne ved hjælp af begge kolonner
Voila:Givet et BYGNING-rækkesæt med type H, kan en post i SKOLE-tabellen (med type S) ikke indstilles til at referere til den bygning
Du kan huske, at jeg sagde, at det var svært at implementere.
Faktisk er det store spørgsmål:Er dette værd at gøre? Hvis det giver mening at implementere de fire (eller flere, som tiden går) bygningstyper som type/undertype (yderligere normaliseringsfordele:ét sted for adresse og andre attributter, der er fælles for hver bygning, med bygningsspecifikke attributter gemt i undertabellerne), det kan godt være den ekstra indsats værd at bygge og vedligeholde. Hvis ikke, så er du tilbage til udgangspunktet:en logisk model, der er svær at implementere i det gennemsnitlige moderne RDBMS.