正規化

論理設計 ≒ 正規化　とも言えるほど重要

異なるレベルのエンティティをテーブルとしてわけてあげる作業

【正規形】：保持するデータの重複が排除されたデータ形式

　　　重複があると面倒な更新処理が発生する

第1～第5正規形 があるが、業務では第3正規形まででOK

　第1正規形：1つのフィールドには1つの値に

　第2正規形：部分関数従属の解消

　第3正規形：推移的関数従属の解消

1つのフィールドには1つの値しか含まないという原則を満たした形式

主キーが各行の値を一意に定めることができなくなり主キーの定義に反するため。

テーブルとは呼べなくなる

＜NG例＞

＜イマイチな例１＞行に分ける方法

主キーを定められない　主キーにNULLは禁止

＜イマイチな例２＞列に分ける方法

子供の列をいくつ用意すればよいか不明、大量のNULL値が発生

＜良い例＞テーブルを分ける方法

※子供テーブルは「社員ID」と「子供」で主キーとなっている

※「社員ID」は外部キー

【関数従属性】：Xが決まればYが決まる 関係性

　　　　　　　　YはXに従属する　｛X｝→｛Y｝

正規化とは　｛主キー｝→｛すべてのカラム｝　を成立させること

部分関数従属が解消されて、完全関数従属のみのテーブルになっている形

【部分関数従属】：複数列の主キーの一部のみに対して従属する列がある状態

【完全関数従属】：主キーを構成するすべての列に対して従属性がある状態

＜部分関数従属の例＞

会社IDと社員IDの組合せが主キーだが、会社名は会社IDにのみ従属している。

＜完全関数従属の例＞

会社IDが外部キーとなり

会社名を別テーブルに分ける

推移的関数従属が解消されている形

【推移的関数従属】：2段階の関数従属がある状態

　　　　　　　　　　｛会社ID，社員ID｝→｛部署ID｝→｛部署名｝

それで困ること：社員がいない部署をテーブルに反映できない

　　　　　　　　過去に存在した部署、一時的欠員の部署など

こちらもテーブルを分けて正規化する

※第1～3正規形のいずれも、異なるレベルのエンティティをテーブルとして分離してやる作業