数据库-范式-范式的转换举例-用变坏的方式理解范式

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 第四范式举例

 
 
 
产品 代理商 工厂
Car      A1 F1
Car A1 F2
Bus      A2 F2

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

主键:代理商+工厂

非主属性:产品

主属性:代理商,工厂

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

 
产品 供应商 工厂
Car      A1 F1
Car A1 F2
Bus      A2 F2
Car      A1 F3
Bus      A2 F3

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

产品-经销商关系表
 
产品 供应商
Car  A1
Bus  A1
Car A2
产品生产关系表
 
产品 工厂
Car     F1
Car     F2
Bus    F2
Car     F3
Bus    F3
图说强调一下
 
3.5 第五范式
3.5.1 基本概念

第五范式:如果关系模式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 举例说明

 
供应者号 零件号 项目号
S1 P1 J2
S1 P2 J1
S2 P1 J1
S1 P1 J1

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

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

 
供应者号 零件号
S1 P1
S1 P2
S2 P1
 
 
零件号 项目号
P1 J2
P2 J1
P1 J1
 
 
项目号 供应者号
J2 S1
J1 S1
J2 S2

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

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

4.思考

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

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

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

发布了463 篇原创文章 · 获赞 38 · 访问量 6万+

猜你喜欢

转载自blog.csdn.net/xie__jin__cheng/article/details/103523214
今日推荐