【数据库系统原理】第1篇：数据、信息与知识——数据库系统的历史使命

目录一、概念的界碑数据、信息与知识二、史前时代的困局人工管理与文件系统三、历史的必然数据库系统的诞生四、核心使命数据共享、冗余控制与独立性五、结语未竟的使命一、概念的界碑数据、信息与知识在进入历史叙述之前有必要先厘清三个常被混淆的概念。数据Data是客观事物属性的符号化记录。它是一串未经解释的数字、字符、图像或声音。例如一串数字“37.5”本身是纯粹的数据它不承载任何意义如同散落在地上的砖石。信息Information是经过结构化和语境化处理后具有意义的数据。当“37.5”被赋予“体温”这一语义标签并被置于“人体正常体温范围为36.1°C至37.2°C”这一语境中时数据便升格为信息——我们从中解读出一个事实此人体温偏高。知识Knowledge则是对信息的进一步提炼它揭示了信息之间的内在关联与因果规律。当大量发热病人的信息被汇总并结合病原学检测结果进行分析最终得出“持续高热伴干咳可能提示某种特定感染”这一判断时信息便凝固为知识。知识能够指导决策与行动。这三者之间存在着清晰的递进逻辑数据是原材料信息是经过加工的产品而知识是产品使用后沉淀下来的认知资产。数据库系统所直接管理的对象是数据但其存在价值却在于支撑信息的高效提取与知识的最终发现。这一基本定位决定了数据库系统在整个信息技术基础设施中的角色——它是连接符号世界与意义世界的桥梁。二、史前时代的困局人工管理与文件系统在计算机诞生的最初年代数据管理处于完全的人工阶段。彼时数据与处理数据的程序紧密耦合数据作为程序的附属品而存在。程序员在使用高级语言编写计算任务时数据通常以常量或变量的形式硬编码于程序之中程序执行结束则数据随之消散。即便部分数据以打孔卡片或纸带的形式物理保存其组织方式也完全由程序员个人决定没有统一的标准更谈不上跨程序共享。一个人若要利用另一个人采集的数据往往需要手动抄录或重新穿孔效率之低下在今天看来几乎不可思议。20世纪50年代末至60年代操作系统开始提供文件系统数据管理进入文件系统阶段。文件系统将数据以文件的形式持久存储于磁盘等外部介质上程序通过操作系统提供的文件读写接口访问数据。这看似是一个巨大的进步——数据终于获得了独立于程序的物理存在。然而文件系统很快暴露出根本性的缺陷。第一个问题是数据冗余与不一致。不同的应用程序往往需要维护各自独立的数据文件。例如一个大学的信息化系统中教务系统维护一份学生信息文件财务系统维护另一份学生信息文件宿舍管理系统再维护第三份。同一个学生的姓名、学号、身份证号等基本信息在三份文件中重复存储。这不仅浪费存储空间更致命的是当该学生修改了手机号码教务系统更新了但财务系统未更新两个系统之间便产生了数据不一致。系统越大、应用越多这种不一致的问题就越严重最终导致整个组织的数据可信度崩塌。第二个问题是数据孤立与共享困难。每个文件都服务于特定的应用程序文件格式由程序开发者自行定义元数据对数据的描述如字段长度、数据类型等往往只存在于程序的源代码之中而非文件本身。当一个新应用需要访问已有数据时程序员必须首先反向工程出原文件的格式然后编写专门的解析程序。数据在不同应用之间的流动需要大量的人工干预和格式转换工作数据共享的边际成本极高。第三个问题是数据与程序的紧耦合。在文件系统中程序对数据的访问路径和存取方法是硬编码的。如果文件结构发生变化——比如某个字段的长度从20字节扩展到50字节——所有访问该文件的程序都必须修改并重新编译。这意味着数据结构的任何微调都会引发应用程序的连锁修改系统的可维护性极差。第四个问题是缺乏统一的数据控制。文件系统对数据的访问控制粒度通常是文件级的难以做到字段级的精细权限管理。此外并发访问控制、故障恢复、完整性约束等高级数据管理功能完全缺失每个应用程序都需要自行实现这些功能造成大量重复劳动。正是这些结构性矛盾的不断累积为数据库系统的诞生准备了历史条件。三、历史的必然数据库系统的诞生20世纪60年代末至70年代初随着计算机在商业领域的广泛应用数据量急剧膨胀应用场景日益复杂文件系统的弊端已到了无法容忍的程度。工业界和学术界几乎同时意识到数据管理不能再继续作为应用程序的附庸而必须成为一个独立的、具有自身理论与方法体系的基础设施层。1968年IBM公司开发的层次数据库IMSInformation Management System投入使用服务于阿波罗登月计划的物资管理系统。IMS采用树形结构组织数据以一种层次化的方式表达实体间的一对多关系。几乎同期通用电气公司推出网状数据库IDSIntegrated 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运动、云原生数据库——每一次技术浪潮本质上都是对这三大目标在新场景、新尺度下的重新诠释与实现。进入大数据与人工智能时代数据的价值被提升到前所未有的高度。但无论上层应用如何变幻数据库系统作为“管理数据的基础设施”这一根本定位没有改变。理解它从哪里来才能更好地判断它往哪里去。在下篇文章中我们将离开宏观的历史叙述深入到数据库系统的逻辑框架内部探讨现实世界如何一步步被抽象为机器可以理解的数据模型。