规范化在数据库设计中的应用

Question

你好，数据库管理员。最近，为了提高我的数据库设计技能，我一直在阅读关于规范化的文章。然而，我对何时应用这项技术感到有点困惑。在学习规范化之前，我通常会阅读需求中的场景/描述，并以名词作为实体和动词作为关系的线索，绘制ER图(使用Chen的符号)，然后直接执行SQL语句来创建表。

目前，在我看来，规范化是在设计ER图之后进行的，然后将其应用于任何包含多值属性的实体。

我这么想对吗？还是应该在创建ER digram之前进行规范化，也许是在列出系统的可能属性之后呢？

Answer 1

听起来你好像是在CS课程或类似课程中学到的(这是件好事，海事组织)。我在一些课堂上也学到了它，我喜欢老师所采取的方法：

其他大学的同学，课程，.他们告诉我，他们得到了一篇大型论文，这些论文以一种非常理论性(因此相当无聊)的方式解释了规范化，他们不知道如何将这些相关知识转化为ER-图。

另一方面，我们花了很多时间学习如何正确地设计ER-图，组成一个好的、可维护的数据库的思想，以及如何解决图表中以及数据库中出现的问题(使用SQL)等等。在考虑了这些概念之后，我们被告知“你所做的被称为‘正常化’”。在设计ER时，您已经这样做了，这是标准化的第一种形式。

我的老师问我这样的问题时，有句话是“虽然设计得很好，但ER-模型设计得很好，但你已经有了一个规范化的数据库，所以你不需要考虑所有的标准化形式”。

因为您的问题不是如何/为什么使用规范化，而是在设计过程中，我认为上面的长文给了您一个可能的答案:当您了解良好DB设计的原则时，您的最终ER-模型是标准化的(例如，您创建了正确的连接表，使用外键是适用的，…)。我认为，这是一个需要与桌子的设置，他们的关系，等等齐头并进的过程。

当然，标准化并不总是必要的或需要的，但在大多数情况下，“绘制”ER并对其进行思考可以避免您通过查看模型并思考：“好的，第一种形式，是我的值尽可能是原子的”。

Answer 2

问得好。数据库规范化通常是通过分解进行规范化的过程--也就是说，您获取一个现有模式，然后通过应用从旧设计中创建新模式的无损分解来改进它。在实践中，这通常不是我们所需要的。

如果您正在创建一个新表或一组新表，那么更典型的情况是，您的起点是要表示的属性列表。因此，您应该识别属性之间的依赖关系，然后根据这些依赖关系直接创建规范化表。通常，在将表格添加到实际设计之前，可以在精神上或纸上完成这一任务。

呃建模不一定是达到这个目的的最好方法。对象角色建模是一种创建语义模型的方法，它比ER建模更准确地捕捉数据建模和业务规则的更多方面。您可以使用诸如诺玛之类的工具直接从ORM模型生成一个5NF数据库模式，而不需要任何特定的规范化步骤。

Answer 3

规范化，作为一个过程，发生在逻辑建模之后和物理模型之前。通常，人们跳过实际的逻辑模型，最终得到一个具有业务友好型名称的物理模型。逻辑模型应该定义数据实体和关系(通常与表约束混淆)，因此术语“term”

由于物理模型通常是以“正常形式”来讨论的，所以表必须已经“规范化”了，对吗？从设计的角度来看，将其转换为物理模型的过程是在应用规范化时进行的。也就是说，实体变成关系(或表)，关系通过约束强制执行，作为规范化过程的副产品。

换句话说，你的想法是正确的:)