写在最前
为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中,这种规则就是范式。范式是符合某一种级别的关系模式的集合。关系型数据库中的关系必须满足一定的要求,即满足不同的范式。
目前关系型数据库有六种范式,分别为:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。要求最低的范式是第一范式。第二范式在第一范式的基础上又进一步的添加了要求,其余范式依次类推。
一般说来,数据库只需满足第三范式就行了,而通常我们用的最多的就是第一范式
、第二范式
、第三范式
,也就是接下来要讲的“三大范式”。
第一范式
第一范式(1NF)用来确保每列的原子性
,要求每列(或者每个属性值)都是不可再分的最小数据单元
(也称为最小的原子单元)。
下表为“不满足第一范式”设计的表:
员工编号 | 姓名 | 性别 | 学历信息 |
---|---|---|---|
101 | 张德华 | 女 | 本科,南京大学 |
102 | 李星驰 | 男 | 专科,北京大学 |
103 | 马润发 | 男 | 硕士,香港大学 |
在上面的表中,“学历信息”列不满足原子性的要求,即可再分,故不满足第一范式,调整如下:
员工编号 | 姓名 | 性别 | 学历 | 毕业院校 |
---|---|---|---|---|
101 | 张德华 | 女 | 本科 | 南京大学 |
102 | 李星驰 | 男 | 专科 | 北京大学 |
103 | 马润发 | 男 | 硕士 | 香港大学 |
第二范式
第二范式(2NF)在 1NF 的基础上,要求表中的每列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。如果一个表满足第一范式,并且除了主键以外的其他列全部都依赖于该主键,那么该表满足第二范式。
下表为 “不满足第二范式” 设计的表:
员工编号 | 姓名 | 性别 | 技能 | 掌握程度 |
---|---|---|---|---|
101 | 张德华 | 女 | Java | 90% |
101 | 张德华 | 女 | Oracle | 80% |
102 | 李星驰 | 男 | Java | 85% |
103 | 马润发 | 男 | Java | 75% |
103 | 马润发 | 男 | Mysql | 95% |
在上图所示的情况中,同一个员工可能掌握不同技能,因此主键必须是“员工编号”和“技能”联合组成。
这样在该表中
掌握程度
字段不与该表的主键相关,而仅仅是与技能
相关。故不满足第二范式,调整如下:
员工编号 | 姓名 | 性别 |
---|---|---|
101 | 张德华 | 女 |
102 | 李星驰 | 男 |
103 | 马润发 | 男 |
员工编号 | 技能 | 掌握程度 |
---|---|---|
101 | Java | 90% |
101 | Oracle | 80% |
102 | Java | 85% |
103 | Java | 75% |
103 | Mysql | 95% |
第三范式
第三范式(3NF)在 2NF 的基础上,确保每列都和主键列直接相关,而不是间接相关,即限制列的冗余性。如果一个关系满足第二范式,并且除了主键以外的其他列都依赖于主键列,列和列之间不存在相互依赖关系,则满足第三范式。
下表为 “不满足第三范式” 设计的表:
员工编号 | 姓名 | 性别 | 学历 | 毕业院校 | 部门编号 | 部门名称 | 部门人数 |
---|---|---|---|---|---|---|---|
101 | 张德华 | 女 | 本科 | 南京大学 | d_1 | 研发一部 | 10 |
102 | 李星驰 | 男 | 专科 | 北京大学 | d_2 | 研发二部 | 15 |
103 | 马润发 | 男 | 硕士 | 香港大学 | d_2 | 研发二部 | 15 |
上表中,“部门名称”和“部门人数”是间接相关主键“员工编号”,故不满足第三范式,调整如下:
员工编号 | 姓名 | 性别 | 学历 | 毕业院校 | 部门编号 |
---|---|---|---|---|---|
101 | 张德华 | 女 | 本科 | 南京大学 | d_1 |
102 | 李星驰 | 男 | 专科 | 北京大学 | d_2 |
103 | 马润发 | 男 | 硕士 | 香港大学 | d_2 |
部门编号 | 部门名称 | 部门人数 |
---|---|---|
d_1 | 研发一部 | 10 |
d_2 | 研发二部 | 15 |
范式化反范式化
在实际的数据库设计中,既要考虑三大范式,避免数据的冗余和各种数据操作异常,又要考虑数据访问性能。为了减少表连接,提高数据库的访问性能,也可以允许适当的数据冗余列,这也许就是最合适的数据库设计方案。
范式化
满足范式的数据库设计,就是范式化。
- 优点:
- 减少数据冗余;
- 范式化后的表中只有很少的重复数据,更新时只需要更新较少的数据,所以范式化的更新操作比反范式化更快;
- 范式化的表通常比反范式化更小;
- 缺点:
- 范式化的表在查询时经常需要很多的关联,这回导致性能降低;
- 增加了索引优化的难度;
反范式化
不满足范式的数据库设计,就是反范式化。
- 优点:
- 可以减少表的关联;
- 可以更好的进行索引优化;
- 缺点:
- 数据表存在数据冗余及数据维护异常;
- 对数据的修改需要更多的成本;
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/78369.html