第1段階,第2段階...と進めていくことができ、その段階によって分類されています。ここではその分類について示します。例として示すテーブルは正規化の実例の節で挙げた販売管理に関するものと同じであり、ここではそれを定義に沿って再度見直していくものとします。定義を理解するにあたって必要な要素はすべて説明してきましたので問題はないものと思いますが、候補キー(という概念)に対する理解は特に重要ですので、主キー(という機能)との区別を含めてきちんと理解しておいてください。「第2正規形とは主キーに対して...であるもの」といった説明がされることがありますが、これは主キー以外のキーが定義されていない段階での便宜的な説明です。そこを曖昧にしたまま候補キーと主キーを混同してしまうと、「主キーが設定されていなければ正規化の度合いを判断できない」あるいは「主キーが設定されていなければ正規化を進められない」といった誤解につながってしまいますので注意してください。生じないため第1正規形であれば即ち第2正規形である」というのもありがちな誤解の一つですので注意してください。正規されていない状態を指しますので、正規化した状態を定義しておけば十分ではありますが、実例を示す意味でもあえて挙げておきます。定義としては単一でない値、繰り返し列のいずれかが存在する。単一でない値とは、スペース、カンマ、改行などで区切られた複数の値を単一の値のように扱っているものを指します。おいてカンマ区切りによる単一でない値が使われていますので非正規形です。1900,7000また、次のテーブルには単一でない値はありませんが、全く同じ意味をもつ列が複数現れています。具体的には商品コード1と商品コード2、商品名1と商品名2、単価1と単価2、数量1と数量2です。このような列を繰り返し列といいます。繰り返し列があるためこのテーブルも非正規形です。7000非正規形のテーブルには多くの問題が存在します。具体的に挙げると以下のようなものです。計算が複雑・困難である。行を追加できる条件(この例では販売という事実)が整わないと基本的にデータを追加できない。同じ情報が繰り返し記録されるため、変更時に変更漏れがあると矛盾を生じる。行を削除したときに必要以上に情報が失われることがある。正規化を進めることにより、これらの問題を順次解決していくこととなります。第1正規形の定義は次のようになります。単一でない値、繰り返し列がいずれも存在しない。非正規形のテーブルにおいて現れていた単一でない値、繰り返し列というのを解消したものが第1正規形です。解消するかいうと、データの量に応じて必要なだけ多くの行(列ではなく)を使うような構造のテーブルとします。第1正規形は次のようになります。7000第1正規形となったことにより、売上額や数量の計算に関しては2つの列を参照するだけでよくなり、集計も容易な形になっていることがわかります。第2正規形の定義は次のとおりです。第1正規形であり、かつ、すべての非キー属性が候補キーに完全関数従属している(部分関数従属していない)。上記の第1正規形は、1件の販売に含まれる商品の種類が1つ増えるごとに行も1つ増えるつくりになっておりますので、販売IDと商品コードを特定できれば行を1つに特定できます。{販売ID,商品コード}が候補キーとなっています。すべて非キー属性です。1つに特定することができます。1件の販売において販売先は1つしかないからです。{取引先コード,取引先名,取引先所在地}は候補キーである{販売ID,商品コード}に部分関数従属しています(完全関数従属していません)。よってこのテーブルは第1正規形ではありますが第2正規形ではありません。取り出すようにテーブルを分割します。販売先に関する部分関数従属を解消したテーブルは次のようになります。7000販売テーブルは1件の販売ごとに1行増えるつくりになっており、候補キーは販売IDです。よって、もはや部分関数従属は存在しません。一方の販売明細テーブルをみると商品に関する部分関数従属が残っています。このテーブルでは依然として{販売ID,商品コード}が候補キーとなっていますが、販売IDと商品コードの両方を特定しなくとも、商品コードさえ特定できれば商品名、単価を1つに特定することができます。{商品名,単価}は候補キーである{販売ID,商品コード}に部分関数従属しています(完全関数従属していません)。よって第2正規形ではありません。そこで、この部分関数従属に係る列、つまり商品コード、商品名、単価を取り出すようにテーブルを分割し、部分関数従属を解消します。結果として第2正規形は次のようになります。第3正規形の定義は次のとおりです。第2正規形であり、かつ、どの非キー属性も候補キーに対し推移的に関数従属していない。上記の第2正規形のうち、販売テーブルの候補キーは販売IDです。販売IDは取引先コードに関数従属していません。{取引先名,取引先所在地}は販売IDに対し推移的に関数従属しています。よって第3正規形ではありません。取り出すようにテーブルを分割し、推移的関数従属を解消します。結果として第3正規形は次のようになります。第3正規形までの定義と実例をみてきました。理論的にはその他にボイスコッド正規形、第4正規形、第5正規形まで定義されていて、さらには第6正規形が提唱されていますが、これらについてはより詳細な概念と実例を必要としますのでここでは省略します。実用的には第3正規形まで進めれば十分であるとされています。いうと、第3正規形までの正規形では、下位の正規形に含まれている情報が完全に保たれ、正規化を進めることで何かが損なわれるということはありえませんが、ボイスコッド正規形以上の正規形では、関数従属性の一部が損なわれてしまう場合があるというのが一つの理由です。損なわれない場合もありますので、そうした場合は正規化を進めない理由も特にありません。込み入った複雑な関数従属性が存在しない限り、第3正規形より上位の正規形を考慮する必要がそもそもないこと。上位の正規化が可能であるとしても、テーブルの追加や更新、削除の状況からみて問題が発生しにくく、むしろテーブルの分割や設定、そして(クエリにおける)結合の計算コストの増大が懸念されること。前者は単なる楽観主義ともいえますが、後者の考え方は非正規化という手法につながるものです。非正規化については次の節で詳しく説明します。テーブルの例示について正規化を進めると上記の販売明細テーブルのようにコードや数字記号のみで構成されるテーブルも増えてきますが、このようなテーブルを単独で示しても、何を記録したテーブルなのかがわかりにくいです。そこで、このサイトにおいては、コード化されているのが自然な例であっても次の例のように名称等をそのまま表示する場合がありますのでご注意ください。読者になるこのブログについてスポンサーリンク注目記事サイト内検索スポンサーリンクはてなブログをはじめよう!accs2014さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。