我正在阅读一些规范化的例子，但是我遇到了一个我不理解的例子。
该示例位于此处的网站：http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone
我不理解的部分是“第三范式”
在我的脑海中，我在EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)中看到了Name->->Office|Floor和Name->->Office|Phone
作者将表格EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)拆分为EMPLOYEE_OFFICE (Name, Office, Floor)和EMPLOYEE_PHONE (Office, Phone)
从我一开始的判断，我仍然看到Name->->Office|Floor中的传递依赖，所以我不明白为什么它在3NF中。我是否错误地指出Name->->Office|Floor中存在传递依赖？
推定传递性： 这是我的功能依赖项列表
谢谢大家的帮助！
答案 0 :(得分：1)
答案 1 :(得分：0)
1. Name -> Office
2. Name -> Floor
3. Name -> Phone
4. Office -> Phone
5. Office -> Floor (Is this the incorrect one? and why?
（1）您和作者和我同意Name-＆gt; Office。
（2）您和作者同意Name-＆gt; Floor。虽然这完全基于样本数据，但Office-＆gt; Floor也是如此。我会通过提出这样一个问题来探讨这个问题：“如果办公室空无一人，我还能知道办公室在哪个楼层吗？” （是）
这些事情表明存在传递依赖，Name-＆gt; Office和Office-＆gt; Floor。所以我不同意你和作者的意见。
（3）你说Name-＆gt; Phone。作者说Office-＆gt; Phone。作者还说“每个办公室只有一个电话号码。”因此，给一个Office值，我知道一个而且只有一个Phone值。给了Name的一个值，我知道Phone的唯一值。我会通过询问“如果我搬到另一个办公室，我的电话号码跟着我吗？”来探讨这个问题。如果是，则命名 - >电话。如果没有，那么Office-＆gt;电话。
这里没有足够的信息来回答这个问题，而且我曾在办公室工作过这两种方式，所以现实世界的经验对我们也没有多大帮助。在这种情况下，我不得不支持作者，尽管我认为对于规范化示例并没有很好的考虑。
（4）这实际上只是上述（3）的延伸。
（5）见上文（2）。这与命名方案无关，您无需假设编号为5xx的办公室位于5楼。唯一相关的问题是：给定Office的一个值，是否只有一个值为Floor？ （是）我可以通过询问“一个办公室可以在一个以上的楼层吗？”来探讨这个问题。 （在现实世界中，这是远程可能的。但样本数据不支持这种可能性。）
一些额外的FD，仅基于样本数据。
Phone->Office
Phone->Floor
Office->Name
答案 2 :(得分：0)
首先，让我明确定义3NF： - 如果满足以下条件，则关系为3NF： - 1.）关系在2NF 2.）非主要属性没有传递依赖于主键。 换句话说，在3NF中的关系是满足以下条件之一的每个函数依赖性X-> Y： - 1.）X是超级钥匙 2.）Y是主要属性 对于您的问题，如果存在以下FD： -
Name -> Office
Name -> Floor
Name -> Phone
Office -> Phone
然后我们无法对Office和Floor进行任何说明。您可以通过应用和检查任何Armstrong推理规则来验证这一点。当您应用这些规则时，您会发现您无法推断任何有关办公室和楼层的信息。