数据库理论-范式(1NF、2NF、3NF)

范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。

第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项。（每个属性不可分割）
第二范式（2NF）要求数据表里的所有数据都要和该数据表的主键有完全依赖关系
第三范式（3NF）每个非关键字列都独立于其他非关键字列，并依赖于关键字，第三范式指数据库中不能存在传递函数依赖关系。

第一范式（1NF）
实际上，1NF是所有关系型数据库的最基本要求，每个属性不可分割。你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为图0的形式：
                                

图0

缺点：但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于图1中的设计：
                                 

图1
1)数据冗余过大
每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次。

2)插入异常
假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的。
注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。
注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。

3)删除异常
假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。

4)修改异常
假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。

正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式（2NF）
其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。

判断的方法是：
第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性。
第四步：查看是否存在非主属性对码的部分函数依赖。

对于，根据前面所说的四步，我们可以这么做：
第一步：找出数据表中所有的码。（学号，姓名，系名，系主任，课号，成绩）
第二步：根据第一步所得到的码，找出所有的主属性。（学号，课号）
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性。（姓名，系名，系主任，成绩）
第四步：查看是否存在非主属性对码的部分函数依赖。    
    对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
    对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
    对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性  对码（学号，课名）的部分函数依赖。  
                                                       

图2

图2表示了表中所有的函数依赖关系，所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

第三范式（3NF）
为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的。

重要：（这里还涉及到一个如何进行模式分解才是正确的知识点）

第三范式（3NF） 3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。接下来我们看看表4中的设计，是否符合3NF的要求。
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：选课（学号，课名，分数）学生（学号，姓名，系名）系（系名，系主任）对于选课表，符合3NF的要求。对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。

新的函数依赖关系如图3
                                                            

图3

现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？
    删除某个系中所有的学生记录       该系的信息不会丢失。——有改进
    插入一个尚无学生的新系的信息。   因为系表与学生表目前是独立的两张表，所以不影响。——有改进
    数据冗余更加少了。                            ——有改进

新的数据表如表：