3NF归一化和分解

Question

我目前在一个数据库中 class 并且正在通过规范化工作，运行遇到了一些麻烦。我希望我能得到一些帮助来解决这个问题。我已经搜索了最后 30 分钟，但没有找到任何有助于解决我的问题的东西，但希望我没有在搜索错误的东西。

问题如下：

考虑普遍关系

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

具有以下函数依赖集 F

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, First, Last, Salary) 和 (Last, Team)?

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

如果需要任何其他信息，请告诉我。谢谢。

Answer 1

So would ID and First, Last both be a candidate key?

ID 是候选键，Last, First 可能是复合索引。人们同名太常见了。

第三范式可以用一句话概括。 “table 中的列取决于键，整个键，只有键，所以 Codd 帮帮我。”

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

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

名字、姓氏和薪水将基于员工 ID。您的依赖关系之一意味着部门中的每个人都获得相同的薪水。我不同意，但无论如何。

一个员工在一个团队中，一个团队可以有一个或多个员工。这是一个一对多的关系，这意味着来自员工 table 的团队 table 的外键。

员工/部门关系也是如此。来自员工 table.

的部门 table 的另一个外键

团队 table 和部门 table 之间似乎没有任何关系。

薪水是一个奇怪的领域。我会说它属于员工 table，但 Salary -> Dept 关系让我感到困惑。

3NF Normalization and Decomposition