数据库三范式
范式
关系模型R(U,F)
,U
为属性,F
为属性U上的一组数据依赖。
关系数据库的关系是要满足一定要求的,满足不同程度要求的为不同范式。
第一范式 (1NF)
定义:如果关系模式 R 的每个关系 r 的属性都是不可分的数据项,那么就称 R 是第一范式的模式。
简单的说,每一个属性都是原子项,不可分割。1NF 是关系模式应具备的最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库。关系数据库设计研究的关系规范化是在 1NF 之上进行的。例如 (学生信息表):
学生编号 | 姓名 | 性别 | 联系方式 |
---|---|---|---|
20080901 | 张三 | 男 | email:zs@126.com,phone:88886666 |
20080902 | 李四 | 女 | email:ls@126.com,phone:66668888 |
以上的表就不符合,第一范式:联系方式字段可以再分,所以变更为正确的是:
学生编号 | 姓名 | 性别 | 电子邮件 | 电话 |
---|---|---|---|---|
20080901 | 张三 | 男 | zs@126.com | 88886666 |
20080902 | 李四 | 女 | ls@126.com | 66668888 |
第二范式(2NF)
定义:如果关系模式 R 是 1NF,且每个非主属性完全函数依赖于候选键,那么就称 R 是第二范式。
简单的说,第二范式要满足以下的条件:首先要满足第一范式,其次每个非主属性要完全函数依赖与候选键,或者是主键。也就是说,每个非主属性是由整个主键函数决定的,而不能由主键的一部分来决定。
例如 (学生选课表):
学生 | 课程 | 教师 | 教师职称 | 教材 | 教室 | 上课时间 |
---|---|---|---|---|---|---|
李四 | Spring | 张老师 | java 讲师 | 《Spring 深入浅出》 | 301 | 08:00 |
张三 | Struts | 杨老师 | java 讲师 | 《Struts in Action》 | 302 | 13:30 |
这里通过(学生,课程)可以确定教师、教师职称,教材,教室和上课时间,所以可以把(学生,课程)作为主键。但是,教材并不完全依赖于(学生,课程),只拿出课程就可以确定教材,因为一个课程,一定指定了某个教材。这就叫不完全依赖,或者部分依赖。出现这种情况,就不满足第二范式。
修改后,
选课表:
学生 | 课程 | 教师 | 教师职称 | 教室 | 上课时间 |
---|---|---|---|---|---|
李四 | Spring | 张老师 | java 讲师 | 301 | 08:00 |
张三 | Struts | 杨老师 | java 讲师 | 302 | 13:30 |
课程表:
课程 | 教材 |
---|---|
Spring | 《Spring 深入浅出》 |
Struts | 《Struts in Action》 |
所以,第二范式可以说是消除部分依赖。第二范式可以减少插入异常,删除异常和修改异常。
第三范式(3NF)
定义:如果关系模式 R 是 2NF,且关系模式 R(U,F)中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系 R 是属于第三范式。
简单的说,第三范式要满足以下的条件:首先要满足第二范式,其次非主属性之间不存在函数依赖。由于满足了第二范式,表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖,就会存在传递依赖,这样就不满足第三范式。
上例中修改后的选课表中,一个教师能确定一个教师职称。这样,教师依赖于(学生,课程),而教师职称又依赖于教师,这叫传递依赖。第三范式就是要消除传递依赖。
修改后,
选课表:
学生 | 课程 | 教师 | 教室 | 上课时间 |
---|---|---|---|---|
李四 | Spring | 张老师 | 301 | 08:00 |
张三 | Struts | 杨老师 | 302 | 13:30 |
教师表:
教师 | 教师职称 |
---|---|
张老师 | java 讲师 |
杨老师 | java 讲师 |
这样,新教师的职称在没被选课的时候也有地方存了,没人选这个教师的课的时候教师的职称也不至于被删除,修改教师职称时只修改教师表就可以了。
简单的说,
第一范式就是原子性,字段不可再分割;
第二范式就是完全依赖,没有部分依赖;
第三范式就是没有传递依赖。