background:为什么要学习数据库设计范式:
为了给我们所开发的项目设计出一个结构合理的数据库,必须遵循一定的设计规则也叫设计规范,在关系数据库中这种规则就称为范式。
参考:https://blog.csdn.net/h330531987/article/details/71194540
范式的分类:
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式) 各种范式呈递次规范,越高的范式数据库冗余越小。
- 一般说来,数据库只需要满足到第三范式(3NF)就行了。
- 要遵循后边的范式要求,必须先遵循前边的所有范式要求。
三种范式的解释:每一列都是原子数据项、消除部分依赖、消除传递依赖。
-
第一范式 (1NF):数据库表的每一列都是不可分割的原子数据项,而不能是集合、数组、记录等非原子数据项。
-
第二范式(2NF):在第一范式的基础上,它的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系而不是部分依赖关系;如果有哪些非主属性只和主键的一部份有关的话,它就不符合第二范式。同时可以得出:如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式(前提是该数据表符合第一范式)。(属性指的是一列)。
第二范式就是不希望大家使用联合主键,而是推荐拆分成多张表,每张表里都使用单一字段做为主键。 -
第三范式 (3NF):在第二范式的基础上,要求确保数据表中的每一列数据都和主键直接相关,不存在非关键字段对任一候选关键字段存在函数依赖的关系。即消除传递依赖、或者说是消除非直接依赖。。
三种范式的举例解释:
- 已知一张表,用来表示学生卡的所有信息:使用 CardNo +StudentNo 作为联合主键。
CardNo | StudentNo | StudentName | Sex | Department | CardCash | inputUserID 班主任 | inputOrg 班主任所属机构 |
---|---|---|---|---|---|---|---|
001 | 021101 | 小明 | 男 | 教育学院,心理系,1班 | 100 | 52551511 | 哈哈学院共青团 |
- 根据第一范式,数据库表中的字段应该都是单一属性的,不可再分的。所以这里把 Department 字段切分掉:
CardNo | StudentNo | StudentName | Sex | Academy | Major | class | CardCash | inputUserID | inputOrg |
---|---|---|---|---|---|---|---|---|---|
001 | 021101 | 小明 | 男 | 教育学院 | 心理系 | 1班 | 100 | 52551511 | 哈哈学院共青团 |
- 根据第二范式,数据表里的所有非主属性都要和该数据表的主键(这里的联合主键)有完全依赖关系而不是部分依赖关系。看的出来,卡内余额字段CardCash 只依赖主键中的CardNo 就能唯一确定了,所以这里形成了部分依赖;同理,在这张表中,StudentName,Sex,Academy,Major,class都是只依赖于StudentNo,所以这里也形成了部分 依赖。所以改造成两张表。
CardNo | CardCash |
---|---|
001 | 100 |
StudentNo | StudentName | Sex | Academy | Major | class | inputUserID | inputOrg |
---|---|---|---|---|---|---|---|
021101 | 小明 | 男 | 教育学院 | 心理系 | 1班 | 52551511 | 哈哈学院共青团组织 |
- 看的出来,班主任inputUserID依赖于主键StudentNo,班主任所属机构inputOrg却是依赖inputUserID,这样的话,就构成一种传递依赖或者说非直接依赖。根据第三范式的原则,把学生表再切分。
CardNo | CardCash |
---|---|
001 | 100 |
StudentNo | StudentName | Sex | Academy | Major | class | inputUserID |
---|---|---|---|---|---|---|
021101 | 小明 | 男 | 教育学院 | 心理系 | 1班 | 52551511 |
inputUserID | inputOrg |
---|---|
52551511 | 哈哈学院共青团组织 |