正規形【normal form】
概要
データベースでは、同じ情報が複数の場所に重複して保存されると、更新時に不整合が発生する可能性がある。例えば、ある顧客の住所を複数のレコードに繰り返し保存している場合、一部だけが更新されて古い値が残留してしまうといった問題が生じることがある。正規形はこのような問題を防ぐために考案された理論的枠組みであり、表に含まれる属性の依存関係を整理して無駄な重複を減らす。テーブルの設計を正規形の基準を満たす形に整理する操作を「正規化」（normalization）という。
第1正規形
「第1正規形」（1NF：1st Normal Form）は最も基本的な形式で、テーブルの各列が原子的な値（それ以上分割できない単一の値）を持ち、繰り返しグループや配列が存在しないことを要件とする。例えば、一つのフィールドに複数の電話番号をカンマ区切りで格納するような設計は排除しなければならない。
第2正規形
「第2正規形」（2NF：2nd Normal Form）は、第1正規形を満たした上で、非キー列がすべて主キー全体に対して関数従属していることを要件とする。複合主キーを持つテーブルで、主キーの一部にのみ依存する列が存在する「部分関数従属」を排除した状態である。例えば、「受注テーブル」で「受注日」「顧客名」「製品コード」が複合主キーを形成するとき、「製品コード」から一意に「製品名」が決まるならば、このテーブルには製品名の列は作らず、別のテーブルで両者の対応関係を管理する。
第3正規形
「第3正規形」（3NF：3rd Normal Form）は、第2正規形を満たした上で、非キー列が別の非キー列に依存する「推移的関数従属」を排除した状態を指す。例えば、「社員テーブル」に「部署コード」と「部署名」が共存している場合、「部署名」は「部署コード」に依存しており推移的従属が生じている。このような場合は「部署コード」のみを残し、両者の対応は別のテーブルで解決する。
より厳格な正規形
さらに厳格な基準として、「ボイスコッド正規形」（BCNF）、「第4正規形」（4NF）、「第5正規形」（5NF）が存在するが、実務上は第3正規形またはボイスコッド正規形までの正規化が一般的である。実用上、過度な正規化はテーブル結合（JOIN句）の増加によるクエリの複雑化や性能低下を招くことがあるため、性能要件を満たすために冗長性に目をつむり、意図的に非正規化を行う場合もある。
共有ボタンをタップ