数据库 三范式

三大范式

第一范式

原子性： 保证每一列不可再分

第二范式

前提： 满足第一范式
然后每张表只描述一件事情
考虑一个订单明细表：【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多次重复的情况。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式

满足前面两个范式的基础上，确保数据表中的 每一列数据都和主键直接相关,不能间接相关

规范性 和性能的问题：

1. 关联查询的表不能超过 3张表
   mysql 关联查询

2. 在规范性能问题的时候，需要适量考虑规范性(考虑商用的性能)

3. 故意给某些增加一些冗余字段（从多表中变单表查询）

4. 故意增加一些计算列（将大数据量降低为小数据量的查询，建立索引等等）

总结：
1.不可再分
2.每张表只是描述一件事情
5. 每个列的数据必须与主键直接相关,不能间接相关

第一范式：列不可再分
第二范式：非主键属性全部依赖于主键属性
第三范式：非主键属性之间无依赖关系
第四范式：主键属性之间无依赖关系