タイプ/サブタイプのデータモデルを検討することをお勧めします。これは、オブジェクト指向プログラミングのクラス/サブクラスに非常によく似ていますが、実装がはるかに厄介であり、RDBMS（私が知っている）はそれらをネイティブにサポートしていません。一般的な考え方は次のとおりです。
- タイプ（建物）を定義し、そのテーブルを作成して、主キーを指定します
- 2つ以上のサブタイプ（ここでは、病院、診療所、学校、大学）を定義し、それぞれにテーブルを作成し、主キーを作成します…ただし、主キーは、Buildingテーブルを参照する外部キーでもあります >
- 「ObjectType」列が1つあるテーブルを、外部キーを使用してBuildingテーブルにビルドできるようになりました。それがどのような建物であるかを判断するには、いくつかのテーブルを結合する必要がありますが、とにかくそれを行う必要があります。または、冗長データを保存します。
このモデルの問題に気づきましたよね？建物が2つ以上のサブタイプテーブルにエントリを持たないようにするにはどうすればよいですか？よろしくお願いします：
- 建物に列（おそらく「BuildingType」）を追加します。たとえば、char（1）の場合、許可されている値は{H、C、S、U}で、建物のタイプを示します。
- BuildingID+BuildingTypeに一意の制約を作成します
- サブテーブルにBulidingType列があります。値（Hospitalsテーブルの場合はHなど）にのみ設定できるように、チェック制約を設定します。理論的には、これは計算列である可能性があります。実際には、次の手順のため、これは機能しません。
- 両方の列を使用してテーブルを関連付ける外部キーを作成します
出来上がり：タイプHで設定されたBUILDING行がある場合、そのビルディングを参照するようにSCHOOLテーブル（タイプS）のエントリを設定することはできません
実装するのは難しいと言ったことを思い出してください。
実際、大きな問題は次のとおりです。これは行う価値がありますか？ 4つ（または時間の経過とともに）の建物タイプをタイプ/サブタイプとして実装することが理にかなっている場合（さらに正規化の利点：すべての建物に共通の住所およびその他の属性用の1つの場所、建物固有の属性がサブテーブルに格納されます）、構築して維持するために余分な努力をする価値があるかもしれません。そうでない場合は、正方に戻ります。これは、現代の平均的なRDBMSでは実装が難しい論理モデルです。