三级数据库第七章考试要点
第七章
一、什么是“不好”的关系模式
关系模式有如下“毛病”:
(1)数据冗余。
(2)更新异常(不一致性的危险)。
(3)插入异常。如果某供应者没有供应任何货物,则我们无法记录他的名称和地址。
(4)删除异常。如果一个供应者供应的所有货物都被删除,则我们无可奈何地丢失了该供应者的名称和地址。
二、函数依赖(一)函数依赖的定义
设R(A1 ,A2 ,…,An )是一个关系模式,X和Y是{A1 ,A2 ,…,An }的子集,若只要关系r是关系模式R的可能取值,则r中不可能有两个元组在X上的属性值相等,而在Y上的属性值不等,则称“X函数决定Y”,或“Y函数依赖于X,记作X→Y。
注意,函数依赖X→Y的定义要求关系模式R的任何可能的r都能满足上述条件。
(二)函数依赖的逻辑蕴含
设R〈U,F〉是一个关系模式,X,Y是U中属性组,若在R〈U,F〉的任何一个满足F函数依赖的关系r上,都有函数依赖X→Y成立,则称F逻辑蕴含X→Y。
(三)码
设K为关系模式R<U,F>中的属性或属性组,若K→U在F+中,而找不到K的任何一个真子集K′,能使K′→U在F+中,则称K为关系模式R的候选码。当候选码多于一个时,选定其中一个做主码。
包含在任何一个候选码中的属性叫做主属性。不包含在任何候选码中的属性叫做非主属性。最简单的情况,单个属性是码。最极端的情况,整个属性组是码,称做全码。
(四)函数依赖的公理系统
设F是属性组U上的一组函数依赖,于是有如下推理规则:
增广律:若X→Y为F所逻辑蕴含,且Z〈U,则XZ→YZ为F所逻辑蕴含。
传递律:若X→Y及Y→Z为F所逻辑蕴含,则X→Z为F所逻辑蕴含。注意:由自反律所得到的函数依赖均是平凡的函数依赖,事实上自反律的应用只依赖于U,不依赖于F。
根据Armstrong公理系统的3条推理规则可以得到下面3条很有用的推理规则:
(1)合并规则:由X→Y,X→Z,有X→YZ。
(2)伪传递规则:由X→Y,WY→Z,有XW→Z。
三、1NF、2NF、3NF、BCNF(一)第一范式(1NF)及进一步规范化
关系模式需要满足一定的条件,不同程度的条件称做不同的范式。最低要求的条件是元组的每个分量必须是不可分的数据项,这叫做第一范式,简称1NF,是最基本的规范化,在第一范式的基础上进一步增加一些条件,则为第二范式。以此类推,还有第三范式,Boyce-Codd范式,等等。函数依赖X→Y不仅给出了对关系的值的限制,而且给出了数据库中应该存储的某种联系:从X的值应该知道与之联系的惟一Y值。若X不含码,则有麻烦了。码是一个元组区别于其他元组的依据,同时也是一个元组赖以存在的条件。在一个关系中,不可能存在两个不同的元组在码属性上取值相同,也不可能存在码或码的一部分为空值的元组。若某关系模式的属性间有函数依赖X→Y,而X又不包含码,那么在具有相同X值的所有元组中,某个特定的Y值就会重复出现,这是数据冗余,随之而来的是更新异常问题;某个X值与某个特定的Y值相联系,这是数据库中应存储的信息,但由于X不含码,这种X与Y相联系的信息可能因为码或码的一部分为空值而不能作为一个合法的元组在数据库中存在,这是插入异常或删除异常问题。第二范式、第三范式和Boyce-Codd范式就是不同程度地限制关系模式中X不包含码的函数依赖X→Y的存在。
(二)第二范式(2NF)
若关系模式R∈1NF,且每一个非主属性完全函数依赖于码,则R∈2NF。
2NF就是不允许关系模式的属性之间有这样的函数依赖X→Y,其中X是码的真子集,Y是非主属性。即不允许有非主属性对码的部分函数依赖。
(三)第三范式(3NF)
若关系模式R∈2NF,且每一个非主属性都不传递依赖于码,则R∈3NF。3NF就是不允许关系模式的属性之间有这样的非平凡函数依赖X→Y,其中X不包含码,Y是非主属性。X不包含码有两种情况,一种情况X是码的真子集,这是2NF不允许的,另一种情况X不是码的真子集,这是3NF不允许的。
(四)Boyce-Codd范式(BCNF)
若关系模式R∈1NF,且对于每一个非平凡的函数依赖X→Y,都有X包含码,则R∈BCNF。BCNF是3NF的进一步规范化,即限制条件更严格。3NF不允许有X不包含码,Y是非主属性的非平凡函数依赖X→Y。BCNF则不管Y是主属性还是非主属性,只要X不包含码,就不允许有X→Y这样的非平凡函数依赖。因此,若R∈BCNF,则必然R∈3NF。然而,BCNF又是概念上更加简单的一种范式,判断一个关系模式是否属于BCNF,只要考察每个非平凡函数依赖X→Y的决定因素X是否包含码就行了。1NF,2NF,3NF,BCNF的相互关系是:BCNF’3NF’2NF’1NF在函数依赖的范畴内,BCNF达到了最高的规范化程度。
四、多值依赖和4NF
多值依赖
多值依赖的定义是:设R是属性集U上的一个关系模式,X、Y是U的子集,Z=U-X-Y。若在R的任一关系r中,只要存在元组t,s,使得tX=sX,就必然存在元组w,v∈r(w,v可以与s,t相同),使得w[X]=ν[X]=t[X]=s[X],而w[Y]=t[Y],w[Z]=s[Z];ν[Y]=s[Y],ν[Z]=t[Z],则称Y多值依赖于X,记做X→→Y。
若X→→Y,而Z=φ ,则称X→→Y为平凡的多值依赖。
在关系模式WSC中,存在多值依赖W→→S。
多值依赖具有以下性质:
(1)若X→→Y,则X→→Z,其中,Z=U-X-Y,即多值依赖具有对称性。
(2)若X→Y,则X→→Y,即函数依赖可以看作多值依赖的特殊情况。因为当X→Y时,对于X的每一个值x,都有Y的一个确定值y与之对应。
(3)若X→→Y在R(U)上成立,且Y′’Y,我们不能断言X→→Y′在R(U)上成立。这也是因为多值依赖的定义中涉及了U中除X,Y之外的其余属性Z,考虑X→→Y′是否成立时涉及的其余属性Z′=U-X-Y′比确定X→→Y成立时涉及的其余属性Z=U-X-Y包含的属性列多,因此X→→Y′不一定成立。
五、关系模式的分解(一)模式分解的等价标准
规范化过程中将一个关系模式分解为若干个关系模式,应该保证分解后产生的模式与原来的模式等价。常用的等价标准有要求分解是具有无损连接性的和要求分解是保持函数依赖的两种。
将一个关系模式R〈U,F〉分解为若干个关系模式R1〈U1 ,F1 >,R2〈U2,F2 〉,…,Rm〈Un ,Fn >(其中,U=U1∪U2∪…∪Un ,Fi 为F在Ui上的投影),这意味着相应地将存在一个二维表r中的数据分散到若干个二维表r1,r2,…,rn中去(其中ri是r在属性组Ui上的投影)。我们当然希望这样的分解不丢失信息,也就是说,希望能通过对关系r1,r2 ,…,r n 的自然连接运算重新得到关系r中的所有信息。
设关系模式R〈U,F〉分解为关系模式R1〈U1 ,F1 〉,R 2〈U2 ,F2 〉,…Rn〈Un ,Fn 〉,若F + =(F1∪F2∪…∪Fn)+,即F所逻辑蕴含的函数依赖一定也由分解得到的各个关系模式中的函数依赖所逻辑蕴含,则称关系模式R的这个分解是保持函数依赖的。
(二)关于模式分解的几个事实
(1)分解具有无损连接性和分解保持函数依赖是两个互相独立的标准。具有无损连接性的分解不一定保持函数依赖,保持函数衣赖的分解不一定具有无损连接性。
(2)若要求分解具有无损连接性,那么模式分解一定可达到BCNF。
(3)若要求分解保持函数依赖,那么模式分解可达到3NF,但不一定能达到BCNF。
(4)若要求分解既具有无损连接性,又保持函数依赖,则模式分解可以达到3NF,但不一定能达到BCNF。
六、数据库设计的内容、方法和步骤
数据库设计包括结构特性的设计和行为特性的设计两方面的内容。结构特性的设计是指确定数据库的数据模型。数据模型反映了现实世界的数据及数据间的联系,要求满足应用需求的前提下,尽可能减少冗余,实现数据共享。行为特性的设计是指确定数据库应用的行为和动作,应用的行为体现在应用程序中,所以行为特性的设计主要是应用程序的设计。
为了使数据库设计更合理更有效,需要有效的指导原则,这种指导原则称做数据库设计方法学。数据库设计方法中比较著名的有新奥尔良(New Orleans)方法。它将数据库设计过程分为4个阶段:需求分析、概念结构设计、逻辑结构设计和物理设计。
七、需求分析(一)需求分析的任务
需求分析的任务是:对现实世界要处理的对象(组织、部门、企业等)进行详细调查,在了解现行系统的概况,确定新系统功能的过程中,收集支持系统目标的基础数据及其处理方法。需求分析是在用户调查的基础上,通过分析,逐步明确用户对系统的需求,包括数据需求和围绕这些数据业务的业务处理需求。数据流图是从“数据”和“处理”两方面表达数据处理过程的一种图形化的表示方法。在数据流图中,用圆圈表示数据处理(加工);用有向线段表示数据的流动及流动方向,即数据的来源和去向;用“书形框”表示要求在系统中存储的数据。在系统分析阶段,不必确定数据的具体存储方式,将来这些数据存储可能是数据库中的关系,也可能是操作系统的文件。数据流图中的“处理”抽象表达了系统的功能要求,系统的整体功能要求可以分解为系统的若干功能要求,通过逐步分解的方法,一直可以分解到将系统的工作过程表达清楚为止。在功能分解的同时,每个功能要处理的所用的数据也在逐步分解,从而形成若干层次的数据流图。
(二)需求分析的基本步骤
(1)需求的收集:数据、发生时间、频率,发生的规则、约束条件、相互联系、计划控制及决策过程。注意不仅要注重处理流程还要注重规约。
(2)需求的分析整理。①数据流程分析。以数据流图表示。②数据分析结果描述。除DFD外,还有一些规范表格作补充描述。(a)数据项:它是数据的最小单位,包括项名、含义、别名、类型、长度、取值范围、与及其他项的逻辑联系等;(b)数据结构:是若干数据项的有序集合。包括数据结构名、含义、组成的成分等;(c)数据流说明:可以是数据项,也可以是数据结构。表示某一加工的输入/输出数据,包括数据流名、说明、流入的加工名、流出的加工名、组成的成分等。(d)数据存储说明;加工中需要存储数据。包括数据存储名、说明、输入数据流、输出数据流、组成的成分、数据量、存储方式、操作方式等;(e)加工过程:包括加工名、加工的简要说明、输入/输出数据流等。③数据分析统计。将收集的数据按基本输入数据(包括人工录入、系统自动采集、转入等)、存储数据(包括一次性存储量、周期递增量)、输出数据(包括报表输出、转出等)分别进行统计。④分析围绕数据的各种业务处理功能,并以带说明的系统功能结构图形给出。需求分析的阶段成果是产生系统需求说明书,系统需求说明书要包括数据流图、数据字典的雏形表格、各类数据的统计表格、系统功能结果结构图,并加以必要的说明编辑而成。系统需求说明书将为数据库设计全过程的重要依据文件。
八、概念结构设计(一)概念结构设计的目标和策略
数据库概念结构设计的任务是产生反映企业组织信息需求的数据库概念结构,即概念模型。概念模型是不依赖于计算机系统和具体的DBMS的。概念模型应具备:
(1)有丰富的语义表达能力。能表达用户的各种需求,包括描述现实世界中各种事物和事物之间的联系,能满足用户对数据的处理要求;
(2)易于交流和理解。概念模型是DBA、应用系统开发人员和用户之间的主要交流工具;
(3)易于变动。概念模型要能灵活地加以改变,以反映有户需求和环境的变化;
(4)易于向各种数据模型转换,易于从概念模型导出与DBMS有关的逻辑模型。
设计概念结构的策略有如下几种:
(1)自顶向下。首先定义全局概念结构的框架,再作逐步细化。
(2)自底向上。首先定义每一局部应用的概念结构,然后按一定的规则把它们集成,从而得到全局概念结构。(3)由里向外。首先定义最重要的那些核心结构,再逐渐向外扩充。
(4)混合策略。把自顶向下和自底向上结合起来的方法。自顶向下设计一个概念结构的框架,然后以它为骨架再自底向上设计局部概念结构,并把它们集成。最常用的设计策略是自底向上设计策略。
(二)采用E-R方法的数据库概念模型设计
E-R方法的基本术语如下:①实体(entity)与属性(attribute)实体是客观存在可互相区分的“事物”。实体必须有一组表征其特征的“属性”来描述。属性与实体无截然划分的界限,描述另一事物的某一特征的,而且其本身在一定意义(应用需求)上说,是不再需要描述(不可分解)的,这样的事物一般归为属性。在设计时可以归为属性的事物尽可能归为属性以简化E-R图的处理,但也要根据需求而定。②联系(relationship)联系是指实体之间存在的对应关系(它也具有属性)。一般可分为:一对一的联系(1:1);一对多的联系(1:n);多对多的联系(m:n)。在该结构设计中用E-R图直观地表示E-R模型。在E-R图中,用长方形表示实体,用椭圆形表示属性,用菱形表示联系。在图形内标识它们的名字,它们之间用无向线段相连,表示联系的线段上标明是哪种联系。采用E-R方法的数据概念结构设计可分为3步进行:
(1)设计局部E-R模型。局部E-R模型的设计内容包括确定局部E-R结构的范围、定义属性、定义实体、定义联系等。
(2)设计全局E-R模型。这一步是将所有局部的E-R图集成全局的E-R图,即全局的概念模型。把局部E-R图集成为全局E-R图时,可以采用一次将所有的局部E-R图集成在一起的方式,也可以采用逐步集成,进行累加的方式,一次只集成两个局部E-R图,这样复杂度较低。当将局部的E-R图集成为全局的E-R图时,可能存在3类冲突:①属性冲突:包括类型、取值范围、取值单位的冲突。②结构冲突:例如同一对象在一个局部E-R图中作为实体,而在另一局部E-R图中作为属性,同一实体在不同的E-R图中属性个数和类型不同等。③命名冲突:包括实体类型名、联系类型名之间异名同义,或同名异义等。属性冲突和命名冲突通常用讨论、协商等行政手段解决;结构冲突则要认真分析后用技术手段解决,例如把实体变换为属性或属性变换为实体,使同一对象具有相同的抽象,又如,取同一实体在各局部E-R图中属性的并作为集成后该实体的属性集,并对属性的取值类型进行协调统一。(3)全局E-R模型的优化一个好的全局E-R模式除能反映用户功能需求外,还应满足下列条件:实体类型个数尽可能少,实体类型所含属性尽可能少,实体类型间联系大肥猪化就是要达到这3个目的,即相关实体类型的合并,一般把具有相同键的实体类型进行合并,还可以考虑将1:1联系的两个实体类型合并为一个实体类型;冗余属性的消除;冗余联系的消除。
九、逻辑结构设计(一)E-R模型向关系数据模型的转换
E-R模型可以向现有的各种数据库模型转换,对不同的数据库模型有不同的转换规则。向关系模型转换的规则是:
(1)一个实体类型转换成一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
(2)一个1:1联系可以转换为一个独立的关系模式,也可以与联系的任意一端实体所对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码。如果与联系的任意一端实体所对应的关系模式合并,则需要在该关系模式的属性中加入另一个实体的码和联系本身的属性。
(3)一个1:n联系可以转换为一个独立的关系模式,也可以与联系的任意n端实体所对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而联系的码为n端实体的码。如果与联系的n端实体的所对应的关系模式合并,则需要在该关系模式的属性中加入1端实体的码和联系本身的属性。
(4)一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
(5)3个或3个以上的实体间的多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
(6)具有相同码的关系模式可合并。
(二)关系数据库的逻辑结构设计过程
关系数据库的逻辑结构设计过程如下:
(1)从E-R图导出初始关系模式。将E-R图按规则转换成关系模式。
(2)规范化处理。消除异常,改善完整性、一致性和存储效率,一般达到3NF就行。规范化过程实际上就是单一化过程,即让一个关系描述一个概念,若多于一个概念的就把它分离出来。
(3)模式评价。目的是检查数据库模式是否满足用户的要求,包括功能评价和性能评价。
(4)优化模式。如疏漏的要新增关系或属性,如性能不好的要采用合并、分解或选用另外结构等。①合并。对具有相同关键字的关系模式,如它们的处理主要是查询操作,且常在一起使用,可将这类关系模式合并。②分解。虽已达到规范化,但因某些属性过多时,可将它分解成两个或多个关系模式。按属性组分解的称为垂直分解。垂直分解要注意得到的每一关系都包含主码。
(5)形成逻辑结构设计说明书。逻辑结构设计说明书包括:①应用设计指南。访问方式、查询路径、处理要求、约束条件等。②物理设计指南。数据访问量、传输量、存储量、递增量等。③模式及子模式的集合。可用DBMS语言描述,也可列表描述。
十、物理设计(一)物设计的内容
物理设计的大致内容如下:
(1)存储记录的格式设计;
(2)存储方法设计;
(3)存取方法设计。
(二)物理设计的评价
多性能测量使设计者能灵活地对初始设计过程和未来的修正作出决策。假设数据库性能用“开销(cost)”描述,在不同时候开销可用时间、空间及可能的货币值给出。在数据库应用系统生存期中,总的开销包括:规划开销、设计开销、实施和测试开销、操作开销、运行维护开销。对物理设计者来说,主要考虑操作开销,即为使用户获得及时、准确的数据所需开销和计算机资源的开销,可分为如下几类:
(1)查询和响应时间
(2)更新事务的开销
(3)报告生成的开销
(4)主存储空间开销
(5)辅助存储空间
十一、实现和维护(一)数据库的实现
根据逻辑结构设计和物理设计的结果,在计算机上建立起实际数据库结构,装入数据,测试和运行的过程称为数据库的实现。主要工作如下:
(1)建立实际的数据库结构。
(2)装入试验数据应用程序进行测试,以确认其功能和性能是否满足设计要求,并检查对空间的占有情况。
(3)装入实际数据,即数据库加载,建立起实际的数据库。
(二)其他设计
其他设计工作包括夹芸数据库的安全性、完整性控制,及保证一致性、可恢复性等,总是以牺牲效率为代价的。设计人员的任务就是要在实现代价和尽可能多的功能之间进行合理平衡。其他设计包括:
(1)数据库的再组织设计
(2)故障恢复方案设计
(3)安全性考虑
(4)事务控制
(三)运行与维护主要工作是:
(1)维护数据库的安全性和完整性:及时调整授权和密码,转储及恢复数据库。
(2)监测并改善数据库性能:分析评估存储空间和响应时间,必要时进行再组织。
(3)增加新的功能:对现有功能按用户需要进行扩充。
(4)修改错误:包括程序和数据。