关系数据库的规范化答案

【问题标题】：Normalisation of Relational Databases关系数据库的规范化
【发布时间】：2016-03-21 11:45:12
【问题描述】：

我正在查看规范化考试问题的评分方案。它给出了附图中显示的表格，并要求瞳孔归一化为第三范式。图片中的表格下方是该问题的评分方案。

有谁知道为什么在 2NF 中 Dept ID 会留在 Team-Employee 表中？它后来被删除了，但我不知道为什么它一直保留在那里？

【问题讨论】：

整体来说，最好将图片中的内容作为文本输入。
您没有提供足够的信息。什么是功能依赖？例如，给定的employeeid 是否只与一个deptid 一起出现？
你有这个例子的来源的参考吗？

标签： database normalization database-normalization functional-dependencies

【解决方案1】：

因为在 1NF 中

仅包含原子值
没有重复组

第二范式

所有非键属性都完全依赖于主键

第三范式

在 3NF 中没有传递函数依赖。

DeptID 取决于您查看的员工。因此它是第一和第二范式。直到第 3 范式才必须提取员工和部门 ID 之间的一对多关系。

在您的情况下，Dept name 与 DeptID 相关联，DeptID 与 Employee 相关联，因此 deptName 具有传递函数依赖关系。换一种说法。该表本身具有一对多的关系；这在第三范式中是不允许的。但它符合 2NF，因为部门与员工直接相关，而不是需要以第一范式解决的多对多。

【讨论】：

TEAM-EMPLOYEE-2 有一个部分 FD 确定 DeptID，因此它不能在 2NF 中。（见我的回答。） PS FD 表示员工：部门是很多：1。

【解决方案2】：

您没有提供足够的信息。我们可以看到一些没有函数依赖的地方，但不知道与函数依赖一致的情况是否真的存在。

但假设 DeptID 在功能上由 {EmployeeID} 确定（即，给定的 EmployeeID 仅与一个 DeptID 一起出现）（根据 EMPLOYEE 具有 {EmployeeID} 作为确定 DeptID 的候选键的情况），TEAM-EMPLOYEE-2 具有具有候选键 {TeamID,EmployeeID} 的 DeptID 不会在 2NF 中，因为 DeptID 在功能上依赖于候选键的适当子集 ({EmployeeID})（即，它在功能上不完全依赖它）。然而，在您的（所谓的）解决方案中，它出现在 2NF 之下。

所以可能是一个错字。（也因为分解后留在两个组件中很奇怪。）

【讨论】：