1


1

3つのエンティティの交差テーブル「多多多」

現在、データモデルの設計に取り組んでいます(これはRDMSによって支援されます)。 これは、組織のメンバーの利益に関連する約3つのエンティティに基づいています。 エンティティは、特典、会員タイプ、およびプロバイダーです。 2つのエンティティを関連付ける標準の多対多の交差テーブルを作成しましたが、3つは作成しませんでした。 誰かがそのようなことをしたかどうか、そして私が避けるべき潜在的な落とし穴があるかどうか疑問に思っています。 テーブルは次のようになります。

create table BENEFIT_MEM_TYPE_PROVIDER
(
   BENEFIT_ID reference BENEFITS not null,
   MEMBERSHIP_TYPE_ID reference MEMBERSHIP_TYPES not null,
   PROVIDER_ID reference PROVIDERS not null,
   primary key (BENEFIT_ID, MEMBERSHIP_TYPE_ID, PROVIDER_ID)
)

この関係についての何かがちょうど私と一緒に座っていないので、私は賢い人々にアドバイスを求めると思いました。

ありがとう

3 Answer


4


_ 誰もがそのようなことをした _

Yes.

_ 潜在的な落とし穴がある場合、私は注意する必要があります。 _

この表のデータから当てはまるかもしれないが、実際には当てはまらないベネフィットメンバーシップ、ベネフィットプロバイダー、およびメンバーシッププロバイダーの間に関係がある場合、これは問題につながる可能性があります。

たとえば、Member-Provider-Benefitには、特定のプロバイダーが関係する場合にのみ特典がメンバーに適用される「制限」がある場合があります。 関係は一般的に真ではない可能性がありますが、何らかの資格があるため、特別な場合として真です。

この場合、単純なSQLクエリでこれらの例外的なケースを適切に検出できるように、この表にその条件を含める必要があります。

つまり、複数のリレーションシップがある場合は、各行のペアワイズリレーションシップも正しいことを確認してください。


3


Yes.

三項関係は非常に広く使用されていますが、二項関係ほど広くは使用されていません。 これは、4次または一般的なn-ary関係にまで拡張できます。

データベース設計でn項関係を確認できる場所の1つは、スタースキーマです。 星の中心にあるファクトテーブルは、n項の関係です。nは、ファクトテーブルによって参照されるディメンションテーブルの数です。

正規化プロセスは、何らかの正規形からの逸脱を検出し、より正規化された同等物を生成するためにテーブルを分解することで構成されます。 分解により、n項関係の順序が低下する場合があります。

スタースキーマは意図的に逆になります。 これが、スタースキーマと正規化が相反するものとして頻繁に見られる理由です。


0


テーブルが第5正規形(5NF)を満たしているかどうかを確認する必要があります。 そうでない場合は、5NFになるように正規化することをお勧めします。