《Linux操作系统》课件-数据库发展与主流类型

数据库发展与主流类型从历史演变到技术选型发展简史人工管理→文件系统→数据库系统经典模型层次模型、网状模型、关系模型关系型(SQL)结构化存储、强事务支持、高数据一致性非关系型(NoSQL)模式灵活、读写高性能、水平高扩展性提示：了解数据库的发展历程有助于理解不同类型数据库的设计哲学。目录学习目标：了解数据库发展历程，区分SQL与NoSQL的核心差异。发展简史：回顾人工管理、文件系统到数据库系统的完整演变过程。经典数据模型：深度解析层次模型、网状模型与关系模型的核心特点。主流类型对比：全方位对比关系型(SQL)与非关系型(NoSQL)数据库的应用场景。总结与思考：系统回顾本章核心知识点，并通过拓展练习巩固学习成果。发展简史：人工管理阶段阶段背景20世纪50年代中期以前，计算机主要用于科学计算，尚无磁盘等直接存取设备。数据管理工作完全由程序员手动编写代码完成。核心特征(一)•数据不保存：计算任务结束后，数据随即被丢弃，无长期存储概念。

•无专用软件：没有文件系统或数据库管理系统(DBMS)辅助管理。核心特征(二)•数据面向应用：一组数据仅对应一个程序，数据冗余度极高。

•程序与数据绑定：数据逻辑结构改变时，程序代码必须重写。阶段剖析数据管理困境由于没有统一管理，相同数据需在不同程序中重复定义，造成大量数据冗余。且数据维护完全依赖程序员，管理效率极低且极易出错。硬件环境制约当时的计算机硬件仅配备纸带、卡片等外部存储，没有磁盘等直接存取设备。内存容量极小，决定了数据无法常驻内存，必须随用随取。💡总结：人工管理阶段是数据管理的萌芽期，完全依赖人工编码，存在数据冗余大、依赖关系强、管理效率低等显著缺点。发展简史：文件系统阶段核心功能20世纪50年代后期至60年代中期，随着磁盘等直接存取存储设备的出现，操作系统中开始具备专门的文件管理功能。阶段意义数据管理由“人工”进入“系统管理”时代，数据可长期保存并由文件系统统一调度，是数据管理技术的一次重要飞跃。核心特点(常用用法)📁数据长期保存：数据存储在磁盘等介质上，可脱离应用程序长期保存，多次使用。🗂️文件系统管理：由操作系统的文件系统统一管理数据的结构、存取方法和存储空间，程序与数据之间有了一定的独立性。阶段局限(主要缺点)共享性差文件面向特定应用设计，不同应用之间难以共享数据。冗余度大相同数据可能在多个文件中重复存储，造成存储空间浪费。独立性差文件结构的改变会导致应用程序必须随之修改，维护成本高。发展简史：数据库系统阶段功能描述20世纪60年代末以来，为解决数据共享和管理的需求，数据库系统应运而生。核心特征由DBMS统一管理和控制数据主要优势数据结构化整体数据结构化，不再局限于单个文件。共享性高数据可以被多个应用程序并发共享。冗余度低数据集中存储，避免了不必要的重复。数据独立性高数据的逻辑结构与应用程序相互分离。里程碑事件时代标志1968年，IBM公司推出了世界上第一个商用数据库管理系统IMS(InformationManagementSystem)，标志着数据库系统正式进入商用阶段。经典数据模型：层次模型核心功能采用“树形结构”来组织和表示数据之间的联系，是一种天然的“一对多”层级关系映射。结构规则有且仅有一个根节点，其他节点仅有一个父节点。主要优劣势✅优点：结构简单直观，单路径查询效率高。

❎缺点：无法直接表示复杂的“多对多”关系。典型代表与形象理解经典代表系统：IBMIMS数据库——最早的大型数据库系统之一生活中的形象比喻：家族族谱/公司组织架构树——层级分明，脉络清晰经典数据模型：网状模型功能说明引入图结构来表示数据间的复杂联系，突破了层次模型的树状限制，支持更灵活的数据组织方式。核心特点•允许多个节点没有父节点（支持“多根”）

•一个节点可以有多个父节点（支持“多双亲”）

•能够自然地表示多对多（M:N）的数据关系主要缺点数据结构过于复杂，导致系统的设计、实现与维护难度极大。模型解析与思考灵活性的体现相比层次模型的“严格树状”，网状模型的图结构能更好地映射现实世界中的复杂关系，例如学生与课程的多对多选课关系。复杂性的代价虽然解决了多对多问题，但复杂的指针链管理和数据库定义语言（DDL）使得开发和维护成本高昂，最终被关系模型取代。💡提示：网状模型是数据库发展史上重要的一环，它试图解决层次模型的局限性，但由于自身过于复杂，未能成为工业界的主流标准。经典数据模型：关系模型核心定义用二维表格（即“关系”）来组织数据，是当今数据库领域的绝对主流模型。核心优势●结构简单：以表格形式呈现，直观易懂●理论坚实：基于严谨的关系代数数学理论●独立性高：完美实现逻辑与物理数据独立核心术语解析关系(Relation)：即我们通常所说的一张二维数据表。元组(Tuple)：二维表中的一行数据，代表一个具体的实体。属性(Attribute)：二维表中的一列，代表实体的一个特征或属性。主键(PrimaryKey)：表中能唯一确定一行记录的属性或属性组合。核心概念可视化关系(表)由行和列组成的

二维数据集合元组(行)代表一个具体的

数据实体对象属性(列)描述实体的一个

特征或性质主流类型：关系型数据库(SQL)功能描述基于关系模型，使用SQL（结构化查询语言）进行数据的存储与管理操作。核心特征强调数据结构化存储与强事务一致性保证关键特性结构化Schema表结构固定，所有数据必须严格符合预定义的表结构。强事务ACID支持原子性、一致性、隔离性、持久性，确保数据准确。复杂查询支持支持多表关联(Join)和复杂的事务处理逻辑。核心适用场景金融交易、电商订单等高一致性要求的核心业务。主流产品生态开源社区代表产品MySQL/PostgreSQL传统商业闭源产品Oracle/SQLServer核心业务应用领域金融核心/电商交易/ERP主流类型：非关系型数据库(NoSQL)核心功能NotOnlySQL，专为互联网时代海量数据存储与高并发读写场景设计，突破传统数据库瓶颈。设计理念灵活Schema·极致高性能·水平高扩展核心特性与适用场景•灵活Schema：无需预定义表结构，适配多变数据。•极致性能：针对特定查询优化，毫秒级读写响应。•典型场景：社交网络、物联网、实时推荐系统等。主流NoSQL数据库分类KV存储&文档存储Redis：内存型键值数据库，高性能缓存。

MongoDB：文档型数据库，支持复杂查询。列族存储&图形存储HBase：分布式列族数据库，海量离线数据。

Neo4j：图形数据库，擅长处理复杂关系网络。综合练习：技术选型案例任务目标：场景分析场景一：银行转账系统需求：必须保证金额准确性，严禁丢失或错误。请思考选型？场景二：社交网络用户状态流需求：海量高并发读写，数据结构需灵活多变。请思考选型？场景三：电商网站商品信息需求：结构相对固定，需支持高并发查询。请思考选型？参考方案解析·Analysis01.银行转账>>关系型(SQL)理由：核心需求是数据强一致性，依赖ACID事务保证。02.社交信息流>>非关系型(NoSQL)理由：Schema灵活适应多变数据，具备极高的并发读写吞吐能力。03.电商商品>>混合架构(SQL+NoSQL)理由：SQL存核心结构化数据，NoSQL作缓存层提升高并发查询性能。💡核心Tip：技术选型没有绝对答案，需综合权衡数据一致性、系统吞吐量、业务扩展性以及开发维护效率等多个维度。总结与回顾发展历程人工管理

→文件系统

→数据库系统经典模型层次模型·网状模型

关系模型（当前主流）关系型(SQL)强事务、结构化、高一致性

适用于：传统核心业务