设计具有多个数据源的维度答案

【问题标题】：Design a dimension with multiple data sources设计具有多个数据源的维度
【发布时间】：2019-10-17 19:46:13
【问题描述】：

我正在设计具有多个数据源的几个维度，并且想知道其他人做了什么来对齐每个数据源的多个业务键。

我的例子：我有 2 个数据源 - 订购系统和执行系统。订购系统有关于付款和应该发生什么的详细信息；执行系统有关于实际发生的事情的详细信息（花了多长时间等，谁在订单上执行）。来自两个系统的数据需要创建一个单一的事实。

在 Ordering 和 Execution 系统中，它们都是 Location 表。两个系统的业务密钥通过 esb 映射。两个系统中的属性构成了关于单个位置的完整图片。计费信息在 Ordering 系统中，经纬度在 Execution 系统中。并且位置名称在两个系统中都存在。

您如何设计 SCD 以适应从两个系统到维度的变化？

我们遵循相当严格的 Kimball 方法 - 仅供参考，但我愿意查看每个人的解决方案。

【问题讨论】：

您是否有每个源系统的维度记录，或者您是否预先合并位置并仅加载一个位置？
在暂存中，我有一个位置的两个维度记录 - 每个源系统都有一个。物理上它是一个位置 - 我不确定如何在 DW 中处理它的最佳实践。它是具有 2 个代理业务键的一维记录吗？它是一个带有外部参照表的记录，其中列出了代理业务键吗？还是二维记录？或者其他方式..？
我无法编辑评论...在我说“代理业务密钥”的地方应该只说“业务密钥”

【解决方案1】：

不一定是答案，但这是我的想法：

您已经在评论中介绍了实际选项。要么：

A.预先合并它

您需要一些在暂存中匹配两个（或更多）记录的合并功能，创建一个新的公共合并键并在维度中使用它。除了正常的 DW 数据之外，这还需要存储某种形式的查找或引用

或

B.合并到维度中

将两条记录放在维度中，并允许报告工具“合并”它，例如按位置名称分组。这意味着您不需要事先的合并逻辑，只需将其转储到维度中

但是你有两个限制，我觉得 A 和 B 之间的选择更清晰

首先，您需要一个 SCD（我假设是类型 2）。这意味着选项 B 可能会变得非常复杂，因为当一个源记录发生更改时，您必须找到另一条记录并进行更改 - 选项 B 非常不愉快。您仍然需要某种预存储的密钥链接它们，这意味着选项B不再简单

其次，假设您有一个属性（位置名称）的两个来源，当这些不匹配时，您需要某种暂存逻辑来选择一个名称

因此，鉴于这两种情况，我建议选项 A 是最好的 - 构建一些预合并逻辑，因为您的需求的复杂性保证了它。

您可能认为这是一个常见问题，但我从来没有找到一个很好的在线参考资料来解释以前有人如何解决这个问题。

【讨论】：

感谢您的回答。我将在 staging 中处理它，但我仍然不知道什么值最适合作为维度表中的业务键。而且，我仍然希望看到一些这样的例子——或者什么被认为是最佳实践。因为，我同意，这应该是一个常见问题，并且应该有关于如何最好地处理它的文档......
我也很想看一个例子。实际上你正在做的是合并，Kimball 建议生成一个“持久密钥”。您可能对本文的底部部分感兴趣：kimballgroup.com/2012/07/… 我不知道 Kimball 是否有所有答案，但他是唯一提出可能解决方案的人。

【解决方案2】：

我的想法其实很琐碎。首先，您需要能够得出关于 Geo+Location 和粒度的主数据集是什么。

我的方法是：

DIM 加载

说下面是我的目标

Dim_Location = {Business_key, Longitude, Latitude, Location Name}

字典

Business_key = 始终从源系统映射到主记录（在本例中为执行系统）。现在想象一下，这张表的业务唯一键（经度、纬度）组合在一起。

位置名称 = 同样，由于我们假设“执行系统”是我们数据的主控系统，那么它将托管在 Source="Execution System"。

现在已加载上表以进行事实查找。

事实加载

您已经在执行系统和计费系统之间集成了记录。这是一个直接的查找和分期加载，因为它与 geo_location 的必要组合存在。

具有挑战性的场景

如果执行系统有迟到的订单记录怎么办？如果相同的 geo_location 指向多个位置名称怎么办？不可能，但值得分析数据的错误。

【讨论】：