数据库管理系统

数据库管理系统（Database Management System, DBMS）是现代信息技术体系中的关键基础设施。 DBMS由结构化的数据集合（即数据库）及其相关的管理、访问和维护程序组成，旨在实现对大量数据的高效、可靠、统一管理。 数据库通常存储与企业、组织或应用领域密切相关的核心信息资源。DBMS的核心目标在于为用户和应用程序提供数据的高效存储、检索、更新与安全控制机制，确保数据的一致性、完整性和可用性。

在当今信息化社会，数据库系统已广泛渗透于各行各业的关键业务流程。 无论是电子商务中的订单处理、银行系统中的账户管理，还是社交媒体平台的信息发布与检索，数据库管理系统均作为底层支撑平台，保障数据的高效流转与安全存储， 推动着现代服务与应用的持续发展。

数据库系统在现代社会中具有极其广泛的应用，已成为各行各业信息化建设的核心支撑平台：

数据库系统的发展演进

数据库系统的发展经历了深刻的技术演进。自20世纪中叶以来，数据库技术在企业信息化进程中实现了快速普及和广泛应用。早期阶段，数据库系统主要作为后台基础设施存在，终端用户通常通过中介（如银行柜员、航空公司订票代理、批量报表等）间接访问数据库，用户与数据库之间存在明显隔离。

随着自动取款机（ATM）的普及，数据库系统首次实现了面向终端用户的直接交互，极大提升了数据服务的实时性和可用性。紧接着，电话语音交互系统（IVR）等技术的应用，使用户能够通过电话终端输入指令，实时查询数据库中的航班信息、课程注册等数据，进一步拓展了数据库的服务边界。

进入20世纪90年代末，互联网技术的兴起彻底变革了数据库的访问模式。Web应用的普及使得用户能够通过浏览器等前端界面直接与数据库交互，极大提升了数据库访问的频率和复杂性。大量传统的电话和线下服务被Web界面所取代，企业和机构通过在线系统为用户提供商品检索、订单处理、账户查询等多样化服务。此时，数据库系统已成为支撑大规模在线业务和实时数据处理的核心平台，用户的每一次在线操作（如下单、账户查询、信息检索等）都直接依赖于数据库系统的高效支撑。

如今像Oracle这样的数据库系统供应商已经成为世界上最大的软件公司之一， 而数据库系统也构成了微软和IBM产品线的重要组成部分。这充分说明了数据库技术在现代信息技术产业中的核心地位。

为什么需要数据库系统

数据库系统的产生，源于对早期计算机化商业数据管理方式在效率、可靠性与可扩展性等方面的深层改进需求。 为深入理解数据库系统的技术优势，我们以一个典型案例剖析传统文件处理系统在数据管理过程中所暴露的结构性缺陷。

传统文件处理系统的局限性

想象一个大学的信息管理场景，需要保存教师、学生、院系和课程等各种信息。在数据库系统出现之前，一种常见的做法是将这些信息存储在操作系统的文件中。为了让用户能够操作这些信息，系统需要许多应用程序来处理文件，比如添加新学生、教师和课程的程序，为学生注册课程并生成班级花名册的程序，以及为学生分配成绩、计算平均学分绩点并生成成绩单的程序。

随着需求的变化，系统会不断添加新的应用程序。例如，当大学决定创建一个新的专业（比如计算机科学）时，就需要创建新的院系，建立新的永久文件来记录该院系所有教师、该专业学生、课程设置、学位要求等信息。同时还可能需要编写新的应用程序来处理这个新专业特有的规则。

这种传统的文件处理系统虽然能够工作，但存在许多严重的缺陷。

文件处理系统的主要问题

数据冗余和不一致

由于不同开发人员在较长时间内各自独立创建文件和相关应用程序，导致文件结构不统一，应用程序实现方式也多种多样。 更常见的是，信息冗余现象普遍存在，即同一数据项会被重复存储在多个文件中。例如，在一个医院的信息系统中，病人的基本信息（如姓名、联系方式）可能既存储在门诊挂号文件中，也存储在住院管理文件中。

这种冗余不仅增加了存储和维护的负担，还容易导致数据不一致的问题。也就是说，同一数据项的多个副本如果没有被同时更新，就会出现不一致的情况。 比如，病人更换了联系方式后，门诊挂号文件中的信息已被更新，而住院管理文件中的信息却未同步修改，最终导致系统中存在不一致的病人联系方式记录。

访问数据困难

假设一家医院的管理人员需要查找所有在过去一个月内接受过某项特定检查的病人联系方式。由于最初的系统设计者并未考虑到这种查询需求， 因此没有现成的应用程序可以直接完成。管理人员只能选择：要么导出所有病人的检查记录并手动筛选出目标病人，再逐一查找联系方式；要么请求程序员专门开发一个新的程序来实现该查询。这两种方式都既低效又容易出错。

传统的文件处理系统难以灵活、高效地满足这类临时和复杂的数据检索需求，因此需要更强大、更灵活的数据管理工具。

数据隔离

比如在一个银行系统中，客户的账户信息、交易记录和贷款资料分别存储在不同的文件中，而且每个文件的格式还不一样。 如果要开发一个新程序来查询某个客户的所有相关信息，就需要分别处理这些异构文件，整合数据变得非常复杂和困难。

完整性问题

存储在数据库中的数据值必须满足某些类型的一致性约束。例如，大学为每个院系维护一个账户，并记录每个账户的余额金额。 大学还要求院系账户余额永远不能低于零。开发人员通过在各种应用程序中添加适当的代码来强制执行这些约束。 然而，当添加新约束时，很难更改程序来强制执行它们。当约束涉及不同文件中的多个数据项时，问题变得更加复杂。

原子性问题

计算机系统和其他设备一样，难免会发生故障。在许多应用场景下，发生故障时，数据必须能够恢复到故障前的一致状态，这一点非常重要。以网上购物为例，假设用户在下单购买商品时，系统需要同时减少商品库存并生成订单记录。如果在这两个操作之间系统突然崩溃，可能会出现库存已经减少但订单没有生成，或者订单生成了但库存没有减少，导致数据出现不一致。

因此，为了保证数据库的一致性，必须确保这类操作要么全部完成，要么全部不做，这就是“原子性”的要求——要么完整地执行所有相关操作，要么在发生故障时全部撤销。在传统的文件处理系统中，实现这种原子性非常困难。

并发访问异常

为了提高系统的整体性能和更快的响应，许多系统允许多个用户同时更新数据。在这种环境中，并发更新的交互是可能的，并且可能导致数据不一致。

以网上商店为例，假设某商品库存为10件。如果有两位顾客几乎同时下单购买该商品，一位购买7件，另一位购买5件。 由于并发操作，两个下单程序都读取到库存为10，并分别判断库存充足后各自完成扣减操作。 如果没有妥善的并发控制，最终库存可能被更新为3件（10-7）或5件（10-5），而不是正确的-2件（10-7-5），甚至出现超卖的情况。 这种并发写入导致的数据不一致问题在传统文件处理系统中很难避免。

安全问题

数据库系统的每个用户都不应该能够访问所有数据。例如，在医院中，医生只需要访问与自己患者相关的病历信息，而不需要查看医院所有病人的详细资料。 相反，药房工作人员可能只需要获取药品库存和发药记录，而无需访问病人的诊断信息。 但是，在传统的文件处理系统中，由于应用程序是临时添加的，很难对不同用户实施细致的数据访问控制，从而难以保障数据安全。

这种种困难促使了数据库系统的发展。数据库系统通过提供统一的数据管理方法，解决了文件处理系统的这些问题。

数据的抽象视图

数据库系统的核心目标之一是为用户提供对数据的抽象视图，即通过屏蔽底层数据存储与管理的实现细节，使用户能够以更高层次、更直观的方式访问和操作数据。 为满足高效数据检索与管理的需求，数据库系统在内部采用了复杂的数据结构和优化机制，以提升系统性能和资源利用率。

鉴于数据库系统的最终用户往往缺乏深入的计算机专业背景，系统设计者通过引入多层次的数据抽象，将底层实现的复杂性封装在不同的抽象层次之下， 从而简化用户与数据库系统的交互过程，提升系统的易用性和可维护性。

数据抽象的三个层次

实例和模式

数据库中的数据内容会随着信息的插入、删除和更新而动态变化。在某一特定时刻，数据库中所有数据的集合被称为数据库的“实例”（instance）。 而数据库的总体结构和组织方式，即对数据类型、结构、约束及其相互关系的完整描述，被称为数据库的“模式”（schema）。

可以将数据库的模式与实例的关系类比为程序设计中的类型定义与变量值：数据库模式相当于程序中的变量声明及其类型定义， 规定了数据的结构和约束；而数据库实例则对应于在某一时刻各变量实际存储的具体值。模式在数据库生命周期内通常保持相对稳定，而实例则随着数据操作不断变化。

在这些模式中，逻辑模式是最重要的，因为它对应用程序的影响最大，程序员使用逻辑模式构建应用程序。物理模式隐藏在逻辑模式之下，通常可以轻松更改而不影响应用程序。如果应用程序不依赖物理模式，因此在物理模式更改时不需要重写，则应用程序据说表现出物理数据独立性。

数据模型

数据库结构的基础是数据模型：用于描述数据、数据关系、数据语义和一致性约束的概念工具集合。数据模型提供了一种在物理、逻辑和视图级别描述数据库设计的方法。 现代数据模型可以分为四个不同的类别：

关系模型

关系模型（Relational Model）通过一组称为“关系”（Relation，即表）的二维表结构来组织和表示数据及其相互关系。每个关系由若干元组（Tuple，即行）组成，元组由一组属性（Attribute，即列）定义，每个属性在同一关系中具有唯一的名称。关系模型属于基于记录（Record-based）的数据模型，其核心思想是将数据以结构化、规范化的方式存储于关系表中，表的每一行对应一个实体实例，表的每一列对应实体的某一属性。关系模型强调数据的逻辑独立性，通过关系代数和关系演算等形式化方法支持数据的查询与操作。

关系数据模型因其高度的数据抽象能力、良好的数据独立性、强大的查询表达能力以及严格的完整性约束支持，成为目前应用最为广泛的数据模型。绝大多数现代数据库管理系统（DBMS）均以关系模型为基础实现。

实体关系模型

实体-关系（E-R）数据模型以实体（Entity）及其相互关系（Relationship）为基本建模单元。实体是客观存在且可被唯一标识的对象或事物，具有一组属性。实体之间通过关系联系，反映现实世界中对象间的关联。 E-R模型以形式化、结构化的方式描述数据及其语义，是数据库概念结构设计的核心工具，广泛应用于数据库建模与需求分析阶段。

面向对象数据模型 —— OODM

面向对象数据模型（Object-Oriented Data Model, OODM）是在面向对象程序设计思想基础上发展而来的高级数据建模方法。 该模型以对象为基本单位，支持数据的封装、继承、多态等特性，并通过对象标识（OID）实现对象的唯一性和可引用性。 面向对象数据模型能够自然地表示复杂数据结构和行为，适用于对复杂对象、嵌套结构及丰富语义有较高要求的应用场景。

对象-关系数据模型（Object-Relational Data Model, ORDM）则融合了面向对象模型与关系模型的优点，既支持关系模型的结构化查询和数据完整性，又引入了对象模型的复杂数据类型和方法扩展，增强了数据库系统对多样化数据的支持能力。

半结构化数据模型（Semi-structured Data Model）是一种灵活的数据建模方法，允许同一类型的数据项具有不同的属性集合，即数据的结构可以部分自描述且不完全固定。 这与传统的结构化数据模型（如关系模型、面向对象模型等）形成鲜明对比，后者要求同类型数据项必须具备一致的属性集合。 半结构化数据模型能够有效支持异构、动态变化的数据结构，适用于描述结构不规则或频繁演化的数据。 可扩展标记语言（XML）是半结构化数据的典型表示和交换标准，广泛应用于互联网数据集成与传输等场景。

数据库语言

数据库管理系统（DBMS）为用户提供了两类核心语言工具：数据定义语言（Data Definition Language, DDL）用于精确定义和管理数据库的模式结构， 包括表、视图、索引及其约束等；数据操作语言（Data Manipulation Language, DML）则用于实现对数据库中数据的查询、插入、 删除和更新等操作。在实际应用中，DDL与DML通常集成于统一的数据库语言体系中，例如结构化查询语言（SQL），以支持数据库的完整生命周期管理和高效数据操作。

数据操作语言

数据操作语言（DML）是一种使用户能够访问或操作由适当数据模型组织的数据的语言。数据操作语言提供的访问类型包括从数据库中检索信息、向数据库中插入新信息、从数据库中删除信息以及修改数据库中存储的信息。

根据用户指定数据需求方式的不同，数据操作语言可以分为两种基本类型：

过程式数据操作语言

过程式DML要求用户指定需要什么数据以及如何获取这些数据。在这种方式下，用户必须详细描述数据检索的步骤和过程，就像编程时需要指定算法的具体步骤一样。

非过程式数据操作语言

非过程式DML（也称为声明式DML）只要求用户指定需要什么数据，而不必指定如何获取这些数据。这种方式下，用户只需要描述期望的结果，而数据库系统负责找出高效的数据访问方法。

查询（Query）是用于从数据库中检索所需信息的语句。数据操作语言（DML）中专门用于信息检索的部分被称为查询语言（Query Language）。尽管严格意义上“查询语言”与“数据操作语言”并非完全等同，但在实际应用和文献中，这两个术语常常交替使用。目前，业界和学术界存在多种数据库查询语言，最具代表性和广泛应用的是结构化查询语言（SQL）。

数据抽象层次（Data Abstraction Levels）的思想不仅体现在数据的定义与建模阶段，同样贯穿于数据操作与查询过程中。在物理层（Physical Level），需要设计和实现高效的数据访问算法与存储结构，以优化数据检索性能；在更高的抽象层次（如逻辑层和视图层），则更侧重于操作的表达能力和用户的易用性，屏蔽底层实现细节，提升人机交互效率。数据库系统中的查询处理器（Query Processor）负责将高级DML查询语句解析、优化，并最终转化为底层物理操作序列，实现从用户需求到物理数据访问的映射与执行。

数据定义语言

我们通过使用称为数据定义语言（DDL）的特殊语言表达的一组定义来指定数据库模式。DDL还用于指定数据的其他属性。我们通过在称为数据存储和定义语言的特殊类型DDL中的一组语句来指定数据库系统使用的存储结构和访问方法。这些语句定义了数据库模式的实现细节，这些细节通常对用户隐藏。

存储在数据库中的数据值必须满足某些一致性约束。DDL提供了指定这些约束的功能。数据库系统在每次更新数据库时都会检查这些约束。一般来说，约束可以是与数据库相关的任意谓词。然而，任意谓词的测试可能代价高昂。因此，数据库系统实现了可以用最小开销测试的完整性约束：

域约束

每个属性都必须关联一个可能值的域（例如整数类型、字符类型、日期时间类型）。将属性声明为特定域的行为充当了对其可以取的值的约束。域约束是完整性约束的最基本形式。每当将新数据项输入数据库时，系统都会轻松测试它们。

参照完整性

在某些情况下，我们希望确保一个关系中给定属性集出现的值也出现在另一个关系中某组属性中（参照完整性）。例如，每门课程列出的院系必须是实际存在的院系。更准确地说，课程记录中的院系名称值必须出现在院系关系的某条记录的院系名称属性中。数据库修改可能导致参照完整性违反。当违反参照完整性约束时，正常的程序是拒绝导致违反的动作。

断言

断言是数据库必须始终满足的任何条件。域约束和参照完整性约束是断言的特殊形式。然而，有许多约束我们无法仅使用这些特殊形式来表达。例如，"每个院系每学期必须至少提供五门课程"必须表达为断言。创建断言时，系统会测试其有效性。如果断言有效，则只有在不会导致该断言被违反的情况下，才允许对数据库的任何未来修改。

授权

我们可能希望在用户对数据库中各种数据值的访问类型方面进行区分。这些区别用授权来表达，最常见的是读授权（允许读取但不修改数据）、插入授权（允许插入新数据但不修改现有数据）、更新授权（允许修改但不删除数据）和删除授权（允许删除数据）。我们可以为用户分配所有、无或这些授权类型的组合。

DDL的输出放在数据字典中，数据字典包含元数据——即关于数据的数据。数据字典被认为是一种特殊类型的表，只能由数据库系统本身（不是普通用户）访问和更新。数据库系统在读取或修改实际数据之前会查询数据字典。

关系数据库

关系数据库（Relational Database）以关系模型为理论基础，通过一组关系（即二维表）来组织和表示数据及其相互之间的联系。 关系数据库系统不仅支持数据操作语言（DML）和数据定义语言（DDL），还实现了完整的事务管理和并发控制机制。 关系模型以其高度的数据独立性和良好的数学基础成为主流数据库模型。

当前，绝大多数商用关系数据库管理系统（RDBMS）均采用结构化查询语言（SQL）作为标准的数据定义与操作语言。

表的概念和结构

关系数据库中的每个表都有多列，每列都有唯一的名称。让我们通过一个具体的例子来理解关系数据库的基本概念。 考虑一个电商平台的简化数据库，包含两个表：一个显示商品的详细信息，另一个显示各个供应商的详细信息。

商品表 (PRODUCT)：

供应商表 (SUPPLIER)：

我们看到这两个表的数据示例，可以很容易地看出它们之间的关系。 现实世界的电商平台会有更多的商品和供应商。我们在文本中使用小表来说明概念。

关系模型是基于记录的模型的一个例子。基于记录的模型之所以这样命名，是因为数据库由几种类型的固定格式记录构成。 每个表包含特定类型的记录。每种记录类型定义了固定数量的字段或属性。表的列对应于记录类型的属性。

数据操作语言在关系数据库中的应用

SQL查询语言是非过程式的。查询以多个表（可能只有一个）作为输入，并始终返回单个表。以下是一个SQL查询示例，用于查找苹果公司所有商品的名称：

|
SELECT product.product_name
FROM product
WHERE product.supplier_name = 'Apple Inc.';

这个查询指定必须检索供应商名称为“Apple Inc.”的商品表中的那些行，并且必须显示这些行的商品名称属性。 更具体地说，执行此查询的结果是一个带有标记为商品名称的单列的表，以及一组行，每行包含供应商为苹果公司的商品名称。

查询可能涉及来自多个表的信息。例如，以下查询查找与信用评级超过9.0的供应商相关的所有商品的商品ID和供应商名称：

|
SELECT product.product_id, supplier.supplier_name
FROM product, supplier
WHERE product.supplier_name = supplier.supplier_name AND
      supplier.credit_rating > 9.0;

这个查询展示了关系数据库如何处理多表连接操作，通过共同的属性（供应商名称）将商品表和供应商表连接起来，然后筛选出信用评级超过9.0的供应商及其相关商品。

数据定义语言在关系数据库中的应用

SQL（结构化查询语言）提供了功能强大的数据定义语言（DDL），使我们能够详细地定义数据库的结构，包括表的创建、字段的数据类型、主键和外键等完整性约束、 唯一性约束、检查条件、默认值以及断言等。通过DDL，数据库管理员和开发者不仅可以创建和修改表结构，还能确保数据的有效性和一致性。 例如，下面的SQL DDL语句详细定义了一个供应商（supplier）表，指定了每个字段的名称和数据类型：

|
CREATE TABLE supplier (
    supplier_name CHAR(50),
    contact_email VARCHAR(100),
    location CHAR(50),
    credit_rating NUMERIC(3,1)
);

执行上述DDL语句会创建具有四列的供应商表：supplier_name、contact_email、location和credit_rating，每列都有与其相关联的特定数据类型。 此外，DDL语句更新数据字典，其中包含元数据。表的模式是元数据的一个例子。

应用程序访问数据库

SQL的功能并不像通用图灵机那样强大；也就是说，有些计算可以使用通用编程语言进行，但无法仅使用SQL进行。SQL也不支持诸如用户输入、显示输出或网络通信等操作。这些计算和操作必须用主机语言（如C、C++或Java）编写，其中嵌入了访问数据库中数据的SQL查询。以这种方式用于与数据库交互的程序称为应用程序。

在电商平台中的例子包括允许顾客浏览商品、管理订单、计算购物车总价、生成发货单等的程序。要访问数据库，需要从主机语言执行DML语句。有两种方法可以做到这一点：

应用程序接口方法

应用程序接口（API）方法通过提供一组标准化的程序接口，使主机语言能够向数据库发送DML和DDL语句并高效地检索结果。在C语言环境中，开放数据库连接（ODBC）标准被广泛采用，作为跨平台的数据库访问接口；而在Java环境中，Java数据库连接（JDBC）标准则为开发者提供了结构化且高效的数据库访问能力。这些接口标准化了数据库操作流程，提升了应用系统的可移植性和可维护性。

|
# JDBC连接示例
Connection conn = DriverManager.getConnection(
    "jdbc:mysql://localhost:3306/ecommerce",
    "username",
    "password"
);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM product");

嵌入式SQL方法

嵌入式SQL方法通过在主机语言（如C、C++或Java）源代码中直接嵌入SQL DML语句实现。通常，这些SQL语句以特定前缀（如EXEC SQL）标识，便于DML预编译器（precompiler）在编译前扫描源代码，将嵌入的SQL语句转换为等效的主机语言API调用或过程调用。预编译器还负责处理主机变量与SQL语句之间的数据类型映射，实现主机程序与数据库系统的高效集成。

数据库设计

数据库系统的设计旨在高效管理和组织大规模数据，这些数据作为企业运营的核心资产，与业务流程紧密耦合，无论数据库本身是信息产品的直接来源，还是作为支撑企业服务和设备的基础设施。

数据库设计的核心任务是数据库模式（schema）的规范化与优化。为了构建能够全面满足企业业务需求的数据库应用环境，设计者不仅要关注数据模型和查询语言的实现，还需综合考虑数据一致性、完整性约束、访问控制、性能优化、可扩展性及系统集成等多方面因素。尽管本章主要聚焦于数据库查询的编写与模式设计，但在实际应用开发中，数据库设计还涉及需求分析、业务流程建模、数据安全与合规性等更为广泛和系统性的问题。

数据库设计过程

高级数据模型为数据库设计者提供了系统化的概念框架，用于形式化地捕获和表达数据库用户的业务数据需求，以及指导数据库结构的构建以满足这些需求。数据库设计的首要阶段是对潜在用户的数据需求进行全面、系统的调研与分析。此过程通常要求数据库设计人员与领域专家、业务用户密切协作，采用访谈、问卷、业务流程建模等多种方法，最终形成结构化、可验证的用户需求规范文档。

在完成需求分析后，设计者需基于业务特性选择合适的数据模型（如关系模型、面向对象模型等），并将用户需求系统性地映射为数据库的概念模式（schema）。概念设计阶段的产出是对企业信息结构的抽象与完整描述，通常以E-R图等形式表达。设计人员需对概念模式进行一致性、完整性和冗余性审查，确保其能够无歧义地覆盖所有业务需求，并消除潜在的数据冗余和结构冲突。此阶段关注的核心是数据实体、属性及其相互关系的建模，而非底层物理实现细节。

在关系模型的概念设计阶段，设计者需系统性地确定需要在数据库中建模的业务实体及其属性，并据此合理划分属性集合以构建关系（表）。其中，“捕获哪些信息”主要依赖于对业务需求的深入分析与抽象建模，而“如何组织这些信息”则属于数据库理论与实现的范畴。针对这一过程，通常有两种主流方法：一是采用实体-关系（E-R）模型，通过实体、属性及其关系的形式化描述，建立清晰的概念结构；二是运用规范化理论，将所有属性集合作为输入，通过一系列规范化算法系统地分解为满足特定范式要求的关系集合，从而优化数据结构，消除冗余并确保数据一致性。

把抽象的数据模型变成真正能用的数据库，要经过最后两个设计阶段。首先是逻辑设计，这一步就是把前面画好的“蓝图”翻译成具体数据库系统能理解的结构，比如表、字段这些。接下来是物理设计，这时候要决定数据在电脑里怎么存，比如用什么文件格式、怎么存储、怎么建索引等，让数据库运行得更快、更高效。

数据存储和查询

数据库系统通常采用模块化架构，以分离和高效地管理系统的各项核心职责。其主要功能组件可分为存储管理器（Storage Manager）和查询处理器（Query Processor）两大部分。

存储管理器负责数据库的物理数据管理，解决大规模数据存储与高效访问的问题。企业级数据库的数据量通常从数百GB到TB级别，远超主存储器容量，因此数据需长期存放于磁盘等外部存储介质。存储管理器的设计目标是优化数据在磁盘与主存储器之间的调度与传输，最大限度地减少I/O瓶颈，提高数据访问效率。为此，存储管理器需合理组织数据结构、管理缓冲区，并协调文件系统与数据库的交互。

查询处理器则负责数据库的高层数据访问与操作。其核心任务是将用户以高级非过程化查询语言（如SQL）编写的查询与更新请求，自动转换为底层的高效物理操作序列。查询处理器不仅屏蔽了底层数据存储和实现细节，使用户能够在逻辑视图层面进行数据操作，还需通过查询优化等机制，确保在保证正确性的前提下实现优良的系统性能。

存储管理器

存储管理器是数据库系统的组件，它在数据库中存储的低级数据与提交给系统的应用程序和查询之间提供接口。存储管理器负责与文件管理器的交互。原始数据使用操作系统提供的文件系统存储在磁盘上。存储管理器将各种DML语句转换为低级文件系统命令。因此，存储管理器负责在数据库中存储、检索和更新数据。

存储管理器组件包括：

授权和完整性管理器

负责对数据库中定义的完整性约束进行验证，并严格审查用户对数据的访问权限。该组件通过实施访问控制策略，确保仅有具备相应授权的用户能够进行数据的查询与修改操作，同时持续监控并维护数据的一致性与完整性，防止非法访问和数据违规变更。

事务管理器

事务管理器负责确保数据库在发生系统故障时能够恢复到一致且正确的状态，并通过并发控制机制防止并发事务间的数据冲突。作为数据库系统核心组件之一，事务管理器严格保障事务的原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）（即ACID特性），以实现数据的可靠性与完整性。

文件管理器

负责磁盘存储空间的分配与回收，并管理用于在磁盘上组织和表示数据的数据结构。文件管理器处理数据的物理存储实现细节，包括数据库文件的创建、删除、扩展、收缩及其维护，确保数据在外部存储介质上的高效、可靠存取。

缓冲区管理器

负责从磁盘存储器中获取数据到主存储器中，并决定在主存储器中缓存哪些数据。缓冲区管理器是数据库系统的关键部分，因为它使数据库能够处理比主存储器大小大得多的数据大小。

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

查询处理器

查询处理器是数据库系统中专责解析、优化与执行用户查询的核心模块。其主要功能在于将高级查询语言（如SQL）解析为高效的内部表示，并通过查询优化生成最优的执行计划，最终将其转化为存储管理器能够执行的低级操作序列，实现对数据的高效访问与处理。

查询处理器组件包括：

DDL解释器

负责解析和处理DDL（数据定义语言）语句，并将数据库对象的定义准确记录至数据字典。当新建表、视图或修改现有数据库结构时，DDL解释器需对元数据进行严格维护和更新，确保数据库结构信息的完整性与一致性。

DML编译器

DML编译器负责将高级查询语言中的DML语句解析并转换为由查询评估引擎能够执行的低级操作指令，形成系统内部的评估计划。针对同一查询，DML编译器通常能够生成多种等价的执行计划，并通过查询优化过程，基于代价模型和统计信息，选择预期执行成本最低的最优评估计划，以提升查询性能和系统资源利用率。

查询评估引擎

查询评估引擎负责执行由DML编译器生成的低级操作指令，是数据库系统中实际完成数据访问与操作的核心执行模块。该引擎与存储管理器紧密协作，实现对底层数据的高效检索与更新，确保查询计划能够被准确、高效地执行。

查询优化在数据库系统性能提升中具有决定性作用。针对同一查询，可能存在多种等价的执行策略，其性能差异可能极为显著。查询优化器通过对查询语句进行系统性分析，结合代价模型与统计信息，综合评估各类执行方案，最终选择预期代价最优的执行计划，以最大化系统资源利用率与查询响应效率。

事务管理

在数据库系统中，多个相关操作通常被视为一个不可分割的逻辑工作单元，称为事务。

事务的概念

事务（Transaction）是数据库管理系统中作为一个不可分割的逻辑工作单元执行的一组操作。每个事务必须同时满足原子性和一致性要求，即事务的所有操作要么全部成功完成，要么全部不执行，并且事务的执行不得违反数据库的任何一致性约束。若数据库在事务开始前处于一致状态，则在事务成功提交后也必须保持一致状态。

事务的正确划分和定义是保证数据库一致性的前提。开发人员应确保每个事务能够独立地将数据库从一个一致状态转换到另一个一致状态。例如，将资金从院系A账户转移到院系B账户的操作，必须作为一个完整的事务整体执行，包含借记A账户和贷记B账户两个步骤。若将这两个操作分解为独立的程序分别执行，则无法保证数据库始终处于一致状态，因此这两个独立程序本身不能被视为事务。

ACID属性

数据库事务必须满足四个重要属性，通常用ACID来概括：

原子性（Atomicity）

事务的所有操作要么全部完成，要么全部不执行。不存在部分完成的事务。如果事务在执行过程中发生错误，数据库系统必须撤销事务已经执行的所有操作，将数据库恢复到事务开始前的状态。

一致性（Consistency）

事务必须使数据库从一个一致状态转换到另一个一致状态。事务执行前后，数据库的完整性约束都必须得到满足。

隔离性（Isolation）

并发执行的事务之间必须相互隔离，一个事务的执行不能被其他事务干扰。每个事务都应该感觉到自己是在独立地访问数据库。

持久性（Durability）

一旦事务成功提交，其对数据库的改变就是永久性的，即使系统发生故障也不会丢失。

并发控制

当多个事务同时操作数据库时，即使每个事务本身都是正确的，数据的一致性也可能受到影响。并发控制管理器的任务就是协调这些事务，确保数据库始终保持一致状态。

我们来看一个图书库存的例子：假设图书馆有一本热门新书，库存数量为1。此时有两位读者（事务1和事务2）几乎同时尝试借阅这本书。 如果两个事务都先读取库存数量1，然后各自判断库存充足并准备借出，最后分别将库存数量写回0。由于并发操作，可能会出现两位读者都成功借出同一本书的情况，导致库存出现负数或不准确。

故障恢复

在数据库系统中，事务在执行过程中可能因多种故障（如系统崩溃、介质故障、事务冲突等）而无法顺利完成。为严格保障原子性（Atomicity）属性，任何未成功完成的事务都必须对数据库状态无任何持久性影响。为此，数据库系统需具备完善的故障恢复机制，能够在检测到故障后，将数据库一致性地恢复至故障事务开始之前的状态。

事务管理器（Transaction Manager）通常由并发控制管理器（Concurrency Control Manager）和恢复管理器（Recovery Manager）两大核心组件构成。其中，恢复管理器主要负责实现原子性与持久性（Durability）属性，通过日志、回滚、重做等技术手段保障数据可靠性；并发控制管理器则专注于事务隔离性（Isolation）的实现，防止并发执行带来的数据不一致问题。

数据库系统架构

数据库系统的体系结构在很大程度上取决于其所依托的底层计算机系统资源。根据部署和运行方式的不同，数据库系统可分为集中式架构、客户端-服务器（Client-Server）架构、并行架构以及分布式架构。 集中式数据库系统将所有功能集中在单一主机上；客户端-服务器架构通过专用服务器为多个客户端提供数据库服务，实现计算与数据管理的分离； 并行数据库系统利用多处理器和多存储设备并行处理数据，以提升系统吞吐量和性能；分布式数据库系统则将数据和事务分布在多个地理位置分离的节点上，通过网络协同工作，实现数据的分布式存储与管理。

集中式和客户端-服务器架构

今天，大多数数据库系统用户不在数据库系统的现场，而是通过网络连接到它。因此，我们可以区分运行远程数据库用户的客户端机器和运行数据库系统的服务器机器。

数据库应用程序通常分为两个或三个部分。在两层架构中，应用程序驻留在客户端机器上，它通过查询语言语句调用服务器机器上的数据库系统功能。应用程序接口标准如ODBC和JDBC用于客户端和服务器之间的交互。

相比之下，在三层架构中，客户端机器仅仅作为前端，不包含任何直接的数据库调用。相反，客户端通过表单界面与应用服务器通信。应用服务器又与数据库系统通信以访问数据。应用程序的业务逻辑（即说明在什么条件下执行什么操作）嵌入在应用服务器中，而不是分布在多个客户端上。

三层架构（Three-Tier Architecture）广泛应用于大型企业级系统及基于互联网的分布式应用。该架构通过将表示层、业务逻辑层和数据层进行物理和逻辑分离，具备更多优势：

• 可扩展性强：应用服务器作为中间层能够高效地管理和调度大量并发客户端请求，便于横向扩展系统容量。
• 可维护性高：业务逻辑集中部署于应用服务器，便于统一管理、升级和维护，降低了系统复杂度和运维成本。
• 安全性增强：客户端无法直接访问数据库，所有数据访问均通过受控的应用层进行，有效隔离和保护核心数据资源，提升系统整体安全性。

并行和分布式架构

随着数据规模和并发访问量的持续增长，单一服务器架构在计算能力、存储容量及系统可用性方面逐渐暴露出瓶颈。并行数据库系统通过引入多处理器和多存储设备，实现任务和数据的并行处理，从而显著提升系统吞吐量与响应速度。分布式数据库系统则将数据和计算分布在多个地理位置分散的节点上，通过网络协同工作，以实现高可用性、可扩展性和容错能力，满足大规模分布式应用的需求。

并行数据库系统

并行数据库系统（Parallel Database System）通过引入多处理器（CPU）和多存储设备，实现数据库操作的并行处理，以显著提升系统的吞吐量和响应速度。根据系统资源的共享方式，主流并行架构可分为以下三类：

• 共享内存架构（Shared-Memory Architecture）：所有处理器通过总线或交换网络共享全局内存和磁盘存储。各处理器可直接访问全局数据，适用于中小规模并行系统，但扩展性受限于总线带宽和内存一致性管理的复杂性。
• 共享磁盘架构（Shared-Disk Architecture）：每个处理器拥有独立的本地内存，但所有处理器通过高速互连网络共享磁盘存储。该架构支持节点间的容错和负载均衡，适合高可用性场景，但需解决并发访问磁盘的数据一致性问题。
• 无共享架构（Shared-Nothing Architecture）：每个处理器拥有独立的本地内存和本地磁盘，各节点间通过网络通信。该架构具备极佳的可扩展性和容错能力，是大规模并行数据库系统（如MPP，Massively Parallel Processing）的主流实现方式，但对分布式数据分区和任务调度提出更高要求。

分布式数据库系统

分布式数据库系统（Distributed Database System）将数据分布存储于多个地理位置分散的节点，各节点通过计算机网络互联，协同完成数据的存储、查询与事务处理。分布式数据库的主要优势包括：

• 数据共享与自治：各节点可根据本地需求独立管理数据，同时支持全局数据访问与共享。
• 高可用性与容错性：数据冗余与多副本机制提升了系统的容灾能力，单点故障不会导致全局服务中断。
• 可扩展性与负载均衡：通过增加节点可线性扩展存储与计算能力，支持大规模并发访问。

然而，分布式数据库系统也面临诸多挑战，如分布式事务一致性（CAP理论）、全局数据一致性维护、网络分区容忍、复杂的安全与访问控制、系统管理与运维等。

数据挖掘和信息检索

数据挖掘（Data Mining）是指利用计算机技术对大规模数据库进行半自动化分析，从中提取潜在的、有效的、可理解的、有价值的模式或知识的过程。 与人工智能领域的知识发现（Knowledge Discovery in AI，亦称机器学习）和统计分析类似，数据挖掘关注于从数据中自动发现规律和模式。 但其专业特点在于，数据挖掘主要面向存储于外部存储介质（如磁盘）上的海量数据，强调高效的数据访问、处理与分析能力，实现对“数据库中知识的发现”（Knowledge Discovery in Databases, KDD）。

数据挖掘的基本概念

从数据库中挖掘出的知识类型通常可形式化为规则、模型或函数关系。例如，关联规则（Association Rule）以“如果-那么”形式表达属性间的强相关性，如：“如果某用户在过去三个月内多次购买婴儿用品，那么该用户很可能会购买婴儿奶粉”。此类规则的有效性通过“支持度（Support）”和“置信度（Confidence）”等统计指标进行量化，分别衡量规则在数据集中出现的频率及其条件概率。此外，数据挖掘还可发现描述变量间依赖关系的函数模型（如回归方程）、分类模型（如决策树、神经网络）或预测模型（如基于特征变量对目标变量的预测机制），以支持对未知数据的推断和决策。

数据挖掘可以发现很多不同类型的有用模式，不同的方法适合找不同的模式。在实际操作中，数据挖掘往往不是全自动完成的。比如，通常需要人工先把原始数据整理成算法能用的格式，挖掘出结果后还要人工筛选和分析，挑出真正有价值的新发现。有时候，从同一个数据库里能挖掘出多种不同的模式，人工还需要参与选择哪些模式最有用。因此，数据挖掘在现实中其实是“半自动”的，需要人和计算机配合完成。

数据挖掘的应用领域

现在，企业越来越多地利用网上积累的大量数据来帮助做决策，比如决定要进哪些商品、怎么更好地吸引客户、提升销售额等。很多时候，他们想要查找的信息很复杂，甚至有些内容用普通的SQL语句都查不出来。为了解决这些问题，出现了各种各样的数据分析工具和技术，帮助企业做出更明智的决策。

有些数据分析工具可以让分析师从不同角度、用不同方式查看和分析数据。还有一些工具会提前把大量数据做成汇总，等有人查询时就能很快给出结果。现在的SQL标准里也增加了不少专门用来支持数据分析的新功能。

除了结构化的数据，文本数据（比如网页、邮件、文档等）也在快速增长。这些文本数据不像表格那样有固定格式，叫做“非结构化数据”。查询这类数据的过程叫“信息检索”。信息检索系统和数据库系统有些相似，比如都要把数据存起来、查出来，但信息检索更关注用关键词查找、判断文档和查询的相关性，以及对文档进行分析、分类和建立索引等。

专业数据库系统

有些应用场景对数据的要求比较特殊，传统的关系型数据模型就不太适用了。为了解决这些问题，研究人员开发了新的数据模型，比如面向对象的数据模型和半结构化数据模型。

面向对象数据模型

面向对象编程（OOP）现在很常见，比如Java、C++等。受OOP影响，数据库领域也出现了“面向对象数据模型”。它是在E-R模型的基础上增加了“封装”“方法”“对象标识”等概念。简单来说，就是把数据和操作数据的方法打包在一起，每个对象有自己的标识，还能继承别的对象的特性，这样数据结构更灵活，也更容易表达复杂的关系。

面向对象数据模型还支持更丰富的数据类型，比如可以直接存储结构体、集合等复杂类型。上世纪80年代，已经有一些数据库系统采用了这种模型。

现在，主流数据库厂商都支持“对象-关系数据模型”，它结合了面向对象和关系型的优点。比如，除了传统的表格数据，还能存储结构化和集合类型的数据，甚至可以自定义类型和方法，让数据库更强大、更灵活。

半结构化数据模型

半结构化数据模型的意思是：同一种数据，里面的每一项可以有不一样的属性。比如，有的“学生”数据有“邮箱”，有的没有，这都没关系。这和传统的数据模型不同，传统模型要求每一项都必须有一样的属性。

XML是一种常见的半结构化数据格式。它最早是用来给文档加标记的，后来因为方便不同系统之间传递数据而变得很流行。XML可以很灵活地表示有层次、嵌套的数据结构，非常适合描述那些不规则、变化多的数据。

数据库用户和管理员

数据库系统的主要作用，就是帮大家存储和查找信息。用数据库的人大致可以分成两类：普通用户和数据库管理员。

数据库用户有哪些类型？

不同的人用数据库的方式不一样，大致可以分为四类：

简单用户

简单用户就是不懂技术的普通人，比如医院的挂号员、图书馆的管理员。他们一般不会直接操作数据库，而是通过别人开发好的系统来完成工作， 比如在电脑上输入信息、点击按钮，实现数据的录入和查询。比如，挂号员帮病人挂号时， 只需要在系统里输入病人的姓名、身份证号、科室、预约时间，然后点一下“提交”就可以了。

再比如，图书馆管理员借还书时，只需扫描图书条码和读者证，系统会自动查询数据库，判断书是否可借、读者是否有超期未还的书。这些操作的背后其实都是数据库在支持，但用户只需要会用操作界面即可。

应用程序员

应用程序员是写程序的人，他们会用各种开发工具，帮简单用户做出好用的界面和功能。比如，开发一个网上订餐系统，或者制作一个学生成绩查询的小程序。他们懂编程，能用专业工具快速搭建应用。

高级用户

高级用户懂得用数据库查询语言（比如SQL），可以自己写查询语句，直接和数据库“对话”。比如，老师想统计某门课程的所有学生成绩分布，就能自己写查询，快速得到结果，无需等待开发人员增加新功能。

专业用户

专业用户是指那些需要开发特殊数据库应用的人，比如搞设计的、做专家系统的、处理图形或音频数据的。这些人会写很复杂的程序，数据库只是他们系统的一部分。

数据库管理员（DBA）

数据库管理员（Database Administrator，简称DBA）是数据库系统的核心管理人员，相当于数据库的“管家”和“守护者”。数据库管理员不仅要负责数据库的日常运行，还要确保数据的安全、完整、高效和可用。数据库管理员的工作内容非常广泛和细致，主要包括以下几个方面：

设计数据库结构

DBA需要根据企业或应用的实际需求，设计合理的数据库结构。这包括确定需要哪些数据表、每个表包含哪些字段（列）、字段的数据类型、主键和外键的设置、表之间的关系等。设计时还要考虑数据的规范化，避免冗余和异常，保证数据的完整性和一致性。

管理存储和访问方式

数据库管理员负责决定数据的存储方式，比如选择合适的存储引擎、分区策略、索引设计等，以提升数据库的性能和存储效率。同时，数据库管理员还要优化数据的访问方式，比如通过建立索引、调整查询语句、配置缓存等手段，让数据库查询和写入都能尽量快、占用资源少。此外，数据库管理员还要根据数据量的增长，合理规划磁盘空间，必要时进行分库分表或扩容，确保数据库系统能够稳定运行。

修改和优化

如果公司业务有变化，或者发现数据库慢了，数据库管理员会调整结构或优化存储方式，让数据库更适合新需求。

设置访问权限

数据库管理员负责为不同用户分配精细化的访问权限，严格控制谁可以查询、修改或管理数据，以确保数据的安全性和合规性。 同时数据库管理员还要定期备份数据库，防止意外丢失；监控数据库运行情况，防止有人提交特别“重”的任务拖慢系统；还要保证磁盘空间够用，必要时升级硬件。

小结

数据库管理系统是现代信息技术体系中的核心基础设施，它实现了对大量数据的统一、高效管理。随着互联网技术的普及，数据库系统已成为各行各业信息化建设的关键支撑平台，从电商平台的订单处理、金融服务的账户管理，到智慧城市的交通调度等，无不依赖于数据库系统的高效运作。 数据库技术的发展经历了从早期后台基础设施到直接面向终端用户交互的演变过程，如今已成为支撑大规模在线业务和实时数据处理的核心平台。

数据库管理员在整个系统中扮演着至关重要的角色，他们负责设计合理的数据库结构、管理存储和访问方式、设置精细化的访问权限，并通过持续的优化和维护确保数据库系统安全、高效运行。 无论是应对业务变化、提升查询性能，还是保障数据安全和系统稳定性，数据库管理员都需具备深厚的技术素养和对业务需求的深刻理解，才能让数据库真正成为企业运营的强大后盾。