数据库系统概论 / Introduction to Database Systems

> 【引言 / Introduction】 > 数据库是数字时代的“数据仓库”，是所有数字应用的核心底座。从你早上起床用手机查天气预报，到晚上睡前刷短视频、玩在线游戏，每一步操作背后都有数据库在默默支撑。很多人觉得数据库是计算机专业的高深内容，离自己的日常生活很远，但实际上你每天都在和数据库打交道：你朋友圈发布的每一条动态、游戏里的每一个角色装备、短视频平台给你推荐的每一条内容，都离不开数据库的存储、计算和管理。本章将带你系统了解数据库系统的核心定义、发展演进历程、主流数据模型分类和典型应用场景，同时建立中英双语专业术语对照体系，为你后续深入学习数据库原理打下坚实基础。

---

1.1 数据库的核心定义 / Core Definition of Database

要理解数据库，我们需要先从最基础的“数据”概念出发。在计算机领域，数据（Data） 是指所有能被计算机识别的符号的集合，包括文字、数字、图片、音频、视频、传感器记录等，它是数据库存储的核心对象。比如你写的一篇日记、拍的一张照片、游戏里的角色等级，都是数据。

当我们把大量有组织、可共享的数据长期存储在计算机的存储介质（如硬盘、SSD）中，就形成了数据库（Database，简称DB）。你可以把数据库理解为一个专门用来存放数据的“数字保险箱”，里面的数据不是杂乱无章堆放的，而是按照一定的规则组织起来的，方便后续查找和使用。

仅仅有存放数据的“保险箱”还不够，我们还需要一个专门用来管理数据库的软件，这就是数据库管理系统（Database Management System，简称DBMS）。DBMS是位于用户和操作系统之间的数据管理软件，负责数据库的建立、使用、维护和管理，相当于这个“数字保险箱”的管理员：它负责帮你把数据整齐地放进保险箱、按照你的要求快速找到你需要的数据、防止别人非法篡改你的数据、甚至在你把保险箱弄丢的时候帮你恢复数据。目前主流的关系型数据库DBMS包括MySQL、PostgreSQL、Oracle等，非关系型数据库DBMS包括Redis、MongoDB、Neo4j等。

而数据库系统（Database System，简称DBS） 则是一个更完整的整体，它不仅包括数据库和DBMS，还包括存储数据库的硬件设备、操作数据库的应用程序、负责管理数据库的数据库管理员（Database Administrator，简称DBA），以及使用数据库的普通用户。你可以把数据库系统理解成“保险箱+管理员+存放保险箱的房间+使用保险箱的你”的完整组合。

和早期的人工管理数据、文件系统管理数据相比，数据库系统有四个核心优势，这些优势也是它能够成为数字世界核心基础设施的原因： 1. 结构化存储：数据库中的数据是按照统一的规则组织的，比如关系数据库中的二维表格结构，所有数据都有明确的字段和类型，不会出现“同一个字段有的是数字有的是文字”的混乱情况。 2. 高可靠性：数据库通过备份、事务、容错等机制，保证数据不会因为硬件故障、软件错误、误操作而丢失，即使出现故障也能快速恢复。 3. 易共享性：数据库支持多用户同时访问和操作，多个用户、多个应用程序可以同时读写同一个数据库，而不会出现数据混乱的情况。 4. 易查询性：数据库提供了高效的查询语言和索引机制，即使存储了上亿条数据，也能在毫秒级返回你需要的查询结果。

举个贴近你生活的例子：你所在的班级需要管理所有同学的信息，如果用人工管理的方式，就是班主任手里拿一个花名册，要查某个同学的信息就得一页页翻；如果用文件系统管理，就是班主任把花名册存成一个Excel文件，要查“所有三年级二班的女生”就得手动筛选；而如果用数据库系统管理，只需要把全班同学的信息存入数据库，输入一句查询指令，系统就能立刻把所有符合条件的同学信息列出来，而且所有老师都能同时访问这个数据库，不会出现班主任改了某个同学的名字，数学老师的花名册还是旧名字的不一致问题。

---

1.2 数据库的发展演进历程 / Development History of Database Systems

数据库技术的发展不是一蹴而就的，而是随着计算机硬件、软件技术的发展，以及应用场景的需求变化，经历了从人工管理到文件系统，再到现代数据库系统的四个主要阶段，每个阶段都对应着不同的技术特点和适用场景。我们可以通过下面的时间轴直观了解数据库的发展脉络：

```mermaid timeline title 数据库系统发展演进时间轴 / Database System Development Timeline 1940s-1950s : 人工管理阶段 / Manual Management Stage : 数据以纸质文件、卡片等形式存储 : 由人工整理、查询、维护 : 典型场景：图书馆借书卡、学生成绩纸质档案 1950s-1960s : 文件系统阶段 / File System Stage : 数据以文件形式存储在磁带、磁盘等存储介质 : 由操作系统统一管理文件 : 典型场景：早期计算机存储的学生成绩单、员工信息表 1970s-1990s : 数据库系统阶段 / Database System Stage : 关系模型诞生，DBMS出现 : SQL语言成为标准查询语言 : 典型场景：银行核心交易系统、企业ERP系统 2000s-2010s : NoSQL与分布式数据库阶段 / NoSQL & Distributed Database Stage : 应对互联网海量数据、高并发场景 : 非关系型数据库百花齐放 : 典型场景：社交平台、电商平台、搜索引擎 2010s-至今 : 云原生与多模数据库阶段 / Cloud-Native & Multi-Model Database Stage : 数据库与云计算深度融合 : 支持弹性扩缩容、Serverless架构 : 典型场景：短视频平台、智能穿戴、元宇宙应用 ```

1.2.1 人工管理阶段（1940s-1950s）/ Manual Management Stage

在计算机诞生的早期，还没有专门的软件来管理数据，所有数据都以纸质文件、卡片、磁带等形式存储，完全由人工负责数据的整理、分类、查询和维护。比如20世纪40年代，美国人口普查的数据就是印在纸质卡片上，由人工分类整理，要查询某个人的信息需要翻几十万张卡片，效率极低。

这个阶段的数据管理有三个明显缺点：

• 数据量非常有限，无法支撑大规模的数据存储需求；
• 数据容易丢失、损坏，可靠性极低；
• 数据无法共享，一份数据只能由一个人使用，查询效率极低。

1.2.2 文件系统阶段（1950s-1960s）/ File System Stage

随着计算机硬件的发展，出现了磁盘、磁带等

随着计算机硬件的发展，出现了磁盘、磁带等大容量存储介质，操作系统开始提供文件管理功能，数据管理进入了文件系统阶段（File System Stage，1950s-1960s）。在这个阶段，数据以文件的形式存储在存储介质上，比如.txt文本文档、.xlsx电子表格、.csv逗号分隔值文件等，每个文件是一组相关数据的集合，程序员可以直接通过文件名读写文件，操作系统负责管理文件的存储位置、读写权限，不需要人工再手动整理卡片了。

这个阶段相比人工管理已经有了质的提升：数据可以长期存储在磁盘上，不会轻易丢失；数据量可以支撑到MB甚至GB级别，远超过纸质卡片的存储能力；多个程序可以同时读取同一个文件，实现了初步的数据共享。但文件系统仍然存在无法解决的缺陷，我们以2000年前后很多学校的学生成绩管理场景为例：当时每个班的班主任都会把本班的学生成绩存在自己电脑里的Excel文件里，教务处要统计全年级的成绩，需要把每个班的Excel文件收集起来，手动合并、筛选、计算，整个过程可能需要几天时间；如果某个班主任改了自己班的成绩，没有及时通知教务处，就会出现全年级统计成绩不一致的问题；如果要查“所有数学成绩90分以上且担任班干部的学生”，需要先把成绩文件和班干部名单文件合并，再手动筛选，效率极低。

文件系统的核心缺陷可以总结为五点： 1. 数据冗余高（High Redundancy）：同一份数据会被多个不同的文件重复存储，比如学生的姓名、班级会同时出现在成绩文件、花名册文件、奖惩记录文件里，浪费大量存储空间； 2. 数据不一致（Data Inconsistency）：同一份数据在不同文件里可能不一样，比如学生转班后，成绩文件里的班级改了，花名册里的班级没改，就会出现数据矛盾； 3. 数据孤立（Data Isolation）：不同文件之间的数据是割裂的，无法直接关联查询，要实现跨文件的查询需要程序员自己写代码合并数据，开发成本极高； 4. 安全性差（Poor Security）：文件系统只能做到文件级的权限控制，无法做到细粒度的数据权限，比如要实现“学生只能看自己的成绩，不能看别人的成绩”，需要程序员自己写大量代码判断，很容易出现漏洞； 5. 并发控制弱（Weak Concurrency Control）：如果多个用户同时读写同一个文件，很容易出现数据覆盖，比如两个老师同时修改同一个学生的成绩，最后可能只保存了一个人的修改，另一个人的修改丢失了。

这些缺陷在数据量小、用户少的场景下还不明显，但随着计算机应用的普及，企业的数据量越来越大，用户数越来越多，文件系统已经无法满足需求，数据库技术的革命已经呼之欲出。

---

1.2.3 数据库系统阶段（1970s-1990s）/ Database System Stage

1970年是数据库发展史上最重要的里程碑年份，IBM公司 San Jose 实验室的研究员埃德加·科德（Edgar F. Codd） 发表了划时代的论文《大型共享数据库数据的关系模型》（*A Relational Model of Data for Large Shared Data Banks*），首次提出了关系模型（Relational Model），开创了数据库的新纪元。科德也因为这一贡献被后世称为“关系型数据库之父”，并于1981年获得了计算机领域的最高荣誉——图灵奖。

关系模型的核心思想非常简单：用我们日常熟悉的二维表格（Table） 来组织所有数据，每个表格对应一类实体（比如学生、课程、成绩），表格的每一列（Column/Attribute）对应实体的一种属性（比如学生的学号、姓名、班级），每一行（Row/Tuple）对应一个具体的实体实例（比如一个具体的学生）。比如我们想存储学生和成绩的信息，就可以创建两个表：学生表（包含学号、姓名、班级三个列）、成绩表（包含学号、课程、分数三个列），两个表通过“学号”这个公共字段关联起来，就可以轻松查询“某个学生的所有课程成绩”“某门课程所有学生的分数”这类跨表数据，就像用Excel做数据透视表一样简单。

关系模型提出后，IBM很快在1974年启动了System R研究项目，第一个实现了关系模型的数据库管理系统原型，同时提出了结构化查询语言（Structured Query Language，简称SQL），这是一种专门用来操作关系型数据库的声明式语言，你不需要告诉数据库“怎么查数据”，只需要告诉数据库“你要什么数据”，数据库会自动找到最高效的查询方式。比如你要查“所有数学成绩大于90分的三年级学生”，只需要写一句简单的SQL语句：`SELECT 姓名 FROM 学生表 WHERE 年级='三年级' AND 数学成绩>90;`，数据库就会立刻返回结果，不需要你自己写代码遍历所有数据。

1979年，Oracle公司推出了第一个商用的关系型数据库管理系统Oracle V2，标志着数据库技术正式进入商用时代。随后IBM的DB2、微软的SQL Server、开源的MySQL、PostgreSQL等关系型数据库陆续出现，关系型数据库迅速成为企业数据管理的标准方案。这个阶段的数据库系统已经具备了关系模型的全部优势：数据结构清晰、支持复杂的关联查询、通过事务（Transaction） 机制保证了数据的ACID特性，完美满足了企业级应用对数据可靠性、一致性的极高要求。

我们以最熟悉的银行转账场景为例，理解ACID特性的价值：假设你要给朋友转100元，这个操作在数据库里会被封装成一个事务，包含两个步骤：第一步从你的账户扣除100元，第二步给朋友的账户增加100元。ACID四个特性保证了这个操作不会出错：

• **原子性（Atomicity）**：这两个步骤要么全部成功，要么全部失败，不会出现只扣了你的钱、没给朋友加钱的情况，也不会出现钱凭空多出来或者少掉的情况；
• **一致性（Consistency）**：转账前后，你和朋友的总金额不变，数据库的完整性约束（比如账户余额不能为负数）不会被破坏；
• **隔离性（Isolation）**：如果同时有几千个人在转账，你的转账操作不会和其他人的操作互相干扰，不会出现你扣了钱，朋友还没收到，别人就看到了你的余额变少的情况；
• **持久性（Durability）**：转账成功后，就算银行的电脑突然断电、数据库服务器损坏，钱已经成功转到朋友账户里的事实不会改变，数据会永久保存在数据库中。

这个阶段的典型应用场景包括银行核心交易系统、学校教务系统、企业ERP系统、政府政务系统等，这些场景对数据的一致性、可靠性要求极高，关系型数据库的ACID特性正好完美匹配需求。

---

1.2.4 NoSQL与分布式数据库阶段（2000s-2010s）/ NoSQL & Distributed Database Stage

进入21世纪，互联网行业爆发式增长，谷歌、亚马逊、Facebook、腾讯、阿里巴巴等互联网公司遇到了关系型数据库无法解决的问题：谷歌要存储整个互联网的网页数据，总规模超过100PB（1PB=100万GB），关系型数据库根本无法支撑这么大的数据量；Facebook的好友关系超过100亿条，每天新增的好友关系、动态发布超过10亿条，关系型数据库的查询和写入速度越来越慢，甚至经常出现宕机；淘宝在“双十一”的时候，每秒有几十万笔交易，关系型数据库根本扛不住这么高的并发访问量。

为了解决这些问题，非关系型数据库（NoSQL，Not Only SQL）应运而生。2009年，NoSQL这个词被正式提出，泛指所有不使用传统关系模型、不需要固定表结构的数据库，核心目标是解决海量数据存储、高并发访问、灵活schema的需求。NoSQL数据库通常采用分布式架构，把数据分散存储在成千上万台服务器上，既可以支撑PB级

> 数据的存储需求，还可以通过增加服务器数量实现水平扩展，性能可以随着服务器数量的增加线性提升。NoSQL数据库的核心理念是“牺牲部分一致性、事务特性，换取更高的性能、更大的存储容量和更灵活的存储结构”，正好匹配互联网场景对性能、扩展性的极致要求。截至2024年，全球数据库市场规模已超过1200亿美元，其中NoSQL数据库的市场占比已达到32%，年增长率超过20%，成为互联网行业的基础设施标配。

NoSQL数据库通常可以分为四大核心类型，不同类型的数据库适配不同的场景需求，我们可以通过下面的对比表快速了解它们的核心差异：

```mermaid classDiagram class NoSQL类型对比 { +String 类型名称 +String 核心特点 +String 典型适用场景 +String 代表产品 } NoSQL类型对比 <|-- 键值型 NoSQL类型对比 <|-- 文档型 NoSQL类型对比 <|-- 列存储型 NoSQL类型对比 <|-- 图型 键值型 : 用唯一键关联任意类型的值 键型 : 读写速度极快（可达10万+QPS） 键值型 : 支持简单键查询，无复杂条件查询 键值型 : 缓存、排行榜、登录态、计数器 键值型 : Redis、Amazon DynamoDB 文档型 : 用JSON/BSON格式存储半结构化数据 文档型 : Schema灵活，支持嵌套字段 文档型 : 支持复杂条件查询和索引 文档型 : 用户信息、内容动态、商品信息 文档型 : MongoDB、CouchDB 列存储型 : 按列而非按行存储数据 列存储型 : 存储密度高，批量查询效率极高 列存储型 : 支持PB级数据存储 列存储型 : 用户行为日志、历史数据、大数据分析 列存储型 : HBase、Cassandra 图型 : 用节点+边的结构存储实体关联关系 图型 : 关联查询效率是关系型数据库的100倍以上 图型 : 支持复杂的关系遍历查询 图型 : 社交关系、推荐系统、知识图谱、反欺诈 图型 : Neo4j、NebulaGraph ```

1.2.4.1 键值型数据库（Key-Value Database）

键值型数据库是最基础、最古老的NoSQL类型，它的存储逻辑和我们日常使用的字典完全一致：每一个数据项都由一个唯一的键（Key）和对应的值（Value）组成，用户可以通过键快速查询、修改、删除对应的值，值可以是字符串、数字、JSON对象、二进制图片等任意类型的数据。

键值型数据库的最大优势是读写速度极快，主流产品Redis的读写速度可以达到每秒10万次以上，延迟低于1毫秒，远高于关系型数据库的每秒几千次的性能。它的缺点是只能通过键查询，不支持“查询所有年龄大于18岁的用户”这类复杂的条件查询，因此只适合简单的键查询场景。

对于青少年用户来说，最常接触到的键值型数据库应用场景就是在线游戏的登录态和排行榜：当你登录王者荣耀的时候，游戏服务器需要验证你的账号是否登录有效，这个登录态就存储在Redis里，每秒有几十万用户同时登录，Redis的高并发能力完全扛得住这样的请求压力；而游戏的段位排行榜，则是用Redis的有序集合（Sorted Set）功能存储，每个玩家的段位积分作为排序分数，查询全服前100名只需要几毫秒，比关系型数据库快几十倍。我们可以通过下面的代码示例直观感受Redis的用法：

```python

用Redis存储王者荣耀段位排行榜

import redis

连接Redis服务器

r = redis.Redis(host='game-server.example.com'