四、物理优化（1）范式化

一、范式化的概念

　　范式化（Normalization）的目标是消除数据冗余，减小物理存储空间。

　　常用的范式有以下3种：

1. 第一范式（1NF）

　　在任何一个关系数据库中，1NF是对关系模式的基本要求，不满足1NF的数据库就不是关系数据库。

　　所谓1NF是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在1NF中表的每一行只包含一个实例的信息。

　　例如，对于员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。　　

 

2. 第二范式（2NF）

　　2NF是在1NF的基础上建立起来的，即满足2NF必须先满足1NF。2NF要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。

　　例如，员工信息表中加上了“员工编号”列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。

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

 

3. 第三范式（3NF）

　　3NF要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。简而言之，3NF就是属性不依赖于其它非主属性。 满足3NF必须先满足2NF。 

　　例如，存在一个部门信息表，有“部门编号”、“部门名称”、“部门简介”等列。那么在员工信息表中列出“部门编号”后就不能再将“部门名称”、“部门简介”等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则3NF也应该构建它，否则就会有大量的数据冗余。

 

 

二、范式化的优点

1. 从设计角度

　　范式化之后，每个表的结构非常明确，对于设计人员来说非常清晰明了，更易于修改系统的架构。

 

2. 从性能的角度 

　　范式化之后，每个表变成最窄，因此每一页可以容纳更多的行。查询、排序、索引的开销都会降低。

 

 

三、反范式化

1. 范式化的缺点

　　当数据来自不同的表，需要join，当基表的记录非常多时，这也将是一个消耗资源的重要原因。此外，频繁查询一些派生列时需要临时计算，这也会影响性能，而且可能会使查询的设计过程变得复杂。

　　例如：对于一张超市POS机的流水单明细表，3NF之后只记录商品ID、单价、数量、单项折扣等信息，查询时才临时产生一个单项金额。 而这张流水单明细表对应的流水单主表，同样也不会保存金额，在查询时通过聚合函数临时计算。

 

　　对于上述表结构，如果频繁查询金额，并且表的记录数非常多，性能就会受影响。

 

2. 反范式化（De-normalization）

　　在范式化的架构遇到性能问题时，就要考虑放宽范式的要求。通常要仔细权衡，将更新（增、删、改）与查询这两者的开销进行对比。

　　例如，在数据更改时就直接计算聚合值，而不是在查询时再临时计算。

 

3. 反范式化的优势

（1）减少join的数量

（2）减少外键的数量

（3）减少索引的数量，从而节省存储空间

（4）加快查询速度，因为聚合值已经预先计算

（5）某些情况下可能减少表的数目 

 

四、反范式化的缺点

1. 虽然加速查询，但降低写入速度。

2. 需要考虑应用程序是否适应。

3. 可能需要增加物理表。

4. 可能使代码变得简单，也可能更复杂。

 

五、范式化 vs. 反范式化

　　范式化对表结构的严格要求，可能会影响性能。在设计阶段，务必权衡查询与更新（增删改）的开销对比。

1. 考虑范式化

　　较多的更新，而较少的查询时。

 

2. 考虑反范式化

　　较少的更新，而较多的查询时。

 

 

本文结语：

　　范式化和反范式化各有优势与短板，需要从存储空间、维护的开销、查询的开销等方面综合考量。

 

本文出自 “我们一起追过的MSSQL” 博客，转载请与作者联系！