原创
关系型数据库范式化与反范式化
温馨提示：
本文最后更新于 2017年02月20日，已超过 2,713 天没有更新。若文章内的图片失效（无法正常加载），请留言反馈或直接联系我。
范式化
范式：英文为Normal Form，所以一般我们简称“NF”。
在设计关系型数据库的时候，通常，我们会遵从不同的规范要求，从而设计出合理的关系型数据库。
这些不同的规范要求就是数据库范式。
关系型数据库一共有六大范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）、第五范式（5NF，完美范式）。
最低要求就是满足第一范式，在第一范式的基础上满足更多范式即为第二范式，以此类推，一般来说，只需要满足第三范式即可。
巴斯-科德范式：即Boyce-Codd Normal Form，所以，简称BCNF。
第一范式（1NF-字段不可再分解）
数据库中所有的属性字段不能再分解。
举个例子：假如有一张学生表。
| 学号 | 姓名 | 学校和学院 |
|---|---|---|
| 123456 | 小明 | 南昌大学信息学院 |
此时，学校和学院字段是不满足第一范式，需要拆分为学校、学院。
| 学号 | 姓名 | 学校 | 学院 |
|---|---|---|---|
| 123456 | 小明 | 南昌大学 | 信息学院 |
此时才是满足第一范式。
第二范式（2NF-数据表要有主键）
在1NF的基础上，要求数据表必须要有一个主键（非主键字段必须依赖主键）。
举个例子，假如有这么一张选课表：
| 学号 | 姓名 | 课程号 | 课程名称 |
|---|---|---|---|
| 123456 | 小明 | 1024 | 云计算 |
学号是学生的唯一标识，课程号是课程名称的唯一标识，但是，它们却杂糅在一张表了。
这就导致数据冗余且杂糅，并且可能会导致crud出现异常。
正确做法：
学生表：
| 学号 | 姓名 |
|---|---|
| 123456 | 小明 |
课程表：
| 课程号 | 课程名称 |
|---|---|
| 1024 | 云计算 |
课程与选课关联表：
| 学号 | 课程号 |
|---|---|
| 123456 | 1024 |
第三范式（3NF-不存在传递依赖）
在2NF的基础上，不存在传递依赖。
假设有这么一张表：
| 学号 | 姓名 | 学院 | 院长 |
|---|---|---|---|
| 123456 | 小明 | 信息学院 | 小张 |
这就导致了：字段冗余、可能导致crud异常。
满足3NF的正确做法：
学生表：
| 学号 | 姓名 | 学院号码 |
|---|---|---|
| 123456 | 小明 | 2048 |
学院表：
| 学院号码 | 学院 | 学院 |
|---|---|---|
| 2048 | 信息学院 | 小张 |
反范式化
范式越高意味着表的划分更细，一个数据库中需要的表也就越多。
但是，反范式化不意味着非范式化（不管不顾规则），反范式化是在满足部分范式化的基础上，为提升系统的运行效率，进行的一些优化。
比如，这么一张评论表。
| ID | 评论内容 | 用户ID |
|---|
假设，这张表很大很大，每次查询都需要将用户名称也查询出来，就可以考虑冗余一个用户名称字段。
| ID | 评论内容 | 用户ID | 用户名称 |
|---|
但是，这是非必需，因为还有很多其它方案可以达到目的，这里只是为了讲解反范式化。
范式化和反范式化的优缺点
范式化
优点
- 减少字段冗余。
- 数据表更小。
- crud更快。
缺点
- 关联表更多。
- 更难优化索引。
反范式化
优点
- 减少关联表。
- 更好优化索引。
缺点
- 可能导致字段冗余。
- crud的成本可能更高。
- 本文标签： MySQL
- 本文链接： http://www.lzhpo.com/article/174
- 版权声明： 本文由lzhpo原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
热门推荐
相关文章
关于我
会打篮球的程序猿
Talk is cheap, show me the code.
