简介：《数据库原理（第四版）》课件面向数据库课程初学者与需要夯实理论基础的从业人员，围绕数据库系统开发全流程和核心理论展开，重点帮助读者理解数据模型的设计与实现。压缩包内仅含1个PPT文件，约289KB，体量轻便，适合课堂演示、期末复习与自学查阅。已有168人学习。课件从需求分析、概念结构设计、逻辑结构设计、物理结构设计到数据库实施逐步展开，并梳理数据字典、数据独立性等基本概念；在数据模型部分比较概念模型、层次模型、网状模型与关系模型，其中网状模型讲得较细，涵盖记录类型、字段、父子联系、排序字段与码字段、一对多联系表达、多对多联系分解，以及查询、插入、删除、更新和DBTG完整性约束，并配有学生、宿舍、教师、教研室等图示，便于把抽象结构对应到现实关系。

1. 别急着通读：先给数据库原理（第四版）课件定一个使用场景

很多人的习惯是从第一页翻到最后一页，翻完绪论就搁下了，过两周只记得「数据模型」四个字。这套数据库原理（第四版）课件更适合反着用：带着一个具体的设计问题进去，比如「一个系里有教师、教研室、学生、宿舍，这几组关系该画成什么结构」，再让课件 1.2 节的数据模型部分来回答。它覆盖第一章到第十章，前几章把开发步骤、概念模型、层次/网状/关系三种模型讲得比较细，网状模型那一节连数据操纵、完整性约束、四种存储链接方式都列了出来，属于少见的把老模型讲完整的材料。它适合两类人：一类是要做课程设计、需要把模型定义和约束条件写准的学生；另一类是工作几年、只熟关系型数据库，想弄明白「多双亲」「路径语义」「属籍类别」这些词到底指什么的后端或数据开发。

2. 从概念模型到三种数据模型：选型这道题，课件给了结论没给判据

课件 1.0 到 1.2 的编排顺序本身就是一条设计流水线：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施，然后才进入数据模型的定义。1.2 节正好卡在「概念结构设计」和「逻辑结构设计」之间，很多读者把它当成名词解释背，结果背完还是不知道手里那个业务该选哪种模型。这一章的用法是把课件当判据库：先用概念模型把现实世界抽干净，再拿三种模型的特征去比对，而不是先选模型再硬套业务。

2.1 概念模型先落地：把一段需求文字拆成实体、属性、联系三栏

课件把概念模型放在 1.2.1，只给了定义，没给操作步骤。我一般会按下面这个顺序把一段需求文字拆开，拆完再回头看课件里「实体型用记录类型描述、属性用字段描述、联系用结点间连线」这句话，会顺很多。

1. 圈出需求描述里的名词，去掉「系统」「模块」「功能」这类空词，剩下的作为候选实体。
2. 圈出数量词和描述性短语，比如「一个教师只属于一个教研室」「一门课可以被多个学生选」，这些是属性或基数约束。
3. 圈出动词，判断它是实体自身的属性变化，还是两个实体之间的关系。
4. 对每个关系标注基数：一对一、一对多、多对多，这一步决定了后面能不能直接用某一种模型。

拿「某高校教务场景」举例，一段两百字的需求能拆成下面这张表：

这张表的价值在于：它不依赖任何 DBMS。概念模型阶段只回答「现实世界长什么样」，一旦开始问「这条联系用指针还是用外键表示」，就已经进入逻辑结构设计了。课件把这两步分开讲，很多人读的时候合并成一步，后面选型就会乱。血泪经验是：概念模型里出现「多对多」三个字，逻辑设计阶段就一定要处理，跑不掉。

2.2 层次、网状、关系三种模型，边界在「一个结点能有几个双亲」

课件 1.2.4 到 1.2.6 依次讲层次、网状、关系。三者的差别不在「谁先进」，而在结构约束上。层次模型是一棵树，每个结点最多一个双亲，所以它只能直接表达一对多；网状模型放宽了两条：允许一个以上的结点没有双亲，允许一个结点有多个双亲，于是它能直接表达更复杂的父子关系，层次模型反而成了网状模型的一个特例；关系模型换成二维表，联系不靠指针靠值匹配，多对多通过中间表解决。

判断顺序可以固定成三步，熟练之后看一眼 E-R 图就能出结论：

• 第一步看联系基数。只要存在多对多，层次模型和网状模型都不能直接表达，必须拆成一対多。课件在网状模型那节写得很直白：用网状模型间接表示多对多联系，方法是将多对多联系直接分解成一对多联系。
• 第二步看导航需求。业务查询是不是强依赖「从父到子按路径走」，比如从系到教研室到教师，每次查询都沿着固定层级下钻。如果是，网状模型的存取效率优势才成立；如果查询条件千变万化，关系模型的声明式查询更省事。
• 第三步看维护成本。课件在网状模型优缺点里写了两条：结构比较复杂，随应用环境扩大而越来越复杂，不利于最终用户掌握；DDL、DML 语言复杂，用户不容易使用。这两条不是套话，它直接决定后期加一个实体要改多少条链接。

一个反直觉的结论：网状模型「存取效率高」这句话只在路径固定的场景下成立。一旦业务要求临时组合条件查询，导航式操纵的代价会迅速吃掉那点效率优势，这也是关系模型后来居上的现实原因。把这句话想清楚，课件里那段优缺点就不用死记了。

2.3 用一张对照表做逻辑结构设计的第一轮筛选

把三种模型放在同一张表里比，比逐段读定义快得多。下表是我按课件内容整理的第一轮筛选依据，参数都来自课件原文，没有额外加戏：

用这张表做筛选的流程是：先把概念模型里的多对多全部标红，标红的关系必须拆；再看剩余关系里有没有「一个子女多个双亲」，有就排除层次模型；最后看查询模式，是否需要临时条件组合，需要就选关系模型，不需要再考虑网状。课件在 1.2.3 只列了「最常用的数据模型」有哪些，没给这张判据表，补上之后选型就不再是玄学。

3. 网状模型的两个判定条件：把「多双亲」画成可检查的邻接表

课件 1.2.5 开篇给的定义很短：满足两个条件的基本层次联系的集合为网状模型，一是允许一个以上的结点无双亲，二是一个结点可以有多于一个双亲。定义短，但真正画图的时候，很多人会把「多对多」和「多双亲」混为一谈，画出来的结构既不是网状也不是关系。这一章把定义翻译成可以逐条打勾的检查项。

3.1 两个条件到底在限制什么

第一个条件针对根结点。层次模型只有一个根，网状模型允许多个结点没有双亲，等于允许多棵树共存于一个结构里。课件配的示意图里，R1、R2 都是没有双亲的结点，它们各自往下挂 L1、L2 之类的子女。第二个条件针对双亲数量，一个结点可以同时挂在两个父结点下面。这两条合起来，网状模型就从「树」变成了「有向图」。

课件还列了网状模型与层次模型的四点区别，其中一条容易被忽略：网状模型允许两个结点之间有多种联系，也就是复合联系。举例来说，同一个人结点和树结点之间，可能同时存在「种植」和「砍伐」两条联系，两条联系的语义完全不同。层次模型做不到这一点，一条连线只能有一种含义。

表示方法沿用了层次模型那一套：实体型用记录类型描述，每个结点是一个记录类型；属性用字段描述，一个记录类型可以包含若干字段；联系用结点之间的连线表示记录类型之间一对多的父子联系。注意最后半句，连线本身只承载一对多，多对多必须另想办法。这是网状模型最容易翻车的地方，下一节专门拆。

判断一个结构是不是网状模型，我会跑三遍检查：数一数没有双亲的结点是不是超过一个；数一数有没有结点的双亲数量大于一；看任意两个结点之间是不是存在两条以上语义不同的连线。三条里中任意一条，层次模型就不适用了。

3.2 多对多拆成一对多的三步走

课件给的方法是「将多对多联系直接分解成一对多联系」，只有一句话。落到操作上，我一般分三步，拿「学生选课」这个经典多对多来演示：

1. 为多对多联系新建一个记录类型，把它当成连接结点。选课这件事本身不是学生也不是课程，单独建一个「选课」记录类型。
2. 把两侧实体的码字段带进连接记录类型。选课记录里放入学号和课程号，这两个字段在网状模型里通常就是排序字段。
3. 连接记录类型分别与两侧建立一对多联系，连接侧永远是子女。学生到选课是一对多，课程到选课也是一对多，两条连线方向都指向连接结点。

拆完之后，原本的多对多消失了，结构变成两个一对多，符合课件里「只能直接处理一对多的实体联系」这条特点。同样的手法可以用在学生与宿舍、教师与课程之间。下面这段 Python 用来把画好的结构跑一遍检查，确认三条判定条件是否满足，避免手画的时候漏掉某个双亲：

# 用邻接表描述课件里的网状结构：key 是记录类型，value 是它的双亲子结点列表 graph = { "学生": [], # 无双亲，允许 "课程": [], # 无双亲，允许 "选课": ["学生", "课程"], # 两个双亲，允许 "教师": ["教研室"], "教研室": ["系"], "系": [], } def check_network(g): roots = [n for n, parents in g.items() if len(parents) == 0] multi_parent = {n: len(p) for n, p in g.items() if len(p) > 1} # 条件一：允许一个以上结点无双亲 cond1 = len(roots) >= 2 # 条件二：允许结点有多个双亲（存在即可，不要求每个都有） cond2 = len(multi_parent) >= 1 print(f"无双亲结点: {roots}") print(f"多双亲结点: {multi_parent}") print(f"条件一={cond1} 条件二={cond2}") return cond1 and cond2 check_network(graph)

这段代码没有依赖任何库，直接跑就能看到输出。graph的 key 是记录类型，value 是双亲列表，跟课件里「连线表示一对多父子联系」的约定一致。roots统计没有双亲的结点数量，对应第一个条件；multi_parent统计双亲数大于一的结点，对应第二个条件。参数改起来很简单：加一个实体就往字典里加一个 key，加一条联系就往对应 value 里塞一个双亲名。跑一遍就能知道自己画的图到底是不是网状模型，比盯着课件上的示意图肉眼比对靠谱。

3.3 排序字段与路径语义：为什么记录值离开路径就没意义

课件在网状模型的数据结构特点里写了两句话，第二句是「每个记录类型定义一个排序字段，也称为码字段」，第三句是「任何记录值只有按其路径查看时，才能显出它的全部意义」。这两句连起来读，才明白网状模型的存储逻辑：记录本身不携带完整语义，语义由它在链路中的位置决定。

举个课件里的例子，父母、子女、树、种植、砍伐这几个记录类型挂在同一个结构里。同样一个「人」记录，从「父母—子女」这条路径看，它是某个家庭的孩子；从「种植—砍伐」这条路径看，它又是某棵树的操作者。记录里的字段可能只有姓名和编号，光看这条记录值，根本判断不出它在业务里扮演什么角色。

这带来两个实操后果。第一，路径查询必须写全链路，不能只给目标记录类型。第二，排序字段的设计要跟路径绑定，同一个双亲下的子女用排序字段定顺序，跨双亲就没有可比性。课件提到「按路径查看」，本质是要求查询语句携带完整的导航信息，这跟 SQL 里一条 SELECT 加 WHERE 完全不是一回事。

导航式查询的步骤通常是固定的：先用码字段定位到起始记录，再沿着某条联系向下走到目标记录类型，最后在当前记录上读取字段。如果中途换一条路径，即使落到同一个记录类型，读到的语义也可能不同。我一般会在设计文档里给每条路径单独编号，写清楚起点、经过的联系、终点，避免后期维护的人凭字段名猜语义。这一步没什么技术含量，但省下来的排查时间相当可观。

4. 数据操纵与完整性约束：把 DBTG 那套规则翻成检查清单

课件 1.2.5 的第 2 到第 4 小节，分别讲数据操纵、完整性约束、存储结构。三节内容都不长，但名词密度高，自学时最容易一晃而过。这三节的正确读法是当成一份操作规范来看：操纵决定动作顺序，约束决定哪些动作允许发生，存储结构决定这些动作在执行时付出多少代价。三者是连着的，拆开读就没味道了。

4.1 四种操纵与执行顺序

课件列的数据操纵只有四个词：查询、插入、删除、更新。看起来跟关系模型差不多，但执行前提完全不同。关系模型的插入只要满足约束就能直接写，网状模型是导航式的，插入之前必须先定位双亲，因为新记录的物理位置要挂到某条链路上。

按课件的完整性约束那节反推，一次插入的完整动作序列是：先找到目标双亲记录，确认当前记录位置；再在双亲下按排序字段确定新记录的插入位置；最后建立链接指针。删除的动作更麻烦，课件明确写了「允许只删除双亲结点值」，意思是双亲可以单独删掉，子女记录留在原地，链接关系断开。这个规则在关系模型里是不可想象的，外键约束会直接拦住。

更新操作在网状模型里要区分两种：改字段值，和改属籍关系。改字段值就是普通更新，改属籍关系相当于把一条子女记录从某个双亲下面移到另一个双亲下面，中间涉及断链和重新挂链。这一层差异课件没有展开，但只要记住「网状模型里记录的位置是结构的一部分」，就能推出来。

我把四种操纵的检查点整理成下面这张表，做课程设计或者写设计文档时可以直接拿去对照：

4.2 属籍类别：加入类别与移出类别的组合

属籍类别是这套课件里名词感最强的一节，也是最能体现网状模型设计思想的一节。课件把它拆成两个维度：加入类别分自动和手工，移出类别分固定、必须、随意。两个维度组合出六种情况，每一种都对应一种业务约束。

「自动」和「手工」的差别在于插入子女记录时，系统是否自动把它挂到某个双亲下；「固定」和「必须」的差别在于脱离的严格程度，固定是完全不允许，必须是不允许没有双亲但允许换双亲。这三个移出类别在课件里是以括号形式给出的，读的时候很容易略过，实际设计时它们直接决定了一条记录能不能被孤立。

课件还给了两条看起来很奇怪的规定：允许插入尚未确定双亲结点值的子女结点值；允许只删除双亲结点值。放到关系模型里，这两条都会被外键约束拦下。网状模型之所以宽松，是因为它的插入和删除本来就是分步的，先建子女后挂双亲是常见流程，强行要求引用完整性反而会让操作没法进行。理解这一点，就不会拿关系模型的外键思维去套属籍类别。

4.3 四种链接方式与取舍

课件在存储结构那节给了一个关键判断：网状模型存储结构的关键是实现记录之间的联系，常用方法有单向链接、双向链接、环状链接、向首链接。四种方式的差别全在指针的数量和方向，直接决定遍历代价。

取舍逻辑不复杂：查询只向下走，单向最省空间；需要沿兄弟记录顺序翻页，双向更顺；系内记录首尾要互达，用环状；子女经常要反查自己挂在哪个双亲下，向首链接能省一次全链遍历。代价体现在插入和删除上，指针越多，断链和重连的步骤越多，出错概率也越高。

我一般会先按查询模式定主链接方式，再对少数高频反查的系单独加向首指针。全部用双向链接是最省心的做法，空间代价在现代存储条件下基本可以忽略，但课件那个年代的存储是真金白银，所以它把四种方式并列讲，而不是直接推荐一种。读这一节要带着年代感，不然会觉得这些取舍没必要。

5. 避坑：自学这套课件最容易翻车的五件事

课件内容本身没大问题，翻车基本发生在理解层面。下面五条是我见过最多的，每条按现象、原因、解决写，遇到对应症状可以直接对号。

第一坑：把「网状模型能表示多对多」当成直接支持。现象是画图时直接在学生和课程之间连一条线，然后声称这是网状模型。原因是把「能表示」和「直接处理」混了，课件原文是「只能直接处理一对多的实体联系」，多对多必须间接表示。解决办法是回到 3.2 节的三步拆解法，任何多对多先建连接记录类型，拆完再检查两个条件。判断标准很简单：如果结构里还有一条连线两侧都是多对多，就没拆干净。

第二坑：把排序字段当成主键。现象是设计文档里写「排序字段唯一标识一条记录」，然后拿它当全局唯一 ID 用。原因是没注意排序字段的作用域，课件说的是「每个记录类型定义一个排序字段」，它的排序意义只在同一个双亲的子女集合内成立，跨双亲没有可比性。解决办法是把排序字段和全局标识分开设计，排序字段只负责系内顺序，需要全局定位时另设一个码字段。

第三坑：用外键思维理解属籍类别。现象是看到「允许只删除双亲结点值」就认为课件写错了，或者认为这套约束不严谨。原因是拿关系模型的引用完整性去套导航式模型，两者的操作粒度不同。解决办法是把属籍类别当成一套状态机来读：加入类别决定初始挂载方式，移出类别决定允许的状态转移，两条宽松规定是给分步操作留的余地。设计时先想清楚每条记录允许哪些状态，再选对应的类别组合。

第四坑：跳过 1.0 的开发步骤直接看数据模型。现象是数据模型的定义能背，但拿到需求不知道从哪下手。原因是课件 1.0 那节列的五个步骤是整本书的骨架，概念模型、逻辑模型、物理模型分别对应其中一步，跳过去之后各个模型就变成了孤立的名词。解决办法是先花二十分钟把 1.0 的流程图在纸上重画一遍，标清楚每个模型出现在哪一步，再回头读 1.2，路径会清晰很多。

第五坑：把课件的年代背景当成技术缺陷。现象是读到「DDL、DML 语言复杂，用户不容易使用」就下结论说网状模型没用，然后整节跳过。原因是忽略了课件写的是历史模型的技术特征，它的价值在于解释「为什么后来的数据库长成现在这样」。解决办法是把优缺点那节当成演化线索来读，每一条缺点对应关系模型的一个设计选择，比如导航式复杂对应声明式查询，结构僵硬对应表结构可扩展。这样读，网状模型这一节反而成了理解关系模型优势的最短路径。

6. 把课件跑成自己的东西：三个自测题和一套笔记法

课件读完不等于会用，检验标准是能不能在没有原文的情况下把结构画出来并解释每条约束。我一般用三个自测题做验收，每题对应课件里的一节，答不上来就回去重读那一节。

第三题最难，也最能暴露理解深度。判断依据是业务规则而不是技术偏好，比如教师与教研室之间选「自动 + 固定」，理由是人事制度上教师必须有归属且不随意调动；学生与宿舍之间选「手工 + 必须」，理由是入住需要人工登记但允许换宿舍。答不出理由，说明属籍类别那节还是背下来的。

笔记法上，我习惯给每个数据模型建一张三列卡片：结构约束、操纵方式、典型代价。结构约束写这个模型允许什么不允许什么，操纵方式写增删改查的动作顺序，典型代价写它在什么场景下会变慢或者变复杂。三列填满，一个模型就算吃透了。这套方法用在课件 1.2 的三节上，一张 A4 纸就能装下层次、网状、关系三个模型的全部要点，比抄课件省事得多。

从那以后我每次带人读这套课件，都强制让对方先做第二题再翻 1.2.5，画不出来就不许往下看完整性约束。因为结构画不对，后面的约束和存储结构全是空中楼阁，读得再细也落不了地。希望帮到你。

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