1. 数据库管理系统的类型

1.1. 数据库管理系统的类型通常有多个分类标准

1. 按数据模型分类
2. 按用户数分类
3. 按数据库分布站点分类

我们需要了解的，主要还是按数据模型分类。

当前，许多商业 DBMS 中所用的主要数据模型仍是关系数据模型。有些商业系统中实现了对象数据模型，但未得到广泛使用。近几年随着 NoSQL 技术的兴起，也产生了一些新的数据模型。

1. 关系型 DBMS
2. 文档型 DBMS
3. 键值型 DBMS
4. 对象型 DBMS

1.2. 数据库模式与范式

1.2.1. 数据库的结构与模式

1.2.1.1. 三级抽象

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

1. 用户级数据库

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

2. 概念级数据库

概念级数据库对应于概念模式，介于用户级和物理级之间，是所有用户视图的最小并集，是数据库管理员可看到和使用的数据库，又称 DBA（DataBase Administrator，数据库管理员）视图。

• 概念级数据库由概念记录组成，一个数据库可有多个不同的用户视图，每个用户视图由数据库某一部分的抽象表示所组成。
• 一个数据库应用系统只存在一个 DBA 视图，它把数据库作为一个整体的抽象表示。
• 概念级模式把用户视图有机地结合成一个整体，综合平衡考虑所有用户要求，实现数据的一致性、最大限度降低数据冗余、准确地反映数据间的联系。

3. 物理级数据库

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

1.2.1.2. 三级模式

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

1. 概念模式

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

1. 外模式

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

1. 内模式

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

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

• 模式是数据库的中心与关键；
• 内模式依赖于模式，独立于外模式和存储设备；
• 外模式面向具体的应用，独立于内模式和存储设备；
• 应用程序依赖于外模式，独立于模式和内模式。

1.2.1.3. 两级独立性

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

1. 物理独立性。

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

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

1. 逻辑独立性。

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

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

逻辑独立性比物理独立性更难实现。

1.3. 数据模型

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

1. 概念数据模型（实体—联系模型）

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

2. 基本数据模型（结构数据模型）

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

1.3.1. 常用的基本数据模型

1. 层次模型
2. 网状模型
3. 关系模型
4. 和面向对象模型

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

• 建立在严格的数学概念基础上；
• 概念（关系）单一，结构简单、清晰，用户易懂易用；
• 存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。

1.3.2. 关系代数

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

1.3.3. 数据的规范化

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

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

• 无损连接性：信息不失真（不增减信息）。
• 函数依赖保持性：不破坏属性间存在的依赖关系。

1. 第一范式

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

2. 第二范式

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

3. 第三范式

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

4. BC 范式

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

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

• 非主属性完全函数依赖于码（2NF 的要求）；
• 非主属性不传递依赖于任何一个候选码（3NF 的要求）；
• 主属性对不含它的码完全函数依赖（BCNF 的要求）；
• 没有属性完全函数依赖于一组非主属性（BCNF 的要求）。

1.3.4. 反规范化

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

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

1. 增加冗余列

增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。

例如：以规范化设计的理念，学生成绩表中不需要字段“姓名”，因为“姓名”字段可以通过学号查询到，但在反规范化设计中，会将“姓名”字段加入表中。这样查询一个学生的成绩时，不需要与学生表进行连接操作，便可得到对应的“姓名”。
1

2. 增加派生列

增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。

例如：订单表中，有商品号、商品单价、采购数量，我们需要订单总价时，可以通过计算得到总价，所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑，由于订单总价在每次查询都需要计算，这样会占用系统大量资源，所以在此表中增加派生列“订单总价”以提高查询效率。
1

3. 重新组表

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

4. 分割表

有时对表做分割可以提高性能。表分割有两种方式。水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。

水平分割通常在下面的情况下使用。

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

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

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

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

1.4. 数据库设计

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

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

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

1. 同时具备数据库知识与应用业务知识的人很少。懂得计算机与数据库的人一般都缺乏应用业务知识和实际经验，而熟悉应用业务的人又往往不懂计算机和数据库。
2. 项目初期往往不能确定应用业务的数据库系统的目标。
3. 缺乏完善的设计工具和设计方法。
4. 需求的不确定性。用户总是在系统的开发过程中不断提出新的要求，甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。
5. 应用业务系统千差万别，很难找到一种适合所有业务的工具和方法，这就增加了研究数据库自动生成工具的难度。因此，研制适合一切应用业务的全自动数据库生成工具是不可能的。

1.4.1 数据库设计的方法

目前已有的数据库设计方法可分为四类

• 直观设计法

直观设计法又称单步逻辑设计法，它依赖于设计者的知识、经验和技巧，缺乏工程规范的支持和科学根据，设计质量也不稳定，因此越来越不适应信息管理系统发展的需要。

• 规范设计法

• 计算机辅助设计法

• 自动化设计法

1.4.2. 数据库设计的基本步骤

1. 需求分析

需求分析是指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。

其目标是通过调查研究，了解用户的数据要求和处理要求，并按一定格式整理形成需求说明书。

需求说明书是需求分析阶段的成果，也是今后设计的依据，它包括数据库所涉及的数据、数据的特征、使用频率和数据量的估计，如数据名、属性及其类型、主关键字属性、保密要求、完整性约束条件、更改要求、使用频率、数据量估计等。

这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。用数据字典管理元数据有利于避免数据的重复或重名，以保持数据的一致性及提供各种统计数据，因而有利于提高数据库设计的质量，同时可以减轻设计者的负担。

2. 概念结构设计

它是数据库设计的第二阶段，其目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，即用户的数据模型或企业数据模型。

这种概念数据模型与 DBMS 无关，是面向现实世界的、极易为用户所理解的数据模型。为保证所设计的概念数据模型能正确、完整地反映用户的数据及其相互关系，便于进行所要求的各种处理，在本阶段设计中可吸收用户参与和评议设计。

在进行概念结构设计时，可先设计各个应用的视图（view），即各个应用所看到的数据及其结构，然后再进行视图集成，以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改，最后形成所需的概念数据模型。

3. 逻辑结构设计

这一阶段的设计目标是把上一阶段得到的与 DBMS 无关的概念数据模型转换成等价的，并为某个特定的 DBMS 所接受的逻辑模型所表示的概念模式，同时将概念设计阶段得到的应用视图转换成外部模式，即特定 DBMS 下的应用视图。

在转换过程中要进一步落实需求说明，并满足 DBMS 的各种限制。该阶段的结果是用 DBMS 所提供的数据定义语言（DDL）写成的数据模式。

逻辑设计的具体方法与 DBMS 的逻辑数据模型有关。逻辑模型应满足数据库存取、一致性及运行等各方面的用户需求。

4. 数据库物理设计

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

1.4.3. 需求分析

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

因此，这一阶段的任务是：

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

数据库设计的第一项工作就是要对系统的整个应用情况进行全面、详细的实地调查，弄清现行系统的组织结构、功能划分、总体工作流程，收集支持系统总的设计目标的基础数据和对这些数据的处理要求，明确用户总的需求目标；

通过分析，确定相应的设计目标，即确定数据库应支持的应用功能和应用范围，明确哪些功能由计算机完成或准备让计算机完成，哪些环节由人工完成，以确定应用系统实现的功能。

这一阶段收集到的基础数据和一组数据流程图是下一步进行概念设计的基础。

2. 分析和收集数据

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

3. 整理文档

分析和收集得到的数据必须经过筛选整理，并按一定格式和顺序记载保存，经过审核成为正式的需求说明文档，即需求说明书。

实际上，需求说明书是在需求分析的过程中逐渐整理形成的，是随着这一过程的不断深入而反复修改与完善的对系统需求分析的全面描述。由用户、领导和专家共同评审，是以后各设计阶段的主要依据。

这一步的工作是进行全面的汇总与整理，使之系统化，以形成标准化的统一形式。

1.4.4. 概念结构设计

概念结构设计阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。

概念结构设计的目标是产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。概念结构设计的任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。

概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

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

概念模型的描述工具应该能够体现概念模型的特点，如 E-R 模型。

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

1. 视图设计

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

• 确定局部视图的范围。
• 识别实体及其标识。
• 确定实体间的联系。

2. 视图集成

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

• 同名异义。
• 异名同义。
• 同名不同层次。

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

• 虽同名同义，但对象联系测度不同

1.4.5. 逻辑结构设计

数据库逻辑设计的基础是概念设计的结果，而其成果应包括某 DBMS 所支持的外模式、概念模式及其说明及建立外模式和概念模式的 DDL 程序。

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

• 将概念结构向一般关系模型转化。
• 将第一步得到的结构向特定的 DBMS 支持下的数据模型转换。
• 依据应用的需求和具体的 DBMS 的特征进行调整与完善。

1.4.6. 物理结构设计

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

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

1. 了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对时间和空间进行平衡，并保证优先满足应用的时间要求。
2. 熟悉使用的 DBMS 的性能，包括 DBMS 的功能，提供的物理环境、存储结构、存取方法和可利用的工具。
3. 了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及 I/O 特性等。

1.5. 事务管理

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

• 原子性（Atomicity）：数据库的逻辑工作单位。
• 一致性（Consistency）：使数据库从一个一致性状态变到另一个一致性状态。
• 隔离性（Isolation）：不能被其他事务干扰。
• 持续性（永久性）（Durability）：一旦提交，改变就是永久性的。

事务通常以 BEGIN TRANSACTION（事务开始）语句开始，以 COMMIT 或 ROLLBACK 语句结束。COMMIT 称为“事务提交语句”，表示事务执行成功的结束。ROLLBACK 称为“事务回退语句”，表示事务执行不成功的结束。

1.5.1. 并发控制

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

数据库的并发操作带来的问题有：丢失更新问题、不一致分析问题（读过时的数据）、依赖于未提交更新的问题（读了“脏”数据）。

处理并发控制的主要方法是采用封锁技术。它有两种类型：排他型封锁（X 封锁）和共享型封锁（S 封锁）

1. 排他型封锁（简称 X 封锁）
2. 共享型封锁（简称 S 封锁）

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

1. 一级封锁协议。事务 T 在修改数据 R 之前必须先对其加 X 锁，直到事务结束才释放。一级封锁协议可防止丢失修改，并保证事务 T 是可恢复的。但不能保证可重复读和不读“脏”数据。
2. 二级封锁协议。一级封锁协议加上事务 T 在读取数据 R 之前先对其加 S 锁，读完后即可释放 S 锁。二级封锁协议可防止丢失修改，还可防止读“脏”数据，但不能保证可重复读。
3. 三级封锁协议。一级封锁协议加上事务 T 在读取数据 R 之前先对其加 S 锁，直到事务结束才释放。三级封锁协议可防止丢失修改、防止读“脏”数据与防止数据重复读。
4. 两段锁协议。所有事务必须分两个阶段对数据项加锁和解锁。其中扩展阶段是在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；收缩阶段是在释放一个封锁之后，事务不能再申请和获得任何其他封锁。若并发执行的所有事务均遵守两段封锁协议，则对这些事务的任何并发调度策略都是可串行化的。遵守两段封锁协议的事务可能发生死锁。

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

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

一般来讲，死锁是可以避免的，目前采用的办法有以下几种：

1. 预防法。此种方法是采用一定的操作方式以保证避免死锁的出现，顺序申请法、一次申请法等即是此类方法。

2. 死锁的解除法。此种方法允许产生死锁，并在死锁产生后通过解锁程序以解除死锁。这种方法需要有两个程序，一是死锁检测程序，用它测定死锁是否发生，另一是解锁程序，一旦经测定系统已产生死锁则启动解锁程序以解除死锁。

1.5.2. 故障与恢复

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

1. 事务故障

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

2. 系统故障

系统故障是指系统在运行过程中，由于某种原因（如操作系统或数据库管理系统代码错误、操作员操作失误、特定类型的硬件错误（如 CPU 故障）、突然停电等造成系统停止运行），致使事务在执行过程中以非正常方式终止，这时内存中的信息丢失，但存储在外存储设备上的数据不会受影响。

3. 介质故障

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

4. 计算机病毒

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

故障的恢复

1. 事务故障的恢复

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

• 反向扫描文件日志，查找该事务的更新操作。
• 对该事务的更新操作执行逆操作。
• 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
• 如此处理下去，直至读到此事务的开始标记，事务故障恢复完成。

2. 系统故障的恢复

3. 介质故障与病毒破坏的恢复

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

• 装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
• 从故障点开始反向读日志文件，找出已提交事务标识将其记入重做队列。
• 从起始点开始正向阅读日志文件，根据重做队列中的记录，重做所有已完成事务，将数据库恢复至故障前某一时刻的一致状态。

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

• 建立检查点时刻所有正在执行的事务清单。
• 这些事务最近一个日志记录的地址。采用检查点的恢复步骤如下：
• 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。
• 由该检查点记录得到检查点建立时所有正在执行的事务清单队列（A）。

1.6 备份与恢复

数据库中的数据一般都十分重要，不能丢失，因为各种原因，数据库都有损坏的可能性（虽然很小），所以事先制定一个合适的、可操作的备份和恢复计划至关重要。备份和恢复计划的制订要遵循以下两个原则：

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

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

1.7. 分布式数据库系统

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

1.7.1. 分布式数据库的概念

分布式数据库系统是相对于集中式数据库系统而言的，是将数据库技术与网络技术相结合的产物。

分布式数据库（Distributed DataBase，DDB）比较确切的定义是：分布式数据库是由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个结点具有独立处理的能力，成为场地自治，它可以执行局部应用，同时，每个结点也能通过网络通信子系统执行全局应用。

负责分布式数据库的建立、查询、更新、复制、管理和维护的软件，称为分布式数据库管理系统（Distributed DataBase Management System， DDBMS）。

分布式数据库管理系统保证分布式数据库中数据的物理分布对用户的透明性。一个计算机网络组成的计算机系统，在配置了分布式数据库管理系统，并在其上建立了分布式数据库和相应的应用程序后，就称其为分布式数据库系统（Distributed DataBase System，DBS）。

分布式数据库管理系统是分布式数据库系统的核心。

1.7.1.1. 几个特点

1. 数据的分布性。分布式数据库中的数据分布于网络中的各个结点，它既不同于传统的集中式数据库，也不同于通过计算机网络共享的集中式数据库系统。
2. 统一性。主要表现在数据在逻辑上的统一性和数据在管理上的统一性两个方面。分布式数据库系统通过网络技术把局部的、分散的数据库构成一个在逻辑上单一的数据库，从而呈现在用户面前的就如同是一个统一的、集中式的数据库。这就是数据在逻辑上的统一性，因此，它不同于由网络互联的多个独立数据库。分布式数据库是由分布式数据库管理系统统一管理和维护的，这种管理上的统一性又使它不同于一般的分布式文件系统。
3. 透明性。用户在使用分布式数据库时，与使用集中式数据库一样，无须知道其所关心的数据存放在哪里，存储了几次。用户需要关心的仅仅是整个数据库的逻辑结构。

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

1. 坚固性好。由于分布式数据库系统是由多个位置上的多台计算机构成的，在个别结点或个别通信链路发生故障的情况下，它仍然可以降低级别继续工作，如果采用冗余技术，还可以获得一定的容错能力。因此，系统的坚固性好，即系统的可靠性和可用性好。
2. 可扩充性好。可根据发展的需要增减结点，或对系统重新配置，这比用一个更大的系统代替一个已有的集中式数据库要容易得多。
3. 可改善性能。在分布式数据库中可按就近分布，合理地冗余的原则来分布各结点上的数据，构造分布式数据库，使大部分数据可以就近访问，避免了集中式数据库中的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且也降低了通信费用。
4. 自治性好。数据可以分散管理，统一协调，即系统中各结点的数据操纵和相互作用是高度自治的，不存在主从控制，因此，分布式数据库较好地满足了一个单位中各部门希望拥有自己的数据，管理自己的数据，同时又想共享其他部门有关数据的要求。

1.7.1.3. 分布式数据库的分类

分布式数据库及其分布式数据库管理系统，根据许多因素有不同的分类方法，总的原则是分布式数据库及 DDBMS 必须是其数据和软件必定分布在用计算机网络连接的多个场地上。

1. 按 DDBMS 软件同构度来分。当所有服务器软件（或每个 LDBMS）和所有客户软件均用相同的软件时称为同构型分布式数据库；反之，则称为异构型分布式数据。
2. 按局部自治度来分。当对 DDBMS 的存取必须通过客户软件，则系统称为无局部自治；当局部事务允许对服务器软件进行直接存取，则系统称为有一定的局部自治。自治的两个分别是无局部自治和联邦型 DDBMS 或称多数据库系统。
3. 按分布透明度来分。分布透明度的另一个概念是模式集成度。若用户可以对集成模式操作不需要涉及任何片段、重复、分布等信息时，则这类 DDBMS 称为有高度分布透明（或高度模式集成）；若用户必须知道所有关于片段、分配、重复等信息时，则这类 DDBMS没有分布透明，没有模式集成度。

1.7.1.4. 分布式数据库的目标

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

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

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

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

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

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

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

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

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

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

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

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

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