<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Cardinality confusion in a measure in DAX Commands and Tips</title>
    <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3597783#M139023</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="664392" data-lia-user-login="MJS_00" class="lia-mention lia-mention-user"&gt;MJS_00&lt;/a&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Here's my explanation:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Iterators create row context but not filter context.&lt;/LI&gt;
&lt;LI&gt;The result of any table expression is determined by the filter context in which the expression is evaluated. Row context does not in itself affect the result of a table expression.&lt;/LI&gt;
&lt;LI&gt;The outer SUMX iterates over the rows of &lt;STRONG&gt;VALUES ( 'Product' )&lt;/STRONG&gt;, and for a given row it creates row context (corresponding to a single row of &lt;STRONG&gt;'Product'&lt;/STRONG&gt;) but not filter context.&lt;/LI&gt;
&lt;LI&gt;Therefore, within the inner SUMX, the reference to the &lt;STRONG&gt;Sales&lt;/STRONG&gt;&amp;nbsp;table is within the same filter context in which the entire expression is evaluated. Nothing has been done to cause &lt;STRONG&gt;Sales&lt;/STRONG&gt;&amp;nbsp;to be evaluated in a different filter context.&lt;/LI&gt;
&lt;LI&gt;If we wanted to apply the current row of &lt;STRONG&gt;VALUES ( 'Product' )&lt;/STRONG&gt; as an equivalent filter, we could make use of context transition (which means transforming row context into an equivalent filter context), which could be achieved by changing &lt;STRONG&gt;Sales&lt;/STRONG&gt; to either:
&lt;UL&gt;
&lt;LI&gt;&lt;STRONG&gt;CALCULATETABLE ( Sales )&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;RELATEDTABLE ( Sales )&lt;/STRONG&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;It looks like page 190 of book addresses "Leveraging context transition in iterators" which should help with understanding this.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Also see:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://www.sqlbi.com/articles/understanding-context-transition-in-dax/" target="_blank" rel="noopener"&gt;https://www.sqlbi.com/articles/understanding-context-transition-in-dax/&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://www.sqlbi.com/articles/row-context-and-filter-context-in-dax/" target="_blank" rel="noopener"&gt;https://www.sqlbi.com/articles/row-context-and-filter-context-in-dax/&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html" target="_blank" rel="noopener"&gt;https://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Hopefully that helps! Post back if needed &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards,&lt;/P&gt;
&lt;P&gt;Owen&lt;/P&gt;</description>
    <pubDate>Fri, 22 Dec 2023 00:53:11 GMT</pubDate>
    <dc:creator>OwenAuger</dc:creator>
    <dc:date>2023-12-22T00:53:11Z</dc:date>
    <item>
      <title>Cardinality confusion in a measure</title>
      <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3597623#M139013</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I am confused by the cardinality of this measure which appears on page 189 of the Definitive Guide to Dax 2nd edition:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;SalesAmoutHighCardinality =&lt;BR /&gt;SUMX(&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; VALUES('Product'),&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; SUMX(&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Sales,&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IF(&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Sales[ProductKey] = 'Product'[ProductKey],&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 'Product'[Unit Price]* Sales[Quantity],&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; )&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; )&lt;BR /&gt;)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The data model is the standard Contoso model with a 1 to many relationship between Product &amp;amp; Sales.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The book states that "&lt;SPAN&gt;the inner SUMX always iterates over the whole Sales table, relying on the internal IF statement to check whether the product should be considered or not for the calculation. In this case the outer SUMX has the cardinality of Product, whereas the inner SUMX has the cardinality of Sales. The cardinality of the whole expression is Product times Sales."&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;My question is why does the inner SUMX iterate over the whole Sales table when I would assume it would be evaluated in the row context of the outer SUMX on Product (thereby filtering the Sales table for the currently iterated Product).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I understand this is a grossly inefficient construct, this question is just for my understanding. Any help here would be greatly appreciated.&lt;/P&gt;</description>
      <pubDate>Thu, 21 Dec 2023 20:36:36 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3597623#M139013</guid>
      <dc:creator>MJS_00</dc:creator>
      <dc:date>2023-12-21T20:36:36Z</dc:date>
    </item>
    <item>
      <title>Re: Cardinality confusion in a measure</title>
      <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3597783#M139023</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="664392" data-lia-user-login="MJS_00" class="lia-mention lia-mention-user"&gt;MJS_00&lt;/a&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Here's my explanation:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Iterators create row context but not filter context.&lt;/LI&gt;
&lt;LI&gt;The result of any table expression is determined by the filter context in which the expression is evaluated. Row context does not in itself affect the result of a table expression.&lt;/LI&gt;
&lt;LI&gt;The outer SUMX iterates over the rows of &lt;STRONG&gt;VALUES ( 'Product' )&lt;/STRONG&gt;, and for a given row it creates row context (corresponding to a single row of &lt;STRONG&gt;'Product'&lt;/STRONG&gt;) but not filter context.&lt;/LI&gt;
&lt;LI&gt;Therefore, within the inner SUMX, the reference to the &lt;STRONG&gt;Sales&lt;/STRONG&gt;&amp;nbsp;table is within the same filter context in which the entire expression is evaluated. Nothing has been done to cause &lt;STRONG&gt;Sales&lt;/STRONG&gt;&amp;nbsp;to be evaluated in a different filter context.&lt;/LI&gt;
&lt;LI&gt;If we wanted to apply the current row of &lt;STRONG&gt;VALUES ( 'Product' )&lt;/STRONG&gt; as an equivalent filter, we could make use of context transition (which means transforming row context into an equivalent filter context), which could be achieved by changing &lt;STRONG&gt;Sales&lt;/STRONG&gt; to either:
&lt;UL&gt;
&lt;LI&gt;&lt;STRONG&gt;CALCULATETABLE ( Sales )&lt;/STRONG&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;STRONG&gt;RELATEDTABLE ( Sales )&lt;/STRONG&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;It looks like page 190 of book addresses "Leveraging context transition in iterators" which should help with understanding this.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Also see:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://www.sqlbi.com/articles/understanding-context-transition-in-dax/" target="_blank" rel="noopener"&gt;https://www.sqlbi.com/articles/understanding-context-transition-in-dax/&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://www.sqlbi.com/articles/row-context-and-filter-context-in-dax/" target="_blank" rel="noopener"&gt;https://www.sqlbi.com/articles/row-context-and-filter-context-in-dax/&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html" target="_blank" rel="noopener"&gt;https://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Hopefully that helps! Post back if needed &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards,&lt;/P&gt;
&lt;P&gt;Owen&lt;/P&gt;</description>
      <pubDate>Fri, 22 Dec 2023 00:53:11 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3597783#M139023</guid>
      <dc:creator>OwenAuger</dc:creator>
      <dc:date>2023-12-22T00:53:11Z</dc:date>
    </item>
    <item>
      <title>Re: Cardinality confusion in a measure</title>
      <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3598795#M139055</link>
      <description>&lt;P&gt;Hi Owen,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Many thanks for your detailed answer, it makes much more sense now. I have a couple of follow up points:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I am assuming that the external filter context would still apply when this measure was executed which would result in a appropriately filtered Sales table. If so then the total cardinality in reality would never be as high as Product * Sales. If this is correct, saying this measure has a total cardinality of Product * Sales is more of a standalone theoretical way of just looking at the measure itself.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regarding your point on introducing filter context via CALCULATETABLE or RELATEDTABLE. Is there a generally perference for one over the other?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Many thanks for your help.&lt;BR /&gt;&lt;BR /&gt;Matt&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 22 Dec 2023 13:24:38 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3598795#M139055</guid>
      <dc:creator>MJS_00</dc:creator>
      <dc:date>2023-12-22T13:24:38Z</dc:date>
    </item>
    <item>
      <title>Re: Cardinality confusion in a measure</title>
      <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3599341#M139081</link>
      <description>&lt;P&gt;&lt;a href="javascript:void(0)" data-lia-user-mentions="" data-lia-user-uid="664392" data-lia-user-login="MJS_00" class="lia-mention lia-mention-user"&gt;MJS_00&lt;/a&gt;&amp;nbsp;You're welcome &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Yes, the external filter context would apply to the measure as a whole, so &lt;STRONG&gt;Sales&lt;/STRONG&gt; or &lt;STRONG&gt;Product&lt;/STRONG&gt; would be evaluated in that external filter context. I guess the authors are assuming no filters have been applied for the purpose of that discussion.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I personally prefer &lt;STRONG&gt;CALCULATETABLE&lt;/STRONG&gt;, as it makes it easier to identify instances of context transition in a consistent way by looking for &lt;STRONG&gt;CALCULATE/CALCULATETABLE&lt;/STRONG&gt; or measure references.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;RELATEDTABLE ( tbl )&lt;/STRONG&gt; is equivalent to &lt;STRONG&gt;CALCULATETABLE ( tbl )&lt;/STRONG&gt; where tbl is a physical table. However, &lt;STRONG&gt;CALCULATETABLE&lt;/STRONG&gt; allows for further filter arguments.&lt;/P&gt;
&lt;P&gt;(see &lt;A href="https://dax.guide/relatedtable/" target="_blank" rel="noopener"&gt;here&lt;/A&gt;)&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards&lt;/P&gt;</description>
      <pubDate>Fri, 22 Dec 2023 23:39:08 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3599341#M139081</guid>
      <dc:creator>OwenAuger</dc:creator>
      <dc:date>2023-12-22T23:39:08Z</dc:date>
    </item>
    <item>
      <title>Re: Cardinality confusion in a measure</title>
      <link>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3600024#M139104</link>
      <description>&lt;P&gt;Thank you Owen &amp;amp; many thanks for the clarification on RELATEDTABLE vs CALCULATETABLE!!&lt;/P&gt;</description>
      <pubDate>Sun, 24 Dec 2023 00:56:18 GMT</pubDate>
      <guid>https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/Cardinality-confusion-in-a-measure/m-p/3600024#M139104</guid>
      <dc:creator>MJS_00</dc:creator>
      <dc:date>2023-12-24T00:56:18Z</dc:date>
    </item>
  </channel>
</rss>

