MySQL的六大范式_还记得数据库设计的六大范式吗？一篇文章让你完全搞懂

数据库范式是为解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题而引入的。简单的理解，数据库范式可以避免数据冗余，减少数据库的空间，并且减轻维护数据完整性的麻烦。

第一范式(1NF)

第一范式，强调属性的原子性约束，要求属性具有原子性，不可再分解。

举个例子，活动表(活动编码，活动名称，活动地址)，假设这个场景中，活动地址可以细分为国家、省份、城市、市区、位置，那么就没有达到第一范式。

第二范式(2NF)

第二范式，强调记录的唯一性约束，表必须有一个主键，并且没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

举个例子，版本表(版本编码，版本名称，产品编码，产品名称)，其中主键是(版本编码，产品编码)，这个场景中，数据库设计并不符合第二范式，因为产品名称只依赖于产品编码。存在部分依赖。所以，为了使其满足第二范式，可以改造成两个表：版本表(版本编码，产品编码)和产品表(产品编码，产品名称)。

第三范式(3NF)

第三范式，强调属性冗余性的约束，即非主键列必须直接依赖于主键。

举个例子，订单表(订单编码，顾客编码，顾客名称)，其中主键是(订单编码)，这个场景中，顾客编码、顾客名称都完全依赖于主键，因此符合第二范式，但是顾客名称依赖于顾客编码，从而间接依赖于主键，所以不能满足第三范式。为了使其满足第三范式，可以拆分两个表：订单表(订单编码，顾客编码)和顾客表(顾客编码，顾客名称)，拆分后的数据库设计，就可以完全满足第三范式的要求了。

值得注意的是，第二范式的侧重点是非主键列是否完全依赖于主键，还是依赖于主键的一部分。第三范式的侧重点是非主键列是直接依赖于主键，还是直接依赖于非主键列。

修正的第三范式(BCNF)

修正的第三范式，是防止主键的某一列会依赖于主键的其他列。

举个例子，每个管理员只能管理一个仓库，那么如果设计库存表(仓库名，管理员名，商品名，数量)，主键为(仓库名，管理员名，商品名)，这是满足前面三个范式的，但是仓库名和管理员名之间存在依赖关系，因此删除某一个仓库，会导致管理员也被删除，因此设计不合理。

第四范式(4NF)

当一个表中的非主属性相互独立时(3NF)，这些非主属性不应该有多值。如果有多值就违反了第四范式。举个例子，有一个用户联系方式表(用户id，固定电话，移动电话)，其中用户id是主键，这个满足了BCNF,但是一个用户有可能会有多个固定电话或者多个移动电话，那么这种设计就不合理，应该改为(用户id，联系方式类型，电话号码)。在实际应用中，一般不要求表满足第四范式。

第五范式(5NF)

第五范式是最终范式，消除了4NF中的连接依赖，第五范式有以下要求：

1. 必须满足第四范式

2.表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。

和第四范式不同的是，第四范式处理的是项目独立的多值情况，几多个属性的多值是相互独立的，没有关联关系，如固定电话和移动电话之间不会有任务关系。而第五范式是处理存在关联关系的冗余情况。例如下表：销售信息表(销售人员，供货商，产品)，设计这么一张表，主键为(销售人员，供货商，产品)，不同的供货商可以提供相同的产品，不同的销售人员，可以销售不同供货商的相同产品，因此这个设计是满足4NF的，但是这里存在一些关系冗余，可以将标拆为三个表(销售人员，供货商)(销售人员，产品)(供货商，产品)。第五范式主要就是消灭这种关系的冗余，在实际应用中，没有太多必要考虑这个。

反模式

范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。

然而，通过数据库范式化设计，将导致数据库业务涉及的表变多，并且可能需要将涉及的业务表进行多表连接查询，这样将导致性能变差，且不利于分库分表。因此，出于性能优先的考量，可能在数据库的结构中需要使用反模式的设计，即空间换取时间，采取数据冗余的方式避免表之间的关联查询。至于数据一致性问题，因为难以满足数据强一致性，一般情况下，使存储数据尽可能达到用户一致，保证系统经过一段较短的时间的自我恢复和修正，数据最终达到一致。

需要谨慎使用反模式设计数据库。一般情况下，尽可能使用范式化的数据库设计，因为范式化的数据库设计能让产品更加灵活，并且能在数据库层保持数据完整性。

有的时候，提升性能最好的方法是在同一表中保存冗余数据，如果能容许少量的脏数据，创建一张完全独立的汇总表或缓存表是非常好的方法。

另外一个比较典型的场景，出于扩展性考虑，可能会使用 BLOB 和 TEXT 类型的列存储 JSON 结构的数据，这样的好处在于可以在任何时候，将新的属性添加到这个字段中，而不需要更改表结构。但是，这个设计的缺点也比较明显，就是需要获取整个字段内容进行解码来获取指定的属性，并且无法进行索引、排序、聚合等操作