范式-规范化理论

天狼1222

已于 2024-03-31 12:11:07 修改

阅读量806

点赞数 15

分类专栏： mysql系列文章标签：数据库范式函数依赖

于 2024-03-26 08:48:40 首次发布

本文链接：https://blog.csdn.net/qq_35461948/article/details/136887473

版权

mysql系列专栏收录该内容

42 篇文章 1 订阅

订阅专栏

在继续学习mysql前，先了解下数据库范式

规范化理论

问题

数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间相关联系。它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。

在已经提出了许多种类型的数据依赖中，最重要的是函数依赖( Functional Dependency, FD)和多值依赖(Multi-Valued Dependency, MVD)。

函数依赖极为普遍地存在于现实生活中。比如描述一一个学生的关系，可以有学号(Sno)、姓名(Sname)、系名(Sdept) 等几个属性。由于-一个学号只对应一个学生，一个学生只在一个系学习。因而当“学号”值确定之后，学生的姓名及所在系的值也就被唯一地确定了。属性间的这种依赖关系类似于数学中的函数y=f(x)，自变量x确定之后，相应的函数值y也就唯一地确定了。

类似的有Sname =f(Sno), Sdept =f(Sno)，即Sno函数决定Sname, Sno 雨数决定Sdept，或者说Sname和Sdept函数依赖于Sno,记作Sno Sname, Sno→Sdept。

[例1] 建立一个描述学校教务的数据库，该数据库涉及的对象包括学生的学号(Sno)、所在系(Sdept)、系主任姓名(Mname)、课程号(Cno)和成绩(Grade)。假设用一个单一的关系模式Student来表示，则该关系模式的属性集合为U= {Sno, Sdept, Mname, Cno, Grade}

现实世界的已知事实(语义)告诉我们：

①一个系有若干学生，但一-个学生只属于一个系。

②一个系只有一名(正职)负责人。

③一个学生可以选修多门课程，每门课程有若干学生选修。

④每个学生学习每一门课程有一个成绩。

于是得到属性组U上的一组函数依赖F (如图1所示)。

F= {Sno一>Sdept, Sdept一>Mname, (Sno, Cno)一>Grade}

如果只考虑函数依赖这一种数据依赖，可以得到一个描述学生的关系模式Student <U,P>。

表1是某一时刻关系模式Student的一个实例，即数据表。

student上的一组函数依赖

Student表

但是，这个关系模式存在以下问题：

(1)数据冗余

比如，每一个系的系主任姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同，如表6.1所示。这将浪费大量的存储空间。

(2)更新异常(update anomalies )

由于数据冗余，当更新数据库中的数据时，系统要付出很大的代价来维护数据库的完整性，否则会面临数据不一致的危险。比如，某系更换系主任后，必须修改与该系学生有关的每一个元组。

(3)插入异常( insertion anomalies )

如果一个系刚成立，尚无学生，则无法把这个系及其系主任的信息存入数据库。

(4)删除异常(deletion anomalies)

如果某个系的学生全部毕业了，则在删除该系学生信息的同时，这个系及其系主任的信息也丢掉了。

鉴于存在以上种种问题，可以得出这样的结论： Student 关系模式不是一个好的模式。一个好的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。

为什么会发生这些问题呢?

这是因为这个模式中的函数依赖存在某些不好的性质。这正是本章要讨论的问题。假如把这个单一的模式改造一下，分成三个关系模式：

S(Sno, Sdept, Sno→Sdept);

SC(Sno, Cno, Grade, (Sno, Cno) → Grade);

DEPT(Sdept, Mname, Sdept →Mname)

这三个模式都不会发生插入异常、删除异常的问题，数据的冗余也得到了控制。

1，函数依赖

定义1 设R(U)是属性集U上的关系模式，X, Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定Y或Y函数依赖于X,记作X→Y。

函数依赖和别的数据依赖一样是语义范畴的概念，只能根据语义来确定一个函数依赖。例如，姓名→年龄这个函数依赖只有在该部门没有同名人的条件下成立。如果允许有

同名人，则年龄就不再函数依赖于姓名了。

设计者也可以对现实世界作强制性规定，例如规定不允许同名人出现，因而使姓名→年龄函数依赖成立。这样当插入某个元组时这个元组上的属性值必须满足规定的函数依赖，若发现有同名人存在，则拒绝插入该元组。

注意，函数依赖不是指关系模式R的某个或某些关系满足的约束条件，而是指R的一切关系均要满足的约束条件。

下面介绍一些术语和记号。

●X→Y，但 $Y \notin X$ 则称X→Y是非平凡的函数依赖。

●X→Y，但 $Y \in X$ ,则称X→Y是平凡的函数依赖。对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义。若不特别声明，总是讨论非平凡的函数依赖。

●若X→Y，则X称为这个函数依赖的决定属性组，也称为决定因素(determinant)。

●若X→Y, Y→X,则记作X←→Y。

●若Y不函数依赖于X，则记作 $X \nrightarrow Y$ 。

定义2 在R(U)中，如果X→Y,并且对于X的任何一个真子集X'，都有 $X' \nrightarrow Y$ ，则

称Y对X完全函数依赖，记作 $A \xrightarrow{F} B$ 。

若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖( partial functional

dependency),记作 $A \xrightarrow{P} B$

例1中(Sno, Cno) $\xrightarrow{F}$ Grade是完全函数依赖，(Sno, Cno) $\xrightarrow{P}$ Sdept是部分函数依赖，因为Sno→Sdept成立，而Sno是(Sno, Cno)的真子集。

定义3 在R(U)中，如果X→Y( $Y \notin X$ ), $Y \nrightarrow X$ ，Y→Z, $Z \notin Y$ 则称Z对X传递函数

传递依赖（transitive functional dependency)。记为XZ。

例1中有Sno→Sdept，Sdept→Mname成立，所以 $Sno \xrightarrow{T} Mname$ （T 传递）。

这里加上条件 $Y \nrightarrow X$ ,是因为如果Y→X,则 $X \leftarrow\rightarrow Y$ ，实际上是 $X \xrightarrow{D} Z$ （D 直接），是直接函数依赖而不是传递函数依赖。

2，码

码是关系模式中的一个重要概念。若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码( candidate key)。

这里用函数依赖的概念来定义码。

定义4 设K为R<U,F>中的属性或属性组合,若 $K\xrightarrow{F}U$ ，则K为R的候选码(candidatekey)。

注意：U是完全函数依赖于K，而不是部分函数依赖于K。如果U部分函数依赖于K，即 $K\xrightarrow{P}U$ ，则K称为超码（Surpkey)。候选码是最小的超码，即K的任意一个真子集都不是候选码。

若候选码多于一个，则选定其中的一个为主码（primary key)。

包含在任何一个候选码中的属性称为主属性(prime attribute)；不包含在任何候选码中的属性称为非主属性(nonprime attribute）或非码属性(non-key attribute)。最简单的情况，单个属性是码；最极端的情况，整个属性组是码，称为全码（all-key)。

[例2] 关系模式S (Sno, Sdept, Sage）中单个属性Sno是码，用下划线显示出来。SC （Sno, Cno, Grade）中属性组合（Sno, Cno）是码。

[例3] 关系模式R(P, W,A)中，属性P表示演奏者，W表示作品,A表示听众。假设一个演奏者可以演奏多个作品，某一作品可被多个演奏者演奏，听众也可以欣赏不同演奏者的不同作品,这个关系模式的码为（P, W, A)，即 all-key。

定义5 关系模式R中属性或属性组X并非R的码，但X是另一个关系模式的码,则称X是R的外部码（foreign key)，也称外码。

如在SC(Sno, Cno, Grade）中，Sno不是码，但Sno是关系模式S(Sno, Sdept, Sage）的码，则Sno是关系模式SC 的外码。

主码与外码提供了一个表示关系间联系的手段，如例2中关系模式S与SC 的联系就是通过Sno来体现的。

小结：

候选码：若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码。若一个关系中有多个候选码，则选定其中一个为主码。

以下所有内容中，主码或候选码都简称为码。

例如所学生表系模式S (Sno, Sname, Sage, Ssex）中，学号可以唯一标识一个元组，故该表的候选码为学号，则学号为主码。

主属性：所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。在上面的学生表模式中，学号就是该关系的主属性，姓名、年龄和性别就是非主属性。

3，范式：

关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称1NF；在第一范式中满足进一步要求的为第二范式，其余以此类推。

有关范式理论的研究主要是E.F. Codd 做的工作。1971—1972年 Codd系统地提出了1NF、2NF、3NF 的概念，讨论了规范化的问题。1974年，Codd和 Boyce 共同提出了一个新范式，即 BCNF。1976年 Fagin提出了4NF。后来又有研究人员提出了5NF。

所谓“第几范式”原本是表示关系的某一种级别，所以常称某一关系模式R为第几范式。现在则把范式这个概念理解成符合某一种级别的关系模式的集合,即R为第几范式就可以写成REx NF。

对于各种范式之间的关系有

5NF∈4NF∈BCNF ∈3NF∈2NF ∈1NF

成立,如图2所示。

各种范式之间的关系

一个低一级范式的关系模式通过模式分解（schemadecomposition)可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化（normalization）。

1NF：

定义5 属于第一范式关系的所有属性都不可再分，即数据项不可分。

比如：属性：商品，这个还可以再分，拆分为：商品名称和商品数量

2NF：

定义6 若R∈1NF,且每一个非主属性完全函数依赖于任何一个候选码,则R∈2NF。

[例4] 有关系模式S-L-C(Sno, Sdept,Sloc, Cno, Grade)，其中 Sloc为学生的住处，并且每个系的学生住在同一个地方。S-L-C的码为（Sno, Cno)。则函数依赖有

(Sno, Cno) $\xrightarrow{F}$ Ggrade

Sno→Sdept, (Sno,Cno) $\xrightarrow{P}$ Sdept

Sno→ Sloc, (Sno, Cno) $\xrightarrow{P}$ Sloc,

Sdept→Sloc（每个系的学生只住一个地方)

函数依赖关系如图3所示。

图3 函数示例

图中用虚线表示部分函数依赖。另外，Sdept还函数确定 Sloc，这一点在讨论第二范式时暂不考虑。可以看到非主属性Sdept、Sloc并不完全函数依赖于码。因此S-L-C (Sno, Sdept, Sloc, Cno, Grade）不符合2NF定义，即S-L-C $\notin$ 2NF。

一个关系模式R不属于2NF，就会产生以下几个问题：

(1）插入异常。假若要插入一个学生Sno=S7，Sdept=PHY, Sloc=BLD2，但该生还未选课，即这个学生无Cno，这样的元组就插不进S-L-C中。因为插入元组时必须给定码值，而这时码值的一部分为空，因而学生的固有信息无法插入。

(2）删除异常。假定某个学生只选一门课，如S4就选了一门课C3现在 C3 这门课他也不选了，那么C3这个数据项就要删除。而C3是主属性，删除了C3，整个元组就必须一起删除，使得S4 的其他信息也被删除了，从而造成删除异常，即不应删除的信息也删除了。

(3）修改复杂。某个学生从数学系(MA）转到计算机科学系（CS)，这本来只需修改此学生元组中的Sdept分量即可，但因为关系模式S-L-C中还含有系的住处Sloc属性，学生转系将同时改变住处，因而还必须修改元组中的Sloc分量。另外，如果这个学生选修了k门课，Sdept、Sloc重复存储了k次，不仅存储冗余度大，而且必须无遗漏地修改k个元组中全部Sdept、Sloc信息，造成修改的复杂化。

分析上面的例子可以发现问题在于有两类非主属性，一类如 Grade，它对码是完全函数依赖；另一类如Sdept、Sloc，它们对码不是完全函数依赖。解决的办法是用投影分解把关系模式S-L-C分解为两个关系模式：SC(Sno, Cno, Grade)和 S-L(Sno, Sdept, Sloc)。

关系模式SC与S-L中属性间的函数依赖可以用图4、图5表示如下。

图4 SC中的函数依赖

图5 S-L中的函数依赖

关系模式SC的码为（Sno,Cno)，关系模式S-L 的码为Sno，这样就使得非主属性对码都是完全函数依赖了。

判断一个关系是否属于第二范式：

找出数据表中的所有码；找出所有主属性和非主属性；判断所有的非主属性对码的部分函数依赖。以上面的学生表模式为例，表中的码为学号(码为学号)，非主属性为姓名、性别和年龄(其余都为主属性)，当学号确定时，姓名、性别和年龄也都惟一的被确定为，故学生表的设计满足第二范式(学生表为单主属性的关系)

第二范式是指每个表必须有一个(有且仅有一个)数据项作为关键字或主键(primary key)，其他数据项与关键字或者主键一一对应，即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。

3NF：

定义7 设关系模式R<U,F>∈ 1NF，若R中不存在这样的码X，属性组Y及非主属性Z（ $Z \nsupseteq Y$ )使得X→Y, Y→Z成立，Y $\nleftarrow$ X，则称R<U, F>∈3NF。

由定义7可以证明，若R∈3NF，则每一个非主属性既不传递依赖于码，也不部分依赖于码。也就是说，可以证明如果R属于3NF，则必有R属于2NF。

在图4中关系模式SC没有传递依赖，而图5中关系模式S-L存在非主属性对码的

传递传递依赖。在S-L 中，由Sno→Sdept(Sdept $\nrightarrow$ Sno)，Sdept→Sloc，可得Sno $\xrightarrow{transmit}$ Sloc。因此 $SC\in3NF$ ，而 $S-L\notin3NF$ 。

第三范式要求在满足第二范式的基础上，任何非主属性不依赖于其他非主属性，即在第二范式的基础上，消除了传递依赖。

在上面的图5 S-L关系中，Sloc对Sno传递函数依赖，故该关系不属于第三范式。

图5 S-L中的函数依赖

BCNF

BCNF （Boyce Codd Normal Form)是由 Boyce与 Codd提出的，比上述的3NF又进了一步，通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。

定义8 关系模式R<U, F>∈1NF，若X $\notin$ Y且YgX时X必含有码，则R<U, F>∈BCNF。

也就是说，关系模式R<U, F>中，若每一个决定因素都包含码，则R<U, F>∈BCNF.

由 BCNF的定义可以得到结论，一个满足 BCNF 的关系模式有：

●所有非主属性对每一个码都是完全函数依赖。

●所有主属性对每一个不包含它的码也是完全函数依赖。

●没有任何属性完全函数依赖于非码的任何一组属性。

由于R∈BCNF，按定义排除了任何属性对码的传递依赖与部分依赖，所以R∈3NF。但是若RE3NF，R未必属于 BCNF。

下面用几个例子说明属于3NF的关系模式有的属于BCNF，但有的不属于BCNF。

[例5]考察关系模式C（Cno, Cname，Pcno)，它只有一个码Cno，这里没有任何属性对Cno部分依赖或传递依赖，所以C∈3NF。同时C中Cno是唯一的决定因素，所以C∈BCNF。对于关系模式SC（Sno, Cno,Grade)可作同样分析。

[例6]关系模式S（Sno, Sname, Sdept, Sage)，假定Sname也具有唯一性，那么S就有两个码，这两个码都由单个属性组成，彼此不相交。其他属性不存在对码的传递依赖与部分依赖，所以S∈3NF。同时S中除Sno、Sname外没有其他决定因素，所以S也属于BCNF。

以下再举几个例子。

[例7]关系模式SJP（S,J, P)中，S是学生,J表示课程,P表示名次。每一个学生选修每门课程的成绩有一定的名次,每门课程中每一名次只有一个学生（即没有并列名次)。由语义可得到下面的函数依赖：

（S, J)→P； (J, P)→S

所以（S,J)与（J,P）都可以作为候选码。这两个码各由两个属性组成，而且它们是相交的。这个关系模式中显然没有属性对码传递依赖或部分依赖。所以SJP∈3NF，而且除（S,J)与（J,P)以外没有其他决定因素,所以SJP∈BCNF。

[例8] 关系模式STJ（S,T,J)中，S表示学生，T表示教师，J表示课程。每一教师只教一门课，每门课有若干教师，某一学生选定某门课，就对应一个固定的教师。由语义可得到如下的函数依赖。

图6 STJ中函数依赖

函数依赖关系可以用图6表示,这里（S, J)、（S,T)都是候选码。

STJ是3NF,因为没有任何非主属性对码传递依赖或部分依赖,但STJ不是 BCNF关系,因为T是决定因素,而T不包含码。

对于不是BCNF的关系模式，仍然存在不合适的地方。读者可自己举例指出STJ的不合适之处。非 BCNF的关系模式也可以通过分解成为BCNF。例如STJ可分解为ST （S,T)与TJ（T, J)，它们都是 BCNF。

3NF 和 BCNF 是在函数依赖的条件下对模式分解所能达到的分离程度的测度。一个模式中的关系模式如果都属于BCNF，那么在函数依赖范畴内它已实现了彻底的分离，已消除了插入和删除的异常。3NF的“不彻底”性表现在可能存在主属性对码的部分依赖和传递依赖。

多值依赖

以上完全是在函数依赖的范畴内讨论问题。属于 BCNF 的关系模式是否就很完美了呢？下面来看一个例子。

[例9]学校中某一门课程由多个教师讲授，他们使用相同的一套参考书。每个教师可以讲授多门课程，每种参考书可以供多门课程使用。可以用一个非规范化的关系来表示教师T、课程C和参考书B之间的关系（如表3所示)。

表3 非规范化关系示例

表4 规范化的二维表Teaching

把这张表变成一张规范化的二维表,如表4所示。

关系模型Teaching (C, T,B）的码是（C, T, B)，即 all-key，因而 Teaching EBCNF"。但是当某一课程（如物理）增加一名讲课教师（如周英）时，必须插入多个(这里是三个)元组:（物理，周英，普通物理学)，(物理，周英，光学原理)，(物理，周英，物理习题集)。

同样，某一门课（如数学）要去掉一本参考书（如微分方程)，则必须删除多个（这里是两个）元组:（数学，李勇，微分方程)，(数学，张平，微分方程)。

因而对数据的增删改很不方便，数据的冗余也十分明显。仔细考察这类关系模式，发现它具有一种称之为多值依赖（Multi-Valued Dependency,MVD)的数据依赖。

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

例如，在关系模式Teaching中,对于一个(物理，光学原理)有一组T值{李勇，王军}，这组值仅仅决定于课程C上的值（物理)。也就是说对于另一个（物理，普通物理学)，它对应的一组T值仍是{李勇，王军}，尽管这时参考书B的值已经改变了。因此T多值依赖于C，即C→→T。

对于多值依赖的另一个等价的形式化的定义是：在R(U)的任一关系r中，如果存在元组t、s使得 t[X]=s[X]，那么就必然存在元组 w、 $v \in r$ (w、v可以与s、t相同)，使得w[X]=[X]=t[X]，而w[Y]=t[Y，w[Z]=s[Z], v[Y]=s[Y]，v[Z]=4[Z](即交换s、1元组的Y值所得的两个新元组必在r中)，则Y多值依赖于X，记为X→Y。这里,X、Y是U的子集，Z=U-X-Y。

若X→→Y，而 $Z=\phi$ ，即Z为空，则称X→→Y为平凡的多值依赖。即对于R(X, Y)，如果有X→→Y成立，则X→→Y为平凡的多值依赖。

下面再举一个具有多值依赖的关系模式的例子。

[例10] 关系模式 WSC(W,S, C)中，W表示仓库，S表示保管员，C表示商品。假设每个仓库有若干个保管员，有若干种商品。每个保管员保管所在仓库的所有商品，每种商品被所有保管员保管。列出关系如表5所示。

表5 WSC表

图7 W→→S且W→→C

按照语义对于W的每一个值W,S有一个完整的集合与之对应而不问C取何值。所以W→→S。

如果用图7来表示这种对应，则对应W的某一个值 $W_{i}$ 的全部S值记作 $\{S\}_{W_{i}}$ （表示此仓库工作的全部保管员)，全部C值记作 $\{C\}_{W_{i}}$ (表示在此仓库中存放的所有商品)。应当有 $\{S\}_{W_{i}}$ 中的每一个值和 $\{C\}_{W_{i}}$ 中的每一个C值对应。于是 $\{S\}_{W_{i}}$ 与 $\{C\}_{W_{i}}$ 之间正好形成一个完全二分图，因而W→→S。

由于C与S的完全对称性,必然有W→→C成立。多值依赖具有以下性质:

（1）多值依赖具有对称性。即若X→→Y，则X→→Z，其中Z=U-X-Y。

从例10容易看出,因为每个保管员保管所有商品，同时每种商品被所有保管员保管，显然若W→→S，必然有W→→C。

（2）多值依赖具有传递性。即若X→→Y, Y→→Z，则X→→Z-Y。

（3）函数依赖可以看作是多值依赖的特殊情况，即若X→Y，则X→→Y。这是因为当X→Y时，对X的每一个值x，Y有一个确定的值y与之对应，所以X→→Y。

（4）若X→→Y, X→→Z，则X→→YZ。

（5）若X→→Y, X→→Z，则X→→Y $\cap$ Z。

（6）若X→→Y, X→→Z，则X→→Y-Z，X→→Z-Y。

多值依赖与函数依赖相比,具有下面两个基本的区别:

（1）多值依赖的有效性与属性集的范围有关。若X→→Y在U上成立，则在W( $XY \subseteq W \nsubseteq U$ )上一定成立；反之则不然，即X→→Y在W( $W \subset U$ )上成立，在U上并不一定成立。这是因为多值依赖的定义中不仅涉及属性组X和Y，而且涉及U中其余属性Z。

一般地，在R(U)上若有X→→Y在W( $W \subset U$ )上成立，则称X→→Y为R(U)的嵌入型多值依赖。

但是在关系模式R(U)中，函数依赖X→Y的有效性仅决定于X、Y这两个属性集的值。只要在R(U)的任何一个关系r中，元组在X和Y上的值满足定义1，则函数依赖X→Y在任何属性集W( $XY \subseteq W \subseteq U$ )上成立。

(2)若函数依赖X→Y在R(U)上成立，则对于任何Y'CY均有X→Y成立。而多值依赖X→→Y若在R(U)上成立,却不能断言对于任何YCY有X→→Y成立。

例如，有关系R(A,B,C, D)如下,A→→BC，当然也有A→→D成立。有R的一个关系实例，在此实例上A→→B是不成立的，如表6所示。

表6 R的一个实例

4NF

定义10 关系模式R<U,F> $\in$ 1NF，如果对于R的每个非平凡多值依赖X→→Y（ $Y \nsubseteq X$ )，X都含有码，则称R<U, F> $\in$ 4NF。

4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。因为根据定义，对于每一个非平凡的多值依赖X→→Y，X都含有候选码，于是就有X→Y，所以4NF所允许的非平凡的多值依赖实际上是函数依赖。

显然，如果一个关系模式是4NF,则必为 BCNF。

在前面讨论的关系模式 WSC 中，W→→S，W→→C，它们都是非平凡的多值依赖。而W不是码，关系模式WSC的码是（W, S,C)，即 all-key。因此 $WSC \notin 4NF$ 。

一个关系模式如果已达到了BCNF但不是4NF，这样的关系模式仍然具有不好的性质。以 WSC为例， $WSC \notin 4NF$ ，但是 WSC $\in$ BCNF。对于 WSC 的某个关系，若某一仓库W有n个保管员，存放m件物品，则关系中分量为W的元组数目一定有m×n个。每个保管员重复存储m次，每种物品重复存储n次，数据的冗余度太大，因此还应该继续规范化使关系模式WSC达到4NF。

可以用投影分解的方法消去非平凡且非函数依赖的多值依赖。例如可以把 WSC分解为WS（W, S)，WC（W,C)。在 WS中虽然有W→→S，但这是平凡的多值依赖。WS中已不存在非平凡的非函数依赖的多值依赖，所以 $WS\in4NF$ ，同理 $WC\in4NF$ 。

函数依赖和多值依赖是两种最重要的数据依赖。如果只考虑函数依赖，则属于 BCNF的关系模式规范化程度已经是最高的了；如果考虑多值依赖，则属于4NF的关系模式规范化程度是最高的。事实上，数据依赖中除函数依赖和多值依赖之外，还有其他数据依赖。例如有一种连接依赖。函数依赖是多值依赖的一种特殊情况，而多值依赖实际上又是连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖可由语义直接导出，而是在关系的连接运算时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。如果消除了属于4NF的关系模式中存在的连接依赖，则可以进一步达到5NF的关系模式。

4，规范化小结

在关系数据库中，对关系模式的基本要求是满足第一范式，这样的关系模式就是合法的、允许的。但是，人们发现有些关系模式存在插入、删除异常，以及修改复杂、数据冗余等问题，需要寻求解决这些问题的方法，这就是规范化的目的。

规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即“一事一地”的模式设计原则。让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去。因此所谓规范化实质上是概念的单一化。

人们认识这个原则是经历了一个过程的。从认识非主属性的部分函数依赖的危害开始，2NF、3NF、BCNF、4NF 的相继提出是这个认识过程逐步深化的标志，图8可以概括这个过程。

图8 规范化过程

关系模式的规范化过程是通过对关系模式的分解来实现的，即把低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的。下面将进一步讨论分解后的关系模式与原关系模式“等价”的问题以及分解的算法。

5，范式的优缺点

范式再怎么好，也只是种手段。它可以帮人们又快又好地设计数据库，但不能代替人们思考。在某些场合，机械地按照范式把所有的冗余都消除干净并不能获得最佳效果。

范式的缺点：数据表的个数越多，把从网页上的表单输入的数据分门别类地存入这些数据表的复杂性就越大。这种复杂性不仅会给程序员带来烦恼，也会给最终用户带来不便（他们不得不一个接一个地填写表单)。

不仅如此，数据表的个数越多，从中提取相关数据生成查询结果的复杂性也越人。为了提高查询的效率，适度的兀余有时反而是必要的。从多个数据表提取数据往往要比从单个数据表提取数据来得慢;这对那些已不再需要或是很少需要修改但经常需要对复杂查询做出快速响应的数据库来说更是如此。(数据库的世界里有个领域叫做“数据仓库"。在设计数据仓库的时候，人们往往会有意识地增加一些兀余度以获得更好的响应速度。不过，MySQL数据库系统至少在目前还不是人们在建设数据仓库时的首选，所以对这一特殊应用领域里的细节问题也就不多加介绍。)

范式的优点：冗余意味着存储空间的浪费。这种浪费在硬盘的单体容量已经达到400GB 的今天似乎并不是什么大问题，但事实却是一个大数据库往往同时也是一个慢数据库（至少在数据库的大小超出了计算机内存容量的时候会如此)。

一般而言，严格按照范式设计出来的数据库能够提供最丰富、最灵活的查询选项。(人们往往要等到必须使用一种新的查询或是必须对数据进行一种新的分类时才会真正意识到这一点，但可惜的是这些新需求几乎总是出现在数据库已投入运行几个月之后，那时再去改动数据库设计方案的代价是令人难以承受的。)