第三章_数据库教案关系模型(1)

第三章 关系模型-本章内容,基础知识回顾 关系模型概述 关系模型基本概念 关系模型的完整性约束 关系代数 逻辑数据库设计：ER到关系的转换 关系演算,基础知识回顾,数据库发展 以数据模型划分 第一代 网状、层次数据库系统。代表：1969年IBM的IMS(information Management System) ;美国 CODASYL(Conference On Data System Language)下属的 DBTG（Data Base Task Group）于60年代末70年代初提议的方法。层次数据库是数据库的先驱，而网状数据库是数据库概念、方法、技术的奠基者。 第二代 关系数据库系统。1970年IBM公司的研究员E.F.Codd提出了数据库的关系模型，关系方法和关系数据理论的研究。代表：IBM的System R 和Berkele大学的INGRES，成果：奠定了关系模型的理论基础；研究了关系数据库语言，有关系代数、关系演算、SQL语言、QBE等；研制了大量的RDBMS的原型，实现了查询优化、并发控制、故障恢复等关键技术；,基础知识回顾,数据库发展 第三代 以面向对象数据模型为主要特征的数据库系统。 模型更加丰富、数据管理功能功能更加强大、能支持传统数据库难以支持的新的应用。 特征：支持数据管理、对象管理和知识管理；保持或者继承第二代数据库的技术；对其他系统开放（支持数据库语言标准和标准网络协议）。 仅支持面向对象数据模型并不能称为第三代数据库系统。,基础知识回顾,关系数据库系统 关系数据库系统。产品的发展情况： (1)对关系模型的支持： 第一阶段（70年代）：仅支持关系数据结构、基本的关系操作（选择、投影、连接）。如：dBASE 第二阶段（80年代)：SQL成为关系数据库语言的国际标准 第三阶段（90年代）：加强了完整性、安全性的支持。 (2)运行环境： 第一阶段：在大、中、小型机上的RDBMS，多用户系统 第二阶段：提高可移植性，能在多种硬件平台、和操作系统环境下运行；联网，向分布式发展，支持多种协议。 第三阶段： 分布式数据库和客户/服务器结构的数据库系统的推出。追求开放性（可移植性、可连接性、可伸缩性）。,基础知识回顾,关系数据库系统 关系数据库系统。产品的发展情况： (3)RDBMS系统构成： 第一阶段：早期的RDBMS产品主要提供数据定义、数据存取、数据控制等基本操作和数据存储组织、并发控制、安全性、完整性检查、系统恢复等RDBMS的核心功能。 第二阶段：以RDBMS基本功能为核心，开发外围软件系统，如：FORM报表生成系统，REPORT报表系统、MENU菜单生成系统、GRAPHIC图形软件等等。为用户提供了良好的第四代应用开发环境。 (4)对应用的支持： 第一阶段：用于信息管理、辅助决策等应用领域。 第二阶段：联机事务处理的应用领域，提高RDBMS事务处理的能力。 第三阶段：由集中到分布，由局部到整个企业甚至整个行业。支持整个企业的联机事务处理。,关系模型概述,为什么要学习关系模型? 关系模型是目前广泛使用的一种数据模型 IBM DB2, Miscrosoft SQL Server, Informix, Oracle, Sybase, . 仅有少量的遗产系统使用旧的数据模型 IBM的IMS目前仍在使用 目前关系模型的竞争者:面向对象的数据模型 Objectstore, Versant, Ontos, . 对象关系模型: Informix Universal Server, UniSQL, O2, ORACLE, DB2, .,关系模型概述,关系数据模型是由E.F.Codd于1970年提出 在此之前大多数数据库系统是基于层次数据模型和网状数据模型的 关系模型给数据库领域带来了一场革命，并取代了旧的数据模型, E.F.Codd并因此于1983年获得Turing Awards 在70年代中期，IBM和UC-Berkeley开发了早期的关系型数据库管理系统,关系模型概述,现在的关系型数据库系统有 IBM的DB2 Informix Oracle Sybase Microsoft的Access, SQL Server Fox-x Paradox,关系模型概述,关系模型是十分简单的 关系模型的数据结构非常单一，实体、联系都表示成关系 一个关系是一个具有行和列的二维表 关系模型给出关系操作的能力，但不对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=（王兵，丁梅，王一）， （王兵，丁梅，李一）， （王兵，丁梅，李二）， （王兵，吴芳，王一）， （王兵，吴芳，李一）， 笛卡尔积可以表示为一个二维表，表中的每一行对应一个元组，每一列对应一个域,关系模型基本概念,MAN WOMAN CHILD 王兵 丁梅 王一 王兵 丁梅 李一 王兵 丁梅 李二 王兵 吴芳 王一 王兵 吴芳 李一 王兵 吴芳 李二 李平 丁梅 王一 李平 丁梅 李一 李平 丁梅 李二 李平 吴芳 王一 李平 吴芳 李一 李平 吴芳 李二,MAN WOMAN CHILD 张英 丁梅 王一 张英 丁梅 李一 张英 丁梅 李二 张英 吴芳 王一 张英 吴芳 李一 张英 吴芳 李二,续左表,关系模型基本概念,关系: 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),MAN WOMAN CHILD 王兵 丁梅 王一 李平 吴芳 李一 李平 吴芳 李二,FAMILY,关系模型基本概念,候选码：能够唯一标识一个元组的最小属性组 主码： 主属性：候选码中的属性 非码属性：不包含在任何候选码中的属性 关系的性质： 关系模型要求在一个关系中不能存在完全相同的元组(但实际商用关系数据库系统支持重复元组) 关系中元组行的序并不重要 关系中列的序并不重要（但有些系统例外）,关系模型基本概念,分量必须取原子值 不同的列可以出自同一个域 给定域：person=王兵，李平，张英，丁梅，吴芳 child=王义，李一，李二,MAN WOMAN CHILD first second 王兵 丁梅 王一 李平 吴芳 李一 李二,FAMILY,bad,关系模型基本概念,构造FAMILY关系，仍然取person X person X child的子集，表示为：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,关系模型-关系代数,A B C A B C A B C a1 b1 c1 a1 b2 c2 a1 b1 c1 a1 b2 c2 a1 b3 c2 a1 b2 c2 a2 b2 c1 a2 b2 c1 a2 b2 c1 a1 b3 c2 A B C A B C a1 b2 c2 a1 b1 c1 a2 b2 c1,R,S,RS,RS,R-S,关系模型-关系代数,RS,A B C A B C A B C a1 b1 c1 a1 b1 c1 a1 b2 c2 a1 b2 c2 a1 b1 c1 a1 b3 c2 a2 b2 c1 a1 b1 c1 a2 b2 c1 a1 b2 c2 a1 b2 c2 A B C a1 b2 c2 a1 b3 c2 a1 b2 c2 a1 b2 c2 a2 b2 c1 a1 b3 c2 a2 b2 c1 a1 b2 c2 a2 b2 c1 a2 b2 c1 a1 b3 c2 a2 b2 c1 a2 b2 c1,R,S,关系模型-关系代数,广义笛卡尔积：两个分别为n和m目的关系R和S的广义笛卡尔积是一个n+m列的元组的集合。若R有k1个元组，S有k2个元组，则广义笛卡尔积有k1k2个元组 记作：R S,关系的建立和修改-SQL-92,SQL语言的简单发展历史 SQL语言是由IBM公司在System R系统中首先提出 SQL在1986年被ANSI采纳为标准，称为SQL-86 在1989又对SQL标准进行了少量修改，称为SQL-89 在1992年ANSI和ISO对SQL标准进行主要修改，称之为SQL-92 在1999年又对SQL-92进行大量修改(面向对象的特点)，称之为SQL-3，有时也称为SQL-99,关系的建立和修改,关系表建立 CREATE TABLE Students( sid CHAR(20), name CHAR(30), login CHAR(20), age INTEGER, gpa REAL) 关系表删除 DROP TABLE Students 关系表修改 ALTER TABLE Students ADD COLUMN maiden-name CHAR(10),关键字约束-实现实体完整性,通过UNIQUE子句来定义候选码(候选关键字) 通过PRIMARY KEY子句来定义主码(主关键字) CREATE TABLE Students( sid CHAR(20), name CHAR(30), login CHAR(20), age INTEGER,gpa REAL, UNIQUE (name, age), UNIQUE ( login ), PRIMARY KEY (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,CREATE TABLE Work3-In( ssn CHAR(11), did integer, from date, to date, PRIMARY KEY(ssn, did, from, to) FOREIG KEY (ssn) REFERENCES Employees, ON DELETE NO ACTION, FOREIG KEY (did) REFERENCES Departments, FOREIGN KEY (from) REFERENCE DURATION, FOREIGN KEY (to) REFERENCE DURATION),一对多联系集的翻译,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? 体现继承性了吗？,类层次的翻译 -方法一,CREATE TABLE Hourly_Emps ( ssn CHAR(20), hourly_wages REAL, hours_worked INTEGER, PRIMARY KEY(ssn), FOREIG KEY (ssn) REFERENCES Employees, ON DELETE CASCADE ),类层次的翻译 -方法二,三个实体集翻译成两个关系 仅生成两个关系: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图