《数据库原理（第四版）课件拆解：网状模型与存取路径验证

简介《数据库原理第四版》配套课件面向数据库课程初学者、高校学生及需要梳理基础理论的从业人员围绕数据库系统开发全流程与核心理论展开。压缩包内仅含1个PPT文件大小约289KB以幻灯片形式组织章节内容便于课堂讲授、自学复盘与知识点检索。课件从数据库系统开发步骤讲起覆盖需求分析、概念结构设计、逻辑结构设计与物理结构设计并系统介绍数据模型、数据字典、数据独立性等基本概念其中对层次模型、网状模型和关系模型的对比梳理较完整尤其细讲网状模型的数据结构、查询与增删改操作、DBTG完整性约束、存储结构及优缺点还用学生、宿舍、教师、教研室和家庭关系等图示帮助理解复杂联系。目前已有168人学习适合用作课程同步复习和数据库基础入门的参考材料。1. 换个角度看这份《数据库原理第四版课件》它是可直接照着实现的材料并非考前速记去年帮一个团队改造一套工作多年的老系统里面还保留着一批十六位记录编号形式的父子结构数据。业务方说不清这些编号之间是什么关系我只能从模型层面反推。翻了几份资料后我重新翻出《数据库原理第四版课件》发现 1.2.5 节里讲网状模型链接方式的那几张示意图跟我现场画的数据映射图几乎一模一样。这份课件从第一章绪论讲到第十章主体是数据模型这条线概念模型把现实世界描述清楚逻辑模型决定数据怎么组织物理模型管存储和存取路径。它适合两类人跟课的在校生以及接手老系统、需要补上模型演进这块短板的一线开发者。下面按「这份资料怎么拆、网状模型怎么读、怎么落到能跑的验证」的顺序过一遍。2. 十章结构拆解理论图与必须动手的部分分别在哪2.1 十章内容分层与投入分配课件的价值不在页数而在密度分布。同一份 PDF前十页可能是整门课的关键中间几十页却是教科书的套路铺垫。我通常按「出题密度」和「修改代价」两个维度做一次分层再决定花多少时间。内容段主题图纸类内容修改代价建议投入第一章前半数据库系统开发步骤、系统概述开发流程的阶段划分低概念固定0.5 小时通读即可1.2 数据模型概念模型、组成要素、层次/网状/关系三种模型的实体关系图高后面所有章节都建立在这一层4 小时以上要手画1.3 系统结构三级结构、两级映像外模式—模式—内模式的结构关系中理解数据独立性需要它1.5 小时画一遍1.4 系统组成硬件、软件、人员、数据组件关系图低0.5 小时1.5 研究领域方向性罗列无低跳过也不影响关系模型与后续关系、SQL、设计、优化关系代数式、规范化表格高按需分配分层的目的是明确重点。数据模型那一节要逐页推演研究领域那一节在半小时内完成浏览即可。我见过不少人把时间均匀摊在十章上结果画不出一张完整的概念模型图一写 SQL 就停住。课件里有个小细节值得记一下英文标题里System拼成了Systenm全套幻灯片上都是。这不是质量问题只是课件反复复制粘贴留下的痕迹。但它提醒我一件事这套材料是授课用的演示稿并非出版级的教材很多图是占位式的线条画得随意需要你自己补上坐标和基数说明。2.2 三层模型与 1.2 节六个小节怎么对应1.2 节的组织顺序本身就是一条设计流水线只是课件没把这条线明说1.2.1 概念模型面向用户用 E-R 图描述现实世界不涉及存储。1.2.2 组成要素数据结构、数据操纵、完整性约束这三样是任何数据模型的三个部分。1.2.3 最常用模型层次、网状、关系按出现时间排。1.2.4 到 1.2.6逐个展开每个都按「结构—操纵—完整性—存储—优缺点—典型系统」六段式讲。看懂这个六段式后面两节就不用死记了。你把 1.2.5 的小标题抽出来会发现它跟 1.2.4 的骨架完全一致只是每个部分的内容换了。这也是我读这类课件的主要方法先识别模板再看每节在模板里填了什么差异。举个具体的差异。层次模型的结点只能有一个双亲所以「多对多」这件事它根本处理不了只能靠冗余或者引入虚拟结点绕开网状模型允许结点有多个双亲、也允许结点没有双亲于是一对多能直接表达多对多能拆开表达。关系模型更彻底干脆用二维表把联系也当成数据存下来代价是存取路径要由优化器现场计算。三个模型解的是同一个问题只是各自选择放弃的东西不同层次放弃灵活网状放弃简单关系放弃预置路径带来的确定性性能。理解了这个取舍1.3 节的数据独立性才有落脚点。三级结构、两级映像本质上讲的是当物理存储变了怎么让上层应用少改代码。网状模型时代这件事很痛苦因为存取路径写死在程序里改一条链接方式就要重编译一大批程序关系模型靠优化器把这个负担接了过去。课件把这一层意思压在定义里不细读很容易漏掉。2.3 三种读法的取舍同一份课件不同的人应该走出不同的路线。我把它归成三类考证型目标是覆盖考点。路线是 1.2 全节 1.3 关系代数 规范化理论网状模型只记两个判定条件和优缺点因为出题多是选择填空。时间紧就按这个顺序走别在存储结构上花时间。迁移型手上真有老系统的数据要搬。路线反过来先看 1.2.5 的结构和存储再回看 1.2.1 的概念模型最后对照关系模型写映射。这类人最需要的是把课件当规范文档读重点是属籍类别和完整性约束那几页因为迁移时的字段语义全靠它。教学型要讲这门课。路线是 1.0 开发步骤 → 1.2.1 → 1.2.6中间用层状和网状作为对比铺垫最后落回关系模型。这个顺序的好处是学生先看见「为什么要有关系模型」而不是先背关系代数。三条路线的共同点是都跳过了 1.5 研究领域。这一节可以看但它不产生可执行的产出。提示课件是演示文稿图中文字的基线常有错位翻页阅读时容易漏掉图注里的关键限定条件比如「只能直接处理一对多」这半句。建议把每页图注单独抄成一行笔记别只截图。3. 网状模型的判定条件与参数把 1.2.5 节当作参数表来读3.1 两个结构条件及它与层次模型的分界网状模型的定义只有两句话允许一个以上的结点无双亲一个结点可以有多于一个双亲。这两句看着简单落到设计上意味着什么课件用了一页对照图说明。层次模型是一棵树根唯一每个结点最多一个父一路向下不回头。网状模型把这两个约束都去掉了于是它成了有向图可以有多个入口一个结点可以从多条路径到达甚至可以成环。课件里提到「层次模型实际上是网状模型的一个特例」这句话是对的但不能反过来理解成「网状就是随便连」。它仍然是按记录类型组织的联系仍然由父子关系表达只是父子关系的重数放开了。表示方法那一页值得逐字读实体型用记录类型描述每个结点是一个记录类型属性用字段描述一个记录类型可含若干字段联系用结点之间的连线表示记录类型之间一对多的父子联系。注意最后半句连线本身表示的是一对多。这一点是后面所有坑的源头。课件还列了三条特点我通常把它们当作设计约束来记只能直接处理一对多的实体联系。多对多要靠分解。每个记录类型定义一个排序字段也叫码字段。这个字段决定同一双亲下子女的次序不是主键。任何记录值只有按其路径查看时才能显出它的全部意义。没有路径你手里只有一个孤立的记录值。第三条最容易被忽略。它意味着网状数据库里「查询」天然带有遍历的语义你从哪个入口进、走哪条路径出结果是不一样的。关系模型里SELECT的输入是一张表网状模型的输入是「双亲加系」。3.2 多对多拆成一对多课件里两组实例的推演课件给了两组例子一组是学生、宿舍、教师、教研室一组是父母、子女加上树种植、砍伐、养育、赡养这些联系。这两组例子的用意不同值得分开看。第一组是典型的组织结构系管理教研室教研室聘用教师系安排学生住宿舍。这里每一段都是天然的一对多直接连即可。但如果你把它画成「学生—教师」的多对多就会卡住因为一条连线放不下「什么时候、上哪门课」这些属性。第二组更微妙。父母与子女是一对多一对父母可以有多个子女但子女成年后又有自己的子女于是形成环。树种植、砍伐这类联系是同一批实体之间的另一种语义属于课件里说的「复合联系」——两个记录类型之间可以存在多种联系。多对多的标准解法课件写得很简短将多对多联系直接分解成一对多联系。具体做法是插入一个中间记录类型把原来的一条多对多边拆成两条一对多边。学生选课就是模板学生与课程之间插入「选课」记录类型它有两个双亲学生、课程自身带成绩字段。这就是网状模型能表达多对多的真实机制借助一个同时拥有两个双亲的结点把多对多联系拆成两个一对多联系。推演的时候要注意学号与课程号放在哪里。它们不是选课记录的字段而是两个双亲记录的码选课记录通过两条系分别挂到学生和课程上。这一点如果理解错了映射到关系库时会多建两个没用的列。3.3 码字段、加入类别、移出类别完整性约束的参数化理解DBTG 方案给数据操纵加的限制课件归纳成几条。这几条不是背了就完事它们每一个都对应一个可以配置的参数约束项取值含义迁移时的对应写法码每个记录类型一个排序字段决定同父下子女的次序不保证全局唯一单独的seq列不设主键双亲与子女联系一对多一条系只能有一个双亲、多个子女链接表 owner_id加入类别自动 / 手工子女插入时是否自动挂到某条系上外键是否允许NULL移出类别固定 / 必须 / 随意子女能否脱离双亲、是否必须留在某条系内ON DELETE策略与业务校验「加入类别」和「移出类别」这两个词在中文资料里译得不统一有的叫属籍类别、成员籍类别指的都是同一件事。理解方式是一个子女记录在某条系里的去留是可以逐条系配置的。固定表示一旦加入就不能移出必须表示必须挂在某条系上、不能悬空随意表示可以自由进出。课件还特意写了两条允许允许插入尚未确定双亲结点值的子女结点值允许只删除双亲结点值。这两条跟关系库的外键约束是冲突的。关系库默认不允许悬空引用而 DBTG 允许。这不是设计缺陷而是那个年代的实际需求数据是一条条录进去的双亲可能还没建好删除双亲时也不能顺手把子女全删了因为子女可能还要挂到别的双亲下面。注意把网状模型往关系库迁移时最常见的错误就是给链接列加上NOT NULL和级联删除。这两条约束一加原本合法的中间态数据就进不来了迁移脚本会在第一批脏数据上直接失败。3.4 四种链接方式单向、双向、环状、向首存储结构那一节只列了四个词单向链接、双向链接、环状链接、向首链接。课件配了一张带页码引用的图正文没展开。我按自己的理解补一下这四个词讲的是「记录之间的指针怎么摆」。单向链接是每个子女记录存一个指向下一个兄弟的指针双亲只存第一个子女的地址。要找第 N 个子女只能从头顺着走。双向链接多存一个前驱指针可以反向遍历代价是每次插入删除要维护两个指针。环状链接把首尾接起来最后一个子女指回第一个适合循环取数的场景。向首链接是每个子女额外存一个指向双亲的指针这样从子女能直接回到双亲不用从头找。这四种方式组合起来决定了一次查询要读多少个块。课件里那句「具有良好的性能存取效率较高」不是空话它指的是路径预置好了查一次父子关系只需要跟指针不需要做连接运算。代价也写在同一页结构复杂随着应用环境扩大数据库结构越来越复杂不利于最终用户掌握DDL、DML 语言复杂用户不容易使用。这两句话我在实际项目里体会很深。老系统的数据字典厚得像电话簿每加一个业务对象就要改一次模式定义改完还得重新编译访问程序。关系模型把这部分复杂度收进了优化器用户写一句JOIN就完事但执行计划变成运行时才确定的东西。两种设计没有绝对优劣只是复杂度放在了不同位置。至于典型系统课件列了几个上世纪七十年代的产品名。这些名字今天基本只在文献里出现实际参考价值有限。真正有价值的是 DBTG 提出的那套方案本身它奠定了数据库系统的基本概念、方法和技术后面所有模型都能从里面找到影子。4. 把课件的图变成可跑的对照实验用关系库模拟存取路径4.1 建表用链接表复现双亲与子女的指针课件里的图是静态的看十遍也不如自己建一遍。我的做法是用关系库把网状结构「架」出来记录类型建成字典表记录实例建成长表系set建成链接表。这样既能验证课件里的结构条件又能直接观察插入删除时的语义差异。-- 1) 记录类型字典对应 DBTG schema 里声明的 record type CREATE TABLE record_type ( rt_id INTEGER PRIMARY KEY, rt_name VARCHAR(32) NOT NULL, -- student / dorm / teacher / dept sort_key VARCHAR(64) NOT NULL -- 每个记录类型必须声明一个排序字段 ); -- 2) 记录实例不同记录类型的字段用文本承载避免建几十张表 CREATE TABLE record_inst ( inst_id BIGINT PRIMARY KEY, rt_id INTEGER NOT NULL REFERENCES record_type(rt_id), payload TEXT NOT NULL, -- 字段值序列化后的内容 sort_val VARCHAR(64) NOT NULL -- 排序字段取值决定同父下的次序 ); -- 3) 系定义一条边代表一种父子联系 CREATE TABLE db_set ( set_id INTEGER PRIMARY KEY, set_name VARCHAR(32) NOT NULL, -- 如 student_dorm owner_rt INTEGER NOT NULL, -- 双亲侧记录类型 member_rt INTEGER NOT NULL -- 子女侧记录类型 ); -- 4) 系实例双亲到子女的落点 CREATE TABLE set_occurrence ( set_id INTEGER NOT NULL, owner_id BIGINT NOT NULL, -- 双亲记录实例 member_id BIGINT NOT NULL, -- 子女记录实例 member_seq INTEGER NOT NULL, -- 子女在系内的次序 PRIMARY KEY (set_id, member_id) -- 一个子女在同一条系里只出现一次 );这四张表的划分对应课件的三层record_type和db_set是模式层record_inst和set_occurrence是实例层。sort_key单独放在类型字典里是因为排序字段是记录类型级别的声明不是每条记录各自决定。set_occurrence的主键选(set_id, member_id)而不是三列联合是为了保证一个子女在同一条系里不重复出现这与 DBTG 的成员籍语义一致。owner_id故意不加外键。原因在 3.3 节说过网状模型允许子女的双亲尚未确定。真要加也只能加一个允许NULL的弱引用完整性靠应用层校验。4.2 递归查询走路径验证「按路径查看才有全部意义」课件那句「任何记录值只有按其路径查看时才能显出它的全部意义」用一条递归查询就能验证。先看单层取子女-- 给定某系的一个双亲按 member_seq 取全部子女 SELECT m.inst_id, m.sort_val, m.payload FROM set_occurrence s JOIN record_inst m ON m.inst_id s.member_id WHERE s.set_id 2 -- 系编号student_dorm AND s.owner_id 1001 -- 双亲某栋宿舍 ORDER BY s.member_seq;set_id决定走哪条系owner_id决定从哪个双亲进。把这两个参数换掉同一条 SQL 就变成了完全不同的语义。这就是路径的含义查询的目标不是「满足条件的行」而是「从某处出发能到达的记录集合」。多层就走递归-- 从指定双亲出发逐层向下展开带环检测 WITH RECURSIVE path AS ( SELECT s.set_id, s.owner_id AS root_id, s.member_id AS node_id, 1 AS depth, ARRAY[s.owner_id, s.member_id] AS visited FROM set_occurrence s WHERE s.owner_id 1001 AND s.set_id 2 UNION ALL SELECT s.set_id, p.root_id, s.member_id, p.depth 1, p.visited || s.member_id FROM path p JOIN set_occurrence s ON s.owner_id p.node_id WHERE p.depth 8 -- 深度上限防御性参数 AND NOT s.member_id ANY(p.visited) -- 环检测网状允许成环 ) SELECT depth, node_id FROM path ORDER BY depth, node_id;三个参数值得说清楚。depth 8是硬性门槛防止数据里有意外长链把查询拖垮visited数组记录走过的结点遇到重复就停这是环状链接必须有的保护ARRAY和ANY是通用写法不同关系库的数组函数名不一样没数组类型就退化成临时表加NOT EXISTS子查询逻辑不变。跑完这条查询你会看到一个现象同一个node_id可能在不同的depth出现因为网状模型允许多条路径到达同一个结点。这正好解释了课件里为什么强调「按路径查看」——脱离路径你分不清这条记录是从哪条系过来的。4.3 四类数据操纵的副作用与事务边界课件把数据操纵列成查询、插入、删除、更新四项每项一句话。实际落地时这四项在网状模型里的语义差异比关系模型大得多关键在「系」的维护。插入一个子女记录要同时决定它挂到哪条系、以什么次序挂。这两件事如果不在一个事务里中间态就是一条没有归属的孤儿记录。更新排序字段更麻烦它可能改变子女在系内的物理次序等价于一次「移出再插入」。删除则要区分删的是双亲还是子女删子女只影响一条系实例删双亲会留下一批悬空子女。-- 只删双亲、保留子女把双亲标记为失效不级联删除 UPDATE record_inst SET payload {status:orphan} WHERE inst_id 1001; -- 此时 set_occurrence 里的子女仍然存在owner_id 指向一个失效双亲 -- 这正是 DBTG 允许的语义允许只删除双亲结点值 SELECT member_id FROM set_occurrence WHERE set_id 2 AND owner_id 1001;这两条语句演示的就是 3.3 节那个「允许只删除双亲」的约束。如果换成关系库的常规做法ON DELETE CASCADE会把子女一起清掉ON DELETE RESTRICT会直接报错拒绝删除。两种做法都不符合原始语义。正确姿势是软删除加一个清理任务由业务决定孤儿记录什么时候回收。事务边界上我一般的划分是一次插入或删除涉及的「记录实例 所有系实例」放在同一个事务里批量导入时按双亲分组一个双亲一个事务避免长事务锁住整张链接表。5. 避坑与排查五处课件没写透的地方5.1 把连线直接建成外键插入顺序被卡死现象迁移脚本跑到第三批数据就报引用完整性错误提示双亲子记录找不到对应的父记录。原因课件的图看起来像外键但 DBTG 允许子女先插入、双亲后补外键是立即校验的。解决链接表的owner_id不加外键约束改成导入结束后跑一次全量校验脚本把悬空引用单独列出来人工确认。5.2 认为网状模型能直接表达多对多现象画 E-R 图时学生和课程之间直接连了一条线落地时发现这条线上没地方放成绩只好临时加一张表结果跟原本的设计对不上。原因课件写得很清楚网状模型只能直接处理一对多多对多必须分解。解决画图阶段就强制插入中间记录类型让它带两个双亲成绩、时间这些属性全部挂到中间记录上。5.3 递归查询跑飞CPU 被打满现象一条遍历查询跑了十几分钟不返回日志里看不到报错。原因数据里存在环状链接课件的存储结构那一节专门列了环状链接但没提醒查询要防环。解决递归查询必须带visited集合或深度上限两个都加上更稳上线前用一条SELECT统计最大链长把上限设成实际最大值的两倍。5.4 把排序字段当成主键现象两张不同双亲下的子女记录出现相同的sort_val按它做关联时结果翻倍。原因码字段只负责同一双亲下的次序不承担全局唯一性。解决sort_val只用于ORDER BY唯一标识另设inst_id如果要按业务码关联业务码必须单独建唯一索引并做冲突检测。5.5 移出类别一律按级联删除处理现象删掉一个部门下面本该保留的教师记录一起没了。原因把 fixed、mandatory、optional 三种移出类别混成了一种。解决迁移前逐条系标注移出类别mandatory的系在删除双亲时先迁移子女optional的允许悬空fixed的直接拒绝删除并在应用层提示。这张对照表建议直接写在数据字典里跟表结构一起维护。6. 四十分钟闭环验证从概念图到可回滚脚本课件看完就放下过两周基本忘光。我的习惯是每学完一个模型用四十分钟做一次闭环产出三样东西一张手画的概念图、一份可执行的建表脚本、一份可回滚的清理脚本。下面这套流程我跑过很多次时间卡得比较准。阶段时长产出验收标准读图8 分钟手画 E-R 图每个联系标出基数多对多处必须有中间实体折模型7 分钟记录类型清单 系清单每个系能写出双亲侧和子女侧且都是一对多建表10 分钟建表 SQL四张表能建起来链接表无强外键灌数5 分钟三到五条样例数据至少有一条悬空子女、一条环验证10 分钟单层查询 递归查询结果递归查询能在深度上限内正常终止灌数这一步最容易被跳过但它恰恰是验证语义的关键。样例数据里必须故意留一条没有双亲的子女记录再留一条首尾相连的环否则 5.1 和 5.3 那两个坑你根本发现不了。清理脚本我一般写成这样跑完能把实验环境恢复干净-- 按依赖顺序清理链接表先于记录表 DELETE FROM set_occurrence WHERE set_id IN (SELECT set_id FROM db_set WHERE set_name LIKE demo_%); DELETE FROM db_set WHERE set_name LIKE demo_%; DELETE FROM record_inst WHERE rt_id IN (SELECT rt_id FROM record_type WHERE rt_name LIKE demo_%); DELETE FROM record_type WHERE rt_name LIKE demo_%;四张表的删除顺序不能反。set_occurrence引用db_set和record_instrecord_inst又引用record_type顺序错了会撞外键。所有实验对象统一加demo_前缀是为了在生产库上跑验证时不至于误伤真实数据。这一点我吃过亏早年在一套共享测试库里直接建了张student表第二天同事的同名建表脚本直接失败排查了半小时才发现是我留下的。从那以后我做任何模型验证都强制走一遍「前缀隔离 清理脚本 悬空与环样例」这三件事缺一样就不算跑完。这套动作跟课件本身没关系但它能把课件里那些只画了线条、没写语义的图变成你真正能开口讲清楚的东西。希望帮到你。本文还有配套的精品资源点击获取