原创
关系型数据库范式化与反范式化
温馨提示:
本文最后更新于 2017年02月20日,已超过 2,790 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我。
范式化
范式:英文为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)》许可协议授权