我有以下数据:
DATE COUNTRY ITEM Value
2005-01-01 UK op_rate 30%
2005-01-01 UK proc 1000
2005-01-01 UK export 750
2005-01-01 ITA op_rate 45%
2005-01-01 ITA proc 500
2005-01-01 ITA export 350
基本上是普通格式的数据,包括比率(op_rate)和其他项目,例如导出的卷和已处理的卷(“ proc”)。
我需要按SUM汇总“ proc”和“ export”,而不是“ op_rate”,因为我需要按“ proc”加权平均。
在这种情况下,合计的op_rate为: 0.45 * 500 + 0.30 * 1000 = 0.35 //而不是.75 SUM或0.375 AVERAGE
我发现所有关于加权平均值的示例都是跨度量的,但是没有一个覆盖其他维度。
最欢迎任何帮助!
答案 0 :(得分:1)
我了解到您不愿意更改模型。这里的问题是您正在尝试使用高度归一化的表,并使用它来使用OLAP工具进行分析。 OLAP工具更喜欢Fact / Dim星型架构,而Tabular / PowerBI也不例外。我怀疑这也将继续困扰着未来的需求。立即尝试更改结构是最好的时机,因为您离开的时间越长,难度就会越大。
这并不是说您无法使用工具来做您想做的事,但是由此产生的dax效率会降低,并且所需的存储将不是最佳的。
因此,在给出警告/演讲(!)的情况下,您可以执行此操作。
op_rate_agg =
VAR pivoted =
ADDCOLUMNS (
SUMMARIZE ( 'Query1', Query1[COUNTRY], Query1[DATE] ),
"op_rate", CALCULATE ( AVERAGE ( Query1[Value] ), Query1[ITEM] = "op_rate" ),
"proc", CALCULATE ( SUM ( Query1[Value] ), Query1[ITEM] = "proc" )
)
RETURN
DIVIDE ( SUMX ( pivoted, [op_rate] * [proc] ), SUMX ( pivoted, [proc] ) )
它的效率真的很低,因为它每次执行时都必须构建透视集,并且您将看到查询计划所要做的工作要比将其作为适当的Fact表持久化时要多得多。如果您的模型很大,则此措施及其引用的任何措施都可能会出现性能问题。
答案 1 :(得分:0)