ER図とテーブル設計 — リレーションの考え方と正規化
テーブル設計はシステムの土台です。 ここが崩れると、あらゆる機能の実装に歪みが伝播します。 逆に、テーブル設計がしっかりしていれば、APIもバリデーションも自然と整います。
この章では、ER図の読み書きから正規化の考え方、実務での判断基準までを整理します。
学習者テーブル設計って、とりあえず必要そうなカラムを並べればいいんじゃないの？正規化って何…？
ER図とは何か
ER図（Entity-Relationship Diagram）は、データの構造とリレーション（関連）を可視化する図です。 テーブル設計の前にER図を描くことで、「どのデータがどう関係しているか」をチーム内で合意できます。
リレーションの種類
| リレーション | 説明 | 例 |
|---|---|---|
| 1:1 | 一方のレコードに対して相手も1つ | users ↔ user_profiles |
| 1:N | 一方のレコードに対して相手が複数 | users → orders |
| N:N | 双方とも複数（中間テーブルが必要） | products ↔ tags |
残りのセクションは現在執筆中です。
- 正規化（第1〜第3正規形）の考え方
- 非正規化する判断基準（パフォーマンスとのトレードオフ）
- 論理削除カラム（deleted_at）の設計
- インデックス設計の基本
- テーブル定義書のテンプレート
ちゃんと使うためのポイント
- テーブル設計はシステムの土台。後から変更するコストが最も高い
- まずER図で全体のリレーションを俯瞰し、その後カラムレベルに落とす
- 正規化は原則だが、パフォーマンス要件によっては意図的に崩す判断もある
- 「なぜこの構造にしたか」をテーブル定義書に残しておく
次の章では、テーブルの上に乗るAPI設計の基本を見ていきます。