如何使用自然键创建事实表答案

【问题标题】：How to create a fact table using natural keys如何使用自然键创建事实表
【发布时间】：2012-12-20 14:11:29
【问题描述】：

我们有一个包含四个维度表和一个事实表的数据仓库设计：

dimUser id、电子邮件、名字、姓氏
dimAddress id, 城市
dimLanguage id，语言
dimDate id、startDate、endDate
factStatistic id、dimUserId、dimAddressId、dimLanguageId、dimDate、loginCount、pageCalledCount

我们的问题是：我们要构建包含计算统计信息（取决于 userId、日期范围）和填充外键的事实表。

但我们不知道如何使用，因为我们不了解如何使用自然键（根据我们阅读的文献，这似乎是我们问题的解决方案）。

我相信一个自然键是 userId，所有计算维度数据的 ETL 作业都需要它。

但是有很多困难：

在 ETL 作业 load() 中，我们使用 INSERT IGNORE INTO 进行批量插入以删除重复项 => 我们不知道生成的代理键
如果我们创建元数据（包括一组维度名称、代理键、自然键），由于重复消除，这将不起作用

问题似乎是重复消除策略。有更好的方法吗？

我们使用的是 MySQL 5.1，如果它有什么不同的话。

【问题讨论】：

您的事实表跟踪是什么？按用户/地址/语言/“日期范围”登录？在我看来，地址和语言是用户的属性？你的日期表有范围吗？为什么不将单个日期存储在事实表中并汇总？
这是真实设计的简化模型。但它基本上是每个用户的登录和页面调用（具有地址和语言）。 loginCount 和 pageCalledCount 按日期范围聚合。
我不太了解您的问题，但如果您正在寻找一种生成和填充代理键的方法，那么我建议使用映射表来回答this question 的一种相当通用的方法。报告数据库通常使用人工键，所以我不确定您为什么要使用自然键；看来您的问题主要是实现您的 ETL 流程，而不是您的设计，尽管我可能错了。
我想我混淆了自然键和业务键这两个术语。
我正在寻找的是一种算法，我可以用它来填充我的事实表。我有一种方法，我将使用一个单独的映射表，如下所示：mappingTable - dimensionId - dimensionName - businessKeyValue 该数据将从计算维度数据的 ETL 作业创建并用于填充事实表（ s)。但是我的同事说，这是 Inmon 和 Kimball 策略的混合（因为我们部分使用单值业务键和串联的多值业务键），在可扩展性方面对我们没有好处。

标签： data-warehouse etl fact surrogate-key natural-key

【解决方案1】：

如果您的事实表跟踪每个用户的登录和页面调用，那么您应该有一组源表来跟踪这些事情，您将从那里加载事实表数据。我可能会以每个用户/登录日期一行的粒度构建事实表 - 如果可能的话，甚至更低以保留原子数据。

然后您将有一个包含两个维度的事实表 - 用户和日期。您也可以坚持地址和语言作为事实的维度，但这些实际上只是用户的属性。

您的维度应该有代理键，但也应该有源“业务”或“自然”键可用 - 可以作为维度本身的属性，或者通过您同事建议的映射表。使用映射表并没有“错误”——当有多个来源时，它确实使事情变得更容易。

如果您将业务键存储在映射表中，或者作为属性存储在维度中，那么对于要加载的每一行，实际上只需对 dim 或映射表进行简单查找（通常通过连接）即可获得用户的代理键（然后从用户那里获得用户的“当前”地址/语言以坚持事实）。日期维度通常有一个以 YYYYMMDD 或其他“自然”格式存储的代理键 - 您可以从要加载到事实中的源记录上的日期信息生成它。

【讨论】：

【解决方案2】：

不要强制单个查询，尝试在单独的查询中加载数据并在某些提供程序中混合数据...

【讨论】：

我不明白。我们已经实现了填充维度表的 ETL 作业。但是我们不知道如何将事实表中的维度条目相互连接。