我不得不就此与我的教授争论，但他坚持认为我的解决方案异常，可能会引起冲突。他补充说我无法理解数据库设计的概念。
但是，他无法向我解释为什么他的解决方案是正确的，而我的解决方案是错误的。
问题是关于以下 kena 数据库表的数据库规范化：
左边是我的答案，右边是教授的答案：
更好的视图： http://tny.cz/48c4a28b
你认为我的错误是什么？为什么你认为他说我的答案远非正确？
【问题讨论】：
标签： sql database normalization
在这里实际上没有太多要回答的问题 - 但这里是......你的教授是正确的。
另外，项目负责人似乎是一个额外的概念。不应该是这个答案的一部分，因为它似乎没有出现在您正在处理的基表中。
【讨论】：
有两个显着差异。
首先，您似乎将小计存储在项目中。这是重复的信息 - 您可以通过汇总每个项目的费用来获得小计。数据库设计的一个关键方面是“不要重复自己”。
第二个是您为“jobclass”创建了一个无意义的主键，而您的教授使用 jobclass 的名称作为主键。
理想情况下，您希望主键是唯一的（两种解决方案都满足这一点）。您还希望它保持不变 - 这就是我认为您的解决方案更好的地方 - 当您更改工作类“系统分析师”的描述时会发生什么？
【讨论】：
这是一个自然键与代理键的问题吗？我们有这些before。还是与项目表中的小计有关？这确实违反了 3NF。
【讨论】：
无论您使用作业类名称还是代理键，从实际的角度来看，两者都可以且正确。如果您使用该名称，则该名称很难更改，因为它被用作 FK 关系的一部分。这就是为什么通常会分配像您的答案中这样的代理 ID。
它也更节省空间（这是一个物理问题）。
主键应该小而稳定，所以我喜欢基于 ID 的解决方案。
【讨论】：
我在这里看到了一些问题。
正如其他人指出的那样，小计是派生的，因此不应包括在内。
Professor 未能捕获项目负责人，似乎无法以其他方式推导出项目负责人。原来是和employee_name一起存储的，这真的让我眼花缭乱。
正如其他人所说，在基于名称的 pk 可能更改的地方使用代理键是正常的。
Total_charge 是另一个派生字段，不应包含在 3nf 解决方案中。
不，你不会离开。您包括了几个派生字段，这是在 3nf 建模中很常见的错误。你的教授也不远，但如果我采访他，我会更深入地挖掘这个。
【讨论】：