我想了解BCNF是什么,我有这样的关系:
学生(id,ssn,电子邮件,姓名,姓氏)
其中
是否存在任何违反BCNF的行为?如果有,我如何通过更好的设计克服这种情况?
修改
我正在尝试编写我的功能依赖项,但如果我错了,请纠正我。
有三个属性决定了其他属性,所以令人困惑的是ssn和email都存在于方程式的左侧和右侧。似乎这种关系不在bcnf中,但必定有错误:)
id -> (ssn, email, name, surname)
ssn -> (id, email, name, surname)
email -> (id, ssn, name, surname)
答案 0 :(得分:2)
正确回答问题的方法是确定应该应用哪些功能依赖项。写下你认为的依赖关系。如果每个非平凡依赖的左侧都是超级密钥,则该关系满足BCNF。
答案 1 :(得分:1)
是的,你的桌子在BCNF。这是因为您没有任何重叠的候选键 - 即没有出现在两个不同键中的属性。
如果你有一些其他属性,X,它构成了键的一部分 - 例如(SSN,X)和(电子邮件,X) - 然后您的表将失败BCNF,因为对于给定的SSN和电子邮件对,X应该是相同的。这些关键定义将允许给定SSN和电子邮件的不同X值。
有关BCNF的详细解释,请阅读this answer。
答案 2 :(得分:-4)
电子邮件地址或SSN的限制是唯一的,也不是可以为空的。您可以强制执行它们,但不应强加它们。 (想想:外国学生。) 通常,对不在您管辖范围内的关键域施加任何约束是一个坏主意,即使它们接近于唯一(例如在SSN案例中)。
举个例子:错字。假设某个人想要成为一名学生,但似乎她的SSN已被另一个人使用,可能是由于一个错字造成的。你应该拒绝新学生,还是删除旧学生? (或者您是否应该允许SSN字段为NON-unique或NULLable?)
更新/最终说明:本主题标记为“datatbase-design”和“data-normalization”。我对设计选择做出了反应(这是有争议的)。其他人试图对BCNF方面做出反应(考虑到UNIQUE候选键和NOT NULL假设,这是微不足道的)
规范化错误的数据模型会为您提供规范化的但仍然错误的模型。