DBデータベーススペシャリスト試験 午後Ⅱ

令和7年度秋期 データベーススペシャリスト 午後Ⅱ 問1

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問1 コード決済業者の決済業務及びポイント管理業務におけるデータベースの実装・運用に関する次の記述を読んで,設問に答えよ。 A社は,バーコードを用いたキャッシュレスの決済サービス,及び商品購入などに応じて一定のポイントを付与するポイントサービスを提供している。A社では,ポイントサービス利用件数の急増を受けて,システムの変更を検討している。 〔業務・現行システムの概要〕 1. サービスの概要 (1) 決済サービス ① 決済サービスを利用する人(以下,決済会員という)は,決済会員登録を行い,金融機関などから一定の金額を決済サービスに入金した上で,物品購入などの支払に充てる。入金及び支払に伴う残高を決済残高という。 ② 決済サービスに加盟する事業者(以下,決済加盟店という)は,決済サービスへの加盟申請,審査を経て決済加盟店登録を受ける。 ③ 決済会員は,スマートフォンなどの携帯端末,決済加盟店の店舗に設置されたPC,POSなどの端末(これらをまとめて,以下,端末という)を使用して,バーコードを読み取ることで支払を行う。同じ決済会員が同時に複数の支払を行うことはない。 ④ 決済は,決済会員の決済残高から支払金額を差し引くことで完了する。 ⑤ A社は,月に1回まとめて決済金額を決済加盟店に支払う。 (2) ポイントサービス ① ポイントサービスを利用する人(以下,ポイント会員という)は,ポイント会員登録を行ってポイントサービスを利用する。 ② ポイントサービスに加盟する事業者(以下,ポイント加盟店という)は,ポイントサービスへの加盟申請,審査を経てポイント加盟店登録を受ける。 ③ ポイント会員は,ポイント加盟店での支払,くじ引き,イベント参加などによってポイントを獲得する。 ④ 獲得したポイントには,有効期限の年月が決まっている。獲得したポイントはポイント残高として貯めておき,支払に充てることができる。 ⑤ 獲得したポイントは,すぐにポイント残高に反映されることもあれば,翌日以降になる場合もある。 (3) サービス間の連携 決済金額の一部をポイントで支払い,残りを決済残高から支払う場合など,両方のサービスを連携した決済を行うことがある。 2. システム構成 現行システムのシステム構成を図1に示す。決済サービス,ポイントサービスそれぞれに専用のサーバ及びRDBMSを用いている。サーバ上ではサービスに用いるアプリケーションプログラム(以下,APという)が稼働している。両サービスを連携した処理は,決済APを介して決済DB,ポイントDBの両方にアクセスする。 図1 現行システムのシステム構成 3. テーブル構造 決済サービス,ポイントサービスのテーブル構造をそれぞれ図2,3に,主な属性の意味・制約を表1に示す。なお,属性名の#は番号,Cはコード,Fはフラグを略した記号である。 図2 決済サービスのテーブル構造(一部省略) 図3 ポイントサービスのテーブル構造(一部省略) 表1 主な属性の意味・制約 4. 主な処理 各サービスの主な処理の内容を表2に,表2中のS1,S2,P2,P3の処理概要とSQL文を表3~6に示す。各処理は一つ以上のステップから成る。表2~6中の二重引用符で囲んだ名前は,図2,3中のテーブル名である。 表2 主な処理の内容 表3 S1の処理概要とSQL文 表4 S2の処理概要とSQL文 表5 P2の処理概要とSQL文(未完成) 表6 P3の処理概要とSQL文 5. 現行システムで使用するRDBMSの排他制御機能 (1) トランザクションのISOLATIONレベルごとの排他制御は,次のとおりである。 ① READ COMMITTEDでは,行の参照時に対象行の共有ロックを取得し,参照終了時に解放する。行の更新時に対象行の専有ロックを取得し,トランザクション終了時に解放する。 ② REPEATABLE READでは,行の参照時に対象行の共有ロックを,行の更新時に対象行の専有ロックを取得し,トランザクション終了時に解放する。 ③ SERIALIZABLEは,行の参照時又は更新時に表単位の専有ロックを取得し,トランザクション終了時に解放する。 (2) READ COMMITTED及びREPEATABLE READでは,SELECT文にFOR UPDATE句を指定すると,行の参照時に対象行の専有ロックを取得し,トランザクション終了時に解放する。 〔現行システムの決済処理〕 決済処理では,表2中の処理S2及びP3を一つのトランザクションとして実行するために,2相コミットプロトコルを用いている。 1. 決済処理の流れ 決済処理の正常実行時のシーケンス図を図4に示す。図中の①~⑬は実行の順番を,時点A,Bは実行の流れにおける特定の時点を表している。 図4 決済処理の正常実行時のシーケンス図(未完成) 2. 障害からの回復 決済処理の実行中に障害によってポイントDBが異常終了する状況を想定した障害・回復の事例を表7にまとめた。表中の時点A,Bは,図4中の時点A,Bに対応している。 表7 決済処理中の障害・回復の事例(未完成) 〔システム変更案の検討〕 ポイントサービスでは,ECサイトを運営する加盟店の増加によって,サービス利用件数が急増し,ポイントDBの応答性能,可用性の低下が問題になっている。その対策として,次のシステム変更案を検討している。 1. システムの構成変更 検討中のシステム構成を図5に示す。業務機能別に会員サービス,決済サービス,ポイントサービスに分け,サービスごとに専用のサーバとデータベースを配置する。各サービスには独立した疎結合のAP及びデータベースを用いて,サービス内部の実装は隠蔽する。サービスに連携するアプリケーションプログラミングインタフェース(以下,APIという)だけを公開し,APIを呼び出すごとに単一のトランザクションとして処理する。端末からのアクセス時には,会員サービスを入り口にして他のサービスに連携する。 図5 検討中のシステム構成 (1) 会員サービス ① 決済会員,ポイント会員の会員情報の登録,端末からの接続認証など会員に関わる機能をもつAP,及び後述する複数サービスが関与する処理の実行制御を担うAPを配置する。 ② 会員DBには,現行システムと同じRDBMSを使用する。“決済会員”,“ポイント会員ランク”及び“ポイント会員”テーブルを配置し,登録,認証に使用する。会員情報の登録,変更は他のサービスにも連携する。 (2) 決済サービス ① 決済APは,ポイントサービスと連携する処理を無効にすることを除いて変更せず,APIを決済APに連携することで,特定の機能を呼び出して実行する方式に変更する。 ② 決済DBは,現行RDBMSのデータベースをそのまま使用する。 (3) ポイントサービス ① ポイントAPは応答性能,可用性を高めるために再構築する。APIをポイントAPに連携することで,特定の機能を呼び出して実行する方式に変更する。 ② ポイントDBをNoSQLに分類されるデータベースに変更し,図3中の全てのテーブルのデータを移行する。新しいポイントDBは,次の特徴をもつ。 ・ワイドカラムデータストアをもち,複数ノードにデータを分散して配置することで,高速性,高可用性を実現している。 ・RDBMSにおけるテーブルと同様に,列及び主キーを定義できる。外部キーは定義できない。CRUD操作命令を行う言語をサポートしていて,表3~6のSQL文と同様の操作を記述できる。 ・複数のCRUD操作命令をまとめて一つのトランザクションとして実行する機能はなく,CRUD操作命令の終了時点でデータへの操作が確定する。 ・2相コミットを実現する機能はない。 2. 処理方式の設計 現行の2相コミットに替えて,次の処理方式を検討している。検討に当たって,ポイントDBに格納するデータの設計には,RDBMSのテーブル構造を用いる。 (1) 処理方式 ① 複数サービスが関与する処理の実行制御を担うAP(以下,オーケストレーターという)を会員サーバに配置する。 ② 端末からの要求ごとにオーケストレーターを割り当て,他サービスへの要求送信と結果受信とを同期的に行うことで,処理を順に実行していく。 ③ オーケストレーターは,ワークフローの機能をもち,登録した処理を状態に応じて実行していく。タイムアウトなどの例外によって処理が異常終了した場合には,処理が成功するまで一定回数のリトライを行う。 ④ リトライを経ても処理が失敗した場合,オーケストレーターは,それ以前に終了した処理について,ワークフローの逆方向に取消処理を順に実行する。取消処理では,データの変更を伴う場合に,そのデータ変更を取り消すトランザクション(以下,補償トランザクションという)を実行する。 (2) 実行制御テーブルの追加 会員DBに“決済指示”テーブルを追加し,オーケストレーターによるトランザクションの実行状態の記録,実行の制御に用いる。追加するテーブルのテーブル構造を図6に示す。“決済指示”テーブルの決済指示#は,決済指示ごとに一意な番号を自動採番し,トランザクションの識別子として使用する。オーケストレーターは,処理実行の指示及び補償トランザクション実行の指示に合わせて,“決済指示”テーブルに対応する行の全列の値を他サービスに連携する。 図6 追加するテーブルのテーブル構造 (3) 決済処理の流れ 決済処理を次のように実行することにした。 ① 決済サービスでは,S2を一つのAPIとして実行する。 ② ポイントサービスでは,P3のステップP3-1~P3-3のそれぞれに対応するAPIを用意し,会員サービスはAPIを順番に実行する。 ③ 会員サービスでは,他のサービスへの実行指示に対する処理結果を“決済指示”テーブルの状態に記録していく。 検討中の決済処理の正常実行時のシーケンス図を図7に示す。図7中の①~⑮は実行の順番を,時点C~Eは実行の流れにおける特定の時点を表している。 図7 検討中の決済処理の正常実行時のシーケンス図 3. テーブル構造及び処理の変更 (1) リトライへの対応 図7中の実行指示に対応する処理の中には,リトライによる実行指示を受けたときに,重複更新の発生が懸念されるものがある。これを避けるためのテーブル構造及び処理の変更を行う。㋑決済サービスでは,対策として図2中の一つのテーブルに列を一つ追加し,処理S2の先頭にステップを一つ追加する。ポイントサービスでも同様の対策を行う。 (2) ポイントDBの整合性確保 表6の処理P3は,ステップごとにデータ操作が確定するので,ステップ実行の合間に他のトランザクションから同じ会員のデータ更新があると,ポイントDB内のデータに不整合が生じるおそれがある。これを防ぐために“ポイント会員”テーブルに更新中Fの列を追加してTRUE又はFALSEを設定した上で,㋒P2及びP3に,それぞれ同じ内容の処理を行うステップを追加する。 4. 補償トランザクションの設計 ここまでの検討結果を踏まえて,決済処理の補償トランザクションを表8にまとめた。表8中の処理IDは表2の処理ID,表8中のステップは表4,6のステップに対応し,補償トランザクションは,図7中の実行指示と同じ単位で実行するものとする。 表8 決済処理の補償トランザクション(未完成) 5. 障害からの回復 表8の補償要否が“要”のステップは,全て補償可否が“可”となるように対策を行った上で,決済処理実行中にポイントサービスが障害によって停止する状況を想定した障害・回復の事例を表9にまとめた。表中の時点C~Eは,図7中の時点C~Eに対応する。 表9 決済処理中の障害・回復の事例 設問1 〔業務・現行システムの概要〕について答えよ。 (1) 表5中の[a]~[d]に入れる適切な字句を答えよ。 (2) 一貫性の観点から,処理実行時のISOLATIONレベルについて答えよ。 (a) 表3の処理S1のISOLATIONレベルはREAD COMMITTEDが適切である。REPEATABLE READである必要がない理由を30字以内で具体的に答えよ。 (b) 表6の処理P3のISOLATIONレベルはSERIALIZABLEが適切である。REPEATABLE READでは不都合がある理由を30字以内で具体的に答えよ。 設問2 〔現行システムの決済処理〕について答えよ。 (1) 図4について答えよ。 (a) “①決済指示”に対応する“決済完了”の応答が欠けている。トランザクションが正常に終了するとみなした時点で決済APから端末に応答を返すとしたら,③~⑬のどのメッセージの受信後か。番号を一つ答えよ。 (b) ポイントDBが④受信後のP3実行において,ステップP3-1でポイント不足エラーを返した場合,⑥及び⑧で同じメッセージを送信してトランザクションを終了する。送信するメッセージの内容を答えよ。 (c) 時点Aと時点Bとでは,トランザクションの状態が異なる。状態の相違点を45字以内で具体的に答えよ。 (2) 表7について答えよ。 (a) 事例1~3の[e]~[g]に入れる適切な字句を次の中から選択して答えよ。 コミット準備指示,コミット実行指示,ロールバック実行指示,トランザクションを終了 (b) 事例4の下線㋐について,発生したと考えられる業務上の不都合を30字以内で具体的に答えよ。 (c) 事例4では,最終的にデータの状態はどのようになるか。40字以内で具体的に答えよ。 設問3 〔システム変更案の検討〕について答えよ。 (1) “3. テーブル構造及び処理の変更”について答えよ。 (a) 本文中の下線㋑について,列を追加する図2中のテーブル名,追加する列名を答えよ。また,追加するステップの適切な処理概要を40字以内で答えよ。 (b) 本文中の下線㋒について,処理P2及びP3の先頭に共通して追加するステップの適切な処理概要を60字以内で,末尾に共通して追加するステップの適切な処理概要を20字以内で答えよ。 (2) “4. 補償トランザクションの設計”について答えよ。 (a) 表8中の[h],[i]に入れる適切な補償処理の概要をそれぞれ40字以内で答えよ。 (b) 表8中の下線㋓への対策として,ポイントDBに図8の“ポイント消込履歴”テーブルを追加して補償を可能にする。図8中の[j]に入れる一つ又は複数の適切な列名を答えよ。なお,主キーの構成列には巻頭の表記ルールに従って実線の下線を付けよ。 図8 “ポイント消込履歴”テーブルのテーブル構造(未完成) (3) “5. 障害からの回復”について答えよ。 表9中の事例5~7のうち,ポイントDB内のデータが一時的に不整合になる事例を一つ答えよ。また,不整合の内容を50字以内で具体的に答えよ。
図1 現行システムのシステム構成。端末から決済AP及びポイントAPへ接続する現行構成。決済APは決済DBとポイントDBの両方に,ポイントAPはポイントDBに接続している。
図1 現行システムのシステム構成。端末から決済AP及びポイントAPへ接続する現行構成。決済APは決済DBとポイントDBの両方に,ポイントAPはポイントDBに接続している。
図2 決済サービスのテーブル構造(一部省略)。決済加盟店,店舗,決済会員,決済残高,入金履歴,決済履歴,加盟店支払の七つの関係スキーマを列挙し,属性と主キー・外部キーの下線を示す。
図2 決済サービスのテーブル構造(一部省略)。決済加盟店,店舗,決済会員,決済残高,入金履歴,決済履歴,加盟店支払の七つの関係スキーマを列挙し,属性と主キー・外部キーの下線を示す。
図3 ポイントサービスのテーブル構造(一部省略)。ポイント会員ランク,獲得方法,付与率,加盟店,会員,残高,会員ランク履歴,獲得履歴,使用履歴の関係スキーマと主キー・外部キーを示す。
図3 ポイントサービスのテーブル構造(一部省略)。ポイント会員ランク,獲得方法,付与率,加盟店,会員,残高,会員ランク履歴,獲得履歴,使用履歴の関係スキーマと主キー・外部キーを示す。
表1 主な属性の意味・制約。決済方式,入金番号,入金方法,ポイント獲得方法コード,有効期限年月と残数,履歴番号,有効フラグ,残高反映フラグの意味及び設定条件を示す。
表1 主な属性の意味・制約。決済方式,入金番号,入金方法,ポイント獲得方法コード,有効期限年月と残数,履歴番号,有効フラグ,残高反映フラグの意味及び設定条件を示す。
表2 主な処理の内容。決済サービスのS1入金処理とS2消費処理,ポイントサービスのP1獲得処理,P2反映処理,P3消費処理について,処理ID,名称及び内容を示す。
表2 主な処理の内容。決済サービスのS1入金処理とS2消費処理,ポイントサービスのP1獲得処理,P2反映処理,P3消費処理について,処理ID,名称及び内容を示す。
表3 S1の処理概要とSQL文。S1の三ステップとして決済残高への加算,決済会員の最終入金番号の更新,入金履歴の追加を示す。各SQL文とホスト変数hv1~hv4の注記を含む。
表3 S1の処理概要とSQL文。S1の三ステップとして決済残高への加算,決済会員の最終入金番号の更新,入金履歴の追加を示す。各SQL文とホスト変数hv1~hv4の注記を含む。
表4 S2の処理概要とSQL文。S2の三ステップとしてFOR UPDATEによる残高確認,決済金額の減算,決済履歴の追加を示す。残高不足時の終了条件とホスト変数の注記を含む。
表4 S2の処理概要とSQL文。S2の三ステップとしてFOR UPDATEによる残高確認,決済金額の減算,決済履歴の追加を示す。残高不足時の終了条件とホスト変数の注記を含む。
表5 P2の処理概要とSQL文(未完成)。未反映の獲得ポイントを有効期限年月ごとに集計して残高へ反映するMERGE文と,残高反映FをTRUEにする更新文を示す。SQL中に空欄a~dがある。
表5 P2の処理概要とSQL文(未完成)。未反映の獲得ポイントを有効期限年月ごとに集計して残高へ反映するMERGE文と,残高反映FをTRUEにする更新文を示す。SQL中に空欄a~dがある。
表6 P3の処理概要とSQL文。使用可能ポイントの集計,有効期限年月の昇順での残数の消込み,ポイント使用履歴の追加を三ステップで示す。カーソル用SQLとホスト変数の注記を含む。
表6 P3の処理概要とSQL文。使用可能ポイントの集計,有効期限年月の昇順での残数の消込み,ポイント使用履歴の追加を三ステップで示す。カーソル用SQLとホスト変数の注記を含む。
図4 決済処理の正常実行時のシーケンス図(未完成)。端末,決済AP,決済DB,ポイントDB間の決済指示,S2・P3実行,コミット準備及び実行を①~⑬で示す。ポイントDBの実行途中に時点A,Bを付記する。
図4 決済処理の正常実行時のシーケンス図(未完成)。端末,決済AP,決済DB,ポイントDB間の決済指示,S2・P3実行,コミット準備及び実行を①~⑬で示す。ポイントDBの実行途中に時点A,Bを付記する。
表7 決済処理中の障害・回復の事例(未完成)。時点A又はBでポイントDBが異常終了した四事例を示す。再始動後の状態に応じた空欄e~gと,ヒューリスティックなコミットを行う事例4の下線㋐を含む。
表7 決済処理中の障害・回復の事例(未完成)。時点A又はBでポイントDBが異常終了した四事例を示す。再始動後の状態に応じた空欄e~gと,ヒューリスティックなコミットを行う事例4の下線㋐を含む。
図5 検討中のシステム構成。端末の入口を会員サービスとし,会員DB,決済サービスと決済DB,ポイントサービスとポイントDBを接続する構成。各サービスを専用サーバに配置する。
図5 検討中のシステム構成。端末の入口を会員サービスとし,会員DB,決済サービスと決済DB,ポイントサービスとポイントDBを接続する構成。各サービスを専用サーバに配置する。
図6 追加するテーブルのテーブル構造。決済指示テーブルの属性,主キーの決済指示番号及び会員番号の外部キーを示す。処理ID,ステップ,モード,状態の設定と外部キーの範囲に関する注記を含む。
図6 追加するテーブルのテーブル構造。決済指示テーブルの属性,主キーの決済指示番号及び会員番号の外部キーを示す。処理ID,ステップ,モード,状態の設定と外部キーの範囲に関する注記を含む。
図7 検討中の決済処理の正常実行時のシーケンス図。端末,会員サービス,決済サービス,ポイントサービス間の処理を①~⑮で示す。S2とP3各ステップの実行,決済指示の登録・更新,時点C~Eを記載する。
図7 検討中の決済処理の正常実行時のシーケンス図。端末,会員サービス,決済サービス,ポイントサービス間の処理を①~⑮で示す。S2とP3各ステップの実行,決済指示の登録・更新,時点C~Eを記載する。
表8 決済処理の補償トランザクション(未完成)。S2及びP3の各ステップについて補償要否,補償可否と理由・処理概要を示す。空欄h,i,P3-2の補償不可理由の下線㋓,網掛け部分及び四つの注記を含む。
表8 決済処理の補償トランザクション(未完成)。S2及びP3の各ステップについて補償要否,補償可否と理由・処理概要を示す。空欄h,i,P3-2の補償不可理由の下線㋓,網掛け部分及び四つの注記を含む。
表9 決済処理中の障害・回復の事例。ポイントサービスが時点C,D,Eで停止する事例5~7を示す。各実行指示を一定回数リトライした後に,オーケストレーターが行う取消実行指示の順序を記載する。
表9 決済処理中の障害・回復の事例。ポイントサービスが時点C,D,Eで停止する事例5~7を示す。各実行指示を一定回数リトライした後に,オーケストレーターが行う取消実行指示の順序を記載する。
図8 “ポイント消込履歴”テーブルのテーブル構造(未完成)。補償を可能にするために追加するポイント消込履歴テーブルの関係スキーマ。括弧内に列名を答える空欄jと消込ポイント数を示し,未完成の構造として掲載する。
図8 “ポイント消込履歴”テーブルのテーブル構造(未完成)。補償を可能にするために追加するポイント消込履歴テーブルの関係スキーマ。括弧内に列名を答える空欄jと消込ポイント数を示し,未完成の構造として掲載する。
解き方のヒントを見る

判断の前提と検討範囲をそろえる

この分野を検討するときは、判断の前提と、その判断が及ぶ範囲をそろえることに注目しましょう。ある範囲で成り立つ説明を別の範囲へ広げていないか、根拠となる条件との対応を丁寧に確かめてください。

この問題で問われていること

考える対象について、どこまでをひとまとまりとして扱っているかを意識してください。結論を急がず、示された条件と判断の範囲が対応しているかという一つの観点で、手元の情報を整理してみましょう。

視点

同じ話題についての情報でも、検討する範囲が異なると、そのまま結び付けて考えられるとは限りません。まずは各情報をどの範囲の話として扱うかを意識し、判断に使う前提と対応させて整理しましょう。

確認ポイント

  • 判断に用いる前提を確認したか
  • その前提が適用される範囲を意識したか
  • 判断の途中で対象の範囲を変えていないか
正解と解説を見る

解説

決済とポイントの連携処理を題材に、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による補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針