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