所以我知道规范化本身的主题和定义已经得到了很好的讨论，但我希望能够对我对规范化的理解做出一些澄清。一个例子是我在Access中快速绘制的图表，我认为，我认为这些关系和表格本身都符合3NF标准。有一个Projects表，其中包含以下字段：ProjNumber（PK），ProjName和ProjDesc。然后有一个Assignments表，复合键与EmpID / ProjNumber一致，字段为HourlyBillingRate，NumOfHours和TeamNum。最后是Teams表，它包含TeamNum（PK），TeamName，ProjNumber字段。
分配和团队中的ProjNumber都是与Projects表相关的外键，而Assignments中的TeamNum字段是与Teams表主键相关的外键。我不太确定是否有必要直接与Teams表关联，如果我有ProjNumber外键，因为该项目将有一个关联的TeamNum。
这些表格的背景是，必须完成一个项目，一个与执行该团队相关联的团队，然后是该团队中的员工，他们按小时计费该项目。在。下工作。
我使用复合键的原因是，我想回答“员工在多个项目上工作的内容是什么？”的问题，因此我无法将EmpID作为唯一的主键，因此我选择将其设为复合密钥，因为即使员工在多个项目上工作，两者的组合也将始终是唯一的。我相信每个领域都是必要的，并且与各自的主键完全相关。
思考？它实际上是否符合3NF标准？
答案 0 :(得分：1)
这取决于。您的图表和讨论似乎假设主键是每个表中唯一的候选键。情况似乎并非如此。
在Assignments表中，看起来EmpID和TeamNumber是另一个候选键，前提是TeamNumber可能不是NULL。
如果我们使用EmpId查看此表，TeamNumber作为键，那么它不在2NF中。 ProjNumber由TeamNumber决定，而不是整个密钥。
所以现在你的问题的答案是关于是否针对所有候选键或仅仅声明的prmary键来分析FD。我已经看到了关于规范化的教程，它们都是双向的。我遵循考虑所有候选键的那个，因此该表不在2NF中。
除非我在您的情况下误解了FD，否则Assigment.TeamNumber可能为NULL。
但是，您的SQL Fiddle演示文稿有所不同。现在，如果一个项目中有多个团队，并且一个员工被分配到一个项目几个小时，那么就没有任何方法可以告诉该员工在哪个团队。这些FD在SQL Fiddle示例中以及我从图中得到的含义中都不相同。
