はじめに
今回の記事では、正規化についてまとめていきます。
事前知識 （主キーと外部キー）
主キー（Primary Key）
主キーは、各行（レコード）を一意に特定するための列（カラム）で、各テーブルに必ず一つだけ存在する必要があります。
下の従業員テーブルでは、従業員IDで各レコード、つまり一人の従業員を特定することができるため、従業員IDが主キーになります。逆に、名字カラムでは山田、名前カラムでは太郎、部署IDカラムでは1が重複しているため、これらのカラムは主キーになることができません。
カラム名の下線は主キーを表します。
複数のカラムの組み合わせで主キーを構成することもできます。これを複合主キーと呼びます。
外部キー（Foreign Key）
外部キーは、親テーブルの主キーを参照するためのカラムです。下の図では、従業員テーブルの部署IDが外部キーとなり、部署テーブルの部署IDを参照します。
この性質により、親テーブルに存在しない無効なデータを子テーブルに追加することができなくなり、データの整合性が保証されます。（参照整合性制約）例えば、部署テーブルに存在しない総務部というデータを、従業員テーブルに追加することができなくなります。
正規化とは
正規化とは、データベース（DB）に対してデータの追加・更新などの処理を不備なく行うために、事前にテーブルを整理（分割）する作業です。
正規化によって作られる正規形には、第1〜第5までのレベルが存在しますが、基本的には第3までで大部分をカバーできるため、本記事では第3正規形までをまとめていきます。
第1正規形
第1正規形は、以下を満たす状態です。
- テーブル内の各セルに値が一つだけ入っている
下の従業員テーブル（非正規形）では、一つのセルに複数の電話番号が登録されているので、第1正規形を満たしません。そのため、電話番号の数だけ行を保持することで第1正規形を満たすようになります。
ちなみにですが、従業員テーブル（正規形）の主キーは、{従業員ID、電話番号}の複合主キーになります。
第2正規形
第2正規形は、以下を満たす状態です。
- 第1正規形を満たしている
- 主キーの一部に依存する非キー列が存在しない（部分関数従属が存在しない）
さて、以下の従業員テーブルは第2正規形を満たすでしょうか。
このテーブルは第2正規形ではありません。なぜなら、主キーの一部の列に依存する非キー列が存在する、つまり部分関数従属が存在するからです。
このテーブルは、複合主キー {従業員ID、部署ID} を持ち、名前・都道府県コード・住所カラムは従業員IDのみに依存し、部署名カラムは部署IDのみに依存しています。
この部分関数従属を取り除くために次のようにテーブルを分割することで、第2正規形を満たすようになります。
なぜ第2正規形を満たしてないとダメなのか
第2正規形を満たしていない場合、どんな不都合があるのでしょうか。先ほどの第2正規形ではない従業員テーブルを見てみます。
ここで、総務部という部署を新たに設立し、総務部所属の従業員がまだ存在しないとします。
この状況で、総務部をテーブルに追加すると、主キーである従業員IDがNULLになってしまうため、総務部を追加することができません。そのため、先ほどのように部署テーブルを独立させることで、総務部の追加が可能になります。
NOT NULL制約
主キーのカラムには、NULL値を入れることができない。
第3正規形
第３正規形は、以下を満たす状態です。
- 第2正規形を満たしている
- 全ての非キー列が、主キーに対してのみ依存する
→ 非キー列が他の非キー列に依存しない（推移的関数従属が存在しない）
さて、先ほど作成した第2正規形のテーブルは、第３正規形も満たすでしょうか。
答えは、従業員テーブルにおいて住所カラム（非キー列）が都道府県コードカラム（他の主キー列）に依存しているため、第３正規形を満たしません。つまり、このテーブルでは都道府県コードが従業員IDに依存し、住所が都道府県コードに依存しており、2段階の依存関係（推移的関数従属）が存在しています。
以下のように都道府県テーブルを独立させ、2段階の依存関係を解消してあげることで、第３正規形を満たすようになります。
なぜ第3正規形を満たしていないとダメなのか
第3正規形を満たしていない場合、どんな不都合があるのでしょうか。先ほどの第3正規形ではない従業員テーブルを見てみます。
現在、従業員が住んでいる都道府県は、東京都、神奈川県、千葉県です。そして、今後入社してくる従業員が他の都道府県に住んでいる可能性を考慮して、他県のデータを事前に追加したい状況を考えます。この時、従業員IDにNULLを設定しない限り、他の都道府県を追加することができません。そのため、以下のように都道府県テーブルを独立させることで、他県を事前に追加できるようになります。
正規化の欠点
ここまでデータの追加・更新時の不整合をなくすために、正規化を行なってきましたが、正規化にも欠点が存在します。
正規化を行いテーブルを整理・分割していくとテーブル数が多くなります。これまでの例ですと、元々1つだった従業員テーブルが、正規化により最終的に4つのテーブルになりました。
これにより、4つのテーブルに分散したデータを取得する際に、テーブルを結合する必要があり、クエリの実行に時間がかかるようになります。SQLでの結合(JOIN)処理は重たい処理なので、パフォーマンスが低下してしまいます。
ただ、一般的には第3正規形までを行うことが推奨されています。
正規化は無損失分解
正規化によって分割されたテーブルは、正規化する前のテーブルに戻すことができます。これを無損失分解と言います。
参考
達人に学ぶDB設計徹底指南書 初級者で終わりたくないあなたへ（ミック）
Database Normalization – Normal Forms 1nf 2nf 3nf Table Examples