次の3項関係を考えます。
すべてのエンティティに2つの属性(PKと名前)しかないと仮定します。
ここに私が導き出した表があります(5つの表):
Sector
-------------------------
ID_Sector SectorName
-------------------------
Product
-------------------------
ID_Product ProductName
-------------------------
Company
--------------------------------------
ID_Company ID_Sector CompanyName
--------------------------------------
Relationship 1 (R1)
-------------------------
ID_Sector ID_Product
-------------------------
Relationship 2 (R2)
-------------------------
ID_Company ID_Product
-------------------------
その三者関係の良い解決策ですか?次の単一のテーブルの代わりに2つのテーブル(R1とR2)を持つことの違いは何ですか?
Ternary table
-------------------------------------
ID_Sector ID_Company ID_Product
-------------------------------------
私には、各リレーションシップ(R1とR2)に2つの別々のテーブルがある方が、1つのテーブルを持つよりも良い解決策のように見えますが、それが実際に当てはまるのか、それとも良い方法なのかはわかりません。
2つのソリューションは異なるルールをモデル化します。三元表では、企業が特定のセクターで特定の製品しか持っていない可能性があると言っています。もちろん、2つのセットは重複する場合がありますが、異なるセクターでは異なる製品のセットがあります。
バイナリテーブルを使用して、セクターが会社が関連する製品に影響を与えないことを示しています。同様に、会社はどの製品がどのセクターにあるかに影響を与えません。
これらの選択肢の選択は、ビジネスルールによって決まります。抽象的で学術的な議論では答えられません。エンティティ間の関係に名前を付けるのが最適です。 thatの会社は製品に関連していると言って面白いです。 why企業が製品に関連している理由は、さらに優れています。 「会社が製品を購入する」は、「会社が製品を製造する」または「会社が製品を使用するためのセキュリティクリアランスを持っていない」とは異なる情報です。これを行うことで、新しい関係、属性、エンティティタイプを発見することがよくあります。バイナリテーブルと3値テーブルの両方が必要になる場合があります。
編集:ルール用
これらのエンティティタイプがあります
セクター-SectorID
会社-CompanyID、SectorID
製品-ProductID、CompanyID
ルールのいずれかが多対多の場合は、バイナリアソシエーションテーブルが必要になります。
余談ですが、関係の名前は、「持っている」、「に属している」、「ある」のように、多くの場合、それらが照らす以上に隠されています。これらを使用しているBAを見つけた場合は、別のことを考えてもらいます。