第一第二第三范式的区别于联系

第一第二第三范式的区别于联系 关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设计出错误的数据库. 目前，主要有六种范式:第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。 范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦，但是操作困难，因为需要联系多个才能得到所需要数据，而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的，一般在项目中，用得最多的也就是第三范式，我认为使用到第三范式也就足够了，性能好而且方便管理数据。 函数依赖,如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。 第一范式(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深入浅出》 ,,, 08:00 张三 Struts 杨老师 java讲师 《Struts in Action》 ,,, 13:30 这里通过(学生，课程)可以确定教师、教师职称，教材，教室和上课时间，所以可以把(学生，课程)作为主键。但是，教材并不完全依赖于(学生，课程)，只拿出课程就可以确定教材，因为一个课程，一定指定了某个教材。这就叫不完全依赖，或者部分依赖。出现这种情况，就不满足第二范式。 修改后，选课表: 学生 课程 教师 教师职称 教室 上课时间 李四 Spring 张老师 java讲师 ,,, 08:00 张三 Struts 杨老师 java讲师 ,,, 13:30 课程表: 课程 教材 Spring 《Spring深入浅出》 Struts 《Struts in Action》 所以，第二范式可以说是消除部分依赖。第二范式可以减少插入异常，删除异常和修改异常。 第三范式(3NF) 定义:如果关系模式R是2NF，且关系模式R(U，F)中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。 简单的说，第三范式要满足以下的条件:首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。 上例中修改后的选课表中，一个教师能确定一个教师职称。这样，教师依赖于(学生，课程)，而教师职称又依赖于教师，这叫传递依赖。第三范式就是要消除传递依赖。 修改后，选课表: 学生 课程 教师 教室 上课时间 李四 Spring 张老师 ,,, 08:00 张三 Struts 杨老师 ,,, 13:30 教师表: 教师 教师职称 张老师 java讲师 杨老师 java讲师 这样，新教师的职称在没被选课的时候也有地方存了，没人选这个教师的课的时候教师的职称也不至于被删除，修改教师职称时只修改教师表就可以了。 简单的说， 第一范式就是原子性，字段不可再分割; 第二范式就是完全依赖，没有部分依赖; 第三范式就是没有传递依赖。