数据库原理第四版课件怎么用：从概念模型到网状模型选型与避坑

简介《数据库原理第四版》课件面向数据库课程初学者与需要夯实理论基础的从业人员围绕数据库系统开发全流程和核心理论展开重点帮助读者理解数据模型的设计与实现。压缩包内仅含1个PPT文件约289KB体量轻便适合课堂演示、期末复习与自学查阅。已有168人学习。课件从需求分析、概念结构设计、逻辑结构设计、物理结构设计到数据库实施逐步展开并梳理数据字典、数据独立性等基本概念在数据模型部分比较概念模型、层次模型、网状模型与关系模型其中网状模型讲得较细涵盖记录类型、字段、父子联系、排序字段与码字段、一对多联系表达、多对多联系分解以及查询、插入、删除、更新和DBTG完整性约束并配有学生、宿舍、教师、教研室等图示便于把抽象结构对应到现实关系。1. 别急着通读先给数据库原理第四版课件定一个使用场景很多人的习惯是从第一页翻到最后一页翻完绪论就搁下了过两周只记得「数据模型」四个字。这套数据库原理第四版课件更适合反着用带着一个具体的设计问题进去比如「一个系里有教师、教研室、学生、宿舍这几组关系该画成什么结构」再让课件 1.2 节的数据模型部分来回答。它覆盖第一章到第十章前几章把开发步骤、概念模型、层次/网状/关系三种模型讲得比较细网状模型那一节连数据操纵、完整性约束、四种存储链接方式都列了出来属于少见的把老模型讲完整的材料。它适合两类人一类是要做课程设计、需要把模型定义和约束条件写准的学生另一类是工作几年、只熟关系型数据库想弄明白「多双亲」「路径语义」「属籍类别」这些词到底指什么的后端或数据开发。2. 从概念模型到三种数据模型选型这道题课件给了结论没给判据课件 1.0 到 1.2 的编排顺序本身就是一条设计流水线需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施然后才进入数据模型的定义。1.2 节正好卡在「概念结构设计」和「逻辑结构设计」之间很多读者把它当成名词解释背结果背完还是不知道手里那个业务该选哪种模型。这一章的用法是把课件当判据库先用概念模型把现实世界抽干净再拿三种模型的特征去比对而不是先选模型再硬套业务。2.1 概念模型先落地把一段需求文字拆成实体、属性、联系三栏课件把概念模型放在 1.2.1只给了定义没给操作步骤。我一般会按下面这个顺序把一段需求文字拆开拆完再回头看课件里「实体型用记录类型描述、属性用字段描述、联系用结点间连线」这句话会顺很多。圈出需求描述里的名词去掉「系统」「模块」「功能」这类空词剩下的作为候选实体。圈出数量词和描述性短语比如「一个教师只属于一个教研室」「一门课可以被多个学生选」这些是属性或基数约束。圈出动词判断它是实体自身的属性变化还是两个实体之间的关系。对每个关系标注基数一对一、一对多、多对多这一步决定了后面能不能直接用某一种模型。拿「某高校教务场景」举例一段两百字的需求能拆成下面这张表名词/动词归类说明教师、教研室、学生、宿舍、课程实体需要独立存在的对象姓名、职称、学号、床位号属性依附于实体不能独立教师属于教研室一对多联系一个教研室多个教师一个教师一个教研室学生选课程多对多联系一个学生多门课一门课多个学生学生住宿舍一对多或多对多取决于是否允许一人多床位这张表的价值在于它不依赖任何 DBMS。概念模型阶段只回答「现实世界长什么样」一旦开始问「这条联系用指针还是用外键表示」就已经进入逻辑结构设计了。课件把这两步分开讲很多人读的时候合并成一步后面选型就会乱。血泪经验是概念模型里出现「多对多」三个字逻辑设计阶段就一定要处理跑不掉。2.2 层次、网状、关系三种模型边界在「一个结点能有几个双亲」课件 1.2.4 到 1.2.6 依次讲层次、网状、关系。三者的差别不在「谁先进」而在结构约束上。层次模型是一棵树每个结点最多一个双亲所以它只能直接表达一对多网状模型放宽了两条允许一个以上的结点没有双亲允许一个结点有多个双亲于是它能直接表达更复杂的父子关系层次模型反而成了网状模型的一个特例关系模型换成二维表联系不靠指针靠值匹配多对多通过中间表解决。判断顺序可以固定成三步熟练之后看一眼 E-R 图就能出结论第一步看联系基数。只要存在多对多层次模型和网状模型都不能直接表达必须拆成一対多。课件在网状模型那节写得很直白用网状模型间接表示多对多联系方法是将多对多联系直接分解成一对多联系。第二步看导航需求。业务查询是不是强依赖「从父到子按路径走」比如从系到教研室到教师每次查询都沿着固定层级下钻。如果是网状模型的存取效率优势才成立如果查询条件千变万化关系模型的声明式查询更省事。第三步看维护成本。课件在网状模型优缺点里写了两条结构比较复杂随应用环境扩大而越来越复杂不利于最终用户掌握DDL、DML 语言复杂用户不容易使用。这两条不是套话它直接决定后期加一个实体要改多少条链接。一个反直觉的结论网状模型「存取效率高」这句话只在路径固定的场景下成立。一旦业务要求临时组合条件查询导航式操纵的代价会迅速吃掉那点效率优势这也是关系模型后来居上的现实原因。把这句话想清楚课件里那段优缺点就不用死记了。2.3 用一张对照表做逻辑结构设计的第一轮筛选把三种模型放在同一张表里比比逐段读定义快得多。下表是我按课件内容整理的第一轮筛选依据参数都来自课件原文没有额外加戏维度层次模型网状模型关系模型结构形态树单根有向图可多根二维表集合单结点双亲数至多一个可多于一个不适用靠值关联多对多表达不支持需拆不直接支持需拆中间表直接表达联系表示结点连线结点连线公共属性值操纵方式导航式导航式声明式典型约束父子一对多码、属籍类别、父子一对多主键、外键、CHECK适合场景层级固定、深度有限路径固定、父子关系复杂查询灵活、结构易变用这张表做筛选的流程是先把概念模型里的多对多全部标红标红的关系必须拆再看剩余关系里有没有「一个子女多个双亲」有就排除层次模型最后看查询模式是否需要临时条件组合需要就选关系模型不需要再考虑网状。课件在 1.2.3 只列了「最常用的数据模型」有哪些没给这张判据表补上之后选型就不再是玄学。3. 网状模型的两个判定条件把「多双亲」画成可检查的邻接表课件 1.2.5 开篇给的定义很短满足两个条件的基本层次联系的集合为网状模型一是允许一个以上的结点无双亲二是一个结点可以有多于一个双亲。定义短但真正画图的时候很多人会把「多对多」和「多双亲」混为一谈画出来的结构既不是网状也不是关系。这一章把定义翻译成可以逐条打勾的检查项。3.1 两个条件到底在限制什么第一个条件针对根结点。层次模型只有一个根网状模型允许多个结点没有双亲等于允许多棵树共存于一个结构里。课件配的示意图里R1、R2 都是没有双亲的结点它们各自往下挂 L1、L2 之类的子女。第二个条件针对双亲数量一个结点可以同时挂在两个父结点下面。这两条合起来网状模型就从「树」变成了「有向图」。课件还列了网状模型与层次模型的四点区别其中一条容易被忽略网状模型允许两个结点之间有多种联系也就是复合联系。举例来说同一个人结点和树结点之间可能同时存在「种植」和「砍伐」两条联系两条联系的语义完全不同。层次模型做不到这一点一条连线只能有一种含义。表示方法沿用了层次模型那一套实体型用记录类型描述每个结点是一个记录类型属性用字段描述一个记录类型可以包含若干字段联系用结点之间的连线表示记录类型之间一对多的父子联系。注意最后半句连线本身只承载一对多多对多必须另想办法。这是网状模型最容易翻车的地方下一节专门拆。判断一个结构是不是网状模型我会跑三遍检查数一数没有双亲的结点是不是超过一个数一数有没有结点的双亲数量大于一看任意两个结点之间是不是存在两条以上语义不同的连线。三条里中任意一条层次模型就不适用了。3.2 多对多拆成一对多的三步走课件给的方法是「将多对多联系直接分解成一对多联系」只有一句话。落到操作上我一般分三步拿「学生选课」这个经典多对多来演示为多对多联系新建一个记录类型把它当成连接结点。选课这件事本身不是学生也不是课程单独建一个「选课」记录类型。把两侧实体的码字段带进连接记录类型。选课记录里放入学号和课程号这两个字段在网状模型里通常就是排序字段。连接记录类型分别与两侧建立一对多联系连接侧永远是子女。学生到选课是一对多课程到选课也是一对多两条连线方向都指向连接结点。拆完之后原本的多对多消失了结构变成两个一对多符合课件里「只能直接处理一对多的实体联系」这条特点。同样的手法可以用在学生与宿舍、教师与课程之间。下面这段 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.1实体、属性、联系三栏齐全基数无遗漏把上题的多对多全部拆成一对多写出连接记录类型1.2.5 第 1 小节拆完结构通过两个条件检查给每条联系指定加入类别和移出类别说明理由1.2.5 第 3 小节六种组合选择有业务依据不是随手填第三题最难也最能暴露理解深度。判断依据是业务规则而不是技术偏好比如教师与教研室之间选「自动 固定」理由是人事制度上教师必须有归属且不随意调动学生与宿舍之间选「手工 必须」理由是入住需要人工登记但允许换宿舍。答不出理由说明属籍类别那节还是背下来的。笔记法上我习惯给每个数据模型建一张三列卡片结构约束、操纵方式、典型代价。结构约束写这个模型允许什么不允许什么操纵方式写增删改查的动作顺序典型代价写它在什么场景下会变慢或者变复杂。三列填满一个模型就算吃透了。这套方法用在课件 1.2 的三节上一张 A4 纸就能装下层次、网状、关系三个模型的全部要点比抄课件省事得多。从那以后我每次带人读这套课件都强制让对方先做第二题再翻 1.2.5画不出来就不许往下看完整性约束。因为结构画不对后面的约束和存储结构全是空中楼阁读得再细也落不了地。希望帮到你。本文还有配套的精品资源点击获取