0

特定の国に多くの観光スポット (モニュメント、公園、博物館) があるとします。もちろん、特定の観光スポットが多くの州に存在する可能性があります。

論理 ERD モデルに関しては、M:N 関係の間でジャンクション テーブルを使用する必要があります。

しかし、単純に隣接する 2 つのテーブルの PK をジャンクション テーブルの PK として使用するだけで十分でしょうか?

つまり、COUNTRY、SIGHTS、および SIGHT_TYPE テーブルがあり、SIGHTS はジャンクション テーブルです。特定の国に複数の博物館があると仮定すると (つまり、MUSEUM は SIGHT_TYPE です)、これは SIGHTS テーブルの各レコードを一意に識別できないことを意味しますね。

つまり、MUSEUM の SIGHT_TYPE_ID が 2 で、GERMANY の country_id が 22 であると仮定します。複数の美術館の場合、上記が当てはまる場合、これは発生しませんか? 22 2 - ミュージアム A 22 2 - ミュージアム B

したがって、SIGHT_ID などの代理キーの使用は、この場合、一意の識別子として機能するために絶対に不可欠ですか?

つまり、隣接する2つのテーブルのPKを結合テーブルや複合テーブルのPKとして利用するのが一般的ですが、このような場合は例外なのでしょうか?

ありがとうございました

4

1 に答える 1

0

ジャンクション テーブル (FK で構成される) の複合キーは、論理設計レベルでは完全に問題ありません。それらは、ジャンクション テーブル内の行の一意性を保証します。また、関係の特定のインスタンスのすべての参加者が、関係の 1 つのインスタンスのみに参加することも保証します。ある種のアプリ ビルダー ツールを使用している場合、そのツールは複合 PK を処理できる必要があります。

通常、その制約はまさにあなたが望むものです。ジャンクション ボックスに追加の列を追加して主キーとして機能させる場合、2 つの外部キーに一意の制約を追加するか、誤った重複を防ぐためにアプリケーションに依存する必要があります。ほとんどの場合、これらのソリューションは適切ではありません。

物理的な設計レベルでは、データをどうするか、格納するデータの量、および特定の DBMS によって異なります。私は、最初の設計では追加の代理キーを使用せずに、コスト以上に節約できる場合にのみ追加する傾向があります。

于 2014-10-05T11:17:04.650 に答える