范式在数据库中的应用_范式和模式的区别

1. 基础概念

1.1 元组：表中的一行就是一个元组。
1.2 候选码和主码：表中可以唯一确定一个元组的某个属性（或者属性组）叫候选码。
1.3 主码：我们从许多个候选码中挑一个就叫主码。（主键）
1.4 属性：教科书上解释为：“实体所具有的某一特性”，在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。
1.5 主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
1.6 非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

2. 范式的概念

2.1 第一范式：即表中的每一个属性都是不可再分的。
2.2 第二范式：符合1NF，且所有的非主属性都完全依赖于主属性。
2.3 第三范式：符合2NF，并要求任何非主属性不依赖于其他非主属性。
2.4 BC范式（BCNF）：符合3NF，并且主属性内部不能有部分或传递依赖。

3.举例说明

3.1.如下为“学生成绩表”，符合BC范式

这里的主键是学好+课程号，成绩是非主码属性，学好和课程都是主属性 

 3.2.变成不符合3范式

这里加了一个“是否及格”的属性，这个属性是依赖于成绩的，成绩依赖于主键 。这里有一个传递依赖，说以不属实第三范式了。

3.3.变成不符合2范式

这里班级依赖于学好 ，不依赖于课程号，说以这里是部分依赖，不满足第二范式。

3.4.变成不符合BC范式

 主键：学号+课程号

候选码：学号+授课教师号

非主属性：成绩

主属性：学号，课程号，授课教师号

这里“成绩”完全依赖于主属性，并且没有传递依赖，满足第三范式。但是是授课教师号依赖于课程号，这里存在主属性（非主码属性）对主键的部分依赖所以并不满足BC范式。

3.4 变成第四范式

学生选课表

X科目成绩表

 X科目成绩表

3.4.1第四范式定义

定:1：除对一个候选键扩展集存在属性组函数依赖外，不存在其它非平凡多值函数依赖。如果且只有一个表符合BCNF，同时多值依赖为函数依赖，此表才符合第四范式。4NF删除了不必要的数据结构：多值依赖。

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

3.4.2多值依赖理解

1.多值依赖：多值依赖属4nf的定义范围，比函数依赖要复杂得多。在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。

2.数学定义：设R(U)是属性集U上的一个关系模式。X，Y，Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r,给定的一对(x，z)值有一组Y的值，这组值仅仅决定于x值而与z值无关。

3.举例说明：有这样一个关系 <仓库管理员，仓库号，库存产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 <仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。

3.1.3 第四范式举例

由这个表可以看出，每个产品都有不同的代理商负责销售，每个产品都有不同的代理商负责生产，而代理商和工厂之间没有直接的关系，但是针对这个需求确可以用上面的表来表示这种关系，表示后的结果如下

主键：代理商+工厂

非主属性：产品

主属性：代理商，工厂

该表的设计不存在传递依赖，也不存在部分依赖，主属性也不纯在传递依赖和部分依赖，符合BC范式范式。但是该设计确有一个明显的问题，如果我要增加一个工厂F3生成全部产品，表要做如下处理。

发现问题没有，F3只生产car和Bus，确因为Car和Bus有相对的代理商却要把这个关系也带到这里。好了，既然发现问题了，那么如何解决问题呢，消除这个没用的关系。

第五范式：如果关系模式R中的每一个连接依赖, 都是由R的候选键所蕴含, 称R是第五范式（看到定义，就知道是要消除连接依赖,并且必须保证数据完整）

多值依赖：对于某个关系上的三个属性A, B, C。如果属性B，C的取值都不单一，同时B的取值与C无关，也就是B依赖于A，随着A取值的变化可以取不同的值。
多值依赖-形式化描述：设R(U)是属性集U上的一个关系模式。X，Y，Z是的U的子集,并且Z=U-X-Y，如果对R(U)的任一关系r，

连接依赖：设关系模式R、Ri的属性集是U、Ui，UiU(1≤i≤n).若R每个容许的实例r均满足r=∏U1(r)∞…∞∏Un(r)则称R满足连接依赖，记作∞(R1,…,Rn).若其中某个Ui=U，则称连接依赖是平凡连接依赖。 多值依赖也是连接依赖。

3.5.2 举例说明

上图解释：项目J1需要供应者S1提供的P1、P2和S2提供的P1，J2项目需要S1提供的P1。与第4范式的例子比，这里项目对零件号和供应号的依赖是连接的，不向第4范式中，产品分别和工厂和代理商发生关系，而代理商和工厂没有关联。这里不同，这里某个项目必须要某个指定供应商的零件。

这里项目号依赖于供应者号+供应者号，存在连接依赖。如何消除呢？

3.6 关于第四范式和第五范式

上面两了例子的处理结果，应该都最终满足，第五范式了，只不过，范式4消除的是多值依赖，范式5消除的是连接依赖，如果能找到一个，消除完多值依赖，但存在连接依赖的例子呢，我再找找。

4.思考

4.1 范式的级别-这里可以看到范式的目的无非是要消除传递依赖和部分依赖，部分依赖的关系本应该在子结构中体现，出现在该表中，存在层次混乱的问题。传递依赖，明显是重复的内容，会使表的意图并不明确，但是为什么部分依赖是2范式，而传递依赖是3范式呢？明显部分依赖犯的错误更严重，因为是级别的错误，明显班级和学号+课程号不是一个级别的。而传递依赖，虽然为了体现表的明确意图，不应该把是否及格放入成绩表中，但是至少也只是一个同级别的错误，成绩和是否及格是同级别的语义，甚至有些时候将他们放在一起也没有关系。

4.2 BC范式-这范式的价值是什么呢，如果把第二范式和第三范式的限制条件变成，任何非主码属性都不能对主码有部分和传递依赖，那么就没有BC范式的必要了，从形式上来说+授课教师号和+是否及格相比视乎并无明显的利弊差别？待深思。

4.3 如果没有组合主键-那么在做一个假设，如果没有组合主键，也就没有部分依赖，没有了第二范式的要求，第一，第三范式就满足设计的需求了。

今天的文章范式在数据库中的应用_范式和模式的区别分享到此就结束了，感谢您的阅读。