在这部分内容开始的时候。我们先提出三个问题：

1. 什么样的关系模式是不好的设计？

2. 如何判断一个关系模式的良好级别？

3. 如何把一个不好的关系模式转换成好的关系模式？如何判断转换的效果？

其实学习规范化理论这部分的内容的主要目的就是要回答这三个问题。让我们首先来看第1个问题“什么样的关系模式是不好的设计？”。为了更便于理解和回答这个问题，我们给出一个关系模式，大家来分析一下：

问题背景：

在学生管理的数据库中要存储学号、姓名、所在系、系地址、课程号和成绩。假定设计以下关系模式来表示上述信息：

       SLC(Sno,Sname,Sdept,Loca,Cno,Grade)

请尝试分析这个关系模式有无问题？

在开始讨论这个模式的问题以前，我们先分析一下这个关系模式的主键应该是什么？Sno？Cno？抑或是Sdept？你应该不会忘记作为主键的条件：能够唯一标识关系中的每一个元组。所以根据这一限定条件，能够作为主键的只能是Sno和Cno的组合：（Sno,Cno），我们把这种由多个属性组合起来构成的主键称作是“联合主键”。因为一个学生可能选修多门课，一门课会被多个学生选修的缘故，导致Sno、Cno谁都不能独立地唯一标识关系中的每一个元组，Sdept就更不用说了。那么Sdept能不能作为联合主键的一部分呢？不能，因为主键同时还应该具有“最小性”原则，因此Sdept属性是多余的。最终我们知道这个关系模式的主键应该是（Sno,Cno）。

如果仅看这个关系模式，你未必会发现问题。我们给你一些样本性的数据，你再看看：

                                          样本数据 1

分析：从样本数据1中，你大概可以注意到这样一个现象：系的相关信息被反复地存储。我们现在给出的系名和地址还仅仅是做一个简略的示范。如果给出真实、完整的系名和系地址的话，可能你会更加直观地观测到这一点。我们就把这种不必要地重复存储相同数据的现象称作“数据冗余”。

这会带来什么样的后果呢？两个方面：

第1，数据被反复存储会浪费数据库的存储空间。

第2，当系的名称或地址发生变化的时候，我们需要修改的数据量非常大。

所以“数据冗余”对于数据库来讲是一种不好的现象。

                                        样本数据 2

分析：“样本数据2”中的数据出现了变化，变化的原因是因为用户将“王文涛”的学号改成了“04015”。先不管用户是有意，还是无意地做出了这样的修改，我们只想讨论一下这样的修改会出现什么问题？问题是：“崔勇”和“王文涛”的学号居然相同！这违背了我们的常识：学号对于每一个学生来讲都应该是唯一的。但是遗憾的是数据库并没有发现这个错误，昏昏然地接受了用户这绝对错误的数据修改。为什么呢？答案就是我们一开始就讨论过的主键问题。因为这个关系模式的主键是（Sno,Cno），所以对主键唯一性的违反必须满足Sno和Cno同时相同。而此处仅仅是Sno相同，所以根据此处的关系模式设计，数据库不可能意识到这个违背常识的错误，依然会坚定地认为这是合法的数据，从而接受修改。显然数据库不应该为你背锅，只能怪罪于你自己的设计出现了问题。我们把这样的情况称作是“修改异常”。

                                         样本数据 3

分析：秋高气爽的九月，我们迎来了新同学。他们在“风雨操场”中挥汗如雨地军训着，课程暂时和他们无关。所以就出现了样本数据3中的情形：一些同学没有选择课程。其实你在真正的关系中是不可能看到未选课程的学生信息的，因为数据库会拒绝你插入类似的信息。为什么呢？原因离不开主键。因为Cno是主键的一部分，而主键的特点之一是不能为空，所以数据库会毫不犹豫地拒绝你插入未选课的学生数据。这样的情况被称做“插入异常”。

                                         样本数据 4

分析：热情似火的七月，我们计算机系送走了毕业的师兄师姐们。他们的信息，我们也将从数据库中删除。之后你就看到了类似样本数据4的结果。发生了什么？计算机系不存在了！因为计算机系目前所有的学生都毕业，信息都被删除了，所以计算机系也随着毕业的学生一起被毕业了。这就尴尬了！虽然当前的学生毕业了，但我们肯定是想保留计算机系，迎接下一届新生！所以这样的删除也是存在问题的。我们把这样的现象称作是“删除异常”。

通过对以上四种情况的分析，让我们来回答第1个问题：

问题：什么样的关系模式是不好的设计？

回答：如果一个关系模式中含有数据冗余、插入异常、更新异常和删除异常，则该关系模式是设计不良好的。

我们既然知道了只要出现“数据冗余”、“修改异常”、“插入异常”和“删除”现象的关系模式就是设计不良好的关系模式，那么我们如何才能避免这些现象的出现呢？

要避免，首先得知道产生异常的原因。这里我们直接抛出原因：原关系模式的设计直接将多个实体（学生、课程、系）不加区分、简单粗暴地放到了一个关系模式中，或者说一个关系模式中包含了多个实体或联系，违背了“一事一地”的原则。

解决办法：遵循“一事一地”的原则设计关系模式，即一个实体或一个多对多联系用一个关系模式表示。

下面给出采用“一事一地”原则改进后的关系模式：

students(Sno,Sname,Sdept) 关系模式：学生（实体）

courses(Cno)  关系模式：课程（实体）

sdepts(Sdept,Loca)  关系模式：系（实体）

sc(Sno,Cno,Grade)  关系模式：选课（联系）

大家可以看出：每一个关系模式都仅仅描述了一种实体或一种联系，这就是“一事一地”的概念。至于这个结果到底是如何得到的？采用的改进方法是什么？你将会在第3个问题的回答中看到这一点，也就是模式分解的概念。

还记得我们提出的第2个问题吗？

“如何判断一个关系模式的良好级别？”

要回答这个问题，却不是那么容易了！我们需要预先理解一些概念和理论。你得有一些思想准备，因为接下来将会遇到很多的概念。

1. 函数依赖

定义：设R(U)是属性集U上的关系模式，X，Y是U的子 集。若对于R(U)的任意一个可能的关系r，r中不

           可能存在两个元组在X上的属性值相等，而在Y 上的属性值不等，则称X函数确定Y或Y函数依赖

           于X。

           记作：X → Y

这个定义是一个基础性的概念，非常关键！我们尝试把它简化一下，便于大家理解。X → Y的含义就是说：在一个关系中，任意两个元组如果在X上相等，那么它们在Y上一定相等。对于这样的情况，我们就称作X决定Y，或者反过来说Y函数依赖于X。

也许你明白了，也许你还是有些糊涂。让我们来看一个实例：

以学生关系为例：students(Sno,Sname,Sage) 其中Sno是学号、Sname是姓名、Sage是年龄

那么谁可以决定谁呢？或者说谁函数依赖于谁呢？大家一定要明白：谁可以决定谁和谁函数依赖于谁只是一个事情从不同的方向做出的两种描述，其含义是一致的。

比如Sno可以决定Sname吗？（反方向的另一种说法：Sname函数依赖于Sno吗？）确定这一点，其实就是需要我们判断在学生关系中，任意两个元祖如果在Sno上相同，那么它们在Sname上是否也一定相同？大家都知道，其实学生关系中的每一个元组就代表了一个学生，因此如果两个学生的学号相同，那么他们一定是同一个人；同一个人的姓名会不同吗？当然不会！所以任意两个学生的学号如果相同，那么他们的姓名也一定相同，即学号可以决定姓名，或者反过来说姓名函数依赖于学号。记作：Sno→Sname

我们再考虑一个：姓名可以决定年龄吗？如果两个学生的姓名相同，那么他们的年龄是否一定相同呢？不一定！为什么？因为考虑到重名的情况，姓名相同的两个同学未必是同一个人，那么他们的年龄也就未必相同了。所以姓名不能决定年龄，或者说年龄不函数依赖于姓名。

好了！这就是函数依赖的概念。

做个练习：你能指出关系模式SC(Sno,Cno,Grade)中存在的函数依赖吗？

答案：关系模式中存在的函数依赖只有：(Sno,Cno)→Grade。Sno,Cno都是不能独立决定Grade的，原因可以自己去分析。

注意：题目等价于“你能指出关系模式SC(Sno,Cno,Grade)中存在的决定关系吗？”因为我们一直强调：函数依赖和决定关系只是对一个事情从两个方向的描述，本质是相同的。请记住这一点。

2. 决定因子和被决定因子

对于函数依赖：X→Y，X称作决定因子，Y称作被决定因子。

好的，这一节对函数依赖做了充分的阐述，希望大家真正地理解了函数依赖的概念。

在了解了函数依赖的概念以后，接下来介绍一下不同类型的函数依赖。

1. 平凡函数依赖

定义：设X→Y是一个函数依赖，若Y⊆ X，则称X→Y是一个平凡的函数依赖。

解析：平凡函数依赖的概念非常简单，就是自己可以决定自己的子集。比如关系模式SC(Sno,Cno,Grade)

（Sno,Cno）→Sno   或 （Sno,Cno）→Cno 都属于平凡的函数依赖。因为两个函数依赖中的被决定因子（Sno或Cno）都是决定因子（Sno,Cno）的子集。

2. 完全函数依赖

定义：设X→Y是一个函数依赖，并且对于任何X’⊂X , X’ →Ｙ都不成立，则称X → Y是一个完全函 

           数依赖，即Y函数依赖于整个X。

解析：完全函数依赖指的是被决定因子不依赖于决定因子的任何一个子集（除了决定因子本身）。比如关系模式SC(Sno,Cno,Grade)：（Sno,Cno）→Grade 就是一个完全函数依赖。因为决定因子（Sno,Cno）的任何一个子集（比如Sno或Cno）都不能独立决定Grade。换句话说，Grade依赖于（Sno,Cno）的全部，而不是其中某一个部分（子集）。

3. 部分函数依赖

定义：设X→Y是一个函数依赖，但不是完全函数依赖，则称X→Y是一个部分函数依赖，或称Y函数依

          赖于X的某个真子集，记作X→Y。

解析：部分函数依赖和完全函数依赖的定义刚好是相反的，所以很好理解。比如在我们最开始提出的关系模式SLC(Sno,Sname,Sdept,Loca,Cno,Grade)中，存在如下的函数依赖：

(Sno,Cno)→Sname，Sno→Sname。

大家可以看到Sname不仅函数依赖于(Sno,Cno)，而且还依赖于(Sno,Cno)的子集Sno。这就说明Sname部分函数依赖于(Sno,Cno)。

4. 传递函数依赖

定义：设R(U)是一个关系模式，X,Y,Z⊆ u，如果 X → Y(Y 不属于X,Y 也不能决定 X)，Y → Z成立，则称Z传递函数依赖于X。

解析：此处还是以关系模式SLC为例来说明传递函数依赖。在SLC中存在以下函数依赖：Sno→Sdept，Sdept→Loc。也就是说Sno可以决定Sdept，Sdept又可以决定Loc，那么我们就说Sno可以决定Loc（Sno→Loc）。这里的Sdept相当于起到了一个桥梁的作用。这就是传递函数依赖。

1.函数依赖与属性的关系

前面去判定一个关系模式中的函数依赖，我们都是拿着定义去判定的。其实两个属性之间是否存在函数依赖，还可以利用它们之间的关系来快速判定。方法如下：

设R(U)是属性集U上的关系模式，X,Y是U的子集：

如果X和Y之间是一对一关系，则X→Y且Y→X。

 比如当学生无重名时，Sno→Sname, Sname →Sno 

如果X和Y之间是一对多关系，则Y→X。

 比如Sdept:Sno=1:n, Sno →Sdept

如果X和Y之间是多对多关系，则X和Y之间不存在函数依赖。    

比如Sno:Cno=n:m, 则Sno与Cno之间不存在函数依赖。

接下来我们为后面的内容铺垫几个非常简单的基本概念。

2. 属性集 U

属性集，顾名思义，就是若干个属性所构成的集合。比如关系模式students(Sno,Sname,Sage)：那么在这个关系模式中的属性集就是Sno，Sname，Sage三个属性所构成的集合，记作：

U = {Sno，Sname，Sage}

提示：属性集一般用大写的字母U来表示。

3. 函数依赖集 F

函数依赖集，顾名思义，就是若干个函数依赖所构成的集合。比如关系模式students(Sno,Sname,Sage)中，存在的函数依赖有：Sno→Sname,Sno→Sage。那么这个关系模式的函数依赖集就是Sno→Sname,Sno→Sage所构成的集合，记作：

F = {Sno→Sname,Sno→Sage}

提示：函数依赖集一般用大写的字母F来表示。

4. 关系模式

大家都知道，任何一个关系模式都由且只由两个部分所构成：属性和属性之间的联系。属性之间的联系就是属性之间的依赖关系，所以也可以说。任何一个关系模式其实都是由属性集（关系中的所有属性）和函数依赖集（属性集中属性之间的联系）所构成的。这句话，我们用数学的方式描述为：

R<U,F>，其中R是关系模式，U是这个关系中的属性集，F是这个关系中属性之间存在的函数依赖的集合。

举个例子来融汇贯通上面的三个概念。对于我们一直在讨论的关系模式students(Sno,Sname,Sage)，如何完整地描述它呢？

根据前面的讨论，我们知道了它的属性集和函数依赖集分别是：{Sno，Sname，Sage}和 {Sno→Sname,Sno→Sage}，所以可用下面的方式来完整地描述这个关系模式：

students({Sno，Sname，Sage},{Sno→Sname,Sno→Sage})

1. 函数依赖的逻辑蕴涵

定义：对于满足一组函数依赖F的关系模式R<U,F>，其任何一个关系r，若函数依赖X→Y均成立， 则称F

          逻辑蕴涵X→Y。

解析：相信这个概念大家不难理解。比如：F={A→B,B→C,C→D}，那么我们就说F逻辑蕴涵A→B,B→C,C→D。但是要注意，其实F逻辑蕴含的函数依赖可不只是你眼中看到的这些，还有一些看不到的。什么是看不到的呢？就是你可以根据现在的函数依赖所推导出来的其它函数依赖。例如根据函数依赖的传递性，以及A→B,B→C可以推出A→C，根据B→C,C→D可以推出B→D，根据A→B,B→C,C→D可以推出A→D。而A→C，B→D，A→D这三个函数依赖都是我们根据现在的函数依赖推导出来的，我们说F也逻辑蕴涵这三个函数依赖。所以F逻辑蕴含的函数依赖，除了明确给出的，还包括那些可以根据给出的函数依赖推导出来的其它函数依赖。

2. Armstrong公理

设关系模式R<U,F>，U为属性集，F为U上的一组函数依赖，对R<U,F>存在如下推理规则：

◇ 自反律：如果Y⊆ X ⊆ U，则X→Y为F所蕴涵。

◇ 增广律：如果X→Y为F所蕴涵，且Z ⊆ U，则XZ→YZ为F所蕴涵。

◇ 传递律：如果X→Y且Y→Z为F所蕴涵，则X→Z为F所蕴涵。

由Armstrong公理可以得到以下推论：

◇ 自合规则：A→A

◇ 分解规则：如果A→BC，则A→B且A→C。

◇ 合并规则：如果A→B，A→C，则A→BC。

◇ 复合规则：如果A→B，C→D则成立，AC→BD。

大家其实可以看出，Armstrong公理主要用于对函数依赖进行推导。下面举一些例子来应用Armstrong公理中的三大定律、四大规则。

【例1】设有关系模式R，A、B、C、D、E、F是它的属性集的子集，R满足下列函数依赖，F={A → BC,

 CD → EF}，证明：函数依赖AD→F成立。

证明： A → BC             　条件给定         

           A → C　　　　　分解规则

           AD → CD　　　　增广律

           AD → EF　　　　 传递律

           AD → F　　　　　分解规则

其实利用Armstrong公理来推导一个函数依赖是否存在还是挺麻烦的一件事情。接下来我们给大家介绍一些相对简便的方法，但首先你得了解“函数依赖的闭包”这个概念。

1. 函数依赖的闭包

定义：关系模式R<U,F>中为F所蕴涵的函数依赖的全体称为F的闭包，记为F+ 。

解析：很简单的一个定义。但必须稍作解释：函数依赖的闭包F+作用于一个关系的属性集之上，包含了明确给出的函数依赖，以及那些可以由给出的函数依赖推导出来的所有函数依赖，是这两种函数依赖的总和。

【例1】: 已知关系模式R<U,F>中，U={A,B,C,D,E,G}，F={AB→C,C→A,BC→D,ACD→B,D→EG,BE→C,

          CG→BD,CE→AG}，判断BD→AC是否属于F+。

           因为D→EG ，所以D→E，所以BD→BE；

           又因为BE→C,C→A，所以 BE→A，所以BE→AC；

           结合上述两个推导结论，根据传递律，所以BD→AC，所以BD→AC是否属于F+。

2. 属性集关于函数依赖集的闭包

定义：设F为属性集U上的一组函数依赖，X ⊆ U，XF+={A|X→A能由F根据Armstrong公理导出}，

          XF＋称为属性集X关于函数依赖集F的闭包。

解析：我们常常把“属性集关于函数依赖集的闭包”简称为“属性闭包”。但是还是必须要明确的是属性闭包是依赖于函数依赖集的。没有函数依赖集的存在，就谈不上属性闭包。“属性闭包”其实指的就是给定的属性集中的属性和凭借这些属性根据给定的函数依赖可以直接或间接推导出的其它所有属性所构成的集合。这么说不知道是否能理解？我们来看个例子：

【例2】：关系模式R<U,F>，U={A,B,C,D,E}，F={A→B,D→C,BC→E,AC→B} ，求(AD)F+。

解析：（AD）是给定的属性集，那么(AD)在函数依赖集F上的闭包(AD)F+是什么呢？其实就是AD加上由AD的任何一个非空子集（A、D或AD）根据F中的函数依赖可以直接或间接推导出的其它属性。        

我们把它表示为：    

(AD)F+ = AD ∪在F的基础上能够利用A或D推出(决定)的其它属性。

那么这个怎么推导呢？这里我们给大家介绍一个基本的算法：

------------------求属性闭包的算法----------------------------

算法：求属性集X(X ⊆ U)关于U上的函数依赖集的闭包XF＋。

◆ 令X(i)=X, i=0

◆ 求B，B={A|(∃ V)(∃ W)(V→W)∈F ∧ V∈X(i) ∧ A∈W} 

◆ X(i+1)＝B∪X(i)

◆ 判断X(i+1)＝X(i)吗？

◆ 若相等或X(i)＝u，则X(i)就是XF+，算法终止。

◆ 若否，则i=i+1，返回第2步。

-----------------------------------------------------------------

根据这个算法，例2的解法如下：

第1步：X(0)＝AD，i=0

第2步：逐一扫描F中的各个函数依赖，找出左部为AD的子集的函数依赖，得到A→B,D→C。因此X(1)=AD∪BC=ADBC。

第3步：判断X(1)==U? 不等，继续。

第4步： 逐一扫描F中的各个函数依赖，找出左部为ADBC的子集的函 数依赖，得到BC→E,AC→B。因此X(2)=ADBC∪BE=ADBCE。

第5步：判断X(2)==U? 相等，因此(AD)F+＝ABCDE。

【练习1】基于例2的条件，求(AE)F+。

参考答案：(AE)F+ = ABE。

在基本了解了“属性闭包”的概念以后，让我们来思考一个问题：属性闭包的价值是什么呢？换句话说：为什么要讨论属性闭包呢？还记得本节开头的那段话吗？凭借Armstrong公理来推导函数依赖实在是太麻烦了！我们想找一些简便的方法，而“属性闭包”就可以帮助我们找到这样一条路。来看一个基于“属性闭包”的定理：

定理：设F为属性集U上的一组函数依赖，X,Y⊆U,X→Y能由F根据Armstrong公理导出的充要

           条件是Y ⊆ XF+.

解析：解释一下这个定理：也就是说我们现在来判断函数依赖X→Y到底成不成立？不再需要用Armstrong公理来一步一步地推导了，而是直接求取X的属性闭包XF+，然后判断Y是否在其中？如果在，那么X→Y就成立；否则不成立。这里面的原因是什么呢？大家可以翻上去看看属性闭包的定义：X的属性闭包是X加上由X根据函数依赖集F可以直接或间接推导出来的所有属性构成的集合，换句话说，如果Y属于X的属性闭包，那么Y就可以由X根据函数依赖集F直接或间接地推导出来，这不正好说明X→Y成立吗！就是这个意思。接下来，我们举例来说明这个定理的运用。

【例3】已知关系模式R中，U={A,B,C,D,E,G}，F={AB→C,C→A,BC→D,ACD→B,D→EG,BE→C,

CG→BD,CE→AG}，判断BD→AC是否属于F+。

解析：这个题求BD→AC是否属于F+？其实就是求能否根据F+中列出的函数依赖直接或间接地推出BD→AC？根据刚刚列出的定理，我们可以把这道题转化为求（BD）的属性闭包，然后来判断AC是否在（BD）的属性闭包中？如果在，那么BD→AC就成立；如果不在，那么BD→AC就不成立；从而避免用Armstrong公理来繁琐地推导。解法如下：

X(0)=BD           {D→EG}

X(1)=BDEG      {BE→C}

X(2)=BDEGC   {C→A,BC→D,CG→BD,CE→AG}

X(3)=BDEGCA=U

(BD)F+=ABCDEG          

AC ⊆ (BD)F+

所以：BD→AC是否属于F+。

在开始本节内容以前，大家试着思考一下：

如果存在以下两个简单的函数依赖集：

F1 = {A→B,B→C,C→D}

F2 = {A→B,B→C,C→D,A→C,A→D,B→D}

那么F1和F2是否相等？

有的同学可能会直观地说：F1和F2显然不等，比如F1中有3个函数依赖存在，F2中有6个函数依赖，其中后面3个在F1中都是不存在的。真的不存在吗？你再看看！你突然会醒悟过来：虽然F1中没有明确给出A→C,A→D,B→D，但你知道根据F1中已经给出的的三个函数依赖（A→B,B→C,C→D）可以推导出它们，所以我们可以认为F1其实暗含了这三个函数依赖：A→C,A→D,B→D。因此F1和F2中所包含的所有函数依赖是相同的，换句话说，F1的函数闭包和F2的函数闭包是相同的。那么这种情况下，我们就称F1和F2等价。

1. 函数依赖集的等价

定义：对于关系模式R(U)上的两个函数依赖集F和G，若有F+=G+，则称F和G等价。

在了解了函数依赖集等价的概念以后，我们接着再看一下上面的F1和F2。既然F1和F2是等价的，那么因为F1更简洁，所以我更愿意写出F1，而不是F2。道理很简单，因为F2中的部分函数依赖没必要写，它们可以被推导出来。那么对于我们喜欢的F1，它里面的三个函数依赖是否都必不可少呢？我们随意去掉1个会有影响吗？比如去掉C→D，那么可以肯定的是C→D是不可能根据剩下的A→B,B→C推导出来的，而且因为C→D这个函数依赖的消失，原本暗含的函数依赖A→D,B→D也不可能被推导出来了！所以C→D是不能去的。同样的道理，F1中的另外两个函数依赖（A→B,B→C）也都不能被去掉。因此我们可以看出对于F1和F2共同的函数依赖集的闭包而言，F1仅仅包含了那些必不可少的函数依赖，没有任何多余，也没有任何缺失！多余的意思是说去掉F1中的某一个，依然能够推出原来函数依赖集闭包中的所有函数依赖；缺失的意思是说根据现有的函数依赖，已经不能推出原来函数依赖集闭包中的所有函数依赖了。那么在这种情况下，我们就可以说F1是极小函数依赖集。

2. 极小函数依赖集

定义：设F是属性集U上的函数依赖集。如果Fmin是F的最小函数依赖集，那么Fmin应满足下列3个

           条件：

           (1)每个函数依赖的右部都是单属性。

           (2)Fmin中没有冗余的函数依赖，即F中不存在这样的函数依赖X→Y，使得F与F-{X→Y}等价。

           (3)每个函数依赖的左边没有冗余的属性，即F中不存在这样的函数依赖X→Y，X有真子集W使得

               F-{X→Y} ∪{W→Y}与F等价。

这就是极小函数依赖集的定义。可以看出，真正的极小函数依赖集的定义比我们上面讨论出F1是极小函数依赖集的原因还要严苛的多。那么怎么去求极小函数依赖集呢？

--------------------求取极小函数依赖集的步骤-----------------------

① 逐一检查F中各函数依赖FDi，将FDi分解为右部为单属性；即对于X→Y，若Y=A1A2…AK,K>=2,则用{X→Aj|j=1,2,…,k}取代X→Y。

② 逐一检查F中各函数依赖FDi，将多余的函数依赖去掉。即从第一个函数依赖X→Y开始，先将其从F中去掉，然后在其余的函数依赖中求X的闭包X+,若Y∈X+则X→Y多余，需要去掉，否则保留X→Y。依次类推，直到检查完所有的函数依赖。

③ 逐一取出F中左部非单属性的函数依赖，去掉各函数依赖中左部多余的属性。即对于X→Y，设X=B1B2…Bn， 逐一考察Bi，若Y⊆(X-Bi)F+，则用X-Bi取代X。

-----------------------------------------------------------------------

这个步骤有点抽象，我们举个例子就清楚多了。

【例】已知关系模式R<U,F>，其中U={A,B,C,D,E,G}, F={AB→C,C→A,CG→BD,ACD→B}，求Fmin 。

① 将每个函数依赖的右部分解为单属性

     AB→C, C→A, CG→B, CG→D, ACD→B

② 循环将多余的函数依赖去掉

     a. 首先去掉AB→C ， F1={C→A, CG→B, CG→D, ACD→B}

     b. 求(AB)F+,  (AB)F+={AB}, C∈(AB)F+，保留AB→C ；

       最终得到{AB→C, C→A, CG→D, ACD→B}

③ 逐一取出左部非单属性的函数依赖，去掉多余的属性

     a. 取出ACD→B：B∈(CD)F+ ， CD→B；

     最终得到Fmin={AB→C, C→A, CG→D, CD→B}