关系数据库的范式和反范式设计

最新推荐文章于 2022-07-22 16:56:54 发布

chenny_

最新推荐文章于 2022-07-22 16:56:54 发布

阅读量195

点赞数

分类专栏： mysql 文章标签：反范式 MySQL

本文链接：https://blog.csdn.net/chenny_/article/details/103164496

版权

mysql 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

## 关系数据库的范式和反范式设计

范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设计出错误的数据库。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，还又称完美范式）。满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。各种范式呈递次规范，越高的范式数据库冗余越小。

通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。简而言之，**======第一范式就是无重复的列======**。

第二范式（2NF）：首先要满足它是1NF，另外还需要包含两部分内容：一是表必须有一个主键；==二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。==
即要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。

第三范式（3NF）：在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。

简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。==简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。==

关于范式的讨论

第二范式和第三范式如何区别？

第二范式：非主键列是否依赖主键（包括一列通过某一列间接依赖主键），要是有依赖关系的就是第二范式；

第三范式：非主键列是否是直接依赖主键，不能是那种通过传递关系的依赖的。要是符合这种就是第三范式；

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

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

范式再给我们带来的上面的好处时，同时也伴随着一些不好的地方：==按照范式的规范设计出来的表，等级越高的范式设计出来的表越多。==

如第一范式可能设计出来的表可能只有一张表而已，再按照第二范式去设计这张表时就可能出来两张或更多张表，如果再按第三范式或更高的范式去设计这张表会出现更多比第二范式多的表。

表的数量越多，当我们去查询一些数据，必然要去多表中去查询数据，这样查询的时间要比在一张表中查询中所用的时间要高很多。也就是说我们所用的范式越高，对数据操作的性能越低。

所以我们在利用范式设计表的时候，要根据具体的需求再去权衡是否使用更高范式去设计表。在一般的项目中，我们用的最多也就是第三范式，第三范式也就可以满足我们的项目需求，性能好而且方便管理数据；

当我们的业务所涉及的表非常多，经常会有多表发生关系，并且我们对表的操作要时间上要尽量的快，这时可以考虑我们使用“反范式”。

**关于反范式**

不满足范式的模型，就是反范式模型。

反范式跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联；

RDBMS模型设计过程中，常常使用范式约束我们的模型，但在NOSQL模型中则大量采用反范式。

范式和反范式的对比

模型 |优点 | 缺点
---|---|---
反范式化模型 | 数据冗余将带来很好的读取性能（因为不需要join很多表，而且通常反范式模型很少做更新操作）|需要维护冗余数据，从目前NoSQL的发展可以看到，对磁盘空间的消耗是可以接受的
范式化模型 | 数据没有冗余，更新容易| 当表的数量比较多，查询设计需要很多关联模型（join）时，会导致查询性能低下

## 举个栗子

---

书上讲了好多，归结起来3句话：

1NF:字段不可分;
2NF:有主键，非主键字段依赖主键;
3NF:非主键字段不能相互依赖;

解释:
1NF:原子性字段不可再分,否则就不是关系数据库;
2NF:唯一性一个表只说明一个事物;
3NF:每列都与主键有直接关系，不存在传递依赖;

不符合第一范式的例子(关系数据库中create不出这样的表)：

表:字段1, 字段2(字段2.1, 字段2.2), 字段3 ......

存在的问题: 因为设计不出这样的表, 所以没有问题;

不符合第二范式的例子:

表:学号, 姓名, 年龄, 课程名称, 成绩, 学分;

这个表明显说明了两个事务:学生信息, 课程信息;

存在问题: