応用情報技術者 2017年 秋期 午後 問06

解答の論理構成

• 【問題文】のエンティティ一覧によると、販売明細エンティティには
  「仕入番号、仕入明細番号」
  が外部キーとして存在します。これは 1 行の販売明細が必ず 1 行の仕入明細を参照することを示すため、 仕入明細 ― 1 対 多 → 販売明細 となり、a は「→」です。
• 「販売 → 販売明細」のリレーションは 1 対 多ですが、図2では販売エンティティが上、販売明細が下にレイアウトされています。よって矢印の向きは縦方向に下へ延びる形で描かれ、b は「↓」になります。
• 【問題文】には
  「仕入方法は仕入区分として管理され、販売方法は販売区分として管理される。」
  とあります。さらに販売区分エンティティには主キーとして
  「販売区分コード」
  が定義されています。販売エンティティ側に販売方法を示す外部キーが必要なので、c に入るのは
  「販売区分コード」
  です。

誤りやすいポイント

• 仕入明細と販売明細を「多対多」と誤認し、矢印を「←→」にしてしまう。外部キーの有無を確認すれば 1 対 多であることが分かります。
• 矢印の向き（水平か垂直か）を問われていると気付かず、b に単に「→」と書いてしまう。図面上のレイアウトもヒントになります。
• 販売エンティティに何の外部キーが必要かを読み飛ばし、c に「販売方法」や「販売区分名」を書いて失点する。外部キーは必ずコード項目になる点に注意が必要です。

FAQ

解答の論理構成

1. 設問は「他の属性から求めることが可能であるが、処理性能を改善するために追加されている属性」を問うています。つまり
   ①計算で導出できる ②あえて物理列として保持している
   という 2 点を同時に満たす属性を探します。
2. 【問題文】には次の記述があります。
   • 「仕入金額は仕入明細のパレット数と単価との積の総和であり、仕入伝票の入力時に取引システムによって算出される。」
   • 「販売金額も仕入金額と同様の方法で求める。」
     ここで両者は “算出される” と明言されており、計算で求められる属性であることが分かります。
3. 図2のエンティティ「仕入」には属性「仕入金額」、エンティティ「販売」には属性「販売金額」がそれぞれ存在します。これらは
   • 仕入明細の「パレット数 × 単価」の合計
   • 販売明細の「パレット数 × 単価」の合計
     という集計結果であり、別に保持しなくても導出可能です。
4. しかし大量データを毎回集計すると販売伝票 300 件 / 日 × 多明細の計算負荷が高くなるため、トランザクション入力時に確定値を保存し読み取りを高速化しています。
5. よって「処理性能を改善するために追加されている」導出属性は
   仕入金額、販売金額
   であると結論付けられます。

誤りやすいポイント

• “パレット数” や “単価” を選んでしまう
  いずれも入力値であって導出項目ではありません。
• 図2のリレーションシップに気を取られ、図3の新規エンティティを調べてしまう
  設問対象は「図2中」であり、改修後の予約系は関係ありません。
• 「販売金額は販売明細から算出できるのでは？」という疑念
  その疑念こそが設問の狙いで、だからこそ “追加されている” 属性と判断できます。

FAQ

解答の論理構成

1. まず、予約エンティティがどの相手と紐付くかを確認します。問題文には
   　「仲卸業者は複数の品目、複数の産地、複数の販売予定日の青果物を一括で予約できる。」
   　とあり、予約は “仲卸業者” との契約情報であることが明示されています。したがって、予約エンティティには仲卸業者を識別する属性が必須です。図2で仲卸業者を一意に識別するのは「仲卸業者コード」なので、d には
   　仲卸業者コード
   　を設定します。外部キーであることを示す破線下線も忘れません。
2. 次に予約明細エンティティに格納すべき項目を整理します。問題文には
   　「販売担当者が仲卸業者の希望する品目、産地、パレット数、単価、販売予定日を予約日と仲卸業者の組合せを軸に取りまとめ…」
   　とあります。また、 　「予約情報は品目や産地に応じて各仕入担当者に割り当てられ…」
   　とも記載されています。ここから、各予約明細行には少なくとも以下が必要になります。
   　・品目を識別するコード
   　・産地を識別するコード
   　・パレット数
   　・単価
   　・どの仕入担当者に割り当てたかを示すコード

1. 以上より、模範解答のとおり
   　d：仲卸業者コード
   　e：品目コード、産地コード、パレット数、単価、仕入担当者コード
   　が導けます。

誤りやすいポイント

• 予約エンティティと予約明細エンティティを混同し、〈仲卸業者コード〉を明細側に入れてしまう。予約単位で1社に対応するため、仲卸業者コードは親エンティティに置くのが自然です。
• 「仕入担当者は予約情報に基づいて…」という記述を読み落とし、〈仕入担当者コード〉を明細属性に含めない。仕入担当者の割当ては品目・産地ごとに異なる可能性があるため明細側に必要です。
• パレット数・単価を数値属性ではなくコード扱いにして破線下線を付けてしまう。これらはマスタ参照ではないので外部キーにはなりません。

FAQ

解答の論理構成

1. 取引システム改修では、図3に新しく追加する「予約」エンティティの主キーを決める必要があります。
2. 本文には、予約情報の集約単位について「予約情報を取りまとめる軸は今後変更される可能性がある」と明示されています。
3. 集約軸（品目や産地、販売予定日など）が変わると、自然キー（項目の組合せ）では一意性が保証できなくなる恐れがあります。
4. 変更影響を最小化し、常に一意性を保てるよう、業務とは独立した人工的なキー＝代用キー（予約番号）を採用するのが合理的です。
5. 以上より、主キーに代用キーとして予約番号を用いる理由は「予約情報を取りまとめる軸は今後変更される可能性があるから」となります。

誤りやすいポイント

• 自然キー（品目＋産地＋販売予定日など）でも一意になると早合点し、後から軸が変わるリスクを見落とす。
• 「代用キー＝オートナンバー」という単純な暗記で理由を答えられない。背景として“変更に強い設計”を説明できないと部分点を失う。
• 「将来の追加属性に備える」といった漠然とした回答で、本文のキーワード「予約情報を取りまとめる軸」を引用し忘れる。

FAQ

解答の論理構成

1. 返品金額を算出する列 f
   • 返品伝票には単価が存在せず、金額を求めるには別表から単価を取得する必要があります。
   • 【問題文】では「販売伝票の明細部には…パレット数、単価が複数記載される。」と述べられ、さらに「返品が発生した場合には…返品伝票に返品内容の詳細を記録」するとあります。したがって単価は“販売明細”側にあり、数量（パレット数）は“返品”側にあります。
   • 金額集計には単価 × パレット数 を合計する SUM(t2.単価 * t1.パレット数) が適切です。
2. 品目・産地情報を得る結合句 g
   • 返品→販売明細の結合は SQL 4 行目で済んでいますが、品目コードと産地コードは販売明細に直接はありません。
   • 【問題文】で「販売明細 → 仕入明細」は“多対多”のリレーションシップが示され、販売明細が保持する 仕入番号、仕入明細番号 で“仕入明細”にたどれます。
   • よって、品目・産地を取得するために “仕入明細” を追加結合します。キーは両表に共通する 仕入番号、仕入明細番号 なので
     sql INNER JOIN 仕入明細 USING (仕入番号、仕入明細番号)
3. 集計対象列 h
   • SELECT 句に列挙した4列（品目コード、品目名、産地コード、産地名）はグループ化対象にするか、別途集約関数で処理する必要があります。
   • これら4列は“品目”と“産地”から得た「コード」「名称」のセットであり、どちらも同一キーでグループ化できるので、試験では
     • 品目コード、品目名、産地コード、産地名
     あるいは冗長性を避けて名称列を省き
     • 品目コード、産地コード
     のいずれも正答とされています。

誤りやすいポイント

• 返品金額計算に t1.単価 を用いる誤り
  （返品表に単価は無い）。
• g で“販売”や“品目”と結合してしまうミス
  （品目コードは“仕入明細”にある）。
• GROUP BY に数量や集計列を含めてしまう
  （集約関数の結果列は GROUP BY 不要）。
• USING 句の列を書き忘れ、ON 句で冗長に指定してしまう。

FAQ