数据库三范式
（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