この記事が第5正規形まで簡単にまとまっていてわかりやすかった。
素早く正規形を見抜く実践テクニック
下記メモ。ビジネスロジックを入れなければ第3正規形までで正規化は完了するらしい。
正規化
・1事実1箇所のポリシー
非正規形（※正規形ではないが、第1正規化の対象を非正規形という）
第1正規形（1NF）
第2正規形（2NF）：部分関数従属性の排除
第3正規形（3NF）
ボイスコッド正規形（BCNF）
第4正規形（4NF）
第5正規形（5NF／PJNF）
重複更新(特定テーブルのデータ更新時に複数箇所を更新する必要が生じる)
関数従属性：商品IDが決まれば商品名は一意に決まる
注文明細テーブルが下記の形式だと商品名が変わったら同じ商品IDのデータをすべて更新しなければならなくなる
注文番号、商品ID、商品名、フォーマット、単価、数量
部分関数従属性：複合キーのいずれかに対する関数従属性がある
注文番号、商品IDの複合キーになっているが、商品名とか商品IDに紐付いているよね
注文番号、商品ID、商品名、フォーマット、単価、数量
推移関数従属性：主キー以外のフィールドに関数従属性がある
名前、住所、電話番号って顧客IDに紐付いているよね
注文番号、注文年月日、顧客ID、名前、住所、電話番号、支払い方法
ボイスコッド正規形：非キーからキーへの関数従属性を取り除く
学生、科目が主キーのテーブル。だが講師が決まれば科目も決まるという非キーからキーへの関数従属性がある
学生、科目、講師
↓
講師、科目
学生、講師
ただし、この分解をすると一人の学生が一つの科目を複数の講師から履修できないという制約が失われてしまう。つまり後者のテーブル構造にはそういった登録が可能になってしまう。
ちなみに実際使うとなると上記の分け方は気持ち悪いから、授業フィールドを作ってこうするだろうなとは思う。
学生、科目、講師
↓
学生、授業
授業、科目、講師
第4正規形、第5正規形はキーだけで構成される対照表が対象
多値従属性：チームが決まればメンバーが決まる
チーム名、メンバー名
チーム名、メンバー名、道具名
↓
チーム名、メンバー名
チーム名、道具名
この正規化をしないとチームにまつわる道具が変わったらテーブルの全ての値を更新するハメになる
下記だとチーム名、会場、ダンスの全てが揃わないとデータ登録ができない
チーム名、会場、ダンス
↓
チーム名、会場
チーム名、ダンス
会場、ダンス
テーブル構造からビジネス構造を排除すると第3正規化までで正規化が完了する
専門の人が書いたスライドもあるけど、ちょっと用語がわかりにくい。
http://www.slideshare.net/nippondanji/db-engineerstudyanim?ref=http://nippondanji.blogspot.jp/2013/11/db.html
