第一章 - 引言

约 4351 个字 预计阅读时间 15 分钟

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

数据库系统应用

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

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

当今的数据库系统充分利用数据结构中的公共特征以获取高效性，同时也允许弱结构化的数据和格式非常易变的数据。其结果是，数据库系统是一个大型的复杂的软件系统，它的任务是管理大型的复杂的数据集合。

对复杂性进行管理很具挑战性，这种挑战不仅存在于数据管理中，也存在于任何领域中。对复杂性进行管理的关键是抽象 (abstraction) 这个概念。

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

• 联机事务处理 (online transaction processing)：即大量的用户使用数据库，每个用户检索相对少量的数据，进行小的更新。这是数据库应用系统的绝大多数用户的主要使用方式。
• 数据分析 (data analytics)：即审阅数据，给出结论，并推导出规则或决策程序，以用于驱动业务决策。

数据挖掘 (data mining) 领域将人工智能研究者和统计分析员所创造的知识发现技术与使之能用于超大规模数据库的高效的实现技术结合起来。

数据库系统的目标

一类典型的文件处理系统 (file-processing system) 是由传统的操作系统所支持的。系统将永久记录存储在多个不同的文件中，需要有不同的应用程序来将记录从有关文件中取出或加入适当的文件中。

在文件处理系统中存储组织机构的信息的主要弊端包括以下方面：

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

这些问题促使了数据库系统的发展。

数据视图

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

数据模型

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

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

• 关系模型 (relational model)：关系模型用表的集合来表示数据和数据间的联系，表也称作关系 (relations)。关系模型是基于记录的模型的一种。
• 实体-联系模型 (entity-relationship model)：实体-联系数据模型使用称作实体 (entity) 的基本对象的集合，以及这些对象间的联系 (relationships)。
• 半结构化数据模型 (semi-structures data model)：半结构化数据模型允许在其数据定义中某些相同类型的数据项含有不同的属性集。JSON 和可扩展标记语言 (eXtensible Markup Language, XML) 被广泛地用来表示半结构化数据。
• 基于对象的数据模型 (object-based data model)：面向对象的程序设计已经成为占主导地位的软件开发方法。对应的，产生了把对象存放到关系表中的规范。过程可以被存放在数据库系统中，并由数据库系统来执行它们。这可以看作是对关系模型的扩展，增加了封装、方法和对象标识等概念。

数据抽象

一个可用的系统必须能高效地检索数据。这种对高效性的需求促使数据库系统开发人员在数据库中使用复杂的数据结构来表示数据。系统开发人员通过如下几个层次的数据抽象 (data abstraction) 来对用户屏蔽复杂性，以简化用户与系统的交互：

• 物理层 (physical level)：最低层次的抽象，描述数据实际上是怎样存储的。物理层详细描述复杂的底层数据结构。
• 逻辑层 (logical level)：比物理层层次稍高的抽象，描述数据库中存储什么数据以及这些数据间存在什么联系。逻辑层的简单结构实现可能涉及复杂的物理层结构，但逻辑层用户不必面对这样的复杂性，这种性质称作物理数据独立性 (physical data independence)。
• 视图层 (viel level)：最高层次的抽象，它只描述整个数据库的某个部分。这一层次的存在是为了使用户与系统的交互更简单。

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

实例和模式

特定时刻存储在数据库中的信息的集合称作数据库的一个实例 (instance)，而数据库的总体设计称作数据库模式 (schema)。

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

• 物理模式 (physical schema)：在物理层描述数据库的设计。
• 逻辑模式 (logical schema)：在逻辑层描述数据库的设计。
• 子模式 (subschema)：数据库在视图层的多种模式，其描述了数据库的不同视图。

由于程序员使用逻辑模式来构造数据库应用程序，故逻辑模式是最重要的一种模式。

数据库语言

数据库系统提供数据定义语言 (Data-Definition Language, DDL) 来定义数据库模式，并提供数据操纵语言 (Data-Manipulation Language, DML) 来表达数据库的查询和更新。在实践中，这两种语言并不是两种互相分离的语言，而是构成单一数据库语言的不同部分。

数据定义语言

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

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

存储在数据库中的数据值必须满足某些一致性约束。DDL 语言提供了指明这些约束的工具。每当数据库被更新时，数据库系统都会检查这些约束。通常，约束可以是关于数据库的任意谓词。然而如果要测试任意谓词，可能代价比较高。因此数据库系统仅实现可以以最小代价测试的完整性约束。我们讨论其中几类：

• 域约束 (domain constraint)：每个属性都必须对应于一个所有可能的取至构成的域。声明一个属性属于某个具体的域就相当于约束它可以取的值。域约束是完整性约束的最基本形式，每当有新数据项差异、入数据库中，系统就能方便地进行域约束检测。
• 引用完整性 (referential integrity)：常常有这样的情况，我们希望能确保一个关系中给定属性集上的取值也在另一关系的某一属性集的取值中出现。数据库的修改有可能会导致引用完整性的破坏，故要对此加以检测。
• 授权 (authorization)：在很多数据库中，我们需要对用户加以区别，对于不同的用户在数据库中的不同数据值上允许不同的访问类型。这种区别即以授权来表达，常见的有：
  • 读权限 (read authorization)：允许读取数据，但不能修改数据；
  • 插入权限 (insert authorization)：允许插入新数据，但不允许修改已有数据；
  • 更新权限 (update authorization)：允许修改，但不能删除数据；
  • 删除权限 (delete authorization)：允许删除数据。

对 DDL 语句的处理会产生一些输出。DDL 的输出放在数据字典 (data dictionary) 中，数据字典包含元数据 (metadata)，元数据是关于数据的数据。

数据操纵语言

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

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

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

• 过程化的 DML (procedual DML)：要求用户指定需要什么数据以及如何获得这些数据。
• 声明式的 DML (declarative DML)：也称非过程化的 DML，只要求用户指定需要什么数据，而不必指明如何获得这些数据。

声明式的 DML 通常比过程化的 DML 易学易用，但这也将给出高效访问数据的途径这一任务交给了数据库系统。

查询 (query) 是要求对信息进行检索的语句，DML 中设计信息检索的部分称作查询语言 (query language)。

从应用程序访问数据库

像 SQL 这样的非过程化查询语言不像普适的图灵机那么强大，这意味着有一些计算可以用更通用的程序设计语言来表达，但无法用 SQL 来表达。SQL 也不支持诸如从用户或取输入、输出到显示器或在网络上通信这样的动作。这样的计算和动作必须要一种宿主 (host) 语言来写（如 C、Java 或 Python），并在其中使用嵌入式的 SQL 查询来访问数据库中的数据。

应用程序 (application program) 就是用来以这种方式与数据库进行交互的程序。

为了访问数据库，需要将 DML 语句从宿主发送到执行这些语句的数据库。最通用的办法是使用应用程序接口来完成这一过程。

数据库设计

数据库设计的主要内容是数据库模式的设计。我们着重讨论数据库查询的编写和数据库模式的设计。

高层的数据模型为数据库设计者提供了一个概念框架，来说明数据库用户的数据需求，以及将怎样构造数据库结构以满足这些需求。因此，数据库设计的初始阶段是全面刻画预期的数据库用户的数据需求。

下一步，设计者选择一个数据模型，并运用该选定的数据模型的概念，将那些需求转换成一个数据库的概念模式。在这个概念设计 (conceptual-design) 阶段开发出来的模式提供了用户的详细综述。这一阶段的重点是描述数据以及它们之间的联系，而不是指定物理的存储细节。

从关系模型的角度来说，概念设计接管涉及决定数据库中应该包括哪些属性，以及如何组织这些属性到各个表中。本课程主要关注后一部分问题，这将在之后的章节中讨论。

一个开发完全的概念模式还将指出用户的功能需求。在功能需求说明 (specification of functional requirement) 中，用户描述将在数据之上执行的各种操作。这同样是概念设计阶段所需要考虑的。

最后，我们进入逻辑设计阶段 (logical-design phrase) 和物理设计阶段 (physical-design phrase)，即设计数据库系统具体的数据模型和物理实现。

数据库引擎

数据库系统被划分为多个模块，每个模块完成整个系统的一个功能。这些功能部件大致可以分为三类：

• 存储管理器
• 查询处理器部件
• 事务管理部件

存储管理器

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

存储管理器部件包括：

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

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

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

查询处理器

查询处理器 (query processor) 组件包括：

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

事务管理

事务 (transaction) 是数据库应用那种完成单一逻辑功能的操作集合。每一个事务时一个既具有原子性又具有一致性的单元。因此，我们要求事务不违反任何数据库一致性约束。

原子性和持久性的保证是数据库系统自身的职责，这由恢复管理器 (recovery manager) 保证。当事务由于某些原因失败时，数据库系统必须进行故障恢复 (failure recovery)，即检测系统故障并将数据库恢复到故障发生之前的状态。

最后，我们还需要并发控制管理器 (concurrency-control manager) 控制并发事务间的相互影响，以保证数据库的一致性。事务管理器 (transaction manager) 包括并发控制管理器和恢复管理器。

数据库和应用体系结构

下图是一个数据库系统体系结构的完整图例：

这种集中式体系结构可以应用在共享内存的服务器体系结构中。进一步地，研究人员也设计了运行在包括多台机器的集群上的并行数据库 (parallel database)，以及允许跨地域地对多台分离的机器进行数据存储和查询处理的分布式数据库 (distributed database)。

接下来讨论使用数据库作为其后端的应用系统的体系结构。数据库应用系统通常可分为两个或三个部分，即较早一代的两层体系结构 (two-tier architecture) 和当今常用的三层体系结构 (three-tier architecture)，如下图：

在三层体系结构中，客户机仅作为一个前端而不包含任何直接的数据库调用，其与应用服务器 (application server) 进行通信，由应用服务器和数据库系统之间通信以访问数据。这有利于更好地实现应用程序的业务逻辑 (business logic)。

数据库用户和管理员

我们一般将与数据库交互的用户按如下分类：

• 数据库用户 (database user)：
  • 初学者用户 (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)