第05章 数据库设计与ER模型

《第05章 数据库设计与ER模型》由会员分享，可在线阅读，更多相关《第05章 数据库设计与ER模型（119页珍藏版）》请在装配图网上搜索。

1、,,,,,,,单击此处编辑母版标题样式,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,,*,第五章 数据库设计和,ER,模型,,,,,数据库系统,2010,年,,本章重要概念,,（,1,）,DBS,生存期及其,7,个阶段的任务和工作。,,（,2,）概念设计的重要性、主要步骤。逻辑设计阶段的主要步骤。,,（,3,）,ER,模型的基本元素，属性的分类，联系的元数、映射基数。采用,ER,方法的概念设计步骤。,,（,4,）,ER,模型到关系模型的转换规则。采用,ER,方法的逻辑设计步骤。,,（,5,）,ER,模型的扩充：弱实体，超类和子类。,,,主要内容和学习要求,数据库设

2、计的全过程（领会）,,,ER,模型 （综合应用）,,,ER,模型到关系模型的转换 （综合应用）,,ER,模型实例分析 （理解）,,增强的,ER,模型（理解）,,5.1,数据库设计的全过程,什么是数据库设计,,数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）,,在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。,,数据库与信息系统,数据库是信息系统的核心和基础,,把信息系统中大量的数据按一定的模型组织起来,,提供存储、维护、检索数据的功能,,使信息系统可以方便、及时、准确地从数据

3、库中获得所需的信息,,数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在,,数据库设计是信息系统开发和建设的重要组成部分,,软件危机,软件危机,,,20,世纪,60,年代中后期，由于软件规模的扩大，复杂性的增加，导致了“软件危机”，表现在：,,缺乏科学的指导原则和管理方法,,开发工作不能按时完成,,软件产品质量低劣，达不到规定的要求,,由于软件产品质量低劣，维护任务繁重,,软件开发费用超出预算，应用部门与开发部门无法负担。,,软件工程,软件工程,,为了解决“软件危机”，在,1968,年首次提出“软件工程”的概念。,人们认为，应该用科学知识、工程方面的纪律指导软件开发的过程，以

4、提高软件质量和开发效率，降低开发成本 。,,,数据库系统生存期,软件生存期,,从软件的规划、研制、实现、投入运行后的维护，直到它被新的软件所取代而停止使用的整个期间,。,,数据库工程,,,数据库应用系统的开发是一项软件工程，但又有自己特有的特点，,,所以特称为“数据库工程”。,,数据库系统生存期,,数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间,。,,隶属关系,,规划,需求分析,系统设计,,程序编制,,调试,,运行维护,,运行和维护,,实现,,物理设计,逻辑设计,概念设计,需求分析,规划,软件生存期,数据库生存期,,,数据库设计的输入,数据库设计的输入,,总

5、体信息需求：数据库系统的目标说明、数据元素的定义、数据在企业组织中的使用描述。,,处理需求：每个应用需要的数据项、数据量以及应用执行的效率。,,DBMS,的特征：,DBMS,所支持的模式、子模式和程序语法的规则。,,硬件和,OS,特征：对,DBMS,和,OS,访问方法特有的内容，例如物理设备容量限制、时间特性及运行要求。,,数据库设计的输出,数据库设计的输出,,说明书：说明数据库的完整结构和基于数据库结构和处理需求的应用程序的设计原则。,,处理需求,DBMS,特征,总体信息需求,第,5,步,,物理设计,第,3,步,,概念设计,第,4,步,,逻辑设计,第,1,步,,规划,第,2,步,,需求描述和

6、分析,硬件和,,OS,特征,,物理数据库结构,,需求说明书,,信息结构（独立于,,硬件、软件,）,逻辑数据库结构,,（,DBMS,能处理的）,,应用程序说明书,数据库设计的输入输出,,规划阶段的目标,得到详尽的可行性分析报告和数据库系统规划纲要，内容包括：信息范围；信息来源；人力资源；设备资源；软件及支持工具资源；开发成本估算；开发进度计划；现行系统向新系统过渡计划等。,,规划阶段的三个步骤,系统调查：,,对企业组织作全面的调查，画出,组织层次图,，以了解企业的组织结构,,可行性分析,,从技术、经济、效益、法律等诸方面对建立数据库的可行性进行分析；写出,可行性分析报告,；组织专家讨论其可行性,

7、,确定,数据库系统的总目标,和制定,项目开发计划,,组织层次图,,医院,病区,药房,中,,药房,西,,药房,急诊,,药房,药库,中,,药,,库,西,,药,,库,出入院处,,功检科室,财务科,,需求分析的目标,对系统的整个应用情况作全面的、详细的调查，确定企业组织的目标，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户的需求，并把这些要求写成用户和数据库设计者都能够接受的文档。,,需求分析工作,分析用户活动产生，产生,业务流程图,,了解用户当前的业务活动和职能，搞清其处理流程（即业务流程）,,确定系统范围，产生,系统关联图,,,确定计算机所能进行的数据处理的范围，确定哪些工作由人工

8、完成，哪些工作由计算机系统完成。,,需求分析工作,分析用户活动涉及的数据，产生,数据流图,,,深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。,,分析系统数据，产生,数据字典,,,数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果，通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。,,业务流程图,,预交金单据,结算单,预交金处理,入区登记,出院结算,病人入院信息,入院处,病人,,护士,医生,医嘱信息,退药申请单,项目执行单,功检科,医嘱执行,药房,诊断,入院登记,病人确费,退药信息,发药信息,发药申请单,退药处理,发药处理

9、,入库申请,退药申请,,顶层数据流图,,F5,F1,F5,1,,出入院管理,D4,费用明细,D1,病人入院信息,D5,病人入区信息,F4,出入院处,2,,病区管理,3,,药房管理,D9,发药信息,D10,退药申请,D11,退药信息,F8 F9 F10 F11,F8 F9 F10

10、 F11,D8,发药申请,F5,F1,F4,F1,F1,,数据字典,,数 据 流,,系统名：医院管理信息系统 编号：,F8,,条目名：发药申请单 别名：,,来源：病区系统,,去处：药房系统,,数据流结构：请求序号、住院号、患者姓名、医嘱序号、药房代码、病区代码、科室代码、医生代码、请求日期、药品代码、药品数量、药品规格、药品单位、单价、请求类型,,,简要说明：病区执行医嘱后产生发药申请单，药房再按照申请单发

11、药,,修改记录,,编 写：,,张三,日 期：,,2004,．,5,,审 核,：,,李四,,日 期：,,2004,．,5,,,概念设计,,什么是概念结构设计,,需求分析阶段描述的用户应用需求是现实世界的具体需求,,将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计,,概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。,,概念结构设计是整个数据库设计的关键,,概念设计的目标,,,产生反映企业组织信息需求的数据库概念结构，即概念模式。,,概念设计的重要性,为什么需要概念设计？,,（,1,）将概念设计从设计过程中独立出来，可以使数据库

12、设计各阶段的任务相对单一化，降低数据库设计的复杂程度，便于组织管理。,,（,2,）概念设计能充分反映现实世界中实体间的联系，不依赖于具体,DBMS,的模式，设计结果容易适应外界环境的变化。,,概念设计的重要性,（,3,）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。,,（,4,）易于向关系模型转换。,,概念设计的主要步骤,进行数据抽象，设计局部概念模式,,将局部概念模式综合成,全局概念模式,,评审,,描述概念模型的工具,E-R,模型,,逻辑设计的目标,,把概念设计阶段设计好的全局概念模式转换成与选用的具体机器上的,DBMS,所支持的数据模型相符合的

13、逻辑结构（包括数据库模式和外模式）。这些模式在功能上、完整性和一致性约束及数据库的可扩充性等方面均应满足用户的各种要求。,,逻辑设计的主要步骤,把概念模型转换成逻辑模型,,设计外模型,,设计应用程序与数据库的接口,,评价模型,,修正模型,,,物理设计,为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。,,数据库的存储记录格式、存储记录安排和存取方法称为数据库的物理结构。它依赖于给定的计算机系统。,,物理设计的步骤,存储记录结构设计,（包括记录的组成、数据项的类型、长度，以及逻辑记录到存储记录的映射。）,,确定数据存放位置,,,存取方法的设计,（主键检索和辅助

14、键检索）,,完整性和安全性考虑,,,程序设计,,数据库的实现,用,DDL,定义数据库结构,,数据装载,,对数据量不大的小型系统（人工）,,主要工作：筛选数据；转换数据格式；输入数据；校验数据。,,对大中型系统（自动，即设计一个数据输入子系统，由计算机辅助数据的入库工作）,,主要工作：筛选数据；输入数据；校验数据；转换数据；综合数据。,,数据库的实现,编制与调试应用程序；,,数据库试运行。,,功能测试,,性能测试（时空代价）,,数据库的运行与维护,,数据库的转储和恢复,,,转储和恢复是系统正式运行后最重要的维护工作之一。,,DBA,要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进

15、行备份。,,一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。,,数据库的运行与维护,数据库安全性、完整性控制,,,DBA,必须根据用户的实际需要授予不同的操作权限。,,在数据库运行过程中，由于应用环境的变化，对安全性的要求也会发生变化，,DBA,需要根据实际情况修改原有的安全性控制。,,由于应用环境的变化，数据库的完整性约束条件也会变化，也需要,DBA,不断修正，以满足用户要求。,,数据库的运行与维护,数据库性能的监督、分析和改进,,在数据库运行过程中，,DBA,必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。,,利用监测工具获取系统运行过程中

16、一系列性能参数的值。,,通过仔细分析这些数据，判断当前系统是否处于最佳运行状态。,,如果不是，则需要通过调整某些参数来进一步改进数据库性能。,,数据库的运行与维护,数据库的重组织和重构造,,1,）数据库的重组织,,,数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。为提高系统性能，需重组织数据库。,,,数据库的运行与维护,数据库的重组织不会改变原设计的数据逻辑结构和物理结构。,,DBMS,一般都提供了供重组织数据库使用的实用程序，帮助,DBA,重新组织数据库。,,数据库的运行与维护,2,）数据库的重构造

17、,,数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求,,数据库重构造的主要工作是根据新环境调整数据库的模式和内模式,,,数据库的运行与维护,重构造数据库的程度是有限的。若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库系统，开始新数据库应用系统的生命周期了。,,5.2 ER,模型,ER,模型的基本元素,,实体,,联系,,属性,实体,联系,属性,ER,模型图例,老,,师,学,,生,教,m,n,学号,姓名,专业,班级,职称,性别,姓名,职号,,实体

18、,实体,是一个数据对象，指应用中可以区别的客观存在的事物。同一类实体构成,实体集,。,实体类型,是对实体集中实体的定义。由于实体、实体集、实体类型等概念的区分在转换成数据库的逻辑设计时才要考虑，因此在不引起混淆的情况下，一般将实体、实体集、实体类型等概念统称为实体。,ER,模型中提到的实体往往是指实体集。,,联系,联系,表示一个或多个实体之间的关联关系。同一类联系构成“,联系集,”。,联系类型,是对联系集中联系的定义。同实体一样，一般将联系、联系集、联系类型等统称为联系。,,属性,实体的某一特性称为,属性,。在一个实体中，能够唯一标识实体的属性或属性集称为“,实体标识符,”。一个实体只有一个实

19、体标识符，没有候选标识符的概念。实体标识符有时也称为实体的主键。,,联系也用属性描述其特征，但联系本身没有标识符。,,,属性的分类,根据属性类型可分为简单属性和复合属性,,简单属性,是不可再分割的属性,,例如：性别、年龄,,复合属性,是可以再分解为其他属性的属性,,,例如：地址属性可分解为邮政编码、省（市）名、区名、街道四个子属性。,,复合属性形成了属性的层次结构。,,属性的分类,图,5.2,地址属性的层次结构,邮政编码,省,（市）名,地 址,区 名,街 道,家庭地址,门牌号码,,,属性的分类,根据属性的取值特点分为单值属性和多值属性,,单值属性,指的是同一实体的属性只能取一个值,,例如：同一

20、个学生只能有一个年龄,,多值属性,只的是同一实体的某些属性可能取多个值,,,例如：一个教师的学位是一个多值属性（学士、硕士和博士）。一种商品可能有多种销售价格（经销、代销、批发和零售）。,,多值属性用双线椭圆形表示。,,,,属性的分类,图,5.3,多值属性的表示,,零件编码,零 件,零件名,供应商,,规格,进货价格,销售价格,零件编码,,属性的分类,在数据库的实施过程中，应修改原来的,ER,模型，对多值属性进行变换。,,将原来的多值属性用几个新的单值属性来表示,,例如：商品销售价格可结合销售性质（经销、代销、批发和零售）进行分解。,,将原来的多值属性用一个新的实体类型表示。这个新实体类型和原来

21、的实体类型是,1:N,联系。这个新实体依赖于原实体而存在，因此称之为,弱实体,。,,弱实体用双线矩形框表示。,,,,,5.3.2,属性的分类,,图,5.4,多值属性的变换（,1,）,零件编码,零 件,零件名,供应商,,规格,进货价格,经销价格,,代销价格,批发价格,零售价格,,,属性的分类,图,5.5,多值属性的变换（,2,）,零件编码,零 件,零件名,供应商,,规格,进货价格,销售性质,售货价格,,存在,销售价格,1,N,,,属性的分类,通过具有相互依赖的属性推导而产生的属性称为,派生属性,。派生属性的值不必存储在数据库内，而其他需要存储值的属性称为,存储属性,。,,例如：实发工资可从基本

22、工资、奖金、房租等属性推导出来。,,派生属性的值不仅可以从其他属性导出，也可以从有关的实体导出，,,派生属性用虚线椭圆形与实体相连。,,5.3.2,属性的分类,,图,5.6,派生属性的表示,工号,职 工,姓名,基本工资,,奖金,房租,实发工资,,空值,当实体在某个属性上没有值时应使用,空值,。,,联系的元数,,一个联系涉及到的实体集个数，称为该联系的元数或度数。,,同一个实体集内部实体间的联系，称为一元联系。也称为递归联系。,,两个不同实体集、实体之间的联系称为二元联系。,,三个不同实体集实体之间的联系，称为三元联系。,,一对一联系,图,5.7,一对一联系,,,一对多联系,图,5.8,一对多联

23、系,,,多对多联系,,图,5.9,多对多联系,,,联系类型的约束,,联系类型的约束限制了参与联系的实体的数目。有两类联系约束：,,基数约束,,,参与一个联系中的实体数目称为映射基数。在具体实现时，有时对映射基数还要做出更精确的描述，即指明参与联系的实体数目的最小映射基数和最大映射基数，用范围“,min..max,”,表示，用“,*,”表示“,∞,”。,,联系类型的约束,,参与约束,,如果实体集,E,中的每个实体都参与联系集,R,的至少一个联系中，称实体集,E“,完全参与,”联系集,R,。如果实体集,E,中只有部分实体参与联系集,R,的联系中，称实体集,E“,部分参与”联系集,R,。在,ER,图

24、中，完全参与用双线表示，部分参与用单线表示。一般，为了简化，很少在,ER,图上考虑参与约束，联系全部用单线边表示。,,联系类型的约束,问题：运动员根据其得分来排定名次。在名次排列中，排在他前面只有一个人，排在他后面也只有一个人,,运动员,编号,姓名,性别,名次,顺序,1,1,图,5.10,一元联系中的,1:1,联系,,,联系类型的约束,职工之间的上下级联系,,职工,工号,姓名,年龄,性别,领导,1,N,图,5.11,一元联系中的,1:N,联系,,,联系类型的约束,工厂的零件之间存在着组合关系，一种零件由许多种子零件组成，而一种零件也可以是其他零件的子零件,,零件,零件号,零件名,规,格,数量,

25、组成,M,N,,图,5.12,一元联系中的,M:N,联系,,,联系类型的约束,某商业集团中，商店、仓库、商品之间的进货联系,,,图,5.13,三元联系中的,M:N:P,联系,,仓库,商品,商店,仓库号,仓库名,地址,数量,商店号,商品名,商品号,商店名,日期,进货,M,N,P,,联系类型的约束,学校里规定每学期每位教师可讲授,0,到,3,门课程，每门课程有且仅有一位教师上课,,图,5.14,教师和课程之间的映射基数,教师,课程,讲授,,1,（,0,，,3,）,,N,（,1,，,1,）,教师的基数为（,0,，,3,）,课程的基数为（,1,，,1,）,,联系类型的约束,学校里规定每学期学生至少选修

26、,1,门课程，最多选修,6,门课程；每门课程至多有,50,人选修，最少可以没人选修,,,图,5.15,学生和课程之间的映射基数,学生,课程,选课,,M （1，6）,,N （0，50）,学生的基数为（,1,，,6,）,课程的基数为（,0,，,50,）,,ER,模型的操作,教师号,姓名,出生日期,职务,工资,奖金,教师,（a）,,在,数据库设计过程中，常常要对,ER,图,进行种种变化，这种变化称为,ER,模型的操作，包括实体类型、联系类型和属性的分裂、合并、增删等。,原实体类型,,分裂,教师号,姓名,出生日期,教师不变信息,职务,工资,奖金,教师号,教师变动信息,（b）,图,5.16,实体类型的垂

27、直分裂,分裂方式有两种：,,水平分裂（元组）和垂直分裂（属性）,,分裂,教师,课程,主讲,辅导,1,M,N,N,图,5.17,联系类型的分裂,教师,课程,教授,M,N,（a） （b）,联系类型也可分裂,,合并,,不合法的合并,B,(a),A,C,A-C,B-C,A,C,A-B-C,(b),B,合并是分裂操作的逆过程。合并的联系类型必须是定义在相同的实体类型组合中，否则是不合法的合并。,,采用,ER,方法的数据库概念设计

28、 之,设计局部,ER,模式,,,,需求分析结果,确定局部结构范围,实体定义,联系定义,属性分配,还有局部,,结构待分析,有,无,进入全局,ER,模式设计,局部,ER,模式设计,范围的划分要自然，易于管理；,范围的大小要适度。太小了，会造成局部结构过多，设计过程繁琐，综合困难；太大了，则容易造成内部结构复杂，不便分析,,范围之间的界面要清晰，相互影响要小,依据系统的的当前用户进行自然划分,按用户要求数据库提供的服务归纳分类,,采用,ER,方法的数据库概念设计 之,设计局部,ER,模式,,,,需求分析结果,确定局部结构

29、范围,实体定义,联系定义,属性分配,还有局部,,结构待分析,有,无,进入全局,ER,模式设计,局部,ER,模式设计,采用人们习惯的划分；,,避免冗余，在一个局部结构中，对一个对象只取一种抽象形式，不要重复；,,依据用户的信息处理需求,,,采用,ER,方法的数据库概念设计 之,设计局部,ER,模式,,,,需求分析结果,确定局部结构范围,实体定义,联系定义,属性分配,还有局部,,结构待分析,有,无,进入全局,ER,模式设计,局部,ER,模式设计,任意两个实体类型之间是否存在联系？,,一个实体类型内部是否存在联系？,,多个 实体类型之间是否存在联系

30、？,,在确定联系类型时，应注意防止出现冗余的联系。,,联系类型确定后，需要命名和确定键。,,采用,ER,方法的数据库概念设计 之,设计局部,ER,模式,,,,需求分析结果,确定局部结构范围,实体定义,联系定义,属性分配,还有局部,,结构待分析,有,无,进入全局,ER,模式设计,局部,ER,模式设计,确定属性的原则：,,属性应该是不可再分解的语义单位；实体与属性之间的关系只能是,1:N,的；不同实体类型的属性之间应无直接关联关系。,,属性分配的原则：,,当多个实体类型用到同一属性时，一般把属性分配给那些使用频率最高的实体类型，或分配给实体值少的

31、实体类型。,,有些属性不宜归属于任一实体类型，只说明实体之间联系的特性,,,,局部模式,现有的教学,,管理系统,初步分析系统的对象,根据服务种类分析教师子模块,……,局部,ER,图,,其他局部模式,,现有的教学,,管理系统,初步分析系统的对象,根据服务种类分析学生子模块,……,学籍管理局部应用的分,E-R,图,导师,班级,学生,组成,管理,班主任,档案材料,宿舍,住宿,归档,指导,系,有,参加,学会,1,N,1,1,1,N,N,N,1,1,N,M,N,1,具有,社会关系,1,N,局部,ER,图,,其他局部模式,现有的教学,,管理系统,初步分析系统的对象,根据服务种类分析课程子模块,……,局部,

32、ER,图,,课程管理局部应用分,E-R,图,1,教室,M,1,教科书,教师,担任,课程,系,开设,N,1,学生,选修,N,M,上课,P,N,,采用,ER,方法的数据库概念设计 之,设计全局,ER,模式,无,全局,ER,模式设计,,局部,ER,模式,确定公共实体类型,合并两个局部,ER,模式,检查并消除冲突,还有未合并的局部模式,有,还有冲突吗,有,仅,根据实体类型名和键来认定公共实体类型：,,一般把同名实体类型作为公共实体类型的一类候选，,,把具有相同键的实体类型作为公共实体类型的另一类候选,,采用,ER,方法的数据库概念设计

33、 之,设计全局,ER,模式,无,全局,ER,模式设计,,局部,ER,模式,确定公共实体类型,合并两个局部,ER,模式,检查并消除冲突,还有未合并的局部模式,有,还有冲突吗,有,合并原则：,,首先进行两两合并,,先合并那些现实世界中有联系的局部结构,,合并从公共实体类型开始，最后再加入独立的局部结构。,,采用,ER,方法的数据库概念设计 之,设计全局,ER,模式,无,全局,ER,模式设计,,局部,ER,模式,确定公共实体类型,合并两个局部,ER,模式,检查并消除冲突,还有未合并的局部模式,有,还有冲突吗,有,属性冲突,：

34、,如，重量单位有的用公斤，有的用克。,,,结构冲突,：,同一对象在不同应用中的不同抽象,；,同一实体在不同局部,ER,图中属性的个数或次序不同,；,实体之间的联系在不同的局部,ER,图中呈现不同的类型,,,命名冲突,：,属性名、实体名、联系名之间存在同名异义或异名同义冲突,,采用,ER,方法的数据库概念设计 之全局,ER,模式的优化,实体类型的合并,,1:1,联系的两个实体类型,,,具有相同键的实体类型,,,冗余属性的消除,,,冗余联系的消除：,利用规范化理论中函数依赖的概念消除冗余联系,,,,例子：三个局部,ER,图合并成一个,ER,图,M,学籍管理

35、局部应用分,E-R,图,N,1,1,N,N,N,社会关系,具有,1,N,系,导师,档案材料,归档,参加,学会,1,宿舍,住宿,指导,有,1,班级,学生,组成,N,N,班主任,管理,1,,1,1,,例子：三个局部,ER,图合并成一个,ER,图,课程管理局部应用分,E-R,图,P,N,1,M,,M,系,教师,教科书,担任,课程,选修,教室,上课,学生,开设,1,N,N,1,,例子：三个局部,ER,图合并成一个,ER,图,项目,系,教师管理局部应用分,E-R,图,1,N,M,1,聘用,承接,参加,设置,院长,学院,主管,N,N,1,1,1,教师,评定,职称,分配,工作量,1,1,1,N,管理,1,1

36、,负责人,N,,例子：三个局部,ER,图合并成一个,ER,图,1,N,1,N,教师,1,合并后的教学管理,E-R,图,P,1,1,N,1,N,1,M,,M,N,N,N,N,社会关系,具有,1,N,N,M,1,系,聘用,承接,项目,参加,设置,院长,学院,主管,N,N,1,1,1,教师,评定,职称,分配,工作量,1,1,1,N,档案材料,归档,参加,学会,1,宿舍,住宿,教科书,担任,指导,课程,选修,教室,上课,有,1,班级,学生,组成,N,开设,N,管理,1,1,管理,1,,1,,5.3 ER,模型到关系模型的转换,算法,5.1,,步骤,1,：将每个实体类型转换成一个关系模式，实体的属性即

37、为关系模式的属性，实体标识符即为关系模式的键,,ER,图转换成关系模式集的规则,步骤,2,联系类型的转换,,步骤,2.1,二元联系类型的转换,,若实体间联系是,1:1,，可以在两个实体类型转换成的两个关系模式中任意一个关系模式的属性中加入另一个关系模式的键和联系类型的属性。,,,若实体间联系是,1:N,，,则在,N,端实体类型转换成的关系模式中加入,1,端实体类型的键和联系类型的属性。,,,若实体间联系是,M:N,，,则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。,,,步骤,2.2,一元联系类型的转换,:,同二元联系,,ER,图转换成关系模式

38、集的规则,步骤,2.3,三元联系类型的转换,,,若实体间的联系是,1:1:1,，可以在,3,个实体类型转换成的,3,个关系模式中任意一个关系模式的属性中加入另两个关系模式的键和联系类型的属性。,,,若实体间联系是,1:1:N,，则在,N,端实体类型转换成的关系模式中加入两个,1,端实体类型的键（作为外键）和联系类型的属性。,,,若实体间联系是,1:M:N,，则将联系类型也转换成关系模式，其属性为,M,端和,N,端实体类型的键（作为外键）加上联系类型的属性，而键为,M,端和,N,端实体键的组合。,,,若实体间联系是,M:N:P,，则将联系类型也转换成关系模式，其属性为,3,端实体类型的键（作为外

39、键）加上联系类型的属性，而键为,3,端实体键的组合。,,ER,模型到关系模型的转换实例,图,2.3,一对一联系,,,ER,模型到关系模型的转换实例,1:1,：在任意一个关系模式的属性中加入另一个,,关系模式的键和联系类型的属性。,,,学校（,校名,，地址，电话，,校长名,，任职年月）,,,校长（,姓名,，性别，年龄，职称）,,,学校（,校名,，地址，电话）,,,校长（,姓名,，性别，年龄，职称，,任职学校,，任职年月）,,,ER,模型到关系模型的转换实例,图,2.4,一对多联系,,,ER,模型到关系模型的转换实例,1:N,：在,N,端关系模式的属性中加入,1,端关系模式的,,,键和联系类型的属

40、性,。,,,,系（,系号,，系名，电话）,,,教师（,工号,，姓名，性别，年龄，,系号,，聘期）,,ER,模型到关系模型的转换实例,,图,2.5,多对多联系,,,ER,模型到关系模型的转换实例,M:N,：,将联系类型转换成关系模式，其属性,,为两端实体类型的键加上联系类型的属性，,,而键为两端实体键的组合。,,,学生,(,学号,，姓名,，,年龄，性别,),,课程,(,课程号,，课程名,，,教师名,),,选课,(,学号,，,课程号,，,成绩,),,,ER,模型到关系模型的转换实例,教师,系,课程,课程号,课程名,学分,姓名,性别,职称,教材,聘用,开设,任教,教工号,电话,聘期,主管,系编号,系

41、名,1,1,1,M,N,N,N,1,,ER,模型到关系模型的转换实例,实体类型的转换,,系,（,系编号,，系名，电话）,,教师,（,教工号,，姓名，性别，职称）,,课程,（,课程号,，课程名，学分）,,,联系类型的转换,,系,（,系编号,，系名，电话，,主管人的教工号,）,,教师,（,教工号,，姓名，性别，职称，,系编号,，聘期）,,课程,（,课程号,，课程名，学分，,系编号,）,,任教,(,教工号,，,课程号,，,教材,),,ER,模型到关系模型的转换实例,,运动员,编号,姓名,性别,名次,顺序,1,1,职工,工号,姓名,年龄,性别,领导,1,N,运动员,（,编号,，姓名，性别，名次，,上一

42、名次编号,，,下一名次编号,）,,职工,（,工号,，姓名，年龄，性别，,经理工号,）,,,ER,模型到关系模型的转换实例,,零件,零件号,零件名,规,格,数量,组成,M,N,零件（,零件号,，零件名，规格）,,组成（,零件号,，,子零件号,，数量）,,,ER,模型到关系模型的转换实例,,仓库,商品,商店,仓库号,仓库名,地址,数量,商店号,商品名,商品号,商店名,日期,进货,M,N,P,仓库（,仓库号,，仓库名，地址）,,商店（,商店号,，商店名）,,商品（,商品号,，商品名）,,进货（,商店号,，,商品名,，,仓库号,，日期，数量）,,,采用,ER,方法的逻辑设计步骤,,关系数据库的逻辑设计

43、,关系模式规范化,模式评价,是否需要修正,从,ER,模式导出,,初始数据库模式,处理需求,ER,模式,,DBMS,特征,用,DBMS,语法描述,模式修正,进入物理设计阶段,是,否,,例,1,库存销售信息管理系统的,ER,模型及转换,P,车间,仓位,产品,客户,销售员,存储,出库,订单,入库,M,N,M,P,M,N,P,M,N,N,库存系统,ER,图,车间,(,车间号,,,车间名,,,主任名,),,产品,(,产品号,，产品名，单价,),,仓位,(,仓位号,，地址，主任名,),,客户,(,客户号,，客户名，联系人，电话，,,地址，税号，账号,),,销售员,(,销售员号,,,姓名,,,性别,,,学历

44、,,,业绩）,实体,入库,（,入库单号,,,入库量,,,入库日期,,,经手人,,,,车间号,,,仓位号,,,产品名,）,,出库,（,出库单号,，出库量，出库日期，经手人，,,客户号,，,产品名,，,仓位号,）,,订单,（,订单号,，数量，折扣，总价，订单日期，,,产品号,，,客户号,，,销售员号,）,,,存储,(,仓位号,,,产品号,,,核对日期,,,核对员,,,存储量,),联系,,例,2,：,公司车队信息系统的,ER,模型,,图,5.27,,公司车队信息系统的,ER,模型,部门,,车队,,司机,,车辆,,开销,,维修公司,调用,报销,拥有,聘用,保险,2,保险,1,M,1,N,N,1,N,N

45、,N,N,1,1,保险公司,,1,N,维修,部门,(,部门号,,,名称,,,负责人,),,车队,(,车队号,，名称，地址,),,司机,(,司机号,，姓名，执照号，电话，工资,),,车辆,(,车牌号,，车型，颜色，载重,),,保险公司,（,保险公司号,，名称，地址）,,维修公司,（,维修公司号,，名称，地址）,,开销,(,顺序号,,,费用类型,,,费用,,,日期,,,经手人）,调用,(,出车编号,,,出车日期,,,,,车程，费用，车辆数目,),,保险,1,(,投保日期，保险种类，费用,),,保险,2,(,投保日期，保险种类，费用,),实体类型,联系的属性,,例,2,：,公司车队信息系统的,ER,

46、模型,,部门,(,部门号,,,名称,,,负责人,),,车队,(,车队号,，名称，地址,),,司机,(,司机号,，姓名，执照号，电话，工资，,保险公司号,，投保日期，保险种类，,,费用，,车队号,),,车辆,(,车牌号,，车型，颜色，载重，,保险公司号,，投保日期，保险种类，费用，,,,维修公司号,，,车队号,),,保险公司,（,保险公司号,，名称，地址）,,维修公司,（,维修公司号,，名称，地址）,,开销,(,顺序号,,,费用类型,,,费用,,,日期,,,经手人，,车牌号,）,调用,(,出车编号,,,部门号,,,车队号,，出车日期,,,车程，费用，车辆数目,),实体类型,联系类型,,例,3,：

47、人事管理,信息系统的,ER,模型,,职工,(,工号,,,姓名,,,性别,,,年龄,,,学历,),,部门,(,部门号,，部门名称，职能,),,岗位,(,岗位编号,，岗位名称，岗位等级,),,技能,(,技能编号,，技能名称，技能等级,),,奖惩,（,序号,，奖惩标志，项目，奖惩金额）,,培训课程,（,课程号,，课程名，教材，学时）,,工资,(,工号,,,基本工资,,,级别工资,,,养老金,,,,,失业金,,,公积金,,,纳税）,选课,(,时间,,,成绩,),,设置,(,人数,),,考核,(,时间，地点，级别,),,接受,(,奖惩时间,),实体类型,联系的属性,N,图,5.28,,人事管理信息系统的

48、,ER,模型,工资,,培训课程,,部门,,职工,,奖惩,,技能,享有,接受,选课,属于,聘任,设置,M,1,1,N,M,N,M,M,N,1,岗位,,N,N,考核,1,,例,3,：人事管理,信息系统的,ER,模型,职工,(,工号,,,姓名,,,性别,,,年龄,,,学历，,部门号,，,岗位编号,),,部门,(,部门号,，部门名称，职能,),,岗位,(,岗位编号,，岗位名称，岗位等级,),,技能,(,技能编号,，技能名称，技能等级,),,奖惩,（,序号,，奖惩标志，项目，奖惩金额）,,培训课程,（,课程号,，课程名，教材，学时）,,工资,(,工号,,,基本工资,,,级别工资,,,养老金,,,,,失业

49、金,,,公积金,,,纳税）,选课,(,工号,,,课程号,，时间,,,成绩,),,设置,(,部门号,，,岗位编号,，人数,),,考核,(,工号,,,技能编号,，时间，地点，级别,),,接受,(,工号,,,序号,，奖惩时间,),实体类型,联系类型,,例,4,：旅游管理,信息系统的,ER,模型,,导游,(,导游编号,,,姓名,,,性别,,,年龄,,,身份证号码,,,,,住址,,,电话,,,语种,,,等级,,,业绩,),,交通工具,(,旅游班次号,，出发工具，出发日期，,,出发班次，出发时间，回程工具，,,回程日期，回程班次，回程时间,),,宾馆,(,宾馆编号,，宾馆名，城市，星级，,,标准房价，联系

50、人，职务，,,地址，电话，传真,),,旅游线路,(,路线号,,,起点,,,终点,,,,,天数,,,主要景点,),,旅游班次,(,班次号,,,出发日期,,,,,回程日期,,,旅游标准,,,报价,),,旅游团,(,团号,,,团名,,,人数,,,联系人,,,,,地址,,,电话,),,游客,(,游客编号,,,姓名,,,性别,,,年龄,,,,,身份证号码,,,住址,,,电话,),,保险单,(,保险单编号,，保险费，,,投保日期,),实体类型,实体类型,N,图,5.29,,旅游管理信息系统的,ER,模型,旅游线路,,旅游班次,,宾馆,,旅游团,,导游,,旅客,开设,陪同,有,交通,参加,食宿,1,1,1,

51、N,M,1,1,N,N,1,保险单,,N,M,组成,交通工具,,1,,例,4,：旅游管理,信息系统的,ER,模型,旅游线路,(,路线号,,,起点,,,终点,,,天数,,,主要景点,),,旅游班次,(,班次号,,,出发日期,,,回程日期,,,旅游标准,,,报价，,路线号,),,旅游团,(,团号,,,团名,,,人数,,,联系人,,,地址,,,电话，,保险单编号,，,班次号,),,游客,(,游客编号,,,姓名,,,性别,,,年龄,,,身份证号码,,,住址,,,电话，,团号,),,保险单,(,保险单编号,，保险费，投保日期,),,导游,(,导游编号,,,姓名,,,性别,,,年龄,,,身份证号码,,,住

52、址,,,电话,,,语种,,,等级,,,业绩,),,交通工具,(,旅游班次号,，出发工具，出发日期，出发班次，出发时间，回程工具，,,回程日期，回程班次，回程时间,),,宾馆,(,宾馆编号,，宾馆名，城市，星级，标准房价，联系人，职务，地址，电话，传真,),陪同,(,导游编号,,,班次号,),,食宿,(,班次号,，,宾馆编号,),实体类型,联系类型,,5.5,增强的,ER,模型,什么是弱实体,,,一个实体对于另一个实体（称为父实体）具有很强的依赖关系，而且该实体,主键的一部分或全部,从其父实体中获得，称该实体为,弱实体,。,,弱实体,弱实体的表示方法,,,在,ER,模型中，弱实体用双线矩形框表示

53、，与弱实体相关的联系，用双线菱形框表示。父实体与弱实体的联系只能是,1:1,或,1:N,。,,,弱实体,顾 客,地 址,通讯,N,1,问题,:,商业应用系统中，顾客地址的存在依赖于顾客的存在,（一般顾客可以有若干个联系地址）,,ER,图,在实际应用中，对于有很强依赖关系的实体才确定为弱实体。,,弱实体,问题：在人事管理系统中，亲属的存在是以职工的存在为前提，即亲属对于职工具有依赖联系，所以说，亲属是弱实体,,职 工,亲属,具有,1,N,ER,,图,职工（,职工号,，职工姓名，性别，年龄）,,亲属（,职工号，称呼,，姓名，工作单位）,,关系,,模式,,,,子类实体与超类实体,什么是子类和超类,,

54、当较低层上实体类型表达了与之联系的较高层上的实体类型的特殊情况时，称较高层上实体类型为超类型（,Supertype,），,较低层上实体类型为子类型。,,从子类到超类的抽象过程称为“概化”；从超类到子类的具体化过程称为“特化”,,,,,子类实体与超类实体,特化过程的不相交约束,,不相交，用,d,表示,,重叠，用,o,表示,,特化过程的完备性约束,,整体特化，用双线表示,,部分特化，用单线表示,,,子类实体与超类实体,对子类和超类进行插入、删除操作的,3,条规则,,从超类删除一个实体意味着该实体被自动地从它隶属的所有子类中删除,,向超类中插入一个实体意味着该实体被强制地插入到满足两种约束的子类中,

55、,向一个整体特化的超类中插入一个实体，意味着实体被强制地插入到至少一个特化的子类中,,,子类实体与超类实体,人员,教师,本科生,学生,研究生,,学校人事系统中实体之间的联系,,人员（,身份证号,，姓名，年龄，性别）,,教师（,身份证号,，教师编号，职称）,,学生（,身份证号,，学号，系别，专业）,,本科生（,身份证号,，入学年份）,,研究生（,身份证号,，研究方向，导师姓名,）,对应的关系模式,,小结,数据库的生命周期,,数据库设计的步骤,,ER,模型,,基本概念,,ER,模型的设计方法,,ER,模型向关系模型的转换,,本章的重点篇幅,,（,1,）教材中,P,1,68-170,的转换规则和实例

56、。,,（,2,）教材中,P171-276,的四个,ER,模型实例。,,,对,ER,模型的理解,（一）,,ER,模型是人们认识客观世界的一种方法、工具。,ER,模型具有客观性和主观性两重含义。,ER,模型是在客观事物或系统的基础上形成的，在某种程度上反映了客观现实，反映了用户的需求，因此,ER,模型具有客观性。但,ER,模型又不等同于客观事物的本身，它往往反映事物的某一方面，至于选取哪个方面或哪些属性，如何表达则决定于观察者本身的目的与状态，从这个意义上说，,ER,模型又具有主观性。,,对,ER,模型的理解,（二）,,ER,模型的设计过程，基本上是两大步：,,－先设计实体类型（此时不要涉及到“联系”）；,,－再设计联系类型（考虑实体间的联系）。,,具体设计时，有时“实体”与“联系”两者之间的界线是模糊的。数据库设计者的任务就是要把现实世界中的数据以及数据间的联系抽象出来，用“实体”与“联系”来表示。,,另外，设计者应注意，,ER,模型应该充分反映用户需求，,ER,模型要得到用户的认可才能确定下来。,,