数据库范式通俗易懂的解释

原文地址

此为原文的精简版，个人学习笔记，之前学习各种范式的时候被一大堆严格的定义搞的头昏脑胀，看了刘老师通俗易懂的文章后终于豁然开朗，之前的疑惑也一一解开

范式的定义

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

通俗的讲即一张数据表的表结构所符合的某种设计标准的级别。 就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2 级等等。数据库范式也分为1NF，2NF，3NF，BCNF，4NF， 5NF。 一般在我们设计关系型数据库的时候，最多考虑到BCNF 就够。符合高一级范式的设计，必定符合低一级范式，例如符 合 2NF的关系模式，必定符合1NF

1NF

符合1NF的关系中的每个属性都不可再分
一般数据表的设计不符合这个最基本的要求，那么在创建表的时候操作一定是不能成功的。

例子:

反例 正例

2NF

2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖

函数依赖

若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

完全函数依赖

在一张表中，若 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 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）

主属性

包含在任何一个码中的属性称为主属性

例子：

反例

上表存在问题：

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

• 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常

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

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

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

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

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

部分函数依赖例子

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

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

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

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

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

选课（学号，课名，分数）

学生（学号，姓名，系名，系主任）

模式分解后的依赖关系 表

• 李小明转系到法律系只需要修改一次李小明对应的系的值即可。——有改进

• 数据冗余是否减少了？学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进

• 删除某个系中所有的学生记录该系的信息仍然全部丢失。——无改进

• 插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进

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

3NF

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖

改进后的表是否符合3NF?

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

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

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

选课（学号，课名，分数）

学生（学号，姓名，系名）

系（系名，系主任）

改进为3NF 改进为3NF

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

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

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

删除某个系中所有的学生记录该系的信息不会丢失。——有改进

插入一个尚无学生的新系的信息。因为系表与学生表目前是独立的两张表，所以不影响。——有改进

数据冗余更加少了。——有改进

符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。

BCNF

在3NF的基础上消除主属性对于码的部分与传递函数依赖

例子：

BCNF

存在的问题

• 先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。

• 某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。

• 如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

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

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

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

仓库（仓库名，管理员）

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

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