数据库规范化，数字主键或字符串

Question

我不得不与我的教授争论这件事，但他坚持认为我的解决方案是异常的，可能会引发冲突。他补充说，我无法理解数据库设计的概念。

然而，他无法向我解释为什么他的解决方案是正确的，而我的错误。

问题是关于以下kena数据库表的数据库规范化：

我的答案在左侧，教授的答案在右侧：

更好的观点： http://tny.cz/48c4a28b

你认为我的错误是什么？为什么你认为他说我的答案远非正确？

Answer 1

在这里实际回答并不多 - 但是这里......你的教授是正确的。

1. 小计不适合项目的概念 - 不属于该表。
2. 员工 - 同样 - 似乎没问题 - 但实际上工作班级可能会随着时间的推移发生变化而且不属于任何一个
3. jobclass应该显示所有3列 - id，name和charge
4. 订单项 - 同样没问题。

同样，项目负责人似乎是一个额外的概念。不应该成为这个答案的一部分，因为它似乎没有出现在您正在使用的基表中。

Answer 2

有两个显着的差异。

首先，您似乎在项目中存储子总计。这是重复的信息 - 您可以通过汇总每个项目的费用来获得小计。数据库设计的一个关键方面是“不要重复自己”。

第二个是你为“jobclass”创建了一个没有意义的主键，而你的教授使用了jobclass的名字作为主键。

理想情况下，您希望主键是唯一的（两种解决方案都符合此要求）。您还希望它不变 - 这就是我将您的解决方案更好地排名的地方 - 当您更改工作类“sys分析师”的描述时会发生什么？

Answer 3

无论您使用的是作业类名称还是代理键，从实际角度来看，这两者都是正确无误的。如果使用名称，则名称很难更改，因为它被用作FK关系的一部分。这就是为什么通常会分配您答案中的代理ID的原因。

它也更节省空间（这是一个物理问题）。

主键应该小而且稳定，所以我喜欢基于ID的解决方案。

Answer 4

我在这里看到一些问题。

1. 正如其他人所指出的那样，小计是派生的，因此不应包括在内。

2. 教授未能抓住项目负责人，而这似乎无法以其他方式得出。在原文中，它与employee_name一起存储，这实际上让我大家注意。

3. 正如其他人所说，在基于名称的pk可能改变的地方使用代理键是可以预期和正常的。

4. Total_charge是另一个派生字段，不应包含在3nf解决方案中。

不，你没有离开。你包含了几个派生字段，这是建模3nf时非常常见的错误。你的教授也不会离开，但如果我正在采访他，我会深入研究一下。

Answer 5

这是替代关键问题的自然关键吗？我们有这些before。或者它是关于项目表中的小计？这确实是违反3NF的行为。