在MDX中,如何对子成员执行计算,然后聚合这些子成员?

在MDX中,如何对子成员执行计算,然后聚合这些子成员?,mdx,olap,Mdx,Olap,我有如下表所示的数据,其中Expected Shipping Amount New实际上是每个索赔计数的平均装运金额,但我无法正确地将其聚合(它应该是26.3total,而不是0)。有人知道怎么做吗 CliID | Claim Count | Expected Shipment Amount | CliId Count Expected Shipment Amount New All | 5 | 61.8 | 2

我有如下表所示的数据,其中Expected Shipping Amount New实际上是每个索赔计数的平均装运金额,但我无法正确地将其聚合(它应该是
26.3
total,而不是
0
)。有人知道怎么做吗

CliID | Claim Count | Expected Shipment Amount | CliId Count   Expected Shipment Amount New
All   |      5      |           61.8           |       2     |              0
159061|   (null)    |          (null)          |    (null)   |            (null)
159063|   (null)    |          (null)          |    (null)   |            (null)
166759|      2      |           34.2           |      1      |             17.1
166769|   (null)    |          (null)          |    (null)   |            (null)
223983|      3      |           27.6           |      1      |             9.2
此pre成员应计算每个CliID的平均值,如果没有预期发货金额,则返回null:

CREATE MEMBER CURRENTCUBE.[Measures].[Pre预期发货金额]
作为IIf(IsLeaf([Claim].[CliID].currentmember),
([Measures].[Expected Shipping Amount]/[Measures].[Claim Count]),0),
可见=0

然后,这就是应该可见的内容,以便正确地聚合所有内容:

CREATE MEMBER CURRENTCUBE.[Measures].[预计发货量新]
作为总额([措施][预计装运金额]),
可见=1


很明显,在聚合级别,它正在查看
预期发货量Pre
并返回
0
,因为聚合本身不是一个叶子,但对于聚合,我希望它计算所有子项,然后将它们相加。如何实现这一点?

在第二步中,您应该使用

CREATE MEMBER CURRENTCUBE.[Measures].[Expected Shipment Amount New]
 AS SUM(EXISTING [Claim].[CliID].[CliID].Members, [Measures].[Expected Shipment Amount Pre]),
VISIBLE=1;
一,。E
CliID
级别的成员之间的总和

编辑 您可以尝试加快速度的方法是更多地依赖内置的AnalysisServices聚合。为此,基于事实表中的
预期装运金额
列创建一个物理度量值
新的预期装运金额
,并将其聚合函数设置为“总和”。然后,在计算脚本中,只需添加

SCOPE([Claim].[CliID].[CliID].Members);
    [Measures].[Expected Shipment Amount New] = [Measures].[Expected Shipment Amount] / [Measures].[Claim Count];
END SCOPE;

这将用平均计算覆盖叶级别上的“预期装运金额新”计算,但不会说明有关
CliID
属性层次结构的
All
级别的任何内容。因此,对于这个级别,应该进行度量值的指定聚合,即
总和

您是否尝试过将
[预期装运金额预]
设置为可见,然后查询多维数据集?是的,但这显示了什么?在聚合级别(All)中,它将零显示为
[预期装运金额Pre]
,这是因为我们在这一级别上还不清楚。如果这有意义的话,我想让它总结一下我们不在一起时的孩子们。好吧-我开始理解你的要求-是不是
26.3
绝对正确为
61.8/526.3
?是的,因为
9.2+17.1=26.3
我对所有的
MDX
附加问题感兴趣。抱歉我帮不上忙。酷。不过,这似乎大大减慢了查询速度。这是意料之中的事吗?@Travis
现有的
会导致严重的减速。您可以在第一条语句中去掉
IIf
,因为第二条语句会注意到,如果您使用度量值,您将始终处于叶级,并且没有用户可以使用该度量值,因为它是不可见的。因此,计算可能会变得更简单、更快。