数据库 - 试图巩固对规范化的理解，这是如何规范化的？答案

【问题标题】：Database - Trying to solidify understanding of normalization, how normalized is this?数据库 - 试图巩固对规范化的理解，这是如何规范化的？
【发布时间】：2017-01-25 21:10:44
【问题描述】：

how normalized is this table?

Example SqlFiddle

所以我知道规范化本身的主题和定义已经得到了很好的讨论，但我希望我能澄清我对规范化的理解。一个例子是我在 Access 中快速绘制的图表，从我的想法来看，我相信这些关系和表格本身都符合 3NF 标准。有一个 Projects 表，其中包含以下字段 ProjNumber(PK)、ProjName 和 ProjDesc。然后是一个Assignments 表，其复合键与EmpID/ProjNumber 一致，具有HourlyBillingRate、NumOfHours 和TeamNum 字段。最后是 Teams 表，它由 TeamNum(PK)、TeamName、ProjNumber 字段组成。

Assignments 和 Teams 中的 ProjNumber 都是与 Projects 表相关的外键，而 Assignments 中的 TeamNum 字段是与 Teams 表主键相关的外键。我不太确定是否有必要直接关联回 Teams 表，如果我有 ProjNumber 外键，因为该项目将有一个关联的 TeamNum。

这些表的上下文是有一个必须完成的项目，一个与执行该团队相关联的团队，然后是该团队中的员工，他们为该项目按小时计费工作。

我之所以使用复合键，是为了回答“员工在多个项目中工作的内容是什么？”的问题，所以我无法将 EmpID 设为唯一的主键，因此我选择将其设为复合键，因为即使员工从事多个项目，两者的组合也始终是唯一的。我相信每个字段都是必要的，并且与它们各自的主键完全相关。

想法？它实际上是否满足 3NF 标准？

【问题讨论】：

@RyanVincent 很抱歉，这在当时更像是一个思想实验，以确保我有正确的概念。虽然我花了一些时间来创建表，但这是我的 sqlfiddle 链接：sqlfiddle.com/#!9/8aba27 我现在确实意识到，如果所有字段都不在引用的表中，复合主键不起作用，因此，我做到了添加一个任意的“AssignID”字段，它只是一个自动递增的值，以作为主键。
@RyanVincent 好吧，我已经建立了表格，从概念上讲，我相信它符合标准，因为它能够处理我扔给它的一些数据，而我不是真的看到任何异常和错误弹出。但是对桌子本身有什么想法吗？这些表本身只是我正在构建的数据库的一个骨架结构，但我只是想确保在我疯狂之前，我对一些关键概念有一个坚实的基础。

标签： database database-design normalization database-normalization

【解决方案1】：

这取决于。您的图表和讨论似乎假设主键是每个表中唯一的候选键。情况似乎并非如此。

在 Assignments 表中，看起来 EmpID 和 TeamNumber 是另一个候选键，前提是 TeamNumber 不能为 NULL。

如果我们以 EmpId、TeamNumber 为键查看此表，则它不在 2NF 中。 ProjNumber 是由 TeamNumber 决定的，不是整个 key。

因此，现在您的问题的答案取决于是针对所有候选键还是仅针对声明的主键来分析 FD。我看过有关规范化的双向教程。我遵循考虑所有候选键的那个，所以该表不在 2NF 中。

除非我在你的情况下误解了 FD，或者 Assigment.TeamNumber 可以为 NULL。

但是，您的 SQL Fiddle 演示文稿是不同的。现在，如果一个项目有多个团队，并且一名员工被分配到一个项目几个小时，则没有任何方法可以判断该员工所在的团队。 SQL Fiddle 示例中的 FD 与我从您的图表中获取的含义不同。

【讨论】：