━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■第28回 ボイスコッド正規化
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第1～第5正規化まで説明してきましたが、第4正規化の前に、ボイスコッド
正規化というのもあります。
ボイスコッド正規形は一見すると第3正規形と良く似ており、同じものとし
て紹介している書籍などもあるようですが、そもそもの目的が違っており、
全くの別物です。
ボイスコッド正規化も、第4・第5正規化と同様に、実際の業務でお目に掛か
ることが少ないのですが、何故そうなのか、今回も考えながら読んでみると
良いかと思います。
●ボイスコッド正規形
こんなテーブルがあったとします。
--------------------------------
| 学籍番号 | 科目 | 担当教員 |
--------------------------------
| 00000001 | 数学 | 荒木教授 |
--------------------------------
| 00000001 | 物理 | 鈴木教授 |
--------------------------------
| 00000002 | 数学 | 近藤教授 |
--------------------------------
| 00000002 | 物理 | 横山講師 |
--------------------------------
| 00000002 | 化学 | 山田教授 |
--------------------------------
| 00000002 | 心理学 | 斉藤教授 |
--------------------------------
学籍番号と科目が決まると担当教員が決まりますので、キーは｛学籍番号、
科目｝と考えられると思いますが、担当教員が決まると科目も決まります。
・第2正規化は、キーの一部から非キー項目への関数従属を排除
・第3正規化は、非キー項目から非キー項目への関数従属を排除
ですが、ボイスコッド正規形では、非キー項目からキー項目への関数従属を
排除することが目的となります。
上記の例では、非キー項目の担当教員からキー項目の科目への従属関係があ
りますので、これを排除します。
--------------------- ---------------------
| 学籍番号 | 科目 | | 担当教員 | 科目 |
--------------------- ---------------------
| 00000001 | 数学 | | 荒木教授 | 数学 |
--------------------- ---------------------
| 00000001 | 物理 | | 鈴木教授 | 物理 |
--------------------- ---------------------
| 00000002 | 数学 | | 近藤教授 | 数学 |
--------------------- ---------------------
| 00000002 | 物理 | | 横山講師 | 物理 |
--------------------- ---------------------
| 00000002 | 化学 | | 山田教授 | 化学 |
--------------------- ---------------------
| 00000002 | 心理学 | | 斉藤教授 | 心理学 |
--------------------- ---------------------
となるのですが、実は大変な問題があることに気づきましたでしょうか。
この２つの表をJOINすると、元のデータに戻らなくなってしまいます。
例えば、学籍番号00000001の生徒は数学を履修しているのですが、数学担当
は荒木教授と近藤教授がいますので、２人の先生の授業を受けることになっ
てしまう訳です。
このように、安易にボイスコッド正規化を行うと、データの整合性が崩れる
可能性がありますので注意が必要になります。
ところで、この表は「元に戻せなくなることがある」ということを説明する
ためのもので、実際にはこういう表を見かけることはほとんどないと思いま
す。
ボイスコッド正規形にすると、ビジネスロジックをセットにしないといけな
くなったりしますので、業務上は第3正規形の方が使いやすいことが多いで
しょう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━