数据库管理系统DBMS的历史不只是一道背完就忘的期末填空题而是理解数据库应用为什么长成今天这个模样的主线。很多人学数据库时直接从 SQL 开始SELECT、JOIN、事务隔离级别背得很熟但一碰到“为什么要有关系模型”“为什么要做范式设计”“NoSQL 凭什么火起来”这类问题往往答不到点上。把数据库应用的历史完整串一遍很多问题会自己解开。下面我会从最早期的人工管理讲起一路走到层次模型、网状模型、关系模型再到 NoSQL、NewSQL 和云数据库把每一阶段为什么出现、解决了什么、留下了什么教训讲清楚。这篇文章既适合正在刷《数据库原理与应用》期末考点的同学也适合刚上手数据库开发、想搞清楚技术选型来龙去脉的人。历史不是拿来背的是拿来建立判断力的。1. 数据库应用的历史到底是考点还是理解主线1.1 为什么我建议先把历史串一遍数据库应用的历史本质上是在回答一个问题数据越来越复杂、用户越来越多、系统越来越大之后我们到底应该怎么组织和管理数据。如果没有这条主线你会发现学到的知识点都是散的。今天讲文件系统有问题你听懂了明天讲关系模型用二维表你也听懂了但你不一定能回答“同样是存数据为什么不用 Excel 当数据库”“为什么现在有那么多数据库产品”。把历史串起来之后你会看到一条非常清晰的演进逻辑先解决“数据能不能长期存下来”的问题再解决“数据能不能方便查、方便改”的问题接着解决“很多人同时用会不会乱”的问题然后解决“数据量巨大、分布在不同机器上怎么办”的问题最后解决“能不能像用水用电一样按需使用”的问题。每一代数据库技术都是被上一代解决不了的应用需求逼出来的。没有大型共享业务就不会有层次模型的诞生没有数据量爆炸的互联网业务就不会有 NoSQL 的流行。技术路线从来不是凭空设计出来的。1.2 历史脉络中的三条主线复习或者阅读时我建议你抓住三条主线而不是逐条背时间线。第一条主线是数据管理方式的变化人工管理阶段、文件系统阶段、数据库系统阶段以及后来的分布式数据库、NoSQL、云数据库。这条线回答“数据放在哪里、怎么组织”。第二条主线是数据能力的变化刚开始只能顺序读写后来能按索引查找再后来有了集合查询、事务控制、并发控制、分布式一致性。这条线回答“数据能做什么操作、做到什么程度”。第三条主线是独立性的变化从应用代码里写死文件路径和结构到可以通过数据库的视图、概念层、存储层分离让数据结构变化时应用尽量少改。这条线回答“业务逻辑和数据存储能不能解耦”。这三条线合起来就是数据库管理系统这门课的核心骨架。你把骨架搭好了再去填充具体的产品名、论文、年份记忆会轻松很多。2. 前数据库时代文件系统为什么撑不住业务2.1 文件管理阶段的真实状态在数据库管理系统出现之前数据管理主要靠两类方式人工管理和文件系统。人工管理阶段数据不长期保存。程序运行前把卡片、纸带准备好程序结束数据就跟着消失。程序员要自己清楚数据放在哪、长度多少、格式是什么。这个阶段谈不上“管理系统”更接近“数据是程序的一部分”。到了 20 世纪 60 年代磁盘开始普及数据可以长期存放在磁盘上了。于是出现了文件系统比如顺序文件、索引文件、随机文件。应用程序通过操作系统提供的文件读写接口把业务数据写进文件。这个阶段已经有了一点“数据管理”的样子但仍然很原始。我见过不少人在期末复习时把“文件系统阶段”当成“用文件夹管理文档”来理解其实不是一回事。这里说的文件系统是应用程序把业务数据按固定格式写入文件比如一个学生记录文件每个记录包含学号、姓名、成绩程序自己负责定位、读取、修改。2.2 文件系统暴露的四个核心问题文件系统最大的问题不是技术落后而是它把“存储细节”完全交给了应用程序。这会导致连锁反应。第一个问题是数据冗余。同一个学号可能出现在学生文件、选课文件、成绩文件里不同文件的保存格式还可能不一致。冗余带来不一致比如学生改名之后成绩文件里还是旧名字。第二个问题是数据和应用高度耦合。文件的结构、字段顺序、存储路径都是写死在程序里的。文件加一个字段所有读写这个文件的程序都要改。数据没有独立性维护成本全堆在应用层。第三个问题是数据共享难。每个应用各自维护文件A 程序产生的文件B 程序不一定知道格式。即使知道也缺少统一的权限控制数据很难在多个应用之间安全共享。第四个问题是缺少统一约束和故障恢复。文件系统本身不校验“成绩必须是 0 到 100”“学号必须唯一”这些逻辑只能写在应用里。更麻烦的是如果写入到一半断电文件可能处于中间状态没有事务的原子性概念。这些问题集中爆发后数据库管理系统就成了一种必然选择。并不是某个公司突发奇想造了一个新名词而是文件系统已经无法支撑越来越复杂的业务应用。3. 层次模型和网状模型第一批 DBMS 的样子3.1 IBM IMS 与层次模型最早的数据库管理系统不叫关系数据库而是层次数据库。最典型的代表是 IBM 的 IMS全称 Information Management System。IMS 诞生于 20 世纪 60 年代最初服务于阿波罗计划用来管理登月项目里的物料清单和工程数据。那个年代对数据管理的要求是数据量大、层次关系明确、可靠性要求极高。层次模型用树形结构组织数据。每个记录类型有若干个字段记录类型之间有父子关系。最顶上是根节点向下是一棵完整的树。比如一个“项目”下面有多个“子项目”“子项目”下面有多个“任务”。这种模型在业务规则非常固定的场合效率很高。因为数据关系事先定义好查询路线也比较固定程序可以沿着树结构快速找到数据。但问题也很快暴露层次模型对“多对多”关系处理非常别扭。一个学生选多门课一门课有多个学生这在树形结构里很难直接表达必须拆成多棵树用冗余或指针串联起来。3.2 CODASYL 与网状模型为了弥补层次模型的不足20 世纪 60 年代末CODASYL数据系统语言协会的数据库任务组提出了网状模型规范。1971 年正式公布了 DBTG 报告。网状模型把数据组织成图结构。记录之间通过“系”set建立联系每个系有主记录owner和成员记录member一个成员可以属于多个系。这样就支持了多对多关系。相比层次模型网状模型表达能力更强。它对现实世界的建模更加贴近业务尤其适合描述复杂的企业数据关系。在关系模型出现之前网状模型也一度被认为是发展方向。但它的代价是使用难度极高。程序员必须非常清楚数据结构的物理细节访问数据时往往要沿着系指针一条一条地导航。查询效率高但编写和维护成本非常大。你可以把它理解成“和数据库非常熟的老程序员才能操作”的系统。3.3 第一批数据库的局限在哪里层次模型和网状模型虽然解决了“文件系统数据冗余和共享难”的问题但它们有一个共同的致命缺陷数据结构和存取路径是事先定义死、并且暴露给应用程序的。这意味着一旦业务需求变化要调整数据模型程序就必须跟着改。今天你按“项目—任务”的结构写了一套查询程序明天改成“任务—项目”代码逻辑几乎要重写。数据独立性仍然很差。而且这两类模型都要求用户必须“导航式”地访问数据。你知道要从哪个节点出发走哪条关系经过几层才能找到目标。这不适合管理人员直接使用。数据库在那个年代更像是程序员的专属工具而不是通用的数据管理平台。用一句话概括层次模型和网状模型证明了数据库系统可行但它们太依赖固定的物理结构没有办法支撑灵活、即席的查询。4. 关系模型的崛起从论文到只要十年的产业革命4.1 Codd 那篇论文解决了什么1970 年IBM 研究员埃德加·科德Edgar F. Codd发表了一篇改变整个数据库行业方向的论文题目是《A Relational Model of Data for Large Shared Data Banks》中文常译作《大型共享数据银行的数据关系模型》。这篇论文的核心主张非常朴素把数据组织成二维表也就是关系。每个表有一个名字表里有若干列每列有明确的含义表与表之间通过公共列建立逻辑联系。用户面对的是逻辑结构而不是存储结构。科德还提出了关系代数和关系演算用集合运算来描述查询。你可以不理解里面的数学细节但要看到关键在于它把“怎么存”和“怎么查”彻底分开了。应用只需要描述“我要什么”不需要告诉数据库“你如何找到数据”。这就是数据独立性的起点。也正是因为这一点关系模型在理论上第一次把数据库从“程序员的导航工具”提升为“通用的声明式平台”。4.2 System R、INGRES 与 SQL 的诞生论文发表之后真正的工程验证从 20 世纪 70 年代开始。IBM 圣何塞实验室启动了 System R 项目目标是在实际系统里实现关系模型。System R 贡献了非常多基础能力SQL 查询语言、代价估算优化器、事务恢复机制、视图机制。今天我们用的 SQL 标准很大程度上就是从 System R 的语法演变来的。同样在 70 年代加州大学伯克利分校的 Michael Stonebraker 团队开发了 INGRES 系统走的是类似的关系路线但在很多细节上做了不同取舍。和很多人想的不同关系数据库不是从实验室里出来就立刻统治市场的。关系数据库在最初几年性能并不理想很多人觉得它只是一个学术玩具。IBM 内部也有人对要不要商业化关系数据库犹豫不决。真正把关系数据库推向市场的是后来成立的甲骨文公司以及 IBM 后来发布的 DB2、微软的 SQL Server。从这个阶段可以看出一项技术从论文到产品中间要补的不仅仅是算法还有可维护性、稳定性、兼容性、优化器、并发控制等一系列工程问题。4.3 关系模型为什么最终胜出关系模型能赢得市场竞争根本原因是它提供了前两代模型给不了的使用体验。第一声明式查询。用户使用 SQL 描述结果不需要关心具体怎么查找。数据库自动选择执行方案。这让非专业程序员也能上手。第二高度的数据独立性。逻辑结构和物理存储分离表结构调整时应用可以通过视图等机制减少改动。这是文件系统、层次模型、网状模型都做不到的。第三数学基础扎实。关系代数和集合论让查询具有明确语义可以判断两个查询是否等价可以做优化可以规范化设计。第四面向集合而非面向记录。层次模型和网状模型是一次处理一条记录关系模型是一次处理一个集合。这个差异在复杂查询场景下是决定性的。到 20 世纪 80 年代SQL 成为事实标准1986 年 SQL 成为正式标准。关系数据库管理系统从此进入黄金时代。5. 关系数据库的黄金时代从大型机到个人电脑5.1 Oracle、DB2、SQL Server 的商业化20 世纪 80 年代到 90 年代是关系数据库管理系统快速商业化的时期。甲骨文公司早期主打的是可移植性和开放性让关系数据库能跑在各种硬件和操作系统上搭上了客户服务器架构兴起的快车。IBM DB2 则依托大型机和企业级应用牢牢占据银行、航空、证券等关键行业。微软 SQL Server 面向 Windows 生态降低了中小企业的数据库使用门槛。这个阶段最值得关注的不是谁打赢了而是数据库应用从“少数大企业专用”变成了“几乎所有企业和机构的标配”。企业开始把财务、人事、生产、销售等核心业务系统全部建立在数据库之上。数据库管理系统真正成了企业信息系统的地基。5.2 客户端/服务器架构与事务处理在这个阶段“客户端/服务器”架构逐渐成为主流。应用程序跑在客户端负责界面和业务逻辑数据库跑在服务器端负责数据存储和查询处理。用户通过数据库连接发出 SQL 请求服务器返回结果。支撑这种架构的关键能力是事务处理。事务把一组数据库操作绑定在一起要么全部成功要么全部回滚同时保证 ACID 特性原子性、一致性、隔离性、持久性。数据库系统通过锁机制、日志、恢复算法来实现这四件事。这里有一个很多初学者容易忽略的点事务不是 SQL 语法层面的花架子它是数据库应用可靠性的基础。没有事务银行转账就可能出现“扣了款没到账”的中间态。没有隔离性两个并发用户同时修改同一行数据结果就不可预测。如果你在期末复习中看到“并发控制”“锁”“两段锁协议”“日志恢复”这些内容对应到历史背景就很好理解它们都是为了支撑多用户共享业务而发展出来的工程方案。5.3 对象数据库和对象关系数据库的插曲20 世纪 80 年代末到 90 年代面向对象编程大流行。有人开始质疑关系模型存简单字段没问题但对于复杂对象、嵌套结构、多媒体数据怎么处理于是出现了面向对象数据库管理系统把对象持久化直接映射到数据库里。对象数据库在特定领域确实有优势比如 CAD、地理信息系统、电信。但它的致命问题是没有统一标准查询能力弱而且把对象和数据库绑得太紧应用迁移困难。真正活下来的是“对象关系数据库”这个折中方案。以 PostgreSQL 的前身 POSTGRES 为代表在关系模型基础上加入自定义类型、继承、复杂数据结构等能力。这条路后来被证明更现实关系模型的表仍然保留但对复杂类型做了扩展。今天主流数据库对 JSON、数组、全文索引的支持都可以看成是这条路的延续。6. NoSQL 与大数据互联网场景重新定义数据管理6.1 为什么 2005 年后数据库又开始分裂进入 21 世纪互联网业务让数据库应用遇到了新的压力。首先是数据规模。搜索引擎、社交网络、电商平台在极短时间内产生海量用户数据单台机器的关系数据库很快到达瓶颈。传统做法是升级更大的硬件也就是“垂直扩展”但成本高而且有上限。其次是数据结构。社交动态、商品评论、日志、用户画像这类数据往往是半结构化甚至无结构的硬塞进固定表结构很麻烦。关系数据库强调严格模式违背了部分互联网业务“快速迭代”的诉求。第三是可用性要求。用户希望服务 7×24 小时可用但分布式环境下节点故障、网络分区是常态。传统关系数据库在分布式场景下维护全局事务和强一致性难度极大。于是Google 发表了关于文件系统、大数据计算、分布式存储的论文亚马逊设计了 Dynamo 存储系统这些技术思路催生了 NoSQL 运动。2009 年前后“NoSQL”这个词被重新定义并流行开来。6.2 NoSQL 的主要类型和适用场景NoSQL 不是一个数据库而是一类数据库的合称。它们放弃或弱化了一部分关系模型能力换取扩展性、性能或灵活性。类型典型代表数据组织方式适合场景典型取舍键值数据库Redis、MemcachedKey 到 Value 的映射缓存、会话、排行榜查询模式单一性能极高文档数据库MongoDBJSON / BSON 文档内容管理、用户资料、灵活结构弱化表结构约束支持嵌套列族数据库HBase、Cassandra按列族组织的大表大数据分析、时序数据、稀疏矩阵适合海量写入和按列扫描图数据库Neo4j、JanusGraph节点和边社交关系、风控、推荐关系查询直观图谱计算强做技术选型时不要被“性能快”三个字带偏。NoSQL 快往往是因为它针对特定访问模式做了优化比如只按主键访问比如大量写入在内存里合并比如弱化多表关联。它牺牲的部分通常是事务、复杂查询、数据一致性保证。我的建议是能用关系数据库表达业务时优先用关系数据库只有当你明确遇到单一瓶颈比如超大规模存储、超高并发写入、灵活多变文档结构再认真评估 NoSQL 方案。6.3 CAP 定理的意义理解 NoSQL绕不开 CAP 定理。这个定理最早由 Eric Brewer 在 2000 年提出核心观点是在分布式系统里一致性Consistency、可用性Availability、分区容错性Partition tolerance三者最多只能同时满足两个。很多时候必须选两个实际上因为分布式系统必然存在网络分区所以 P 通常必须满足剩下的选择在 C 和 A 之间。选择强一致就可能短暂拒绝服务选择高可用就可能让用户读到旧数据。这里要提醒一下CAP 不是让你随便三选二而是描述网络分区发生时的trade-off场景。选择哪一个取决于业务对数据正确性有多敏感。金融交易要强一致社交动态可以容忍短暂不一致。从历史角度看NoSQL 流行和 CAP 被广泛传播是同一个背景人们意识到所谓“数据库管理系统”并没有一个在所有场景下都最优的统一方案。数据管理重新进入了多样化时代。7. NewSQL、云数据库与新一代数据库应用7.1 NewSQL想把 NoSQL 的扩展和 SQL 的便利同时拿回来NoSQL 解决了扩展性问题但它丢掉了事务、复杂查询和标准化接口。于是从 2011 年左右开始出现了一类叫 NewSQL 的数据库。NewSQL 的目标很清楚保留 SQL 接口和 ACID 事务同时又支持分布式水平扩展。代表系统包括 TiDB、CockroachDB 等。它们的实现思路通常是把数据按范围或哈希分片分布到多个节点通过分布式一致性协议比如 Raft保证副本一致外层仍提供和单机数据库相近的使用体验。如果你在工作中遇到“业务必须强事务但单机数据库扛不住”的场景NewSQL 是一个值得关注的选项。它不是 NoSQL 的替代品而是一种更接近传统关系数据库的分布式扩展。7.2 云数据库改变了什么云数据库是数据库应用历史上一次非常重大的变化数据库从“自己买硬件、自己装软件、自己运维”变成了“按需订阅的服务”。云厂商提供托管数据库自动完成备份、扩容、故障切换、版本升级。用户只需要关注表结构、SQL 和业务逻辑。存储和计算分离、Serverless 数据库、自动化运维这些能力大幅降低了数据库使用的门槛。云数据库不是取消了数据库管理系统而是把 DBMS 的大部分工程复杂度迁到了云平台侧。对使用者来说体验是“开箱即用”对平台方来说要在多租户隔离、资源调度、弹性伸缩、按量计费上做大量工作。喜欢动手的同学可以在云平台创建一台免费的数据库实例感受一下托管数据库和本机安装之间的差异。你会发现底层还是那些原理但操作界面和故障处理逻辑完全不同。7.3 湖仓一体、HTAP 与 AI 数据库再往后的趋势也不难理解都是对上一阶段问题的回应。数据爆炸让“数据仓库”成为必需品它把多个业务系统的数据汇总到一起支撑报表分析。但传统数据仓库的导入导出链路很重于是出现了“数据湖”和“湖仓一体”把结构化、半结构化、非结构化数据统一管理同时提供接近数据仓库的分析能力。HTAP 则试图让一个系统既能处理在线事务又能处理分析型查询。传统架构里 OLTP 和 OLAP 是分开的数据要从业务库同步到分析库存在延迟。HTAP 通过行存、列存混合存储希望在同一份数据上兼顾两者。AI 与数据库的结合也越来越多。向量数据库用来支撑大模型应用里的语义检索数据库自动调参、索引推荐、自然语言转 SQL 也逐渐落地。这个方向还在快速变化不必神化但确实值得持续关注。8. 期末复习和后续学习建议8.1 期末高频考点梳理如果你的目标是《数据库原理与应用》期末考试下面这些知识点基本绕不开而且和历史脉络强相关。第一数据库管理技术发展三个阶段。人工管理阶段、文件系统阶段、数据库系统阶段。要能说出文件系统阶段的问题是什么、数据库系统阶段解决了什么。第二数据库系统三级模式和两级映像。外模式、概念模式、内模式以及对应的外模式/概念模式映像、概念模式/内模式映像。核心是数据独立性逻辑独立性和物理独立性。第三关系模型的基本术语。关系、元组、属性、码、主键、外键、关系完整性约束实体完整性、参照完整性、用户自定义完整性。第四层次模型和网状模型与关系模型的对比。层次模型树结构、网状模型图结构、关系模型二维表前两者导航式访问关系模型声明式访问。第五SQL 基础。数据定义、数据操作、数据控制。排序、分组、连接、子查询是常考内容。第六事务与并发控制。ACID、并发带来的问题丢失修改、不可重复读、脏读、封锁协议、三级封锁协议、两段锁、隔离级别。第七NoSQL 与大数据。NoSQL 四类模型、CAP 定理、NoSQL 和关系数据库的适用边界。复习时不要只背名词。把“问题—方案—缺陷”三个要素绑定起来记。比如文件系统有问题所以出现 DBMS层次/网状模型解决了共享问题但耦合度高关系模型解决独立性但分布式扩展难NoSQL 解决扩展性但弱化事务。这样记下来的不是时间线而是判断逻辑。8.2 建议的学习路径如果这门课已经快期末了我的建议是先抓主线再补细节。第一遍把三级模式、关系模型、SQL、事务这四块吃透第二遍再去看范式、索引、数据库设计、NoSQL。历史部分不需要死记年份能画出演变顺序、说出每个阶段的优缺点就够了。如果是自学我更建议配一个真实数据库动手验证。装一个 SQLite 或者 PostgreSQL把书本上的例子敲一遍特别要自己构造并发现数据冗余、更新异常、并发问题。经历一次“明明改了数据却没按预期保存”之后你对事务、隔离级别、日志恢复的理解会牢固很多。再往后可以试着从单机数据库切换到分布式场景。不一定非要搭建真实集群读一读 TiDB、CockroachDB 的架构说明理解分片、复制、一致性协议就足够建立分布式数据库的整体概念了。数据库应用的历史其实是一条不断把问题抽象掉、把复杂度转移给系统的路。每次技术换代都是在为开发者减少一类负担。但底层的原理始终不变数据怎么组织、怎么保证正确、怎么支撑并发、怎么应对规模增长。把这四件事想明白无论未来出现多少新数据库产品你都能很快看懂它在解决什么、放弃了什么。期末备考也好日常开发也好我最后留一个很实用的习惯遇到一个数据库产品先问三个问题。它的数据模型是什么它的扩展方式是什么它在事务和一致性上做了什么取舍这三个问题回答清楚你就不需要背产品文档也能做出基本判断。 
长河君 · 2026/9/7 3:55:42 · 阅读 1.2k 数据库管理系统演进史：从文件系统、关系模型到NoSQL与云数据库
数据库管理系统DBMS的历史不只是一道背完就忘的期末填空题而是理解数据库应用为什么长成今天这个模样的主线。很多人学数据库时直接从 SQL 开始SELECT、JOIN、事务隔离级别背得很熟但一碰到“为什么要有关系模型”“为什么要做范式设计”“NoSQL 凭什么火起来”这类问题往往答不到点上。把数据库应用的历史完整串一遍很多问题会自己解开。下面我会从最早期的人工管理讲起一路走到层次模型、网状模型、关系模型再到 NoSQL、NewSQL 和云数据库把每一阶段为什么出现、解决了什么、留下了什么教训讲清楚。这篇文章既适合正在刷《数据库原理与应用》期末考点的同学也适合刚上手数据库开发、想搞清楚技术选型来龙去脉的人。历史不是拿来背的是拿来建立判断力的。1. 数据库应用的历史到底是考点还是理解主线1.1 为什么我建议先把历史串一遍数据库应用的历史本质上是在回答一个问题数据越来越复杂、用户越来越多、系统越来越大之后我们到底应该怎么组织和管理数据。如果没有这条主线你会发现学到的知识点都是散的。今天讲文件系统有问题你听懂了明天讲关系模型用二维表你也听懂了但你不一定能回答“同样是存数据为什么不用 Excel 当数据库”“为什么现在有那么多数据库产品”。把历史串起来之后你会看到一条非常清晰的演进逻辑先解决“数据能不能长期存下来”的问题再解决“数据能不能方便查、方便改”的问题接着解决“很多人同时用会不会乱”的问题然后解决“数据量巨大、分布在不同机器上怎么办”的问题最后解决“能不能像用水用电一样按需使用”的问题。每一代数据库技术都是被上一代解决不了的应用需求逼出来的。没有大型共享业务就不会有层次模型的诞生没有数据量爆炸的互联网业务就不会有 NoSQL 的流行。技术路线从来不是凭空设计出来的。1.2 历史脉络中的三条主线复习或者阅读时我建议你抓住三条主线而不是逐条背时间线。第一条主线是数据管理方式的变化人工管理阶段、文件系统阶段、数据库系统阶段以及后来的分布式数据库、NoSQL、云数据库。这条线回答“数据放在哪里、怎么组织”。第二条主线是数据能力的变化刚开始只能顺序读写后来能按索引查找再后来有了集合查询、事务控制、并发控制、分布式一致性。这条线回答“数据能做什么操作、做到什么程度”。第三条主线是独立性的变化从应用代码里写死文件路径和结构到可以通过数据库的视图、概念层、存储层分离让数据结构变化时应用尽量少改。这条线回答“业务逻辑和数据存储能不能解耦”。这三条线合起来就是数据库管理系统这门课的核心骨架。你把骨架搭好了再去填充具体的产品名、论文、年份记忆会轻松很多。2. 前数据库时代文件系统为什么撑不住业务2.1 文件管理阶段的真实状态在数据库管理系统出现之前数据管理主要靠两类方式人工管理和文件系统。人工管理阶段数据不长期保存。程序运行前把卡片、纸带准备好程序结束数据就跟着消失。程序员要自己清楚数据放在哪、长度多少、格式是什么。这个阶段谈不上“管理系统”更接近“数据是程序的一部分”。到了 20 世纪 60 年代磁盘开始普及数据可以长期存放在磁盘上了。于是出现了文件系统比如顺序文件、索引文件、随机文件。应用程序通过操作系统提供的文件读写接口把业务数据写进文件。这个阶段已经有了一点“数据管理”的样子但仍然很原始。我见过不少人在期末复习时把“文件系统阶段”当成“用文件夹管理文档”来理解其实不是一回事。这里说的文件系统是应用程序把业务数据按固定格式写入文件比如一个学生记录文件每个记录包含学号、姓名、成绩程序自己负责定位、读取、修改。2.2 文件系统暴露的四个核心问题文件系统最大的问题不是技术落后而是它把“存储细节”完全交给了应用程序。这会导致连锁反应。第一个问题是数据冗余。同一个学号可能出现在学生文件、选课文件、成绩文件里不同文件的保存格式还可能不一致。冗余带来不一致比如学生改名之后成绩文件里还是旧名字。第二个问题是数据和应用高度耦合。文件的结构、字段顺序、存储路径都是写死在程序里的。文件加一个字段所有读写这个文件的程序都要改。数据没有独立性维护成本全堆在应用层。第三个问题是数据共享难。每个应用各自维护文件A 程序产生的文件B 程序不一定知道格式。即使知道也缺少统一的权限控制数据很难在多个应用之间安全共享。第四个问题是缺少统一约束和故障恢复。文件系统本身不校验“成绩必须是 0 到 100”“学号必须唯一”这些逻辑只能写在应用里。更麻烦的是如果写入到一半断电文件可能处于中间状态没有事务的原子性概念。这些问题集中爆发后数据库管理系统就成了一种必然选择。并不是某个公司突发奇想造了一个新名词而是文件系统已经无法支撑越来越复杂的业务应用。3. 层次模型和网状模型第一批 DBMS 的样子3.1 IBM IMS 与层次模型最早的数据库管理系统不叫关系数据库而是层次数据库。最典型的代表是 IBM 的 IMS全称 Information Management System。IMS 诞生于 20 世纪 60 年代最初服务于阿波罗计划用来管理登月项目里的物料清单和工程数据。那个年代对数据管理的要求是数据量大、层次关系明确、可靠性要求极高。层次模型用树形结构组织数据。每个记录类型有若干个字段记录类型之间有父子关系。最顶上是根节点向下是一棵完整的树。比如一个“项目”下面有多个“子项目”“子项目”下面有多个“任务”。这种模型在业务规则非常固定的场合效率很高。因为数据关系事先定义好查询路线也比较固定程序可以沿着树结构快速找到数据。但问题也很快暴露层次模型对“多对多”关系处理非常别扭。一个学生选多门课一门课有多个学生这在树形结构里很难直接表达必须拆成多棵树用冗余或指针串联起来。3.2 CODASYL 与网状模型为了弥补层次模型的不足20 世纪 60 年代末CODASYL数据系统语言协会的数据库任务组提出了网状模型规范。1971 年正式公布了 DBTG 报告。网状模型把数据组织成图结构。记录之间通过“系”set建立联系每个系有主记录owner和成员记录member一个成员可以属于多个系。这样就支持了多对多关系。相比层次模型网状模型表达能力更强。它对现实世界的建模更加贴近业务尤其适合描述复杂的企业数据关系。在关系模型出现之前网状模型也一度被认为是发展方向。但它的代价是使用难度极高。程序员必须非常清楚数据结构的物理细节访问数据时往往要沿着系指针一条一条地导航。查询效率高但编写和维护成本非常大。你可以把它理解成“和数据库非常熟的老程序员才能操作”的系统。3.3 第一批数据库的局限在哪里层次模型和网状模型虽然解决了“文件系统数据冗余和共享难”的问题但它们有一个共同的致命缺陷数据结构和存取路径是事先定义死、并且暴露给应用程序的。这意味着一旦业务需求变化要调整数据模型程序就必须跟着改。今天你按“项目—任务”的结构写了一套查询程序明天改成“任务—项目”代码逻辑几乎要重写。数据独立性仍然很差。而且这两类模型都要求用户必须“导航式”地访问数据。你知道要从哪个节点出发走哪条关系经过几层才能找到目标。这不适合管理人员直接使用。数据库在那个年代更像是程序员的专属工具而不是通用的数据管理平台。用一句话概括层次模型和网状模型证明了数据库系统可行但它们太依赖固定的物理结构没有办法支撑灵活、即席的查询。4. 关系模型的崛起从论文到只要十年的产业革命4.1 Codd 那篇论文解决了什么1970 年IBM 研究员埃德加·科德Edgar F. Codd发表了一篇改变整个数据库行业方向的论文题目是《A Relational Model of Data for Large Shared Data Banks》中文常译作《大型共享数据银行的数据关系模型》。这篇论文的核心主张非常朴素把数据组织成二维表也就是关系。每个表有一个名字表里有若干列每列有明确的含义表与表之间通过公共列建立逻辑联系。用户面对的是逻辑结构而不是存储结构。科德还提出了关系代数和关系演算用集合运算来描述查询。你可以不理解里面的数学细节但要看到关键在于它把“怎么存”和“怎么查”彻底分开了。应用只需要描述“我要什么”不需要告诉数据库“你如何找到数据”。这就是数据独立性的起点。也正是因为这一点关系模型在理论上第一次把数据库从“程序员的导航工具”提升为“通用的声明式平台”。4.2 System R、INGRES 与 SQL 的诞生论文发表之后真正的工程验证从 20 世纪 70 年代开始。IBM 圣何塞实验室启动了 System R 项目目标是在实际系统里实现关系模型。System R 贡献了非常多基础能力SQL 查询语言、代价估算优化器、事务恢复机制、视图机制。今天我们用的 SQL 标准很大程度上就是从 System R 的语法演变来的。同样在 70 年代加州大学伯克利分校的 Michael Stonebraker 团队开发了 INGRES 系统走的是类似的关系路线但在很多细节上做了不同取舍。和很多人想的不同关系数据库不是从实验室里出来就立刻统治市场的。关系数据库在最初几年性能并不理想很多人觉得它只是一个学术玩具。IBM 内部也有人对要不要商业化关系数据库犹豫不决。真正把关系数据库推向市场的是后来成立的甲骨文公司以及 IBM 后来发布的 DB2、微软的 SQL Server。从这个阶段可以看出一项技术从论文到产品中间要补的不仅仅是算法还有可维护性、稳定性、兼容性、优化器、并发控制等一系列工程问题。4.3 关系模型为什么最终胜出关系模型能赢得市场竞争根本原因是它提供了前两代模型给不了的使用体验。第一声明式查询。用户使用 SQL 描述结果不需要关心具体怎么查找。数据库自动选择执行方案。这让非专业程序员也能上手。第二高度的数据独立性。逻辑结构和物理存储分离表结构调整时应用可以通过视图等机制减少改动。这是文件系统、层次模型、网状模型都做不到的。第三数学基础扎实。关系代数和集合论让查询具有明确语义可以判断两个查询是否等价可以做优化可以规范化设计。第四面向集合而非面向记录。层次模型和网状模型是一次处理一条记录关系模型是一次处理一个集合。这个差异在复杂查询场景下是决定性的。到 20 世纪 80 年代SQL 成为事实标准1986 年 SQL 成为正式标准。关系数据库管理系统从此进入黄金时代。5. 关系数据库的黄金时代从大型机到个人电脑5.1 Oracle、DB2、SQL Server 的商业化20 世纪 80 年代到 90 年代是关系数据库管理系统快速商业化的时期。甲骨文公司早期主打的是可移植性和开放性让关系数据库能跑在各种硬件和操作系统上搭上了客户服务器架构兴起的快车。IBM DB2 则依托大型机和企业级应用牢牢占据银行、航空、证券等关键行业。微软 SQL Server 面向 Windows 生态降低了中小企业的数据库使用门槛。这个阶段最值得关注的不是谁打赢了而是数据库应用从“少数大企业专用”变成了“几乎所有企业和机构的标配”。企业开始把财务、人事、生产、销售等核心业务系统全部建立在数据库之上。数据库管理系统真正成了企业信息系统的地基。5.2 客户端/服务器架构与事务处理在这个阶段“客户端/服务器”架构逐渐成为主流。应用程序跑在客户端负责界面和业务逻辑数据库跑在服务器端负责数据存储和查询处理。用户通过数据库连接发出 SQL 请求服务器返回结果。支撑这种架构的关键能力是事务处理。事务把一组数据库操作绑定在一起要么全部成功要么全部回滚同时保证 ACID 特性原子性、一致性、隔离性、持久性。数据库系统通过锁机制、日志、恢复算法来实现这四件事。这里有一个很多初学者容易忽略的点事务不是 SQL 语法层面的花架子它是数据库应用可靠性的基础。没有事务银行转账就可能出现“扣了款没到账”的中间态。没有隔离性两个并发用户同时修改同一行数据结果就不可预测。如果你在期末复习中看到“并发控制”“锁”“两段锁协议”“日志恢复”这些内容对应到历史背景就很好理解它们都是为了支撑多用户共享业务而发展出来的工程方案。5.3 对象数据库和对象关系数据库的插曲20 世纪 80 年代末到 90 年代面向对象编程大流行。有人开始质疑关系模型存简单字段没问题但对于复杂对象、嵌套结构、多媒体数据怎么处理于是出现了面向对象数据库管理系统把对象持久化直接映射到数据库里。对象数据库在特定领域确实有优势比如 CAD、地理信息系统、电信。但它的致命问题是没有统一标准查询能力弱而且把对象和数据库绑得太紧应用迁移困难。真正活下来的是“对象关系数据库”这个折中方案。以 PostgreSQL 的前身 POSTGRES 为代表在关系模型基础上加入自定义类型、继承、复杂数据结构等能力。这条路后来被证明更现实关系模型的表仍然保留但对复杂类型做了扩展。今天主流数据库对 JSON、数组、全文索引的支持都可以看成是这条路的延续。6. NoSQL 与大数据互联网场景重新定义数据管理6.1 为什么 2005 年后数据库又开始分裂进入 21 世纪互联网业务让数据库应用遇到了新的压力。首先是数据规模。搜索引擎、社交网络、电商平台在极短时间内产生海量用户数据单台机器的关系数据库很快到达瓶颈。传统做法是升级更大的硬件也就是“垂直扩展”但成本高而且有上限。其次是数据结构。社交动态、商品评论、日志、用户画像这类数据往往是半结构化甚至无结构的硬塞进固定表结构很麻烦。关系数据库强调严格模式违背了部分互联网业务“快速迭代”的诉求。第三是可用性要求。用户希望服务 7×24 小时可用但分布式环境下节点故障、网络分区是常态。传统关系数据库在分布式场景下维护全局事务和强一致性难度极大。于是Google 发表了关于文件系统、大数据计算、分布式存储的论文亚马逊设计了 Dynamo 存储系统这些技术思路催生了 NoSQL 运动。2009 年前后“NoSQL”这个词被重新定义并流行开来。6.2 NoSQL 的主要类型和适用场景NoSQL 不是一个数据库而是一类数据库的合称。它们放弃或弱化了一部分关系模型能力换取扩展性、性能或灵活性。类型典型代表数据组织方式适合场景典型取舍键值数据库Redis、MemcachedKey 到 Value 的映射缓存、会话、排行榜查询模式单一性能极高文档数据库MongoDBJSON / BSON 文档内容管理、用户资料、灵活结构弱化表结构约束支持嵌套列族数据库HBase、Cassandra按列族组织的大表大数据分析、时序数据、稀疏矩阵适合海量写入和按列扫描图数据库Neo4j、JanusGraph节点和边社交关系、风控、推荐关系查询直观图谱计算强做技术选型时不要被“性能快”三个字带偏。NoSQL 快往往是因为它针对特定访问模式做了优化比如只按主键访问比如大量写入在内存里合并比如弱化多表关联。它牺牲的部分通常是事务、复杂查询、数据一致性保证。我的建议是能用关系数据库表达业务时优先用关系数据库只有当你明确遇到单一瓶颈比如超大规模存储、超高并发写入、灵活多变文档结构再认真评估 NoSQL 方案。6.3 CAP 定理的意义理解 NoSQL绕不开 CAP 定理。这个定理最早由 Eric Brewer 在 2000 年提出核心观点是在分布式系统里一致性Consistency、可用性Availability、分区容错性Partition tolerance三者最多只能同时满足两个。很多时候必须选两个实际上因为分布式系统必然存在网络分区所以 P 通常必须满足剩下的选择在 C 和 A 之间。选择强一致就可能短暂拒绝服务选择高可用就可能让用户读到旧数据。这里要提醒一下CAP 不是让你随便三选二而是描述网络分区发生时的trade-off场景。选择哪一个取决于业务对数据正确性有多敏感。金融交易要强一致社交动态可以容忍短暂不一致。从历史角度看NoSQL 流行和 CAP 被广泛传播是同一个背景人们意识到所谓“数据库管理系统”并没有一个在所有场景下都最优的统一方案。数据管理重新进入了多样化时代。7. NewSQL、云数据库与新一代数据库应用7.1 NewSQL想把 NoSQL 的扩展和 SQL 的便利同时拿回来NoSQL 解决了扩展性问题但它丢掉了事务、复杂查询和标准化接口。于是从 2011 年左右开始出现了一类叫 NewSQL 的数据库。NewSQL 的目标很清楚保留 SQL 接口和 ACID 事务同时又支持分布式水平扩展。代表系统包括 TiDB、CockroachDB 等。它们的实现思路通常是把数据按范围或哈希分片分布到多个节点通过分布式一致性协议比如 Raft保证副本一致外层仍提供和单机数据库相近的使用体验。如果你在工作中遇到“业务必须强事务但单机数据库扛不住”的场景NewSQL 是一个值得关注的选项。它不是 NoSQL 的替代品而是一种更接近传统关系数据库的分布式扩展。7.2 云数据库改变了什么云数据库是数据库应用历史上一次非常重大的变化数据库从“自己买硬件、自己装软件、自己运维”变成了“按需订阅的服务”。云厂商提供托管数据库自动完成备份、扩容、故障切换、版本升级。用户只需要关注表结构、SQL 和业务逻辑。存储和计算分离、Serverless 数据库、自动化运维这些能力大幅降低了数据库使用的门槛。云数据库不是取消了数据库管理系统而是把 DBMS 的大部分工程复杂度迁到了云平台侧。对使用者来说体验是“开箱即用”对平台方来说要在多租户隔离、资源调度、弹性伸缩、按量计费上做大量工作。喜欢动手的同学可以在云平台创建一台免费的数据库实例感受一下托管数据库和本机安装之间的差异。你会发现底层还是那些原理但操作界面和故障处理逻辑完全不同。7.3 湖仓一体、HTAP 与 AI 数据库再往后的趋势也不难理解都是对上一阶段问题的回应。数据爆炸让“数据仓库”成为必需品它把多个业务系统的数据汇总到一起支撑报表分析。但传统数据仓库的导入导出链路很重于是出现了“数据湖”和“湖仓一体”把结构化、半结构化、非结构化数据统一管理同时提供接近数据仓库的分析能力。HTAP 则试图让一个系统既能处理在线事务又能处理分析型查询。传统架构里 OLTP 和 OLAP 是分开的数据要从业务库同步到分析库存在延迟。HTAP 通过行存、列存混合存储希望在同一份数据上兼顾两者。AI 与数据库的结合也越来越多。向量数据库用来支撑大模型应用里的语义检索数据库自动调参、索引推荐、自然语言转 SQL 也逐渐落地。这个方向还在快速变化不必神化但确实值得持续关注。8. 期末复习和后续学习建议8.1 期末高频考点梳理如果你的目标是《数据库原理与应用》期末考试下面这些知识点基本绕不开而且和历史脉络强相关。第一数据库管理技术发展三个阶段。人工管理阶段、文件系统阶段、数据库系统阶段。要能说出文件系统阶段的问题是什么、数据库系统阶段解决了什么。第二数据库系统三级模式和两级映像。外模式、概念模式、内模式以及对应的外模式/概念模式映像、概念模式/内模式映像。核心是数据独立性逻辑独立性和物理独立性。第三关系模型的基本术语。关系、元组、属性、码、主键、外键、关系完整性约束实体完整性、参照完整性、用户自定义完整性。第四层次模型和网状模型与关系模型的对比。层次模型树结构、网状模型图结构、关系模型二维表前两者导航式访问关系模型声明式访问。第五SQL 基础。数据定义、数据操作、数据控制。排序、分组、连接、子查询是常考内容。第六事务与并发控制。ACID、并发带来的问题丢失修改、不可重复读、脏读、封锁协议、三级封锁协议、两段锁、隔离级别。第七NoSQL 与大数据。NoSQL 四类模型、CAP 定理、NoSQL 和关系数据库的适用边界。复习时不要只背名词。把“问题—方案—缺陷”三个要素绑定起来记。比如文件系统有问题所以出现 DBMS层次/网状模型解决了共享问题但耦合度高关系模型解决独立性但分布式扩展难NoSQL 解决扩展性但弱化事务。这样记下来的不是时间线而是判断逻辑。8.2 建议的学习路径如果这门课已经快期末了我的建议是先抓主线再补细节。第一遍把三级模式、关系模型、SQL、事务这四块吃透第二遍再去看范式、索引、数据库设计、NoSQL。历史部分不需要死记年份能画出演变顺序、说出每个阶段的优缺点就够了。如果是自学我更建议配一个真实数据库动手验证。装一个 SQLite 或者 PostgreSQL把书本上的例子敲一遍特别要自己构造并发现数据冗余、更新异常、并发问题。经历一次“明明改了数据却没按预期保存”之后你对事务、隔离级别、日志恢复的理解会牢固很多。再往后可以试着从单机数据库切换到分布式场景。不一定非要搭建真实集群读一读 TiDB、CockroachDB 的架构说明理解分片、复制、一致性协议就足够建立分布式数据库的整体概念了。数据库应用的历史其实是一条不断把问题抽象掉、把复杂度转移给系统的路。每次技术换代都是在为开发者减少一类负担。但底层的原理始终不变数据怎么组织、怎么保证正确、怎么支撑并发、怎么应对规模增长。把这四件事想明白无论未来出现多少新数据库产品你都能很快看懂它在解决什么、放弃了什么。期末备考也好日常开发也好我最后留一个很实用的习惯遇到一个数据库产品先问三个问题。它的数据模型是什么它的扩展方式是什么它在事务和一致性上做了什么取舍这三个问题回答清楚你就不需要背产品文档也能做出基本判断。