3NF归一化和分解

如何解决3NF归一化和分解

我目前在数据库课程中，并且正在通过normalization进行工作，并且遇到了一些麻烦。希望我能从中获得一些帮助。我已经搜索了过去30分钟，却没有找到任何可以解决我问题的信息，但希望我没有在搜索错误的内容。

问题如下：

考虑普遍关系

EMPLOYEE (ID,First,Last,Team,Dept,Salary)

具有以下功能依赖项集

ID -> First
ID -> Last
First,Last -> ID
Last -> Team
ID -> Dept
ID -> Salary
Salary -> Dept

确定候选关键字，并构造Employee分解为3NF中保留依赖关系的关系。

对于候选键，我很挣扎，因为在做边缘图时，每个属性都有传入的依赖关系。没有没有出现在依赖项的RHS上的属性。我认为可能使我感到困惑的是，尽管ID决定了一切，而First,Last却决定了ID。那么ID和First,Last都是候选密钥吗？

对于解构，我知道Last -> Team和Salary -> Dept是可传递的，但是ID具有直接依赖项ID -> Dept和ID-> Salary。

这是否意味着我只需要两个表， (ID,Salary) 和 (Last,Team)？

或者基于上面的候选键问题，我需要 (ID,Last) (ID,Salary,Dept) (Last,Team)

让我知道是否需要其他信息。谢谢。

解决方法

那么ID和First，Last都是候选密钥吗？

ID是一个候选键，Last，First可能是一个复合索引。人们以相同的名字命名是很常见的。

第三范式可以用一句话总结。 “表中的列取决于键，整个键，而仅取决于键，所以请帮我Codd。”

所以，让我们看一下您的原始描述。

EMPLOYEE (ID,First,Last,Team,Dept,Salary)

“第一，最后和薪水”将基于员工ID。您的依赖项之一意味着部门中的每个人都获得相同的薪水。我不同意，但是随便。

一个员工在一个团队中，一个团队可以有一个或多个员工。这是一对多的关系，这意味着从Employee表到Team表的外键。

员工/部门关系也是如此。 Employee表中另一个Department表的外键。

Team表和Department表之间似乎没有任何关系。

工资是一个奇怪的领域。我会说它属于Employee表，但是Salary -> Dept关系使我感到困惑。