Question

维度ID记录是否也可以用作列（属性）？我不知道这是否有效，或者如果我这样做是违反最佳做法的话。这里有一个更详细的解释，为什么我要问这个，以及我在寻找什么：我有一个只有6条记录的维度，称为过期维度。它看起来如下：

    PastDueBandDimID     PastDueMin     PastDueMax     PastDueDesc
    _____________________________________________________________________
    1                    0              0              Current
    _____________________________________________________________________
    2                    1              29             1-29 Days Past Due

在30-59天/ 60-89天/ 90-180天。这个模式一切正常，但我想用这个数据创建一个用户层次结构，所以我可以用不同的方式对它进行分组。所以我想做的就是在DSV中创建名为1-29 / 30-59的其他字段....并在这些字段中引用DimID，这样我就可以创建我的Hierarchy了。我觉得这不是一个好方法，但我没有其他想法。任何建议表示赞赏！我希望在0-59天和60-180天的时间内对我的报告进行分组（在所有情况下除外），并且用户层次结构将使用户能够执行此操作。

Answer 1

在进行这样的分段时，我几乎总是在聚合事实上创建物理存储桶列，而不是“过期”维度。

我可以理解构建此维度的诱惑，因为它非常“灵活”，但是当您发现它使得使用自动化工具（例如ssas）变得更加困难时，以及迫使您不断更新事实表反映新的“过期”维度值。

相反，为什么不只是构建一个位于事实之上并且每天重建的聚合（如果你的数据库足够强大，甚至是视图）。以发票为例：

Invoice
Invoice Due Date
PastDueLTE29 (1 if <= 29, 0 otherwise)
PastDue30to59 (1 if >= 30 and <= 59, 0 otherwise)
PastDue60to89 (1 if >= 60 and <= 89, 0 otherwise)
PastDue90to180 (1 if >= 90 and <= 179, 0 otherwise)
PastDueGTE180 (1 if >= 180, 0 otherwise)

如果您想要分组，请说明所有发票＆lt;逾期60天，您只需过滤前两列中的任何一列= 1。

如果您真的想要一个层次结构，那么您是否只能在表中添加几列？

我真的不喜欢在列名中使用“Level”但是：

PastDueBandDimID
PastDueLevel1Name ("Past Due" or "Current")
PastDueLevel2Name ("1-60" or "61-180" or "180+")
PastDueLevel3Name ("1-30", "31-60", "61-90", "90+"
PastDueLevel3Min
PastDueLevel3Max

可以使用维度ID记录，也可以用作列（属性）？

1 个答案: