対象試験と出題頻度
分散データベースは、応用情報技術者（AP）で出題されるテーマです。
午前問題で「透過性」「2相コミットプロトコル」「データ分割（水平分割・垂直分割）」といった関連語との組合せで問われる傾向があります。
深い実装知識よりも、概念と用語の対応を正確に覚えているかが得点を分けます。
詳細をクリックして確認
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
情報処理試験を勉強していると、「分散データベースって普通のDBと何が違うの？クラウドのこと？」と混乱しがちです。
分散データベース（Distributed Database）とは、一言で言うと
「ネットワーク上の複数のコンピュータに分散配置されたデータベースを、利用者からは1つのデータベースに見せる仕組み」
のことです。
イメージとしては、「全国チェーンの図書館ネットワーク」です。
東京館・大阪館・福岡館にそれぞれ蔵書がありますが、利用者は最寄りの窓口で「この本ありますか？」と聞くだけで、どの館にあるかを意識せず本を取り寄せられます。
利用者にとっては「1つの大きな図書館」に見えるわけです。
分散データベースも同じ発想で、データが物理的にどのサーバーにあるかを利用者やアプリから隠蔽します。
📊 分散データベースの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Distributed Database（DDB） |
| 分類 | データベースシステムの構成形態 |
| 主な目的 | 負荷分散、可用性向上、地理的分散 |
| キー概念 | 透過性、2相コミット、データ分割、レプリケーション |
解説
1台のサーバーに全データを集約する集中型データベースには、限界があります。
アクセスが集中すると応答が遅くなり、サーバーが故障すれば業務が止まります。さらに、グローバル展開する企業では地理的に離れた拠点で同じデータを扱う必要が出てきます。
こうした課題に対応するため、データを複数ノードに分散しつつ、利用者からは1つのDBに見せる仕組みが設計されました。これが分散データベースです。
構成イメージ
分散データベースの構成イメージ
│
▼
問い合わせを各ノードに振り分け、結果を統合する
│
▼
ノードA
東京拠点
顧客データ 1〜1000
ノードB
大阪拠点
顧客データ 1001〜2000
ノードC
福岡拠点
顧客データ 2001〜3000
物理的には3台のサーバーに分散 → 分散DBMSが集約 → アプリには1台に見える
分散データベースの「透過性」
分散データベースの中核概念が透過性（Transparency）です。
これは「分散していることを利用者に意識させない」性質を指します。試験で問われる主な透過性は以下の通りです。
| 透過性の種類 | 何を隠蔽するか |
|---|---|
| 位置に対する透過性 | データがどのサーバーにあるかを意識させない |
| 分割に対する透過性 | テーブルが水平・垂直に分割されていても1つの表として扱える |
| 複製に対する透過性 | 同じデータが複数ノードに複製されていても1件として扱える |
| 障害に対する透過性 | 一部ノードが故障しても処理を継続できる |
| 移動に対する透過性 | データが別ノードに移動してもアプリ側の修正が不要 |
2相コミットプロトコル（2PC）
複数ノードにまたがる更新では、「全ノードで成功するか、全ノードで取り消すか」を保証する必要があります。これを実現するのが2相コミットプロトコル（Two-Phase Commit）です。
2相コミットの流れ
【フェーズ1：準備フェーズ（Prepare）】
調整者（コーディネータ）が各ノードに「コミット可能か？」と問い合わせる。各ノードは「Yes」または「No」を返答する。
【フェーズ2：コミットフェーズ（Commit）】
全ノードが「Yes」なら → コミット指示を送信し全体で確定。
1つでも「No」なら → ロールバック指示を送信し全体で取消。
▲ 全員一致でなければコミットしない仕組み（ACIDの原子性を分散環境で保証）
データの分割方式
テーブルを複数ノードに配置する方法には、水平分割と垂直分割の2種類があります。
水平分割（行で分ける）
| ID | 名前 | 地域 |
|---|---|---|
| 1 | 佐藤 | 東京 |
| 2 | 鈴木 | 東京 |
| 3 | 田中 | 大阪 |
| 4 | 山田 | 大阪 |
行（レコード）単位で
ノードA・Bに振り分け
垂直分割（列で分ける）
| ID | 名前 | 給与 |
|---|---|---|
| 1 | 佐藤 | 300 |
| 2 | 鈴木 | 350 |
| 3 | 田中 | 400 |
列（属性）単位で
ノードA・Bに振り分け
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 分散データベースの核心を3行で
・複数ノードのDBを利用者から1つに見せる仕組み
・透過性（位置・分割・複製・障害・移動）で分散を隠蔽する
・複数ノードの整合性は2相コミットプロトコルで保証する
試験ではこう出る！
分散データベースは、応用情報技術者の午前問題で「透過性」と「2相コミット」を中心に問われます。出題実績は次の通りです。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H29春 午前 問29 |
2相コミットプロトコルにおける主サイト（コーディネータ）の動作を問う問題。 | ・準備完了応答→コミット指示の流れ ・1つでも応答がなければアボート |
| AP H26秋 午前 問31 |
分散データベースの透過性のうち「位置に対する透過性」の説明を選ぶ問題。 | ・データの物理的位置を意識せずアクセスできること ・複製・分割・障害との混同に注意 |
| AP H22春 午前 問33 |
分散DBにおける2相コミットの目的を問う問題。 | ・複数サイトの更新の原子性保証が正解 ・性能向上・セキュリティはひっかけ |
📝 IPA試験での出題パターン
パターン1：「透過性の種類を識別させる」
5種類ある透過性の説明文をシャッフルし、特定の透過性（例：位置）の説明はどれかを選ばせる形式。「物理的位置を意識せず」が位置、「分割されていても1表」が分割、「複数の複製を1件」が複製、というキーワードで切り分ける。
パターン2：「2相コミットの動作を問う」
準備フェーズとコミットフェーズの役割、コーディネータと参加者の動作を問う形式。「全員Yesでコミット、1人でもNoでロールバック」を覚えていれば解ける。
頻出度Cの用語なので、APの午前で出れば1問取りに行く程度で十分です。深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 分散データベースの説明として、最も適切なものはどれでしょうか？
- A. 1台のサーバー内で複数のテーブルを別領域に格納し、I/O負荷を分散することで応答性能を高める仕組み。
- B. データベースのバックアップを定期的に取得し、障害発生時に過去時点へ復元できるようにする仕組み。
- C. ネットワーク上の複数のコンピュータに配置されたデータベースを、利用者からは1つのデータベースとして扱えるようにする仕組み。
正解と解説を見る
正解：C
解説：
分散データベースは、複数ノードに分散したDBを透過性によって1つに見せる構成形態です。利用者は物理的な配置を意識せず、通常のDB操作と同じ感覚でアクセスできます。
選択肢Aは、単一サーバー内のテーブルスペース分割やパーティショニングの説明に近い内容です。「ネットワーク上の複数コンピュータ」という分散DB本来の構成を欠いており不正解です。選択肢Bは、バックアップ・リカバリ機能（ロールフォワード／ロールバックリカバリ）の説明であり、分散とは別の概念です。データの保全性を扱う仕組みであって、複数ノードへの分散配置を表すものではありません。
よくある質問（FAQ）
Q. 分散データベースとレプリケーションは同じものですか？
違います。レプリケーションは「同じデータを複数ノードに複製する技術」で、分散データベースを実現する手段の一つです。分散データベースには複製を持たず、データを分割だけで配置する構成（シャーディング型）もあります。レプリケーションはあくまで複製に対する透過性を支える技術要素で、分散DB全体と同義ではありません。
Q. 2相コミットの欠点はありますか？
あります。最大の弱点は、コーディネータがフェーズ2の途中で故障すると、参加ノードが「コミットすべきかロールバックすべきか」判断できずブロック状態に陥ることです。これを解決するために3相コミット（3PC）も提案されていますが、実装が複雑なため、近年はBASE特性に基づく結果整合性（最終的に整合すればよい）を採用するNoSQL系DBも普及しています。応用情報の試験範囲では2相コミットの仕組みまで押さえれば十分です。
Q. クラウドのDBサービスは分散データベースですか？
多くは分散データベースの一種です。Amazon Aurora、Google Cloud Spanner、Azure Cosmos DBなどは、内部で複数ノードへのデータ分散とレプリケーションを行いつつ、利用者には単一のエンドポイントを提供しています。これはまさに分散DBの「位置に対する透過性」を実装した形です。ただしマネージドサービスでは内部構造が隠蔽されるため、利用者が分散構造を意識する場面は限定的です。
Q. 分散データベースとCAP定理の関係は？
CAP定理は、分散データシステムにおいて一貫性（Consistency）・可用性（Availability）・分断耐性（Partition tolerance）の3つを同時に完全には満たせない、という法則です。分散データベース設計では「ネットワーク分断は避けられないので、CかAのどちらを優先するか」を選ぶことになります。RDB系の分散DBはC（一貫性）を優先、NoSQL系の多くはA（可用性）を優先する傾向があります。応用情報ではCAP定理単体で問われることもあるため、用語として押さえておくと得点源になります。
