---
note: 講座全体の索引。全13回の地図・共通データセット(PostShop)・修了判定をまとめた入口
created: 2026-08-14T10:00:00+09:00
---

# データベース・プロフェッショナル養成講座（PostgreSQL・全13回）

> 初心者を「設計・性能・運用・安全の四方向から根拠を語れる実務者」へ引き上げる、全13回の自習教材。

このページは講座全体の索引である。各回は独立した自習ドキュメントになっており、上から順に読むことを想定している。
全回で PostgreSQL 16 系を前提とし、第1回で作る共通の EC データセット（架空のEC「PostShop」）を最後までいじり続ける。

## この講座の進め方

- **内部構造 → 性能 → 運用の順で積む。** 「なぜ遅いか」を説明できないまま小手先のチューニングを覚えると、そこで成長が止まる。
- **毎回、手を動かす。** 各回に再現可能なハンズオンと想定解答を用意した。自分の環境で必ず動かす。
- **一つのデータセットを育て続ける。** 設計の良し悪しもチューニングの効果も、同じデータ・同じクエリで体感する。
- **暗記しない。** 正規形は「どの更新異常を防ぐか」、インデックスは「どのアクセスを速くするか」、制約は「どの不整合を弾くか」で理解する。

## 学習ロードマップ

```text
基礎(1-3) → 設計(4-6) → 内部構造・性能(7-8) → 整合性・安全(9-11) → 運用・スケール(12-13)
```

段階は5つ。**基礎**（1〜3）で関係モデルと SQL を身につけ、**設計**（4〜6）で正規化・型・制約・実務モデリングを積み、
**内部構造・性能**（7〜8）で索引と実行計画を読み、**整合性・安全**（9〜11）でトランザクション・権限・インジェクションを扱い、
最後に**運用・スケール**（12〜13）で定点観測と分散を俯瞰する。

## 共通教材データセット（PostShop）

第1回で以下を投入し、最後まで使い続ける。行数は PostgreSQL でチューニングの差が体感できる規模に設定している。

| テーブル | 概算行数 | 役割 |
|---|---|---|
| `customers` | 約 5万 | 顧客。地域・登録日を持つ |
| `categories` | 約 30 | 商品カテゴリ |
| `products` | 約 5,000 | 商品。カテゴリ・価格 |
| `product_prices` | 約 2万 | 価格の履歴（第6回で使う） |
| `orders` | 約 100万 | 注文。ステータスと注文日時（本データセットの主役） |
| `order_items` | 約 300万 | 注文明細（注文×商品の多対多の実体化） |
| `events` | 約 1,000万 | アクセスログ。パーティション/OLAP 回で使う |

スキーマの詳しい定義とデータ投入手順は[第1回](01-setup-encoding.md)にある。

## 各回一覧

| 回 | タイトル | 主題 |
|---|---|---|
| 1 | [環境構築・エンコーディング/照合順序](01-setup-encoding.md) | Docker で PostgreSQL を立て、教材データを投入。一方通行の初期決定（エンコーディング・collation） |
| 2 | [関係モデルとは何だったのか](02-relational-model.md) | テーブル＝集合。宣言的 SQL への頭の切り替え。三値論理と NULL |
| 3 | [SQL を書ききる](03-writing-sql.md) | JOIN・集約・サブクエリ・CTE・ウィンドウ関数。アプリのループを 1 クエリへ |
| 4 | [論理設計と正規化](04-normalization.md) | ER と関数従属。正規形を「防ぐ更新異常」で理解し BCNF まで分解 |
| 5 | [データ型と制約設計](05-datatypes-constraints.md) | 金額・日時・列挙の型選定。制約を DB 側で守る |
| 6 | [実務のモデリング](06-modeling.md) | 履歴・有効期間・状態遷移・論理削除・非正規化の実務判断 |
| 7 | [ストレージとインデックス＋照合順序の実害](07-storage-indexes-collation.md) | ページ／B-tree／複合索引の列順。照合順序が前方一致検索に効く実害 |
| 8 | [実行計画を読む（虫眼鏡）](08-explain.md) | `EXPLAIN (ANALYZE, BUFFERS)` で遅さの原因を言語化し改善 |
| 9 | [トランザクションと並行制御](09-transactions.md) | ACID・分離レベル・MVCC。ロストアップデートを再現して防ぐ |
| 10 | [権限・ロール・RLS・監査](10-roles-rls-audit.md) | 最小権限・行レベルセキュリティ・監査。superuser 接続からの卒業 |
| 11 | [アプリとの境界＋インジェクション](11-app-boundary-injection.md) | N+1・プール・長時間 Tx と SQL インジェクションを同時に防ぐ |
| 12 | [運用＋pg_stat_statements（定点観測）](12-operations-monitoring.md) | バックアップ・PITR・無停止スキーマ変更・VACUUM・遅いクエリの定点観測 |
| 13 | [スケールと外の世界](13-scaling.md) | レプリケーション・パーティション・OLTP/OLAP 分離・NoSQL/ベクトルDB |

各回の冒頭には「この回で新しく出てくる用語」表がある。回をまたいで繰り返し出る語は
[用語集](glossary.md)にまとめてあるので、読み進めていて意味が取れない語に出会ったらそちらを引く。

## 修了判定（Capstone）

卒業要件は最終課題で判定する。設計レビューでは性能・整合性・運用に加え、権限最小化とインジェクション耐性（安全）も観点に含める。

| 卒業要件 | 判定課題 |
|---|---|
| 遅いクエリを EXPLAIN から特定して直せる | 未知の遅いクエリを渡し、原因特定 → 改善 → before/after を説明（第7・8・12回の応用） |
| 要求仕様から ER を起こし正規化度合いを説明できる | 新しい小さな要求仕様から ER 設計 → 型・制約まで含めて正規化度合いと逸脱理由を説明（第4〜6回） |
| 設計判断を性能・整合性・運用（・安全）から語れる | 上記設計を「なぜこの設計か」で、性能・整合性・運用・権限/安全の観点からレビューに答える |

合格ラインは、各課題で選択の「理由」を自分の言葉で説明できること。正解の暗記ではなく判断の言語化を見る。

## 修了後

全13回の先で、実務経験以外に積めるステップは
[講座修了後のロードマップ](roadmap-after-course.md)にまとめている。