応用情報技術者 2018年 春期 午後 問06

解答の論理構成

• 【問題文】では見積依頼処理について
  「数量及び希望回答日と一緒に入力する。」と明示しています。
  また、相見積り用に新設する一つ目のエンティティには
  「キーに見積依頼番号、属性に見積依頼日と見積依頼者、a をもたせる。」
  と指示されています。
  したがって、a に入る属性名は “希望回答日” となります。
• 図1の凡例では、エンティティ間の関連を線種で区別しています。
  1対1 … 実線（—）
  1対多 … 実線＋矢印（→）
  （多対多は本問に該当なし）
• 【問題文】に記された既存の関連は次のとおりです。
  ・「発注 → 検収（1対1）」
  ・「発注 → 納品（1対多）」
  したがって
  ・b は 1対1 を示す “—”
  ・c は 1対多 を示す “→”
  が正解となります。
• 以上より解答は
  a：希望回答日
  b：—
  c：→

誤りやすいポイント

• 1対1 と 1対多 の線種記号を逆に書く
  （“→” を 1対1 と思い込みやすい）。
• “希望納品日” と取り違える
  「見積依頼」で入力するのは “希望回答日”、
  「発注」で入力するのは “希望納品日” です。
• 図1の凡例を見落とし、線種を文章で書いてしまう
  （「1対1」と記述するだけでは減点対象）。

FAQ

解答の論理構成

1. 相見積りを実現するには、同一の依頼内容を複数の取引先へ送れるように“束ね役”と“取引先別”の二段構えが必要です。本文には
   「一つ目のエンティティは、複数の取引先への見積依頼を束ねるエンティティとして、キーに見積依頼番号、属性に見積依頼日と見積依頼者、a をもたせる。」
   とあり、ここでキーに既に「見積依頼番号」が指定されています。
2. 二つ目のエンティティについては
   「二つ目のエンティティは、各取引先への見積依頼を管理するエンティティとして、キーに d と e、属性に取引先担当者をもたせる。」
   と記述されています。複数取引先へ依頼を出す以上、キーは「見積依頼番号」に対し「取引先番号」を組み合わせた複合主キーにするのが自然です。
3. さらに
   「この変更に伴い、f エンティティにも変更を加えることで、この機能を実装することができた。」
   とあるため、見積依頼にぶら下がる明細エンティティを、取引先別見積依頼へぶら下がる形に修正する必要があります。E-R図には“見積依頼明細”が存在し、従来は親キー「見積依頼番号」のみを外部キーにしていました。相見積り導入後は親が“見積依頼番号＋取引先番号”の複合キーになるため、最も影響を受けるエンティティは“見積依頼明細”です。
4. 以上より
   d＝「見積依頼番号」
   e＝「取引先番号」
   f＝「見積依頼明細」
   が妥当であると結論づけられます。

誤りやすいポイント

• 「見積番号」と勘違いしやすい
  見積は“取引先が回答した後”に発生するエンティティであり、依頼フェーズのキーにはなりません。
• 「見積依頼番号＋見積依頼明細番号」と取り違える
  明細側は取引先を区別せずに商品単位で採番していたため、複合主キーの構成を取り違えがちです。
• f に「見積」や「発注」を選ぶミス
  相見積りで直接変更が必要なのは、見積依頼に従属する“明細”であり、見積や発注の構造には直接影響しない点を見落としがちです。

FAQ

解答の論理構成

1. 集計済みの納品数量を取得する
   • 【問題文】には
     “COALESCE(　　　　　　　　　　　g, 0)”
     とあり、NULL のときだけ 0 を返すように指示しています。
   • LEFT OUTER JOIN で結合する内側サブクエリでは、SUM(DD.納品数量) AS 納品数量計 を出力しているので、空欄 g にはその列を参照する DLI.納品数量計 が入ります。
2. 発注側サブクエリの抽出条件
   • 発注明細を絞り込む条件として
     “WHERE 　　　　　　　　　　　　　h”
     が要求されています。
   • 指定された発注番号を表す埋込み変数“:発注番号”が与えられているため、発注 表（別名 OD）の主キー列を比較する式
     OD.発注番号 = :発注番号
     が h となります。
3. 納品側サブクエリでの集計単位
   • 納品数量を商品ごとに合計するため
     “WHERE DE.発注番号 = :発注番号
     　　　　　　　　　　　　　　i”
     が示されています。
   • SUM を使用しているので GROUP BY が必須です。発注番号と商品番号の組で集計するため
     GROUP BY DE.発注番号, DD.商品番号
     が i に入ります。
4. 最終結果の並べ替え
   • “　　　　　　　　　　　　　　　j” は一覧の表示順を指示する位置です。
   • 要件に “発注した各商品の数量と納品された数量を、商品番号の昇順に一覧表示” とあるので、ORDER BY ORD.商品番号 が j になります。

誤りやすいポイント

• COALESCE の第 1 引数をサブクエリのエイリアスなしで書く
  → 納品数量計 だけでは参照先が曖昧になるため減点対象です。
• GROUP BY に DE.発注番号 だけを書き、DD.商品番号 を漏らす
  → 集計結果が商品単位にならず、SUM が誤った値になります。
• INNER JOIN と LEFT OUTER JOIN を混同し、納品が 0 件の商品が落ちる
  → 問題の要求は「納品数量が 0 の行も表示」です。
• ORDER BY を DLI.商品番号 で記述する
  → 外部結合で NULL が混在する場合、並べ替え結果が乱れることがあります。

FAQ

解答の論理構成

1. 返品処理の制約
   【問題文】では、既存レコードを更新せず「①納品表と納品明細表とそれぞれ新しいレコードを追加」と明記されています。つまり、返品分は“追加”で表現する必要があります。
2. 数量差分の表現方法
   既存レコードを残す条件下で数量を調整する代表的な方法は、差分レコードを登録し、正と負の数量を合算して実在庫を算出する方式です。
3. 属性との対応付け
   納品明細表には【問題文】図1の列「納品数量」が存在します。ここに返品量を負数で記録すれば、元の納品量と相殺でき、かつ返品の事実（負数レコード）が履歴として残ります。
4. 解答導出
   以上より、追加する納品明細レコードは「返品した商品の数量をマイナスで登録したもの」と導けます。

誤りやすいポイント

• 正の数量で新規レコードを追加し、別フラグで区別すると考えてしまう。試験文ではフラグ列の追加が許可されていません。
• 既存「納品数量」を更新して差し引くと誤解する。更新は禁止と明記されています。
• 納品表だけに追加し、納品明細表を変更しないと判断してしまう。返品は商品単位で管理するため明細側も必須です。

FAQ