正規化
T.Takao
正規化とは、表より冗長性を
排除し、データ要素の従属性の強いものごとに表を作ることである。正規化することにより、決まった手順で矛盾、無駄のない表を作ることができる。第一正規
化から第五正規化まであるが、代表的な第一正規化から第四正規化までを簡単に説明する。なお、正規化について議論する場合、表という列、行をふくんだあい
まいな表現でなく、リレーションというデータの集合をあらわす言葉が使われることもあるが、ここではなじみのある表という言葉を使う。
・第一正規化
データの繰り返しをなくす。
例： 受注番号 顧客番号 顧客名 顧客連絡先 受注品目１ 受注個数
受注品目２
受注個数
このままだと、品目数に制限がでてくる。このような繰り返しはやめる。
受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数
受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数
これを「関数従属」にするという。
・第二正規化
第一正規形の表において、キーに従属していない属性（列）があれば、キーで特定できる表に分割する。
例： 受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数
このままだと、顧客が注文しないと連絡先をかえられないし、連絡先をかえようとするとすべてのレコードを調べなければならないので切り出す。
受注番号 顧客番号 受注品コード 受注品単価 受注個数
顧客番号 顧客名 顧客連絡先
これを「完全関数従属にする」という。
また、ひとつの項目のみでユニークなキーとできない場合、複数の項目を組み合わせてユニークなキーとする。これを「複合キー」という。例えば上記の例で、受注番号が顧客ごとに採番されているとすると、「受注番号＋顧客番号」でキーとする。
・第三正規化
第二正規形の表において、キーを構成しないが、異なる項目間で関係が見いだせる場合は、別の表に分割する。
例: 受注番号 顧客番号 受注品コード 受注品単価 受注個数
この中で受注品コード、受注品単価は関係があるので、別の表とする。
受注番号 顧客番号 受注品コード 受注個数
受注品コード 受注品単価
ここで項目間に関係があることを「中間従属性」とか「推移従属性」という。
・第四正規化
多値従属性のあるものは、表をわける。
例：
|
社員番号 |
プロジェクト |
技能コード |
|
100 |
A |
1 |
|
100 |
A |
2 |
|
100 |
A |
3 |
|
100 |
B |
1 |
|
100 |
B |
2 |
|
100 |
b |
3 |
こういう場合、次の２つの表にわける。
|
社員番号 |
プロジェクト |
|
100 |
A |
|
100 |
B |
|
社員番号 |
技能 |
|
100 |
1 |
|
100 |
2 |
|
100 |
3 |
正規化の問題
論理的には、このように表をデータ強度の強いものに分割していくべきである。
しかり、実際にデータベースを設計する場合は、データベースのパフォーマンスを考慮せざるを得ない。
テーブルをふやすことは、参照する場合、テーブルを数多く結合することを意味する。ＤＢＭＳの探索ロジックによるが、最悪の場合（といってもしばしば起こるが）テーブルのフルスキャンが行われる。
したがって、アプリケーションが特定のテーブルグループでしか参照しない、とか、特定のテーブルを頻繁に参照するといった場合、あえて、非正規化したままの形でテーブルを作成することがある。
このような作業を「データベースの物理設計」という。
以上、
