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）就行了。
参考链接：
百度百科-数据库范式
第一范式定义是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
第二范式定义是属性完全依赖于主键，要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
第三范式定义是要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
第一范式第二范式第三范式的要求
第一范式要求消除拆分字段至原子字段，即不可再拆分；第二范式要求消除部分函数依赖，实现完全函数依赖；第三范式要求消除传递函数依赖。
每个属性不可再分。相近或一样的属性要尽量合并在一起确保不会产生冗余数据。是对关系模型的基本要求，不满足第一范式的关系，不能称之为关系型数据库。符合第一范式的关系，每个属性都不可以再分割。
第一范式(1NF)(必须有主键,列不可分)
数据库表中的任何字段都是单一属性的,不可再分
create table aa(id int,NameAge varchar(100))
insert aa values(1,''无限-女'')
没有达到第一范式
create table aa(id int,name varcahr(10),age char(2))
insert aa values(1,''无限'',''女'')
达到第一范式
第二范式(2NF)
数据库表中非关键字段对任一候选关键字段的 都不存在部分函数依赖
(当一个表是复合主键时,非主键的字段不依赖于部分主键(即必须依赖于全部的主键字段))
create table sci(
sno int(32),cno int(32),grade int(32),credit int(32),
primary key sno,cno
)
课程(cno)1---1学分(credit)
学生(sno)n---n课程(cno)
学生+课程--->分数(grade)
sci
sno cno grade credit
1 1 60 80
2 1 90 80
3 1 70 80
....
....
....
如此以来,学分被大量重复存储,数据冗余
如要某课程学分,则要大量重复 *** 作
如要加新课程,由于sno和cno共同做为主键,则在加入新课程时,必须有人选该课
如某学生某课程结业,则该学生其它课程信息也同时被删除了
总之
这种设计不太好吧,非关键字属性credit仅函数依赖于cno,也就是credit部分依赖组合关键字（sno,cno）而不是完全依赖
解决
分成两个关系模式 sc1（sno,cno,grade）,c2（cno,credit）.新关系包括两个关系模式,它们之间通过sc1中的外关键字cno相联系,需要时再进行自然联接,恢复了原来的关系
第三范式(3NF)
关系模式R（U,F）中的所有非主属性对任何候选关键字都不存在传递依赖
例----S1（SNO,SNAME,DNO,DNAME,LOCATION)
学号 姓名 所在系 系名称 系地址
关键字SNO决定各个属性.由于是单个关键字,没有部分依赖的问题,肯定是2NF.但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况.
原因:关系中存在传递依赖造成的.即SNO 1->1 DNO.而DNO 1->n SNO却不存在,而DNO ->LOCATION存在,因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO ->LOCATION 实现的.也就是说,SNO不直接决定非主属性LOCATION.
解决目地：每个关系模式中不能留有传递依赖.
解决方法：分为两个关系 S（SNO,SNAME,DNO）,D（DNO,DNAME,LOCATION）
注意：关系S中不能没有外关键字DNO.否则两个关系之间失去联系
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）