简介《数据库系统概论第五版》第6章配套PPT课件面向计算机专业学生、数据库初学者及备考者聚焦关系数据理论和关系模式的规范化设计适合作为课堂讲授、课后自学与考前复习的辅助材料。内容以“问题的提出—函数依赖—码—范式—公理系统—模式分解”为主线系统讲解关系模型逻辑设计中的关键概念并通过学校教务数据库实例分析数据冗余、更新异常、插入异常和删除异常说明如何使用规范化理论消除不合适的数据依赖、优化关系模式。课件共1个PPT文件压缩包大小911KB课件以例题和定义相结合的方式呈现便于对照教材逐节学习也可用于制作笔记或复习提纲。目前已有60人学习下载。通过这份课件可理清1NF到2NF、3NF等更高范式的递进逻辑掌握Armstrong公理系统、模式分解和依赖保持的判断方法减少冗余与异常建立规范的数据库设计思路。1. 为什么工作五年后我还要回去重读数据库第6章先给结论数据库系统概论第五版第6章讲的是关系数据理论核心是函数依赖、范式1NF 到 4NF、候选键求解和模式分解。这些内容在教科书里看起来像数学推导但真正逼我回头重读的是某次在一个“报表宽表”项目里被数据冗余逼到重写底层表结构。那张表每天凌晨跑批35 个字段、5000 万行同一合同编号的客户名称重复存储更新客户电话要走全表扫描加去重跑到凌晨三点还报磁盘空间不足——问题从根上就是违反第二范式。这一章适合三类人正在准备软考或研究生考试的在校生、刚接手老旧系统的后端开发以及被数据仓库里各种“跑得慢、改不动、算不对”的表折磨到想重构的一线工程师。学完这一章你获得的不是“能背诵范式的定义”而是拿到一把尺子能在一张表设计完成前就判断它未来会不会出问题。真正动手复现这一章的内容建议不要只看书。把书上的例子用 SQL 建出来自己推一遍函数依赖闭包再把一个反范式的表拆成 3NF这个过程比刷十页习题有用得多。接下来我从第 6 章最容易被跳过的部分讲起:候选键和最小函数依赖集,这是整个规范化理论的钥匙。2. 函数依赖与候选键建表之前先找“决定者”2.1 函数依赖不是玄学是字段间的主从关系第6章开篇定义了函数依赖形式化记作 X → Y意思是“X 的值确定后Y 的值也随之唯一确定”。不要被数学符号吓住在实际表结构里这就是主键决定一行记录、学号决定学生姓名、订单号决定下单时间这件事。理解函数依赖的关键在于它是依据业务语义来的不是依据某个时刻表里恰好有这些数据。我在审查一个“员工项目工时表”时看到这么一列员工ID → 员工姓名、部门、部门主管。从数据上看没问题但在实际业务里员工可能调岗。如果把“部门主管”也放进这张表就出现了跨实体的传递依赖它不属于员工本身而是属于部门。这个判断靠的是业务知识不是数据统计。函数依赖还能分成完全函数依赖和部分函数依赖。完全函数依赖好理解就是 X 整体决定 Y少了任何一个属性 Y 就不唯一部分函数依赖则常出现在联合主键的表里比如订单ID商品ID→ 商品单价实际上商品单价只依赖商品ID这就是部分函数依赖也是第二范式要消灭的病灶。在动手规范化之前先做一件事把表的每个字段写出来标出候选键再把非主属性与候选键之间的依赖关系画出来。这张图越乱表就越需要拆。下面给你一个清晰的判定流程第一步列出所有函数依赖检查每个依赖左侧是否包含候选键第二步若有依赖左侧不是超键那么在 2NF 检查中先看是否存在部分依赖第三步再看非主属性间是否有传递依赖实操中我会把这张依赖图画在一张白纸上箭头代表决定关系。如果箭头指向了候选键之外的方向基本就能断定范式等级不够。2.2 求候选键闭包计算的工程化捷径候选键的计算是很多读者卡住的第一个点。教材给出了属性闭包的算法其实就是从已知依赖出发反复推导能多确定哪些属性。闭包这个概念看着抽象写代码却很简单。这里提供一个我常用的 Python 脚本输入属性集合和函数依赖输出该集合的闭包。def compute_closure(attrs, fds): # attrs: 初始属性集合如 {学号} # fds: 函数依赖列表如 [((学号,), (姓名,)), ((课程号,), (课程名,))] closure set(attrs) changed True while changed: changed False for lhs, rhs in fds: # 若依赖左侧全部在闭包中则右侧属性加入闭包 if set(lhs).issubset(closure): new_attrs set(rhs) - closure if new_attrs: closure | new_attrs changed True return closure fds [ ((学号,), (姓名,)), ((学号,), (系名,)), ((系名,), (系主任,)), ] print(sorted(compute_closure({学号}, fds))) # 输出: [姓名, 系名, 系主任, 学号]这段代码的核心逻辑是循环扩张每一轮把所有函数依赖扫一遍遇到“左侧已经能确定”的依赖就把右侧加进闭包直到闭包不再变化。参数里 fds 的每一项是一个二元组第一元是决定属性元组第二元是被决定属性元组。如果初始属性是一个复合属性比如想求学号课程号的闭包把 {学号, 课程号} 传给 attrs 即可。判定候选键的方法就是逐个尝试属性组合求闭包如果闭包等于全部属性集合那这个组合是一个超键再排除掉“去掉任一属性后闭包仍为全集”的组合剩下的就是候选键。用这个脚本跑一遍第 6 章课后习题会发现计算量比手算小很多正确率也高很多。实际工程里求候选键还有一个意义设计同步或缓存表时两个系统间做数据比对你通常需要先确定双方唯一的业务键是什么。当两个团队对“哪几个字段合起来唯一确定一条记录”争论不休时把候选键算法跑一遍全体闭嘴。3. 范式判定实战从 1NF 到 BCNF 逐级过检3.1 范式等级不是越高越好但要能判定范式是一套递进的规范等级每一级都解决一类异常。第 6 章的脉络是从 1NF 往上走1NF 要求属性不可再分2NF 消灭非主属性对候选键的部分依赖3NF 消灭非主属性对候选键的传递依赖BCNF 更进一步要求左部都是超键。到 BCNF 这个级别传统 3NF 仍然存在的“主属性对候选键的部分依赖”问题也被解决。判定一张表属于第几范式我习惯按这个顺序查是否所有列都是原子值不是则为 0NF需要拆列是否存在非主属性对候选键的部分函数依赖存在则最高到 1NF是否存在非主属性对候选键的传递函数依赖存在则最高到 2NF是否所有函数依赖的左部都包含候选键全部包含则是 BCNF否则最高是 3NF实际操作时我见过大量系统停在第 3NF 就止步了这没问题。BCNF 在工程上常用于那种“多个业务字段轮流做唯一标识”的表比如同一个客户既有客户编号又有身份证号还有手机号这三个都能唯一确定一条记录它们互为候选键此时若某个依赖左部只用了其中一个就可能违反 BCNF。处理方式也简单把独立候选键拆分出来或建立映射表。判断的时候要保留依据。我给团队做表结构评审每次都在设计文档里加一栏“范式判定结论”写明该表函数依赖集合、候选键、达到的范式级别、未满足项的具体字段。三个月后有人来问你为什么拆表直接翻文档不用重新推理。3.2 把一张反范式表拆到 3NF从依赖图到 SQL DDL下面用一个贴近工程的“项目申报表”演示完整的判定与拆分过程。初始表设计如下CREATE TABLE project_apply ( apply_id VARCHAR(32) PRIMARY KEY, -- 申请单号 project_code VARCHAR(20), -- 项目编码 project_name VARCHAR(100), -- 项目名称 emp_no VARCHAR(20), -- 员工工号 emp_name VARCHAR(50), -- 员工姓名 dept_no VARCHAR(20), -- 部门编号 dept_manager VARCHAR(50), -- 部门经理 apply_date DATE -- 申请日期 );这张表的问题一眼能看出来项目编码决定项目名称员工工号决定员工姓名和部门编号部门编号决定部门经理而申请单号又同时决定了项目和员工。依赖链是apply_id → project_code → project_name以及 apply_id → emp_no → dept_no → dept_manager。非主属性 project_name 依赖了 apply_id 的非键子集 project_code这是传递依赖所以最多只能到 2NF。拆分的依据是函数依赖的左侧左侧相同就聚成一张表依赖 project_code → project_name拆出项目表依赖 emp_no → emp_name, dept_no拆出员工表依赖 dept_no → dept_manager拆出部门表申请单表保留外键 project_code、emp_no 和自身属性 apply_dateCREATE TABLE project ( project_code VARCHAR(20) PRIMARY KEY, project_name VARCHAR(100) ); CREATE TABLE dept ( dept_no VARCHAR(20) PRIMARY KEY, dept_manager VARCHAR(50) ); CREATE TABLE employee ( emp_no VARCHAR(20) PRIMARY KEY, emp_name VARCHAR(50), dept_no VARCHAR(20), FOREIGN KEY (dept_no) REFERENCES dept(dept_no) ); CREATE TABLE project_apply ( apply_id VARCHAR(32) PRIMARY KEY, project_code VARCHAR(20), emp_no VARCHAR(20), apply_date DATE, FOREIGN KEY (project_code) REFERENCES project(project_code), FOREIGN KEY (emp_no) REFERENCES employee(emp_no) );拆分后更新部门经理只需改 dept 表一行而不是像以前那样全表更新。判断拆分是否无损用第 6 章里的判定方法拆出的两张表公共属性是外键且其中一张表对该属性是候选键就能保证自然连接还原原表信息。project_apply 与 employee 通过 emp_no 连接employee.emp_no 是主键无损employee 与 dept 通过 dept_no 连接dept.dept_no 是主键同样无损。这里有一个容易翻车的地方不要为了满足 3NF 把所有外键关系全拆掉。如果业务查询经常要同时取申请单、项目名、员工名拆分后每次查询都要三表连接性能压力反而更大。第 6 章讲的是理论底线线上系统要在 3NF 基础上有策略地逆规范化。我的经验是核心交易表严格 3NF统计报表宽表允许 2NF甚至 1NF但必须用定时任务保证数据一致性不留实时写入入口触碰冗余列。4. 模式分解的两种路径无损连接与保持依赖4.1 分解不是拆开就行两个性质必须验证把一张大表拆成多张小表人人都能拆但拆得对不对第 6 章给了两个硬指标无损连接和保持依赖。无损连接指拆开后自然连接能还原出原表的全部元组不多不少保持依赖指拆完后原有函数依赖在子表里依然能被约束或验证。这两个性质在工程上对应两类痛点无损连接被破坏数据同步时上下游对不上账保持依赖被破坏应用层要写一堆校验逻辑来模拟数据库本应保证的唯一性约束。我见过一个系统把“用户表”和“用户扩展表”拆开后两张表各自存了一份 user_type结果同一用户在两边的类型不一致整整一周才排查出来根因就是分解时没有保持 user_id → user_type 这个依赖。检查无损连接的方法是看两个子表的公共属性是否在其中一个子表中是超键。检查保持依赖则是看每个函数依赖的左右属性是否落在同一个子表里。如果依赖分散到多张表数据库就无法用简单的唯一索引或外键来约束一致性只能靠应用层代码而这通常是 bug 的开始。4.2 保持依赖分解到 3NF 的合成算法实践第 6 章给出了保持依赖分解到 3NF 的合成法先求函数依赖集的最小覆盖再按最小覆盖中每个依赖左侧相同的依赖聚成一张表最后看是否有某个表的候选键包含了原表候选键没有就补一张候选键表。这个算法用代码实现更踏实我把它写成了一个小脚本输入函数依赖集直接输出分解后的表结构建议。def minimal_cover(fds): # 1. 右侧拆成单属性 single [] for lhs, rhs_set in fds: for r in rhs_set: single.append((lhs, r)) # 2. 去掉多余依赖依次尝试移除若闭包不变则冗余 minimal list(single) for item in single: trial [x for x in minimal if x ! item] lhs, rhs item if rhs in compute_closure(set(lhs), trial): minimal trial # 3. 去掉左侧冗余属性 result [] for lhs, rhs in minimal: new_lhs lhs for attr in lhs: smaller tuple(a for a in new_lhs if a ! attr) if rhs in compute_closure(set(smaller), minimal): new_lhs smaller result.append((new_lhs, rhs)) return result def decompose_to_3nf(fds): mc minimal_cover(fds) tables {} for lhs, rhs in mc: key lhs if key not in tables: tables[key] set() tables[key].add(rhs) return tables fds [ ((apply_id,), (project_code,)), ((apply_id,), (emp_no,)), ((apply_id,), (apply_date,)), ((project_code,), (project_name,)), ((emp_no,), (emp_name,)), ((emp_no,), (dept_no,)), ((dept_no,), (dept_manager,)), ] print(decompose_to_3nf(fds))这段代码的 minimal_cover 干了三件事右侧单属性化、删除冗余依赖、删除左侧冗余属性。单属性化是为了后续按依赖合并方便删除冗余依赖时每次尝试去掉一个依赖如果剩余依赖仍能推出同样结论就说明它是多余的删除左侧冗余属性则检查依赖左侧能不能再缩短。decompose_to_3nf 按依赖左侧分组左侧相同就放一张表输出结果基本能映射成 SQL 建表语句。参数说明fds 的每个元素是二元组第一个元素是决定属性元组第二个是字符串集合。compute_closure 复用了第二小节的闭包函数这里不再重复贴。运行完你会发现输出的表集合和我们之前手动拆的计划是一致的额外的好处是算法还帮你做了去冗余少了一个多余依赖表就可能少一张。工程上这个脚本的价值在于当你面对一个 50 个字段的老表时手写函数依赖集往往漏掉隐性依赖但脚本能把隐含依赖通过闭包推导识别出来。我曾用它重构一个 200 万行的订单扩展表光删冗余依赖就省掉 3 张中间表。需要提醒的是合成法保证的是无损连接和保持依赖但如果原表存在多值依赖合成法可能不会拆得足够细这个时候要看下一节的第 4 范式。5. 第6章避坑指南这些坑我踩过你别再踩5.1 坑一求闭包时无限循环或漏推现象手算属性闭包时推出了十几个属性还没停或者结果明显缺属性和标准答案对不上。原因多数是函数依赖集合没写全。教材习题里常用“省略号”表示隐含依赖比如给出 A→B, B→C 时A→C 是推导出来的不是显式给出的。很多人只在闭包里放显式依赖漏了传递推导。另一个常见问题是闭包计算过程中没有把“新增属性”作为下次推导的输入循环只扫了一遍就停了。解决用上面那段 Python 脚本跑把显式依赖全部录入脚本的 while 循环会不断扩张直到稳定。手算核对时每轮循环后都问自己一句“上一轮新加进来的属性能不能触发新的依赖”直到没有任何依赖左侧是闭包子集为止。5.2 坑二分解时把无损连接和保持依赖搞混现象拆出来的表各自没问题但 join 回去多出不少脏数据或丢失数据。排查半天发现是外键关系建错了。原因保持依赖只关心函数依赖有没有被保留不关心 join 结果对不对无损连接只关心 join 还原不关心依赖是否容易约束。两者是独立的性质很多设计者以为做到一个就自动满足另一个其实不然。解决每次分解完先按“公共属性是否是一边超键”验证无损再逐条把原始函数依赖对应到子表看是否有依赖跨表。两件事分开检查做一张验证清单一次打勾。我习惯把原始依赖和拆后依赖打印出来并排贴在建表 SQL 注释里后续维护的人一眼能看到设计意图。5.3 坑三中学生式“见重复就拆”忽略外键成本现象按第 6 章的范式标准把一张表拆成七八张查询时 join 了五次线上接口从 30ms 涨到 900ms缓存还难做。原因范式化的收益是写入和一致性代价是查询时的连接成本。第 6 章教材默认是教学环境没有讲并发和索引开销直接照搬到 OLTP 系统就会出问题。解决核心交易表严格范式化报表或查询频繁且更新低频的表可以保留冗余列但更新必须走统一服务入口用事务保证冗余列同步变更。还有一种折中方案是保留范式表做写入源再单独建一张物化宽表供查询由异步任务从范式表刷新。这样写入模型和查询模型分离两边都不妥协。5.4 坑四多值依赖只有 4NF 才提但实际每天都在发生现象一个订单表里有商品列表字段还有赠品列表字段两个列表互相独立订单主键确定后商品集合和赠品集合各自被确定双方没有函数依赖关系。原因这是典型的多值依赖场景。函数依赖描述的是“一对一”多值依赖描述的是“一对多”而且是两组独立的一对多。第 6 章把多值依赖放在 4NF 部分讲很多人只背定义没意识到实体-属性-值EAV设计里到处都是多值依赖。解决把独立的多值属性拆成子表比如“订单商品明细”和“订单赠品明细”不要让两组多值数据躺在同一张表里。否则会出现记录数量乘积爆炸3 个商品 × 2 个赠品原表要存 6 行拆成两张表只用 32 行。数据量一大这个差别就是磁盘和查询性能的数量级差距。6. 用最小函数依赖集反向检查既有表比重新建表更实用前面几章都在讲怎么从零设计一张规范的表但真实项目里更多场景是接手一张运行了两三年的旧表。与其推倒重来不如用第 6 章的最小函数依赖集工具做一次“反向体检”。具体做法是从现有表和已知业务规则出发反向推导函数依赖计算最小覆盖然后看哪些依赖暴露了设计冗余。我常用的一段实用流程是用 information_schema 查出目标表所有字段结合业务代码或接口文档列出已知唯一性约束和字段关联把这些关联写成函数依赖喂给最小覆盖脚本检查最小覆盖里每个依赖左侧是否为候选键超集对不满足项生成 ALTER 建议举个例子一张“客户标签表”有 customer_id, tag_name, tag_category 三个字段业务上 customer_id tag_name 联合唯一。函数依赖是 customer_id, tag_name → tag_category这是一个完全依赖表已经在 3NF 且 BCNF。但如果你发现业务还要求“同一个客户同一分类下不能有重复标签”那应该加的是联合唯一索引 (customer_id, tag_category, tag_name)而不是改表结构。函数依赖理论能帮你判断该加什么约束比拍脑袋定索引靠谱得多。最后留一个我从第 6 章里真正用得最多的习惯每张新建的表在注释里写清楚“候选键字段、依赖集、达到的范式”。这个习惯救过我很多次三个月后业务方要求加字段时我能立刻判断该加到哪张子表而不是在原表上加冗余列。这是教科书的边界和工程使用的边界结合得最好的地方——理论用来决策实践用来验证。希望帮到你。本文还有配套的精品资源点击获取