第一范式(1NF):关系中的所有分量不可再分,即数据库表中的字段都是单一属性的,不可再分。
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系型数据库。
例如,这样是符合的:Student(id,name,age,class)
而这样就不符合:Student(id,(first name, last name),age,class)
第二范式(2NF):如果关系模式R属于1NF,且每一个非主属性都完全依赖于主码,则称关系R是属于第二范式的,记作R属于2NF。
第二范式是在第一范式的基础上建立的。
例如,
假定选修课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:
(学号,课程名称)->(姓名,年龄,成绩,学分)
这个数据库表不满足第二范式,因为存在如下决定关系:
(课程名称)->(学分)
(学号)->(姓名,年龄)
即存在学分和姓名,年龄部分依赖于主关键字。
修改,我们将设计修改了一下,把选课关系表SelectCourse改为如下三个表:
学生:Student(学号,姓名,年龄)
课程:Course(课程名称,学分)
选课关系:SelectCourse(学号,课程名称,成绩)
注意:所有的单关键字的数据库表都符合第二范式,因为不可能存在组合关键字,也就不可能存在非主属性部分依赖于主关键字了。
第三范式(3NF):关系中非主属性必须直接依赖于主码,而不能通过其他非主属性传递依赖于主码。
传递依赖,如:A依赖于B,B依赖于C,那么,A传递依赖于C。
假定学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话),关键字为单一的学号,所以肯定符合第二范式,但是因为存在非关键字学院地点和学院电话依赖于所在学院,即传递依赖于学号,所以此关系表不符合第三范式。同样会导致数据冗余,DDL操作异常等问题。
所以我们可以对其进行修改:
学生:(学号,姓名,年龄,所在学院)
学院:(学院,地点,电话)
这样的数据库表就符合第三范式了。
在关系数据库中,除了函数依赖之外还有多值依赖,联接依赖的问题,从而提出了第四范式,第五范式等更高一级的规范化要求。
规范化过程: