Vielleicht möchten Sie ein Type/SubType-Datenmodell in Betracht ziehen. Dies ist den Klassen/Unterklassen in der objektorientierten Programmierung sehr ähnlich, aber viel umständlicher zu implementieren, und kein RDBMS (das mir bekannt ist) unterstützt sie nativ. Die allgemeine Idee ist:
- Sie definieren einen Typ (Gebäude), erstellen eine Tabelle dafür und geben ihm einen Primärschlüssel
- Sie definieren zwei oder mehr Untertypen (hier Krankenhaus, Klinik, Schule, Universität), erstellen Tabellen für jeden von ihnen, erstellen Primärschlüssel ... aber die Primärschlüssel sind auch Fremdschlüssel, die auf die Gebäudetabelle verweisen
- Ihre Tabelle mit einer „ObjectType“-Spalte kann jetzt mit einem Fremdschlüssel auf der Building-Tabelle erstellt werden. Sie müssten sich an ein paar Tischen anschließen, um festzustellen, um welche Art von Gebäude es sich handelt, aber das müssten Sie trotzdem tun. Das, oder redundante Daten speichern.
Sie haben das Problem mit diesem Modell bemerkt, richtig? Was hindert ein Gebäude daran, Einträge in zwei oder mehr der Untertyptabellen zu haben? Gut, dass Sie gefragt haben:
- Fügen Sie eine Spalte, vielleicht „BuildingType“, zu Building hinzu, sagen Sie char(1) mit zulässigen Werten von {H, C, S, U}, die (duh) den Gebäudetyp angeben.
- Erstellen Sie eine eindeutige Einschränkung für BuildingID + BuildingType
- Haben Sie die BulidingType-Spalte in den Untertabellen. Legen Sie eine Check-Einschränkung darauf, sodass sie immer nur auf den Wert gesetzt werden kann (H für die Krankenhaustabelle usw.). Theoretisch könnte dies eine berechnete Spalte sein; in der Praxis wird dies wegen des folgenden Schritts nicht funktionieren:
- Erstellen Sie den Fremdschlüssel, um die Tabellen mit beiden Spalten zu verknüpfen
Voila:Bei einem BUILDING-Zeilensatz mit Typ H kann ein Eintrag in der SCHOOL-Tabelle (mit Typ S) nicht so eingestellt werden, dass er auf dieses Gebäude verweist
Sie werden sich erinnern, dass ich gesagt habe, dass es schwer zu implementieren sei.
Tatsächlich ist die große Frage:Lohnt sich das? Wenn es sinnvoll ist, die vier (oder im Laufe der Zeit mehr) Gebäudetypen als Typ/Untertyp zu implementieren (weitere Normalisierungsvorteile:ein Ort für Adresse und andere Attribute, die jedem Gebäude gemeinsam sind, wobei gebäudespezifische Attribute in den Untertabellen gespeichert sind), Es kann sich durchaus lohnen, zusätzliche Anstrengungen für den Aufbau und die Wartung zu unternehmen. Wenn nicht, dann sind Sie wieder bei Null:ein logisches Modell, das in einem durchschnittlichen modernen RDBMS schwer zu implementieren ist.
