さて、データベースの正規化を実際にやってみましょう。たとえば、レストランでカレーを食べたとき、以下のレシートがあったとします。これをデータベース化しましょう。
database


■非正規形
これを表にすると、以下の1行目のようになります。
注文番号担当者番号担当者名商品番号商品名数量単価
102117016鈴木010カレー1800
202サラダ1300
301コーヒー1200
102118008田中012パスタ2900
301コーヒー2200
※合計金額は自動計算できますので、データベースに記録する必要はありません。

上記の表の場合、1つの注文番号に、商品が複数並んでいますので、データベースとしては適正な状態ではありません。そこで、正規化を行います。

■第一正規形
第一正規形では、上記のように、1行に複数の属性があるような状態を解消します。
注文番号担当者番号担当者名商品番号商品名数量単価
102117016鈴木010カレー1800
102117016鈴木202サラダ1300
102117016鈴木301コーヒー1200
102118008田中012パスタ2900
102118008田中301コーヒー2200

これで、以下の注文テーブルが出来上がりました。
注文(注文番号,担当者番号、担当者名、商品番号,商品名,数量,単価)

■第二正規形
第二正規形では、候補キー(およびその一部)からの関数従属性を分割します。
さて、このテーブルの候補キーは何でしょうか。候補キーは、注文番号と、商品番号です。つまり、この2つが決まると、すべての属性が決まります。
候補キーおよびその一部は「注文番号」「商品番号」「注文番号、商品番号」の3つです。この3つからの関数従属性は以下です。
・注文番号→担当者番号、担当者名
・商品番号→商品名、単価
・注文番号、商品番号→数量

この関係をテーブルにします。
【注文】
注文番号担当者番号担当者名
102117016鈴木
102118008田中

【商品】
商品番号商品名単価
010カレー800
012パスタ900
202サラダ300
301コーヒー200

【注文明細】
注文番号商品番号数量
1021170101
1021172021
1021173011
1021180122
1021183012

これで、以下の3つのテーブルが出来上がりました。
注文(注文番号、担当者番号、担当者名)
商品(商品番号、商品名、単価)
注文明細(注文番号、商品番号、数量)


■第三正規形
第三正規形では、候補キー以外の属性にて関数従属性がある場合,その関係を分解します。
今回の場合、注文テーブルにおいて、担当者番号→担当者名という関数従属性があります。
これ分解すると、以下の2つのテーブルになります。
注文(注文番号、担当者番号)
担当者(担当者番号、担当者名)

最終的には以下の4つのテーブルが出来上がります。
注文(注文番号、担当者番号)
担当者(担当者番号、担当者名)
商品(商品番号、商品名、単価)
注文明細(注文番号、商品番号、数量)

【注文】
注文番号担当者番号
102117016
102118008

【担当者】
担当者番号担当者名
016鈴木
008田中

【商品】
商品番号商品名単価
010カレー800
012パスタ900
202サラダ300
301コーヒー200

【注文明細】
注文番号商品番号数量
1021170101
1021172021
1021173011
1021180122
1021183012