このビデオの9:34に、スピーカーは3つの機能依存性すべてがBoyce CoddNormalFormにあると言います。明らかにGPAはSSN、sName、address、および学生テーブル内の他のすべての属性を判別できないため、私はそれを信じていません。Boyce Codd Normal Formの定義について混乱しているのか、それともスーパーキーとは何か？スキーマ内のすべての属性ではなく、特定の属性を一意に識別できる必要があるだけですか？たとえば、GPAは優先度（機能依存性の右側にあります）を決定しますが、他のすべてを決定するわけではありません。
たとえば、関係R（A、B、C、D）とFD A-> Bがある場合、AはBのスーパーキーであると言えますが、スーパーキーはテーブル全体のスーパーキーだと思いましたか？私の混乱に加えて、BCNFの場合、それは（主）キーである可能性がありますが、テーブルの主キーでしか持つことができません。うーん、脳が痛い。
「...スピーカーは、3つの機能依存性すべてがボイスコッド正規形であると言っています。」
BCの正規形であるということは、関数従属性ではなく、RELATIONS（関係変数、より具体的には、関係スキーマ、またはその用語がより適切な場合は関係スキーマ）が持つことができるプロパティです。正規化理論についてだらしなく話している人を見つけた場合は、そのままにして、より正確な説明に進んでください。
関係変数が実際にBC正規形であるかどうかは、どの関数従属性がその中に保持されるかによって異なります。そのため、関数従属性がBCの正規形であるかどうかを言うのはまったくナンセンスです。
「明らかにGPAはSSN、sName、address、および学生テーブル内の他のすべての属性を判別できないため、私はそれを信じていません。BoyceCodd Normal Formの定義について混乱しているのか、それともスーパーキーとは何か？スキーマ内のすべての属性ではなく、特定の属性を一意に識別できればよいのですか？」
既約候補キーは、データベースのリレーション変数に有効に表示される可能性のあるリレーション値の属性値の一意の組み合わせを持つことが保証されている、リレーションスキーマの属性のセット（必ずしも一意ではない）です。
（A、B、C、D）の例では、A-> Bが保持する唯一のFDである場合、唯一の候補キーは{A、C、D}です。
「たとえば、関係R（A、B、C、D）とFD A-> Bがある場合、AはBのスーパーキーであると言えます。」
このような場合、AがBの「鍵」であると話すのは、ずさんで混乱を招きます。他人に教えているふりをしている人はこれを知っているべきであり、知らない人はこれを知るまで教えるべきではありません。このような状況では、AをBの「決定要因」として話す方がよいでしょう。リレーショナルデータベース設計のコンテキストでの「キー」という用語は、非常に明確で正確な意味を持ち、他の意味に同じ用語を使用すると、人々を混乱させるだけです。あなたの質問によって証明されるように。
「でも、スーパーキーはテーブル全体にあると思いましたか？」
はい、あなたは正しいと思いました。
（A、B、C、D）の例に戻ります。 その設計を（A、B）と（A、C、D）に分割すると、リレーションスキーマ（（A、B））が作成され、そのうちの1つは「{A}はそのスキーマの「キー」。
これは、実際にはFD A-> Bが意味することです。（A、B、C、D）スキーマのデータベースに表示されるリレーション値の射影を属性{A、B}に適用すると、 、次に、A値が2回表示されない関係を取得する必要があります（表示された場合、そのA値は> 1の異なるB値に対応します。つまり、AがBの決定要因になる可能性はありません）。
「混乱を増すために、BCNFの場合、それは（主）キーになる可能性がありますが...」
今、あなたは自分自身がだらしている。「それ」とは何を指しますか？