-1

我目前在 DB 类中并正在通过规范化工作，并且遇到了一些麻烦。我希望我能得到一些帮助来解决这个问题。我已经搜索了最后 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)

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

4

1 回答 1

2

那么 ID 和 First, Last 都可以成为候选键吗？

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

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

所以，让我们来看看你原来的描述。

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

First、Last 和 Salary 将基于员工 ID。您的依赖项之一意味着部门中的每个人都获得相同的薪水。我不同意，但无论如何。

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

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

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

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

于 2020-11-08T21:18:03.060 回答