戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

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


在庫管理システムに関する次の記述を読んで、設問に答えよ。

   M社は、ネットショップで日用雑貨の販売を行う企業である。M社では、在庫管理について次の課題を抱えている。  ・在庫が足りない商品の注文を受けることができず、機会損失につながっている。  ・商品の仕入れの間隔や個数を調整する管理サイクルが長く、余計な在庫を抱える傾向にある。   〔現状の在庫管理〕  現在、在庫管理を次のように行っている。  ・商品の注文を受けた段階で、出荷先に最も近い倉庫を見つけて、その倉庫の在庫から注文個数を引き当てる。この引き当てられた注文個数を引当済数という。各倉庫において、引き当てられた各商品単位の個数の総計を引当済総数という。  ・実在庫数から引当済総数を引いたものを在庫数といい、在庫数以下の注文個数の場合だけ注文を受け付ける。  ・商品が倉庫に入荷すると、入荷した商品の個数を実在庫数に足し込む。  ・倉庫から商品を出荷すると、出荷個数を実在庫数から引くとともに引当済総数からも引くことで、引き当ての消し込みを行う。    M社では、月末の月次バッチ処理で毎月の締めの在庫数と売上個数を記録した分析用の表を用いて、商品ごとの在庫数と売上個数の推移を評価している。  また、期末に商品の在庫回転日数を集計して、来期の仕入れの間隔や個数を調整している。
 M社では、商品の在庫回転日数を、簡易的に次の式で計算している。   在庫回転日数 = 期間内の平均在庫数×期間内の日数÷期間内の売上個数  
 在庫回転日数の計算において、現状では、期間内の平均在庫数として12か月分の締めの在庫数の平均値を使用している。
 現状の在庫管理システムのE-R図(抜粋)を図1に示す。  在庫管理システムのデータベースでは、E-R図のエンティティ名を表名にし、属性名を列名にして、適切なデータ型で表定義した関係データベースによって、データを管理している。
応用情報技術者試験(令和5年度 秋期 午後 問06 図01)
〔在庫管理システム改修内容〕  課題を解決するために、在庫管理システムに次の改修を行うことにした。  ・在庫数が足りない場合は、在庫からは引き当てず、予約注文として受け付ける。なお、予約注文ごとに商品を発注することで、注文を受けた商品の個数が入荷される。  ・商品の仕入れの間隔や個数を調整する管理サイクルを短くするために、在庫の評価を月次から日次の処理に変更して、毎日の締めの在庫数と売上個数を在庫推移状況エンティティに記録する。    現状では、在庫数が足りない商品の予約注文を受けようとしても、在庫引当を行うと実在庫数より引当済総数の方が多くなってしまい、注文に応えられない。そこで、予約注文の在庫引当を商品の入荷のタイミングにずらすために、E-R図に予約注文用の二つのエンティティを追加することにした。追加するエンティティを表1に、改修後の在庫管理システムのE-R図(抜粋)を図2に示す。
応用情報技術者試験(令和5年度 秋期 午後 問06 表01)
応用情報技術者試験(令和5年度 秋期 午後 問06 図02)
 在庫管理システムにおける予約注文を受けた商品の個数に関する処理内容を表2に示す。
応用情報技術者試験(令和5年度 秋期 午後 問06 表02)
〔在庫の評価〕  より正確かつ迅速に在庫回転日数を把握するために、在庫推移状況エンティティから、期間を1週間(7日間)とし て、倉庫コード、商品コードごとに、各年月日の6日前から当日までの平均在庫数及び売上個数で在庫回転日数を集計することにする。  可読性を良くするために、SQL文にはウィンドウ関数を使用することにする。  ウィンドウ関数を使うと、FROM句で指定した表の各行ごとに集計が可能であり、各行ごとに集計期間が異なるような移動平均も簡単に求めることができる。ウィンドウ関数で使用する構文(抜粋)を図3に示す。
応用情報技術者試験(令和5年度 秋期 午後 問06 図03)
 ウィンドウ関数を用いて、倉庫コード、商品コードごとに、各年月日の6日前から当日までの平均在庫数及び売上個数を集計するSQL文を図4に示す。
応用情報技術者試験(令和5年度 秋期 午後 問06 図04)

設問1

図1及び図2中のaに入れる適切なエンティティ間の関連を答え、E-R図を完成させよ。なお、エンティティ間の関連の表記は図1の凡例に倣うこと。

模範解答

a:↓

解説

解答の論理構成

  1. 在庫推移状況エンティティが持つ列
    – 問題文には「在庫推移状況エンティティに記録する」として、列に「倉庫コード」「商品コード」「在庫数」「売上個数」などがあると説明されています。
  2. 生成タイミング
    – 「毎日の締めの在庫数と売上個数を在庫推移状況エンティティに記録する」とあり、1つの倉庫について日次で複数行が蓄積される設計です。
  3. 倉庫エンティティの性質
    – 倉庫エンティティは「倉庫コード」を主キーとし、物理拠点を1行で管理します。
  4. 関連の方向と多重度
    – 1つの倉庫(倉庫コード)に対して在庫推移状況には日付・商品ごとに多数の行がひも付くため、関係は「1対多」で倉庫側が1、多側が在庫推移状況です。
  5. E-R図の表記
    – 図の凡例では1対多を「→」または縦方向の場合「↓」で示すとされており、倉庫から在庫推移状況へ垂直に線が伸びているため、a には「↓」を記入して完成します。

誤りやすいポイント

  • 「入荷」「出荷」など時系列エンティティと混同し、倉庫と在庫推移状況の間を多対多と誤判定する。
  • ウィンドウ関数の説明から横方向の関連を想像して「→」と書いてしまう。
  • 「商品コード」も在庫推移状況の主キー構成要素のため、倉庫との関連を弱めに考えがちだが、あくまで倉庫側は1行のみ。

FAQ

Q: 「↓」ではなく「→」でも1対多を表せませんか?
A: 図の凡例で縦方向の関連は「↓」が正式表記と定められているので、在庫推移状況が倉庫の真下に描かれている本図では「↓」が正解です。
Q: 在庫推移状況の主キーに日付が含まれていても倉庫とは1対多になりますか?
A: はい。複合主キーで複数列を持っていても、倉庫コードについては重複せず複数行を持つため1対多となります。
Q: 商品コードも外部キーですが、倉庫と商品の複合で多対多では?
A: 商品コードとの別の関連は存在しますが、問題の a は倉庫単独との関連を問われています。倉庫1:在庫推移状況多の関係に変わりはありません。

関連キーワード: 1対多、エンティティ、主キー、外部キー、E-R図

設問2〔在庫管理システム改修内容〕について答えよ。

(1)図2中のbcに入れる適切なエンティティ名を表1中のエンティティ名を用いて答えよ。

模範解答

b:引当情報 c:引当予定

解説

解答の論理構成

  1. 追加されたエンティティ名
    【問題文】には「追加するエンティティを表1に」とあり、表1には
    ・「引当情報」―「予約注文を受けた商品の個数と入荷済となった商品の個数を管理する。」
    ・「引当予定」―「予約注文を受けた商品の、未入荷の引当済数の総計を管理する。」
    の二つだけが挙げられています。
  2. 図2のb の属性と照合
    図2でb引当番号・倉庫コード・商品コード・引当済数・入荷済数を持っています。これは表1の説明「予約注文を受けた商品の個数(=引当済数)と入荷済となった商品の個数(=入荷済数)を管理」に完全一致します。したがってb は「引当情報」です。
  3. 図2のc の属性と照合
    図2でc倉庫コード商品コード・未入荷引当済総数を持っています。これは表1の説明「未入荷の引当済数の総計を管理」に該当します。よってc は「引当予定」です。
  4. 表2の処理内容との整合確認
    表2には「e エンティティの未入荷引当済総数から…」とあり、続く行で「入荷した商品の個数を g エンティティの個数に設定」と書かれています。
    ・未入荷引当済総数を操作するのは「引当予定」。
    ・個数(引当済数/入荷済数)を持つのは「引当情報」。
    これも②③の判断を裏付けます。
以上より
b:引当情報
c:引当予定

誤りやすいポイント

  • 「入荷済数」という属性があるので「入荷明細」と混同しやすいが、図2のb引当番号が主キーとして存在する点が決定的な違いです。
  • 未入荷引当済総数は一商品単位ではなく倉庫+商品単位の集計値であるため、個別明細と思い込みb を「引当予定」と誤答しがちです。
  • 表2のefgh を先に埋めずにエンティティ名だけを見比べると判断根拠が弱まり、行き違いを起こすことがあります。

FAQ

Q: 「引当情報」と「引当予定」は似ていますが、最も簡潔に区別するポイントは?
A: 「引当情報」は個別予約注文を表す“明細”で主キーに引当番号を持ち、入荷済数も保持します。一方「引当予定」は未入荷分を合計した“サマリ”で主キーが倉庫コード+商品コードです。
Q: c が在庫エンティティと上下双方向で矢印接続されている理由は?
A: 入荷やキャンセルで「未入荷引当済総数」を更新すると同時に、在庫側でも引当可能数を即時把握したいからです。論理的には在庫と引当予定の相互参照が必要になります。
Q: 表2のf エンティティが「在庫」となる根拠は?
A: 処理内容に「実在庫数と引当済総数に入荷した商品の個数を足す」とあるため、実在庫数と引当済総数の両方を持つエンティティ=「在庫」しか該当しません。

関連キーワード: E-R図、エンティティ、在庫引当、主キー、集計テーブル

設問2〔在庫管理システム改修内容〕について答えよ。

(2)図2中のdに入れる、在庫推移状況エンティティに追加すべき適切な属性名を答えよ。なお、属性名の表記は図1の凡例に倣うこと。

模範解答

d:

解説

解答の論理構成

  1. 現状では「在庫推移状況」エンティティに
    」・「」が存在します(図1の抜粋より)。
  2. 改修方針として【問題文】に
    「在庫の評価を月次から日次の処理に変更して、毎日の締めの在庫数と売上個数を在庫推移状況エンティティに記録する。」
    と明示されています。
    ─── 月次(年+月)で管理していたレコードを、日次(年+月+日)で管理できるようにする必要があります。
  3. さらにウィンドウ関数を用いた集計例(図4)でも
    「SELECT 年、月、日、倉庫コード、商品コード …」
    と「日」列を前提に記述されています。
  4. よって、図2に追加すべき属性は「」となります。

誤りやすいポイント

  • 「在庫推移状況」に既に「入荷日」などがあると勘違いしてしまう。現行スキーマには日付単位の属性がなく、追加が必要です。
  • 改修箇所を図2全体で探すうち、別エンティティの属性と混同する。
  • SQL 文に「日」が出てくるのを見落とす、あるいは試験上“SELECT 句にだけあれば良い”と誤解してテーブル定義の変更を忘れる。

FAQ

Q: 既に「入荷日」や「出荷日」があるのに、なぜ「日」を追加するのですか?
A: 「入荷」や「出荷」は個別トランザクションの日付を保持します。一方、「在庫推移状況」は倉庫・商品ごとに1日単位で締め処理した集計結果を保持するため、日付キー「」が別途必要です。
Q: 「年月日」を 1 つの DATE 型にまとめる設計ではダメですか?
A: もちろん可能ですが、本システムでは既存のキー構成「」「」を踏襲し、最小変更で「」を追加する方針です。既存処理との互換性を優先しています。
Q: ウィンドウ関数を使わないで同じ集計を行うことはできますか?
A: サブクエリや自己結合で 6 日間の範囲を計算することも可能ですが、ウィンドウ関数を利用すると SQL が簡潔になり性能も向上しやすいため、改修ではウィンドウ関数を採用しています。

関連キーワード: ウィンドウ関数、期間集計、ER図、主キー、日次処理

設問2〔在庫管理システム改修内容〕について答えよ。

(3)表2中のehに入れる適切な字句を答えよ。

模範解答

e:引当予定 f:在庫 g:入荷明細 h:入荷済数

解説

解答の論理構成

  1. 「未入荷引当済総数」という語が出てくるエンティティは【表1】で追加された「引当予定」だけです。したがって
    e エンティティの未入荷引当済総数から入荷した商品の個数を引く。」
    e は「引当予定」になります。
  2. 「実在庫数」と「引当済総数」の 2 つを同時に保持しているエンティティは、現行システムから存在する「在庫」です。よって
    f エンティティの実在庫数と引当済総数に入荷した商品の個数を足す。」
    f は「在庫」となります。
  3. 入荷処理で新たにレコードを登録し、個数を記録するエンティティは E-R 図【図2】の「入荷明細」です。そこで
    「入荷した商品の個数を g エンティティの個数に設定し、」
    g は「入荷明細」と判定できます。
  4. 「引当情報」には「引当済数」と「入荷済数」の 2 つの数量列があります。入荷時に増えるのは当然「入荷済数」なので
    「引当情報エンティティの h に足す。」
    h は「入荷済数」です。
以上より
e:引当予定
f:在庫
g:入荷明細
h:入荷済数

誤りやすいポイント

  • 「未入荷引当済総数」という列名だけでなく“未入荷”の業務意味に注目しないと、e を「引当情報」と誤答しやすいです。
  • f を「在庫推移状況」と混同するケースがありますが、締め集計用エンティティには「実在庫数/引当済総数」はありません。
  • g の欄で「入荷」と「出荷」を読み間違え、「出荷明細」を選ぶミスが散見されます。処理タイミングが“入荷したとき”であることを確認しましょう。
  • 「入荷済数」「引当済数」は似た字面のため逆に入れ替えやすいので注意が必要です。

FAQ

Q: 「引当予定」と「引当情報」は何が違うのですか?
A: 「引当情報」は予約注文ごとにレコードを持ち、個別の「引当済数」「入荷済数」を管理します。一方「引当予定」は倉庫・商品単位で“未入荷分の合計”を 1 行で管理し、在庫引当のタイミング制御に使います。
Q: 入荷処理で「在庫推移状況」を更新しないのでしょうか?
A: 「在庫推移状況」は締め処理(日次バッチ)で更新します。リアルタイムな入荷処理では「在庫」エンティティを更新し、日次でその結果をサマリー表へ反映させる設計です。
Q: 入荷済数が引当済数を上回った場合のチェックはどこで行いますか?
A: 業務ロジックとしては入荷済数を足し込む際に「引当済数 ≥ 入荷済数」を担保するか、DB レベルで CHECK 制約を設ける方法が一般的です。本問ではロジック詳細までは問われていません。

関連キーワード: E-R図、在庫引当、予約注文、ウィンドウ関数、在庫回転日数

設問3

図4中のijに入れる適切な字句を答えよ。

模範解答

i:OVER j:ORDER BY

解説

解答の論理構成

  1. 図3にウィンドウ関数の構文として
    「〈ウィンドウ関数〉 ::= 〈ウィンドウ関数名〉(〈列〉) OVER {〈ウィンドウ名〉 | (〈ウィンドウ指定〉)}」
    と明記されています。したがって、図4の
    sql AVG(在庫数) i 期間定義
    には関数とウィンドウを結び付けるキーワード OVER を入れるのが規則どおりです。
  2. 図3の〈ウィンドウ指定〉の中には
    「[〈PARTITION BY 句〉] [〈ORDER BY 句〉] [〈ウィンドウ枠〉]」
    が並びます。図4のWINDOW句では
    sql PARTITION BY 倉庫コード、商品コード j 年、月、日 ASC
    と列の並び替えを宣言する位置に空欄があり、ここには ORDER BY を置く必要があります。
  3. 以上より
    i = 「OVER」
    j = 「ORDER BY」
    が妥当であると結論付けられます。

誤りやすいポイント

  • PARTITION BY の直後にも別途句が続くため、j に誤って PARTITION BY を重ね書きしてしまう。
  • 自前で定義したウィンドウ名「期間定義」を使うとき、関数直後を省略可と誤解し i を空白にしてしまう。
  • ORDER BY をWINDOW句の外側(SELECT句側)に書けば良いと考え、句のスコープを混同する。

FAQ

Q: ウィンドウ名を付けた場合でも関数側に OVER は必須ですか?
A: 必須です。ウィンドウ名を参照する場合でも構文「関数(列) OVER ウィンドウ名」で書くルールです。
Q: ORDER BY がなくても平均や合計は計算できるのでは?
A: 計算自体は可能ですが、本問は「各年月日の6日前から当日まで」という“行の範囲”を ROWS BETWEEN で指定しており、その基準となる行順序を ORDER BY で明示しないと期待どおりに動きません。
Q: 期間を 7 行に限定する部分はどの句ですか?
A: WINDOW句内の「ROWS BETWEEN 6 PRECEDING AND CURRENT ROW」が該当します。ORDER BY で並べ替えた後、現在行を含め 7 行を対象としています。

関連キーワード: ウィンドウ関数、PARTITION BY, ORDER BY, 移動平均、データ分析
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について