定义
1NF（第一范式）：每个属性都是原子的，即不可再分解。也就是说，每个属性中都不能包含多个值或重复的组合值。
2NF（第二范式）：在满足1NF的基础上，非主属性必须完全依赖于候选码，而不是仅依赖于部分候选码。也就是说，关系模式中每个非主属性都必须与候选码有直接关系，不能通过其他非主属性派生出来。
3NF（第三范式）：在满足2NF的基础上，任何非主属性都不能依赖于其他非主属性。也就是说，每个非主属性都应该直接依赖于候选码，而不是依赖于其他非主属性。
BCNF（巴斯-科德范式）：在满足3NF的基础上，如果关系模式中有任何冗余的函数依赖关系，那么就需要进一步分解关系模式，以消除这些冗余的依赖关系。也就是说，每个非主属性都必须直接依赖于候选码，而不是依赖于其他非主属性或候选码的组合。
打个比方
假设有一个“订单”关系模式，包含以下属性：订单号、顾客ID、顾客姓名、顾客电话、订单日期、商品ID、商品名称、商品单价、商品数量、订单金额。
在这个关系模式中，订单号和顾客ID组合起来可以唯一标识每个订单，因此它们是候选码之一。另外，商品ID也可以作为候选码之一，因为每个商品都有唯一的ID。在这里，我们以订单号和顾客ID作为候选码。
1NF：首先需要满足1NF，也就是每个属性都是原子的。在这个例子中，所有的属性都已经是原子的，不需要进行分解。
2NF：在满足1NF的基础上，需要保证非主属性完全依赖于候选码。在这个例子中，顾客姓名、顾客电话、商品名称、商品单价和商品数量都依赖于商品ID，而与订单号和顾客ID无关。因此，这些属性应该从订单关系模式中移除，创建一个新的商品关系模式，使其仅包含商品ID、商品名称、商品单价和商品数量属性，从而满足2NF。
3NF：在满足2NF的基础上，需要保证每个非主属性都不能依赖于其他非主属性。在这个例子中，订单金额属性直接依赖于商品单价和商品数量属性，而与订单号、顾客ID和顾客信息无关。因此，订单金额应该从订单关系模式中移除，放在新的订单详情关系模式中，使其仅包含订单号、商品ID、商品单价和商品数量属性，从而满足3NF。
BCNF：在满足3NF的基础上，需要进一步消除冗余的函数依赖关系。在这个例子中，由于订单详情关系模式中的商品单价和商品数量属性都依赖于商品ID，而与订单号无关，因此应该将其从订单详情关系模式中移除，创建一个新的商品明细关系模式，使其仅包含商品ID、商品单价和商品数量属性，从而满足BCNF。
打个比方 X2
假设有一个“图书”关系模式，包含以下属性：书号、书名、作者、出版社、出版日期、价格。
在这个关系模式中，书号和书名组合起来可以唯一标识每本书，因此它们是候选码之一。另外，书号也可以作为候选码之一，因为每本书都有唯一的书号。在这里，我们以书号和书名作为候选码。
1NF：首先需要满足1NF，也就是每个属性都是原子的。在这个例子中，所有的属性都已经是原子的，不需要进行分解。
2NF：在满足1NF的基础上，需要保证非主属性完全依赖于候选码。在这个例子中，作者、出版社、出版日期和价格都依赖于书号，而与书名无关。因此，这些属性应该从图书关系模式中移除，创建一个新的“出版信息”关系模式，使其仅包含书号、出版社、出版日期和价格属性，从而满足2NF。
3NF：在满足2NF的基础上，需要保证每个非主属性都不能依赖于其他非主属性。在这个例子中，出版日期属性直接依赖于出版社，而与书号和价格无关。因此，出版日期应该从“出版信息”关系模式中移除，创建一个新的“出版商信息”关系模式，使其仅包含出版社和出版日期属性，从而满足3NF。
BCNF：在满足3NF的基础上，需要进一步消除冗余的函数依赖关系。在这个例子中，由于书名和作者的关系不是唯一的，因此无法将其作为候选码或主键。此时，“图书”关系模式无法满足BCNF。我们可以进一步分解“图书”关系模式，创建一个新的“书籍信息”关系模式，使其仅包含书号和书名属性，再创建一个新的“作者信息”关系模式，使其仅包含书号和作者属性，从而满足BCNF。
打个比方 X3
假设有一个“公司”关系模式，包含以下属性：员工号、员工姓名、所在部门、部门负责人、入职日期、工资、项目名称、项目负责人、项目开始日期、项目结束日期、项目收益。
在这个关系模式中，员工号和项目名称组合起来可以唯一标识每个员工在每个项目中的信息，因此它们是候选码之一。另外，员工号也可以作为候选码之一，因为每个员工都有唯一的员工号。在这里，我们以员工号和项目名称作为候选码。
1NF：首先需要满足1NF，也就是每个属性都是原子的。在这个例子中，所有的属性都已经是原子的，不需要进行分解。
2NF：在满足1NF的基础上，需要保证非主属性完全依赖于候选码。在这个例子中，员工姓名、所在部门、部门负责人、入职日期和工资都依赖于员工号，而与项目名称、项目负责人、项目开始日期、项目结束日期和项目收益无关。因此，这些属性应该从“公司”关系模式中移除，创建一个新的“员工信息”关系模式，使其仅包含员工号、员工姓名、所在部门、部门负责人、入职日期和工资属性，从而满足2NF。
3NF：在满足2NF的基础上，需要保证每个非主属性都不能依赖于其他非主属性。在这个例子中，项目负责人属性直接依赖于项目名称，而与员工号、员工信息和项目时间和收益无关。因此，项目负责人应该从“公司”关系模式中移除，创建一个新的“项目信息”关系模式，使其仅包含项目名称、项目负责人、项目开始日期和项目结束日期属性，从而满足3NF。
BCNF：在满足3NF的基础上，需要进一步消除冗余的函数依赖关系。在这个例子中，项目收益属性直接依赖于员工号和项目名称的组合，而与项目信息无关。因此，项目收益应该从“公司”关系模式中移除，创建一个新的“员工项目信息”关系模式，使其仅包含员工号、项目名称和项目收益属性，从而满足BCNF。
打个比方 X4
假设有一个“学生选课”关系模式，包含以下属性：学生编号、学生姓名、选课编号、选课名称、授课教师、学分、成绩。
1NF：每个属性都应该是原子的。在这个例子中，所有的属性都已经是原子的。
2NF：满足1NF，且非主属性完全依赖于候选码。在这个例子中，学生编号和选课编号的组合可以唯一标识每个选课记录，因此这两个属性是候选码。学生姓名、选课名称、授课教师、学分和成绩都与学生编号和选课编号有关，而与其他属性无关，因此满足2NF。
3NF：满足2NF，且每个非主属性都不依赖于其他非主属性。在这个例子中，授课教师属性直接依赖于选课名称，而与学生编号、学生姓名、选课编号、学分和成绩无关。因此，授课教师应该从“学生选课”关系模式中移除，创建一个新的“课程信息”关系模式，使其仅包含选课编号、选课名称和授课教师属性，从而满足3NF。
BCNF：满足3NF，且没有任何冗余的函数依赖。在这个例子中，假设每个学生只能选一门课程，那么学生编号和选课编号的组合就是唯一的。此时，“学生选课”关系模式已经满足BCNF。但是，如果一个学生可以选多门课程，那么学生编号就不能成为“学生选课”关系模式的主键，因为一个学生的学号可能对应多个选课记录。此时，“学生选课”关系模式应该进一步分解，创建一个新的“学生信息”关系模式和一个新的“选课信息”关系模式，使其分别包含学生的基本信息和选课的基本信息，再创建一个新的“选课记录”关系模式，将学生信息和选课信息通过学号和选课编号的关系连接起来，从而满足BCNF。