第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的数据库模式。