在这一节，我们将会正式回答第2个问题，希望你还记得：

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

在数据库中，将关系模式的良好程度分为若干个等级，这就是“范式”的概念。

1. 范式

定义： 关系数据库中符合某一级别的关系模式的集合。所谓“第几范式”，是表示关系的某一种级别，关系模式R为第几范式就可以写成：R ∈ xNF

常见的范式有（从低到高）：

1NF Ì 2NF Ì 3CNF Ì BCNF Ì 4NF Ì 5NF

关系模式符合的范式越高，说明关系模式的良好程度越高。但设计关系模式时并不总是需要达到最高范式。本课程只讲到第三范式（3NF），这也是最常用的范式。

2. 第1范式（1NF）

定义：设R是一个关系模式，R属于第一范式当且仅当R中每一个属性A的值域只包含原子项，即不可分割的数据项。

第1范式的要求非常简单，就是关系模式中的每一个属性都必须是不可拆分的、原子的。比如我们来看看下面的这个例子：

在上面这个关系中，大家可以观察到：属性“系”其实是由两个子属性构成：系名+系地址，属性“课程”也是由两个子属性构成：课程名+任课教师，所以这两个属性都不是原子的，都可以继续拆分。拆分以后的结果如下：

这个结果符合1NF吗？还是不符合！不难看出，有的“教师名”属性包含了多位教师，所以它依然不是原子的，我们应该进一步拆分，以确保每一个“教师名”属性只包含一位教师。如下所示：

好了！到这里，我们就把关系模式中的每一个属性变成了原子属性——不可拆分的属性。至此，这个非规范化（连1NF都不满足）的关系模式变成符合1NF了！

3. 第2范式（2NF）

定义：设R是一个关系模式，R属于第二范式当且仅当R是1NF，且每个非主属性都完全函数依赖于主码。

这个定义中提到了一个重要的概念：非主属性。回顾一下，还记得什么是非主属性吗？

候选码中的属性称作主属性，其它的称作非主属性。

2NF怎么理解呢？我们举个例子：

【例1】存在关系模式R(A,B,C,D)，R满足函数依赖A→D；请判定R是否满足2NF？

解析：这里需要说明的是：属性AB有下划线标识，这意味着这两个属性是关系模式R中的主码。那又怎样呢？那就厉害了，主码是可以决定关系中的任何一个属性的！所以AB可以决定C或D！有同学会问这样一个问题吗：除了C和D以外，AB能不能决定A或者B呢?当然能，平凡的函数依赖吗！任何属性都可以决定自己或自己的子集，相信这不难理解。好了，我们把它表示出来：

AB→C ，AB→D

在理解了这一点以后，我们来分析一下R中的主属性和非主属性都有谁？根据前面的定义“候选码中的属性称作主属性，其它的称作非主属性。”，因为AB是主码，所以A、B是主属性，C、D是非主属性。

大家再看看题目！题目中还有一个条件：R满足函数依赖A→D！所以我们可以得出这样的结论：非主属性D部分函数依赖于主码。因此关系模式R不符合2NF！

继续：R不符合2NF，那我们如何改造R使其满足2NF呢？

考虑一下：R不符合2NF的原因是因为函数依赖A→D的存在。如果我们将这个函数依赖从R中去掉，那不就消除了这个部分函数依赖了吗？好的，如果你明白了这一点，那么现在的问题就变成了怎么去掉这个函数依赖呢？方法很简单，从关系R中去掉属性D，形成新关系R1（A,B,C）。

在R1（A,B,C）中存在函数依赖：AB→C，而且A或者B都不能独自决定C，所以非主属性C完全函数依赖于主码AB，因此R1满足2NF。现在有一个问题，被我们去掉的D怎么办？D是原始关系中存在的属性，是不能丢失的！因为如果D丢失，那么就意味着与D相关的数据的丢失！我们绝不能因为关系模式的规范化而丢失数据，所以我们可以尝试构建一个新关系R2（D）来存放与D相关的数据。那么现在原始的R就被我们变成了两个新的子关系模式：R1（A,B,C），R2（D）。

我们成功了吗？经过我们上面的讨论，R1已经满足2NF，而R2是一定满足2NF的！R2中只有一个属性D，因此无论如何都不可能有部分函数依赖的存在。所以似乎通过将R拆分为R1和R2，让我们达到了2NF的目标。事情真的是这样吗？其实我们遗漏了一件很重要的事情：那就是D和AB的关系！从现在的R1和R2是看不出任何D与AB 之间的关系的！没有关系！但是我们都知道题目中告诉了我们：A→D！所以怎么办？解决的办法就是将A同时放入R2，变成：R1（A,B,C），R2（A,D）。

好了！事情终于要告一段落了！在R2中，不存在部分函数依赖，R2属于2NF！并且我们找回了丢失的函数依赖：A→D，而且R2可以和R1通过关联字段A进行关联，以恢复出拆分之前的原始数据，即R=R1⋈ R2。这，就是我们想要的最终结果！

经过艰苦的分析、改进，我们最终将一个不满足2NF的关系模式通过拆分的方法转换成为了符合2NF的关系模式。这种拆分的方法在我们数据库中叫做“模式分解”。后面我们还会详细地讨论它！

4. 第3范式（3NF）

定义：设R是一个关系模式，R属于第三范式当且仅当R是2NF，且每个非主属性都非传递函数依赖于主

          码。

3NF如何理解？关键点是不存在非主属性对主码的传递函数依赖，即满足第三范式的关系模式应该不存在如下依赖关系：

主属性 → 非主属性x → 非主属性y 

首先需要强调的是：

满足2NF必须首先满足1NF，满足3NF必须首先满足2NF！

接下来我们要对最开始提出来的关系模式SLC进行病灶分析和手术治疗了！还记得这个异常多多的SLC吗！

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

同学们可以自己分析一下，SLC还是满足1NF的，所以现在我们需要分析的是它是否满足2NF？在开始把脉以前，先让我们弄清楚一些事情：

问题1：SLC的主属性和非主属性是谁？

前面曾经讨论过，SLC中的主码是（Sno,Cno），所以SLC中的主属性是：Sno和Cno，非主属性是：Sname、Sdept、Loca、Grade。

问题2：SLC中存在哪些函数依赖？

根据主码的特点，首先存在以下函数依赖：

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

然后还存在下述函数依赖：

Sno→Sname，Sno→Sdept, Sno→Loca, Sdept→Loca

好了，分析SLC是否属于2NF的工作正式开始！2NF的定义是什么？不存在非主属性对主码的部分函数依赖。这里有吗？答案是肯定的。比如

(Sno,Cno)→Sname,  Sno→Sname

(Sno,Cno)→Sdept,  Sno→Sdept

(Sno,Cno)→Loca,  Sno→Loca

不仅有！而且还很多！很尴尬！分析一下根源在哪里？你会发现根源其实出在Cno！如果没有Cno，一切的部分函数依赖瞬间消失！OK！怎么办？根据2NF中的讨论，最好的办法就是将Cno从SLC中移除，形成一个新关系SC（Cno）。但是需要我们注意的是：SLC中的Grade脱离了Cno和Sno是没有任何意义的！比如我给你一个90，不告诉你这是哪位同学的哪门课程的成绩，这有何意义呢？所以Grade应该从SLC移到SC。那么Sno是否也应该从SLC简单地移到SC呢？不能，因为在SLC 中Sno还决定着Sname等其它属性，所以Sno会被复制一份到SC。因此，我们得到了以下两个子关系模式：

SC（Sno,Cno,Grade）  其中（Sno,Cno）是主码。

SL（Sno,Sname,Sdept,Loca） 其中Sno是主码。

在SC中，Sno和Cno都不能独自决定Grade，所以非主属性Grade不存在对主属性（Sno,Cno）的部分函数依赖，因此SC属于2NF。在SL中，主属性只有Sno，所以无论如何都不可能存在非主属性对主属性的部分函数依赖（部分函数依赖的存在一定是主属性有多个），因此SL也属于2NF。

SC和SL都属于2NF，那么它们都属于3NF吗？3NF的条件是：每个非主属性都非传递函数依赖于主码。这意味着非主属性必须不低于2个，否则谈不上传递依赖，因此SC一定属于3NF。SL呢？这是我们讨论的焦点。先来看看SL中存在的函数依赖都有哪些：

Sno→Sname，Sno→Sdept, Sno→Loca, Sdept→Loca

看到了吗？Sno→Sdept,  Sdept→Loca，所以非主属性Loca传递函数依赖于主属性Sno。可以下结论了：SL不属于3NF！怎么办？还用说？一个字：“拆”（模式分解）。大家可以根据前面的思路，自己尝试着分解一下。

最后的结果是我们将SL分解成为了以下两个子关系模式：

S（Sno,Sname,Sdept） 其中主码是Sno。

L（Sdept,Loca）  其中主码是Sdept。

这样分解的原因是由于要去除造成传递函数依赖存在的因素： Sdept→Loca。而为了不造成S和L联系的丢失，Sdept被作为关联字段分别放入了两个新的子关系模式中。最后来检视一下，S和L都满足3NF吗？

在S中，非主属性Sname和Sdept不能互相决定，所以不存在非主属性对主属性的传递函数依赖，因此S属于3NF；在L中，非主属性只有Loca一个，何谈传递性，因此L 属于3NF。

给出最终的结果，我们将SLC分解成为了以下子关系模式：

SC(Sno,Cno,Grade)

S(Sno,Sname,Sdept)    

L(Sdept,Loca)

从而将仅仅满足1NF的SLC规范化到3NF。

这就是数据库规范化理论中的三级范式（1NF、2NF、3NF）。

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

最后，让我们正式地回答第2个问题：

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

一个关系模式符合的范式级别越高（3NF>2NF>1NF），说明这个关系模式越良好。

在上一节中，关系模式从低一级范式向高一级范式转化时，我们采用了分解的方法。但分解的策略基本是靠分析和推理，有一定难度。有没有一种固定的算法或步骤呢？这就是这一节的中心内容。

好，先提出我们早已熟悉的“模式分解”和“规范化”的概念。

1. 模式分解

模式分解：对于存在数据冗余、插入异常、删除异常等问题的关系模式，应采取将一个关系模式分解为多个关系模式的方法进行处理。

2. 规范化

一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式。

3. 模式分解的方法与步骤

（1）从非规范化到规范化，即第一范式：

第1种情况：

分析：其中属性“高级职称人数”非原子项，可以进一步拆分为“教授”和“副教授”，因此原关系不满足1NF。

转换方法：将非原子数据项分解表示为原子数据项。

转换结果：

第2种情况：

分析：其中属性“课程号”和“成绩”非原子项，因此原关系不满足1NF。

转换方法1：表的修平(flattening)：通过在包含非原子数据的行的空列中输入合适的数据，从而消除非原子数据项。

转换结果：

转换方法2：将关系中的非原子数据列移到一个独立的新关系中，同时将原来的关键字也复制到这个新关系中，并在原表中删除被复制的非原子数据列，形成新关系。

转换结果：

（2）从第一范式到第二范式

○ 用组成主键的属性集合的每一个子集作为主键构成一个关系；

○ 将依赖于这些主键的属性分别放置到相应的关系中；

○ 最后去掉只由主键的子集构成的关系。

此处以SLC为例，前面我们已经通过分析、推理将SLC转换成为了2NF。此处我们利用介绍的算法再将原始的、不满足1NF的SLC转换成为2NF。大家可以对照比较一下，看看我们前面的转换结果和此处的转换结果是否一致。

SLC(Sno,Sname,Sdept,Loca,Cno,Grade)      主键：(Sno,Cno)

第1步：用组成主键的属性集合的每一个子集作为主键构成一个关系

SL(Sno, …)                C(Cno, …)                SC(Sno,Cno, …)

第2步：将依赖于这些主键的属性分别放置到相应的关系中

SL(Sno,Sname,Sdept,Loca)         C(Cno)          SC(Sno,Cno, Grade)

第3步：最后去掉只由主键的子集构成的关系

SL(Sno,Sname,Sdept,Loca)         SC(Sno,Cno, Grade)

好了，这就是符合2NF的结果，和前面我们讨论的结果完全相同。

（3）从第二范式到第三范式

○ 对于不是候选码的每个决定因子，从关系中删去依赖于它的所有属性；

○ 新建一个关系，新关系中包含原关系中所有依赖于该决定因子的属性；

○ 将决定因子作为新关系的主键。

SC已符合3NF，所以此处我们需要继续规范化的是SL(Sno,Sname,Sdept,Loca) 。

第1步：对于不是候选码的每个决定因子，从关系中删去依赖于它的所有属性；

分析：SL(Sno,Sname,Sdept,Loca) 中的候选码是Sno，除此以外的其它属性都不是候选码。但SL中存在函数依赖：Sdept→Loca。因为Sdept能够决定Loca，所以我们将Sdept称作“决定因子”。但是Sdept却不是候选码，所以根据算法，需要将依赖于Sdept的Loca从SL中删除。结果如下：

S(Sno, Sname,Sdept)

第2步：新建一个关系，新关系中包含该决定因子和原关系中所有依赖于该决定因子的属性；

分析：这一步算法中说的“该决定因子”就是第1步中那个非候选码的决定因子。所以在本步中，我们将会拿Sdept和依赖于它的属性来构建一个新关系。结果如下：

L(Sdept,loca)

第3步：将决定因子作为新关系的主键。

L(Sdept,loca)

好的，此时，SL通过算法已被分解为：S(Sno, Sname,Sdept)，L(Sdept,loca)。因为非主属性和主属性之间不存在传递函数依赖，所以分解后的两个子关系模式均符合3NF。

最后，让我们给出 SLC经过以上算法分解后的最终结果：

SC(Sno,Cno,Grade)

S(Sno, Sname,Sdept)

L(Sdept,loca)

大家可以将最终结果和上一节对比，完全相同！的确，利用本节介绍的模式分解算法来进行关系模式的规范化，比我们上一节纯粹的分析、推理来的更简单、更准确。

各位还记得我们的第3个问题吗？

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

我想，“范式及规范化方法”一节的内容很好地回答了第3个问题的前半部分，接下来我们需要回答的是后半部分。

大家应该能够想象：一个关系模式被分解以后，如果是良好的分解，那么分解以后的结果应该是能够通过连接再恢复回去的。也就是说分解是可逆的，分解以后的结果不应该造成原始数据和联系的丢失或增加。好，我们来给出“可逆性”的概念。

1. 模式分解的可逆性

可逆性：模式分解是可逆的，即分解的结果能够重新映像到分解前的关系模式；它意味着在规范化过程中没有信息丢失，且数据间语义联系依然存在。

我们把“没有信息丢失”的分解称作“无损分解”，把“数据间语义联系依然存在”的分解称作是“保持函数依赖”的分解。

为了帮助大家理解，下面举个例子来加以说明：

【例1】已知关系模式R<U,F>，其中U={Sno,Sdept,Mname},F={Sno→Sdept,Sdept→Mname}。学生Sno在系Sdept学习，其系主任是Mname。

大家一看就知道，这个关系模式的主码是Sno，因为它可以决定每一个属性。但我们观察给出的函数依赖，你就会发现非主属性Mname传递函数依赖于主码Sno，所以它并不符合3NF。方法很简单：模式分解。大家完全可以采用前面介绍的算法来实施模式分解，但为了更好地研究分解的可逆性，此处我们给出以下的分解方式供大家分析、讨论：

分解方式1：ρ={R1<Sno,φ>, R2<Sdept,φ>, R3<Mname,φ>}

解释一下上面的符号。ρ代表一种分解结果。R1<Sno,φ>代表分解结果ρ中包含的一个子关系模式，R1是关系的名称，Sno是R1中的属性集，φ是R1中的函数依赖集。φ本身表示“空”的意思，用在此处表示R1没有函数依赖存在。R2、R3类似，不再赘述。

分解方式1的结果如下图所示：

分析：这种分解的效果怎么样呢？我们说分解效果主要是从两方面来加以判断。第1：有没有实现数据无损？第2：有没有保持函数依赖？先看第1个：我们将分解以后的数据连接起来，大家很清楚，由于各个子关系中没有关联字段存在，所以这就是一个毫无意义的笛卡儿积运算。连接的结果一定是连接后的数据远远超过原始的数据，那么大家会说，数据没有损失啊？各位：数据增加或减少都是有损的！再看第2个：各个子关系模式中的函数依赖都是空，所以合并起来的函数依赖依然为空。和原始的函数依赖集比较，所有的函数依赖都没有被保持下来。所以对于这种分解效果的结论是：函数依赖丢失、增加噪音。增加噪音指的就是数据有损。

分解方式2：ρ={R1<{Sno,Sdept},{Sno→Sdept}>,R2<{Sno,Mname},{Sno→Mname}>}

分解方式2的结果如下图所示：

分析：鉴于分解后的两个子关系模式有关联字段Sno，所以连接以后的数据和原始数据是一致的，好，这是一个无损分解！我们再来看看函数依赖的保持性。R1和R2的函数依赖合并起来以后是{Sno→Sdept,Sno→Mname}，能不能推出原始的函数依赖Sdept→Mname？不能！所以对于这种分解效果的结论是：函数依赖丢失。

分解方法3：ρ={R1<{Sno,Sdept},{Sno→Sdept}>,R2<{Sdept,Mname},{Sdept→Mname}>}

分解方式3的结果如下图所示：

分析：分解以后的R1和R2具有关联字段Sdept，可以通过连接得到和分解前完全一致的数据，这是一个无损分解。R1和R2的函数依赖合并起来和分解前的函数依赖也完全一致，这也是一个保持了函数依赖的分解。所以对于这种分解效果的结论是：无损连接、保持函数依赖。

最后，我们总结一下：

一个模式的分解可以有多种方式，但必须要保证分解后的模式与原来的模式等价。等价的标准通常有以下3类：

◆ 分解要具有无损连接性

◆ 分解要保持函数依赖

◆ 分解既要保持函数依赖，又要具有无损连接性

无损分解的定义

到底什么是“无损分解”呢？这里，我们需要给出“无损分解”的定义：

定义：设ρ={R1,R2, … ,Rn}是关系模式R<U,F>的一个分解，如果对于R的任一满足F的关系r都有：

                     r = πR1(r) ⋈ πR2(r) ⋈ … ⋈ πRk(r)

           则称这个分解ρ是函数依赖集F的无损分解。

从定义分析，对无损性的检视，其实就是将分解后的子关系模式中的数据实施连接，然后将连接的结果与原始数据进行比对。如果两者完全一致，那么这就是无损分解；否则是有损分解。

【例1】设有关系模式R(A,B,C)，ρ={R1,R2}是它的一个分解,其中R1=AB，R2=BC，问此分解是否具有无损连接性。

现在我们将分解以后的R1和R2作连接，看看会怎样？

R1⋈ R2 =   

大家可以看出，R1⋈ R2的数据与原始数据并不一致，所以这个分解是一个有损分解。

前面对分解无损性的判定是通过对前后数据的比对来完成的。如果没有数据呢？如果数据量很大呢？还能以这种简单的连接比对方式来判定无损性吗？不能！所以接下来我们给大家介绍一种判定无损性的算法。它脱离了数据，只依赖关系模式来进行判定。

无损分解验证算法

输入：关系模式R(U)，其中U={A1, A2, …, An}，R(U)上成立的函数依赖集F和R(U)的一个分解ρ={R1(U1),R2(U2), …, Rk(Uk)}，其中U＝U1∪U2∪…∪Uk。

输出：ρ相对于F具有或不具有无损连接性的判断。 

计算方法和步骤：

⑴构造一张k行n列的表格，每列对应一个属性Aj(j=1, 2, …, n)，每行对应一个模式Ri(Ui) 的属性集合(i=1, 2, …, k)。如果Aj在Ui中，那么在表格的第i行第j列处境上符号aj，否则填上符号bij；

⑵ 反复检查F的每一个函数依赖，并修改表格中的元素，直到表格不能修改为止。其方法如下： 取F中的函数依赖X->Y，如果表格中有两行在X分量上相等，在Y分量上不相等，那么修改Y分量上的值，使这两行在Y分量上也相等，具体修改分两种情况：

 ①如果Y的分量中有一个是aj，那么另一个也修改成aj；

②如果Y的分量中没有aj，那么用下标i较小的那个bij替换另一个符号。

⑶ 若修改结束后的表格中有一行是全a，即a1, a2, …, an，那么ρ相对于F是无损连接分解，否则，ρ相对于F不是无损连接分解。 

【例2】设有关系模式R<U,F>，其中U={A,B,C}，F={A→B,C→B}，判断一个分解ρ={AC,BC}是否具有无损分解。

第1步：根据算法，首先构成初始表格：

此处任意举2个表格中单元格的值来解释一下这些值的形成：a1和b12。为了更好地解释，我们利用i、j的值作为坐标值来描述单元格在表格中的位置，比如a1所处的单元格是“11”（行号i在前，列号j在后）。单元格11的值为什么是a1呢？因为单元格11所在列的属性A出现在所在行的属性AC中，所以其值为aj的形式，又因为本列j=1，因此单元格11的值是a1。那么单元格12的值为什么是b12呢？因为单元格12所在列的属性B没有出现在所在行的属性AC中，所以其值为bij的形式，又因为本行i=1，本列j=2，因此单元格12的值是b12。其它单元格的值以此类推。

第2步：考查第1个函数依赖：A→B。在第1步形成的表格中，寻找属性A所在的列中是否存在具有相同值的单元格？因为没有，所以本步结束。

第3步：考查第2个函数依赖：C→B。在第2步形成的表格中（其实第2步未影响原始表格），寻找属性C所在的列中是否存在具有相同值的单元格？存在！所以修改B列中对应的单元格（与C列中具有相同值的单元格相对应）。修改的方式是：如果将被修改的单元格中有类似aj形式的值存在，那么所有被修改的单元格的值都改为aj（j为该列列号）；如果将被修改的单元格中没有类似aj形式的值存在，那么所有被修改的单元格的值都改为bij（i是被修改的值中最小的行号，j为该列列号）。

鉴于以上方法，由于被修改的值中有a2存在，所以将原始的b12改为a2，结果如下：

至此，所有的函数依赖均被扫描完毕，对表格的修改结束。接下来，我们就需要搜索在最后形成的表格中是否有某一行的所有单元格的值显示为全aj的形式？如果有，那么这就是无损分解；否则就是有损分解。不难看出，最后形成的表格中的第一数据行为全aj的形式。

因此分解ρ是无损分解。

【例3】已知关系模式R<U,F>，U={A,B,C,D,E}，F={A→C,B→C,C→D,DE→C,CE→A}，验证分解ρ={R1(AD),R2(AB),R3(BE),R4(CDE),R5(AE) }是否具有无损连接性？

第1步：根据算法，首先构建初始表格（原理见例1的解释）

第2步：考查第1个函数依赖：A→C。

属性A所在列有3个单元格值相等（单元格11、单元格21，单元格51），修改对应的C列单元格（单元格13、单元格23，单元格53）。

单元格13、单元格23，单元格53的值均为bij的形式，取最小的i，因此均改为b13。修改后的结果如下表：

第3步：考查第2个函数依赖：B→C。

属性B所在列有2个单元格值相等（单元格22、单元格32），修改对应的C列单元格（单元格23、单元格33）。

单元格23、单元格33的值均为bij的形式，取最小的i，因此均改为b13。修改后的结果如下表：

第4步：考查第3个函数依赖：C→D。

属性C所在列有4个单元格值相等（单元格13、单元格23、单元格33、单元格53），修改对应的C列单元格（单元格14、单元格24、单元格34、单元格54）。

单元格14、单元格24、单元格34、单元格54的值中存在aj的形式，因此均改为a4。修改后的结果如下表：

第5步：考查第4个函数依赖：DE→C。

属性DE所在列有3个单元格值相等（（单元格34，单元格35）、（单元格44，单元格45）、（单元格54，单元格55）），修改对应的C列单元格（单元格33、单元格43、单元格53）。

单元格33、单元格43、单元格53的值中存在aj的形式，因此均改为a3。修改后的结果如下表：

第6步：考查第5个函数依赖：CE→A。

属性CE所在列有3个单元格值相等（（单元格33，单元格35）、（单元格43，单元格45）、（单元格53，单元格55）），修改对应的A列单元格（单元格31、单元格41、单元格51）。

单元格31、单元格41、单元格51的值中存在aj的形式，因此均改为a1。修改后的结果如下表：

至此，所有的函数依赖均被扫描完毕，对表格的修改结束。接下来，我们就需要搜索在最后形成的表格中是否有某一行的所有单元格的值显示为全aj的形式？如果有，那么这就是无损分解；否则就是有损分解。不难看出，最后形成的表格中的第三数据行为全aj的形式。

因此分解ρ是无损分解，具有无损连接性。

在本节的最后，我们再提出一种判断无损分解的简便方法：

验证无损分解的充要条件

如果R的分解为ρ={R1,R2},F为R所满足的函数依赖集合，则分解ρ具有无损分解的充分必要条件为：

           R1∩R2→(R1 – R2)     或     R1∩R2→ (R2 – R1)

关于这个定理的应用，我们在后面的例子中会看到。

我们已经实现了“无损分解”的判定，接下来让我们来讨论如何判定一个分解是否具有“函数依赖的保持性”？

函数依赖的投影

定义：设有关系模式R，F是R的函数依赖集，Z是R的一个属性集合，则称Z所涉及到的F+中所有函数依赖为F在Z上的投影，记为πZ(F),有： πz(F)={ x→y|x→y∈F＋ ∧ xy ⊆ Z }

什么是函数依赖在属性集上的投影呢？我们来看下面这个例子：

【例1】设有关系模式R<U,F>，其中U={A,B,C,D}，F={A→B,B→C,C→D,D→A}，现将关系模式R作

  分解ρ={AB,BC,CD}。请写出每一个子关系模式。

解析：根据题目，R被分解成为了3个子关系模式：

          R1=（{AB},）    R2=（{BC},）      R3=（{CD},）

但是通过前面的学习，我们知道对一个关系模式的完整描述应该包括属性和函数依赖两个部分，即：

         R=（U，F）

所以我们必须将R上的函数依赖集F={A→B,B→C,C→D,D→A}投影到各子关系模式中。投影的方法比较加简单：只需将F中包含的函数依赖（也许是直接给出的，也许是未直接给出、但可以推导出来的）按照子关系模式中拥有的属性分配过去即可。

比如R1中包含AB两个属性，那么在F中与属性A或B有关的函数依赖就应该投影到R1中，但必须强调的是如果函数依赖左右两侧的任意一侧含有A或B以外的属性（例如C、D等），那么这个函数依赖就不能投影到R1。相信大家对这一点很好理解。

所以能够投影到R1中的函数依赖是：A→B（已知）、B→A（推导），即：πAB(F) ={A→B,B→A}。

因此R1=({AB},{A→B,B→A})，同理，R2=({BC},{B→C,C→B})，R1=({CD},{C→D,D→C})。

我们在投影函数依赖时，都是根据关系中的属性来完成的。这就是“函数依赖在属性上的投影”。

保持函数依赖的分解

定义：设关系模式R的一个分解ρ={R1,R2, … ,Rk}，F是R的依赖集，如果F等价于 πR1(F) ∪πR2(F) 

          ∪…∪πRK(F)，则称分解ρ具有依赖保持性。

从定义可知：分解后的函数依赖到底是否保持？其实就是将投影到每个子关系模式中的函数依赖合并起来，测试它与原始函数依赖集是否等价？如果等价，那么就保持住了函数依赖；否则没有。

我们先以例1的分解结果来做一个分析：

R1=({AB},{A→B,B→A})，R2=({BC},{B→C,C→B})，R1=({CD},{C→D,D→C})

三个子关系模式中的函数依赖合并起来是：{A→B,B→A,B→C,C→B,C→D,D→C}。它与原始的函数依赖集F={A→B,B→C,C→D,D→A}等价吗？各位，这个不需要我再推了吧？每一个函数依赖是不是都能在对方的函数依赖中直接或间接找到？所以这两个函数依赖集是完全等价的，因此例1的分解保持了函数依赖。

【例2】设有关系模式R<U,F>，其中U={A,B,C,D}，F={A→B,B→C,B→D,C→A}，将该关系分解为关于U1=AB，U2=ACD两个关系，求R1,R2 ，并验证该分解的无损连接性和函数依赖保持性。

首先来求R1和R2。R1和R2的属性已经给出，所以这里要求的无外乎是函数依赖集在这两个属性集上的投影。原理和例1的解析一致，这里我们就直接给出答案了：

F1=ΠR1(F)={A→B,B→A}

F2=ΠR2(F)={A→C,A→D,C→A}

所以：

R1=({A,B},{A→B,B→A})

R2=({A,C,D},{A→C,A→D,C→A})

其次，我们来验证这个分解的无损性。还记得“无损分解”一节最后给出的那个定理吗（验证无损分解的充要条件）？如果你忘了，就返回去看看。我们这里就用这个定理。

R1∩R2 = AB∩ACD = A

R1-R2 = AB – ACD = B

A→B ∈ F  

所以，例2中的分解是一个无损分解。

最后，让我们来验证函数依赖是否保持？

F1∪F2 = {A→B,B→A,A→C,A→D,C→A)

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

所以，例2中的分解也保持了函数依赖。

好了，验证一个分解是否保持函数依赖就是这样了！最后，我们说一下“无损分解”和“保持函数依赖”的验证结果对关系模式符合哪一级范式的规定。

     按照规范化理论，一个关系模式的分解可能有3种情况：

      ◆ 若要求分解具有无损连接性，则分解后的模式一定能达到4NF。

      ◆ 若要求分解保持函数依赖，那么分解后的模式一定可以达到3NF，但不一定可以达到BCNF。

      ◆ 若要求分解既具有无损连接性，又保持函数依赖，那么分解后的模式一定可以达到3NF，但不一定

         可以达到BCNF。

至此，我想我们已经完整地回答了规范化理论开篇的第3个问题：

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

希望你也如此以为！

规范化理论讲到这里，相信有不少同学已经挺不住了！好漫长的一段理论化讲述！不过值得你兴奋的是：规范化理论到此结束！正是“行至水穷处，坐看云起时。”

学习规范化理论的目的是对逻辑结构设计阶段得到的关系模型进行优化。这里我们随意举出前面得到的一个关系模型，来看看是否需要优化？别忘了，我们的目标是要符合3NF。

对于“13.3 逻辑结构设计-关系模型”一节中的例1，我们最后得到的关系模型如下：

学生(学号,姓名,性别)

课程(课程号,课程名,学分)

选修(学号,课程号,成绩)

教师(工号,姓名,职称)

讲授(工号,课程号,时间,地点)

大家可以利用范式的概念逐一判定上述关系模式的范式级别。经过判定，我们会发现“学生、课程、选修、教师、讲授”五个关系模式均已经属于3NF了，无需优化。这是巧合吗？其实你可以再看看该节中其它例题最后得到的关系模型，这并不是巧合！所以我们说只要你按照前面讲解过的、正确的方法和步骤来设计E-R模型，并转化为关系模型，基本上它已经符合3NF了，不需要你再做更多模型优化的操作。

所以讲到这里，数据库设计的七个步骤中的前四个，我们就完成了。剩下的物理结构设计、数据库实现、数据库运行维护也在我们利用SQL创建数据库、表、视图、索引等对象的过程中进行了介绍。

这就是数据库设计的七个步骤！最后，我们对数据库设计做一个总结。

数据库设计的特征

1. 反复性：数据库设计不可能“一气呵成”，需要反复推敲和修改才能完成。前阶段的设计是后阶段的基础和起点，后阶段也可向前阶段反馈其要求。如此反复，以趋完善。

2. 试探性：数据库的设计结果一般不是唯一的，设计过程往往是一个试探的过程。

3. 分步进行：数据库设计通常由不同的人员分阶段完成。

良好的数据库设计的一般特征

1. 便于检索所需要的数据： 

2. 具有较高的完整性、数据更新的一致性： 

3. 使系统具有尽可能良好的性能。

不好的数据库设计的一般特征

1. 需要多次输入相同的数据，或需要输入多余的数据。

2. 返回不正确的查询结果。

3. 数据之间的关系难以确定。

4. 表或列的名称不明确。