首先要理解，什么是函数依赖、完全函数依赖、部分函数依赖、传递函数依赖、码、候选码、主码、全码、主属性、非主属性。
- 码(Key)：关系中的一个属性集合，其属性值可以唯一标识关系中的每个元组。
- 候选码(Candidate key)：若一个码的任意一个真子集都不为码时，称其为候选码。
- 或者换一个定义：设K为R(U)中的属性或属性组，若K完全函数确定U，则K为R的候选码。
- 主码：人为选择的某一个候选码。
- 全码：关系中所有属性构成的码。
- 主属性 (Prime Attribute)：出现在任意一个候选码中的属性。
- 非主属性：不出现在任何码中的属性。
码的值可以唯一确定一个元组，也即通过查询给出的值只能查询到一条信息。
所以只要表中不存在重复记录，码不会在关系中出现重复值。
接下来是正经的规范化定义：
- 1NF：每一个分量都是不可分的（最基本的规范化）。
- 2NF：若R∈1NF，且每个非主属性都完全函数依赖于R的码，那么R∈2NF。
- 3NF：若R∈2NF，且每个非主属性都不传递依赖于R的候选码，那么R∈3NF。
- BCNF：若R∈2NF，且每个属性都不传递依赖于R的候选码，那么R∈BCNF。
- BCNF：若R∈3NF，且R只有一个候选码，或者每个候选码都是单属性，则R∈BCNF。
接下来是我的瞎扯（真的是瞎扯，大家不要相信）：
首先定义一下什么叫主体类。
主体类简称主体，是客观世界存在的一个具有一系列属性的对象的集合。主体的属性可分为两种：默认在研究范围内不变的本质属性（比如学生的姓名和学号，课程的课程号和课程名称，教师的姓名）和可变属性（比如选课的成绩，教师的职称）。
再定义一下什么叫关系中的主体。
一个关系中所包含的主体是指关系中出现的所有可变属性所归属的主体。比如（学号，课程号，期中成绩，期末成绩）的主体只有“选课”（学生-课程之间的连接），不能认为“学生”或者“课程”也是这个关系中的主体。但是（学号，学生所在系，课程号，期中成绩，期末成绩）这个关系的主体就包括“学生”和“选课”，因为出现了“学生所在系”这个可变属性。
那么，直观地（很不学术地）理解一下前几个规范化：
2NF实际上是惟一性约束，可以有多个候选码，但是要求关系中所有候选码所确定的主体是同一个。同时2NF可以有多个主体，但是要求关系中存在的其他主体与候选码所确定的主体之间没有交集。
比如关系（学号，姓名，课程号，课程名，课程期中成绩，课程期末成绩）这个例子。如果已知姓名、课程名没有重名的话，候选码有4个：（学号，课程号）（姓名，课程号）（学号，课程名）（姓名，课程名）。但是其对应的主体只有“选课”（学生-课程之间的连接）。因此和关系（学号，课程号，课程期中成绩，课程期末成绩）一样满足2NF。
如果在上例中插入任何以“学生”或者“课程”为主体的可变属性（比如学生住址、学生所在系、课程教师、课程时间）都会使关系不再属于2NF。因为关系包含的主体增加了，而增加的主体与候选码所确定的主体之间有交集。不符合2NF怎么办呢？把表拆开，把相互有交集的主体分散到不同的关系里就好了。
如果插入的属性不是以“学生”或者“课程”为主体的可变属性则不会使关系不属于2NF。比如关系（学号，课程号，授课教师姓名，授课教师职称，课程期中成绩，课程期末成绩）这个例子。如果相同课号课名的课程任课老师有多位的话，候选码是（学号，课程号）。虽然主体有“选课”（候选码所确定的主体）和“教师”，但是之间没有交集。这个例子符合2NF，只是不符合3NF。
3NF依然可以有多个候选码，相对于2NF的区别是只能有一个主体。为什么要搞3NF？因为2NF中那些不是候选码所确定的主体很憋屈，他们不能独立存在；候选码所确定的主体也很憋屈，其他主体一变，他们得跟着变来变去。主体既然是主体，总还是分开比较方便。
BCNF则只能有一个候选码，或者每个候选码都是单属性。为什么搞BCNF？因为明明这个关系就一个主体，一个候选码就能唯一确定了，很多候选码放在表里只是在重复，如果不是经常要用到，不如放另一张表里算了。比如（学号，姓名，课程号），没重名的时候候选码是（学号，课程号）（姓名，课程号），点名收作业的时候姓名学号都有点用，张贴成绩的时候就可以不用姓名这一栏了。