sql-server - 如何为维度仓库中的日期设计收缩维度表并在SSAS中使用？

Question

我所面临的情况是，我们正在从拥有一堆事务性事实表转向具有聚合、快照等的更复杂的图景。过去，有一些情况需要聚合数据按月，但以前的开发人员只是将其所属月份的第一天的键放入事实表的列中，并将其指向通常的日期维度。这似乎工作正常，我们在每个日期维度的多维数据集中都有日/月/年层次结构，并且当用户需要按月查看事物时，他们做得很好。

当我四处阅读时 - 主要是 Kimball 的作品，但也有其他指南 - 建议我们在这些情况下应该使用“缩小的维度”。 The Kimball Group even specifically mention it in regards to a Month dimension 。但在那篇文章之后，我确实没有找到有关实现它们的大量信息，也没有找到似乎重新表述其中部分内容的简短文章。

<小时/>

我特别关心的一个问题是，目前，使用我们多维数据集的人们习惯于为具有年月日层次结构的每种不同类型的日期使用一个日期维度，而且他们只是当他们需要时，降低到月份水平。如果这将导致一个具有年月层次结构的单独维度，那么它看起来可能会是不受欢迎的困惑。但这是意图吗？

链接文章中的最后两段是我发现的唯一解决如何在表示层中工作的内容，但我只是不明白他们试图描述的内容。感觉很短的几个例子来充实它应该如何出现在立方体中。通常情况下，我只会反复试验，但时间非常紧迫。所以...

• 如果我这样做，立方体中的预期显示是什么？我是否可以有两个单独的日期维度，其中一个仅分割为月份？
• 如果上述内容正确，那么这真的有什么意义吗？因为人们目前可以在没有它的情况下愉快地按月查询事物？我觉得我错过了真正的好处。我可以看到它在语义上更正确(我们处于月份级别，因此保留该月的第一天是很麻烦的，并且会显示不相关的属性)，但是对于已经习惯了这一点的用户，我不相信这是足够的理由现在花更多的时间在这上面。我可以看到，如果尺寸更小，它的性能会更好，但我们目前并没有遇到性能问题。我错过了什么吗？
• 如果我继续进行更改，有什么关于让缩小的维度在多维数据集中工作的提示吗？通常情况下，我可以在网上进行挖掘，直到将范围缩小到最好的几个选项，但实际上没有太多选择，我很感激以前做过这件事的人的来信。不是在寻找任何大的东西，而是写一些比那篇文章技术性更高一点的东西或者一个小例子可能会让我更清楚地知道需要做什么以及为什么。当讨论需要将基本维度加入到缩小维度才能查看属性时，Kimball 文章尤其让我困惑。

前两点是最重要的，因为我知道是否需要对数据仓库进行任何更改，如果需要的话就完成它们 - 我会很高兴得到这些问题的答案，即使您不能涵盖第三点。

Answer 1

这不是答案，也不是 Cognos fanboi 的回复。为了进行比较，我想强调一下如何在其他工具中对多粒度事实进行建模。

http://www-01.ibm.com/support/knowledgecenter/SSWGNW_8.0.0/com.ibm.swg.im.cognos.ug_best.8.4.0.doc/ug_best_id1339multi-factmulti-grainquery.html%23multi-factmulti-grainquery

http://www.cognoise.com/index.php?topic=17992.0

在第一个链接中:

• 每月表有一个月份键，并连接到日历表中的月份
• 每日表有一个日期键，并连接到同一个日历表
• 该链接没有显示您在幕后定义层次结构级别，以便该工具自动知道不要重复计算每月级别数据
• 结果是该工具自动知道如何汇总事实

我不是 SSAS 专家，但它似乎不支持这种功能。

如果是这种情况，那么在我看来，“正确”地对数据建模是没有意义的。我所说的正确是指将特定月份分配给仅在每月级别定义的事实。

到目前为止，我认为通过指定该月中的特定日期来建模没有问题。如果事实表都处于同一级别(每月)，那么我们知道表中的日期代表一个月。至少您可能想要施加一个检查约束，以确保它是本月的第一天，这样就不会出现歧义。

结果是，当您按月观察每月和每日的事实时，一切都是一致的。当您每天观察每月和每日的事实时，您会在月初看到很大一部分。如果您可以使用 SSAS 隐藏此级别的度量..问题就解决了。