DBデータベーススペシャリスト試験 午後Ⅱ
令和7年度秋期 データベーススペシャリスト 午後Ⅱ 問1
事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。
問題

















解き方のヒントを見る
判断の前提と検討範囲をそろえる
この分野を検討するときは、判断の前提と、その判断が及ぶ範囲をそろえることに注目しましょう。ある範囲で成り立つ説明を別の範囲へ広げていないか、根拠となる条件との対応を丁寧に確かめてください。
この問題で問われていること
考える対象について、どこまでをひとまとまりとして扱っているかを意識してください。結論を急がず、示された条件と判断の範囲が対応しているかという一つの観点で、手元の情報を整理してみましょう。
視点
同じ話題についての情報でも、検討する範囲が異なると、そのまま結び付けて考えられるとは限りません。まずは各情報をどの範囲の話として扱うかを意識し、判断に使う前提と対応させて整理しましょう。
確認ポイント
- 判断に用いる前提を確認したか
- その前提が適用される範囲を意識したか
- 判断の途中で対象の範囲を変えていないか
正解と解説を見る
解説
決済とポイントの連携処理を題材に、SQLによる残高反映、分離レベルの選択、2相コミットの障害回復を考える問題です。さらに、サービス分割とNoSQLへの移行に伴う重複更新や一時的な不整合に対し、識別子、更新中フラグ、消込履歴、補償処理を設計します。
問題の全体像
A社は、入金した決済残高と獲得したポイントを組み合わせて支払えるサービスを提供しています。現行システムは二つのRDBMSを2相コミットで連携しますが、ポイント利用の急増を受け、サービスを分割してポイントDBをNoSQLに変更する案を検討しています。変更後は複数操作をまとめて確定できないため、再実行による重複更新の防止や、確定済みの変更を取り消す補償処理が必要になります。公式解答例の出題趣旨では、ACIDを重視する方式とBASEによる可用性を重視する方式の特徴を踏まえ、データ操作、排他制御、分散トランザクション、テーブル構造を設計する能力を問うとされています。
設問1(1)(a)
表5のP2-1では、ポイント残高に未反映の獲得ポイントを有効期限年月ごとにまとめます。SELECTにはポイント会員#と有効期限年月があり、同じ列でGROUP BYしているので、各グループの獲得ポイント数を合計する集約関数が必要です。公式解答例では「SUM(獲得ポイント数)」です。この合計が、後続の更新・追加で使う加算ポイント数になります。
設問1(1)(b)
表1では、残高反映FがTRUEなら加算済み、FALSEなら未加算と定義されています。P2-1の処理対象は未反映の行なので、会員番号の条件に加えて未加算であることを指定します。公式解答例では「残高反映F IS FALSE」です。加算済みの行まで集計すると、同じ獲得ポイントを再び残高に加算してしまいます。
設問1(1)(c)
MERGEの対象であるポイント残高の別名がA、獲得ポイントを集計した結果の別名がBです。WHEN MATCHEDは、同じ会員・有効期限年月の残高行が既に存在する場合に対応します。既存の残数に今回の集計値を加えるため、公式解答例では「残数 = A.残数 + B.加算ポイント数」です。既存残数を集計値で置き換えるのではなく、加算する点に着目します。
設問1(1)(d)
WHEN NOT MATCHEDでは、該当するポイント残高の行を新規追加します。INSERTの列順は、ポイント会員#、有効期限年月、残数、有効Fです。最後の有効Fには既にTRUEが記述されているので、空欄には残り三列に対応する集計結果を同じ順番で指定します。公式解答例では「B.ポイント会員#、 B.有効期限年月、 B.加算ポイント数」です。
設問1(2)(a)
表3では、S1-2で決済会員の最終入金#を更新してから、S1-3でその値を参照して入金履歴を追加します。本文のREAD COMMITTEDでも、更新時に取得した専有ロックはトランザクション終了まで保持されるため、参照前に対象行が保護されています。また、同じ行を繰り返し読み込む処理ではありません。公式解答例はこの二つを理由として示しています。30字以内では「参照する行の専有ロックを事前に取得するから」のように、READ COMMITTEDで足りる具体的な理由を示します。
設問1(2)(b)
表6のP3は、P3-1で使用可能ポイント数を集計し、P3-2で対象行を改めて読み込んで消費します。この間にP2がポイント残高の行を追加すると、集計時と消込時で対象行の集合が変わる可能性があります。本文のREPEATABLE READは既存行をロックしますが、新しい行の追加を防ぐ表単位のロックではありません。公式解答例では、P2の追加行によるファントムリードを理由としています。30字以内なら「P2の追加行のファントムリードが発生するから」と要点を示せます。採点講評でも、現象の発生条件を理解して分離レベルを判断することが求められています。
設問2(1)(a)
図4の③と⑤は個々の処理の完了であり、全体のコミットを保証する応答ではありません。⑦と⑨は各DBのコミット準備完了で、⑨を受信すると決済APは両DBがコミットできることを確認できます。公式解答例では「⑨」です。本問では、両DBの準備完了を受けてコミットを決定できる時点を、正常に終了するとみなす時点としています。⑬のコミット完了応答まで待つという判断との違いを押さえます。
設問2(1)(b)
ポイント不足なら、決済残高とポイント残高を組み合わせた決済は成立しません。図4では既にS2が実行されていますが、その更新はまだコミットされていないので取り消せます。公式解答例では、⑥と⑧で送るメッセージは「ロールバック実行指示」です。両DBに同じ取消指示を送り、片方だけの更新が確定することを防ぎます。
設問2(1)(c)
時点AはポイントDBのコミット準備の段階であり、準備できたこととコミットが確定したことを区別する必要があります。時点Bはコミット実行指示を受けた段階です。公式解答例では、Aはコミット・ロールバックが不定のIn doubt、Bはコミットが確定したIn commitと説明しています。45字以内では「時点Aはコミットかロールバックか未定、時点Bはコミット確定の状態」と、結果が確定しているかどうかを対比します。
設問2(2)(a)(e)
事例1では、再起動後のポイントDBにコミット準備のログが残っています。未コミットでも、準備状態を回復できており、コミット実行の指示を受けられる状態です。公式解答例のeは「コミット実行指示」です。決済APは両DBにこの指示を送り、決済残高とポイント残高の変更をそろえて確定させます。準備ログがあることを、既にコミット済みであることと混同しないようにします。
設問2(2)(a)(f)
事例2では、ポイントDBにコミット準備のログがなく、そのトランザクションは既にロールバックされています。ポイント側の変更が取り消された以上、決済側だけをコミットすると整合性が失われます。公式解答例のfは「ロールバック実行指示」です。決済DBの未確定の変更も取り消し、両DBの結果をそろえます。
設問2(2)(a)(g)
事例3の時点Bではコミットが確定しており、ポイントDBは再起動後にロールフォワードによってデータを回復しています。決済DBも図4の⑪までにコミットを完了しているため、決済APはポイントDBの状態を確認して処理を終えられます。公式解答例のgは「トランザクションを終了」です。準備状態からの回復と、コミットが確定した更新を再現する回復との違いが判断の根拠になります。
設問2(2)(b)
事例4では、ポイントDBの復旧を待つ間、決済DBの仕掛り中のトランザクションが終了できません。更新に伴うロックも保持されるため、該当会員の決済完了や、その会員による次の利用に影響します。公式解答例では、ポイント会員が決済完了を長時間待たされること、同じポイント会員が決済サービスを利用できなくなることを挙げています。30字以内なら「ポイント会員が決済の完了を長時間待たされる」と具体化できます。採点講評では、一方のDB障害でサービス全体が停止するとした解答が誤りとして指摘されています。
設問2(2)(c)
事例4では、決済DBの仕掛り中の変更をヒューリスティックな決定でコミットし、ポイントDBでは未コミットの変更をロールバックしています。したがってS2の決済残高の減算は残り、P3のポイント消費は取り消されます。公式解答例では、決済残高だけを消費してポイント残高を消費していない不正な状態です。40字以内なら「決済残高だけが消費され、ポイント残高は消費されていない状態」と、両残高の結果を示します。
設問3(1)(a)(テーブル名)
図7では、S2が終了していても応答を受信できなければ、同じ実行指示がリトライされる可能性があります。表4のS2-3は決済履歴を追加するので、この履歴に要求の識別子を保存すれば、同じ決済が実行済みか確認できます。公式解答例のテーブル名は「決済履歴」です。残高の値だけでは、どの要求によって更新されたかを判別できない点に着目します。
設問3(1)(a)(列名)
図6の決済指示#は、決済指示ごとに一意に採番され、トランザクションの識別子として他サービスに連携されます。同じ要求のリトライを見分けるには、この識別子を決済履歴に保存します。公式解答例の追加列は「決済指示#」です。既存の履歴#は行の追加時に自動設定される番号なので、同じ要求が再送されたことを識別する役割とは異なります。
設問3(1)(a)(処理概要)
S2の先頭で、今回の決済指示#に対応する履歴が既にあるか確認します。あれば実行済みと判断して終了し、S2-2の残高減算とS2-3の履歴追加を繰り返さないようにします。公式解答例もこの存在確認と終了を示しています。40字以内なら「決済履歴に決済指示#が一致する行があれば処理を終了する」とまとめられます。採点講評では、APIを呼び出す方式で要求の重複処理を防ぐ仕組みを設計する重要性が指摘されています。
設問3(1)(b)(先頭)
変更後のポイントDBでは、P3の各ステップの間に他の処理が同じ会員のデータを更新できるため、処理全体を通じた排他制御が必要です。そこでポイント会員の更新中Fを、P2とP3に共通する使用中の印として使います。公式解答例では、TRUEなら更新中エラーを設定して終了し、FALSEならTRUEに更新します。60字以内なら「更新中FがTRUEなら更新中エラーを設定して終了し、FALSEならTRUEに更新する」と、両状態への対応を示します。
設問3(1)(b)(末尾)
先頭で更新中FをTRUEにしたままでは、後続のP2やP3が更新中と判断して実行できません。処理の末尾では、同じ会員への更新を再び受け付けられるようにします。公式解答例では「更新中FをFALSEに更新する」です。この表現は20字以内に収まり、先頭で設定した排他状態を解除する操作を示しています。
設問3(2)(a)(h)
表4のS2-2は、決済残高から決済金額を減算します。その補償では、対象会員の現在の残高に同じ決済金額を加算し、今回の減算を打ち消します。公式解答例では、決済会員の決済残高テーブルの残高に決済金額を加算して更新します。40字以内なら「決済会員の決済残高の残高に決済金額を加算する」と、対象と逆操作を示せます。補償は、確定済みの変更を別の更新処理で取り消すものです。
設問3(2)(a)(i)
表4のS2-3は、今回の決済を決済履歴に追加します。補償では、その決済に対応する履歴行だけを削除します。設問3(1)(a)で追加した決済指示#を使えば、連携された指示と履歴を対応付けられます。公式解答例も、決済指示#が一致する行の削除を示しています。40字以内なら「決済履歴から決済指示#が一致する行を削除する」と、削除対象を限定して書けます。
設問3(2)(b)(j)
P3-2では、一回のポイント使用を有効期限年月の早い残高から順に消し込みます。合計の使用ポイント数だけでは、どの年月の残数をいくつ減らしたか分からず、元に戻せません。図8には消込ポイント数が既にあるので、どの決済指示の、どの有効期限年月に対する消込かを識別する列が必要です。公式解答例では「決済指示#、有効期限年月」で、両方が複合主キーです。表記は「<u>決済指示#</u>,<u>有効期限年月</u>」のように両列へ実線の下線を付けます。採点講評でも、決済指示#を主キーの一部としない解答が指摘されています。
設問3(3)(事例)
表9の事例7では、P3-2のポイント消込が終了した後、P3-3の実行中にポイントサービスが停止します。オーケストレーターはリトライ後、P3-2から逆順に取消を指示しますが、停止中のポイントサービスでは残数を戻す補償を完了できません。公式解答例では「事例7」です。ポイントDB内に既に確定した残数の減少があり、その取消が遅れることに着目します。
設問3(3)(内容)
事例7では、P3-2による残数の減少が確定しています。決済を取り消す方向に進んでも、ポイント側の補償が完了するまでは、その減少が残ります。公式解答例では、取消処理が完了するまでポイント残高テーブルの残数が消費された状態になると示しています。50字以内なら「取消処理が完了するまで、ポイント残高の残数が消費された状態になる」とまとめられます。変更後の方式では、確定済みの更新を後から補償するため、一時的な不整合が生じることが要点です。
学習のポイント
既存行の保護とファントムリード防止の違い、2相コミットの準備と確定の違い、再実行の識別と補償に必要な情報を重点的に学習します。
出典:独立行政法人 情報処理推進機構(IPA)令和7年度秋期 データベーススペシャリスト試験 午後Ⅱ 問1(公式資料:問題冊子(PDF) / 解答例 / 採点講評)
関連する過去問一覧
IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針