数据库技术基础实践 6

第7章

数据库设计本章内容7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5物理结构设计7.6数据库的实施与维护7.1数据库设计概述7.1数据库设计概述数据库是长期存储在计算机内，有组织、大量共享的数据集合。它可以供各种用户共享，具有最小冗余度和较高的数据独立性。数据库管理系统是在数据库建立、运行和维护时，对数据库进行统一控制，以保证数据的完整性和安全性，并在多用户同时使用数据库时进行并发控制，在发生故障后对数据库进行恢复。7.1数据库设计概述目前数据库已应用于各类系统，通常把使用数据库的各类信息系统统称为数据库应用系统。常见的数据库应用系统有管理信息系统（ManagementInformationSystem，MIS）、决策支持系统（Decision-makingSupportSystem，DSS）、办公自动化系统（OfficeAutomationSystem，OA）、地理信息系统（GeographicInformationSystem或Geo－Informationsystem，GIS）、电子政务系统（E-governmentSystem）等。7.1数据库设计概述广义地讲，数据库设计是数据库及其应用系统的设计，即设计整个数据库应用系统；狭义地讲，数据库设计是设计数据库本身，即设计数据库的各级模式并建立数据库，是数据库应用系统设计的一部分。我们重点讲解狭义的数据库设计，即对于一个给定的应用环境，构造(设计)优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求。7.1数据库设计概述要建立一个数据库应用系统，我们需要选定并组织开发小组人员，根据数据处理的规模及对应用系统的性能要求等，选择合适的计算机硬件配置如数据库服务器的选型、网络配置如公网（广域网）或私网（本地局域网）、软件环境配置如操作系统等，并在此基础上完成整个应用系统的设计工作。数据库建设是涉及多学科的综合性技术，包括数据库应用系统从设计、实施到运行与维护的全过程。数据库的创建是一项软件工程，要尽量把软件工程的原理技术和方法应用到数据库建设中。如何建立一个高效适用的数据库应用系统是数据库应用领域研究的一个主要课题。与一般软件系统设计相比，数据库应用系统与应用环境联系紧密，应用系统的信息结构复杂，加上数据库系统本身的复杂性，数据库设计具有其自身的特点。7.1.1数据库设计特性1.技术、管理与基础数据缺一不可建设一个好的数据库应用系统，不仅涉及开发技术，还涉及到管理。管理不仅包括数据库建设作为一个大型的工程项目本身的项目管理，还包括该企业应用部门的业务管理。对业务流程模拟的精确程度越高，形成的数据模式越能反映现实的业务水平。对数据库应用系统来说，管理的数据量大，数据间的联系越复杂，数据有越多的用户共享，因此数据是数据库运行的基础，在数据库设计中基础数据的作用非常关键。结构设计指数据结构的设计，好的数据库结构是应用系统的基础。结构设计在模式和外模式中定义，包括数据库的概念设计，逻辑设计和物理设计，这个过程涉及实体和属性及相互的联系、域和完整性约束等，最终建立数据库。行为设计是指确定数据库用户的行为和动作，即对数据库的操作，这些操作通过应用程序实现包括功能组织，流程控制等方面的设计。2.结构设计与行为设计的结合3.多学科的综合数据库设计是一项复杂的工程，是涉及多学科的综合性技术。它要求设计人员不但要具有数据库的基础知识和数据库设计技术，熟悉DBMS，而且要有应用领域方面的知识。数据库设计人员一般需要具备的知识和能力包括计算机基础知识、软件工程的原理和方法、程序设计的方法和技巧、数据库的基础知识、用户界面设计相关技术以及应用领域知识等。7.1.2数据库设计方法与常用工具1.数据库设计方法（1）新奥尔良（NewOrleans）法（2）基于E-R模型的设计方法（3）3NF（第三范式）设计方法（4）面向对象的数据库设计方法（5）统一建模语言（UnifiedModelLanguage，UML）2.常用工具（1）PowerDesigner（2）ERwinDataModeler早期数据库设计中，数据库设计的好坏完全取决于设计人员的经验和水平，缺乏科学依据，因而很难保证设计的质量。伴随着数据库系统的规模越来越大，需要处理的信息越来越多，更多的实践证明，数据库设计应分阶段进行，并在此过程中进行阶段评审，以便及时发现错误及时纠正。按照结构化系统设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护6个阶段。7.1.3数据库设计的基本步骤图7-1数据库设计步骤7.1.3数据库设计的基本步骤此外，数据库设计过程中各个阶段的数据具有独特的特征。7.2需求分析7.2需求分析

需求分析是数据库设计的首要任务，也是后续设计工作的基础。需求分析的重点是调查收集并分析客户业务的数据需求，处理安全性和完整性需求。这一阶段的主要任务是通过调查，详细了解用户的每一个业务过程和活动的工作流程以及信息处理流程，准确理解用户对信息系统的需求，使需求分析尽可能充分与准确。需求分析结果是否准确，将直接影响到后面各阶段的设计，并影响到设计结果。需求是用户要求数据库应用系统必须满足的所有功能和限制，它包括功能要求、性能要求、可靠性要求、安全性和完整性要求等限制，其中功能要求又包括信息要求和处理要求。需求分析就是通过与用户的沟通和交流，获取用户的需求，并对需求进行分析和整理，最终形成需求文档。需求分析阶段的主要目标是通过对企业组织架构、业务活动的详实调查，尽可能准确地确认用户需求，确定应用系统功能，收集和分析需求数据，最终撰写需求说明书。需求分析的目标总体上分为三类：信息要求、处理要求、安全性与完整性要求。7.2.1需求分析的目标7.2.1需求分析的目标（1）信息要求：指数据库中存储信息的内容与性质，明确数据库的输入、输出数据及数据间的联系。（2）处理要求：指要完成的数据处理功能及对处理性能的要求。例如描述操作的优先次序，操作的执行频率和场合，操作与数据间的联系，每种处理的执行频度，用户需求的响应时间及处理方式等。（3）安全性与完整性要求：安全性要求描述系统中不同用户对数据库的使用和操作情况，完整性要求描述数据之间的关联关系及数据的取值范围等。需求分析阶段的输出是需求说明书。需求说明书是用户和开发设计人员达成的技术协议书，是进行设计工作的基础和依据，并在系统开发完成以后，为产品的验收提供依据。需求说明书是对需求分析工作的全面总结，它详细定义了信息流、系统功能、设计要求和限制、测试准则和质量保证要求。7.2.1需求分析的目标需求分析阶段的最终目标是清晰地了解用户的实际需求并形成需求文档。首先，要了解企业的管理模式、组织架构和经营理念，理清各个部门的职责范围和主要业务活动。然后，针对具体的业务活动开展详细的调研，调研的重点包括各部门输入和使用什么数据；如何加工、处理这些数据；输出什么信息，输出到哪些部门，输出结果的格式是什么等等。在此过程中，可以根据不同的问题和条件，使用不同的调研方法。常用的调研方法有：查阅记录文档、问卷调查、座谈、跟班作业等。7.2.2用户需求调研的方法7.2.2用户需求调研的方法查阅记录文档即查阅与原系统有关的数据记录，通过检查相关的文档、表格、报告和文件，进一步理解原系统，并可以发现与原系统问题相关的业务信息。问卷调查根据用户的职责范围、业务工作目标、业务处理过程、与其他业务工作的联系等方面设计问卷，请用户填写。座谈座谈的对象必须具有代表性、普遍性。座谈的目标是标识业务功能、各功能所处理的逻辑和使用的数据、执行管理等功能的明显或潜在规律。跟班作业设计开发人员需深入参与用户的业务活动，掌握业务流程中发生的各类事件，收集相关资料。调查了解用户需求以后，需要进一步分析和表达用户的需求。结构性分析（StructuredAnalysis，SA）方法是面向过程的分析方法，它把分析对象抽象成一个系统，然后自顶向下逐层分解，用数据流图（DataFlowDiagram,DFD）、数据字典（DataDictionary，DD）描述系统组成及各部分之间的关系。7.2.3需求分析的方法1.数据流图（DataFlowDiagram,DFD）数据流图（DataFlowDiagram,DFD）是从“数据”和“处理”两个方面，直观表达数据处理流程的一种图形化表示方法。DFD有4个基本要素，外部实体、数据流、数据处理和数据存储。（1）外部实体包括数据来源和数据输出，表示系统数据的外部来源和去向，也可以是另外一个系统，用方框表示。（2）数据流由数据组成表示数据的流向，通常用能够反映其含义的名称命名，用箭头表示。1.数据流图（DataFlowDiagram,DFD）DFD基本要素（3）数据处理：指对数据的逻辑处理，也就是数据的变换，用圆圈表示。（4）数据存储：数据保存位置的逻辑描述，用双线段表示。

学生选课的数据流图见图7-2。图7-2“学生选课”数据流图2.数据字典（DataDictionary，DD）数据字典（DataDictionary，DD）也称为系统目录，用于记录元数据。元数据（metadata）是关于数据的数据，例如关系名、属性名和类型、存储信息、完整性约束以及用户信息等。数据字典是进行详细的数据收集和数据分析所获得的主要成果，在需求分析阶段建立，在数据库设计过程中被不断修改、充实完善，占有重要的地位。作为结构化分析方法的一种工具，数据字典用来描述数据流图中出现的所有数据，以使DFD中的数据处理过程和数据存储得到详尽的描述。数据字典通常包括数据项，数据结构，数据流，数据存储和处理过程几部分。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义，来描述数据流、数据存储和逻辑内容。2.数据字典（DataDictionary，DD）数据项：不可再分的数据单位。数据项描述={数据项名称，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}其中，“取值范围”与“其他数据上的逻辑关系”，定义了数据的完整性约束条件，如该数据项等于其他几个数据项的和、等于另一个数据项的值等，是设计数据检验功能的依据。可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。（1）数据项数据项示例：“学号”的数据项数据项名称：学号数据项含义说明：唯一标识学生个体别名：学生编号数据类型：字符型长度：10取值范围：0000000000-9999999999取值含义：入学年份（2位）-专业（2位）-系代码（2位）-班级代码（2位）-号码（2位）与其他数据项的逻辑关系：主码或外码（1）数据项数据结构：反映数据之间的组合关系数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。数据结构描述={数据结构名称，含义说明，组成：{数据项或数据结构}}例：“学生”的数据结构数据结构名称：学生含义说明：“学生管理”子系统的主体数据结构，定义了一个学生的相关信息组成：{学号，姓名，性别，出生年月，年级，系别，专业} （2）数据结构数据流：数据结构在系统内传输的路径。数据流描述={数据流名称，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}其中，“数据流来源”说明该数据流来自哪个过程，“数据流去向”说明该数据流将到哪个过程去，“平均流量”是指在单位时间（天、周、月）里的传输次数。（3）数据流数据流示例：“学生选课”数据流描述

数据流名称：学生选课说明：记录学生选课信息数据流来源：学生选课处理数据流去向：学生选课存储组成：{学号，课程号}平均流量：每天500次（3）数据流数据存储：是数据结构停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或手工拼单，也可以是计算机文档。数据存储描述={数据存储名称，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}其中，“存取频度”包含每小时、每天或每周的存取次数及每次存取的数据量等信息；“存取方式”指是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等。（4）数据存储处理过程处理过程的具体处理逻辑，一般用判定表或判定数来描述。数据字典中只需要描述处理过程的说明性信息即可。处理过程描述={处理过程名称，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}其中，“说明”主要说明该处理过程的功能及处理要求。功能：指该处理过程用来做什么，而不是怎么做。处理要求：处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。（5）处理过程处理过程示例：“学生选课”的处理过程处理过程名称：学生选课说明：学生选择课程输入：学号，课程号输出：学生选课的数据处理：{每学期学生可以从公布的选修课程中选修课程，除选修课程基本要求（如先修课）外，还要保证选修课的上课时间不能与该生必修课时间冲突，每个学生的选修课门数和总学分也应符合学校要求等等。}（5）处理过程需求说明书是在需求分析活动后建立的文档资料，它是对开发项目需求分析的全面描述，是需求分析阶段成果的具体表现。需求说明书需要由用户领导和专家相结合进行评审，是进行数据库评价的依据。需求说明书应包含需求分析的目标和任务、具体需求说明、系统功能和性能、系统运行环境等。此外，还应包括在分析过程中得到的数据流图、数据字典、功能结构图和系统配置图等必要的图表说明。7.2.4需求说明书7.3概念结构设计7.3概念结构设计

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计。需求分析得到的数据描述是无结构的，概念结构设计就是在需求分析的基础上，将其转化为有结构的、易于理解的精确表达。概念模型设计阶段的目标是形成整体数据库的概念结构，它独立于数据库逻辑结构和具体的数据库管理系统概念，是整个数据库设计的关键。逻辑结构与具体的DBMS有关，因而用其描述客观世界将受到一定的限制，用户也不容易理解，用户与设计人员之间不方便交流，当外界环境改变时还需要重新设计数据库的逻辑结构。概念结构设计独立于具体的计算机系统，它以用户能理解的形式表示信息结构，产生一个能反映用户观点的、更接近于现实世界的数据模型，即概念模型。7.3.1概念结构设计的方法概念模型能真实充分的反映现实世界，便于用户理解，且可以很容易地向关系网状层次等多种数据模型转换，简化逻辑设计中由于考虑多种因素带来的复杂性问题。概念模型在客观环境不变的情况下相对稳定，当应用系统需要更换DBMS时，只需重新设计逻辑结构，而概念模型可以保持不变。总之，概念模型是各种数据模型的共同基础，它比数据模型更抽象、更独立于机器、从而更加稳定。7.3.1概念结构设计的方法7.3.1概念结构设计的方法概念结构设计的方法有4种：（1）自底向上。首先定义局部应用的概念结构，然后按一定的规划把它们集成起来，得到全局概念模型，这也是普遍采用的概念模型设计方法。（2）自顶向下。首先定义全局概念结构，然后再逐步细化。一般情况下，需求分析常用此方法。（3）由里向外。首先定义最重要的核心概念结构，然后再逐步向外拓展。（4）混合策略。自顶向下与自底向上结合起来使用。先用自顶向下方法设计一个全局概念结构框架，并将其划分为若干个局部概念结构，再用自底向上的方法将其合并，最终实现全局概念结构。描述概念模型的方法很多，其中最为常用的是P.P.SChen于1976年提出的实体-联系（Entity-Relationship）方法，该方法用E-R图（E-Rdiagram）来描述现实世界的概念模型，E-R方法也称为E-R模型。E-R模型是对组织业务领域数据的一种详细的逻辑表达，表述了业务环境中的实体、实体间的联系，以及实体和实体联系的属性。7.3.2E-R模型E-R图提供了表示实体型、属性和联系的方法。（1）实体型用矩形表示，矩形框内写明实体名；（2）属性用椭圆形表示，并用无向边将其与相应的实体型连接起来；（3）联系用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标注联系的类型（1∶1，1∶n或m∶n）。注意：联系也可以具有属性。7.3.2E-R模型1.实体与属性实体（Entity）是现实世界中可区别于所有其他对象的一个“事物”或“对象”。例如大学中的学生是一个实体、教师是一个实体。每个实体有一组属性，并且某些属性集合的值必须唯一地标识一个实体。例如一名教师拥有教工号属性，由于每名教师的教工号必须不同，因此教工号能唯一标识教师这个实体。实体可以是实在的，也可是抽象的。注意：实体集的属性应该只在其第一次出现时显示一次，后续出现的实体集不应带任何属性，以避免在多个位置重复相同的信息，因为这可能导致数据的不一致性。2.实体与联系实体之间的联系可以分为实体内部的联系和实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常是指不同实体集之间的联系。（1）两实体型之间的联系

一对一联系(1:1)：如果对于实体集A中的每一个实体，实体集B中最多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。（1）两实体型之间的联系

一对一联系(1:1)例如，住院病患在医院中只能申请一张床位，一张床位只能分配给一个病患，则病患与床位之间具有一对一联系。如图7-3所示。图7-3两实体间1:1联系

一对多联系(1:n）：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1∶n。例如，一名员工只能在一个部门任职，而一个部门里有多名员工，则部门与员工之间存在一对多联系。如图7-4所示。（1）两实体型之间的联系图7-4两实体间1:n联系

多对多联系(m:n)：如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m∶n。例如，一门课程可以由多名教师讲授，一名教师可以讲授多门课程，则教师与课程之间存在多对多联系。如图7-5所示。（1）两实体型之间的联系图7-5两实体间m:n联系两个以上的实体型之间，也存在着一对一、一对多、多对多联系。例如，对于供应商、客户和商品三个实体，每个供应商拥有多个客户，每个客户也拥有多个供应商，供应商可以向不同客户提供不同的产品，客户可以从不同的供应商订购不同的商品，因此供应商、客户和商品之间具有多对多联系。如图7-6所示。（2）两个以上实体型之间的联系图7-6三个实体间的多对多联系单个实体型内部，也存在一对一、一对多、多对多的联系。例如，学生实体内部，存在班长领导班级学生，而学生在班级里只被一个班长领导，这是一个典型的一对多联系。如图7-7所示。（3）单个实体型内部的联系图7-7单个实体内部的1对多联系有时，我们把参与联系的实体型的数目称为联系的度。两个实体型之间的联系度为2，也称为二元联系；三个实体型之间的联系度为3，也称为三元联系；N个实体型之间的联系度为N，也称为N元联系2.实体与联系概念结构设计是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成E-R图。首先是建立局部概念模式即局部E-R模型，然后综合局部模式为全局模式，并在此基础上进一步优化，最终得到全局E-R模型，也就是概念模型。7.3.3E-R模型设计步骤确定局部结构的范围。确定范围的方法一种是按照数据库系统用户分类，如以企业的财务部门、销售部门、生产部门、采购部门、技术部门等分类，分别设计局部E-R模型。另一种方法是按照需求对数据库的子功能进行分类，确定每一类应用访问的数据，为每一类应用设计概念模型，即局部E-R模型。确定局部结构时，应尽量将范围划分的自然、界限清晰且相互影响小、易于管理；范围大小要适度，过小会导致设计过程复杂，后期集成及优化困难，过大则容易导致分析困难。1.局部E-R模型设计局部E-R模型的设计过程一般包括以下几个步骤：（1）确定实体从需求分析和局部结构范围出发，分析并确定概念模型所涉及的实体及相应的属性。对实体的命名应尽量反应实体的性质和语义，做到简明清晰，其主码应符合实体完整性规则，可以是单个属性，也可以是属性的组合。（2）确定属性即确定某个概念用实体还是属性表示合适，一个属性是实体的属性还是联系的属性。1.局部E-R模型设计（2）

确定属性实体和属性按照现实世界中事物的自然划分来定义，通常将一组具有某些共同特性和行为的对象抽象为一个实体，将对象的组成成分抽象为实体的属性。为了简化E-R图的处理，现实世界中的事物能够作为属性对待的应尽量作为属性。属性的确定应尽量遵循以下原则：①属性不能再具有需要描述的性质，即属性必须是不可分的数据项，不能再由另一些属性组成。②属性不能与其他实体有联系，即联系只发生在实体之间。因此，一般将属性分配给那些使用频率高或实体值少的实体。1.局部E-R模型设计（3）确定联系联系主要是刻画实体间的关系，分析实体间及实体内部的相互关联，并考察联系的种类是一对一、一对多还是多对多。联系的命名要知名达意，尽量突出联系的特性，防止出现冗余联系。1.局部E-R模型设计图7-8冗余联系示例局部模式反映的是用户的数据观点，而全局概念模式设计是要从全局数据观点出发，进行局部视图的综合和归并，消除不一致和冗余，形成完整的数据库的概念结构。所有的局部E-R模型设计好后，必须合理地表示一个完整、一致的全局E-R模型。2.全局E-R模型设计全局E-R模型设计过程：（1）确定公共实体当系统庞大时，不同的局部E-R模型可能有不同的设计人员确定，这就造成了对同一现实世界对象描述的差异。这种情况下，除了要将同名实体作为公共实体外，还需将具有相同键的实体作为公共实体处理。（2）合并局部E-R模型首先，对于那些在现实世界中有联系的局部结构进行两两合并；其次，合并公共实体；最后，加入独立的结构.。2.全局E-R模型设计全局E-R模型设计过程：（3）检查并消除冲突冲突即各局部E-R模型之间存在的各种不一致情况，一般包括属性冲突、命名冲突和结构冲突。属性冲突指属性值的类型、取值范围或集合不同，一般通过讨论、协商等方式解决。命名冲突一般包含同名异义或者异名同义的情况，命名冲突更为常见，一般也可以通过讨论、协商等方式解决。2.全局E-R模型设计（3）检查并消除冲突结构冲突比较复杂，一般包括：①同一实体面对不同应用时具有不同的抽象，如某应用场景下是实体而其他应用时是属性。②同一实体包含的属性个数或排列不同。③不同局部E-R模型中联系的类型不同，例如对于实体E1和E2之间的联系R1，在局部E-R模型1中是m:n联系，而在局部E-R模型2中是1:n联系；又如在局部E-R模型3中E3和E4之间存在联系，而在局部E-R模型4中是E3、E4和E5之间存在联系。2.全局E-R模型设计（4）模型优化好的E-R模型除了能准确全面反映用户功能需求外，实体和属性的个数应尽可能少，实体间联系也尽可能没有冗余。全局E-R模型优化的原则

合并某些存在1:1联系的实体。

消除冗余属性。对于属性值可由其他属性值导出的属性，可以将其从全局E-R模型中取出。

消除冗余联系。对于全局模型中可能存在的冗余联系，通常利用规范化理论中函数依赖的概念来消除。2.全局E-R模型设计创建E-R模型时，经常存在一些错误。1.使用一个实体集的主码作为另一个实体的属性，而不是使用联系。例如，在描述大学的E-R模型中，存在Student，Department，Instructor等实体，sno，dno，ino分别是三个实体的主码。将dno作为Student的属性不正确，因为这会与Student和Department之间的联系stud-dept的语义信息重复。7.3.4E-R模型设计问题创建E-R模型时，经常存在一些错误。2.将相关实体集的主码作为联系集的属性。例如，对于Student和Instructor之间的联系stud_instr，sno和ino不应该作为stud_instr的属性出现，因为这个联系本身就隐含了这些主码属性。注意：尽管这两个属性会出现在联系stud_instr创建的模式中，但不应该在E-R模型中出现。7.3.4E-R模型设计问题7.3.4E-R模型设计问题(1)实体与属性的选择对于联系方式phone，如果考虑phone的类型，如手机、固定电话，则应该将phone作为实体而不是属性存在，该实体具有phone_number和phone_type两个属性。若将phone作为员工实体的一个属性，则说明每名员工恰好只有一个电话号码；若将phone作为实体则说明允许员工有若干个电话（包括0个）与之关联；当然我们也可以将phone定义为多值属性，允许每名员工有多部电话。7.3.4E-R模型设计问题(2)实体与联系的选择一个对象是被表示成实体还是联系并不绝对。例如：对学生选课进行建模，一种情况我们可以将学生student和课程course分别作为实体，而student_course作为联系存在。当然我们也可以用一个实体集来表示这个联系，如定义选课登记registration实体，registration与course和student之间分别建立联系student_registration和course_registration。显然，这两种方法都可以准确描述学生选课，但是如果某门course分学期开设，即对于course_registration仍有属性period，则显然建立registration实体更合理。(3)二元与N元联系的选择数据库中的联系通常是二元的，一些看起来非二元的联系实际上可以用几个二元联系来表示。例如：创建孩子与父母之间的“亲子”三元联系，其实我们也可以分别创建母子和父子两个二元联系来表示。这样做的好处是，即使我们不知道父亲或母亲的身份，也可以记录单个二元关系，而对于“亲子”三元联系中，必然会出现空值的情况，所以这里使用二元联系更好。7.3.4E-R模型设计问题7.3.4E-R模型设计问题一般情况下，可以用一组不同的二元联系来替代一个非二元的联系集。只需新创建一个实体集E替换原来的非二元联系R，并在E与之前跟R相联系的实体间建立新的联系。利用E-R模型进行数据库的概念结构设计主要是描述目标系统涉及的实体、属性和实体间的联系。这些实体、属性及联系是对现实世界的人、物、事等的抽象，这种抽象是在需求分析的基础上进行的。下面我们给出一个以E-R模型为工具，来模拟TMS学员-培训数据库系统的的学员注册培训课程管理的概念模型。1.确定实体与属性学员注册培训课程的管理过程涉及到以下几个实体：7.3.5E-R模型设计实例7.3.5E-R模型设计实例TMS学员-培训数据库的概念模型（1）course(课程)，属性有：couseid、coursename、description、level、price，分别表示课程编号、课程名称、简介、等级和费用；course的实体属性图如图7-9所示。图7-9course的实体属性图7.3.5E-R模型设计实例（2）base（基地），属性有：baseid、basename、area、address、description，分别表示基地编号、基地名称、区域、地址、简介；base的实体属性图如图7-10所示。图7-10base的实体属性图（3）user（学员），属性有：userid、username、gender、mobile、birthday、degree、major、address，分别表示学员编号、学员姓名、性别、手机号、出生日期、学位、专业、地址；user的实体属性图如图7-11所示。7.3.5E-R模型设计实例图7-11user的实体属性图（4）class（班级），属性有：classid、classname、starttime、endtime、period，分别表示：班级编号、班级名称、开始时间、结束时间、期数；class的实体属性图如图7-12所示。7.3.5E-R模型设计实例图7-12class的实体属性图7.3.5E-R模型设计实例2.确定联系这些实体间的联系如下：（1）一个学员可以选择若干班级，一个班级有若干学员，因此班级与学员之间是多对多联系。（2）班级选择一个基地开课，每个基地可以承办若干培训班级，因此基地和班级之间是一对多联系。（3）每个班级可以包含若干培训课程，每门课程可以被添加到任意班级中，因此班级与课程之间是多对多联系。7.3.5E-R模型设计实例由以上语义分析，得到“班级创建”局部E-R模型，见图7-13所示。图7-13“班级创建”E-R模型7.3.5E-R模型设计实例由以上语义分析，得到“学员选课”局部E-R模型，见图7-14所示。图7-14“学员选课”E-R模型7.3.5E-R模型设计实例将两个局部E-R模型合并后得到全局E-R模型，见图7-15。可以发现，该全局E-R模型实体简单、联系明确，并不存在属性冲突、命名冲突和结构冲突，也没有明显的实体属性或联系的冗余，因此图7-15即为最后的全局E-R模型。图7-15全局E-R模型UML(UnifiedModelingLanguage，UML)是由对象管理组织(ObjectManagementGroup，OMG)主持开发的一项标准，是为软件开发的所有阶段提供模型化和可视化支持的规范语言，用以建立软件系统不同部分的规范定义。UML可以用于数据建模、业务建模、对象建模、组件建模等，也提供了多种类型的模型描述图，借助这些图可以帮助用户更容易理解计算机应用系统开发中的应用程序。7.3.6UML1.UML的模型描述图1.UML的模型描述图一般包括：(1)类图（classdiagram）：与E-R图类似，class对应E-R图中的实体。(2)用例图（usecasediagram）：用于展示用户和系统之间的交互，特别是用户所执行的任务的步骤（如登录、注册流程等）。(3)活动图（activitydiagram）：用于说明系统各部分之间的任务流。(4)实现图（implementationdiagram）：用于在软件构建层和硬件构建层展示系统组成及各组成部分之间的联系。1.UML的模型描述UML为对象建模，E-R为实体建模，对象和实体很像也有属性，除此之外对象还提供一组方法（也叫“函数”），这些方法可以在对象属性的基础上被调用以更新对象或计算出值。类图不但可以说明属性（class）也可以说明方法。由于E-R模型和关系模型都不提供方法，因此在用UML表示E-R图时，我们省略对象方法的说明。此外，在UML术语中，E-R模型中的联系被称为“关联”。（1）实体：用类表示，矩形框中实体名在上部，属性在下方。（2）码：在类图的属性后面加“PK（primarykey）”来表示。（3）联系：用类图之间的“关联”表示，关联的两个类用无向边连接，在连线上方写关联名称；对于非二元关联，用菱形框表示关联，框内写联系名。（4）基数约束：与E-R图中类似，用一个数对“min..max”表示类中的任何一个对象可以在关联中出现的最少和最多次数。例如，0..100、0..*等。2.UML类图表示E-R图方法2.UML类图表示E-R图示例用类图表示E-R图实例，如图7-16所示。图7-16用类图表示E-R图实例7.4逻辑结构设计7.4

逻辑结构设计

由概念建模产生的概念模型完全独立于DBMS及任何其他软件或计算机硬件。该模型必须转换为DBMS支持的逻辑数据结构，并最终实现物理数据库结构。逻辑结构设计的任务，就是把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品支持的数据模型相符合的逻辑结构，即由概念结构导出特定的DBMS可以处理的逻辑结构。7.4

逻辑结构设计由于我们主要介绍的是关系数据库管理系统，因此逻辑结构设计是将E-R图转换为一组关系模式。逻辑结构设计过程可分为以下几步：（1）将E-R图转换为关系模式；（2）优化数据模型；（3）设计用户子模式。7.4.1E-R模型向关系模型的转换一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。实体间的联系转换为关系模式时，应遵循一定的原则。1.两实体间的联系（1）实体间的1:1联系①若转换为一个独立的关系模式：a.关系模式的属性：与该联系相连的各实体的码以及联系本身的属性b.关系模式的候选码：每个实体的码均是该关系模式的候选码7.4.1E-R模型向关系模型的转换实体间的联系转换为关系模式时，应遵循一定的原则。1.两实体间的联系（1）实体间的1:1联系②若与相连的任意一端对应的关系模式合并：a.关系模式的属性：与某一端关系模式合并，则在该关系模式的属性中加入另一端关系模式的码和联系的属性b.合并后关系模式的码：不变1.两实体间的联系（2）实体间的1:N联系①若转换为一个独立的关系模式：a.关系模式的属性：与该联系相连的各实体的码+联系本身的属性b.关系模式的码：N端的实体的码②若与N端对应的关系模式合并（推荐）a.合并后关系模式的属性：在N端关系模式中加入1端关系的码，再加入联系本身的属性b.合并后关系模式的码：不变注意：由于此种方法可以减少系统模式中的关系个数，因此一般情况下更倾向于采用这种方法。1.两实体间的联系（3）实体间的M:N联系一个M:N联系转换为一个关系模式：①关系的属性：与该联系相连的各实体的码+联系本身的属性②关系的码：各实体码的组合三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为联系的属性，各实体的码组成关系的码或关系码的一部分。（1）1:1:1联系在3个实体转换的3个关系模式中的任意一个关系模式属性中加入另外两个关系模式的码（作为外码）和联系的属性。（2）1:1:N联系在N端实体转换的关系模式中加入两个1端实体的码（作为外码）和联系的属性。2.三个或三个以上实体间的一个多元联系（3）1:M:N联系

将联系转换为关系模式，其属性为M端和N端实体的码（作为外码）加上联系的属性；两端实体的码作为该关系模式的码或码的一部分；1端的码可以根据应用的实际情况，加入M端、N端或者联系中作为外码。（4）M:N:P联系

将联系转换为关系模式，其属性为3端实体的码（作为外码）加上联系的属性，各实体的码组成该关系模式的码或码的一部分。2.三个或三个以上实体间的一个多元联系2.三个或三个以上实体间的一个多元联系为减少系统中关系的个数，具有相同码的关系模式可以合并。将其中一个关系模式的全部属性加入到另一个关系模式中；然后去掉其中的同义属性（可能同名也可能不同名）；最后适当调整属性的次序。7.4.2关系模式的优化关系模式优化通常以规范化理论为指导，其优点在于能够消除异常、减少冗余、节约存储空间，降低I/O次数，提升增、删、改速度。但是，并非规范化程度越高的关系越优。例如涉及到两个或多个关系模式的连接运算会造成关系模型低效，这时可以考虑将多关系合并，第二范式甚至是第一范式更加合适。因此，为了提高某些查询或应用的性能，有时会有意破坏规范化规则，这样的做法也叫做“逆规范化”。关系模式优化的一般方法1.考查关系模式是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式，一般先基于3NF进行规范化处理，再根据实际情况对部分关系模式进行逆规范化操作。2.常用的逆规范化方法有增加冗余属性、增加派生属性、重建关系和关系分解等。（1）增加冗余属性为避免查询时的连接操作，在多个关系中加入相同的属性。例如：对于病房管理系统，工作人员需要频繁检索病人所在病房、床位等信息，可以在病人关系中加入病房号和床位号属性，显然这两个属性为冗余属性，但是可以有效避免连接操作。当然，增加冗余属性操作会以牺牲更多的存储空间为代价，增加了表维护的工作量。常用的逆规范化方法（2）增加派生属性为避免连接操作后再使用相对复杂的聚集函数操作，可以增加涉及其他关系中需要参与计算的属性，这种属性称为“派生属性”。例如：如果要计算某病房中的病人总数，则需要在病房关系中增加“入住人数”属性，并在病人关系上建立增删改触发器，以维护病房中“入住人数”的值。增加派生属性与增加冗余属性的缺点类似。常用的逆规范化方法常用的逆规范化方法（3）重建关系如果用户需要经常查看两个关系连接的结果数据，则可以将这两个关系重新组成一个新的关系，提升查询性能。例如：如果要经常查询负责某病人的住院医师信息，则可以建立新的病人关系，并将医生工号和姓名加入新的关系中。常用的逆规范化方法（4）关系分解常用的关系分解方法有水平分解和垂直分解两种。水平分解是按照一定原则如“80/20原则”将元组分为若干个子集合，经常被使用的数据占原来元组的20%左右。垂直分解是把关系模式的属性分为若干个子集合，将经常使用的属性从原属性集中分解出来形成一个子关系模式。这种分解方法需要确保无损连接性和保持函数依赖，可以提高某些事务的效率，但有可能造成不必要的连接操作降低效率，因此是否进行垂直分解取决于分解后的所有事务的总效率是否得到提高。7.4.3逻辑结构设计实例TMS数据库E-R模型向关系模型的转换图7-15全局E-R模型1.E-R图向关系模型的转换（1）将实体转换为关系模式

基地base(baseid,area,basename,address,description)

课程course(courseid,coursename,description,level,price)

班级class(classid,starttime,period,endtime)

学员user(userid,username,gender,mobile,birthday,degree,major,address)1.E-R图向关系模型的转换（2）联系的转换base_class联系根据转换规则，由于联系两端实体是1:N联系，推荐与N端对应的关系模式合并，合并后关系模式的属性包括在N端关系模式中。加上1端关系的码，再加上联系本身的属性，合并后关系模式的码不变。即更新class，添加1端的码baseidclass(classid,baseid,starttime,period,endtime)。图7-17E-R图中的联系对于class_course联系，根据转换规则，由于联系两端实体是M:P联系，关系的属性包括与该联系相连的各实体的码加上联系本身的属性，关系的码为各实体码的组合。即：class_course(classid,courseid)同理，对于M:N联系class_user，应有：class_user(classid,userid,time,payment,check_status)。1.E-R图向关系模型的转换图7-17E-R图中的联系2.关系模式的优化考查每个关系模式并不存在部分函数依赖、传递函数依赖、多值依赖等，因此均属于3NF。根据实际情况对部分关系模式进行逆规范化操作。对于class_course(classid,courseid)，由于我们经常要查看某次培训包含的课程及培训所在地，因此我们增加baseid属性。即class_course(classid,courseid,baseid)3.最终的关系模式

基地base(baseid,area,basename,address,description)

课程course(courseid,coursename,description,level,price)

班级class(classid,baseid,starttime,period,endtime)

学员user(userid,username,gender,mobile,birthday,degree,major,address)

班级课程class_course(classid,courseid,baseid)

学员选班class_user（classid,userid,time,payment,check_status）定义数据库全局模式是从系统的时间效率、空间效率、易维护等角度出发。将概念模型转换为全局逻辑模式后，还应根据局部应用需求和DBMS的特点设计用户的外模式。在设计用户的外模式时，重点应考虑的用户的习惯和便利性，利用视图机制设计外模式。具体包括：1.重定义属性名由于视图是一张虚表，因此在设计视图时使用更符合用户习惯的别名定义属性名，并不影响的数据库的逻辑结构。7.4.4设计用户外模式7.4.4设计用户外模式2.提高安全性为不同级别的用户定义不同的视图，提高系统的安全性。3.简化用户操作某些局部应用中经常要使用多表查询的连接操作和一些如分组、聚集函数查询等相对复杂的查询，如果将这些复杂查询定义为视图，用户可以只对定义好的视图进行查询，将大大简化用户的使用。7.5物理结构设计7.5物理结构设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构。为已确定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理结构设计。数据库物理结构设计的任务是有效的把数据库逻辑结构在物理存储器上加以实现。其目标是在确定的应用环境及软硬件条件下建立具有较高性能的物理数据库。“较高性能”一是指物理数据库应占有较小的存储空间，二是指数据库的操作具有尽可能高的处理速度。合理的物理数据库设计，可以使事务的响应时间缩短、存储空间利用率提高，事务的吞吐量增大。7.5.1物理结构设计的内容和方法首先，要详细分析事务执行所需要的参数；其次，要充分了解所用DBMS的内部特征，特别是系统提供的存取方法和存储结构。数据库的物理结构设计通常分为两步：（1）确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；（2）对物理结构进行评价，评价的重点是时间和空间效率。如果评价结果满足原设计要求，则可进入到物理实施阶段；否则就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。7.5.1物理结构设计的内容和方法7.5.2关系模式存取方法选择数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多应用需求。存取方法是快速存取数据库中数据的技术。DBMS一般提供多种存取方法，常用的存取方法为索引方法和聚簇(clustering)方法。1.索引方法索引（存取）方法，即根据应用要求确定对关系属性列建立索引、唯一索引、组合索引等，经典的索引方法包括B+树索引和Hash索引。在建立索引之前要权衡数据库操作，如果查询多