Ceeds Academy教材アプリ教材・症状語・タグで検索
索引グラフ試す
DB▸RDB(リレーショナルDB)

DB: テーブル設計の基礎(正規化・主キー/外部キー)

knowledge所要 25分最新草稿
前提: DB: リレーショナルDBの基礎(テーブル・主キー・リレーション)→次: DB: ORM(SQLModel / SQLAlchemy で Python から操作)
意味グラフ(この教材と内容的に近い教材・1ネスト)
例え(Analogies)
テーブル設計=書類の整理棚

正規化は「同じ情報を何度も書かず、1か所にまとめて参照する」整理術。住所を毎回書く代わりに住所表を作り、IDで参照する。

概要

📍 db / design ▸ RDB ▸ テーブル設計の基礎 | 種別: knowledge | facts_as_of 2026-06

公式ドキュメント — knowledge

🎞 スライド

良い設計=正規化 × 適切な PK/FK

重複を減らし、関連で表をつなぐ

正規化(before → after・テキスト図)

before: [order: 顧客名 / 顧客住所 / 商品 ...] ← 顧客情報が重複
│ 分ける
after: [customers: id / 名 / 住所] ◀FK─ [orders: id / customer_id / 商品]

多対多は中間表

[students] ─< [enrollments] >─ [courses]

—
出典(sources)

DB設計の基礎(正規化); PostgreSQL docs ; 2026-06確認

確認問題(Review-Questions)
正規化の目的を一言で。記述
基礎公式
解答・解説▾ 開く

重複を排除し、1か所で管理して不整合を防ぐこと。

多対多の関連はどう表現する?択一
基礎公式
解答・解説▾ 開く

中間テーブル(両者の外部キーを持つ表)を作る。

目次
例え概要公式ドキュメント出典確認問題
鮮度
最新
更新: 2026-06-15
次回棚卸し: 2027-06-15
周期: 12か月
版: RDB一般

概要

良いテーブル設計=正規化(重複を排除)+適切な主キー/外部キー。「何をテーブルに分け、どう関連させるか」を決める。

正規化before/afterとPK/FK
正規化before/afterとPK/FK

公式ドキュメント準拠

  • 正規化:重複データを別表に分けて一元管理(1NF→単一値、2NF/3NF→依存を減らす)。
  • 主キー/外部キーで関連を表現。1対多(user→orders)、多対多は中間表。
  • 命名は一貫性を(複数形テーブル名 / id / *_id 等)。

出典: PostgreSQL Documentation / DB設計(正規化)の基礎

🧭 誤解訂正集

よくある誤解 正しい理解
正規化すれば常に正解 性能とのトレードオフ(意図的な非正規化もある)
主キーは意味のある値がよい 代理キー(id)が無難なことが多い
多対多は1つの表で持てる 中間表で1対多×2 に分けて表す

📖 用語

  • 正規化 … 重複を別表に分け一元管理する設計(1NF/2NF/3NF)。
  • 主キー / 外部キー … 行を一意に特定する列/別表を参照する列。
  • 1対多 / 多対多 … 関連の多重度。多対多は中間表で表す。
  • 中間表 … 多対多を2つの1対多に分けるための橋渡しの表。
  • 代理キー … 意味を持たない id 等を主キーにする方式。

✅ 確認の目安(can-do)

正規化で表を分け、PK/FK と中間表で関連を設計でき、**「どこを正規化し・どこは非正規化が妥当か(性能との兼ね合い)」**を判断できる。