2011-12-28 89 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供应商都适用。