-3

次の要件を満たすエンティティ関係図を作成しようとしています。

• 各顧客には、名前、本籍地、および社会保障番号があります。

• 各顧客は複数の電話番号を持つことができ、同じ電話番号が複数の顧客によって共有される場合があります。

• 顧客は複数のアカウントを所有できますが、各アカウントは 1 人の顧客が所有します。• 各口座には、口座番号、タイプ (貯蓄、当座預金など)、および残高があります。

• 銀行は、口座ごとに口座明細書を発行し、口座所有者に毎月郵送します。時間が経つにつれて、同じアカウントの複数のステートメントが表示されます。

• 各ステートメントには、発行日とステートメント ID があります。同じ口座の明細書はすべて異なる明細書 ID を持っていますが、2 つの異なる口座が同じ明細書 ID の明細書を持っている可能性があります。たとえば、アカウント A には ID '123' のステートメントがあり、アカウント B には同じ ID '123' の別のステートメントがある可能性があります。

私はこれを実装しました：

ここに画像の説明を入力

いくつかの質問を聞きたいんです：

  1. 何らかの関係がある場合、または説明にそれが示されている場合にのみ、最小最大表記を使用できますか?

  2. 多対多の関係はここで正しく描写されていますか?

  3. Account と Account Statement と StatementID の間の関係を適切に表現できますか?

  4. 私の仮定によると、Account Statement は本当に弱いエンティティでありHas、Statement ID に依存する弱い関係なのでしょうか? issue-date は弱いキーですか?

4

2 に答える 2

1

Q1. はい。それらは、あらゆる関係の場合に使用できます。説明にその情報がない場合でも、情報が存在しないという意味ではありません。

Q2 と Q3 と Q4。 Phone Numberエンティティではなく、多値属性である必要があります。 エンティティではなく、のStatement Id弱いキーにする必要があります。上記の変更を行うと、それが本来あるべきものに依存しているAccount Statementことに気付くでしょう。Account StatementAccount

于 2016-01-15T05:47:31.207 に答える
0
  1. この表記法は、数字が適用されるエッジの近くに数字を配置することに慣れているため、私にとっては少し奇妙です (N-1 の関係と 1-N の関係を持つことは同じではありません)。個人的には、リレーションシップのカーディナリティを常に示すのが好きです。
  2. 次のコメントがあります。
    • 顧客は複数のアカウントを所有できるため、関係のカーディナリティは (1, N) です。
    • アカウントは複数のアカウント ステートメントを生成できるため、関係は (1, N) です。

  3. ステートメント ID を AccountStatement の属性として (および「弱いキー」として) 持つことができ、アカウント番号を複合キーの他のコンポーネントとして使用できると思います (私が見たように、AccountStatement には複合キーがあり、ステートメント ID と口座番号)。

  4. 実際、AccountStatement は弱いエンティティだと思います。3 で述べたことのコンテキストでは、発行日をキーとは見なさず (口座番号と発行日は複合候補キーである可能性がありますが)、Has 関係と StatementID エンティティを削除し、移動します。 AccountStatement の属性へのステートメント ID。

それが役に立てば幸い！

于 2016-01-15T01:48:28.633 に答える