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