核心内容摘要
使用PDF-Extract-Kit-1.0实现房地产合同关键条款比对
【软考每日一练023】经典真题详解范式等级判定与模式分解特性分析在数据库系统工程师或软件设计师的考试中关系数据库规范化理论是必考的硬核知识点。
这类题目通常考察两个维度一是判断关系模式处于第几范式二是分析模式分解后的“无损连接性”和“函数依赖保持性”。
今天我们通过一道经典的真题来彻底搞懂这套分析逻辑。
题目原文
假设关系模式R(U,F)R(U, F)R(U,F)属性集U{A,B,C}U\{A, B, C\}U{A,B,C}函数依赖集F{A→B,B→C}F\{A \rightarrow B, B \rightarrow C\}F{A→B,B→C}。
若将其分解为ρ{R1(U1,F
,R2(U2,F
}\rho\{R1(U1, F
, R2(U2, F
\}ρ{R1(U1,F
,R2(U2,F
}其中U1{A,B}U1\{A, B\}U1{A,B}U2{A,C}U2\{A, C\}U2{A,C}。
那么关系模式R、R
R2R、R
R2R、R
R2分别达到了 分解ρ\rhoρ 。
第一个空选项A、1NF、2NF、3NFB、1NF、3NF、3NFC、2NF、2NF、3NFD、2NF、3NF、3NF第二个空选项A、有损连接但保持函数依赖B、既无损连接又保持函数依赖C、有损连接且不保持函数依赖D、无损连接但不保持函数依赖参考答案第一空D2NF、3NF、3NF第二空D无损连接但不保持函数依赖详细题解与逻辑推导为了确保准确性我们采用“抽丝剥茧”的方式分步验证每一个结论。
分范式等级判定我们需要依次分析原模式RRR和分解后的子模式R1,R2R1, R2R1,R2。
分析原关系模式RRR确定候选键 (Candidate Key)已知依赖集F{A→B,B→C}F\{A \rightarrow B, B \rightarrow C\}F{A→B,B→C}。
根据传递性由AAA可以得到BBB由BBB可以得到CCC。
即A→{A,B,C}A \rightarrow \{A, B, C\}A→{A,B,C}。
因此AAA是RRR的唯一候选键。
判定范式1NF属性不可分默认满足。
2NF是否存在非主属性对码的部分依赖候选键是单属性AAA不存在“组合键的一部分”这种情况因此自然满足 2NF。
3NF是否存在非主属性对码的传递依赖我们观察到依赖链A→BA \rightarrow BA→B且B→CB \rightarrow CB→C。
这里CCC是非主属性它依赖于BBB而BBB又依赖于候选键AAA。
这就是典型的传递依赖 (CCC传递依赖于AAA)。
因为存在传递依赖所以RRR不满足 3NF。
结论RRR处于2NF。
分析子模式R1(A,B)R1(A, B)R1(A,B)属性{A,B}\{A, B\}{A,B}。
依赖仅有A→BA \rightarrow BA→B。
分析AAA是键。
没有部分依赖也没有传递依赖只有两个属性无法形成传递链。
结论R1R1R1达到3NF实际上也达到了 BCNF。
分析子模式R2(A,C)R2(A, C)R2(A,C)属性{A,C}\{A, C\}{A,C}。
依赖根据原依赖集A→B→CA \rightarrow B \rightarrow CA→B→C在{A,C}\{A, C\}{A,C}范围内可以推导出A→CA \rightarrow CA→C。
分析AAA是键。
同样没有部分依赖和传递依赖。
结论R2R2R2达到3NF。
⇒\Rightarrow⇒第一空选 D2NF、3NF、3NF。
分分解特性分析ρ\rhoρ的性质这是本题的难点需要分别验证“无损连接”和“保持函数依赖”两个性质。
验证是否“无损连接” (Lossless Join)无损连接的意思是分解后的表R1R1R1和R2R2R2自然连接Natural Join后能否完全还原回原来的表RRR且不产生多余的“垃圾数据”。
判定定理如果分解ρ{R1,R2}\rho\{R1, R2\}ρ{R1,R2}且R1∩R2R1 \cap R2R1∩R2公共属性是R1R1R1或R2R2R2的超键Super Key则分解是无损的。
应用到本题计算交集R1∩R2{A,B}∩{A,C}{A}R1 \cap R2 \{A, B\} \cap \{A, C\} \{A\}R1∩R2{A,B}∩{A,C}{A}。
检查交集AAA是否为键在R1R1R1中A→BA \rightarrow BA→B所以AAA是R1R1R1的键。
在R2R2R2中A→CA \rightarrow CA→C所以AAA是R2R2R2的键。
只要满足其中一个即可。
这里两个都满足。
结论该分解是无损连接的。
验证是否“保持函数依赖” (Dependency Preserving)保持函数依赖的意思是原有的所有业务规则函数依赖能否在分解后的各个子表中独立验证而不需要把表拼起来。
分析步骤原依赖集F{A→B,B→C}F \{A \rightarrow B, \mathbf{B \rightarrow C}\}F{A→B,B→C}。
分解后的依赖集R1R1R1保持了A→BA \rightarrow BA→B。
R2R2R2保持了A→CA \rightarrow CA→C由传递性推导而来。
关键问题原依赖集中的B→CB \rightarrow CB→C还在吗在R1R1R1中只有AAA和BBB无法验证B→CB \rightarrow CB→C。
在R2R2R2中只有AAA和CCC无法验证B→CB \rightarrow CB→C。
虽然我们可以通过A→BA \rightarrow BA→B和A→CA \rightarrow CA→C推导出A→B,CA \rightarrow B, CA→B,C但这无法反推出B→CB \rightarrow CB→C。
即如果我们只检查R1R1R1和R2R2R2的数据合法性可能会漏掉“BBB相同但CCC不同”这种违反B→CB \rightarrow CB→C的情况。
结论该分解不保持函数依赖丢掉了B→CB \rightarrow CB→C。
⇒\Rightarrow⇒第二空选 D无损连接但不保持函数依赖。
知识点
总结 (Key Takeaways)为了帮助读者举一反三建议掌握以下核心概念
范式判定速查2NF 检查看有没有组合键。
如果是单属性键直接通过 2NF进入下一轮。
3NF 检查看有没有传递依赖。
即是否存在Key - 非主属性A - 非主属性B的链条。
无损连接判定口诀“交集是锁键连接无损。
”找出两个表的公共字段交集。
看这个公共字段能不能决定其中一个表的所有其他字段即是否为该表的键。
如果是则无损否则通常是有损。
保持函数依赖的本质不要看逻辑推导能不能推出来要看约束能不能落地。
如果某个依赖关系如X→YX \rightarrow YX→Y中的XXX和YYY被拆分到了两个互不相关的表中这个依赖通常就无法保持了。
在本题中BBB和CCC被强行拆散导致B→CB \rightarrow CB→C无法直接约束。
希望这篇解析能帮你彻底厘清数据库分解的相关考点如果有任何疑问欢迎在评论区留言讨论。