データベーススペシャリスト午後II 総合事例記述令和7年 秋期
午後II 問1
問1 コード決済業者の決済業務及びポイント管理業務におけるデータベースの実装・運用
テーマ：コード決済業務及びポイント管理業務におけるデータベースの実装・運用（排他制御、2相コミットプロトコル、補償トランザクション）
左右2分割表示：左側の問題文をスクロールしながら右側の設問に解答できます
長文事例本文
図表クリックで拡大問1 コード決済業者の決済業務及びポイント管理業務におけるデータベースの実装・運用に関する次の記述を読んで，設問に答えよ。
A社は，バーコードを用いたキャッシュレスの決済サービス，及び商品購入などに応じて一定のポイントを付与するポイントサービスを提供している。A社では，ポイントサービス利用件数の急増を受けて，システムの変更を検討している。
〔業務・現行システムの概要〕
1. サービスの概要
(1) 決済サービス
① 決済サービスを利用する人（以下，決済会員という）は，決済会員登録を行い，金融機関などから一定の金額を決済サービスに入金した上で，物品購入などの支払に充てる。入金及び支払に伴う残高を決済残高という。
② 決済サービスに加盟する事業者（以下，決済加盟店という）は，決済サービスへの加盟申請，審査を経て決済加盟店登録を受ける。
③ 決済会員は，スマートフォンなどの携帯端末，決済加盟店の店舗に設置されたPC，POSなどの端末（これらをまとめて，以下，端末という）を使用して，バーコードを読み取ることで支払を行う。同じ決済会員が同時に複数の支払を行うことはない。
④ 決済は，決済会員の決済残高から支払金額を差し引くことで完了する。
⑤ A社は，月に1回まとめて決済金額を決済加盟店に支払う。
(2) ポイントサービス
① ポイントサービスを利用する人（以下，ポイント会員という）は，ポイント会員登録を行ってポイントサービスを利用する。
② ポイントサービスに加盟する事業者（以下，ポイント加盟店という）は，ポイントサービスへの加盟申請，審査を経てポイント加盟店登録を受ける。
③ ポイント会員は，ポイント加盟店での支払，くじ引き，イベント参加などによってポイントを獲得する。
④ 獲得したポイントには，有効期限の年月が決まっている。獲得したポイントはポイント残高として貯めておき，支払に充てることができる。
⑤ 獲得したポイントは，すぐにポイント残高に反映されることもあれば，翌日以降になる場合もある。
(3) サービス間の連携
決済金額の一部をポイントで支払い，残りを決済残高から支払う場合など，両方のサービスを連携した決済を行うことがある。
2. システム構成
現行システムのシステム構成を図1に示す。決済サービス，ポイントサービスそれぞれに専用のサーバ及びRDBMSを用いている。サーバ上ではサービスに用いるアプリケーションプログラム（以下，APという）が稼働している。両サービスを連携した処理は，決済APを介して決済DB，ポイントDBの両方にアクセスする。
```
┌───────────────┐
│ 決済サーバ │ ┌─────────┐
┌─>│ 決済AP │────────────>│ 決済DB │
│ └───────┬───────┘ └─────────┘
┌────┐ │ │
│端末│─┤ │
└────┘ │ ▼
│ ┌───────────────┐ ┌─────────┐
└─>│ポイントサーバ │────────────>│ポイント │
│ ポイントAP │ │ DB │
└───────────────┘ └─────────┘
```
図1 現行システムのシステム構成
3. テーブル構造
決済サービス，ポイントサービスのテーブル構造をそれぞれ図2，3に，主な属性の意味・制約を表1に示す。なお，属性名の#は番号，Cはコード，Fはフラグを略した記号である。
拡大
拡大
表1 主な属性の意味・制約
| 属性名 | 意味・制約 |
| :--- | :--- |
| 決済方式 | バーコードの読取りを利用者の端末，店舗の端末のどちらで行うかを表す区分 |
| 入金# | 決済会員ごとに決済残高への入金の都度払い出す連番 |
| 入金方法 | 入金時に使用した銀行口座，クレジットカードなどの情報 |
| ポイント獲得方法C | ポイント加盟店での支払，くじ引き，イベント参加などポイント獲得の方法を表すコード |
| 有効期限年月，残数 | ポイントが有効な期間は，獲得方法によって異なる。“ポイント獲得履歴”テーブルには獲得したポイントの有効期限年月を設定し，“ポイント残高”テーブルには有効期限年月ごとにポイントの残数を記録する。 |
| 履歴# | “決済履歴”，“ポイント獲得履歴”，“ポイント使用履歴”テーブルの履歴#には，それぞれに一意な番号を自動的に設定する。 |
| 有効F | 有効期限年月が現在の年月以降の場合はTRUE，それよりも前のものはFALSEを設定する。 |
| 残高反映F | 獲得ポイント数を“ポイント残高”テーブルの残数に加算済みの場合はTRUE，未加算の場合はFALSEを設定する。 |
4. 主な処理
各サービスの主な処理の内容を表2に，表2中のS1，S2，P2，P3の処理概要とSQL文を表3～6に示す。各処理は一つ以上のステップから成る。表2～6中の二重引用符で囲んだ名前は，図2，3中のテーブル名である。
表2 主な処理の内容
| サービス | 処理ID | 名称 | 内容 |
| :--- | :--- | :--- | :--- |
| 決済サービス | S1 | 決済残高入金処理 | 決済会員の指示によって金融機関からの入金実行を記録し，“決済残高”の残高に反映する。 |
| 決済サービス | S2 | 決済残高消費処理 | 決済会員の決済指示を受けて，“決済残高”の残高を消費して，内容を“決済履歴”に記録する。 |
| ポイントサービス | P1 | ポイント獲得処理 | ポイント会員がポイントを獲得する都度，獲得したポイント数を“ポイント獲得履歴”に記録する。 |
| ポイントサービス | P2 | 獲得ポイント反映処理 | 任意のタイミングで，ポイント会員のポイント獲得履歴を“ポイント残高”の有効期限年月該当行に反映する。 |
| ポイントサービス | P3 | ポイント消費処理 | ポイント使用指示を受けて，“ポイント残高”の残数を消費して，内容を“ポイント使用履歴”に記録する。 |
表3 S1の処理概要とSQL文
| ステップ | 処理概要（上段）とSQL文（下段） |
| :--- | :--- |
| S1-1 | 決済会員の“決済残高”の残高に入金金額を加算して更新する。
`UPDATE 決済残高 SET 残高 = 残高 + :hv3 WHERE 決済会員# = :hv1` | | S1-2 | “決済会員”の最終入金#を更新する。
`UPDATE 決済会員 SET 最終入金# = 最終入金# + 1 WHERE 決済会員# = :hv1` | | S1-3 | “入金履歴”の入金#に更新後の最終入金#を設定して行を追加する。
`INSERT INTO 入金履歴 (決済会員#, 入金#, 入金日, 入金金額, 入金方法)`
`SELECT 決済会員#, 最終入金#, :hv2, :hv3, :hv4 FROM 決済会員 WHERE 決済会員# = :hv1` | 注記 ホスト変数hv1～hv4には，決済会員#，入金日，入金金額，入金方法をそれぞれ設定する。 表4 S2の処理概要とSQL文 | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | S2-1 | 決済会員の“決済残高”の残高が決済金額以上であることを確認し，残高が不足していれば，戻り値に残高不足エラーを設定して処理を終了する。
`SELECT 残高 FROM 決済残高 WHERE 決済会員# = :hv1 AND 残高 >= :hv5 FOR UPDATE` | | S2-2 | 決済会員の“決済残高”の残高から決済金額を減算して更新する。
`UPDATE 決済残高 SET 残高 = 残高 - :hv5 WHERE 決済会員# = :hv1` | | S2-3 | “決済履歴”の各列に対応するホスト変数の値を設定して行を追加する。
`INSERT INTO 決済履歴 (決済加盟店#, 店舗#, 決済会員#, 決済日, 決済金額, 使用ポイント数) VALUES(:hv2, :hv3, :hv1, :hv4, :hv5, :hv6)` | 注記 ホスト変数hv1～hv6には，決済会員#，決済加盟店#，店舗#，決済日，決済金額，使用ポイント数をそれぞれ設定する。 表5 P2の処理概要とSQL文（未完成） | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | P2-1 | 指定されたポイント会員#について“ポイント獲得履歴”からポイント残高未反映の行の獲得ポイント数を有効期限年月ごとにまとめて，“ポイント残高”の該当行があれば残数に獲得ポイント数を加算して更新し，行がなければ残数に獲得ポイント数を設定して行を追加する。
`MERGE INTO ポイント残高 A`
`USING (SELECT ポイント会員#, 有効期限年月, a AS 加算ポイント数`
` FROM ポイント獲得履歴 WHERE ポイント会員# = :hv1 AND b`
` GROUP BY ポイント会員#, 有効期限年月) B`
`ON (A.ポイント会員# = B.ポイント会員# AND A.有効期限年月 = B.有効期限年月)`
`WHEN MATCHED THEN UPDATE SET c`
`WHEN NOT MATCHED THEN INSERT (ポイント会員#, 有効期限年月, 残数, 有効F)`
`VALUES( d，TRUE)` | | P2-2 | “ポイント獲得履歴”の該当行の残高反映Fの値を更新する。
`UPDATE ポイント獲得履歴 SET 残高反映F = TRUE WHERE ポイント会員# = :hv1 AND 残高反映F IS FALSE` | 注記 ホスト変数hv1にはポイント会員#を設定する。 表6 P3の処理概要とSQL文 | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | P3-1 | 指定されたポイント会員#について“ポイント残高”から有効期限内の残数を集計して求めた使用可能ポイント数が使用ポイント数に満たない場合は，戻り値にポイント不足エラーを設定して処理を終了する。
`SELECT SUM(残数) AS 使用可能ポイント数 FROM ポイント残高 WHERE ポイント会員# = :hv1 AND 有効F IS TRUE` | | P3-2 | ①のSQL文に基づくカーソルによって，“ポイント残高”からポイントが有効な行を有効期限年月の昇順に読み込み，行ごとに残数を使用ポイント数に合わせて消し込む。ホスト変数lv1に消し込むポイント数（以下，消込ポイント数という）を，lv2に有効期限年月を設定して②の更新を行い，使用ポイント数を全て消し込むまで繰り返す。
① `SELECT 有効期限年月, 残数 FROM ポイント残高 WHERE ポイント会員# = :hv1 AND 有効F IS TRUE ORDER BY 有効期限年月 ASC`
② `UPDATE ポイント残高 SET 残数 = 残数 - :lv1 WHERE ポイント会員# = :hv1 AND 有効期限年月 = :lv2` | | P3-3 | “ポイント使用履歴”の各列に対応するホスト変数の値を設定して行を追加する。
`INSERT INTO ポイント使用履歴 (ポイント会員#, ポイント加盟店#, 使用日, 使用ポイント数) VALUES(:hv1, :hv2, :hv3, :hv4)` | 注記 ホスト変数hv1～hv4には，ポイント会員#，ポイント加盟店#，使用日，使用ポイント数をそれぞれ設定する。 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は実行の流れにおける特定の時点を表している。
拡大
2. 障害からの回復
決済処理の実行中に障害によってポイントDBが異常終了する状況を想定した障害・回復の事例を表7にまとめた。表中の時点A，Bは，図4中の時点A，Bに対応している。
表7 決済処理中の障害・回復の事例（未完成）
| 事例 | 内容 |
| :--- | :--- |
| 事例1 | 決済処理中の時点AでポイントDBが障害によって異常終了した。障害除去後に再始動したところ，ポイントDBにはコミット準備のログがあり，トランザクションは未コミットの状態となった。決済APは，ポイントDBに状態を問い合わせ，決済DB及びポイントDBに e を行った。 |
| 事例2 | 決済処理中の時点AでポイントDBが障害によって異常終了した。障害除去後に再始動したところ，ポイントDBにはコミット準備のログがなく，トランザクションはロールバックされた。決済APは，ポイントDBに状態を問い合わせ，決済DBに f を行った。 |
| 事例3 | 決済処理中の時点BでポイントDBが障害によって異常終了した。障害除去後に再始動したところ，ポイントDBはロールフォワードによってデータベースを回復した。決済APは，ポイントDBに状態を問い合わせ， g した。 |
| 事例4 | 決済処理中の時点AでポイントDBが障害によって異常終了した。ア 復旧までの時間が長くなることで，業務上の不都合が生じたので，決済DBにおいて仕掛け中のトランザクションをヒューリスティックな決定によって全てコミットした。障害除去後の再始動において，ポイントDBは未コミットのトランザクションをロールバックした。 |
〔システム変更案の検討〕
ポイントサービスでは，ECサイトを運営する加盟店の増加によって，サービス利用件数が急増し，ポイントDBの応答性能，可用性の低下が問題になっている。その対策として，次のシステム変更案を検討している。
1. システムの構成変更
検討中のシステム構成を図5に示す。業務機能別に会員サービス，決済サービス，ポイントサービスに分け，サービスごとに専用のサーバとデータベースを配置する。各サービスには独立した疎結合のAP及びデータベースを用いて，サービス内部の実装は隠蔽する。サービスに連携するアプリケーションプログラミングインタフェース（以下，APIという）だけを公開し，APIを呼び出すごとに単一のトランザクションとして処理する。端末からのアクセス時には，会員サービスを入り口にして他のサービスに連携する。
```
┌───────────────┐
│ 会員サーバ │
┌─>│ 会員サービス │
│ └───────┬───────┘
┌────┐ │ │ ┌───────────────┐ ┌─────────┐
│端末│─┤ ├─>│ 決済サーバ │────────────>│ 決済DB │
└────┘ │ ┌───────┴──────┐│ 決済サービス │ └─────────┘
│ │ 会員DB │└───────────────┘
│ └───────────────┘
│ │ ┌───────────────┐ ┌─────────┐
└──────────┴─>│ポイントサーバ │────────────>│ポイント │
│ポイントサービス│ │ DB │
└───────────────┘ └─────────┘
```
図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に示す。“決済指示”テーブルの決済指示#は，決済指示ごとに一意な番号を自動採番し，トランザクションの識別子として使用する。オーケストレーターは，処理実行の指示及び補償トランザクション実行の指示に合わせて，“決済指示”テーブルに対応する行の全列の値を他サービスに連携する。
```
決済指示 (決済指示#, 加盟店#, 店舗#, 決済会員#, ポイント会員#, 決済金額,
使用ポイント数, 決済指示日時, 処理ID, ステップ, モード, 状態)
```
注記1 処理ID，ステップには仕掛り中の処理について表2～6の処理ID，ステップのいずれかを設定する。モードには通常モード，取消モードのいずれか，状態には進行中，完了，失敗のいずれかを表す値を設定する。
注記2 外部キーは会員DBに配置するテーブルとの間にだけ設定する。
図6 追加するテーブルのテーブル構造
(3) 決済処理の流れ
決済処理を次のように実行することにした。
① 決済サービスでは，S2を一つのAPIとして実行する。
② ポイントサービスでは，P3のステップP3-1～P3-3のそれぞれに対応するAPIを用意し，会員サービスはAPIを順番に実行する。
③ 会員サービスでは，他のサービスへの実行指示に対する処理結果を“決済指示”テーブルの状態に記録していく。
検討中の決済処理の正常実行時のシーケンス図を図7に示す。図7中の①～⑮は実行の順番を，時点C～Eは実行の流れにおける特定の時点を表している。
拡大
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中の実行指示と同じ単位で実行するものとする。
拡大
5. 障害からの回復
表8の補償要否が“要”のステップは，全て補償可否が“可”となるように対策を行った上で，決済処理実行中にポイントサービスが障害によって停止する状況を想定した障害・回復の事例を表9にまとめた。表中の時点C～Eは，図7中の時点C～Eに対応する。
表9 決済処理中の障害・回復の事例
| 事例 | 内容 |
| :--- | :--- |
| 事例5 | ポイントサービスが時点Cで障害によって停止した。オーケストレーターは，P3-1実行指示を一定回数リトライ後，S2の取消実行指示を行った。 |
| 事例6 | ポイントサービスが時点Dで障害によって停止した。オーケストレーターは，P3-2実行指示を一定回数のリトライ後，P3-1，S2の取消実行指示を順に行った。 |
| 事例7 | ポイントサービスが時点Eで障害によって停止した。オーケストレーターは，P3-3実行指示を一定回数のリトライ後，P3-2からS2までの取消実行指示を順に行った。 |
拡大図2 決済サービスのテーブル構造（一部省略）
拡大図3 ポイントサービスのテーブル構造（一部省略）
`UPDATE 決済残高 SET 残高 = 残高 + :hv3 WHERE 決済会員# = :hv1` | | S1-2 | “決済会員”の最終入金#を更新する。
`UPDATE 決済会員 SET 最終入金# = 最終入金# + 1 WHERE 決済会員# = :hv1` | | S1-3 | “入金履歴”の入金#に更新後の最終入金#を設定して行を追加する。
`INSERT INTO 入金履歴 (決済会員#, 入金#, 入金日, 入金金額, 入金方法)`
`SELECT 決済会員#, 最終入金#, :hv2, :hv3, :hv4 FROM 決済会員 WHERE 決済会員# = :hv1` | 注記 ホスト変数hv1～hv4には，決済会員#，入金日，入金金額，入金方法をそれぞれ設定する。 表4 S2の処理概要とSQL文 | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | S2-1 | 決済会員の“決済残高”の残高が決済金額以上であることを確認し，残高が不足していれば，戻り値に残高不足エラーを設定して処理を終了する。
`SELECT 残高 FROM 決済残高 WHERE 決済会員# = :hv1 AND 残高 >= :hv5 FOR UPDATE` | | S2-2 | 決済会員の“決済残高”の残高から決済金額を減算して更新する。
`UPDATE 決済残高 SET 残高 = 残高 - :hv5 WHERE 決済会員# = :hv1` | | S2-3 | “決済履歴”の各列に対応するホスト変数の値を設定して行を追加する。
`INSERT INTO 決済履歴 (決済加盟店#, 店舗#, 決済会員#, 決済日, 決済金額, 使用ポイント数) VALUES(:hv2, :hv3, :hv1, :hv4, :hv5, :hv6)` | 注記 ホスト変数hv1～hv6には，決済会員#，決済加盟店#，店舗#，決済日，決済金額，使用ポイント数をそれぞれ設定する。 表5 P2の処理概要とSQL文（未完成） | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | P2-1 | 指定されたポイント会員#について“ポイント獲得履歴”からポイント残高未反映の行の獲得ポイント数を有効期限年月ごとにまとめて，“ポイント残高”の該当行があれば残数に獲得ポイント数を加算して更新し，行がなければ残数に獲得ポイント数を設定して行を追加する。
`MERGE INTO ポイント残高 A`
`USING (SELECT ポイント会員#, 有効期限年月, a AS 加算ポイント数`
` FROM ポイント獲得履歴 WHERE ポイント会員# = :hv1 AND b`
` GROUP BY ポイント会員#, 有効期限年月) B`
`ON (A.ポイント会員# = B.ポイント会員# AND A.有効期限年月 = B.有効期限年月)`
`WHEN MATCHED THEN UPDATE SET c`
`WHEN NOT MATCHED THEN INSERT (ポイント会員#, 有効期限年月, 残数, 有効F)`
`VALUES( d，TRUE)` | | P2-2 | “ポイント獲得履歴”の該当行の残高反映Fの値を更新する。
`UPDATE ポイント獲得履歴 SET 残高反映F = TRUE WHERE ポイント会員# = :hv1 AND 残高反映F IS FALSE` | 注記 ホスト変数hv1にはポイント会員#を設定する。 表6 P3の処理概要とSQL文 | ステップ | 処理概要（上段）とSQL文（下段） | | :--- | :--- | | P3-1 | 指定されたポイント会員#について“ポイント残高”から有効期限内の残数を集計して求めた使用可能ポイント数が使用ポイント数に満たない場合は，戻り値にポイント不足エラーを設定して処理を終了する。
`SELECT SUM(残数) AS 使用可能ポイント数 FROM ポイント残高 WHERE ポイント会員# = :hv1 AND 有効F IS TRUE` | | P3-2 | ①のSQL文に基づくカーソルによって，“ポイント残高”からポイントが有効な行を有効期限年月の昇順に読み込み，行ごとに残数を使用ポイント数に合わせて消し込む。ホスト変数lv1に消し込むポイント数（以下，消込ポイント数という）を，lv2に有効期限年月を設定して②の更新を行い，使用ポイント数を全て消し込むまで繰り返す。
① `SELECT 有効期限年月, 残数 FROM ポイント残高 WHERE ポイント会員# = :hv1 AND 有効F IS TRUE ORDER BY 有効期限年月 ASC`
② `UPDATE ポイント残高 SET 残数 = 残数 - :lv1 WHERE ポイント会員# = :hv1 AND 有効期限年月 = :lv2` | | P3-3 | “ポイント使用履歴”の各列に対応するホスト変数の値を設定して行を追加する。
`INSERT INTO ポイント使用履歴 (ポイント会員#, ポイント加盟店#, 使用日, 使用ポイント数) VALUES(:hv1, :hv2, :hv3, :hv4)` | 注記 ホスト変数hv1～hv4には，ポイント会員#，ポイント加盟店#，使用日，使用ポイント数をそれぞれ設定する。 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 決済処理の正常実行時のシーケンス図（未完成）
拡大図7 検討中の決済処理の正常実行時のシーケンス図
拡大表8 決済処理の補償トランザクション（未完成）
設問一覧 ＆ 解答・演習
まずは解答を作成してみましょう。「解答例を見る」をクリックするとIPA公式解答例と採点基準が開きます。
設問1 (1)記号・選択式
表5中の a ～ d に入れる適切な字句を答えよ。
※直接入力してください
設問1 (2) (a)記述問題
制限字数：30 字以内
一貫性の観点から，処理実行時のISOLATIONレベルについて答えよ。
表3の処理S1のISOLATIONレベルはREAD COMMITTEDが適切である。REPEATABLE READである必要がない理由を30字以内で具体的に答えよ。
表3の処理S1のISOLATIONレベルはREAD COMMITTEDが適切である。REPEATABLE READである必要がない理由を30字以内で具体的に答えよ。
0 / 30 文字
設問1 (2) (b)記述問題
制限字数：30 字以内
一貫性の観点から，処理実行時のISOLATIONレベルについて答えよ。
表6の処理P3のISOLATIONレベルはSERIALIZABLEが適切である。REPEATABLE READでは不都合がある理由を30字以内で具体的に答えよ。
表6の処理P3のISOLATIONレベルはSERIALIZABLEが適切である。REPEATABLE READでは不都合がある理由を30字以内で具体的に答えよ。
0 / 30 文字
設問2 (1) (a)記号・選択式
図4について答えよ。
“①決済指示”に対応する“決済完了”の応答が欠けている。トランザクションが正常に終了するとみなした時点で決済APから端末に応答を返すとしたら，③～⑬のどのメッセージの受信後か。番号を一つ答えよ。
“①決済指示”に対応する“決済完了”の応答が欠けている。トランザクションが正常に終了するとみなした時点で決済APから端末に応答を返すとしたら，③～⑬のどのメッセージの受信後か。番号を一つ答えよ。
※直接入力してください
設問2 (1) (b)記号・選択式
図4について答えよ。
ポイントDBが④受信後のP3実行において，ステップP3-1でポイント不足エラーを返した場合，⑥及び⑧で同じメッセージを送信してトランザクションを終了する。送信するメッセージの内容を答えよ。
ポイントDBが④受信後のP3実行において，ステップP3-1でポイント不足エラーを返した場合，⑥及び⑧で同じメッセージを送信してトランザクションを終了する。送信するメッセージの内容を答えよ。
※直接入力してください
設問2 (1) (c)記述問題
制限字数：45 字以内
図4について答えよ。
時点Aと時点Bとでは，トランザクションの状態が異なる。状態の相違点を45字以内で具体的に答えよ。
時点Aと時点Bとでは，トランザクションの状態が異なる。状態の相違点を45字以内で具体的に答えよ。
0 / 45 文字
設問2 (2) (a)記号・選択式
表7について答えよ。
事例1～3の e ～ g に入れる適切な字句を次の枠内から選択して答えよ。
[ コミット準備指示, コミット実行指示, ロールバック実行指示, トランザクションを終了 ]
事例1～3の e ～ g に入れる適切な字句を次の枠内から選択して答えよ。
[ コミット準備指示, コミット実行指示, ロールバック実行指示, トランザクションを終了 ]
※記号ボタンをクリックするか、直接入力してください
設問2 (2) (b)記述問題
制限字数：30 字以内
表7について答えよ。
事例4の下線部アについて，発生したと考えられる業務上の不都合を30字以内で具体的に答えよ。
事例4の下線部アについて，発生したと考えられる業務上の不都合を30字以内で具体的に答えよ。
0 / 30 文字
設問2 (2) (c)記述問題
制限字数：40 字以内
表7について答えよ。
事例4では，最終的にデータの状態はどのようになるか。40字以内で具体的に答えよ。
事例4では，最終的にデータの状態はどのようになるか。40字以内で具体的に答えよ。
0 / 40 文字
設問3 (1) (a)記述問題
制限字数：40 字以内
“3. テーブル構造及び処理の変更”について答えよ。
本文中の下線①について，列を追加する図2中のテーブル名，追加する列名を答えよ。また，追加するステップの適切な処理概要を40字以内で答えよ。
本文中の下線①について，列を追加する図2中のテーブル名，追加する列名を答えよ。また，追加するステップの適切な処理概要を40字以内で答えよ。
0 / 40 文字
設問3 (1) (b)記述問題
制限字数：60 字以内
“3. テーブル構造及び処理の変更”について答えよ。
本文中の下線ウについて，処理P2及びP3の先頭に共通して追加するステップの適切な処理概要を60字以内で，末尾に共通して追加するステップの適切な処理概要を20字以内で答えよ。
本文中の下線ウについて，処理P2及びP3の先頭に共通して追加するステップの適切な処理概要を60字以内で，末尾に共通して追加するステップの適切な処理概要を20字以内で答えよ。
0 / 60 文字
設問3 (2) (a)記述問題
制限字数：40 字以内
“4. 補償トランザクションの設計”について答えよ。
表8中の h，i に入れる適切な補償処理の概要をそれぞれ40字以内で答えよ。
表8中の h，i に入れる適切な補償処理の概要をそれぞれ40字以内で答えよ。
0 / 40 文字
設問3 (2) (b)記号・選択式
“4. 補償トランザクションの設計”について答えよ。
表8中の下線エへの対策として，ポイントDBに図8の“ポイント消込履歴”テーブルを追加して補償を可能にする。図8中の j に入れる一つ又は複数の適切な列名を答えよ。なお，主キーの構成列には巻頭の表記ルールに従って実線の下線を付けよ。
表8中の下線エへの対策として，ポイントDBに図8の“ポイント消込履歴”テーブルを追加して補償を可能にする。図8中の j に入れる一つ又は複数の適切な列名を答えよ。なお，主キーの構成列には巻頭の表記ルールに従って実線の下線を付けよ。
※直接入力してください
設問3 (3)記述問題
制限字数：50 字以内
“5. 障害からの回復”について答えよ。
表9中の事例5～7のうち，ポイントDB内のデータが一時的に不整合になる事例を一つ答えよ。また，不整合の内容を50字以内で具体的に答えよ。
表9中の事例5～7のうち，ポイントDB内のデータが一時的に不整合になる事例を一つ答えよ。また，不整合の内容を50字以内で具体的に答えよ。
0 / 50 文字
午後II長文記述の得点力を引き上げる定番対策書Amazon・楽天 公式提携
PR
IPA 厳選対策書徹底攻略 データベーススペシャリスト教科書 令和8年度株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
DB徹底攻略株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
徹底攻略 データベーススペシャリスト教科書 令和8年度
💡 推薦ポイント:午後I・午後IIの概念データモデル穴埋めや排他制御・性能設計の記述問題で確実に合格点を勝ち取る実践テクニックが満載です。
¥3,278（税込）
※本リンク先はプロモーション（アフィリエイト広告）が含まれています
【出題趣旨】IPA公式発表
【採点講評】IPA公式発表
本問に関連するデータベーススペシャリスト重要用語解説
本番形式・制限時間付きで演習する
令和7年 秋期 午後II（2問中1問選択・120分）を実戦演習モードで通し解答し、総合採点を受けられます。