数据库/数据仓库中的多个冲突事实答案

【问题标题】：Multiple conflicting facts in database / data warehouse数据库/数据仓库中的多个冲突事实
【发布时间】：2012-10-08 11:54:29
【问题描述】：

我们的组织目前正在构建一个新的数据仓库。我们实际上可以使用从 DW 社区借来的一些技术，例如 ETL 处理来整合数据、“kimbal”风格的非规范化维度等。总体而言，数据仓库对我们的组织来说仍然是相当新的，但我们我们正在学习这些概念。

问题：我们有多种数据来源，而事实来源往往相互矛盾。例如，我们有一个 Master Person Index，我们在 ETL 期间使用基于分数的匹配算法将入站人员与现有人员进行匹配，因此即使入站记录不完全匹配，我们也可以根据其他事物进行评分比如邮政编码半径。

问题是：处理来自两个或多个来源的事实的多个版本的标准方法是什么？

我了解数据仓库的主要思想之一是保留我们正在做的任何事实的运行历史。当记录由一个入站来源维护时，这一切都很好，我们会随着时间的推移保留该事实的历史。当可能每天更新的两个不同来源具有两个不同的事实时，就会出现问题，例如来源 A 说名字是 Mary Smith，来源 B 说名字是 Mary Jane 每天都在改变这个值！基于匹配算法，我们确信它是同一个人，但由于我们的历史样式表，它基本上每天都在两个名字之间来回切换，因为它从每个数据源读取名字作为“变化”。

示例表：

first_name  last_name    source    last_updated
Mary        Smith        A         5/2/12 1:00am
Mary        Jane         B         5/2/12 2:00am
Mary        Smith        A         5/3/12 1:00am
Mary        Jane         B         5/3/12 2:00am
Mary        Smith        A         5/4/12 1:00am
Mary        Jane         B         5/4/12 2:00am
...

【问题讨论】：

您认为这两种来源中哪一种更可靠，为什么？当您找到这两个问题的答案时，您应该能够实现您在数据仓库应用程序中遵循的相同推理。当您确信 Mary Jane 和 Mary Smith 是同一个人，但不同的数据库可能以任一姓名引用她时，您可以将一个姓名存储为另一个姓名的别名，这样您就可以在两个姓名下找到同一个人.当 Jane Smith 成为 James Smith 然后与 Jones 女士结婚并使用她的姓氏时，此别名功能也可能会变得很方便。

标签： sql data-warehouse business-intelligence

【解决方案1】：

拥有一个存储您的外部数据的表：

 id | first_name | last_name | source | external_unique_id | import_date
----+------------+-----------+--------+--------------------+-------------
  1 | Mary       | Smith     |    A   |     abcdefg123     | 5/2/12 1:00am
  2 | Mary       | Jane      |    B   |     1234567abc     | 5/2/12 2:00am

然后有第二个表包含您清理的数据：

 id | first_name | last_name 
----+------------+-----------
  1 | Mary       | Jane-Smith     (or whatever)

然后有一个两者之间的映射表。

 local_person_id | foreign_person_id
-----------------+-------------------
       1         |        1 
       1         |        2

或大致相似的东西。

目标是从您的来源加载事实一次，并保留它们。

然后使用您的模糊逻辑将它们与某处的主记录相关联。只有在加载新事实或更改旧事实时才需要这样做。

不过，您可以选择使用什么 last_name。但在没有确定数据的情况下，这几乎是任意的。例如：从最近加载的事实中选择姓氏。

您仍然可以快速简单地将主事实与子事实、它们的来源以及它们的相应数据相关联。但是您的仓库中有一个统一的实体来挂载这些外部事实。

【讨论】：

【解决方案2】：

关于术语的一件事 - 您列出的是“属性”，而不是“事实”。事实是您对一组维度属性采取的度量。（例如，此“人”下的订单，或此客户最近订单的美元价值等）。在这种情况下，您有多个维度属性来源，每个来源都被认为是“相同的”。

@Dems 方法是一种（也是一种很好的）方法，可以将清理后的数据与暂存/操作数据集分开。

另一个，如果您需要在报告中访问两个数据集，同时仍保持“干净”版本，则将所有属性放在您的人员/客户维度上：

   FIRST_NAME
   LAST_NAME
   SOURCE1_FIRST_NAME
   SOURCE1_LAST_NAME
   SOURCE2_FIRST_NAME
   SOURCE2_LAST_NAME

对于用户社区期望从源 2 中看到名称的度量报告，您可以使用 source2 属性。对于期待来源 1 的人，请使用它。对于寻找“符合”名称的处理结果的人，请使用 main 属性。

【讨论】：