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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

FD理论也是DBMS设计者应该知道的重要材料。例如，关系数据库管理系统需要能够对关系表达式执行所谓的“键推断”(即，在给定输入的键是什么的情况下，计算连接的输出必须符合哪个键。如果没有FD理论，这样的推断是不可能的。)

至于“如果您了解您的实体是什么，以及它们的属性是什么--您基本上不是从BCNF中已经存在的表开始的吗？”，这在一定程度上取决于您的概念级实体是否已经被“正确”标识(对于后者的某种含义--我所指的是，就像人们可以提出糟糕的数据库设计一样，他们也可以提出糟糕的概念模型，如果您使用如此糟糕的模型作为数据库设计的基础，那么您可以猜到结果会是什么)。