大学数据库系统原理《数据库设计》复习课件

2026数据库设计复习数据库系统原理·数据库设计期末冲刺·核心概念与范式判断课程导览01设计总览数据库设计六阶段全流程02概念建模E-R模型三要素与图形符号03逻辑转换E-R图转关系模式规则04规范化理论函数依赖与各级范式05范式判断判断流程与例题实战06工程权衡反规范化与设计取舍01设计总览设计先于建表，蓝图先于实现设计六阶段全流程数据库设计不是直接建表，而是一条从需求到运维的完整链条。六步先后逻辑清晰，后续知识点即可各归其位。第一步·需求分析搞清要做什么产出数据流图、数据字典与需求说明书重点获取信息、处理、系统三类输入第二步·概念设计抽象成模型将需求抽象为E-R图即实体-联系图第三步·逻辑设计转成关系模式把E-R图转换为关系模式确定完整性约束与用户视图第四步·物理设计确定存储方式确定数据分布与存储结构确定访问方式第五步·实施阶段建库与调试建库、编写调试应用程序组织数据入库并试运行第六步·运行维护持续优化持续评价、调整与修改三层数据模型递进01概念层概念定义现实事物

实体与关系只描述业务对象，不含技术细节。02逻辑层判断方法补充属性与标识符如

主键、外键。03物理层实例应用落为引用完整性约束。转换链条实体→表属性→列·标识符→键·关系→参照完整性约束E-R模型→关系模型关系数据库设计的核心一步三层模式呼应视图

外模式基本表

模式·存储文件

内模式逻辑独立性靠外模式与模式之间的映像物理独立性靠模式与内模式之间的映像设计两大陷阱与合并冲突识别并化解两类陷阱与三类冲突，是判断设计图是否合格的基本功。两大陷阱冗余重复信息引发数据不一致不完整某些方面难以建模，数据无处安放合并三步法1选择局部应用2逐一设计分E-R图3合并三类冲突属性冲突

同一属性取值或粒度不一致命名冲突

同义异名，或同名异义结构冲突

同一实体属性不同，或实体与属性抽象层次不一02概念建模矩形、椭圆、菱形，三形定乾坤E-R模型三要素与符号矩形、椭圆、菱形，三形定乾坤E-R模型·三要素记忆口诀实体Entity可独立存在、能被唯一识别的对象，如学生、课程，用矩形表示属性Attribute描述实体特征的信息，如学号、姓名、学分，用椭圆表示联系Relationship实体之间的业务关联，如选课、授课，用菱形表示连接规则Connection实体与属性、实体与联系之间均用无向线段连接，不画箭头主码标注PrimaryKey主码属性名下画下划线标出矩形、椭圆、菱形，三形定乾坤概念设计阶段·核心方法论联系的三类基数约束一对一（1:1）唯一对应两端各唯一对应。如一名学生对应一个校园卡。一对多（1:n）一多对应一端对应多端多个实例。如一个系包含多名学生，一名学生只属一个系。多对多（m:n）双向多对两端均可对应多个对方实例。如学生与课程经选课联系，双向均为多个。属性的分类体系建模时先分清属性类别，才能避免把可派生或可分解的信息错误固化进表结构。按结构分两类简单属性不可再分复合属性可进一步拆分按取值分三类单值属性每个实体只有一个值多值属性可有多个值，用双椭圆表示派生属性可由其他属性计算得出，用虚椭圆表示01案例一派生属性不存储学生关系若设计为Students（学号、姓名、性别、出生日期、年龄、家庭地址），因年龄可由出生日期派生，正确设计应去掉年龄。改为Students（学号、姓名、性别、出生日期、家庭地址）。02案例二NULL属性允许取空值NULL属性允许取空值。建模时先分清属性类别，才能避免把可派生或可分解的信息错误固化进表结构。弱实体与其他概念弱实体与其他概念·考点速览Q

什么是弱实体？A

依赖强实体才能完整定义，如借阅记录依赖读者与图书。图中用双边矩形表示，标识靠部分键，以虚下划线标记。Q

角色与度如何理解？A

同一实体集可在关系中扮演不同角色，如先修课关系中课程号与先修课号。关系的度指参与实体集个数，二元关系度为

2

最常见，三元以上少见。Q

联系的属性指什么？A

联系本身可带描述性属性，如“选课”联系带“成绩”，画图时用无向边连到菱形上。03逻辑转换实体成表，联系定键实体转关系的总原则E-R图转关系模式的三条核心规则：实体成表、联系落位、冗余不存。实体先成表规则一每个实体转为一个关系模式，属性对应列，主码对应主键。联系按类型落位规则二1:1/1:N→外键融入实体关系，不新建表M:N→独立产生新关系模式派生属性不存储规则三可由其他属性推算的冗余字段一律不带入。应试要点规范成果按三类规则逐条转换，结果至少达

3NF，多数情况达

BCNF。一对一与一对多转换“外键始终落在多端，避免数据重复。”1:1任选一端学生与校园卡一一对应，两端主键可互作外键。学生关系加卡号，或校园卡关系加学号，择一即可。1:n固定落多端系与学生一对多，系号必须加入学生关系作外键。不可反向把学号塞进系关系。联系类型与转换规则联系类型转换规则外键位置1:1任一端主键加入另一端作外键任选一端1:n一端主键加入多端作外键多端实体判断要点：先分清哪端是“一”、哪端是“多”，外键始终落在多端，避免数据重复。多对多转换与派生处理从1:1、1:n到m:n，转换规则层层递进，最终合成完整链条。完整链条1:1→择一外键1:n→外键落多端m:n→独立成表，合并两端主键1m:n独立建表多对多联系产生独立关系模式属性=两端实体主键+联系自身属性选课（学号、课程号、成绩），学号与课程号共同构成码2考试常考点E1与E2的多对多联系R转独立关系模式后关键字由E1和E2的关键字共同组成3派生属性不存储年龄可由出生日期推出，不写入关系属性04规范化理论消除依赖，一事一地函数依赖与码的概念函数依赖是规范化的理论基石：属性(组)X的值确定时，必定能确定属性Y的值，记为

X→Y。候选码是区分主属性与非主属性的标尺；所有范式判断归根结底都是围绕候选码展开的依赖关系检查。码与属性分类概念含义🏷️

候选码能唯一标识元组的最小属性组，一个关系可有多个⭐

主属性包含在任一候选码中的属性🔹

非主属性关系中不属于任何候选码的属性🎯

决定因素函数依赖X→Y中的左边X三类函数依赖部分依赖是

2NF

的消除对象，传递依赖是

3NF

的消除对象。完全依赖2项定义非主属性由整个候选码决定不能只靠真子集实例选课关系成绩完全依赖于(学号，课程号)部分依赖2项定义非主属性只依赖候选码的一部分依赖的是候选码的真子集实例(学号，课程号，姓名，成绩)姓名仅依赖学号传递依赖2项定义A→B且B→CB不能决定A，则C传递依赖于A实例学号→系号→系主任系主任传递依赖于学号规范化的目的与原则四类异常源于一张“学生-课程-系-系主任”宽表一事一地：一个关系只描述一个实体或一种联系。模式分解正是据此把混杂宽表拆成职责单一的多个关系，消除冗余、便于插入删除与更新。规范化动机四类异常数据冗余：系名与系主任随每条选课记录重复存储插入异常：新系未招到学生，系信息无法单独插入删除异常：删光某系学生，系与系主任信息随之消失修改异常：学生转系，需同步修改多条记录1NF与2NF的定义范式奠基：从1NF到2NF，逐步消除数据冗余1NF：原子性底线定义属性值不可再分，RDBMS中建成的表自动满足违反例工资可拆为基本工资、奖金、补贴修正拆开即可2NF：消除部分依赖定义满足1NF，且每个非主属性完全函数依赖于候选码升级方法投影分解——候选码各子集单独成表自动满足候选码为单属性，或全体属性均为主属性3NF与BCNF的定义第三范式3NF定义满足2NF，且每个非主属性都不传递依赖于候选码。升级做法把传递依赖的非主属性拆出单独成关系，切断间接依赖链。工程共识工程中做到3NF已能满足多数业务需求。更严格范式BCNF定义比3NF更严格，要求每个非平凡函数依赖X→Y的决定因素X都包含候选码。核心作用进一步消除主属性对候选码的部分与传递依赖，补上3NF未覆盖的盲区。⊂范式层级包含关系包含关系BCNF⊂3NF⊂2NF⊂1NF，高一级自动满足低一级。4NF消除多值依赖。5NF消除连接依赖，工程中通常只考虑到BCNF。05范式判断求码、分属性、逐级检验范式判断的三步流程“求码—分属性—逐级检验”是范式大题的通用解题骨架。1步骤01求候选码逐个计算属性集闭包能推出全部属性且真子集不能者，即为候选码2步骤02分主属性包含在任一候选码中的属性为主属性其余为非主属性3步骤03逐级检验由高到低依次判断：所有X都是超键→BCNFX是超键或Y全为主属性→3NF候选码真子集不能推出非主属性→2NF否则→1NF经典例题：判断2NF与3NF关系模式

R(A,B,C,D,E)，判断最高范式。求候选码闭包AB、AC、AD

的闭包均能推出全部属性，即三个候选码。属性主属性：A、B、C、D；非主属性：仅

E。判断2NFE

对三个候选码均完全依赖，无部分依赖。满足

2NF。判断3NFB→C、C→D

形成传递链，E

经多步间接决定。非主属性对候选码存在传递依赖，不满足

3NF。结论：该关系模式属于

2NF，最高不达到

3NF。经典例题：判断BCNF“3NF与BCNF的分界在于主属性之间的依赖，而非非主属性。”已知条件函数依赖仓库名→管理员，管理员→仓库名，（仓库名，物品名）→数量候选码（仓库名，物品名）与（管理员，物品名）属性主属性：仓库名、管理员、物品名；非主属性：数量判断过程非主属性仅数量，无部分依赖与传递依赖→满足3NF检查“仓库名→管理员”：决定因素“仓库名”不包含候选码→不满足BCNF结论：该关系模式满足

3NF，但最高不达到

BCNF。例题小结与答题规范规范作答，步骤分与自查两得Takeaway规范作答，步骤分与自查两得范式判断四步法1求码：闭包法求候选码，真子集推不出全属性才算“最小”。2分属性：以候选码为界划分主属性与非主属性，勿误算。3逐级筛：1NF默认成立→2NF查部分依赖→3NF查传递依赖→BCNF查决定因素是否含码。4作答四段：求码—分属性—判断—结论；写明依赖类型，逐级判定，点明不满足下一级的具体依赖。06工程权衡规范化非越高越好，权衡方为上策反规范化的定义与场景核心定义CoreDefinition反规范化是在可控冗余前提下，为提升查询效率而适当降低规范化程度的策略。适用场景Application读多写少——查询频繁、更新较少时，过度分解导致大量自然连接，每次取数跨表拼接，开销显著增大。典型做法Practice选课场景中把系名冗余到学生表，查询学生所在系无需再连接系表。代价与对策Trade-off冗余带来更新不一致风险，常配合触发器、应用层同步等手段维持一致性。判断关键Judgment从“绝对消冗余”转向“按访问模式权衡冗余”。设计权衡与复习要点规范保可靠，权衡得高效规范化减冗余目标减