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



■非正規形
これを表にすると、以下の1行目のようになります。

注文番号	担当者番号	担当者名	商品番号	商品名	数量	単価
102117	016	鈴木	010	カレー	1	800
			202	サラダ	1	300
			301	コーヒー	1	200
102118	008	田中	012	パスタ	2	900
			301	コーヒー	2	200

※合計金額は自動計算できますので、データベースに記録する必要はありません。

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

■第一正規形
第一正規形では、上記のように、1行に複数の属性があるような状態を解消します。

注文番号	担当者番号	担当者名	商品番号	商品名	数量	単価
102117	016	鈴木	010	カレー	1	800
102117	016	鈴木	202	サラダ	1	300
102117	016	鈴木	301	コーヒー	1	200
102118	008	田中	012	パスタ	2	900
102118	008	田中	301	コーヒー	2	200

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

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

この関係をテーブルにします。
【注文】

注文番号	担当者番号	担当者名
102117	016	鈴木
102118	008	田中

【商品】

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

【注文明細】

注文番号	商品番号	数量
102117	010	1
102117	202	1
102117	301	1
102118	012	2
102118	301	2

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


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

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

【注文】

注文番号	担当者番号
102117	016
102118	008

【担当者】

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

【商品】

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

【注文明細】

注文番号	商品番号	数量
102117	010	1
102117	202	1
102117	301	1
102118	012	2
102118	301	2