如何确保含多组织关联的请愿数据库模式符合BCNF规范？

咱们先从分析原模式的问题入手，再一步步拆分到符合BCNF的结构：

第一步：揪出原模式的核心问题 #

原petition表（ID, title, contents, budget, organizationID, official, resultID, applicantID）最大的问题是部分函数依赖：
如果把(petitionID, organizationID)当作候选码（因为同一个请愿可以对应多个组织，所以必须组合起来唯一标识元组），那title、contents、budget这些属性其实只依赖petitionID，和organizationID没关系。这种部分依赖直接违反了2NF，更别说BCNF了，还会引发约束2里提到的更新异常——改个budget得同步改所有同petitionID的记录，很容易出错。

另外，原表的official字段应该是officialID更合理（存储关联ID而非名字，避免冗余和不一致），后面我会用officialID来表述，你可以根据实际字段名调整。

第二步：拆分出符合BCNF的关系模式 #

我们需要把原模式拆成4个表（保留原有3个合规表，新增1个关联表，重构1个核心表）：

1. 请愿核心信息表 petition #

petition(petitionID, title, contents, budget, officialID, resultID, applicantID)

• 候选码：petitionID（唯一标识一个请愿）
• 函数依赖：petitionID → title, contents, budget, officialID, resultID, applicantID
• 为什么符合BCNF？所有非平凡函数依赖的决定因素都是候选码，没有部分或传递依赖，完全满足BCNF要求。

2. 请愿-组织关联表 petition_organization #

petition_organization(petitionID, organizationID)

• 候选码：(petitionID, organizationID)（复合码，因为一个请愿对应多个组织，一个组织也可能参与多个请愿）
• 函数依赖：没有额外的非平凡依赖（两个属性共同构成唯一标识，彼此不依赖）
• 符合BCNF：所有属性都是主属性，不存在违反BCNF的依赖关系，完美解决多组织关联的问题。

3. 保留原有已符合BCNF的表 #

原有的三个表本身已经满足BCNF，不用动：

• applicant(applicantID, name)：applicantID是候选码，name完全依赖于它
• official(officialID, name, department)：officialID是候选码，name和department都依赖于它
• organization(organizationID, name, phoneNumber)：organizationID是候选码，name和phoneNumber依赖于它

第三步：验证是否满足所有约束 #

拆分后的模式完美适配你给出的所有约束：

• 约束1（每个请愿对应一名公职人员）：petition表中petitionID唯一对应officialID，通过函数依赖保证不会出现一个请愿对应多个公职人员的情况。
• 约束2（请愿关联多组织，budget/result变更同步）：现在budget和result只存在于petition表的一条记录里，修改时只需更新一次，再也不用同步多条记录；petition_organization专门存储关联关系，插入不同组织ID的记录完全不影响核心信息。
• 约束3（budget可为NULL）：直接在petition表中允许budget字段为NULL即可。
• 约束4（result处理完成后填充）：petition表的resultID初始设为NULL，处理完成后更新值就行。

最后再确认BCNF合规性 #

BCNF的核心规则是所有非平凡函数依赖的决定因素必须是候选码。拆分后的每个表都严格遵守：

• petition表的所有依赖都以petitionID（候选码）为决定因素；
• petition_organization表没有多余的依赖；
• 原有三个表的依赖都以各自的ID（候选码）为决定因素。

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