データベース - 正規化

提供:MochiuWiki : SUSE, EC, PCB
2024年1月22日 (月) 19:51時点におけるWiki (トーク | 投稿記録)による版 (→‎非正規形とは)
ナビゲーションに移動 検索に移動

概要

データベースの正規化とは、データを扱いやすくするために行うデータベース設計の理論である。

1データ1箇所の原則を実現するため、1970年にE.F.Codd氏がリレーショナルモデルの理論として提案された。
正規化の理論は、データの冗長性を排除し、更新時の整合性を維持しやすくすることを目指している。

データベースは常にレコードが追加、更新、削除されている。
もし、正規化を適切に行っていない場合は、データベースのレコード間で矛盾が発生して、データベースとして役割を果たさない。

データベースの正規化の目的は、データの重複や不要な依存関係を排除することである。
これにより、データの整合性を維持できるようになる。


関数従属

関数従属とは

ある属性Aの値が決まると他の属性Bの値が一意に決まる時、属性Bは、属性Aに関数従属である (A -> B) という。

完全従属

完全従属とは、2つの属性A、Bの間でA -> Bが成立して、Aが複数の属性の集合で成り立っている場合、属性Aのいかなる部分集合も関数従属が成立しない状態を表す。

部分従属

部分従属とは、関数従属が成立しているが、完全従属ではない状態を表す。

推移従属

推移従属とは、エンティティの3つの属性A、B、Cにおいて、A -> B、 B ≠ A、 B -> Cである時、 A -> Cが得られ、既存の関数従属から新たな関数従属が得られる状態を表す。


正規化の手順

正規化は、データの一元管理を行うために、データベース設計で行うべき理論である。
一般的には、第3正規化までを実施すればよいと云われているが、理論に当てはまる場合には第5正規化まで行う必要がある。

Database Normalization 1.png
図. 正規化の手順




非正規形

非正規形とは

現実の世界では、データは属性の集合として存在している。

例えば、注文伝票や納品伝票等の形で存在しているデータは、属性の集合ということができる。

一般的に、これらの属性は正規化されていないため、非正規形と呼ぶ。

下図に示す受注伝票を例にして、正規化の手順を実施する。

Database Normalization 2.png
図. 受注伝票



導出属性

導出属性は、正規化の作業を行う場合、取り除くのが原則である。

ただし、実際の設計では、管理項目を上流工程で削除する場合、元々管理されていた属性を失い、後で復旧することは困難となる。
そこで、導出属性である旨を明記した上でER図に記述する。

この非正規形のデータ集合を表の形に成形する。

図. 非正規形のデータ集合を表の形に成形



表の形に成形する場合、表の定義として以下に示す2点に注意する。

  • 表を定義する列は、1列につき1つのみとする。
  • 表の各行を特定できるキー列(一意識別子)を考える。


下図に、非正規形のデータを表の形に成形している。

表として成形




第1正規化

第1正規化とは

第1正規化では、同一の情報のグループが繰り返し出現している部分を分解する。
その結果、第1正規形は、繰り返しの配列構造が排除された構造となる。

第1正規化の手順

  • 重複の削除
    同じ属性が繰り返されている部分の重複を削除する。
    この時、細かい複数の表に分解されるため、元の表と結合できるように、分解した表に元の表のキー項目(主キー)を外部キーとする。

    まず、属性が繰り返し出現するグループを別の表に分解して、元の表に残った行と、分解した繰り返し出現するグループの行を一意に決められる主キーをそれぞれ定義する。
    次に、 分解した表の行と元の表の関係を維持することを目的として、分解先の表に元の表と結合できるようにキー項目(外部キー)を定義する。


例: 受注伝票の第1正規化

  1. 元の表のキーを注文番号とする。
  2. 下図に示すように、繰り返しグループを分解して、主キーをそれぞれ*がついている属性とする。
  3. 分解した注文明細表と注文表との関係は、注文明細表に取り込んだ注文番号を使用して参照できるようにする。
  4. 注文明細表の注文番号は、注文表への外部キーとする。


図. 第1正規形