从第一范式(2nf)到第二范式(3nf)_数据库范式笔记

范式：全文内容均摘抄自数据库第一二三范式到底在说什么？

第一范式：符合1NF关系中的每个属性（每个字段）都不可再分

不符合第一范式。

1NF是所有关系型数据库的最基本要求

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

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

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

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

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

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

模式分解之后：

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

1. 李小明转系到法律系只需要修改一次李小明对应的系的值即可。——有改进
2. 数据冗余是否减少了？学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进
3. 删除某个系中所有的学生记录该系的信息仍然全部丢失。——无改进
4. 插入一个尚无学生的新系的信息。因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进

仍然存在非主属性系主任对于码学号的传递函数依赖

第三范式：

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

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

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

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

系（系名，系主任）

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

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

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

满足第三范式：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量

码：（管理员，物品名），（仓库名，物品名）

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

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

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

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

模式分解：

仓库（仓库名，管理员）

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