关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有1NF,2NF,3NF,BCNF,4NF,5NF，通常到4NF为止，其中1NF的级别最低。这几种范式之间，5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF成立。通过分解，可以将一个低一级范式的关系模式转化成若干个高一级范式的关系模式，这个过程为规范化。下面我们来看一个栗子（好吃），有错误的地方希望读者可以提出改正。
1NF 第一范式
定义：若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式
第一范式有四个缺点：（1）冗余度大（2）引起数据修改不一致（3）插入异常（4）删除异常 此处对该四个缺点不进行详细描述
第一范式简单来说，每隔属性都是不能分割的原子项，在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
例如：userInfo：山东省烟台市 131777368781
userAds：山东省烟台市
userTel：131777368781
2NF 第二范式
定义：若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF
满足1NF后，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情；
例如：订单表只描述订单相关的信息，所以所有字段都必须与订单id相关 ；产品表只描述产品相关的信息，所以所有字段都必须与产品id相 关；因此不能在一张表中同时出现订单信息与产品信息；如下图所示：
3NF 第三范式
定义：若关系模式R(U,F)中若不存在这样的码X，属性组Y及非主属性Z（Z￠Y）使用X->Y(Y-/->X)，Y->Z成立，则关系模式R∈3NF。
即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。
必须先满足第二范式（2NF），要求：表中的每一列只与主键直接相关而不是间接相关，（表中的每一列只能依赖于主键）；
例如：订单表中需要有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户id即可，而不能有其他的客户信息。因为其他的客户信息直接关联于用户id，而不是直接与订单id直接相关。
BC范式
定义：若关系模式R∈1NF，若X->Y，且Y属于X，X必含有码，则关系模式R∈BCNF。
换句话说，所有的非主码属性都需要消除传递函数依赖，包括候选码，则称为BC范式
完全依赖、部分依赖、传递依赖
部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
举个例子：学生基本信息表R中（学号，身份证号，姓名）当然学号属性取值是唯一的，在R关系中，（学号，身份证号）->（姓名），（学号）->（姓名），（身份证号）->（姓名）；所以姓名部分函数依赖与（学号，身份证号）；
完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
例子：学生基本信息表R（学号，班级，姓名）假设不同的班级学号有相同的，班级内学号不能相同，在R关系中，（学号，班级）->（姓名），但是（学号）->(姓名)不成立，（班级）->(姓名)不成立，所以姓名完全函数依赖与（学号，班级）；
传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
例子：在关系R(学号 ,宿舍, 费用)中，(学号)->(宿舍),宿舍！=学号，(宿舍)->(费用),费用!=宿舍，所以符合传递函数的要求；