概念理解
术语定义：范式是符合某一种级别的关系模式的集合
通俗理解：相当于一个衡量数据库表关系模式设计优劣的一个标准，同教师的职称有初级、中级、高级、特级等等一样，范式同样分为几个级别
关系模式的冗余和异常问题
数据冗余：同一数据在系统中重复出现，在数据库管理中，数据冗余一直是影响系统性能的大问题。
操作异常：由于数据冗余，对数据库的操作会引起各种异常（修改异常，插入异常，删除异常）
范式
由于关系模式的各种问题，所以就出现了一个衡量数据库关系模式的标准也就是范式
第一范式（1NF）
定义：数据库表中的字段都是单一属性的，不可再分的（段是最小的单元不可再分）
1NF是关系模式应具备的最起码的条件
第二范式（2NF）
定义：在满足第一范式的情况下，且每个非主属性完全依赖于候选键
理解这句话的时候，我们先理解一下其中的一些名词
码（候选键）：
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码（候选键），简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码
第三范式（3NF）
实例
1、分析上表可知，上表属于第一范式（关系中的每个属性不可再分），但有许多问题，比如，数据冗余、插入异常、删除异常、修改异常等等
2、现在我们将其规范到第二范式，即 达到每个非主属性完全依赖于候选键，大致有四个步骤。
第一步：找出表中所有的码
方法是当找出的码值确定，其他的数据也就确定了，可知码为（学号，课名）
第二步：根据上一步找出的码，确定主属性
码为（学号，课名），所以主属性为学号和课名
第三步：根据表中，去除所有的主属性，剩下的就是非主属性了
根据主属性学号和课名，可知非主属性为姓名、系名、系主任和分数
第四步：查看是否存在非主属性对码的部分函数依赖
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 系主任 对码（学号，课名）的部分函数依赖
第五步：如果存在非主属性对码的部分函数依赖，将大数据表拆分成两个或者更多个更小的数据表
下图表示了模式分解以后的新的函数依赖关系
下图表示模式分解以后新的数据
上述模式虽然有改进，但是仍然存在一些问题如
1、当删除学生信息时候，把系别信息也删除了
2、当插入新的系别时，由于没有学生信息，所以插入异常
所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）