关系数据库中的关系满足一定要求的，满足不同程度要求的为不同的范式。满足最低要求的叫第一范式，简称1NF；在第一范式的基础上满足进一步要求的称为第二范式，简称2NF，其余范式以此类推。对于各种范式之间有如下关系：
如下图所示：
1. 第一范式 1NF
定义： 属于第一范式关系的所有属性都不可再分，即数据项不可分。
理解： 第一范式强调数据表的原子性，是其他范式的基础。如下图所示数据库就不符合第一范式：
上表将商品这一数据项又划分为名称和数量两个数据项，故不符合第一范式关系。改正之后如下图所示：
上表就符合第一范式关系。
但日常生活中仅用第一范式来规范表格是远远不够的，依然会存在数据冗余过大、删除异常、插入异常、修改异常的问题，此时就需要引入规范化概念，将其转化为更标准化的表格，减少数据依赖。
规范化： 一个低一级的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合，这个过程叫做规范化。
2. 第二范式 2NF
定义： 若某关系R属于第一范式，且每一个非主属性完全函数依赖于任何一个候选码，则关系R属于第二范式。
此处我们需要理解非主属性、候选码和完全函数依赖的概念。
候选码： 若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码。若一个关系中有多个候选码，则选定其中一个为主码。
以下所有内容中，主码或候选码都简称为码。
例如下图所示的学生表中，学号和姓名都可以唯一标识一个元组，故该表的候选码为学号和姓名，主码我们可以随便选定其中一个，则选学号为主码。
学号
姓名
年龄
性别
101
刘晨
19
女
102
王琪
21
男
103
张宇
20
男
104
李琛
19
女
105
欧阳慧
20
女
主属性： 所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。
在上面的学生表中，学号和姓名就是该关系的主属性，年龄和性别就是非主属性。
函数依赖： 设R(U)是属性集U上的关系模式，X、Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称Y函数依赖于X或X函数确定Y。
完全函数依赖： 设R(U)是属性集U上的关系模式，X、Y是U的子集。如果Y函数依赖于X，且对于X的任何一个真子集X’，都有Y不函数依赖于X’，则称Y对X完全函数依赖。记作：如果Y函数依赖于X，但Y不完全函数依赖于X，则称Y对X部分函数依赖。
理解： 第二范式是指每个表必须有一个(有且仅有一个)数据项作为关键字或主键(primary key)，其他数据项与关键字或者主键一一对应，即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。
判断一个关系是否属于第二范式：找出数据表中的所有码；
找出所有主属性和非主属性；
判断所有的非主属性对码的部分函数依赖。
以上面的学生表为例，表中的码为学号(码可以为学号或者姓名，此处假定码为学号)，非主属性为性别、年龄(其余都为主属性)，当学号确定时，性别、年龄也都惟一的被确定为，故学生表的设计满足第二范式(学生表为单主属性的关系)。
下面举一个不满足第二范式的关系。
有关系模式S-L-C(Sno, Sdept, Sloc, Cno, Grade)，其中Sno, Sdept, Sloc, Cno, Grade依次表示学生的学号、所在的系、住处、课程号、班级，并且每个系的学生住在同一个地方。可知S-L-C的码为(Sno, Cno)，则存在以下函数依赖：
可以看到，非主属性Sloc、Sdept并不完全函数依赖于码，因此关系模式S-L-C(Sno, Sdept, Sloc, Cno, Grade)不符合第二范式。
3. 第三范式 3NF
定义： 非主属性既不传递依赖于码，也不部分依赖于码。
首先我们要理解传递函数依赖的概念。
理解： 第三范式要求在满足第二范式的基础上，任何非主属性不依赖于其他非主属性，即在第二范式的基础上，消除了传递依赖。
在下图S-L关系中，Sloc对Sno传递函数依赖，故该关系不属于第三范式。
4. BC范式 BCFN
定义： 关系模式R中，若每一个决定因素都包含码，则R属于BCFN。
理解： 根据定义我们可以得到结论，一个满足BC范式的关系模式有：所有非主属性对每一个码都是完全函数依赖；
所有主属性对每一个不包含它的码也是完全函数依赖；
没有任何属性完全函数依赖于非码的任何一组属性。
例如有关系模式C(Cno, Cname, Pcno)，Cno, Cname, Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno，且没有任何属性对Cno部分函数依赖或传递函数依赖，所以关系C属于第三范式，同时Cno是C中的唯一决定因素，所以C也属于BC范式。
5. 第四范式 4NF
定义： 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
理解： 显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时(3NF)，这些非主属性不应该有多值，若有多值就违反了4NF。
6. 第五范式 5NF
第五范式有以下要求：
(1)必须满足第四范式；
(2)表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。

1. 第一范式(1NF)(针对具体某一列)
所谓第一范式(1NF)是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
例：下面这个表中张三其实是一个人，如果在一个java程序中应该是一个实体类，但是在数据库中记录成两条记录，因为tel列中包含了手机和宅电两个属性
id
name
tel
1
张三
18656565656
2
张三
36522323
正确的方式是下面这样
id
name
tel
phone
1
张三
36522323
18656565656
2.第二范式( 2NF )(针对某一列与复合主键的一部分有关)
所谓第二范式，是指所有的非主属性都完全依赖于关键字。从这个定义可以看出，第二范式不存在非主属性对于部分候选关键字的部分依赖，不过允许非主属性之间存在着传递依赖。
例：
假定选课关系表为SelectCourse(学号，姓名，年龄，课程名称,成绩，学分)，关键字为组合关键字(学号，课程名称)，因为存在如下决定关系：
stuId
name
age
kemu
score
xuefen
1
张三
16
数学
89
100
2
张三
16
语言
90
100
age、name是由stuId决定的，与kemu无关;
xuefen是由kemu决定的,与stuId无关；
score是由stuId和kumu共决定的；
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号,姓名，年龄)；
课程：Course(课程名称，学分)；
选课关系：SelectCourse(学号，课程名称，成绩)。
这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
3、第三范式(3NF)(针对某一列与主键无关，但是与某一非主键列有关)
所谓第三范式，是指每一个非主属性既不部分依赖于也不传递依赖于关键字，也就是在第二范式的基础上消除传递依赖(A＞B＞C)。
假定学生关系表为Student(学号，姓名，年龄，所在学院,学院地点，学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名，年龄，所在学院，学院地点，学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点，学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号，姓名,年龄，所在学院)；
学院：(学院，地点，电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
4、BCNF(针对某一列与复合主键中的某一列有关，而与其他主键无关)
所谓BCNF，是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。BCNF需要符合3NF，并且，主属性不依赖于主属性。
假设仓库管理关系表为StorehouseManage(仓库ID,存储物品ID,管理员ID,数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID,存储物品ID) →(管理员ID,数量)
(管理员ID,存储物品ID) → (仓库ID,数量)
所以，(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID,管理员ID)；
仓库：Storehouse(仓库ID,存储物品ID,数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
又如，有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号，PNO表示配件号，ENO表示职工号，QNT表示数量。
有以下约束要求：
(1)一个仓库有多名职工；
(2)一个职工仅在一个仓库工作；
(3)每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件；
(4)同一种型号的配件可以分放在几个仓库中。
分析表中的函数依赖关系，可以得到：
(1)ENO->WNO;
(2)(WNO，PNO)->QNT
(3)(WNO，PNO)->ENO
(4)(ENO，PNO)->QNT
可以看到，候选键有：(ENO,PNO);(WNO,PNO)。所以，ENO,PNO,WNO均为主属性，QNT为非主属性。显然，非主属性是直接依赖于候选键的。所以此表满足第三范式。
而我们观察一下主属性：(WNO,PNO)->ENO;ENO->WNO。显然WNO对于候选键(WNO,PNO)存在传递依赖，所以不符合BCNF.
解决这个问题的办法是分拆为两个表：管理表EP(ENO，PNO，QNT)；工作表EW(ENO，WNO)。但这样做会导致函数依赖(WNO,PNO)->ENO丢失。
虽然，不满足BCNF，也会导致一些冗余和一致性的问题。但是，将表分解成满足BCNF的表又可能丢失一些函数依赖。所以，一般情况下不会强制要求关系表要满足BCNF。
5、4NF(第四范式)
对于第四范式，从理论层面来讲是，关系模式R∈1NF,如果对于R对于R的每个非平凡多值依赖X→→Y(Y不属于X),X都含有候选码，则R∈4NF。4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。显然一个关系模式是4NF，则必为BCNF。
也就是说，当一个表中的非主属性互相独立时(3NF)，这些非主属性不应该有多值。若有多值就违反了第四范式。
有这样一个用户联系方式表TELEPHONE(CUSTOMERID,PHONE,CELL)。CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。
本来，这是一个非常简单的第3范式表。主键为CUSTOMERID，不存在传递依赖。但在某些情况下，这样的表还是不合理的。比如说，用户有两个固定电话，两个移动电话。这时，表的具体表示如下：
CUSTOMERID PHONE CELL
1000 8828-1234 149088888888
1000 8838-1234 149099999999
由于PHONE和CELL是互相独立的，而有些用户又有两个和多个值。这时此表就违反第四范式。
在这种情况下，此表的设计就会带来很多维护上的麻烦。例如，如果用户放弃第一行的固定电话和第二行的移动电话，那么这两行会合并吗？等等
解决问题的方法为，设计一个新表NEW_PHONE(CUSTOMERID,NUMBER,TYPE).这样就可以对每个用户处理不同类型的多个电话号码，而不会违反第四范式。
显然，第四范式的应用范围比较小，因为只有在某些特殊情况下，要考虑将表规范到第四范式。所以在实际应用中，一般不要求表满足第四范式。
6、5NF(第五范式)
第五范式(5NF)：是最终范式。消除了4NF中的连接依赖。
第五范式有以下要求：
(1)必须满足第四范式
(2)表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。
有一个销售信息表SALES(SALEPERSON，VENDOR，PRODUCT)。SALEPERSON代表销售人员，VENDOR代表供和商，PRODUCT则代表产品。
在某些情况下，这个表中会产生一些冗余。可以将表分解为PERSON_VENDOR表(SALEPERSON，VENDOR)；PERSON_PRODUCT表(SALEPERSON，PRODUCT)；VENDOR­_PRODICT表(VENDOR，PRODUCT)

范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF)，其余范式以次类推。一般说来，数据库只需满足第三范式(3NF)就行了。
第一范式(1NF)无重复的列 　　所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。
说明：在任何一个关系数据库中，第一范式(1NF)是对关系模式的基本要求，不满足第一范式(1NF)的数据库就不是关系数据库。
第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖]
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
例如员工信息表中加上了员工编号(emp_id)列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。
第三范式(3NF)属性不依赖于其它非主属性[消除传递依赖]
满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之，第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。
那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式(3NF)也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
范式的说明
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解
通俗的理解是字段还可以再分吗？如过不能，则是符合1NF的设计。
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
简单的解释，比如你和一个女生约会建立一张表，不用每条约会记录都记录她的身高、体重，将身高体重单独的存在一张表中供查询即可。
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
打个比方，比如评论表，如果你将用户ID，用户头像都放在这留言表中，就是不合适的了。用户头像是依赖于用户ID，而不依赖该评论。

关系数据库中的关系满足一定要求的，满足不同程度要求的为不同的范式。满足最低要求的叫第一范式，简称1NF；在第一范式的基础上满足进一步要求的称为第二范式，简称2NF，其余范式以此类推。对于各种范式之间有如下关系：
如下图所示：
1. 第一范式 1NF
定义：属于第一范式关系的所有属性都不可再分，即数据项不可分。
理解：
第一范式强调数据表的原子性，是其他范式的基础。如下图所示数据库就不符合第一范式：
上表将商品这一数据项又划分为名称和数量两个数据项，故不符合第一范式关系。改正之后如下图所示：
上表就符合第一范式关系。
但日常生活中仅用第一范式来规范表格是远远不够的，依然会存在数据冗余过大、删除异常、插入异常、修改异常的问题，此时就需要引入规范化概念，将其转化为更标准化的表格，减少数据依赖。
规范化：一个低一级的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合，这个过程叫做规范化。
2. 第二范式 2NF
定义：若某关系R属于第一范式，且每一个非主属性完全函数依赖于任何一个候选码，则关系R属于第二范式。
此处我们需要理解非主属性、候选码和完全函数依赖的概念。
候选码：若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码。若一个关系中有多个候选码，则选定其中一个为主码。
以下所有内容中，主码或候选码都简称为码。
例如下图所示的学生表中，学号和姓名都可以唯一标识一个元组，故该表的候选码为学号和姓名，主码我们可以随便选定其中一个，则选学号为主码。
主属性：所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。
在上面的学生表中，学号和姓名就是该关系的主属性，年龄和性别就是非主属性。
函数依赖：设R(U)是属性集U上的关系模式，X、Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称Y函数依赖于X或X函数确定Y。
完全函数依赖：
设R(U)是属性集U上的关系模式，X、Y是U的子集。如果Y函数依赖于X，且对于X的任何一个真子集X’，都有Y不函数依赖于X’，则称Y对X完全函数依赖。记作：如果Y函数依赖于X，但Y不完全函数依赖于X，则称Y对X部分函数依赖。
理解：第二范式是指每个表必须有一个(有且仅有一个)数据项作为关键字或主键(primary key)，其他数据项与关键字或者主键一一对应，即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。
判断一个关系是否属于第二范式：
找出数据表中的所有码；找出所有主属性和非主属性；判断所有的非主属性对码的部分函数依赖。以上面的学生表为例，表中的码为学号(码可以为学号或者姓名，此处假定码为学号)，非主属性为性别、年龄(其余都为主属性)，当学号确定时，性别、年龄也都惟一的被确定为，故学生表的设计满足第二范式(学生表为单主属性的关系)。
下面举一个不满足第二范式的关系。
有关系模式S-L-C(Sno,Sdept,Sloc,Cno,Grade)，其中Sno,Sdept,Sloc,Cno,Grade依次表示学生的学号、所在的系、住处、课程号、班级，并且每个系的学生住在同一个地方。可知S-L-C的码为(Sno,Cno)，则存在以下函数依赖：
可以看到，非主属性Sloc、Sdept并不完全函数依赖于码，因此关系模式S-L-C(Sno,Sdept,Sloc,Cno,Grade)不符合第二范式。
3. 第三范式 3NF
定义：非主属性既不传递依赖于码，也不部分依赖于码。
首先我们要理解传递函数依赖的概念。
第三范式要求在满足第二范式的基础上，任何非主属性不依赖于其他非主属性，即在第二范式的基础上，消除了传递依赖。
在下图S-L关系中，Sloc对Sno传递函数依赖，故该关系不属于第三范式。
4. BC范式 BCFN
定义：关系模式R中，若每一个决定因素都包含码，则R属于BCFN。
理解：根据定义我们可以得到结论，一个满足BC范式的关系模式有：
所有非主属性对每一个码都是完全函数依赖；所有主属性对每一个不包含它的码也是完全函数依赖；没有任何属性完全函数依赖于非码的任何一组属性。例如有关系模式C(Cno, Cname, Pcno)，Cno, Cname, Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno，且没有任何属性对Cno部分函数依赖或传递函数依赖，所以关系C属于第三范式，同时Cno是C中的唯一决定因素，所以C也属于BC范式。
5. 第四范式 4NF
定义：限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
理解：显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时(3NF)，这些非主属性不应该有多值，若有多值就违反了4NF。
6. 第五范式 5NF
第五范式有以下要求：(1)必须满足第四范式；(2)表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。