范式就是一张数据表的表结构所符合的某种设计标准的级别
1NF
符合1NF的关系中的每个属性都不可再分，一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定
如下就不符合1NF
1NF是所有关系型数据库的最基本要求
只满足1NF会存在一些问题，以下表为例
① 数据冗余过大： 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次
② 插入异常： 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的，因为这里把学号与课名的组合作为码，根据三种关系完整性约束中实体完整性的要求，关系中的码所包含的任意一个属性都不能为空，所有属性的组合也不能重复
③ 删除异常： 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）
④ 修改异常： 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据
正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”
2NF
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖
也就是说二范式就是要有主键，要求其他字段都依赖于主键
为什么要有主键？没有主键就没有唯一性，没有唯一性在集合中就定位不到这行记录，所以要主键
其他字段为什么要依赖于主键？因为不依赖于主键，就找不到他们。更重要的是，其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的
函数依赖
我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
例如，对于表3中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如
- 系名 → 系主任
- 学号 → 系主任
- (学号，课名） → 分数
但以下函数依赖关系则不成立：
- 学号 → 课名
- 学号 → 分数
- 课名 → 系主任
- (学号，课名） → 姓名
从“函数依赖”这个概念展开，还会有三个概念
完全函数依赖
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作
- 学号 F→ 姓名
- (学号，课名） F→ 分数 （注：因为同一个的学号对应的分数不确定，同一个课名对应的分数也不确定）
部分函数依赖
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作
- (学号，课名） P→ 姓名
传递函数依赖
假如 Z 函数依赖于 Y，且 Y 函数依赖于 X 那么我们就称 Z 传递函数依赖于 X
码
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码**。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码**）
非主属性
包含在任何一个码中的属性成为主属性
终于可以回过来看2NF了。首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
第一步：找出数据表中所有的码 （学号，课名）
第二步：根据第一步所得到的码，找出所有的主属性（学号和课名）
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了（姓名、系名、系主任、分数）
第四步：查看是否存在非主属性对码的部分函数依赖
对于**（学号，课名） → 姓名，有 学号 → 姓名**，存在非主属性 姓名 对码**（学号，课名）**的部分函数依赖。
对于**（学号，课名） → 系名**，有 学号 → 系名，存在非主属性 系名对码**（学号，课名）**的部分函数依赖。
对于**（学号，课名） → 系主任**，有 学号 → 系主任，存在非主属性 对码**（学号，课名）**的部分函数依赖。
所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求
为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：
选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
-
李小明转系到法律系只需要修改一次李小明对应的系的值即可。—有改进
-
数据冗余是否减少了？学生的姓名、系名与系主任，不再像之前一样重复那么多次了。—有改进
-
删除某个系中所有的学生记录该系的信息仍然全部丢失。—无改进
-
插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。—无改进
所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求
3NF
第三范式（3NF） 3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖
可以看做是“消除冗余”，就是各种信息只在一个地方存储，不出现在多张表中
接下来我们看看表4中的设计，是否符合3NF的要求。
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）
对于选课表，符合3NF的要求，之前已经分析过了。
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
删除某个系中所有的学生记录，该系的信息不会丢失 ——有改进
插入一个尚无学生的新系的信息，因为系表与学生表目前是独立的两张表，所以不影响。——有改进
数据冗余更加少了。——有改进
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的
BCNF范式
在 3NF 的基础上消除主属性对于码的部分与传递函数依赖
