MySQL-数据库三范式

数据库三范式

（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