在设计与操作维护时最关键的問题就是要确保数据能够正确地分布到数据库第二范式的表中。使用正确的数据结构不仅有助于对数据库第二范式进行相应的存取操作，还可以极大地简化应用程序中的其他内容(查询、窗体、报表、代码等)按照“数据库第二范式规范化”对表进行设计，其目的就是减少數据库第二范式中的数据冗余以增加数据的一致性。

泛化时在识别数据库第二范式中的一个数据元素、关系以及定义所需的表和各表中嘚项目这些初始工作之后的一个细化的过程常见的范式有1NF、2NF、3NF、BCNF以及4NF。下面对这几种常见的范式进行简要分析

第一范式是指数据库第②范式表中的每一列都是不可分割的基本数据项，同一列中不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性就可能需要定义一个新的实体，新的实体由重复的属性构成新实体与原实体之间为一对多关系。第一范式的模式要求属性值不可再分裂成更小部分即属性项不能是属性组合或是由一组属性构成。

简而言之第一范式就是无重复的列。例如由“职工號”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和一部移动电话)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性即职工(职工号，姓名办公电话，移动电话)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)第二范式(2NF)要求数据库第二范式表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列以存儲各个实例的唯一标识。

如果关系模型R为第一范式并且R中的每一个非主属性完全函数依赖于R的某个候选键，则称R为第二范式模式(如果A是關系模式R的候选键的一个属性则称A是R的主属性，否则称A是R的非主属性)

例如，在选课关系表(学号课程号，成绩学分)，关键字为组合關键字(学号课程号)，但由于非主属性学分仅依赖于课程号对关键字(学号，课程号)只是部分依赖而不是完全依赖，因此此种方式会导致数据冗余以及更新异常等问题解决办法是将其分为两个关系模式：学生表(学号，课程号分数)和课程表(课程号，学分)新关系通过学苼表中的外关键字课程号联系，在需要时进行连接

如果关系模型R是第二范式，且每个非主属性都不传递依赖于R的候选键则称R是第三范式的模式。

以学生表(学号姓名，课程号成绩)为例，其中学生姓名无重名所以该表有两个候选码(学号，课程号)和(姓名课程号)，故存茬函数依赖：学号——>姓名(学号，课程号)——>成绩唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖所以属性属于第三范式。

它构建在第三范式的基础上如果关系模型R是第一范式，且每个属性都不传递依赖于R的候选键那么称R为BCNF的模式。

假设仓库管理关系表(仓库号存储物品号，管理员号数量)，满足一个管理员只在一个仓库工作；一个仓库可以存储多种物品则存在如下关系：

(仓库号，存储物品号)——>(管理员号数量)

(管理员号，存储物品号)——>(仓库号数量)

所以，(仓库号存储物品号)和(管理员号，存储物品号)都是仓库管理关系表的候选码表中唯一非关键字段为数量，它是符合第三范式的但是，由于存在如下决定关系：

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况因此其不符合BCNF。把仓库管理关系表分解为两个关系表仓库管理表(仓库号管理员号)和仓庫表(仓库号，存储物品号数量)，这样这个数据库第二范式表是符合BCNF的并消除了删除异常、插入异常和更新异常。

设R是一个关系模型D昰R上的多值依赖集合。如果D中存在凡多值依赖X->Y时X必是R的超键，那么称R是第四范式的模式

例如，职工表(职工编号职工孩子姓名，职工選修课程)在这个表中，同一个职工可能会有多个职工孩子姓名同样，同一个职工也可能会有多个职工选修课程即这里存在着多值事實，不符合第四范式如果要符合第四范式，只需要将上表分为两个表使它们只有一个多值事实，例如职工表一(职工编号职工孩子姓洺)，职工表二(职工编号职工选修课程)，两个表都只有一个多值事实所以符合第四范式。

拓展：各范式的关系图如下所示：

关系数据库第二范式有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）满足最低要求的范式是苐一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF）其余范式以次类推。一般说来数据库第二范式只需满足苐三范式（3NF）就行了

国内绝大多数院校用的王珊的《數据库第二范式系统概论》这本教材某些方面并没有给出很详细很明确的解释，与实际应用联系不那么紧密你有这样的疑问也是挺正瑺的。我教《数据库第二范式原理》这门课有几年了有很多学生提出了和你一样的问题，试着给你解释一下吧（基本来自于我上课的內容，某些地方为了不过于啰嗦放弃了一定的严谨，主要是在“关系”和“表”上）

首先要明白”范式（NF）”是什么意思按照教材中嘚定义，范式是“符合某一种级别的关系模式的集合表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧实际上你可以把咜粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材最环保的是E0级，其次是E1级还有E2级等等。数据庫第二范式范式也分为1NF2NF，3NFBCNF，4NF5NF。一般在我们设计关系型数据库第二范式的时候最多考虑到BCNF就够。符合高一级范式的设计必定符合低一级范式，例如符合2NF的关系模式必定符合1NF。

接下来就对每一级范式进行一下解释首先是第一范式（1NF）。

符合1NF的关系（你可以理解为數据表“关系”和“关系模式”的区别，类似于面向对象程序设计中”类“与”对象“的区别”关系“是”关系模式“的一个实例，伱可以把”关系”理解为一张带数据的表而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每个属性都不可再分表1所示的情况，就不符合1NF的要求

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

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

• 每一名学生的学号、姓名、系名、系主任这些数据重复多次每个系与对应的系主任的数据也重复多次——数据冗余过大
• 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常

  注１：根据三种关系完整性约束中实体完整性的偠求关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复为了满足此要求，图中的表只能将学号与課名的组合作为码，否则就无法地区分每一条记录

  注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“え组”理解为一张表中的每条记录也就是每一行）。

• 假如将某个系中所有学生相关的记录都删除那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）——删除异常
• 假如李小明转系到法律系，那么为了保证数据库第二范式Φ数据的一致性需要修改三条记录中系与系主任的数据。——修改异常
  

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

第二范式（2NF）在关系悝论中的严格定义我这里就不多介绍了（因为涉及到的铺垫比较多）只需要了解2NF对1NF进行了哪些改进即可。其改进是2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依賴”进行一下解释。

函数依赖 我们可以这么理解（但并不是特别严格的定义）：若在一张表中在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值那么就可以说Y函数依赖于X，写作 X → Y也就是说，在数据表中不存在任意两条记录，它们在X属性（或属性组）上的徝相同而在Y属性上的值不同。这也就是“函数依赖”名字的由来类似于函数关系 y = f(x)，在x的值确定的情况下y的值一定是确定的。

例如對于表3中的数据，找不到任何一条记录它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号写作 学号 → 姓名。但昰反过来因为可能出现同名的学生，所以有可能不同的两条学生记录它们在姓名上的值相同，但对应的学号不同所以我们不能说学號函数依赖于姓名。表中其他的函数依赖关系还有如：

• （学号课名） → 分数
  

但以下函数依赖关系则不成立：

• （学号，课名） → 姓名
  

从“函数依赖”这个概念展开还会有三个概念：

完全函数依赖 在一张表中，若 X → Y且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性嘚话），X ' → Y 不成立那么我们称 Y 对于 X 完全函数依赖，记作 X F→ Y（那个F应该写在箭头的正上方，没办法打出来……正确的写法如图1）

• （学號，课名） F→ 分数 （注：因为同一个的学号对应的分数不确定同一个课名对应的分数也不确定）
  

部分函数依赖 假如 Y 函数依赖于 X，但同时 Y 並不完全函数依赖于 X那么我们就称 Y 部分函数依赖于 X，记作 X P→ Y如图2。

• （学号课名） P→ 姓名
  

传递函数依赖 假如 Z 函数依赖于 Y，且 Y 函数依赖於 X （严格来说还有一个X 不包含于Y且 Y 不函数依赖于Z的前提条件），那么我们就称 Z 传递函数依赖于 X 记作 X T→ Z，如图3

码 设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了）那么我们称 K 为候选码，简称为码在实际中我们通常可鉯理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定那么 K 就是码。一张表中可以有超过一个码（实际应用中为叻方便，通常选择其中的一个码作为主码）

对于表3（学号、课名）这个属性组就是码。该表中有且仅有这一个码（假设所有课没有重洺的情况）

非主属性 包含在任何一个码中的属性成为主属性。

对于表3主属性就有两个，学号 与 课名

终于可以回过来看2NF了。首先我们需要判断，表3是否符合2NF的要求根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖若存在，则数據表较高只符合1NF的要求若不存在，则符合2NF的要求判断的方法是：

第一步：找出数据表中所有的码。

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

对于表3根据前面所说的四步，我们可以这么做：

• 查看所有每一单个属性当它的值确定了，是否剩下的所有属性值都能确定
• 查看所有包含有两个属性的属性组，当它的值确定了是否剩下的所有属性值都能确定。
• 查看所有包含了六个属性也就是所有属性的属性組，当它的值确定了是否剩下的所有属性值都能确定。
  

看起来很麻烦是吧但是这里有一个诀窍，就是假如A是码那么所有包含了A的属性组，如（AB）、（A，C）、（AB，C）等等都不是码了（因为作为码的要求里有一个“完全函数依赖”）。

图4表示了表中所有的函数依赖關系：

这一步完成以后可以得到，表3的码只有一个就是（学号、课名）。

主属性有两个：学号 与 课名
非主属性有四个：姓名、系名、系主任、分数

第四步： 对于（学号课名） → 姓名，有 学号 → 姓名存在非主属性 姓名 对码（学号，课名）的部分函数依赖

对于（学号，课名） → 系名有 学号 → 系名，存在非主属性 系名 对码（学号课名）的部分函数依赖。
对于（学号课名） → 系主任，有 学号 → 系主任存在非主属性 对码（学号，课名）的部分函数依赖

所以表3存在非主属性对于码的部分函数依赖，较高只符合1NF的要求不符合2NF的要求。

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

选课（学号课名，分数）
学生（学号姓名，系名系主任）

我们先来判断以下，选课表与学生表是否符合了2NF的要求？

对于选课表其码是（学号，课洺）主属性是学号和课名，非主属性是分数学号确定，并不能确定分数课名确定，也不能确定分数所以不存在非主属性分数对于碼 （学号，课名）的部分函数依赖所以此表符合2NF的要求。

对于学生表其码是学号，主属性是学号非主属性是姓名、系名和系主任，洇为码只有一个属性所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求

图5表示了模式分解以后的新的函数依赖关系

表4表示了模式分解以后新的数据

（这里还涉及到一个如何进行模式分解才是正确的知识点，先不介绍了）

现在我们来看一下进行同样嘚操作，是否还存在着之前的那些问题

只需要修改一次李小明对应的系的值即可。——有改进 学生的姓名、系名与系主任不再像之前┅样重复那么多次了。——有改进
• 删除某个系中所有的学生记录
  该系的信息仍然全部丢失——无改进
• 插入一个尚无学生的新系的信息。
  洇为学生表的码是学号不能为空，所以此操作不被允许——无改进
  

所以说，仅仅符合2NF的要求很多情况下还是不够的，而出现问题的原因在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题我们还需要将符合2NF要求的数据表改进为符匼3NF的要求。

第三范式（3NF）3NF在2NF的基础之上消除了非主属性对于码的传递函数依赖。也就是说 如果存在非主属性对于码的传递函数依赖，則不符合3NF的要求

接下来我们看看表4中的设计，是否符合3NF的要求

对于选课表，主码为（学号课名），主属性为学号和课名非主属性呮有一个，为分数不可能存在传递函数依赖，所以选课表的设计符合3NF的要求。

对于学生表主码为学号，主属性为学号非主属性为姓名、系名和系主任。因为 学号 → 系名同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖所以学生表的设计，鈈符合3NF的要求。

为了让数据表设计达到3NF我们必须进一步进行模式分解为以下形式：

选课（学号，课名分数）
学生（学号，姓名系洺）

对于选课表，符合3NF的要求之前已经分析过了。

对于学生表码为学号，主属性为学号非主属性为系名，不可能存在非主属性对于碼的传递函数依赖所以符合3NF的要求。

对于系表码为系名，主属性为系名非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系）所以符合3NF的要求。

新的函数依赖关系如图6

现在我们来看一下，进行同样的操莋是否还存在着之前的那些问题？

• 删除某个系中所有的学生记录
  该系的信息不会丢失——有改进
• 插入一个尚无学生的新系的信息。
  因為系表与学生表目前是独立的两张表所以不影响。——有改进
• 数据冗余更加少了——有改进
  

结论 由此可见，符合3NF要求的数据库第二范式设计基本上解决了数据冗余过大，插入异常修改异常，删除异常的问题当然，在实际中往往为了性能上或者应对扩展的需要，經常 做到2NF或者1NF但是作为数据库第二范式设计人员，至少应该知道3NF的要求是怎样的。

BCNF范式 要了解 BCNF 范式那么先看这样一个问题：

• 每个仓庫只能有一名管理员，一名管理员只能在一个仓库中工作；
• 一个仓库中可以存放多种物品一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量
  

那么关系模式 仓库（仓库名，管理员物品名，数量） 属于哪一级范式

答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名（仓库名，物品名）→ 数量

码：（管理员物品名），（仓库名物品名）
主属性：仓库名、管理员、物品洺
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF

基于此关系模式的关系（具体的数据）可能如图所示：

好，既然此关系模式已经属于了 3NF那么这个关系模式是否存在问题呢？我们来看以下几种操作：

• 先新增加一个仓库但尚未存放任何物品，昰否可以为该仓库指派管理员——不可以，因为物品名也是主属性根据实体完整性的要求，主属性不能为空
• 某仓库被清空后，需要刪除所有与这个仓库相关的物品存放记录会带来什么问题？——仓库本身与管理员的信息也被随之删除了
• 如果某仓库更换了管理员，會带来什么问题——这个仓库有几条物品存放记录，就要修改多少次管理员信息
  

从这里我们可以得出结论，在某些特殊情况下即使關系模式符合 3NF 的要求，仍然存在着插入异常修改异常与删除异常的问题，仍然不是 ”好“ 的设计

造成此问题的原因：存在着主属性对於码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员物品名）】的部分函数依赖。

解决办法僦是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖

仓库（仓库名，管理员）

库存（仓库名物品名，数量）

这样之前的插入異常，修改异常与删除异常的问题就被解决了

以上就是关于 BCNF 的解释。

最近身体不太舒服写不动了。有空再放几个典型习题及其解答吧

：老师您好，我看了您关于数据库第二范式范式的回答有一点不太理解，就是关于码的定义如果除K之外的所有属性都完全函数依赖於K时才能称K为码，那么在判断2NF时又怎么会存在非主属性对码的部分函数依赖这种情况希望老师有时间能指点一下，谢谢

我 ：在“码”的萣义中除 K 之外的所有属性应该看成是一个集合 U（也就是一个整体），也就是说只有 K 能够完全函数决定 U 中的每一个属性，那么 K 才是码洳果 K 只是能够完全函数决定 U 中的一部分属性，而不能完全函数决定另外一部分属性那么 K 不是码。

所以可得到主属性：Sno, Cno

R 中存在非主属性 Cname 对於码 (Sno, Cno) 的部分函数依赖 (Cno → Cname) （还有很多别的例子就不一一列举了）。所以 R 不符合 2NF 的要求

花了好几天断断续续写了这个答案，累死我了看囿不少人对此有疑问，干脆写一个详细点的希望成为这个知识点的权威回答……如果有一些细节方面的问题，比如表达上还会进行修妀，大的方面肯定是没错的。