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

ITパスポート 2016年 秋期 81


問題文

複数の利用者がデータベースの同じレコードを更新するときに、データの整合性を保つために行う制御として、適切なものはどれか。

選択肢

正規化
タイマ監視
ロールフォワード
ロック/アンロック(正解)

🔒 解説は解答すると表示されます

複数の利用者がデータベースの同じレコードを更新するときに、データの整合性を保つために行う制御として、適切なものはどれか。【ITパスポート 解説】

正解の理由

同時に複数人が同じデータ(レコード)を変更すると、更新が競合してデータに矛盾が生じます。こうした「誰かが更新中は他の人が触れないようにする」仕組みを指すのが、選択肢のうちの「ロック/アンロック」です。
  • ロック(lock)は「データに対して排他(他が触れない)あるいは共有(読み取りは可だが書き込みは不可)の権利を一時的に与える仕組み」です。
  • アンロック(unlock)はそのロックを解除する操作です。
  • これにより、トランザクション(transaction:一連の処理をひとまとまりで扱うこと)の整合性が保たれます。例えば銀行の口座残高を同時に更新する場面で正しい処理順・結果を保証します。
したがって、同時更新による整合性確保のために行う制御として最も適切なのは、のロック/アンロックです。

解法ステップ

  1. 問題文で求められているものを確認する
    • 「複数の利用者が同じレコードを更新」→ 同時実行(並行)による「競合(コンフリクト)」の問題。
  2. 各選択肢が何を指すかを理解する
    • 用語の意味を一つずつ簡単に置き換える(後述の選択肢別誤答解説参照)。
  3. 同時更新の場面で直接使われる仕組みを選ぶ
    • データへのアクセス制御(排他制御)が必要 → ロック/アンロックが該当。
  4. 結論を出す
    • 同時更新での整合性確保=ロック/アンロック()。

選択肢別の誤答解説

  • ア: 正規化
    • 正規化(normalization:データの重複を減らして整った構造にする設計手法)は、データ設計の話です。データの一貫性や冗長性を減らす役割はありますが、同時に更新される際のアクセス制御(誰がいつ書き込めるか)を直接管理する仕組みではありません。したがって今回の問いの答えにはなりません。
  • イ: タイマ監視
    • 「タイマ監視(timer monitoring)」は一般に時間や監視を行う仕組みを指します。時刻やタイマーで処理を監視することはあっても、同時更新の排他制御を意味する標準用語ではありません(注意:似た概念として「タイムスタンプ(timestamp)方式」という同時実行制御の手法はありますが、本肢はそれとは異なります)。よって不適切です。
  • ウ: ロールフォワード
    • ロールフォワード(roll forward)は障害復旧の手法で、ログを使って処理結果を再適用してデータを復旧することを指します。更新の競合を予防する「同時実行制御」とは目的が違います。復旧後に整合性を取り戻す役割はしますが、同時に更新を制御する仕組みではありません。
  • エ: ロック/アンロック(正解)
    • データベースで同時に起きる更新競合を防ぐ代表的な手段です。共有ロック(読み取り可)や排他ロック(書き込み専用)などの種類があります。トランザクションが完了したらアンロックして他の処理を許可します。

よくある誤解

  1. 「正規化すれば同時更新の問題も解決する」
    • 正規化はデータ構造の整理で、同時アクセスの排他制御そのものは行いません。設計と実行制御は別の対策です。
  2. 「ロックは常に安全だから無条件で使えばよい」
    • ロックは便利ですが、長時間ロックすると他の処理が待たされます。また、複数のロックが絡んで互いに待ちあう「デッドロック(deadlock)」が発生する可能性があります。実際はロックの粒度やタイムアウト、楽観的制御などの工夫が必要です。
  3. 「タイマ監視=タイムスタンプ方式だ」と混同する
    • タイムスタンプ(timestamp)方式は同時実行制御法の一つで、処理順序を時間で決めますが、選択肢の「タイマ監視」は一般的な表現でタイムスタンプ方式とは別物と考えるべきです。試験では用語の正確な意味を確認してください。

補足コラム

  • ロックの種類(簡単に)
    • 共有ロック(Sロック):読み取りは許可、書き込みは不可。複数人が同時に読むときに使う。
    • 排他ロック(Xロック):書き込み専用。他は読み書きできない。
    • 行ロック(レコードロック):特定のレコードだけロックする。テーブル全体をロックするより細かくて効率的。
  • 楽観的ロックと悲観的ロック(pessimistic/optimistic locking)
    • 悲観的ロック:更新前にロックしておく(衝突を防ぐ)。
    • 楽観的ロック:ロックをかけずに処理し、更新時に「他の更新がなかったか」をチェックして衝突を検出する。衝突があれば再試行する。Webアプリでよく使われます(例:バージョン番号チェック)。
  • SQLの実例(行ロック)
    • 例:トランザクション内で特定レコードを更新する際にロックする(データベースによって文法は異なります)。
      BEGIN;
      SELECT * FROM accounts WHERE id = 100 FOR UPDATE; -- この行で行ロック
      UPDATE accounts SET balance = balance - 100 WHERE id = 100;
      COMMIT;
      

FAQ

Q1: ロックはアプリ側で実装できますか?
A1: 可能ですが難しいです。アプリ側でのロックは分散環境や異なるアプリ間で整合性を保つのが大変です。データベース管理システム(DBMS)に委ねるのが一般的で安全です。
Q2: デッドロックとは何ですか?対策は?
A2: デッドロックは互いに相手のロック解除を待って処理が進まなくなる状態です。対策はロックの取得順序を統一する、タイムアウトを設定する、デッドロック検出機能で片方を強制終了する、などがあります。
Q3: すべてロックすれば安全ですか?
A3: 技術的には安全性は上がりますが、性能が悪化します。適切な粒度(行ロック vs テーブルロック)や、楽観的手法との併用で性能と安全性を両立します。
Q4: ロールフォワードはまったく無関係ですか?
A4: 完全に無関係ではありません。ロールフォワードは障害から復旧して整合性を戻すための手段で、同時実行の予防策ではありません。運用面では両方が重要です(実行時の制御+復旧手順)。

関連キーワード: データベース、同時実行制御、ロック、トランザクション、整合性、楽観的ロック、排他制御、デッドロック、行ロック、タイムスタンプ
← 前の問題へこの年度をクイズで解く次の問題へ →
戦国ITクイズ機能

\ せっかくなら /

ITパスポート
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

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

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