正規化
更新時異常を排除するためにテーブルを関数従属性に基づいて分割する、正規化の基礎から実務判断まで。
推奨する学習順序
- 基礎01なぜ正規化が必要かなぜ正規化が必要か
正規化されていないテーブルでは、同じ事実を複数の行に重複して持つために、挿入・更新・削除の各操作で矛盾や情報損失が発生する。この「更新時異常」を体系的に排除するのが正規化の目的である。
- 基礎02関数従属性関数従属性 (Functional Dependency)
属性 X の値が決まると属性 Y の値も一意に決まる関係を関数従属という。この概念は 1NF〜3NF、BCNF まで正規化の全ステップの判定基準になる。部分関数従属・推移関数従属など派生概念も整理する。
- 基礎03キーの階層キーの階層 (スーパーキー・候補キー・主キー)
正規化の議論に入る前に、スーパーキー・候補キー・主キーの3階層と、外部キー・代替キー・複合キーとの関係を整理する。2NF/3NF の「非キー属性」「部分従属」を語るための語彙を揃える。
- 基礎04第1正規形第1正規形 (1NF)
全ての属性がアトミック値をとり、繰り返しグループを含まない状態が第1正規形。非1NF (unnormalized form) の代表例を並置し、1NF に変換する具体的手続きを図解する。
- 基礎05第2正規形第2正規形 (2NF)
複合主キーの一部分にだけ関数従属する非キー属性 (部分関数従属) を切り出して別テーブル化するのが 2NF。単一主キーのテーブルは自動的に 2NF を満たす点も整理する。
- 基礎06第3正規形第3正規形 (3NF)
非キー属性が別の非キー属性を経由して主キーに従属する「推移関数従属」を排除するのが 3NF。実務ではここまで来れば十分と言われることが多い理由も示す。
- 発展07非正規化非正規化とパフォーマンスの実務判断
読み取り性能や運用の都合で、あえて正規化を崩す設計判断が非正規化。何を守り何を捨てるか、カバリングインデックスやマテリアライズドビューとの棲み分けまで含めて整理する。
もっと深くDBを学びたい方へ。
たいてっくが、SQL・データベース設計・パフォーマンスチューニング・ IPAデータベーススペシャリスト対策まで、1対1で学習をサポートします。まずは無料相談から。