数据库是长期存储在计算机内的、有组织的、可共享的数据集合，数据库系统是指在计算机信息系统中引入数据库后的系统，一般由数据库、数据库管理系统（DataBase Management System，DBMS）、应用系统、数据库管理员（DataBase Administrator ，DBA）和用户构成。数据库系统的结构可以有多种不同的层次或不同的角度，其中典型的是三级划分法，其中包括三级模式和两级映射。

1. 三级模式与两级映射

数据库系统由外模式、概念模式和内模式三级构成。其关系如图 “数据库三级模式两级映射示意图” 所示。

由 “数据库三级模式两级映射示意图” 可以看出，整个数据库体系由数据库管理系统（DBMS）进行管理，其内容涉及底层的数据存储问题，顶层涉及与用户的交互，这种层次的划分，主要目标是使数据库体系内部耦合度更低，变得更为灵活。

外模式也称为子模式或用户模式，它对应的是我们平时所用到的数据库视图。外模式用来描述用户（包括程序员和最终用户）看到或使用的那部分数据的逻辑结构，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式，一个应用程序只能使用一个外模式。

概念模式也称为模式或逻辑模式，它对应我们平时所用到的数据表。概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图，用以描述现实世界中的实体及其性质与联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系。概念模式通常还包含有访问控制、保密定义和完整性检查等方面的内容，以及概念/ 物理之间的映射。一个数据库只有一个概念模式。

内模式对应于物理级数据库，是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。内模式不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示和存储记录的物理顺序，以及索引和存储路径等数据的存储组织。一个数据库只有一个内模式。

在数据库系统的三级模式中，模式是数据库的中心与关键；内模式依赖于模式，独立于外模式和存储设备；外模式面向具体的应用，独立于内模式和存储设备；应用程序依赖于外模式，独立于模式和内模式。

从数据库三级模式两级映射示意图可以看出，三级模式实际对应着数据库系统中的三个层次，这三个层次划分出来以后，为了达到“一个层次的变化不对其它两个层产生影响”的效果，提出了两级映射。两级映射分别是：外模式与概念模式之间的映射、概念模式与内模式之间的映射。

外模式与概念模式之间的映射：用于维护数据库的逻辑独立性。也就是说，有了这个映射，使得数据的逻辑结构改变时，应用程序不需要改变，只需要改变映射中的对应关系即可达到目的。

概念模式与内模式之间的映射：用于维护数据库的物理独立性。也就是说当数据的物理存储改变时，应用程序不需要改变。

2. ER模型

数据库系统是对现实世界中数据的一种抽象，正如在“数据库系统功能和特性”知识点中所描述的，首先我们将通过概念模型将现实世界抽象成为信息世界，然后再抽象成为基本数据模型，而最常使用的概念模型就是ER模型。

上图展示了一个简单的ER模型，我们通过该图进行ER模型的概念入门：

实体：客观存在并可相互区别的事物，可以是具体的人、事、物，也可以是抽象的概念或联

系。图学生-课程 ER模型中的“学生”与“课程”便是实体。

属性：实体所具有的某一特性称为属性，通常一个实体可以由多个属性来描述。图52中“学

生”实体旁边的“学号”、“姓名”、“班级号”便是属性。

联系：实体内部的联系通常是指组成实体的各属性间的关系。图学生-课程 ER模型中“选课”便是联系。

（1）ER模型实体联系类型

一对一联系（1: 1）：对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系。例：一个班级只有一个班主任，一个班主任也只在一个班级中任职。

一对多联系（1: n）：对于实体集A中的每一个实体，实体集B中有n（n>0）个实体与之联系。反之，实体集B中的每一个实体，实体集A中至多只有一个实体与之联系。

例：一个班级中有许多学生，而每个学生只在一个班级中学习。

多对多联系（m: n）：对于实体集A中的每一个实体，实体集B中有n（n>0）个实体与之联系。反之，实体集B中的每一个实体，实体集A中有m（m>0）个实体与之联系。一门课程同时有许多学生选修，而一个学生也可以选修多门课程。如学生-课程 ER模型图，该ER模型便属于m: n型。

（2）ER模型的集成

在数据库的概念设计过程中，由于系统都存在一定的复杂度，一次性设计全局ER图将存在较大风险，所以一般会先设计各子系统的局部ER图，然进行集成。

集成的方法：

多个局部E-R图一次集成；

（常用）逐步集成，用累加的方式一次集成两个局部E-R。

但由于各子系统应用所面临的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个局部ER图之间必定会存在许多不一致的问题，称之为冲突。因此，在合并ER图时，不能简单地将各个局部ER图画到一起，而是必须着力消除各个局部ER图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。各局部ER图之间的冲突主要有三类，分别是属性冲突、命名冲突和结构冲突。

1）属性冲突。属性冲突包括属性域冲突和属性取值冲突。属性冲突理论上好解决，只要换成相同的属性就可以了，但实际上需要各部门协商，解决起来并不简单。

2）命名冲突。命名冲突包括同名异义和异名同义。处理命名冲突通常也像处理属性冲突一样，通过讨论和协商等行政手段加以解。

3）结构冲突。结构冲突包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部ER图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是将属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部ER图中属性的并集，再适当调整属性的次序。

（3）ER模型转关系模式

ER图向关系模式的转换属于数据库的逻辑设计阶段的工作，该阶段需要将ER模型转换为某种DBMS能处理的关系模式，具体转换规则如下：

1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键。

2）一个1: 1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，每个实体的主键均是该关系的键属性；如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的主键和联系本身的属性。

3）一个1: n联系可以转换为一个独立的关系模式，也可以与任意n端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，而关系的主键为n端实体的主键；如果与n端实体对应的关系模式合并，则需要在该关系模式的属性中加入1端关系模式的主键和联系本身的属性。

4）一个m: n联系转换为一个独立的关系模式，与该联系相连的各实体的主键以及联系本身的属性均转换为关系的属性，而关系的主键为各实体主键的组合。

5）三个以上实体间的一个多元联系可以转换为一个独立的关系模式，与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性，而关系的主键为各实体主键的组合。

另外，还有四种情况是需要特别注意的：

1）多值属性的处理：如果ER图中某实体具有一个多值属性，则应该进行优化，把该属性提升为一个实体，通常称为弱实体；或者在转化为关系模式时，将实体的主键与多值属性单独构成一个关系模式；

2）派生属性的处理：因为派生属性可由其他属性计算得到，因此，在转化成关系模式时，通常不转换派生属性；

3）复合属性：比如：学生实体Students(学号，姓名，性别，家庭住址);然而“家庭住址”记录了邮编、省、市、街道信息；此“家庭住址”可以细分为更小的属性。家庭住址为复合属性；

4）在面向对象模型中，关系模式就对应类，关系模式的属性就对应类的属性。

3.关系运算

关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。

（1）并。计算两个关系在集合理论上的并集，即给出关系R和S（两者有相同元/ 列数），R∪S的元组包括R和S所有元组的集合，形式定义如下：

式中 t 是元组变量（下同）。显然，R∪S=S∪R。

（2）差。计算两个关系的区别的集合，即给出关系R和S（两者有相同元/ 列数），R-S的元组包括R中有而S中没有的元组的集合，形式定义如下：

（3）交。计算两个关系集合理论上的交集，即给出关系R和S（两者有相同元/ 列数），R∩S的元组包括R和S相同元组的集合，形式定义如下：

显然，R∩S = R-( R-S) 和R∩S = S-( S-R) 成立。

（4）笛卡尔积。计算两个关系的笛卡尔乘积，令R为有m元的关系，S为有n元的关系，则R×S是m+n元的元组的集合，其前m个元素来自R的一个元组，而后n个元素来自S的一个元组。形成定义如下：

若R有u个元组，S有v 个元组，则R×S有u×v个元组。

（5）投影。从一个关系中抽取指明的属性（列）。令R为一个包含属性A的关系，则

（6）选择。从关系R中抽取出满足给定限制条件的记录，记作：

其中F表示选择条件，是一个逻辑表达式（逻辑运算符+算术表达式）。选择运算是从元组（行）的角度进行的运算。

（7）θ连接。θ连接从两个关系的笛卡儿积中选取属性之间满足一定条件的元组，记作：

其中A和B分别为R和S上元数相等且可比的属性组。θ为“=”的连接，称为等值连接，记作：

（8）除。设有关系R( X，Y) 与关系S( Z) ，Y和Z具有相同的属性个数，且对应属性出自相同域。关系R( X，Y) ÷S( Z) 所得的商关系是关系R在属性X上投影的一个子集，该子集和S( Z) 的笛卡尔积必须包含在R( X，Y) 中，记为R÷S，其具体计算公式为：

例如，由 “表-关系R”与“表-关系S” 所示

关系R
UI	U2	U3	U4
a	b	c	d
a	b	e	f
c	a	c	d

关系S
U3	U4
c	d
e	f

则R÷S的求解过程为：首先，按除运算定义要求，确定X，Y，Z属性集合。Y是关系R中的属性集合，Z是S中全部属性的集合，即Z={ U3，U4} ，由于Y=Z，因此，Y={ U3，U4} ，X={ U1，U2} 。也就是说，R÷S结果集包含属性U1和U2；然后，将关系R的U1、U2（共有<a，b>、<c，a>两个元组）与关系S作笛卡尔积操作，结果如表 " R(U1,U2)*S " 所示

R(U1,U2)*S
U1	U2	U3	U4
a	b	c	d
a	b	e	f
c	a	c	d
c	a	e	f

通过检查表R(U1,U2)*S，可以发现元组<a，b>与S( Z) 的笛卡尔积被包含在R( X，Y) 中，而元组<c，a>与S( Z) 的笛卡尔积有一个元组未被包含在R( X，Y) 中，所以，结果集中只有元组<a，b>

4.元祖运算

在元组演算中，元组演算表达式简称为元组表达式，其一般形式为{ t | P( t ) } ，其中，t 是元组变量，表示一个元数固定的元组；P是公式，在数理逻辑中也称为谓词，也就是计算机语言中的条件表达式。{ t | P( t ) } 表示满足公式P的所有元组t 的集合。

在元组表达式中，公式由原子公式组成，原子公式有下列两种形式：

（1）R( s ) ，其中R是关系名，s 是元组变量。其含义是“s 是关系R的一个元组”。

（2）s [ i ] θu[ j ] ，其中s 和u是元组变量，θ是算术比较运算符，s [ i ] 和u[ j ] 分别是s 的第i 个分量和u的第j 个分量。原子公式s [ i ] θu[ j ] 表示“元组s 的第i 个分量与元组u的第j 个分量之间满足θ运算”。例如，“t [ 2] <u[ 3] ”表示元组t 的第2个分量小于元组u的第3个分量。这个原子公式的一种简化形式是s [ i ] θa或aθu[ j ] ，其中a为常量。例如，“t [ 4] =3”表示t 的第4个分量等于3。

在一个公式中，如果元组变量未用存在量词“ $\huge \exists$ ”或全称量词“ $\huge \forall$ ”等符号定义，那么称为自由元组变量，否则称为约束元组变量。公式的递归定义如下。

（1）每个原子是一个公式，其中的元组变量是自由变量。

（2）如果P1和P2是公式，那么，也是公式。

（3）如果P1是公式，那么也都是公式。

（4）公式中各种运算符的优先级从高到低依次为θ、 $\huge \exists$ 和 $\huge \forall$ 、、 $\huge \wedge$ 和 $\huge \vee$ 、→。在公式外还可以加括号，以改变上述优先顺序。

（5）公式只能由上述四种形式构成，除此之外构成的都不是公式。

在元组演算的公式中，有下列四个等价的转换规则：

（1）

（2）

（3）( $\huge \forall$ s ) ( P1( s ) ) 等价于；

( $\huge \exists$ s) ( P1( s ) ) 等价于；

（4）P1→P2等价于

关系代数表达式可以转换为元组表达式，例如，R∪S可用{ t | R( t ) $\huge \vee$ S( t ) } 表示，RS可用{ t | R( t ) $\huge \wedge$ S( t ) }表示

二、规范化理论

不同的人对于相同的东西可以建立不同的模型，如何衡量模型建立的好坏？换而言之，按照什么原则建立模型？这个原则就是规范化理论。

1. 规范化理论的作用

设有一个关系模式R（SNAME，CNAME，TNAME TADDRESS），其属性分别表示学生姓

名、选修的课程名、任课教师姓名和任课教师地址。仔细分析一下，就会发现这个模式存在下列存储异常的问题：

（1）数据冗余：如果某门课程有100个学生选修，那么在R的关系中就要出现100个元组，这门课程的任课教师姓名和地址也随之重复出现100次。

（2）修改异常：由于上述冗余问题，当需要修改这个教师的地址时，就要修改100个元组中的地址值，否则就会出现地址值不一致的现象。

（3）插入异常：如果不知道听课学生名单，这个教师的任课情况和家庭地址就无法进入数据库；否则就要在学生姓名处插入空值。

（4）删除异常：如果某门课程的任课教师要更改，那么原来任课教师的地址将随之丢失。

因此，关系模式R虽然只有四个属性，但却是性能很差的模式。产生这些异常的原因与关系模式属性值之间的联系直接有关。在模式R中，学生与课程有直接联系，教师与课程有直接联系，而教师与学生无直接联系，这就产生了模式R的存储异常。如果将R分解成下列两个关系模式：R1（SNAME，CNAME）和R2（CNAME，TNAME，TADDRESS），则能消除上述的存储异常现象。

2．函数依赖

函数依赖是数据库的一种约束，决定了关系模式属于哪种范式。为了理解方面，下面我们先介绍函数依赖的有关概念。

设R( U) 是属性U上的一个关系模式，X和Y是U的子集，r 为R的任一关系，如果对于r 中的任意两个元组u，v，只要有u[ X] =v [ X] ，就有u[ Y] =v[ Y] ，则称X函数决定Y，或称Y函数依赖于X，记为X→Y。

例如，记录职工信息的结构如下：

职工工号（EMP_ NO）

职工姓名（EMP_ NMAE）

所在部门（DEPT）

我们说EMP_ NO函数决定EMP_ NMAE和DEPT，或者说EMP_ NMAE，DEPT函数依赖于EMP_ NO，记为：EMP_ NO→EMP_ NMAE，EMP_ NO→DEPT。

3．键

超键：在关系模式中，能唯一标识元组的属性集称为超键。

候选键：一个属性集能唯一标识元组，且又不含有多余属性。

主键：关系模式中用户正在使用的候选键称为主键。

外键：如果公共关键字在一个关系中是主关键字，那么这个公共关键字被称为另一个关系的外键。

例如，记录职工信息的结构如下：

职工工号（EMP_ NO）

职工身份证号（EMP_ CARDID）

职工姓名（EMP_ NMAE）

职工性别（EMP_ SEX）

所在部门编号（DEPT_ NO）

在此关系中：

（1）EMP_ NO和EMP_ NMAE的组合是超键。

理由：EMP_ NO和EMP_ NMAE的组合能唯一标识元组的属性。

补充说明：其实只需要EMP_ NO就可以唯一标识元组的属性，所以EMP_ NO是本关系的候选键，也可以是本关系的主键。

（2）EMP_ NO 和EMP_ CARDI D是候选键。

补充说明：一个关系的候选键可以有多个。

（3）EMP_ NO 或EMP_ CARDI D可选作本关系的主键。

补充说明：一个关系的候选键有多个，但主键只能有一个，通常在候选键中选一个作为主键。

（4）DEPT_ NO为本关系相对于部门关系的外键。

理由：DEPT_ NO在本关系中不是主键，而在部门关系中是主键，所以它是本关系的外键。

补充说明：外键的作用是进行连接操作。例如现在要查找某个职工所在的部门名称，我们就需要用到外键来与部门关系进行连接，连接之后可以得到职工所在部门的名称。

求解关系模式的候选键

求关系模式的候选键是进行范式界定的基础，也是系统分析员应该掌握的基本技能。使用候选键的定义“如果一个属性集能唯一标识元组，且又不含有多余属性。”来求解一个简单关系模式的候选键尚能应对，但面对复杂一些的关系模式，这种方法就不管用了。在此，引入一种求候选键的快捷方法，即图示法。

使用图示法求候选键，主要有三个步骤：

（1）将关系的函数依赖关系，用“有向图”的方式表示。

（2）找出入度为0（没有箭头指向该结点）的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键。

（3）若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点（既有入度，也有出度的结点）并到入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键。

例如，给定关系R( A1，A2，A3，A4) 上的函数依赖集F={ A1→A2，A3→A2，A2→A3，

A2→A4} ，现在要求R的候选关键字。

第一步，需要针对函数依赖集画出有向图，如 “函数依赖集对应有向图” 所示

第二步，从该图中找出入度为0的结点，本图中入度为0的结点只有1个，即A1。通过尝试，可以发现从A1出发可以遍历有向图中的所有结点，所以本关系模式的候选键为A1

4. 范式

在数据库设计过程中，往往遇到数据冗余、修改异常、插入异常和删除异常等，为了设计一个好的数据库，人们定义了一些好的关系模式标准，称它们为规范的关系模式( 简称范式，NF) 。目前共定义了多个范式，分别为1NF、2NF、3NF、BCNF、4NF和5NF。但实际应用中，一般只要达到3NF。

如果有X→U在关系模式R( U) 上成立，并且不存在X的任一真子集X′使X′→U成立，那么称X是R的一个候选键。也就是X值惟一决定关系中的元组。

在R( U) 中，如果X→Y，并且对于X的任何一个真子集X′，都有X′→Y不成立，则称Y对X完全函数依赖。若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖（注意：此处的X是一个属性集）。

如 “部分函数依赖示意图” 所示：X1X2→Y，又有X1→Y，则Y部分函数依赖于X1X2

如传递函数依赖示意图所示：在R( U) 中，如果X→Y（Y不是X的真子集），且Y→X不成立，Y→Z，则称Z对X传递函数依赖

有了上述的函数依赖概念之后，我们再介绍范式的概念。

第一范式（1NF）：在关系模式R中，当且仅当所有域只包含原子值，即每个分量都是不可再分的数据项，则称实体E是第一范式。本书中所引用的关系模式，一般都达到了第一范式的要求。

如 “教师职称情况关系表” 就不满足第一范式的要求

教师职称情况关系表
系名称	高级职称人数
系名称	教授	副教授
计算机系	9	15
电子系	4	10

原因在于该关系模式中的“高级职称人数”不是一个原子属性，将其拆分为“教授”和“副教授”两个属性，则满足1NF。满足1NF的关系模型会有许多重复值，并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏，我们需要更加规范的第二范式（2NF）。

第二范式（2NF）：当且仅当实体E是第一范式（1NF），且每一个非键属性完全依赖主键（没有不完全依赖）时，则称实体E是第二范式。

注：非键属性完全依赖又称部分函数依赖。

例如，有选课关系模式SC( Sno，Cno，Grade，Credit ) ，其中：( Sno，Cno) →Grade，Cno→Credit

由此可知SC的主键为：( Sno，Cno) 。这样( Sno，Cno) →Credit 就被称为Credit 对主键( Sno，Cno) 的部分函数依赖，即Credi t 属性只需要主键的一部分Cno即可确定。所以本关系模式不符合2NF，只是1NF。若要将该关系模式转化为2NF，可以将关系模式拆分为：SC1( Sno，Cno，Grade)和SC2( Cno，Credit ) ，同时也解决了数据重复的问题。

第三范式（3NF）：当且仅当实体E是第二范式（2NF），且E中没有非主属性传递依赖于码时，则称实体E是第三范式。

例如，学生关系Sudent （Sno，Sname，Dno，Dname，Locat i on）各属性分别代表学号，

姓名，所在系，系名称，系地址。其数据如表 “关系Student” 所示，从关系模式中各属性之间的联系可以判断出本关系模式的函数依赖有：Sno→Sname，Sno→Dno，Sno→Dname，Sno→Location，

Dno→Dname，Dno→L ocation。显然，Sno为主键。在函数依赖中有：Sno→Dno→Dname与Sno→Dno→L ocation。这便是传递函数依赖。由于Dname与Location为非主属性，同时传递依赖于码，所以本关系模式不满足3NF。若要满足3NF，需要将关系模式拆分为：Sudent （Sno，Sname，Dno）和Department（Dno，Dname，Location）

关系Student
Sno	Sname	Dno	Dname	Location
1	Jack	D001	电子系	1号楼
2	Zhang	D001	电子系	1号楼
3	Wang	D001	电子系	1号楼
4	Lily	D002	计算机系	2号楼

BCNF：如果关系模型R∈1NF，且R中每一个函数依赖关系中的决定因素都包含码，则R是满足BC范式的关系，记作R∈BCNF。

根据此定义，消除了任何属性对码的传递依赖与部分依赖即为BCNF。但要判断任何属性是否对码存在传递依赖并不是一件容易的事情。

例如，有关系模式P( C，S，T，R) ，根据语义有函数依赖F={ C→T，ST→R，TR→C} ，现在需要判断该关系模式是否满足BCNF。此时我们需要分析其是否存在传递依赖。根据之前的图示法求候选键的方法，我们可以先画出相应的函数依赖图。

对该图进行分析，可以得知本关系模式的候选键有：（S，T）和（S，C），所以主属性为：S、T、C，非主属性为：R。

由于有C→T，而C不包含候选键，所以本关系模式不满足BCNF

一个BCNF的关系模式必须满足以下条件：

所有非主属性对每一个码都是完全函数依赖；
所有非主属性对每一个不包含它的码，也是完全函数依赖；
没有任何属性完全函数依赖于非码的任何一组属性，即每一个函数依赖的左部都必须包含候选键。

若某关系模式不满足以上任意一条，则它不满足BCNF

根据各范式的定义，各级范式这间存在如下关系：

1NF $\huge \subset$ 2NF $\huge \subset$ 3NF $\huge \subset$ BCNF

主属性和非主属性是互补的，一个关系模式中的属性不是主属性就是非主属性。组成候选码的属性就是主属性，其它的就是非主属性，所以要判断关系模式中的属性是主属性还是非主属性，首先要求解出其候选码。

5. 关系模式分解

如果某关系模式存在存储异常等问题，则可通过分解该关系模式来解决问题。将一个关系模式分解成几个子关系模式，需要考虑的是该分解是否保持函数依赖，是否是无损连接。

（1）无损联接分解

在理解无损联接分解前，我们需要明确一个概念：什么叫有损，什么又是无损？

有损——分解后不能还原；无损——分解后可以还原。

无损联接分解：指将一个关系模式分解成若干个关系模式后，通过自然联接和投影等运算仍能还原到原来的关系模式。

无损连接分解定义如下：设R是一个关系模式，F是R上的一个函数依赖集。R分解成数据库模式δ={ R1，…，RK} 。如果对R中每个满足F的关系r都有下式成立：

r=ϖR1(r) ϖR2(R) … ϖRK(r)

则称分解δ相对于F是无损联接分解，否则称为损失联接分解。

要根据上述定义来判断一个分解是否是无损联接，这是一件很困难的事情，所以常常用公式法和表格法来解决这个问题。

方法一：公式法

优点：速度快。

缺点：只能应用于一分为二的情况，一个关系模式要分解为三个关系模式就用不上了。

判定定理：设ρ={ R1，R2} 是R的一个分解，F是R上的函数依赖集，那么分解ρ相对于F是无损联接分解的充要条件是( R1∩R2) →( R1R2) 或( R1∩R2) →( R2R1) 。要注意的是，这两个条件只要有任意一个条件成立就可以了。

方法二：表格法

优点：速度慢。

缺点：适用于所有形式的模式分解。

对于表格法，由于其方法复杂，所以在此用一个例题进行讲解。

例：

设关系模式R( U, F），其中R上的属性集U={ A,B,C,D,E} ，R上的函数依赖集F=｛A→B, DE→B, CB→E，E→A，B→D｝。分别判断：p1=｛R1( AC) , R2( ED) , R3( AB) ｝、p2=｛R1,( ABC) , R2( ED) , R3( ACE) ｝是否为无损连接？

首先可以利用之前讲到的图示法求出本题的候选键，求得关系R有三个候选键：BC、EC，AC。

接下来是判断模式分解过程中的无损连接的问题。这个问题相对来说比较复杂。

需要列表来进行分析。对p1=｛R1( AC) , R2( ED) , R3( AB) ｝构造初始的判定表

由于A→B，属性A的第1行和第3行相同，可以将第3行b32改为a 2 ；E→A，属性E的第2行和第3 行相同，可以将属性A第2行b21改为a1；AC→E，属性E的第2行和第3行相同，可以将属性E第1行 b15改为a 5 ；B→D，属性B的第1行和第3行相同，所以需要将属性D第1行b14和第3行b34，改为同一符号，即取行号值最小的b14。E→D，属性E的第1～3行相同，可以将属性D第1行b14和第3行b34改为a 4