AP科目A 35 — 分散データベースとデータウェアハウス：分割・レプリケーション・CAP・2相コミットからETL・OLAPまで

AP科目A・第35回 · 2026年度・シラバスVer.7.2に基づく独立した学習資料です。IPAとの提携はなく、合格を保証しません。シリーズ一覧を見る

2026年IPA応用情報技術者試験（AP）科目A、シラバスVer.7.2を基準とし、2026-10-22確認。Motitoryの独立した学習資料であり、IPAとの提携やIPAによる承認・確認はない。Ver.7.2の全範囲や分散データベース・データウェアハウス技術の全体を網羅せず、合格を保証しない。本文の例題と問題はすべてMotitoryのオリジナルで、IPAの過去問題ではない。

本記事は固定の仕上げ計画AP33–38のうちAP35（補足編）であり、シリーズ最後の記事ではない。全回はシリーズ一覧で確認できる。次の内容は既に扱ったので、ここでは再説明しない。

クラウド・仮想化・負荷分散・分散処理の一般論：AP10
キー・関数従属・正規化：AP13
SQL・結合の意味・集計・NULL：AP14
単一DBMS内のACID・隔離性水準・WAL・障害回復：AP15
インデックス・性能・アクセス制御などのDB総合診断：AP32

ここでは、データが複数のサイト（ノード）に置かれたときに新たに生じる問題と、分析用データベース（DWH）だけを扱う。

1. 用語の早見表

한국어	日本語（試験用語）	English	一行定義
분산 데이터베이스	分散データベース	distributed database	複数サイトのデータを一つのDBのように使わせる構成
수평 분할	水平分割	horizontal partitioning	行（レコード）を条件で分ける。和集合で復元
수직 분할	垂直分割	vertical partitioning	列（属性）を分ける。各断片に主キーを残し結合で復元
샤딩	シャーディング	sharding	水平分割した断片（シャード）を別々のサーバに配置
복제(레플리케이션)	レプリケーション	replication	同じデータの複製を複数サイトに保持
분산 투과성	分散透過性（位置透過性など）	distribution transparency	利用者がデータの場所・分割・複製を意識しなくてよい性質
2단계 커밋	2相コミット（2相コミットメント）	two-phase commit (2PC)	準備・投票の後、全員コミットか全員ロールバックかを決める分散トランザクションのプロトコル
스플릿 브레인	スプリットブレイン	split brain	分断された双方がそれぞれ主（プライマリ）として動き、データが食い違う状態
강한 일관성	強い一貫性	strong consistency	コミット済みの最新値をどの複製から読んでも得られる
결과 일관성(최종 일관성)	結果整合性	eventual consistency	新たな更新が止まれば、複製はいずれ同じ値に収束する
CAP 정리	CAP定理	CAP theorem	ネットワーク分断中は一貫性と可用性を同時に完全には満たせないという定理
BASE	BASE	basically available, soft state, eventually consistent	ACIDと対比される設計方針（保証ではない）
데이터 웨어하우스	データウェアハウス	data warehouse (DWH)	複数システムのデータを統合し、履歴とともに蓄積した分析用DB
데이터 마트	データマート	data mart	特定の部門・目的向けに絞った分析用DB
ETL	ETL（抽出・変換・書出し）	extract, transform, load	抽出 → 変換 → 書出し（ロード）
데이터 클렌징	データクレンジング	data cleansing	表記ゆれ・重複・欠損・誤りを正す
팩트 테이블	ファクトテーブル	fact table	測定値（売上金額など）とディメンションへの外部キーを持つ中心のテーブル
디멘션 테이블	ディメンションテーブル	dimension table	分析軸（商品・地域・期間）の属性を持つテーブル
스타 스키마	スタースキーマ	star schema	ファクトテーブルの周りにディメンションテーブルを星形に置いた構造
OLAP	OLAP	online analytical processing	多次元で集計・分析する処理
OLTP	OLTP	online transaction processing	短い更新トランザクションを大量に処理する業務システム

2. 分散データベースと透過性

分散データベースは、ネットワークでつながった複数サイトのデータを、利用者に一つのデータベースのように見せる。そのために求められる性質が透過性であり、試験では次の種類を区別する。

透過性	한국어	利用者が意識しなくてよいこと
位置透過性	위치 투과성	データがどのサイトにあるか
移動透過性	이동 투과성	データが別のサイトへ移されたか
分割透過性	분할 투과성	表が複数の断片に分かれているか
重複透過性（複製透過性）	복제(중복) 투과성	同じデータの複製が複数の場所にあるか
障害透過性	장애 투과성	一部のサイト・回線の障害
並行透過性	병행 투과성	他サイトのトランザクションと同時に実行されているか

透過性とはSQLやアプリケーションプログラムを変えなくてよいという意味であって、性能上のコストや障害の影響が消えるという意味ではない。遠隔サイトを読めば通信遅延が生じ、4〜5節のとおり障害と分断は一貫性と可用性の選択を迫る。

3. データの分割

方式	分ける単位	復元方法	注意
水平分割	行。例：年度別、地域別	断片の和集合（UNION）	断片どうしは異なる行を持つ。複製ではない
垂直分割	列。例：よく使う列とまれな列	各断片に残した主キーで結合	キーを欠くと元の行に戻せない
シャーディング	水平分割＋断片ごとに別サーバ	シャードキーで担当サーバを探す	シャードキーの選び方が悪いと一台に集中する（ホットスポット）

分割と複製は違う。 水平分割は行を分けて重ならないように置くこと、複製は同じデータを重ねて複数持つことである。実際のシステムは両者を組み合わせることも多い（各シャードをさらに複製する）。
分割とシャーディングの関係： 同じDBMSの中で表をパーティションに分けることも水平分割である。シャーディングはその断片を独立したサーバ群に散らして置く場合を指す言葉で、シャードをまたぐ問合せ・トランザクションは6〜7節の分散処理になる。

計算例1 — パーティションの刈込みと複製の記憶容量

仮定：売上表12,000,000行、平均行サイズ600バイト固定。容量は10進単位（1 GB = 10^9バイト）で、インデックス・ログ・ページ管理領域・圧縮を無視した生データサイズである。

生データサイズ：12,000,000 × 600 = 7,200,000,000バイト = 7.2 GB。
水平分割：販売年度で5パーティション、各2,400,000行（均等と仮定）。問合せ条件が直近3年で、パーティションキーと一致するなら、理想的には3パーティションだけを読む（パーティションプルーニング）。読む行 = 3 × 2,400,000 = 7,200,000行。
削減率：(12,000,000 − 7,200,000) ÷ 12,000,000 = 4,800,000 ÷ 12,000,000 = スキャン行数が40%減る。読む生データは7,200,000 × 600 = 4.32 GB。ただし行数が40%減っても応答時間がちょうど40%縮む保証はない（キャッシュ・インデックス・並列度に左右される）。
複製：完全な複製を3組（元を含めて合計3組）持つと7.2 × 3 = 21.6 GB（オーバーヘッド前の生データサイズ）。水平分割は記憶容量を増やさないが、複製は複製数の分だけ増やす。
（参考）垂直分割：600バイト = キー8 + よく使う列92 + まれな列500バイトとする。両断片ともキーを持つので断片の行は100バイトと508バイト、合計608バイトとキーの分だけ増える。よく使う列だけを読む問合せは12,000,000 × 100 = 1.2 GBを読めば済む。二つの断片をキーで結合すれば元の行が復元される。

4. レプリケーションと一貫性

方式	コミット応答の時点	長所	短所
同期レプリケーション	複製側の受信（または書込み）確認後	確認応答に使った永続化済みの複製には更新がある。その複製へフェールオーバーすれば、その更新を失わない	応答遅延が増える。複製に届かないと更新が止まるか遅れる
非同期レプリケーション	主（プライマリ）に書き込んだらすぐ	応答が速く、遠距離にも向く	複製遅延（ラグ）の間、複製からの読取りは古い値。まだ転送されていない更新は、主が故障して切り替えるときに失われうる

強い一貫性： コミット済みの最新値をどの複製から読んでも得られる。その代わり複製間の調整が要り、遅延が増え、分断時には一部の要求を拒否しなければならないことがある。
結果整合性： 新たな更新が止まれば、すべての複製がいずれ同じ値に収束するという保証である。その間は古い値を読みうる。「確認済みの更新を勝手に失ってよい」という意味ではない。 耐久性（応答前に何か所に記録するか）と、同時更新の競合解決ルールは別途設計・明示する必要がある。
レプリケーションはバックアップではない。 誤って削除した行や、アプリケーションのバグで壊れたデータもそのまま複製に伝わる。特定の時点に戻すには、別にバックアップとログが必要である（回復の原理はAP15）。
スプリットブレイン： 主・待機の2サイト間の回線だけが切れたのに、待機側が「主が死んだ」と判断して昇格すると、双方がそれぞれ更新を受け付けてデータが食い違う。対策は、過半数（クォーラム）でだけ主を決めること（3ノードなら2ノード以上の側だけが更新可）、第三の監視ノード（ウィットネス）、旧主を確実に切り離すフェンシングである。過半数を得られない側は更新を止めるので、一貫性のためにその側の可用性を諦める選択になる。

5. ネットワーク分断とCAP

CAP定理の正確な意味：データを複製する分散システムでは、ネットワーク分断（P）が起きている間、次の二つを同時に完全には満たせない。

C（一貫性）： すべての読取りが最新の書込み結果を返すか、エラーになる。
A（可用性）： 故障していないノードへのすべての要求が（エラーではない）応答を受け取る。

分断中に双方が応答し続けると（A優先）、互いの更新を知らないので古い値や競合する値を返しうる。一貫性を守るには（C優先）、一方（通常は過半数を得られない側）が要求を拒否するか待たせる必要がある。

「三つのうち好きな二つを選ぶ」というよくある説明は不正確である。実際のネットワークでは分断は起こりうる障害なので、選択は分断が起きたときにCとAの間で生じる。
分断がないとき、CAPは何も強制しない。 平常時にはCとAを両立できる。ただし平常時にも、複製間の調整を待つか（一貫性）すぐ応答するか（遅延）のトレードオフは残る。これはCAPの主張ではなく、別の設計上の問題である。
BASE（Basically Available, Soft state, Eventually consistent）は、可用性と結果整合性を優先する設計方針をACIDと対比して呼ぶ言葉である。何らかの性質を保証する規格ではなく、BASEだからといってACIDの原子性を提供するわけでもない。

6. 分散問合せと結合

結合の意味とSQLの文法はAP14と同じである。分散環境で変わるのはどこで計算し、何を送るかである。分散問合せでは、サイト間の転送量がコストを大きく左右する。

選択・射影を先に： 各サイトで条件（WHERE）に合う行と必要な列だけを残してから送る。
小さい方を送る： 大きな表を丸ごと移さず、小さい方を大きい方のサイトへ送って結合する。
セミジョイン： サイトAが結合列の値だけをサイトBへ送り、Bはその値に一致する行だけをAへ返す。その後Aで結合を仕上げる。結合に関わらない行を送らないので転送量が減る。結合列の値を送るコストが減らせる行より大きければ得はない。
分割との関係： 条件がパーティションキーと合えば、無関係なサイトはまったく読まずに済む（計算例1）。シャードキーでない列で結合・検索すると、全シャードに問合せを送らなければならないことがある。

7. 2相コミット

複数サイトを更新する一つのトランザクションを、全部コミットするか全部ロールバックするかにするプロトコルが2相コミットである。調停者（コーディネータ）と参加者で構成される。単一DBMS内の原子性とログはAP15で扱った。

第1相（準備・投票）： コーディネータが全参加者にPREPAREを送る。各参加者はコミットに必要な内容を安定記憶上のログに記録し、YES（コミットできることを約束）またはNOを投票する。NOを出した参加者は自分の側をロールバックする。
第2相（決定）： 全員がYESなら、コーディネータはCOMMITの決定をログに記録してからCOMMITを送る。一つでもNO、または時間内に投票が来なければABORTを送る。参加者は決定に従ってコミットまたはロールバックし、確認応答を返す。

ブロッキング問題： YESを投票した参加者は、決定を受け取るまで、単独でコミットすることも（他の参加者がNOだったかもしれない）、単独でロールバックすることも（コーディネータが既にCOMMITを決め、他の参加者がコミットしたかもしれない）できない。この不確定（in-doubt）状態でコーディネータが故障すると、参加者はロックを持ったまま決定が分かるまで待つ。まだ投票していない参加者は自らロールバックできる。したがって2相コミットは原子性のためのプロトコルであり、可用性を提供しない。 ブロッキングを減らす3相コミットや合意アルゴリズムは本記事の範囲外である。

計算例2 — 2相コミットの三つのケース

一つの注文が、在庫DB（サイトX）の在庫減算と決済DB（サイトY）の決済記録をまとめて更新する。コーディネータは注文サーバである。

ケース	第1相の投票	コーディネータの決定	結果
(a)	X：YES、Y：YES	COMMITをログに記録してから送信	X・Yともにコミット、確認応答の後に終了
(b)	X：YES、Y：NO（限度額超過）	ABORT	Yは既にロールバック、XもABORTを受けてロールバック。在庫は減らない
(c)	X：YES、Y：YES（各参加者は自分の投票を送信）	コーディネータが二つの投票を両方受信したと保証できる前で、かつ決定がどの参加者にも届く前にコーディネータが故障	X・Yともに不確定状態。両参加者がYESを送ったことを互いに確認しても、コーディネータが期限内に両方を受け取りCOMMITを記録したのか、一方を受け取れずABORTを記録したのかは分からない。コーディネータが回復してログの決定を送り直すまで、ロックを持ったままブロックされる

(b)の要点は「一つでもNOなら全員ロールバック」、(c)の要点は「YESの後は単独で決められない」である。

8. データウェアハウスとOLTP

観点	OLTP（業務システム）	データウェアハウス（DWH）
目的	受注・決済などの業務処理	意思決定のための分析
処理	短い更新トランザクションが多数	大量の行を読む集計問合せ
データ	現在値が中心	履歴（時系列）を蓄積
出所	おおむね一つの業務	複数システムを統合
設計	更新時異状を防ぐ正規化が中心	集計しやすいスタースキーマなど（ディメンションは非正規化することもある）
更新	随時の更新・削除	主に定期的なロード。ロードした履歴は上書きしない

DWHの特徴は、よくサブジェクト指向・統合・時系列・不揮発とまとめられる。したがってDWHはOLTPのDBをそのままコピーしたものではない。 複数の出所のコードや表記を統合し、クレンジング（9節）した上で、分析向けの構造（10節）に履歴とともに蓄積する。

データマート： DWH（または出所）から、特定の部門・目的（例：営業分析）に必要なデータだけを選んで作った小さな分析用DB。

9. ETLとELT

方式	順序	どこで変換するか	特徴
ETL	抽出 → 変換 → ロード	ロード前に、別の変換処理で	クレンジング済みのデータだけがDWHに入る
ELT	抽出 → ロード → 変換	ロード後に、DWHの中で	生データを先に入れ、DWHの処理能力で変換する。生データを変換し直せる

データクレンジング： 表記ゆれ（全角／半角、法人名の表記）の統一、コード体系の統一、重複レコードの統合（名寄せ）、欠損値・範囲外の値の処理。ルールに合わない行は捨てずにリジェクト一覧に残して原因を追跡するのが一般的である。

計算例3 — 1日のロード件数

仮定：出所Aが1日1,200,000行、出所Bが1日800,000行を送る。合わせた入力の2%がクレンジングで拒否されるか既存行に統合され、新しい行としてはロードされないと仮定する。30日間毎日同じ量とする。

合わせた入力：1,200,000 + 800,000 = 2,000,000行／日。
拒否・統合：2,000,000 × 0.02 = 40,000行。
ロード：2,000,000 − 40,000 = 1,960,000行／日。
30日：1,960,000 × 30 = 58,800,000行。

注意：2%を出所Bだけに適用すると2,000,000 − 16,000 = 1,984,000となり、別の答えになる。率を何に適用するかを問題文で必ず確かめる。

10. ファクトとディメンション

ファクトテーブル： 分析対象となる出来事の測定値（売上金額、数量）と、各ディメンションを指す外部キーを持つ。一般に行数が最も多い。
ディメンションテーブル： 分析軸の属性。例：商品（商品名・分類）、地域（店舗・都市・地方）、期間（日・月・四半期・年）。
スタースキーマ： ファクトテーブルを中心に、ディメンションテーブルが一段ずつつながった構造。結合が単純で集計しやすい。ディメンションをさらに正規化して枝分かれさせた形をスノーフレークスキーマという。

11. OLAPの操作

データを商品 × 地域 × 月のような多次元キューブとして捉え、次の操作で分析する。

操作	한국어	すること	例
ロールアップ	롤업	より粗い水準に集約する	月別 → 四半期別
ドリルダウン	드릴다운	より詳細な水準へ下りる	四半期別 → 月別 → 日別
スライス	슬라이스	一つの次元を一つの値に固定して断面を見る	地域 = R1の商品 × 月の表
ダイス	다이스	複数の次元で範囲を選び、小さなキューブを切り出す	商品P1〜P5 × 地域R1〜R3 × 1〜3月
ピボット（回転）	피벗	行・列の軸を入れ替えて見る観点を変える。集計値そのものは変わらない	行=商品／列=月 → 行=月／列=商品

計算例4（任意） — キューブのセル数

商品40 × 地域10 × 月12 = 4,800セルが最大のセル数である。実際に売上がある組合せが1,500しかなければ、3,300セルは空である（疎）。月を四半期（4）にロールアップすると、最大セル数は40 × 10 × 4 = 1,600セルになる。

12. クイックシートと落とし穴

水平分割 = 行、和集合で復元。垂直分割 = 列、主キーの結合で復元。シャーディング = 水平分割の断片をサーバごとに。
分割 ≠ 複製。レプリケーション ≠ バックアップ。非同期レプリケーション = ラグの間は古い読取り、切替え時に未転送の更新を失いうる。
結果整合性 = 更新が止まれば収束。任意の消失を許すものではない。
CAP = 分断中にCとAのどちらかを選ぶ。分断がなければCAPは何も強制しない。BASE = 方針であって保証ではない。
スプリットブレイン → クォーラム・ウィットネス・フェンシング。
2相コミット = 準備・投票 → 全員YESならコミット、一つでもNOなら中止。YES後のコーディネータ故障 → 不確定状態でブロック。2相コミットは可用性を与えない。
分散結合 = 転送量の最小化、セミジョイン。
DWH = サブジェクト指向・統合・時系列・不揮発。OLTPの単純コピーではない。データマート = 目的別の部分集合。
ETL = 変換してからロード、ELT = ロードしてからDWH内で変換。クレンジング = 統一・重複統合・欠損処理。
ロールアップ = 粗く、ドリルダウン = 細かく、スライス = 一つの値に固定、ダイス = 複数の範囲、ピボット = 軸の入替え。

13. オリジナル診断5問

以下の問題はMotitoryが作成したオリジナル（非公式）であり、IPAの過去問題を使用・翻案していない。

Q1 — 分割

データの分割に関する記述として正しいものはどれか。

A. 水平分割は同じ行を複数のノードに重ねて格納するので、レプリケーションの一形態である。

B. 垂直分割では各断片に主キーを残しておき、キーで結合すれば元の行を復元できる。

C. シャーディングは、表を列単位で分けて別々のサーバに置く方式である。

D. 水平分割した断片どうしは、主キーで結合して元の表を復元する。

A：誤り。水平分割の断片は互いに異なる行を持つ。同じデータを重ねて持つのはレプリケーションである。
B：正解。 キーが各断片にあるから、結合で元の行に戻せる（計算例1の手順5）。
C：誤り。シャーディングは行単位（水平）の断片をサーバごとに置く方式である。
D：誤り。水平分割の断片は和集合（UNION）で復元する。キーの結合で復元するのは垂直分割である。

Q2 — 2相コミットの障害

2相コミットで、参加者P1がYESを投票した後、決定を受け取る前にコーディネータが故障した。P1に関する記述として正しいものはどれか。

A. P1はYESを投票したので、単独でコミットしてよい。

B. P1は一定時間内に決定が来なければ、単独でロールバックしてよい。

C. P1は不確定状態であり、準備状態とロックを保ったまま、決定を知ることができるまで待たなければならない。

D. 2相コミットは、コーディネータが故障しても全参加者が処理を続けることを保証するので、可用性には影響しない。

A：誤り。他の参加者がNOを投票し、コーディネータがABORTを決めたかもしれない。
B：誤り。コーディネータが既にCOMMITを決め、他の参加者がコミットしたかもしれないので、タイムアウトだけで単独ロールバックすると原子性が崩れる。
C：正解。 YESの後は単独で決められず、ブロックされる（計算例2の(c)）。
D：誤り。2相コミットは原子性のためのプロトコルであり、コーディネータ故障時に参加者をブロックしうる。可用性は提供しない。

Q3 — 一貫性とCAP

複製された分散データベースに関する記述として正しいものはどれか。

A. CAP定理によれば、分散データベースはいつでもC、A、Pのうち好きな二つを自由に選べる。

B. ネットワーク分断で複製が分かれている間は、すべての要求に応答する可用性と、常に最新の値を返す一貫性を同時に完全には満たせない。

C. 結果整合性とは、複製が最終的に一致しさえすれば、確認済みの更新を任意に失ってもよいという意味である。

D. BASEは、ACIDと同じ原子性をより高い性能で保証する規格である。

A：誤り。選択は分断が起きたときにCとAの間で生じる。「好きな二つ」は不正確で、分断がなければCAPは何も強制しない。
B：正解。 CAP定理の正確な記述である。
C：誤り。結果整合性は更新が止まれば収束するという保証であり、任意の消失を許す定義ではない。耐久性と競合解決は別途設計する。
D：誤り。BASEは可用性と結果整合性を優先する設計方針であり、保証ではない。ACIDの原子性を提供するという意味でもない。

Q4 — ETLの計算

出所Aが1日900,000行、出所Bが1日600,000行を送る。合わせた入力の4%がクレンジングで拒否または統合され、ロードされないと仮定する。7日間毎日同じ量なら、7日間でロードされる行数はどれか。

A. 10,500,000行

B. 10,332,000行

C. 10,080,000行

D. 1,440,000行

A：誤り。(900,000 + 600,000) × 7で、4%の拒否・統合を引いていない。
B：誤り。4%を出所Bだけに適用している。600,000 × 0.04 = 24,000、(1,500,000 − 24,000) × 7 = 10,332,000。
C：正解。 1,500,000 × 0.04 = 60,000、1,500,000 − 60,000 = 1,440,000行／日、× 7 = 10,080,000行。
D：誤り。1日のロード量であり、7日間の合計ではない。

Q5 — DWHとOLAP

商品 × 地域 × 月の売上キューブを分析する。正しいものはどれか。

A. 月別合計を四半期別合計に切り替えて見ることは、ドリルダウンである。

B. 地域をR1一つに固定し、商品 × 月の表を見ることは、スライスである。

C. レポートの行と列を入れ替えると集計値が変わり、この操作をダイスという。

D. データウェアハウスは毎晩OLTPのDBを変換なしでコピーしたものなので、分析にも同じ正規化スキーマをそのまま使う。

A：誤り。より粗い水準に上げるのはロールアップである。ドリルダウンはその逆方向である。
B：正解。 一つの次元を一つの値に固定して断面を見るのがスライスである。
C：誤り。軸を入れ替えるのはピボットで、集計値は変わらない。ダイスは複数の次元で範囲を選び、小さなキューブを切り出す操作である。
D：誤り。DWHは複数の出所を統合・クレンジングして履歴とともに蓄積し、スタースキーマのような分析向けの構造を使うことが多い。

正解：B、C、B、C、B

14. セルフチェックと復習スケジュール

水平分割・垂直分割・シャーディング・レプリケーションを「何を分け、どう復元するか」で区別できる。
計算例1の7.2 GB、40%、21.6 GBを仮定とともに再計算できる。
同期・非同期レプリケーションのトレードオフと「レプリケーションはバックアップではない」ことを説明できる。
CAP定理を「分断中」という条件を入れて正確に言える。
2相コミットの二つの相と、YES投票後の不確定状態がブロックする理由を言える。
DWHとOLTPの違い、データマート、ETLとELTの違いを言える。
計算例3の1,960,000行／日と58,800,000行を再計算できる。
ロールアップ・ドリルダウン・スライス・ダイス・ピボットを例とともに区別できる。

推奨する復習サイクル（公開スケジュールとは別）：当日、計算例1〜3を見ずに再計算 → 1日後、Q1〜Q5 → 3日後、クイックシートだけを見て用語表の空欄を埋める → 7日後、行数・率・複製数を変えて計算例1と3を新たに計算し、間違えた問題を再確認。

15. 公式出典

IPA 試験要綱・シラバスの概要 — 各試験区分の試験要綱とシラバスが公開されているIPAのページ。APシラバスの公式掲載場所の確認に使った。2026-10-22確認。
IPA 応用情報技術者試験シラバスVer.7.2（PDF） — 出題範囲の根拠となるシラバス本文。本記事は大分類3／中分類9 データベース／5. データベース応用の（1）データベースの応用と（2）分散データベースに対応させた。2026-10-22確認。
IPA シラバスの変更情報 — シラバスの改訂履歴と変更点を確認するページ。2026-10-22確認。
IPA 2026年度試験情報 — 2026年度の試験日程・実施案内のページ。出題範囲ではなく試験実施情報の確認に使う。2026-10-22確認。

本記事はAP33–38仕上げ計画の3回目である。次に予定しているテーマはAP36 ファシリティマネジメントで、シリーズはAP38で完結する。