数据库系统概论之关系模型课件

第三章关系模型--本章内容基础知识回顾关系模型概述关系模型基本概念关系模型的完整性约束关系代数逻辑数据库设计：ER到关系的转换关系演算第三章关系模型--本章内容基础知识回顾1基础知识回顾数据库发展以数据模型划分第一代网状、层次数据库系统。代表：1969年IBM的IMS(informationManagementSystem);美国CODASYL(ConferenceOnDataSystemLanguage)下属的DBTG（DataBaseTaskGroup）于60年代末70年代初提议的方法。层次数据库是数据库的先驱，而网状数据库是数据库概念、方法、技术的奠基者。第二代关系数据库系统。1970年IBM公司的研究员E.F.Codd提出了数据库的关系模型，关系方法和关系数据理论的研究。代表：IBM的SystemR和Berkele大学的INGRES，成果：奠定了关系模型的理论基础；研究了关系数据库语言，有关系代数、关系演算、SQL语言、QBE等；研制了大量的RDBMS的原型，实现了查询优化、并发控制、故障恢复等关键技术；基础知识回顾数据库发展2基础知识回顾数据库发展第三代以面向对象数据模型为主要特征的数据库系统。模型更加丰富、数据管理功能功能更加强大、能支持传统数据库难以支持的新的应用。特征：支持数据管理、对象管理和知识管理；保持或者继承第二代数据库的技术；对其他系统开放（支持数据库语言标准和标准网络协议）。仅支持面向对象数据模型并不能称为第三代数据库系统。基础知识回顾数据库发展3基础知识回顾关系数据库系统关系数据库系统。产品的发展情况：(1)对关系模型的支持：第一阶段（70年代）：仅支持关系数据结构、基本的关系操作（选择、投影、连接）。如：dBASE第二阶段（80年代)：SQL成为关系数据库语言的国际标准第三阶段（90年代）：加强了完整性、安全性的支持。(2)运行环境：第一阶段：在大、中、小型机上的RDBMS，多用户系统第二阶段：提高可移植性，能在多种硬件平台、和操作系统环境下运行；联网，向分布式发展，支持多种协议。第三阶段：分布式数据库和客户/服务器结构的数据库系统的推出。追求开放性（可移植性、可连接性、可伸缩性）。基础知识回顾关系数据库系统4基础知识回顾关系数据库系统关系数据库系统。产品的发展情况：(3)RDBMS系统构成：第一阶段：早期的RDBMS产品主要提供数据定义、数据存取、数据控制等基本操作和数据存储组织、并发控制、安全性、完整性检查、系统恢复等RDBMS的核心功能。第二阶段：以RDBMS基本功能为核心，开发外围软件系统，如：FORM报表生成系统，REPORT报表系统、MENU菜单生成系统、GRAPHIC图形软件等等。为用户提供了良好的第四代应用开发环境。(4)对应用的支持：第一阶段：用于信息管理、辅助决策等应用领域。第二阶段：联机事务处理的应用领域，提高RDBMS事务处理的能力。第三阶段：由集中到分布，由局部到整个企业甚至整个行业。支持整个企业的联机事务处理。基础知识回顾关系数据库系统5关系模型概述为什么要学习关系模型?关系模型是目前广泛使用的一种数据模型IBMDB2,MiscrosoftSQLServer,Informix,Oracle,Sybase,…………….仅有少量的遗产系统使用旧的数据模型IBM的IMS目前仍在使用目前关系模型的竞争者:面向对象的数据模型Objectstore,Versant,Ontos,……….对象关系模型:InformixUniversalServer,UniSQL,O2,ORACLE,DB2,………...关系模型概述为什么要学习关系模型?6关系模型概述关系数据模型是由E.F.Codd于1970年提出在此之前大多数数据库系统是基于层次数据模型和网状数据模型的关系模型给数据库领域带来了一场革命，并取代了旧的数据模型,E.F.Codd并因此于1983年获得TuringAwards在70年代中期，IBM和UC-Berkeley开发了早期的关系型数据库管理系统关系模型概述关系数据模型是由E.F.Codd于1970年提出7关系模型概述现在的关系型数据库系统有IBM的DB2InformixOracleSybaseMicrosoft的Access,SQLServerFox-xParadox关系模型概述现在的关系型数据库系统有8关系模型概述关系模型是十分简单的关系模型的数据结构非常单一，实体、联系都表示成关系一个关系是一个具有行和列的二维表关系模型给出关系操作的能力，但不对RDBMS语言给出具体的语法要求查询操作：选择、投影、连接、除、并、交、差等更新操作：增加、删除和修改一次一集合关系代数和关系演算高度非过程化关系模型概述关系模型是十分简单的9关系模型概述关系模型的三类完整性约束系统支持：实体完整性和参照完整性用户定义：用户定义的完整性本章主要讨论以下问题关系模型是如何表示数据的关系模型可以表示何种完整性约束数据是如何被查询的如何将由ER模型表示数据库概念模式转换为关系模式(模式)的视图(外模式)问题关系模型概述关系模型的三类完整性约束10关系模型基本概念关系域：一组具有相同数据类型值的集合笛卡尔积：给定一组域D1,D2,…,Dn，它们的笛卡尔积为：D1XD2X…Dn={(d1,d2,…,dn)|di∈Di,i=1,2,…n)元组：每一个元素(d1,d2,…,dn)叫做一个n元组，或元组分量：元素中的每一个值di叫做一个分量基数：若Di为有限集，其基数为mi,则D1XD2X…Dn的基数为：关系模型基本概念关系11关系模型基本概念例如：给定三个域D1=MAN={王兵，李平，张英}，D2=WOMAN={丁梅，吴芳}D3=CHILD={王一，李一，李二}D1XD2XD3={（王兵，丁梅，王一），（王兵，丁梅，李一），（王兵，丁梅，李二），（王兵，吴芳，王一），（王兵，吴芳，李一），…}笛卡尔积可以表示为一个二维表，表中的每一行对应一个元组，每一列对应一个域关系模型基本概念例如：给定三个域D1=MAN={王兵，李平，12关系模型基本概念MANWOMANCHILD王兵丁梅王一王兵丁梅李一王兵丁梅李二王兵吴芳王一王兵吴芳李一王兵吴芳李二李平丁梅王一李平丁梅李一李平丁梅李二李平吴芳王一李平吴芳李一李平吴芳李二MANWOMANCHILD张英丁梅王一张英丁梅李一张英丁梅李二张英吴芳王一张英吴芳李一张英吴芳李二续左表关系模型基本概念MANWOMANCHIL13关系模型基本概念关系:D1XD2X…Dn的子集叫做在域D1,D2,…,Dn上的关系表示为R(D1,D2,…,Dn)关系的目或度：n单元关系：n=1二元关系：n=2关系是一个二维表（子集）例如：假设王兵的妻子是丁梅，他们的孩子是王一，李平的妻子是吴芳，他们的孩子是李一和李二，则取笛卡尔积的一个子集构造一个关系FAMILY关系模型基本概念关系:D1XD2X…Dn的子集叫做在域D114关系模型基本概念在R(D1,D2,…,Dn)表示中，域可以重名，给每列一个名字，称为属性，关系表示为：R(A1,A2,…,An)例如：FAMILY(FATHER,MOTHER,CHILD)MANWOMANCHILD王兵丁梅王一李平吴芳李一李平吴芳李二FAMILY关系模型基本概念在R(D1,D2,…,Dn)表示中，域15关系模型基本概念候选码：能够唯一标识一个元组的最小属性组主码：主属性：候选码中的属性非码属性：不包含在任何候选码中的属性关系的性质：关系模型要求在一个关系中不能存在完全相同的元组(但实际商用关系数据库系统支持重复元组)关系中元组行的序并不重要关系中列的序并不重要（但有些系统例外）关系模型基本概念候选码：能够唯一标识一个元组的最小属性组16关系模型基本概念分量必须取原子值不同的列可以出自同一个域给定域：person={王兵，李平，张英，丁梅，吴芳}child={王义，李一，李二}MANWOMANCHILDfirstsecond王兵丁梅王一李平吴芳李一李二FAMILYbad关系模型基本概念分量必须取原子值MANWOMAN17关系模型基本概念构造FAMILY关系，仍然取personXpersonXchild的子集，表示为：FAMILY(FATHER,MOTHER,CHILD)此处dom(FATHER)=dom(MOTHER)=person关系模式：关系的描述形式化表示：R(U,D,dom,F)，简记为R(U)或R(A1,A2,…,An)属性向域的映象常常说明为属性的类型和长度关系模式是型，关系是值关系模型基本概念构造FAMILY关系，仍然取personX18关系模型基本概念在关系模型中，实体和联系都是用关系表示的例如：左图

学生(学号，姓名，性别，专业，年龄)

课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)一个关系数据库是一组关系的集合；关系数据库模式则是该数据库所有关系模式的集合学生课程选修mn关系模型基本概念在关系模型中，实体和联系都是用关系表示的学生19关系模型--关系的完整性关系模型的完整性是对关系的某种约束实体完整性：主码中的属性不可取空值(例子)参照完整性：例子：对于关系模式学生(学号，姓名，性别，专业，年龄)

课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)外码：设F是关系R的一个或一组属性，但不是关系R的码，如果F与关系S的主码Ks相对应，则称F为关系R的外码关系模型--关系的完整性关系模型的完整性是对关系的某种约束20关系模型--关系的完整性参照关系R，被参照关系S参照完整性：F的取值必须为：或者取空值或者等于S中某个元组的主码值例如：部门(部门号，部门名，电话)

雇员(雇员号，雇员名，职称，部门号)雇员中部门号的取值部门雇员拥有1n关系模型--关系的完整性参照关系R，被参照关系S部门雇员拥有21关系模型--关系的完整性用户定义的完整性：任何关系数据库系统都应支持实体完整性和参照完整性用户定义的完整性定义某一具体应用中所涉及的数据必须满足的语义要求，例如年龄的取值关系数据库系统提供定义和检验这类完整性机制关系模型--关系的完整性用户定义的完整性：22关系模型--关系代数关系代数运算分为：传统的集合运算和专门的关系运算集合运算前提：关系R和关系S具有相同的目，相应的属性取自同一个域并：关系R和关系S的并记作：RS（下页）差：关系R和关系S的差记作：R-S交：关系R和关系S的交记作：RS关系模型--关系代数关系代数运算分为：传统的集合运算和专门的23关系模型--关系代数ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1RSRSRSR-S关系模型--关系代数ABC24关系模型--关系代数R×SABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1RS关系模型--关系代数R×SABC25关系模型--关系代数广义笛卡尔积：两个分别为n和m目的关系R和S的广义笛卡尔积是一个n+m列的元组的集合。若R有k1个元组，S有k2个元组，则广义笛卡尔积有k1×k2个元组记作：R×S关系模型--关系代数广义笛卡尔积：两个分别为n和m目的关系R26关系的建立和修改--SQL-92SQL语言的简单发展历史SQL语言是由IBM公司在SystemR系统中首先提出SQL在1986年被ANSI采纳为标准，称为SQL-86在1989又对SQL标准进行了少量修改，称为SQL-89在1992年ANSI和ISO对SQL标准进行主要修改，称之为SQL-92在1999年又对SQL-92进行大量修改(面向对象的特点)，称之为SQL-3，有时也称为SQL-99关系的建立和修改--SQL-92SQL语言的简单发展历史27关系的建立和修改关系表建立CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL)关系表删除DROPTABLEStudents关系表修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR(10)关系的建立和修改关系表建立28关键字约束--实现实体完整性通过UNIQUE子句来定义候选码(候选关键字)通过PRIMARYKEY子句来定义主码(主关键字)CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE(name,age),UNIQUE(login),PRIMARYKEY(sid))关键字约束--实现实体完整性通过UNIQUE子句来定义候选码29外键约束--实现参照完整性外键约束指的是两个关系之间的关键字约束关系,考虑下列关系Students(sid,name,login,age,gpa)Enrolled(sid,cid,grade)从语义上来讲,在关系Enrolled中出现的sid值,在关系Students中必须存在,Enrolled中的sid称为外键,引用关系Students中的主关键字sid外键必须与被引用关系中的主关键字相匹配可以有不同的名字列数要相同,且要具有兼容的数据类型外键约束--实现参照完整性外键约束指的是两个关系之间的关键字30外键约束----示例外键约束----示例31外键约束的语义在被参照关系中关键字的值在参照关系中不一定出现但在参照关系中出现的关键字值在被参照关系中必须要出现如果我们向关系Enrolled中插入元组<55555,Art104,A>,这个操作将被拒绝因为违反了外键约束外键约束的语义在被参照关系中关键字的值在参照关系中不一定出现32外键约束的语义对于操作:将关系Students中的<53666,Jones,joines@cs,18,3.4>删除,有两种处理禁止这种删除操作同时删除参照关系中的相关元组值得注意的是外键可能来自于同一关系,也就是被参照关系就是参照关系Students(sid,name,login,age,gpa,partner),partner是对sid的一个外键约束Courses(cid,name,desc,preq),preq是对cid的一个外键约束当一门课程没有前期课程时,preq可以为空,空值并不违反外键约束外键约束的语义对于操作:将关系Students中的<536633外键约束的定义---SQL-92外键约束的定义---SQL-9234逻辑数据库设计：ER到关系的转换实体集到表的转换实体集中的属性映射为表中的属性实体集中的(主)关键字映射为关系中的(主)关键字实体集中属性的域映射为关系中属性的域逻辑数据库设计：ER到关系的转换实体集到表的转换35实体集到表的转换--示例实体集到表的转换--示例36多对多联系集到表的转换多对多联系被映射为一个关系表，包括属性：每个参加联系的实体集的主关键字属性，作为外键存在所有外键构成该实体集的主关键字联系集本身的属性--一般属性多对多联系集到表的转换多对多联系被映射为一个关系表，包括属性37多对多联系集到表的转换--例1mn多对多联系集到表的转换--例1mn38多对多联系集到表的转换--例1多对多联系集到表的转换--例139多对多联系集到表的转换--例2mnp多对多联系集到表的转换--例2mnp40多对多联系集到表的转换--例2CREATETABLEWork3-In(ssnCHAR(11),didinteger,fromdate,todate,PRIMARYKEY(ssn,did,from,to)FOREIGKEY(ssn)REFERENCESEmployees,ONDELETENOACTION,FOREIGKEY(did)REFERENCESDepartments,FOREIGNKEY(from)REFERENCEDURATION,FOREIGNKEY(to)REFERENCEDURATION)多对多联系集到表的转换--例2CREATETABLEWo41一对多联系集的翻译1n一对多联系集的翻译1n42一对多联系集的翻译----方法一将一对多联系翻译为一个独立的表一对多联系集的翻译----方法一将一对多联系翻译为一个独立43一对多联系集的翻译----方法二将Manages和Departments翻译为一个关系一对多联系集的翻译----方法二将Manages和Depa44关于联系集到关系映射的思考题在一对多联系中，Manages和Departments为什么可以合并为一个关系？对于一对多联系翻译的两种方法的优缺点是什么？对于一个多对多联系集为什么必须映射为一个独立的关系表？一对一联系应如何翻译？关于联系集到关系映射的思考题在一对多联系中，Manages和45思考题部分答案方法一和方法二的优缺点方法一多产生一个关系对于有些查询，方法一需要两次连接，而方法二只需要一次连接即可方法二的缺点是浪费空间，如果有些部门没有经理的话思考题部分答案方法一和方法二的优缺点46具有参加约束的联系集的翻译1nnm具有参加约束的联系集的翻译1nnm47具有参加约束的1:n(1:1)联系集的翻译具有参加约束的1:n(1:1)联系集的翻译48具有参加约束的联系集的翻译ssn的非空定义反映了参加约束使用上面的第一种方法也可以表示Manages和Departments，但使用方法二比方法一好，(why?因为方法二浪费空间的缺点已不复存在)具有参加约束的联系集的翻译ssn的非空定义反映了参加约束49弱实体集的翻译一个弱实体总是参加一个二元一对多联系(?)全参加约束1m弱实体集的翻译一个弱实体总是参加一个二元一对多联系(?)1m50弱实体集的翻译使用具有1:n联系的第二种翻译方法（Why?）,但必须考虑下面的具体要求必须考虑弱实体集有一个部分关键字当一个Owner实体被删除以后,弱实体集中相应的实体也应被删除弱实体集的翻译使用具有1:n联系的第二种翻译方法（Why?）51弱实体集的翻译弱实体集的翻译52类层次的翻译类层次的翻译53类层次的翻译--方法一三个实体集翻译成三个关系实体集Employees的翻译比较简单关系Hourly_Emps的属性包括:ssn,hourly_wages,hours_worked,;ssn是主关键字;同时ssn一个外键;当超类中实体被删除时子类中的对象也必须删除Contract_Emps的翻译相类似思考题：为什么在关系Hourly_Emps的属性中不包含属性name和lot?

体现继承性了吗？类层次的翻译--方法一三个实体集翻译成三个关系54类层次的翻译--方法一CREATETABLEHourly_Emps(ssnCHAR(20),hourly_wagesREAL,hours_workedINTEGER,PRIMARYKEY(ssn),FOREIGKEY(ssn)REFERENCESEmployees,ONDELETECASCADE)类层次的翻译--方法一CREATETABLEHourl55类层次的翻译--方法二三个实体集翻译成两个关系仅生成两个关系:Hourly_Emps和Contract_Emps,他们都包含超类Employees的属性,除了主关键字约束以外,不需要定义任何约束当然，对于overlap约束只能用通用约束机制来实现对于方法一来讲，covering约束也只能用通用约束机制来实现类层次的翻译--方法二三个实体集翻译成两个关系56类层次的翻译--两种方法的比较方法一:当查询涉及到Employees的属性和其它一些细节属性时需要连接操作;当查询仅涉及到Employees的属性时则在Employees关系上进行即可;另一个优点是可以存储非Hourly_Emps和Contract_Emps的实体方法二:主要确定无法存储非Hourly_Emps和Contract_Emps的实体,且name和lot出现了两次;优点是仅涉及到Hourly_Emps或Contract_Emps的查询仅在一个关系上进行即可,不需要额外的连接操作,但涉及到所有雇员的查询则需要在两个关系上进行;类层次的翻译--两种方法的比较方法一:当查询涉及到Empl57实例分析一个公司数据库需要存储雇员、部门和雇员小孩的信息。雇员工作在部门(一个雇员只能工作在一个部门)，每个部门由一个雇员管理，每个雇员小孩的名字是唯一的，假定小孩只有一个家长工作在这个公司，而且我们不关心哪些已经调离雇员的小孩情况。请画出ER图扑获这些信息。雇员(ssn,salary,phone)部门(dno,dname,budget)小孩(name,age)实例分析一个公司数据库需要存储雇员、部门和雇员小孩的信息。雇58实例分析部门雇员小孩工作有1m管理n11ndnodnamebudgetssnsalaryphonenameage雇员(ssn,salary,phone,dno)部门(dno,dname,budget,ssnnotnull)小孩(ssn,name,age)实例分析部门雇员小孩工作有1m管理n11ndnodnameb59实例分析一个大学数据库包括教授、课程信息。教授讲授课程，下面几种情况都是描述有关讲授联系集的，对于每一种情况画ER图描述教授可以在几个学期讲授同一门课程，但仅最近一次的讲授活动需被记录下来教授可以在几个学期讲授同一门课程，每次讲授活动需被记录下来每个教授必须讲授课程每个教授只讲授一门课程实例分析一个大学数据库包括教授、课程信息。教授讲授课程，下面60实例分析每个教授只讲授一门课程，每门课程可有几位教授讲授假定一些课程可由一组教授联合讲授假定一些特定课程只能由一组教授联合讲授，且这些教授中的任一位不可能独立讲授这门课程（思考题）实例分析每个教授只讲授一门课程，每门课程可有几位教授讲授61实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人数（1）实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人62实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人数教授课程讲授nm职工号姓名电话课号课时学分班级学期人数？讲授情况p（2）实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人63实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人数讲授情况n（3）实例分析教授课程讲授nm职工号姓名电话课号课时学分班级学期人64实例分析教授课程讲授m1职工号姓名电话课号课时学分班级学期人数讲授情况n（4，5）实例分析教授课程讲授m1职工号姓名电话课号课时学分班级学期人65实例分析教授课程讲授m1职工号姓名电话课号课时学分班级讲授号人数讲授情况n学期（6）实例分析教授课程讲授m1职工号姓名电话课号课时学分班级讲授号66实例分析教授课程m1职工号姓名电话课号课时学分n（7）组构成nmISA一般课程特定课程讲授2讲授11参考答案实例分析教授课程m1职工号姓名电话课号课时学分n（7）组构成67第三章关系模型--本章内容基础知识回顾关系模型概述关系模型基本概念关系模型的完整性约束关系代数逻辑数据库设计：ER到关系的转换关系演算第三章关系模型--本章内容基础知识回顾68基础知识回顾数据库发展以数据模型划分第一代网状、层次数据库系统。代表：1969年IBM的IMS(informationManagementSystem);美国CODASYL(ConferenceOnDataSystemLanguage)下属的DBTG（DataBaseTaskGroup）于60年代末70年代初提议的方法。层次数据库是数据库的先驱，而网状数据库是数据库概念、方法、技术的奠基者。第二代关系数据库系统。1970年IBM公司的研究员E.F.Codd提出了数据库的关系模型，关系方法和关系数据理论的研究。代表：IBM的SystemR和Berkele大学的INGRES，成果：奠定了关系模型的理论基础；研究了关系数据库语言，有关系代数、关系演算、SQL语言、QBE等；研制了大量的RDBMS的原型，实现了查询优化、并发控制、故障恢复等关键技术；基础知识回顾数据库发展69基础知识回顾数据库发展第三代以面向对象数据模型为主要特征的数据库系统。模型更加丰富、数据管理功能功能更加强大、能支持传统数据库难以支持的新的应用。特征：支持数据管理、对象管理和知识管理；保持或者继承第二代数据库的技术；对其他系统开放（支持数据库语言标准和标准网络协议）。仅支持面向对象数据模型并不能称为第三代数据库系统。基础知识回顾数据库发展70基础知识回顾关系数据库系统关系数据库系统。产品的发展情况：(1)对关系模型的支持：第一阶段（70年代）：仅支持关系数据结构、基本的关系操作（选择、投影、连接）。如：dBASE第二阶段（80年代)：SQL成为关系数据库语言的国际标准第三阶段（90年代）：加强了完整性、安全性的支持。(2)运行环境：第一阶段：在大、中、小型机上的RDBMS，多用户系统第二阶段：提高可移植性，能在多种硬件平台、和操作系统环境下运行；联网，向分布式发展，支持多种协议。第三阶段：分布式数据库和客户/服务器结构的数据库系统的推出。追求开放性（可移植性、可连接性、可伸缩性）。基础知识回顾关系数据库系统71基础知识回顾关系数据库系统关系数据库系统。产品的发展情况：(3)RDBMS系统构成：第一阶段：早期的RDBMS产品主要提供数据定义、数据存取、数据控制等基本操作和数据存储组织、并发控制、安全性、完整性检查、系统恢复等RDBMS的核心功能。第二阶段：以RDBMS基本功能为核心，开发外围软件系统，如：FORM报表生成系统，REPORT报表系统、MENU菜单生成系统、GRAPHIC图形软件等等。为用户提供了良好的第四代应用开发环境。(4)对应用的支持：第一阶段：用于信息管理、辅助决策等应用领域。第二阶段：联机事务处理的应用领域，提高RDBMS事务处理的能力。第三阶段：由集中到分布，由局部到整个企业甚至整个行业。支持整个企业的联机事务处理。基础知识回顾关系数据库系统72关系模型概述为什么要学习关系模型?关系模型是目前广泛使用的一种数据模型IBMDB2,MiscrosoftSQLServer,Informix,Oracle,Sybase,…………….仅有少量的遗产系统使用旧的数据模型IBM的IMS目前仍在使用目前关系模型的竞争者:面向对象的数据模型Objectstore,Versant,Ontos,……….对象关系模型:InformixUniversalServer,UniSQL,O2,ORACLE,DB2,………...关系模型概述为什么要学习关系模型?73关系模型概述关系数据模型是由E.F.Codd于1970年提出在此之前大多数数据库系统是基于层次数据模型和网状数据模型的关系模型给数据库领域带来了一场革命，并取代了旧的数据模型,E.F.Codd并因此于1983年获得TuringAwards在70年代中期，IBM和UC-Berkeley开发了早期的关系型数据库管理系统关系模型概述关系数据模型是由E.F.Codd于1970年提出74关系模型概述现在的关系型数据库系统有IBM的DB2InformixOracleSybaseMicrosoft的Access,SQLServerFox-xParadox关系模型概述现在的关系型数据库系统有75关系模型概述关系模型是十分简单的关系模型的数据结构非常单一，实体、联系都表示成关系一个关系是一个具有行和列的二维表关系模型给出关系操作的能力，但不对RDBMS语言给出具体的语法要求查询操作：选择、投影、连接、除、并、交、差等更新操作：增加、删除和修改一次一集合关系代数和关系演算高度非过程化关系模型概述关系模型是十分简单的76关系模型概述关系模型的三类完整性约束系统支持：实体完整性和参照完整性用户定义：用户定义的完整性本章主要讨论以下问题关系模型是如何表示数据的关系模型可以表示何种完整性约束数据是如何被查询的如何将由ER模型表示数据库概念模式转换为关系模式(模式)的视图(外模式)问题关系模型概述关系模型的三类完整性约束77关系模型基本概念关系域：一组具有相同数据类型值的集合笛卡尔积：给定一组域D1,D2,…,Dn，它们的笛卡尔积为：D1XD2X…Dn={(d1,d2,…,dn)|di∈Di,i=1,2,…n)元组：每一个元素(d1,d2,…,dn)叫做一个n元组，或元组分量：元素中的每一个值di叫做一个分量基数：若Di为有限集，其基数为mi,则D1XD2X…Dn的基数为：关系模型基本概念关系78关系模型基本概念例如：给定三个域D1=MAN={王兵，李平，张英}，D2=WOMAN={丁梅，吴芳}D3=CHILD={王一，李一，李二}D1XD2XD3={（王兵，丁梅，王一），（王兵，丁梅，李一），（王兵，丁梅，李二），（王兵，吴芳，王一），（王兵，吴芳，李一），…}笛卡尔积可以表示为一个二维表，表中的每一行对应一个元组，每一列对应一个域关系模型基本概念例如：给定三个域D1=MAN={王兵，李平，79关系模型基本概念MANWOMANCHILD王兵丁梅王一王兵丁梅李一王兵丁梅李二王兵吴芳王一王兵吴芳李一王兵吴芳李二李平丁梅王一李平丁梅李一李平丁梅李二李平吴芳王一李平吴芳李一李平吴芳李二MANWOMANCHILD张英丁梅王一张英丁梅李一张英丁梅李二张英吴芳王一张英吴芳李一张英吴芳李二续左表关系模型基本概念MANWOMANCHIL80关系模型基本概念关系:D1XD2X…Dn的子集叫做在域D1,D2,…,Dn上的关系表示为R(D1,D2,…,Dn)关系的目或度：n单元关系：n=1二元关系：n=2关系是一个二维表（子集）例如：假设王兵的妻子是丁梅，他们的孩子是王一，李平的妻子是吴芳，他们的孩子是李一和李二，则取笛卡尔积的一个子集构造一个关系FAMILY关系模型基本概念关系:D1XD2X…Dn的子集叫做在域D181关系模型基本概念在R(D1,D2,…,Dn)表示中，域可以重名，给每列一个名字，称为属性，关系表示为：R(A1,A2,…,An)例如：FAMILY(FATHER,MOTHER,CHILD)MANWOMANCHILD王兵丁梅王一李平吴芳李一李平吴芳李二FAMILY关系模型基本概念在R(D1,D2,…,Dn)表示中，域82关系模型基本概念候选码：能够唯一标识一个元组的最小属性组主码：主属性：候选码中的属性非码属性：不包含在任何候选码中的属性关系的性质：关系模型要求在一个关系中不能存在完全相同的元组(但实际商用关系数据库系统支持重复元组)关系中元组行的序并不重要关系中列的序并不重要（但有些系统例外）关系模型基本概念候选码：能够唯一标识一个元组的最小属性组83关系模型基本概念分量必须取原子值不同的列可以出自同一个域给定域：person={王兵，李平，张英，丁梅，吴芳}child={王义，李一，李二}MANWOMANCHILDfirstsecond王兵丁梅王一李平吴芳李一李二FAMILYbad关系模型基本概念分量必须取原子值MANWOMAN84关系模型基本概念构造FAMILY关系，仍然取personXpersonXchild的子集，表示为：FAMILY(FATHER,MOTHER,CHILD)此处dom(FATHER)=dom(MOTHER)=person关系模式：关系的描述形式化表示：R(U,D,dom,F)，简记为R(U)或R(A1,A2,…,An)属性向域的映象常常说明为属性的类型和长度关系模式是型，关系是值关系模型基本概念构造FAMILY关系，仍然取personX85关系模型基本概念在关系模型中，实体和联系都是用关系表示的例如：左图

学生(学号，姓名，性别，专业，年龄)

课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)一个关系数据库是一组关系的集合；关系数据库模式则是该数据库所有关系模式的集合学生课程选修mn关系模型基本概念在关系模型中，实体和联系都是用关系表示的学生86关系模型--关系的完整性关系模型的完整性是对关系的某种约束实体完整性：主码中的属性不可取空值(例子)参照完整性：例子：对于关系模式学生(学号，姓名，性别，专业，年龄)

课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)外码：设F是关系R的一个或一组属性，但不是关系R的码，如果F与关系S的主码Ks相对应，则称F为关系R的外码关系模型--关系的完整性关系模型的完整性是对关系的某种约束87关系模型--关系的完整性参照关系R，被参照关系S参照完整性：F的取值必须为：或者取空值或者等于S中某个元组的主码值例如：部门(部门号，部门名，电话)

雇员(雇员号，雇员名，职称，部门号)雇员中部门号的取值部门雇员拥有1n关系模型--关系的完整性参照关系R，被参照关系S部门雇员拥有88关系模型--关系的完整性用户定义的完整性：任何关系数据库系统都应支持实体完整性和参照完整性用户定义的完整性定义某一具体应用中所涉及的数据必须满足的语义要求，例如年龄的取值关系数据库系统提供定义和检验这类完整性机制关系模型--关系的完整性用户定义的完整性：89关系模型--关系代数关系代数运算分为：传统的集合运算和专门的关系运算集合运算前提：关系R和关系S具有相同的目，相应的属性取自同一个域并：关系R和关系S的并记作：RS（下页）差：关系R和关系S的差记作：R-S交：关系R和关系S的交记作：RS关系模型--关系代数关系代数运算分为：传统的集合运算和专门的90关系模型--关系代数ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1RSRSRSR-S关系模型--关系代数ABC91关系模型--关系代数R×SABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1RS关系模型--关系代数R×SABC92关系模型--关系代数广义笛卡尔积：两个分别为n和m目的关系R和S的广义笛卡尔积是一个n+m列的元组的集合。若R有k1个元组，S有k2个元组，则广义笛卡尔积有k1×k2个元组记作：R×S关系模型--关系代数广义笛卡尔积：两个分别为n和m目的关系R93关系的建立和修改--SQL-92SQL语言的简单发展历史SQL语言是由IBM公司在SystemR系统中首先提出SQL在1986年被ANSI采纳为标准，称为SQL-86在1989又对SQL标准进行了少量修改，称为SQL-89在1992年ANSI和ISO对SQL标准进行主要修改，称之为SQL-92在1999年又对SQL-92进行大量修改(面向对象的特点)，称之为SQL-3，有时也称为SQL-99关系的建立和修改--SQL-92SQL语言的简单发展历史94关系的建立和修改关系表建立CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL)关系表删除DROPTABLEStudents关系表修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR(10)关系的建立和修改关系表建立95关键字约束--实现实体完整性通过UNIQUE子句来定义候选码(候选关键字)通过PRIMARYKEY子句来定义主码(主关键字)CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE(name,age),UNIQUE(login),PRIMARYKEY(sid))关键字约束--实现实体完整性通过UNIQUE子句来定义候选码96外键约束--实现参照完整性外键约束指的是两个关系之间的关键字约束关系,考虑下列关系Students(sid,name,login,age,gpa)Enrolled(sid,cid,grade)从语义上来讲,在关系Enrolled中出现的sid值,在关系Students中必须存在,Enrolled中的sid称为外键,引用关系Students中的主关键字sid外键必须与被引用关系中的主关键字相匹配可以有不同的名字列数要相同,且要具有兼容的数据类型外键约束--实现参照完整性外键约束指的是两个关系之间的关键字97外键约束----示例外键约束----示例98外键约束的语义在被参照关系中关键字的值在参照关系中不一定出现但在参照关系中出现的关键字值在被参照关系中必须要出现如果我们向关系Enrolled中插入元组<55555,Art104,A>,这个操作将被拒绝因为违反了外键约束外键约束的语义在被参照关系中关键字的值在参照关系中不一定出现99外键约束的语义对于操作:将关系Students中的<53666,Jones,joines@cs,18,3.4>删除,有两种处理禁止这种删除操作同时删除参照关系中的相关元组值得注意的是外键可能来自于同一关系,也就是被参照关系就是参照关系Students(sid,name,login,age,gpa,partner),partner是对sid的一个外键约束Courses(cid,name,desc,preq),preq是对cid的一个外键约束当一门课程没有前期课程时,preq可以为空,空值并不违反外键约束外键约束的语义对于操作:将关系Students中的<5366100外键约束的定义---SQL-92外键约束的定义---SQL-92101逻辑数据库设计：ER到关系的转换实体集到表的转换实体集中的属性映射为表中的属性实体集中的(主)关键字映射为关系中的(主)关键字实体集中属性的域映射为关系中属性的域逻辑数据库设计：ER到关系的转换实体集到表的转换102实体集到表的转换--示例实体集到表的转换--示例103多对多联系集到表的转换多对多联系被映射为一个关系表，包括属性：每个参加联系的实体集的主关键字属性，作为外键存在所有外键构成该实体集的主关键字联系集本身的属性--一般属性多对多联系集到表的转换多对多联系被映射为一个关系表，包括属性104多对多联系集到表的转换--例1mn多对多联系集到表的转换--例1mn105多对多联系集到表的转换--例1多对多联系集到表的转换--例1106多对多联系集到表的转换--例2mnp多对多联系集到表的转换--例2mnp107多对多联系集到表的转换--例2CREATETABLEWork3-In(ssnCHAR(11),didinteger,fromdate,todate,PRIMARYKEY(ssn,did,from,to)FOREIGKEY(ssn)REFERENCESEmployees,ONDELETENOACTION,FOREIGKEY(did)REFERENCESDepartments,FOREIGNKEY(from)REFERENCEDURATION,FOREIGNKEY(to)REFERENCEDURATION)多对多联系集到表的转换--例2CREATETABLEWo108一对多联系集的翻译1n一对多联系集的翻译1n109一对多联系集的翻译----方法一将一对多联系翻译为一个独立的表一对多联系集的翻译----方法一将一对多联系翻译为一个独立110一对多联系集的翻译----方法二将Manages和Departments翻译为一个关系一对多联系集的翻译----方法二将Manages和Depa111关于联系集到关系映射的思考题在一对多联系中，Manages和Departments为什么可以合并为一个关系？对于一对多联系翻译的两种方法的优缺点是什么？对于一个多对多联系集为什么必须映射为一个独立的关系表？一对一联系应如何翻译？关于联系集到关系映射的思考题在一对多联系中，Manages和112思考题部分答案方法一和方法二的优缺点方法一多产生一个关系对于有些查询，方法一需要两次连接，而方法二只需要一次连接即可方法二的缺点是浪费空间，如果有些部门没有经理的话思考题部分答案方法一和方法二的优缺点113具有参加约束的联系集的翻译1nnm具有参加约束的联系集的翻译1nnm114具有参加约束的1:n(1:1)联系集的翻译具有参加约束的1:n(1:1)联系集的翻译115具有参加约束的联系集的翻译ssn的非空定义反映了参加约束使用上面的第一种方法也可以表示Manages和Departments，但使用方法二比方法一好，(why?因为方法二浪费空间的缺点已不复存在)具有参加约束的联系集的翻译ssn的非空定义反映了参加约束116弱实体集的翻译一个弱实体总是参加一个二元一对多联系(?)全参加约束1m弱实体集的翻译一个弱实体总是参加一个二元一对多联系(?)1m117弱实体集的翻译使用具有1:n联系的第二种翻译方法（Why?）,但必须考