【问题标题】:Dimensional Modeling - Common Attribute Used In Various Dimensions Compositie Keys维度建模 - 各种维度组合键中使用的通用属性
【发布时间】:2015-03-20 05:21:14
【问题描述】:

我在这里遇到了以前从未遇到过的情况。

我有同一个 ERP 系统的多个实例,但因卫星区域而异。 每个语言环境都分配有自己的 ID。

在每个卫星位置内,数据库架构与其他数据库架构相同、相同的表、相同的值。

当组合来自这些语言环境中的两个或更多的表时,假设是部件,它们的自然操作键将是相同的,但附加的属性数据可能会有所不同。由于我需要能够根据它来自哪个卫星区域设置链接到一个部件,我想我需要一个复合键 - 部件 ID 和卫星 ID。

现在这对于这个单一维度来说是可以的,但是,这个卫星 ID 在许多其他维度的其他地方以相同的方式使用。它也是许多事实表的主要切片器。

我应该如何对待这个属性?把它放在它自己的维度里,雪花呢?还是将值推入每个维度(重复),然后让事实表将唯一的 FK 保存到卫星维度?

【问题讨论】:

  • 您能否澄清“附加属性数据可能不同”的含义。并确保用一个例子来补充(抓住问题和例外的本质)。
  • Satellite ID 将不同,但 Natural 密钥将相同。其他属性数据,例如描述、度量单位,也许还有商品代码可能会有所不同,因为每个 Satellite 区域设置处理的部分与其他部分略有不同。希望这可以澄清。

标签: data-warehouse dimensional-modeling star-schema snowflake-schema


【解决方案1】:

在理想情况下,解决方案是在 ETL 过程中将 Natural Operational Keys 替换为每个 PartID/SatelliteID 唯一的代理键(例如,对于处于相同情况的每个维度,我确实怀疑对于时间维度,您可以跳过代理键)。

当然,这不仅需要在维度表中添加此代理键,还需要在事实表中添加。

如果您需要按卫星报告,卫星 ID 列也将作为单独的维度显示。

这将是一个理想的解决方案。

一个快速而肮脏的解决方案可能是您建议在自然键旁边添加一个带有卫星 ID 的附加列,您需要为每个维度(同样除了时间维度)和事实表添加此列。然后,您需要在每次加入时都包含 Satellite ID 列。

在这种情况下,在您的报告工具中,您需要将卫星 ID 作为复合 ID 的一部分,由自然操作密钥和卫星 ID 组成。

您还可以创建一个特定的卫星维度,您可以使用它来为特定的卫星选择数据。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-13
    • 2016-08-22
    • 1970-01-01
    • 2013-03-15
    • 1970-01-01
    相关资源
    最近更新 更多