我正在设计具有多个数据源的几个维度，并且想知道其他人做了什么来对齐每个数据源的多个业务键。
我的示例：我有 2 个数据源 - 订购系统和执行系统。订购系统有关于付款和应该发生什么的详细信息；执行系统有关于实际发生的事情的详细信息（花了多长时间等，谁在订单上执行）。来自两个系统的数据需要创建一个单一的事实。
在 Ordering 和 Execution 系统中，它们都是 Location 表。两个系统的业务密钥通过 esb 映射。两个系统中的属性构成了关于单个位置的完整图片。计费信息在 Ordering 系统中，经纬度在 Execution 系统中。并且位置名称存在于两个系统中。
您如何设计 SCD 以适应从两个系统到维度的变化？
我们遵循相当严格的 Kimball 方法 - 仅供参考，但我愿意查看每个人的解决方案。
不一定是答案，但这是我的想法：
您已经在评论中介绍了实际选项。任何一个：
A. 预先合并
您需要一些在暂存中匹配两个（或更多）记录的合并功能，创建一个新的公共合并键并在维度中使用它。除了正常的 DW 数据之外，这还需要存储某种形式的查找或引用
或者
B.在维度中合并
将两条记录都放在维度中，并允许报告工具通过例如按位置名称分组来“合并”它。这意味着您不需要事先的合并逻辑，只需将其转储到维度中
但是，您有两个限制，我认为这使 A 和 B 之间的选择更加清晰
首先，您需要一个 SCD（我假设为 2 型）。这意味着选项 B 可能会变得非常复杂，因为当一个源记录发生更改时，您必须找到另一条记录并对其进行更改 - 这对选项 B 来说非常不愉快。您仍然需要某种预存储的密钥来链接它们，这意味着选项 B 不再简单
其次，假设您有一个属性（位置名称）的两个来源，当这些不匹配时，您需要某种暂存逻辑来选择一个名称
因此，鉴于这两种情况，我建议选项 A 是最好的 - 构建一些预合并逻辑，因为您的需求的复杂性保证了这一点。
您可能认为这将是一个常见问题，但我从未找到一个很好的在线参考资料来解释以前有人如何解决这个问题。
我的想法其实很琐碎。首先，您需要能够得出关于 Geo+Location 和粒度的主数据集是什么。
我的方法是：
DIM 加载
说下面是我的目标
Dim_Location = {Business_key, Longitude, Latitude, Location Name}
字典
Business_key = 始终从源系统映射到主记录（在本例中为执行系统）。现在想象一下，这张表的业务唯一键（经度、纬度）组合在一起。
位置名称= 同样，由于我们假设“执行系统”是我们数据的主控系统，因此它将从 Source="Execution System" 托管。
上表现在已加载以进行事实查找。
事实加载
您已经在执行系统和计费系统之间集成了记录。这是一个直接的查找和分期加载，因为它与 geo_location 的必要组合存在。
具有挑战性的场景
如果执行系统有迟到的订单记录怎么办？如果相同的 geo_location 指向多个位置名称怎么办？不可能，但值得分析数据的错误。