DBデータベーススペシャリスト試験 午後Ⅰ
令和7年度秋期 データベーススペシャリスト 午後Ⅰ 問3 オフィスじゅう器メーカーの在庫管理システムのデータベース実装
事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。
問題





解き方のヒントを見る
処理の目的と前提を対応づける
SQLの実行や同時利用、索引の検討では、個別の用語を暗記するより、何を守り、何を効率化したい処理なのかを先に整理して、設問に示された条件や制約と対応づけて考えます。
この問題で問われていること
一つの観点として、各記述が示す仕組みの目的と、成立するための前提条件が対応しているかに注目し、処理の対象・順序・影響範囲を問題文に沿って丁寧に確認してください。
視点
処理を考えるときは、まず達成したい目的を明確にし、その目的に関係する対象と前提を整理します。次に、記述がその関係を一貫して説明しているかを、用語の印象ではなく条件の対応で確かめます。
確認ポイント
- 記述が前提としている対象と条件を確認する
- 目的と処理の関係が同じ観点で説明されているか確認する
- 結果だけでなく影響範囲と順序にも注目する
正解と解説を見る
解説
在庫履歴の効率的な作成、中央移動平均の算出、在庫引当時のデッドロック回避、並列処理に適した索引設計を問う問題です。
問題の全体像
Y社は、10年間稼働した在庫管理システムを更改しようとしている。問題は、既存の在庫・出庫・入庫データを履歴表へ効率的に蓄積するSQL、7日間の中央移動平均、在庫引当APで発生するデッドロック、在庫反映APの並列化に伴う索引設計を扱う。出題の狙いは、SQLの構文だけでなく、業務処理の流れ、ロックの取得・解放、索引の探索条件と更新負荷を関連付けて改善策を考えることにある。
設問1(1)
SQL1では、前日の在庫数量を基準に、当日の出庫を減算し、当日の入庫を加算する。したがって、出庫状況と入庫状況の集計はそれぞれ SUM(出庫数量)、SUM(入庫数量)となり、結合後に参照する別名は当日出庫数量、当日入庫数量となる。SQL2では、在庫履歴を倉庫コードと部品番号ごとに分け、履歴年月日順に7行の窓を作る。中央の年月日の前後3日を含めるため、範囲は3 PRECEDING AND 3 FOLLOWINGであり、平均対象は在庫数量です。よって、公式解答例は a=SUM(出庫数量)、b=SUM(入庫数量)、c=当日出庫数量、d=当日入庫数量、e=AVG(在庫数量)、f=倉庫コード、 部品番号、g=履歴年月日、h=3、i=3としている。
設問1(2)
中央移動平均は、対象日の前後3日を含む計7日間のデータが必要です。問題文で7日間のデータがそろわない期間は対象外と明記されているため、COUNT(*) OVER 移動平均区間 が7未満の場合は、CASE式のELSE句でNULLにする。25字以内では「計7日間のデータがそろわない期間は対象外だから」とまとめられる。
設問2(1)
図3の①は在庫数量と引当済在庫数量をSELECTして出庫可能在庫数量を判定する処理であり、REPEATABLE READでは読み取った行の共有ロックが保持される。その後、②で引当済在庫数量をUPDATEするため専有ロックを取得し直す。別APも①で同じ行を共有ロックしていると、互いに②の専有ロックを待つためデッドロックになる。したがって、j=①、k=②です。
設問2(2)
最終更新TS列を利用する案では、①のSELECTで現在のTS値も読み取り、①の後にCOMMITして共有ロックを解放する。②のUPDATEは、読み取ったTS値と現在のTS値が一致する場合だけ実行することで、他APによる更新を検出する。更新対象がなければ、処理をやり直す必要があるため、図3の①に戻る。公式解答例は、l=最終更新TS列の値も取得、m=最終更新TS列が①で取得した値と一致する、n=①としている。
設問2(3)
READ COMMITTEDでは①の共有ロックが早く解放されるため、複数APが同じ在庫行を読み取ってから更新する可能性がある。その場合、それぞれが同時点の在庫数量を基に出庫可能在庫数量を判定し、要求数量の合計が出庫可能在庫数量を超過しても更新できると、引当済在庫数量が過大になる。したがって、oは「出庫可能在庫数量を超過」です。
設問2(4)
ISOLATIONレベルを変更せず、①で読み取った直後から対象行を専有ロックすれば、別APが同じ行を同時に読み取ることを防げる。問題文の仕様ではSELECT文にFOR UPDATE句を指定すると対象行の専有ロックを取得できるため、pは「FOR UPDATE句を指定」です。
設問3(1)
並列化後は、各プロセスが出庫倉庫コードと部品番号の範囲を担当し、出庫表の処理状況を確認して対象行を更新する。処理要否の判定を索引探索にするには、WHERE条件の列を先頭から連続して索引キーに含める必要があるため、q=出庫、r=出庫倉庫コード、s=部品番号となる。他APが処理を進めると処理状況を更新するのでt=更新であり、表探索でその行を参照すると、他APの更新ロックによりu=ロックの解放待ちが起こり得る。SELECTで処理状況まで索引に含めれば表の行を読まずに判定できるため、v=処理状況です。
設問3(2)
処理状況列を索引キーに加えると、出庫の処理が進むたびに処理状況の値が変化する。そのたびに索引キーの値も変わり、索引を更新する必要があるため、更新頻度が増加する。30字以内では「出庫の処理が進むたびに索引キーの値が変わるから」と書ける。
学習のポイント
集計SQL、ウィンドウ関数、楽観的排他制御、索引更新コストを一連の業務要件と結び付けて学ぶ。
出典:独立行政法人 情報処理推進機構(IPA)令和7年度秋期 データベーススペシャリスト試験 午後Ⅰ 問3(公式資料:問題冊子(PDF) / 解答例 / 採点講評)
関連する過去問一覧
IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針