3

キューブではよくあることですが、ユーザーは、階層に収まらないものを階層的に表示することを望んでいます。彼らは日 > 週 > 月 > 四半期 > 年を階層として見たいと思っていますが、週の問題は、1 か月だけでなく 1 ～ 2 か月の一部になる可能性があることです (さらに、2 四半期の一部、学期、年）。

私の質問は、属性の関係を設定する方法と、階層を設定する方法です。これが私が持っているものですが、最適ではないことはわかっています。

階層 (サイクル == 週):

階層

属性の関係:

属性関係 多対多の関係であるため、Cycle -> Year はありません。

4

2 に答える 2

6

考慮すべき週には、次の 4 つのタイプがあります。

  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 に答える