web-dev-qa-db-ja.com

別のジャンクションテーブルに関連するジャンクションテーブル

私はDB構造を定義していますが、正しく実行していないと強く感じています。私は、いくつかのオプションサービス（空港送迎、マッサージ）を提供するように構成できるホテルを持っています。これらのホテルは部屋で予約できます。したがって、各ホテルは、提供するサービスと価格を選択します。現在、私は次の表を持っています（簡略化）：

Guests (id, (PK), name)
Hotels (id (PK), name)
HotelServices (name (PK))
Hotels_HotelServices (id (PK), hotel_id (FK), service (FK), price_value, price_currency)
Rooms (id (PK), hotel_id (FK), number, capacity, price_value, price_currency)
Bookings (id (PK), guest_id (FK), room_id (FK), date_from, date_to)
Bookings_Hotels_HotelServices (id (PK), hotels_hotelServices_id (FK))

この最後のテーブルが私を最も邪魔していますか？ジャンクションテーブルが別のジャンクションテーブルを指すのは好きではありませんが、部屋で予約されたサービスを表す別の方法は考えられません。

そのような状況をモデル化するためのより良い、一般的なアプローチはありますか？

databasedatabase-designrelational-databasemodeling
6
mark951131b

なぜトリプルリファレンスが必要なのですか？サボイはHOTELです。 「トルコ式マッサージ」はSERVICEです。サボイがそれを提供する場合、それはH_Sテーブルのエントリです。

誰かがサボイに滞在している場合、それはホテルを指すBOOKINGテーブルのエントリです。彼らがマッサージも注文した場合、それは予約とサービスを指すB_Sテーブルのエントリです。 SERVICEを直接指すのではなく、H_Sを指す必要はありません。

編集「サービス」の定義がホプテルによって異なり、ホテルによって価格が異なる場合、all興味があるのは価格なら、確かに、価格をH_Sテーブルに保存し、SERVICEテーブルも含めないでください。ただし、サービスに取得する必要がある独自の属性がある場合（たとえば、請求書に記載するため）、サービスは常に必要に応じて参加する別のテーブルに移動する必要があります。数百行または数千行のモデルまたはサービス定義などの準静的データは、実際には「ビッグデータ」ではありません。データベースエンジンは基本的にそれを笑います。アクセス効率が通常問題になるのは、無限の成長の可能性があるもの（ソーシャルメディアのコメントなど）だけです。

4
Kilian Foth

ホテルのサービスが「部屋で予約」されているかどうかはわかりません。会議室や終日プールパスはどうですか？

ホテルにはゲストではない顧客がいるため、「顧客」エンティティの方が適しています。部屋に宿泊しているお客様がゲストです。

また、エンティティ/テーブルには単数形の名前を付ける必要があります。

enter image description here

編集：

他の「ジャンクションテーブル」との関係がある「ジャンクションテーブル」と呼んでも問題はありません。ジャンクションテーブルには、ビジネスドメイン名が含まれていることがよくあります。正当なエンティティ名。たとえば、労働者と船の間のジャンクションテーブルは、WORKER_SHIPではなくCREWと呼ばれる必要があります。そのようにして、ジャンクションテーブル間の関係について気になっていることが、おそらくそれほど気になりません。

4
Tulains Córdova