考虑以下关系来说明我的问题:
Person( name, street, city, zipcode )
name -> street , city , zipcode
street + city -> zipcode
因此,如果我们知道这个名字,我们也知道这个人住在哪里.但是,邮政编码也是(短暂的)依赖于街道+城市.因此,这种关系破裂3NF,应该分成两个表来符合.
但在这种情况下,我们对zipcodes作为一个单独的实体不感兴趣.它是地址的一部分,恰好是瞬态依赖.我们永远不会单独使用它.
我理解为什么规范化是一件好事.但是,是否真的有必要始终规范化(从而使数据库更加复杂)？如果没有,你怎么知道什么时候可以跳过它？
(如果我的术语或符号错误,欢迎您纠正我)
规范化是一种用于分析依赖关系并确保正确实现表示为依赖关系的数据完整性规则(业务规则)的工具.规范化的基本假设是您知道或可以确定您实际想要实施哪些业务规则.如果您已经确定您不希望或不需要强制执行给定的业务规则,那么在为其设计数据库时将其视为依赖关系可能没什么价值.请记住,依赖关系点是规则对数据库中所有可能的数据始终有效; 不只是针对当前数据或某些特定数据子集.
可能是依赖{street,city} - > {zipcode}并非真正是系统所需的业务规则,因此不应强制执行.例如,如果必须在没有地址验证软件的情况下输入数据,则确保邮政编码以这种方式保持一致是不切实际的.这并不意味着您违反了任何规范化规则.它只是意味着函数依赖不是为了保持而不是保持,因此它不是任何真正意义上的传递依赖.
除了性能之外,如果您的数据中存在某种"模糊性",则不能完全正常化的另一个原因可能是.
据我了解1,ZIP可能是特定于城市街区或区域,这意味着特别长的街道可能有多个ZIP.即使ZIP确实对应于美国的城市+街道,对于其他国家的邮政编码也可能不一样,如果您决定走向国际.
但即使假设 ZIP确实是城市+街道特定的,人类也可能自己输入地址信息,这意味着他们可能会犯错误,包括错误的ZIP.因此,对于城市和街道的相同组合,您最终可以使用两个ZIP.
完全规范化的数据库根本无法表示 - 您必须以某种方式选择其中一个ZIP .除非您可以访问所有ZIP的完整,最新的数据库,否则您无法解决此冲突.如果您最终选择了错误的ZIP,则同一城市+街道上的所有人都将使用错误的ZIP.
另一方面,非规范化数据库将让每个人保持自己的ZIP,然后与其他人隔离后果.你甚至可以实现一个自动完成的建议,"你确定吗？" 警告以防用户为已有ZIP的现有城市+街道输入不同的ZIP,但如果他表示他确定,则让他(或她)继续.
1我不住在美国,所以我可能会离开.