简介：这份《数据库原理（第四版）》课件面向数据库初学者与从业人员，围绕数据库系统开发流程和核心理论展开，从第一章到第十章覆盖数据库系统概述、数据模型组成要素、系统结构与组成等内容，并重点讲解概念模型、层次模型、网状模型和关系模型的设计与实现。包内共1个PPT文件，约289KB，以幻灯片形式组织章节内容，便于课堂讲授、自学翻阅和复习串联。目前已有168人学习下载。读者可据此理解需求分析、概念结构设计、逻辑结构设计与物理结构设计等环节，重点掌握网状模型的一对多父子联系、记录类型与字段表示、排序字段（码字段）的唯一性保证，以及查询、插入、删除、更新操作和DBTG完整性约束；课件还借助学生、宿舍、教师、教研室等图示说明复杂实体联系，为后续学习关系模型、SQL语言及数据库设计优化打下基础。

1. 数据库原理的知识地图：十章内容其实是一条主线

「数据库原理（第四版）课件」这门课最容易被学成碎片：概念一堆、模型三套、SQL 又是一套，考完就散。系统梳理下来会发现它其实只有一条主线——先讲数据库系统是什么（绪论、系统结构、系统组成），再讲怎么把现实世界翻译成机器能存的东西（概念模型→逻辑模型→物理存储），最后讲怎么用、怎么设计、怎么不出事（SQL、设计、恢复、并发）。适合两类人：正跟着课件从头学的，和已经学过一遍、想找一张能随时翻看复习的地图的人。第一章先把骨架立起来，后面几章逐个模块压实。

2. 开发六步与三级结构：数据库系统的骨架怎么搭

不少人把开发步骤当成背诵题，背完「需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、运行维护」六个词就过去了。真正做题、做项目时才会发现，这六步是一条信息逐级收敛的流水线：每一步的产出都是下一步的输入，任何一步偷工减料，后面都要用双倍的时间补。数据库系统结构那一节（三级模式两级映像）则是这条流水线的静态切片，一个讲「怎么造」，一个讲「造好之后长什么样」，两节合起来才是完整的骨架。

2.1 六个步骤的输入、产出与高发问题

需求分析阶段收集的不是「要建哪些表」，而是业务里有哪些对象、对象之间有什么关系、每个字段的取值范围和更新频度。产出物是数据字典和数据流图，数据字典里除了字段名和类型，更要写清码、非空约束、取值域。这一步最常见的失误是只记字段不记约束，等到逻辑设计才发现「一个学生能不能选同一门课两次」这种问题没人能回答。

概念结构设计阶段产出 E-R 图，它的关键特征是独立于任何具体 DBMS：图里不该出现索引、分区、字段长度这类存储细节。E-R 图能不能让业务方看懂，是判断这一步做没做好的土办法——如果只有你自己看得懂，那多半是把逻辑设计提前做了。

逻辑结构设计把 E-R 图转成关系模式，同时做规范化（一般到 3NF，特殊场景到 BCNF），再按用户角色划出外模式（视图）。这一步的坑集中在多对多联系上：m:n 必须单独成表，很多人图省事把联系属性塞进某一端，后面查询写得极其别扭。

物理结构设计决定存取方法和存储结构，索引建几个、建在哪几列、要不要聚簇，都在这里定。索引不是越多越好，写多读少的表上堆索引，插入性能会被拖垮，这是典型的「设计时爽、上线后哭」。

数据库实施阶段是建库建表、装载初始数据、编写应用程序、试运行。血泪经验是约束一定要在装数据之前定义好，先灌数据再补约束，等于给自己制造一场数据清洗的苦役。

运行维护阶段做备份恢复、性能监控、调优和结构调整。这一步最容易被忽略的是恢复演练——备份文件从来没被还原过，就等于没有备份。

2.2 三级模式两级映像：数据独立性到底靠什么撑住

三级模式是外模式、模式、内模式。外模式是用户看到的那部分数据的逻辑描述，一个数据库可以有多个外模式，对应不同角色；模式是全体数据的逻辑结构和特征的描述，全局只有一份；内模式描述数据的物理存储方式和存取方法。三层之间的关系不是包含，而是「视图」——外模式是模式的一个子集加派生，内模式是模式的存储实现。

两级映像才是独立性的真正来源。外模式/模式映像定义了外模式与模式之间的对应关系，当模式改变（比如加了一个字段、拆了一张表），只要调整这层映像，外模式和应用程序可以不动，这叫逻辑独立性。模式/内模式映像定义了逻辑结构与物理存储之间的对应关系，当存储方式改变（换存储设备、改索引组织方式），只要调整这层映像，模式可以不动，这叫物理独立性。

这两条对应关系是考试里最经典的送分题，也是最经典的记混点。判断口诀可以这么记：越靠近用户的那层映像，管的是「逻辑」；越靠近存储的那层映像，管的是「物理」。数据独立性不是数据库白送的特性，它是用两级映像换来的——代价是每次结构变更都要维护映像，这也是为什么实际项目里改表结构要评估影响面。

2.3 系统组成与三条研究主线

数据库系统不只是「一个数据库加一个软件」，它由数据库、数据库管理系统、应用程序、数据库管理员、最终用户和硬件支撑环境共同组成。其中数据库管理员的职责常被低估：定义模式、定义存储结构与存取方法、监控运行、保证数据完整性、做恢复与授权，这些工作贯穿数据库整个生命周期，而不是上线前配一次就完事。

数据库技术的研究领域大致分三块。第一块是数据库管理系统本身的研制，关注数据模型、查询优化、事务处理、存储引擎这些内核问题；第二块是数据库设计，关注怎么用现有的模型和工具把一个具体业务建模建好，属于方法论；第三块是数据库理论，比如关系代数、规范化理论、依赖理论，偏数学基础。三块的分工很清楚：第一块造工具，第二块用工具，第三块解释工具为什么成立。复习时把这三条线和前面六步对应起来，知识就不会散——逻辑结构设计对应设计方法论，三级模式对应管理系统实现，范式与依赖对应理论基础。

3. 数据模型三要素：从现实世界到机器世界的两次翻译

数据模型这一节是整个课程的方法论核心。教材先讲概念模型，再讲数据模型的组成要素，最后罗列层次、网状、关系三种最常用的模型，这个顺序不是随意的：它对应现实世界→信息世界→机器世界的两次转换，也对应「先想清楚、再选工具、最后落地」的工作节奏。把这条转换链想通，后面再看任何模型都不会觉得是零散知识点。

3.1 三个世界与两次转换

现实世界是客观存在的那部分：学生、课程、教师、宿舍，以及它们之间真实发生的关系。信息世界是对现实世界的一次抽象，用实体、属性、联系这些概念把「有意义的特征」提取出来，形成概念模型。机器世界是对信息世界的二次抽象，用记录、字段、指针这些计算机能处理的结构来表达，形成数据模型。

两次转换的边界要分清。第一次转换发生在需求分析和概念结构设计之间，做的是「取舍」——哪些对象重要、哪些属性值得记录，由业务目标决定；第二次转换发生在概念结构设计和逻辑结构设计之间，做的是「映射」——实体变表、属性变列、联系变外码或独立表，由所选模型决定。混淆这两次转换，就会出现「概念模型里写字段长度」或者「逻辑模型里还在讨论业务语义」的情况。

值得强调的是，概念模型独立于具体的数据库管理系统，这是它最大的价值。业务需求变化时，先改概念模型，再往下推；换了数据库产品，概念模型不用动。

3.2 三要素是所有模型的通用答题框架

数据模型的三要素是数据结构、数据操纵、完整性约束。数据结构描述系统的静态特性，包括数据对象、它们之间的联系以及约束；数据操纵描述动态特性，包括查询和更新两大类操作；完整性约束是一组语义规则，保证数据的正确、有效、相容。

这三要素的价值在于它是一个万能框架。评价任何一个数据模型，都可以按这三个维度拆：数据结构怎么表示联系，数据操纵有哪些操作、以什么为单位，完整性约束靠什么机制保证。复习时如果只能背出三要素的名字却说不出在每个模型里的具体表现，那基本等于没学。

表里最容易被忽略的是「一次一集合」与「一次一记录」的差别。它不是措辞差异，而是两种模型在易用性上拉开差距的根本原因：关系模型把「怎么找」交给了优化器，网状模型把「怎么找」写进了程序里。

3.3 概念模型的六个术语与 E-R 表达

概念模型的核心术语有六个：实体是客观存在并可相互区分的事物；属性是实体所具有的某一特性；码是能唯一标识实体的属性或属性组；域是属性的取值范围；实体型是同类实体的抽象，用实体名加属性名表示；实体集是同一类型实体的集合。前四个术语描述个体，后两个描述集合，这一层区分经常被含糊过去。

联系用来刻画实体之间的关联，按参与数量分 1:1、1:n、m:n 三类。E-R 图用矩形表示实体型，椭圆表示属性，菱形表示联系，连线标注联系类型。画图时有两个习惯值得养成：一是把联系上的属性画在菱形旁边，不要挂到某一端的实体上；二是对 m:n 联系一定要标清两端的基数，这是后面转关系模式的依据。

3.4 从 E-R 图到关系模式：三种联系的转换规则

转换规则可以浓缩成三句话：1:1 联系可以并入任意一端，把另一端的码作为外码；1:n 联系并入 n 端，把 1 端的码作为外码；m:n 联系必须独立成一张表，两端码的组合作为主码（或联合主码），联系自身的属性也放到这张表里。

这三条规则里，m:n 的独立成表是重点也是易错点。用学生选课的例子落地：

-- 实体表：学生，sid 为主码，对应 E-R 图里的矩形 CREATE TABLE student ( sid CHAR(8) PRIMARY KEY, sname VARCHAR(20) NOT NULL ); -- 实体表：课程，cid 为主码 CREATE TABLE course ( cid CHAR(8) PRIMARY KEY, cname VARCHAR(30) NOT NULL ); -- 联系表：选课，(sid, cid) 联合主码，grade 是联系上的属性 CREATE TABLE sc ( sid CHAR(8) NOT NULL, cid CHAR(8) NOT NULL, grade DECIMAL(4,1), PRIMARY KEY (sid, cid), -- 同一学生同一课程只能有一条选课记录 FOREIGN KEY (sid) REFERENCES student(sid), -- 参照完整性：不允许选不存在的学生 FOREIGN KEY (cid) REFERENCES course(cid) -- 参照完整性：不允许选不存在的课程 );

联合主码(sid, cid)承担了两个作用：一是保证不重复选课，二是天然形成按学生、按课程的两种查询路径。两个外码分别把联系表挂回实体表，参照完整性由数据库系统检查，不需要应用层自己维护。grade放在联系表而不是学生表或课程表，是因为成绩既不属于学生本身，也不属于课程本身，它只存在于「某个学生选了某门课」这一事实里——这个判断标准可以推广到所有 1:1 和 1:n 的联系属性归属问题。

4. 网状模型拆解：从双亲条件到完整性约束

网状模型是课件里讲得最细的一种非关系模型，细到数据结构、数据操纵、完整性约束、存储结构、优缺点、典型系统六个方面逐条展开。它值得花时间，原因有两个：一是它把「用指针表达联系」这件事讲透了，理解了它再回头看关系模型的外码，会明白关系模型到底省掉了什么；二是它的完整性约束设计很反直觉，和关系模型的参照完整性几乎是两个方向，考试特别爱在这里设陷阱。

4.1 两个成立条件：网状模型到底「网」在哪

网状模型的数据结构，定义为满足下面两个条件的基本层次联系的集合：允许一个以上的结点无双亲；一个结点可以有多于一个双亲。这两个条件要连起来读——第一个条件打破了「必须有一个根」的限制，第二个条件打破了「每个结点只能有一个上级」的限制，两条合起来，结构就从树变成了图。

表示方法和层次模型一致：实体型用记录类型描述，每个结点是一个记录类型；属性用字段描述，每个记录类型可包含若干字段；联系用结点之间的连线表示记录类型之间的一对多父子联系。这里有个容易漏掉的限定：连线表达的仍然是一对多的父子联系，网状模型的「网」是靠多个一对多联系拼出来的，不是靠一条连线直接表达多对多。

三个特点要背准。第一，只能直接处理一对多的实体联系，多对多必须绕一道；第二，每个记录类型定义一个排序字段，也叫码字段，用来标识记录；第三，任何记录值只有按其路径查看时，才能显出它的全部意义。第三条最抽象，翻译一下就是：一条教师记录脱离了「属于哪个系」这条路径，它的含义是不完整的，值本身不携带完整语义。

4.2 与层次模型的四条区别

这两个模型经常被放在一起对比，区别可以归成四条：网状模型允许多个结点没有双亲结点；网状模型允许结点有多个双亲结点；网状模型允许两个结点之间有多种联系，也就是复合联系；网状模型可以更直接地描述现实世界，而层次模型实际上是网状模型的一个特例。

最后一句是判断 nugget：层次模型是网状模型的特例，反过来不成立。这意味着凡是能用层次模型描述的结构，网状模型都能描述，反之不然。答题时如果问「网状模型相比层次模型的优势」，标准答案就落在这四条上，尤其是「复合联系」和「更直接描述现实世界」这两条，前者是结构能力，后者是建模效果。

4.3 多对多怎么落进网状模型

网状模型只能直接处理一对多，那多对多怎么办？办法是把多对多联系直接分解成一对多联系，用一个中间记录类型承接两端。学生和课程的多对多，在网状模型里会变成「学生—选课—课程」这样两个一对多：一个学生对应多条选课记录，一门课程对应多条选课记录，选课记录同时对双亲有联系。

这个中间记录类型有时被叫作联结记录，它承担的角色和关系模型里那张联系表一模一样。两者的差别在于实现：关系模型靠外码的值匹配，网状模型靠指针把记录物理地串起来。理解了这个对应关系，再看后面的存储结构就不会觉得突兀——所谓单向链接、双向链接、环状链接、向首链接，说的都是这些指针怎么摆。

4.4 数据操纵与完整性约束：属籍类别是关键

数据操纵包括查询、插入、删除、更新四类，操作单位是记录，访问路径必须由程序指定。这一点决定了网状模型的使用门槛：同样的查询，关系模型写一句 SQL 就行，网状模型要沿着指针一步步走。

完整性约束部分信息密度最高。早期网状数据库的规范方案对数据操纵加了一些限制，提供了一定的完整性约束，主要包括码、双亲结点与子女结点之间的一对多联系、以及属籍类别。

属籍类别又分加入类别和移出类别两组。加入类别描述子女记录加入某个双亲系的方式，有自动的和手工的两种：自动意味着插入子女记录时系统自动把它挂到对应双亲下，手工意味着需要程序显式建立连接。移出类别描述子女记录脱离双亲系时的处置方式，分固定的、必须的、随意的三种：固定表示子女必须随双亲一起处理，必须表示子女不能脱离任何系而存在，随意表示可以自由移出。

另外两条约束条件更要留意：允许插入尚未确定双亲结点值的子女结点值；允许只删除双亲结点值。这两条在关系模型里都是「违规操作」——前者相当于外码为空，后者相当于留下孤儿记录。网状模型允许它们，是因为指针结构本身能表达「暂时没有挂上」和「悬空」这两种状态。理解了这一点，就理解了两种模型在完整性上的根本分歧：关系模型靠约束拒绝非法状态，网状模型靠结构容纳中间状态。

4.5 存储结构与四种链接方式

存储结构的关键是实现记录之间的联系，常用方法有四种：单向链接、双向链接、环状链接、向首链接。

单向链接是每个子女记录只存一个指向下一个兄弟的指针，只能顺着走不能回头；双向链接多存一个前驱指针，可以来回遍历，代价是多一份存储和维护成本；环状链接让最后一个子女的指针指回第一个，首尾相接，适合循环扫描；向首链接让每个子女都存一个指向双亲的指针，便于从子女快速找回双亲，也就是反向导航。

这四种方式的选择本质上是「查询方向」与「存储开销」的权衡。如果业务主要按双亲查子女，用单向或双向链接就够；如果经常要从子女反查双亲，向首链接更划算。用 C 语言的结构体可以把「系—教师」这个一对多关系的存储方式写清楚：

/* 系与教师：一对多，采用双向链接 + 向首链接的组合 */ typedef struct teacher_record { char tno[8]; /* 码字段（排序字段）：教师号，网状模型要求每个记录类型都有 */ char tname[20]; char dept_no[8]; /* 向首链接：直接指回双亲（系）记录，支持子女反查双亲 */ struct teacher_record *next; /* 双向链接的后继：同一系内的下一个教师 */ struct teacher_record *prev; /* 双向链接的前驱：支持反向遍历同一系内的教师 */ } TEACHER; typedef struct dept_record { char dno[8]; /* 码字段：系号 */ char dname[20]; TEACHER *first_teacher; /* 双亲侧的入口指针，指向本系第一个教师记录 */ } DEPT;

这段结构里，first_teacher是双亲侧的入口，next和prev构成子女侧的双向链，dept_no是子女侧的向首链接。三个指针合起来解决了三类访问：按系列教师、按系倒序列教师、按教师查所属系。参数tno之所以标注为码字段而不是主码，是因为网状模型的码字段主要承担排序与标识作用，它的唯一性靠数据库系统的约束保证，语义上和关系模型的主码并不完全等同——这个差别在第 5 章还会再提一次。

4.6 优缺点与它的历史位置

优点有两条：能够更为直接地描述现实世界，比如一个结点可以有多个双亲；具有良好的性能，存取效率较高。效率高不是玄学，是因为访问路径在程序里写死了，数据库系统不需要在运行时做路径选择，省掉了优化开销。

缺点也是两条：结构比较复杂，而且随着应用环境的扩大，数据库的结构会变得越来越复杂，不利于最终用户掌握；数据定义语言和数据操纵语言复杂，用户不容易使用。这两条其实是同一个问题的两面——把复杂度从系统转移给了使用者和开发者。

上世纪 70 年代，一个由多家厂商组成的数据库任务组提出了一个系统方案，奠定了数据库系统的基本概念、方法和技术，随后出现了若干商用网状数据库产品。这些产品在当时的批处理场景里表现很好，但随着应用规模扩大和终端用户增多，结构复杂、语言难用的短板被放大，最终让位给关系模型。这段历史给复习者的启示不是「哪个模型更好」，而是「模型的选择取决于使用者和场景」——这也是第 5 章横向对比的落脚点。

5. 三模型对比与易错点：层次、网状、关系最容易记混的五处

层次、网状、关系三种模型放在一起讲的时候，很多人会陷入「背完就混」的状态：单个模型的问题都能答，一旦要横向比较就开始含糊。原因往往不是记性不好，而是比较的维度没定下来。这一章先把维度固定成一张表，再逐条处理五个最容易出错的地方——这五处基本覆盖了选择题和简答题里 80% 的失分点。

5.1 用五个维度把三种模型摆平

比较任何数据模型，都可以回到第 3 章那个三要素框架，再补上「多对多支持」和「使用门槛」两个工程维度。五个维度定下来，横向对比就不会东一榔头西一棒子。

表里最值得盯的是「多对多支持」这一行。三种模型里只有关系模型能直接表示多对多，层次和网状都得绕。这个差别决定了三者在建模复杂业务时的成本，也是关系模型胜出的技术原因之一。

再补一条常被漏掉的：层次模型是网状模型的特例。答题时如果只写「网状比层次灵活」，不够；写清「层次模型是网状模型在限制条件下的特例」才完整。

5.2 五个易错点：漏在哪、为什么漏、怎么补

易错点一：把「网状模型能直接处理多对多」当成结论。为什么漏：看到网状模型里一个结点可以有多个双亲，直觉上就以为多对多被直接支持了，把「多双亲」和「多对多」混成了一件事。怎么补：回到定义，网状模型的连线表达的仍然是一对多的父子联系，多对多必须先分解成一对多再表达。记住一句话——多双亲解决的是「一个子女挂多个父」，不是「两个实体互为多对多」。

易错点二：把网状模型的码字段直接等同于关系模型的主码。为什么漏：两个概念都叫「码」，教材在不同章节分别定义，复习时容易合并成一个。怎么补：关系模型的主码约束的是元组的唯一性，是完整性约束的一部分；网状模型的码字段（排序字段）首先承担排序与路径定位的作用，唯一性约束是附加的。答题时如果问「网状模型的特点」，写「每个记录类型定义一个排序字段，也称码字段」，别顺手加「相当于主码」。

易错点三：记住「允许只删除双亲结点值」，却不知道它意味着什么。为什么漏：这条约束条件背起来很顺口，但它的后果从来没人展开讲。怎么补：把它和关系模型的参照完整性对照——关系模型里删掉被参照的记录会被拒绝或级联，网状模型允许留下悬空的子女记录，靠移出类别（固定的、必须的、随意的）来控制子女的处置方式。理解了「允许中间状态存在」，才算真正理解网状模型的完整性设计取向。

易错点四：两级映像与两种独立性的对应关系记反。为什么漏：四个名词（外模式/模式映像、模式/内模式映像、逻辑独立性、物理独立性）两两配对，纯记忆时极易交叉。怎么补：用位置判断，靠近用户的映像管逻辑，靠近存储的映像管物理。外模式在用户侧，所以外模式/模式映像对应逻辑独立性；内模式在存储侧，所以模式/内模式映像对应物理独立性。

易错点五：把概念模型和逻辑模型搞混，往 E-R 图里塞存储细节。为什么漏：课件讲 E-R 图时经常紧跟着举关系模式的例子，视觉上连着，容易以为是一回事。怎么补：判断标准只有一个——概念模型独立于任何具体的数据库管理系统。凡是出现字段长度、索引、分区、数据类型这些依赖具体产品的描述，就已经不是概念模型了。画 E-R 图时强迫自己只写实体名、属性名和联系类型，不写任何类型声明。

这五条整理下来会发现一个规律：所有易错点都出在「两个相似概念之间的边界」上，而不是出在单个概念本身。复习时的有效做法不是重复背定义，而是主动去找每个概念的「邻居」，把边界说清楚。

6. 复习清单：按题型倒推的查漏补缺顺序

复习到这一步，最怕的是「感觉都看过，一做题就虚」。比较靠得住的做法不是再从头翻一遍课件，而是按题型倒推：这门课的题基本落在概念辨析、结构判断、转换规则、约束分析四类上，那就按这四类各自准备一份自查清单，逐条过，过的标准是「能不看书画出结构、说出理由」。

表格只是目录，真正起作用的是「三遍过法」。第一遍画地图：拿一张白纸，默写从开发六步到三级模式再到三种模型的骨架，写不出来的地方做标记，只补标记处。第二遍填表：把上面这张表当考卷，每一行逼自己说出具体内容，说不清就回到对应章节，重点看定义里的限定词——「只能直接处理一对多」「允许一个以上结点无双亲」这类限定词，才是判卷时的采分点。第三遍只看错：把两遍里所有卡住的地方抄成一页纸，考前只翻这一页，不再碰整本课件。

有一个特别值得单独练的动作：把网状模型的「允许只删除双亲结点值」和关系模型的参照完整性摆在一起，用三句话说明它们各自的设计取向。能说清这个，说明你对完整性约束的理解已经从背诵升到了比较，简答题基本不会失分。

从那以后我每次复习数据库，都强制先默写三要素框架和三级模式两级映像，写不出来就不往下翻课件——因为这两块一旦含糊，后面所有模型都只能靠死记，越记越乱。希望帮到你。

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