第 3 章 数据库系统 3.2数据库模式与范式

第 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 的 U一、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） 肯定实体间的联系。实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工做一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。

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

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

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

 

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

 

一对一联系：这是一种最简单的联系类型。若对于实体集 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 相关的另外一实体的属性，而后再进行集成。

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

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

 

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：将实体 E一、E2 和联系名 R 分别转换成为关系 E一、E2 和 R，它们的属性分别转为相应关系的属性，即获得：

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

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

 

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

 

方案 2：将实体 El 转换为关系 El ，将实体 E2  与联系名 R  一块儿转换成关系 E2  ，E2 的属性由 E2 和 R 的属性加上 E1 的关键字组成，其关键字 k一、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、 Db二、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. 大数据应用

 

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