【问题标题】:Star Schema from multiple source tables来自多个源表的星型模式
【发布时间】:2021-07-18 03:02:51
【问题描述】:

我正在努力弄清楚如何从多个源表创建星型模式。我在一家贸易公司工作,因此数据与用户交易活动有关。我遇到的问题是我们的数据集没有可能是维度的每个字段的主 ID。相反,我们通常使用日期和帐号的组合将我们的数据联系在一起。这是 3 个源表的示例...

我想把它变成一个星型模式,看起来像......

是我将源表非规范化为一个宽表的唯一选择(将交易加入到帐号和日期的位置,并加入帐号上的用户表),为每个维度创建键,然后将其重新规范化为星号架构?星型模式是否曾经从多个源表构建?

【问题讨论】:

    标签: data-modeling data-warehouse denormalization star-schema fact-table


    【解决方案1】:

    星型模式几乎总是从多个源表创建。

    正常流程是:

    1. 填充维度表
    2. 使用您的源数据创建临时/虚拟事实记录
    3. 使用此事实记录,查找相关维度键
    4. 将实际事实记录写入目标事实表

    【讨论】:

    • 这个虚拟事实记录(第 2 步)是否可以通过连接原始源表来在一行中获得完整的“事务”来创建?我认为这是维度相互了解的唯一方式(即它们是否在同一行/记录中)。
    • 是的 - 它将包含查找相关维度所需的所有事实信息,然后填充事实表
    【解决方案2】:

    数据仓库与查询速度有关。数据仓库不应该关心数据完整性。它不应该清理或纠正不良数据。它只需要将所有数据收集到一个单独的记录中,即可呈现给模型进行分析。非规范化数据就是这样做的。

    在星型模式中,维度彼此不了解,并且与其他维度没有关系。在雪花中,维度与其他维度相关。这就是星星和雪花的主要区别。

    事件的所有元数据选项都汇总到维度中并用于切片/过滤。事件的所有可测量/计算数据都包含在事件事实中,以及对包含相关元数据的维度的引用。元数据/维度在多个事实记录中重复使用。

    根据您提供的有限示例,我建议您研究退化维度和垃圾维度。您的交易和头寸数据可能需要转换为事实和维度(退化),并且您的某些标志属性可能最好放入垃圾维度。

    您还应确保维度键清晰。一个维度不应有多个路径(帐号:交易 -> 仓位 -> 用户和交易 -> 用户),因为这会在查询时根据您遍历的关系导致不一致的结果。

    【讨论】:

      猜你喜欢
      • 2011-07-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多