U kunt een Type/SubType-gegevensmodel overwegen. Dit lijkt erg op klasse/subklassen in objectgeoriënteerd programmeren, maar veel lastiger om te implementeren, en geen enkel RDBMS (voor zover ik weet) ondersteunt ze native. Het algemene idee is:
- Je definieert een type (gebouw), maakt er een tabel voor, geeft het een primaire sleutel
- Je definieert twee of meer subtypes (hier, Ziekenhuis, Kliniek, School, Universiteit), maakt tabellen voor elk van hen, maakt primaire sleutels... maar de primaire sleutels zijn ook externe sleutels die verwijzen naar de tabel Bouwen
- Uw tabel met één "ObjectType"-kolom kan nu met een externe sleutel in de tabel Bouwen worden gebouwd. Je zou aan een paar tafels moeten deelnemen om te bepalen wat voor soort gebouw het is, maar dat zou je toch moeten doen. Dat, of overtollige gegevens opslaan.
Je hebt het probleem met dit model toch opgemerkt? Wat zorgt ervoor dat een gebouw geen vermeldingen heeft in twee of meer subtypetabellen? Blij dat je vroeg:
- Voeg een kolom toe, misschien "BuildingType", aan Gebouw, bijvoorbeeld char(1) met toegestane waarden van {H, C, S, U} die het (duh) type gebouw aangeven.
- Bouw een unieke beperking op BuildingID + BuildingType
- Zet de kolom BulidingType in de subtabellen. Zet er een controlebeperking op zodat deze alleen op de waarde (H voor de tabel Ziekenhuizen, enz.) kan worden ingesteld. In theorie zou dit een berekende kolom kunnen zijn; in de praktijk zal dit niet werken vanwege de volgende stap:
- Bouw de externe sleutel om de tabellen te relateren met behulp van beide kolommen
Voila:gegeven een BUILDING-rij die is ingesteld met type H, kan een item in de SCHOOL-tabel (met type S) niet worden ingesteld om naar dat gebouw te verwijzen
U zult zich herinneren dat ik zei dat het moeilijk te implementeren was.
In feite is de grote vraag:is dit de moeite waard om te doen? Als het zinvol is om de vier (of meer, naarmate de tijd verstrijkt) gebouwtypes als type/subtype te implementeren (verdere normalisatievoordelen:één plaats voor adres en andere attributen die gemeenschappelijk zijn voor elk gebouw, met gebouwspecifieke attributen opgeslagen in de subtabellen), het kan de extra moeite waard zijn om te bouwen en te onderhouden. Zo niet, dan bent u weer terug bij af:een logisch model dat moeilijk te implementeren is in het gemiddelde moderne RDBMS.