数据库教案关系模型.ppt

第三章关系模型-本章内容,基础知识回顾关系模型概述关系模型基本概念关系模型的完整性约束关系代数逻辑数据库设计：ER到关系的转换关系演算,基础知识回顾,数据库发展以数据模型划分第一代网状、层次数据库系统。代表：1969年IBM的IMS(informationManagementSystem);美国CODASYL(ConferenceOnDataSystemLanguage)下属的DBTG（DataBaseTaskGroup）于60年代末70年代初提议的方法。层次数据库是数据库的先驱，而网状数据库是数据库概念、方法、技术的奠基者。第二代关系数据库系统。1970年IBM公司的研究员E.F.Codd提出了数据库的关系模型，关系方法和关系数据理论的研究。代表：IBM的SystemR和Berkele大学的INGRES，成果：奠定了关系模型的理论基础；研究了关系数据库语言，有关系代数、关系演算、SQL语言、QBE等；研制了大量的RDBMS的原型，实现了查询优化、并发控制、故障恢复等关键技术；,基础知识回顾,数据库发展第三代以面向对象数据模型为主要特征的数据库系统。模型更加丰富、数据管理功能功能更加强大、能支持传统数据库难以支持的新的应用。特征：支持数据管理、对象管理和知识管理；保持或者继承第二代数据库的技术；对其他系统开放（支持数据库语言标准和标准网络协议）。仅支持面向对象数据模型并不能称为第三代数据库系统。,基础知识回顾,关系数据库系统关系数据库系统。产品的发展情况：(1)对关系模型的支持：第一阶段（70年代）：仅支持关系数据结构、基本的关系操作（选择、投影、连接）。如：dBASE第二阶段（80年代)：SQL成为关系数据库语言的国际标准第三阶段（90年代）：加强了完整性、安全性的支持。(2)运行环境：第一阶段：在大、中、小型机上的RDBMS，多用户系统第二阶段：提高可移植性，能在多种硬件平台、和操作系统环境下运行；联网，向分布式发展，支持多种协议。第三阶段：分布式数据库和客户/服务器结构的数据库系统的推出。追求开放性（可移植性、可连接性、可伸缩性）。,基础知识回顾,关系数据库系统关系数据库系统。产品的发展情况：(3)RDBMS系统构成：第一阶段：早期的RDBMS产品主要提供数据定义、数据存取、数据控制等基本操作和数据存储组织、并发控制、安全性、完整性检查、系统恢复等RDBMS的核心功能。第二阶段：以RDBMS基本功能为核心，开发外围软件系统，如：FORM报表生成系统，REPORT报表系统、MENU菜单生成系统、GRAPHIC图形软件等等。为用户提供了良好的第四代应用开发环境。(4)对应用的支持：第一阶段：用于信息管理、辅助决策等应用领域。第二阶段：联机事务处理的应用领域，提高RDBMS事务处理的能力。第三阶段：由集中到分布，由局部到整个企业甚至整个行业。支持整个企业的联机事务处理。,关系模型概述,为什么要学习关系模型?关系模型是目前广泛使用的一种数据模型IBMDB2,MiscrosoftSQLServer,Informix,Oracle,Sybase,.仅有少量的遗产系统使用旧的数据模型IBM的IMS目前仍在使用目前关系模型的竞争者:面向对象的数据模型Objectstore,Versant,Ontos,.对象关系模型:InformixUniversalServer,UniSQL,O2,ORACLE,DB2,.,关系模型概述,关系数据模型是由E.F.Codd于1970年提出在此之前大多数数据库系统是基于层次数据模型和网状数据模型的关系模型给数据库领域带来了一场革命，并取代了旧的数据模型,E.F.Codd并因此于1983年获得TuringAwards在70年代中期，IBM和UC-Berkeley开发了早期的关系型数据库管理系统,关系模型概述,现在的关系型数据库系统有IBM的DB2InformixOracleSybaseMicrosoft的Access,SQLServerFox-xParadox,关系模型概述,关系模型是十分简单的关系模型的数据结构非常单一，实体、联系都表示成关系一个关系是一个具有行和列的二维表关系模型给出关系操作的能力，但不对RDBMS语言给出具体的语法要求查询操作：选择、投影、连接、除、并、交、差等更新操作：增加、删除和修改一次一集合关系代数和关系演算高度非过程化,关系模型概述,关系模型的三类完整性约束系统支持：实体完整性和参照完整性用户定义：用户定义的完整性本章主要讨论以下问题关系模型是如何表示数据的关系模型可以表示何种完整性约束数据是如何被查询的如何将由ER模型表示数据库概念模式转换为关系模式(模式)的视图(外模式)问题,关系模型基本概念,关系域：一组具有相同数据类型值的集合笛卡尔积：给定一组域D1,D2,Dn，它们的笛卡尔积为：D1XD2XDn=(d1,d2,dn)|diDi,i=1,2,n)元组：每一个元素(d1,d2,dn)叫做一个n元组，或元组分量：元素中的每一个值di叫做一个分量基数：若Di为有限集，其基数为mi,则D1XD2XDn的基数为：,关系模型基本概念,例如：给定三个域D1=MAN=王兵，李平，张英，D2=WOMAN=丁梅，吴芳D3=CHILD=王一，李一，李二D1XD2XD3=（王兵，丁梅，王一），（王兵，丁梅，李一），（王兵，丁梅，李二），（王兵，吴芳，王一），（王兵，吴芳，李一），笛卡尔积可以表示为一个二维表，表中的每一行对应一个元组，每一列对应一个域,关系模型基本概念,MANWOMANCHILD王兵丁梅王一王兵丁梅李一王兵丁梅李二王兵吴芳王一王兵吴芳李一王兵吴芳李二李平丁梅王一李平丁梅李一李平丁梅李二李平吴芳王一李平吴芳李一李平吴芳李二,MANWOMANCHILD张英丁梅王一张英丁梅李一张英丁梅李二张英吴芳王一张英吴芳李一张英吴芳李二,续左表,关系模型基本概念,关系:D1XD2XDn的子集叫做在域D1,D2,Dn上的关系表示为R(D1,D2,Dn)关系的目或度：n单元关系：n=1二元关系：n=2关系是一个二维表（子集）例如：假设王兵的妻子是丁梅，他们的孩子是王一，李平的妻子是吴芳，他们的孩子是李一和李二，则取笛卡尔积的一个子集构造一个关系FAMILY,关系模型基本概念,在R(D1,D2,Dn)表示中，域可以重名，给每列一个名字，称为属性，关系表示为：R(A1,A2,An)例如：FAMILY(FATHER,MOTHER,CHILD),MANWOMANCHILD王兵丁梅王一李平吴芳李一李平吴芳李二,FAMILY,关系模型基本概念,候选码：能够唯一标识一个元组的最小属性组主码：主属性：候选码中的属性非码属性：不包含在任何候选码中的属性关系的性质：关系模型要求在一个关系中不能存在完全相同的元组(但实际商用关系数据库系统支持重复元组)关系中元组行的序并不重要关系中列的序并不重要（但有些系统例外）,关系模型基本概念,分量必须取原子值不同的列可以出自同一个域给定域：person=王兵，李平，张英，丁梅，吴芳child=王义，李一，李二,MANWOMANCHILDfirstsecond王兵丁梅王一李平吴芳李一李二,FAMILY,bad,关系模型基本概念,构造FAMILY关系，仍然取personXpersonXchild的子集，表示为：FAMILY(FATHER,MOTHER,CHILD)此处dom(FATHER)=dom(MOTHER)=person关系模式：关系的描述形式化表示：R(U,D,dom,F)，简记为R(U)或R(A1,A2,An)属性向域的映象常常说明为属性的类型和长度关系模式是型，关系是值,关系模型基本概念,在关系模型中，实体和联系都是用关系表示的例如：左图学生(学号，姓名，性别，专业，年龄)课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)一个关系数据库是一组关系的集合；关系数据库模式则是该数据库所有关系模式的集合,学生,课程,选修,m,n,关系模型-关系的完整性,关系模型的完整性是对关系的某种约束实体完整性：主码中的属性不可取空值(例子)参照完整性：例子：对于关系模式学生(学号，姓名，性别，专业，年龄)课程(课程号，课程名，学时，学分)选修(学号，课程号，成绩)外码：设F是关系R的一个或一组属性，但不是关系R的码，如果F与关系S的主码Ks相对应，则称F为关系R的外码,关系模型-关系的完整性,参照关系R，被参照关系S参照完整性：F的取值必须为：或者取空值或者等于S中某个元组的主码值例如：部门(部门号，部门名，电话)雇员(雇员号，雇员名，职称，部门号)雇员中部门号的取值,部门,雇员,拥有,1,n,关系模型-关系的完整性,用户定义的完整性：任何关系数据库系统都应支持实体完整性和参照完整性用户定义的完整性定义某一具体应用中所涉及的数据必须满足的语义要求，例如年龄的取值关系数据库系统提供定义和检验这类完整性机制,关系模型-关系代数,关系代数运算分为：传统的集合运算和专门的关系运算集合运算前提：关系R和关系S具有相同的目，相应的属性取自同一个域并：关系R和关系S的并记作：RS（下页）差：关系R和关系S的差记作：R-S交：关系R和关系S的交记作：RS,关系模型-关系代数,ABCABCABCa1b1c1a1b2c2a1b1c1a1b2c2a1b3c2a1b2c2a2b2c1a2b2c1a2b2c1a1b3c2ABCABCa1b2c2a1b1c1a2b2c1,R,S,RS,RS,R-S,关系模型-关系代数,RS,ABCABCABCa1b1c1a1b1c1a1b2c2a1b2c2a1b1c1a1b3c2a2b2c1a1b1c1a2b2c1a1b2c2a1b2c2ABCa1b2c2a1b3c2a1b2c2a1b2c2a2b2c1a1b3c2a2b2c1a1b2c2a2b2c1a2b2c1a1b3c2a2b2c1a2b2c1,R,S,关系模型-关系代数,广义笛卡尔积：两个分别为n和m目的关系R和S的广义笛卡尔积是一个n+m列的元组的集合。若R有k1个元组，S有k2个元组，则广义笛卡尔积有k1k2个元组记作：RS,关系的建立和修改-SQL-92,SQL语言的简单发展历史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,关系的建立和修改,关系表建立CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL)关系表删除DROPTABLEStudents关系表修改ALTERTABLEStudentsADDCOLUMNmaiden-nameCHAR(10),关键字约束-实现实体完整性,通过UNIQUE子句来定义候选码(候选关键字)通过PRIMARYKEY子句来定义主码(主关键字)CREATETABLEStudents(sidCHAR(20),nameCHAR(30),loginCHAR(20),ageINTEGER,gpaREAL,UNIQUE(name,age),UNIQUE(login),PRIMARYKEY(sid),外键约束-实现参照完整性,外键约束指的是两个关系之间的关键字约束关系,考虑下列关系Students(sid,name,login,age,gpa)Enrolled(sid,cid,grade)从语义上来讲,在关系Enrolled中出现的sid值,在关系Students中必须存在,Enrolled中的sid称为外键,引用关系Students中的主关键字sid外键必须与被引用关系中的主关键字相匹配可以有不同的名字列数要相同,且要具有兼容的数据类型,外键约束-示例,外键约束的语义,在被参照关系中关键字的值在参照关系中不一定出现但在参照关系中出现的关键字值在被参照关系中必须要出现如果我们向关系Enrolled中插入元组,这个操作将被拒绝因为违反了外键约束,外键约束的语义,对于操作:将关系Students中的删除,有两种处理禁止这种删除操作同时删除参照关系中的相关元组值得注意的是外键可能来自于同一关系,也就是被参照关系就是参照关系Students(sid,name,login,age,gpa,partner),partner是对sid的一个外键约束Courses(cid,name,desc,preq),preq是对cid的一个外键约束当一门课程没有前期课程时,preq可以为空,空值并不违反外键约束,外键约束的定义-SQL-92,逻辑数据库设计：ER到关系的转换,实体集到表的转换实体集中的属性映射为表中的属性实体集中的(主)关键字映射为关系中的(主)关键字实体集中属性的域映射为关系中属性的域,实体集到表的转换-示例,多对多联系集到表的转换,多对多联系被映射为一个关系表，包括属性：每个参加联系的实体集的主关键字属性，作为外键存在所有外键构成该实体集的主关键字联系集本身的属性-一般属性,多对多联系集到表的转换-例1,m,n,多对多联系集到表的转换-例1,多对多联系集到表的转换-例2,m,n,p,多对多联系集到表的转换-例2,CREATETABLEWork3-In(ssnCHAR(11),didinteger,fromdate,todate,PRIMARYKEY(ssn,did,from,to)FOREIGKEY(ssn)REFERENCESEmployees,ONDELETENOACTION,FOREIGKEY(did)REFERENCESDepartments,FOREIGNKEY(from)REFERENCEDURATION,FOREIGNKEY(to)REFERENCEDURATION),一对多联系集的翻译,1,n,一对多联系集的翻译-方法一,将一对多联系翻译为一个独立的表,一对多联系集的翻译-方法二,将Manages和Departments翻译为一个关系,关于联系集到关系映射的思考题,在一对多联系中，Manages和Departments为什么可以合并为一个关系？对于一对多联系翻译的两种方法的优缺点是什么？对于一个多对多联系集为什么必须映射为一个独立的关系表？一对一联系应如何翻译？,思考题部分答案,方法一和方法二的优缺点方法一多产生一个关系对于有些查询，方法一需要两次连接，而方法二只需要一次连接即可方法二的缺点是浪费空间，如果有些部门没有经理的话,具有参加约束的联系集的翻译,1,n,n,m,具有参加约束的1:n(1:1)联系集的翻译,具有参加约束的联系集的翻译,ssn的非空定义反映了参加约束使用上面的第一种方法也可以表示Manages和Departments，但使用方法二比方法一好，(why?因为方法二浪费空间的缺点已不复存在),弱实体集的翻译,一个弱实体总是参加一个二元一对多联系(?)全参加约束,1,m,弱实体集的翻译,使用具有1:n联系的第二种翻译方法（Why?）,但必须考虑下面的具体要求必须考虑弱实体集有一个部分关键字当一个Owner实体被删除以后,弱实体集中相应的实体也应被删除,弱实体集的翻译,类层次的翻译,类层次的翻译-方法一,三个实体集翻译成三个关系实体集Employees的翻译比较简单关系Hourly_Emps的属性包括:ssn,hourly_wages,hours_worked,;ssn是主关键字;同时ssn一个外键;当超类中实体被删除时子类中的对象也必须删除Contract_Emps的翻译相类似思考题：为什么在关系Hourly_Emps的属性中不包含属性name和lot?体现继承性了吗？,类层次的翻译-方法一,CREATETABLEHourly_Emps(ssnCHAR(20),hourly_wagesREAL,hours_workedINTEGER,PRIMARYKEY(ssn),FOREIGKEY(ssn)REFERENCESEmployees,ONDELETECASCADE),类层次的翻译-方法二,三个实体集翻译成两个关系仅生成两个关系:Hourly_Emps和Contract_Emps,他们都包含超类Employees的属性,除了主关键字约束以外,不需要定义任何约束当然，对于overlap约束只能用通用约束机制来实现对于方法一来讲，covering约束也只能用通用约束机制来实现,类层次的翻译-两种方法的比较,方法一:当查询涉及到Employees的属性和其它一些细节属性时需要连接操作;当查询仅涉及到Employees的属性时则在Employees关系上进行即可;另一个优点是可以存储非Hourly_Emps和Contract_Emps的实体方法二:主要确定无法存储非Hourly_Emps和Contract_Emps的实体,且name和lot出现了两次;优点是仅涉及到Hourly_Emps或Contract_Emps的查询仅在一个关系上进行即可,不需要额外的连接操作,但涉及到所有雇员的查询则需要在两个关系上进行;,实例分析,一个公司数据库需要存储雇员、部门和雇员小孩的信息。雇员工作在部门(一个雇员只能工作在一个部门)，每个部门由一个雇员管理，每个雇员小孩的名字是唯一的，假定小孩只有一个家长工作在这个公司，而且我们不关心哪些已经调离雇员的小孩情况。请画出ER图扑获这些信息。雇员(ssn,salary,phone)部门(dno,dname