【问题标题】:Fact Table Recommendation事实表推荐
【发布时间】:2014-01-27 22:03:28
【问题描述】:

我有一个数据集市,它只需要获取产品的序列号、活动日期以及活动发生的地点(哪个帐户)。

有五种可能的活动。我遇到的问题是这个。其中两项活动在仓库级别进行。其余三个发生在帐户级别(WH 不适用)。然而,最终每个仓库都会汇总到一个主账户。

因此,如果我有一个事实表,我基本上需要两个 FK,并且您必须遍历事实表来构建 WH > Account 层次结构,这似乎很难维护。我想要一维表。

或者是否建议我将其拆分为两个事实表,即使每个表的唯一不同特征是活动是否发生在仓库中。

报告的目标是帐户级别,但拥有 WH 信息在某些时候可能会很有用。而且我需要检查重复项等,这就是为什么我倾向于第一个,但不知道如何适当地处理层次结构。

单一事实表设计

  • 项目:1
  • 帐号:14
  • 仓库:2
  • ActivityType:3
  • 日期:20130204
  • 序列号:123456
  • 计数:1

双重事实表设计

表 1

  • 项目:1
  • 仓库:2
  • ActivityType:3
  • 日期:20130204
  • 序列号:123456
  • 计数:1

表 2

  • 项目:1
  • 帐号:2
  • ActivityType:3
  • 日期:20130204
  • 序列号:123456
  • 计数:1

【问题讨论】:

  • 如果将仓库和账户都存储在事实表中,为什么很难“构建WH>账户”层次结构?听起来在您的报告中您将忽略仓库字段并在帐户上汇总。
  • 大卫,我的意思是,如果我想在某个时候再次查看完整的层次结构,我将不得不使用事实表作为链接。虽然我认为这可能不是问题。我想我为什么质疑这种方法是因为两者之间的层次结构是如此紧密地联系在一起,将它们保持在同一维度似乎是最佳实践。虽然听起来这可能是我最好的选择?

标签: sql data-warehouse


【解决方案1】:

我将你的情况解释为:

  • 所有活动都需要一个帐户
  • 某些活动涉及 仓库。
  • 选择仓库意味着一个帐户。这 上述两点中提到的帐户属于同一类型(有 只有 1 个帐户维度表)

在这种情况下,您应该可以使用单 FACT 表设计:

[ACTIVITY_FACT]
SK                    (Optional, i find unique surrogate PKs useful)
ITEM_SK               (Link to your ITEM_DIM table)
ACCOUNT_SK            (Link to your ACCOUNT_DIM table)
WAREHOUSE_SK          (Link to your WAREHOUSE_DIM table, -1 for no warehouse activities)
ACTIVITY_TYPE_SK      (Link to your ACTIVITY_TYPE_DIM table) 
ACTIVITY_DATE_SK      (Link to your DATE_DIM table)
ITEM_SERIAL_NUMBER
ITEM_COUNT

在您的 WAREHOUSE 维度中记录 NONE 或 NOT APPLICABLE 并为其分配一个很好的明显特殊条件 SK 值 -1 或 -9 或您的商店用于此类事情的任何内容。

对于引用仓库的活动记录,请放置相应的仓库 sk 和属于该仓库的帐户 sk。

对于不涉及仓库的活动,使用 NONE / NOT APPLICABLE 仓库维度记录和相应的 Account SK 填充仓库 sk。

现在您的事实表可以连接到您的 Account 和 Warehouse 维度表,而无需担心外部连接或空条件处理。这应该允许您和您的用户根据需要使用仓库维度数据,而不必费心管理两个包含基本相同日期的表。

【讨论】:

  • 谢谢乔。我最终使用了这种方法
【解决方案2】:

一种可能性是在单个维度表中定义层次结构。猜测你在处理什么,我想出了以下内容。

维表概要:

TABLE: Account

Account_ID  <surrogate key>
Account     <Account name, identifier>
Warehouse   (Warehouse name, identifier)

样本数据:

Account_ID   Account   Warehouse
    1           A        n/a
    2           B        n/a
    3           C        n/a
    4           W        wh1
    5           W        wh2
    6           Z        wh3
    7           Z        n/a

Account_ID 只是一个代理键,没有内在意义或价值

帐户列出帐户。在这里,我显示了五个,A、B、C、W 和 Z。选择 distinct 以获取帐户列表;通过 Account_ID 加入事实表,其中 Account = “W” 获取该帐户的所有数据(适用于许多仓库,如果适用)。

Warehouse 列出所有仓库及其关联的账户;这里,“W”是两个独立仓库的账户(wh1,wh2); Z 与仓库 wh3 相关联,但也可由具有“无”仓库的事实表使用。通过 Account_ID 加入事实表,其中 Warehouse = “wh1” 获取该仓库的所有数据。

使用它,在事实表中使用 Account_ID,您可以向下钻取任何给定帐户或特定仓库(或没有仓库,如果其中有价值的话)的所有条目。

这种方法可能有很多变化和排列。

【讨论】:

  • 谢谢菲利普。我最终使用了乔的方法,但我也在考虑这个。这两种方法都有意义,但我最终可能会重新审视这种方法。
猜你喜欢
  • 2010-11-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-31
  • 2021-05-22
相关资源
最近更新 更多