网状数据库模型原理与现代启示：导航式存储的兴衰逻辑

简介：本资源是《数据库原理（第四版）》配套教学课件，面向高校计算机、软件工程及信息管理类专业本科生与数据库初学者，系统解决数据库基础理论与核心模型理解难题。课件以PPT格式呈现，共1个文件，大小289KB，内容覆盖从第一章绪论到第十章的完整知识链，重点剖析数据模型（尤其网状模型）的结构设计、数据操纵（查询/插入/删除/更新）、完整性约束（DBTG规范）、存储实现及典型系统案例，辅以学生-宿舍-教师、家庭关系等多组图示化实例，直观展现网状模型支持多父节点、一对多联系及复杂现实映射的能力。目前已有168人学习下载，内容理论扎实、图例丰富、逻辑递进，既可作为课堂补充材料夯实概念，也适合自学梳理数据库系统开发全流程（需求分析→概念/逻辑/物理设计→实施），为后续关系模型、SQL及数据库优化学习奠定坚实基础。

1. 网状模型：为什么一个节点能有多个“父亲”，却反而比关系模型更难被现代系统采用？

你可能刚学完关系模型——三范式、主外键、SQL 一行JOIN就能连起学生和课程，逻辑干净得像教科书。但翻到《数据库原理（第四版）》课件第一章的网状模型部分，突然看到一张图：一个“教师”节点同时连着“教研室”和“学生”，而“学生”又连着“宿舍”和“系”，甚至“父母”节点下挂着两个“子女”，还标着“多对多联系需拆成中间记录类型”……第一反应是：这不就是个带环的树？怎么还能叫“模型”？更奇怪的是，课件里明明白白写着：“网状模型性能高、存取效率好”，可现实中几乎没人用 IDMS 或 DMS1100 这类网状数据库了。矛盾就在这里：它底层结构更贴近现实、物理访问路径更直接、没有连接开销，却在工程实践中被关系模型全面取代。这不是技术退步，而是数据建模的抽象层级发生了根本迁移——网状模型把“如何存”和“如何查”死死绑在一起，把导航式访问变成了模型本身的一部分。理解它，不是为了回去写 DBTG DDL，而是为了看清今天 ORM 的 N+1 问题从哪来、为什么图数据库要重新发明“遍历”、甚至为什么某些嵌入式数据库仍悄悄用着网状思想。这份课件的价值，正在于它用最原始的笔触，画出了数据库抽象演进的“断层线”。

2. 网状模型的数据结构：不是图论意义上的图，而是带约束的导航式记录网络

网状模型常被误称为“图模型”，但课件第 1.2.5 节反复强调：它本质是记录类型（Record Type）与系属类别（Set Type）构成的受限网络。它的“节点”不是任意对象，而是强类型的记录；它的“边”不是泛化关系，而是预定义的、单向的父子隶属（Owner-Member）链接。这种设计不是数学妥协，而是 1970 年代硬件限制下的工程最优解：磁盘寻道慢、内存小、CPU 弱，与其让数据库运行时动态解析关系，不如在模式定义阶段就把访问路径固化下来。

2.1 记录类型与系属类别的二元绑定

课件中所有示意图都遵循同一范式：矩形框代表记录类型（如R1,L1,学生,教师），连线标注R1→L1表示“R1 是 L1 的双亲”。但关键细节藏在文字里：“每个记录类型定义一个排序字段（码字段）”，且“任何记录值只有按其路径查看时，才能显出它的全部意义”。这意味着：

• 一个学生记录本身不携带系名称，只存系编号；
• 要获取该学生的系名，必须先通过学生→系这条系属路径导航到系记录，再读其系名称字段；
• 没有路径定义，字段值就是无意义的字节串。

这直接导致网状模型的 DML 必须是导航式语言（如 DBTG 的FIND,GET,STORE,MODIFY），而非声明式语言。下面这段伪代码展示了典型操作：

/* DBTG 风格伪代码：查找某教师所带的所有学生 */ FIND FIRST teacher WITH teacher_id = 'T001' *> 定位教师记录 FIND FIRST student OF teacher_set *> 进入 teacher_set 系属集合 PERFORM UNTIL END OF SET DISPLAY student_name, student_id *> 读取当前学生 FIND NEXT student OF teacher_set *> 导航到下一个学生 END-PERFORM

提示：这里的teacher_set不是 SQL 中的视图或表别名，而是模式中预先声明的系属类别（Set Type），它强制规定了teacher（Owner）与student（Member）之间的物理存储顺序和指针关系。编译时，DBTG 预处理器会将FIND NEXT student OF teacher_set编译为直接的磁盘块偏移计算，跳过索引查找。

2.2 多父节点的实现：双向指针链与存储碎片化代价

课件图示中R1同时是L1和L2的双亲，L3又同时属于R1和R2。这看似灵活，实则暗藏存储陷阱。课件第 1.2.5 节“4. 网状数据模型的存储结构”指出，实现多父依赖常用“双向链接”或“环状链接”，但每种方案都带来结构性成本：

• 双向链接：每个L3记录需存储两个指针——一个指向R1，一个指向R2。当R1被删除时，系统必须遍历所有L3记录，将其R1指针置空，否则留下悬垂指针；
• 环状链接：R1→L3→R2→L3→R1形成闭环。插入新L3时，需原子更新R1、R2、L3三个记录的指针域，事务控制复杂度陡增；
• 存储碎片化：为维持导航效率，同类L3记录常被分散存储在不同磁盘块（靠近其双亲），导致顺序读取L3全集时产生大量随机 I/O。

这解释了课件中“优点：性能高”与“缺点：结构复杂”的并存——高性能仅针对预定义路径的访问，一旦查询需求偏离建模时设定的系属关系（例如：统计所有L3记录中R1和R2的联合属性），就必须进行昂贵的全表扫描或跨系属遍历。

2.3 多对多联系的“降维”：用记录类型充当关系实体

课件明确指出：“多对多联系在网状模型中需分解成一对多联系”。这不是权宜之计，而是模型不可逾越的边界。因为网状模型不允许记录类型之间存在非系属的直接关联。以“学生-课程”多对多为例，课件示意必须引入中间记录类型选课：

学生 ──(belongs to)── 选课 ──(belongs to)── 课程 ↑ ↑ (owner) (owner)

这里选课不是关系模型中的“关系实例”，而是具有完整字段的独立记录类型（含学号、课号、成绩等）。其物理存储策略课件未详述，但根据 DBTG 规范，常见做法是：

• 将选课记录按学号排序，链入学生的选课_set；
• 同时按课号排序，链入课程的选课_set；
• 一个选课记录因此成为两个系属集合的成员，需维护两套指针。

这种设计使“查询某学生所有课程”和“查询某课程所有学生”都极快，但“查询某专业所有学生选修的课程分布”却需遍历该专业下所有学生，再逐个遍历其选课_set——典型的 N² 复杂度。这正是课件强调“不利于最终用户掌握”的根源：业务逻辑被硬编码进存储结构，变更即重构。

3. 网状模型的数据操纵：导航即语法，路径即契约

在关系模型中，SELECT * FROM students JOIN courses ON ...是对数据语义的描述；而在网状模型中，FIND FIRST student; FIND FIRST course OF student_course_set是对磁盘上字节流的物理定位指令。课件第 1.2.5 节“2. 网状模型的数据操纵”仅列出“查询、插入、删除、更新”四词，但背后是整套与存储紧耦合的操作语义。理解它，是读懂课件中所有 DML 示例的前提。

3.1 查询：从“找记录”到“走路径”的思维转换

网状查询的起点永远是一个已知键值的记录（如FIND teacher WITH id='T001'），后续所有操作都基于此记录的系属关系展开。课件图示中学生→宿舍→教师的链式结构，对应的实际操作序列是：

FIND FIRST student WITH stu_id = 'S001' *> 定位学生 FIND FIRST dormitory OF student_dorm_set *> 进入学生-宿舍系属 FIND FIRST teacher OF dorm_teacher_set *> 从宿舍进入教师系属（注意：此路径需在模式中明确定义） DISPLAY teacher_name

关键点在于：dorm_teacher_set这个系属类别必须在数据库模式中预先声明，且dormitory记录类型必须作为其 Owner。如果业务需要“从教师反查其管理的宿舍”，就必须额外定义teacher_dorm_set，并确保teacher是 Owner、dormitory是 Member——每条反向路径都是独立的、需单独维护的存储契约。

注意：这种路径依赖导致网状模型天然缺乏“关联发现”能力。关系模型中JOIN可自由组合任意表，而网状模型中，未定义的路径等于不存在。这也是为何课件强调“只能直接处理一对多的实体联系”——多对多需中间记录，一对多是唯一原生支持的拓扑。

3.2 插入与删除：完整性约束的硬性落地

课件第 1.2.5 节“3. 网状数据模型的完整性约束”提到 DBTG 系统的限制，其核心是系属关系的生命周期管理。插入一个student记录时，系统不只校验字段格式，更检查其是否满足所属系属集合的约束：

• 若student属于department_student_set，则必须提供有效的dept_id（作为 Owner 的department记录必须存在）；
• 若该系属定义为MANDATORY（必须的），则student不能孤立存在，必须挂载到某个department下；
• 若定义为AUTOMATIC（自动的），则插入student时，系统自动将其加入第一个可用的department（需预设规则）。

删除操作同理。课件指出“允许只删除双亲结点值”，意味着可执行DELETE department，此时系统行为取决于系属约束：

• 若department_student_set定义为FIXED（固定的），则删除前必须先清空所有下属student；
• 若为MANDATORY（必须的），则删除department会导致所有student记录失效（或触发级联删除）；
• 若为ARBITRARY（随意的），则student记录可保留，但其dept_id指针变为悬垂。

这种约束不是 SQL 中的ON DELETE CASCADE，而是存储引擎层面的强制动作，由 DBTG 的SET语句在模式定义时指定。例如：

CREATE SET department_student_set OWNER IS department MEMBER IS student MANDATORY AUTOMATIC;

此语句编译后，会生成对应的指针维护逻辑，嵌入到所有INSERT/DELETE的执行路径中。

3.3 更新：字段修改背后的指针重连

网状模型的UPDATE比关系模型更危险。课件未展开，但 DBTG 规范要求：若更新涉及排序字段（码字段），则可能触发物理记录移动。例如：

• student记录的stu_id是排序字段；
• 将stu_id='S001'改为S999，若新值在物理存储中应位于文件末尾，则系统必须：
  1. 从原位置读取整个student记录；
  2. 在新位置写入；
  3. 更新所有指向该记录的指针（包括其department的student_set链、所有course的student_course_set链等）。

这解释了课件中“DML 语言复杂”的深层原因：开发者必须时刻意识到，一次字段更新可能引发跨多个系属集合的指针重连，而这些细节本应由存储引擎隐藏。

4. 网状模型的存储结构：指针即索引，链表即查询计划

课件第 1.2.5 节“4. 网状数据模型的存储结构”仅列出“单向链接、双向链接、环状链接、向首链接”四个术语，并引用“P29 例”。这页纸背后，是网状数据库性能的全部秘密：它把索引结构直接编码进记录本身，让每一次导航都变成 O(1) 的指针解引用。理解这四种链接方式，就是理解为何 IDMS 在 1970 年代能碾压早期关系系统。

4.1 单向链接：最简实现与路径锁定

单向链接是网状存储的基石。课件图示中R1→L1→L2的箭头，对应物理存储中每个L1记录末尾的一个指针域，指向下一个L1（同属R1）的磁盘地址。其结构如下：

• next_L1_ptr是 4 字节或 8 字节的绝对地址（如0x000A3F20）；
• 查找R1下第 5 个L1，需从R1的first_L1_ptr开始，连续解引用 4 次指针；
• 优势：插入/删除只需修改相邻指针，O(1) 时间；
• 劣势：反向遍历（从最后一个L1找第一个）需全链扫描，O(n) 时间。

这决定了网状模型的查询必须严格按预设方向导航。课件中所有FIND NEXT操作，本质都是在遍历这条单向链。

4.2 双向链接：空间换时间的典型权衡

为支持双向遍历，DBTG 允许在记录中增加prev_L1_ptr字段：

• 插入新L1时，需原子更新前驱的next、后继的prev、以及自身的next/prev；
• 删除时，只需修改前后节点的指针，自身记录可标记为“空闲”；
• 代价：每个L1记录增大 4~8 字节，对磁盘密集型系统影响显著（1970 年代 1MB 磁盘售价超 $10,000）；
• 更致命的是：双向链在并发环境下极易死锁。课件未提，但 DBTG 实现中，INSERT操作常需锁住整个系属集合，而非单个记录。

4.3 环状链接与向首链接：解决“首节点定位”难题

单向/双向链都面临一个问题：如何快速定位系属集合的“第一个”记录？若每次FIND FIRST都要扫描目录表，性能归零。DBTG 的解法是“向首链接”（Head Pointer Linking）：

• 每个系属集合（如teacher_student_set）在系统目录中存储一个head_ptr，指向第一个student记录；
• 该student记录的prev_ptr不指向NULL，而是指向head_ptr自身，形成环；
• FIND FIRST直接读head_ptr；
• FIND LAST则读head_ptr->prev_ptr（即环中前一个）。

环状链接（Circular Linking）则更进一步：所有student记录首尾相接，last->next_ptr = head_ptr。这使FIND NEXT在到达末尾时自动回到开头，适合循环队列类场景。但课件强调“向首链接”是 P29 例的标准解法，因其避免了环检测开销。

提示：这些指针不是逻辑地址，而是物理磁盘块号 + 块内偏移。DBTG 编译器会将FIND FIRST student OF teacher_set编译为一条机器指令：LOAD R1, [system_catalog + offset_of_teacher_student_head]。这才是课件所谓“性能较高”的硬件级真相。

5. 网状模型的避坑指南：那些课件没写的血泪经验

课件用严谨的学术语言描述了网状模型的理论框架，但真实项目中踩过的坑，往往藏在规范之外。以下是基于 DBTG 系统（IDMS/DMS1100）实际开发总结的 4 条高频翻车点，每条都对应课件中一笔带过的概念：

5.1 现象：FIND NEXT返回NOT FOUND，但FIND FIRST却能定位到记录

原因：系属集合的head_ptr正确，但首个记录的next_ptr被意外覆盖为0x00000000（常见于未初始化指针或内存越界写）。网状模型不校验指针有效性，FIND NEXT直接跳转到地址0，触发硬件异常或返回错误码。
解决：在FIND FIRST后立即检查next_ptr是否为有效地址（非0且在合法磁盘范围内）；启用 DBTG 的VALIDATE SET工具定期扫描指针链完整性。

5.2 现象：插入新记录后，原有记录的next_ptr指向乱码，导致后续遍历崩溃

原因：插入时未按 DBTG 要求的“原子更新”顺序操作。正确流程是：① 分配新记录空间；② 设置新记录的next_ptr和prev_ptr；③ 修改前驱的next_ptr；④ 修改后继的prev_ptr。若步骤③失败（如磁盘满），则前驱指针悬垂。
解决：所有插入操作必须包裹在BEGIN TRANSACTION中；使用 DBTG 的RECOVER工具回滚不完整事务；生产环境禁用AUTOMATIC插入模式。

5.3 现象：更新student的dept_id后，该学生从原department的student_set中消失，但未出现在新department的集合中

原因：dept_id是排序字段，更新触发记录物理迁移，但 DBTG 未自动更新department记录中的student_set链。课件说“允许更新双亲结点值”，但未说明需手动调用RECONNECT语句。
解决：更新排序字段后，必须显式执行RECONNECT student TO new_department IN department_student_set；将此逻辑封装为存储过程，禁止应用层直连更新。

5.4 现象：多线程并发插入同一系属集合时，出现记录丢失或指针错乱

原因：DBTG 的默认锁粒度是“系属集合级”，而非记录级。两个线程同时FIND FIRST，均获得相同head_ptr，随后各自插入，导致后一个插入覆盖前一个的next_ptr。课件未提并发控制，因早期系统多为批处理单用户。
解决：升级到支持LOCK SET的 DBTG 版本；或在应用层实现乐观锁（读取head_ptr时附带版本号，更新前校验）；终极方案：改用关系模型，让数据库引擎处理并发。

6. 为什么网状模型消亡了？不是输给了关系，而是输给了“抽象泄漏”

网状模型从未被“证伪”，它至今仍在银行核心系统（如某些 COBOL 遗留系统）、航天嵌入式数据库中服役。它的消亡，不是技术失败，而是抽象层级的必然迁移。课件将网状、层次、关系并列为“最常用的数据模型”，但未点破一个事实：层次与网状是存储模型（Storage Model），而关系是逻辑模型（Logical Model）。这个分野，决定了它们的命运。

6.1 关系模型的胜利：用声明式语言封住抽象泄漏

网状模型的每一个FIND、GET、STORE，都在暴露磁盘寻道、指针解引用、链表遍历这些物理细节。当业务需求变化（如新增“学生-导师”关系），开发者必须：

• 修改模式，定义新系属student_mentor_set；
• 修改所有相关程序，添加FIND mentor OF student_mentor_set；
• 重编译、重部署、停机验证。

而关系模型用SELECT ... JOIN ... WHERE ...一句声明，就将物理存储（B+树索引、哈希表、物化视图）完全隔离。数据库优化器自动选择访问路径——即使底层从 B+树换成 LSM-Tree，SQL 无需改动。课件中强调关系模型“数据独立性高”，其深意正在于此：它把‘如何高效存取’的决策权，从程序员移交给了数据库引擎。

6.2 网状模型的遗产：在不该抽象的地方强行抽象

有趣的是，网状思想并未消失，只是沉入了更底层。观察现代技术栈：

• ORM 框架（如 Hibernate）的@OneToMany注解，本质是课件中R1→L1系属关系的 Java 封装；
• GraphQL的嵌套查询{ user { posts { comments } } }，复刻了网状模型的导航式数据获取范式；
• 图数据库（Neo4j）的MATCH (u:User)-[r:POSTED]->(p:Post)，虽用 Cypher 声明，但底层仍依赖邻接表（Adjacency List）——即课件中“双向链接”的变体。

它们的成功，恰恰证明网状模型的直觉是正确的：对高度关联的数据，导航式访问比笛卡尔积更自然。但它们都刻意回避了网状模型的原罪：把导航路径写死在模式里。Neo4j 允许任意节点间建立关系，Hibernate 的fetch=LAZY延迟加载，都是在用运行时灵活性，弥补编译时硬编码的缺陷。

6.3 给当代开发者的启示：警惕“过度抽象”的新形态

今天，我们用微服务拆分单体，用 Kafka 解耦模块，用 Kubernetes 抽象基础设施——每一层抽象都在解决旧问题，也埋下新隐患。网状模型的教训是：当抽象开始要求你为每一个可能的访问路径预先建模时，它就不再是解放，而是枷锁。课件中那个“学生-宿舍-教师-教研室”的复杂图示，今天可能变成“用户服务 → 订单服务 → 库存服务 → 仓储服务”的调用链，而链路追踪（如 Jaeger）显示的span嵌套，竟与网状模型的导航路径惊人相似。

从那以后我每次设计领域模型，都强制走一遍“反向遍历测试”：如果删掉某个聚合根，所有下游数据是否还能通过其他路径重建？如果答案是否定的，我就知道，这里正悄悄长出一根网状模型的指针——而我的任务，不是加固它，是把它剪断，用事件溯源或 CQRS 重构数据流。希望帮到你。

本文还有配套的精品资源，点击获取