DBの正規化

正規化

T.Takao

正規化とは、表より冗長性を
排除し、データ要素の従属性の強いものごとに表を作ることである。正規化することにより、決まった手順で矛盾、無駄のない表を作ることができる。第一正規
化から第五正規化まであるが、代表的な第一正規化から第四正規化までを簡単に説明する。なお、正規化について議論する場合、表という列、行をふくんだあい
まいな表現でなく、リレーションというデータの集合をあらわす言葉が使われることもあるが、ここではなじみのある表という言葉を使う。

・第一正規化

データの繰り返しをなくす。

例: 受注番号 顧客番号 顧客名 顧客連絡先 受注品目1 受注個数
受注品目2
受注個数

このままだと、品目数に制限がでてくる。このような繰り返しはやめる。

受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数

受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数

これを「関数従属」にするという。

・第二正規化

第一正規形の表において、キーに従属していない属性(列)があれば、キーで特定できる表に分割する。

例: 受注番号 顧客番号 顧客名 顧客連絡先 受注品コード 受注品単価 受注個数

このままだと、顧客が注文しないと連絡先をかえられないし、連絡先をかえようとするとすべてのレコードを調べなければならないので切り出す。

受注番号 顧客番号 受注品コード 受注品単価 受注個数

顧客番号 顧客名 顧客連絡先

これを「完全関数従属にする」という。

また、ひとつの項目のみでユニークなキーとできない場合、複数の項目を組み合わせてユニークなキーとする。これを「複合キー」という。例えば上記の例で、受注番号が顧客ごとに採番されているとすると、「受注番号+顧客番号」でキーとする。

・第三正規化

第二正規形の表において、キーを構成しないが、異なる項目間で関係が見いだせる場合は、別の表に分割する。

: 受注番号 顧客番号 受注品コード 受注品単価 受注個数

この中で受注品コード、受注品単価は関係があるので、別の表とする。

受注番号 顧客番号 受注品コード 受注個数

受注品コード 受注品単価

ここで項目間に関係があることを「中間従属性」とか「推移従属性」という。

・第四正規化

多値従属性のあるものは、表をわける。

例: 

社員番号

プロジェクト

技能コード

100

A

1

100

A

2

100

A

3

100

B

1

100

B

2

100

b

3

こういう場合、次の2つの表にわける。

社員番号

プロジェクト

100

A

100

B

社員番号

技能

100

1

100

2

100

3

正規化の問題

論理的には、このように表をデータ強度の強いものに分割していくべきである。

しかり、実際にデータベースを設計する場合は、データベースのパフォーマンスを考慮せざるを得ない。

テーブルをふやすことは、参照する場合、テーブルを数多く結合することを意味する。DBMSの探索ロジックによるが、最悪の場合(といってもしばしば起こるが)テーブルのフルスキャンが行われる。

したがって、アプリケーションが特定のテーブルグループでしか参照しない、とか、特定のテーブルを頻繁に参照するといった場合、あえて、非正規化したままの形でテーブルを作成することがある。

このような作業を「データベースの物理設計」という。

以上、

コメント