数据库三范式及反范式设计、对比（详解版）

数据库三范式（详解版）

范式化设计

什么是范式

范式来自英文Normal Form，简称NF。

实际上你可以把它粗略地理解为 一张数据表的表结构所符合的某种设计标准的级别 。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式5NF，又称完美范式）。

满足最低要求的范式是第一范式（1NF），在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。

第一范式（1NF）

定义： 属于第一范式关系的所有属性都不可再分，即数据项不可分。

理解：第一范式强调数据表的原子性，是其他范式的基础。一张表有一个name-age列，这个列具有两个属性，一个name,一个 age，所以不符合第一范式，我们把它拆分成两列name和age，这张表就符合第一范式关系。

你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，1NF是所有关系型数据库设计的最基本要求。

第一范式详细的要求如下：

1. 每一列属性都是不可再分的属性值，确保每一列的原子性；
2. 两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据；
3. 单一属性的列为基本数据类型构成；
4. 设计出来的表都是简单的二维表。

第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求实体的属性完全依赖于主关键字。

以上这张表不符合第二范式（2NF），虽然有主键，但是实体的属性不完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

设计成两张表，主键分别是id和op_id，这样就符合第二范式（2NF）。

第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）；

第三范式（3NF）要求一个数据库表中不包含已在其它表中包含的非主关键字信息，即数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。

产品表

这里如果产品ID或产品名称变化会发生什么情况？所以以上不符合第三范式（3NF）

以上订单表就符合第三范式

反范式化设计

完全符合范式化的设计真的完美无缺吗？很明显在实际的业务查询中会大量存在着表的关联查询，而表设计都做成了范式化设计（甚至很高的范式），大量的表关联很多的时候非常影响查询的性能。
反范式化就是违反范式化设计：

1. 为了性能和读取效率而适当的违反对数据库设计范式的要求；
2. 为了查询的性能，允许存在部分（少量）冗余数据。

换句话来说反范式化就是使用空间来换取时间。

范式化和反范式对比

1. 范式化的更新操作通常比反范式化要快（字段较少）。
2. 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
3. 范式化的表通常更小，所以占据的内存更少。
4. 范式化设计的缺点是通常需要关联，稍微复杂一些的查询语句在符合范式的表上都可能需要至少一次关联，也许更多。
5. 复杂一些的查询语句也可能使一些索引策略无效。例如，范式化可能将列存放在不同的表中，而这些列如果在一个表中本可以属于同一个索引