ADB-2-关系数据库基

高级数据库技术及应用

——第2章关系数据库根底2017.09关系数据库基于关系数据模型□提出和诞生于20世纪70年代□成熟和开展于20世纪80-90年代□进入21世纪，与计算机网络密切结合，焕发新生命活力□建立在关系数学理论之上，技术意义下的数据管理及使用等具有较高的抽象层次和科学属性第2章关系数据库根底□关系数据库的建立是数据库开展历史上最重要的事件□关系数据库直到现在且在今后可想见时间内都是最重要和最流行的数据库。□关系数据技术是其它数据库开展根底重要借鉴本章简要回忆关系数据库根本理论与技术如以下图为高级数据库学习提供原理和技术上准备知识第2章关系数据库根底第2章关系数据库根底第2章关系数据库根底2.1关系数据模型2.2关系数据语言SQL2.3关系模式设计2.4关系数据库保护2.5关系数据事务管理计算机主要用于数据“计算”：“计算”具极为广泛意义不局限于常规“四那么”运算数据计算:数据处理数据管理●数据处理经过“处理”的数据会发生变化，例如数值数据的分析计算和非数值数据的加工挖掘●数据管理需要“管理”的主要是非数值型数据，通过赋予海量数据以适当结构用于长期保存和多用户共享2.1数据模型与数据模式数据管理:一类最大的计算机应用领域核心技术:统一管理数据和多用户共享数据为特征数据库技术数据模型:□数据结构和数据操作的抽象□数据管理的出发点□数据库原理和技术的根底2.1数据模型与数据模式数据模型开展线条:数据管理技术的演进轨迹关系数据模型:□静态数据结构□动态数据操作□语义限制的数据完整性约束关系数据模式:□关系模型在一个应用环境中的具体实现2.1数据模型与数据模式数据结构□关系数据结构:本质上是一种数学结构域上笛卡尔乘积的一个子集□离散数学中这样子集称为域上一个关系“关系”数据模型中“关系”一词由来□域是一组具有相同数据类型的值的集合例如：整数域、实数域、长度指定的字符串集合、枚举集合{‘male’，‘female’}和介于某个取值范围的整数等。2.1数据模型与数据模式一组域D1，D2，…，Dn，其上笛卡尔乘积为集合D1×D2×…×Dn＝｛〔d1，…，dn〕｜diDi，i＝1，…，n｝□笛卡尔乘积:表示为一个二维表□表中每一行:对应一个元素〔向量〕□表中每一列:对应一个域

关系数据结构做为集合，笛卡尔乘积中元素称为元组〔Tuple〕通常记为t，关系R是元组t的一个集合关系R中元组以行形式出现，从形式上看，关系R就相当于一张二维表〔table〕□一个关系也称为一张关系表R□每一行对应一个元组〔向量〕□每一列对应一个属性〔域〕

关系数据结构□关系R需要满足R⊆D1×D2×…×Dn关系R的最根本语法要求□数据不能没有语义数据使用和管理的要点是数据的语义□对满足语法要求的关系R应进行相应语义描述即还需考虑下述问题：

关系数据结构①计算机只处理有限个对象的问题数学“关系”可有无限个元素②计算机管理数据需有一个最小技术处理单元数学关系元素〔分量〕却无此限制，可以任意嵌套③关联难以操作实际应用中数据成分顺序并不必要如对一个学生而言，先讲“学号”还是先讲“姓名”并不影响对该学生各类特征信息的了解和掌握；数学“关系”元素“分量”顺序却不能随意调换

关系数据结构④数据处理本质在于其含义及与其它数据关联数学“关系”过于宽泛，不能有效描述数据间的关联，这种由“数学的语法描述”到“应用的语义实现”差异，需对语法意义下的“关系”提出相应的语义约束。针对上述“①”、“②”和“③”，满足下述条件标准化关系R构成关系数据模型的数据结构通常也称为标准化二维平面关系表

关系数据结构一.根本语义限制进行如下标准化了的数学“关系”才能是关系模型的数据结构：标准化二维平面关系表●有限性：关系是其元组的有限集合●原子性：关系中的每个列具有不可再分性质●属性列无序性：关系中列不考虑相互顺序，为此，需要为每个列给知名称，及属性名。

关系数据结构二.数据关联描述数据关联：同一关系内数据关联和不同关系数据关联。(1)同一关系内数据关联同一关系中各个属性关联通过主键机制实现●能够唯一标识元组的一组属性称为“超键”●最小的超键称为“候选键”●确定使用的候选键称为主键〔关系可有多个候选键〕

关系数据结构(1)不同关系间数据关联□不同关系间数据关联通过外键机制实现设有关系R和S，R中一组属性A假设不是R主键，却是S主键那么A为R〔关于S〕的外键。□外键的意义:将关系间关联也作为一种“关系”进行描述统一和简化了关系数据的技术处理□带来难以有效处理比较复杂语义关联的新的课题

关系数据结构关系数据模型不同于其它模型等的根本特征：□关系数据结构依赖于数学中笛卡尔乘积和关系原理□关系数据操作以数学中集合运算和数理逻辑为支撑□关系数据操作也称为关系运算●基于集合代数的运算称为关系代数●基于数理逻辑的运算称为关系演算

关系数据操作数据语义描述与处理是数据管理的根本课题：●通过“标准化”二维表对关系进行根本语义限定●通过“主键”和“外键”对关系进行语义关联描述但这仅是数据语义的根本要求：□只能保证关系数据能够进行计算机管理〔合法性〕□难以保证计算机管理数据的正确性和有效性〔适宜性〕

关系数据完整性约束从应用和技术实现角度还需要对相应数据实体集的范围外延和数据间关系加以约束这就是关系数据完整性约束机制关系数据完整性约束机制包括三个组成局部□实体完整性约束□参照完整性约束□用户完整性约束

关系数据完整性约束①实体完整性约束数据标识是数据语义处理的前提，否那么，计算机处理和实际应用过程中将难以进行语义和技术上的识别，需要限定关系数据中元组标识不能为空实体完整性约束：关系主键不能取空值

关系数据完整性约束②参照完整性约束描述和处理数据语义关联的意义，理解和使用计算机处理数据语义的根底，实现高效数据处理的技术途径，例如通过数据间“引用”可减少存储空间和实现快速查找□参照完整性约束：当属性集A是关系R关于关系S的外键时A或取空值，或取S中某个元组的主键值。

关系数据完整性约束③

用户完整性约束数据语义与数据所处语境有密切关联，实际用户的应用环境是最重要的数据语境之一。□用户完整性约束用户在应用环境中自行定义的语义约束实体完整性和参照完整性通常由DBMS实现用户完整性约束与各样应用背景关联，系统难以统一处理，呈现出复杂多样的特点。

关系数据完整性约束●数据模型数据管理过程中数据结构、数据操作和完整性约束的抽象●数据模式在给定数据模型框架内对具体应用数据的描述。□数据模型：像是一种给定的程序设计语言□数据模式：使用该语言对一个实际问题的具体实现程序应用关系数据模型建立具体数据库就是关系数据数据模式

关系数据模式数据模型：有逻辑数据模型和物理数据模型之分数据模式：有逻辑数据模式和物理数据模式之别美国国家标准协会〔ANSI〕就将数据模式分为三种级别●内模式〔物理模式〕●概念模式〔模式逻辑模式〕●外模式〔用户模式〕

关系数据模式□内模式使用物理数据模型对一个应用单位所涉及数据的描述内模式对于一般用户透明，由相应的DBMS设计处理□概念模式使用逻辑数据模型对一个应用单位所涉及数据的描述数据库设计的最重要工作通常所说的数据库模式设计就是数据库概念模式的设计

关系数据模式□外模式对一个应用单位中某个或某些用户所涉及数据个别描述

外模式可以看做是相应概念模式一个子集需要从相应概念模式推导而得

关系数据模式数据库系统三级模式结构意义□将一个应用单位所涉及数据的具体组织交由DBMS完成□使用户不必具体处理数据在计算机中的表示和存储方式□专心在较高的抽象层面上对数据进行有效管理上述三个数据模式可以通过下述两级映射进行相互转换

●外模式/概念模式映射●概念模式/内模式映射

关系数据模式●外模式/概念模式映射保证数据的逻辑独立性：当概念模式发生添加新的关系表、取消原有关系表或对已有关系表增添新的数据或删除原有属性时只需要改动相应的映射，而外模式本身并不需要改变用户的应用程序时依据相应外模式编写所以应用程序也无需改变

关系数据模式●概念模式/内模式映射保证数据的物理独立性：当内模式由于采用了新的存储结构〔例如原先无索引需要改用索引存储结构等〕而发生改变时只需要改动相应的映射，而概念模式本身也不需要改变进而对应的外模式也无改变

关系数据模式●三级模式结构：使得数据在计算机内表述与组织对用户透明●两级映射：提供数据的逻辑独立性与物理独立性三级模式/两级映射：现今所有数据模式根本架构数据库的三级模式/两级映射的体系结构。

关系数据模式第2章关系数据库根底2.1关系数据模型2.2关系数据语言SQL2.3关系模式设计2.4关系数据库保护2.5关系数据事务管理计算机本质是进行数据计算对非数值型数据，分为数据管理和数据处理□数据管理：通过查询技术对数据进行频繁访问□数据处理：通过应用程序对数据进行计算处理2.2

关系数据标准语言SQL□使用数据库：高效、正确和完整查询所需数据□数据库技术是一种数据管理技术□数据库语言具不同于一般高级程序语言的特征□SQL：一种得到广泛使用关系数据库标准语言2.2

关系数据标准语言SQL□20世纪70年代，IBM研制SystemR使用SEQUEL非过程关系数据语言，这是SQL雏形□1982IBM：首个商品化DBMS：SQL/DS，使用SQL〔StructuredQueryLanguage〕取代SEQUEL□1986国家标准协会〔ANSI〕:首个SQL标准SQL-86.□1987国际标准化组织〔ISO〕：通过SQL标准□1989ISO公布SQL-89。2.2

关系数据标准语言SQL□1992ISO公布SQL-92□1999ISO公布SQL-99增添对象数据管理功能扩充□2003ISO公布SQL-2003关系到对象的二次扩充□2003ISO公布SQL-2006增添XML管理功能

具有里程碑意义的是SQL-92和SQL-99SQL-92：集经典关系数据管理之大成SQL-99：开启由传统关系数据到新型数据管理历史转变2.2

关系数据标准语言SQL①高度综合统一SQL虽然名为结构查询语言具有完成数据库几乎所有功能的综合统一机制：□重构与维护□完整性与平安性□并发控制与故障恢复等SQL根本特征②非过程操作□先前数据库语言面向过程语言，即不仅告知系统“做什么”，更需要告知“如何做”□SQL是一种面向结果的“非过程”语言即只要告知系统“做什么”，不需要告知“如何做”具体实现完全对于用户透明由此大大拓展了关系数据库的用户面SQL根本特征③面向集合处理□程序语言每次处理对象大多是单个数据具有特征：“一次一数据”□SQL处理对象是“元组”集合，输出结果也是关系表

具有特征：“一次一集合”从而能够简化相应的系统设计，增强系统效率SQL根本特征④多样使用方式SQL能够独立地用于数据处理的联机交互□SQL独立完成指定操作为一般用户提供数据使用□SQL语句嵌入程序设计语言为程序设计人员使用一种语法结构而提供多种应用方式为实际应用带来极大灵活性与方便性SQL根本特征⑤语言简洁易学为实现创立、查询和更新等关系数据核心操作SQL只需要如以下图所示的九个动词如以下图所示各类SQL语句十分接近于自然英语表达，简洁易懂。SQL根本特征SQL中关系定义就是模式定义，包括□定义数据库模式〔数据库〕□定义关系模式〔根本表和视图〕此时“定义”实际包括“创立”〔CREATE〕“撤销”〔DROP〕“修改”〔ALTER〕

关系定义SQL数据操作主要分为数据查询和数据更新两种情形数据查询的根本操作是投影、选择和连接。数据更新的根本操作是插入、删除和修改。SQL数据查询功能可看做一种基于关系运算的操作形式。在关系代数当中，许多查询的逻辑实现都可被描述为“选择之后再投影”的常见运算，即可用下面根本表达式表示：∏a1，ar2，…，anσF〔R1R2R3…Rn〕

关系定义这个表达式中有三组根本参数。●查询的目标属性：a1，a2，…，an。●查询所涉及的关系：R1，R2，R3，…，Rn。●查询的逻辑条件：F。在SQL中，上述根本表达式可以被抽象为一个映射块，这个映射块构成SQL查询的根本语句——映像〔Mapping〕语句，而上述三组参数实现使用映像语句的三个子句分别表示。这三个子句是SELECT子句、FROM子句和WHERE子句。

关系定义⑴SELECT子句：表示查询结果中所需的目标属性，可看作做应于关系代数中投影运算。⑵

FROM子句：表示查询所涉及的一个或多个关系，在多个关系情形，可看做对应于关系代数中的连接运算。⑶

WHERE子句：表示作用于FROM子句所列关系中相关属性上的逻辑条件，可看做对应于关系代数中的选择运算。

关系定义由上述三个子句组成的映像语句的一般格式为：SELECT[ALL|DISTINCT]<属性名>[，<属性名>]…FROM<根本表名或视图名>[，<根本表名或视图名>]…[WHERE<逻辑条件式>][GROUPBY<属性名1>[HAVING<逻辑表达式>]][ORDERBY<属性名2>[ASC|DESC]]

关系定义上述整个映像语句的运算含义描述如下：首先，根据WHERE子句中的条件表达式进行选择；其次，由FROM子句指定的根本表或视图中检索满足条件的元组；最后，按照SELECT子句中的目标属性表达式，选出元组中的属性值形成结果关系表。

关系定义设需要定义一个“学生-课程数据库”S-C:学生关系表：S(Sno,Sname,Ssex,Sage,Sdept)课程关系表：C(Cno,Cname,Cpno,Ccredit)学生课程关系表：SC(Sno,Cno,Grade)例2-1创立一个学生-课程数据库S-CCREATESCHEMA“S-C”AUTHORIZATIONJohn;

关系定义例2-5建立一个“学生选课”根本表SCCREATETABLESC(SnoCHAR(9)，CnoCHAR(4)，GradeSMALLINT，PRIMARYKEY(Sno，Cno)，FOREIGNKEY(Sno)REFERENCESS(Sno)，FOREIGNKEY(Cno)REFERENCESC(Cno) );

关系定义例2-10建立计算机科学系的学生视图。

CREATEVIEWCS_SASSELECTSno，Sname，SageFROMStudentWHERESdept=‘IS’；

关系定义关系数据查询分为□基于单表查询□基于连接的多表查询□基于嵌套的多表查询基于嵌套查询：

●

不相关子查询

●

相关子查询

数据查询例2-13基于连接多表查询：查询每个学生及其选修课程的情况SELECTStudent.*，SC.*FROMStudent，SCWHEREStudent.Sno=SC.Sno；

数据查询例2-14

基于嵌套的多表查询：查询选修了课程名为“DB”的学生学号和姓名

SELECTSno，Sname

//③

最后在Student关系中取出Sno

和Sname FROMStudent WHERESnoIN(SELECTSno//②

然后在SC关系中找出选修了3号课程的学

生学号

FROMSCWHERECnoIN(SELECTCno//①

首先在C中找出“DB”的课程号—3号

FROMCWHERECname=‘DB’));

数据查询例2-16设有如下嵌套查询SELECTSnameFROMStudentWHEREEXISTS(SELECT*FROMSCWHERESno=Student.SnoANDCno='1')；那么可以转换为如下连接查询：SELECTSname FROMStudent,SC WHEREStudent.Sno=SC.SnoANDSC.Cno='1';

数据查询SQL有插入元组和插入子查询结果两种方式例2-18

对每一个系，求学生平均年龄首先，定义相应关系表Dept_age：

CREATETABLEDept_age(SdeptCHAR(15) /*系名*/Avg_ageSMALLINT)； /*学生平均年龄*/向Dept_age插入数据

INSERTINTODept_age(Sdept，Avg_age)

SELECTSdept，AVG(Sage)FROMStudentGROUPBYSdept；2.2.3数据更新2.数据删除例2-19

删除CS中所有学生的选课记录。

DELETEFROMSCWHERE'CS'=(SELETESdeptFROMStudentWHEREStudent.Sno=SC.Sno)；

数据更新3.数据修改例2-20

将计算机科学系全体学生的成绩置零。

UPDATESCSETGrade=0WHERE'CS'=(SELETESdeptFROMStudentWHEREStudent.Sno=SC.Sno)；2.2.3数据更新第2章关系数据库根底2.1关系数据模型2.2关系数据语言SQL2.3关系模式设计2.4关系数据库保护2.5关系数据事务管理关系数据模式设计=关系数据库逻辑设计针对具体问题构造一个相应数据模式构造原理：关系数据库标准化理论实际应用问题中需要将客观实体各种特征抽象为属性然后将这些属性构成相应关系模式实际中抽象出来的多个属性不能简单凑成假设干个关系模式□“有关联”和“没关联”属性不可组成同一个关系表□“强关联”和“弱关联”属性不可组成同一个关系表否那么会产生数据冗余数据冗余会引发数据异常2.3

关系模式设计为了防止由于数据冗余带来的数据不一致只能将有关联的属性子集以及有较强关联的属性子集放在一起构成相应关系模式需要研究：□如何刻画属性子集之间的语义关联？□如何得到属性子集之间的语义关联？

函数依赖〔1〕描述属性间语义关联就是研究各类数据依赖数据依赖:关系模式内部属性间约束关系反映数据内在性质是数据语义的实际表达。主要数据依赖□函数依赖〔FunctionalDependency，FD〕□多值依赖〔MultivaluedDependency，MVD〕□连接依赖〔JoinedDependency，JD〕〔2〕获取属性间语义关联的根本途径□构建Armstrong公理系统□研究建立其上的相关技术2.3

关系模式设计函数依赖:最根本的数据依赖设R(U)是一个属性集U上的关系模式，X和Y是U的子集。假设对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等而在Y上的属性值不等，那么称“X函数确定Y”或“Y函数依赖于X”记作X→Y。其中X称为决定因素属性组，Y称为依赖因素属性组

函数依赖函数依赖类型〔1〕平凡函数依赖与非平凡函数依赖假设X→Y，但YX，那么X→Y是非平凡的函数依赖假设X→Y，但YX,那么X→Y是平凡的函数依赖〔2〕局部函数依赖在R(U)中，假设X→Y，并且对于X的任何一个真子集X’，都有X’不函数依赖于Y,那么称Y对X完全函数依赖假设X→Y，但Y不完全函数依赖于X，那么Y对X局部函数依赖〔3〕传递函数依赖在R(U)中，如X→Y，(YX),Y→XY→Z，那么称Z对X传递函数依赖。记为：X→Z如Y→X，即X←→Y，那么Z直接依赖于X

函数依赖□平凡函数依赖\□局部函数依赖--“弱”语义关联数据依赖□传递函数依赖/□非平凡函数依赖\□完全函数依赖--“强”语义关联数据依赖□直接函数依赖/

函数依赖关系模式设计根本要求：●不能将无数据语义关联的属性做成一个关系模式●不能将弱数据语义关联的属性做成一个关系模式□根本前提确定给定属性集合上所有属性子集之间的函数依赖关联□根本工具Armstrong公理系统

函数依赖为什么要创立Armstrong公理系统：●对给定属性集合，需找出其上所有函数依赖组成集合●给定属性集有或者显而易见函数依赖组的较小集合●需要从这些函数依赖集合出发得到所有函数依赖●通过Armstrong公理系统，通过计算机完成上述工作

函数依赖怎样通过得到所有函数依赖之集：□给定属性集合上函数依赖集为F通过基于函数依赖语义推理“逻辑蕴含”得到F的包F+□计算机是不能基于语义进行推理，只能通过基于语法进行推演的“逻辑推演”□需要“比照”函数依赖语义建立相应推演系统这个系统就是Armstrong公理系统

函数依赖“逻辑蕴含”与“逻辑推演”的等价性：●Armstrong公理比照函数依赖相关语义建立，需研究：□逻辑推演的结果是否一定是“逻辑蕴含”的结果？□逻辑蕴含结果是否一定能够通过“逻辑推演”得到？●基于“语义”推理和基于“语法”推演等价性问题这也是任何计算机智能需要研究的关键性问题●Armstrong公理系统意义□实现了逻辑蕴含和逻辑推演的等价性□纯粹数理逻辑在计算机学科的成果应用案例

函数依赖使用计算机获得给定属性集合函数依赖集合思路：●通过各种适宜方法获取初始函数依赖子集F●通过基于Armstrong公理系统得到F的逻辑推演结果F0●通过逻辑蕴含和逻辑推演的等价性，F0就是基于逻辑蕴含的闭包F+

函数依赖1.函数依赖集的闭包□给定R〔U〕，总有函数依赖存在，如平凡函数依赖和由候选键确定的函数依赖。□通常会指定一些语义明显的函数依赖以构建一个集合F，以F作为讨论的初始根底。这就将问题转化为如何通过由初始函数依赖集合F得到其它未知函数依赖

Armstrong公理系统例2-27设有R〔U〕，X、Y、Z⊆U，A、B∈U。X→{A，B}、X→Y和Y→Z是R〔U〕上非平凡函数依赖。按照函数依赖概念可得X→{A}和X→{B}；按照传递依赖概念可得X→Z。上述函数依赖并不直接显现，而是按照一定规那么〔函数依赖和传递函数依赖概念〕由函数依赖“推导”出来将此一般化，就是如何由的函数依赖集合F，推导出新的函数依赖

Armstrong公理系统①函数依赖集合F的逻辑蕴含设有关系模式R〔U，F〕，X、Y⊆U，假设R中满足F中函数依赖的关系实例r也满足X→Y，那么称F逻辑蕴含X→Y，记为F╞X→Y②函数依赖集合F的闭包被F逻辑蕴含的函数依赖全体构成集合称为函数依赖集F的闭包记为F+，即F+={X→Y|F╞X→Y}显然F⊆F+如果还有F=F+，那么称F是函数依赖的完备集合。

Armstrong公理系统由函数依赖集F求新函数依赖可归结为求F+但根据函数依赖定义完成这项工作却相当困难因为属性间函数依赖关系存在与否完全取决于数据语义例如，对于一个教师来说，如果只允许有一个电子邮箱，那么教师工号确定后，其电子邮箱地址随之确定。但如果教师有多个电子邮箱，那么上述函数依赖就不存在

Armstrong公理系统□确定函数依赖，需仔细研究数据语义不能仅根据当前数据值进行归纳，更不能“想当然”□实际中难以从语义得到所需要各种新函数依赖，□更难保证没有遗漏得到能由F逻辑蕴含“所有”函数依赖

Armstrong公理系统数理逻辑提供了解决问题的思路：□先将语义求解转换为语法求解，□即将“逻辑蕴含”转换为“逻辑推导”，□再讨论两者“等价性”，即通常所说的有效性与完备性这种根本考虑在关系模式设计理论中就表达为基于Armstrong公理系统的函数依赖推导技术

Armstrong公理系统2.Armstrong公理系统为建立基于函数依赖的语法系统，求得函数依赖集合闭包F+于1974年提出一套推导规那么。这套规那么能由已有函数依赖“逻辑推导”出新的函数依赖经过不断完善，形成了著名的“Armstrong公理系统”为关系模式设计提供了一个有效并且完备的理论根底

Armstrong公理系统〔1〕根本公理与推理规那么1〕根本公理Armstrong公理系统3条根本公理①A1〔自反律，reflexivity〕如果YXU，那么X→Y。②A2〔增广律，augmentation〕如果X→Y在R〔U〕上成立，且ZU，那么XZ→YZ③A3〔传递律，transitivity〕如果X→Y和Y→Z成立，那么X→Z。

Armstrong公理系统将F中函数依赖看作“形式”公式，即在相关讨论中并不涉及这些公式的语义，仅仅将其看做一些符号的组合，而形式公式正是数理逻辑中语法系统研究的对象。按照三公理，由F中形式公式“逻辑推导”出新形式公式如果形式公式Q可通过Armstrong公理系统由形式公式P“逻辑推导”得到，那么记为PᅡQ。

Armstrong公理系统2〕推理规那么由根本公理A1、A2和A3为根底，可得下面五条推理规那么⑴A4〔合并性规那么union〕{X→Y，X→Z}ᅡX→YZ。⑵A5〔分解性规那么decomposition〕：{X→Y，ZY}ᅡX→Z。⑶A6〔拟传递性规那么pseudotransivity〕{X→Y，WY→Z}ᅡWX→Z。⑷A7〔复合性规那么compositionrule〕{X→Y，W→Z}ᅡWX→YZ。⑸A8〔通用一致性规那么generalunificationrule〕：{X→Y，W→Z}ᅡX〔W-Y〕→YZ。

Armstrong公理系统3.有效性和完备性□如果由F出发根据Armstrong公理逻辑推导出的每个形式公式X→Y作为“函数依赖”X→Y都在F+当中，那么称Armstrong公理系统是有效的。□如果F+中每个函数依赖X→Y都可通过将F中元素作为“形式公式”，根据Armstrong公理系统“逻辑推导”而得到，那么称Armstrong公理系统是完备的。

Armstrong公理系统●公理系统有效性

保证了所有逻辑推导出的“形式公式”作为函数依赖都是语义为真，即逻辑推导出的形式公式都是函数依赖；●公理系统完备性保证了可以逻辑推导出所有可能的函数依赖，即所有函数依赖都可以由逻辑推导得到，或者说，不能用公理系统逻辑推导的函数依赖都不能为真可以证明，Armstrong公理具有有效性与完备性

Armstrong公理系统范式符合某一种级别的关系模式的集合□关系数据库中的关系必须满足一定的要求□满足不同程度要求的为不同范式□关系模式R为第n范式，可简记为R∈nNF□一个低一级范式的关系模式通过模式分解可以转换为假设干个高一级范式的关系模式的集合过程叫标准化

关系模式范式〔1〕第一范式□如果一个关系模式R所有属性都是不可分的根本数据项那么R∈1NF。□第一范式是对关系模式最根本要求不满足第一范式数据库模式不能称为关系数据库□对于不满足1NF的关系模式，需将不满足要求的属性“分解”为满足原子性多个属性

关系模式范式〔2〕第2范式假设R∈1NF，且每一个非主属性完全函数依赖于键，那么称R满足第2方式，记为R∈2NF〔3〕第3范式□关系模式R中假设不存在这样的键X、属性组Y及非主属性Z〔Z⋢Y〕,使得X→Y，Y→Z成立，那么称R满足第3范式记为R∈3NFN假设R∈3NF必有R∈2NF□假设R∈3NF，那么每一个非主属性既不局部依赖于键也不传递依赖于键。

关系模式范式〔4〕BC范式关系模式∈1NF，假设X→Y且Y⋢X时X必含有键，那么称R满足BCNF，并记为R∈BCNF。R∈BCNF等价于每一个决定因素属性组都包含主键。当假设R∈BCNF时，所有非主属性对键都是完全函数依赖；所有主属性对每一个不包含它的键也是完全函数依赖；没有任何属性完全函数依赖于非键的任何一组属性。R∈BCNF必有R∈3NF。

关系模式范式多值依赖和连接依赖是更为一般的数据依赖联系。1.多值依赖与4NF□函数依赖实质上反映的是“多对一”联系□在实际应用中还会有“一对多”数据联系□诸如此类不同于函数依赖的数据联系也会产生数据冗余从而引发各种数据异常

多值依赖和连接依赖〔1〕多值依赖设有关系模式R〔U〕，X、Y是属性集U中两个子集，而r是R〔U〕中任意给定一个关系实例。如果下述条件成立，那么称Y多值依赖于X，记为X→→Y。①对于r在X上的一个确定的值〔元组〕，都有r在Y中一组值与之对应②Y的这组对应值与r在Z=U-X-Y中的属性值无关如果X→→Y，但Z=U-X-Y≠Φ，那么称其为非平凡多值依赖，否那么称为平凡多值依赖。平凡多值依赖常见情形是U=X∪Y，此时Z=Φ。

多值依赖和连接依赖〔2〕第4范式——4NF对于R〔U〕中的任意两个属性子集X和Y，如果对于任意非平凡多值依赖X→→Y，X都为超键，那么称R〔U〕满足第4范式，记为R〔U〕∈4NF。①由于R〔U〕上的函数依赖X→Y可看做多值依赖X→→Y，如果R〔U〕属于第4范式，此时X就是超键，所以X→Y满足BCNF，即4NF中所有的函数依赖都满足BCNF。

多值依赖和连接依赖2.连接依赖与5NF更为一般数据依赖是连接依赖。就像引入多值依赖之后，函数依赖就成为多值依赖特例引入连接依赖概念之后，多值依赖就可以作为连接依赖的特例对于连接依赖，也有相应的第5范式。实际应用中，主要是函数依赖及相应范式。各种数据依赖和范式之间关系如以下图所示。

多值依赖和连接依赖

多值依赖和连接依赖第2章关系数据库根底2.1关系数据模型2.2关系数据语言SQL2.3关系模式设计2.4关系数据库保护2.5关系数据事务管理关系数据库保护是指数据库完整性保护和平安性保护□数据库完整性保护:防范目标：数据库中不符合语义即不正确的数据防范对象：合法用户的非法操作□数据库平安性保护:防范目标：保护数据库防止恶意破坏和非法存取防范对象：非法用户的非法操作2.4关系数据库保护数据库完整性:□逻辑描述上：数据正确性和相容性□技术实现上：指数据实体完整性、参照完整性、用户完整性〔1〕实体完整性在CREATETABLE由PRIMARYKEY定义□如主键由单属性构成，可将其定义为列级约束条件□如主键由多属性构成，需将其定义为表级约束条件完整性保护〔2〕参照完整性保护关系模式参照完整性在CREATETABLE中□用FOREIGNKEY定义哪些列为外键□用REFERENCES指明这些外键参照哪些表的主键。例如，关系SC一元组表示一学生选修的某门课程的成绩〔Sno，Cno〕是主键Sno，Cno分别参照引用Student主键和Course主键完整性保护出现破坏参照完整性情形时DBMS会进行相应处理完整性保护违反参照完整性三种处理方式：□拒绝(NOACTION)：系统默认策略；□级联(CASCADE)□设置为空值〔SET-NULL〕对于参照完整性，除定义外键外还应定义外键列是否允许空值完整性保护〔3〕用户定义完整性保护用户定义完整性约束在SQL中分为两种类型：●直接使用：创立关系表时定义用户约束□属性级约束□元组级约束●间接调用：独立定义用户完整性约束□断言约束□域约束完整性保护间接调用：独立定义用户完整性约束①断言〔Asseertion〕完整性约束涉及多个关系或聚合时可使用SQL“断言”约束

●创立：CREATEASSERTION<断言名>CHECK〔<条件>〕

<条件>与SELECT语句中WHERE子句条件关系达式相同

完整性保护●撤销:DROPASSERTION<断言名>

撤销断言句法不提供RESTRICT和CHECK〔<条件>〕

例6-27关系T，S，C,SC中使用断言写出完整性约束。

□每位教师开设的课程不超过10门

CREATEASSERTIONASSE1CHECK

〔10>=ALL(SELECTCOUNT(C#)

FROMC

GROUPBYT#)〕；完整性保护②域(Domain)约束

SQL支持域的使用，可创立一个域并在其上定义相应约束

域约束作用于所有属于指定域的属性列●创立：CREATEDOMAIN<域名><域类型>CHECK<条件>域约束语句可使用CHECK子句。为便于引用，约束可以命名。

约束命名使用保存字CONSTRAINT。

完整性保护例6-26

CREATEDOMAINGradesCHAR〔1〕DEFULT‘？’

CONSTRAINTVALID-Grades

CHECK〔VALUEIN

〔‘A’，‘B’，‘C’，‘D’，‘E’，‘？’〕〕□上述定义一个新的域Grades□并加一个名为“VALID-Grades”域约束□CHECK子句指明定义在该域列上取值，缺省值为“？”完整性保护如对SC〔S#，C#，G〕中G用域Grades定义：

CREATETABLESC

〔S#NUMERIC〔6〕，

C#CHAR〔6〕，

GGrades，

……〕；对SC进行插入操作时，每插入一条学生成绩记录，其成绩G须为CHECK子句指明值，缺省时为“？”

否那么为非法成绩值，系统将会产生一个含有约束名为“VALID-Grades”的诊断信息，以关系明当前操作不满足该域约束

完整性保护●数据库平安性涉及技术平安、管理平安和政策平安●数据库学科主要讨论技术平安 □操作系统平安、 □网络平安□数据库自身平安技术。●数据库平安技术:数据库自身平安技术●数据库自身平安技术:数据库平安性控制、视图和审计其中平安性控制是数据库平安性保护主要技术支撑平安性保护〔1〕基于存取控制的平安性技术数据库平安性控制:自主存取控制和强制存取控制①自主存取控制〔DAC〕：□用户对于不同数据库对象具有不同存取权限□不同用户对同一数据库对象具有不同存取权限□只有具有相应权限的用户才能存取相应的数据库对象平安性保护□用户权限:数据库对象操作类型□数据库对象：数据库、根本表、视图和索引等□数据库操作：创立、更新、查询等□RDBMS支持自主存取控制□SQL通过GRANT和REVOKE语句实现自主存取控制平安性保护②强制存取控制〔MAC〕：□每个数据库对象都分配一个“密级”□每个用户也被授予一个级别□对于每个数据库对象，根据其密级，具有相应合法许可证级别的用户才能存取□相比自主存取控制，强制存取控制平安性检查更为严格实际应用中，在实现MAC之前先实现DAC，由两者共同构成数据库的平安性保护平安性保护〔2〕基于视图的平安性保护□为不同用户创立不同视图□通过将数据对象限制在一定范围□把需要保密的数据对无权存取的用户屏蔽起来□自动为数据提供一定程度的平安性保护例2-46建立计算机系学生的视图，把对该视图的SELECT权限授于王平，把该视图上的所有操作权限授于张明平安性保护先建立计算机系学生的视图CS_StudentCREATEVIEWCS_StudentASSELECT*FROMStudentWHERESdept='CS'；平安性保护〔3〕基于审计的平安性保护基于存取控制和视图平安性机制可看作是“事先预防”任何平安性措施都会有缺陷，都有可能被攻破审计〔audit〕：□将用户对于数据库对象所有操作都通过审计日志予以记录□然后通过审计跟踪性心□重现导致数据库平安性破坏的一系列事件□从而发现非法存取的人、事件和内容等平安性保护第2章关系数据库根底2.1关系数据模型2.2关系数据语言SQL2.3关系模式设计2.4关系数据库保护2.5关系数据事务管理完成业务工作常常会涉及到多个数据操作组成的序列技术上:每个操作都可独立完成逻辑上:只有序列中每个操作都完成才能实现一项业务工作这些可单个执行的操作有内在关联它们组成的操作序列需看做一个不可分割的工作单元这种工作单元就是数据库中的事务2.5关系数据事务管理事务〔transaction〕:满足下述性质的数据操作序列：①工作执行的原子性〔Atomic〕序列中数据操作“要么全做，要么全不做”，不能存在局部完成情况②更行操作的一致性〔comsistency〕执行数据更新过程中保证数据前后一致性,能够从一种一致性状态转换到另一种一致性状态2.5关系数据事务管理③并发执行的隔离性〔Isolation〕如果多个操作序列同时执行，最终效果需与单个操作序列独立执行相同④成功结果的持久性〔Durability〕当操作序列成功执行后相应数据结果于数据库影响持久即便是当数据库发生故障遭到破坏时也能恢复原先结果2.5关系数据事务管理数据库根本目标是对实现对数据的统一管理和用户共享实现用户共享数据技术途径：多项数据库操作并发执行进行统一管理数据重要任务：数据库故障恢复事务管理：“并发执行”和“故障恢复”适当和有效技术实现架构2.5关系数据事务管理数据库共享：多用户同时使用数据库中同一数据即数据库多事务并发执行多事务并发执行三种实现方式①事务串行执行

每时刻只有一个事务运行其它事务须等该事务结束方能运行缺点：不能充分利用系统资源，发挥数据库共享资源特征2.5.1并发控制②交叉并发方式〔InterleavedConcurrency〕□单处理机系统并行事务操作轮流交叉运行，事务没真正并行运行，但能减少处理机的空闲时间，提高系统效率③同时并发方式〔simultaneousconcurrency〕□多处理机系统每个处理机可运行一个事务，多个处理机可以同时运行多个事务，真正实现多事务并行运行。数据库多事务并发执行主要研究交叉并发执行。2.5.1并发控制多事务并发执行研究课题①如果不进行并发控制，会出现哪些问题，又如何解决？②并发调度有多种方式，如何判定那种方式“适宜”？③并发执行的复杂性，在上述两个问题之外，还会产生什么问题，又如何解决？2.5.1并发控制1.并发控制根本技术〔1〕并发控制必要性并发执行需加以控制或调度，否那么会出现下述问题。①丧失修改②不可重复读□事务T1读取数据后□事务T2执行更新操作□使T1无法再现前一次读取结果2.5.1并发控制③读“脏”数据□事务T1修改某一数据，并将其写回磁盘□事务T2读取同一数据后，T1由于某种原因被撤销□这时T1已修改正的数据恢复原值，T2读到的数据就与数据库中的数据不一致□T2读到的数据就为“脏”数据，即不正确的数据2.5.1并发控制(2)封锁技术并发控制技术：事务的封锁技术。封锁是系统对事务并发执行的一种调度和控制保证系统对数据项的访问以互斥方式进行封锁根本点:对数据对象操作实行某种专有控制在一段时间内，防止其它事务访问指定资源禁止对数据J进行操作保证并发执行事务间相互隔离互不干扰2.5.1并发控制①事务T需对数据D进行操作〔读/写〕时，□须向系统提出申请，对D加以封锁□加锁成功后，即具有对数据D一定操作与控制权限□此时，其它事务不能对加锁的数据D随意操作②事务T操作完成之后即释放锁此后数据即可为其它事务操作效劳基于封锁技术的事务进程如图2-13所示。2.5.1并发控制2.5.1并发控制表级封锁两种形式●排它锁〔eXclusivelocks〕:事务T对数据对象D加X锁后，T可对D进行读写其它事务只有等到T解除X锁后，才能对D进行封锁和操作排它锁实质:保证事务对数据的独占性排除其它事务对它执行过程的干扰2.5.1并发控制由于只容许一个事务单独封锁数据，其它申请封锁的事务只能排队等待，所以采用X锁时并发程度较低□共享锁〔SharingLocks〕：事务T对数据D加S锁之后，T可读D但不能写D其它事务可对D加S锁但不能加X锁□共享锁实质：保证多个事务可以同时读A但在施加共享封锁的事务T释放D上的S锁之前其它各个事务〔包括T本身〕都不能写D图2-14所示为X锁和S锁的示意图。2.5.1并发控制2.5.1并发控制(3)三级封锁协议对数据封锁时需约定一些规那么，如何时申请封锁、持锁时间和什么时间释放封锁等，这就是所谓封锁协议①一级封锁协议：□事务T对数据D进行写操作前，须对D加X锁保持加锁状态直到事务结束才可释放加在D上的X锁□一级封锁协议可以防止“修改丧失”2.5.1并发控制②二级封锁协议□事务T在读取数据D前须先对D加S锁□读完之后即刻释放加在D上的S锁。此封锁方式与一级封锁