【DB概論】正規化の手順：できるエンジニアになる！ ちょい上DB術・基礎編（7）（1/2 ページ）
デキるエンジニアになるためには、DB技術の基礎は必須です。本連載では、豊富な実例と演習問題で、プロとして恥ずかしくない設計手順を解説します。DB設計のポイントとなる汎用的なケースを紹介しているので、通常の業務とは異なる場合でも応用できる「共通の考え方」を身に付けられます。
正規化の手順
正規化は、データの一元管理を行うために、データベース設計で行うべき手順です。
図1 正規化の手順正規化とは、データを一元管理するための理論です。
1データ1箇所の原則を実現するために、1970年にE.F.Codd氏がリレーショナルモデルの理論として提案しました。正規化の理論は、データの冗長性を排除し、更新時の整合性を維持しやすくすることを目指しています。
具体的には、属性間の関連性を分析し、属性の最適なグループ化を図ることを目的としています。 一般には第3正規化まで行えば十分といわれていますが、本来は、あてはまる場合にはきちんと第5正規化まで行う必要があります。 まず、正規化の処理をする際によく出てくる関数従属という用語の意味を復習しておきましょう。
◎ 関数従属とは
ある属性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」が得られ、既存の関数従属から新たな関数従属が得られる状態を表します。
正規化の手順
正規化の手順を、ある受注伝票を例にとって説明します。 まず、実際の業務で目に触れているデータは、非正規形といわれる状態で管理されています。
図2 受注伝票非正規形
現実の世界では、データは属性の集合として存在しています。
つまり注文伝票や納品伝票などの形で存在しているデータは、属性の集合ということができます。 通常、これらの属性は正規化されていません。 これを非正規形といいます。
導出属性
導出属性は、正規化の作業を行う場合、取り除くのが原則です。
ただし、実際の設計では、管理項目を上流工程で削除してしまうと、元々管理されていた属性を失ってしまい、後で復活させることは難しくなります。 そこで、導出属性である旨明記した上でER図には残しておきます。 この非正規形のデータ集合を表の形に成形します。
図3 非正規形のデータ集合を表の形に成形表の形に成形する際、表の定義として以下の2点に留意してください。
- 表を定義する列は、1列につき1個しか入れない。
- 表の1行を特定できるキー列（一意識別子）を考える。
非正規形のデータを、これから正規化していく前準備として表の形に成形しました。 次のように表すことができます。
図4 受注伝票を表に成形それでは、この形を基に、正規化の作業を順次、進めていきましょう。
第1正規化
第1正規化では、同一の情報のグループが繰り返し出現している部分を分離します。その結果、第1正規形は、繰り返しの配列構造が排除された構造になります。
第1正規化の手順
- 同じ属性が繰り返されている部分の重複をなくす。 すると、細かい複数の表に分かれるので、元の表と結合できるように、分けた表に元の表のキー項目（主キー）を外部キーとして入れる。
- 1．を具体的に説明すると、まず、属性が繰り返し出てきているグループを別の表に分解し、元表の残った行と、分解した繰り返しグループの行を一意に決められる、主キーをそれぞれ定義する。
- 次に、 分解した表の行と元の表の関係を維持することを目的として、分解先の表に元の表と結合できるように、キー項目（外部キー）を定義する。
受注伝表の第1正規化をしてみよう
- 元の表のキーは「注文番号」。
- 繰り返しグループを図5のように分解し、主キーをそれぞれ＊がついている属性とする。
- 分解した注文明細表と注文表との関係は、注文明細表に取り込んだ「注文番号」を使用して参照できるようにする。注文明細表の「注文番号」は、注文表への外部キー。
図5 第1正規形Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。