解説

• 〔aについて〕
  仕入明細エンティティと販売明細エンティティには共通の属性"仕入番号"と"仕入明細番号"があります。この2つの属性は、仕入明細エンティティ側では（複合）主キーであり、仕入明細（仕入れた青果物のうち、1品目ずつの詳細）を一意に特定します。また、販売明細エンティティ側では（複合）外部キーとなっています。
  
  本文中には「生産者からは複数のパレット（運搬用の荷台）に積まれた青果物を一括で仕入れ，仲卸業者にはパレット単位で販売する」とあるため、仕入明細の1つの品目が複数の仲卸業者に販売された場合には、1つの仕入明細について複数の販売明細が紐付くことが考えられます。つまり、販売明細エンティティには同一の仕入番号・仕入明細番号の値の組を持つ複数のレコードが存在しえるということです。例えば、ある日に青果物Xを10パレット仕入れ、それを仲卸業者Aに5パレット、仲卸業者Bに3パレット、仲卸業者Cに2パレット販売するようなケースです。
  
  したがって、仕入明細エンティティと販売明細エンティティのカーディナリティ（多重度）は1対多であり、[a]には「→」が入ります。
  
  ∴a＝→
  
  〔bについて〕
  販売明細エンティティの（複合）主キーは"販売番号"と"販売明細番号"であり、このうち"販売番号"は販売エンティティの主キーとなっています。販売エンティティは販売明細エンティティをひとまとめにしたものと考えられ、1つの販売に対して複数の販売明細が発生することが想定されています（同一日に同一の販売担当者が同一の仲卸業者に複数種類の品目を販売した場合）。
  
  したがって、販売エンティティと販売明細エンティティのカーディナリティは1対多であり、bには「↓」が当てはまります。
  
  ∴b＝↓
  
  〔cについて〕
  〔現行の取引システムの概要〕には、「販売方法は販売区分として管理される」とあります。販売エンティティには販売区分を表す属性がないので、これが追加すべき属性となります。販売区分エンティティと販売エンティティのカーディナリティは1対多であるにもかかわらず、販売エンティティ側には販売区分エンティティの主キーである"販売区分コード"に相当する属性がありません。よって、cは"販売区分コード"とすればよいと考えられます。この場合、販売エンティティの属性"販売区分コード"は、販売区分エンティティの主キーを参照する外部キーです。外部キーには破線の下線を付けるので、cには「販売区分コード」が入ります。
  
  ∴c＝販売区分コード
  
  
• 〔現行の取引システムの概要〕には「仕入金額は仕入明細のパレット数と単価との積の総和であり，仕入伝票の入力時に取引システムによって算出される。販売金額も仕入金額と同様の方法で求める」とあります。よって、仕入エンティティの属性"仕入金額"は、仕入明細エンティティの属性"パレット数"と"単価"から求めることができます。また同様に、販売エンティティの属性"販売金額"は、販売明細エンティティの属性"パレット数"と"単価"から求めることができます。
  
  計算式などにより、既存の属性から論理的に導ける値を持つ属性を「導出属性（または派生属性）」といいます。上記2つの属性は、パレット数×単価の総和として求めることも可能であり、最小かつ完備の原則から言えば冗長と言えます。ただ、2つの金額を計算で求める場合、行ごと明細をグループ化してパレット数×単価の総和を求める、という計算処理を表参照の度にしなければならず処理性能の低下が懸念されます。"仕入金額"と"販売金額"は、この計算処理を不要にし、処理性能を改善する目的で意図的に追加されていると考えられます。
  
  ∴仕入金額，販売金額

解説

• 〔dについて〕
  〔取引システムの改修〕には「販売担当者が（中略）予約日と仲卸業者の組合せを軸に取りまとめ，それが予約情報として取引システムに入力される」とあり、予約には仲卸業者の情報を記録することがわかります。しかし、予約エンティティには仲卸業者についての属性がないので、仲卸業者を特定できる"仲卸業者コード"を追加する必要があります。この場合、予約エンティティの属性"仲卸業者コード"は、仲卸業者エンティティの主キーを参照する外部キーです。したがって、[d]には「仲卸業者コード」が入ります。
  
  ∴仲卸業者コード
  
  〔eについて〕
  〔取引システムの改修〕には「販売担当者が仲卸業者の希望する品目，産地，パレット数，単価，販売予定日を（中略）それが予約情報として取引システムに入力される。（中略）予約情報は品目や産地に応じて各仕入担当者に割り当てられ，その情報も取引システムに入力される」とあります。よって、予約明細エンティティには品目を示す"品目コード"、産地を示す"産地コード"、"パレット数"、"単価"、そして仕入担当者を示す"仕入担当者コード"を追加する必要があります。このとき、予約明細エンティティの外部キー（追加分）は次のようになります。
  • "品目コード"：品目エンティティの主キーを参照
  • "産地コード"：産地エンティティの主キーを参照
  • "仕入担当者コード"：従業員エンティティの主キー"従業員コード"を参照
  したがって[e]に入る属性は、以下の5つです。
  
  品目コード
  産地コード
  パレット数
  単価
  仕入担当者コード
  
  ∴e＝品目コード，産地コード，パレット数，単価，仕入担当者コード
  
  ※予約情報に対応するために変更されたE-R図（関係する部分のみ）は次のようになります。
  
• 〔取引システムの改修〕には「販売担当者が（中略）予約日と仲卸業者の組合せを軸に取りまとめ，それが予約情報として取引システムに入力される」とあり、予約エンティティは"予約番号"がなくとも、"予約日"，"仲卸業者コード"の組み合わせによっても予約を一意に特定できることがわかります。
  
  複合主キーには、本来持ち合わせている属性だけを使用してテーブルを構成することができるという利点もあるのですが、①SQLの結合演算記述が煩雑になる、②テーブル間の依存度が高くなる、③テーブル構造の仕様変更の影響を受けやすいなどの弊害があります。このようなときはデータをシンプルに扱うために、単一でレコードを特定可能な属性をテーブルに追加し、複合キーの代わりにそれを主キーとする手法が用いられます。この追加されて主キーとなる属性を代用キー（サロゲートキー）といい、通常は連番コードなどのように値の固有性を容易に確保しやすいものを設定します。値自体に業務上の意味がない注文Noや社員IDなどがこれに該当します。予約エンティティで言えば、"予約番号"は代用キー（サロゲートキー）であり、"予約日"，"仲卸業者コード"の組は代理キー（代替キー）という位置付けになります。
  
  本文中には「予約情報を取りまとめる軸は今後変更される可能性がある」とあるので、"予約日"，"仲卸業者コード"を（複合）主キーとしてしまうと、変更時に問題が起こり得ることが想定されます。したがって、これが主キーに代用キーである"予約番号"を用いる理由となります。
  
  ∴予約情報を取りまとめる軸は今後変更される可能性があるから

解説