2011-12-28 91 views
0

我已創建計算不同策略的新度量(此度量稱爲FK Policy Distinct Count)。MDX:在年度至今計算成員中使用截然不同的計數

然後,我創建了一個名爲CountPolicyEndorsesNull計算成員,其對使用過濾器從FK Policy Distinct Count所有策略:

(([Policy].[Endorses].&[0],[FK Policy Distinct Count])

比我新計算成員稱爲CountPolicy

SUM(EXCEPT([Policy].[Policy Status].[Policy Status],[Policy].[Policy Status].&[Void]), [Measures].[CountPolicyEndorsesNull])

接下來,我創建了一個新的成員CountNewBound

SUM(
    { 
     [Submission].[Tran Type].&[New], [Submission].[Tran Type].&[Developed] 
    }, 
    [Measures].[CountPolicy] 
) 

最後,YTDCountNewBound

SUM(YTD([Invoice Date].[Date Hierarchy].CurrentMember), [Measures].[CountNewBound]) 

很明顯,SUM函數在這種情況下不起作用。任何想法如何爲計算成員做適當的YTD計數?

enter image description here

+0

是的,它顯示正確的值。截圖是因爲比較:1 + 3 + 1 = 5,它匹配2011-01-06 YTDCountNewBound,但總計是4 – 2011-12-28 22:01:25

+0

那麼,我的問題是如何獲得計算成員的YTD計數?它有可能嗎?顯然這不可能使用SUM。 – 2011-12-28 22:15:20

+0

我不明白你的評論的第二部分...... – 2011-12-28 22:17:13

回答

0

重複計數是應該多一點謹慎管理的特別措施。這背後的理由是,評估測量時,一組以前的值保存在內存中。爲了提高性能,這個結構不被傳遞,並且很快轉換爲標量值。

再回到你的問題:

重複計數可以在一個元組進行評估沒有問題,但你會在問題得到一旦你嘗試,以評估在一組元組。一個可能的但代價高昂且並非總是可行的方法是創建一個值的層次結構,以便您可以將您的集合轉換爲維度的成員。

在您的情況下,不是使用YTD([發票日期]。[日期層次結構] .CurrentMember)函數使用另一個層次結構 - > [發票日期]。[YTD日期層次結構]。

這一切都取決於您使用的特定OLAP實現,但我想對於所有OLAP供應商都適用。