Kimball风格事实表是否需设置BK？我的理解是否有误？

首先明确：你并没有误解Kimball方法论，核心是要区分他的原则本质和实际场景的灵活适配。

Kimball强调“事实表粒度由维度组合的代理键（SK）维护”，核心逻辑是以业务粒度为核心——事实表的每条记录必须对应一个清晰、唯一的业务事件粒度，比如“某客户在某时间购买某产品的单次交易”。他反对的是：把业务系统的主键直接照搬成事实表的唯一标识，却忽略了维度组合定义的粒度逻辑（比如用业务系统的订单号当事实表主键，但订单里包含多个产品，这就破坏了“单产品交易”的粒度）。

而你遇到的场景是完全合理的：

• 当维度代理键的组合确实无法唯一标识一条事实记录时，添加业务键（比如TransactionNo）是必要的。比如同一客户、同一产品、同一时间点可能产生多笔独立交易（比如重复支付、拆分付款），这时候SK_Customer+SK_Product+SK_Time的组合会重复，必须用交易号来区分不同的业务事件。
• 实际数据运维中，业务键能快速关联业务系统的原始记录，方便排查数据问题、做变更捕获（CDC）或者回溯业务场景，这是落地时的实用需求。

需要注意的是：

• 不要把业务键当成事实表的“粒度定义者”，粒度依然要由维度组合来明确。业务键只是在维度组合无法唯一标识时的补充，或者是运维工具。
• 如果维度组合能唯一确定粒度（比如“每日每个客户的总消费金额”这种聚合事实表），那确实不需要额外的业务键，遵循Kimball的原则即可。

总结：Kimball的方法论是指导原则，而非绝对教条。在保证粒度清晰的前提下，根据业务场景和运维需求添加业务键，完全是合理的实践。

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