《数据库第六章关系数据理论.ppt》由会员分享，可在线阅读，更多相关《数据库第六章关系数据理论.ppt（31页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、2023/4/5关系数据理论要点v关系规范化理论研究背景v数据依赖v规范化(Normalization)理论u1NF、2NF、3NF、BCNF等范式u关系模式规范化的必要性及方法6.1 问题的提出v问题提出：u针对一个具体问题，如何构造合适的合适的(更好更好的的)数据模式，即如何更好地设计数据库的逻辑结构？v关系数据理论的研究背景u关系模型建立在严格的数学基础上，并可向别的数据模型转换，因此常以关系模型为背景来讨论这个问题背景知识v数据模式(schema)u数据库中全体数据的逻辑结构和特征描述，如数据记录的构成，数据间的联系，安全性、完整性要求等。常以某一种数据模型为基础。v关系模型的形式化定
2、义uR(U,D,dom,F)，本章简化为R(U,F)。v候选码、主码、外码、全码。主码和外码提供了一个表示关系间联系的手段主码和外码提供了一个表示关系间联系的手段v不包含在任何码中的属性，叫做非主属性。非主属性。一个例子：学生-课程-成绩管理v客观事实：u一个系有若干学生，但一个学生只属于一个系；一个系只有一名负责人；一个学生可以选修多门课程，每门课程有若干学生选修；每个学生学习每一门课程有一个成绩。v设计如下单个模式u属性组U=学号SNO,系名SDEPT,系负责人MN,课程名CNAME,成绩Gu数据依赖：关系模式中各属性之间相互依赖、相互制约的联系。两种重要的数据依赖：函数依赖（与“自变量”
3、和“函数值”之间的映射类比）多值依赖 (考试不做要求)问题和改进v该模式的主码为（该模式的主码为（SNO，CNAME）v存在的问题存在的问题u插入异常插入异常：一个系无学生或未安排课程时，无法存入：一个系无学生或未安排课程时，无法存入系与负责人（实体完整性约束）系与负责人（实体完整性约束）u删除异常删除异常：一个系的学生全部毕业而没有招生时，系：一个系的学生全部毕业而没有招生时，系与负责人也随之删除（现实中该系仍存在）与负责人也随之删除（现实中该系仍存在）u更新异常更新异常：当某系负责人更换时，须更新该系所有学：当某系负责人更换时，须更新该系所有学生信息中的数据，系统需付出的维护工作量很大生信
4、息中的数据，系统需付出的维护工作量很大u冗余太大冗余太大：系名、负责人姓名重复存储：系名、负责人姓名重复存储 “包罗万象包罗万象”的关系模式并不好！的关系模式并不好！SNO CNAMEGSDEPTMNv原因：数据依赖存在一些不合适的性质，需寻找更好的模式，一个好的模式应具备以下四个条件：1、尽可能少的数据冗余 2、没有插入异常 3、没有删除异常 4、没有更新异常 S(SNO,SDEPT,)SG(SNO,CNAME,G,)DEPT(SDEPT,MN,)一个好的关系模式并非在任何情况下均是效率上最优的，应结合实际的应用目的。如上例中，查询某个学生选修课程名及所在系的系主任时就需要通过连接（系统开销
5、很大），如这样的查询是非常经常的，则该模式的运行效率就较低。关系的规范化：按照一定的规范设计关系模式，将结构复杂的关系分解成结构简单的关系，从而把有问题的关系数据库模式转变为好的关系数据库模式。6.2.1 函数依赖v定义1u设R(U)是属性集U上的关系模式。X,Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称X函数确定函数确定Y或或Y函数依赖于函数依赖于X，记作 。u若 ，则X叫做决定因素。u若Y不函数依赖于X，则记作 。对定义的说明v函数依赖是语义范畴的概念 只能根据语义来确定一个函数依赖，而不能按照其形式化定义来证明一
6、个函数依赖是否成立；（如在无重名前提下Sname Age 成立，否则就不存在此函数依赖）v 函数依赖关系的存在与时间无关 它是关系中的所有元组均满足的约束条件，当关系中的元组增加、删除或更新均不能破坏它；v 函数依赖可以保证关系分解的无损连接性 设R（X,Y,Z）,X,Y,Z为不相交的属性集合，如果 或 ，则有R（X,Y,Z）=RX,Y RX,Z,即R等于R的两组投影在X上的自然连接，保证了关系R分解后不会丢失原有的信息。进一步说明：函数依赖与属性之间联系类型的关系v如属性X与Y有1:1联系时,X Y 当学生无重名时，SNo SNamev如果属性X与Y有m:1的联系时，则只存在函数依赖X Y
7、如SNo与Sage、SDept之间均为m:1 SNo Sage、SNo SDeptv 如果属性X与属性Y有m:n的联系时，则X与Y之间不存在任何函数依赖关系 如 SNo与CNo之间不存在函数依赖函数依赖之（完全依赖与传递依赖）v定义2u设R(U)是属性集U上的关系模式。X,Y是U的子集。如果 ，并且对于X的任何一个真子集X,都有 ，则称Y对对X完全完全函数依赖函数依赖(“一个都不能少一个都不能少”)，记作u若对于X的某个真子集X,则称Y对对X部分函数依赖部分函数依赖，记作NOTE：只有当决定因素为组合属性时，讨论部分函数依赖才有 意义，当决定因素是单属性时，只能是完全函数依赖v定义3u设R(U
8、)是属性集U上的关系模式。X,Y,Z是U的子集，如果 但 ，而 （，）则称Z对对X传递函传递函数依赖数依赖，记作FP t6.2.3 范式v范式：符合某种级别(对关系中数据依赖的要求)的关系模式。v范式种类u1NF,2NF,3NF,BCNF,4NF,5NFu按级别(条件、要求)由低到高：1NF 2NF 3NF BCNF 4NF 5NFv通常称某一关系模式R为第几范式，记作R xNF。1NF(First Normal Form)v定义：关系R中每个分量都是不可分割的数据项，则R 1NF。v说明：1NF是关系模式的基本要求。v举例：关系模式S-L-C(学号SNO,系SDEPT,住处SLOC,课程CN
9、O,成绩G)是1NF。6.2.4 2NFv定义：若R 1NF,且每个非主属性完全依赖于码，则R 2NFv说明：不存在非主属性部分依赖于码的关系为2NFv举例：关系模式 S-L-C(SNO,SDEPT,SLOC,CNO,G)u函数依赖图GSNOCNOSDEPTSLOC关系模式S-L-C是不2NF？不是，因为SDEPT和SLOC部分依赖于码不是2NF可能出现的问题v插入异常u某学生没有选课时，无法插入其系、住处等信息。v删除异常u某学生所有的选课信息都删除后，其系、住处等信息也被删除。v修改复杂（更新异常）u学生转系时，除了修改其系名外，还需修改其住处信息；另外，若该学生选修了多门课程，则其对应的
10、重复存储的系、住处等信息需一一修改。v冗余u同系的所有学生的住处信息重复存储，同一学生选多门课程时，其系、住处信息重复存储。解决办法v模式分解u依赖关系分析u上例中的模式分解为下列两个模式，该模式是2NFSC(SNO,CNO,G)(SNO,CNO)GS-L(SNO,SDEPT,SLOC)SNO SDEPT,SNO SLOC,SDEPT SLOCGSNOCNOSDEPTSLOC分解说明v一个1NF，但非2NF的关系总是可以被分解成为一组2NF的关系。v规范化过程中通过一组投影运算消除部分依赖，建议作如下分解（No1）：u已知关系R(A,B,C,D),(A,B)为主码，即(A,B)-C,(A,B)
11、-D，且A-D（部分依赖）,则将R分解成为两个投影:R1(A,D),A为主码R2(A,B,C),(A,B)为主码，A为外码6.2.5 3NFv定义：若R2NF,且它的任何一个非主属性都不传递依赖于任何候选码，则R 3NF。v说明：即不存在非主属性部分依赖和传递依赖于码的关系为3NF。v推论：不存在非主属性的模式为3NF。v上例中得到的关系模式是2NF SC(SNO,CNO,G);S-L(SNO,SDEPT,SLOC);S-L中存在传递传递依赖，故该模式不是3NFSNOSDEPTSLOC不是3NF可能存在的问题v插入异常u当新系没有招生时，其住处信息无法插入。v删除异常u当某系所有学生毕业而又没
12、招生时，该系学生住处信息将丢失。v更新异常u一个系住处信息变动时，需改动较多记录。v冗余u每个系的系名与学生住处信息重复存储的次数等于该系学生人数解决方法v继续模式分解u如上例中的模式可分解为3NFSC(SNO,CNO,G);(SNO,CNO)G S-D(SNO,SDEPT);SNO SDEPT D-L(SDEPT,SLOC);SDEPT SLOCSNOSDEPTSLOCSDEPTGSNOCNO分解说明v一个2NF，但非3NF的关系总是可以被分解成为一组3NF的关系。v规范化过程中通过一组投影运算消除传递依赖，建议作如下分解(No2)：u已知关系R(A,B,C),A为主码(A-B,A-C)，且
13、B-C,则将R分解成为两个投影:R1(B,C),B为主码R2(A,B),A为主码，B为外码对3NF的进一步说明v在不考虑主属性对码的部分依赖和传递依赖时，可以认为已实现了彻底的分解，已消除了插入异常，删除异常，修改异常，冗余等问题。v但是，当关系中存在两个或更多的候选码时，尤其是在几个候选码内的属性存在部分交迭时，仅仅满足3NF仍有问题，需要进一步分解成BCNF。6.2.6 BCNF(Boyce/Codd Normal Form)v定义：若每一个决定因素都包含(或是)码，则R BCNF。v说明uBCNF中所有的依赖都是包含码的依赖。u一个BCNF范式必是3NF，但一个3NF范式不一定是BCNF
14、(3NF中可能存在主属性对码的部分和传递依赖)。无重名条件下 SNC（SNO，SN，CNO，SCORE）两个候选码:（SNO，CNO）;（SN，CNO）函数依赖:SNO SN （SNO，CNO）SCORE （SN，CNO）SCORE 非主属性SCORE对码不存在部分函数依赖和传递函数依赖，但决定因素SNO或SN不包含候选码，即主属性对码存在部分函数依赖 （SNO，CNO）SN （SN，CNO）SNO 故SNC 是3NF，非BCNF。其弊端？PP 主属性对码的部分函数依赖，造成SNC较大的数据冗余，学生姓名的存储次数等于选课数，导致更新异常。当学生改名时，必须对该学生的每一记录逐一修改。uBCN
15、F是在函数依赖范畴内对关系模式的彻底分解，已消除了插入和删除异常。u通常认为BCNF是扩充的第三范式，一般数据库设计达到BCNF已足够。实例v例1:无并列名次时的SJP(学生S,课程J,名次P)u(S,J)和(J,P)均为候选码u函数依赖为(S,J)P,(J,P)S其中，两个决定因素均包含(是)候选码可见SJP BCNFv例2:每教师只教一门课时的STJ(学生S,教师T,课程J)u(S,T)和(S,J)均为候选码u函数依赖为(S,J)T,(S,T)J,T J可见STJ 3NF(此例中无非主属性),但STJ BCNF，因T为决定因素，但不包含码例子v前例是3NF,也是BCNFSC(SNO,CNO
16、,G);(SNO,CNO)GS-D(SNO,SDEPT);SNO SDEPTD-L(SDEPT,SLOC);SDEPT SLOCSNOSDEPTSLOCSDEPTGSNOCNO 规范化v规范化u概念：将一个低一级范式的关系模式分解模式分解为若干个高一级范式的关系模式的过程。u目的：设计正确、良好的关系模式。u基本思想：逐步消除关系模式的数据依赖中不合适的部分，使模式达到一定程度的分离，但又不丢失原模式中的信息。u模式分解的数学实质：投影。v说明u模式分解可以在很大程度上消除冗余，解决更新异常等问题，但也要付出做连接运算等效率上的代价。规范化与数据库设计v如何辨别一个关系模式的“好坏”？u不存在
17、部分和传递函数依赖等“不好”的性质的模式是“好”模式，否则会出现冗余和插入、删除、更新等异常现象v规范化过程是用于设计好的数据库的有力辅助，但并不是唯一的方法。v 最初的设计中尽量做到“概念单一化”，即做到让一个关系描述一个概念、一个实体或实体间的一种联系，这样所设计的关系模式将会接近或达到第三范式，甚至达到BCNF。规范化过程小结1NF2NF3NFBCNF4NF消除非主属性对码的部分函数依赖消除非主属性对码的传递函数依赖消除主属性对码的部分和传递函数依赖消除多值依赖练习一v设计关于供应商供应零件的数据库，要求达到3NFv最初的设计：R(S#,Sname,City,Status,P#,Pnam
18、e,Color,Weight,QTY)u主码：(S#,P#)u函数依赖：S#Sname,S#Status,S#City,City Status,P#Pname,P#Color,P#Weight（S#,P#）QTYv可见，其中有部分依赖，还有传递依赖。该模式仅为1NF分解第一步分解，消除部分依赖，得到：R1(S#,P#,QTY)，(S#,P#)为码R2(S#,Sname,City,Status)，S#为码R3(P#,Pname,Color,Weight)，P#为码其中，R1和R3都已达到3NF，但R2还存在传递依赖，仅仅是2NF第二步分解，消除R2中的传递依赖，得到：R2-1(S#,Sname,City)，S#为码R2-2(City,Status)，City为码这样，R1,R2-1,R2-2和R3就是达到3NF的关系模式。此例中也已达到BCNF