第 3 章 数据库系统 3.3数据库设计

第 3 章 数据库系统

 

 

随着应用系统的规模越来越大，现在的系统开发大部分都是基于数据库的应用，因此， 作为一名系统架构设计师，要熟练地掌握数据库系统的设计方法和技术。

本章在宏观上就系统架构设计师必须要掌握的内容进行介绍，有关细节方面的知识，如果读者感兴趣，可以参考数据库专业教程。

3.1 数据库管理系统的类型

 

数据库管理系统的类型通常有多个分类标准。如按数据模型分类、按用户数分类、按数据库分布站点分类等。但我们需要了解的，主要还是按数据模型分类。

当前，许多商业 DBMS 中所用的主要数据模型仍是关系数据模型。有些商业系统中实现了对象数据模型，但未得到广泛使用。近几年随着 NoSQL 技术的兴起，也产生了一些新的数据模型。目前常见的 DBMS 按数据模型划分，包括：关系型 DBMS、文档型 DBMS、键值型 DBMS、对象型 DBMS 等。

3.2 数据库模式与范式

 

数据库模式与范式是数据库系统中的两个重要概念，是进行数据库设计的基础。

3.2.1 数据库的结构与模式

 

数据库技术中采用分级的方法将数据库的结构划分为多个层次。最著名的是美国 ANSI/ SPARC 数据库系统研究组 1975 年提出的三级划分法，如图 3-1 所示。

1. 三级抽象

数据库系统划分为三个抽象级：用户级、概念级、物理级。

（1） 用户级数据库。用户级数据库对应于外模式，是最接近用户的一级数据库，是用户可以看到和使用的数据库，又称用户视图。用户级数据库主要由外部记录组成，不同的用户视图可以互相重叠，用户的所有操作都是针对用户视图进行的。

（2） 概念级数据库。概念级数据库对应于概念模式，介于用户级和物理级之间，是所有用户视图的最小并集，是数据库管理员可看到和使用的数据库，又称 DBA（DataBase Administrator，数据库管理员）视图。概念级数据库由概念记录组成，一个数据库可有多个不同的用户视图，每个用户视图由数据库某一部分的抽象表示所组成。一个数据库应用系统只存在一个 DBA 视图，它把数据库作为一个整体的抽象表示。概念级模式把用户视图有机地结合成一个整体，综合平衡考虑所有用户要求，实现数据的一致性、最大限度降低数据冗余、准确地反映数据间的联系。

（3） 物理级数据库。物理级数据库对应于内模式，是数据库的低层表示，它描述数据的实际存储组织，是最接近于物理存储的级，又称内部视图。物理级数据库由内部记录组成， 物理级数据库并不是真正的物理存储，而是最接近于物理存储的级。

1. 三级模式

数据库系统的三级模式为外模式、概念模式、内模式。

（1） 概念模式。概念模式（模式、逻辑模式）用以描述整个数据库中数据库的逻辑结构，描述现实世界中的实体及其性质与联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系，是数据项值的框架。

数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念/物理之间的映射。

概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个概念模式。

外模式是数据库用户（包括程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。一个应用程序只能使用一个外模式。

（2） 外模式。外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。

（3） 内模式。内模式是整个数据库的最低层表示，不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织。

内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。

内模式、模式和外模式之间的关系如下：

（1） 模式是数据库的中心与关键；

（2） 内模式依赖于模式，独立于外模式和存储设备；

（3） 外模式面向具体的应用，独立于内模式和存储设备；

（4） 应用程序依赖于外模式，独立于模式和内模式。

1. 两级独立性

数据库系统两级独立性是指物理独立性和逻辑独立性。三个抽象级间通过两级映射（外模式—模式映射，模式—内模式映射）进行相互转换，使得数据库的三级形成一个统一的整体。

（1） 物理独立性。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时，应用程序不需要改变。

物理独立性存在于概念模式和内模式之间的映射转换，说明物理组织发生变化时应用程序的独立程度。

（2） 逻辑独立性。逻辑独立性是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据的逻辑结构改变时，应用程序不需要改变。

逻辑独立性存在于外模式和概念模式之间的映射转换，说明概念模式发生变化时应用程序的独立程度。

希赛教育专家提示：逻辑独立性比物理独立性更难实现。

 

 

3.2.2 数据模型

 

数据模型主要有两大类，分别是概念数据模型（实体—联系模型）和基本数据模型（结构数据模型）。

概念数据模型是按照用户的观点来对数据和信息建模，主要用于数据库设计。概念模型主要用实体—联系方法（Entity-Relationship Approach）表示，所以也称 E-R 模型。

基本数据模型是按照计算机系统的观点来对数据和信息建模，主要用于 DBMS 的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述，数据操作是对系统动态特性的描述，完整性约束是一组完整性规则的集合。

常用的基本数据模型有层次模型、网状模型、关系模型和面向对象模型。

层次模型用树形结构表示实体类型及实体间的联系。层次模型的优点是记录之间的联系通过指针来实现，查询效率较高。层次模型的缺点是只能表示 1:n 联系，虽然有多种辅助手段实现 m:n 联系，但比较复杂，用户不易掌握。由于层次顺序的严格和复杂，导致数据的查询和更新操作很复杂，应用程序的编写也比较复杂。

网状模型用有向图表示实体类型及实体间的联系。网状模型的优点是记录之间的联系通过指针实现，m:n 联系也容易实现，查询效率高。其缺点是编写应用程序的过程比较复杂， 程序员必须熟悉数据库的逻辑结构。

关系模型用表格结构表达实体集，用外键表示实体间的联系。其优点有：

（1） 建立在严格的数学概念基础上；

（2） 概念（关系）单一，结构简单、清晰，用户易懂易用；

（3） 存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。

3.2.2 关系代数

 

关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。

（1） 并。计算两个关系在集合理论上的并集，即给出关系 R 和 S（两者有相同元/列数），R∪S  的元组包括 R  和 S  所有元组的集合，形式定义如下：

RUSo{t|tÎRútÎS}

式中 t 是元组变量（下同）。显然，R∪S=S∪R。

（2） 差。计算两个关系的区别的集合，即给出关系 R 和 S（两者有相同元/列数），R-S的元组包括 R  中有而 S  中没有的元组的集合，形式定义如下：

R -So{t|tÎR ùtÏS}

（3） 交。计算两个关系集合理论上的交集，即给出关系 R  和 S（两者有相同元/列数），

R∩S 的元组包括 R 和 S 相同元组的集合，形式定义如下：

RISo{t |tÎRùtÎS}

显然，R∩S = R-(R-S) 和 R∩S = S-(S-R)成立。

（4） 笛卡尔积。计算两个关系的笛卡尔乘积，令 R 为有 m 元的关系，S 为有 n  元的关系，则 R×S 是 m+n 元的元组的集合，其前 m 个元素来自 R  的一个元组，而后 n  个元素来自 S 的一个元组。形成定义如下：

R′So{t |t=<tr,ts >ùtr ÎRùts ÎS}

若 R 有 u 个元组，S 有 v 个元组，则 R×S  有 u×v  个元组。例如，有关系 R  与关系 S 如表 3-1 和表 3-2 所示。

对 R 与 S 做笛卡尔积运算，其结果有 4+2＝6 列，元组数量有 3*2＝6 条。如表 3-3

所示。

（5） 投影。从一个关系中抽取指明的属性（列）。令 R 为一个包含属性 A 的关系，

则

pA(R)o{t[A]|tÎR}

例如，对表 3-1 关系 R 做投影操作， p1,2(R)，则结果如表 3-4 所示。

注意：在关系代数操作中涉及的数字代表的是列号，， p1,2(R)操作是对第 1  列与第 2

列做投影。

其中 F 表示选择条件，是一个逻辑表达式（逻辑运算符+算术表达式）。选择运算是从元组（行）的角度进行的运算。

（7）θ连接。θ连接从两个关系的笛卡儿积中选取属性之间满足一定条件的元组，记作：

其中 A 和 B 分别为 R 和 S  上元数相等且可比的属性组。θ 为“=”的连接，称为等值连接，记作：

如果两个关系中进行比较的分量必须是相同的属性组，并且在结果中将重复的属性去掉， 则称为自然连接，记作：

例如，对表 3-1 关系 R 与表 3-2 关系 S 做自然连接操作。结果集如表 3-6 所示。

（8）除。设有关系 R(X，Y)与关系 S(Z)，Y 和 Z 具有相同的属性个数，且对应属性出自相同域。关系 R(X，Y)÷S(Z)所得的商关系是关系 R 在属性 X 上投影的一个子集，该子

集和 S(Z)的笛卡尔积必须包含在 R(X，Y)中，记为 R÷S，其具体计算公式为：

例如，对表 3-1 的关系 R 与表 3-2 的关系 S 做除法运算。

求解过程为：首先，按除运算定义要求，确定 X，Y，Z 属性集合。Y 是关系 R 中的属性集合，Z 是 S 中全部属性的集合，即 Z={U3，U4}，由于 Y=Z，因此，Y={U3，U4}， X={U1， U2}。也就是说，R÷S 结果集包含属性 U1 和 U2；然后，将关系 R 的 U1、U2（共有<a， b>、<c，a>两个元组）与关系 S 作笛卡尔积操作，结果如表 3-7 所示。

通过检查表 3-7，可以发现元组<a，b>与 S(Z)的笛卡尔积被包含在 R(X，Y)中，而元组

<c，a>与 S(Z)的笛卡尔积有一个元组未被包含在 R(X，Y)中，所以，结果集中只有元组<a， b>。

3.2.4 数据的规范化

 

关系模型满足的确定约束条件称为范式，根据满足约束条件的级别不同，范式由低到高分为 1NF（第一范式）、2NF（第二范式）、3NF（第三范式）、BCNF（BC 范式）、4NF（第四范式）等。不同的级别范式性质不同。

把一个低一级的关系模型分解为高一级关系模型的过程，称为关系模型的规范化。关系模型分解必须遵守两个准则。

（1） 无损连接性：信息不失真（不增减信息）。

（2） 函数依赖保持性：不破坏属性间存在的依赖关系。

规范化的基本思想是逐步消除不合适的函数依赖，使数据库中的各个关系模型达到某种程度的分离。规范化解决的主要是单个实体的质量问题，是对于问题域中原始数据展现的正规化处理。

规范化理论给出了判断关系模型优劣的理论标准，帮助预测模式可能出现的问题，是数据库逻辑设计的指南和工具，具体有：

（1） 用数据依赖的概念分析和表示各数据项之间的关系。

（2） 消除 E-R 图中的冗余联系。

1. 函数依赖

通俗地说，就像自变量 x 确定之后，相应的函数值 f(x)也就唯一确定了一样，函数依赖是衡量和调整数据规范化的最基础的理论依据。

例如，记录职工信息的结构如下： 职工工号（EMP_NO）

职工姓名（EMP_NMAE） 所在部门（DEPT）。

则说 EMP_NO 函数决定 EMP_NMAE 和 DEPT，或者说 EMP_NMAE，DEPT 函数依赖于 EMP_NO，记为：EMP_NO→EMP_NMAE，EMP_NO→DEPT。

关系 R<U，F>中的一个属性或一组属性 K，如果给定一个 K 则唯一决定 U 中的一个元组，也就是 U 函数完全依赖于 K，就称 K 为 R 的码。一个关系可能有多个码，选中其中一个作为主码。

包含在任一码中的属性称为主属性，不包含在任何码中的属性称为非主属性。

关系 R 中的属性或属性组 X 不是 R 的码，但 X 是另一个关系模型的码，称 X 是 R

的外码。

主码和外码是一种表示关系间关联的重要手段。数据库设计中一个重要的任务就是要找到问题域中正确的关联关系，孤立的关系模型很难描述清楚业务逻辑。

1. 第一范式

1NF 是最低的规范化要求。如果关系 R 中所有属性的值域都是简单域，其元素（即属性）不可再分，是属性项而不是属性组，那么关系模型 R 是第一范式的，记作 RÎ1NF。这一限制是关系的基本性质，所以任何关系都必须满足第一范式。第一范式是在实际数据库设计中必须先达到的，通常称为数据元素的结构化。

例如，表 3-8 所示的结构就不满足 1NF 的定义。

表 3-8 为非第一范式，分解如表 3-9 所示。

就满足了第一范式。经过处理后，就可以以省、市为条件进行查询和统计了。

满足 1NF 的关系模型会有许多重复值，并且增加了修改其数据时引起疏漏的可能性。为了消除这种数据冗余和避免更新数据的遗漏，需要更加规范的 2NF。

1. 第二范式

如果一个关系 R 属于 1NF，且所有的非主属性都完全依赖于主属性，则称之为第二范式，记作RÎ2NF。

为了说明问题，现举一个例子来说明：

有一个获得专业技术证书的人员情况登记表结构为：

省份、姓名、证书名称、证书编号、核准项目、发证部门、发证日期、有效期。

这个结构符合 1NF，其中“证书名称”和“证书编号”是主码，但是因为“发证部门” 只完全依赖于“证书名称”，即只依赖于主关键字的一部分（即部分依赖），所以它不符合 2NF， 这样首先存在数据冗余，因为证书种类可能不多。其次，在更改发证部门时，如果漏改了某 一记录，存在数据不一致。再次，如果获得某种证书的职工全部跳槽了，那么这个发证部门 的信息就可能丢失了，即这种关系不允许存在某种证书没有获得者的情况。

可以用分解的方法消除部分依赖的情况，而使关系达到 2NF 的标准。方法是，从现有关系中分解出新的关系表，使每个表中所有的非关键字都完全依赖于各自的主关键字。可以分解成两个表（省份、姓名、证书名称、证书编号、核准项目、发证日期、有效期）和（证书名称、发证部门），这样就完全符合 2NF  了。

1. 第三范式

如果一个关系 R 属于 2NF，且每个非主属性不传递依赖于主属性，这种关系是 3NF， 记作 RÎ3NF。

从 2NF  中消除传递依赖，就是 3NF。例如，有一个表（职工姓名，工资级别，工资额），其中职工姓名是关键字，此关系符合 2NF，但是因为工资级别决定工资额，也就是说非主属性“工资额”传递依赖于主属性“职工姓名”，它不符合 3NF，同样可以使用投影分解的办法分解成两个表：（职工姓名，工资级别），（工资级别，工资额）。

1. BC 范式

一般满足 3NF 的关系模型已能消除冗余和各种异常现象，获得比较满意的效果，但无论 2NF 还是 3NF 都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。由此引入 BC 范式（由 Boyeet 和 Codd 提出）。通常认为 BCNF 是第三范式的改进。

BC 范式的定义：如果关系模型 R∈1NF，且 R 中每一个函数依赖关系中的决定因素都包含码，则 R 是满足 BC 范式的关系，记作 RÎBCNF。

当一个关系模型 R BCNF，则在函数依赖范畴里，就认为已彻底实现了分离，消除了插入、删除的异常。

综合 1NF、2NF 和 3NF、BCNF 的内涵可概括如下：

（1） 非主属性完全函数依赖于码（2NF  的要求）；

（2） 非主属性不传递依赖于任何一个候选码（3NF  的要求）；

（3） 主属性对不含它的码完全函数依赖（BCNF  的要求）；

（4） 没有属性完全函数依赖于一组非主属性（BCNF 的要求）。

3.2.5 反规范化

 

数据库中的数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O 次数减少，同时加快了增、删、改的速度，但是对完全规范的数据库查询，通常需要更多的连接操作，从而影响查询速度。因此，有时为了提高某些查询或应用的性能而破坏规范规则，即反规范化（非规范化处理）。

常见的反规范化技术包括：

（1） 增加冗余列

增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如：以规范化设计的理念，学生成绩表中不需要字段“姓名”，因为“姓名”字段可以通过学号查询到，但在反规范化设计中，会将“姓名”字段加入表中。这样查询一个学生的成绩时，不需要与学生表进行连接操作，便可得到对应的“姓名”。

（2） 增加派生列

增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。例如：订单表中，有商品号、商品单价、采购数量，我们需要订单总价时，可以通过计算得到总价，所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑，由于订单总价在每次查询都需要计算，这样会占用系

统大量资源，所以在此表中增加派生列“订单总价”以提高查询效率。

（3） 重新组表

重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。

（4） 分割表

有时对表做分割可以提高性能。表分割有两种方式。

水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用。

情况 1：表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询效率。

情况 2：表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。

情况 3：需要把数据存放到多个介质上。

垂直分割：把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少 I/O 次数。其缺点是需要管理冗余列，查询所有数据需要连接操作。

3.3 数据库设计

 

数据库设计的过程是将数据库系统与现实世界密切地、有机地、协调一致地结合起来的过程。数据库的设计质量与设计者的知识、经验和水平密切相关。作为数据库应用系统的重要组成部分，数据库设计的成败往往直接关系到整个应用系统的成败。

以数据库为基础的数据库应用系统与其他计算机应用系统相比往往具有数据量庞大、数据保存时间长、数据关联复杂、用户要求多样化等特点。

数据库设计中面临的主要困难和问题有：

（1） 同时具备数据库知识与应用业务知识的人很少。懂得计算机与数据库的人一般都缺乏应用业务知识和实际经验，而熟悉应用业务的人又往往不懂计算机和数据库。

（2） 项目初期往往不能确定应用业务的数据库系统的目标。

（3） 缺乏完善的设计工具和设计方法。

（4） 需求的不确定性。用户总是在系统的开发过程中不断提出新的要求，甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。

（5） 应用业务系统千差万别，很难找到一种适合所有业务的工具和方法，这就增加了研究数据库自动生成工具的难度。因此，研制适合一切应用业务的全自动数据库生成工具是不可能的。

3.3.1 数据库设计的方法

 

目前已有的数据库设计方法可分为四类，即直观设计法、规范设计法、计算机辅助设计法和自动化设计法。直观设计法又称单步逻辑设计法，它依赖于设计者的知识、经验和技巧， 缺乏工程规范的支持和科学根据，设计质量也不稳定，因此越来越不适应信息管理系统发展的需要。为了改变这种状况，1978 年 10 月来自 30 多个欧美国家的主要数据库专家在美国新奥尔良市专门讨论了数据库设计问题，提出了数据库设计规范，把数据库设计分为需求分析、概念结构设计、逻辑结构设计和物理结构设计 4 个阶段。目前，常用的规范设计方法大多起源于新奥尔良方法，如基于 3NF 的设计方法、LRA 方法、面向对象的数据库设计方法及基于视图概念的数据库设计方法等。架构设计师考试中，主要了解基于 3NF 的数据库设计方法即可。

基于 3NF 的数据库设计方法是由 S.Atre 提出的数据库设计的结构化设计方法，其基本思想是在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将它们组织成一个单一的关系模型，然后再分析模式中不符合 3NF 的约束条件，用投影和连接的办法将其分解，使其达到 3NF 条件。其具体设计步骤分为 5 个阶段，如图 3-2 所示。

3-2 基于 3NF 的数据库设计方法

 

（1） 设计企业模式。利用上述得到的 3NF 关系模型画出企业模式。具体包括：

分析应用环境，并设定环境中所使用的各种资料。

确定每一种报表各自所包含的数据元素。

确定数据元素之间的关系，如确定主关键字和一般的数据元素。

对每一组或若干组数据元素推导出 3NF 的关系模型。

3NF 关系模型的基础上画出数据库的企业模式。

（2） 设计数据库逻辑模式。根据上一步得到的企业模式选定数据模型，从而得出适用 于某个 DBMS 的逻辑模式。根据逻辑模式导出各种报表与事务处理所使用的外模式。

（3） 设计数据库物理模式（存储模式）。根据数据库的逻辑模式和给定的计算机系统 设

计物理模式。

（4） 评价物理模式。对物理模式估算空间利用情况，并推算输入输出的概率。必要时 根据物理模式调整各种报表与事务处理的外模式。对外模式进行存取时间的估算。

（5） 数据库实现。具体实现数据库。

3.3.2 数据库设计的基本步骤

 

分步设计法遵循自顶向下、逐步求精的原则，将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的技术与工具，解决不同的问题，从而将问题局部化， 减少了局部问题对整体设计的影响。目前，此方法已在数据库设计中得到了广泛应用并获得了较好的效果。

在分步设计法中，通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计 4 个阶段，如图 3-3 所示。

1. 需求分析

需求分析是指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。其目标是通过调查研究，了解用户的数据要求和处理要求，并按一定格式整理形成需求说明书。需求说明书是需求分析阶段的成果，也是今后设计的依据， 它包括数据库所涉及的数据、数据的特征、使用频率和数据量的估计，如数据名、属性及其类型、主关键字属性、保密要求、完整性约束条件、更改要求、使用频率、数据量估计等。这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。用数据字典管理元数据有利于避免数据的重复或重名，以保持数据的一致性及提供各种统计数据，因而有利于提高数据库设计的质量，同时可以减轻设计者的负担。

1. 概念结构设计

它是数据库设计的第二阶段，其目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，即用户的数据模型或企业数据模型。这种概念数据模型与 DBMS 无关，是面向现实世界的、极易为用户所理解的数据模型。为保证所设计的概念数据模型能正确、完整地反映用户的数据及其相互关系，便于进行所要求的各种处理，在本阶段设计中可吸收用户参与和评议设计。在进行概念结构设计时，可先设计各个应用的视图（view），即各个应用所看到的数据及其结构，然后再进行视图集成，以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改，最后形成所需的概念数据模型。

1. 逻辑结构设计

这一阶段的设计目标是把上一阶段得到的与 DBMS 无关的概念数据模型转换成等价的， 并为某个特定的 DBMS  所接受的逻辑模型所表示的概念模式，同时将概念设计阶段得到的应用视图转换成外部模式，即特定 DBMS  下的应用视图。在转换过程中要进一步落实需求说明，并满足 DBMS 的各种限制。该阶段的结果是用 DBMS 所提供的数据定义语言（DDL） 写成的数据模式。逻辑设计的具体方法与 DBMS  的逻辑数据模型有关。逻辑模型应满足数据库存取、一致性及运行等各方面的用户需求。

1. 数据库物理设计

物理设计阶段的任务是把逻辑设计阶段得到的满足用户需求的已确定的逻辑模型在物理上加以实现，其主要内容是根据 DBMS 提供的各种手段，设计数据的存储形式和存取路径， 如文件结构、索引设计等，即设计数据库的内模式或存储模式。数据库的内模式对数据库的性能影响很大，应根据处理需求及 DBMS、操作系统和硬件的性能进行精心设计。

实际上，数据库设计的基本过程与任何复杂系统开发一样，在每一阶段设计基本完成后，

都要进行认真的检查，看是否满足应用需求，是否符合前面已执行步骤的要求和满足后续步骤的需要，并分析设计结果的合理性。在每一步设计中，都可能发现前面步骤的遗漏或处理不当之处，此时，往往需要返回去重新处理并修改设计和有关文档。所以，数据库设计过程通常是一个反复修改、反复设计的迭代过程。

3.3.3 需求分析

 

需求分析是数据库设计过程的第一步，是整个数据库设计的依据和基础。需求分析做得不好，会导致整个数据库设计重新返工。需求分析的目标是通过对单位的信息需求及处理要求的调查分析得到设计数据库所必需的数据集及其相互联系，形成需求说明书，作为后面各设计阶段的基础。因此，这一阶段的任务是：

1. 确认需求、确定设计目标

数据库设计的第一项工作就是要对系统的整个应用情况进行全面、详细的实地调查，弄清现行系统的组织结构、功能划分、总体工作流程，收集支持系统总的设计目标的基础数据和对这些数据的处理要求，明确用户总的需求目标；通过分析，确定相应的设计目标，即确定数据库应支持的应用功能和应用范围，明确哪些功能由计算机完成或准备让计算机完成， 哪些环节由人工完成，以确定应用系统实现的功能。这一阶段收集到的基础数据和一组数据流程图是下一步进行概念设计的基础。

1. 分析和收集数据

这是整个需求分析的核心任务。它包括分析和收集用户的信息需求、处理需求、完整性需求、安全性需求，以及对数据库设计过程有用的其他信息。

信息需求是指在设计目标范围内涉及的所有实体、实体的属性及实体间的联系等数据对象，包括用户在数据处理中的输入/输出数据及这些数据间的联系。在收集中，要收集数据的名称、类型、长度、数据量、对数据的约束及数据间联系的类型等信息。

处理需求是指为了获得所需的信息而对数据加工处理的要求。它主要包括，处理方式是实时还是批处理，各种处理发生的频度、响应时间、优先级别及安全保密要求等。所要收集的其他信息还有企业在管理方式、经营方式等方面可能发生的变化等。

分析和收集数据的过程是数据库设计者对各类管理活动进行深入调查研究的过程，调查对象包括数据管理部门的负责人、各使用部门的负责人及操作员等各类管理人员，通过与各类管理人员相互交流，逐步取得对需求的一致认识。

1. 整理文档

分析和收集得到的数据必须经过筛选整理，并按一定格式和顺序记载保存，经过审核成为正式的需求说明文档，即需求说明书。实际上，需求说明书是在需求分析的过程中逐渐整理形成的，是随着这一过程的不断深入而反复修改与完善的对系统需求分析的全面描述。由用户、领导和专家共同评审，是以后各设计阶段的主要依据。这一步的工作是进行全面的汇总与整理，使之系统化，以形成标准化的统一形式。

3.3.4 概念结构设计

 

概念结构设计阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。概念结构设计的目标是产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。概念结构设计的任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

概念数据模型的作用是：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。

概念模型的描述工具应该能够体现概念模型的特点，如 E-R 模型。近年来，由于面向对象数据模型具有更丰富的语义、更强的描述能力而越来越受到人们的重视，不但出现了商品化的面向对象 DBMS，而且开始实际应用于概念模型的设计中，作为数据库概念设计的工具。 Teory 等人提出的扩展的 E-R  模型增加了类似面向对象数据模型中的普遍化和聚合等语义描述机制，为这种最为人们熟悉的数据模型注入了新的生机，为概念模型的描述增加了一种理想的选择。

概念结构的设计策略主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案，一是建立一个覆盖整个单位所有功能域的全局数据库， 称之为全局方案或全局策略；另一种则是对每一个应用都建立一个单独的数据库，称之为应用方案或应用策略。

由于各个部门对于数据的需求和处理方法各不相同，对同一类数据的观点也可能不一样， 它们有自己的视图，所以可以首先根据需求分析阶段产生的各个部门的数据流图和数据字典 中的相关数据设计出各自的局部视图，然后进行视图集成。

1. 视图设计

在实体分析法中，局部视图设计的第一步是确定其所属的范围，即它所对应的用户组， 然后对每个用户组建立一个仅由实体、联系及它们的标识码组成的局部信息结构（局部数据模式）框架，最后再加入有关的描述信息，形成完整的局部视图（局部数据模式）。这样做的目的是为了集中精力处理好用户数据需求的主要方面，避免因无关紧要的描述细节而影响局部信息结构的正确性。整个过程可分为 4 个步骤：确定局部视图的范围；识别实体及其标识；确定实体间的联系；分配实体及联系的属性。

（1） 确定局部视图的范围。需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据，但它通常与子模式范围相对应，有时因为过大而不利于局部信息结构的构造，故可根据情况修改，但也不宜分得过小，过小会造成局部视图的数量太大及大量的数据冗余和不一致性，给以后的视图集成带来很大的困难。

局部视图范围确定的基本原则是：

各个局部视图支持的功能域之间的联系应最少。

实体个数适量。一个局部视图所包含的实体数量反映了该局部视图的复杂性，按照信息论中“7 2”的观点，人们在同一时刻可同时顾及的事情一般在 5～9 之间，其中以 6 或 7 最

为适当。因此，一个局部视图内的实体数不宜超过 9 个，否则就会过于复杂，不便于人们理解和管理。

（2） 识别实体及其标识。在需求分析中，人们已经初步地识别了各类实体、实体间的联系及描述其性质的数据元素，这些统称为数据对象，它们是进一步设计的基本素材。这一步的任务就是在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本实体及其标识，并定义有关数据对象在 E-R 模型中的地位。

（3） 确定实体间的联系。实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工作一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。

在现实世界中，诸多形式的联系大致可分为三类：存在性联系、功能性联系和事件联系。存在性联系如学校有教师、教室有学生、工厂有产品、产品有顾客等；功能性联系如教师讲授课程、教师参与科研、仓库管理员管理仓库等；事件联系如学生借书、产品发运等。

根据上述分类仔细检查在给定的局部视图范围内是否有未识别的联系，在确认所有的联系都已识别并无遗漏之后，还需对联系进行正确的定义。定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。

① 二元联系的类型与定义。二元联系是指两个实体类之间的联系。根据参与联系的两

个实体类值之间的对应关系分为一对一、一对多及多对多三种类型。

一对一联系：这是一种最简单的联系类型。若对于实体集 A  中的每一个实体，实体集 B  中至多有一个实体与之联系，反之亦然，则称实体集 A 与实体集 B 具有一对一联系，记为 1:1。例如在一个施工单位中，如果规定每项工程最多只能由一名工程师负责管理，而一名工程师 最多也只能负责一项工程，则工程师与工程间的这种管理联系便是一对一联系。

一对多联系：若对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（n≥0）与之联系；反之，对于实体集 B 中的每一个实体，实体集 A 中至多有一个实体与之联系，则称实体集 A 与实体集 B 有一对多的联系，记为 1:n。以专业与学生间的关系为例：如规定一个专业可以管理许多学生，每个学生只能属于一个专业，这种联系就是一对多联系。

多对多联系：若对于实体集 A 中的每一个实体，实体集 B  中有 n  个实体（n≥0）与之联系，反过来，对实体集 B 中每一个实体，实体集 A 中也有 m 个实体（m≥0）与之联系， 则称实体集 A 与实体集 B  具有多对多联系，记为 m:n。教师与学生这两个实体类间的教与学的联系就是多对多的联系。这时，只有<教师、学生>对才能确定一个特定的教学联系。因此，一般情况下可以以两个关联实体的标识拼凑作为联系的标识。但这种方法对某些情况就不能构成有效的联系标识。当一个实体值在同一个联系上可能存在多个不同的联系值时， 就会出现这种情况。如教师与其讲授的课程之间的联系，同一个教师可讲授几门不同的课程， 也可以多次讲授同一门课程，这是一种特殊的多对多联系。显然，对于教师与讲授课程间的联系，如在教师档案中要求记录担任教学工作的情况，就需要在联系标识中增加表示授课日期的属性，即其合适的联系标识可能为（教师号，课程号，授课日期）。

实体类内部的联系：这种联系发生在同一类实体的不同实体之间，因此称为内部联系或自联系，它也是一种二元联系，其表示方式与前面的二元联系并无不同，要注意仔细区别同一实体类中的不同实体在联系中扮演的不同角色及联系标识的选择。例如在职工类实体中间就存在着管理者与被管理者的联系。一个职工可以管理别的职工，称为管理者或领导者。一个管理者可以管理多个职工，而一个职工最多只从属于一位管理者，从而构成了一对多联系。若规定所有职工都要受管理（最高管理者考虑自己管理自己），但不是所有职工都是管理者，则此联系在“多”端呈现强制性。其中每个联系实体包含两个职工号值：职工号和管理员职工号，以区别不同的实体在联系中的角色。

若略去实体与其属性图，以上实体间的二元联系可用图 3-4 表示。

② 多元联系的识别与定义。两个以上的实体类之间的联系称为多元联系。例如在供应商向工程供应零件这类事件中，如果任一供应商可向任一工程供应任一种零件，则为了确定哪个供应商向哪个工程供应了何种零件，就必须定义一个三元联系，因为只有供应商、工程及零件三者一起才能唯一地确定一个联系值。其联系的标识由参与联系的实体类的标识拼接而成，在此例中由供应商、工程、零件三个实体类的标识拼接而成。

1. 视图集成

视图集成就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的 单一数据视图，即全局数据模式，又称模式汇总。该全局数据模式是未来数据库结构的基础， 因此视图集成是数据库设计过程中一个十分重要的步骤，也是一项较为复杂和困难的任务。当所有局部视图设计完毕，就可开始视图集成。集成过程中会发生一些冲突，冲突的表现和处理策略如下：

① 同名异义。为了发现不同视图间的同名异义问题，可以列出所有同名数据对象，然后逐一判别其语义。对同名异义冲突通常采用换名加以解决，既可对同名者之一换名，也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。

② 异名同义。识别异名同义比较困难，一般由设计者对所有对象一个不漏地逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象，则可以把其中之一的名称作为合并后的对象名；若集成后，它们仍以两个不同的对象存在，则可对其一换名。当然， 若原名都不合适，则可以对两者都重新命名。

③ 同名不同层次。如果两个对象同名，但其中之一是作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时就会发生同名不同层次的冲突。解决这种冲突的办法有两个，一是将属性转换为实体，二是将实体变换成属性。

例如，设一局部视图中有一部门实体 DEPT，而在另一与之集成的视图中有职工实体

EMP，且 EMP  有属性 DEPT，于是发生了同名不同层次的冲突。此时，可将 EMP  的 DEPT

属性去掉，另设一个实体 DEPT 与 EMP 建立联系，这时再与另一视图集成就容易多了。再如，设一局部视图中有一名为 STOR    的仓库实体，其中含有一属性部门号（DEPT-NO）；

在另一局部视图中有一单位实体 DEPT，其中仅含有一个属性 DEPT-NO。对这类同名不同层次的冲突，可将 DEPT 实体变换为其所在视图中与 DEPT 相关的另一实体的属性，然后再进行集成。

希赛教育专家提示：实体变换为属性时通常要满足一些特定条件，例如，该实体通常只 含有一个与同名属性具有共同特征的属性，且一定存在一个与该实体存在联系的另外的实体。

④ 虽同名同义，但对象联系测度不同。所谓联系测度是指实体的联系是一对一、一对多还是多对多。若同名同义对象在一个局部视图中为一对多联系，在另一局部视图中为多对多联系，则在集成时将发生联系测度冲突。一般而言，一对多包含一对一，多对多包含一对多。所以解决这种冲突的方法往往取较高测度为集成后的相应联系的测度。

3.3.5 逻辑结构设计

 

数据库逻辑结构设计的任务就是把概念结构设计阶段设计好的基本 E-R 图转换为与具体机器上的 DBMS 产品所支持的数据模型相符合的逻辑结构。这一阶段是数据库结构设计的重要阶段。

数据库逻辑设计的基础是概念设计的结果，而其成果应包括某 DBMS 所支持的外模式、概念模式及其说明及建立外模式和概念模式的 DDL 程序。因此，进行逻辑设计前，必须了解数据库设计的需求说明和概念设计的成果（包括 E-R  图和其他文档），并仔细阅读有关 DBMS 的文件。数据库的外模式和概念模式是用户所看到的数据库，是应用程序访问数据库的接口，因此在数据库逻辑设计阶段，还必须提供应用程序编制的有关说明，最好试编一些典型的访问数据库的应用程序，以检验所设计的概念模式是否满足使用要求。概念模式是数据库的基础，它的设计质量对数据库的使用和性能，以及数据库在今后发展过程中的稳定性均有直接的影响。为了设计出能够正确反映一个项目数据间内在联系的好的概念模式，设计时必须正确处理各种应用程序之间、数据库性能与数据模式的合理性和稳定性之间的各种矛盾，对设计中出现的各种矛盾要权衡利弊，分清主次，按统筹兼顾的原则加以正确处理。

逻辑结构设计一般分为以下几个步骤：

（1） 将概念结构向一般关系模型转化。

（2） 将第一步得到的结构向特定的 DBMS 支持下的数据模型转换。

（3） 依据应用的需求和具体的 DBMS 的特征进行调整与完善。

下面以常用的 E-R 模型和扩充 E-R 模型为主，针对关系数据库的逻辑设计介绍基本原则和方法。

1. 基本E-R 模型向关系模型的转换

基本 E-R 模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性。其转换的基本原则是，实体和联系分别转换成关系，属性则转换成相应关系的属性。因此，E-R 模型向关系模型的转换比较直观，但不同元数的联系具体转换方法稍有不同，下面根据不同的情况分别讨论。

（1） 一对一联系。设有两个实体 E1 和 E2 之间为一对一联系。此情况存在三种可能的转换方案。

方案 1：将实体 E1、E2 和联系名 R 分别转换成为关系 E1、E2 和 R，它们的属性分别转为相应关系的属性，即得到：

El（k1，a） E2（k2，b）

R（k1，k2，r）（k2  是候选关键字）

其中属性下面带一横线者为关系的关键字。

方案 2：将实体 El 转换为关系 El ，将实体 E2  与联系名 R  一起转换成关系 E2  ，E2 的属性由 E2 和 R 的属性加上 E1 的关键字组成，其关键字 k1、k2  为其候选关键字。转换后的关系为：

E1（kl，a）

E2′（k2，b，k1，r），（k1 是候选关键字）

方案 3：与方案 2 类似，不过把实体E1 与联系R 一起转换成关系E1 后，其结果为：

E1′（kl，a，k2，r），（k2 是候选关键字）

E2（k2，b）

上述三个方案实际上可归结为转换成三个关系和转换成两个关系两种。如果每个实体的属性数较少，而联系的属性与两个实体之一关系又较密切，则可采用方案 2 或方案 3，其优点是可减少关系数，有利于减少连接运算从而提高查询效率，但如果每个实体的属性较多， 且合并后，会造成较大数据冗余和操作异常，则以采用方案 1 为宜。

（2） 一对多联系。这种情况存在两种转换方案，其一是把两个实体类和一个联系类分

别转换成对应的关系，实体类的属性转换为对应关系的属性，其标识属性即为对应关系的关键字，而联系类转换得到的关系，其属性由两个实体的标识属性和联系类本身的属性组成， 并以多端实体类的标识属性为其关键字。其转换结果为三个关系。第二个方案是转换

成两个关系，设少端和多端的两个实体类分别为 El、E2，联系名 R。转换时，将实体类 El 转换为一个关系 El，E2 和 R 合起来转换成一个关系 E2′，E2′的属性由 E2 和 R 的属性加上 E1 的标识属性组成，并以 E 2 的标识属性为其关键字。

（3） 多对多联系。由两个实体类之间多对多联系组成的 E-R 模型向关系模型转换时， 将两个实体类和一个联系类分别转换成关系，实体类的属性分别转换成对应关系的属性，其 标识属性为其关键字，由联系类转换得到的关系的属性由两个实体类的标识属性和联系类本身的属性组成，其关键字是由两个联系的实体类的标识属性组成。

（4） 多元联系。实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该 联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。例如图 3-5  所示的部件（PART）、工程（PROJECT）和供应者（SUPPLIER）三者之间的联系为 PJS，其属性为 QTY。转换时，把 PART、PROJECT、 SUPPLIER  和联系 PJS 分别转换为相应的关系，其结果如下：

（5） 自联系。自联系是同一实体集的实体间的联系。例如对于职工实体类内部有领导与被领导的联系，在部件这个实体集的实体之间有组成成分与组成者之间的联系等，均属于实体类的自联系。在这种联系中，参与联系的实体虽然来自同一实体类，但所起的作用不一样。

（6） 弱实体类的转换。一个实体类，如果它的存在依赖于另一实体类，则称之为弱实体类。例如职工的亲属（DEPENDENTS）是依赖于职工（EMPLOYEE）实体类而存在的，因为实体集亲属（DEPENDENTS）是弱实体类，它们之间的关系如图 3-6 所示。由于弱实体类不

能独立地存在，而是由其他实体标识而存在，所以不能单独地转换成一个关系，因此图 3-6

可转换成如下两个关系：

EMPLOYEE（empno，name，birthday） DEPENDENTS（empno，name，sex，age，kinship）

其中 kinship 表示职工亲属与职工的关系，可以取值为“配偶”、“儿子”、“女儿”等。

1. 数据模型的优化

由 E-R 图表示的概念模型转换得到的关系模型经过规范化以后，基本上可以反映一个企业数据的内在联系，但不一定能满足应用的全部需要和系统要求，因此，还必须根据需求分析对模型做进一步的改善和调整，其内容主要是改善数据库的性能和节省存储空间两个方面。

（1） 改善数据库性能的考虑。查询速度是关系数据库应用中影响性能的关键问题，必须在数据库的逻辑设计和物理设计中认真加以考虑，特别是那些对响应时间要求较苛刻的应用，应予以特别注意。

就数据库的逻辑设计而论，可从下列几个方面提高查询的速度。

① 减少连接运算。连接运算对关系数据库的查询速度有着重要的影响，连接的关系越多，参与连接的关系越大，开销也越大，因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询，最好是一元查询，但这与规范化的要求相矛盾。有时为了保证性能，往往不得不牺牲规范化要求，把规范化的关系再合并起来，称之为逆规范化。当然，这样做会引起更新异常。总之，逆规范化有得有失，设计者可根据实际情况进行权衡。

② 减小关系大小及数据量。被查询的关系的大小对查询速度影响较大。为了提高查询速度，可以采用水平分割或垂直分割等方法把一个关系分成几个关系，使每个关系的数据量

减少。例如，对于大学中有关学生的数据，既可以把全校学生的数据集中在一个关系中，也可以用水平分割的方法，分系建立关系，从而减少了每个关系的元组数。前者对全校范围内的查询较方便，后者则可以显著提高对指定系的查询速度。也可采用垂直分割的方法，把常用数据与非常用数据分开，以提高常用数据的查询速度。例如，高校中教职工档案，属性很多，有些需经常查询，有些则很少查询，如果放在一起，则关系的数据量就会很大，影响查询速度，因此把常用属性和非常用属性分开，就可提高对常用属性的查询速度。

③ 尽量使用快照。快照是某个用户所关心的那部分数据，与视图一样是一种导出关系， 但它与视图有两点不同：一是视图是虚关系，数据库中并不存储作为视图的导出关系，仅仅保留它的定义，快照则是一个由系统事先生成后保留在数据库中的实关系；二是视图随数据当前值的变化而变化，快照则不随原来关系中数据的改变而及时改变，它只反映数据库中某一时刻的状态，不反映数据库的当前状态，犹如照片只反映某一时刻的情景，不能反映情景变化一样，之所以称它为快照，原因就在于此。但它与照片又有不同，快照不是一成不变的， 它可以由系统周期性地刷新，或由用户用命令刷新。刷新时用当前值更新旧值。在实际应用中，快照可满足相当一部分应用的需要，甚至有些应用就是需要快照，而不是当前值。例如注明列出“某年某月某日截止”的统计或报表就是快照。由于快照是事先生成并存储在数据库中的，因而可大大缩短响应时间。目前不少 DBMS，如 Oracle、 MS SQL Server 等支持快照。对不支持快照的 DBMS，用户也可以把需要作为实关系使用的导出关系作为一个独立关系存于数据库中，但这种做法只能供查询使用，对它们的刷新及管理由用户负责。

（2） 节省存储空间的一些考虑。尽管随着硬件技术的发展，提供给用户使用的存储空间越来越大，但毕竟是有限度的。而数据库，尤其是复杂应用的大型数据库，需要占用较大的外存空间。因此，节省存储空间仍是数据库设计中应该考虑的问题，不但要在数据库的物理设计中考虑，而且还应在逻辑设计中加以考虑。在数据库逻辑设计中可采取以下措施：

① 缩小每个属性占用的空间。减少每个属性占用的空间，是节省存储空间的一个有效的措施。通常可以有两种方法：即用编码和用缩写符号表示属性，但这两种方法的缺点是失去了属性值含义的直观性。

② 采用假属性。采用假属性可以减少重复数据占用的存储空间。设某关系模型 R 的属性 A 和 B  之间存在函数依赖 A→B，B  的每一个值需要占用较大的空间，但 B  的域中不同的值却比较少，A 的域中具有较多的不同值，则 B 的同一值可能在多个元组中重复出现， 从而需要占用较多的空间。为了节省空间，可利用属性 B 的域中不同值少的特点，对 B  的值进行分类，用 B′表示 B 的类型，则 A→B 可分解成两个函数依赖，即：

A→B′，B′→B

这样，就可用 B′代替原来元组较多的关系 R 中的属性 B，而另外建立一个较小的关系 R′来描述 B′与 B 的对应关系。这里 B′在原关系 R 中起了属性 B 的替身的作用， 所以称 B′ 为假属性。例如，在职工关系中，职工的经济状况这一属性通常由职工号决定， 一个大型企业的职工人数很多，如每一职工逐一填写，就要占用较多的空间，为了节省空间可把经济状况分为几种类型，在元组较多的职工关系中用经济状况的类型代替原来的经济状况，这里经济状况的类型就是假属性，另外建立一个较小的关系来描述每种经济状况类型的具体内容。

希赛教育专家提示：数据库设计与数学问题求解不同，它是一项综合性工作，受到各种各样的要求和因素的制约，有些要求往往又是彼此矛盾的，因此，设计结果很难说是最佳的， 常常有得有失，设计者必须根据实际情况，综合运用上述原则和有关理论，在基本合理的总体设计的基础上，做一些仔细的调整，力求最大限度地满足用户各种各样的要求。

3.3.6 物理结构设计

 

数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。数据库物理设计是利用已确定的逻辑结构及 DBMS 提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配，设计出一个高效的、可实现的物理数据库结构。显然，数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。数据库物理设计过程如图 3-7 所示。

由于不同的 DBMS 提供的硬件环境和存储结构、存取方法，以及提供给数据库设计者的系统参数、变化范围有所不同，因此，为了设计出一个较好的存储模式，设计者必须了解以下几方面的问题，做到心中有数。

（1） 了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对时间和空间进行平衡，并保证优先满足应用的时间要求。

（2） 熟悉使用的 DBMS 的性能，包括 DBMS 的功能，提供的物理环境、存储结构、存取方法和可利用的工具。

（3） 了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及 I/O 特性等。

存储模式和概念模式不一样，它不是面向用户的，一般的用户不一定也不需要了解数据库存储模式的细节。所以数据库存储模式的设计可以不必考虑用户理解的方便，其设计目标主要是提高数据库的性能，其次是节省存储空间。

在进行物理设计时，设计人员可能用到的数据库产品是多种多样的。不同的数据库产品所提供的物理环境、存储结构和存取方法有很大差别，能供设计人员使用的设计变量、参数范围也大不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。

3.4 事务管理

 

数据库系统运行的基本工作单位是事务，事务相当于操作系统中的进程，是用户定义的一个数据库操作序列，这些操作序列要么全做要么全不做，是一个不可分割的工作单位。事务具有以下特性：

（1） 原子性（Atomicity）：数据库的逻辑工作单位。

（2） 一致性（Consistency）：使数据库从一个一致性状态变到另一个一致性状态。

（3） 隔离性（Isolation）：不能被其他事务干扰。

（4） 持续性（永久性）（Durability）：一旦提交，改变就是永久性的。

事务通常以 BEGIN TRANSACTION（事务开始）语句开始，以 COMMIT 或 ROLLBACK 语句结束。COMMIT  称为“事务提交语句”，表示事务执行成功的结束。ROLLBACK  称为“事务回退语句”，表示事务执行不成功的结束。从终端用户来看，事务是一个原子，是不可分割的操作序列。事务中包括的所有操作要么都做，要么都不做（就效果而言）。事务不应该丢失或被分割地完成。

3.4.1 并发控制

 

在多用户共享系统中，许多事务可能同时对同一数据进行操作，称为“并发操作”，此时数据库管理系统的并发控制子系统负责协调并发事务的执行，保证数据库的完整性不受破坏，同时避免用户得到不正确的数据。

数据库的并发操作带来的问题有：丢失更新问题、不一致分析问题（读过时的数据）、依赖于未提交更新的问题（读了“脏”数据）。这三个问题需要 DBMS 的并发控制子系统来解决。处理并发控制的主要方法是采用封锁技术。它有两种类型：排他型封锁（X 封锁）和共

享型封锁（S  封锁），分别介绍如下：

（1）排他型封锁（简称 X 封锁）。如果事务 T 对数据 A（可以是数据项、记录、数据集，乃至整个数据库）实现了 X 封锁，那么只允许事务 T 读取和修改数据 A，其他事务要等事务 T 解除 X 封锁以后，才能对数据 A 实现任何类型的封锁。可见 X 封锁只允许一个事务独锁某个数据，具有排他性。

（2）共享型封锁（简称 S 封锁）。X 封锁只允许一个事务独锁和使用数据，要求太严。需要适当放宽，例如可以允许并发读，但不允许修改，这就产生了 S 封锁概念。S 封锁的含义是：如果事务 T 对数据 A 实现了 S 封锁，那么允许事务 T 读取数据 A，但不能修改数据 A，在所有 S 封锁解除之前绝不允许任何事务对数据 A 实现 X 封锁。

数据库是一个共享资源，它允许多个用户程序并行地存取数据库中的数据，但是，如果系统对并行操作不加以控制，就会存取不正确的数据，破坏数据库的完整性。

在多个事务并发执行的系统中，主要采取封锁协议来进行处理。

（1） 一级封锁协议。事务 T 在修改数据 R 之前必须先对其加 X 锁，直到事务结束才释放。一级封锁协议可防止丢失修改，并保证事务 T 是可恢复的。但不能保证可重复读和不读“脏”数据。

（2） 二级封锁协议。一级封锁协议加上事务 T 在读取数据 R  之前先对其加 S  锁， 读完后即可释放 S 锁。二级封锁协议可防止丢失修改，还可防止读“脏”数据，但不能保证可重复读。

（3） 三级封锁协议。一级封锁协议加上事务 T 在读取数据 R 之前先对其加 S  锁，直到事务结束才释放。三级封锁协议可防止丢失修改、防止读“脏”数据与防止数据重复读。

（4） 两段锁协议。所有事务必须分两个阶段对数据项加锁和解锁。其中扩展阶段是在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；收缩阶段是在释放一

个封锁之后，事务不能再申请和获得任何其他封锁。若并发执行的所有事务均遵守两段封锁协议，则对这些事务的任何并发调度策略都是可串行化的。遵守两段封锁协议的事务可能发生死锁。

下面讨论封锁的粒度。所谓封锁的粒度即是被封锁数据目标的大小。在关系数据库中，封锁粒度有属性值、属性值集、元组、关系、某索引项（或整个索引）、整个关系数据库、物理页（块）等几种。

封锁粒度小则并发性高，但开销大；封锁粒度大则并发性低，但开销小。综合平衡照顾不同需求以合理选取适当的封锁粒度是很重要的。

采用封锁的方法固然可以有效防止数据的不一致性，但封锁本身也会产生一些麻烦，最主要的就是死锁问题。所谓死锁是指多个用户申请不同封锁，由于申请者均拥有一部分封锁权而又需等待另外用户拥有的部分封锁而引起的永无休止的等待。一般来讲，死锁是可以避免的，目前采用的办法有以下几种：

（1） 预防法。此种方法是采用一定的操作方式以保证避免死锁的出现，顺序申请法、一次申请法等即是此类方法。所谓顺序申请法是指对封锁对象按序编号，在用户申请封锁时必须按编号顺序（从小到大或反之）申请，这样能避免死锁发生。所谓一次申请法即是指用户在一个完整操作过程中必须一次性申请它所需要的所有封锁，并在操作结束后一次性归还所有封锁，这样也能避免死锁的发生。

（2） 死锁的解除法。此种方法允许产生死锁，并在死锁产生后通过解锁程序以解除死锁。这种方法需要有两个程序，一是死锁检测程序，用它测定死锁是否发生，另一是解锁程序，一旦经测定系统已产生死锁则启动解锁程序以解除死锁。有关死锁检测及解锁技术请参阅相应的资料，这里不做进一步讨论。

3.4.2 故障与恢复

 

数据库的故障可用事务的故障来表示，主要分为四类：

（1） 事务故障。事务在运行过程中由于种种原因，如输入数据的错误、运算溢出、违反了某些完整性限制、某些应用程序的错误，以及并发事务发生死锁等，使事务未运行至正常终止点就被撤销，这种情况称为“事务故障”。

（2） 系统故障。系统故障是指系统在运行过程中，由于某种原因（如操作系统或数据库管理系统代码错误、操作员操作失误、特定类型的硬件错误（如 CPU 故障）、突然停电

等造成系统停止运行），致使事务在执行过程中以非正常方式终止，这时内存中的信息丢失， 但存储在外存储设备上的数据不会受影响。

（3） 介质故障。系统在运行过程中，由于某种硬件故障，如磁盘损坏、磁头碰撞或由于操作系统的某种潜在的错误、瞬时强磁场干扰，使存储在外存上的数据部分损失或全部损失，称为“介质故障”。这类故障比前两类故障的可能性虽然小得多，但破坏性却最大。

（4） 计算机病毒。计算机病毒是一种人为破坏计算机正常工作的特殊程序。通过读写染有病毒的计算机系统中的程序与数据，这些病毒可以迅速繁殖和传播，危害计算机系统和数据库。目前大多数病毒是在 PC 和其兼容机上传播的。有的病毒一侵入系统就马上摧毁系统，有的病毒有较长的潜伏期，有的病毒则只在特定的日期发生破坏作用，有的病毒感染系统所有的程序和数据，有的只影响特定的程序和数据。

在数据库系统中，恢复的基本含义就是恢复数据库本身。也就是说，在发生某种故障使数据库当前的状态已经不再正确时，把数据库恢复到已知为正确的某一状态。目前数据库系统中最常用的恢复方法是转储和登记日志文件，可根据故障的不同类型，采用不同的恢复策略。

2．故障的恢复

（1） 事务故障的恢复。事务故障是指事务未运行至正常终止点前被撤销，这时恢复子系统应对此事务做撤销处理。事务故障的恢复是由系统自动完成的，不需要用户干预，步骤如下：

反向扫描文件日志，查找该事务的更新操作。

对该事务的更新操作执行逆操作。

继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。

如此处理下去，直至读到此事务的开始标记，事务故障恢复完成。

（2） 系统故障的恢复。系统故障发生时，造成数据库不一致状态的原因有两个：一是由于一些未完成事务对数据库的更新已写入数据库；二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。系统故障的恢复是在重新启动时自动完成的，不需要用户干预，步骤如下：

正向扫描日志文件，找出在故障发生前已经提交的事务，将其事务标识记入重做（Redo） 队列。同时找出故障发生时尚未完成的事务，将其事务标识记入撤销（Undo）队列。

对撤销队列中的各个事务进行撤销处理：反向扫描日志文件，对每个 Undo 事务的更新操作执行逆操作。

对重做队列中的各个事务进行重做处理：正向扫描日志文件，对每个 Redo 事务重新执行日志文件登记的操作。

（3） 介质故障与病毒破坏的恢复。在发生介质故障和遭病毒破坏时，磁盘上的物理数据库被破坏，这时的恢复操作可分为三步：

装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。

从故障点开始反向读日志文件，找出已提交事务标识将其记入重做队列。

从起始点开始正向阅读日志文件，根据重做队列中的记录，重做所有已完成事务，将数据库恢复至故障前某一时刻的一致状态。

（4） 具有检查点的恢复技术。检查点记录的内容可包括：

建立检查点时刻所有正在执行的事务清单。

这些事务最近一个日志记录的地址。采用检查点的恢复步骤如下：

从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。

由该检查点记录得到检查点建立时所有正在执行的事务清单队列（A）。

建立重做队列（R）和撤销队列（U），把 A  队列放入 U  队列中，R  队列为空。

从检查点开始正向扫描日志文件，若有新开始的事务 T1，则把 T1 放入 U 队列，若有提交的事务 T2，则把 T2 从 U 队列移到 R 队列，直至日志文件结束。

U 队列的每个事务执行 Undo 操作，对 R 队列的每个事务执行 Redo 操作。

DBA 要做的基本操作是：

重装最近转储的后援副本。

运行日志文件，执行系统提供的恢复命令。

数据库安全和恢复是数据库系统正常运行的保证。大型数据库管理系统一般都提供了实现安全机制的保证，即由系统提供了相应的功能，但小型的数据库管理系统并非都具有相应功能，因此有时需要人工的辅助措施，用以保证数据库的安全和恢复。

3.5 备份与恢复

 

数据库中的数据一般都十分重要，不能丢失，因为各种原因，数据库都有损坏的可能性

（虽然很小），所以事先制定一个合适的、可操作的备份和恢复计划至关重要。备份和恢复计划的制订要遵循以下两个原则：

（1） 保证数据丢失的情况尽量少或完全不丢失，因为性价比的要求，这要取决于现实系统的具体要求。

（2） 备份和恢复时间尽量短，保证系统最大的可用性。数据库备份按照不同方式可分为多种，这里按照备份内容分为物理备份和逻辑备份两类。

物理备份是在操作系统层面上对数据库的数据文件进行备份，物理备份分为冷备份和热备份两种。冷备份是将数据库正常关闭，在停止状态下利用操作系统的 copy、cp、tar、 cpio 等命令将数据库的文件全部备份下来，当数据库发生故障时，将数据文件复制回来，进行恢复。热备份也分为两种，一种是不关闭数据库，将数据库中需要备份的数据文件依次置于备份状态，相对保持静止，然后再利用操作系统的 copy、cp、tar、cpio 等命令将数据库的文件备份下来，备份完毕后再将数据文件恢复为正常状态，当数据库发生故障时，恢复方法同冷备份一样。热备份的另外一种方式是利用备份软件（例如，veritas  公司的 netbackup，legato公司的 network 等）在数据库正常运行的状态下，将数据库中的数据文件备份出来。

为了提高物理备份的效率，通常将完全、增量、累积三种备份方式相组合。完全备份是将数据库的内容全部备份，作为增量、累积的基础；增量备份是只备份上次完全、增量或累积备份以来修改的数据；累积备份是备份自上次完全或累积备份以来修改过的数据。一个备份周期通常由一个完全备份和多个增量、累积备份组成。由于增量或累计备份导出的数据少， 所以其导出的文件较小，所需要的时间较少。利用一个完全备份和多个增量、累积备份恢复数据库的步骤如下：

（1） 首先从完全备份恢复数据库。

（2） 然后按照时间顺序从早到晚依次导入多个增量和累积备份文件。

逻辑备份是指利用各数据库系统自带的工具软件备份和恢复数据库的内容，例如， Oracle 的导出工具为 exp，导入工具为 imp，可以按照表、表空间、用户、全库等四个层次备份和恢复数据；Sybase 的全库备份命令是 dump database，全库恢复命令是 load database，另外也可利用 BCP 命令来备份和恢复指定表。

在数据库容量不大的情况下逻辑备份是一个非常有效的手段，既简单又方便，但现在随着数据量的越来越大，利用逻辑备份来备份和恢复数据库已力不从心，速度也很慢。针对大型数据库的备份和恢复一般结合磁带库采用物理的完全、增量、累积三种备份方式相组合来进行。但无论任何时候逻辑备份都是一种非常有效的手段，特别适合于日常维护中的部分指定表的备份和恢复。

3.6 分布式数据库系统

 

近年来，随着计算机技术与网络技术的发展，特别是 Internet 的兴起，分布式数据库系统得到了很快的发展和应用。

3.6.1 分布式数据库的概念

 

分布式数据库系统是相对于集中式数据库系统而言的，是将数据库技术与网络技术相结合的产物。分布式数据库（Distributed DataBase，DDB）比较确切的定义是：分布式数据库是由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个结点具有独立处理的能力，成为场地自治，它可以执行局部应用，同时，每个结点也能通过网络通信子系统执行全局应用。负责分布式数据库的建立、查询、更新、复制、管理和维护的软件， 称为分布式数据库管理系统（Distributed DataBase Management System， DDBMS）。分布式数据库管理系统保证分布式数据库中数据的物理分布对用户的透明性。一个计算机网络组成的计算机系统，在配置了分布式数据库管理系统，并在其上建立了分布式数据库和相应的应用程序后，就称其为分布式数据库系统（Distributed DataBase  System，DDBS）。分布式数据库管理系统是分布式数据库系统的核心。

1. 分布式数据库的特点从上面的定义可以看出分布式数据库系统有以下几个特点：

（1） 数据的分布性。分布式数据库中的数据分布于网络中的各个结点，它既不同于传统的集中式数据库，也不同于通过计算机网络共享的集中式数据库系统。

（2） 统一性。主要表现在数据在逻辑上的统一性和数据在管理上的统一性两个方面。分布式数据库系统通过网络技术把局部的、分散的数据库构成一个在逻辑上单一的数据库， 从而呈现在用户面前的就如同是一个统一的、集中式的数据库。这就是数据在逻辑上的统一性，因此，它不同于由网络互联的多个独立数据库。分布式数据库是由分布式数据库管理系统统一管理和维护的，这种管理上的统一性又使它不同于一般的分布式文件系统。

（3） 透明性。用户在使用分布式数据库时，与使用集中式数据库一样，无须知道其所关心的数据存放在哪里，存储了几次。用户需要关心的仅仅是整个数据库的逻辑结构。

与集中式数据库相比，分布式数据库具有下列优点：

（1） 坚固性好。由于分布式数据库系统是由多个位置上的多台计算机构成的，在个别结点或个别通信链路发生故障的情况下，它仍然可以降低级别继续工作，如果采用冗余技术， 还可以获得一定的容错能力。因此，系统的坚固性好，即系统的可靠性和可用性好。

（2） 可扩充性好。可根据发展的需要增减结点，或对系统重新配置，这比用一个更大的系统代替一个已有的集中式数据库要容易得多。

（3） 可改善性能。在分布式数据库中可按就近分布，合理地冗余的原则来分布各结点上的数据，构造分布式数据库，使大部分数据可以就近访问，避免了集中式数据库中的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且也降低了通信费用。

（4） 自治性好。数据可以分散管理，统一协调，即系统中各结点的数据操纵和相互作用是高度自治的，不存在主从控制，因此，分布式数据库较好地满足了一个单位中各部门希望拥有自己的数据，管理自己的数据，同时又想共享其他部门有关数据的要求。

虽然分布式数据库系统与集中式数据库相比有不少优点，但同时也需要解决一些集中式数据库所没有的问题。首先，异构数据库的集成问题是一项比较复杂的技术问题，目前还很难用一个通用的分布式数据库管理系统来解决这一问题。其次，如果数据库设计得不好，数据分布不合理，以致远距离访问过多，尤其是分布连接操作过多，不但不能改善性能，反而会使性能降低。

1. 分布式数据库的分类

分布式数据库及其分布式数据库管理系统，根据许多因素有不同的分类方法，总的原则是分布式数据库及 DDBMS 必须是其数据和软件必定分布在用计算机网络连接的多个场地上。从应用需要或本身的特征方面考虑可将它从以下几个方面来划分：

（1） 按 DDBMS  软件同构度来分。当所有服务器软件（或每个 LDBMS）和所有客户软件均用相同的软件时称为同构型分布式数据库；反之，则称为异构型分布式数据库。

（2） 按局部自治度来分。当对 DDBMS 的存取必须通过客户软件，则系统称为无局部自治；当局部事务允许对服务器软件进行直接存取，则系统称为有一定的局部自治。自治的两个分别是无局部自治和联邦型 DDBMS  或称多数据库系统。多数据库系统本质上是集中式与分布式的混合体：对一个局部用户而言，它是自治的，那么是一个集中式 DBS；对一个全局用户而言，则是一个分布式 DBS，但这个 DDBS 没有全局概念模式，只有一个由各局部数据库提供给全局允许共享的有关模式的集成。

（3） 按分布透明度来分。分布透明度的另一个概念是模式集成度。若用户可以对集成模式操作不需要涉及任何片段、重复、分布等信息时，则这类 DDBMS 称为有高度分布透明（或高度模式集成）；若用户必须知道所有关于片段、分配、重复等信息时，则这类 DDBMS 没有分布透明，没有模式集成度。当系统不提供分布透明，用户查询时必须指定特定的场地、特定的片段等信息，当然 DDBMS 可以部分分布透明（介于两者之间）。

1. 分布式数据库的目标

理想的分布式系统使用时应该精确得像一个非分布式系统。概括起来有以下 12 条具体规则和目标：

（1） 局部结点自治性。网络中的每个结点是独立的数据库系统，它有自己的数据库， 运行它的局部 DBMS，执行局部应用，具有高度的自治性。

（2） 不依赖中心结点。即每个结点具有全局字典管理、查询处理、并发控制和恢复控制等功能。

（3） 能连续操作。该目标使中断分布式数据库服务情况减至最少，当一个新场地合并到现有的分布式系统或从分布式系统中撤离一个 场地不会导致任何不必要的服务中断；在分布式系统中可动态地建立和消除片段，而不中止任何组成部分的场地或数据库；应尽可能在不使整个系统停机的情况下对组成分布式系统的场地的 DBMS 进行升级。

（4） 具有位置独立性（或称位置透明性）。用户不必知道数据的物理存储地，可工作 可像数据全部存储在局部场地一样。一般位置独立性需要有分布式数据命名模式和字典子系统的支持。

（5） 分片独立性（或称分片透明性）。分布式系统如果可将给定的关系分成若干块或片，可提高系统的处理性能。利用分片将数据存储在最频繁使用它的位置上，使大部分操作为局部操作，减少网络的信息流量。如果系统支持分片独立性，那么用户工作起来就像数据全然不是分片的一样。

（6） 数据复制独立性。是指将给定的关系（或片段）可在物理级用许多不同存储副本或复制品在许多不同场地上存储。支持数据复制的系统应当支持复制独立性，用户工作可像它全然没有存储副本一样地工作。

（7） 支持分布式查询处理。在分布式数据库系统中有三类查询：局部查询、远程查询和全局查询。局部查询和远程查询仅涉及单个结点的数据（本地的或远程的），查询优化采用的技术是集中式数据库的查询优化技术。全局查询涉及多个结点上的数据，其查询处理和优化要复杂得多。

（8） 支持分布事务管理。事务管理有两个主要方面：恢复控制和并发控制。在分布式系统中，单个事务会涉及多个场地上的代码执行，会涉及多个场地上的更新，可以说每个事务是由多个“代理”组成的，每个代理代表在给定场地上的给定事务上执行的过程。在分布式系统中必须保证事务的代理集或者全部一致交付，或者全部一致回滚。

（9） 具有硬件独立性。希望在不同硬件系统上运行同样的 DBMS。

（10） 具有操作系统独立性。希望在不同的操作系统上运行 DBMS。

（11） 具有网络独立性。如果系统能够支持多个不同的场地，每个场地有不同的硬件 和不同的操作系统，则要求该系统能支持各种不同的通信网络。

（12） 具有 DBMS 独立性。实现对异构型分布式系统的支持。理想的分布式系统应该提供 DBMS 独立性。

上述的全功能分布式数据库系统的准则和目标起源于：一个分布式数据库系统，对用户来说，应当看上去完全像一个非分布式系统。值得指出的是，现实系统出于对某些方面的特别考虑，对上述各方面做出了种种权衡和选择。

3.6.2 分布式数据库的架构

 

分布式数据库系统的模式结构有六个层次，如图 3-8 所示，实际的系统并非都具有这种结构。在这种结构中各级模式的层次清晰，可以概括和说明任何分布式数据库系统的概念和结构。

图 3-8 的模式结构从整体上可以分为两大部分：下半部分是集中式数据库的模式结构， 代表了各局部场地上局部数据库系统的基本结构；上半部分是分布式数据库系统增加的模式级别。

（1） 全局外模式。它们是全局应用的用户视图，是全局概念模式的子集。

（2） 全局概念模式。它定义分布式数据库中数据的整体逻辑结构，数据就如同根本没有分布一样，可用传统的集中式数据库中所采用的方法定义。全局概念模式中所用的数据模型应该易于向其他层次的模式映像，通常采用关系模型。这样，全局概念模式包括一组全局关系的定义。

（3） 分片模式。每一个全局关系可以划分为若干不相交的部分，每一部分称为一个片段，即“数据分片”。分片模式就是定义片段及全局关系到片段的映像。这种映像是一对多的，即每个片段来自一个全局关系，而一个全局关系可对应多个片段。

（4） 分布模式。由数据分片得到的片断仍然是 DDB 的全局数据，是全局关系的逻辑部分，每一个片段在物理上可以分配到网络的一个或多个不同结点上。分布模式定义片段的存放结点。分布模式的映像类型确定了分布式数据库是冗余的还是非冗余的。若映像是一对多的，即一个片段分配到多个结点上存放，则是冗余的分布数据库，否则是不冗余的分布数据库。

根据分布模式提供的信息，一个全局查询可分解为若干子查询，每一子查询要访问的数据属于同一场地的局部数据库。由分布模式到各局部数据库的映像（映像 4）把存储在局部场地的全局关系或全局关系的片段映像为各局部概念模式采用局部场地的 DBMS 所支持的数据模型。

分片模式和分布模式均是全局的，分布式数据库系统中增加的这些模式和相应的映像使分布式数据库系统具有了分布透明性。

（5） 局部概念模式。一个全局关系经逻辑划分成一个或多个逻辑片断，每个逻辑片断被分配在一个或多个场地上，称为该逻辑片断在某场地上的物理映像或物理片断。分配在同一场地上的同一个全局概念模式的若干片断（物理片断）构成了该全局概念在该场地上的一个物理映像。

一个场地上的局部概念模式是该场地上所有全局概念模式在该场地上物理映像的集合。由此可见，全局概念模式与场地独立，而局部概念模式与场地相关。

（6） 局部内模式。局部内模式是 DDB  中关于物理数据库的描述，类似于集中式 DB 中的内模式，但其描述的内容不仅包含局部本场地的数据的存储描述，还包括全局数据在本场地的存储描述。

在图 3-8 的六层模式结构中，全局概念模式、分片模式和分布模式是与场地特征无关的，是全局的，因此它们不依赖于局部 DBMS 的数据模型。在低层次上，需要把物理映像映射成由局部 DBMS 支持的数据模型。这种映像由局部映射模式完成。具体的映射关系，

由局部 DBMS 的类型决定。在异构型系统中，可在不同场地上拥有类型的局部映射模式。这种分层的模式结构为理解 DDB 提供了一种通用的概念结构。它有三个显著的特征：

（1） 数据分片和数据分配概念的分离，形成了“数据分布独立型”概念。

（2） 数据冗余的显示控制。数据在各个场地的分配情况在分配模式中一目了然，便于系统管理。

（3） 局部 DBMS 的独立性。这个特征也称为“局部映射透明性”。此特征允许在不考虑局部 DBMS 专用数据模型的情况下研究 DDB 管理的有关问题。

1. 分布式数据库系统与并行数据库系统的区别

分布式数据库系统与并行数据库系统具有很多相似点：它们都是通过网络连接各个数据 处理结点的，整个网络中的所有结点构成一个逻辑上统一的整体，用户可以对各个结点上的 数据进行透明存取等。但分布式数据库系统与并行数据库系统之间还是存在着显著的区别的， 主要表现在以下几个方面：

（1） 应用目标不同。并行数据库系统的目标是充分发挥并行计算机的优势，利用系统中的各个处理机结点并行地完成数据库任务，提高数据库的整体性能。分布式数据库系统主要目的在于实现各个场地自治和数据的全局透明共享，而不要求利用网络中的各个结点来提高系统的整体性能。

（2） 实现方式不同。由于应用目标各不相同，在具体实现方法上，并行数据库与分布式数据库之间也有着较大的区别。在并行数据库中，为了充分发挥各个结点的处理能力，各结点间采用高速通信网络互联，结点间数据传输代价相对较低。当负载不均衡时，可以将工作负载过大的结点上的任务通过高速通信网络送给空闲结点处理，从而实现负载平衡。在分布式数据库系统中，各结点（场地）间一般通过局域网或广域网互联，网络带宽比较低，各场地之间的通信开销较大，因此在查询处理时一般应尽量减少结点间的数据传输量。

（3） 各结点的地位不同。在并行数据库中，各结点之间不存在全局应用和局部应用的概念。各个结点协同作用，共同处理，而不可能有局部应用。

在分布式数据库系统中，各结点除了能通过网络协同完成全局事务外，还有自己结点场地的自治性。也就是说，分布式数据库系统的每个场地又是一个独立的数据库系统，除了拥有自己的硬件系统（CPU、内存和磁盘等）外，还拥有自己的数据库和自己的客户，可运行自己的 DBMS，执行局部应用，具有高度的自治性。这是并行数据库与分布式数据库之间最主要的区别。

1. 数据分片和透明性

将数据分片，使数据存放的单位不是关系而是片段，这既有利于按照用户的需求较好地组织数据的分布，也有利于控制数据的冗余度。分片的方式有多种，水平分片和垂直分片是两种基本的分片方式，混合分片和导出分片是较复杂的分片方式。

分布透明性指用户不必关心数据的逻辑分片，不必关心数据存储的物理位置分配细节， 也不必关心局部场地上数据库的数据模型。从图 3-8 的模式结构可以看到分布透明性包括： 分片透明性、位置透明性和局部数据模型透明性。

（1） 分片透明性是分布透明性的最高层次。所谓分片透明性是指用户或应用程序只对全局关系进行操作而不必考虑数据的分片。当分片模式改变时，只要改变全局模式到分片模式的映像（映像 2），而不影响全局模式和应用程序。全局模式不变，应用程序不必改写，这就是分片透明性。

（2） 位置透明性是分布透明性的下一层次。所谓位置透明性是指，用户或应用程序应当了解分片情况，但不必了解片段的存储场地。当存储场地改变时，只要改变分片模式到分配模式的映像（映像 3），而不影响应用程序。同时，若片段的重复副本数目改变了，那么数据的冗余也会改变，但用户不必关心如何保持各副本的一致性，这也提供了重复副本的透明性。

（3） 局部数据模型透明性是指用户或应用程序应当了解分片及各片断存储的场地，但不必了解局部场地上使用的是何种数据模型。模型的转换及语言等的转换均由映像 4 来完成。

1. 分布式数据库管理系统分布式数据库管理系统的任务，首先就是把用户与分布式数据库隔离开来，使其对用户而言，整个分布式数据库就好像是一个传统的集中式数据库。换句话说，一个分布式数据库管理系统与用户之间的接口，在逻辑上与集中式数据库管理系统是一致的。但是考虑到分布式数据库的特点，其物理实现上又与集中式数据库不同。下面以一种分布式数据库管理。

以系统 DDBMS 的结构为例来分析它的主要成分和功能，如图 3-9 所示。

由图 3-9 可以看出，DDBMS 由 4 部分组成：

（1） LDBMS（局部 DBMS）。局部场地上的数据库管理系统的功能是建立和管理局部数据库，提供场地自治能力、执行局部应用及全局查询的子查询。

（2） GDBMS（全局 DBMS）。全局数据库管理系统的主要功能是提供分布透明性，协调全局事务的执行，协调各局部 DBMS 以完成全局应用，保证数据库的全局一致性，执行并发控制，实现更新同步，提供全局恢复功能。

（3） 全局数据字典。存放全局概念模式、分片模式、分布模式的定义及各模式之间映像的定义；存放有关用户存取权限的定义，以保证全局用户的合法权限和数据库的安全性； 存放数据完整性约束条件的定义，其功能与集中式数据库的数据字典类似。

（4） CM（Communication Management，通信管理）。在分布数据库各场地之间传送消息和数据，完成通信功能。

DDBMS 功能的分割和重复及不同的配置策略就导致了各种架构。

（1） 全局控制集中的 DDBMS。这种结构的特点是全局控制成分 GDBMS 集中在某一结点上，由该结点完成全局事务的协调和局部数据库转换等一切控制功能，全局数据字典只有一个，也存放在该结点上，它是 GDBMS 执行控制的依据。它的优点是控制简单，易实现更新一致性。但由于控制集中在某一特定的结点上，不仅容易形成瓶颈而且系统较脆弱， 一旦该结点出故障，整个系统就会瘫痪。

（2） 全局控制分散的 DDBMS。这种结构的特点是全局控制成分 GDBMS 分散在网络的每一个结点上，全局数据字典也在每个结点上有一份，每个结点都能完成全局事务的协调和局部数据库转换，每个结点既是全局事务的参与者又是协调者，一般称这类结构为完全分布的 DDBMS。它的优点是结点独立，自治性强，单个结点退出或进入系统均不会影响整个系统的运行，但是全局控制的协调机制和一致性的维护都比较复杂。

（3） 全局控制部分分散的 DDBMS。这种结构是根据应用的需要将 GDBMS 和全局数据字典分散在某些结点上，是介于前两种情况之间的架构。

局部 DBMS 的一个重要性质是：局部 DBMS 是同构的还是异构的。同构和异构的级别可以有三级：硬件、操作系统和局部 DBMS。其中最主要的是局部 DBMS 这一级，因为硬件和操作系统的不同将由通信软件处理和管理。

异构型 DDBMS 的设计和实现比同构型 DDBMS 更加复杂，它要解决不同的 DBMS 之间及不同的数据模型之间的转换。因此在设计和实现 DDBMS 时，若是用自顶向下的方法进行，即并不存在已运行的局部数据库，则采用同构型的结构比较方便。若是采用自底向上设计 DDBMS 的方法，即现已存在的局部数据库，而这些数据库可能采用不同的数据模型

（层次、网状或关系），或者虽然模型相同但它们是不同厂商的 DBMS（如 Informix、Sybase、 Db2、Oracle），这就必须开发异构型的 DDBMS。要解决异构数据库模型的同种化问题，是研制异构型 DDBMS 的关键所在，所谓同种化就是寻找合适的公共数据模型，采用公共数据模型与异构数据模型（局部）之间的转换，不采用各结点之间的一对一转换。这样可以减少转移次数。设有 N 个结点，用公共数据模型时转换次数为 2N，而各结点之间一对一转换则需 N（N1）次。

3.7 数据仓库

 

传统的操作型数据库主要是面向业务的，所执行的操作基本上也是联机事务处理， 但随着企业规模的增长，历史积累的数据越来越多，如何利用历史数据来为未来决策服务， 就显得越来越重要了，而数据仓库就是其中的一种技术。

3.7.1 数据仓库的概念

 

著名的数据仓库专家 W.H.Inmon 在《Building the Data Warehouse》一书中将数据仓库定义为：数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、且随时间

变化的数据集合，用于支持管理决策。

1. 面向主题的操作型数据库的数据组织面向事务处理任务（面向应用），各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。例如，一个保险公司所进行的事务处理（应用问题）可能包括汽车保险、人寿保险、健康保险和意外保险等，而公司的主要主题范围可能是顾客、保险单、保险费和索赔等。 2．集成的在数据仓库的所有特性中，这是最重要的。面向事务处理的操作型数据库通

常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

1. 相对稳定的操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作， 但修改和删除操作很少，通常只需要定期地加载、刷新。
2. 随时间变化的操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。数据仓库反映历史变化的属性主要表现在：

（1） 数据仓库中的数据时间期限要远远长于传统操作型数据系统中的数据时间期限， 传统操作型数据系统中的数据时间期限可能为数十天或数个月，数据仓库中的数据时间期限往往为数年甚至几十年；

（2） 传统操作型数据系统中的数据含有“当前值”的数据，这些数据在访问时是有效的，当然数据的当前值也能被更新，但数据仓库中的数据仅仅是一系列某一时刻（可能是传统操作型数据系统）生成的复杂的快照；

（3） 传统操作型数据系统中可能包含也可能不包含时间元素，如年、月、日、时、分 、秒等，而数据仓库中一定会包含时间元素。

数据仓库虽然是从传统数据库系统发展而来，但是两者还是存在着诸多差异，如：从数据存储的内容看，数据库只存放当前值，而数据仓库则存放历史值；数据库数据的目标是面向业务操作人员的，为业务处理人员提供数据处理的支持，而数据仓库则是面向中高层管理人员的，为其提供决策支持等。表 3-10 详细说明了数据仓库与传统数据库的区别。

3.7.2 数据仓库的结构

 

从数据仓库的概念结构看，一般来说，数据仓库系统要包含数据源、数据准备区、数据仓库数据库、数据集市/知识挖掘库及各种管理工具和应用工具，如图 3-10 所示。数据仓库建立之后，首先要从数据源中抽取相关的数据到数据准备区，在数据准备区中经过净化处理后再加载到数据仓库数据库，最后根据用户的需求将数据导入数据集市和知识挖掘库中。当用户使用数据仓库时，可以利用包括 OLAP（On-Line Analysis Processing，联机分析处理） 在内的多种数据仓库应用工具向数据集市/知识挖掘库或数据仓库进行决策查询分析或知识挖掘。数据仓库的创建、应用可以利用各种数据仓库管理工具辅助完成。

1. 数据仓库的参考框架

数据仓库的参考框架由数据仓库基本功能层、数据仓库管理层和数据仓库环境支持层组成，如图 3-11 所示。

（1） 数据仓库基本功能层。数据仓库的基本功能层部分包含数据源、数据准备区、数据仓库结构、数据集市或知识挖掘库，以及存取和使用部分。本层的功能是从数据源抽取数据，对所抽取的数据进行筛选、清理，将处理过的数据导入或者说加载到数据仓库中，根据用户的需求设立数据集市，完成数据仓库的复杂查询、决策分析和知识的挖掘等。

（2） 数据仓库管理层。数据仓库的正常运行除了需要数据仓库功能层提供的基本功能外，还需要对这些基本功能进行管理与支持的结构框架。数据仓库管理层由数据仓库的数据管理和数据仓库的元数据管理组成。

数据仓库的数据管理层包含数据抽取、新数据需求与查询管理，数据加载、存储、刷新和更新系统，安全性与用户授权管理系统及数据归档、恢复及净化系统等四部分。

（3） 数据仓库的环境支持层。数据仓库的环境支持层由数据仓库数据传输层和数据仓库基础层组成。数据仓库中不同结构之间的数据传输需要数据仓库的传输层来完成。

数据仓库的传输层包含数据传输和传送网络、客户/服务器代理和中间件、复制系统及数据传输层的安全保障系统。

1. 数据仓库的架构大众观点的数据仓库的架构如图 3-12 所示。

（1） 数据源。是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于 RDBMS（关系型 DBMS）中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等。

（2） 数据的存储与管理。是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。

（3） OLAP 服务器。对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP、MOLAP 和 HOLAP。ROLAP 基本数据和聚合数据均存放在 RDBMS 之中；MOLAP 基本数据和聚合数据均存放于多维数据库中；HOLAP 基本数据存放于 RDBMS 之中，聚合数据存放于多维数据库中。

（4） 前端工具。主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对 OLAP 服务器， 报表工具、数据挖掘工具主要针对数据仓库。

3.7.3 数据仓库的实现方法

 

数据仓库的特性决定了数据仓库的设计不同于传统的数据库设计方法。数据仓库系统的原始需求通常不是很明确，并且需求仍在不断变化、增加，所以，数据仓库的建立是一个过程，从建立简单的基本框架着手，不断丰富和完善整个系统。这一过程将由以下几部分构成： 需求分析、概念模型设计、逻辑模型设计、物理模型设计和数据仓库生成。

从整体的角度来看，数据仓库的实现方法主要有自顶向下法、自底向上法和联合方法。

1. 自顶向下法

在该方法中，首先应找出数据仓库解决方案所要满足的商业需求，把商业需求视为实现数据仓库的首要任务。数据仓库是一种功能而不是一种特征，数据仓库保存信息，并以外部工具易于显示和操作的方式组织这些信息。因此，如果不借助于可以利用这种功能的外部工具，最终用户就无法将这种功能嵌入数据仓库中。这样，就很难定出该功能的范围，除非用广义上的商业术语，如“数据仓库将包含有关客户、供应商、市场、产品的信息”。自顶向

下方法的优点和缺点如表 3-11 所示。

规划和实现数据仓库的自顶向下方法一般用于以下情况：

（1） 实现单位比较熟悉技术，并具有根据商业需求采用自顶向下方法开发应用程序的丰富经验。

（2） 决策层（总经理、决策者、投资者）完全清楚数据仓库的预测目标。

（3） 决策层（总经理、决策者、投资者）完全清楚数据仓库用作哪些机构的决策支持工具。

（4） 决策层（总经理、决策者、投资者）完全清楚数据仓库已经是商业过程中的一个子过程。

如果技术是成熟的和众所周知的，或者必须解决的商业问题是显而易见的，那么自顶向下方法是很有用的。采用自顶向下方法可以将技术和商业目标有机地结合起来。

1. 自底向上法

自底向上方法一般从实验和基于技术的原形入手。先选择一个特定的、众所周知的商业问题的子集，再为该子集制订方案。实现自底向上一般是比较快的。自底向上可以使一个单位在发展时用尽可能少的经费和时间，就可以在做出有效的投入之前评估技术的收益情况。在数据仓库领域，自底向上方法是快速实现数据集市、部门级数据仓库的有效手段。自底向上方法的优点和缺点如表 3-12 所示。

规划和实现数据仓库的自底向上方法一般用于以下情况：

（1） 企业还没有确实掌握数据仓库技术，希望进行技术评估来决定运行该技术的方式、地点和时间。

（2） 企业希望了解实现和运行数据仓库所需要的各种费用情况。

（3） 企业在对数据仓库进行投资选择。自底向上方法对于希望从数据仓库投资中快速得到回报的用户是非常有效的。该方法

可以使企业充分利用各种技术，无须冒很大风险。

1. 联合方法

在以上两种方法的联合方法中，企业在保持自底向上方法的快速实现和机遇应用的同时， 还可以利用自顶向下方法的规划和决策性质。这种方法依赖于以下两个因素：

（1） 自顶向下的结构、标准和设计小组，可以从一个项目向另外一个项目传递知识， 也可以把战术决策变为战略决策。

（2） 自底向上方法的项目小组，它直接负责在短期内实现一个集中的、部门级的商务解决方案。

联合方法具有以上两种方法的优点，但是难以作为一个项目来管理。该方法一般用于：

（1） 实现企业拥有经验丰富的设计师，有能力建立、证明、应用和维护数据结构、技术结构及企业模型，可以很容易地从具体（运作系统中的元数据）转移到抽象。

（2） 企业拥有固定的项目小组，完全清楚数据仓库技术应用的场所。他们可以清楚地看到当前的商务需求。

联合方法适合数据仓库技术的快速试运行，并且保留了建立长远的决策方案的机会。

3.8 数据挖掘

 

随着数据库技术的迅速发展及数据库管理系统的广泛应用，人们积累的数据越来越多。激增的数据背后隐藏着许多重要的信息，人们希望能够对其进行更高层次的分析，以便更好地利用这些数据。目前的数据库系统可以高效地实现数据的录入、查询、统计等功能，但无法发现数据中存在的关系和规则，无法根据现有的数据预测未来的发展趋势。缺乏挖掘数据背后隐藏的知识的手段，导致了“数据爆炸但知识贫乏”的现象。

3.8.1 数据挖掘的概念

 

数据挖掘（Data Mining）技术是人们长期对数据库技术进行研究和开发的结果。起初各种商业数据是存储在计算机的数据库中的，然后发展到可对数据库进行查询和访问，进而发展到对数据库的即时遍历。数据挖掘使数据库技术进入了一个更高级的阶段，它不仅能对过

去的数据进行查询和遍历，并且能够找出过去数据之间的潜在联系，从而促进信息的传递。现在数据挖掘技术在商业应用中已经可以马上投入使用，因为对这种技术进行支持的三种基础技术已经发展成熟，它们是海量数据搜集、强大的多处理器计算机和数据挖掘算法。

从技术角度来看，数据挖掘就是从大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。这个定义包括好几层含义：数据源必须是真实的、大量的、含噪声的；发现的是用户感兴趣的知识；发现的知识要可接受、可理解、可运用；并不要求发现放之四海而皆准的知识，仅支持特定的发现问题。

还有很多和这一术语相近的术语，如从数据库中发现知识、数据分析、数据融合（Data Fusion），以及决策支持等。

何为知识？从广义上理解，数据、信息也是知识的表现形式，但是人们更把概念、规则、模式、规律和约束等看做知识。原始数据可以是结构化的，如关系数据库中的数据；也可以是半结构化的，如文本、图形和图像数据；甚至是分布在网络上的异构型数据。发

现知识的方法可以是数学的，也可以是非数学的；可以是演绎的，也可以是归纳的。发现的知识可以被用于信息管理，查询优化，决策支持和过程控制等，还可以用于数据自身的维护。因此，数据挖掘是一门交叉学科，它把人们对数据的应用从低层次的简单查询，提升到从数据中挖掘知识，提供决策支持。在这种需求牵引下，汇聚了不同领域的研究者，尤其是数据库技术、人工智能技术、数理统计、可视化技术、并行计算等方面的学者和工程技术人员， 投身到数据挖掘这一新兴的研究领域，形成新的技术热点。

从商业角度来看，数据挖掘是一种新的商业信息处理技术，其主要特点是对商业数据库中的大量业务数据进行抽取、转换、分析和其他模型化处理，从中提取辅助商业决策的关键性数据。

简而言之，数据挖掘其实是一种深层次的数据分析方法。数据分析本身已经有很多年的历史，只不过在过去数据收集和分析的目的是用于科学研究，另外，由于当时计算能力的限制，对大量数据进行分析的复杂数据分析方法受到很大限制。现在，由于各行业业务自动化的实现，商业领域产生了大量的业务数据，这些数据不再是为了分析的目的而收集，而是由于纯机会的商业运作而产生。分析这些数据也不再是单纯为了研究的需要，更主要是为商业决策提供真正有价值的信息，进而获得利润。但所有企业面临的一个共同问题是：企业数据量非常大，而其中真正有价值的信息却很少，因此从大量的数据中通过深层分析，获得有利于商业运作、提高竞争力的信息，就像从矿石中淘金一样，数据挖掘也因此而得名。

因此，数据挖掘可以描述为：按企业既定业务目标，对大量的企业数据进行探索和分析， 揭示隐藏的、未知的或验证已知的规律性，并进一步将其模型化的先进有效的方法。

数据挖掘与传统的数据分析（如查询、报表、联机应用分析）的本质区别是数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识。数据挖掘所得到的信息应具有先知，有效和可实用三个特征。

先前未知的信息是指该信息是预先未曾预料到的，即数据挖掘是要发现那些不能靠直觉发现的信息或知识，甚至是违背直觉的信息或知识，挖掘出的信息越是出乎意料，就可能越有价值。在商业应用中最典型的例子就是一家连锁店通过数据挖掘发现了小孩纸尿布和啤酒之间有着惊人的联系。

特别要指出的是，数据挖掘技术从一开始就是面向应用的。它不仅是面向特定数据库的简单检索查询调用，而且要对这些数据进行微观、中观乃至宏观的统计、分析、综合和推理， 以指导实际问题的求解，企图发现事件间的相互关联，甚至利用已有的数据对未来的活动进行预测。例如，加拿大 BC 省电话公司要求加拿大 Simon Fraser 大学知识发现研究组，根据其拥有十多年的客户数据，总结、分析并提出新的电话收费和管理办法，制定既有利于公司又有利于客户的优惠政策。这样一来，就把人们对数据的应用，从低层次的末端查询操作， 提高到为各级经营决策者提供决策支持。这种需求驱动力比数据库查询更为强大。

3.8.2 数据挖掘的功能

 

数据挖掘通过预测未来趋势及行为，做出前摄的、基于知识的决策。数据挖掘的目标是从数据库中发现隐含的、有意义的知识，主要有以下五类功能。

1. 自动预测趋势和行为数据挖掘自动在大型数据库中寻找预测性信息，以往需要进行大量手工分析的问题如今可以迅速直接由数据本身得出结论。一个典型的例子是市场预测问题，数据挖掘使用过去有关促销的数据来寻找未来投资中回报最大的用户，其他可预测的问题包括预报破产及认定对指定事件最可能做出反应的群体。
2. 关联分析数据关联是数据库中存在的一类重要的可被发现的知识。若两个或多个变量的取值之间存在某种规律性，就称为关联。关联可分为简单关联、时序关联、因果关联。关联分析的目的是找出数据库中隐藏的关联网。有时并不知道数据库中数据的关联函数，即使知道也是不确定的，因此关联分析生成的规则带有可信度。
   1. 聚类数据库中的记录可被划分为一系列有意义的子集，即聚类。聚类增强了人们对

客观现实的认识，是概念描述和偏差分析的先决条件。聚类技术主要包括传统的模式识别方法和数学分类学。20 世纪 80 年代初，Mchalski 提出了概念聚类技术及其要点，即在划分对象时不仅要考虑对象之间的距离，还要求划分出的类具有某种内涵描述，从而避免了传统技术的某些片面性。

1. 概念描述概念描述就是对某类对象的内涵进行描述，并概括这类对象的有关特征。概念描述分为特征性描述和区别性描述，前者描述某类对象的共同特征，后者描述不同类对象之间的区别。生成一个类的特征性描述只涉及该类对象中所有对象的共性。生成区别性描述的方法很多，如决策树方法、遗传算法等。
2. 偏差检测数据库中的数据常有一些异常记录，从数据库中检测这些偏差很有意义。偏差包括很多潜在的知识，如分类中的反常实例、不满足规则的特例、观测结果与模型预测值的偏差、量值随时间的变化等。偏差检测的基本方法是，寻找观测结果与参照值之间有意义的差别。

3.8.3 数据挖掘常用技术

 

常用的数据挖掘技术包括关联分析、序列分析、分类、预测、聚类分析及时间序列分析等。

1. 关联分析

关联分析主要用于发现不同事件之间的关联性，即一个事件发生的同时，另一个事件也经常发生。关联分析的重点在于快速发现那些有实用价值的关联发生的事件。其主要依据是事件发生的概率和条件概率应该符合一定的统计意义。

对于结构化的数据，以客户的购买习惯数据为例，利用关联分析，可以发现客户的关联购买需要。例如，一个开设储蓄账户的客户很可能同时进行债券交易和股票交易，购买纸尿裤的男顾客经常同时购买啤酒等。利用这种知识可以采取积极的营销策略，扩展客户购买的产品范围，吸引更多的客户。通过调整商品的布局便于顾客买到经常同时购买的商品，或者通过降低一种商品的价格来促进另一种商品的销售等。

对于非结构化的数据，以空间数据为例，利用关联分析，可以发现地理位置的关联性。例如，85%的靠近高速公路的大城镇与水相邻，或者发现通常与高尔夫球场相邻的对象等。

1. 序列分析

序列分析技术主要用于发现一定时间间隔内接连发生的事件。这些事件构成一个序列，

发现的序列应该具有普遍意义，其依据除了统计上的概率之外，还要加上时间的约束。

1. 分类分析

分类分析通过分析具有类别的样本的特点，得到决定样本属于各种类别的规则或方法。利用这些规则和方法对未知类别的样本分类时应该具有一定的准确度。其主要方法有基于统计学的贝叶斯方法、神经网络方法、决策树方法及支持向量机（support vector machines） 等。

利用分类技术，可以根据顾客的消费水平和基本特征对顾客进行分类，找出对商家有较大利益贡献的重要客户的特征，通过对其进行个性化服务，提高他们的忠诚度。

利用分类技术，可以将大量的半结构化的文本数据，如 WEB 页面、电子邮件等进行分类。可以将图片进行分类，例如，根据已有图片的特点和类别，可以判定一幅图片属于何种类型的规则。对于空间数据，也可以进行分类分析，例如，可以根据房屋的地理位置决定房屋的档次。

1. 聚类分析

聚类分析是根据物以类聚的原理，将本身没有类别的样本聚集成不同的组，并且对每一个这样的组进行描述的过程。其主要依据是聚到同一个组中的样本应该彼此相似，而属于不同组的样本应该足够不相似。

仍以客户关系管理为例，利用聚类技术，根据客户的个人特征及消费数据，可以将客户群体进行细分。例如，可以得到这样的一个消费群体：女性占 91%，全部无子女、年龄在 31 岁到 40 岁占 70%，高消费级别的占 64%，买过针织品的占 91%，买过厨房用品的占 89%， 买过园艺用品的占 79%。针对不同的客户群，可以实施不同的营销和服务方式，从而提高客户的满意度。

对于空间数据，根据地理位置及障碍物的存在情况可以自动进行区域划分。例如，根据分布在不同地理位置的 ATM 机的情况将居民进行区域划分，根据这一信息，可以有效地进行 ATM 机的设置规划，避免浪费，同时也避免失掉每一个商机。

对于文本数据，利用聚类技术可以根据文档的内容自动划分类别，从而便于文本的检索。

1. 预测

预测与分类类似，但预测是根据样本的已知特征估算某个连续类型的变量的取值的过程， 而分类则只是用于判别样本所属的离散类别而已。预测常用的技术是回归分析。

1. 时间序列

分析时间序列分析的是随时间而变化的事件序列，目的是预测未来发展趋势，或者寻找

相似发展模式或者是发现周期性发展规律。

3.8.4 数据挖掘的流程

 

数据挖掘是指一个完整的过程，该过程从大型数据库中挖掘先前未知的，有效的，可实用的信息，并使用这些信息做出决策或丰富知识。

数据挖掘环境示意图如图 3-13 所示。

数据挖掘的流程大致如下：

1. 问题定义在开始数据挖掘之前，最先的也是最重要的要求就是熟悉背景知识，弄清用户的需求。缺少了背景知识，就不能明确定义要解决的问题，就不能为挖掘准备优质的数据，也很难正确地解释得到的结果。要想充分发挥数据挖掘的价值，必须对目标有一个清晰明确的定义，即决定到底想干什么。
   1. 建立数据挖掘库

要进行数据挖掘必须收集要挖掘的数据资源。一般建议把要挖掘的数据都收集到一个数据库中，而不是采用原有的数据库或数据仓库。这是因为大部分情况下需要修改要挖掘的数据，而且还会遇到采用外部数据的情况；另外，数据挖掘还要对数据进行各种纷繁复杂的统计分析，而数据仓库可能不支持这些数据结构。

1. 分析数据

分析数据就是通常所进行的对数据深入调查的过程。从数据集中找出规律和趋势，用聚类分析区分类别，最终要达到的目的就是搞清楚多因素相互影响的、十分复杂的关系，发现因素之间的相关性。

1. 调整数据

通过上述步骤的操作，对数据的状态和趋势有了进一步的了解，这时要尽可能对问题解决的要求能进一步明确化、进一步量化。针对问题的需求对数据进行增删，按照对整个数据挖掘过程的新认识组合或生成一个新的变量，以体现对状态的有效描述。

1. 模型化

在问题进一步明确，数据结构和内容进一步调整的基础上，就可以建立形成知识的模型。这一步是数据挖掘的核心环节，一般运用神经网络、决策树、数理统计、时间序列分析等方法来建立模型。

1. 评价和解释

上面得到的模式模型，有可能是没有实际意义或没有实用价值的，也有可能是其不能准确反映数据的真实意义，甚至在某些情况下是与事实相反的，因此需要评估，确定哪些是有效的、有用的模式。评估的一种办法是直接使用原先建立的挖掘数据库中的数据来进行检验， 另一种办法是另找一批数据并对其进行检验，再一种办法是在实际运行的环境中取出新鲜数据进行检验。

数据挖掘过程的分步实现，不同的步骤需要不同专长的人员，他们大体可以分为三类。

（1） 业务分析人员。要求精通业务，能够解释业务对象，并根据各业务对象确定出用于数据定义和挖掘算法的业务需求。

（2） 数据分析人员。精通数据分析技术，并较熟练地掌握统计学，有能力把业务需求转化为数据挖掘的各步操作，并为每步操作选择合适的技术。

（3） 数据管理人员。精通数据管理技术，并从数据库或数据仓库中收集数据。

由上可见，数据挖掘是一个多种专家合作的过程，也是一个在资金上和技术上高投入的过程。这一过程要反复进行，在反复过程中，不断地趋近事物的本质，不断地优选问题的解决方案。

3.9 NoSQL

 

NoSQL  即 Not Only SQL，可直译“不仅仅是 SQL”，这项技术正在掀起一场全新的数据库革命性运动。

在本章 3.2.2 节曾提到数据的模式包括多种类型，如层次模型、网状模型、关系模型等， 而在实际应用过程中，几乎都是在用关系模型，主流的数据库系统都是关系型的。但随着互联网 web2.0 网站的兴起，传统的关系数据库在应付 web2.0 网站，特别是超大规模和高并发的 SNS 类型的 web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。这也就使得 NoSQL 技术进入了人们的视野。

NoSQL 的出现打破了长久以来关系型数据库与 ACID 理论大一统的局面。NoSQL 数据

存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。

关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

与关系型数据库相比，NoSQL 数据库具有以下几个优点：

1. 易扩展

NoSQL 数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间，在架构的层面上带来了可扩展的能力。

1. 大数据量，高性能

NoSQL 数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般 MySQL 使用 Query Cache，每次表一更新 Cache 就失效，它是一种大粒度的 Cache，在针对 web2.0 的交互频繁的应用，Cache 性能不高。而 NoSQL 的 Cache  是记录级的，是一种细粒度的 Cache，所以 NoSQL  在这个层面上来说性能就高很多了。

1. 灵活的数据模型

NoSQL 无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的 web2.0 时代尤其明显。

1. 高可用

NoSQL 在不太影响性能的情况，就可以方便地实现高可用的架构。比如 Cassandra， HBase 模型，通过复制模型也能实现高可用。

当然，NoSQL 也存在很多缺点，例如，并未形成一定标准，各种产品层出不穷，内部混乱，各种项目还需时间来检验，缺乏相关专家技术的支持等。

3.10 大数据

 

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

1. 大数据的特点

业界通常用 4 个 V(即 Volume、Variety、Value、Velocity)来概括大数据的特征。

Volume：指的是数据体量巨大，从 TB  级别跃升到 PB  级别（1PB=1024TB）、EB  级别

（1EB=1024PB），甚至于达到 ZB  级别（1ZB=1024EB）。截至目前，人类生产的所有印刷材料的数据量是 200PB，而历史上全人类说过的所有话的数据量大约是 5EB。当前，典型个人计算机硬盘的容量为 TB 量级，而一些大企业的数据量已经接近 EB 量级。

例如，在交通领域，某市交通智能化分析平台数据来自路网摄像头/传感器、公交、轨道交通、出租车以及省际客运、旅游、化危运输、停车、租车等运输行业，还有问卷调查和地理信息系统数据。4 万辆车每天产生 2000 万条记录，交通卡刷卡记录每天 1900

万条，手机定位数据每天 1800 万条，出租车运营数据每天 100 万条，电子停车收费系统

数据每天 50 万条，定期调查覆盖 8 万户家庭等，这些数据在体量上就达到了大数据的规模。

Variety：指的是数据类型繁多。这种类型的多样性也让数据被分为结构化数据和非结构化数据。相对于以往便于存储的以文本为主的结构化数据，非结构化数据越来越多，包括网络日志、音频、视频、图片、地理位置信息等，这些多类型的数据对数据的处理能力提出了更高要求。

Value：指的是价值密度低。价值密度的高低与数据总量的大小成反比。以视频为例， 一部 1 小时的视频，在连续不间断的监控中，有用数据可能仅有 1-2 秒。如何通过强大的机器算法更迅速地完成数据的价值“提纯”成为目前大数据背景下亟待解决的难题。当然把数据集成在一起，并完成“提纯”是能达到 1+1 大于 2 的效果的，这也正是大数据技术的核心价值之一。

Velocity：指的是处理速度快。这是大数据区分于传统数据挖掘的最显著特征。根据 IDC 的“数字宇宙”的报告，预计到 2020 年，全球数据使用量将达到 35.2ZB。在如此海量的数据面前，处理数据的效率就是企业的生命。

1. 传统数据与大数据的比较

传统数据与大数据的差异如表 3-13 所示。

1. 大数据处理关键技术

大数据处理关键技术一般包括：大数据采集、大数据预处理、大数据存储及管理、大数据分析及挖掘、大数据展现和应用（大数据检索、大数据可视化、大数据应用、大数据安全等）。

1. 大数据应用

大数据可以在各行各业得以应用，如金融服务、医疗保健、零售业、制造业、政府机构等。