1.2 数据库系统设计

数据库系统的设计包括数据库设计和数据库应用系统设计两方面。数据库设计是设计数据库结构特征，即为特定应用环境构造出最优的数据模型；数据库应用系统设计是设计数据库的行为结构特性，并建立能满足各种用户对数据库应用需求的功能模型。数据库及应用系统的设计是开发数据库系统的首要环节和基础问题。

1.2.1 数据库系统设计概述

1.2.1.1 数据库系统设计的内容

数据库系统设计的目标是：对于给定的应用环境，建立一个良好的、能满足不同用户使用要求的、又能被选定的DBMS所接受的数据库系统模式。按照该数据库系统模式建立的数据库系统，应当能够完整地反映现实世界中信息及信息之间的联系，能够有效地进行数据存储，能够方便地执行各种数据检索和处理操作，并且有利于进行数据维护和数据控制管理的工作。

数据库系统设计的内容主要有：数据库的结构特性设计、数据库的行为特性设计、数据库的物理模式设计。在数据库系统设计过程中，数据库结构特性的设计起着关键作用，行为特性设计起着辅助作用。将数据库的结构特性设计和行为特性设计结合起来，相互参照，同步进行，才能较好地达到设计目标。

1.数据库的结构特性设计

数据库的结构特性是指数据库的逻辑结构特征。由于数据库的结构特性是静态的，一般情况下不会轻易变动，因此数据库的结构特性设计又称为数据库的静态结构设计。

数据库的结构特性设计过程是：将现实世界中的事物、事物间的联系用E-R图表示，再将各个分E-R图汇总，得出数据库的概念结构模型，最后将概念结构模型转化为数据库的逻辑结构模型表示。

最后，在选定的DBMS环境下，把数据库的逻辑结构模型加以物理实现，从而得出数据库的存储模式和存取方法。

2.数据库的行为特性设计

数据库的行为特性设计是指确定数据库用户的行为和动作，并设计出数据库应用系统的系统层次结构、功能结构和系统数据流程图，确定数据库的子模式。数据库用户的行为和动作是指数据查询和统计、事物处理及报表处理等操作，这些都要通过应用程序表达和执行。由于用户行为总是更新数据库内容的存取数据操作，其行为特性是动态的，所以数据库的行为特性设计也称为数据库的动态特性设计。

数据库行为特性的设计步骤是：将现实世界中的数据及应用情况用数据流程图和数据字典表示，并详细描述其中的数据操作要求（即操作对象、方法、频度和实时性要求）；确定系统层次结构；确定系统的功能模块结构；确定数据库的子模式；确定系统数据流程图。

1.2.1.2 数据库设计过程

数据库设计过程就是一种自上而下、逐步逼近设计目标的过程。按照规范设计的方法，同时考虑数据库及其应用系统开发的全过程，图1.2 是数据库设计过程示意图，其中将数据库设计分为几个阶段：

● 需求分析阶段。

● 结构设计阶段，主要包括概念结构设计、逻辑结构设计和物理结构设计。

● 行为设计阶段，主要包括功能设计、事务设计和程序设计。

● 数据库实施阶段，包括加载数据库数据和试运行应用程序。

● 数据库运行和维护阶段。

需求分析阶段主要是收集信息并进行分析和整理，为后续各阶段提供充足的信息，这个过程是整个设计过程的基础，也是最困难、最耗时间的阶段，需求分析做得不好，会导致整个数据库设计重新返工。

概念结构设计阶段是整个数据库设计的关键，此过程对需求分析的结果进行综合、归纳形成一个独立于具体的DBMS概念模型。逻辑结构设计阶段是将概念结构设计的结果转换为某个具体的DBMS所支持的数据模型，并对其进行优化。物理数据库设计阶段是为逻辑结构设计的结果选取一个最适合应用环境的数据库物理结构。

数据库的行为设计是要设计数据库所包含的功能、这些功能间的关联关系以及一些功能的完整性要求。

数据库实施阶段是设计人员运用DBMS提供的数据语言以及数据库开发工具，根据结构设计和行为设计的结果建立数据库，编制应用程序，组织数据入库并进行试运行。数据库运行和维护阶段指将已经过试运行的数据库应用系统投入正式使用，在数据库应用系统的使用过程中不断对其调整、修改和完善。

设计一个完善的数据库应用系统不可能一蹴而就，往往需要上述几个阶段的不断反复才能成功。

1.2.2 需求分析

需求分析是数据库设计成败的关键。需求分析阶段应该对系统的整个应用情况进行全面、详细的调查，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户的需求，并把这些要求写成用户和数据库设计者都能够接受的文档。

需求分析阶段的工作分为6个步骤。

（1）分析用户活动，产生业务流程图

了解用户当前的业务活动和职能，厘清其处理流程。把用户业务分成若干个子处理过程，使每个处理功能明确、界面清楚，画出用户活动图（业务流程图）。

（2）确定系统范围，产生系统范围图

在和用户充分讨论的基础上，确定计算机所能进行数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。

（3）分析用户活动所涉及的数据，产生数据流图

深入分析用户的业务处理，以数据流图（Data Flow Diagram，DFD）形式表示出数据的流向和对数据所进行的加工。DFD有4个基本成分：数据流、数据加工或处理、数据存储、外部实体。DFD可以形象地表示数据流与各业务活动的关系，它是需求分析的工具和分析结果的描述手段。

（4）分析系统数据，产生数据字典

仅仅有DFD并不能构成需求说明书，DFD只表示系统由哪几部分组成和各个部分之间的关系，并没有说明各个成分的含义。数据字典提供对数据库时间描述的集中管理，它的功能是存储和检索各种数据描述（元数据，Metadata），数据字典是数据收集和数据分析的主要成果，在数据库设计中占有很重要地位。

（5）功能分析

数据库的设计是与应用系统的设计紧密结合的过程，离开一定的功能，数据库就失去其存在价值。数据库设计的一个重要特点是结构（数据）和行为（功能）的结合，用户希望系统能提供的功能必须有一个清晰的描述。

功能分析是对数据流图中的处理过程进行详细的说明。功能分析可以采用软件结构图或模块图来表示系统的层次分解关系、模块调用关系。

功能分析建立在用户需求和数据分析基础上，它通常是系统模块划分和应用程序菜单设置的依据。

（6）功能数据分析

反映系统全貌的数据流图与数据、功能详细分析完成后，为保证总的系统描述和细节情况相一致，需要进行整理和审核，这一过程称为功能数据分析。

功能数据分析可以采用填写数据功能格栅图等方法，如果完成某功能所需的数据不存在，需在数据字典中添加项目；如果数据字典中的数据没有任何一个功能被使用，那么它可能是多余的或者在功能分析中有遗漏。

通过功能数据分析的最后大检验，使需求分析报告中的内容翔实准确。

有关需求分析的详细内容，特别是数据流图和数据字典的详细描述方法可参见其他相关书籍，这里不再详细介绍。

1.2.3 数据库结构设计

数据库结构设计包括设计数据库的概念结构、逻辑结构和物理结构。

1.2.3.1 概念结构设计

概念结构设计就是将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程，它是整个数据库设计的关键，它独立于逻辑结构设计，独立于DBMS。

概念结构设计方法很多，其中较早出现的、最常用的是P. P. S. Chen于1976年提出的实体-联系模型（E-R模型），近年来，统一建模语言（UML）类图方法得到了广泛的应用。

1.概念结构设计的策略

① 自底向上：先定义局部应用的概念结构，然后按一定的规则把它们集成起来，从而得到全局概念模型。

② 自顶向下：先定义全局概念模型，然后再逐步细化。

③ 逐步扩展：先定义最重要的核心结构，然后再逐步向外扩展。

④ 混合策略：将自顶向下和自底向上结合起来使用。

2.采用E-R模型方法的概念结构设计

利用E-R方法进行数据库的概念设计可以分成以下三步。

（1）进行数据抽象，设计局部概念模式

局部用户的信息需求是构造全局概念模式的基础，因此要为每个用户或每个对数据的观点与使用方式相似的用户建立一个相应的局部概念结构。

概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质细节，并把这些特性用各种概念加以准确的描述。

一般有三种抽象方法：

① 分类。定义某一类概念作为现实世界中一组对象的类型，这些对象具有某些相同的特性和行为。它抽象的是对象值和型之间的“is member of”的语义。图1.3表示了学生分类。

② 聚集。定义某一类型的组成成分，它抽象了对象内部类型和成分之间“is part of”的语义。在E-R模型中若干属性的聚集组成了实体型，就是这种抽象，如图1.4所示。

③ 概括。定义类型之间的一种子集联系，它抽象了类型之间的“is subset of”的语义。例如，学生是一个实体型，本科生、研究生也是实体型。本科生和研究生均是学生的子集。把学生称为超类，本科生和研究生为学生的子类，如图1.5所示。

概念设计的第一步就是利用上面介绍的抽象机制对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体、实体的属性，标识实体的码，确定实体之间的联系类型（1:1，1:n，m:n），设计局部E-R模型。

（2）将局部概念模式综合成全局概念模式

综合各局部概念结构就可得到反映所有用户需求的全局概念结构。

全局E-R模型的设计过程为：依次取出E-R模型，对它们进行合并，直至所有局部E-R模型都合并完毕。

在合并中，各个分E-R图之间必定存在许多不一致的地方。合理消除各分E-R图的冲突是合并分E-R图的主要工作与关键所在。冲突主要有三类：

① 属性冲突。包括属性域冲突和属性取值单位冲突。

属性域冲突即属性值的类型、取值范围或取值集合不同。如学号，有的部门把它定义为整数，有的部门定义为字符型。

属性取值单位冲突是指同一属性在不同的局部E-R模型中有不同的单位。如体重有的以公斤为单位，有的以斤为单位。

② 命名冲突。包括同名异义和异名同义。

同名异义是不同意义的对象在不同局部应用中具有相同的名字。异名同义（一义多名）是同一意义的对象在不同局部应用中具有不同的名字。

③ 结构冲突。包含3种，一是同一对象在不同应用中具有不同的抽象；二是同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同；三是实体之间的联系在不同局部视图中呈现不同的类型。

上述3类冲突中的前两类冲突可以通过协商解决，第三类冲突必须根据实际应用的语义进行调整。

（3）优化全局E-R模型

一个好的全局E-R模型除了能反映用户功能需求外，还应满足如下条件：

● 实体个数尽可能少。

● 实体所包含的属性尽可能少。

● 实体间联系无冗余。

优化的目的就是要使E-R模型满足上述3个条件。实体个数尽可能少即可以进行相关实体的合并，一般是把具有相同主码的实体进行合并。另外，还可以考虑将1:1 联系的两个实体合并为一个实体；消除冗余属性；消除冗余联系。但也应该根据具体情况，有时候适当的冗余可以提高效率。

1.2.3.2 逻辑结构设计

逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为具体的数据库管理系统支持的数据模型，也就是导出特定的DBMS可以处理的数据库逻辑结构（数据库的模式和外模式）。

特定的DBMS可以支持的数据模型有层次模型、网状模型和关系模型、面向对象模型等。

逻辑结构设计包括基本设计和视图设计两部分，下面分别予以介绍。

1.基本设计

下面我们讨论的是从概念模型向关系模型的转换方法，即将E-R模型转换成关系模型。E-R模型是由实体、实体的属性和实体的联系3个要素组成的，所以将E-R模型转换成关系模型实际上就是要将实体、实体的属性和实体的联系转化为关系模式的集合。下面介绍这种转换规则。

（1）实体集到关系模式的转换

将每个实体集转换成一个关系模式，实体的属性即为关系模式的属性，实体集的键即为关系模式的主键。

例1：将图1.4所示的实体课程转化为如下关系模型：

学生（学号，姓名，专业，班级）

其中转换后的关系模式名为学生，圆括号内列出的是关系的属性集，主键为下画线标注的（学号）。很显然，E-R图中的一个实体对应关系模式集合中的一个关系模式。

（2）联系到关系模型的转换

对于联系类型，要对1:1、1:n、m:n 3种不同的情况进行不同的处理。

① 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

② 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性转换为关系的属性，而关系的码为n端实体的码。

③ 一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性转换为关系的属性，每个实体的码组成关系的码或关系码的一部分。

④ 3个或3个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性转换为关系的属性，每个实体的码组成关系的码或关系码的一部分。

⑤ 具有相同码的关系模式可合并。

在将E-R图转换成关系表后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。

2.视图设计

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。

目前关系数据库管理系统一般都提供了视图的概念，可以利用这一功能设计更符合局部用户需求的用户外模式。

定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发的。由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便。包括：

① 使用更符合用户习惯的别名。

② 针对不同级别的用户定义不同的视图，以满足系统对安全性的要求。

③ 简化用户对系统的使用。

1.2.3.3 物理结构设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。

1.存取方法设计

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理结构设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径。

DBMS一般都提供多种存取方法。常用的存取方法有三种，第一种是索引方法，第二种是聚簇（Cluster）方法，第三种是Hash方法。

（1）索引方法

索引方法就是根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等。一般来说：

● 如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）；

● 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引；

● 如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。

关系上定义的索引数过多会带来较多的额外开销，系统维护索引要付出代价，查找索引也要付出代价。因此关系上的索引数不是越多越好。

（2）聚簇方法

为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块称为聚簇。

聚簇对某些特定应用特别有效，它可以大大提高查询的效率，但对于与聚簇属性无关的访问则效果不佳。建立聚簇开销很大，只有在以下情况下才考虑建立聚簇：

● 通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的。

● 对应每个聚簇码值的平均元组数既不太少，也不太多。太少聚簇效益不明显，而太多则要对盘区采用多种连接方式，对提高效率产生负面影响。

● 聚簇属性的值应相对稳定，可以减少修改聚簇所引起的维护开销。

（3）Hash方法

如果一个关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中，而且满足下列两个条件之一，则可以选择Hash存取方法：

● 该关系的大小可预知，而且不变；

● 该关系的大小动态改变，而且DBMS提供了动态Hash存取方法。

2.存储结构设计

确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

（1）确定数据存放位置

为了提高系统性能，应根据应用情况将数据易变部分与稳定部分、存取频率较高部分与存取频率较低部分分开存放。

例如，如果计算机有多个磁盘或磁盘阵列，可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于磁盘驱动器并行工作，因此可以提高物理读写的效率；也可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效；还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。

（2）确定系统配置

物理设计的一个重要内容是针对数据管理系统产品设置与调整系统参数配置，如数据库用户数、同时打开的数据数、内存分配参数、使用的缓冲区长度和个数、存储分配参数等。

1.2.4 数据库行为设计

前面我们详细讨论了数据库的结构设计问题，这是数据库设计中最重要的任务。数据库系统设计过程是结构设计和行为设计二者分离设计、相互参照、反复探寻的过程。在数据库系统设计中，结构特性设计和行为特性设计必须相结合才能达到设计目标。

数据库行为设计一般分为功能需求分析、功能设计、事务设计和应用程序实现，我们主要介绍前三个方面。

1.2.4.1 功能需求分析

在进行功能需求分析时，实际上进行了两项工作，一项是“数据流”的调查分析，另一项是“事务处理”的调查分析。数据流的调查分析为数据库的信息结构提供了最原始的依据，事务处理的调查分析是行为设计的基础。

对行为特性要进行如下分析：

● 标识所有的查询、报表、事务及动态特性，指出对数据库所要进行的各种处理；

● 指出对每个实体所进行的操作（增、删、改、查）；

● 给出每个操作的语义，包括结构约束和操作约束；

● 给出每个操作（针对某一对象）的频率；

● 给出每个操作（针对某一应用）的响应时间；

● 给出该系统总的目标；

● 功能需求分析是在需求分析之后、功能设计之前的一个步骤。

1.2.4.2 功能设计

系统目标的实现是通过系统的各功能模块来达到的。由于每个系统功能又可以划分为若干个更具体的功能模块，因此，可以从目标开始，一层一层分解下去，直到每个子功能模块只执行一个具体的任务为止。子功能模块是独立的，具有明显的输入信息和输出信息。当然，也可以没有明显的输入和输出信息，只是动作产生后的一个结果。通常我们按功能关系画成的图叫功能结构图，如图1.6所示。

例如，“学籍管理”的功能结构图如图1.7所示。

1.2.4.3 事务设计

事务处理是计算机模拟人处理事务的过程，包括：输入设计，输出设计，功能设计，等等。

（1）输入设计。在进行输入设计时应完成如下几方面工作：

● 原始单据的设计格式；

● 制成输入一览表；

● 制作输入数据描述文档。

（2）输出设计。在输出设计时要考虑如下因素：

● 用途。区分输出结果是给客户的还是用于内部或报送上级领导的。

● 输出设备的选择。是仅仅显示出来，还是要打印出来或需要永久保存。

● 输出量。

● 输出格式。

1.2.5 数据库的实施和维护

完成了数据库的结构设计和行为设计并编写了实现用户需求的应用程序之后，就可以利用DBMS提供的功能实现数据库逻辑设计和物理设计的结果。然后将一些数据加载到数据库中，运行已编好的应用程序，以查看数据库设计以及应用程序是否存在问题。这就是数据库的实施阶段。

1.2.5.1 数据库数据的加载和试运行

数据库结构建好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。数据装载方法有人工方法和计算机辅助数据入库方法。对于数据量不是很大的小型系统，可以用人工方法完成数据的入库；对于中大型系统，由于数据量极大，用人工方式组织入库将会消耗大量人力物力，而且很难保证数据的正确性，因此应该设计一个数据输入子系统，由计算机辅助数据的入库工作。

在数据库系统中，一般数据量都很大，各应用环境差异也很大。为了保证数据库中的数据正确、无误，必须十分重视数据的校验工作。在将数据输入系统进行数据转换过程中，应该进行多次校验。对于重要的数据，校验更应该反复多次进行，确认无误后再进入到数据库中。

在有一部分数据加载到数据库之后，就可以开始对数据库系统进行联合调试了，这个过程称为数据库试运行。

这一阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，则要对应用程序进行修改、调整，直到达到设计要求为止。

在数据库试运行阶段，还要对系统的性能指标进行测试，分析其是否达到设计目标。

1.2.5.2 数据库的运行和维护

数据库试运行合格后，数据库即可投入正式运行了。数据库投入运行标志着开发任务的基本完成和维护工作的开始，并不意味着设计过程的终结。由于应用环境在不断变化，数据库运行过程中的物理存储也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

在数据库运行阶段，对数据库的经常性维护工作主要由数据库系统管理员完成，其主要工作包括：数据库的备份和恢复；数据库的安全性和完整性控制；监视、分析、调整数据库性能；数据库的重组。

数据库的结构和应用程序设计得好坏只是相对的，它并不能保证数据库应用系统始终处于良好的性能状态。这是因为数据库中的数据是随着数据库的使用而变化的，随着这些变化的不断发生，系统的性能就有可能会日趋下降，所以即使不出现故障，也要对数据库进行维护，以便始终能够获得较好的性能。总之，数据库的维护工作与一台机器的维护工作类似，花的工夫越多，它的服务就会越好。因此，数据库的设计工作并非一劳永逸，一个好的数据库应用系统同样需要精心维护方能使其保持良好的性能。