处理地址维度并在多个事实中扮演角色

Posted 2023-03-29

【中文标题】处理地址维度并在多个事实中扮演角色

【英文标题】：Dealing with Address Dimension and role playing it in multiple facts

【发布时间】：2017-04-27 03:12:00

【问题描述】：

关于维度建模和角色扮演的问题。 我们有一个地址维度，即“角色扮演”。我们收到来自不同来源的地址，包括 CRM 系统。地址也可以是不同类型的，例如公司地址、个人地址等。因此，从角色扮演地址维度，可以将单个地址标记为公司地址和用于不同事实的计费地址。

有不同的事实表，它们有不同的键来保存地址数据。 Fact_Sales 将具有诸如 Customer_Address_Key、Company_Head_Office_Address_Key 之类的键。所以我相信我们是在扮演这些事实中的地址。

问题：

我们的首席数据架构师对此表示担忧。 • 我们正在从多个系统中获取大量地址。我们如何识别这些地址来自哪里，以及这些地址是什么类型的，而不需要查看事实表。

我仍然建议了解事实，但我想在脚踏实地之前咨询那里更广泛的社区。​​p>

有没有更好的方法来做到这一点，也许是一个单独的表来定义 Address_Key、Address_Type_Key 和 Source_Key 的组合。

如果您需要任何进一步的说明或图片等，请告诉我。

干杯 尼丁

【参考方案1】：

听起来在您遇到的情况下，您应该只在地址维度本身中包含地址类型和地址来源的列，因此它是独立的，您不必通过事实来知道它是什么样的东西。正如您所提到的，您不需要带有键的单独表 - 可以安全地在维度中对数据进行非规范化。

顺便说一句：

尽管许多人确实有一个单独的地址表，但 Kimball Group 的方法不会将“地址”或位置维度作为独立的多用途维度 - 它提供了描述其他事物的部分内容（比如公司、客户，甚至是“送货地点”）。相反，您将拥有维度（例如客户），并且在该维度内，您将拥有许多地址字段，并适当命名（CustomerAddress1、CustomerAddress2、CustomerCity）。为方便起见，您可以选择在后台集中管理地址，其他维度通过视图或进一步的 ETL 形成，但在星型模式的呈现中，地址表不会单独显示。这些地址仍然是一致的，因为它们被称为相同的东西并且意味着相同的东西。

但是很多人都像你一样使用单独的地址表

【参考方案2】：

将来源作为维度的属性包含在内是非常合理的。更大的问题是，如果您有多个来源，如何为客户选择“当前”地址。这就是事情变得棘手的地方。

您需要当前客户地址在您的整个企业中都具有相同的含义，无论它是从哪个来源获取的。我将其称为一致维度。您需要将所有地址来源“统一”到同一结构，以便将它们用作单一维度。

在您的大部分事实中，地址的来源是无关紧要的。您只需要知道它是当前地址。您可能有一个较小的模型，可以提供对客户地址来源的分析。

当地址来自多个来源时，困难的部分是决定哪个来源最值得信赖。您需要考虑上次更新的来源和日期。换句话说，当不太可靠的来源有更新的更新时，是否仍然首选主要来源。

类型通常只是地址的一个属性。但是，如果您的地址可用于多种事物（物理、运输、账单等），则可能需要通过角色扮演关系来定义。对于地址的其他分析，如果您需要按地理位置分解事物，您可以将城市/州和 zip 分解为单独的维度。我建议将 City & State 用作单一实体。如果将 City 与 State 分开对待，则在按多个州中存在的城市进行切片时会得到有趣的结果。