· 暮らし・ツールガイド

AP科目A 32 — データベースの空白を埋めるAP1–32核心マップの総合診断

応用情報技術者試験 科目AのAP1–32核心マップを締めくくる総合診断として、B-tree・ハッシュ・ビットマップ・カバリングインデックス、ページアクセス数の計算と性能測定、GRANT・REVOKEと最小権限を整理し、オリジナル診断問題5問で確認します。

応用情報技術者試験科目Aデータベースインデックスアクセス制御総合診断

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

2026年IPA応用情報技術者試験科目A、シラバスVer.7.2を基準とし、2026-10-21確認。本資料は合格を保証せず、Ver.7.2の逐条的・網羅的なカバーも主張しない。事例は全て架空である。

改訂履歴：2026-10-28 結びの案内を訂正。本記事はAP1–32の核心マップだけを閉じ、シリーズはAP33–38の仕上げ計画を経てAP38で完結する。

学習インデックス

  1. インデックスの選択
  2. 性能設計と測定
  3. アクセス制御
  4. 技術・管理・戦略の接続
  5. クイックシートと落とし穴
  6. オリジナル診断5問
  7. セルフチェックと出典

AP1–32の全回は公開シリーズ目次で確認できる。上記のとおり、本シリーズはVer.7.2の逐条的・網羅的なカバーを主張しない。

1. インデックスの選択

  • B-treeインデックス：順序を保つ構造で、=、<、BETWEENなどの等価・範囲条件に通常適する。
  • ハッシュインデックス：等価検索には適する場合があるが順序を保たず、一般的な範囲検索の解として選ばない。
  • ビットマップインデックス：低カーディナリティ列を組み合わせる読取り中心の分析で有効な場合がある。更新頻度が高い環境では同時実行性・保守コストが不利になり得るが、製品・実装依存である。
  • カバリングインデックス：問合せに必要な列を全て供給し、表アクセスを減らし得る。実際の省略可否はDBMS、実行計画、可視性、キャッシュ状態などに依存する。

インデックスを増やすと読取りを高速化できる一方、INSERT/UPDATE/DELETE時の保守、記憶域、キャッシュの費用が増える。選択性（選択度）が低い条件は多数行を読むため利点が小さい場合がある。述語、整列、結合、読書き比率から候補を立て、実行計画と代表負荷で検証する。全DBMSで機能・費用が同一になる方式はない。

2. 性能設計と測定

独立に確認できる単純計算

総操作100回＝読取り80回＋挿入20回のみとする。費用単位は論理ページアクセス数で、待ち、キャッシュ、並列性、競合は無視する。

状態 読取り 挿入 合計 1操作平均
導入前 80 × 1000 = 80,000 20 × 2 = 40 80,040 80,040 ÷ 100 = 800.4
導入後 80 × 4 = 320 20 × 5 = 100 420 420 ÷ 100 = 4.2

この架空モデルでは合計80,040→420、平均800.4→4.2だが、挿入1回は2→5に増える。これは算術例であり実遅延の予測ではない。実システムでは代表SQL・データを使い、前後の実行計画、論理／物理I/O、p50/p95/p99遅延、スループット、ロック待ち、CPU、キャッシュ状態を測定する。

3. アクセス制御

最小権限は業務に必要な権限だけを与える。架空のreport_readerにはordersのSELECTのみを与え、INSERT/UPDATE/DELETEは与えない。order_writerにも必要な書込み権限だけを分離する。定期的に見直し、異動・退職時に取り消す。

以下は補足的なPostgreSQL構文例であり、IPAによる製品推奨ではない。

GRANT SELECT ON TABLE orders TO report_reader;
GRANT INSERT, UPDATE ON TABLE orders TO order_writer;
REVOKE UPDATE ON TABLE orders FROM order_writer;

GRANT／REVOKE、ロール継承、所有者・スキーマ権限、DELETEの扱いの詳細はDBMSで異なり得る。SELECT可能だからINSERT/UPDATE/DELETEも可能、とは限らない。アプリ用アカウント分離、監査ログ、秘密管理も組み合わせる。

4. 技術・管理・戦略の接続

  • 技術：インデックス候補と権限表を設計し、計画・負荷で検証する。
  • 管理：変更承認、回帰試験、監視、権限の定期レビュー、監査ログを運用する。
  • 戦略：SLAと事業KPIを先に定め、読取り改善が書込み・記憶域費用とセキュリティリスクに見合うか判断する。単一問合せの最速化ではなく、事業目標とリスク許容度に合う設計を選ぶ。

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

  • 範囲→B-tree候補、等価→hashも候補、低カーディナリティ・読取り中心→bitmapを慎重に検討。
  • coveringは「必要列を含む」であり、全環境で表I/Oが必ず0になる意味ではない。
  • インデックス増加は書込み・記憶域・保守費用を増やし得る。低い選択性は利点を減らし得る。
  • 平均だけでなく裾の遅延、スループット、計画、負荷を測る。
  • SELECTとINSERT/UPDATE/DELETEは別権限。最小権限、GRANT、REVOKEを区別する。
  • 「常に」「全DBMS」「多いほど良い」「単純計算＝実測」という絶対表現に注意。

6. オリジナル診断5問

過去問を使用・翻案していないオリジナル問題である。

Q1 — インデックス

注文表でordered_at BETWEEN ...の範囲検索と日付順出力が多い。最初の候補として最適なのはどれか。

A. 順序を保たないハッシュだけを使う。

B. ordered_atのB-treeを候補にし、実行計画で確認する。

C. 選択性を問わず全列にbitmapを作る。

D. 書込み費用はないので可能な限り作る。

Q2 — 性能計算と測定

本文の100操作モデルの正しい説明はどれか。

A. 導入前合計は80,400。

B. 導入後平均は42。

C. 合計は80,040から420になるが、実環境では計画・遅延・負荷の測定が必要。

D. 挿入費用も2から1に減る。

Q3 — アクセス制御

報告用アカウントの業務は注文の参照だけである。最小権限に最も合うものはどれか。

A. ordersのSELECTだけをGRANTし、不要な書込み権限は与えないかREVOKEする。

B. SELECTを与えればDELETEも自動的に必要とする。

C. 利便性のため管理者権限を共有する。

D. 異動後も権限を永久に残す。

Q4 — 技術・管理の統合

本番に新インデックスを導入する最適な方法はどれか。

A. 平均を一度だけ見て直ちに全社導入する。

B. 読取りが速いので書込み回帰試験を省く。

C. DBMSが違っても同じ計画と仮定する。

D. 代表負荷で計画・裾の遅延・スループット・書込み影響を試験し、承認・ロールバック・監視を用意する。

Q5 — 戦略の統合

読取りSLAが重要で書込み急増時間もあるサービスの適切な判断方法はどれか。

A. インデックス数をKPIとして最大化する。

B. SLA・事業KPI・リスク許容度を定め、読取り利益と書込み・記憶域・セキュリティ費用を測定する。

C. coveringなら権限レビューは不要。

D. 高速な問合せ一つで投資判断を終える。

正答：2, 3, 1, 4, 2

7. セルフチェックと公式出典

  • B-tree/hash/bitmap/coveringの適用条件と限界を説明できる。

  • 80,040、800.4、420、4.2を再計算できる。

  • 計画・遅延・スループット・負荷を測る理由を説明できる。

  • SELECTと三つの書込み権限、GRANT/REVOKE、最小権限を区別できる。

  • 技術・管理・戦略の判断を一つの説明に接続できる。

  • IPA APシラバスVer.7.2 — DB性能向上・アクセス制御、PDF pp.44–45（冊子pp.40–41）

  • IPAシラバス改訂ハブ

  • PostgreSQL indexes、GRANT、REVOKE — 補足製品文書であり実装差がある。

以上でAP1–32の核心学習マップを閉じる。シリーズ全体はここで終わらない。次回はAP33 コンパイラと言語処理であり、固定の仕上げ計画AP33–38（AP33–36補足編、AP37–38総合診断）を経てAP38で完結する。

ブログへ