第9讲关系模式的分解与范式
《关系模式分解》课件
索引优化
通过合理的关系模式分解，可以 为查询语句创建更有效的索引， 提高查询效率。
查询优化
分解后的关系模式可以简化查询 逻辑，减少查询复杂度，提高查 询效率。
缓存策略应用
利用数据库的缓存策略，可以减 少对物理存储的访问次数，提高 数据查询效率。
05
CATALOGUE
关系模式分解的挑战与未来发展
数据冗余问题
数据完整性维护
主键和外键约束
01
关系模式分解后，可以通过主键和外键约束来维护数据的完整
性，确保数据的准确性和一致性。
数据完整性检查
02
通过定期的数据完整性检查，可以及时发现并修复数据异常，
保证数据的可靠性。
事务处理能力
03
关系模式分解后，可以利用数据库的事务处理能力，确保数据
的完整性和一致性。
数据查询效率提升
案例二
总结词
数据安全与隐私保护
详细描述
某银行客户信息管理系统涉及到客户、账户、交易等多个实体的关系，这些关系中包含敏感信息。通 过关系模式分解，可以将敏感信息隐藏在虚拟属性中，降低数据泄露的风险，提高数据的安全性和隐 私保护。
案例三：某社交网络的关系模式分解
总结词
网络结构分析
详细描述
社交网络中存在着各种复杂的关系，如用户之间的关注关系、互动关系等。通过关系模 式分解，可以深入分析这些关系的结构特征，挖掘网络中的核心节点和社区结构，为社
关系模式分解
目录
• 关系模式分解简介 • 关系模式分解的基本概念 • 关系模式分解的方法 • 关系模式分解的应用 • 关系模式分解的挑战与未来发展 • 关系模式分解的案例分析
01
CATALOGUE
范式理论
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式等价，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。
数据库范式的判断及分解
数据库范式的判断及分解在数据库设计中，范式是一种评估关系模式的方法。
范式是规范化关系模式的一个过程，旨在减少数据冗余，提高数据的一致性和完整性，增强数据的可维护性和查询效率。
在本篇文章中，我们将讨论数据库范式的判断和分解以及如何通过规范化来改善数据库的性能和可维护性。
第一范式（1NF）第一范式是关系模型的基础，它要求关系模式的每个属性必须是不可分的原子值。
例如，如果一个属性保存了多个值，那么它不符合第一范式。
可以通过将该属性拆分为单个属性来解决这个问题。
同时，需要注意的是，重复的记录不应存在于同一个关系中。
第二范式（2NF）第二范式要求非主属性必须完全依赖于关系模式的全部主属性。
因此在设计数据库时，需要将属性进行分解，使得每个非主属性都只依赖于一个唯一的主属性。
例如，在一个包含订单信息和订单明细信息的表中，如果订单明细信息可以通过订单号和产品号访问，那么它就可以成为一个独立的表。
第三范式（3NF）第三范式要求非主属性不依赖于其他非主属性。
如果存在这样的依赖关系，需要将非主属性拆分为独立的关系。
例如，在一个包含雇员信息和部门信息的表中，如果部门号和部门经理都通过雇员号进行访问，则需要将部门信息拆分为一个独立的表。
其他范式此外，还存在其他的范式，如BCNF、4NF、5NF等，它们都是在第三范式基础上进一步增强关系正确性和一致性的。
在实际应用中，通常只需要使用1NF、2NF、3NF和BCNF这几种范式。
范式的优缺点范式的目的是提高数据库的一致性和减少数据的冗余。
但是，范式化可能会导致查询时需要进行多表联结（join），这可能会影响查询效率。
因此，在实际应用中，需要权衡数据库的性能和一致性。
如果数据库的性能是至关重要的，则可以使用数据冗余来提高查询效率。
如果一致性和数据完整性是最重要的，则需要采用范式化设计。
总结范式化设计是数据库设计的基础。
它是优化数据库性能和数据一致性的重要工具，在设计数据库时，需要权衡数据库的性能和一致性，并根据实际需求选择合适的范式化水平。
关系模式的分解准则
关系模式的分解准则
关系模式的分解准则有：
（1）实体冗余（E-R）分解法。
根据E-R模式的规则，可以把一个实体分成多个实体，其中重要的实体可以多次出现。
（2）覆盖索引（CRC）分解法。
它考虑了实体约束和属性约束，用两个分解条件来分解关系模式，即冗余表分解（RD）和实体冗余分解（ERD）。
（3）非集中规范化（3NF）分解法。
它强调的是保持一般情况表的不可分割性，
其分解方法是根据实体与属性的约束，从模式中把出现在死关系中的属性拆分出来。
（4）最终规范化（BCNF）分解法。
这种分解方法更强调实体的约束，它是根据实体与实体之间的约束，把关系拆分成几个满足BCNF规范化要求的子集。
数据库范式与关系模式示例
补充讲义一、范式举例BCNF.如：课程号与学号）例4：R(X,Y,Z),F={XY->Z},R为几范式？BCNF。
例5：R(X,Y,Z),F={Y->Z，XZ->Y},R为几范式？3NF。
R的候选码为{XZ,XY}，（R中所有属性都是主属性，无传递依赖）二、求闭包数据库设计人员在对实际应用问题调查中，得到的结论往往是零散的、不规范的（直观问题好办，复杂问题难办了），所以，这对分析数据模型，达到规范化设计要求，还有差距，为此，从规范数据依赖集合的角度入手，找到正确分析数据模型的方法，以确定关系模式的规范化程度。
例1．已知关系模式R(U、F)，其中，U={A,B,C,D,E}; F={AB→ C, B→ D, EC → B , AC→B} ,求（AB）+F.解：设X(0)=AB○1计算X(1),在F中找出左边为AB子集的FD,其结果是：AB→C,B→D∴X(1)=X(0)UB=ABUCD=ABCD 显然，X(1)≠X(0)○2计算X(2),在F中找出左边为ABCD子集的FD，其结果是：C→E,AC→B∴X(2)=X(1)UB=ABCDUBE=ABCDE 显然，X(2)=U所以，（AB）+ F=ABCDE.（等于U，所以AB是唯一候选关键字）例2．设有关系模式R(U、F)，其中U={A,B,C,D,E，I};F={A→D,AB→E,B→E,CD→I,E→C},计算（AE）+解：令X={AE},X(0)=AE○1在F中找出左边是AE子集的FD,其结果是：A→D,E→C∴X(1)=X(0)UB=X(0)UDC=ACDE 显然，X(1)≠X(0)○2在F中找出左边是ACDE子集的FD，其结果是：CD→I∴X(2)=X(1)UI=ACDEI显然，X(2)≠X(1)，但F中未用过的函数依赖的左边属性已含有X(2)的子集，所以不必再计算下去，即（AE）+=ACDEI.因为，X（3）＝X（2），所以，算法结束。
关于关系数据库模式分解与范式的总结
1.关系模式设计不规范会带来一系列的问题数据冗余更新异常插入异常删除异常因此需要一个标准的模式来解决这些问题，引入模式分解来解决存在问题。
2.无损连接的概念比较好懂，就是要保证模式分解后仍然可以根据分解后的关系回退回分解前。
这可以保证分解过程没有丢失信息，不会破坏和更改已经存在的。
而检验无损连接的方法分为两种：①当R分解为两个关系模式R1和R2时，有一种简便的方法可以测试无损连接性p＝{R1,R2}p是无损连接的分解当且仅当下面之一满足（R1 ∩R2）→（R1－R2）（R1 ∩R2）→（R2－R1）其中R1 ∩R2指模式的交，返回公共属性R2－R1表示模式的差集，返回属于R2但不属于R1的属性集也可以理解为R1∩R2的结果是R的超码，即该结果可以推出全部R属性。
②当R分解为多个关系模式时，可以使用chase算法：举个栗子R(A,B,C,D,E)R1(A,D), R2(A,B), R3(B,E), R4(C,D,E), R5(A,E)F={A→C, B→C, C→D, DE→C, CE→A}判断R分解为p＝{R1,R2,R3,R4,R5}是否是无损连接的分解？第一步，构造初始表。
第二步，处理表A→C：将b23，b53改为b13B→C：将b33改为b13C→D：将b24，b34，b54改为a4DE→C：将第3行和第5行的C改为a3CE→A：将第3行和第4行的A改为a1处理后BE行将全变为a，证明为无损连接。
3.函数依赖（FD）的表现形式是x→y,可以根据函数的概念理解,当x属性的值相同时，可以断定y也一定相同。
在实际关系模式中，x与y会存在逻辑上的相关性，如一个学号会对应一个姓名。
要理解函数依赖是关系模式的内涵，保持函数依赖才能保持关系模式中存在的关系。
举个栗子：R(city, street, zip), F={(city,street)→zip, zip→city}分解为p={R1(street,zip),R2(city,zip)}在R1中插入（’a’,’100081’）和（’a’,’100082’）R2中插入（’Beijing’,’100081’）和（’Beijing’,’100082’）R1∞R2：得到违反了(city,street)→zip，因为它被丢失了，语义完整性被破坏。
关系模式分解
4.2 关系模式的规范化
三、第二范式： 2NF 定义4.6 若R∈1NF，且R中的每一个非主属性都完全函数 依赖于R的任一候选码，则R∈2NF。 例：学生关系S(S#，SNAME，CLASS，C#，TNAME，TAGE， ADDRESS，GRADE),判断R是否为2NF? 侯选码为(S#，C#)，非主属性有：SNAME，CLASS， TNAME，TAGE，ADDRESS，GRADE (S#，C#)－>SNAME， S# －> SNAME (S#，C#) P >SNAME S2NF(每一个非主属性!)。
4.1函数依赖
二、函数依赖functional dependency, abbr. FD
设：R（A1，A2，…An)=R( U ) X，Y，Z 为U的不同子集
属性全集
定义4.1： ① 函数依赖 是完整性约束的一种，它推广了关键词 的概念。If t1.X=t2.X, then t1.Y=t2.Y ②函数依赖：若R的任意关系有：对X中的每个属性值， 在Y中都有惟一的值与之对应，则称Y函数依赖于X， 记作 XY 。
4.2 关系模式的规范化
定理4.1 一个3NF的关系必定是 2NF。 （3NF传递函数依赖，2NF完全函数依赖。） 证明：用反证法。设R∈3NF，但R2NF，则R中必有非 主属性A、侯选码X和X的真子集X‘存在，使得X’→A。 X’是侯选码X的真子集，有X-X‘≠ф ；A是非主属性，AX≠ф ，A-X‘≠ф ，这样A、X、X‘是U的不同子集。 X’是侯选码X的真子集，则有X→X’ 且 X’+>X，联合反 证假设X’→A可知存在传递依赖（X→X’，X’+>X，X’→A） R不是3NF，与题设矛盾。
关系模式文档
4.1 名词解释(1)函数依赖：FD(function dependency)，设有关系模式R(U)，X，Y是U的子集， r是R 的任一具体关系，如果对r的任意两个元组t1,t2,由t1[X]=t2[X]导致t1[Y]=t2[Y], 则称X 函数决定Y,或Y函数依赖于X，记为X→Y。
X→Y为模式R的一个函数依赖。
(2) 函数依赖的逻辑蕴涵：设F是关系模式R的一个函数依赖集，X，Y是R的属性子集，如果从F中的函数依赖能够推出X→Y，则称F逻辑蕴涵X→Y,记为F|=X→Y。
(3) 部分函数依赖：即局部依赖，对于一个函数依赖W→A，如果存在X W(X包含于W)有X→A 成立，那么称W→A是局部依赖，否则称W→A为完全依赖。
(4)完全函数依赖：见上。
(5) 传递依赖：在关系模式中，如果Y→X，X→A，且X Y（X不决定Y）， A X（A不属于X）,那么称Y→A是传递依赖。
(6) 函数依赖集F的闭包F+: 被逻辑蕴涵的函数依赖的全体构成的集合，称为F的闭包(closure),记为F+。
(7) 1NF：第一范式。
如果关系模式R的所有属性的值域中每一个值都是不可再分解的值, 则称R是属于第一范式模式。
如果某个数据库模式都是第一范式的，则称该数据库存模式属于第一范式的数据库模式。
第一范式的模式要求属性值不可再分裂成更小部分，即属性项不能是属性组合和组属性组成。
(8) 2NF：第二范式。
如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称是第二范式模式；如果某个数据库模式中每个关系模式都是第二范式的，则称该数据库模式属于第二范式的数据库模式。
(注：如果A是关系模式R的候选键的一个属性，则称A是R的主属性，否则称A是R的非主属性。
)(9)3NF：第三范式。
如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。
如果某个数据库模式中的每个关系模式都是第三范式，则称为3NF的数据库模式。
关系模式分解的两种主要准则
关系模式分解的两种主要准则关系模式分解的两种主要准则在数据库设计过程中，关系模式分解是一个重要的步骤，它将一个复杂的关系模式分解为多个简单的关系模式。
这个过程有助于提高数据库的性能和可维护性。
在关系模式分解过程中，有两种主要的准则，即函数依赖和多值依赖。
函数依赖函数依赖是关系模式分解的重要准则之一。
函数依赖描述了一个关系模式中的属性之间的关系。
在一个关系模式中，如果一个属性的值可以通过其他属性的值来确定，那么我们说这个属性依赖于其他属性。
这种依赖关系可以用函数依赖来表示。
具体来说，如果在一个关系模式R中，属性集X的值决定着属性集Y的值，我们可以表示为X->Y。
其中，X称为函数依赖的左侧，Y称为函数依赖的右侧。
函数依赖的左侧属性集称为决定因素，右侧属性集称为被决定因素。
在关系模式分解过程中，我们需要将函数依赖的左侧属性集作为一个新的关系模式的主键，并将函数依赖的右侧属性集作为新的关系模式的属性。
函数依赖的准则包括：完全依赖：如果函数依赖X->Y满足以下条件，我们称之为完全依赖：Y不包含X中的任何一个属性。
如果从X中移除任何一个属性，函数依赖不再成立。
部分依赖：如果函数依赖X->Y满足以下条件，我们称之为部分依赖：Y包含X中的某些属性。
如果从X中移除任何一个属性，函数依赖仍然成立。
通过分解满足完全依赖和部分依赖的关系模式，我们可以得到一个更规范、更高效的数据库设计。
多值依赖多值依赖是关系模式分解的另一个重要准则。
它描述了一个关系模式中两个属性之间的关系，其中一个属性的值可以确定另一个属性的多个值。
具体来说，如果在一个关系模式R中，属性集X的值决定着属性集Y的多个值，我们可以表示为X->>Y。
其中，X称为多值依赖的左侧，Y称为多值依赖的右侧。
在关系模式分解过程中，我们需要将多值依赖的左侧属性集作为一个新的关系模式的主键，并将多值依赖的右侧属性集作为新的关系模式的属性。
多值依赖的准则包括：非平凡多值依赖：如果一个多值依赖X->>Y满足以下条件，我们称之为非平凡多值依赖：X与Y没有公共属性。
范式概述
BCNF范式
如果一个关系属于3NF，且它的主码是 由一个主属性构成，则该关系肯定为BCNF。
BCNF范式的特征
BCNF范式
所有非主属性对每一个码都是完全函数 依赖 所有的主属性对每一个不包含它的码， 也是完全依赖 没有任何属性完全函数依赖于非码的任 何一组属性
BCNF范式示例讲解
BCNF范式
关系模式分解实例
2NF关系模式：学生_系(学号，姓名，年龄，性别，系名，系主任) 分析：学号系名，系名系主任 ，因存在传递函数依赖（无部分 函数依赖），当前关系为2NF，需要进一步规范化。 2NF关系模式：选课（学号，课程名，成绩） 分析：（学号，课程名）成绩，因当前关系既无传递函数依赖也 无部分函数依赖，只存在完全函数依赖，因此当前关系为3NF。
BCNF范式概述
BCNF范式
在若关系模式R属于1NF，且每个属性 都不部分依赖和传递依赖于主关键字，则R 属于BCNF。 BCNF即检查非主属性，又检查主属性， 当只检查非主属性而不检查主属性时，就成 了3NF。因此，可以说满足BCNF的关系必 定满足3NF。
BCNF范式定义
若关系模式R（U，F）∈1NF。若X→Y 且Y X时，X必含有关系R的一个关键字， 则R（U，F）∈BCNF。
第二范式
关系模式分解实例
第二范式
关系模式分解实例
第二范式
完全函数依赖：(学号,课程名)成绩 部分函数依赖：(学号,课程名)姓名 (学号,课程名)年龄 (学号,课程名)系名 传递函数依赖：(学号,课程名)系主任 因存在部分函数依赖，因此当前关系模 式属于1NF。
关系模式分解实例
完全函数依赖：（学号，课程名）成绩
关系模式：教学(学ห้องสมุดไป่ตู้，姓名，年龄，性别， 系名，系主任，课程名，成绩) 主键：（学号，课程名） 分析：学号→姓名，但学号并不是主码，只 是主码的一部分，因此它不属于BCNF，通 过前面的分析知道它也不属于2NF、3NF。
范式和关系模式规范化
内容列表
范式的定义与分类 第一范式 第二范式
第三范式
BC范式
范式和关系模式规范化
1
范式的定义与分类
范式(Normal Forms，NF)是规范 化过程中一系列逻辑步骤。 范式的类型有：第一范式(1NF), 第二范式(2NF),第三范式(3NF)， Boyce Codd范式(BCNF)。
范式和关系模式规范化
2
第一范式
如果一个关系模式R的所有属性 都是不可再分的数据项，则R为 第一范式。记作：R∈1NF
例如，关系模式： R(学号，课程号，成绩，姓名， 性别，班级，班主任) 其中每个属性都不可再分，因
此满足1NF。
范式和关系模式规范化
3
第二范式
若关系模式R∈1NF，并且每一 个非主属性都完全函数依赖于R 的关键字，则R为第二范式。记 作：R∈2NF。
属于BCNF的模式一定属于3NF， 但属于3NF的模式不一定属于 BCNF。 注意：对于排除主属性对候选 键的传递依赖或部分依赖的问 题，模式分解不能保证保持函 数依赖。
范式和关系模式规范化
6
总结
• 范式的定义与分类 • 第一范式 • 第二范式 • 第三范式 • BC范式
范式和关系模式规范化
7
思考题
• 请搜集关系模式规范化的相 关资料，进一步理解范式的 概念。
范式和关系模式规范化
8
例如，关系模式： R1(学号，姓名，性别，班级， 班主任) 学号 → 班级 班级 → 班主任 非主属性“班主任”传递函数 依赖于关键字“学号”。因此
关系R1不满足第三范式。
范式和关系模式规范化
5
BC范式
如果关系模式R是1NF，且每个 属性都不部分依赖于候选键也 不传递依赖于候选键，那么称R 是BC范式
关系模式的分解举例
分解后的关系为： 第四种分解： ND Sno Sdept DL Sdept
ND(Sno,Sdept) DL(Sdept,Sloc)
04001 04002 04003 04004 CS IS MA IS CS IS
Sloc
A B
MA
PH
C
B
NL⋈DL
04005
PH
这种分解保 持了函数依 赖，也做到 了无损连接。
Sno
04001
04002 04003 04004
Sdept
CS
IS MA CS
Sloc
A
B C B
没有丢失信息
04005
PH
B
★设R是一个关系模式，F是R上的一个FD集。R分解
成数据库模式ρ=｛ R1，…，Rk ｝。如果对R中满足F 的每一个关系r，都有： r=∏R1（r）⋈ ∏ R2（r）⋈ … ⋈ ∏ Rk（r） 那么称分解ρ相对于F是“无损联接分解”（lossless join decomposition），简称为“无损分解”，否则称为 “损失分解”（lossy decomposition）。 第三种方法当然具有无损连接分解，保证了不丢失原 有关系中的信息。但还是存在插入异常、删除异常和 更新异常等问题。之所有出现这问题，是因为SL中函 数依赖Sdept Sloc没有投影到分解的两个关系模式 上。也就是说这种分解没有保持原来关系的函数依赖。
Sno
04001 04002 04003 04004 04005
Sdept
CS IS MA CS PH
Sloc
A B C B B
关系模式的规范化
一、关系模式规范化的步骤
1NF
消除非主属性对码的部分函数依赖
详解第一范式、第二范式、第三范式、BCNF范式
详解第⼀范式、第⼆范式、第三范式、BCNF范式什么是”范式(NF)”按照教材中的定义，范式是“符合某⼀种级别的关系模式的集合，表⽰⼀个关系内部各属性之间的联系的合理化程度”。
很晦涩吧？实际上你可以把它粗略地理解为⼀张数据表的表结构所符合的某种设计标准的级别。
就像家⾥装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。
数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。
⼀般在我们设计关系型数据库的时候，最多考虑到BCNF就够。
符合⾼⼀级范式的设计，必定符合低⼀级范式，例如符合2NF的关系模式，必定符合1NF。
接下来就对每⼀级范式进⾏⼀下解释。
1. 第⼀范式（1NF）符合1NF的关系（你可以理解为数据表。
“关系模式”和“关系”的区别，类似于⾯向对象程序设计中”类“与”对象“的区别。
”关系“是”关系模式“的⼀个实例，你可以把”关系”理解为⼀张带数据的表，⽽“关系模式”是这张数据表的表结构。
1NF的定义为：符合1NF的关系中的每个属性都不可再分。
表1所⽰的情况，就不符合1NF的要求。
表1实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作⼀定是不能成功的。
也就是说，只要在RDBMS中已经存在的数据表，⼀定是符合1NF的。
如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2但是仅仅符合1NF的设计，仍然会存在数据冗余过⼤，插⼊异常，删除异常，修改异常的问题，例如对于表3中的设计：表31. 每⼀名学⽣的学号、姓名、系名、系主任这些数据重复多次。
每个系与对应的系主任的数据也重复多次——数据冗余过⼤2. 假如学校新建了⼀个系，但是暂时还没有招收任何学⽣（⽐如3⽉份就新建了，但要等到8⽉份才招⽣），那么是⽆法将系名与系主任的数据单独地添加到数据表中去的（注１）——插⼊异常注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意⼀个属性都不能为空，所有属性的组合也不能重复。
《关系模式分解》幻灯片
R3
b31
a2
b33
b34
a5
R4
b41
b42
a3
a4
a5
R5
a1
b52
b53
b54
a5
例 5.7 设R(ABCDE)，F={A→C，B→C，C→D，
DE→C，CE→A}，ρ={R1(AD)，R2(AB)，R3(BE)， R4(CDE)，R5(AE)}，检验分解ρ是否具有无损联接 性。
第二步：修正①A→C
对于任意的i,j(1≤i, j≤k)，不成立UiUj
R(U,F)
U=U1∪U2∪…∪Uk Fi是F在Ui上的投影
ρ
= {R1(U1,F1),R2(U2,F2),…,Rk(Uk,Fk)}
1、分解定义
R(U,F)的一个分解 也称数据库模式
2、F在Ui上的投影
设有关系模式R(U,F)，F是R的函数依赖 集，Z是U的子集，那么把F＋中所有满足XY Z
A
B
C
D
E
R1
a1
b12
b13
a4
b15
R2
a1
a2
b23
b24
b25
R3
b31
a2
b33
b34
a5
R4b41Fra bibliotekb42
a3
a4
a5
R5
a1
b52
b53
b54
a5
例 5.7 设R(ABCDE)，F={A→C，B→C，C→D，
DE→C，CE→A}，ρ={R1(AD)，R2(AB)，R3(BE)， R4(CDE)，R5(AE)}，检验分解ρ是否具有无损联接 性。
《关系模式分解》幻灯片
《数据库系统原理与技术》试题库试题与参考答案选编5
一、选择题1 关系模型中,一个关键字是（）。
Ａ.可由多个任意属性组成Ｂ.至多由一个属性组成Ｃ.可由一个或多个其值能惟一标识该关系模式中任何元组的属性组成Ｄ.以上都不是C2 关系数据库中的关键字是指( ) 。
Ａ.能唯一决定关系的字段Ｂ.不可改动的专用保留字Ｃ.关键的很重要的字段Ｄ.能唯一标识元组的属性或属性集合D3 在一个关系中如果有这样一个属性存在,它的值能唯一地标识关系中的每一个元组,称这个属性为( )。
Ａ.关键字Ｂ.数据项Ｃ.主属性Ｄ.主属性值A4 关系模式分解的结果（）。
Ａ.惟一Ｂ.不惟一，效果相同C.不惟一，效果不同，有正确与否之分D.不惟一，效果不同，有应用的不同D5 3NF同时又是（）。
A.2NFB.1NFC. BCNFD.1NF,2NFD6 当B属性函数依赖于A属性时，属性A与B的联系是（）。
A. 1对多B. 多对1C. 多对多D. 以上都不是A7 当关系模式R(A,B)已属于3NF,下列说法中( )是正确的。
Ａ.它消除了删除异常Ｂ.仍存在插入和删除异常Ｃ.属于BCNF Ｄ.它消除了插入异常B8 根据关系数据库规范化理论,关系数据库的关系要满足第一范式。
下面"部门"关系中,因哪个属性而使它不满足第一范式?( )Ａ.部门总经理Ｂ.部门成员Ｃ.部门名Ｄ.部门号B9 关系模式规范化的最起码的要求是达到第一范式，即满足（）。
A.每个非码属性都完全依赖于主码。
B.主码属性唯一标识关系中的元组C.关系中的元组不可重复D.每个属性都是不可分解的数据项。
D10 关系模式中，满足2NF的范式（）A.不可能是1NFB.可能是3NFC.必定是1NF且必定是3NFB11 关系模式中不存在任何非主属性对主属性的完全函数依赖，则其范式（）A.是1NFB.是2NFC.是3NFB12 关系数据库规范化的目的是为解决关系数据库中（）问题。
A.插入删除异常和数据冗余B.提高查询速度C.减少数据操作的复杂性。
数据结构-范式
�
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系
第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，
姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。
各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？
第9讲 关系模式的分解与范式
定义4.12 设有R，F是R上的函数依赖集，ρ={R1， R2，…，Rk}。如果对R中满足F的每一个 关系r，有: r =ΠR1(r)∞ΠR2(r)∞…∞ΠRk(r), 那么就称 分解ρ相对于F是“无损连接分解” ；否 则称为“损失分解”。
1
4.3.3 无损分解的测试算法
（1）构造一个k行n列的表格Rρ，表中每一列对应一个属性Aj （1≤j≤n），每一行对应一个模式Ri（1≤i≤k）。如果Aj在Ri中， 则在表中的第i行第j列处填上符号aj，否则填上bij。 （2）把表格看成模式R的一个关系，根据F中的每个函数依赖，在 表中寻找X分量上相等的行，分别对Y分量上的每一列做修改：
i 1
如果有F +=(
分解。
i 1
k
Ri
( F ) )+，则称ρ是保持函数依赖集F的
一个无损连接分解不一定是保持函数依赖的 一个保持函数依赖的分解也不一定是无损连接的
5
4.4 关系模式的范式
各种范式之间的关系
6
4.4.1 第一范式
定义4.14 如果关系模式R所有的属性均为简单属 性，即每个属性都是不可再分的，则称R属于第 一范式，简称1NF，记作R∈1NF。
12
算法4.7 把一个关系模式分解为3NF，使它既具有无损连接 性又具有保持函数依赖性。
（1）根据算法4.6求出保持函数依赖的分解：ρ={R1，R2，…，Rk}。 （2）判定ρ是否具有无损连接性，若是，转（4）。 （3）令ρ=ρ∪{X}={R1，R2，…，Rk，X}，其中X是R的候选键。 （4）输出ρ。
4
4.3.4 保持函数依赖的分解
定义4.13 设有关系模式R(U)，F是R(U)上的函数依赖集，Z是属 性集U上的一个子集，ρ={R1，R2，…，Rk}是R的一个分解。
简述关系模式分解的两大准则
简述关系模式分解的两大准则
关系模式分解是数据库设计中的重要步骤之一，它通过将一个大型关系模式分解成多个较小的、相关的关系模式，来提高数据库的性能和可维护性。
关系模式分解需要遵循以下两大准则：
第一，无损连接（Lossless Join）准则。
即分解后所得到的关系模式能够保持对原始关系模式中所有可能连接的支持，即能够无损地连接起来。
这意味着分解后的关系模式能够通过连接操作得到与原始关系模式相同的结果，不会因为分解而引入额外的元组或导致遗失某些元组。
无损连接准则确保了数据的完整性和一致性。
第二，函数依赖（Functional Dependency）准则。
即分解后的关系模式要能够保持原始关系模式中的所有函数依赖。
对于给定的关系模式R，如果存在函数依赖A → B，那么在分解后的关系模式中，A和B仍然在同一个关系模式中，并且该函数依赖仍然有效。
这意味着分解后的关系模式要能够保持数据的一致性和完整性。
通过遵循无损连接和函数依赖准则，关系模式分解能够确保分解结果的数据完整性和一致性，提高数据库的性能和可维护性。