Database 正常化：我是db正常化的新手。我不知道我的答案是否正确

将以下各项标准化至3NF：

projnum | projname | empnum | empname | job class | chrghour |小时|

    15 |Evergreen|   103   |  June    |Engineer | 84      |  23  |
    15 |Evergreen|   101   |  John    |Designer | 105     |  19  |
    15 |Evergreen|   105   |  Alie    |Designer | 105     |  35  |
    15 |Evergreen|   106   |  Dave    |Analyst  | 96      |  12  |
    15 |Evergreen|   102   |  Anne    |Clerical | 26      |  23  |

编辑：

1NF我得到：

Table 1(projnum[pk], projname, hours)
Table 2(projnum[pk], empnum[pk], empname, jobclass, chrghour)

2如果我得到：

Table 1(projnum[pk], projname, hours)
Table 2(projnum[pk], empnum[pk])
Table 3(empnum[pk], empname, jobclass, chrghour)

如果我得到：

Table 1(projnum[pk], projname) //then i put [hours] in table 2 but I DONT KNOW THE LOGIC BEHIND. Explanation is welcomed.
Table 2(Projnum[pk], empnum[pk], hours)
Table 3(empnum[pk], empname, jobclass)
Table 4(jobclass[pk], chrghour)

---

是否有任何违反规范形式规则的行为？我的回答正确吗？

需要更多关于数据含义的信息；有些答案似乎是错的，但哪些答案是不可能的。具体而言：

• 如果

  hours

  是项目所属项目的持续时间 项目表，如2NF答案中所示；如果是员工 在多对多关系表中所属的项目上工作 在项目和员工之间，如3NF答案中所示
• 同一名员工能否以不同的

  chrghour

  和/或

  jobclass

  值出现

---

你的3NF结果是正确的，但你的道路毫无希望

规范化的过程是一个分解（“拆分”）的过程。重要的是要理解的是，您从一个关系模式开始，所有的FD都应用于该模式。还需要了解的是，在规范化过程中的任何时候，某个特定的FD集都应用于一个关系模式。因此，在您将初始的单个模式拆分为两个关系模式之后，您还将得到两组不同的FD，每个FD在拆分后恰好应用于一个关系模式。甚至可能会出现这样的情况，即通过执行某些特定的模式拆分，您将失去在拆分之前表达应用于该模式的某些特定FD的所有能力。在你做的第一次拆分中，你对FD5做了完全相同的操作。FD5在表1中不可表达，因为该模式中缺少empnum；在表2中不可表达，因为该模式中缺少小时。所以FD5已经完全无法表达了。（这并非总是可以避免的，因此也不一定是一件坏事，但在您的情况下确实如此。）

---

事实上，你只能继续进一步分裂，这就是为什么你的分解过程是有缺陷的。您不能“将[hours]移动到表2”。

通过BCNF进行规范化是基于功能依赖性的。编辑您的问题，并包括功能相关性。标准化基于您知道的所有FD。你应该包括所有你知道的FD。“我们应该以第二范式本身列出所有FD吗？”这句话没有真正的意义。你确定projname->projnum不是函数依赖项吗？empnum，empname->jobclass会简化为empnum->jobclass，不是吗？a）你误解了。b） 如果你“几乎肯定”，你就是在猜测。你在猜吗？（在数据库设计的现实世界中，我们有时不得不猜测，但这是一种非常糟糕的学习规范化的方法。）如果你不是猜测，你可以从家庭作业问题的文本中阅读FDs。这似乎更适合作为注释而不是答案。不，同一名员工不能出现在不同的chrghour或jobclass中，分解当然是一种标准化方法，但不是唯一的方法。完全可以通过不涉及任何分解的过程来实现规范化的数据库设计。在我看来，有点不幸的是，学生们仍然被教导将标准化作为通过连续范式分解的线性过程。我不相信这是实现每个数据库设计概念的最佳方式。@sqlvogel，如果你指的是从一开始就用5NF设计的概念，仅仅基于直觉/经验/常识/…，是的，我非常了解这种“方法”我也很清楚，它通常比“教科书”中的分解归一化方法在更短的时间内产生好的结果。然而，如果教科书方法是你所能做的全部（通常是教科书课程中的情况），那么分解就是你所能做的全部。

Table 1(projnum[pk], projname) //then i put [hours] in table 2 but I DONT KNOW THE LOGIC BEHIND. Explanation is welcomed.
Table 2(Projnum[pk], empnum[pk], hours)
Table 3(empnum[pk], empname, jobclass)
Table 4(jobclass[pk], chrghour)