带有一个代理键和两个唯一键的BCNF

Question

我想了解BCNF是什么，我有这样的关系：

学生（id，ssn，电子邮件，姓名，姓氏）

其中

• id是主要的代理键，不具有null和自动增量属性，
• ssn是一个非空属性的唯一键和
• 电子邮件也是一个非空属性的唯一键。

是否存在任何违反BCNF的行为？如果有，我如何通过更好的设计克服这种情况？

修改

我正在尝试编写我的功能依赖项，但如果我错了，请纠正我。

有三个属性决定了其他属性，所以令人困惑的是ssn和email都存在于方程式的左侧和右侧。似乎这种关系不在bcnf中，但必定有错误：）

id -> (ssn, email, name, surname)
ssn -> (id, email, name, surname)
email -> (id, ssn, name, surname)

Answer 1

正确回答问题的方法是确定应该应用哪些功能依赖项。写下你认为的依赖关系。如果每个非平凡依赖的左侧都是超级密钥，则该关系满足BCNF。

Answer 2

是的，你的桌子在BCNF。这是因为您没有任何重叠的候选键 - 即没有出现在两个不同键中的属性。

如果你有一些其他属性，X，它构成了键的一部分 - 例如（SSN，X）和（电子邮件，X） - 然后您的表将失败BCNF，因为对于给定的SSN和电子邮件对，X应该是相同的。这些关键定义将允许给定SSN和电子邮件的不同X值。

有关BCNF的详细解释，请阅读this answer。

Answer 3

电子邮件地址或SSN的限制是唯一的，也不是可以为空的。您可以强制执行它们，但不应强加它们。 （想想：外国学生。） 通常，对不在您管辖范围内的关键域施加任何约束是一个坏主意，即使它们接近于唯一（例如在SSN案例中）。

举个例子：错字。假设某个人想要成为一名学生，但似乎她的SSN已被另一个人使用，可能是由于一个错字造成的。你应该拒绝新学生，还是删除旧学生？ （或者您是否应该允许SSN字段为NON-unique或NULLable？）

更新/最终说明：本主题标记为“datatbase-design”和“data-normalization”。我对设计选择做出了反应（这是有争议的）。其他人试图对BCNF方面做出反应（考虑到UNIQUE候选键和NOT NULL假设，这是微不足道的）

规范化错误的数据模型会为您提供规范化的但仍然错误的模型。