【数据库系统原理】第1篇：数据、信息与知识——数据库系统的历史使命
目录
一、概念的界碑：数据、信息与知识
二、史前时代的困局：人工管理与文件系统
三、历史的必然：数据库系统的诞生
四、核心使命：数据共享、冗余控制与独立性
五、结语：未竟的使命
一、概念的界碑：数据、信息与知识
在进入历史叙述之前，有必要先厘清三个常被混淆的概念。
数据（Data）是客观事物属性的符号化记录。它是一串未经解释的数字、字符、图像或声音。例如，一串数字“37.5”本身是纯粹的数据，它不承载任何意义，如同散落在地上的砖石。
信息（Information）是经过结构化和语境化处理后具有意义的数据。当“37.5”被赋予“体温”这一语义标签，并被置于“人体正常体温范围为36.1°C至37.2°C”这一语境中时，数据便升格为信息——我们从中解读出一个事实：此人体温偏高。
知识（Knowledge）则是对信息的进一步提炼，它揭示了信息之间的内在关联与因果规律。当大量发热病人的信息被汇总，并结合病原学检测结果进行分析，最终得出“持续高热伴干咳可能提示某种特定感染”这一判断时，信息便凝固为知识。知识能够指导决策与行动。
这三者之间存在着清晰的递进逻辑：数据是原材料，信息是经过加工的产品，而知识是产品使用后沉淀下来的认知资产。数据库系统所直接管理的对象是数据，但其存在价值却在于支撑信息的高效提取与知识的最终发现。这一基本定位决定了数据库系统在整个信息技术基础设施中的角色——它是连接符号世界与意义世界的桥梁。
二、史前时代的困局：人工管理与文件系统
在计算机诞生的最初年代，数据管理处于完全的人工阶段。彼时，数据与处理数据的程序紧密耦合，数据作为程序的附属品而存在。程序员在使用高级语言编写计算任务时，数据通常以常量或变量的形式硬编码于程序之中，程序执行结束则数据随之消散。即便部分数据以打孔卡片或纸带的形式物理保存，其组织方式也完全由程序员个人决定，没有统一的标准，更谈不上跨程序共享。一个人若要利用另一个人采集的数据，往往需要手动抄录或重新穿孔，效率之低下在今天看来几乎不可思议。
20世纪50年代末至60年代，操作系统开始提供文件系统，数据管理进入文件系统阶段。文件系统将数据以文件的形式持久存储于磁盘等外部介质上，程序通过操作系统提供的文件读写接口访问数据。这看似是一个巨大的进步——数据终于获得了独立于程序的物理存在。
然而，文件系统很快暴露出根本性的缺陷。第一个问题是数据冗余与不一致。不同的应用程序往往需要维护各自独立的数据文件。例如，一个大学的信息化系统中，教务系统维护一份学生信息文件，财务系统维护另一份学生信息文件，宿舍管理系统再维护第三份。同一个学生的姓名、学号、身份证号等基本信息在三份文件中重复存储。这不仅浪费存储空间，更致命的是，当该学生修改了手机号码，教务系统更新了但财务系统未更新，两个系统之间便产生了数据不一致。系统越大、应用越多，这种不一致的问题就越严重，最终导致整个组织的数据可信度崩塌。
第二个问题是数据孤立与共享困难。每个文件都服务于特定的应用程序，文件格式由程序开发者自行定义，元数据（对数据的描述，如字段长度、数据类型等）往往只存在于程序的源代码之中，而非文件本身。当一个新应用需要访问已有数据时，程序员必须首先反向工程出原文件的格式，然后编写专门的解析程序。数据在不同应用之间的流动需要大量的人工干预和格式转换工作，数据共享的边际成本极高。
第三个问题是数据与程序的紧耦合。在文件系统中，程序对数据的访问路径和存取方法是硬编码的。如果文件结构发生变化——比如某个字段的长度从20字节扩展到50字节——所有访问该文件的程序都必须修改并重新编译。这意味着数据结构的任何微调都会引发应用程序的连锁修改，系统的可维护性极差。
第四个问题是缺乏统一的数据控制。文件系统对数据的访问控制粒度通常是文件级的，难以做到字段级的精细权限管理。此外，并发访问控制、故障恢复、完整性约束等高级数据管理功能完全缺失，每个应用程序都需要自行实现这些功能，造成大量重复劳动。
正是这些结构性矛盾的不断累积，为数据库系统的诞生准备了历史条件。
三、历史的必然：数据库系统的诞生
20世纪60年代末至70年代初，随着计算机在商业领域的广泛应用，数据量急剧膨胀，应用场景日益复杂，文件系统的弊端已到了无法容忍的程度。工业界和学术界几乎同时意识到：数据管理不能再继续作为应用程序的附庸，而必须成为一个独立的、具有自身理论与方法体系的基础设施层。
1968年，IBM公司开发的层次数据库IMS（Information Management System）投入使用，服务于阿波罗登月计划的物资管理系统。IMS采用树形结构组织数据，以一种层次化的方式表达实体间的一对多关系。几乎同期，通用电气公司推出网状数据库IDS（Integrated Data Store），采用图状结构组织数据，能够表达更加复杂的多对多关系。这两个系统标志着数据管理正式进入了数据库时代——数据不再依附于特定的应用程序，而是作为一种独立的企业资源被集中规划、统一管理。
1970年，IBM研究员埃德加·科德（Edgar F. Codd）发表了一篇具有划时代意义的论文《A Relational Model of Data for Large Shared Data Banks》，提出了关系数据模型。科德的核心洞见在于：数据应当按照严格的数学理论（集合论与一阶谓词逻辑）来组织，用户只需声明“想要什么”而非指定“如何获取”，数据与程序之间应当建立起坚固的逻辑隔离。这一思想在当时遭到不少质疑——许多人认为关系模型过于理论化，无法在实际系统中高效实现。然而，此后十余年间，IBM的System R、加州大学伯克利分校的Ingres等原型系统相继证明了关系模型的实际可行性。到20世纪80年代，关系型数据库已成为绝对的主流。
回顾这段历史，我们可以清晰地辨认出数据库系统产生的内在逻辑：不是数据库技术创造了数据管理的需求，而是日益膨胀的数据管理需求倒逼出了数据库技术。当数据量突破人工管理的阈值，当数据共享跨越部门与应用的边界，当数据一致性的要求高于冗余存储的成本时，数据库系统的出现就成为一种历史必然。
四、核心使命：数据共享、冗余控制与独立性
数据库系统的核心目标可以用三个关键词来概括：数据共享、冗余控制、数据独立性。
数据共享是数据库系统的首要使命。在文件系统时代，每个应用程序独占其数据，形成一座座数据孤岛。数据库系统通过将所有数据整合为一个逻辑上统一的整体，允许多个用户、多个应用程序在并发条件下同时访问相同的数据。但这种共享并非简单的文件打开，它需要一套复杂的并发控制机制——多个事务同时读写相同数据时，系统必须保证数据不会被破坏，每个用户看到的结果都是逻辑一致的。同时，共享也意味着需要精细的授权控制：不同用户对同一数据的访问权限可能完全不同，有人可读不可写，有人只允许查看特定字段，有人甚至不知道某些敏感数据的存在。
冗余控制是数据库系统提升数据质量的战略手段。绝对的零冗余在实践中既不经济也不必要——适度的冗余有时可以换取查询性能的显著提升。数据库系统追求的是可控冗余而非绝对消除冗余。通过数据库设计的规范化理论（这是本专栏后续将深入探讨的话题），设计者能够有意识地决定哪些数据需要冗余存储，哪些数据必须保持单一来源。对于必要的冗余，系统通过触发器、物化视图或应用层逻辑来保证各个副本之间的一致性。这样一来，数据冗余不再是一个失控的灾难之源，而成为一种可以为性能优化服务的可控工具。
数据独立性是数据库系统最深刻的架构贡献。它分为两个层次：逻辑独立性与物理独立性。逻辑独立性是指应用程序不会因数据库逻辑结构的改变（如增加新的字段、拆分原有的表）而被迫修改；物理独立性是指应用程序不会因数据物理存储方式的改变（如更换索引结构、迁移存储设备）而被迫修改。这两层独立的实现，依靠的是数据库系统的三级模式架构：外模式面向用户，概念模式定义全局逻辑结构，内模式定义物理存储细节。每一层之间通过映射机制相互衔接，任何一层的变动只要调整映射关系即可，无需波及上层应用。这种分层解耦的架构思想，远远超出了数据库领域本身的范畴，成为现代软件工程的一项基本原则。
五、结语：未竟的使命
从20世纪60年代至今，数据库系统已走过半个多世纪的发展历程。回望这段历史，数据共享、冗余控制与数据独立性这三大核心目标始终指引着数据库技术的演进方向。关系模型、事务处理、分布式架构、NoSQL运动、云原生数据库——每一次技术浪潮，本质上都是对这三大目标在新场景、新尺度下的重新诠释与实现。
进入大数据与人工智能时代，数据的价值被提升到前所未有的高度。但无论上层应用如何变幻，数据库系统作为“管理数据的基础设施”这一根本定位没有改变。理解它从哪里来，才能更好地判断它往哪里去。在下篇文章中，我们将离开宏观的历史叙述，深入到数据库系统的逻辑框架内部，探讨现实世界如何一步步被抽象为机器可以理解的数据模型。