共享日期维度
下单日期键：需求发生
发货日期键：履约启动
签收日期键：客户收到
退款日期键：售后发生
结论：一张物理日期维度可以扮演多个业务角色
订单事实同时包含下单、支付、发货、签收和退款日期。为每个角色复制一套日期数据会增加维护和口径漂移。
保留一张共享日期维度，在语义层为不同外键创建明确角色。
时间角色必须进入指标定义
下单金额默认按下单日，履约时长连接下单与签收，退款额按退款日或原订单日会回答不同问题。
指标应声明默认日期角色，并允许用户显式切换。
同一查询可能需要多个日期角色
分析“本月下单且本月签收”需同时过滤两个角色；只用一个全局日期筛选会遗漏或误收记录。
别名、Join 路径和筛选作用域应由模型明确，不交给 AI 临时猜。
空日期和业务状态一起解释
未发货订单的发货日期为空是尚未发生，不等同于数据缺失。取消订单可能永远没有签收日。
日期状态、订单状态与数据质量标记共同决定是否进入时效指标。
用跨角色问题验收
测试按下单日销售、按签收日履约、跨月签收、未发货、退款和同时过滤两个日期，核对明细与时间窗口。
BuildTable 可作为日期角色和指标语义建模候选；角色别名、过滤路径和 AI 选角能力需 POC 核验。
共享物理日期，显式暴露语义角色
物理层通常维护一张完整日期维度 dim_date，包含自然日、星期、月份、季度、财务期间、节假日和工作日等受治理属性。订单事实分别保存 order_date_key、paid_date_key、ship_date_key、delivered_date_key 和 refund_date_key，查询时用不同别名连接同一维度。这样日历修订只发生一处，同时每条关系仍有清晰业务名称。
语义层不应只暴露一个模糊的 date。为每个角色提供“下单日期”“发货日期”等对象、描述、默认指标和允许过滤，并标记关系是否激活。否则 BI 工具或 AI 可能选择最短 Join 路径，却把退款分析按下单日统计。物理复用与语义区分必须同时成立。
指标的时间角色是合同的一部分
“本月销售额”通常按下单或支付日，“本月发货额”按发货日，“本月退款额”既可按退款发生日观察运营，也可回溯原订单日重述历史净销售。两种退款指标都可能合理，但名称、用途和公式必须不同。指标定义至少记录默认日期角色、时区、日界线和可替换角色。
持续时间指标需要两个角色，例如 delivered_at - ordered_at。若业务只按日期键保存，会丢失小时级差异；可同时保留时间戳和本地日期键，并明确夏令时与跨时区处理。AI 生成查询时应调用已定义的“履约时长”，而不是随意相减两个字段。
双重日期过滤需要独立作用域
问题“7 月下单且 8 月签收的订单”要求 order_date 在 7 月、delivered_date 在 8 月。一个全局日期控件只能表达其中一个条件。模型应允许为两个日期角色分别建立过滤器，并在 SQL 中使用两个维度别名；页面也要让用户看见每个范围作用于哪个业务事件。
反例是把日历表 Join 两次后，查询工具自动合并同名字段，导致一个筛选同时作用于两个角色，意外变成“7 月下单且 7 月签收”。另一个反例是先按签收日汇总收入，再与按下单日目标比较。跨角色比较应先声明不同时间轴，避免把不可比序列画在一起。
空值、未知日期和未发生事件分开编码
未发货订单的 ship_date 为空表示业务里程碑尚未发生，不是数据质量问题；源系统丢失发货日期则是未知；不需要发货的数字商品属于不适用。三种状态若都连到日期键 0，积压和质量分析会混淆。可保留 nullable 外键并配状态字段，或建立不同的特殊成员，但语义必须清楚。
日期维度还要处理超出范围的未来预约、错误日期和迟到事件。ETL 不应因为维度缺少某日就丢弃事实；应先扩展日期范围或进入隔离队列。取消、重开和多次发货可能需要事件事实或履约粒度，不能强迫一行订单只有一个日期。
模型测试、查询验收与 BuildTable 边界
自动测试包括日期键引用完整、角色字段命名一致、日期与时间戳对应、财务日历唯一和特殊状态覆盖。业务用例覆盖跨月、跨时区、未发生、取消、退款回溯和双角色过滤，逐笔与源订单核对。还应检查查询计划，确保别名 Join 不会形成重复关系或循环路径。
BuildTable 可作为日期角色和语义模型设计候选，但角色关系生成、默认时间选择、双过滤与 AI 选角能力需实际验证。本文不主张所有日期都强制复用一张物理表；当不同业务日历或时间粒度真正不同，可以建立独立维度，但必须通过一致键和定义维持可比性。
交付物应包含一张时间角色矩阵
矩阵按事实表列出每个日期与时间戳、业务含义、来源字段、允许为空原因、默认关联、适用指标、时区和日界线。例如订单金额默认 order_date，签收及时率使用 promised_delivery 与 delivered_at，退款发生额使用 refund_date，退款回溯额使用原订单日期。每个角色配正反例和自然语言问法，供业务评审与 AI 回归。
模型变更时检查所有引用指标、看板和查询样本。新增“开票日期”不能仅加一个外键，还要决定它与收入、应收和税务指标的关系；日历属性修订要在所有角色上同步生效。通过矩阵，团队能看出哪些问题是同一日期的不同别名，哪些实际上需要独立财务日历或时间粒度。
上线前用十组跨角色问题做业务签字，包括同月双过滤、跨月履约、取消无签收、退款按两种时间轴和跨时区订单。对每组保存预期行集、指标和 SQL 关系；任何工具升级后自动回归。若系统无法让用户看见当前日期角色，就不应开放含糊的“本月”查询。