1

我希望我的数据库制作得不是特别好但功能还可以达到 3NF...我主要关心的是是否需要完美的 3NF，如果有这样的事情，以及我是否应该对其中的任何一个进行调整表达到足够好的 3NF？！帮助我了解这个数据库的规范化级别是否为 3NF 并且足以作为 3NF 传递... *请多多包涵，这是我的第一个 Web 项目，因此是我的第一个数据库！ 更改项目数据库

4

2 回答 2

2

3NF 通常（但并非总是）很有意义。至少，3NF 中的数据库往往更小，并且出现不一致的可能性大大降低。

查看您的数据库，作为起点，这里有一些想法：

  1. 用户。使您的主键合理。userid 是唯一的吗？username-mobileno 组合是唯一的吗？当然，唯一性不能由这三者的组合来定义。一种常见的策略是将 userid 作为主键，将 username-mobileno 作为唯一约束。如果这对您有用，请参阅#2
  2. 用户名-mobileno/userid。在子表中使用这三列似乎存在很大的混淆。只有用户的主键应该迁移到子表。
  3. servicepost子表。servicepost_details 和评级。username 在这些子表中似乎是多余的（在父表中可用）。
  4. 出价。它似乎是 servicepost 的另一个孩子。username, mobileno 似乎是多余的（在父表中可用）。
  5. 用户详细信息。这张桌子有什么用？如果每个用户只有一行，则转储表并将相关列移动到用户中。
  6. servicepost_details。再一次，在这个表中是否可以有多个行用于服务站中的一个？如果没有，请将其转储，并将相关列移动到 servicepost。
于 2015-07-25T22:42:56.570 回答
0

从 1NF 到 5NF 的每一种范式都是出于某种原因而被发明（或可能被发现）的。偏离正常形式会产生后果。正如@RudyF 已经指出的那样，正常形式通常但并非总是很有意义。

如果您是初学者，您现在最好忽略 BCNF、4NF 和 5NF。离开 1NF 的后果是您失去了对某些数据的密钥访问权限。背离 2NF 或 3NF 的后果是相同的事实在数据库中存储不止一次，这增加了它在两个地方存储不一致的可能性，从而在数据库内部产生矛盾。

至于您是否必须遵守“真正的 3NF”的问题，这归结为您是否准备好在数据库更新应用程序中确保永远不会提交自相矛盾的数据库，或者产生不一致的数据库结果会打扰你。

达到3NF并不难。每个表都需要一个键。通常，即使有多个可能的键，您也将键命名为主键。一个键可以由多个列组成。然后，确保非关键数据依赖于密钥、整个密钥，并且只依赖于密钥（所以请帮帮我 Codd）。如果不参考主题，您将无法回答有关依赖性的问题。

当你在规范化时，不要太在意速度或效率。您可以在构建之前调整设计以提高速度。

我希望这不会重复你已经知道的东西。学习这些东西很容易。变得精通并不是那么容易。

于 2015-07-27T11:09:12.647 回答