第四章数据库规范化理论(第二节)课件

1第四章

数据库规范化理论第二节、范式理论第一节、函数依赖第三节、关系模式分解概述2第四章

数据库规范化理论第二节、范式理论

数据依赖引起的主要问题是操作异常，解决的办法是进行关系模式的合理分解，也就是进行关系模式的规范化(Normalization)。由于关系的规范化的要求不同，出现了不同的范式(NormalForm)，有1NF、2NF、3NF、BCNF、4NF、5NF等。满足最低要求的条件是叫做第一范式，简称1NF。这是最基本的范式化。

在第一范式的基础上进一步增加条件，则有第二范式2NF、第三范式3NF，BCNF范式，第四范式4NF和第五范式5NF等。其规范化的条件按上述次序越来越强，后面的范式可以看成是前面范式的特例。把低级范式的关系模式，通过分解转换为高一级范式的关系模式的集合，这个过程称为规范化设计。31NF2NF3NFBCNF4NF5NF第四章

数据库规范化理论第二节、范式理论图4-15第四章

数据库规范化理论第二节、范式理论一、第一范式（1NF）如果关系仅仅满足第一范式的条件是不够的，可能会存在更新异常。为了消除这些异常，需要进行关系的规范化。下面是满足第一范式的(不好的)关系模式的例子。例如：设有一关系模式R(S#，C#，G，TN，D)，其中(S#)为学号，C#为课程号，G为成绩，TN为任课教师姓名，D为教师所在系名，这些数据具有下列语义：

(1)学号是一个学生的标识，课程号是一门课程的标识。

(2)一位学生所修的每门课程都有一个成绩。

(3)每门课程只有一位任课教师，但一位教师可以教多门课。

(4)教师中没有重名，每位教师只属于一个系。6下面是一个具体关系实例的数据，如表4-6：

第四章

数据库规范化理论第二节、范式理论一、第一范式（1NF）学号

S#课程号

C#成绩

G教师

TN系名

Ds1c1g1t1d1s1c2g2t2d2s2c1g3t1d1s2c2g4t2d2s3c2g5t2d2s3c3g6t2d27第四章

数据库规范化理论第二节、范式理论一、第一范式（1NF）虽然上述的关系模式只有五个属性，但它是一个不好的关系模式。因为该模式在使用过程中有以下几个问题：(4)修改异常。(3)删除异常。(2)插入异常。(1)数据冗余。教师所在系名对选该教师所开课的所有学生都重复输入一次。由于关系的主键{S#,C#}不能为空值，如果一个教师不教课，则这位教师的姓名及所属的系名就不能插入表中。如果所有学生都退选某一门课，则有关该门课的其它数据(任课教师名及所在系名)也将被删除。如果改变一门课的任课教师，则需要修改表中选修该门课程的多行记录，如果部分修改，部分不修改，则会导致数据的不一致。8第四章

数据库规范化理论第二节、范式理论一、第一范式（1NF）

上述关系模式只所以是一个不好的关系模式，是因为模式中存在部分函数依赖和传递函数依赖。消除这些部分函数依赖和传递函数依赖，就可以得到一个比较好的关系模式。根据上述示例说明的语义，找出其函数依赖集合F：

F＝{{S#,C#}→G，C#→TN，TN→D}S#C#TNGD图4-210第四章

数据库规范化理论第二节、范式理论一、第一范式（1NF）把原来一个关系表的数据分解为三个关系表存放。表4-9S#C#Gs1

s1

s2

s2

s3

s3c1

c2

c1

c2

c2

c3g1

g2

g3

g4

g5

g6表4-7

C#TNc1

c2

c3t1

t2

t2TNDt1

t2d1

d2表4-812第四章

数据库规范化理论第二节、范式理论二、第二范式（2NF）

如果关系模式R满足第一范式，且它的任何一个非主属性都完全函数依赖于任一个候选码，则R满足第二范式（简记为2NF）例：设有关系模式如下：REPROT(S#,C#,TITLE,LNAME,ROOM#,MARKS)其中S#是学号，C#是课程号，TITLE为课程名，LNAME是教师名，

ROOM#是教室号，MARKS是分数。假设关系中的一个元组：<s,c,t,l,r,m>表示学生s在课程c中的得分为m，课程名为t,由教师l讲授，其教室编号为r。则REPORT的函数依赖如下：(S#,C#)→MARKS

C#→TITLE

C#→LNAMELNAME→ROOM#14第四章

数据库规范化理论第二节、范式理论二、第二范式（2NF）关系模式REPROT(S#,C#,TITLE,LNAME,ROOM#,MARKS)的码是：(S#,C#)非主属性有：TITLE，LNAME和ROOM#，对码的函数依赖为部分函数依赖。并存在其它函数依赖关系：传递函数依赖---C#→LNAME，LNAME→ROOM#。为了消除部分函数依赖，将REPORT关系模式分解为REPORT1和COURSE模式：REPORT1(S#,C#,MARKS)

函数依赖是(S#,C#)→MARKSCOURSE(C#,TITLE,LNAME,ROOM#)函数依赖是C#→TITLE,C#→LNAME,LNAME→ROOM#。

REPORT1和COURSE都消除了对码的部分函数依赖，因此都属于2NF。15第四章

数据库规范化理论第二节、范式理论二、第二范式（2NF）一个关系模式仅仅满足2NF仍是不够的。Why？如在关系模式COURSE(C#,TITLE,LNAME,ROOM#)中，仍存在着插入，删除和修改异常问题：Why？●

新来的教师，还没有分配授课之前，教师的姓名及教室编号都不能加到关系中；●

如果要修改某个教师的教室编号，必须修改与教师授课相对应的各元组中的教室编号，因为一位教师可能会教多门课。存在上述这些问题的原因是:关系模式COURSE中存在传递函数依赖，所以要把关系模式COURSE向第三范式转化，除去非主属性对码的传递函数依赖。16第四章

数据库规范化理论第二节、范式理论三、第三范式（3NF）

如果关系模式R满足2NF，并且它的任何一个非主属性都不传递依赖于任何候选码，则称R是第三范式(3NF),记作R∈

3NF。在上面的例中，关系模式：COURSE(C#,TITLE,LNAME,ROOM#)其中存在非主属性ROOM#对码的传递依赖，即：

C#→LNAME,LNAME→ROOM#因此COURSE不属于3NF。将COURSE分解为：

COURSE1(C#,TITLE,LNAME)

和LECTURE(LNAME,ROOM#),则关系模式COURSE1和LECTURE中都没有传递函数依赖，因此COURSE1和LECTURE都属于3NF。17第四章

数据库规范化理论第二节、范式理论三、第三范式（3NF）至此，关系模式REPORT分解为下列3个属于3NF的一组关系模式：REPORT1(S#,C#,MARKS)COURSE1(C#,TITLE,LNAME)LECTURE(LNAME,ROOM#)和关系模式REPORT相比，这些关系模式是对现实世界更加精确的描述。把这3个关系进行连接，总能重构初始的关系。18第四章

数据库规范化理论第二节、范式理论四、BCNF范式BCNF(BoyceCoddNormalForm)是由Boyce和Codd提出的，通常认为BCNF是3NF的修正，有时也称为扩充的第三范式。定义：关系模式R∈1NF，若X→Y，且Y⊈

X时，X必含有候选码，则R∈BCNF。即在关系模式R中，若R的每一个决定因素都包含候选码，则R∈BCNF。由BCNF的定义可知，一个满足BCNF的关系模式有如下特性：●每个非主属性对每个码都是完全函数依赖；●所有的主属性对每一个不包含它的码，也是完全函数依赖；●没有任何属性完全函数依赖于非码的任何一组属性。●若R∈BCNF，则R∈3NF。若R∈3NF，则R不一定于BCNF。20第四章

数据库规范化理论第二节、范式理论四、BCNF范式函数依赖的图形表示如图4-4所示。图4-4STJ的函数依赖SJTSJT21由图4-4可以看到：第四章

数据库规范化理论第二节、范式理论四、BCNF范式·

（S，J）和（S，T）都是候选码；S，T，J都是主属性。·

STJ∈3NF，因为没有任何非主属性对候选码的传递函数依赖或部分函数依赖。·

STJ∉BCNF，因为T是决定因素，但T不包含码。·

对于不是BCNF的关系模式，仍然存在不合适的地方。

例如，在上例中，当课程已设置，并已确定教师，但还没有学生选课，则教师和课程的信息就不能加入到数据库中。

非BCNF的关系模式可以通过分解成为BCNF，例如STJ可以分解为ST(S,T)和TJ(T,J),则ST和TJ都是属于BCNF范式。23第四章

数据库规范化理论第二节、范式理论3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的限度。

一个关系数据库中的所有关系模式如果都属于BCNF，这在函数依赖范畴内，就已经实现了彻底的分离，达到了最高的规范化程度，并消除了插入异常和删除异常。3NF的不彻底性表现在可能存在主属性对码的部分函数依赖和传递依赖。

四、BCNF范式24第四章

数据库规范化理论第二节、范式理论五、第四范式(4NF)第四范式是BCNF的推广，它适用于多值依赖的关系模式。定义：设关系模式R属于1NF，如果对于R的每个非平凡多值依赖X→→Y(Y⊈X)，X都包含码，则称R为第四范式，表示为R∈4NF。如果一个关系模式属于BCNF，但没有达到4NF，仍然存在操作中的异常问题。例如，在关系模式TSC中(见(第一节表4-3)，数据的冗余度很大。解决的方法是分解TSC为TS(T,S)和TC(T,C)，则TC和TS都是第四范式。26第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例有学生基本情况的关系模式STUDENT：STUDENT（SNO，SNAME，AGE，SEX，CLASS，DEP，CNO，CNAME，GRADE，SCORE）该关系模式的函数依赖集F={SNO→SNAME，SNO→AGE，SNO→SEX，SNO→CLASS，SNO→DEP，

CLASS→DEP，CNO→CNAME，CNO→SCORE，SNO+CNO→GRADE}该模式的码是(SNO,CNO)；该模式是属于1NF：满足的条件是元组的每个分量必须是不可分的数据项。它不是一个好的关系模式。同学自己分析为什么是一个不好的关系模式？27(1).修改设计使其满足第二范式2NF。第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例关系模式STUDENT不符合2NF要求，·

关系模式STUDENT的主码是(SNO，CNO)·

非主属性SNAME，AGE，SEX，CLASS，DEP，CNAME，GRADE，SCORE·

非主属性中存在对码的部分函数依赖，如，SNO→SNAME，CNO→CNAME。因为其中存在部分函数依赖。28第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例

消除部分函数依赖，将STUDENT关系模式进行分解，消除部分函数依赖，得到三个关系模式符合2NF要求：·STUDENT2（SNO，SNAME，AGE，SEX，CLASS，DEP）·COURSE（CNO，CNAME，SCORE）·SC（SNO，CNO，GRADE）分解后，在STUDENT2模式中，仍然存在数据冗余，以及插入和删除异常。因为在STUDENT2模式中，仍然有非主属性中对码的传递函数依赖。30(2).修改设计使其满足第三范式3NF。第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例至此，关系模式STUDENT分解为4个3NF的关系模式：·STUDENT3(SNO，SNAME，AGE，SEX，CLASS);·CLASS（CLASS，DEP）

·COURSE（CNO，CNAME，SCORE）·SC（SNO，CNO，GRADE）31(3).修改设计使其满足第BCNF范式。第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例

分析STUDENT分解的四个关系模式，它们是满足第三范式的，同时也是满足BCNF范式的。32同时，COURSE中CNO是唯一的决定因素，例1，关系模式课程COURSE(CNO，CNAME，SCORE)所以COURSE∈3NF。因此COUSE∈BCNF。第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例其中只有一个码CNO，没有任何属性对码有部分和传递函数依赖，

33例2，在关系模型例2中，有关系模式CSZ(CITY，ST，ZIP)，其中城市

CITY，街道ST，邮政编码ZIP。第四章

数据库规范化理论第二节、范式理论六、关系模式规范化设计实例关系模式CSZ3NF。关系模式CSZ

BCNF。因为函数依赖ZIP→CITY的决定因素ZIP不包含码，所以CSZ∉BCNF。它们就都是BCNF的关系模式了。若将关系模式CSZ分解为两个关系模式：ZC(ZIP，CITY)和ST(ST，ZIP),∈∉34第四章

数据库规范化理论第二节、范式理论七、关系模式规范化小结规范化的基本思想是逐步消除数据依赖中不合适的部分，使关系模型中的各关系模式达到某种程度的“分离”，以解决关系模式中存在的插入、删除、修改异常和数据冗余等毛病。但关系模式的分解不是唯一的。(2)数据库设计是一个相当复杂而且是具有很强应用性的工作，规范化理论仅仅从一个侧面提供了改善关系模式的理论和方法。(3)规范化程度是衡量一个关系模式好坏的标准之一，但不是唯一的标准。(4)一个关系数据库模式中的关系模式都属于BCNF，则在函数依赖的范畴内，已实现了彻底的分离，消除了插入、删除和修改异常。(5)在实际设计中，并不是规范化程度越高越好，这取决于应用。因为对规范化程度高的关系模式进行查询时，可能要做更多的连接操作。35

例如，原来的STUDENT数据模式中存在数据冗余度大，及插入，删除和修改异常现象，但用来查询非常方便。对原数据模式进行分解后，所带来的问题是对某些查询需要进行开销很大的连接操作，可能影响数据库的性能。第四章

数据库规范化理论第二节、范式理论七、关系模式规范化小结36第四章

数据库规范化理论第二节、范式理论七、关系模式规范化小结关系模式规范化的步骤：

规范化就是对原关系进行投影，消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步：3．对3NF关系进行投影，消除原关系中主属性对键的部分函数依赖和传递函数依赖，也就是说使决定因素都包含一个候选键。得到一组BCNF关系。2．对2NF关系进行投影，消除原关系中非主属性对键的传递函数依赖，将

2NF关系转换成若干个3NF关系。1．对1NF关系进行投影，消除原关系中非主属性对键的部分函数依赖，将

1NF关系转换成若干个2NF关系。37关系规范化的基本步骤如下图所示。

1NF2NF3NFBCNF消除决定属性不是候选键的非平凡的函数依赖消除非主属性对键的部分函数依赖消除非主属性对键的传递函数依赖消除主属性对键的部分和传递函数依赖第四章

数据库规范化理论第二节、范式理论七、关系模式规范化小结38一般情况下，我们说没有异常弊病的数据库设计是好的数据库设计，一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。第四章

数据库规范化理论第二节、范式理论七、关系模式规范化小结在实际应用中，最有价值的是3NF和BCNF，在进行关系模式的设计时，通常分解到3NF就足够了。对于那些只要求查询而不要求插入、删除等操作的系统，几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解，否则当要对整体查询时，需要更多的多表连接操作，这有可能得不偿失。但是在分解时要全面衡量，综合考虑，视实际情况而定。39第四章

数据库规范化理论第二节、范式理论八、第四范式设计示例

BCNF的关系模式是否就很完美呢？

关系模式WSC(W,S,C)中W表示仓库，S表示保管员，C表示物品。假设每个仓库有若干个保管员，存放若干种物品。每种物品由存放仓库中的所有保管员负责保管。现有仓库、保管员、物品一组