关于隐藏日历表单,你应该知道的那个事儿

盆友们,闲着无聊,大家来看看下面这个表单,如果添加这个%Months的度量值后应该显示的值是多少呢?

%Months =
DIVIDE (
    SUM ( Sales[Amount] ),
    CALCULATE (
        SUM ( Sales[Amount] ),
        ALL ( Sales[Date].[月份] )
    )
)

关于隐藏日历表单,你应该知道的那个事儿_第1张图片
哈,结果全是100%,惊不惊喜,意不意外?hmmm,看起来好像哪里不对的样子?

关于隐藏日历表单,你应该知道的那个事儿_第2张图片

产生这个奇怪现象的原因吗,就是因为当前表中的Date列是一个日期数据列,在默认情况下Power BI会自动为Date或Date/Time数据类型的字段创建隐藏的日期表,从而构建日期层次结构。也就是说,相当于Power BI在你的数据集当中偷偷的创建了下面这个日期表,然后跟你的当前这个日期列又关连在了一起。并且,为了显示好看,它还很贴心的把单词类型Month列和Quarter列按照实际代表的日期顺序进行了排序,这样再使用这些列创建视觉对象时就不会尴尬的按照字母顺序排序了。

关于隐藏日历表单,你应该知道的那个事儿_第3张图片
Power BI这么做的直观结果就是每个表单中的日期列,你都能看得下面有一个日期层次结构,能让你很方便的按照月,季度或年信息来对数据进行聚合现实。而从后台看,这些日期层次结构中选择字段实际上就是来自于这个隐藏的日期表内的字段,相当于隐藏日期表内的字段作为筛选条件参见了运算。

Power BI这种自动生成隐藏日历表的功能确实简化了数据建模步骤,但是也挖了个小坑给用户,特别刚刚开始接触DAX函数的盆友们,那就是,稍不留神就可能忘记了隐藏字段对当前DAX表达式计算结果的影响。

之所以%Months的计算结果都是100%是因为在CALCULATE函数内,ALL函数只去掉了日期层次结构列中Sales[Date].[月份]这个列上的筛选上下文。而实际在当前可视化表当中,除了有Sales[Date].[月份]列和Amount列以外,还有一个隐藏的Sales[Date].[MonthNo]列,这个列作为月份列的排序依据也被添加了进来并且还作为筛选上下文对计算结果产生了影响。这样,在Sales[Date].[MonthNo]筛选条件的影响下,CALCULATE函数的计算结果都是当前月份对应的Amount值,而不是全部12个月对应的Amount值的总和,因此%Month的值都是100%。

要想获得所要结果,需要再用一个ALL函数将Sales[Date].[MonthNo]列上的筛选条件也清除掉,就大功告成了。

%Months =
DIVIDE (
    SUM ( Sales[Amount] ),
    CALCULATE (
        SUM ( Sales[Amount] ),
        ALL (
            Sales[Date].[月份],
            Sales[Date].[MonthNo]
        )
    )
)

关于隐藏日历表单,你应该知道的那个事儿_第4张图片

你可能感兴趣的:(Power,BI玩具箱,PowerBI)