スキーマの混乱：R(A,B,C,D,E,F,G,H,I,J)と機能依存FD = { A->DE, IJ->H, I->A, J->FG, G->BC }BCNF
質問：はBCNFに関係か？
回答：Aはスーパーキーではありません。
私はBCNFにどのような条件関係があるのか分かっていますが、いつも私を混乱させるものはsuperkeyです。誰でも答えの理由を説明することができますAスーパーキーではありませんか？そして、たとえばIJまたはIをスーパーキーとして選択するのはなぜですか？ k
BCNFの定義では、リレーショナルRの非自明な関数依存性は、スーパーキーである行列式（左辺）を持たないことが必要です。スーパーキーは、リレーションのすべての属性を決定するアトリビュートまたはアトリビュートのセットです。したがって、少なくとも依存関係にスーパーキーではない行列式がある場合、その関係はBCNFにはありません。
この例では、任意の依存関係から開始できます。 A → DEから始めましょう。
A+ → A
A+ → ADE (because of A → DE)
を他の属性を追加できませんので、AはRのスーパーキーではなく、関係はではない：私たちは、Aはその閉鎖を計算することにより、スーパーキーであり、それはすべての属性が含まれているかどうかどうかを確認することができますBCNF。
同様に、I,J、およびGはスーパーキーではありません。
実際には、この関係には一意の候補キーIJがあります。これはクロージャIJ+を計算して確認できます。つまり、各スーパーキーはにはIJが含まれている必要があります。
スーパーキーを「選択」しません。スキーマと関数の依存関係が与えられると、属性のセットの中には候補キーがあります。候補キーのすべてのスーパーセットはスーパーキーです。
候補キーの概念は通常、スーパーキーの観点から定義されます。スーパーキーは、すべての属性を決定する一連の属性です。候補キーは、スーパーキーである適切な（より小さい）サブセットを持たないスーパーキーである。
"スーパーキー"を定義する別の方法は、値のすべてのサブローが一意である属性のセットです。それゆえ、私たちはしばしば、一組の属性が「一意」であると言ってスーパーキーであることを表現したり認識したりします。
（任意の候補キーを「主キー」にすることもできますが、これは関係理論とは関係ありません。 SQLでのKEYは、それがスーパーキー、必ずしも候補キー、すなわち必ずしも主キーであると述べている。限り制約が懸念しているとして、それがUNIQUE NOT NULLを意味します。）
を、いくつかの機能の依存関係がスキーマ内に保持した場合、他のものは行います。保持しているのは、原作がアームストロングの公理を暗示しているものです。 {A}がスーパーキーであるためには、その一部のサブセットが候補キーでなければなりません。しかし、関数の依存関係のセットを考えると、{}も{A}のどちらも候補キーではありません。 {I}についても同様です。しかし、{IJ}は、閉包を決定すると、すべての属性を決定します。それはスーパーキーです。だからそれのすべてのスーパーセットです。適切なサブセットは存在しないので、これも候補キーです。
「BCNFにはどのような条件の関係がありますか」をどのように表現しますか？ – philipxy