第7章 数据库设计优秀课件.ppt

第第7章章 数据库设计数据库设计第1页，本讲稿共102页7.1 数据库设计介绍数据库设计介绍 合理的数据库结构是数据库应用系统性能良好的基础和保证,但数据库的设计和开发却是一项庞大而复杂的工程。从事数据库设计的人员,不仅要具备数据库知识和数据库设计技术,还要有程序开发的实际经验,掌握软件工程的原理和方法；数据库设计人员必须深入应用环境,了解用户具体的专业业务；在数据库设计的前期和后期,与应用单位人员密切联系,共同开发,可大大提高数据库设计的成功率。第2页，本讲稿共102页7.1.1数据库设计的一般策略数据库设计的一般策略有两种：自顶向下（TopDown）和自底向上（BottomUp）。自顶向下是从一般到特殊的开发策略。它是从一个企业的高层管理着手,分析企业的目标、对象和策略,构造抽象的高层数据模型。然后逐步构造越来越详细的描述和模型（子系统的模型）。模型不断地扩展细化,直到能识别特定的数据库及其应用为止。第3页，本讲稿共102页自底向上的开发采用与抽象相反的顺序进行。它从各种基本业务和数据处理着手,即从一个企业的各个基层业务子系统的业务处理开始,进行分析和设计。然后将各子系统进行综合和集中,进行上一层系统的分析和设计,将不同的数据进行综合。最后得到整个信息系统的分析和设计。这两种方法各有优缺点。在实际的数据库设计开发过程中,常常把这两种方法综合起来使用。第4页，本讲稿共102页7.1.2数据库设计的步骤在确定了数据库设计的策略以后,就需要相应的设计方法和步骤。多年来,人们提出了多种数据库设计方法,多种设计准则和规范。数据库是某个企业、组织或部门所涉及的数据的综合,它不仅反映数据本身的内容,而且反映数据之间的联系。在数据库中,是用数据模型来抽象、表示、处理现实世界中的数据和信息的。根据模型应用的不同目的,我们将数据模型分成两个层次：概念模型和具体的（如关系）数据模型。第5页，本讲稿共102页概念模型是用户和数据库设计人员之间进行交流的工具,数据模型是由概念模型转化而来,是按照计算机系统的观点来对数据建模。产生具体数据模型的数据库设计即为逻辑设计。1978年10月召开的新奥尔良（NewOrleans）会议提出的关于数据库设计的步骤,简称新奥尔良法,是目前得到公认的,较完整较权威的数据库设计方法,它把数据库设计分为如下四个主要阶段：第6页，本讲稿共102页(1)用户需求分析。(2)信息分析和定义（概念设计）：视图模型化；视图分析和汇总。(3)设计实现（逻辑设计）：模式初始设计；子模式设计；应用程序设计；模式评价；模式求精。第7页，本讲稿共102页(4)物理设计。当各阶段发现不能满足用户需求时,均需返回到前面适当的阶段,进行必要的修正。如此经过不断的迭代和求精,直到各种性能均能满足用户的需求为止。数据库设计一般应包括数据库的结构设计和行为设计两部分内容。所谓数据库的结构设计,是指系统整体逻辑模式与子模式的设计,是对数据的分析设计；数据库的行为设计,是指施加在数据库上的动态操作（应用程序集）的设计,是对应用系统功能的分析设计。第8页，本讲稿共102页虽然,数据库行为设计与一般软件工程的系统设计,产生模块化程序的过程是一致的,并且,从学科划分的范畴来看,它更偏重于软件设计。但是,在系统分析中,过早地将“数据分析”和“功能分析”进行分离是不明智的,也是不可能的。因为数据需求分析是建立在功能分析上的,只有通过功能分析,才能产生系统数据流程图与数据字典,然后才通过数据分析去划分实体与属性等,最后才能进入结构设计。目前,较多的数据库设计专家认为,数据库结构设计的基本步骤应如图71所示。第9页，本讲稿共102页图71专家认同的数据库结构设计的基本步骤第10页，本讲稿共102页在任一设计阶段,一旦发现不能满足用户数据需求时,均需返回到前面的适当阶段,进行必要的修正。经过如此的迭代求精过程,直到能满足用户需求为止。在进行数据库结构设计时,应考虑满足数据库中数据处理的要求,将数据和功能两方面的需求分析、设计和实现在各个阶段同时进行,相互参照和补充。第11页，本讲稿共102页事实上,数据库设计中,对每一个阶段设计成果都应该通过评审。评审的目的是确认某一阶段的任务是否全部完成,从而避免出现重大的错误或疏漏,保证设计质量。评审后还需要根据评审意见修改所提交的设计成果,有时甚至要回溯到前面的某一阶段,进行部分重新设计乃至全部重新设计,然后再进行评审,直至达到系统的预期目标为止。第12页，本讲稿共102页7.1.3数据库设计的主流方法从20世纪70年代末以来,众多学者对数据库设计方法进行了深入的探讨和尝试,给出了许多各有优缺点的数据库设计方法,有基于ER模型的数据库设计方法,基于3NF的设计方法,基于抽象语法规范的设计方法等,较实用的主流方法有以下两种：1.ER模型加规范化关系的方法在数据库结构设计中,主要工作是从需求分析所得到的所有信息以及它们之间的依赖关系出发,去构造系统数据模型。在构模中,最常用的是ER模型法。第13页，本讲稿共102页ER模型中最基本的成分是实体、联系以及它们的属性。而由实体（或联系）与属性构成的关系,因为是否“规范化”而有“好”、“坏”之分,而关系的好坏又直接影响数据库的质量。所以,把ER模型与规范化关系结合起来,形成了目前最为流行的数据库构模方法。本章介绍概念结构设计时,采用了此方法。第14页，本讲稿共102页2数据元素图加规范化关系的方法需求分析中得到的每一种信息,称为数据元素。数据元素图指系统所涉及的数据元素信息（包括：数据元素名、类型、字节长度、可能的别名、有效取值范围等）以及数据元素之间的依赖关系。用数据元素图及数据元素之间的关联类型的分析来归并实体,并且产生部分实体之间的联系,这种方法称为数据元素图法（也称为数据项图法）。把数据元素图法与规范化关系有机结合起来,也是一种较实用的构模方法。采用这种方法,不必再经过ER模型转换成规范化的关系,而直接根据作图法获得规范化的关系,有时也被称为“扩充数据元素图法”。第15页，本讲稿共102页7.1.4数据库设计的基本概念数据库设计中将会用到很多基本概念和术语,下面分别加以介绍：(1)需求分析：数据库设计人员采用一定的辅助工具对应用对象的功能、性能、限制等要求所进行的科学分析。(2)概念设计：对应用对象精确地抽象、概括而形成的独立于计算机系统的企业信息模型。描述概念模型的最好工具是ER图。第16页，本讲稿共102页(3)逻辑设计：将抽象的概念模型转化为与选用的DBMS产品所支持的数据模型相符合的逻辑模型,它是物理设计的基础。(4)物理设计：逻辑模型在计算机中的具体实现方案。(5)数据字典（DD：DataDictionary）：关于数据的信息集合。它包含了应用对象和DBMS运行时所需的控制和管理信息的信息库。它既可为用户服务,又可为系统服务。第17页，本讲稿共102页数据字典在需求分析阶段建立,在数据库设计过程中被不断修改、充实和完善。(6)数据流程图（DFD：DataFlowDiagram）：也称为数据流图,是便于用户理解的系统数据流程的图形表示,能精确地在逻辑上描述系统的功能、输入、输出和数据存储。该工具用于需求分析中。第18页，本讲稿共102页7.2 需求分析需求分析需求分析是数据库设计的第一阶段,本阶段所得的结果是下一阶段系统的概念结构设计的基础。如果需求分析有误,则以它为基础的整个数据库设计将成为毫无意义的工作。而需求分析也是数据库设计人员感觉最繁琐和困难的一步。第19页，本讲稿共102页数据库需求分析和一般信息系统的系统分析,基本上是一致的。但是,数据库需求分析所收集的信息,却要详细得多,不仅要收集数据的型（包括数据的名称、数据类型、字节长度等）,还要收集与数据库运行效率、安全性、完整性有关的信息,包括数据使用频率、数据间的联系以及对数据操纵时的保密要求等等。第20页，本讲稿共102页7.2.1需求调查需求调查是指,为了彻底了解原系统的全部概况,系统分析师和数据库设计人员深入到应用部门,和用户一起调查和收集原系统所涉及的全部数据。需求调查要明确的问题很多,大到企业的经营方针策略、组织结构,小到每一张票据的产生、输入、输出、修改、查询等。重点是以下几个方面：(1)信息要求。用户需要对哪些信息进行查询和分析,信息与信息之间的关系如何等。第21页，本讲稿共102页(2)处理要求。用户需要对信息进行何种处理,每一种处理有哪些输入、输出要求,处理的方式如何,每一种处理有无特殊要求等。(3)系统要求：安全性要求：系统有几种用户使用,每一种用户的使用权限如何。使用方式要求：用户的使用环境是什么,平均有多少用户同时使用,最高峰时有多少用户同时使用,有无查询相应的时间要求等。可扩充性要求：对未来功能、性能和应用访问的可扩充性的要求。第22页，本讲稿共102页需求调查的方法主要有：(1)阅读有关手册、文档及与原系统有关的一切数据资料。(2)与各种用户（包括企业领导、管理人员、操作员）交谈。每个用户所处的地位不同,对新系统的理解和要求也不同。与他们进行交谈,可获得在查阅资料时遗漏的信息。(3)跟班作业。有时用户并不能从信息处理的角度来表达他们的需求,需要分析人员和设计人员亲自参加他们的工作,了解业务活动的情况。第23页，本讲稿共102页(4)召集有关人员讨论座谈。可按职能部门召开座谈会,了解各部门的业务情况及对新系统的建议。(5)使用调查表的形式调查用户的需求。需求调查的方法很多,常常综合使用各种方法。对用户对象的专业知识和业务过程了解得越详细,为数据库设计所作的准备就越充分。确信没有漏掉大的方面。并且设计人员应考虑到将来对系统功能的扩充和改变,尽量把系统设计得易于修改。第24页，本讲稿共102页7.2.2需求分析需求调查所得到的数据可能是零碎的、局部的,分析师和设计人员必须进一步分析和表达用户的需求。需求分析的具体任务是：(1)分析需求调查得到的资料,明确计算机应当处理和能够处理的范围,确定新系统应具备的功能。(2)综合各种信息所包含的数据,各种数据之间的关系,数据的类型、取值范围、流向。第25页，本讲稿共102页(3)将需求调查文档化,文档既要为用户所理解,又要方便数据库的概念结构设计。需求分析的结果应及时与用户进行交流,反复修改,直到得到用户的认可。在数据库设计中,数据需求分析是对有关信息系统现有数据及数据间联系的收集和处理,当然也要适当考虑系统在将来的可能需求。一般地,需求分析包括数据流的分析及功能分析。功能分析是指系统如何得到事务活动所需要的数据,在事务处理中如何使用这些数据进行处理（也叫加工）,以及处理后数据流向的全过程的分析。换言之,功能分析是对所建数据模型支持的系统事务处理的分析。第26页，本讲稿共102页数据流分析是对事务处理所需的原始数据的收集及经处理后所得数据及其流向。一般用数据流程图（DFD）来表示。DFD不仅指出了数据的流向,而且还指出了需要进行的事务处理（但并不涉及如何处理,这是应用程序的设计范畴）。在需求分析阶段,应当用文档形式整理出整个系统所涉及的数据、数据间的依赖关系、事务处理的说明和所需产生的报告,并且尽量借助于数据字典（DD）加以说明。除了使用数据流程图、数据字典以外,需求分析还可使用判定表、判定树等工具。下面介绍数据流程图和数据字典,其他工具的使用可参见软件工程等方面的参考书。第27页，本讲稿共102页1.数据流程图（DFD）数据流程图的符号说明如下：数据流代表数据流,箭头表示数据流动的方向加工或称为处理,代表数据的处理逻辑文件或称为数据库存储文件,代表数据存储外部实体代表系统之外的信息提供者或使用者第28页，本讲稿共102页(1)数据流：由一组确定的数据组成。数据流用带名字的箭头表示,名字表示流经的数据,箭头则表示流向。例如,“成绩单”数据流由学生名、课程名、学期、成绩等数据组成。(2)加工：是对数据进行的操作或处理。加工包括两方面的内容：一是变换数据的组成,即改变数据结构；二是在原有的数据内容基础上增加新的内容,形成新的数据。例如,在学生学习成绩管理系统中,“选课登记”是一个加工,它把学生信息和开课信息进行处理后生成学生的选课清单。第29页，本讲稿共102页(3)文件：数据暂时存储或永久保存的地方。如：学生表、开课计划表。(4)外部实体：指独立于系统而存在的,但又和系统有联系的实体。它表示数据的外部来源和最后的去向。确定系统与外部环境之间的界限,从而可确定系统的范围。外部实体可以是某种人员、组织、系统或某事物。例如,在学生学习成绩管理系统中,家长可作为外部实体存在,因为家长不是该系统要研究的实体,但它可以查询本系统中有关的学生成绩。第30页，本讲稿共102页构造DFD的目的是使系统分析师与用户进行明确的交流,指导系统设计,并为下一阶段的工作打下基础。所以DFD既要简单,又要容易被理解。构造DFD通常采用自顶向下、逐层分解,直到功能细化为止,形成若干层次的DFD。如图72是学校成绩管理系统的第一层数据流程图。如果需要,还可以对其中的三个处理过程分别作第二层数据流程图。第31页，本讲稿共102页图72成绩管理的第一层数据流程图（部分）第32页，本讲稿共102页2.数据字典（DD）数据字典是以特定格式记录下来的,对数据流程图中各个基本要素（数据流、文件、加工等）的具体内容和特征所作的完整的对应和说明。数据字典是对数据流程图的注释和重要补充,它帮助系统分析师全面确定用户的要求,并为以后的系统设计提供参考依据。数据字典的内容包括：数据项、数据结构、数据流、加工、文件、外部实体等,一切在数据定义需求中出现的名称都必须有严格的说明。在数据库设计过程中,数据字典被不断地充实、修改、完善。第33页，本讲稿共102页下面以成绩管理数据流图中几个元素的定义加以说明：（1）数据项名：成绩别名：分数描述：课程考核的分数值定义：数值型,带一位小数取值范围：0100（2）数据结构名：成绩单别名：考试成绩描述：学生每学期考试成绩单定义：成绩清单=学生号+开课号+学期+考试成绩第34页，本讲稿共102页（3）加工名：选课登记处理输入数据流：学期、学生号、开课号、课程号输出数据流：选课清单加工逻辑：把选课者的学生号、所处的学期号、以及所选的开课号、课程号记录进数据库中处理频率：根据学校的学生人数而定,具有集中性第35页，本讲稿共102页（4）文件名：学生信息表简述：用来记录学生的基本情况组成：记录学生各种情况的数据项,如学生号、姓名、性别、政治面貌、专业、班级号等读文件：提供各项数据的显示,提取学生的信息写文件：对学生情况的修改、增加或删除第36页，本讲稿共102页这一阶段的主要任务有：(1)确认系统的设计范围；(2)调查信息需求、收集数据；(3)分析、综合系统调查得到的资料；(4)建立需求说明文档、数据字典、数据流程图。与本阶段同步,对数据处理的同步分析应产生：数据流程图、判定树（判定表）以及数据字典中对处理过程的描述。第37页，本讲稿共102页7.3 概念结构设计概念结构设计 概念结构设计的目标是产生反映系统信息需求的数据库概念结构,即概念模式。概念结构是独立于支持数据库的DBMS和使用的硬件环境的。此时,设计人员从用户的角度看待数据以及数据处理的要求和约束,产生一个反映用户观点的概念模式,然后再把概念模式转换为逻辑模式。各级模式之间的关系如图73所示。第38页，本讲稿共102页图73数据库各级模式第39页，本讲稿共102页描述概念结构的模型应具有以下几个特点：(1)有丰富的语义表达能力。能表达用户的各种需求,反映现实世界中各种数据及其复杂的联系,及用户对数据的处理要求等。(2)易于交流和理解。概念模型是系统分析师、数据库设计人员和用户之间的主要交流工具。(3)易于修改。概念模型能灵活地加以改变,以反映用户需求和环境的变化。第40页，本讲稿共102页(4)易于向各种数据模型转换。设计概念模型的最终目的是向某种DBMS支持的数据模型转换,建立数据库应用系统。传统的数据模型（层次、网状、关系）,由于缺乏必要的语义表达手段,不适合作概念模型。人们提出了多种概念设计的表达工具,其中最常用、最有名的是ER模型。在需求分析中,我们已初步得到了有关各类实体、实体间的联系以及描述它们性质的数据元素,统称数据对象。第41页，本讲稿共102页在这一阶段中,首先要从以上数据对象中确认出：系统有哪些实体？每个实体有哪些属性？哪些实体间存在联系？每一种联系有哪些属性？然后就可以作出系统的局部ER模型和全局ER模型。在第5章中,我们已详细讨论了建立ER模型、从局部ER图生成全局ER图的基本方法,这里主要介绍业务规则的文档化。从ER模型中可以获得实体、实体间的联系等信息,但不能得到约束实体处理的业务规则。第42页，本讲稿共102页对模型中的每一个实体中的数据所进行的添加、修改和删除,应该符合预定的规则。特别是删除,往往包含着一些重要的业务规则。例：下面是学校图书管理系统中有关读者借阅图书的业务规则：(1)借阅者必需持有图书馆所发的借书证,每张借书证的号码唯一；(2)学生的借书数最高为10本,教职工为20本；第43页，本讲稿共102页(3)学生的借书周期为3个月,教职工为6个月；(4)一旦有图书超期,学生和教职工都不能再借阅任何图书；(5)尚未全部归还图书的学生及教职工不能办离校手续。第44页，本讲稿共102页业务规则是在需求分析中得到的,需要反映在数据库模式和数据库应用程序中。概念结构设计的最后一步是把全局概念模式提交评审。评审可分为用户评审和DBA及设计人员评审两部分。用户评审的重点是确认全局概念模式是否准确完整地反映了用户的信息需求,以及现实世界事务的属性间的固有联系；DBA和设计人员的评审则侧重于确认全局概念模式是否完整,属性和实体的划分是否合理,是否存在冲突,以及各种文档是否齐全等。第45页，本讲稿共102页本阶段利用需求分析得到的数据流程图等进行工作,主要输出文档为：(1)系统各子部门的局部概念结构描述；(2)系统全局概念结构描述；(3)修改后的数据字典；(4)概念模型应具有的业务规则。与本阶段同步,对数据处理的同步分析应产生系统说明书。系统说明书包括：新系统的要求、方案和概图,反映新系统信息流的数据流程图。第46页，本讲稿共102页7.4 逻辑结构设计逻辑结构设计数据库的逻辑设计就是把概念设计得到的数据库模型,转化为具体的DBMS所能接受的数据库逻辑结构,包括数据库模式和外模式。而目前大多数DBMS支持关系数据模型,所以数据库的逻辑设计,首先是将ER模型转换为等价的关系模式。关系数据库的逻辑结构设计的一般步骤如图74所示。第47页，本讲稿共102页图74关系数据库的逻辑设计步骤第48页，本讲稿共102页从图74可见,逻辑结构设计阶段主要有以下输入信息：(1)概念结构设计阶段的输出信息：所有的局部和全局概念模式。图中用ER模型表示。(2)处理需求：需求分析阶段产生的业务活动分析结果。包括：用户需求、数据的使用频率和数据库的规模。(3)DBMS特性：即特定的DBMS所支持的数据结构。如RDBMS的数据结构是二维表。第49页，本讲稿共102页本阶段需完成的任务有：(1)将ER模型转换为等价的关系模式。（2）按需要对关系模式进行规范化。（3）对规范化后的模式进行评价。调整关系模式,使其满足性能、存储空间等方面的要求。（4）根据局部应用的需要,设计用户外模式。第50页，本讲稿共102页ER模型向关系模式的转换和关系模式的规范化我们已分别在第5章、第6章中讨论过,这里简要介绍模式评价、关系模式的调整和外模式的设计。必须指出,本书介绍的数据库设计方法,是针对事务型数据库。对事务型数据库采用规范化关系,可以提高数据库的设计质量；对于工程型的数据库（工程数据库）,规范化关系却不一定是好的,有时非规范化的模型反而更为适宜。近年来,工程数据库正在发展,其数据模型和相应的设计方法,都还处于研究阶段。第51页，本讲稿共102页7.4.1模式评价模式评价可检查规范化后的关系模式,是否满足用户的各种功能要求和性能要求,并确认需要修正的模式部分。1功能评价关系模式中,必须包含用户可能访问的所有属性。根据需求分析和概念结构设计文档,如果发现用户的某些应用不被支持,则应进行模式修正。但涉及多个模式的联接应用时,应确保联接具有无损性。否则,也应进行模式修正。第52页，本讲稿共102页对于检查出有冗余的关系模式和属性,应分析产生的原因,是为了提高查询效率或应用扩展的“有意冗余”,还是某种疏忽或错误造成的。如果是后一种情况,应当予以修正。问题的产生可能在逻辑设计阶段,也可能在概念设计或需求分析阶段。所以,有可能需要回溯到上两个阶段进行重新审查。第53页，本讲稿共102页2性能评价对数据库模式的性能评价是比较困难的,因为缺乏相应的评价手段。一般采用LRA评价技术进行估算,以提出改进意见。LRA是“逻 辑 记 录 存 取”（Logical RecordAccess）的缩写,它主要用于估算数据库操纵的逻辑记录传送量及数据的存储空间。此算法由美国密执安大学的T.Teorey和J.Fry于1980年提出的。第54页，本讲稿共102页7.4.2逻辑模式的修正修正逻辑模式的目的是改善数据库性能、节省存储空间。在关系模式的规范化中,很少注意数据库的性能问题。一般认为,数据库的物理设计与数据库的性能关系更密切一些,事实上逻辑设计的好坏对它也有很大的影响。除了性能评价提出的模式修正意见外,还可以考虑以下几个方面：1.尽量减少连接运算在数据库的操作中,连接运算的开销很大。参与连接的关系越多、越大,开销也越大。第55页，本讲稿共102页所以,对于一些常用的、性能要求比较高的数据查询,最好是单表操作。这与规范化理论相矛盾。有时为了保证性能,不得不把规范化了的关系再连接起来,即反规范化。当然这将带来数据的冗余和潜在的更新异常的发生。需要在数据库的物理设计和应用程序中加以控制。2.减小关系的大小和数据量关系的大小对查询的速度影响也很大。有时为了提高查询速度,可把一个大关系从纵向或横向划分成多个小关系。第56页，本讲稿共102页例如学生关系,可以把全校学生的数据放在一个关系中,也可以按系建立学生关系。前者方便全校学生的查询,而后者可以提高按系查询的速度。也可以按年份建立学生关系,如在一些学校的学生学籍成绩管理系统中,有在校学生关系和已毕业学生关系。这些都属于对关系的横向分割。有时关系的属性太多,可对关系进行纵向分解,将常用和不常用的属性分别放在不同的关系中,可以提高查询关系的速度。第57页，本讲稿共102页3.选择属性的数据类型关系中的每一属性都要求有一定的数据类型,为属性选择合适的数据类型不但可以提高数据的完整性,还可以提高数据库的性能,节省系统的存储空间。(1)使用变长数据类型当数据库设计人员和用户不能确定一个属性中数据的实际长度时,可使用变长的数据类型。现在很多DBMS都支持以下几种变长数据类型：Varbinary（）、Varchar（）和Nvarchar（）。第58页，本讲稿共102页使用这些数据类型,系统能够自动地根据数据的实际长度确定数据的存储空间,大大提高存储效率。(2)预期属性值的最大长度在关系的设计中,必须能预期属性值的最大长度,只有知道数据的最大长度,才能为数据定制最有效的数据类型。第59页，本讲稿共102页例如,在SQLServer中,若关系中一属性表示人的年龄,可以为该属性选择tinyint类型(2字节)；而如果属性表示书的页数,就可选择smallint（4字节）类型。(3)使用用户自定义的数据类型如果使用的DBMS支持用户自定义数据类型,则利用它可以更好地提高系统性能。因为这些类型是专门为特定的数据设计的,能够有效地提高存储效率，保证数据安全。第60页，本讲稿共102页7.4.3设计用户外模式外模式也叫子模式,是用户可直接访问的数据模式。同一系统中,不同用户可有不同的外模式。外模式来自逻辑模式,但在结构和形式上可以不同于逻辑模式,所以它不是逻辑模式简单的子集。在第1章中,我们已经讨论了外模式的作用,主要有：通过外模式对逻辑模式的屏蔽,为应用程序提供了一定的逻辑独立性；可以更好地适应不同用户对数据的需求；为用户划定了访问数据的范围,有利于数据的保密等。第61页，本讲稿共102页在关系型DBMS中,都提供了视图的功能。利用这一功能,设计更符合局部用户需要的视图,再加上与局部用户有关的基本表,就构成了用户的外模式。在设计外模式时,可参照局部ER模型,因为ER模型本来就是用户对数据需求的反映。与本阶段同步,对数据处理的同步分析应产生：系统结构图（或称模式结构图）。第62页，本讲稿共102页7.5 物理结构设计物理结构设计 数据库物理结构设计阶段将根据具体计算机系统（DBMS与硬件等）的特点,为给定的数据模型确定合理的存储结构和存取方法。为设计数据库物理结构,设计人员必须充分了解所用DBMS的内部特征；充分了解数据库的应用环境,特别是数据应用处理的频率和响应时间的要求；充分了解外存储设备的特性。数据库物理结构设计的环境如图75所示。第63页，本讲稿共102页图75数据库物理结构设计环境第64页，本讲稿共102页数据库物理结构主要由存储记录格式、记录在物理设备上的安排及访问路径（存取方法）等构成。7.5.1存储记录结构设计存储记录结构包括记录的组成、数据项的类型、长度和数据项间的联系,以及逻辑记录到存储记录的映射。在设计记录的存储结构时,并不改变数据库的逻辑结构。但可以在物理上,对记录进行分割。数据库中数据项的被访问频率是很不均匀的。基本上符合公认的“80%20规则”,即“从数据库中检索的80%的数据由其中的20%的数据项组成”。第65页，本讲稿共102页当多个用户同时访问常用数据项时,会因访盘冲突而等待。如果将这些数据分布在不同的磁盘组上,当用户同时访问时,系统可并行地执行I/O,减少访盘冲突,提高数据库的性能。所以对于常用关系,最好将其水平分割成多个裂片,分布到多个磁盘组上,以均衡各个磁盘组的负荷,发挥多磁盘组并行操作的优势。第66页，本讲稿共102页目前,数据库系统一般都拥有多个磁盘驱动器,如,现在使用较多的是廉价冗余磁盘阵列（RAID：RedundantArrayofInexpensiveDisks）。数据在多个磁盘组上的分布,叫做分区设计（PartitionDesign）。利用分区设计,可以减少磁盘访问冲突,均衡I/O负荷,提高I/O的并行性。所以,数据库的性能不但决定于数据库的设计,还与数据库系统的运行环境有关。例如,系统是多用户还是单用户,数据库的存储是在单个磁盘上还是磁盘组上,等等。第67页，本讲稿共102页7.5.2存储记录布局存储记录的布局,就是确定数据的存放位置。存储记录作为一个整体,如何分布在物理区域上,是数据库物理结构设计的重要一环。聚簇功能可以大大提高按聚簇码进行查询的效率。例如,有一职工关系,现要查询1970年出生的职工,假设全部职工元组为10000个,分布在100个物理块中。其中1970年出生的职工有100个。考虑以下几种情况：第68页，本讲稿共102页(1)设：属性“出生年月”上没有建任何索引,100个1970年出生的职工就分布在100个物理块中（这是最极端的情况,但很有可能）。系统在做此类查询时需要：扫描全表,访问数据需要100次I/O,因为每访问一个物理块需要一次I/O操作。对每一个元组需要比较出生年月的值。(2)设：属性“出生年月”上建有一普通索引,100个1970年出生的职工就分布在100个物理块中。查询时,即使不考虑访问索引的I/O次数,访问数据也要100次I/O操作。第69页，本讲稿共102页(3)设：属性“出生年月”上建有一聚簇索引,100个1970年出生的职工就分布在i（I100，很可能就等于1）个连续的物理块中,显著地减少了访问磁盘I/O的次数。聚簇功能不但可用于单个关系,也适用于多个关系。设有职工表和部门表,其中部门号是这两个表的公共属性。如果查询涉及到这两个表的连接操作,可以把部门号相同的职工元组和部门元组在物理上聚簇在一起,既可显著提高连接操作的速度,又可节省存储空间。第70页，本讲稿共102页任何事物都有两面性,聚簇对于某些特定的应用可以明显地提高性能,但对于与聚簇码无关的查询却毫无益处。相反地,当表中数据有插入、删除、修改时,关系中有些元组就要被搬动后重新存储,所以建立聚簇的维护代价是很大的。在以下情况下可以考虑建立聚簇：(1)聚簇码的值相对稳定,没有或很少需要进行修改；(2)表主要用于查询,并且通过聚簇码进行访问或连接是该表的主要应用；(3)对应每个聚簇码值的平均元组数既不太多,也不太少。第71页，本讲稿共102页7.5.3存取方法的设计存取方法是为存储在物理设备（通常是外存储器）上的数据提供存储和检索的能力。存取方法包括存储结构和检索机制两部分。存储结构限定了可能访问的路径和存储记录；检索机制定义每个应用的访问路径。存取方法是快速存取数据库中数据的技术。数据库系统是多用户共享系统,对同一个关系建立多条存取路径才能满足多用户的多种应用要求。为关系建立多种存取路径是数据库物理设计的另一个任务。在数据库中建立存取路径最普遍的方法是建立索引。第72页，本讲稿共102页索引是用于提高查询性能的,但它要牺牲额外的存储空间和提高更新维护代价。因此要根据用户需求和应用的需要来合理使用和设计索引。所以正确的索引设计是比较困难的。索引从物理上分为聚簇索引和普通索引。确定索引的一般顺序是：(1)首先可确定关系的存储结构,即记录的存放是无序的,还是按某属性（或属性组）聚簇存放。这在前面已讨论过,这里不再重复。第73页，本讲稿共102页(2)确定不宜建立索引的属性或表。凡是满足下列条件之一的,不宜建立索引：太小的表。因为采用顺序扫描只需几次I/O,不值得采用索引。经常更新的属性或表。因为经常更新需要对索引进行维护,代价较大。属性值很少的表。例如“性别”,属性的可能值只有两个,平均起来,每个属性值对应一半的元组,加上索引的读取,不如全表扫描。过长的属性。在过长的属性上建立索引,索引所占的存储空间较大,有不利之处。第74页，本讲稿共102页一些特殊数据类型的属性。有些数据类型上的属性不宜建立索引,如：大文本、多媒体数据等。不出现或很少出现在查询条件中的属性。(3)确定宜建立索引的属性。凡是满足下列条件之一的,可以考虑在有关属性上建立索引：关系的主码或外部码一般应建立索引。因为数据进行更新时,系统将对主码和外部码分别作唯一性和参照完整性的检查,建立索引,可以加快系统的此类检查,并且可加速主码和外部码的连接操作。第75页，本讲稿共102页对于以查询为主或只读的表,可以多建索引。对于范围查询（即以=、等比较符确定查询范围的）,可在有关的属性上建立索引。使用聚集函数（Min、Max、Avg、Sum、Count）或需要排序输出的属性最好建立索引。以上仅仅是建立索引的一些理由。一般地,索引还需在数据库运行测试后,再加以调整。第76页，本讲稿共102页在RDBMS中,索引是改善存取路径的重要手段。使用索引的最大优点是可以减少检索的CPU服务时间和I/O服务时间,改善检索效率。如果没有索引,系统只能通过顺序扫描寻找相匹配的检索对象,时间开销太大。但是,不能在频繁作存储操作的关系上,建立过多的索引。因为,当进行存储操作（增、删、改）时,不仅要对关系本身作存储操作,而且还要增加一定的CPU开销,修改各个索引。因此,关系上过多的索引会影响存储操作的性能。第77页，本讲稿共102页7.6 数据库实施和维护数据库实施和维护在数据库正式投入运行之前,还需要完成很多工作。比如,在模式和子模式中加入数据库安全性、完整性的描述,完成应用程序和加载程序的设计,数据库系统的试运行,并在试运行中对系统进行评价。如果评价结果不能满足要求,还需要对数据库进行修正设计,直到满意为止。数据库正式投入使用,也并不意味着数据库设计生命周期的结束,而是数据库维护阶段的开始。第78页，本讲稿共102页7.6.1数据库实施根据逻辑和物理设计的结果,在计算机上建立起实际的数据库结构,并装入数据,进行试运行和评价的过程,叫做数据库的实施（或实现）。一、建立实际的数据库结构用DBMS提供的数据定义语言（DDL）,编写描述逻辑设计和物理设计结果的程序（一般称为数据库脚本程序）,经计算机编译处理和执行后,就生成了实际的数据库结构。第79页，本讲稿共102页所用DBMS的产品不同,描述数据库结构的方式也不同。有的DBMS提供数据定义语言DDL,有的提供数据库结构的图形化定义方式,有的两种方法都提供。在定义数据库结构时,应包含以下内容：1数据库模式与子模式,以及数据库空间等的描述模式与子模式的描述主要是对表和视图的定义,其中应包括索引的定义。索引在具体的DBMS中有聚簇与非聚簇、压缩与非压缩等之分。第80页，本讲稿共102页使用不同的DBMS,对数据库空间描述的差别较大。比如,在Oracle系统中,数据库逻辑结果的描述包括表空间（Tablespace）、段（Segment）、范围（Extent）和数据块（Datablock）。DBA或设计人员通过对数据库空间的管理和分配,可控制数据库中数据的磁盘分配，将确定的空间份额分配给数据库用户,控制数据的可用性,将数据存储在多个设备上,以提高数据库性能等。而在SQLServer7.0中,数据库空间描述可以简单得多,可以只定义数据库的大小、自动增长的比例,以及数据库文件的存放位置。第81页，本讲稿共102页2数据库完整性描述所谓数据的完整性,是指数据的有效性、正确性和一致性。在数据库设计时如果没有一定的措施确保数据库中数据的完整性,就无法从数据库中获得可信的数据。数据的完整性设计,应该贯穿在数据库设计的全过程中。如,在数据需求分析阶段,收集数据信息时,应该向有关用户调查该数据的有效值范围。第82页，本讲稿共102页在模式与子模式中,可以用DBMS提供的DDL语句描述数据的完整性。虽然每一种DBMS提供的DDL语句功能都有所不同,但一般都提供以下几种功能：(1)对表中列的约束,包括：列的数据类型、对列值的约束。其中对列值的约束又有：非空约束（NotNull）、唯一性约束（Unique）,主码约束（PrimaryKey）,外部码约束（ForeignKey）,域（列值范围）的约束（如：18职工年龄65）(2)对表的约束。主要有表级约束（多个属性之间的）和外部码的约束。第83页，本讲稿共102页(3)多个表之间的数据一致性。主要是外部码的定义。现在有些DBMS产品提供了用来设计表间一对一、一对多关系的图表工具,如：Access 2000的EditRelationships和MSSQLServer的Diagram数据库组件、VFP的数据库设计器等。(4)对复杂的业务规则的约束。第84页，本讲稿共102页一些简单的业务规则可以定义在列和表的约束中,但对于复杂的业务规则,不同的DBMS有不同的处理方法。对数据库设计人员来说,可以采用以下几种方法：利用DBMS提供的触发器等工具,定义在数据库结构中；写入设计说明书,提示编程人员以代码的形式在应用程序中加以控制；写入用户使用手册,由用户来执行。第85页，本讲稿共102页触发器是一个当预定事件在数据库中发生时,可被系统自动调用的SQL程序段。比如在学校学生成绩管理数据库中,如果一个学生退学,删除该学生记录时,应同时删除该学生在选课表中的记录。可以在学生表上定义一删除触发器来实现这一规则。在多数情况下,尽可能让DBMS实现业务规则,因为DBMS对定义的规则只需编码一次。如果由应用程序实现,则应用程序的每一次应用都需编码,这将影响系统的运行效率,还可能存在施加规则的不一致性。如果由用户在操作时控制,是最不可靠的。第86页，本讲稿共102页3数据库安全性描述使用数据库系统的目的之一,就是实现数据的共享。因此,应从数据库设计的角度,确保数据库的安全性。否则,需要较高保密度的部门将会不愿意纳入数据库系统。数据安全性设计同数据完整性设计一样,也应在数据库设计的各个阶段加以考虑。在进行需求分析时,分析人员除了收集信息及数据间联系的信息之外