3NF归一化和分解答案

【问题标题】：3NF Normalization and Decomposition3NF归一化和分解
【发布时间】：2021-02-20 20:12:18
【问题描述】：

我目前正在学习数据库课程并正在通过规范化工作，但遇到了一些麻烦。我希望我能得到一些帮助来解决这个问题。我搜索了过去 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)

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

【问题讨论】：

您的“我有这些 FD”没有意义。 “这些都是持有的FD”？--不可能。 “这些都是持有的不平凡的FD”？--不可能。 “这些是一些持有的FD”？--问题无法回答。找出什么是 cover 以及应用特定定义/规则/算法的确切条件。要确定 CK 和 NF，我们必须得到构成掩护的 FD。有时是最小/不可约覆盖。并且必须给出所有属性的集合。 See this answer.
现在您实际上是在要求我们使用定制教程重写您的教科书。请参阅How to Ask，点击谷歌搜索“stackexchange 作业”和投票箭头鼠标悬停文本。按照教科书的理由展示您的工作步骤，并在您遇到困难的第一个地方提出 1 个经过研究的特定非重复问题。引用您所依赖的定义、定理、算法和启发式方法。所有步骤也是常见问题解答。 PS这包括解释“边缘图”。另外，您的意思似乎是“分解”而不是“解构”。

【解决方案1】：

那么 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 关系让我感到困惑。

【讨论】：