给定关系模式能否转换为BCNF？规范化技术问询

嘿，咱们先把原始数据摆出来，看得更直观：

原始表（暂命名为MemberSports） #

已知核心业务规则：每个体育中心仅能举办一种运动，这是咱们规范化的关键依据。

第一步：识别函数依赖 #

结合业务规则和数据，咱们可以梳理出这些非平凡函数依赖：

• Sport Centre → Sport：给定一个体育中心，就能确定它对应的运动（比如A1只能是网球，A2只能是高尔夫）
• (Name, Sport) → Sport Centre：同一个人参加同一种运动，只会去固定的体育中心（比如Jim打网球只去A1）
• (Name, Sport Centre) → Sport：这个依赖其实是冗余的——因为Sport Centre本身已经能确定Sport了

接下来找候选键：能唯一确定所有属性的最小属性集。这里(Name, Sport)和(Name, Sport Centre)都是候选键，任意一个组合都能定位到表中的唯一一行。

第二步：判断原表为何不符合BCNF #

BCNF的核心要求是：所有非平凡函数依赖的左部必须是候选键。

原表中，Sport Centre → Sport这个依赖的左部Sport Centre不是候选键（它没法单独确定会员姓名或者其他属性），所以原表直接违反了BCNF规范，会带来插入、更新、删除异常。

第三步：分解为BCNF #

咱们按照BCNF的分解规则，把违反规范的依赖单独抽成一个表，剩下的属性组成另一个表：

拆分表1：SportCentres #

专门存储体育中心与对应运动的映射关系，主键是Sport Centre（每个中心唯一）：

这个表的唯一依赖是Sport Centre → Sport，左部就是主键，完全符合BCNF。

拆分表2：MemberBookings #

存储会员与他们预订的体育中心的关系，主键是(Name, Sport Centre)（同一个人可以去多个中心，同一个中心可以有多个会员，组合起来唯一）：

这个表没有额外的非平凡依赖，完全符合BCNF要求。

验证分解的正确性 #

• 依赖保持：原表的所有业务规则都被保留了（中心与运动的映射在SportCentres，会员预订关系在MemberBookings）
• 无损连接：把两个表通过Sport Centre连接，能完整还原出原表的所有数据，没有信息丢失
• 无异常：后续插入新中心、更新会员预订信息时，不会出现数据冗余或不一致的问题

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