5
我正在从一大堆事务性事实表转移到一个更复杂的聚合，快照等图像的情况下工作。在过去，有一些情况下数据需要通过聚合月，但以前的开发人员刚刚将它所属月份第一天的关键字放入事实表中的列中，并将其指向通常的日期维度。这似乎可以正常工作，我们在每个日期维度的多维数据集中都有日/月/年层次结构，并且用户在需要按月查看事务时表现良好。如何设计尺寸仓库中日期的缩小尺寸表并在SSAS中使用？
当我四处阅读 - 主要是Kimball的工作，但也有其他指导 - 建议是我们应该在这些情况下使用“缩小的维度”。 The Kimball Group even specifically mention it in regards to a Month dimension。但是我实际上并没有找到关于通过这篇文章实施它们的大量信息，并且简单地写了一些似乎是重新措词的部分。
我的一个特别关注的问题的是，目前，使用我们的立方体人们习惯把各种不同类型的日期年 - 月 - 日层次的一个日期维度，他们仅仅只去当这就是他们所需要的时候，降到月级。如果这将导致一个单独的维度与年度层次结构，那么它似乎可能是不受欢迎的混乱。但这是用意吗？
链接文章中的最后两段是我发现的唯一解决方法，它应该如何在表示层工作，而我只是没有得到他们想要描述的内容。对于如何在立方体中显示它，感觉很简短。通常情况下，我只是试错了，但时间表非常紧张。所以...
- 如果我这样做，多维数据集中的预期显示是什么？我会有两个单独的日期维度，只有一个月的月份？
- 如果以上内容是正确的，那么真的有很多观点，因为人们目前可以愉快地在没有它的情况下每月查询事物吗？我觉得我错过了真正的好处。我可以看到它在语义上更加正确（我们处于月份级别，因此，在本月的第一天举行哈希会显示不相关的属性），但对于已经习惯了这一点的用户，我不相信这是足够的理由现在花更多时间在这个上面。我可以看到它可以执行得更好，因为它会是一个更小的维度，但我们现在没有性能问题。我错过了什么吗？
- 如果我确实继续进行这些更改，那么有关让缩小的尺寸在多维数据集中工作的任何提示？通常情况下，我可以在网上挖掘，直到我缩小到最好的几个选项的范围，但实际上并没有太多的东西，我很乐意听到之前做过这个的人。没有寻找任何巨大的东西，但是要么比这篇文章或者一个小例子在技术上写得更多一些，可能会让我更清楚地知道需要做什么以及为什么。 Kimball的文章在讨论需要将基本维度加入缩小维度以查看属性时尤其困惑。
前两点是大问题，因为我知道是否需要进行任何数据仓库更改，如果是这样，我会很乐意回答这些问题，即使您不能涵盖第三点。
我去了金博尔培训，并问乔伊这件事。她基本上说，他们认为一个好的分析工具除了挖掘功能外还具有钻取功能。 MSBI堆栈本身不提供SSAS的此功能。所以迷你尺寸不会像他们所建议的那样工作。除非它仍然可以提供良好的可用性，否则我倾向于不将它们用于SSAS。将您的事实与现有日期维度相关联的问题可能存在一定程度的粒度（日期），不适用于月份级别的事实。 – mmarie
你是对的，你会得到一个完整的日期维度，然后是一个月维度。你需要更新他们的名字以适当地反映他们的内容。小型维度的另一种选择是限制这些度量，以便在钻取到不适当的级别时消除这些度量。 （这是我的建议，不是Joy的。） – mmarie
@mmarie - 谢谢，这是很棒的信息。大概解释了为什么人们在这里避免使用它们，以及为什么我在努力寻找信息！你所说的话似乎是非常有价值的信息，即使有其他可能的方式向前发展 - 有没有把它写成答案的机会？我可能不会马上接受，只是为了看看我们是否有其他想法，但肯定会因为已经有帮助而投票赞成。 –