01
来源：交易业务键
02
位置：事实表直接保存
03
用途：追溯、分组与钻取
04
限制：不是可随意求和的维度
05
升级：出现属性时再建头维度
结论：没有独立属性的交易标识可留在事实表
订单号能把多条订单行归为一笔订单，却通常没有值得放入独立维度表的描述属性。建立只有订单键的一行维表会增加 Join 而不增加语义。
这类业务键作为退化维度直接存入事实表。
退化维度不是技术主键
事实表代理键标识一行，订单号标识业务交易，两者用途不同。订单号可能跨来源重复，需要搭配来源系统或租户形成唯一范围。
保留原始格式，同时可增加规范化键用于匹配。
它支持明细问题和精确计数
可用于订单钻取、按订单分组、去重订单数、平均每单行数和跨事实对账。
计数时明确订单数、订单行数和客户订单次数，避免对业务键直接做无意义聚合。
属性增加时重新评估模型
若订单头包含下单渠道、收货地址、整体状态或整单优惠，可建订单头事实或维度，取决于粒度和变化方式。
不要把高基数交易号放进通用文本维度，也不要把订单级属性复制到每行后重复求和。
用跨粒度查询验收
测试订单行金额汇总、独立订单计数、部分退款、拆单、跨来源同号和订单头属性，核对明细与总额。
BuildTable 可用于声明事实粒度和业务键；退化维度识别、唯一性测试和自动查询行为需 POC 核验。