对于Expanded Table的新认识

ThxAlot

Expanded Table、Data Lineage、Auto-Exist等内容，在《DAX权威指南》里作为较为高级的概念，一般在学习者对DAX主要函数较为熟悉后才加以详细介绍。其实，这些概念在我们写第一个DAX公式时，就无时无刻不在计算中起着重要的作用，有时为我们提供了极大的便利，有时又会不声不响的给我们挖坑。

插几句题外话：

• 我一般避免计算列（Calculated Column，CC），除非用度量值实现起来有困难，因为PBI不是EXCEL，虽然我也是EXCEL公式的忠粉；
• 如果使用CC，我是尽一切可能避免使用CALCULATE/CALCULATETABLE，原因很单纯，难得有机会不用费神去分析Filter Context，而只是存粹的Row Context，何必还要自找麻烦呢；
• 我一直很推崇Expanded Table在（度量值）计算中的使用，虽然牺牲了一点点性能，却能（起码让我自己可以）轻易厘清从*端到1端逆向传递的Filter Propogation；
• 在EH上发帖，防火防盗防遗忘，过些时日后还能翻得到，可以温故知新；
  

回到正题，这两天偶然的机会，让我不得不在CC里用上了CALCULATE，本来只是一个看上去比较简单的公式，我以为结果也就顺理成章的出来了，没想到结果不对，咋看一眼看不出哪里不对，分析半天无果，于是又重新把《DAX权威指南》翻出来，在有关CC的章节里翻看，希望能得到答案，可惜又无果。于是祭出我的“念念不忘必有回响”大法——实际上就是放一放，该吃吃该喝喝但不彻底忘记，说不定什么时候灵光一现有答案。哈，大法又一次起了作用，今天无意中在SQLBI上看到这么一句“Tables in DAX are always expanded”，也就是Expanded Table，回头来已验证，成了，赶紧屁颠的来EH把这点新的新的记录下来，同时也与各位同飨。

简化后的data model很简单：

然后我添加了一个简单的CC（情况一）


问题来了，我原来预计所有的结果都应该是30，因为我认为计算的过程是这样的（以第一行Num=10为例）：
Conn_F[Num] in {20, 30}作为Filter Modifier，把原本通过context transition转化的Conn_F[Num]=10覆盖了，对于每一行都是这样；然后MAX(Conn_F[Num])的结果都应该是30。


但骨感的现实却是这样。。。

为什么呢？就像标题里说的那样，因为Expanded Table，因为Expanded Table，因为Expanded Table！
就像前面提到的那句“Tables in DAX are always expanded”，如果Expanded Table在此处也发挥作用的话，那么实际的情况应该是这样


进行验证：


到此结合Expanded Table这样去理解：
虽然Conn_F[Num] in {20, 30}作为Filter Modifier，把原本通过context transition转化的Conn_F[Num]=10覆盖了，但是Conn_D[Num]列在Expanded Table的作用下，会得到Conn_D[Num]=10，并通过已有关系和将这一筛选和Conn_F[Num] in {20, 30}共同作用，这样就会得到“情况一”中的空值了。

再次验证：

Voilà，终于得到预期的结果，印证了以上关于Expanded Table的想法，也是我对于Expanded Table的有一点心得。

后记：
虽然到目前为止，我并没有找到“Expanded Table同样存在于Calculated Column中”的明确表述，但通过以上的例子，我个人确信是存在这股“神秘力量”的。如有哪位老师有其他的理解或者类似的佐证，希望可以共享和探讨！

Enjoy DAX!

flashevil

一句话总结：计算列的行上下文 不仅包括当前表，还包括当前表的扩展表。  

ThxAlot

后记的后记：
这几天暂时没有电脑可用，索性就把The Definitive Guide to DAX又翻出来温故知新，终于了结了这桩（于我个人而言的）悬案：
Whenever one references a table in DAX, it is always the expanded table.

机智

学习了，不错