Relational database 第三范式（3NF）中新创建关系的层次顺序

我有一个名为

EMPLOYEE

的关系，我的任务是将其转换为第三范式（3NF）。它有多个属性，但出于这个问题，我们只对以下内容感兴趣：

 emp_no     (employee number)
 office_no  (office number)
 dep_no     (department number)
 proj_no    (project number)

我知道，在第三范式中，主键可以是同一关系中非键属性的唯一的行列式，并且在问题中，它声明上述属性必须是全局唯一的。因此，我假设我将为每个属性创建一个新的关系

但是，这就是我困惑的地方。创建新关系时，我将相应的属性设置为旧关系中的外键，以及新关系的主键，对吗

还有其他一些事情：

我这样做的顺序重要吗？例如，我可以让

员工

关系引用

办公室

的新关系，然后让该关系引用新的

部门

关系。。。不过，我也可以让它去

员工->部门->办公室

。业务规则确实规定每个员工只能属于一个部门，每个部门只能属于一个办公室

我假设在第三范式中，如果不是主键的一部分，我不能拥有

emp\u no

以及上述任何属性，对吗？我的理由是，如果您知道办公室号码，您可以通过遍历每个关系的外键/主键对来确定（例如）电话号码

---

提前谢谢你

1）是的。您的示例对业务规则Employee->Office->Department进行建模，而不是Employee->Department->Office。（2） 嗯?？第二个问题是什么。“我知道在第三范式中，主键可以是同一关系中非键属性的唯一行列式…”不。每个候选键——不仅仅是主键——都是每个非键属性的行列式。彼特，我的意思是，举例来说，若你们可以从项目中任意数量的步骤派生出部门，那个么你们就不能让它们处于相同的关系中，对吗？迈克，你是对的，但我的意思是，基本上当你完成时，唯一应该确定非关键属性值的属性是候选关键点，它很可能会成为主键。。。我的假设正确吗？@araisbec:不，在你开始尝试改进表的结构之前，你需要知道所有候选键。例如，如果您不知道每个候选密钥，那么如何识别部分密钥依赖关系（必须删除才能达到2NF）？