web-dev-qa-db-ja.com

ERダイアグラム:三者関係-適切な読み方

ERダイアグラム内の3項関係の読み方がよくわかりません。これが与えられた三項関係であるとしましょう。それから私は何を解釈できますか?

account-user-project three-way relation

2つのエンティティセットに手を置いて、そのように読み取る必要があると書かれています。

アカウントとユーザーの引き継ぎ:アカウントとユーザーのペアをMプロジェクトに関連付けることができます。

アカウントとプロジェクトの引き継ぎ:アカウントとプロジェクトのペアをMユーザーに関連付けることができます。

プロジェクトとユーザーの対応:プロジェクトとユーザーのペアを1つのアカウントに関連付けることができます。

ペアは常に1対1の関係ですか、それともいくつのペアが存在できますか?

12
user2276094

遅い答えですが、将来の読者に役立つかもしれません。

三元関係にエンティティA、B、Cが関与していると仮定します(次数> 3の場合、かなり毛むくじゃらになります)。

関係を読み取る方法は、3つの参加エンティティから常に2つを分離し、それらが3番目のエンティティとどのように関連しているかを確認することです。そして、すべての可能なペアに対してこれを行う必要があります。

より正確には、毎回ペアリングする2つのエンティティは、それぞれについて「1つ」と見なされる必要があり、答える質問は、3番目のエンティティの「いくつ」がこのペアに対応できるかです。

抽象例

_"One of A and one of B can {have/associate with/belong to} X? of C"_。 _X?_を_1_またはNにする必要があるかどうかを判断するには、ビジネスモデルに関する知識を使用する必要があります。これは、3項関係をエンティティCに接続するEdgeの3項関係に割り当てるカーディナリティです。

このフレーズは、可能なすべての組み合わせに対して再構成する必要があります(組み合わせの順序は関係ないため、順列ではありません)。したがって、質問_How many pairs are there?_に答えるために、単純な数学では、3つのものを2つのグループにまとめる可能な方法は次のようになります。

3!/(2!*(3-2)!) = 3

したがって、私たちのビジネスモデルを使用して回答する可能なフレーズはすべて次のとおりです。

  • _One of A and one of B can {have/associate with/belong to} ?X? of C_
  • _One of A and one of C can {have/associate with/belong to} ?Y? of B_
  • _One of B and one of C can {have/associate with/belong to} ?Z? of A_

具体例

私が見つけたこの画像を借りています オンライン

enter image description here

このイメージに導いた私たちのビジネスモデルの現実は次のとおりです。

  • _1 Physician with 1 specific Patient can log M Treatments_
  • _1 Physician logs 1 specific Treatment for N Patients_
  • _1 Patient is logged 1 specific Treatment by 1 Physician_

したがって、3項関係logは、参加エンティティ間の_Treatment-Patient-Physician_(この順序で)のM-N-1関係です。

24
Thalis K.

おそらくそれは階層であり、それは多くのアカウントと多くのユーザーがいることを意味します。また、アカウントがユーザーと同等かそれ以下であることも意味します。それは、より多くのユーザーを説明することを意味します。ほとんどの場合、トライで3値データ構造を使用します。

0
Gigamegs

別の遅い答えですが、将来の読者に役立つかもしれません。しかし、はい、あなたは正しい@ user2276094です。

あなたが言及したように、三元関係の多重度は、1つのエンティティ(ターゲットエンティティ)を他の2つのエンティティから分離し、ターゲットエンティティ(たとえば、スタッフ)を他の2つのエンティティ(たとえば、クライアントとブランチ)。

したがって、これらの関係の多重度を次のように表現できます(スタッフが支店でクライアントを登録するなど)。

スタッフオカレンスとブランチオカレンスの固定ペアの場合、クライアントが存在する場合と存在しない場合があります(一部のスタッフはクライアントを登録しないため、他の職務に関与している可能性があります)。

ブランチオカレンスとクライアントオカレンスの固定ペアの場合、唯一のスタッフが存在する必要があります(クライアントは、唯一のスタッフメンバーが一度だけ登録できるため)。

スタッフオカレンスとクライアントオカレンスの固定ペアの場合、存在する必要があるのは1つだけです(クライアントは1つのブランチでのみ登録できると想定しています)。

0
idl99