1.第一范式：存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B。如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的。
那么符合第一模式的特点就有：有主关键字、主键不能为空、主键不能重复,、字段不可以再分。例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.net,phone:222456
20040901 mary famale email:kkk@fff.net phone:123455
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是：
StudyNo | Name | Sex | Email | Phone
20040901 john Male kkkk@ee.net 222456
20040902 mary famale kkk@fff.net 123455
2.第二范式：存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C。如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。所以第二范式的主要任务就是：满足第一范式的前提下，消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male kkkk@ee.net 222456 200401 A楼2
01 mary famale kkk@fff.net 123455 200402 A楼3
这个表完全满足于第一范式,主键由StudyNo和ClassNo组成，这样才能定位到指定行。但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress，所以要变为两个表：
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male kkkk@ee.net 222456 200401
01 mary famale kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
3.第三范式
不存在非主属性对码的传递性依赖以及部分性依赖 ，
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male kkkk@ee.net 优秀 $1000
20040902 mary famale kkk@fff.net 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖，更改为：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male kkkk@ee.net 1
20040902 mary famale kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里可以用bounsNo作为主键，基于两个原因
（1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？
（2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
扩展资料：
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
参考链接：
百度百科-数据库范式
欢迎分享，转载请注明来源：民族网
