导图社区 数据库系统概论-第七章
- 199
- 举报
数据库系统概论-第七章
华中师范大学情报学考研初试参考书，数据库设计，数据库设计概述，需求分析，概念结构设计，逻辑结构设计，物理结构设计，数据库的实施和维护，知识点总结。
编辑于2022-06-04 15:34:05- 数据库设计
- 系统概论
- 相似推荐
- 大纲
数据库设计
数据库设计概述
概念
定义
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和 物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满 足各种用户的应用需求，包括信息管理要求和数据操作要求。
目标
数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行 环境。高效的运行环境指数据库数据的存取效率、数据库存储空间的利用率、数据 库系统运行管理的效率等都是高的。
特点
数据库建设的基本规律
“三分技术，七分管理，十二分基础数据”是数据库设计的特点之一。 在数据库建设中不仅涉及技术，还涉及管理。要建设好一个数据库应用系统， 开发技术固然重要，但是相比之下管理更加重要。
结构设计和行为设计相结合
整个设计过程中要把数据库结构设计和对数据的处理设计密切结合起来。这是 数据库设计的特点之二。
方法
早期数据库设计主要采用手工与经验相结合的方法，设计质量往往与设计人员的经 验和水平有直接的关系。常常是数据库运行一段时间后又不同程度地发现各种问 题，需要进行修改甚至重新设计，增加了系统维护的代价。 为此，人们提出了各种 数据库设计方法。例如，新奥尔良方法、基于 E-R 模型的设计方法、3NF（第三范 式）的设计方法、面向对象的数据库设计方法、统一建模语言（UML）方法等。
基本步骤
数据库设计开始前
按照结构化系统设计的方法，考虑数据库及其用系统开发全过程，将数据库设计分 为 6 个阶段。 数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库 设计人员、应用开发人员、数据库管理员和用户代表。 系统分析和数据库设计人员 是数据库的核心人员，将自始至终参与数据库设计，其水平决定了数据库系统的质 量。 用户和数据库管理主要参加需求分析与数据库的运行和维护，其积极参与不但 能加速数据库设计，而且也是决定数据库设计质量的重要因素。 应用开发人员（包 括程序员和操作员）分别负责编制程序和准备软硬件环境，他们在系统实施阶段参 与进来。
具体阶段
（1）需求分析阶段。进行数据库设计首先必须准确了解与分析用户需求。需求分析 是整个设计过程的基础，是最困难和最耗费时间的一步。 （2）概念结构设计阶段。概念结构设计是整个数据库设计的关键，它通过对用户需 求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。 （3）逻辑结构设计阶段。逻辑结构设计是将概念结构转换为某个数据库管理系统所 支持的数据模型，并对其进行优化。 （4）物理结构设计阶段。物理结构设计是为逻辑数据模型选取一个最适合应用环境 的物理结构。 （5）数据库实施阶段。在数据库实施阶段，设计人员运用数据库管理系统提供的数 据库语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编写与 调试应用程序，组织数据入库，并进行试运行。 （6）数据库运行和维护阶段。数据库应用系统经过试运行后即可投入正式运行。在 数据库系统运行过程中必须不断地对其进行评估、调整与修改。
需求分析阶段
概念结构设计阶段
逻辑结构设计阶段
物理结构设计阶段
数据库实施阶段
数据库运行和维护阶段
各级模式
在需求分析阶段综合各个用户的应用需求； 在概念结构设计阶段形成独立于机器特 点、独立于各个关系数据库管理系统产品的概念模式，在本篇中就是 E-R 图； 在逻 辑结构设计阶段将 E-R 图转换成具体的数据库产品支持的数据模型，如关系模型， 形成数据库逻辑模式，然后根据用户处理的要求、安全性的考虑，在基本表的基础 上再建立必要的视图形成数据的外模式； 在物理结构设计阶段，根据关系数据库管 理系统的特点和处理的需要进行物理存储安排，建立索引，形成数据库内模式。
需求分析
概念
需求分析简单地说就是分析用户的要求。需求分是设计数据库的起点，需求分析结 果是否准确反映用户的实际要求将直接影响到后面各阶段的设计，并影响到设计结 果是否合理和实用。
需求分析的任务
任务
需求分析的任务是通过详细调查现实世界要处理的对象，充分了解原系统的工作概 况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考 虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库
调查的重点
调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的 如下要求： （1）信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以 导出数据要求，即在数据库中需要存储哪些数据。 （2）处理要求。指用户要完成的数据处理功能，对处理性能的要求。 （3）安全性与完整性要求
确定用户需求的过程
确定用户的最终需求是一件很困难的事， 这是因为一方面缺少计算机知识，开始时 无法确定计算机究竟能为自己做什么，不能做什么，因此往往不能准确地表达自己 的需求，所提出的需求往往不断地变化。 另一方面，设计人员缺少用户的专业知识， 不易理解用户的真正需求，甚至误解用户的需求。因此设计人员必须不断深入地与 用户交流才能逐步确定用户的实际需求。
需求分析的方法
概要
进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达 这些需求。
调查用户需求的具体步骤
（1）调查组织机构情况 （2）调查各部门的业务活动情况。 （3）在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息 要求、处理要求、安全性与完整性要求，这是调查的又一个重点。 （4）确定新系统的边界。确定哪些功能由计算机完成或将来准备让计算机完成， 哪些活动由人工完成。
常用的调查方法
（1）跟班作业。通过亲身参加业务工作来了解业务活动的情况。 （2）开调查会。通过与用户座谈来了解业务活动情况及用户需求。 （3）请专人介绍。 （4）询问。对某些调查中的问题可以找专人询问。 （5）设计调查表请用户填写。如果调查表设计得合理，这种方法是很有效的。 （6）查阅记录。查阅与原系统有关的数据记录。
数据字典
概念
它是关于数据库中数据的描述，即元数据，而不是数据本身。 数据字典是在需求分 析阶段建立，在数据库设计过程中不断修改、充实、完善的。它在数据库设计中占 有很重要的地位。 数据字典通常包括数据项、数据结构、数据流、数据存储和处理 过程几部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据 结构。
组成部分
数据项
数据项是不可再分的数据单位。对数据项的描述通常包括以下内容: 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，取值范 围，取值含义，与其他数据项的逻辑关系，数据项之间的联系｝
数据结构
数据结构反映了数据之间的组合关系。一个数据结构可以由若干个 数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混 合组成。 对数据结构的描述通常包括以下内容: 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝
数据流
数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以 下内容: 数据流描述＝｛数据流名，说明，数据流来源，数据流去向，组成:｛数据结 构｝，平均流量，高峰期流量｝
数据存储
数据存储是数据结构停留或保存的地方，也是数据流的来源和去向 之一。 对数据存储的描述通常包括以下内容: 数据存储描述＝｛数据存储名，说明，编号，输入的数据流，输出的数据流， 组成:｛数据结构｝，数据量，存取频度，存取方式｝
处理过程
处理过程的具体处理逻辑一般用判定表或判定树来描述。 数据字典 中只需要描述处理过程的说明性信息即可，通常包括以下内容: 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝，处 理:｛简要说明｝
强调重点
（1）需求分析阶段的一个重要而困难的任务是收集将来应用所涉及的数据，涉及人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充。 （2）必须强调用户的参与，这是数据库应用系统设计的特点。
概念结构设计
概念模型
特点
概念模型的主要特点是: （1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对 数据的处理要求，是现实世界的一个真实模型。 （2）易于理解，可以用它和不熟悉计算机的用户交换意见。用户的积极参与是数 据库设计成功的关键。 （3）易于更改，当应用环境和应用要求改变时容易对概念模型修改和扩充。 （4）易于向关系、网状、层次等各种数据模型转换。
地位
概念模型是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。
E-R模型
定义
E-R 模型是用 E-R 图来描述现实世界的概念模型。包括实体、属性、实体之间的联 系等。
实体之间的联系
定义
实体内部的联系通常是指组成实体的各属性之间的联系，实体之间的联系通常 是指不同实体型的实体集之间的联系。 一般地，把参与联系的实体型的数目称为联系的度。两个实体型之间的联系度为2，也称为二元联系； 三个实体型之间的联系度为3，称为三元联系； N个实体型之间的联系度为N，称为N元联系.
类型
两个实体型之间的联系
两个实体型之间的联系可以分为以下三种: 一对一联系（1：1）； 一对多联系（1： n）； 多对多联系（m：n）。
两个以上的实体型之间的联系
一般地，两个以上的实体型之间也存在着一对一、一对多和多对多联系。
单个实体型内的联系
同一个实体集内的各实体之间也可以存在一对一、一对多和多对多的联系。
E-R图
E-R 图提供了表示实体型、属性和联系的方法。 ①实体型用矩形表示，矩形框内写明实体名。 ②属性用椭圆形表示，并用无向边将其与相应的实体型连接起来。 ③联系用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起 来，同时在无向边旁标上联系的类型（1：1、1：n 或 m：n）。 需要注意的是，如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。
概念结构设计
定义
概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，确定实 体、实体的属性、实体之间的联系类型，形成 E-R 图。
实体与属性的划分原则
为了简化E-R图的处置，现实世界的事物能作为属性对待的尽量作为属性对待。 ①作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能 包含其他属性。 ②属性不能与其他实体具有联系，即 E-R 图中所表示的联系是实体之间的联系。 凡满足上述两条准则的事物，一般均可作为属性对待。
E-R图的集成
概述
在开发一个大型信息系统时，最经常采用的策略是自顶向下地进行需求分析， 然后再自底向上地设计概念结构。即首先设计各子系统的分 E-R 图，然后将它 们集成起来，得到全局 E-R 图。 E-R 图的集成一般需要分两步走， 1 合并。解决各分 E-R 图之间的冲突，将分 E-R 图合并起来生成初步 E-R 图。 2 修改和重构。消除不必要的冗余，生成基本 E-R 图。
步骤
合并E-R图，生成初步E-R图
各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部视图设 计，这就导致各个子系统的 E-R 图之间必定会存在许多不一致的地方，称之为 冲突。合理消除各 E-R 图的冲突是合并 E-R 图的主要工作与关键所在。 各子系统的 E-R 图之间的冲突主要有三类:属性冲突、命名冲突和结构冲突。 1）属性冲突。属性冲突主要包含以下两类冲突: 属性域冲突，即属性值的类型、取值范围或取值集合不同； 属性取值单位冲突。 属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。 2）命名冲突。命名冲突主要包含以下两类冲突: 同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。 异名同义，即同一意义的对象在不同的局部应用中具有不同的名字。 命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。 处理 命名冲突通常也像处理属性冲突一样，通过讨论、协商等行政手段加以解 决。 3）结构冲突 结构冲突主要包含以下三类冲突: 1同一对象在不同应用中具有不同的抽象。解决方法通常是把属性变换为 实体或把实体变换为属性，使同一对象具有相同的抽象。 2同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不 完全相同。原因是不同的局部应用关心的是该实体的不同侧面。解决方 法是使该实体的属性取各子系统的 E-R 图中属性的并集，再适当调整属 性的次序。 3实体间的联系在不同的 E-R 图中为不同的类型。解决方法是根据应用的 语义对实体联系的类型进行综合或调整。
消除不必要的冗余，设计基本E-R图
在初步 E-R 图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据 是指加可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。 冗 余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以 消除。消除了冗余后的初步 R 图称为基本 E-R 图。 消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中 关于数据项之间逻辑关系的说明来消除冗余。 但并不是所有的冗余数据与冗余联 系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。 因此在设 计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根 据用户的整体需求来确定。 除分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的 概念提供了消除冗余联系的形式化工具。具体方法如下: 1)确定分 E-R 图实体之间的数据依赖。实体之间一对一、一对多、多对多的 联系可以用实体码之间的函数依赖来表示。 2)求 FL的最小覆盖 GL，差集为 D＝FL-GL 逐一考察 D 中的函数依赖，确定是否是冗余的联系，若是就把它去掉。 由于规范 化理论受到假设的限制，应注意下面两个问题: 1)冗余的联系一定在 D 中，而 D 中的联系不一定是冗余的。 2)当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分
逻辑结构设计
任务
逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用数 据库管理系统产品所支持的数据模型相符合的逻辑结构。
E-R图向关系模型的转换
E-R 图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关 系模式，如何确定这些关系模式的属性和码。将 E-R 图转换为关系模型实际上就是 要将实体型、实体的属性和实体型之间的联系转换为关系模式。 一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。 对于实体型间的联系有以下不同的情况 ： （1）一个 1:1 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关 系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的 码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候 选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性 中加入另一个关系模式的码和联系本身的属性。 （2）一个 1:n 联系可以转换为一个独立的关系模式，也可以与 n 端对应的关系模 式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以 及联系本身的属性均转换为关系的属性，而关系的码为 n 端实体的码。 （3）一个 m:n 联系转换为一个关系模式，与该联系相连的各实体的码以及联系本 身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。 （4）三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元 联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的 码组成关系的码或关系码的一部分。 （5）具有相同码的关系模式可合并。
数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还 应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。 关系数据模型的优化通常以规范化理论为指导，方法为: （1）确定数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部 各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。 （2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 （3）按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、 传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。 （4）根据需求分析阶段得到的处理要求分析对于这样的应用环境这些模式是否合 适，确定是否要对某些模式进行合并或分解。 必须注意的是，并不是规范化程度越高的关系就越优。以对于一个具体应用来说， 到底规范化到什么程度需要权衡响应时间和潜在问题两者的利弊决定。 （5）对关系模式进行必要分解，提高数据操作效率和存储空间利用率。常用的两 种分解方法是水平分解和垂直分解。 水平分解是把（基本）关系的元组分为若子集合，定义每个子集合为一个子关系， 以提高系统的效率。根据“80/20 原则”，一个大关系中，经常被使用的数据只是 关系的一部分，约 20％，可以把经常使用的数据分解出来形成一个子关系。如果 关系 R 上具有 n 个事务，而且多数事务存取的数据不相交，则 R 可分解为少于或 等于 n 个子关系，使每个事务存取的数据对应一个关系。 垂直分解是把关系模式 R 的属性分解为若干子集合，形成若干子关系模式。垂直 分解的原则是，将经常在一起使用的属性从 R 中分解出来形成一个子关系模式。 垂直分解可以提高某些事务的效率，但也可能使另一些事务不得不执行连接操 作，从而降低了效率。因此是否进行垂直分解取决于分解后 R 上的所有事务的总 效率是否得到了提高。
设计用户子模式
定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。 因此在定义用户外模式时可以注重考虑用户的习惯与方便。 具体包括以下几方 面: （1）使用更符合用户习惯的别名。 （2）可以对不同级别的用户定义不同的视图，以保证系统的安全性。 （3）简化用户对系统的使用。如果某些局部应用中经常要使用某些很复杂的查询，为 修改了方便用户，可以将这些复杂查询定义为视图。
物理结构设计
概述
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选 定的数据库文数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用 要求的物理结构的过程，就是数据库的物理设计。 数据库的物理设计通常分为两步 （1）确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。 （2）对物理结构进行评价，评价的重点是时间和空间效率 。 如果评价结果满足原设计要求，则可进入到物理实施阶段。否则，就需要重新设 计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
内容和方法
首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数； 其 次，要充分了解所用关系数据库管理系统的内部特征，特别是系统提供的存取方 法和存储结构。 对于数据库查询事务，需要得到如下信息：查询的关系；查询 条件所涉及的属性；连接条件所涉及的属性；确定取友依据查询的投影属性。 对于数据更新事务，需要得到如下信息：被更新的关系；每个关系上的更新操作 条件所涉及的属性；修改操作要改变的属性值。 此外，还需要知道每个事务 在各关系上运行的频率和性能要求。 以上是确定关系的存取方法的依据。 通常关系数据库物理设计的内容主要包括为关系模式选择存取方法，以及设计关 系、索引等数据库文件的物理存储结构。
关系模式存取方法选择
存取方法的定义
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多 用户的多种应用要求。物理结构设计的任务之一是根据关系数据库管理系统支持 的存取方法确定选择哪些存取方法。 存取方法是快速存取数据库中数据的技术。 数据库管理系统一般提供多种存取方法。 常用的存取方法为索引方法和聚簇方 法。
代表方法
B+树索引存取方法的选择
所谓选择索引存取方法，实际上就是根据应用要求确定对关系的哪些属性列建立 索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等。一般来说: ①如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或组）属性 上建立索引（或组合索引）。 ②如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上 建立索引。 ③如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或 这组）属性上建立索引。
hash索引存取方法的选择
选择hash存取方法的规则如下:如果一个关系的属性主要出现在等值连接条件中 或主要出现在等值比较选择条件中，而且满足下列两个条件之一，则此关系可以 选择 hash 存取方法。 ①一个关系的大小可预知，而且不变。 ②关系的大小动态改变，但数据库管理系统提供了动态 hash 存取方法。
聚簇存取方法的选择
为了提高某个属性（或属性组）的查询速度，把这个或这些属性上具有相同值的 元组集中存放在连续的物理块中称为聚簇。该属性（属性组）称为聚簇码。 聚簇 功能可以大大提高按聚簇码进行查询的效率。 聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系。即把多 个连接关系的元组按连接属性值聚集存放。从而大大提高连接操作的效率。 一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。选择聚簇存取方法， 即确定需要建立多少个聚簇，每个聚簇中包括哪些关系。 首先设计候选聚簇，一般来说: （1）对经常在一起进行连接操作的关系可以建立聚簇。 （2）如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立 43 聚簇。 （3）如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建 立聚簇。 然后检查候选聚簇中的关系，取消其中不必要的关系。 （1）从聚簇中删除经常进行全表扫描的关系。 （2）从聚簇中删除更新操作远多于连接操作的关系。 （3）不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能 同时加入多个聚簇。要从这多个聚簇方案中选择一个较优的，即在这个聚簇 上运行各种事务的总代价最小。
确定数据库的存储结构
簇确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、 索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。 确定数据 的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面 的因素。 （1）确定数据的存放位置。为了提高系统性能，应该根据应用情况将数据的易变 部分与稳定部分、经常存取部分和存取频率较低部分分开存放。 （2）确定系统配置。关系数据库管理系统产品一般都提供了一些系统配置变量和 存储分配参数，供设计人员和数据库管理员对数据库进行物理优化。
评价物理结构
数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为 数据库的物理结构。 评价物理数据库的方法完全依赖干所选用的关系数据库管理 系统，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手对估算 结果进行权衡、比较，选择出一个较优的，合理的物理结构。如果该结构不符合 用户需求，则需要修改设计。
数据库的实施和维护
数据的载入和应用程序的调试
数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的 编码。数据库应用程序的设计应该与数据库设计同时进行，因此在组织数据入库 的同时还要调试应用程序。
数据库的试运行
在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联 合调试了，这又称为数据库的试运行。 这一阶段要实际运行数据库应用程序，执 行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足， 对应用程序部分则要修改、调整，直到达到设计要求择为止。 在数据库试运行时，还要测试系统的性能指标，分析其是否达到设计目标。如果 测试的结果与设计目标不符，则要返回物理设计阶段重新调整物理结构，修改系 统参数，某些情况下甚至要返回逻辑设计阶段修改逻辑结构。 这里特别要强调两点。 第一，应分期分批地组织数据入库，先输入小批量数据做 调试用，待试运行基本合格后再大批量输入数据，逐步增加数据量，逐步完成运 行评价。 第二，在数据库试运行阶段，由于系统还不稳定，硬、软件故障随时都 可能发生；而系统的操作人员对新系统还不熟悉，误操作不可避免，因此要做好 数据库的转储和恢复工作。
数据库的运行和维护
数据库试运行合格后，数据库开发工作就基本完成，可以投入正式运行了。 在数 据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的库的。 维护工作主要包括以下几方面 ： （1）数据库的转储和恢复 （2）数据库的安全性、完整性控制 （3）数据库性能的监督、分析和改造 （4）数据库的重组织与重构造 数据库运行一段时间后，由于记录不断增、删、改，将会使数据库的物理存储变 坏，降低数据的存取效率，使数据库性能下降，这时数据库管理员就要对数据库 进行重组织或部分重组织。关系数据库管理系统一般都提供重组织用的实用程 序。在重组织的过程中，按原设计要求重新安排存储位置、回收垃、减少指针链 等，提高系统性能。 数据库的重组织并不修改原设计的逻辑和物理结构，而数据 库的重构造则不同，它是指部分修改数据库的模式和内模式。 如果应用变化太大，重构也无济于事，说明此数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统。