Should we construct bridge tables with DAX or M?
Picture stolen from here
It seems very tempting to use DAX. With DAX the code is short and clear:
IDList = DISTINCT(
UNION(
DISTINCT(Table1[ID])
,DISTINCT(Table2[ID])
))
Moreover, DAX tables do not need to be loaded as M tables. However I wonder if advantage of DAX over M is not illusory? M seems to load once and DAX seems to be calculated on the fly, maybe anytime, over and over?
DAX calculated tables are re-calculated if any of the tables it pulls data from are refreshed or updated in any way. (from https://learn.microsoft.com/en-us/power-bi/desktop-calculated-tables )
They're not re-calculated "on the fly", nor "over and over". There's no difference to the refresh cycle of your Power BI data model, between using a DAX calculated table or an M query table. You may however find that DAX calculated tables refresh faster than M, depending on the complexity of the table...
Considering M Tables, M Conditional Columns, M Custom Columns, DAX Tables, DAX Calculated Columns and DAX Measures. It is only the DAX Measures that gets created on the fly and is not a part of the data model.
So for a Simple Bridge Table, DAX Table and M Table have no real advantage over each other.
Both Tables allows one to create relationships. Now, When I say simple Bridge Table, it is something that is created from 2 or 3 tables and uses the same column to establish relationships with two or more tables.
But when the requirements become complex and agile (growing over time), the maintenance and the developments efforts also increases, if it is created by DAX. (my personal opinion and I think most people's personal opinion as well.)
If it is created by M, then it is more easy to add a new column or filter based on a logic or to replace an existing value.
Taking back to the Thumb Rule :- If it is created by DAX, then M Cannot be used on top of it to make changes. So, if the Bridge Table is created by DAX, then it won't appear in the query editor and limits the advantages of GUI to make any required simple transformations in the data.
For a Simple Bridge Table :- DAX.
But For a complex and changing requirement :- M.
Related
I'm trying to build a report in a table that returns a count of completed checklists that are filtered by 2 Date Intelligence slicers. I have the targets for that month in a table, but I'm not sure how to change the measure by what's selected in the slicer.
I would like the measure to return the Target.Monthname of the selected slicers from the table Targets. The slicer is based on the DonesafeFolder Table with "Date of Completion"
Your question is a bit hard to understand.
But from your pictures, I think you should take a step back.
when using powerBI it is recommended to use a star schema, with facts and dimensions tables. Usually you model that when you import your data (with power query).
When using a star schema you also have a date dimension with the month on the rows instead of columns and powerBI is better at handling data structured like that. to lean about designing the data model you can read MS's guide to star schemas
Of cause, if you know what you are doing, you can use your approach, but it makes things alot harder.
BTW. you can't access the values in the slicers/filters directly. they filters the column you select which are then passed to the measures you create. If your datamodel is sound they should indirectly filter your measure.
What is the best way to vertically combine two large tables of the same structure. Each table is about 2 mln rows. Is there any performance advantage to do it in M, not in DAX?
M approach
BigTable_M = Table.Combine( {Table1, Table2} )
DAX approach
BigTable_DAX = UNION ( 'Table1', 'Table2' )
I have a feeling that M way loads the tables two times. Separately each primary source (Table1 and Table2) and then again both tables while loading rows to BigTable_M. Is there any reason to suffer this double load for better performance later?
By this article it seems that M is faster.
https://www.sqlbi.com/articles/comparing-dax-calculated-columns-with-power-query-computed-columns/
Best practice would be to do it in M/Power Query first, before loading the data to the data model. You always want the data model to be quick and responsive with as little overhead in calculations. I always recommend working from the lowest level,for example, if you can do it in the source do it there, then if you can't do it there do it in Power Query, and as a last resort do it in the Dax/Power Pivot part.
This works well if you are working with a database, as you let the technology designed to do the heavy lifting/shifting of data, rather then do it all in Power BI.
If you are working with files, then it would be best to do it in the Power Query part were possible, and again let the Power Pivot engine be as quick as possible.
When consulting with clients data models, both Power BI and Analysis services, most of the trouble comes from doing stuff in the data model, rather than doing it before then. For example, data type transformations, string replacement, iterative calculations, ranking etc that would be best placed to do long before it hits the model.
Doing it in the query editor, you can choose to only load the combined table into your data model while having Table1 and Table2 exist merely as staging tables. That should address your concern about loading the tables twice.
I'd expect combining them in M would result in better compression (though the difference might not be very much). Combining in M would also allow for query folding in some situations.
Is it possible to refer from Power Query (M) to DAX calculated table? I would like to get DAX table as a source to my power query.
The purpose. I have grouping table made in DAX. I would like to make econometric model with R. So I would like to transform the DAX table with R to get the model parameters. I would like to use these parameters further in DAX measures (not just display them).
Currently I dump the DAX grouping table to Excel file and then pull it up with Power Query.
Actually, there is a way.
DISCLAIMER: This is a hack. You should not rely on this way.
1. Create DAX calculated table
Input any DAX formula that evaluates to a table in Modeling > New Table.
2. Check port number using DAX Studio
Connect to your PBI Desktop data model using DAX Studio, and check the port number where the data model is hosted. It should be displayed in the right bottom of the window.
3. Import the table to Power Query
Click Get Data > Analysis Services and input the address (in my example "localhost:50293") to Server. Then navigate to your DAX calculated table.
it's not possible to refer to a DAX calculated table in M as it's loaded into DAX/Power Pivot engine after M has done the transformations. You can't write to a DAX table after loading into R as well. You can do grouping in M, or if needed run R in the Power Query. One approach that I have used has to load the data, duplicate the query, run a group/filter on the new query, then use that data in a later stage in the report.
Hope that helps
Jonee is correct. This is not possible. DAX calculated tables are computed after the M queries have loaded and you cannot feed them back into Power Query without saving them externally like you are currently doing.
The M language is more powerful than you might think and very likely could do the same grouping operations, though depending on what they are, it might be fairly difficult. You can also use R or Python script within an M query if you are more comfortable with those.
I'm trying to figure out how to get a measure to adhere to the filter set by a slicer in Power BI.
My DAX query is: Block Time Cost = SUMX( FILTER(v_Invoice_Line_Items, v_Invoice_Line_Items[IV_Item_RecID]=9), v_Invoice_Line_Items[billable_ext_price_amount])
I know very, very little about DAX so my initial query may be way off base.
It calculates as I expect, but when filter with a date range silcer the value does not update as expected or at all.
I'm pulling my data from two views in the same database, v_Invoice and v_Data_Combined. I have a page level filter on the row Record_Description to limit the data to the types I'm looking for and the measure pulls it's data from rows in the v_Data_Combined view.
The rows in v_Invoice are below.
A sample copy is here.
and the rows for v_Data_Combined, if you click they will enlarge.
A sample copy is here.
I have no relations set between the views.
How can I have a measure adhere to slicer filters?
The slicer has to be on the same table as the measures you're filtering, or on a table related to that table. If your slicer is on a column in v_Invoice and your data is from v_Data_Combined - and the 2 tables are unrelated in Power BI, the slicer from one table will have no effect on the data from the other table.
Without sample data (which can be fake data), it's hard to make further recommendations.
However, if the two tables you have aren't really related to each other, then I would recommend exploring the possibility of "lookup" tables. E.g. if you have Company_Name in both tables, then you might add a 3rd table that is a unique list of companies (their name, address, etc). Then, when you want to slice by company you would slice on this 3rd table. That slicer will then filter both related tables (without having to have the tables related to each other).
You can read more about data modeling in Power BI, and how to design lookup tables, here: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/
I have been working on Power BI for a while now and I often get confused when I browse through help topics of it. They often refer to the functions and formulas being used as DAX functions or Power Query, but I am unable to tell the difference between these two. Please guide me.
M and DAX are two completely different languages.
M is used in Power Query (a.k.a. Get & Transform in Excel 2016) and the query tool for Power BI Desktop. Its functions and syntax are very different from Excel worksheet functions. M is a mashup query language used to query a multitude of data sources. It contains commands to transform data and can return the results of the query and transformations to either an Excel table or the Excel or Power BI data model.
More information about M can be found here and using your favourite search engine.
DAX stands for Data Analysis eXpressions. DAX is the formula language used in Power Pivot and Power BI Desktop. DAX uses functions to work on data that is stored in tables. Some DAX functions are identical to Excel worksheet functions, but DAX has many more functions to summarize, slice and dice complex data scenarios.
There are many tutorials and learning resources for DAX if you know how to use a search engine. Or start here.
In essence: First you use Power Query (M) to query data sources, clean and load data. Then you use DAX to analyze the data in Power Pivot. Finally, you build pivot tables (Excel) or data visualisations with Power BI.
M is the first step of the process, getting data into the model.
(In PowerBI,) when you right-click on a dataset and select Edit Query, you're working in M (also called Power Query). There's a tip about this in the title bar of the edit window that says Power Query Editor. (but you have to know that M and PowerQuery are essentially the same thing). Also (obviously?) when you click the get data button, this generates M code for you.
DAX is used in the report pane of PowerBI desktop, and predominantly used to aggregate (slice and dice) the data, add measures etc.
There is a lot of cross over between the two languages (eg you can add columns and merge tables in both) - Some discussion on when to choose which is here and here
Think of Power Query / M as the ETL language that will be used to format and store your physical tables in Power BI and/or Excel. Then think of DAX as the language you will use after data is queried from the source, which you will then use to calculate totals, perform analysis, and do other functions.
M (Power Query): Query-Time Transformations to shape the data while you are extracting it
DAX: In-Memory Transformations to analyze data after you've extracted it
One other thing worth mentioning re performance optimisation is that you should "prune" your datatset (remove rows / remove columns) as far "upstream" - of the data processing sequence - as possible; this means such operations are better done in Power Query than DAX; some further advice from MS here: https://learn.microsoft.com/en-us/power-bi/power-bi-reports-performance