在该视频中的 9:34，演讲者说所有 3 个函数依赖项都处于 Boyce Codd 范式。我不相信，因为显然 GPA 无法确定学生表中的 SSN、sName、地址和所有其他属性。要么我对 Boyce Codd 范式的定义感到困惑，要么对什么是超级键感到困惑？它是否只需要能够唯一地识别某些属性，而不是模式中的所有属性？例如，GPA 确实确定了优先级（位于功能依赖的右侧），但不是其他所有内容。
例如，如果我有关系 R(A,B,C,D) 和 FD A->B，我们会说 A 是 B 的超级键，但我认为超级键是整个表的吗？为了增加我的困惑，我知道 BCNF 它可以是（主）键，但您只能拥有表的主键。哎呀我的脑袋好痛。
“......演讲者说所有 3 个函数依赖项都在 Boyce Codd 范式中。”
处于 BC 范式是RELATIONS（更具体地说，是关系变量，或关系模式，如果该术语更适合您）而不是函数依赖项可以具有的属性。如果您发现有人在谈论标准化理论时如此草率，请离开并继续进行更准确的解释。
一个关系变量是否确实是 BC 范式，取决于它应该包含哪些函数依赖关系。这就是为什么说函数依赖是否为 BC 范式完全是无稽之谈。
“我不相信，因为显然 GPA 无法确定学生表中的 SSN、sName、地址和所有其他属性。要么我对 Boyce Codd 范式的定义感到困惑，要么对什么是超级密钥感到困惑？它只需要能够唯一地识别某些属性，而不是模式中的所有属性？”
一个不可约的候选键是关系模式的属性集（不一定是唯一的），它保证在数据库中的关系变量中有效出现的任何关系值中具有属性值的唯一组合。
在您的 (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) 之一 - 我们可以说“{A} 是键”在该架构中。
这实际上正是 FD A->B 的含义：如果您将在 (A,B,C,D) 模式中出现在数据库中的关系值投影到属性 {A,B} ，那么你应该得到一个没有 A 值出现两次的关系（如果出现了，那么 A 值将对应于 >1 个不同的 B 值，这意味着 A 毕竟不可能是 B 的决定因素）。
“为了增加我的困惑，我知道 BCNF 它可以是一个（主）键，但是......”
现在你自己马虎了。“它”指的是什么？