主页 / dba / 问题 / 8747
Accepted
Ankur Trapasiya
Asked: 2011-12-05 05:19:37 +0800 CST

是否需要规范化过程？

  • 772

好吧，在学习 DBMS 作为一门学科之后，我想到了很多问题。规范化就是其中之一。据我了解，有更多的困惑，我发现无论我们在规范化过程中做什么，我们也可以通过一般常识来完成。即使在制定项目时，人们也不习惯遵循它。那么真的有必要吗？公司是否遵循它？我问这个问题是因为它可能会花费更多时间来规范化数据库。我们可以仅使用常识直接对其进行归一化，因此我认为没有必要遵循标准归一化程序。如果我错了，请纠正我。

normalization rdbms

6 个回答

  1. Best Answer

    要回答您的问题，是的，需要规范化。

    常识是一个相对术语，可以进行解释。RDBMS 从 1970 年代就出现了。在过去的 30 年中，规范化已在无数项目中投入使用，这对正在开发的应用程序大有裨益。

    我在过去 15 年中处理过的最复杂的耗时问题可以直接归因于数据库设计者缺乏对规范化规则的理解（或故意无视）。

    如果您没有时间正确设计数据库，那么您就进错了领域，或者正在从事一个注定要失败的项目。

    • 8

  2. 编程课程中教授的每条规则、每一个过程、每一种模式都是试图将常识“制度化”的努力。如果您所有的开发人员在任何时候都具有完美的常识并且头脑清醒且富有洞察力，那么您就不需要遵循任何人的规则、流程或模式。

    然而，俗话说：“常识不是” ——意思是人们实际上往往没有完美的常识，不会自然而然地做他们需要做的一切来让自己远离麻烦，无论是现在，还是尤其是在未来。

    在拥有专业数据建模师和开发人员的组织中，规范化数据库是一种非常普遍的做法，他们了解正确设置数据库模式的重要性。规范化数据库不需要很多时间。事实上，大多数经验丰富的数据建模人员在构建模型时仍处于白板阶段时自然会这样做。

    在开始构建之前花（很少）时间确保逻辑模式被规范化，并花时间准确理解为什么要在物理模式中进行非规范化，以及这种冗余对代码的影响商业是专业发展过程的重要组成部分。

    • 7

  3. 然而，关键是规范化的原则采用那些常识性的想法，并提供对这些直觉概念的精确、准确的描述。

    Chris Date 和 David McGoveran 谈正交设计的原则。

    • 4

  4. 规范化可能主要是常识，但它是“形式化的常识”（Chris Date）。也许你在大学学习的例子非常简单，很容易在你的脑海中解决，而不需要仔细应用逻辑方法。实际上，并非所有数据模型都那么简单。一旦您超越了教程，拥有一种分析、理解和解决复杂问题的精确方法就很重要。

    • 3

  5. 回答你的问题：如果你能忍受后果，那就真的不需要了。是的，我合作过的所有公司都在使用它。

    常识只能让你走到这一步。在某些情况下，常识完全是错误的。我见过的许多设计问题都是屈服于常识的结果。

    常识告诉您，社会保险号码是唯一标识符。除了使用它们本身的法律问题外，这至少在四个方面失败了：

    1. 大多数国家在拥有适当的自动化系统之前就开始发布号码。在某些情况下，不止一个人获得了相同的号码。
    2. 有些人可能会申请并获得多个号码。
    3. 不止一个国家​​发布社会保险号码。
    4. 不是每个人都有社会保险号码。

    数据规范化是与应用程序设计不同的技能集。数据库设计处理静态数据，而应用程序设计处理动态数据。键值对数据库设计至关重要，而没有它们，应用程序也可以完美运行。

    像许多好的做法一样，这是现在付钱或以后付钱的情况。您现在可以花一些时间规范您的设计，或者稍后花很多时间来修复您的设计。无论您如何设计，它可能都不是满足您需求的完美模型。在充分了解风险和成本的情况下，稍后添加适当的反规范化比稍后删除意外的反规范化更容易。

    您应该考虑的一些事项。

    • 候选密钥是否随时间稳定？如果您允许用户创建它，则可能不会。
    • 您应该为此表使用代理键吗？
    • 除了主键还有其他唯一键吗？
    • 候选键真的是唯一的吗？
    • 属性真的依赖于主键吗？
    • 是否可以从我们拥有的其他数据中推导出任何属性？如果是这样，它们就是反规范化。考虑先导出它们，然后在必要时进行反规范化。
    • 表的所​​有属性都是同一个概念的一部分吗？如果不是，请在概念上拆分它们，并考​​虑您要如何制作物理模型。

    一旦有了规范化的概念模型，您就应该考虑这是否是您的物理模型。你应该很接近，有些公司不会为正式的转型步骤而烦恼。在其他情况下，模型可能需要进行重大转换。在某些情况下，您可以放宽实体的规则。在其他情况下，您可以组合实体。某些情况（例如子类型）有实现的替代方案。开始时考虑一下可以节省以后的大量返工。

    如果您有来自企业的意见，请确保您了解他们在说什么。我见过同一个词用来指代三个完全不同的事物。在其他情况下，差异可能很微妙，但可能很重要。

    • 2

  6. 要纠正一个常见但重要的误解：您不“规范化数据库”，而是规范化逻辑数据模型。

    数据设计，即设计数据如何在静止状态下生存的过程，有四个不同的阶段：概念、逻辑、实施、物理。

    规范化是改进逻辑模型的过程。是必需的吗？是的，如果您希望您的实施和物理模型保护数据完整性并表现良好。

    保护完整性的策略会降低性能，因此有时应用于逻辑模型的规范化过程在实现和物理模型中是相反的，这个过程通常称为非规范化。这是一种权衡——非规范化意味着以更好的性能为名接受更少的数据完整性保护。

    （这也意味着这里发布的问题“这个表是否规范化了？”是没有意义的，除非张贴者包括从中派生出该表的概念和逻辑模型。）

    我怀疑 OP 的情况是他们学习了“数据库系统”而不是学习“数据设计”。我经常在学习 Microsoft Access 的人身上看到这一点。他们开始相信数据库（物理模型）是整个数据模型。

    • 1

相关问题