候选键由主键和备用键组成。
超键 >= 候选键 >= 主键
这篇文章讲得非常细致(https://www.cnblogs.com/langdashu/p/5924082.html)
第一范式（1NF）：每个属性类型都是原子单值，则关系为第一范式。
第二范式（2NF）：在上一条基础上排除部分函数依赖，即每个非主属性类型完全依赖于关系的键，则关系为第二范式。
例：R1（SSN，Pnumber，Pname，hours）
函数依赖：Pnumber->Pname,(SSN,Pnumber)->hours
键：（SSN，Pnumber）
主属性:SSN,Pnumber
非主属性：Pname，hours
Pname对于键（SSN，Pnumber）是部分依赖，所以不是第二范式，改为：
R11（SSN，Pnumber，hours）
R12（SSN，Pname）
在上一条基础上排除传递函数依赖，即每个非主属性类型只依赖键，不依赖其他非主属性，则关系为第三范式。
例：R1（SSN，ename，dnumber，dname，dmgrssn）
一个员工在一个部门，一个部门有多个员工，一个部门有一个经理。
函数依赖：SSN->ename,SSN->dnumber,dnumber->dname,dnumber->dmgrssn
键：SSN，dnumber
主属性：SSN，dnumber
非主属性：ename,dname,dmgrssn
因为SSN可推出dnumber，dnumber可推出dname和dmgrssn，存在传递函数依赖，不是第三范式，可改为：
R11（SSN，ename，dnumber）
R12（dnumber，dname，dmgress）
在上一条基础上每个非平凡函数依赖X->Y（X不包含Y），X是超键（即X是候选键或其一个超集），则关系为巴斯范式。通俗来说就是消除主属性对于键的部分与传递函数依赖。
例1：R1（SUPNR，SUPNAME，PRODNR，QUANTITY）
一个供应商可以供应多个产品，一个产品能由多个供应商供应且每个供应商有唯一的命名
函数依赖：supnr->supname，supname->supnr，(supnr，prodnr)->quantity
键：（supnr,prodnr）,(supname,prodnr)
主属性：supnr,supname,prodnr
非主属性：quantity
两种判断方法：
1.存在主属性supname对于键（supnr,prodnr）的部分函数依赖，所以不是BCNF
2.supnr->supname,supname->supnr左边不是键，所以不是BCNF
改为BCNF：
R11（SUPNR，PRODNR，QUANTITY）
R12（SUPNR，SUPNAME）
例2：STC（S,T,C）中，S表示学生，T表示教师，C表示课程。假设每个教师只教一门课，每门课有若干老师，某一学生选一门课就对应一个老师。
函数依赖：（S，C）->T，（S，T）-> C，T-> C
键：（S，C），（S，T）
主属性：S，C，T
两种判断方法：
1.主属性是：S，C，T，因为T就能推出C，还有（S,T）->C,有主属性对于键的部分函数依赖 ，所以不是BCNF。
2.或者（S，C）和（S，T）都是键，但T不是，所以STC属于第三范式，不属于BCNF。
在上一条基础上若存在平凡多值依赖（当每个X值精确地确定一组Y值时，存在从X到Y，X->->Y的多值依赖性，与其它属性类型无关），对于它的每个非平凡的多值依赖关系X->->Y，X是超键，则关系为第四范式。简单来说就是消除关系中的多对多关系。
例：R（course，instructor，textbook）
假如一个课程能由不同的老师授课，且有多种教材。该关系不是第四范式，改为：
R11（course，textbook）
R12（course，instructor）
由上到下越来越严格，下面的一定属于上面，反之不一定成立