第一范式:
1NF(第⼀范式) 属性(对应于表中的字段)不能再被分割,也就是这个字段只能是⼀个值,不能再分为多个其他的字 段了。1NF 是所有关系型数据库的最基本要求 ,也就是说关系型数据库中创建的表⼀定满⾜第⼀范式。
例子:
一个字段只能有一个值
修改后:
第二范式:
2NF(第⼆范式) 2NF 在 1NF 的基础之上,消除了⾮主属性对于码的部分函数依赖。如下图所示,展示了第⼀范式到 第⼆范式的过渡。第⼆范式在第⼀范式的基础上增加了⼀个列,这个列称为主键,⾮主属性都依赖于主键(也就相当于完全依赖而不是部分依赖)。
完全依赖例子:
这里有学生学号,课程号,学生考试分数,课程名称 4个
学生学号 | 课程号 | 学生考试分数 | 课程名称 |
1001 | 01 | 89.0 | 数学 |
学生学号和课程号共同组成联合组建
可以由 学生学号+课程号-->学生考试分数
但是课程名称只由 课程号-->课程名称
这里课程名称只是部分依赖关系
修改后:
学生学号 | 课程号 | 学生分数 |
1001 | 01 | 89.0 |
课程号 | 课程名称 |
01 | 数学 |
依赖:
函数依赖(functional dependency) :若在⼀张表中,在属性(或属性组)X 的值确定的情 况下,必定能确定属性 Y 的值,那么就可以说 Y 函数依赖于 X,写作 X → Y。
部分函数依赖(partial functional dependency) :如果 X→Y,并且存在 X 的⼀个真⼦集 X0,使得 X0→Y,则称 Y 对 X 部分函数依赖。⽐如学⽣基本信息表 R 中(学号,身份证号, 姓名)当然学号属性取值是唯⼀的,在 R 关系中,(学号,身份证号)->(姓名),(学号)- >(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);
完全函数依赖(Full functional dependency) :在⼀个关系中,若某个⾮主属性数据项依赖于全 部关键字称之为完全函数依赖。⽐如学⽣基本信息表 R(学号,班级,姓名)假设不同的班级学 号有相同的,班级内学号不能相同,在 R 关系中,(学号,班级)->(姓名),但是(学号)- >(姓名)不成⽴,(班级)->(姓名)不成⽴,所以姓名完全函数依赖与(学号,班级);
传递函数依赖 : 在关系模式 R(U)中,设 X,Y,Z 是 U 的不同的属性⼦集,如果 X 确定 Y、Y 确定 Z,且有 X 不包含 Y,Y 不确定 X,(X∪Y)∩Z=空集合,则称 Z 传递函数依赖(transitive functional dependency) 于 X。传递函数依赖会导致数据冗余和异常。传递函数依赖的 Y 和 Z ⼦ 集往往同属于某⼀个事物,因此可将其合并放到⼀个表中。⽐如在关系 R(学号 , 姓名, 系名,系 主任)中,学号 → 系名,系名 → 系主任,所以存在⾮主属性系主任对于学号的传递函数依赖。
第三范式:
3NF 在 2NF 的基础之上,消除了⾮主属性对于码的传递函数依赖 。符合 3NF 要求的数据库设计, 基本上解决了数据冗余过⼤,插⼊异常,修改异常,删除异常的问题。⽐如在关系 R(学号 , 姓名, 系名,系主任)中,学号 → 系名,系名 → 系主任,所以存在⾮主属性系主任对于学号的传递函数依 赖,所以该表的设计,不符合 3NF 的要求。
总结:
1NF:属性不可再分。
2NF:1NF 的基础之上,消除了⾮主属性对于码的部分函数依赖。
3NF:3NF 在 2NF 的基础之上,消除了⾮主属性对于码的传递函数依赖 。