范式（NF）
教材：“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”
粗略的理解：一张数据表的表结构所符合的某种设计标准的级别
范式的级别：1NF，2NF，3NF，BCNF，4NF，5NF。（一般在我们设计关系型数据库的时候，考虑到BCNF就够）
符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
第一范式（1NF）
关系和关系模式：
“关系”和“关系模式”的区别，类似于“对象”与“类”的区别。
”关系”是一张带数据的表，而“关系模式”是这张表的表结构。
1NF的定义
符合1NF的关系中的每个属性都不可再分
错误示例：
（实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的）
缺点：
数据冗余过大，插入异常，删除异常，修改异常
举例：
2NF
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。
定义
当一个表有组合主键时，其他非主键的字段必须完全依赖于主键
（如果不是组合主键那就谈不上符不符合第二范式了）
函数依赖
在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
完全函数依赖
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y
对于 X 完全函数依赖，记作 X F→ Y。
部分函数依赖
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X P→ Y
传递函数依赖
前提：Y 不包含于 X，且 X 不函数依赖于 Y
假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，那么我们就称 Z 传递函数依赖于 X，记作 X T→ Z
候选码
设 K 为表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码，简称为码。
主属性
包含在任何一个码中的属性成为主属性。
2NF判断方法：
- 找出数据表中所有的码。
- 根据所得到的码，找出所有的主属性。
- 数据表中，除去所有的主属性，剩下的就都是非主属性了
- 查看是否存在非主属性对码的部分函数依赖。
对于表2，根据前面所说的四步，我们可以这么做：
模式分解
为了让表2符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，以达到更高一级范式的要求。
缺点
插入，删除异常
(出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。)
3NF
定义
主键以外的字段必须依赖主键 而不能依赖其他字段
3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖
对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
BCNF范式
问题
若某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？
答
已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
码：（管理员，物品名），（仓库名，物品名）
主属性：仓库名、管理员、物品名
非主属性：数量
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。
在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。
造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。仓库（仓库名，管理员）
库存（仓库名，物品名，数量）这样，之前的插入异常，修改异常与删除异常的问题就被解决了。
扫一扫
332
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
