3

与多维数据集通常一样,用户希望不适合层次结构的事物分层显示。他们希望将日 > 周 > 月 > 季度 > 年视为层次结构,但周的问题是它们可以是 1-2 个月的一部分,而不仅仅是 1 个月(并且扩展为 2 个季度、学期的一部分,年)。

所以我的问题是:如何设置属性关系,以及如何设置层次结构?这是我所拥有的,但我知道这不是最佳的。

层次结构(周期 == 周):

层次结构

属性关系:

属性关系 没有Cycle -> Year,因为是多对多的关系

4

2 回答 2

6

有四种类型的星期需要关注:

  1. 一年中的一周 (1-53)。层次结构:年 > 周

    您应该决定是希望第 1 周从 1 月 1 日开始,还是遵循ISO 标准

  2. 每月的第几周 (1-5)。层次结构:年 [> 季度] > 月 > 周

    您应该决定是希望第 1 周从每月的第一天开始,还是从每月的第一个星期日/星期一开始。

  3. 财政年度的一周 (1-53)。层次结构:会计年度 > 周

  4. 财政月的一周 (1-5)。层次结构:财政年度 [> 季度] > 月 > 周

于 2013-08-12T20:41:55.143 回答
4

You can leave the design as you have it, or even add the weeks to the "Calendar Time" hierarchy, thus only having one hierarchy as requested by the users. This is just what Microsoft calls a non-natural hierarchy. Analysis Services query response time is much slower for these than for natural hierarchies (those with all child levels having a relationship to their parent level). That is why you get a warning in BIDS. You just will have to test if the performance is good enough for your users. If it is, fine. If it is not, maybe fall back from the one-hierarchy solution to the two hierarchy solution described in your question. Then at least the first hierarchy would be fast, and only the second have bad performance.

There are other solutions, but they are all a bit unnatural: Some companies define months to have exactly four or five weeks so that the relationship can be set, but a reporting month starts or ends a few days before or after the calendar month. See e. g. the 4-4-5 calendar article in Wikipedia.

于 2013-08-14T16:44:40.943 回答