国内绝大多数院校用的王珊的《数据库系统概论》这本教材，某些方面并没有给出很详细很明确的解释，与实际应用联系不那么紧密，所以学习范式的时候经常会有很多疑问。也有不少人提出各式各样的问题，现在在这里就试着解释一下吧，力图让大家轻松看明白。接下来就对每一级范式进行一下解释，首先是第一范式（1NF）。
表1实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2
表3每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。函数依赖我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如：但以下函数依赖关系则不成立：从“函数依赖”这个概念展开，还会有三个概念：完全函数依赖在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ‘ → Y 不成立，那么我们称 Y 对于 X完全函数依赖，记作 X F→ Y。（那个F应该写在箭头的正上方，没办法打出来……，正确的写法如图1）图1例如：学号 F→ 姓名（学号，课名） F→ 分数 （注：因为同一个的学号对应的分数不确定，同一个课名对应的分数也不确定）部分函数依赖图2例如：（学号，课名） P→ 姓名传递函数依赖图3码假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。例如：非主属性包含在任何一个码中的属性成为主属性。例如：对于表3，根据前面所说的四步，我们可以这么做：第一步：图4表示了表中所有的函数依赖关系：
图4第二步：第三步：第四步：对于（学号，课名） → 姓名，有学号 → 姓名对于（学号，课名） → 系名，有学号 → 系名对于（学号，课名） → 系主任，，有学号 → 系主任所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：选课（学号，课名，分数）学生（学号，姓名，系名，系主任），因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。图5表示了模式分解以后的新的函数依赖关系
图5表4表示了模式分解以后新的数据
表4（这里还涉及到一个如何进行模式分解才是正确的知识点，先不介绍了）现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？李小明转系到法律系只需要修改一次李小明对应的系的值即可。——有改进数据冗余是否减少了？学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进删除某个系中所有的学生记录该系的信息仍然全部丢失。——无改进插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进第三范式（3NF）3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。接下来我们看看表4中的设计，是否符合3NF的要求。。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：选课（学号，课名，分数）学生（学号，姓名，系名）系（系名，系主任）新的函数依赖关系如图6
图6新的数据表如表5
表5现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？删除某个系中所有的学生记录该系的信息不会丢失。——有改进插入一个尚无学生的新系的信息。因为系表与学生表目前是独立的两张表，所以不影响。——有改进数据冗余更加少了。——有改进结论由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。BCNF范式要了解 BCNF 范式，那么先看这样一个问题：若：某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量码：（管理员，物品名），（仓库名，物品名）主属性：仓库名、管理员、物品名非主属性：数量∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。基于此关系模式的关系（具体的数据）可能如图所示：
好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。仓库（仓库名，管理员）库存（仓库名，物品名，数量）这样，之前的插入异常，修改异常与删除异常的问题就被解决了。以上就是关于 BCNF 的解释。
三亚呀——赴一个蓝天碧海。
