跨过程整合要解决的问题是：让销售、支付、退款等分别记录的事实能够共同回答业务问题，同时保留各自真实的粒度、时间和度量含义。
把表连接起来，不代表业务已经整合。相同的商品名称、客户编号或日期列，也不保证含义一致。
本文依据《数据仓库工具箱》第2章的一致性维度、跨表钻取、价值链与企业数仓总线架构整理。正文以依赖推导为主，示例是教学构造。
一、先拆清过程，再明确共同问题
同一经营问题可能涉及多个过程。分析活动交易保留金额，至少需要销售及退款；分析履约效率，还要接入发货等事件。
这些过程发生的时间、记录细度和度量不同。原书强调价值链中的各过程应以相应粒度建模，不能为了整合而抹平差异。
先说明各过程一行代表什么，再确定共同问题准备在哪个层次比较。例如，销售记录商品行，退款记录退款分配行，共同输出可能是"商品×门店×日"。
这里的日期还需要另行定义：销售发生日、退款发生日和原销售归属日，不能只因列名都叫日期就当作同一个意思。
二、用总线矩阵识别共享关系
各过程明确后，用过程为行、维度为列，标出哪些过程需要哪些维度。原书称之为企业数据仓库总线矩阵。
矩阵既帮助发现可共享的日期、商品、门店等定义，也暴露缺口：例如退款来源没有商品明细，就不能直接承诺商品级退款分析。
总线矩阵承担规划和沟通作用，不要求把所有来源合并成一张宽表。相同过程也可能需要不同粒度的事实表，细节需要在后续设计中明确。
检查矩阵时，重点是共享关系是否真实，以及来源能否支持，而不是每格是否都有勾。
三、建立一致性维度，而不只统一编码
原书的一致性维度要求共享属性的名称和取值含义能够对齐，以支持不同事实结果在相同背景下比较。
例如，两个系统都使用商品编号，但一个编号表示规格，另一个表示商品大类。简单统一字段名，仍无法直接做规格级分析。
还要确认分类层级、未知值、有效历史及成员范围。一个来源只有品类级数据时，可以在兼容层级分析，但不能把品类金额伪装成各SKU实测值。
因此，一致性来自共同业务定义及其映射规则。编码转换是实现的一部分，来源缺口与历史差异也需要保留。
四、分别计算，再在兼容粒度对齐
过程和共享维度明确后，先分别得到所需结果，再按一致的行标题对齐。这对应原书的跨表钻取、多遍SQL方法。
教学例子：同一个商品、门店和日期，销售明细两行，各50元；退款明细两行，各10元。直接只按商品、门店、日期连接，会形成四行，销售额被累计为200元、退款40元。
分别汇总后，销售为100元、退款为20元；若业务口径确定两者可以相减，结果才是80元。
这不是禁止所有事实间关联。若有明确的原事件标识和可控关系，可以按已证明的基数设计关联；按共享维度直接拼接多张明细事实尤其危险。
对只在一侧出现的商品，也要决定保留、标记或排除，避免内连接无声删除有销售无退款、有退款无当日销售的记录。
五、检查整合没有改变事实含义
至少检查：各过程关联前后金额是否守恒，共享成员和层级是否一致，日期解释是否明确，以及缺失匹配是否有记录。
如果某个来源细度不足，可以降低比较粒度、补充来源或采用公开的分配规则。不同选择的分析含义不同，不能靠SQL技术动作消除业务缺口。
整合完成的标志，是共同问题能够获得可解释结果，而各过程仍能独立追溯。
快速复习
拆清过程和粒度 → 总线矩阵识别共享关系 → 建立一致性维度 → 分别计算并对齐 → 检查守恒、时间和缺失。
关键反例：两张表都有商品和日期，不代表可以直接连接后求和。
原书入口与边界
《数据仓库工具箱》第3版2.4，书内34---35页、PDF56---57页；2.7.11，书内39页、PDF61页；第4章总线架构见书内84页、PDF106页起。
Kimball官方跨事实分析说明强调避免通过共享外键直接连接多张事实表。本文的归属日期、缺失处理检查及金额例子为应用推导。