数据库范式

1. 数据库范式概念

数据库规范化，又称正规化、标准化，是数据库设计的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念，并于1970年代初定义了第一范式、第二范式和第三范式的概念，还与Raymond F. Boyce于1974年共同定义了第三范式的改进范式——BC范式。
除外还包括针对多值依赖的第四范式，连接依赖的第五范式、DK范式和第六范式。
现在数据库设计最多满足3NF，普遍认为范式过高，虽然具有对数据关系更好的约束性，但也导致数据关系表增加而令数据库IO更易繁忙，原来交由数据库处理的关系约束现更多在数据库使用程序中完成。
目前，主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。

2. 范式的作用

• 避免信息重复
• 避免更新异常
• 避免插入异常，防止无法正常显示信息
• 避免删除异常，防止丢失有效信息

3. 三大范式

1. 第一范式
   原子性：保证每一列不可再分

• 例子：
  例如(学生信息表)：

学生编号　　姓名　　性别　　联系方式
20080901　　王二　　男　　　email:we@163.com,phone:88886666
20080902　　李甜　　女　　　email:ls@263.com,phone:66668888

以上的表就不符合，第一范式：联系方式字段可以再分，所以变更为正确的是：

学生编号　　姓名　　性别　　		联系方式             手机号
20080901　　王二　　男　　　we@163.com    88886666
20080902　　李甜　　女　　　ls@263.com      66668888

2. 第二范式
   • 前提：满足第一范式
   • 每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。
   • 每张表只描述一件事，所以，第二范式可以说是消除部分依赖。第二范式可以减少插入异常，删除异常和修改异常。

• 例子

学生　　　　课程　　　教师　　　　教师职称　　     教材　　　　　　　　　 教室　　  上课时间
李四　　　　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》

3. 第三范式
   • 前提：满足第一范式和第二范式
   • 第三范式要确保数据表中每一列数据都和主键直接相关，而不能间接相关
   • 非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。

• 例子
  上例中修改后的选课表中，一个教师能确定一个教师职称。这样，教师依赖于（学生，课程），而教师职称又依赖于教师，这叫传递依赖。第三范式就是要消除传递依赖。

修改后，选课表：

学生　　　　课程　　　教师　　　　教室　　上课时间
李四　　　　Spring　　张老师　　　３０１　08:00
张三　　　　Struts　　杨老师　　　３０２　13:30
教师表：
教师　　　　教师职称
张老师　　　java讲师
杨老师　　　java讲师

数据库表修改后，新教师的职称在没被选课的时候也有地方存了，没人选这个教师的课的时候教师的职称也不至于被删除，修改教师职称时只修改教师表就可以了。

总结：
第一范式就是原子性，字段不可再分割；
第二范式就是完全依赖，没有部分依赖；
第三范式就是没有传递依赖。