Loading article…
ボイス・コッド正規形（BCNFまたは3.5NF）は、データベース正規化で使用される正規形です。これは、第3正規形（3NF）をやや厳密化したバージョンです。BCNFを使用することで、データベースは関数従属性に基づくすべての冗長性を排除します。
エドガー・F・コッドは、1970年6月に「大規模共有データバンクのためのリレーショナルデータモデル」という論文を発表しました。これは、リレーショナルデータベースの概念が初めて発表された事例です。ボイス・コッド正規形法をはじめとする、その後のすべての研究はこのリレーショナルモデルに基づいています。
ボイス・コッド正規形は、1971年にイアン・ヒースによって初めて記述され、クリス・デイトによってヒース正規形とも呼ばれています。[ 1 ]
BCNFは、当初定義された3NFでは対処できない特定の種類の異常に対処するために、 1974年にレイモンド・F・ボイスとエドガー・F・コッドによって正式に開発されました。 [ 2 ]
前述のとおり、クリス・デイトは、現在BCNFとして知られているものの定義が1971年のイアン・ヒースの論文に登場したことを指摘している。[ 3 ]デイトは次のように書いている。[ 1 ]
その定義はボイスとコッド自身の定義より約3年も前に存在していたので、BCNFは本来ヒース正規形と呼ばれるべきだと思う。しかし、そうはなっていない。
関係スキーマが BCNF である場合、関数従属性に基づく冗長性はすべて除去されていますが、[ 4 ]他の種類の冗長性は依然として存在する可能性があります。関係スキーマRが Boyce–Codd 正規形であるのは、その関数従属性X → Yのそれぞれについて、以下の条件の少なくとも 1 つが成り立つ場合のみです。[ 5 ]
関係スキーマがBCNFであれば、BCNFは3NFのより厳密な形式であるため、自動的に3NFにもなります。すべてのBCNF関係は3NFの条件を満たしますが、すべての3NF関係が、関数従属性によって生じるすべての冗長性を排除するBCNFのより厳密な要件を満たすわけではありません。
3NF テーブルが BCNF の要件を満たさないのはまれなケースのみです。複数の重複する候補キーを持たない 3NF テーブルは、 BCNF であることが保証されています。[ 6 ] 2 つ以上の重複する候補キーを持つ 3NF テーブルは、その関数従属性に応じて、BCNF である場合とそうでない場合があります。
BCNFを満たさない3NFテーブルの例は次のとおりです。
テーブルのスーパーキーは次のとおりです。
上記の表では、開始時刻と終了時刻の属性に重複する値はありませんが、他の日にはコート1とコート2で2つの異なる予約が同時に開始または終了する可能性があることに注意してください。これが、{開始時刻}と{終了時刻}をテーブルのスーパーキーとみなせない理由です。
テーブルの候補キーは次のとおりです。
S 1、S 2、S 3、S 4だけが候補キー（つまり、その関係の最小スーパーキー）です。例えば、S 1 ⊂ S 5なので、S 5 は候補キーにはなり得ません。
2NFでは非主属性（つまり、どの候補キーにも出現しない属性）の部分関数従属性が禁止されており、3NFでは非主属性の候補キーへの推移関数従属性が禁止されていることを考慮すると、
今日の裁判予約テーブルには、非主属性は存在しません。つまり、すべての属性は何らかの候補キーに属しています。したがって、このテーブルは2NFと3NFの両方を満たしています。
このテーブルはBCNFに準拠していません。これは、レートタイプ→裁判所という依存関係が存在し、決定属性がレートタイプであり、裁判所がレートタイプに依存しているためです。なお、（1）レートタイプはスーパーキーではなく、（2）裁判所はレートタイプの部分集合ではありません。
依存関係レートタイプ → 裁判所が尊重されます。レートタイプは常に単一の裁判所にのみ適用されるべきだからです。
設計を修正することで、BCNFの要件を満たすことができます。
料金タイプテーブルの候補キーは {料金タイプ} と {法廷、会員フラグ} です。今日の予約テーブルの候補キーは {法廷、開始時刻} と {法廷、終了時刻} です。どちらのテーブルも BCNF です。料金タイプテーブルで {料金タイプ} がキーである場合、1 つの料金タイプが 2 つの異なる法廷に関連付けられることは不可能なので、料金タイプテーブルで {料金タイプ} をキーとして使用することで、元のテーブルに影響を与えていた異常が解消されました。
場合によっては、BCNFでないテーブルを、BCNFを満たし、元のテーブルで保持されていた依存関係を保持するテーブルに分解することはできません。BeeriとBernsteinは1979年に、例えば、関数従属性の集合{AB → C, C → B}はBCNFスキーマでは表現できないことを示しました。[ 7 ]
関数従属性が{AB → C, C → B}パターンに従う、以下の非BCNFテーブルを考えてみましょう。
表には、人物と店舗タイプの組み合わせごとに、その人物の自宅から地理的に最も近い店舗が示されています。簡略化のため、1つの店舗が複数のタイプに属することはないものとします。
テーブルの候補キーは以下のとおりです。
3つの属性はすべて主属性（つまり候補キーに属する属性）であるため、このテーブルは3NFです。ただし、Shop type属性は非スーパーキーであるNearest shopに機能的に依存しているため、このテーブルはBCNFではありません。
BCNF違反は、テーブルに異常が生じる可能性があることを意味します。例えば、イーグルアイの「フラー」レコードではショップタイプが「検眼医」に変更されている一方で、「デイビッドソン」レコードではショップタイプが「眼鏡技師」のままになっている可能性があります。これは、「イーグルアイのショップタイプは何ですか？」という質問に対して矛盾した答えを出すことになります。各ショップのショップタイプを一度だけ保持する方が望ましいでしょう。そうすることで、このような異常の発生を防ぐことができます。
この改訂された設計では、「人物別最寄りの店舗」テーブルの候補キーは{人物、店舗}、そして「店舗」テーブルの候補キーは{店舗}となっています。残念ながら、この設計はBCNFに準拠しているものの、別の理由で受け入れられません。同じ人物に対して同じタイプの店舗を複数記録できてしまうためです。つまり、候補キーによって関数従属性{人物、店舗タイプ} → {店舗}が満たされることが保証されないのです。
これらの異常をすべて解消する（ただしBCNFには準拠しない）設計は可能です。この設計では、基本キー正規形（Elementary Key Normal Form ）と呼ばれる新しい正規形が導入されます。[ 8 ]この設計は、上記の「Shop」テーブルを追加した元の「Nearest shops」テーブルで構成されています。Bernsteinのスキーマ生成アルゴリズム[ 9 ]によって生成されるテーブル構造は実際にはEKNFですが、この3NFへの拡張はアルゴリズムが設計された時点では認識されていませんでした。
最初のテーブルの{Shop type, Nearest shop}が2番目のテーブルの{Shop type, Shop}を参照しなければならないという参照整合性制約が定義されている場合、前述のデータ異常は防止されます。
第三正規形のデータベーススキーマが与えられたとき、それがボイス・コッド正規形に違反するかどうかを判定することはNP完全である。 [ 10 ]
関数従属性X→Yのために関係RがBCNFでない場合、その関係を2つのサブ関係に置き換えることで、RをBCNFに分解することができます。
両方のサブリレーションがBCNFであるかどうかを確認し、BCNFでないサブリレーションに対して再帰的にこのプロセスを繰り返す。[ 11 ]
系3。