DAX For SQL Folks: Part I- Intro to DAX, Power BI and Data Viz

  • Comments posted to this topic are about the item DAX For SQL Folks: Part I- Intro to DAX, Power BI and Data Viz

    Frank Banin
    BI and Advanced Analytics Professional.

  • Great article and well written.  As a leader of our data analytics team, I am well versed in SQL and T-SQL and not DAX.  This series will go along way in helping me understand how Power B/I works with data.  When my team comes to me with questions, my context (SQL) is always different than theirs (DAX) and they have to interpret from my bias/experience into DAX - and not always successfully.  Now I will have a better understanding of their context and can direct my input in more constructive ways.  I am looking forward to the rest of the series!

     

  • This is a really useful article. Thank you.

  • Thank you for this.  Very good explanation of  DAX  for us SQL programmers.

  • Great concept.  Very effective way of teaching DAX by comparing it to something we are all very familiar with already.   A little feedback.  I found it confusing sometimes when you referred to the "one-to-many side" or "many-to-one side" of a relationship.  A more terse (loved your use of this word) explanation is "the one-side" or the "many-side", IMHO.  Also, could you please put a hyperlink on the "next installment of the series" at the end there?  Wanted to go straight to it, but couldn't.  : )

  • This was removed by the editor as SPAM

  • Thank you!

    There are a few typos.

    Table DimFactResellerSales is mentioned several times, whereas the table concerned is named FactResellerSales.

    In the explanation of Expanded Tables in DAX it says "The only table with a relationship to DimProductCategory is DimProductSubCategory. DimProductSubcategory is on the one-to-many side of the relationship, ..." This should be many-to-one.

  • Useful if you need to learn DAX. But I think some of this is misleading.

    The basis of the relational model is a relation, a mathematical structure that represents a relation between sets. This is called a table in SQL. The commonly held idea that relational is about relations between tables if NOT the reason why we talk about relational databases.

    The primary key makes the relation into a function. Therefore SQL is a functional language if needs be.

    But functional programming language can only access the data via the primary key. A relational programming language can access the data via all items (columns) in the relation.

    Therefore a functional language is far less flexible than a relational one. All functions are relations, but not all relations are functions.

    The result of a function can be used by another function. The result of a relational expression is another relation, so a relational language like SQL also has the properties of closure, just as functions do.

     

     

    • This reply was modified 1 month, 2 weeks ago by  will 58232.
  • deleted

    • This reply was modified 1 month, 2 weeks ago by  will 58232.

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply