范式

转载自：小麦苗

当设计关系型数据库时，需要遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式（Normal Form），越高的范式数据库冗余越小。应用数据库范式可以带来许多好处，但是最主要的目的是为了消除重复数据，减少数据冗余，让数据库内的数据更好的组织，让磁盘空间得到更有效的利用。范式的缺点：范式使查询变的相当复杂，在查询时需要更多的连接，一些复合索引的列由于范式化的需要被分割到不同的表中，导致索引策略不佳

一、二、三、BC 范式

所谓“第几范式”，是表示关系的某一种级别，所以经常称某一关系R为第几范式。目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。满足高等级的范式的先决条件是必须先满足低等级范式。

• • 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。简而言之，第一范式就是无重复的列。
  • 第二范式（2NF）：首先要满足它是1NF，另外还需要包含两部分内容：一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
  即要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
  • 第三范式（3NF）：在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）

在关系数据库中，关系是通过表来表示的。在一个表中，每一行代表一个联系，而一个关系就是由许多的联系组成的集合。所以，在关系模型中，关系用来指代表，而元组用来指代行，属性就是表中的列。对于每一个属性，都存在一个允许取值的集合，称为该属性的域。

下表列出了各种范式：

四种范式之间存在如下关系：

示例：

学习了范式，为了巩固理解，接下来设计一个论坛的数据库，该数据库中需要存放如下信息：
（1）用户：用户名，EMAIL，主页，电话，联系地址
（2）帖子：发帖标题，发帖内容，回复标题，回复内容
第一次可以将数据库设计为仅仅存在一张表：
用户名 EMAIL 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容
这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，唯一的关键字段用户名也不能完全决定整个元组。所以，需要增加“发帖ID”、“回复ID”字段，即将表修改为：
用户名 EMAIL 主页 电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题 回复内容
这样数据表中的关键字（用户名，发帖ID，回复ID）能决定整行：
（用户名，发帖ID，回复ID）→（EMAIL，主页，电话，联系地址，发帖标题，发帖内容，回复标题，回复内容）
但是，这样的设计不符合第二范式，因为存在如下决定关系：
（用户名）→（EMAIL，主页，电话，联系地址）
（发帖ID）→（发帖标题，发帖内容）
（回复ID）→（回复标题，回复内容）
即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。
因此，需要对这张表进行分解，具体可以分解为（带下划线的为关键字）：
（1）用户信息：用户名，EMAIL，主页，电话，联系地址
（2）帖子信息：发帖ID，标题，内容
（3）回复信息：回复ID，标题，内容
（4）发贴：用户名，发帖ID
（5）回复：发帖ID，回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？不一定。
观察可知，第4项“发帖”中的“用户名”和“发帖ID”之间是1：N的关系，因此，可以把“发帖”合并到第2项的“帖子信息”中；第5项“回复”中的“发帖ID”和“回复ID”之间也是1：N的关系，因此，可以把“回复”合并到第3项的“回复信息”中。这样可以一定程度地减少数据冗余，新的设计如下所示：
（1）用户信息：用户名，EMAIL，主页，电话，联系地址
（2）帖子信息：用户名，发帖ID，标题，内容
（3）回复信息：发帖ID，回复ID，标题，内容
数据库表1显然满足所有范式的要求。
数据库表2中存在非关键字段“标题”、“内容”对关键字段“发帖ID”的部分函数依赖，满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常。
数据库表3中也存在非关键字段“标题”、“内容”对关键字段“回复ID”的部分函数依赖，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。
由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好。
对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。
对于1：1的关系，可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。
所以，满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
所以，在数据库设计的时候，一定要时刻考虑范式的要求。

反范式

不满足范式的模型，就是反范式模型。
反范式跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联；
RDBMS模型设计过程中，常常使用范式约束我们的模型，但在NOSQL模型中则大量采用反范式。
　　反范式是通过增加冗余数据或数据分组来提高数据库读性能的过程。在某些情况下， 反范式有助于掩盖关系型数据库软件的低效。关系型的范式数据库即使做过优化， 也常常会带来沉重的访问负载。

数据设计要严格遵守范式，这样设计出来的数据库，虽然思路很清晰，结构也很合理，但是，有时候却要在一定程度上打破范式设计。因为范式越高，设计出来的表可能越多，关系可能越复杂，但是性能却不一定会很好，因为表一多，就增加了关联性。特别是在高可用的OLTP数据库中，这一点表现得很明显，所以就引入了反范式。最明显的打破范式的设计方法就是冗余法，以空间换取时间的做法，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联。
不满足范式的模型，就是反范式模型。反范式跟范式所要求的正好相反，在反范式的设计模式中，可以允许适当的数据冗余，用这个冗余可以缩短取数据的时间。反范式其本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时就可以减少或者是避免表之间的关联。反范式技术也可以称为反规范化技术
反范式的优点：减少了数据库查询时表之间的连接次数，可以更好的利用索引筛选和排序，从而减少了I/O数据量，提高了查询效率，可以提高查询操作的性能；
反范式的缺点：数据存在重复和冗余，存在部分空间浪费。另外为了保持数据一致性，必须维护这部分冗余数据，因此增加了维护的复杂性。所以进行范式设计时，要在数据一致性与查询之间找到平衡点，符合业务场景的设计才是好设计。

在RDBMS模型设计过程中，常常使用范式来约束模型，但在NoSQL模型中则大量采用反范式。常见的数据库反范式技术如下：

举例，有学生表与课程表，假定课程表要经常被查询，而且在查询中要显示学生的姓名，则查询语句为：

SELECT CODE,NAME,SUBJECT FROM COURSE C,STUDENT S WHERE S.ID=C.CODE WHERE CODE=?

如果这个语句被大范围、高频率执行，那么可能会因为表关联造成一定程度的影响，现在，假定评估到学生改名的需求是非常少的，那么，就可以把学生姓名冗余到课程表中。注意：这里并没有省略学生表，只不过是把学生姓
名冗余在了课程表中，如果万一有很少的改名需求，只要保证在课程表中改名正确即可。

那么，修改以后的语句可以简化为：

SELECT CODE,NAME,SUBJECT FROM COURSE C WHERE CODE=?

范式和反范式的对比如下表所示：

使用范式有哪些优点和缺点？

范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。
范式再给我们带来的上面的好处时，同时也伴随着一些不好的地方：按照范式的规范设计出来的表，等级越高的范式设计出来的表越多。
如第一范式可能设计出来的表可能只有一张表而已，再按照第二范式去设计这张表时就可能出来两张或更多张表，如果再按第三范式或更高的范式去设计这张表会出现更多比第二范式多的表。
表的数量越多，当我们去查询一些数据，必然要去多表中去查询数据，这样查询的时间要比在一张表中查询中所用的时间要高很多。也就是说我们所用的范式越高，对数据操作的性能越低。
所以我们在利用范式设计表的时候，要根据具体的需求再去权衡是否使用更高范式去设计表。在一般的项目中，我们用的最多也就是第三范式，第三范式也就可以满足我们的项目需求，性能好而且方便管理数据；
当我们的业务所涉及的表非常多，经常会有多表发生关系，并且我们对表的操作要时间上要尽量的快，这时可以考虑我们使用“反范式”。