2.3ボイスコッド正規形と高次正規化

第3正規形まで正規化しても、複数の候補キーが複雑に絡み合うスキーマでは、なお更新時異常が残ることがあります。DB設計者はこの残存異常を見抜き、ボイスコッド正規形（BCNF）まで踏み込むべきか、あるいはBCNF化が引き起こす「分解による情報の可逆性」の問題とどう折り合いをつけるかを判断しなければなりません。この節では、BCNFの定義と、さらに稀なケースで必要になる第4・第5正規形、そして分解の可逆性という理論的な安全網を学びます。

2.3.1ボイスコッド正規形（BCNF）

• BCNFの定義＝その表に存在する全ての関数従属 X→Y について、決定子X（左辺）が必ず候補キーである状態。第3正規形は「非キー属性が非キー属性に推移的に従属しない」ことしか保証しないため、候補キーが複数あり、非キー属性が別の候補キーの一部を決定してしまうようなケースでは3NFを満たしても異常が残る。
• BCNFはこの盲点を塞ぐ、3NFよりも厳格な正規形。BCNFまで分解すると、決定子が候補キーでない関数従属が表内から一掃されるため、その従属関係に起因する更新時異常が根絶される。

2.3.2第4正規形と第5正規形

• 第4正規形（4NF）＝BCNFを満たした上で、多値従属（1つのキー値に対し、互いに独立した複数の値の集合が結び付く関係）を排除した状態。例えば「社員が複数のスキルを持ち、かつ独立して複数の資格を持つ」場合、スキルと資格を同一表に格納すると両者の全組合せを冗長に持つことになり、これを分離するのが4NF化。
• 第5正規形（5NF）＝結合従属（表を複数に分解しても、それらを結合すれば元の表を無損失で復元できるという制約）に基づく正規形で、3つ以上の表の組合せでのみ生じる冗長性を排除する。実務での出現頻度は低く、理論上の完全性を担保する最終段階という位置づけ。

2.3.3分解の可逆性（無損失分解）

• 正規化は表を分解する作業だが、分解の仕方を誤ると、分解後の表を結合しても元の表の情報を正しく復元できない（損失分解）ことがある。DB設計者は、分解した表の結合キーが適切に共通の候補キー・外部キーの関係を保っているかを必ず検証しなければならない。
• 無損失分解の保証には、分解後の各表の共通属性が、少なくとも一方の表の候補キーになっている必要がある。BCNF分解は無損失分解を維持できるが、関数従属性の保存（元の制約をすべて分解後の表だけで検証できること）までは保証されない場合があるため、分解後にどの制約をどの表でチェックするかの設計判断が必要になる。

ある大学の履修管理システムの設計者が「担当」表(学生ID, 科目名, 教員ID)を検討しています。業務ルールとして「1人の教員は1つの科目のみを担当する（教員ID→科目名という関数従属が成立）」「1人の学生は同じ科目を複数の教員から履修することはない」という制約があり、候補キーは(学生ID, 科目名)と(学生ID, 教員ID)の2つが成立します。この表は各属性が非キー属性への推移的従属を持たないため第3正規形を満たしていますが、「教員ID→科目名」という関数従属の決定子である教員IDは、単独では候補キーになっていません（候補キーは複合キーのみ）。これはBCNFの定義（決定子は必ず候補キーであるべき）に違反しており、実際に更新時異常が残ります——ある教員が担当科目を変更した場合、その教員が履修される全学生の行を漏れなく更新しなければ、同じ教員IDに対して異なる科目名が矛盾して併存する状態になり得ます。これを解消するには、「教員担当科目」表(教員ID, 科目名)と「履修」表(学生ID, 教員ID)へ分解します。この分解では共通属性である教員IDが「教員担当科目」表の候補キーになっているため無損失分解が保証され、結合すれば元の「担当」表を正しく復元できます。ここで設計者は、この分解によって「学生IDと科目名だけを条件にした検索」には常に2表のJOINが必要になるという性能面のトレードオフが生じることも認識し、履修管理という整合性が最優先される業務領域では、性能より正しさを優先してBCNFまで分解するのが妥当と判断しました。

2.3.4この節のまとめ

• BCNF＝全ての関数従属の決定子が候補キーである状態。候補キーが複数あるスキーマでは3NFを満たしてもBCNFを満たさないことがある
• 第4正規形＝多値従属の排除、第5正規形＝結合従属の排除。実務での出現は稀で理論上の完全性を担保する
• 分解は無損失分解（共通属性が候補キー）であることを必ず検証する。BCNF化は関数従属性の保存を犠牲にすることがある