针对一个具体问题,应该如何构造一个适合于它的数据库模式呢?
一、异常
以下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade},键码为 {Sno, Cname}。也就是说,确定学生和课程之后,就能确定其它信息。
不符合范式的关系,会产生很多异常,主要有以下四种异常:
- 数据冗余:例如 学生 -2 出现了两次。
- 更新异常:修改了一个记录中的信息,但是另一个记录中相同的信息却没有被修改。
- 删除异常:删除一个信息,那么也会丢失其它信息。例如删除了 课程-1 需要删除第一行和第三行,那么 学生-1 的信息就会丢失。
- 插入异常:例如想要插入一个学生的信息,如果这个学生还没选课,那么就无法插入。
数据依赖是一个关系内部属性和属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间的相关联系。其中最重要的是函数依赖和多值依赖。
一个模式的数据依赖会有哪些不好的性质,如何改造一个不好的模式,这就是规范化要讨论的内容
二、规范化
1. 规范化的目的
关系数据库进行规范化的目的:使结构更合理,解决数据中可能出现的异常情况(比如数据冗余、更新异常、删除异常、插入异常),从而增强数据的稳定性和灵活性
关系模式进行规范化的原则:遵从概念单一化“一事一地”原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
关系模式进行规范化的方法:将关系模式投影分解成两个或两个以上的关系模式。
2. 函数依赖(functional dependency,FD)
① 概念
记 A->B
表示 A 函数决定 B
,也可以说 B 函数依赖于 A
。
在一个关系中,任意元组,若属性 A1,A2….An 一样,则属性 B1,B2…Bm 必一样,那么称 A1,A2…An 函数决定 B1,B2…Bm。
记号为 A1,A2...An → B1,B2...Bm
Ai与Bi有函数依赖)
如果 {A1,A2,... ,An}
是关系的一个或多个属性的集合,该集合函数决定了关系的其它所有属性并且是最小集合,那么该集合就称为 键码。
对于
A->B
,如果能找到 A 的真子集 A’,使得A'-> B
,那么 A->B 就是 部分函数依赖,否则就是 完全函数依赖。对于
A->B,B->C
,则A->C
是一个传递函数依赖。
② 范式理论
关系数据库中的关系是要满足一定要求的,满足不同程度要求的为不同范式。
范式理论是为了解决以上提到四种异常。
高级别范式的依赖于低级别的范式,1NF 是最低级别的范式。
一个低一级的范式的关系模式通过模式分解可以转换为若干个高一级的关系模式的集合,这个过程就叫 规范化(normalization)
Ⅰ 第一范式 (1NF)
定义:
属性不可分。可以认为任何表都属于第一范式,因为每个表的最小单位为表中的各个属性。
Ⅱ 第二范式 (2NF)
定义:
在满足第一范式前提下,在所有函数依赖表达式中,不存在 任何 候选键的真子集 决定 非主属性。即消除 非主属性 对于 主键 的 部分依赖,使得非主属性完全依赖于主键
一个关系模式不符合2NF定义,会导致如下问题
- 插入异常
- 删除异常
- 修改复杂
实例:
有关系模式 S-L-C(Sno,Cno,Sdept,Sloc,Grade),其中Sloc为学生住处,并且每个系的学生住在同一个地方。则函数依赖有
- (Sno,Cno) — F —> Grade
- Sno ——> Sdept,(Sno, Cno) — P —> Sdept
- Sno ——> Sloc,(Sno, Cno) — P —> Sloc
- Sdept ——> Sloc
函数依赖关系图如图所示
非主属性Sdept、Sloc并不完全函数依赖于主键/码,因此不符合2NF定义
解决的办法是用 投影 分解原先的关系模式 S-L-C(Sno,Cno,Sdept,Sloc,Grade),分解为:
SC(Sno, Cno, Grade)
S-L(Sno, Sdept, Sloc)
这样就使得非主属性对主键是完全函数依赖了,满足第二范式
Ⅲ 第三范式(3NF)
定义:
在满足第二范式前提下,在所有函数依赖表达式中,所有 非主属性 不传递依赖于 候选键,这里 A → B , B → C 则称 C 传递依赖于 A
一个关系模式不符合3NF定义,会导致如下问题(同2NF)
- 插入异常
- 删除异常
- 修改复杂
实例:
在上面的实例关系模式 S-L(Sno, Sdept, Sloc) 中存在传递依赖,Sno ——> Sdept, Sdept——> Sloc, Sloc传递依赖于Sno
解决的方法同样是投影分解,将 S-L 分解为
- S-D (Sno, Sdept)
- D-L (Sdept, Sloc)
分解后的关系模式 S-D 和 D-L 中不再存在传递依赖,满足第三范式3NF
Ⅳ 修正的第三范式(BCNF)
定义:在满足第二范式的条件下,消除所有属性对主属性的传递依赖。即如果一个属性/属性组 A 决定其他属性/属性组B,则 A 必须包含主键
关系模式 R 属于 3NF,但 R 不一定属于 BCNF
下面给出几个例子说明属于3NF的关系模式有的属于BCNF,有的不属于BCNF
实例:
关系模式C(Cno, Cname , Pcno),他只有一个码Cno,且没有任何属性对Cno部分依赖或传递依赖,C属于3NF,同时C中Cno是唯一决定因素,所以C属于BCNF
有如下函数依赖:(S,J) —> T,(S,J) —> J,T —> J。这里的(S,J) (S,J) 都是主码
该关系模式是 3NF,因为没有任何非主属性对主码传递依赖;
不是 BCNF,因为 T 作为决定因素(T 决定 J)但是并不包含主码。
3. 多值依赖
① 概念
以上完全是在函数依赖的范畴内讨论问题,属于BCNF的关系模式是否就很完美了呢?下面来看一个例子
② 范式理论
Ⅰ 4NF
4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖
4. 规范化总结
规范化的思想是逐步消除数据依赖中不合适的部分,使模式中的各关系模式达到某种程度的分离。
三、关系数据库设计习题
设有关系模式 R(A,B,C,D,E,F),其函数依赖集为: F={E→D, C→B, CE→F, B→A}.
请回答如下问题:
指出R的所有候选键并说明原因;
按照上述函数依赖画出下述函数依赖图
得出:(C, E) 为唯一的候选键,因为只需要这两个元素就可以唯一的确定所有元素
R最高属于第几范式,为什么?
第三范式需要满足无传递依赖,显示不属于第三范式;
第二范式需要满足无部分函数依赖,E——>D,(C, E) —P—> D, D部分依赖于主键(C,E),所以不属于第二范式;
所以R属于第一范式
分解R为3NF.
1NF ——> 2NF 消除部分函数依赖
R1(C,E,B,A,F) + R2(E,D)
2NF ——>3NF 消除传递函数依赖
分解为 R3(C, E, F, B) + R4 (B, A) + R2 (E,D)