BCNF分解技术问询：基于指定函数依赖的BCNF分解求解

我来帮你把这个BCNF分解的问题拆解清楚，先从函数依赖的梳理开始，再一步步推导符合要求的分解方案：

根据题目里的业务规则，我们可以明确以下函数依赖：

• 客户维度：身份证号(D)是客户的唯一标识（题目说明客户有且仅有一个身份证号），所以每个身份证号必然对应唯一的姓名(A)、地址(B)、电话(C)，因此：
  • D → A
  • D → B
  • D → C
• 账户维度：账号(E)是账户的唯一标识，每个账号对应唯一的类型(F)、余额(G)，而且每个账户只属于一位客户（对应唯一的身份证号D），因此：
  • E → F
  • E → G
  • E → D

⚠️ 注意：题目没说姓名、地址或电话是唯一的（比如可能存在重名客户），所以这些属性不能反向决定身份证号，也不能互相推导。

先回忆下BCNF的核心规则：关系模式中所有非平凡函数依赖的左部，必须是该关系的候选键。我们从原始的全属性关系R(A,B,C,D,E,F,G)开始分析：

1. 确定候选键：账号(E)是这个关系的候选键——因为通过E→D可以推导出客户的所有属性(A/B/C)，同时E直接决定账户的类型(F)和余额(G)，所以E能唯一标识每条记录。

2. 找出违反BCNF的依赖：观察上面的函数依赖，D→A、D→B、D→C这三个依赖的左部是D，而D不是候选键（候选键是E），所以这些依赖违反了BCNF要求。

3. 执行分解：我们把原始关系拆成两个独立的关系模式：

   • R1(D,A,B,C)：专门存储客户的基本信息，它的候选键是D。这里的所有函数依赖（D→A/B/C）的左部都是候选键，完全符合BCNF。
   • R2(D,E,F,G)：存储账户信息以及账户和客户的关联，它的候选键是E。这里的函数依赖（E→D/F/G）的左部都是候选键，也符合BCNF。

这样分解后，两个关系都满足BCNF的要求，同时保留了所有原始的业务规则，也避免了数据冗余和更新异常的问题。

内容的提问来源于stack exchange，提问作者Kim