2

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

  • 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，如果它有什么不同的话。

4

2 回答 2

1

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

在这里，您将拥有一个具有两个维度的事实表 - 用户和日期。您也可以将地址和语言作为事实的维度保存，但这些实际上只是用户的属性。

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

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

于 2012-12-22T02:38:29.210 回答
0

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

于 2012-12-20T14:49:33.087 回答