Chapter 1: Introduction¶

约 5201 个字 3 张图片预计阅读时间 17 分钟

数据库管理系统（DataBase-Management System，DBMS）由一个互相关联的数据的集合和一组用以访问这些数据的程序组成，这个数据集合通常称作数据库（database）。DBMS 的主要目标是要提供一种可以方便、高效地存取数据库信息的途径。

数据库系统应用¶

数据库系统用于管理如下的数据集合：

具有很高价值的数据集合
相对庞大的数据集合
常常同时被多个用户和应用系统访问的数据集合

概括地说，有两种使用数据库的方式：

联机事务处理（online transaction processing），即大量用户使用数据库，每个用户检索相对少量的数据，进行小的更新。
数据分析（data analytics），即审阅数据，给出结论，并推导出规则或决策程序，以用于驱动业务决策。

数据库系统的目标¶

典型的文件处理系统（file-processing system）是传统的操作系统所支持的。系统将永久记录存储在多个不同的文件中，需要有不同的应用程序来将记录从有关文件中取出或加入适当的文件中。在文件处理系统中存储组织机构的信息的主要弊端包括以下方面：

数据的冗余和不一致性（data redundancy and inconsistency）
数据访问困难（difficulty in accessing data）
数据孤立（data isolation）
完整性问题（integrity problem）
原子性问题（atomicity problem）
并发访问异常（concurrent-access anomaly）
安全性问题（security problem）

数据视图¶

数据库系统是一些互相关联的数据以及一组使得用户可以访问和修改这些数据的程序的集合。数据库系统的一个主要目的是给用户提供数据的抽象视图，也就是说，系统隐藏关于数据存储和维护的某些细节。

数据模型¶

数据库结构的基础是数据模型（data model），一个描述数据、数据联系、数据语义以及一致性约束（consistency constraint）的概念工具的集合。

数据模型可被划分为四类：

关系模型（relational model）：关系模型用表的集合来表示数据和数据间的联系，每个表有多个列，每列有唯一的列名。表也称作关系。关系模型是基于记录的模型的一种。
实体 - 联系模型（entity-relationship model，E-R model）：E-R 数据模型使用称作实体的基本对象的集合，以及这些对象间的联系。
半结构化数据模型（semi-structured data model）：半结构化数据模型允许在其数据定义中某些相同类型的数据项含有不同的属性集，而在前两种数据模型中特定类型的每一个数据项都必须有相同的属性集。JSON 和可扩展标记语言（eXtensible MarkupLanguage，XML）被广泛地用来表示半结构化数据。
基于对象的数据模型（object-based data model）：过程可以被存放在数据库系统中，并由数据库系统来执行它们，这可以看成对关系模型进行扩展，增加了封装、方法和对象标识等概念。

关系数据模型¶

在关系模型中，数据以表的形式表示。每个表有多个列，每个列有唯一的名字。表的每一行表示一条信息。

数据抽象¶

系统开发人员通过如下几个层次的数据抽象（data abstraction）来对用户屏蔽系统的复杂性，以简化用户与系统的交互：

物理层（physical level）：最低层次的抽象，描述数据实际上是怎样存储的。物理层详细描述复杂的底层数据结构。
逻辑层（logical level）：比物理层层次稍高的抽象，描述数据库中存储什么数据以及这些数据间存在什么联系，通过少量相对简单的结构描述整个数据库。逻辑层的简单结构的实现可能涉及复杂的物理层结构，但逻辑层的用户不必意识到这样的复杂性，这称作物理数据独立性（physical data independence）。
视图层（view level）：最高层次的抽象，它只描述整个数据库的某个部分。视图层抽象的存在是为了使不需要全部数据库中信息的用户与系统的交互更加简单。系统可以为同一数据库提供多个视图。

这三层抽象的相互关系如下图所示：

实例和模式¶

特定时刻存储在数据库中的信息的集合称作数据库的一个实例（instance），数据库的总体设计称作数据库模式（schema）。用程序设计语言进行类比，数据库模式对应程序中的变量声明（以及与之关联的类型的定义），每个变量在特定时刻会有特定的值，程序中变量在某一时刻的值对应于数据库模式的一个实例。

按不同的抽象层次划分，数据库系统有几种模式：

物理模式（physical schema）：在物理层描述数据库的设计。
逻辑模式（logical schema）：在逻辑层描述数据库的设计。

数据库在视图层也可以有几种模式，有时称为子模式（subschema），它描述了数据库的不同模式。

数据库语言¶

数据库系统提供数据定义语言（Data-Definition Language，DDL）来定义数据库模式，并提供数据操纵语言（Data-Manipulation Language，DML）来表达数据库的查询和更新。这二者并不是两种互相分离的语言，它们仅仅是构成了单一的数据库语言（如 SQL 语言）的不同部分。

数据定义语言¶

数据库模式通过一系列定义来说明，这些定义由一种称作数据定义语言的特定语言来表达。DDL 也可用于定义数据的其他特征。

通过一系列特定的 DDL 语句来说明数据库系统所采用的存储结构和访问方式，这种特定的 DDL 称作数据存储和定义（data storage and definition）语言。这些语句定义了数据库模式的实现细节，而这些细节对用户来说通常是不可见的。

存储在数据库中的数据值必须满足某些一致性约束。例如，假设大学要求一个系的账户余额必须不能为负值。DDL 语言提供了指明这样的约束的工具。每当数据库被更新时，数据库系统都会检查这些约束。通常，约束可以是关于数据库的任意谓词。然而，如果要测试任意谓词，可能代价比较高。因此，数据库系统仅实现可以以最小代价测试的完整性约束。在此介绍以下几类：

域约束（domain constraint）：每个属性都必须对应于一个所有可能的取值构成的域（例如，整数型、字符型、日期／时间型）。声明一个属性属于某个具体的域就相当于约束它可以取的值。域约束是完整性约束的最基本形式。
引用完整性（referential integrity）：我们通常希望能确保一个关系中给定属性集上的取值也在另一关系的某一属性集的取值中出现（引用完整性）。数据库的修改有可能会导致引用完整性的破坏。当引用完整性约束被违反时，通常的处理是拒绝执行导致完整性被破坏的操作。
授权（authorization）：我们希望对用户加以区别，对于不同的用户在数据库中的不同数据值上允许不同的访问类型。这些区别以授权来表达，最常见的是：
- 读权限（read）：允许读取数据，但不能修改数据；
- 插入权限（insert）：允许插入新数据，但不允许修改已有数据；
- 更新权限（update）：允许修改，但不能删除数据；
- 删除权限（delete）：允许删除数据。
我们可以赋予用户所有或者部分这些权限，也可以不赋予用户任何这些权限。

对 DDL 语句的处理会产生一些输出，这些输出放在数据字典（data dictionary）中，数据字典包含元数据（metadata），元数据是关于数据的数据。可以把数据字典看作一种特殊的表，这种表只能由数据库系统本身来访问和修改。在读取和修改实际的数据前，数据库系统先要参考数据字典。

数据操纵语言¶

数据操纵语言是这样一种语言，它使得用户可以访问或操纵那些按照某种适当的数据模型组织起来的数据。有以下访问类型：

对存储在数据库中的信息进行检索；
向数据库中插入新的信息；
从数据库中删除信息；
修改数据库中存储的信息。

基本上有两种类型的数据操纵语言：

过程化的 DML（procedural DML）：要求用户指定需要什么数据以及如何获得这些数据。
声明式的 DML（declarative DML，也称为非过程化的 DML）：只要求用户指定需要什么数据，而不必指明如何获得这些数据。因此数据库系统必须找出一种访问数据的高效途径。

查询（query）是要求对信息进行检索的语句。DML 中涉及信息检索的部分称作查询语言（query language）。实践中常把查询语言和数据操纵语言作为同义词使用，尽管从技术上来说这并不正确。

从应用程序访问数据库¶

SQL 不支持诸如从用户输入、输出到显示器或在网络上通信这样的动作。这样的计算和动作必须用一种宿主（host）语言来写，比如 C/C++、Java 或 Python，在其中使用嵌入式的 SQL 查询来访问数据库中的数据。应用程序（application program）就是用来以这种方式与数据库进行交互的程序。

为访问数据库，需要将 DML 语句从宿主发送到执行这些语句的数据库。最通用的办法是使用应用程序接口（过程集合），它可以用来将 DML 和 DDL 的语句发送给数据库，再取回结果。开放数据库连接（ODBC）标准定义用于 C 语言和其他几种语言的应用程序接口。Java 数据库连接（JDBC）标准为 Java 语言提供了相应的接口。

数据库设计¶

数据库设计的主要内容是数据库模式的设计。

高层的数据模型为数据库设计者提供了一个概念框架，来说明数据库用户的数据需求，以及将怎样构造数据库结构以满足这些需求。

下一步，设计者选择一个数据模型，并运用该选定的数据模型的概念，将那些需求转换成一个数据库的概念模式。在这个概念设计（conceptual-design）阶段开发出来的模式提供了企业的详细综述。设计者再复审这个模式，确保满足所有的数据需求并且需求之间没有冲突。这一阶段的重点是描述数据以及它们之间的联系，而不是指定物理的存储细节。

从关系模型的角度来看，概念设计阶段涉及决定数据库中应该包括哪些属性，以及如何组织这些属性到各个表中。解决第二个问题的方法主要有两种：一种是使用实体 - 联系模型，另一种是采用一套算法（统称为规范化（normalization），它将所有属性集作为输入，生成一组关系表）。

一个开发完全的概念模式还将指出企业的功能需求。在功能需求说明（specification of functional requirement）中，用户描述将在数据之上执行的各种操作（或事务）。操作的示例包括修改或更新数据、查找和取回特定的数据、删除数据等。在概念设计的这个阶段，设计者可以对模式进行复审，确保它满足功能需求。

现在，将抽象数据模型转换到数据库实现的过程进入最后两个设计阶段。在逻辑设计阶段（logical-design phrase），设计人员将高层的概念模式映射到要使用的实现数据库系统的数据模型上。然后设计人员将得到的特定于系统的数据库模式用到后续的物理设计阶段（physical-design phrase）中，在这个阶段中说明数据库的物理特性，这些特性包括文件组织的形式以及内部的存储结构。

数据库引擎¶

数据库系统被划分为多个模块，每个模块完成整个系统的一个功能。数据库系统的功能部件大致可分为存储管理器、查询处理器（query processor）部件和事务管理部件。

传统上数据库引擎是集中式的计算机系统，而当今的并发处理是高效管理海量数据的关键所在。现代的数据库引擎非常注重并发数据存储和并发查询处理。

存储管理器¶

存储管理器（storage manager）是数据库系统中负责在数据库中存储的低层数据与应用程序以及向系统提交的查询之间提供接口的部件。存储管理器负责与文件管理器进行交互。原始数据通过操作系统提供的文件系统存储在磁盘上。存储管理器将各种 DML 语句翻译为底层文件系统命令。因此，存储管理器负责数据库中数据的存储、检索和更新。

存储管理器部件包括：

权限及完整性管理器（authorization and integrity manager）：检测是否满足完整性约束，并检查试图访问数据的用户的权限。
事务管理器（transaction manager）：保证即使系统发生了故障，数据库也保持在一致的（正确的）状态，并保证并发事务的执行不发生冲突。
文件管理器（file manager）：管理磁盘存储空间的分配，管理用于表示磁盘上所存储信息的数据结构。
缓冲区管理器（buffer manager）：负责将数据从磁盘上取到内存中，并决定哪些数据应被缓冲存储在内存中。缓冲区管理器是数据库系统的一个关键部分，因为它使数据库可以处理比内存大得多的数据。

作为系统物理实现的一部分，存储管理器实现了以下几种数据结构：

数据文件（data file）：存储数据库自身。
数据字典（data dictionary）：存储关于数据库结构的元数据，特别是数据库模式。
索引（index）：提供对数据项的快速访问。

查询处理器¶

查询处理器组件包括：

DDL 解释器（DDL interpreter）：解释 DDL 语句并将这些定义记录在数据字典中。
DML 编译器（DML compiler）：将查询语言中的 DML 语句翻译为包括一系列查询执行引擎能理解的低级指令的执行方案。DML 编译器还进行查询优化（query optimization），即从几个候选执行计划中选出代价最小的那个执行计划。
查询执行引擎（query evaluation engine）：执行由 DML 编译器产生的低级指令。

事务管理¶

事务（transaction）是数据库应用中完成单一逻辑功能的操作集合。每一个事务是一个既具原子性又具一致性的单元。因此，我们要求事务不违反任何的数据库一致性约束，也就是说，如果事务启动时数据库是一致的，那么当这个事务成功结束时数据库也应该是一致的。然而，在事务执行过程中，有可能需要允许暂时的不一致，这种暂时的不一致虽然是必需的，但在故障发生时，很可能导致问题的产生。

程序员应适当地定义各个事务，使之能保持数据库的一致性。例如，资金从账户 A 转到账户 B 这个事务有可能被定义为由两个单独的程序组成：一个对账户 A 执行取出操作，另一个对账户 B 执行存入操作。这两个程序的依次执行可以保持一致性。但是，这两个程序自身都不是把数据库从一个一致的状态转入一个新的一致的状态，因此它们都不是事务。

原子性和持久性的保证是数据库系统自身的职责，确切地说，是恢复管理器（recovery manager）的职责。在没有故障发生的情况下，所有事务均成功完成，这时要保证原子性很容易。但是，由于各种各样的故障，事务并不总能成功执行完毕。为了保证原子性，失败的事务必须对数据库状态不产生任何影响。因此，数据库必须被恢复到该失败事务开始执行以前的状态。在这种情况下数据库系统必须进行故障恢复（failure recovery），即它必须检测系统故障并将数据库恢复到故障发生以前的状态。

最后，当几个事务并发地对数据库进行更新时，即使每个单独的事务都是正确的，数据的一致性也可能被破坏。并发控制管理器（concurrency-control manager）控制并发事务间的相互影响，保证数据库的一致性。事务管理器（transaction manager）包括并发控制管理器和恢复管理器。

数据库和应用体系结构¶

下图展示了数据库系统的各个部分以及它们之间的联系。

上图所示的集中式体系结构可以应用在共享内存的服务器体系结构中，该结构有多个 CPU 进行并行处理，但所有的 CPU 都访问一个公共的共享内存。为扩展到更大的数据规模和更高的处理速度，研究人员设计了运行在包括多台机器的集群上的并行数据库（parallel database）。更进一步地，分布式数据库（distributed database）允许跨地域地对多台分离的机器进行数据存储和查询处理。

现在考虑使用数据库作为其后端的应用系统的体系结构。数据库应用系统通常可分为两个或三个部分，如下图所示。

较早一代的数据库应用系统采用两层体系结构（two-tier architecture），其中应用程序驻留在客户机上，通过查询语言语句来调用服务器上的数据库系统功能。

当今的数据库应用系统采用三层体系结构（three-tier architecture），客户机仅作为一个前端，它并不包含任何直接的数据库调用。前端与应用服务器（application server）进行通信。应用服务器与数据库系统进行通信以访问数据。应用程序的业务逻辑（business logic）被嵌入应用服务器中，而不是分布在多个客户机上。与两层的应用系统相比，三层结构的应用提供了更好的安全性和更高的性能。

数据库用户和管理员¶

数据库用户可分为四种不同类型，系统为不同类型的用户设计了不同类型的用户界面：

初学者用户（naive user）
应用程序员（application programmer）
老练用户（sophisticated user）
数据库管理员（DataBase Administrator，DBA）其主要作用包括：
- 模式定义（schema definition）
- 存储结构及存取方法定义（storage structure and access-method definition）
- 模式及物理组织的修改（schema and physical-organization modification）
- 数据访问授权（granting of authorization for data access）
- 日常维护（routine maintenance）