1

我正在从事务表重建 Factless Fact 表。有明显的共享昏暗，如 Org、Status、Service、ServiceAction、Send Date 等。但是，我正在尝试解决 2 个问题：

  1. 在 Transaction 表上，有用于电话、电子邮件、chkbxRequestReceipt 等值的自由表单输入字段。它们都与 TransactionKey 直接相关。如果我将这些字段从事实表中拉出到它们自己的暗淡中，它会创建一个似乎不正确的 1-1 暗淡事实关系。

  2. ServiceAction dim 是事实表上的 1 个字段，但随后分解为 3 个不同的 dim 表。这样做是因为服务几乎不共享公共字段。每个 ServiceAction 都有 1 个事务。所以 3 个服务表中的行总和 = 事务表的总行数。

任何人都可以就最好的建模方法提供建议吗？

4

2 回答 2

1

  1. 您可以将电话、电子邮件、chkbxRequestReceipt 视为退化维度（或多个退化维度）。退化维度是没有维度表的维度。当事实表具有事务级别粒度时，您具有退化维度。

  2. 关于三个表ServiceAction。我的建议是将它们放在同一个维度表中，但我知道您将拥有一个包含很多 NULL 的表。如果您只是手动编写报告，三个表不是问题，但如果您使用利用维度模型自动生成 SQL 代码的工具，那么您可能需要一个维度表。

您甚至可以认为让三个不同的维度共享事实表上的同一列，这会起作用，但如果业务用户可以创建自己的报告，这可能会有点混乱。无论如何，在这种情况下，您还需要创建第四个维度AllSerivceAction，以防您需要创建要显示所有呼叫以及有关信息的报告ServiceAction

于 2015-03-18T21:22:51.983 回答
0

1)并非每个数据项都必须属于维度模型。维度应该是您分析度量的依据。您的用户是否会通过电话号码、电子邮件地址或是否要求收据来查看您的任何措施？如果不是，这些东西很可能不属于您的维度模型。它们可能属于规范化仓库层或报告数据库（如果您也有这些）。

如果有人坚持认为这些必须在维度模型中可用（并且他们的推理是合理的 - 比如说，他们首先使用更明显的维度进行分析，然后偶尔他们需要查看其中一个数据项以对他们奇怪的事情采取行动'已经找到）：

  • 首先检查这些是否应该是现有维度的属性。可能电子邮件地址和电话属于像 Org 这样的维度，或者可能属于您没有提到的 Customer 或 Person 维度。如果它们在概念上属于一起但不适合模型中的现有维度，则值得考虑是否应该添加一个维度。您已经提到这些是自由文本，因此如果您采用这种方式，您可能需要将数据质量作为 ETL 流程的一部分进行管理。
  • 如果它们在另一个维度上没有意义，或者如果您有任何带有评论/注释之类的自由文本字段，那么 Ralph Kimball 处理自由文本字段的方法是将它们推到一个维度中，以便人们可以将它们添加到当他们需要的时候。

2)老实说，根据给出的信息很难判断这是否正确。如果不了解更多关于什么是服务、什么是 ServiceAction、ServiceAction 维度中存在哪些字段等信息。我不想为此猜测合适的设计。如果添加更多信息，我会很乐意重新访问。

于 2015-05-24T21:03:55.717 回答