数据库设计，一二范式理解

第一范式要求确保表中每列的原子性，也就是不可拆分；

第二范式要求确保表中每列与主键相关，而不能只与主键的某部分相关（主要针对联合主键），主键列与非主键列遵循完全函数依赖关系，也就是完全依赖；

第三范式确保主键列之间没有传递函数依赖关系，也就是消除传递依赖。

 

第一范式(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》

 

所以，第二范式可以说是消除部分依赖。第二范式可以减少插入异常，删除异常和修改异常。