结论：事实表记录业务过程，不要求一定有数值

学生到课、员工排班、客户报名和商品参加促销都是真实业务事件，即使每行没有金额或数量。

把维度键组合记录在事实表中，行数本身可以成为事件次数。

先区分事件事实与覆盖事实

事件事实记录确实发生的到访或报名；覆盖事实记录本应适用的资格、计划或组合，例如哪些商品应参加活动。

两者组合才能回答“哪些应该发生但没有发生”。

一行是一次签到、一个人一天一次出勤，还是一个人一节课一次出勤，结果完全不同。

定义自然唯一键和重复处理规则，状态变化若需审计可另建事件流水。

缺席、未购买或未覆盖不能只从事件表推断，必须有应到人员、目标客户或活动商品清单作为分母。

基准集合也要有生效时间和排除规则，否则反连接会把无资格对象误报为缺失。

同时测试发生次数、唯一对象数、重复事件、取消、应发生未发生和不适用对象，并与源系统抽样核对。

BuildTable 可作为事实模型设计候选；覆盖集合生成、反连接语义和增量去重能力需项目核验。

事实表的本质是记录可计数的业务过程，不要求每行必须有金额。员工某天被排班、学生参加课程、客户获得活动资格、商品被纳入促销范围，都可由维度键组合表达。首先写出粒度句子，例如“一行代表一个员工在一个班次的一次排班资格”，再决定唯一键。

如果过程本身有事件 ID，保留为退化维度便于追溯；若没有，日期、对象、地点和活动组合可能构成自然唯一。行数可以是 count，但要警惕重复扫描、状态更改和源系统重发。没有度量不等于没有数据质量契约。

事件事实记录确实发生，例如到访或点击；覆盖事实记录理论上应发生或适用，例如排班、资格、目标客户和促销商品。要回答“哪些应到员工未签到”，需要从覆盖集合左连接或反连接事件集合。只有事件表只能看见发生者，永远看不见缺席分母。

两张表的粒度必须可比。覆盖是一人一班次，事件却是一人一天多次刷卡时，需要先按业务规则归并事件，再比较；直接反连接会把迟到、重复和跨班次误判。取消资格和临时换班要有有效期和状态，避免把不再适用的人算作缺失。

“未购买客户”看似简单，但目标客户集合是否包含新注册、已退订、无服务区域或风险冻结客户，会决定结果。覆盖表应保存生成批次、规则版本、生效区间和排除原因，使人能解释某对象为何在分母中。分母规则变化后，历史转化率不能无说明地重算。

大规模笛卡尔组合也要避免。所有客户 × 所有商品 × 每日可能产生不可用数据量；只生成真实业务允许或计划覆盖的组合，或使用规则维度在查询时展开。物化覆盖事实前评估行数、稀疏性和查询频率，并用分区与增量策略控制成本。

报名后取消、签到后撤销、促销资格中途终止都不是简单删除。保留不可变事件流或状态变更历史，事实表可表示当前有效事件或每次业务事件，但必须明确。若一行代表最终到访，重复刷卡应去重；若分析客流频次，则每次进出可能都是事实。

反例是给每行加 measure=1 就认为解决了模型问题。常量 1 只是方便求和，无法替代粒度和唯一性；另一个反例是把未发生直接存成海量 0 行。通常覆盖事实加反连接更节省，也更能追踪分母，除非业务确实需要固定稠密矩阵。

同时验证事件次数、唯一参与者、覆盖人数、应发生未发生、无资格对象、取消、重复和迟到。抽样从排班或活动规则重建分母，再与事件源核对；检查覆盖和事件 Join 后不会放大计数，并为每条缺失提供可解释的资格证据。

BuildTable 可作为事实模型设计候选，但覆盖集合生成、反连接语义、增量去重和规则版本能力需确认。无事实事实表不适合替代所有关系表；若关系只是当前主数据属性且不需按事件或时间分析，普通桥表或维度属性可能更简洁。

模型文档应给出四类受控查询：事件行数、唯一参与者、覆盖分母、覆盖反连接事件的缺失集合。每类注明 Join 键、有效期、去重和取消规则。例如缺勤率应先生成当日有效排班，再归并有效签到，最后用缺勤人数除以应到人数；不能从签到表推断未签到者，也不能把重复刷卡当多人。

对大覆盖集合先估算分区行数和查询成本，必要时按日或活动物化。规则变化时保存 coverage_batch_id，使历史分母可复现。质量面板比较覆盖人数、事件人数、匹配、未匹配事件和缺失，任何事件无覆盖都进入调查，而不是静默丢弃；这样模型既能回答正向发生，也能可信回答负向未发生。

上线试点选择一个分母明确的过程，例如员工排班或活动商品。连续两周由业务负责人核对新增、取消和临时例外，再随机抽取缺失集合回到源系统验证。只有覆盖生成及时、反连接结果可解释且重复事件稳定去重后，才扩展到客户未购买等规则更复杂的负向分析。

联系我们讨论企业数据建模场景并获取 BuildTable Desktop。