データベース設計の質問

Question

私は家を格納するデータベースを持っています。各家は複数の施設を持つことができ、各施設は複数の値を持つことができます。

家のタイプ（アパート、ヴィラ、スタジオなど）を保存したいとしましょう。私が考えているのは、ハウスタイプのproperty_typeテーブルと、home_idとproperty_type_idを保存するファシリティテーブルを持つことです。

私の考えは正しいですか？より良い方法がありますか？

Answer 1

これは私が描いたものです。私は少しあなたの定義については、facilityの混乱しています。私は、ジム、フィットネスセンター、屋根付き駐車場のような施設を見ています。

Property table 
| property_id | property_type_id 
    111    001 
    112    002 


Property type table 
| property_type_id | description 
    001    | house 
    002    | apartment 
    003    | villa 


Facility 
| facility_id  | description  | property_id 
| 999   | community bathroom | 111 
| 998   | community kitchen | 111 
| 997   | fitness center |  112 
| 996   | covered parking |  111 
| 995   | covered parking |  112 

Tenant/Owner table 
| owner_id   | property_id 
| 888   | 111 
| 887   | 112 

Answer 2

これは完全に有効な設計ですが、ロケーションが複数のタイプを持つことができる場合はおそらくより適切です。私は通常、ロケーションテーブルの上に直接property_type_idを追加します。このような状況では

は、すべての場所（この場合には思わ）タイプ

EDIT有することを条件とする： O待ち、それが一つの家のように思えるができます複数の施設があります。その場合、house_idを持つファシリティテーブルを作成し、facility_type_idとその他の関連情報をファシリティテーブルに追加します。

Answer 3

あなたのデザインは有効で、何も間違ってはいません。しかし、property_type属性を使用するのではなく、あなたのプロパティ型の継承を使用しないのはなぜですか？テーブル間の継承は、PKとPKの関係を使用して行われます。異なるタイプのプロパティが共通の属性（スーパータイプ/スーパーテーブルに配置される）とサブタイプに入る異なる属性を持つ場合、これの実装はさらに有効性が証明されます。さらに、これらのプロパティの1つが別のテーブルとの関係を持っている可能性もありますが、他のプロパティのすべてに実際にこの関係があるわけではありません。しかし、再び、それはあなたのビジネス要件に依存します。

Answer 4

"施設"とは、プロパティの特徴に似たもの（別の回答に対するあなたのコメントにより、あなたがそう思われる）を意味する場合、あなたが持っているものは多対多より短い、M：M）関係。言い換えれば、（

• プロパティ
• 施設

を、各プロパティには、複数の施設を有していてもよく、そして任意の施設が複数のプロパティに存在することができます。つまり、次の2つの「もの」を持っています特定のプロパティはプールや電子レンジを持つことができますし、プールと複数のプロパティを持つ複数のプロパティを電子レンジで持つことができます）。

リレーショナルデータベースでは、M：M関係は、関連テーブルを使用して表されます。だから、一般的に、あなたの最初の2つの表は、次のようになります。

Property 
------------ 
Property ID 
Description 
etc. 

Facility 
------------ 
Facility ID 
Description 
etc. 

は今、あなたは行ごとに、あなたが与えられた施設に指定されたプロパティを関連付けることができ、テーブルを必要としています。これは次のようになります：

これは基本的に教科書M：Mの関係であり、必要なものを提供する必要があります。