178.关系数据库理论基础

第2章  关系数据库理论基础

•    2.1 关系模型

•    2.2 关系代数

•    2.3 关系数据库

•    2.4 函数依赖

•    2.5 关系模式的范式

•    2.6 关系模式的分解和规范化

 

2.1 关系模型

•         关系模型的基本要素：关系模型的数据结构、关系操做和关系的完整性约束三部分。

•         2.1.1 关系模型的数据结构——关系

定义2.1   令D = D₁×D₂×…×D_n = {(d₁, d₂,…, d_n) | d_i ∈D_n ,  i = 1,2,…,n}，即D为D₁, D₂, …, D_n的笛卡儿积，则D的任何非空子集R都称为D₁, D₂, …, D_n上的n元关系，其中D_i为有限的属性值域，i = 1,2,…,n。

 

Ø 一个n元关系R一般记为R(D₁, D₂, …, D_n)，R中的任一元素(d₁, d₂,…, d_n)称为n元组，简称元组（Tuple）。元组中的每一个值d_i称为份量。n称为关系的度或元。当n = 1时，R称为单元关系；当n = 2时，R称为二元关系。

Ø 注意，一个关系实际上就是若干元组的集合。一个关系必须是有限元组的集合，无限集合对数据库技术来讲是无心义的。

 

•         笛卡儿积能够用二维表直观地表示。

【例子】  假设笛卡儿积D = D1×D2×D3，D1为学号的集合， D1={201301, 201302}，D2为姓名的集合， D2={李思思, 刘洋}，D3为英语成绩（简称“英语”）的集合， D3={90, 85, 70}。

D = {201301, 201302}×{李思思, 刘洋}×{90, 85, 70}

    = 　　{(201301, 李思思, 90), (201301, 李思思, 85), (201301, 李思思, 70),                                                       　　　　 　　　　(201301, 刘洋, 90), (201301, 刘洋, 85), (201301, 刘洋, 70),

 　　　　(201302, 李思思, 90), (201302, 李思思, 85), (201302, 李思思, 70),

 　　　　(201302, 刘洋, 90), (201302, 刘洋, 85), (201302, 刘洋, 70)}。

 

•         由定义2.1，D为一个笛卡儿积，D的任意子集都是三元关系。

【例子】令R = {(201301, 刘洋, 70), (201302, 李思思, 90)}，R 为D的一个子集，因此R 为3元关系。

•         这个关系记做R(D1, D2, D3)，其对应二维表示如表2.2所示。

 

 

 

 

 

•         笛卡儿积D自己也是一种关系，但这种关系因为过于泛化而可能会致使语义上的矛盾，从而失去实际意义。通常来讲，只有部分关系有意义，而不是所有。

【例子】  元组(201301, 刘洋, 90)和元组(201301, 刘洋, 85)就是一对矛盾的元组，由于学号“201301”、姓名为“刘洋”的学生的英语成绩不可能同时取90分和85分这两个值。

 

•         数据库理论中的一些概念；

Ø 关系：一个关系等同于一张二维表，是有限元组的集合；一个数据库能够视为若干关系的集合

Ø 元组：二维表中的一行对应一个元组，也称为记录。

Ø 由表2.2所示，“201301”，““刘洋”和“70”构成的行就是元组(201301，刘洋, 70)。

Ø 属性：二维表中的每一列都称为属性或字段。

Ø 域：即属性的值域，也就是属性的取值范围。

Ø 由表2.2所示，“学号”这个属性的值域为{201301, 201302}。

 

 

Ø 份量：一个元组中的一个属性值，也常称为数据项。

Ø 由表2.2所示，“刘洋”、“70”等都是数据项。数据项不能再分了，它是关系数据库中最小的数据单位。

Ø 候选码和主码：若是二维表中存在一个属性或若干属性组合的值可以惟一标识表中的每个元组，则该属性或属性组合就称为候选码，简称码；若是一个表存在候选码，且从中选择一个候选码用于惟一标识每个元组，则该候选码称为主码（Primary key）。主码也常称为主健（主关键字段）。

Ø 主属性和非主属性：包含在任何候选码中的属性都称为主属性，不包含在任何候选码中的属性称为非主属性。

 

 

•         关系的性质：

Ø 列是同质的，即每一列中的份量是同一类型的数据，它们都是来自同一个域。

Ø 每一列为一个属性，不容许存在相同属性名的状况。

Ø 列（行）的顺序是任意的，列（行）的次序能够任意交换。

Ø 不容许存在两个相同的元组。

Ø 每个份量都是不可再分的，即不容许表中套表。

 

 

 定义2.2   假设一个n元关系R的属性分别为A1, A2, …, An，令R(A1, A2, …, An)表示关系R的描述，称为关系模式。

Ø  关系模式是由属性构成，与属性值无关。为了体现关系模式中的主码，对构成主码的属性添加下划线。

【例子】在关系模式R(A, B, C, D, E)中，属性A和B的组合是该关系模式的主码。

Ø  关系模式是描述关系的“型”，即凡是具备相同属性的关系都属于相同的“型”，即它们都属于同一个关系模式。

Ø  一个关系模式能够视为一类具备相同类型的关系集合，属于同一个关系模式的关系都拥有相同的属性（但属性值却不必定相同）。

Ø  一个特定的关系是其对应关系模式的“值”，或者说关系是关系模式这个集合中在某一时刻的一个“元素”。

 

 

Ø  关系和关系模式的区别和联系：

•            关系和关系模式之间的联系就好像是数据类型和数据之间的联系。

•            关系模式和关系是有区别的，即前者是后者的抽象，后者是前者的特定实例

•            关系模式是相对稳定的，数据在更新，关系是随时间变化的。但在运用中经常将它们统称为关系，读者可根据上下文来区分。

 

 

•         2.1.2 关系操做

•          关系操做的分类：查询操做、更新操做

•         查询操做是最经常使用和最主要的操做，其包括：

Ø 选择：从关系中检索出知足既定条件的全部元组的集合，这种操做就称为选择。其中，选择的条件是以逻辑表达式给出的，使表示式的值为真的元组被选取。从二维表的结构上看，选择是一种对行的操做。（最经常使用）

Ø 投影：从关系中选出若干个指定的属性来组成新的关系，这种操做就称为投影。从二维表的结构上看，选择是一种对列的抽取操做。

Ø 链接：从两个关系中抽出知足既定条件的元组，并将它们“首尾相接”地拼接在一块儿，从而造成一个新的关系，这种操做称为链接。

Ø 除：一种行列同时参加的运算。

 

 

•         如下三个选择操做的共同特色是，参加运算的两个关系必须有相同的属性个数，且相应属性的取值分别来自同一个域（属性名能够不一样）：

Ø 并：将两个关系中的元组合并到一块儿（纵向），从而造成一个新的关系，这种操做称为并。

Ø 交：将两个关系中的共同元组组成一个新的关系，这种操做称为交。

Ø 差：将第一个关系中的元组减去第二个关系中的元组，从而也产生了新的关系，这种操做称为差。

 

 

•         更新操做种类：（最经常使用）

Ø 插入：把一个关系（元组的集合）插入到已有的关系中，造成新的关系。

Ø 删除：从一个关系中删除知足既定条件的全部元组，剩下的元组构成新的关系。

Ø 修改：利用给定的值更改关系中知足既定条件的全部元组的对应份量值，更改后获得新的关系。

•         关系操做的特色：

•                 针对集合进行，即操做的对象是元组的集合，操做后所获得的结果也是元组的集合。

•                 非关系模型（网状模型和层次模型）的操做对象是一个元组。

 

 

•         2.1.3 关系的完整性约束

   关系是关系模型的数据结构。关系须要知足一些基本要求——关系的完整性约束。

   完整性约束包括：实体完整性约束、参照完整性约束、用户定义的完整性约束。

 

 

1.实体完整性

Ø 每个关系中的主码属性的值不能为空（NULL），可以惟一标识对应的元组。

    缘由：主码设置的目的是用于区分关系中的元组，以将各个元组区别开来。若是主码中的属性值能够为空，那么在关系中将存在一些不肯定的元组，这些元组将不知道是否可以与别的元组有区别（由于空值被系统理解为“不知道”或“无心义”的值），这在关系模型中是不容许的。各个元组在主码上的取值不容许相等，不然就不知足实体完整性约束。

Ø 实体完整性是关系模型必须知足的完整性约束条件。

 

 

【例2.1】考虑如表2.3所示的学生关系student(学号, 姓名, 性别, 专业号)和表2.4所示的课程关系course(课程号, 课程名, 学分)。假设学生关系的主码为“学号”，课程关系的主码为“课程号”，那么学生关系的“学号”以及课程关系的“课程号”的取值就不能为空，并且取值不能重复（能惟一标识每一行），不然就不知足实体完整性。

 

 

2. 参照完整性

Ø 参照完整性与外码密切相关，这里先介绍外码的概念。

Ø 对于关系R和S，假设F是关系R的一个属性或一组属性，但F不是R的码，K是关系S的主码，且F与K相对应（或相同），则F称为R的外码（Foreign key），R和S分别称为参照关系（Referencing relation）和被参照关系（Referenced relation），如图2.1所示。

 

 

 

 

•         F与K是相同的属性或属性集，它们的取值范围相同。

•         关系模型的参照完整性约束：外码F中的每一个属性值等于主码K的某一个属性值或F的每一个属性值均为空值。

•         若是要在关系R中插入一个元组，则该元组在属性F上的取值等于关系S中某一个元组在主码K上的取值或全置为空值，不然不能插入该元组。当关系S为空时，不能向关系R中插入元组；当要删除关系S中的一些元组时，必须先删除关系R中与这些元组相关联的元组。

•         参照完整性也是关系模式必须知足的完整性约束条件。

 

 

【例子】选课关系SC(学生编号, 课程编号, 成绩)，如表2.5所示。可见属性组{学生编号，课程编号}为该关系的主码。

 

 

 　　　属性“学生编号”是选课关系的外码，它与关系“student（学号, 姓名, 性别, 专业号）”的主码“学号”相对应，选课关系为参照关系，学生关系为被参照关系，“课程编号”同理。

•         外码“学生编号”和“课程编号”共同组成了该关系的主码，这两个属性的取值不能为空，只能为相应被参照关系中相应列中的取值。

【例子】表2.5中“学生编号”列的属性值“201301”必须等于表2.3中“学号”列中的某一个属性值；表2.5中的“课程编号”列的属性值“13989”必须等于表2.4中“课程号”列中的某一个属性值。

 

 

•         表2.6所示的专业关系major（专业编号, 专业名），该关系的主码是“专业编号”，且表2.3所示关系“学生”中的“专业号”与该关系中的“专业编号”相对应，即“专业号”是学生关系student的外码。在这种状况下，因为学生关系student中的“专业号”不是该关系的主码，于是“专业号”列的属性值能够取空值。

【例子】表2.3中学生“李鑫”所对应的“专业号”为空值，这代表还没有给该学       生分配专业。

 

 

3.用户定义的完整性

l 用户定义的完整性是指由用户定义的、针对某一具体应用需求制定的约束条件，多用于知足数据的一些语义要求。

【例子】在表2.5所示的关系SC中，常常定义这样的约束：成绩的取值必须在0～100之间；又如，某些属性值不能为空或取值必须惟一等。

l 用户定义完整性约束能够有效减小应用程序的负担，关系数据库管理系统都提供定义和检验这类完整性的机制和方法。

 

 

2.2 关系代数

l  2.2.1 基本集合运算

    基本集合运算是指集合的并、交、差和笛卡儿积运算，这些运算都是二元运算。咱们约定：本节中R和S都默认是n元关系，且对应属性取自同一个值域。如下介绍基于关系的基本集合运算。

1. 并∪

Ø n元关系R和S的并是一种新的n元关系，这个新的关系是由R的元组或S的元组组成，记为R∪S，即R∪S = {x |  x∈ R∨x ∈ S}

2. 交∩

Ø n元关系R和S的交是一种新的n元关系，这个新的关系是由R和S的共同元组组成，也就是说，由既属于R的元组又属于S的元组组成，记为R∩S，

     即R∩S = {x | x ∈ R ∧ x ∈S }

 

 

3. 差－

Ø n元关系R和S的差是一种新的n元关系，这个新的关系是由属于R的元组但不属于S的元组组成，记为R－S，即R－S = {x | x ∈ R∧x ∈S}

 

4. 笛卡儿积

Ø 设R和S分别是n元关系和m元关系，则R和S的笛卡儿积是一种(n + m)元关系，该关系是由R的每个元组分别与S每个元组进行“首尾并接”所获得的元组的集合，记为R×S，即R×S = {x_r  x_s| x_r ∈ R∧ x_s ∈ S}

Ø x_rx_s是表示由元组x_r和元组x_s并接而获得的新元组。

【例子】若是x_r =（1班，李好，78）且x_s =（03987，陈永江，01，3班），

则x_rx_s =（1班，李好，78，03987，陈永江，01，3班）。

Ø  关系R和S的元组个数分别为k_r和k_s，则R×S的元组个数为k_r×k_s。

 

 

•         2.2.2 关系运算

 关系一些特殊的运算，主要包括选择（σ）、投影（π）、链接（⋈ ）、除（/）等。

Ø  先约定一种表示方法：设x为某一个关系R的一个元组，L为R的关系模式的一个子集（即属性子集），则令x(L)表示由元组x在属性子集L上的全部份量构成的新元组。

【例子】对于关系R(A,B,C,D)，令x = (a , b ,c , d)，则x({A,B,C}) = (a , b , c)，x({C,D}) = (c , d)，x({B}) = (b)，等。

 

 

•                 选择σ

  从关系中筛选出知足既定条件的元组，这些元组组成了一个新的关系，这个操做过程称为选择。

Ø  选择的操做符用σ表示，选择条件则用逻辑公式来表示，用R表示逻辑公式。对关系R的选择运算就能够表示为σ_t(R)，即

σ_t(R) = {x | x∈R∧t(x) = true}

　　　　“t(x) = true”表示元组x知足条件公式t。对于选择运算，关键是设置选择条件t。

　　　　在数据查询中，条件公式t一般是由<、>、≤、≥、=、between、∧、∨等链接符号构成的条件表达式或逻辑表达式。

 

 

【例子】表2.3所示的学生关系student。令选择条件t = (性别=‘男’∧专业号=‘z3’)，则选择运算s_t(student)表示查找那些专业号为“z3”的男同窗，结果如表2.7所示。

 

 

 

2. 投影π

l  投影是指从关系中选出若干个指定的属性来组成新的关系。令投影的操做符为π，L为指定的属性子集，则关系R在属性子集L上的投影就能够表示为π_L(R)，即 π_L(R) = {x(L) | x ∈ R}

                           x(L)表示由元组x在属性集L上的取值构成的新元组。

l  投影还有一种表示方法就是在投影运算表达式π_L(R)中用指定的属性在关系R中的序号来代替L中的属性名。

 【例子】对于上述的投影π_{{姓名，性别}} (student)也能够表示为π_{2，3}(student)。

l  投影就是从关系表中按指定的属性抽取相应的列，这些列组成一个新的关系。

l  注意，投影运算是对列进行筛选，而选择运算则对行进行筛选。

 

 

【例子】对于表2.3所示的学生关系student，令L = {姓名，性别}，则学生关系在L上的投影：

         π_L(student)  = {x(L) | x∈  R}

      = {x({姓名，性别}) | x∈  R}

      = {(刘洋,男), (李思思,女), (陈永江,男), (王大河,男), (吕文星,男), (李鑫,女)}

 

结果如表2.8所示。

 

 

 

3. 链接  ⋈

   链接运算是二元运算，即涉及到两个关系的运算。假设参与运算的两个关系是R和S，则链接运算的结果是R和S笛卡儿积中知足属性间既定条件的元组的集合，即它是R和S笛卡儿积的一个子集。链接运算经常使用的主要有两种：等值链接和天然链接。

1）等值链接

     对于关系R和S，假设F和M分别是关系模式R和S的属性子集，若是按照F和M进行链接，则R和S的等值链接表示为：

 

x_rx_s表示由元组x_r和x_s链接起来而构成的新元组。等值链接R    S是R和S笛卡儿积的一个子集，子集中的元组在F和M上的取值相等。

 

 

2）天然链接

   天然链接是一种特殊的等值链接，它是在等值链接的基础上加上两个条件：

（1）参与比较的属性子集F 和M 必须是相同的，即F=M；

（2）造成的新关系中不容许存在重复的属性，若是有则去掉。R和S的天然链接能够表示为：

F是关系R和S都包含的属性（组）。

 

 

 

 表2.9和表2.10所示的两个关系，分别表示学生的基本信息和学生的考试成绩。

 

等值链接stu_info⋈ _{年龄=高数}grade和stu_info⋈ _{姓名=姓名}grade以及

天然链接stu_info ⋈ _姓名grade的结果分别见表2.十一、表2.12和表2.13所示。

从这三个结果的对比中读者不难比较这几种链接的区别。

 

 

 

4. 除/  

 

对于关系模式R(L_R)和S(L_S)，约定：

     L_R --- R的属性集

     L_S --- S的属性集

     L = L_R ∩L_S    (即L表示关系R和关系S的公共属性)

     L_x = {t(L) | t∈R∧t(L_R-L)=x}       (其中，x∈π_{LR -L}（R） ，L_x称为x在R中关于L的像集)

 

    R和S的除运算产生一个新关系R/S：

         该新关系由投影 x∈π_{LR -L}（R）中的某些元组组成，这些元组在R中关于L的像集包含S在L上的投影πL(S)。即：

相同部分所在行

 

 

 

 

 

2.3 关系数据库  

l  2.3.1 关系数据库的概念

      关系数据库（Relation database）是以关系模型为基础的数据库，它是利用关系来描述实体及实体之间的联系。简单地说，一个关系数据库是若干个关系的集合。一个关系可表示为一张二维表（也称数据表），一个关系数据库也能够理解为若干张二维表的集合。

Ø   一张数据表是由一系列的记录（行）组成，每一条记录由若干个数据项组成。数据项也是前面讲到的字段值、属性值，是关系数据库中最小的数据单位，不能再分解。

Ø  每一张数据表都有本身的表名。在同一个数据库中，表名惟一。当要访问数据库中的某一个数据项时，先经过表名找到相应的数据表，而后检索到该数据项所在的记录，最后经过记录访问到该数据项。

Ø  “元组”、“份量”等概念多用于描述关系模型，可理解为理论范畴中的概念；而“记录”、“数据项”则分别是“元组”、“份量”在关系数据库中的映象，理解为它们的实例化对象。它们基本上是对应的。这种对应关系说明如表2.15所示（但这种对应关系不是严格的，在使用中要视上下文而定）。

 

 

 

 

•         2.3.2 关系数据库的特色

     关系数据库的主要特色和优势包括：

Ø 具备较小的数据冗余度，支持建立数据表间的关联，支持较为复杂的数据结构。

Ø 应用程序脱离了数据的逻辑结构和物理存储结构，数据和程序之间的独立性高。

Ø 实现了数据的高度共享，为多用户的数据访问提供了可能。

Ø 提供了各类相应的控制功能，有效保证数据存储的安全性、完整性和并发性等，为多用户的数据访问提供了保证。

 

 

 

2.4 函数依赖

l  2.4.1 函数依赖的概念  

     定义2.3  设R(U)是属性集U上的一个关系模式，A, B ⊆ U，对于R(U)的任意一个可能的关系r，若关系r的两个元组x₁, x₂知足x₁(A) = x₂(A)，则必有x₁(B) = x₂(B)，那么A函数决定B，或称B函数依赖于A，记为A→B，A中的每一个属性都称为决定因素（Determinant），其中x₁(A)表示元组x₁在属性集A上的取值。若是A→B且B→A，则记为A↔B；若是A→B不成立，则记为  AB。

Ø  函数依赖不是指关系模式R(U)的某一个或某一些关系知足的约束条件，而是指关系模式R(U)的全部关系均须要知足的约束条件。

  【例2.2】表2.3所示的学生关系模式student（学号, 姓名, 性别, 专业号）。学号是不容许重复的，若是学号相同的两个学生元组在其余属性上的取值确定相同，能够推出{学号} →{姓名}, {学号} → {性别}, {学号} → {专业号}。

l  属性间的这种函数依赖关系跟语义有关，它属于语义范畴的概念。

 【例子】 若是不容许出现重名的学生元组，则能够有{姓名} →{学号}，进而{学号} ↔ {姓名}。

l  若是属性集是由单个属性构成，标志集合的大括号“{”和“}”能够省略，如“{学号} →{姓名}”能够写成“学号→ 姓名”。

l  注意，在实际数据库开发中，能够从用户提供的需求说明中或是从基本常识中获取函数依赖关系，例如上述“学号→ 姓名”就是一个基本常识。

 

 

 

     定义2.4   设R(U)是属性集U上的一个关系模式，A,B ⊆ U。若A→B是一个函数依赖，若是B→A，则称A→B为一个平凡函数依赖；若是B⊄A，则称A→B为一个非平凡函数依赖。

 

Ø 对于任意B⊆A，显然有A→B，它是一种平凡函数依赖。

【例子】“{学号, 姓名} → 姓名”是一种平凡函数依赖。因为平凡函数依赖没有实际意义，通常不予以讨论，在默认状况下提到的函数依赖均指非平凡函数依赖。

 

 

 

     定义2.5   设R(U)是属性集U上的一个关系模式，A, B ⊆ U。若A→B是一个函数依赖，而且对于任意C ⊆ A且C非空，均有C B，则称A→B是一个彻底函数依赖（Full functional dependency），即B彻底函数依赖于A，记为AB；不然称A→B是一个部分函数依赖（Partial functional dependency），即B部分函数依赖于A，记为AB。

【例2.3】表2.5所示的选课关系模式SC（学生编号，课程编号，成绩），{学生编号, 课程编号}     成绩，由于学生编号    成绩且课程编号    成绩。又如，表2.3所示学生关系模式student（学号, 姓名, 性别, 专业号），{学号, 姓名}     性别，确实有{学号, 姓名} → 性别，但学号→性别。

Ø 对于函数依赖A→B，若是A只包含一个属性，则必有A B中，由于这时的A不存在非空真子集。

 

 

 

     定义2.6   设R(U)是属性集U上的一个关系模式，A, B, C Í U。若A→B (B⊄A, B  A)，且B→C成立，则称C传递函数依赖于A，记为A C。

Ø 注意，此处加上条件B    A，是由于若是B→A，则实际上变为A↔B，即A→C，而不是A  C。

【例2.4】 对于关系模式—分班(学号, 班级号, 班长)，容易知道学号→ 班级号，班级号→ 班长，又由于班级号

学号，因而学号 班长。

 

•         2.4.2 候选码和主码

    定义2.7   在关系模式R(U)中，假设A ⊆ U，若是A U，则A称为关系模式R(U)的一个候选码；候选码可能有多个，从候选码中选择一个用于惟一标识关系中的每个元组，则该候选码称为主码（Primary key）。

Ø 含在任何候选码中的属性称为主属性（Prime attribute），不包含在任何码中的属性称为非主属性(Nonprime attribute)。一般将主码和候选码都简称为码。最简单的状况，单个属性构成码；最极端的状况，一个关系模式的全部属性构成码，称为全码（All key）。

Ø 对于候选码和主码，须要说明几点：

•          为正确理解候选码A，应该牢牢抓住其如下两个特性：

                  A能够函数决定U，即A→U。 

                  A具备极小性，即A的任何真子集都不可能函数决定U。

•          候选码可能有多个。若是有多个候选码，则它们的地位是平等的，任何一个均可以被设置为主码。在应用当中，通常是根据实际须要来将某一个候选码设置为主码。

 

 

 

     定理2.1    在关系模式R(U)中，对任意A, B ⊆U且A ∪ B = U，若是A     B，则有A  U，从而A是关系模式R(U)的一个候选码。

  【例2.5】 考虑如表2.16所示的学生成绩关系模式，其中U = {学号, 姓名，系别，成绩}。对于属性“学号”，容易验证：学号   {姓名，系别，成绩}，而{学号}∪{姓名，系别，成绩} = U。根据定理2.1，“学号”是学生成绩关系模式的一个候选码。

 

 

•          2.4.3 函数依赖的性质（Armstrong公理系统）

Ø 1974年Armstrong首次提出了这样的一套推理规则，由此构成的系统就是著名的Armstrong公理系统。

Ø 在关系模式R(U)中，假设A, B, C, D为U的任意子集。在Armstrong公理系统中，基于函数依赖集F的推理规则能够归结为如下3条：

ü 自反律：若C ⊆ B，则B→C为F所蕴含（平凡函数依赖）。

ü 增广律：若B → C为F所蕴含，则B∪D→C∪D为F所蕴含。

ü 传递律：若B→C且C→D为F所蕴含，则B→D为F所蕴含。

 

 

Ø 基于上述的推理规则，进一步获得下列的推理规则：

ü 自合规则：B→B。

ü 合并规则：若B→C且B→D，则B→C∪D。

ü 分解规则：若B→C∪D，则B→C且B→D。

ü 符合规则：若A→B且C→D，则A∪C→B∪D。

ü 伪传递规则：由B→C，A∪C→D，有A∪B→D。

 

 定理2.2   在关系模式R(U)中，B及B₁, B₂,…, B_n是U的子集，则B→B₁∪B₂∪…∪B_n成立的充分必要条件是B→B_i成立，其中i = 1,2,…,n。

 

 

 

2.5 关系模式的范式

Ø  范式一共分为六个等级，从低到高依次是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）和第五范式（5NF）。

Ø  高等级范式是在低等级范式的基础上增长一些约束条件而造成的，等级越高，范式的约束条件就越多，要求就越严格。各类范式之间的包含关系能够描述以下：

                               5NF ⊆ 4NF ⊆ BCNF ⊆ 3NF ⊆ 2NF ⊆ 1NF

Ø  经过模式分解，能够将一个低级别的范式转化为若干个高一级的范式，而这种转化过程称为规范化。

 

•         2.5.1 第一范式（1NF）

    定义2.8  设R(U)是一个关系模式，U是关系R的属性集，若U中的每个属性a的值域只包含原子项，即不可分割的数据项，则称R(U)属于第一范式，记为R(U)∈1NF。

  【例子】表2.17所示。该数据表所对应的关系模式不属于第一范式，由于其中每一个元组在“学生人数”属性上的属性值都不是原子项，它们均可以再分，实际上它们都是由两个原子项复合而成。为将其转化为第一范式，须要将复合项（非原子项）分解为原子项便可，结果如表2.18所示。

 

 

 

 

  【例2.6】假设有一个研究生信息管理系统，该系统涉及的信息主要包括导师信息、研究生信息以及所选课程信息（supervisor, student, course）等。设计了以下的一个关系模式：  SSC(学号, 姓名, 系别, 导师工号, 导师姓名, 导师职称, 课程名称, 课程成绩) 。

     根据常识能够知道：

•             一位研究生只有一位导师（不含副导师），但一位导师能够指导多位研究生；

•             一位研究生能够选修多门课程，一门课程也能够被多位研究生选修；

•             一位研究生选修一门课程后有且仅有一个成绩；

•             不一样的课程，课程名是不相同的，即课程名是惟一。

  

基于以上语义信息能够知道：

•   学号→{姓名, 系别}

•   学号→导师工号

•   导师工号→{导师姓名, 导师职称}

•   {学号, 课程名称}→课程成绩

Ø根据Armstrong公理及定理2.2能够推知：

  {学号, 课程名称}→{学号, 姓名, 系别, 导师工号, 导师姓名, 导师职称, 课程名称, 课程成绩}

Ø且能够进一步推知：

  {学号, 课程名称}     {学号, 姓名, 系别, 导师工号, 导师姓名, 导师职称, 课程名称, 课程成绩}

Ø根据定义2.7，{学号, 课程名称}是关系模式SSC的候选码，其实是惟一的候选码，因此故只能选择它为模式的主码。

 

 

 

关系模式SSC存在的缺点：

•      数据冗余

    关系中每一个元组既包含研究生信息，也包含导师信息以及所选课程的信息。一位导师可指导多名研究生，每一个研究生对应的元组都包含同一个导师的相同信息。一位导师带有多少名研究生就有多少条重复的导师信息。形成了数据冗余，若是数据量很大，就会浪费大量的存储空间，为这些数据的维护付出巨大的代价。

•      插入异常

    假设某个老师刚刚被聘为研究生导师，但尚未招收学生（这种状况常常出现），这时也就没有他的研究生信息和研究生选修课程的信息，意味着“学号”和“课程名称”等属性的属性值为空（null）。若是这时在关系SSC中插入该导师的信息，则会产生异常。由于属性“学号”和“课程名称”是主码，其取值不能为空。这种异常就是插入异常。插入异常的存在使得添加导师信息的操做没法完成。

 

 

•             删除异常

    假设某个导师刚招收了两名研究生，但过了一个学期之后，这两个研究生都因出国而注销学籍了。注销时，将这两个研究生对应的元组从关系SSC中删除（所有删除）。因为删除操做是以元组为单位进行的，因此导师信息也将所有被删除，之后就没法使用该导师的信息了，称为删除异常。

    关系模式SSC还容易产生数据不一致等其余的一些问题。仅知足第一范式的关系模式确实还存在许多问题。人们在第一范式的基础上增长一些约束条件，从而获得第二范式。

 

 

2.5.2 第二范式（2NF）

    定义2.9   设R(U)是一个关系模式，若是R(U)∈1NF且每一个非主属性都彻底函数依赖于任一候选码，则称R(U)属于第二范式，记为R(U)∈2NF。

l  第二范式是在第一范式的基础上，增长了条件“每一个非主属性都彻底函数依赖于任一候选码”，它比第一范式具备更高的要求。

l  若是一个关系模式的候选码都是由一个属性构成，该关系模式确定属于第二范式，此时每一个非主属性都显然彻底函数依赖于任一候选码。

l  若是一个关系模式的属性全是主属性，则该关系模式也确定属于第二范式，此时不存在非主属性。

 

 

 

  【例2.7】例2.6中的关系模式SSC(学号, 姓名, 系别, 导师工号, 导师姓名, 导师职称, 课程名称, 课程成绩)。该关系的惟一候选码为{学号, 课程名称}，所以“姓名”, “系别”, “导师工号”, “导师姓名”, “导师职称”, “课程成绩”等6个属性为其非主属性。不存在“学号”相同而“姓名”不一样的研究生元组，“姓名”函数依赖于“学号”，即“学号→ 姓名”。非主属性“姓名”并不是彻底函数依赖于码{学号, 课程名称}，此关系模式不属于第二范式。

Ø 由于关系模式SSC仅属于第一范式而不属于第二范式，这决定了它还存在数据冗余、插入异常和删除异常等问题。咱们经过模式的投影分解，将之分解为若干个子模式，使得每一个子模式都属于第二范式，从而解决上述问题。

Ø 先考察关系模式SSC中的函数依赖：

ü 学号→姓名

ü 学号→系别

ü 学号→导师工号

ü 导师工号→导师姓名

ü 导师工号→导师职称

ü {学号, 课程名称}       课程成绩

 

 

l  因为“学号”和“导师工号”都是单属性，所以上述函数依赖都是彻底函数依赖，一共有三种类型，所以在进行投影分解后可获得以下的三个关系模式：

Ø Student(学号, 姓名, 系别, 导师工号)

Ø supervisor(导师工号, 导师姓名, 导师职称)

Ø course(学号, 课程名称, 课程成绩)

l  这三个关系模式的码分别为学号、导师工号和{学号, 课程名称}，每一个关系模式中非主属性都彻底函数依赖于码。这三个关系模式都属于第二范式。

l  利用基于外码的天然链接能够将这三个关系合成原来的关系SSC，即 SSC = student⋈ _导师工号supervisor ⋈_学号course。外码的设置如：“导师工号”是student的关于supervisor的外码，“学号”是course的关于student的外码。

l  一个关系模式的码都是由一个属性构成，该关系模式确定属于第二范式，由于这时每一个非主属性都显然彻底函数依赖于码。

 

  【例2.8】设有关系模式teacher（课程名, 任课教师名, 任课教师职称），表2.19为关系模式teacher的一张关系表。假设每名教师能够上多门课，每门课只由一名教师上，请问关系模式teacher属于几范式？

 

关系模式teacher的候选码只有“课程名”，而“任课教师名”和“任课教师职称”都是非主属性。显然有函数依赖集{课程名→任课教师名, 任课教师姓名→任课教师职称, 课程名任课教师职称}，即每一个非主属性都彻底依赖于候选码，故关系模式teacher属于2NF。

 

 

 

上例中关系模式teacher属于2NF，仍存在数据冗余和插入、删除操做异常。

 

   【例子】若某任课教师上多门课，则须要在teacher表中存储屡次该教师的职称信息（数据冗余）；对于一个新来教师，若是其尚未排课，那么将没法输入该教师的信息，由于课程名做为主码不能为空（插入异常）；又如删除一个任课教师的全部任课记录，则找不到该任课教师姓名和职称信息了（删除异常）。致使这种数据冗余和操做异常的缘由在于该关系模式中存在传递函数依赖，这将在2.5.3节举例说明。

 

2.5.3 第三范式（3NF）

     定义2.10   设R(U)是一个关系模式，若是R(U)∈2NF且每一个非主属性都不传递函数依赖于任一候选码，则称R(U)属于第三范式，记为R(U)∈3NF。

          注意，若是一个关系模式的属性全是主属性，那该关系模式确定属于第三范式，由于该关系模式不存在非主属性。

    【例2.9】假设有一个关于学生选课信息的关系模式——s_c(学号, 课程号, 名次)，其相关语义是：学号和课程号分别是学生和课程的惟一标识属性，每一名学生选修的每门课程有一个名次，且名次不重复。

Ø 其函数依赖包括：{学号, 课程号} → 名次，{课程号, 名次} → 学号。{学号, 课程号}和{课程号, 名次}是此关系的候选码。其全部的属性都是主属性，此关系模式属于第三范式。

l  第三范式是在第二范式的基础上，增长了条件“每一个非主属性都不传递函数依赖于任一候选码”而获得的。

 

 

【例2.10】假设有一个关于员工信息的关系模式：emp_info(Eno, Ename, Dept, Dleader)。其中，Eno为员工编号，Ename为员工姓名，Dept为员工所在部门，Dleader为部门领导。请说明该关系模式属于第几范式以及它存在的问题。

Ø 员工编号是惟一的，每一个员工只属于一个部门，每一个部门只有一个领导（这里假设领导不属于员工范畴，且不考虑纵向领导关系）。员工编号（Eno）为惟一的码，由此容易推出：   

　　　　　　  Eno → Ename

                　　Eno → Dept

                       Eno → Dleader

Ø 显这些函数依赖都是彻底函数依赖。这些函数依赖说明了全部非主属性都彻底函数依赖于码Eno，因此关系模式emp_info属于第二范式。但该关系模式还存在下列的函数依赖：           

　　　Eno→Dept

          Dept→Dleader

          Eno→Dleader

 

l  上述说明非主属性Dleader传递函数依赖于码Eno，即关系模式emp_info中存在传递函数依赖，它不属于第三范式。传递函数依赖的存在一样会致使必定程度的数据冗余以及插入异常和删除异常等问题。这体如今：

Ø 一个部门有多个员工，每个员工在关系emp_info中都造成一个元组。该元组除了包含员工编号和姓名外，还包含所在部门和部门领导的信息。后两项信息会屡次重复出现，重复的次数与部门的员工数相等。这是数据冗余的根源。

Ø 数据冗余的存在致使数据维护成本增长。

Ø 当一个部门刚成立时，若是尚未招员工，那么将没法输入部门和部门领导的信息（主码Eno的输入值不能为null）。这就形成了插入异常。

Ø 出于某些缘由，部门的员工可能所有辞职，或者暂时所有转到其余部门去时，须要将全部的员工信息所有删除，这时部门和部门领导的信息也将被删除。这就致使了删除异常。

 

 

l  为消除传递函数依赖，可使用投影分解法将关系模式分解成相应的若干个模式

     【例子】根据存在的传递链“Eno→Dept→Dleader”，能够从节点“Dept”上将此传递链切开，造成如下两个模式：

             emp_info2(Eno, Ename, Dept)

             dept_info2(Dept, Dleader)

关系模式emp_info2的码为Eno，dept_info2的码为Dept。

l  在消除传递函数依赖后获得的两个关系模式emp_info2和dept_info2都属于第三范式，它们当中都不存在传递函数依赖。

    【例子】能够在没有员工信息的前提下插入部门信息；能够删除全部的员工信息而不影响部门信息；数据冗余度也有所下降了，从而也简化了其余的一些操做等。

l  属于3NF的关系模式主要是消除了非主属性对于候选的传递函数依赖和部分函数依赖，但并无考虑主属性和候选码之间的依赖关系。它们之间存在的一些依赖关系也会引发数据冗余和操做异常等问题。人们提出了更高一级的范式——BC范式。

 

 

2.5.4 BC范式（BCNF）

     定义2.11   设R(U)是一个关系模式且R(U) ∈1NF，若是对于R(U)中任意一个非平凡的函数依赖B→C，B必含有候选码，则称R(U)属于BC范式，记为R(U)∈BCNF。

l  若是要求B→C为非平凡的且彻底的，则要求该函数依赖的决定因素为候选码便可。

l  在BC范式的定义中并无明确提出其中的关系要属于3NF，可是该定义确实保证了“其非主属性既不部分函数依赖于候选码，也不传递函数依赖于候选码”，于是BCNF为3NF的一个子集，即BCNF⊆3NF。

 

 

 

对于BC范式中的每个关系R(U)，它们具备下列的性质：

u R(U)中的每个非主属性都彻底函数依赖于任何一个候选码。假设存在一个非主属性attr部分函数依赖于一个候选码B₀，即B₀ →^p attr。由部分函数依赖的定义，必存在B₀的一个真子集B₀′，使得B₀′→attr。因为B₀′→attr是一个非平凡函数依赖。根据BCNF的定义，B₀′必包含某一个候选码C₀。因为候选码B₀的真子集包含该候选码C₀，因此B₀也包含C₀且C₀异于B₀。这说明一个候选码包含一个异于本身的另一个候选码，这是不可能的。

u R(U)中的每个主属性彻底函数依赖于任何一个不包含它的候选码。假设存在一个主属性attr并不是彻底函数依赖于某一个不包含它的候选码B₀。当选择该候选码B₀为主码时，attr也不彻底函数依赖于主码B₀。这与主码的定义相矛盾。

u R(U)中没有属性彻底函数依赖于非候选码（包括主码）的属性集。假设存在一个异于任何一个候选码的属性集B₀和某一个属性attr，使得属性attr彻底函数依赖于B₀，即B₀      attr。但因为B₀   →^f   attr，因此显然有B→attr。由BCNF的定义，B₀必包含某一个候选码C₀。由于B₀异于任何一个候选码，因此B₀≠C₀，于是B₀真包含C₀，C₀为B₀的一个真子集。因为C₀为候选码，因此C₀→attr。这说明，存在B₀的一个真子集C₀，使得C₀→attr。但这与B₀  →^f attr相矛盾。

 

 

 

      定理2.3  设R(U)是一个关系模式，且R(U)Î3NF，若是R(U)只有一个候选码，则R(U)ÎBCNF。

     证实：对于R(U)中任意一个非平凡函数依赖C→D，假设R(U)惟一的候选码为B，只要证实C包含B便可。

     假设C不包含B，即B ⊄ C。因为B为候选码，因此B   →^f   U，进而可知B→U。由于C和D都为U的子集，因此由Armstrong公理，U→C，U→D，因而B→C，B→D；因为C→D为非平凡函数依赖，因此D ⊄C；因为C是任意的，因此C    B；加上条件假设B Ë C，因而：

          D ⊄ C，B ⊄ C，C  →/    B

            B→C

            C→D

          B→D

    D传递依赖于B，这与R∈3NF矛盾。证毕。

    特别地，在一个属于3NF的关系中，当仅有一个属性可以惟一标识每一个元组时，则这个关系属于BCNF，且该属性为惟一的候选码（也只能以它为主码）。

 

 

  【例2.11】观察例2.10中分解后造成的关系模式：emp_info2(Eno, Ename, Dept)

u 该关系模式中既没有部分函数依赖也没有传递依赖，因此属于3NF。且因为仅有惟一的属性Eno可以惟一标识每个元组，因此这个关系属于BCNF。  

u 定理2.3看起来很是简单，但它很是有用。在许多状况下，设计的关系每每都是有且仅有一个可以惟一标识每个元组的属性，这时只要保证不存在对该属性的部分函数依赖和传递函数依赖便可保证该关系属于BCNF，而不用对BCNF的定义进行验证，从而避免了复杂的验证过程，提升设计效率。

u 定理2.3中的条件只是一个关系属于BCNF的充分条件，但不是必要条件。也就是说，知足该定理条件的关系必属于BCNF，但不知足该定理条件的关系也可能属于BCNF，如例2.12。

 

 

   【例2.12】 对于学生住宿关系模式StuDom(学号, 姓名系别, 宿舍)而言，假定“姓名”属性也具备惟一性，那么关系模式StuDom拥有两个由单属性组成的候选码，分别是“学号”和“姓名”。因为非主属性，即“系别”和“宿舍”，不存在对任一候选码的部分或传递函数依赖，因此关系模式StuDom属于第三范式。同时关系模式StuDom中除“学号”和“姓名”外没有其它决定因素，因此StuDom关系模式属于BC范式。

u此例中，关系模式StuDom有两个候选码，分别是“学号”和“姓名”，而不是只有一个候选码（不知足定理2.3的条件），但它却属于BC范式。

u那么有没有属于第三范式的关系模式却不属于BC范式的状况呢？

 

 

    【例2.13】对教学关系模式Teach(学生, 教师, 课程)，若每一名教师只教授一门课，每门课可由多名任课教师教授，某一名学生选定某门课即对应一个固定的教师。获得下述函数依赖集：

     {学生, 课程}→教师

     {学生, 教师}→课程

     教师→课程

Ø {学生, 课程}和{学生, 教师}均是候选码。由于没有任何非主属性对码的传递函数依赖或部分函数依赖，故关系模式Teach属于三范式。关系模式Teach不属于BC范式，由于函数依赖“教师→课程”的决定因素——“教师”不含任一候选码。

u 若是一个关系模型中的关系模式都属于BCNF，则称该关系模型知足BCNF，称基于该关系模型的关系数据库知足BCNF。

u 一个知足BCNF的关系数据库已经极大地减小数据的冗余，对全部关系模式实现了较为完全的分解，消除了插入异常和删除异常，已经达到了基于函数依赖为测度的最高规范化程度。

 

2.6 关系模式的分解和规范化

l  2.6.1 关系模式的规范化

Ø  关系模式的规范化实际上就是经过模式分解将一个较低范式的关系模式转化为多个较高范式的关系模式的过程。

     从范式变化的角度看，关系模式的规范化是一个不断增长约束条件的过程；

     从关系模式变化的角度看，规范化是关系模式的一个逐步分解的过程。

Ø  关系模式的分解是关系模式规范化的本质问题，其目的是实现概念的单一化，即便得一个关系仅描述一个概念或概念间的一个种联系。经过分解能够将一个关系模式分红多个知足更高要求的关系模式，这些关系模式能够在必定程度上解决或缓解数据冗余、更新异常、插入异常、删除异常等问题。

Ø  关系模式分解实际上又是一个关系模式的属性投影和属性重组的过程，又称投影分解。投影和重组的基本指导思想是逐步消除数据依赖中不适合的成分，结果将产生多个属于更高级别范式的关系模式。

 

u 投影分解的步骤就是低级范式到高级范式转化的步骤，具体步骤是：

Ø 基于消除关系模式中非主属性对候选码的函数依赖的原则，对1NF关系模式进行合理的投影（属性重组），结果将产生多个2NF关系模式。 

Ø 基于消除关系模式中非主属性对候选码的传递函数依赖的原则，对2NF关系模式进行合理的投影，结果将产生多个3NF关系模式。 

Ø 基于消除关系模式中主属性对候选码的传递函数依赖的原则，对3NF关系模式进行合理的投影，结果将产生多个BCNF关系模式。

 

 

2.6.2 关系模式的分解

•             链接无损分解

    定义2.12   假设一个关系模式R(U)被分解成n个子关系模式：R₁(U₁),R₂(U₂),…, R_n(U_n)，其中U = R₁(U₁)∪R₂(U₂)∪…∪R_n(U_n)，并假设r, r₁, r₂,…, r_n分别属于关系模式R(U)及n个子关系模式的关系（二维表），若是这n个子关系的天然链接与原关系r相等，即r = r1 ⋈  r2 ⋈    …   ⋈ rn，那么这种分解称为（天然）链接无损分解，其中ri是r在Ui上的投影, i = 1,2,…n。

Ø  分解的基本思想之一是消除对候选码的部分函数依赖和传递函数依赖。咱们能够先在待分解的关系模式中找出这些部分函数依赖和传递函数依赖以及彻底函数依赖，而后“分解”部分函数依赖和传递函数依赖，使得这些函数依赖最终都变成彻底函数依赖，最后将这些彻底函数依赖所涉及的属性分别投影成新的关系便可。

     

 

   【例2.14】对于例2.6中的关系模式SSC(学号, 姓名, 系别, 导师工号, 导师姓名, 导师职称, 课程名称, 课程成绩)，请运用模式分解方法将其转化为若干个属于BC范式的关系模式。

Ø 关系模式SSC中惟一的候选码为{学号, 课程名称}。咱们先找出对候选码的全部彻底函数依赖、部分函数依赖和传递函数依赖：

•    {学号, 课程名称}     课程成绩

•    {学号, 课程名称}     {姓名, 系别}

•    {学号, 课程名称}     导师工号

•    导师工号      {导师姓名, 导师职称}

•    {学号, 课程名称}      {导师姓名, 导师职称}

 

 

 

 

u 如下找出部分函数依赖中的彻底函数依赖：

    由“{学号, 课程名称}      {姓名, 系别}”获得“学号      {姓名, 系别}”

    由“{学号, 课程名称}     导师工号 ”获得“学号      导师工号”

u 咱们根据以上全部的彻底函数依赖初步设定分解成的各关系模式（原则是“一个彻底函数依即为一个关系模式”）：

Ø T1(学号, 课程名称, 课程成绩)

Ø T2(导师工号, 导师姓名, 导师职称)

Ø T3(学号, 姓名, 系别)

Ø T4(学号, 导师工号)

 

 

 

u 为了减小数据冗余和减小数据维护的复杂性，能够将关系模式T4(学号, 导师工号)并到T3(学号, 姓名, 系别)中，从而造成新的关系模式——T3′(学号, 姓名, 系别, 导师工号)。这样，就获得以下的分解结果：

Ø T1(学号, 课程名称, 课程成绩)

Ø T2(导师工号, 导师姓名, 导师职称)

Ø T3′(学号, 姓名, 系别, 导师工号)

u 由定理2.3稍加分析能够知道，以上三个关系模式均属于BC范式，并且上述的分解是链接无损分解。

 

 

       定理2.4   假设S和T为关系模式R分解后所获得的两个关系模式，则该分解为链接无损分解的充分必要条件是：(S∩T) → (S-T)或(S∩T) → (T-S)

 

 

2. 保持函数依赖的分解

      定义2.13   设R(U)是一个关系模式，F为R(U)的一个函数依赖集，B,C为R(U)所涉及的属性集的子集。若是利用Armstrong公理系统中的推理规则可以从函数依赖集F中推出B→C，则称F逻辑蕴涵B→C。F所逻辑蕴涵的函数依赖的集合称为F的闭包，记为F⁺。

      定义2.14   设一个关系模式R(U)被分解成n个关系模式：R₁, R₂,…, R_n，F为R(U)的属性间函数依赖的集合，F₁, F₂,…, F_n分别为F在R₁, R₂,…, R_n上的投影。对于任意F所逻辑蕴涵的函数依赖B→C，总存在某一个F_i，使得F_i逻辑蕴涵B→C，则这种分解称为保持函数依赖的分解。 

 

 

3. 既保持函数依赖又具备天然链接无损的分解

Ø 链接无损分解和保持函数依赖的分解是两个相互独立的模式分解。但它们的优缺点具备必定的互补性。

Ø 链接无损分解能够保证分解所获得的关系模式通过天然链接后又获得原关系模式，不会形成信息的丢失。这种分解可能带来数据冗余、更新冲突等问题。

     缘由：链接无损分解不是按照关系模式所蕴涵数据语义来进行分解。而保持函数依赖的分解则正好是按照数据语义来进行分解，它可使分解后的关系模式相互独立。避免由链接无损分解带来的问题，但它在某些状况下可能形成信息丢失。一个天然的想法就是构造这样的分解：该分解既是保持函数依赖的分解，又具备天然链接无损的特性。这种分解就称为既保持函数依赖又具备天然链接无损的分解。

 

 

     【例2.15】  考虑例2.10中的关系模式：emp_info(Eno, Ename, Dept, Dleader)

Ø Eno为员工编号，Ename为员工姓名，Dept为员工所在部门，Dleader为部门领导。若是将该关系模式分解为：emp_info1(Eno, Ename, Dept)和emp_info2(Eno, Dleader)。易验证，这种分解虽然是链接无损分解，但会形成数据冗余、更新异常等问题。进一步分析还能够发现，该分解不保持函数依赖。例如，函数依赖Dept→Dleader既不被emp_info1的函数依赖集所逻辑蕴涵，也不为emp_info2的函数依赖集所逻辑蕴涵。

Ø 如今咱们将关系模式emp_info(Eno, Ename, Dept, Dleader)分解成以下的两个模式：

          emp_info2(Eno, Ename, Dept)

          dept_info2(Dept, Dleader)

Ø 能够验证，这种分解方法保持了函数依赖，同时又具备天然链接无损的特性，它是既保持函数依赖又具备天然链接无损的分解。