第3 章 数据库设计技术 本章主要介绍数据库设计的方法和步骤,包括从数据库设计的需求分析开始,到数据库 概念结构设计、逻辑结构设计、物理结构设计以及数据库的实施、运行和维护的整个过程。 如果说第2章学的是数据库设计理论,那么本章介绍的是对这些理论的应用方法。 通过本章的学习,读者可以: . 了解数据库设计的一般步骤,掌握需求分析的过程和方法 . 掌握数据库结构设计的方法,包括概念结构设计、逻辑结构设计和物理结构设计 . 理解数据库的实施、运行和维护方法 图3.1 数据库设计的基本步骤 3.1 数据库设计概述 在应用数据库技术解决实际问题时,需要针对给定应用 环境,构造最优的数据库模式,然后基于该模式创建相应的数 据库及其应用系统,使形成的数据库系统能够有效地进行各 种数据存储和管理任务,满足用户的各种应用需求,而这个过 程就是数据库设计。 一般地,数据库设计是指在现有的应用环境下,从建立问 题的概念模型开始,逐步建立和优化问题的逻辑模型,最后建 立其高效的物理模型,并据此建立数据库及其应用系统,使之 能够有效地收集、存储和管理数据,满足用户的各种应用需 求。简单而言,数据库设计是数据库及其应用系统的设计。 本章介绍的数据库设计主要是针对数据库本身的设计,较少 涉及应用系统的设计。 数据库设计是数据库应用系统开发的关键技术之一,其 最终目的可以归结为两点:(1)满足用户的需求;(2)简化应 用程序的编程设计,实现系统协同、高效的开发,减少开发成 本。从过程看,数据库设计主要分为六个步骤:系统需求分 析、概念结构设计、逻辑结构设计、物理结构设计、数据库实 施、数据库系统运行和维护,各步骤的先后关系如图3.1所 示。其中,对每一个步骤,如果设计结果不满足要求,都有可 能返回前面的任一步骤,直到满足要求为止。 由于实际问题的时空复杂性,数据库设计过程中也存在 第 3 章 数据库设计技术 诸多的不确定因素,加上应用程序运行环境的制约,这就使得数据库设计变得异常复杂。一 般来说,数据库设计不是“一次到位”,而是“认识-设计-纠正-认识”的一种反复并逐步求精的 过程。但是经过长期的积累,人们还是总结了数据库设计有关理论和方法,形成了数据库设 计的一些基本规律,可为实际的数据库设计提供理论和经验参考。 3.系统需求分析 2 系统需求分析首先了解用户需求,然后明确用户需求,最后形成系统需求文字表达(系 统需求分析说明书)的一个过程。系统需求分析的最终结果就是形成一份有效的系统需求 分析说明书。本节将从系统调研过程和方法、系统需求分析所需要的技术和方法以及数据 字典的形成等方面来阐述系统需求分析的过程。 3.2.1 系统调研过程和方法 系统调研也称项目调研,即把系统开发当作项目来运作,其主要目的是通过接触用户以 了解并最终明确用户的实际需求。这个过程是一个系统分析人员理解和掌握用户业务流程 的过程,是一个需要不断与用户进行沟通和磋商的过程。系统调研方法比较灵活,因人、因 系统而异。但大致的调研过程基本一样,可以分为以下几个步骤来完成。 (1)充分了解项目背景以及开发的目的。 (2)深入用户单位(指使用该系统的机构和组织)进行调查,包括了解单位的组织结构、 运作方式,了解各部门的职责和功能。从数据流的角度分析各个部门的特点以及它与其他 部门之间的关系,如各部门的输入(输出)数据及其格式是什么,这些数据来自哪里、去向何 方等,并作相应的记录。 这个步骤是调查的重点,而且难度比较大,其难点在于如何建立与用户理性的沟通渠 道。因为用户与系统分析人员一般都具有不同的技术背景,所以经常导致这种情况的出现: 用户认为已经说清楚了的东西而分析人员也许对之还不能理解,或者用户提出的要求过高, 超出了计算机能够处理的范围等。当出现这种情况时,需要分析人员不断地询问或说明,久 了就会导致用户的厌倦。因此,在进行这项调查前分析人员应该做好充分的准备,例如拟好 调查方案、设计合理而简洁的调查表等。 以下给出了一种调查方法,可供读者参考和选用。 ①单位情况及其运作方式的介绍。第一次到用户单位作现场调查时,系统分析人员都 应同时到场,并邀请单位的相关负责人及各部门负责人就单位情况和各部门运作方式等方 面作一个简要的介绍,回答系统分析人员的一些问题。其目的是使系统分析人员对整个单 位及其各部门的关系有一个初步的理解。 ②对部门工作职能的深入了解。在总体介绍之后,系统分析人员应分头深入各个部门 进行现场观摩,请专人具体介绍,允许的话可进行跟班作业,以准确理解用户的需求。 ③召开调查会。通过对部门的观察后,应该有一个初步的书面总结,这时分析人员也 已经对部门的职责和运作方式有一个较为深入的理解。为验证这个理解的正确程度,通过 询问、讨论、填调查表等方式来召开一次调查会是必要的。但这种调查会召开的次数要严格 控制,一般1、2次为宜,否则会令用户厌倦。 80 数据库原理与应用（第 3 版） ④如果与用户还没有就需求达成共识,相关分析人员可有选择地重复②和③步。 需要提醒的是,不管在什么时候,保持与用户良好的关系都是系统顺利开发的必要 条件 ( 。 3)确定用户需求、明确系统功能和边界。综合各个分析人员的调查结果,形成系统的 功能说明,确定哪些功能是系统要实现的,哪些是不应该实现的,或者是不能实现的。所有 这些结果都应该与用户确认后予以书面形式确定下来。 以上调研结果是下一步设计的前提和基础,任何不准确的结果都会导致开发工作的返 工,增加开发成本。所以,在系统调研时应尽最大的努力作出具有最小误差的调研结果。 3.2.2 系统需求分析的方法 1.SA 方法 在已有调研结果的基础上,运用系统需求分析的各种方法,形成高质量的系统需求说明 书。但这是针对整个系统的设计而言。如果仅针对数据库设计来说,那就是形成用户需求 的有效表达,这种表达在说明书中多以数据流图、数据字典等形式来描述。 用户需求的表达一般是面向系统分析员的。为建立用户需求的表达,可以采用多种 分析方法来完成。这些方法主要包括自顶向下和自底向上两种方法,其中常采用的方法 是自顶向下的结构化分析方法(structuredanalysis,SA )。这种方法的分析过程符合人类 对问题的认识并最终解决问题的一般过程,其分析过程简单、实用,现已在众多领域中得 到应用。其特点可以归结为一棵树的产生过程:先创建树根,然后创建树根节点的子节 点,接着创建各子结点的子节点,直到创建所有的树叶节点为止。在这棵树中,树根节点 相当于整个系统(第一层次上的系统), 其子节点相当于第二层次上的系统,……, 最后层 次上的系统由叶子节点表示,它对系统分析人员是可认知的(认为已经清楚而不必再分 解了)。可见,自顶向下的SA 方法是从整个系统开始,采用逐层分解的方式对系统进行 分析的方法。 例如,当初次面对一个复杂的系统时,我们只能对它有一个初步的了解,比如这个系 统的功能是什么,输入和输出分别是什么;也可能认识得比这个层次稍微细一点,如这个 系统分为几个大的子系统,每个子系统的作用及其关系,以及子系统输入输出情况等。 为寻求对整个系统的全面认识,需要对各子系统作进一步的分解,明确各个子系统的作 用、系统之间的数据流向关系等。这个分解、认识的过程要持续到产生的每个子系统都 能够被分析人员认知为止。基于这种分解的分析方法就是典型的自顶向下的结构化分 析方法。 2. 数据流图 实际上,SA 方法只是对问题分析的一种思想,在具体的分析过程中还需要借助其他的 分析工具,这样才能完成对分析过程和结果的记录、对用户需求的表达等。其中,数据流图 就是最为常用的辅助分析工具和描述手段。 数据流图(dataflowdiagram)是以图形的方式来刻画数据处理系统中信息的转变和传 递过程,是对现实世界中实际系统的一种逻辑抽象表示,但又独立于具体的计算机系统。以 下对数据流图常采用的符号作一个简要介绍。 第 3 章 数据库设计技术 数据流图常采用的符号主要包括以下几种。 (1)数据流。 顾名思义,数据流是流动中的数据,所以数据流是用有方向的曲线或直线来表示,用箭 头表示数据流的方向,旁边标以数据流的名称,其格式如下: 其中,数据流名不是随意取的,而是应该能够简要地概括数据流的含义,且易于理解。 下文提到的数据名、加工名、文件名等都有同样的要求。 数据流可以来自数据的源点、加工和数据文件,可以流向数据的终点、加工和数据文件。 但是,当数据取自文件或者流向文件时,相应的有向直线或曲线可以不命名,因为从相应的 文件中即可知道流动的是什么数据。 (2)数据的源点和终点。 显然,系统中的数据是来自系统以外的其他数据对象,其最终的流向也是系统以外的有 关数据对象。这种向系统提供数据的数据对象统称为系统的数据源点,而系统数据所流向 的数据对象则统称为数据终点。这两个概念的引入是为了帮助用户对系统接口界面的理 解。在数据流图中,数据源点和数据终点都是用矩形来表示,矩形中标以数据的名称。其格 式如下: (3)加工。 加工是对数据处理的一个抽象表示。如果这种“加工”还不为系统分析员所理解,则需 要SA 方法对其进行分解,直到所得到的加工已经足够简单、不必再分时为止。这时的加工 也称为基本加工。在数据流图中,加工是用圆圈(或椭圆)表示,圆圈标以加工的名称。其格 式如下: (4)数据文件。 数据文件是表示数据临时存放的地方,“加工”能够对其进行数据读取或存入。在数据 流图中,数据文件通常用平行的双节线表示,旁边标以数据文件名。其格式如下: 此外,对于数据流图中的一个节点,可能有几条表示数据流的有向线出自或指向该节 点。那么,该节点对数据流的影响方式(流出情况)或这几股数据流对该节点的作用方式是 多种的。这种影响和作用方式说明如表3. 1所示。 82 数据库原理与应用 （ 第 3 版） 表3.1 数据流的关系 符号表示 说明 表示在收到X和Y后才进行加工,然后产生Z 表示在收到X或者收到Y后即可进行加工,结果产生Z 表示从数据流X和Y中选择其中之一来进行加工,结果产生Z 表示在对Z进行加工后同时产生X和Y 表示在对Z进行加工后,产生X或Y,或者两者都产生 表示在对Z进行加工后,仅产生X和Y的其中之一 图3. 2 YPFXMS 的根节点数据流图 (2)绘制子节点图。对系统开发来说,数据流图的根节点不提供任何有用的信息,需要 对加工“样品分析管理系统”作进一步的分解。在调研中发现,不是每一种样品都需要分析 的,能够分析的是那些已经有计算公式或分析方案的样品,而且送样(被送用于分析的样品) 以上是数据流图中常用的符号,除此外,还有其他的一些符号,读者可参考有关书籍。 3. 基于数据流图的SA 方法 自顶向下的SA 分析方法可以与数据流图有机地结合起来,将对系统的分析过程和结 果形象地表示出来。在数据流图中,SA 分析方法主要体现在对“加工”进行分解的过程。 对数据流图的绘制和分解过程就是用户需求的分析及其表达的形成过程。 一个系统的数据流图是由多个子图构成,如果加上子图之间的分解关系,就可以形成一 棵树。但由于所有的子图通过表示分解关系的边连在一起而形成的树将是很庞大的,无法 在同一平面中画出,所以在绘制数据流图时要分为多个子图来画。绘制的原则一般是,先绘 制树根节点对应的子图,然后绘制根节点的子节点所对应的子图,一直绘制到所有叶子节点 对应的子图为止。 下面以某中石化集团的样品分析管理系统(一个子系统)的开发为例,介绍数据流图的 基本绘制方法。 (1)绘制根节点图。从加工粒度上看,根节点图(即根节点对应的数据流图)是最大的 数据流图,它是将整个应用系统当作一个加工。例如,对于样品分析管理系统(YPFXMS), 其根节点子图如图3. 2所示。 第 3 章 数据库设计技术 要先存在样品分析员那里,样品分析员则按照某一个原则一次对这些送样进行分析。在送 样被分析后,还需要对分析的结果进行检查,如果发现分析结果不合格(是指分析手段和方 法出错)则返回给样品分析员重新进行分析,分析合格则返回给送样人员。于是,分解后得 到如图3. 3所示的数据流图。 图3.根节点0的子节点数据流图 3 图3.分别以“”“” 3标记。如果某个节点对应的加工内部还包 3中有3个节点, 1、2和“” 含有数据流,则对该加工进一步分解,直到不能再分而形成基本加工为止。例如,节点“对(”) 应的加工“样品分析实验”还可再分解,从而可以按照上述的方法绘制相应的数据流图 2 。这 时数据流图中所有的加工节点都以“2.头, 2.”2.等,(”) 2分(”) 开(”) 如“1“2表明这些加工是由加工“ 解得到的。这样使数据流图层次清楚。 当一个系统的数据流图绘制完了以后,应该和用户作进一步的交流,以确认数据流图是 能够充分表达用户需求的。 3.2.3 形成数据字典 数据流图主要是表示数据和处理之间的关系,但缺乏对数据流、数据文件、加工等图中 各个元素进行描述的能力。实际上,数据流图是将用户头脑中的需求转化为机器能够接受 的表达的一个中转站,但数据流图表示的信息离机器能够接受的信息还比较远。如果把用 户需求和机器表示放在两头,数据流图放在两者之间,那么数据流图更靠近用户需求一些, 而相对远离机器表示。为此,需要引入数据字典的概念,通过数据字典可以加强数据流图的 信息表达能力,同时这种表达拉近了与机器表示的距离,使得用户需求从纯粹的逻辑表达逐 步转向机器表示,为数据库的实施奠定基础。 与数据流图一样,数据字典也是SA 方法中一种有力的工具。通常情况下,数据字典与 数据流图结合使用,主要是用于对数据流图中出现的各种元素进行描述,给出所有数据元素 的逻辑定义。简而言之,数据字典是数据流图中数据元素的描述。这种描述是由一系列的 条目组成,但不同的应用、不同的系统其组成的条目可能有所不同。一般来说,至少应该包 括数据项、数据流、数据文件和加工等4种条目,这4种条目的组成格式有较大的差别。现 对这些条目及其格式说明如下。 84 数据库原理与应用（第 3 版） 1. 数据项条目 数据项是数据构成的最小组成单位,它不能再分割。数据项条目用于说明数据项的名 称、类型、长度、取值范围等。例如,在课题管理系统中数据项“课题申请代码”条目可描述如 下(也可以用表格等其他方式描述): 数据项名:课题申请代码 类型:字符型 长度:12 取值范围:000000000000~999999999999 取值说明:前4位为年份,第5~6位、第7~8位分别表示月份和日期,后4位表示当天 的课题序号 2. 数据流条目 数据流条目主要用于说明数据流的组成(由哪些数据项组成), 数据流的来源和流向以 及数据流量等信息。例如,数据流“样品分析请求信息”条目描述如下: 数据流名称:样品分析请求信息 组成:申请表编号、申请表名称、分析项目代码、样品编号、样品名称、送样日期、送样 人员 来源:记录送样信息(加工) 去向:样品分析请求信息(文件) 流量:10~20 件/天 3. 数据文件条目 数据文件条目用于说明数据文件是由哪些数据项组成,组织方式、存储频率如何等信 息。例如,数据文件“一审合格实验信息”条目如下: 文件名:一审合格实验信息 数据组成 : 试验记录表编号、试验记录表名称、试验日期、试验环境、试验目的、操作人 员、原料规格、试验配方与工艺、操作过程与现象、试验结果与讨论、记录人 员、试验组长、课题代码 组织方式:按试验记录表编号递增排列 存储频率:1次/天 4. 加工条目 加工条目主要用于说明加工的逻辑功能、指明输入数据和输出数据等信息。其中逻辑 功能项用于指出该加工用来做什么、对加工处理的一些要求等。例如, 加工编号:1 加工名:记录送样信息 第 3 章 数据库设计技术 输入数据:样品数据 输出数据:样品分析请求信息 逻辑功能:对送检的样品数据进行登记,并由此转化成样品分析请求信息。 数据字典是对系统调研所收集的大量数据进行详细分析所得到的主要结果。它是数据 库设计阶段的一项主要成果,因而它的创建是一项重要的工作,但同时也是一项费时的 工作。 对数据字典的维护也是一项艰巨的任务。对于中型规模以上的系统来说,数据字典都 是比较庞大的,可能包含成千上万个条目。在数据字典中需要保持这些条目的准确性、一致 性,要按照一定的顺序来排列这些条目,以方便查找。这些工作量是非常可观的。幸运的 是,现在有很多用于创建和维护数据字典的软件,使我们的工作量大大地减少。但是,软件 是代替不了人的,创建和维护的许多工作还需要人工的参与。因此,深入理解数据字典的形 成过程及其维护方法,都是学习数据库设计的主要任务。 3.数据库结构设计 3 在系统需求分析后,将形成系统的数据流图和数据字典。在此基础上,可以对数据库结 构进行设计。数据库结构设计包括概念结构设计、逻辑结构设计和物理结构设计三部分。 3.3.1 概念结构设计 1. 概念结构及其设计思想 系统需求分析的成果是数据流图和数据字典,这是对用户需求在现实世界中的一次抽 象。但这种抽象还只停留在现实世界当中,而概念结构设计的目的就是将这种抽象转化为 信息世界中基于信息结构表示的数据结构———概念结构,即概念结构是用户需求在信息世 界中的模型。 数据库的概念结构独立于它的逻辑结构,更与数据库的物理结构无关。它是现实世界 中用户需求与机器世界中机器表示之间的中转站。它既有易于用户理解、实现分析员与用 户交流的优点,也有易于转化为机器表示的特点。当用户的需求发生改变时,概念结构很容 易作出相应的调整。所以,概念结构设计是数据库设计的一个重要步骤。 概念模式描述的经典工具是E-R图,由E-R图表示的概念模型就是所谓的E-R模型。 E-R模型的创建和设计过程就是概念结构的创建和设计过程,所以概念结构的设计集中体 现为E-R模型的设计。 E-R模型的优点主要体现在:它具有较强的表达能力,可以充分表示各种类型数据及 数据之间的联系;数据表达形式简单,没有过多的概念,定义严格,无二义性等;E-R模型是 以图形的形式出现,表示直观。 E-R图的基本画法在第1章已经进行了介绍,那么如何基于E-R图进行概念结构设计 呢? 实际上,对于概念结构的设计,人们已经总结了4种设计指导思想。 细化 ( 。 1)自顶向下。首先根据用户需求定义全局概念结构的E-R模型,然后对其分解,逐步 86 数据库原理与应用（第 3 版） (2)自底向上。首先根据各个部分的需求定义局部概念结构的E-R模型,然后将这些 局部的E-R模型拼接成为全局的E-R模型,从而形成全局概念结构。 (3)先主后次。分析各种子需要的“轻重”,首先设计最重要的概念结构,形成它的E-R 模型,然后定义次要概念结构的E-R模型,接着按照类似的方法定义其他所有概念结构的 E-R模型,最后将这些模型集成起来,形成全局概念结构。 方法 ( 。 4)上下混合。这是将自顶向下和自底向上这两种方法结合起来使用的一种设计 在实际应用当中,概念结构设计通常采用的是自底向上的设计方法(而需求分析一般是 采用自顶向下的方法), 即这种方法分为如下两步: (1)先建立局部概念结构的E-R模型; (2)然后将所有的局部E-R模型集成起来形成全局概念结构 。 下面主要介绍这种自底向上的概念结构设计方法 。 2. 局部E- R 模型的设计 E-R模型的设计是基于需求分析阶段产生的数据流图和数据字典来进行的。一个系统 的数据流图是按分层来绘制,是由多张数据流图构成。基于一张数据流图及其对应的数据 字典部分进行的E-R模型设计得到的是一个局部概念。所以,采用从局部到全局的概念结 构设计方法也就是很自然的事了。 局部应用所涉及的数据都已经收集在数据字典中,但如何从中进一步抽象出系统的实 体以及实体间的联系却是基于局部数据流图进行E-R模型设计的主要难点。实体和实体 间联系的划分并无统一的标准,一般采用的划分原则是“先凭经验,后作调整”。 经验是指在一般情况下对于那些具有共同特征和行为的对象,可以将之抽象为实体;对象 的共同特征和行为可以抽象为实体的属性。调整是指在凭经验完成抽象后,根据具体的应用 和建模环境对实体与其属性之间的关系以及实体与实体之间的关系进行相应的更改,有可能 使得原来的属性变为实体,原来是实体的变为属性等,从而也导致了实体间关系的改变。 对于实体及实体间关系的抽象还应注意以下3点: (1)在同一应用环境中,被抽象为属性的事物就不能再被抽象为实体了,否则会导致 “属性又包含属性”的错误,这违反第一范式; (2)属性具有不可再分性,所以具有不可再分性的事物一般都应抽象为属性,而具有可 再分性的事物一般不能抽象为属性; (3)一个事物不能同时被抽象为两个实体的属性,即一个属性只能隶属于一个实体。 例如,对于一个企业信息管理系统来说,企业中的工作人员可以抽象为“职工”实体,而 工作人员的姓名、性别、职称、职工”实体的属性,如图3. 年龄、所在部门等可以抽象为“4 所示 图3.“职工”实体属性图 4 第 3 章 数据库设计技术 这是凭普遍经验作出的抽象(第一感觉就认为应该作出这样的抽象), 但有可能不正确 或不全面,需要进一步调整。例如,如果在这个系统中除了“职工”信息以外还需要考虑部门 的一些信息,如部门的名称、人数、经理、位置等信息,那就应该对前面的抽象进行调整:应 该将“部门”由原来作为“职工”的属性改为一个新的实体———“ 部门”实体,同时原来作为属 性的“部门”被删除(这避免了出现一个事物既作为属性又作为实体的情况)。这两个实体的 关系是“部门”拥有“职工”(或者“职工”隶属于“部门”), 即“拥有”是这两个实体之间的联系。 这样,原来的E-变为如图3. R图进一步得到调整和扩充,5所示。 图3.部门”和“职工”的ER 图 5 “ 假设从需求分析中还发现,部门中的职工所做的工作是开发项目,用于说明项目的信息 包括项目名称、项目性质、项目开发的起始时间、项目经费、项目经理等。于是,将项目抽象 为实体,形成“ 实体,6所示。 项目” 如图3. 图3.“项目”实体属性图 6 3. 全局E- R 模型的集成 显然,相对于一个整体而言,以上画出的E-R图是局部的,这些E-R图应该能够合成一 张总的E-R图。对概念结构来说,就是将局部概念结构集成为全局的概念结构。 例如,根据需求分析结果可以进一步发现,在这个企业中每个部门都有承接多个项目的 可能,每个职工只参加一个项目。于是,5和图3.-结果得 到了整个系统的E-R图,7所示。 将图3.6所示的ER图拼接起来, 如图3. 从以上E-R图的创建过程中可以看出,这种创建方法基本上是按照先局部后全局的自 底向上的设计思想来实现的,E-R图的创建过程是一个不断修正的反复过程。当然,实际系 统不可能这么简单,但从这个设计过程中读者可以体会到一个系统E-R图设计的一般方 法,由此可以融会贯通,举一反三。 一般来说,局部E-R图可能是由多人设计的,即使是由同一个人设计,但由于设计是在 不同的时间、不同的条件下完成的,这都有可能造成各个局部E-R图的不一致,从而使得在 局部E-R图的拼接过程中产生许多问题。这些问题主要体现为各个局部E-R图之间的冲 突,包括命名冲突、属性冲突和结构冲突等。 (1)命名冲突。命名冲突是指意义不同的元素在不同的局部E-R图中有相同的名字, 或者是有相同意义的元素在不同的局部E-R图中具有不相同的名字。名字冲突的解决比 较容易,只要开发人员进行充分的协商,制定同一的命名规则即可解决。 88 数据库原理与应用（第 3 版） 图3.企业信息管理系统的ER 图 7 (2)属性冲突。属性冲突是指同义同名的属性在不同的局部E-R图中的取值类型、范 围、所使用的单位等却完全不一样。例如,有的将职工编号定义为长度为12 个字节的字符 串类型,有的则定义为8个字节的字符串类型,有的可能将职工编号定义为整型,等等。一 般来说,在一个E-R图中不应该存在属性冲突。这种冲突也主要是通过协商、加强沟通来 解决 ( 。 3)结构冲突。结构冲突是指一个事物在一个局部E-R图被抽象为实体,而在另一个 局部E-R图中又被抽象为属性。这时不能直接将这两个局部E-R图并接为一个E-R图,首 先要解决结构冲突问题。解决的办法是,视具体情况将相应的属性改为实体,或者将相应的 实体改为属性。但这种操作又可能引起别的问题,更改时要慎重。 还有一种结构冲突是相同的实体在不同的局部E-R图中有不同的属性或不同的联系。 对于前一种情况,一种简单的解决方法是:使该实体的属性集为它在各E-R图中的属性集 的并;对于后一种情况,解决方法相对复杂,要视具体情况对联系进行分解,或者进行其他的 调整。 另外,在构建的E-R图中 , 最好不要包含环形结构,因为这容易出现“死循环”参照关 系。例如,假设实体X、Y和Z以及它们之间的联系a、b和c 构成如图3.-则该ER图出现“ 问 8所示的ER图,-死循环” 题,因为在据此图建立数据表时,将出现X参照Y、Y参照Z、 Z参照X的“死循环”参照关系,从而无法创建数据表。因 此,如果一个E-R图包含环形结构,则需要进一步确认对概 图3.带环结构的ER 图 重新修改E-或者直接将环中 8-念结构的建模是否正确?R图, 的一条边(关联)去掉,以破坏“死循环”结构。 显然,读者可能注意到,7所示的E-死 图3.R图就包含了环结构。但该环结构并非是“ 循环”结构,因此不会出现无法建表的情况,其表达的实体参照关系是正确的。 解决结构冲突所需要的工作量比较大,解决过程比较烦琐。所以在设计局部E-R图 第 3 章 数据库设计技术 前,分析人员应尽可能地加强沟通,达成较为全面的共识,尽量避免出现结构冲突的问题。 3.3.2 逻辑结构设计 数据库的逻辑结构设计就是将以E-R图表示的概念结构转换为DBMS 支持的数据模 型并对其进行优化的过程。如今,绝大多数的数据库都是关系数据库,所以在此主要介绍从 概念结构到关系模型的转换方法和相关技术。 概念结构是由E-R图来描述的,所以这种转化问题可以归结为从E-R图到关系模型的 转换问题。E-R图的基本元素是实体、属性和联系等,于是从E-R图到关系模型的转换就 变成了从实体、属性和联系等基本元素到关系模式的转化问题了。 1. 实体和属性的转变 这种转变比较简单、直观,即一个实体转化为一个关系模式,其中实体名变成了关系模 式的名称,实体属性相应地变成了关系的属性。例如,7中的3个实体分别转化为以下 图3.3个关系模式: 项目(编号,名称,经理,性质,启动时间,结题时间,经费) 部门(编号,名称,经理,人数,地址) 职工(编号,姓名,性别,职称,年龄) 2.(1∶1)联系的转变 一对一联系的转变比较简单。其中,最直观和最简单的方法就是创建一个独立的关系 模式,该关系模式的属性是由该联系本身的属性以及与之相连的实体的候选码(每个实体中 取一个候选码)组成。例如,一个仓库仅由一个仓库管理员管理,而一个仓库管理员也只能 管理一个仓库,所以仓库管理员和仓库之间的联系是管理,管理时间为8小时(一天), 其E-R 图如图3. 9所示。 图3.“仓库管理员”和“仓库”的ER 图 9 可见,“仓库管理员”和“仓库”之间的联系是(1∶1), 该联系转换后形成如下的关系 模式: 管理(管理员编号,仓库编号,时间) 其中,管理员编号和仓库编号分别为“仓库管理员”实体和“仓库”实体的候选码,时间是 “管理”联系的属性。 但是,有时为了减少数据冗余或者其他原因,也可以将联系对应的关系合并到与之相连 的某一个实体对应的关系中去。合并的方法是,将一个实体的候选码以及联系的属性添加 到另一个实体对应的关系中。例如,对于以上例子,易知“仓库管理员”实体对应的关系 90 数据库原理与应用（第 3 版） 如下: 仓库管理员(管理员编号,姓名) 这时,我们只需将“仓库”实体的候选码“仓库编号”以及联系的属性“时间”一起添加到 仓库管理员关系中即可,从而实现对联系“管理”的转换,结果得到的关系模式如下: 仓库管理员(管理员编号,姓名,仓库编号,时间) 当然,也可以将“仓库管理员”的候选码和联系的属性“时间”一起添加到仓库关系中,结 果得到如下的关系模式: 仓库(仓库编号,仓库规模,管理员编号,时间) 一般来说,联系可以合并到任意与之相连的实体对应的关系中。但在实际应用,往往从 效率的角度来考虑如何进行合并。例如,对于上面的例子,如果查询仓库关系比查询仓库管 理员关系要频繁得多,则应将联系合并到仓库管理员关系中去,这样可以提高整个系统的 效率。 3.(1∶n)联系的转变 与一对一联系类似,一对多联系可以转化为一个独立的关系模式。但是,如果采用合并 的方法,则只能将联系合并到 n 端对应的关系模式中。 例如,对于图3.-“ 联系是一对多联系, 7所示的ER图,拥有” 当把这个联系转化为独立 的关系模式时,则得到如下的关系模式: 拥有(职工.编号,部门.编号) 如果采用合并的方法对该联系进行转换,则只能合并到 n 端对应的关系模式中,结果 如下: 职工(职工.编号,姓名,性别,年龄,职称,部门.编号) 其中,以上的“编号”属性都是相应实体的主码。 4.(m∶n)联系的转变 多对多联系只能转换为一个独立的关系模式,其属性集是由与该联系相连的实体的属 性(码)以及该联系本身的属性转换而得到的。例如,一个仓库可以存放多种零件,一种零件 也可以存放在多个仓库中,可见仓库和零件之间的联系———“ 存放”是(m∶n)联系。假设其 E-10 所示。 R图如图3. 图3.“仓库”和“零件”及其联系的ER 图 10 那么,“存放”联系转换为独立的关系模式后,结果如下: 存放(仓库编号,零件编号,数量) 以上讨论的是与两个实体相连的联系(称为二元联系)的转换问题。对于多元联系的转 换问题,我们不难从二元联系转换方法的推广中获得解决,此不赘言。 第 3 章 数据库设计技术91 5. 应用规范化理论实现逻辑结构的优化 逻辑结构设计的结果是数据模型。以上主要介绍了如何将以E-R图表示的概念结构 转换为以关系模型表示的逻辑结构。在形成关系模式后,还需要对其进行优化处理,以尽可 能地减少数据冗余、删除冲突和插入冲突等问题。对关系模式的优化处理主要是基于规范 化理论进行的,具体操作方法可参见第2章的相关内容。 6. 用户子模式的设计 用户子模式也称为外模式,它是面向用户的,是用户可见的数据模型部分。它可以屏蔽 概念模式,有助于实现程序与数据的独立,可以满足不同用户对数据的个性化需求,同时也 有利于数据库的管理。 用户子模式的设计主要是利用局部E-R图,因为每一张E-R图一般都是表示局部概念 结构。现在流行的DBMS 一般都提供了视图功能,支持用户的虚拟视图。我们可以利用这 个功能设计符合不同局部应用需要的用户子模式。 3.3.3 物理结构设计 在逻辑结构设计阶段得到的数据模型只是一个理论上的概念,与具体的计算机系统无 关的。但是,基于数据模型的数据库最终还是必须存放到某个具体的物理设备中,由特定的 DBMS 来管理。所以,如何选取合理的存储结构和有效的存储路径,以充分利用系统资源、 提高数据库的性能,这就是物理结构设计需要完成的任务。 简而言之,物理结构设计就是为既定的数据模型选取特定的、有效的存储结构和存储路 径的过程。特定性是指与具体的计算机系统有关,包括操作系统和DBMS 等;有效性是指 以尽可能少的系统资源获得数据库尽可能高的运行效率。可以看出,物理结构设计的内容 主要包括数据库存储结构的确定和数据库存取方法的确定。 1. 数据库存储结构的设计 数据库存储结构设计的任务是确定数据的存放位置和使用的存储结构,具体来讲,确定 如何在磁盘空间中存储关系、索引、日志、备份等数据库文件,以及如何设置系统存储参数, 目的是用最小的系统资源获取最高的系统性能。 存储结构的设计是在已选定的DBMS 和硬件条件下进行的,主要从以下两方面考虑。 (1)确定数据的存放方式。 在大多的关系DBMS 中,数据的分类和指定存储是通过数据文件的划分和存储来实 现。因为在DBMS 中,不能直接指定数据的存放位置,而只能通过一定的机制实现数据文 件的指定存放,从而实现将数据存放在指定的位置,所以,确定了数据文件的存放位置也就 确定了数据的存放位置。 数据文件的划分和存储主要是基于数据访问的稳定性、安全性、效率等方面考虑的,相 应的指导性规则包括: .数据文件和日志文件应该分开存放在磁盘中; .如果计算机系统中有多个磁盘,可以将数据库文件分为多个文件,并分布在不同的 磁盘中; .将数据表和索引等分开存放在不同的数据库文件中; 92 数据库原理与应用（第 3 版） .大的数据对象要分散存储在不同的数据库文件中。 以上操作,对不同的DBMS 有不同的操作方式,但大多都提供这些操作功能。而对设 计人员来说,他必须熟悉DBMS 提供的这些功能及其操作方法。 (2)确定系统参数的配置。 系统参数是指DBMS 提供的设置参数。这些参数主要包括数据库的大小、同时连接的 用户数、缓冲区个数和大小、索引文件的大小、填充因子等。DBMS 一般都对这些参数设置 了初始值,但这些设置并不一定适应每一种应用环境,这需要设计人员重新设计。 这些参数的配置操作一般都可以在DBMS 提供管理工具中完成。例如,SQLServer 2008 提供的管理工具是SQLServerManagementStudio(SSMS),SSMS 可以管理SQL Server2008 的所有组件,包括访问、配置、控制和开发这些组件。 2. 确定存取方法 存取方法即关系模式的存取方法,其目的是实现数据的快速存取。每一种DBMS 都提 供了多种不同的存取方法,其中索引法是最常用的一种,在实际开发当中用得最多。以下重 点介绍这种存取方法。 索引为什么可以提高数据库中数据的存取速度呢? 这道理与目录可以提高图书的查阅 速度的道理一样,即可以将索引形象地比喻为目录。实际上,索引正是基于目录的原理来设 计的,它是“数据标题”和数据内存地址的列表。通过索引可以从部分数据检索中实现数据 的快速查找,从而提高数据的查询效率。 但索引的创建并不是无代价的。索引本身也是一种数据表,同样占用存储资源,而且要 保持与数据表的同步,这要求在进行数据更新操作(包括添加、删除和修改操作)时也要对索 引进行相应的更新操作。如果索引很大时,其占用的空间资源以及对其更新维护所需要付 出的代价同样是非常可观的。所以对索引的创建与否,应该慎重考虑。 在创建索引时,要考虑以下几个经验性的指导原则。 .在经常用于检索的列上创建索引,特别是要对主码创建索引(一般是由DBMS 自动 完成)。 .在外键上创建索引,因为它经常用于与其他关系进行连接查询。 .在以读为主或者经常需要排列的列上创建索引。因为索引已经排序,它可以加快读 取速度和排序效率。 .在经常用于条件查询的列上创建索引,特别是对那些常常出现少量元组满足条件 的列 。 而对具有以下性质的列,则不宜对其创建索引 。 .对于不经常用于检索的列,则不宜在其上创建索引。因为其上有无索引是无关紧要 的,创建了反而浪费存储空间。 .对于那些值域很小的列不应该创建索引。例如,不宜在“性别”列上创建索引,因为 “性别”只有两个值:“ 男”和“女”,索引对这种列并无作用。 .对于值域严重分布不均匀的列不宜在其上创建索引。 .对于更新操作非常频繁的列,不宜在其上创建索引。因为在进行更新操作时,不但 要更新数据表的内容,而且还要更新索引表中的索引项,这会降低系统的效率。 第3 章 数据库设计技术 93 . 对于长度超过30字节的列,一般不要在其上创建索引。因为在过长的列上创建索 引,索引所占的存储空间就大,索引级数也随之增加,从而消耗系统资源、降低系统 效率。如果非要创建不可,最好能够采取索引属性压缩措施。 3.4 数据库的实施、运行和维护 在数据库的逻辑结构和物理结构设计完了以后,就可以将这些设计结果付诸实践,并创 建相应应用程序,形成实际可运行的系统。系统运行之后还需要对其进行日常维护。这些 工作就是数据库的实施、运行和维护要讨论的内容。 3.4.1 数据库实施 数据库的实施是在数据库逻辑设计和物理设计的基础之上进行的。与前面设计不同的 是,数据库实施后将形成一种能够实际运行的系统,这种系统是将前面设计结果付诸实践而 形成的,是动态的;而前面的设计(包括需求分析、概念、逻辑设计和物理设计等)是在纸上进 行的,停留在文档阶段,是静态的,但它们是数据库实施的基础,是数据库系统能够稳定、高 效运行的前提。 数据库实施包括以下3方面的内容。 1.建立数据库结构 根据物理结构的设计结果,选定相应的DBMS。然后在该DBMS系统中利用其提供的 DDL语言建立数据库结构。 例如,在SQLServer中,可用如下的SQL语句来分别创建数据库和数据表: CREATE DATABASE database_name CREATE TABLE table_name 关于它们的使用格式,将在下一章中详细介绍。此外,在SQLServer中,还为数据库结 构的创建提供了可视化的图形界面操作方法,极大地提高工作效率。 在数据库结构定义以后,通过DBMS提供的编译处理程序编译后即可形成了实际可运 行的数据库。但这时的数据库还仅仅一个框架,内容是空的。要真正发挥它的作用,还需要 编写相应的应用程序,将数据保存在其中,形成一个“有血有肉”的动态系统。 2.装载测试数据,编写调试应用程序 应用程序设计与数据库设计可以同时进行,但应用程序的代码编写和调试则在数据库 结构创建以后进行的。应用程序的设计、编写同样是一个复杂的过程,相关的设计技术可参 加软件工程方面的书籍。 应用程序的编写和调试是一个反复进行的过程,其中需要对数据库进行测试性访问。 所以,这时应该在数据库中装载一些测试数据。这些数据可以随机产生,也可以用实际数据 作为测试数据(但这些实际数据要留有副本)。但不管用什么产生方法,使用的测试数据都 应该能充分反映实际应用中的各种情况,以使得可以充分测试应用程序是否符合实际应用 的要求。 94 数据库原理与应用（第 3 版） 3. 试运行 在应用程序调试完了以后,给数据库加载一些实际数据并运行应用程序,但还没有正式 投入使用,而只是想查看数据库应用系统各方面的功能,那么这种运行就称为试运行。试运 行也称联合调试,与调试的目的基本一样,但侧重点有所不同。调试主要是为了发现系统中 可能存在的错误,以便及时纠正;试运行虽然也需要发现错误,但它更注重于系统性能的检 测和评价。所以,试运行的主要工作包括: .系统性能检测。包括测试系统的稳定性、安全性和效率等方面的指标,查看是否符 合设计时设定的目标。 .系统功能检测。运行系统,按各个功能模块逐项检测,检查系统的各个功能模块是 否能够完成既定的功能。 如果检测结果不符合设计目标,则返回相应的设计阶段,重新修改程序代码或数据库结 构,直到满足要求为止。如果不符合要求就强行投入使用,可能会产生意想不到的灾难性后 果。对此,用户和开发方都应该慎重考虑。 总之,试运行是系统交付使用的最后一道“门槛”,能否在这一关中正确而充分地检测系 统对以后的正式运行有着非常重要的意义。 3.4.2 数据库系统的运行和维护 试运行结束并被证实符合设计要求后,数据库就可以正式投入使用。数据库的正式使 用标志着数据库开发阶段的基本结束,同时意味着数据库运行和维护阶段的开始。数据库 的运行和维护并不是数据库设计的终点,而是数据库设计的延续和提高。 数据库的日常运行和维护也是一项专业性很强的工作,需要很强的专业技术。维护工 作不是普通的用户就能够胜任的,一般是由系统管理员(DBA)完成。这种工作就是软件产 品的售后服务。 在数据库的运行和维护阶段,DBA 的主要工作如下。 1. 数据库的转储和恢复 一旦数据库正式投入使用,企业的相关数据将全部存入数据库(一般不会另记在纸质材 料中)。如果数据库发生故障,可能会导致这些数据的丢失,从而造成企业的重大损失。所 以,为了尽量避免在数据库发生故障时造成数据丢失,DBA 应当根据应用的具体要求制定 相应的备份和恢复方案,保证一旦发生故障,能够尽快将数据库恢复到某一种一致性的最近 状态,尽量减少损失。 数据库转储正是为了解决上述问题而提出一种数据库恢复技术,它是指定期地把整个 数据库复制到磁盘或者其他存储设备上保护起来的过程。实际上,数据库的转储和恢复是 数据库运行维护中最重要的工作之一。 2. 数据库性能的检测、分析和改善 随着运行时间的增加,数据库的物理存储不断发生改变,加上数据量和用户的不断增 加,这都使得数据库的运行性能不断下降。为此,DBA 必须利用DBMS 提供的性能监控和 分析工具定期地对数据库的各种性能指标进行检测,以便及早地发现问题并采取相应的优 化和改善措施。 第 3 章 数据库设计技术 3. 数据库的安全性和完整性维护 不管是从企业内部还是从企业外部来讲,数据库的安全性和完整性都是至关重要的。 作为数据库的管理者,DBA 必须对数据库的安全性和完整性负责。所以,DBA 应该认真审 核每一个用户的身份,并正确授予相应的权限;随着时间的推移和应用环境的改变,对安全 性的要求也随之发生变化,这要求DBA 对数据库的安全性控制作出相应的调整,以适应新 的情况。类似地,数据库的完整性约束条件也会发生变化,这同样要求DBA 作出相应的修 正,以满足新的要求。 4. 数据库的重组和重构 数据的插入、修改和删除是数据库的基本操作。这些操作的多次使用会使得数据在磁 盘上的存储分布越来越散,导致数据的存储效率降低,整个系统性能下降。这时应该对数据 库进行重新组织(即重组), 以提高系统的性能。现在流行的DBMS 一般都提供重组功能。 随着应用发展的需要,用户可能要求增加某些属性或实体,也可能要求删除某些属性或 实体,或者要求修改某些实体之间的联系等。为满足这种要求,需要对数据库的模式和内模 式进行调整,如增加或删除某些列和表、增加或删除某些索引、修改数据库的完整性约束条 件等,这种调整就是对数据库进行重新构造的过程,即数据库的重构。现在流行的DBMS 也提供数据库重构功能。 数据库重组和数据库重构有着本质的区别,这主要体现在:数据库重组的目的是提高 系统的性能,它通过DBMS 提供的功能对数据库在磁盘上的存储分布进行调整来达到重组 的目的,重组不会改变数据库的模式和内模式;数据库重构的目的则是为了实现新的用户需 求,它需要修改数据库结构,从而使数据库的概念模式和内模式也被修改。 数据库重构不但使数据库结构发生了改变,而且在多数情况下也要求应用程序作出相 应的修改。这会导致“牵一发而动全身”的后果,所以由数据库重构而引起的修改工作量是 非常大的。因此,不是在迫不得已的情况下请不要使用数据库重构。 虽然数据库重构可以实现新的用户需求,但这种需求的变化幅度必须限制在一定的范 围内。如果超过这个范围,数据库重构可能无法实现,也可能是实现的代价太高而失去重构 的意义。所以数据库重构并不是“无所不能”的。如果在一个数据库系统中无法进行数据库 构成,则表明这个数据库系统已经被淘汰了,需要设计一个新的系统来取代它。 习题 3 一、简答题 1. 数据库设计主要分为哪几个步骤? 每个设计步骤的主要目的以及获得的结果是 什么? 2.数据库结构设计包含哪几个部分? 3.什么是E-R图? 它在数据库设计中有何作用? 4. 需求分析主要采用什么方法? 5. 什么是概念结构? 其设计思想是什么? 有哪些特点? 6.E-R模型的集成需要注意什么问题? 96 数据库原理与应用（第 3 版） 7. 简述数据字典的结构及其作用。 8. 什么是逻辑结构设计? 二、设计题 1. 已知系统a的局部E-概念结构) 11 所示。 R图( 如图3. 图3.系统a的局部ER 图 11 其中,各实体的属性说明如下(为了简化E-R图,属性没有在图中标出): 部门:部门编号,名称,地址,人数 部门经理:工号,姓名,性别,职称,年龄 请将该E-R图表示的概念结构转换为相应的关系模式(逻辑结构)。 2. 已知系统b的局部E-R图( 如图3.请据此给出它合理的关系模式 (逻辑结构)。 概念结构) 12 所示, 图3.系统b的局部ER 图 12 其中,各实体的属性如下: 学院:学院代号,名称,年科研经费,专业数,教师人数 班级:班级代号,名称,专业,人数 学生:学号,姓名,性别,专业,籍贯 3. 已知系统c的局部E-13 所示, R图如图3.请据此给出它合理的关系模式。 图3.13 系统c的局部E- R 图 其中,各实体的属性如下: 零件:零件号,零件名,价格 产品:产品号,产品名,价格 4. 假设要开发一套研究生信息管理系统,在进行需求分析时发现该系统涉及的对象包 括研究生、导师和课程,其中导师可以指导多名研究生,一位研究生只有一位导师;一位研究 第 3 章 数据库设计技术 生可以选修多门课程,一门课程也可能为多位研究生所选修;每位导师至多开设一门课程, 且课程不能重复开设。各对象的描述信息如下: 研究生:学号,姓名,性别,年龄,专业,籍贯 课程:课程代码,名称,性质 导师:编号,姓名,性别,年龄,研究领域 请根据上述信息对该系统进行概念结构设计,然后进行逻辑结构设计。