|
■正規化 |
|
|
|
●学習内容 |
|
|
|
|
では、正規化の話です。簡単に言って正規化っていうのは、様々な要素から構成されているテーブルを分離させてしまう事です。しかし、勘や経験でテーブルを分離させていてはそれが正しいのか評価する事ができません。正規化の理論はその基準になってくれるものです。
データベースアプリケーションを作成する際には、なるべく避けて通りたくなるところですがテーブルを設計する事は重要ですからしっかり気を引き締めてがんばってください。
|
|
|
|
|
|
|
|
|
|
|
●第一正規化 |
|
|
|
|
●第二正規化 |
|
|
|
|
●第三正規化
|
|
|
|
|
|
|
|
|
|
●第一正規化
|
|
|
|
|
第一正規形は単純な作業です。すべての属性の値を単純な値にします。つまり次のような単純な二次元のテーブルにしてしまいます。 |
|
|
|
|
|
|
|
|
|
これで第一正規形は終了!! |
|
|
|
|
■コメント |
|
|
|
|
RDBは、Cinema_code(7)のような一つのタプルに複数の値を持つ構造を許していません。また『データベースの規則』で述べたようにW_Dayのように日付として扱う場合はよいのですが、「年」「月」「日」の直積である場合はこれを分解して属性の値を原子値にしなければなりません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
●第二正規化 |
|
|
|
|
次に第二正規形を説明します。数学的な用語が出てきますがそれほど難しくないので理解するまで読み返してください。では、実際に第二正規化を行う前に理論的な事を説明しておきます。 |
|
|
|
|
|
|
|
|
|
|
■関数従属性 |
|
|
|
|
一方の値が決まると他の項目の値も一意に決まる関係を関数従属性といいます。その関係のなかで主キー(主キーが複数のキー項目から構成されている場合)の全ての項目を使って値が決定する関係を完全従属、主キー項目の一部によって値が決定する関係を部分従属といいます。以下に部分従属の例を以下に示します。 |
|
|
|
|
|
|
|
|
|
このテーブル(Cinema)は、主キーが決まればテーブルを構成する主キー以外の属性の値が決定する関数従属関係にあります。ここで{Cinem_Name,W_day,Genre_code,Genre_name}を見てみると、これらの属性の値は(Cinema_code)だけで決定する事が出来る事がわかります。つまり、これらの属性属性は、部分従属しているという事になります。では、実際に第二正規化の方法を説明します。 |
|
|
|
|
|
|
|
|
|
|
■第二正規化の方法 |
|
|
|
|
第二正規化は、主キーに部分従属している属性を分離する作業です。以下にその作業の例を示します。 |
|
|
|
|
|
|
|
|
|
■コメント |
|
|
|
|
★主キーの選択について |
|
|
|
|
映画製作では、主演・監督など役職を兼任する事があります。その場合には、今回設定した主キーでは主キーの役割(一意にタプルを識別できる)が果たせなくなる可能性があります。この主演・監督と言った場合に今回は、同一人物であっても異なるStaff_codeを与える事で問題を解決します。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
最後に第三正規形の説明をします。正規化の方法を説明する前にまた理論的な事を説明しておきます。 |
|
|
|
|
■推移従属関係 |
|
|
|
|
主キー以外の項目に従属する関係を推移従属と言います。説明する前に以下の例を見てください。 |
|
|
|
|
|
|
|
|
|
上のテーブルでは主キー以外の属性は、主キーに完全従属しています。しかし(Genre_name)を見てみると(Genre_code)に従属しています。この関係を推移従属関係といいます。 |
|
|
|
|
|
|
|
|
|
|
■第三正規化の方法 |
|
|
|
|
第三正規化は、テーブル内にある推移従属関係を分離して、どのテーブルであってもすべての属性が主キーに対して完全従属であるテーブルにします。では、具体的に第三正規化を行ってみます。 |
|
|
|
|
|
|
|
|
|
このように主キー以外の属性に推移従属する項目をテーブルから分離する事で、どのテーブルでも主キー以外の属性が主キーに対して完全従属し、推移従属関係にある属性はありません。これで第三正規化が終了!!です。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|