数据库设计 – 什么时候可以不规范化?

前端之家收集整理的这篇文章主要介绍了数据库设计 – 什么时候可以不规范化?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
考虑以下关系来说明我的问题:
Person( name,street,city,zipcode )

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

因此,如果我们知道这个名字,我们也知道这个人住在哪里.但邮政编码也是(短暂的)依赖于街头城市.因此,这种关系破坏了3NF,应该分成两个表来符合.

但在这种情况下,我们对zipcodes作为一个单独的实体不感兴趣.它是地址的一部分,恰好是瞬态依赖.我们永远不会单独使用它.

我理解为什么规范化是一件好事.但是,是否真的有必要始终规范化(从而使数据库更加复杂)?如果没有,你怎么知道什么时候可以跳过它?

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

解决方法

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

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

猜你在找的MsSQL相关文章