MySQL-数据库三范式

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MySQL-数据库三范式，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2047字，纯文字阅读大概需要3分钟。

内容图文

数据库三范式

（1）第一范式（1NF）：

定义:每一列都是不可分割的原子数据项（强调的是列的原子性）；

例：一个表：【联系人】（姓名，性别，电话）

如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到1NF。

解决方案：

要符合1NF我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF很好辨别，但是2NF和3NF就容易搞混淆。

 （2）第二范式（2NF）：

定义:有主键，要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性；（强调的是唯一性）

例：一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。

因为我们知道在一个订单中可以订购多种产品，所以单单一个OrderID是不足以成为主键的，主键应该是（OrderID，ProductID）。

显而易见Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），

而UnitPrice，ProductName只依赖于ProductID。所以OrderDetail表不符合2NF。不符合2NF的设计容易产生冗余数据。

解决方案：

可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和

【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

（3）第三范式（3NF）：

定义:任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）；
即不能存在：非主键列A依赖于非主键列B，非主键非主键列必须直接依赖于主键，不能存在传递依赖。列B依赖于主键的情况。

例：一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。

其中OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity等非主键列都完全依赖于主键（OrderID），所以符合2NF。

不过问题是CustomerName，CustomerAddr，CustomerCity直接依赖的是CustomerID（非主键列），而不是直接依赖于主键，

它是通过传递才依赖于主键，所以不符合3NF。

解决方案:

通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和

【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到3NF。

第二范式和第三范式对比：

2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；

3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

 原文链接：https://blog.csdn.net/csdnluolei/article/details/83410855

内容总结

以上是互联网集市为您收集整理的MySQL-数据库三范式全部内容，希望文章能够帮你解决MySQL-数据库三范式所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端