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

【问题标题】：Do you use dependencies and normal forms to design a relational database schema?您是否使用依赖关系和范式来设计关系数据库模式？
【发布时间】：2018-08-02 21:38:58
【问题描述】：

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

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

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

对于那些设计和维护模式的人，你真的使用依赖理论和范式吗？还是你像我一样随心所欲？

【问题讨论】：

我在设计表或查询时会考虑功能依赖关系。当我加入表时，我需要知道哪些列确定/识别输出，以了解我是否需要执行 GROUP BY。这需要使用 Armstrong 公理来理解 FD 和心理代数。我知道人们成功地实现了这一目标，但我不想再那样工作了。
我对设计表格特别感兴趣。你如何获得FD？您如何获得从分解中受益的初始表定义？
当我规划一个功能时，我经常会想“要做到这一点，我们需要一个从 X 到 Y 的 FD”。例如。在设计 UI 屏幕或报告时，如果要求为每个 X 显示一个 Y，则需要一个相应的 FD（可能是可传递的）。如果 FD 不存在并且无法添加，则需要调整屏幕或报告以处理每个 X 的多个 Y。至于分解，在广告中构建或改编的旧表格源源不断- 特设时尚。在修复不一致的数据时，我也经常使用这些技术。
“我发现这种模式设计方法在现实世界中完全没用。” 为什么？不准确吗？是不确定的吗？不明白函数依赖从何而来？
您最好在Database Administrators 提问。（或Computer Science。）虽然我觉得这很奇怪——你的实际兴趣似乎是“这种方法是否有“实际价值”？规范化在教科书中的表现不佳，在教科书之外表现得非常糟糕，因此实际上总是学得不好或被误解，或者只是没有学过，那么“你会使用什么”呢？（我一直想发表一个答案——大意是即使是最好的演示文稿也是一团糟，但规范化至关重要且 ER 建模不足——但理由使它有点像一篇文章。）

标签： database-design relational-database database-schema database-normalization functional-dependencies

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

FD 理论也是 DBMS 设计人员应该了解的重要材料。例如，关系型 DBMS 需要能够对关系表达式进行所谓的“键推断”（即，考虑到输入的键是什么，计算出 JOIN 的输出保证符合哪些键。如果没有 FD 理论，这样的推断是不可能的。）

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

【讨论】：

【解决方案4】：

reannb 谈到了可以提供有关 FD 信息的各种工件：领域专业知识、UI 设计、FK 约束、源代码、查询、与其他开发人员交谈。换句话说，您要么只是以某种方式了解 FD（领域专家、其他开发人员），要么您正在查看这些人（UI、FK、代码）的知识提炼。但是领域专家从哪里获得 FD？如果它不是一个 E/R 模型——无论是明确的还是内部的、直观的——那么 FD 的来源是什么？

Erwin Smout 基本上说的是 GIGO，这显然是正确的。但是如果不是一个 E/R 模型，那仍然没有说明 FD 是从哪里来的。

所以我还是不明白：如果不是 E/R 模型，FD 是从哪里来的？让我澄清一下：我并不是说归一化理论没有用，我同意 Erwin Smout 在这个问题上的观点。另外，我不是因为我是新手而问的（请参阅我的原始帖子）。我的问题与模式设计的教学有关。归一化理论的讨论似乎非常做作。他们从一个设计非常糟糕的模式开始，以及来自......的功能依赖关系......好吧，他们从不说FD来自哪里。应用规则，瞧，我们有一个 BCNF 模式。在我看来，一种更合理、更现实、更有用的方法是：

架构设计从 E/R 模型开始。
以下是从 E/R 模型生成一组表和 FK 定义的过程。
现在请注意，您的 E/R 模型实际上暗示了这些功能依赖关系。
然后进入规范化理论并展示 BCNF 分解（例如）如何从非常糟糕的起点产生相同的模式。
如果您继承了一个错误的架构，开发一个清晰的 E/R 模型和功能依赖关系可以帮助您找出一个好的架构。

【讨论】：

你也可以问“E/R 模型从何而来”。答：设计师采访主题专家。基本上就是这样。一切都来自那里。现在，这些访谈的结果是否以关系模式和具体的 FD 集的形式写下来，是另一回事。在实践中，我从未见过这种情况发生。因此，您正确地观察到，在实践中，做任何诸如“BCNF 分解”之类的事情总是缺少完成该过程所需的正式输入。 ...
但我不相信 db 设计者可以承担对各种 NF 的无知以及它们在任何特定 xNF 中的任何设计都会出现的“更新异常”方面的属性我>。 ...
也就是说，我也认为应该教授FD理论的缺点和缺点。例如，它如何无法处理时间数据库中时间/日期范围之间的“非重叠要求”。例如，SQL 的 NULL 如何模糊甚至取消设计可能被认为具有基于其模式加 FD 的许多属性。（如果你有一个带有 FD X->Y 的模式 XY，那么你可以有两个元组（null，“A”）和（null，“B”）???）等等。（注意我是不是说后者以任何方式提倡 NULL ！）
可能出现的业务情况和表格含义共同决定了约束。约束描述了数据库状态的不变属性，同时通过业务情况的含义来描述。当它的行列式子元组在其表中的确定子元组的值恰好为 1 时，FD 成立。这同时表明在业务情况中存在某种含义。（例如，只有 1 名员工管理一个部门。）我们声明 FK 是因为我们看到约束和/或暗示成立。我们不需要为此设计 ER 设计，只需要一个关系设计。
不，因为如果您只有一个指定键的 ER 模式，那么根据定义，您可以合理假设应用的唯一 FD 是那些“从键派生”的 FD .那么根据定义必然是对应的逻辑关系模式在BCNF中。顺便说一句，我有一个建议给你。尝试在线查找“FCO-IM 书”。它是关于概念建模的另一种技术，它有一些关于面试过程应该如何进行的非常详细的内容。并非所有演讲都同样幸运/值得称赞，但我想你会喜欢的。

【解决方案5】：

“你真的使用依赖理论和范式吗？或者你只是像我一样随心所欲吗？”

我已经设计数据库模式超过 15 年了。

但是，我从未使用过依赖理论（功能依赖分析-FDA）我也不会“即兴发挥”。
然而，我所有的模式设计都是第五范式。 (5NF)

我的秘诀是我使用了一种叫做“对象-角色建模”的形式化方法我使用一个名为 NORMA 的免费工具来设计一个正式的模型，NORMA 工具可以从中自动生成一个 5NF 逻辑模型。

在建模过程中，我打开了一个“关系视图”窗口，它会自动立即生成我的对象角色模型在其“当前状态”下的 5NF 逻辑视图。

当我对我的设计感到满意时，我会选择一个目标 RDBMS（例如 SQL Server），然后单击几下鼠标，我就有了 SQL DDL，然后我将其剪切并粘贴到 SQL Server Management Studio 的“新查询”面板中. 这种方法比FDA或wing it要有效得多。

您可以download the free NORMA tool from here。 tutorials are here。

顺便说一句 - 我最近听说一所大学放弃了实体关系建模，转而教授对象-角色建模。

自白：我作为学生在几门大学课程中确实使用过 FDA，但这足以让我终生放弃它！

【讨论】：