データベース
第 11 回 正規化
鈴木幸市
今日の内容
正規化の概要と背景
正規化の段階
第一正規形～第三正規形
演習
正規化 (normalization) とは
実際のデータをテーブルに展開するための方法
効率よく
矛盾なく
データをデータベースに格納するための方法
正規化とは
データの重複がないようにデータベースの構造を作ること
一つの情報は一箇所に格納する。
2 箇所以上に重複格納すると
こらのデータがたまたま違っていると大変
変更の順序もきちんと決めないといろいろ不具合が
デッドロック
どのデータを見るかで結果が違ったり
正規化されていないデータベースも設計できる
故意にそうすることもある
性能の問題
テーブルが増えすぎて、結合演算が多くなるなど（正規化を進めるとテーブ ルの数が増える傾向になる）
正規化されていないところをきちんと意識してアプリケーションの設 計までおこなうことが重要
データの構造をとりあえず書いてみる
（ 1 ）
とりあえずリレーショナルモデルは忘れる
同じ構造のデータがたくさんできるはず
一つしかないものはデータベースにはしない
レコード：たとえば「書籍」
データの構造をとりあえず書いてみる
（ 2 ）
レコードの内容を詳しく書いてみる第一正規形 (the first normal form,
1NF)
データ型で規定される値だけが入っている 繰り返し項目がない
参考書の例では ...
第 1 正規形 (2)
参考書の例
入っているデータは基本データ型のみ → これは OK
伝票明細が繰り返されている → これが第一正規形に違反している！！
伝票明細の枚数が固定なら、「繰り返しではない」と言い張るのもできるが
上記では明細が何枚あるかわからない
第 1 正規形 (3)
どうやって第一正規形にするか？
繰り返し項目を別な表にする
上で作った新しい表にキーをつけて、これを
元の表の外部キーにする。参照制約をつけて
おくとよい。
第一正規形
繰り返し項 目を別なリ レーション にする 伝票番号を
外部キーに する
さらに先に進める前に (1)
関数依存性 (functional dependency) を理
解しておくとよい
テーブルの各カラムの間の論理的な関係
あるカラム X の値が決まると他のカラム Y の値が
決まるような関係の場合、「 Y は X に関数従属であ
る」 という。
X → Y と表記する
例： 学籍番号の値が決まると氏名が決まる 学籍番号→氏名
X → Y かつ Y→ Z の場合、「 Z は X に推移的関数従
属である」という。
例： 学籍番号の値が決まると学部番号が決まる。学部番 号が決まると学部名が決まる
学籍番号→学部番号、学部番号→学部名 すなわち、学籍番号→学部名
第二正規形
テーブルの各カラムの関数従属性が
主キー→主キー以外のカラム
だけになっているもの
候補キー
(*)→ 主キー以外のカラム
があってはならない
(*) 候補キー： 主キーを構成するカラムの部分集 合
第二正規形への変換 (1)
別な例で考える：仕入先情報を考える
仕入れ先名→ ( 住所、代表電話番号 ) ---(1)
( 仕入れ先名、部署名 )→ 担当者内線番号 --- (2)
(1) は第二正規形に適合していない 主キー
これを避けて第二正規形にする 候補キー
第二正規形への変換 (2)
正規化前
正規化後
適合していない従属性の候補キーを主 キーにして、別なテーブルを作る
住所は「仕入 れ先名」に従
属
代表番号は
「仕入れ先 名」に従属
第二正規形になっていないデータベース
の様子
同じデータのコピーが大 量にできてしまう
修正するときは全部一緒 に修正しないとデータに
矛盾が生じる 主キー
第二正規形にした場合のデータベースの
様子
主キーと外 部キーの関
係
データなし重複した 主キー
主キー
もう一つの第二正規形の例
まだ隠れた従属性がある
担当者番号→ (担当者名、担当部署番号、担当部署名 ) 確かに担当者番号は他のカラムの候補キーになっている
担当部署番号→担当部署名 主キー以外のカラム同志
の従属性がある！
遷移従属性
データベースの様子
同じデータのコピーが大 量にできてしまう
修正するときは全部一緒 に修正しないとデータに
矛盾が生じる
担当者を第三正規形にすると
主キー以外の従属性のあ る部分を別のテーブルに する
第 3 正規形にした後のデータベースの様
子
主キーと外 部キーの関
係
データなし重複した
正規化のゴール
まずは第三正規形を目指す
工程は
まず第一正規形に→繰り返し項目を別な表にする
次に第二正規形→第一正規形の候補キーを見つける
さらに第三正規形→第二正規形の中に別な従属性があったらこれも別な表にする
第二正規形 担当者情報
第三正規形 担当部署情報
第三正規形 担当者情報
正規化を行う際のポイント
一つのレコードには繰り返し項目は入れてはいけない
基本型のデータ項目だけで表を作ってみる
テーブルの主キーの
キー以外のデータが複数回現れないようにする
レコードの中に別な従属性はないかを調べてみる
キー以外のデータが複数回現れないようにする
第一正規形
第二正規形
第三正規形
正規化の背景 ( 復習 )
実際のデータをテーブルに展開するための方法
効率よく
矛盾なく
データをデータベースに格納するための方法
正規化とは
データの重複がないようにデータベースの構造を作ること
一つの情報は一箇所に格納する。
2 箇所以上に重複格納すると
こらのデータがたまたま違っていると大変
変更の順序もきちんと決めないといろいろ不具合が
デッドロック
どのデータを見るかで結果が違ったり
カラム間の関数従属性を正しく導き出すことが重要
関数従属性はデータの性質そのもの
正規化されていないデータベースも設計できる
故意にそうすることもある
性能の問題
テーブルが増えすぎて、結合演算が多くなるなど（正規化を進めるとテーブ ルの数が増える傾向になる）
