第七章 数据库设计

,数据库系统概论,第七章 数据库设计,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,数据库系统概论,第六章 关系数据理论,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第七章 数据库设计,7.1 数据库设计概述,7.2 需求分析,7.3 概念结构设计,7.4 逻辑结构设计,7.5 数据库的物理设计,7.6 数据库实现和维护,什么是数据库设计,数据库设计是指对于一个给定的应用环境，构造最优的数据库逻辑模式和物理结构，并根据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求（信息管理要求和数据操作要求）,在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。,7.1 数据库设计概述,7.1.1 数据库设计的特点,一、数据库建设的基本规律,三分技术，七分管理，十二分基础数据；,二、结构（数据）设计和行为（处理）设计相结合,结构（数据）设计：设计数据库框架或数据库结构；,行为（处理）设计：设计应用程序、事务处理等。,三、结构和行为分离的设计,传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策,早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计,现实世界,概念模型设计,子模式设计,物理数据库设计,逻辑数据库设计,建立数据库,数据分析,功能分析,功能模型,功能说明,事务设计,程序说明,应用程序设计,程序编码调试,图7.1 结构和行为分离的设计,结构特性和行为特性结合起来,7.1.2 数据库设计方法,一、要求数据库设计人员应该具备的技术和知识,数据库的基本知识；,软件工程的原理和方法；,程序设计的方法和技巧；,数据库的基本知识和设计技术；,应用领域的知识。,二、规范设计法(,本质上看:手工设计方法,),新奥尔良（New Orleans）方法,将数据库设计分为四个阶段(需求分析、概念设计、逻辑设计、物理设计）,基于E-R模型的数据库设计方法,3NF的设计方法,ODL方法：面向对象的数据库设计方法,计算机辅助设计,ORACLE Designer 2000,SYBASE PowerDesigner,7.1.3 数据库设计的基本步骤,一,、数据库设计的准备工作(选定参加设计的人员),1. 数据库分析设计人员,数据库设计的核心人员,自始至终参与数据库设计,其水平决定了数据库系统的质量,2. 用户,在数据库设计中也是举足轻重的,主要参加需求分析和数据库的运行维护,用户积极参与带来的好处,加速数据库设计,提高数据库设计的质量,3. 程序员,(,在系统实施阶段参与进来，负责编制程序),4. 操作员,(,在系统实施阶段参与进来，准备软硬件环境),需求分析阶段,概念结构设计阶段,逻辑结构设计阶段,数据库物理设计阶段,数据库实施阶段,数据库运行和维护阶段,准确了解与分析用户需求（包括数据与处理）；,是整个设计过程的基础，是最困难、最耗费时间的一步。,需求分析是设计数据库的起点,需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用,是整个数据库设计的关键；,通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型（E-R图）。,将概念结构转换为某个DBMS所支持的数据模型（关系数据模型）；,对其进行优化。,然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式,为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）,根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式,运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果,建立数据库,编制与调试应用程序,组织数据入库,并进行试运行,数据库应用系统经过试运行后即可投入正式运行。,在数据库系统运行过程中必须不断地对其进行评价、调整与修改。,设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。,（如：P202图7.2）,二,、数据库设计的过程(六个阶段),需求收集和分析,设计概念结构,设计逻辑结构,数据模型优化,设计物理结构,评价设计,性能预测,物理实现,试验性运行,使用、维护数据库,应用需求,数据、处理,转换规则、,DBMS功能,优化方法,应用要求,DBMS详,细特征,需求分析阶段,不满意,不满意,数据库实施阶段,物理设计阶段,逻辑设计阶段,概念设计阶段,图7.2 数据库设计步骤,数据库运行、维护阶段,设计特点,在设计过程中把,数据库的设计,和对数据库中,数据处理的设计,紧密结合起来,将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计,设计过程各个阶段的设计描述：P204图7.3,设,计阶 段,设 计 描 述,数 据,处 理,需求分 析,数据字典、全系统中数据项、,数据流、数据存储的描述,数据流图和判定表（判定树）、数据字典中处理过程的描述,概念模型（E-R图）,数据字典,系统说明书包括：,新系统要求、,方案和概图,反映新系统信息,流的数据流图,某种数据模型,关系 非关系,系统结构图,（模块结构）,存储安排,方法选择,存取路径建立,模块设计,IPO表,实施阶段,编写模式,装入数据,数据库试运行,程序编码、,编译联结、,测试,运行、维护,性能监测、转储/恢复,数据库重组和重构,新旧系统转换、运行、维护（修正性、适应性、改善性维护）,IPO表,输入：,输出：,处理：,Creat,Load,Main( ),if,then,end,分区1,分区2,概念结构设计,逻辑结构设计,物理设计,图7.3 设计过程各个阶段的设计描述,应用1,应用要求,应用2,应用要求,应用3,应用要求,概念,模式,综合,应用1,外模式1,应用2,外模式2,应用3,外模式3,逻辑,模式,转换,映象,映象,图7.4 数据库的各级模式,内模式,7.1.4 数据库设计过程中的各级模式,7.2 需求分析,7.2.1 需求分析的任务,一、需求分析的任务,二、需求分析的重点,三、需求分析的难点,一、需求分析的任务,通过详细调查现实世界要处理的对象（组织、部门、企业等），充分,了解原系统,（手工系统或计算机系统）,工作概况，明确用户的各种需求。,在此基础上,确定新系统的功能,。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库,二、需求分析的重点,需求分析的重点是调查、收集与分析用户在数据管理中的,信息要求、处理要求、安全性与完整性要求,。,信息要求,用户需要从数据库中获得信息的内容与性质,由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据,处理要求,对处理功能的要求,对处理的响应时间的要求,对处理方式的要求(批处理 / 联机处理),安全性与完整性要求。,三、需求分析的难点,确定用户最终需求的难点,用户,缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此无法一下子准确地表达自己的需求，他们所提出的需求往往不断地变化。,设计人员,缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。,新,的硬件、软件,技术的出现,也会使用户需求发生变化。,解决方法,设计人员必须采用有效的方法，与用户不断,深入,地进行,交流,，才能逐步得以确定用户的实际需求,7.2.2 需求分析的方法,调查清楚用户的实际需求并进行初步分析，与用户达成共识，然后 进一步分析与表达这些需求。,一、 调查用户需求的具体步骤,调查组织机构情况,(为分析信息流程做准备),组织部门的组成情况,各部门的职责等,调查各部门的业务活动情况。调查重点之一。,各个部门输入和使用什么数据,如何加工处理这些数据,输出什么信息,输出到什么部门,输出结果的格式是什么,在熟悉业务活动的基础上，协助用户明确对新系统的各种要求,（信息要求、处理要求、完全性与完整性要求）。调查重点之二。,确定新系统的边界,对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成；确定哪些活动由人工完成。,由计算机完成的功能就是新系统应该实现的功能。,常用调查方法,跟班作业,开调查会,请专人介绍,询问,设计调查表请用户填写,查阅记录,二、常用调查方法,做需求调查时，往往需要同时采用多种方法,无论使用何种调查方法，都必须有用户的积极参与和配合。,设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果共同承担责任。,通过亲身参加业务工作了解业务活动的情况。能比较准确地理解用户的需求，但比较耗时。,通过与用户座谈来了解业务活动情况及用户需求。,对某些调查中的问题，可以找专人询问,如果调查表设计合理，则很有效，且易于为用户接受,查阅与原系统有关的数据记录,三、进一步分析和表达用户需求,分析和表达用户的需求,的常用方法,自顶向下的结构化分析方法（Structured Analysis，简称SA方法）,SA方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并用数据流图和数据字典描述系统。,1首先把任何一个系统都抽象为：,数据流,数据流,信息要求,数据,来源,处理,数据,输出,处理要求,图7.5系统高层抽象图,数据存储,2分解处理功能和数据,（1）分解处理功能,将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止。,（2）分解数据,在处理功能逐步分解的同时，其所用的数据也逐级分解，形成若干层次的数据流图。,数据流图表达了数据和处理过程的关系。,（3）表达方法,处理过程,：用判定表或判定树来描述,数据：,用数据字典来描述,3将分析结果再次提交给用户，征得用户的认可,四、需求分析过程,图7.6 需求分析过程,7.2.3 数据字典和数据流图,一、数据字典的用途,数据字典是各类数据描述的集合,数据字典是进行详细的数据收集和数据分析所获得的主要结果,数据字典在数据库设计中占有很重要的地位,二、数据字典的内容,数据字典的内容,数据项,数据结构,数据流,数据存储,处理过程,数据项是数据的最小组成单位,若干个数据项可以组成一个数据结构,数据字典通过对数据项和数据结构的定义来,描述数据流、数据存储的逻辑内容。, 数据项,数据项是不可再分的数据单位,对数据项的描述,数据项描述,数据项名，数据项含义说明，,别名，数据类型，长度，取值范围，,取值含义，与其他数据项的逻辑关系,取值范围、与其他数据项的逻辑关系定义了,数据的完整性约束条件, 数据结构,数据结构反映了数据之间的组合关系。,一个数据结构可以,由若干个数据项,组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。,对数据结构的描述,数据结构描述,数据结构名，含义说明，组成:数据项或数据结构, 数据流,数据流是数据结构在系统内传输的路径。,对数据流的描述,数据流描述,数据流名，说明，数据流来源，,数据流去向，组成:数据结构，,平均流量，高峰期流量,数据流来源是说明该数据流来自哪个过程,数据流去向是说明该数据流将到哪个过程去,平均流量,是指在单位时间（每天、每周、每月等）里的传输次数,高峰期流量,则是指在高峰时期的数据流量, 数据存储,数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。,对数据存储的描述,数据存储描述数据存储名，说明，编号，,流入的数据流 ，流出的数据流 ，,组成:数据结构，数据量，存取方式,流入的数据流：指出数据来源,流出的数据流：指出数据去向,数据量：每次存取多少数据，每天（或每小时、每周等）存取几次等信息,存取方法：批处理 / 联机处理；检索 / 更新；顺序检索 / 随机检索, 处理过程,处理过程的具体处理逻辑一般用,判定表或判定树来,描述。数据字典中只需要描述处理过程的说明性信息,处理过程说明性信息的描述,处理过程描述,处理过程名，说明，,输入:数据流，输出:数据流，,处理:简要说明,简要说明：主要说明该处理过程的功能及处理要求,功能：该处理过程用来做什么,处理要求：处理频度要求（如单位时间里处理多少事务，多少数据量）；响应时间要求等,处理要求是后面物理设计的输入及性能评价的标准,数据字典举例,例：学生学籍管理子系统的数据字典。,数据项,，以“学号”为例：,数据项：学号,含义说明：唯一标识每个学生,别名：学生编号,类型：字符型,长度： 8,取值范围：00000000至99999999,取值含义：前两位标别该学生所在年级，,后六位按顺序编号,与其他数据项的逻辑关系：,数据结构,以“学生”为例,“学生”是该系统中的一个核心数据结构：,数据结构：学生,含义说明：是学籍管理子系统的主体数据结构，定义了一个学生 的有关信息,组成：学号，姓名，性别，年龄，所在系，年级,数据流,“体检结果”可如下描述：,数据流：体检结果,说明：学生参加体格检查的最终结果,数据流来源：体检,数据流去向：批准,组成：,平均流量：,高峰期流量：,数据存储,“学生登记表”可如下描述：,数据存储：学生登记表,说明：记录学生的基本情况,流入数据流：,流出数据流：,组成：,数据量：每年3000张,存取方式：随机存取,处理过程,“分配宿舍”可如下描述：,处理过程：分配宿舍,说明：为所有新生分配学生宿舍,输入：学生，宿舍，,输出：宿舍安排,处理：在新生报到后，为所有新生分配学,生宿舍。要求同一间宿舍只能安排,同一性别的学生，同一个学生只能,安排在一个宿舍中。每个学生的居,住面积不小于3平方米。安排新生,宿舍其处理时间应不超过15分钟。,三、数据流图（Data Flow Diagram，简称DFD）,数据流图,是描绘系统逻辑模型的一种网络表示(这里的系统可以是自动化系统、手工系统或是两者混合而成的系统)。数据流图通过它的成分及所标明各个成分之间的接口来描述系统，数据流图的基本成分是:,1.数据流;,2.文件(数据存储);,3.加工(亦称处理、过程或变换);,4.数据源点或终点。,是某种已知构成的信息所流过的通道,是数据的暂存区,是系统之外的人或组织；这些人或组织是单纯数据的产生源或接收者,是一种将进入数据流转化为流出数据流的变换,命名原则,：,要具体，便于区分，名副其实，反映功用,数据流图,常用的符号,数据处理,数据流,1.数据流,用箭头线表示；,数据存储,数据源点或终点,2.文件（数据存储）,用开口矩形或两条平行横线表示；,3.加工（亦称处理、过程或变换）,用圆角矩形或圆形表示；,4.数据源点或终点,用正方形或立方体表示。,7.3.1 概念结构,什么是概念结构设计,需求分析阶段描述的用户应用需求是现实世界的具体需求,将需求分析得到的用户需求,抽象,为信息结构即概念模型的过程就是概念结构设计,概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。,概念结构设计是整个数据库设计的关键,现实世界,机器世界,信息世界,需求分析,概念结构设计,概念结构设计的特点,（1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是,对现实世界的一个真实模型。,（2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。,（3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。,（4）易于向关系、网状、层次等各种数据模型转换,描述概念模型的工具,E-R模型,自底向上,首先定义各,局部,应用的概念结构，然后将它们集成起来，得到全局概念结构,7.3.2 概念结构设计的方法与步骤,设计概念结构的四类方法,自顶向下,首先定义,全局,概念结构的框架，然后逐步细化,逐步扩张,首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构,混合策略,将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。,全局概念模式,概念模式,概念模式,概念模式,概念模式,概念模式,(a)自顶向下的设计方法,概念模式,需求,概念模式,(b)自底向上的设计方法,概念模式,概念模式,概念模式,子需求,概念模式,概念模式,全局概念模式,子需求,子需求,子需求,(c)逐步扩张的设计方法,核心需求,需求,核心概念结构,全局概念结构,概念结构设计的方法与步骤（续）,需求,需求,1,需求,1,.1,需求,1,.,2,概念模式,1,.1,概念模式,1,.,2,概念模式,1,需求,n,需求,n,.1,需求,n,.,2,概念模式,n,.,1,概念模式,n,.,2,概念模式,n,(,应用,1),全局概念模式,(,应用,n,),需求分析,(,自顶向下,),概念结构设计,(,自底向上,),图7.8 自顶向下需求分析与自底向上设计概念结构,常用策略（P211图7.8）,自顶向下进行需求分析,自底向上设计概念结构,自底向上设计概念结构的步骤 （P211图7.9）,第1步：抽象数据并设计局部视图,第2步：集成局部视图，得到全局概念结构,图7.9 自底向上方法的设计步骤,需求分析,数据抽象、,局部视图设计,视图集成,征求用户意见,DFD、DD,局部ER图,全局ER图,逻辑结构设计,概念结构是对现实世界的一种抽象,从实际的人、物、事和概念中抽取所关心的,共同特性,，忽略非本质的细节,把这些特性用各种概念精确地加以描述,这些概念组成了某种模型,三种常用抽象,1. 分类（Classification,）,定义某一类概念作为现实世界中一组对象的类型,这些对象具有某些共同的特性和行为,它抽象了对象,值和型,之间的“is member of”的语义,在E-R模型中，实体型就是这种抽象,例：P212图7.10,一、数据抽象,学 生,张英 王平 刘勇 赵亮,7.3.3 数据抽象与局部视图设计,2,. 聚集（Aggregation）,定义某一类型的组成成分,它抽象了对象内部类型和成分之间“is part of”的语义,在E-R模型中若干属性的聚集组成了实体型，就是这种抽象,例：P212图7.11，图7.12,3. 概括（Generalization,）,定义类型之间的一种子集联系,它抽象了类型之间的“is subset of”的语义,概括有一个很重要的性质：继承性。子类继承超类上定义的所有抽象。,例：P213图7.13,注：,原E-R模型不具有概括，本书对E-R模型作了扩充，允许定义超类实体型和子类实体型。,用双竖边的矩形框表示子类，,用直线加小圆圈表示超类-子类的联系,仓库号,面积,主任,仓库,姓名,年龄,性别,工资,图7.12 更复杂的聚集,学 生,学号,姓名,专业,班级,实体型,属性,图7.11 聚集,本科生,学 生,研究生,“is subset of ”,图7.13 概括,数据抽象的用途,对需求分析阶段收集到的数据进行分类、组织（聚集），形成,实体,实体的属性，标识实体的码,确定实体之间的联系类型(1:1，1:n，m:n),二、局部视图设计,设计分E-R图的步骤:,选择局部应用,逐一设计分E-R图, 选择局部应用,需求分析阶段，已用多层,数据流图,和,数据字典,描述了整个系统。,设计分E-R图首先需要根据系统的具体情况，在多层的数据流图中,选择,一个,适当层次的数据流图,，让这组图中每一部分对应一个局部应用，然后以这一层次的数据流图为出发点，设计分E-R图。,通常以中层数据流图作为设计分E-R图的依据。,原因：,高层数据流图只能反映系统的概貌,中层数据流图能较好地反映系统中各局部应用的子系统组成,低层数据流图过细,实例:某工厂的信息管理系统,物资管理子系统,销售管理子系统,人事管理子系统,设计E-R图的出发点,图7.14 设计分E-R图的出发点, 逐一设计分E-R图,任务,标定局部应用中的实体、属性、码，实体间的联系,将各局部应用涉及的数据分别从,数据字典,中抽取出来，参照,数据流图,，标定各局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1，1:n，m:n）,如何抽象实体和属性,实体：,现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of的关系。,例：在学校环境中，可把张三、李四等对象抽象为学生实体。,属性：,对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of的关系。,例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码,如何区分实体和属性,实体与属性是相对而言的,。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。,例：,学校中的系，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时它就需要作为实体了。,一般原则,属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成。,属性不能与其他实体具有联系。联系只发生在实体之间。,符合上述两条特性的事物一般作为属性对待。,为了简化E-R图的处置，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。,举例,例1：,“学生”由学号、姓名等属性进一步描述，根据准则，“学生”只能作为实体，不能作为属性。,例2：,职称通常作为教师实体的属性，但在涉及住房分配时，由于分房与职称有关，也就是说职称与住房实体之间有联系，根据准则，这时把职称作为实体来处理会更合适些。,图7.15 职称作为一个实体,职工,职工号,姓名,年龄,职称,职工,职称,聘任,n,1,职工号,姓名,性别,年龄,职称代码,工资,住房标准,附加福利,病人,住院号,姓名,病房号,住在,病人,n,1,病房,医疗,医生,住院号,姓名,m,1,图7.16病房作为一个属性或实体,存放,货物,n,m,仓库,货号,单价,仓库号,面积,货物,货号,单价,存放仓库号,存量,图7.17,仓库作为一个属性或实体,存放,货物,n,m,仓库,管理,职工,货号,单价,1,n,仓库号,面积,设计分E-R图的步骤,（1）,以,数据字典,为出发点定义E-R图。,数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合,（2）,按上面给出的准则进行必要的调整。,例:销售子系统分E-R图的设计,第一层数据流图(P216 图7.18),第二层数据流图(P216 图7.19图7.22),存放,顾客,1,n,应付帐款,支付,订单,订单,？,？,分析数据字典整个系统功能围绕“订单”和“应收帐款的处理,数据结构中订单、顾客、顾客应付帐目用的最多，是许多子功能共享的数据，因此先设计分E-R的草图（P218 图7.32),逐一设计分E-R图（例）,顾客,1.0,接收订单,已批准订单,2,.0,处理订单,顾客账目状况,应收账款,产品描述,订单细节,3,.0,开发票,订单记录本,包装通知单,结算数据,主管,部门,主管部门,批准,/,不批准,核对订,单数据,生产,部门,生产通知单,准备发货细节,应收账款,发票,4,.0,支付过账,调整,未付差,额调整,5,.0,提供应,收账款,应收账款报表,财务费,用变动,当前价格,订单数据,批准,/,不批准,图,7,.,18,销售管理子系统第一层数据流图,逐一设计分E-R图（例）,1.1,核对价格,产品描述,主管,部门,顾客,订单数据,已核对价,格的订单,1.,2,核对账,目状况,1.,3,批准订单,账目状况已核对的订单,已批准的订单,当前价格,应收账款,顾客账,目状况,批准,/,不批准,主管部门,批准,/,不批准,核对订单数据,图,7.19,接收订单,逐一设计分E-R图（例）,图7.20 处理订单,图7.21 开发票,图7.22 支付过账,图中在订单实体与产品实体之间的问号“？”,表示还不能确定这两个实体之间的联系类型,。然后参照第二层数据流图和数据字典中的详尽描述，遵循前面给出的两个准则，进行如下调整：,订单应作为实体,零件号+数量+,订单：订单号,+,若干头信息,+,订单细节,+,每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则（2），订单细节就不能作订单的属性处理而应该上升为实体。一张订单可以订若干产品，所以订单与订单细节两个实体之间是1,n,的联系。,原订单和产品的联系实际上是订单细节和产品的联系,发票清单是否作为实体？,否，因为该信息在应收帐款中体现了,折扣规则实体体现各种商品不同数量的折扣。,通过调整得到分E-R图如下：,支付,顾客,1,n,应付帐款,订货,订单,组成,订单细节,参照2,产品描述,参照1,折扣规则,1,n,1,n,n,n,1,1,图7.24 销售子系统的分E-R图,每个实体定义的属性如下；,顾客：,顾客号，顾客名，地址，电话，信贷状况，帐目余额,订单：,订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点,订单细则：,订单号，细则号，零件号，订货数，金额,应收帐款：,顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额,折扣规则,：,产品号，订货量，折扣,7.3.4 视图的集成,各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。,视图集成的两种方式,一次集成（P219图7.25(a)）,一次集成多个分E-R图，通常用于局部视图比较简单时。,逐步集成（P220图7.25(b)）,首先集成两个局部视图（通常是比较关键的两个局部视图）以后每次将一个新的局部视图集成进来,第1种方法比较复杂，做起来难度较大。,第2种方法每次只集成两个分E-R图，可以降低复杂度。,集成局部E-R图的步骤,1. 合并,2. 修改与重构,分析,规范化,理论,集成,视图,基本,E-R,图,分,E-R,图,修改与重构,(,消除不必,要的冗余,),初步,E-R,图,合并,(,消除冲突,),图7.26 视图的集成,一、合并分E-R图，生成初步E-R图,各分图存在冲突,各个局部应用所面向的问题不同，并且通常由不同的设计人员进行设计，所以各个分E-R图之间必定会存在许多不一致的地方，称之为冲突。,合并分E-R图的主要工作与关键所在：合理消除各分E-R图的冲突。,冲突的种类,属性冲突,命名冲突,结构冲突, 属性冲突,两类属性冲突,属性域冲突,：属性值的类型、取值范围或取值集合不同。,例如：零件号（C/N）年龄（D/N）,属性取值单位冲突：,例如：零件的重量（公斤/克）,属性冲突的解决方法,通常用讨论、协商等行政手段加以解决。, 命名冲突,两类命名冲突,同名异义,：不同意义的对象在不同的局部应用中具有相同的名字。,异名同义（一义多名）,：同一意义的对象在不同的局部应用中具有不同的名字,例如：有的部门把科研项目称项目 有的部门则把科研项目称课题,命名冲突可能发生在属性级、实体级、联系级上。其中属性的命名冲突更为常见。,命名冲突的解决方法,通过讨论、协商等行政手段加以解决, 结构冲突,三类结构冲突,同一对象在不同应用中具有不同的抽象,例，“课程”在某一局部应用中被当作实体在另一局部应用中则被当作属性,解决方法：,通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。变换时要遵循,7.3.3,两个准则。,同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同,。,产生原因,：不同的局部应用关心的是该实体的不同侧面。,解决方法：,使该实体的属性取各分E-R图中属性的,并集,，再适当设计属性的次序。,实体之间的联系在不同局部视图中呈现不同的类型,解决方法：根据应用语义对实体联系的类型进行综合或调整。(P221图7.27),例如:,图7.27 合并两个分E-R图的综合,二、消除不必要的冗余，设计基本E-R图,1 冗余,所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。,合并,解决冲突,初步E-R图,分E-R图,可能存在冗余的数据,和冗余的实体间联系,基本E-R图,消除不必要的冗余,冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难,并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。,设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。,消除不必要的冗余后的初步E-R图称为基本E-R图,。,2消除冗余的方法,1) 分析方法,以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。,如果是为了提高效率，人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。,一种更好的方法是把冗余数据定义在视图中。,图7.28 消除冗余,消除不必要的冗余,冗余 Q3=Q1 Q2 Q4=Q5 允许冗余 提高某些应用响应时间Q4保留，Q4=Q5是完整性约束条件。并且由于Q,3,消去，产品与材料间mn的冗余联系也应消去。,2) 规范化理论,函数依赖的概念提供了消除冗余联系的形式化工具。,方法,(1),确定分E-R图实体之间的数据依赖,F,L,。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。,(2),求,F,L,的最小覆盖,G,L,，,差集为：,D,=,F,L,-,G,L,。,逐一考察,D,中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。,由于规范化理论受到泛关系假设的限制，应注意下面两个问题：,(1) 冗余的联系一定在D中，而D中的联系不一定是冗余的；,(2) 当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。,6. 最小依赖集,定义5.15 如果函数依赖集F满足下列条件，则称F为一个,极小函数依赖集,。亦称为,最小依赖集,或,最小覆盖,。,(1) F中任一函数依赖的右部仅含有一个属性。,(2) F中不存在这样的函数依赖XA，使得F与,F-XA等价。,(3) F中不存在这样的函数依赖XA， X有真子集Z,使得 F-XAZA与F等价。,例,2 对于5.1节中的关系模式,S,，其中：,U,= SNO，SDEPT，MN，CNAME，G ，,F,= SNOSDEPT，SDEPTMN，,（SNO，CNAME）G ,设F,=SNOSDEPT，SNOMN，,SDEPTMN，(SNO，CNAME)G，,(SNO，SDEPT)SDEPT,F,是最小覆盖，而,F ,不是。,因为：,F ,-SNOMN与,F,等价,F ,-(SNO，SDEPT)SDEPT也与,F,等价,F ,-(SNO，SDEPT)SDEPT,SNOSDEPT也与,F,等价,实例：某工厂信息管理系统的视图集成。,图1.14,工厂物资管理系统,职工,职工号,姓名,年龄,职称,(a),实体及其属性图,零件号,名称,规格,单价,描述,零件,预算,项目,项目号,开工日期,地址,供应商号,姓名,电话号,账号,供应商,仓库,仓库号,面积,电话号,图1.14,工厂物资管理系统,供应商,m,供应,供应量,项目,n,仓库,库存,零件,m,n,p,工作,1,n,职工,库存量,领导,1,n,(b)实体及其联系图,图1.14 工厂物资管理系统E-R图,供应商,姓名,供应商号,地址,账号,电话号,仓库,仓库号,面积,电话号,职工号,姓名,年龄,职工,工作,1,n,领导,1,n,库存,供应量,m,供应,库存量,m,项目,项目号,预算,开工日期,n,零件,零件号,规格,名称,描述,单价,n,p,(C)完整的实体联系图,职称,部门,1,n,职工,n,1,项目,m,1,图 7.29 劳动人事管理的分,E-R,图,生产,属于,负责,天数,实例：某工厂信息管理系统的视图集成。,支付,顾客,1,n,应付帐款,订货,订单,组成,订单细节,参照2,产品描述,参照1,折扣规则,1,n,1,n,n,n,1,1,图7.24 销售子系统的分E-R图,图1.14(c)、图7.24、图7.29分别为该厂,物资,、,劳动人事,和,销售管理,的分E-R图。把这3个分E-R图进行集成过程中解决了以下问题：,（1）异名同义，“,项目”和“产品”,含义相同。某个“项目”实质上是指某个“产品”的生产。统一用“产品”作实体名。,（2）库存管理中,职工与仓库,的工作关系已包含在劳动人事管理部门与职工之间的联系之中，所以可以取消。职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。,图7.30为该系统的基本E-R图。基本E-R图中各实体的属性因篇幅有限这里从略。,部门,属于,天数,1,n,职工,参加,负责,n,1,产品,m,1,领导,1,1,供应商,供应,n,供应量,零件,m,p,参照,2,1,库存,库存量,m,订单细节,n,仓库,n,n,组成,订单,1,n,订货,顾客,1,支付,1,n,应收款,参照,1,1,n,折扣规则,图,6. 30,某工厂管理信息系统的基本,E-R图,三、验证整体概念结构,视图集成后形成一个,整体的数据库概念结构,，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件：,整体概念结构内部必须具有一致性，不存在互相矛盾的表达。,整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系。,整体概念结构能满足需要分析阶段所确定的所有要求。,整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据,概念结构设计小结,概念结构设计的步骤,抽象数据并设计局部视图,集成局部视图，得到全局概念结构,验证整体概念结构,数据抽象(分类、聚集、概括）,设计局部视图, 选择局部应用, 逐一设计分E-R图,标定局部应用中的实体、属性、码，实体间的联系,用E-R图描述出来,集成局部视图,1.合并分E-R图，生成初步E-R图,消除冲突（属性冲突、命名冲突、结构冲突）,2. 修改与重构,消除不必要的冗余，设计生成基本E-R图,分析方法,规范化理论,7.4 逻辑结构设计,逻辑结构设计的任务,概念结构是各种数据模型的共同基础,为了能够用某一DBMS实现用户需求，还必须将概念结构进一步转化为相应的数据模型，这正是,数据库逻辑结构,设计所要完成的任务。,逻辑结构设计的步骤,将概念结构转化为一般的关系、网状、层次模型,将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换,对数据模型进行优化,逻辑结构设计,转化为一般数据模型,转化为特定DBMS支持下的据模型,优化模型,概念结,构设计,数据库,物理设计,基本E-R图,转换规则,特定DBMS的特点与限制,优化方法如规范化理论,逻辑,模型,图7.31 逻辑结构设计时的三个步骤,7.4.1 E-R图向关系模型的转换,转换内容,E-R图由实体、实体的属性和实体之间的联系三个要素组成；,关系模型的逻辑结构是一组关系模式的集合；,将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。,转换原则, 一个,实体型,转换为一个关系模式。,关系的属性：,实体型的属性,关系的码：,实体型的码,例，职工实体可以转换为如下关系模式：,职工（,职工号,，部门号，姓名，职务，性别，出生日期）,职工,职工号,姓名,性别,职务,出生日期,部门号, 一个,m:n联系,转换为一个关系模式。,关系的属性：,与该联系相连的各实体的码以及联系本身的属性,关系的码,：,各实体码的组合,例 “选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：,选修（,学号，课程号,，成绩）, 一个,1:n联系,可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。,1) 转换为一个独立的关系模式,关系的属性：,与该联系相连的各实体的码以及联系本身的属性,关系的码：,n端实体的码,2) 与n端对应的关系模式合并,合并后关系的属性：,在n端关系中加入1端关系的码和联系本身的属性,合并后关系的码：,不变,可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。, 一个,1:1,联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并,。,1) 转换为一个独立的关系模式,关系的属性：,与该联系相连的各实体的码以及联系本身的属性,关系的候选码：,每个实体的码均是该关系的候选码,2) 与某一端对应的关系模式合并,合并后关系的属性：,加入对应关系的码和联系本身的属性,合并后关系的码：,不变, 三个或三个以上实体间的一个,多元联系,转换为一个关系模式。,关系的属性：,与该多元联系相连的各实体的码以及联系本身的属性,关系的码：,各实体码的组合,例，“供应”联系是一个三元联系，可以将它转换为如下关系模式，其中产品号、供应商号和零件号为关系的组合码：,供应,（,产品号，供应商号，零件号,，供应量）, 同一实体集的实体间的联系，即,自联系,，,也可按上述1:1、1:n和m:n三种情况分别处理。,例 如果职工实体集内部存在领导与被领导的1:n自联系，我们可以将该联系与职工实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分：,职工：,职工号,，部门号，姓名，性别，职称，出生日期，,部门领导, 具有相同码的关系模式可合并。,目的：,减少系统中的关系个数,。,合并方法：,将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。,下面把图7.30中虚线上部的E-R图转换为一组关系模式。关系模式的码用下横线标出,。,部门,（,部门号,，部门名，经理的职工号，）,此为部门实体对应的关系模式。该关系模式已包含了联系“领导”所对应的关系模式。经理的职工号是关系的候选码。,职工,（,职工号,，部门号，职工名，职务，）,此为职工实体对应的关系模式。该关系模式已包含了联系“属于”所对应的关系模式。,产品,（,产品号,，产品名，产品组长的职工，）,此为产品实体对应的关系模式。,供应商,（,供应商号,，姓名，）-此为供应商实体对应的关系模式。,零件,（,零件号,，零件名，）-此为零件实体对应的关系模式。,职工工作,（,职工号，产品号,，工作天数，）,此为联系“参加”所对应的关系模式。,供应,（,产品号，供应商号，零件号,，供应量）,此为联系“供应”所对应的关系模式。,向特定DBMS规定的模型进行转换,一般的数据模型还需要向特定DBMS规定的模型进行转换。,转换的主要依据是所选用的DBMS的功能及限制。没有通用规则。,对于关系模型来说，这种转换通常都比较简单。,7.4.2 数据模型的优化,数据库逻辑设计的结果不是唯一的。,得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。,关系数据模型的优化通常以规范化理论为指导。,数据模型的优化（方法）, 确定数据依赖,按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。, 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。, 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。, 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。,并不是规范化程度越高的关系就越优。,当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行,联接运算,，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。,非BCNF,的关系模式虽然从理论上分析会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。,对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。, 按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率。,常用分解方法,水平分解,垂直分解,水平分解,什么是水平分解,把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。,水平分解的适用范围,1. 满足“80/20原则”的应用,80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20%，把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。,2.并发事务经常存取不相交的数据,如果关系,R,上具有,n,个事务，而且多数事务存取的数据不相交，则,R,可分解为少于或等于,n,个子关系，使每个事务存取的数据对应一个关系。,垂直分解,什么是垂直分解,把关系模式R的属性分解为若干子集合，形成若干子关系模式。,垂直分解的原则,经常在一起使用的属性从R中分解出来形成一个子关系模式。,垂直分解的优点,可以提高某些事务的效率,垂直分解的缺点,可能使另一些事务不得不执行连接操作，从而降低了效率。,垂直分解的适用范围,取决于分解后R上的所有事务的总效率是否得到了提高。,进行垂直分解的方法,简单情况：直观分解,复杂情况：用第五章中的模式分解算法,垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。,7.4.3 设计用户子模式,将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体RDBMS的特点，设计,用户的外模式,。,目前关系数据库管理系统一般都提供了视图（View）概念，可以利用这一功能设计更符合局部用户需要的用户外模式。,定义数据库模式,主要是从系统的时间效率、空间效率、易维护等角度出发。,由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以考虑用户的习惯与方便。包括三个方面：,7.4.3 设计用户子模式,(1) 使用更符合用户习惯的别名,合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。,当然，为了应用的规范化，我们也不应该一味地迁就用户。,(2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。,例如，有关系模式：,产品（,产品号,，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级）,可以在该关系模式上建立两个视图：,为一般顾客建立视图：,产品1（,产品号,，产品名，规格，单价）,为产品销售部门建立视图：,产品2（,产品号,，产品名，规格，单价，车间，生产负责人）,(3) 简化用户对系统的使用,如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。,逻辑结构设计小结,任务将概念结构转化为具体的数据模型,逻辑结构设计的步骤,将概念结构转化为一般的关系、网状、层次模型；,将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；,对数据模型进行优化；,设计用户子模式。,E-R图向关系模型的转换内容,将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。,逻辑结构设计小结,E-R图向关系模型的转换原则, 一个,实体型,转换为一个关系模式。, 一个,m:n联系,转换为一个关系模式。, 一个,1:n联系,可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。, 一个,1:1联系,可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。,三个或三个以上实体间的一个,多元联系,转换为一个关系模式。, 同一实体集的实体间的联系，即,自联系,，也可按上述1:1、1:n和m:n三种情况分别处理。, 具有,相同码,的关系模式可合并。,逻辑结构设计小结,优化数据模型的方法, 确定数据依赖, 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。, 确定各关系模式分别属于第几范式。, 分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。, 对关系模式进行必要的分解或合并,设计用户子模式,1. 使用更符合用户习惯的别名,2. 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。,3. 简化用户对系统的使用,7.5 数据库的物理设计,数据库在物理设备上的,存储结构与存取方法,称为数据库的物理结构，它依赖于给定的计算机系统。,为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。,数据库物理设计的步骤,确定数据库的物理结构,对物理结构进行评价，评价的重点是时间和空间效率,如果评价结果满足原设计要求则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。,数据库物理设计,确定数据库的物理结构,评价数据库的物理结构,逻辑结,构设计,数据库,实施,物理,模型,逻辑,模型,7.5.1 数据库的物理设计的内容和方法,一、设计数据库物理结构的准备工作,1