📚 课程目录第3章数据模型

3. 数据模型：概念模型、逻辑模型、物理模型，以及层次模型、网状模型、关系模型的特点与比较

数据模型是数据库系统的核心与基础，它描述了数据结构、数据操作以及数据约束三要素。在计算机三级数据库技术考试中，理解数据模型的三个层次（概念、逻辑、物理）以及三种经典数据模型（层次、网状、关系）的演变与比较，是后续学习数据库设计、SQL语言和数据库管理的重要基石。本章将系统梳理这些模型的核心原理、判断方法、应用场景及常见误区，帮助您构建清晰的知识图谱。

3.1 数据模型的三个层次：概念模型、逻辑模型与物理模型

数据模型根据抽象层次的不同，可以分为概念模型、逻辑模型和物理模型。这三者分别对应数据库设计的不同阶段，从用户需求到系统实现逐步细化。

3.1.1 核心原理：三层次模型的定位与作用

概念模型是最高层次的抽象，它完全站在用户的视角，描述现实世界中的实体、属性以及实体之间的联系。概念模型不依赖于任何具体的数据库管理系统（DBMS），其典型代表是实体-联系（E-R）模型。它的主要作用是帮助设计人员和用户进行有效沟通，确保需求理解的准确性。

逻辑模型是中间层次，它将概念模型转换为某种特定DBMS支持的逻辑结构。逻辑模型需要描述数据的逻辑组织方式，例如关系模型中的二维表结构、层次模型中的树形结构、网状模型中的图结构。逻辑模型是数据库设计中最关键的环节，直接决定了数据操作的灵活性和应用程序的编写方式。

物理模型是最低层次的抽象，它描述了数据在物理存储介质上的组织方式，包括文件结构、索引类型、数据压缩、分区策略等。物理模型与具体的硬件环境、操作系统和DBMS的存储引擎密切相关。物理设计的优劣直接影响数据库的查询性能、存储效率和I/O开销。

3.1.2 判断方法：如何区分三个层次

判断一个模型属于哪个层次，可以从以下三个维度进行：

面向对象：概念模型面向业务用户，逻辑模型面向数据库设计人员，物理模型面向系统管理员和存储工程师。
与DBMS的关系：概念模型与DBMS无关，逻辑模型与DBMS相关（不同DBMS支持不同的逻辑模型），物理模型与DBMS及硬件均相关。
设计阶段：概念模型对应需求分析阶段，逻辑模型对应逻辑设计阶段，物理模型对应物理设计阶段。

3.1.3 案例拆解：从E-R图到关系表再到索引文件

以“学生选课系统”为例，三个层次的设计过程如下：

层次	设计内容	具体示例
概念模型	E-R图	学生（学号、姓名、系别）、课程（课程号、课程名、学分）、选修（成绩）
逻辑模型	关系模式	Student(Sno, Sname, Sdept); Course(Cno, Cname, Ccredit); SC(Sno, Cno, Grade)
物理模型	存储结构	Student表按Sno建立主索引，SC表按(Sno, Cno)建立复合索引，数据文件按堆组织

这个案例清晰地展示了从抽象到具体、从业务到技术的逐步转化过程。概念模型不关心数据如何存储，逻辑模型确定了表结构，物理模型则决定了数据在磁盘上的实际排列和检索效率。

3.1.4 常见误区与总结复盘

常见误区：将E-R图直接当作逻辑模型使用。E-R图是概念模型，它无法直接转换为SQL语句，必须先转换为关系模式（逻辑模型），再进行物理设计。另外，物理模型并非越复杂越好，过度索引会导致写操作性能下降。

总结：三层次模型是数据库设计的“三层抽象”，每一层都屏蔽了下一层的复杂性。掌握三者的区别与联系，是进行规范数据库设计的前提。

3.2 层次模型与网状模型：非关系模型的代表

层次模型和网状模型是数据库发展早期（20世纪60-70年代）的主流数据模型，它们以记录为基本结构，通过指针或路径来体现数据之间的联系。虽然如今已很少独立使用，但其设计思想对理解现代数据库仍有启发意义。

3.2.1 核心原理：树与图的组织方式

层次模型使用树形结构表示实体及其联系。在层次模型中，有且仅有一个节点无父节点（根节点），其他节点有且仅有一个父节点。父子节点之间是一对多（1:N）的联系。层次模型的数据操作需要按照从根开始的路径进行，存取路径是预先定义好的，因此数据访问效率较高，但灵活性较差。

网状模型使用有向图结构表示实体及其联系。与层次模型不同，网状模型允许一个节点有多个父节点，且两个节点之间可以有多条联系。网状模型能够直接表示多对多（M:N）的联系，数据访问路径更加灵活，但用户必须熟悉系统的内部结构，编程复杂度较高。

3.2.2 判断方法：识别模型类型

判断一个数据模型是层次还是网状，主要看两点：

根节点数量：若整个结构只有一个根节点，且每个非根节点只有一个父节点，则为层次模型；若存在多个无父节点的节点，或某个节点有多个父节点，则为网状模型。
联系类型：层次模型只能表达1:N联系（树形），网状模型可以表达M:N联系（图结构）。

3.2.3 案例拆解：IMS与DBTG系统对比

IBM的IMS（Information Management System）是层次模型的典型代表，而DBTG（Database Task Group）提案是网状模型的经典规范。以“学校-系-教师-学生”为例：

层次模型（IMS）：学校为根，系为第一层子节点，教师和学生为第二层子节点。查询“某学生的教师”必须从学校→系→教师→学生逐层遍历，路径固定。
网状模型（DBTG）：教师和学生可以分别与系建立联系，学生也可以直接与教师建立“指导”联系，形成多对多的网络结构。查询路径可以灵活选择，但需要编写复杂的导航式代码。

从性能上看，层次模型和网状模型在特定查询下效率很高，因为存取路径是预定义的。但它们的致命弱点是数据独立性差——应用程序必须知道数据的物理存储路径，一旦数据结构改变，应用程序也必须修改。

3.2.4 常见误区与总结复盘

经验提醒：层次模型和网状模型虽然已不是主流，但“导航式”查询思想在现代图数据库（如Neo4j）中仍有体现。理解它们的优缺点，有助于解释为什么关系模型最终成为市场主流。

总结：层次模型结构简单、查询高效但灵活性差；网状模型灵活性强但用户负担重。两者都因数据独立性不足而逐渐被关系模型取代。

3.3 关系模型：现代数据库的基石

关系模型由E.F. Codd于1970年提出，它基于严格的数学理论——集合论和关系代数。关系模型使用二维表（关系）来组织数据，通过外键来体现实体之间的联系，具有高度的数据独立性和非过程化的数据操作方式。

3.3.1 核心原理：二维表与关系运算

关系模型的核心概念包括：

关系（Relation）：一张二维表，每行是一个元组（记录），每列是一个属性（字段）。
主键（Primary Key）：唯一标识一个元组的属性或属性组。
外键（Foreign Key）：引用另一个关系主键的属性，用于建立表之间的联系。
关系完整性：包括实体完整性（主键非空且唯一）、参照完整性（外键值必须存在或为空）和用户定义完整性（业务规则）。

关系模型的操作采用集合运算（并、交、差）和关系运算（选择、投影、连接、除），用户只需描述“做什么”，而不需要指定“怎么做”。SQL语言正是基于关系模型设计的。

3.3.2 判断方法：关系模型的优势识别

判断一个数据库系统是否基于关系模型，可以检查以下特征：

数据以二维表形式呈现，表间通过外键关联。
支持SQL语言进行数据定义、操纵和控制。
数据独立性高，逻辑结构与物理存储完全分离。
支持集合级操作，而非逐条记录处理。

3.3.3 案例拆解：关系模型解决数据冗余问题

以“订单管理”为例，非关系模型（如层次模型）可能需要为每个客户重复存储订单信息，导致大量数据冗余。关系模型通过规范化设计（如第三范式）将数据拆分为客户表、订单表、产品表，并通过外键关联：

-- 客户表
CREATE TABLE Customer (
    CustID INT PRIMARY KEY,
    CustName VARCHAR(50)
);
-- 订单表
CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    CustID INT,
    OrderDate DATE,
    FOREIGN KEY (CustID) REFERENCES Customer(CustID)
);
-- 查询某客户的所有订单
SELECT * FROM Orders WHERE CustID = 1001;

这种设计消除了数据冗余，保证了数据一致性，同时通过JOIN操作可以灵活地组合数据，满足各种查询需求。

3.3.4 常见误区与总结复盘

  重点提示：关系模型并非没有缺点。对于复杂的关系网络（如社交图谱）或高并发读写场景，关系模型的JOIN操作可能成为性能瓶颈。此时，NoSQL数据库（如文档型、图型）可能更合适。但在绝大多数企业级事务处理系统中，关系模型依然是首选。

总结：关系模型以集合论为基础，提供了高度的数据独立性和非过程化的操作方式，是当前数据库技术的主流。

3.4 三种逻辑模型的综合比较与选型

为了更直观地对比层次模型、网状模型和关系模型，下表从多个维度进行了系统比较：

比较维度	层次模型	网状模型	关系模型
数据结构	树形（有序）	有向图（无序）	二维表（无序）
联系表示	1:N（父子）	1:N 和 M:N	通过外键（1:N、M:N均可）
数据操作	导航式（路径固定）	导航式（路径灵活）	非过程化（集合操作）
数据独立性	物理独立性差	物理独立性差	物理和逻辑独立性均高
用户友好性	低（需了解结构）	低（需了解结构）	高（SQL声明式）
典型系统	IMS	DBTG、IDMS	Oracle、MySQL、SQL Server
适用场景	结构固定、层次清晰的业务	复杂网络关系（早期）	绝大多数企业级应用

3.4.1 选型判断流程

在实际数据库设计中，选择哪种逻辑模型通常遵循以下判断流程：

需求分析：明确数据量、并发量、事务要求、查询复杂度。
关系评估：若实体间关系简单且固定，层次模型可考虑；若关系复杂且多变，关系模型是安全选择。
团队能力：关系模型有成熟的SQL标准和大量人才储备，维护成本低。
扩展性：关系模型支持规范化设计，易于扩展和重构。

3.4.2 实战场景：从层次模型迁移到关系模型

某银行早期使用IMS系统管理客户账户，随着业务发展，客户与账户之间出现了多对多关系（一个客户多个账户，一个账户多个客户），层次模型难以表达。迁移到关系模型后，通过客户表、账户表、客户账户关联表，轻松解决了问题，且新业务上线时间从数周缩短到数天。这个案例说明，关系模型在应对业务变化时具有显著优势。

3.4.3 常见误区与总结复盘

风险提示：不要盲目追求“最新”模型。虽然NoSQL在某些场景下性能优异，但关系模型在事务一致性（ACID）、数据完整性、标准化方面依然不可替代。选型应基于业务需求，而非技术潮流。

总结：层次模型和网状模型是数据库技术的先驱，关系模型是当前的主流。理解三者的演进逻辑，有助于在未来的数据库选型中做出理性决策。

本章系统梳理了数据模型的三个层次和三种经典逻辑模型。概念模型是沟通的桥梁，逻辑模型是设计的核心，物理模型是性能的保障。层次模型和网状模型虽然历史意义重大，但关系模型凭借其坚实的理论基础和极高的数据独立性，成为现代数据库的主流。掌握这些知识，您将能够更深入地理解后续的SQL语言、数据库设计和性能调优内容。