web-dev-qa-db-ja.com

1つのエンティティに属性がない場合の多対多の関係

多対多の関係をリレーショナルモデルにマッピングすることに興味があります。

基本的なアプローチは、エンティティを多対多の関係で接続する3番目のテーブル（関連エンティティ）を作成することです。しかし、エンティティの1つに属性がない場合はどうなりますか？本当に3つ目のテーブルが必要ですか？

たとえば、エンティティのユーザーとクラスターを考えてみましょう。 1人のユーザーが複数のクラスターに属することができ、1つのクラスターに複数のユーザーを含めることができます。そして、「所属」などの3番目のテーブルを作成できます。しかし、クラスターに属性がない場合、本当に必要ですか？その場合、user_idキーを外部キーとしてクラスターテーブルに配置し、そのペア（user_id、cluster_id）を複合キーと見なすことができますか？

別のテーブルを作成するメリットはないようです。クラスターに属性がある場合、各クラスターのすべての情報を繰り返すことは意味がありません。ただし、属性がない場合は、どちらの場合も同じ量の情報が保存されるため、別のテーブルを作成するか、user_idキーをクラスターテーブルに配置します。

私は混乱しています、正しいことは何ですか？

database-designrelational-theorymany-to-many
4
Marko

クラスターに本当に属性がない場合は、属性はありません。これらのエンティティ用の個別のテーブルは必要ありません。次のようにします：

User            UserCluster
====            ===============
UserID (PK) --> UserID (FK, PK)
UserProp1       ClusterID (PK)
UserProp2
...
UserPropN

ただし、エンティティのプロパティが完全にゼロであるのは珍しいです。通常、表示目的で少なくとも人間にわかりやすい名前が付けられています。もちろん、クラスターのIDを名前と同じにすることもできますが、名前が変更される可能性があるため、通常これを行うことはお勧めしません（可能な場合、主キーはエンティティの存在中に不変の値にする必要があります）。

0
David Spillett

実行する「正しい」ことは異なります。

将来的にクラスターが属性を持つようになる可能性がある場合は、はい、結合テーブルが必要です。

それ以外の場合、データの正規化に懸命に取り組んでいる場合は、結合テーブルを用意する必要があります。サイズ/パフォーマンスのマイナーな向上についてより懸念がある場合は、追加のテーブルをスキップできます。個人的には、未来を見るタイムマシンがないので、とにかく余分なテーブルを作ってしまいます。

1
Gareth Webb