Database design 您是否使用依赖项和范式来设计关系数据库模式？

作为一名软件工程师，我有多年的工作经验，并曾广泛使用数据库，主要是Oracle和Postgres。我对数据库模式使用了一种非正式的设计方法。我画出一个类似于E/R图的东西，然后从那里生成DDL。随着时间的推移，随着更多需求的到来，我会从那里修改模式。 我接受了计算机科学学术方面的严格培训，并撰写了与数据库相关的硕士和博士论文。我了解依赖关系、范式和分解方法。我发现这种模式设计方法在现实世界中是完全无用的

我现在教授一门关于数据库系统的高级课程，我尽职尽责地学习了模式设计的经典材料，包括依赖项、范式和分解。但我仍然不相信这种方法的实际价值

教科书中对这些理论主题的讨论，从设计非常糟糕的模式开始，以及来自。。。嗯，我不知道。它们就在那里，然后引导你找到更好的模式。但是从一个好的实体/关系模型开始，您可能会从一个非常好的模式开始。如果您了解了实体是什么，以及它们的属性是什么，那么基本上您不是从BCNF中已有的表开始的吗

---

对于那些设计和维护模式的人来说，你们真的使用了依赖理论和范式吗？或者你只是像我一样使用它？

教科书和课程经常用渐进式分解的例子来解释规范化-从模式开始，在模式中依赖关系不能通过键正确地强制执行，然后逐步发展到满足BCNF、5NF、，这是一个用来解释一些概念和技巧的教学练习；它不是实际数据库设计应该如何进行的蓝图。这类似于在数学课上练习长除法，不是因为这种方法很常用，而是因为基础算术知识很重要

---

我使用了函数依赖性分析来解决一些困难的情况，验证设计，并通过合成进行规范化。有一些CASE工具支持通过合成进行规范化，而更多的主流软件工具不支持规范化，这可能是一个遗憾。

当我构建数据库时，我通常从一个好的ER模型开始。我需要这个来检查我对主题的理解。 将ER模型转换为关系模型后，结果通常是3NF，通常是BCNF。通常足以进行OLTP工作。 对于OLAP工作，我使用了星型模式设计。这充满了更新异常，我通过小心使用ETL来处理这些异常。

---

仅此而已。

通常，对业务的扎实理解（通常通过详细阐述的概念建模获得）和在设计实践中不太缺乏经验的结合，将足以在大多数用例中“从头开始”实现5NF设计。因此，教科书中通常说明/建议的“规范化程序”几乎从未实际实施过。应用该过程是一种“自下而上”的方法，对于大多数实践设计师来说，这种方法感觉很不自然，他们更喜欢从概念模型开始“自上而下”，概念模型通常已经被“分解”，就像您最终将标准化过程作为一种方法应用一样

这并不意味着规范化理论本身就可以被淘汰。它仍然构成了为什么某些设计比解决相同问题的其他替代设计“更好”的正式基础

FD理论也是DBMS设计人员应该了解的重要内容。例如，关系数据库管理系统需要能够对关系表达式进行所谓的“键推理”（即，根据输入的键，计算连接的输出保证符合哪些键。如果没有FD理论，这种推理是不可能的。）

---

至于“如果您了解您的实体是什么，以及它们的属性是什么——您基本上不是从BCNF中已有的表开始的吗？”，这在一定程度上取决于您的概念级实体是否已“正确”标识（对于后一个词的某些含义，我指的是，就像人们可以提出糟糕的数据库设计一样，他们也可以提出糟糕的概念模型，如果你使用这样一个糟糕的模型来建立数据库设计，那么你可以猜出结果是什么）

REANB讨论了可以提供FDs信息的各种工件：领域专家、UI设计、FK约束、源代码、查询、与其他开发人员交谈。换句话说，您可能只是不知怎么地了解FDs（领域专家、其他开发人员），或者您正在查看从这些人那里提取的知识（UI、FK、代码）但是，领域专家从何处获得FDs？如果它不是E/R模型——无论是明确的，还是内部的，直观的模型——那么FDs的来源是什么

埃尔文·斯穆特（Erwin Smout）说，基本上是吉戈（GIGO），这显然是正确的。但如果不是E/R模型，这仍然不能说明FDs来自哪里

所以我仍然不明白：如果不是E/R模型，FDs从何而来？让我澄清一下：我并不是说规范化理论是无用的，我同意埃尔文·斯穆特在这个问题上的观点。此外，我也不是因为我是一个新手而问这个问题（见我的原始帖子）.我的问题与模式设计的教学有关。规范化理论的讨论似乎非常做作。他们从一个设计非常糟糕的模式开始，以及来自…的函数依赖性，他们从来没有说FD来自何处。应用规则，瞧，我们有一个BCNF模式。在我看来，更合理的，现实而有用的方法是：

• Sche