1、学习原因
我们学习关系型数据库设计范式的原因在于设计出一个结构清晰、简洁的数据库,且不会发生插入、删除、更新异常。
没有规矩不成方圆,不满足数据库设计范式会让我们设计出的表相对复杂,乱七八糟,还容易出现大量冗余数据。
2、分类
关系型数据库设计范式有六种,重点是前四种(1NF、2NF、3NF、BCNF)
- 第一范式(1NF)
- 第二范式(2NF)
- 第三范式(3NF)
- 巴斯-科德范式(BCNF)
- 第四范式(4NF)
- 第五范式(5NF,又称完美范式)
他们之间的关系是逐层包含关系,例如2NF满足则1NF一定满足,2NF是以1NF为基础
BCNF看作是第三范式的补充,因此并不被称为第四范式,有些地方将此称为第四范式,实际上有些不够严谨
3、名词解释
数据库范式的定义中存在不少关于关系模型与函数依赖的名词,如果不理解这些名词,将很难看懂范式的定义,也难以更深刻的去把握这些范式
3.1、关系模型
3.1.1、码
定义:如果在一个关系中存在唯一标识一个实体的一个属性或属性集称为实体的键,即使得在该关系的任何一个关系状态中的两个元组,在该属性上的值的组合都不同
通俗理解:某个属性或属性集合,可以唯一标识一个元组,例如学号可以唯一标识姓名,一个学号对应一个学生
3.1.2、元组
定义:在二维表中的一行,称为一个元组
3.1.3、域(值域)
定义:属性值的取值范围为值域
3.1.4、属性
定义:表中的列名称为属性,属性的个数称为关系的元或度。列的值称为属性值
3.1.5、候选码(候选键)
定义:若关系中的某一属性的值能唯一标识一个元组,如果在关系的一个键中不能移去任何一个属性,否则它就不是这个关系的键,则称这个被指定的候选键为该关系的候选键或者候选码
通俗理解:即这个属性或属性集合必须是个码,且这个码去除其中任一属性都无法再称为码的码称为候选码
与码的关系:算是码的子集,比如{a,b,c,d}中,{a}是码,则{a,b}也可作为码,因为起唯一标识作用的是a,但是{a,b}不是候选码,因为去除b,a依然可以作为码,即码可以是非码与码的组合,而候选码必须是单一属性的码,或着无法分开的多个属性聚合的码
3.2、函数依赖
3.3.1、函数依赖
设X,Y是关系R的两个属性集合,当任何时刻R中的任意两个元组中的X属性值相同时,则它们的Y属性值也相同,则称X函数决定Y,或Y函数依赖于X,类比y=f(x)
记法:
例如:姓名依赖于学号,由于姓名存在重名可能,一个姓名对应多个学号,不满足任意姓名相同,则学号也相同的定义,所以学号不依赖姓名
3.3.2、完全函数依赖
设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X
3.3.3、部分函数依赖
设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X
3.3.4、传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X
4、数据库范式
4.1、1NF
保持属性的原子性
每个属性应该都是不可再分的
例如:

是符合1NF的
而

不符合1NF
显然,如今的大部分数据库的表创建时都不允许你创建成后者,因此1NF都是满足的
4.2、2NF
在1NF的基础上,非码属性必须完全依赖于候选码(在1NF基础上消除非主属性对主码的部分函数依赖)
通俗解释:必须有一个主键,这个主键是唯一的,不会存在相同主键,这个主键可以且必须唯一标识一个实体,以区分表中每个实体。不能存在主键只能标识部分实体的情况
属性中必须存在一个能区分每个实体的字段或字段集合,而这个字段或从字段集合中选取一个字段将被作为主键,也就可以理解为此处的候选码,2NF要求主键必须能对应且唯一对应一个实体
主键未必只能有一个字段,也可以多个字段组合成一个主键,来标识唯一一个实体,但是大多数情况且也推荐使用一个字段来作为主键,这样更方便且直观
4.3、3NF
在2NF的基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)
通俗解释:一个表只描述一个事物
例如员工信息表{ID、姓名、部门编号}和部门信息表{部门编号、部门名称},员工信息表中不应有部门名称
4.4、BCNF
在3NF基础上,任何非主属性不能对主键子集依赖(在3NF基础上消除对主码子集的依赖)
未完待续……




