database-design - 什么时候可以不规范化？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




考虑以下关系来说明我的问题:

Person( name, street, city, zipcode )

name -> street , city , zipcode
street + city -> zipcode

所以如果我们知道名字，我们也知道这个人住在哪里。但是邮政编码也(暂时)依赖于街道 + 城市。因此，这种关系打破了 3NF并且应该分成两个表以符合要求。

但在这种情况下，我们对作为单独实体的邮政编码不感兴趣。它是地址的一部分，恰好是一个 transient 依赖项。我们永远不会单独使用它。

我明白为什么规范化是一件好事。但是是否真的有必要始终进行规范化(从而使数据库更加复杂)？如果没有，你怎么知道什么时候可以跳过它？

(如果我的术语或符号有错误，欢迎您纠正我)

Answer 1

规范化是一种用于分析依赖关系并确保正确实现表示为依赖关系的数据完整性规则(业务规则)的工具。规范化的一个基本假设是您知道或可以确定您实际想要实现哪些业务规则。如果您已经确定不想或不需要执行给定的业务规则，那么在为其设计数据库时将其视为依赖项可能没有什么值(value)。请记住，依赖关系的要点是，对于数据库中所有可能的数据，规则始终有效；不仅适用于当前数据或某些特定的数据子集。

在这种情况下，依赖关系 {street,city} -> {zipcode} 并不是系统真正需要的业务规则，因此不应强制执行。例如。如果必须在没有地址验证软件的情况下输入数据，以这种方式确保邮政编码一致可能是不切实际的。这并不意味着您违反了任何规范化规则。它只是意味着函数依赖不打算保持并且不保持，因此它不是任何真正意义上的传递依赖。