We've captured the moments from FabCon & SQLCon that everyone is talking about, and we are bringing them to the community, live and on-demand. Starts on April 14th. Register now
Hi @ImkeF & PBI Community,
I have a scenerio where I need to merge Fact table to two different Dimentions (Lookups) tables based on condition in Fact table, I know the standard method of doing it by merging both lookup table one by one with Fact table and then create a custom column but I want to avoid it instead considering Pro approach.
Condition: If FactTable[Destination] contains "EX" then DimCountry[Country] else DimDestination[Destination]
Thanks in advance
Solved! Go to Solution.
Avoid merges in Power Query wherever possible. Let the data model do the work for you.
Hi @Numan_S ,
if you think merging tables is bad (for performance), the alternative (using a Table.SelectRows(YourDimTable, (dimTable)=> dimTable[keyColumn] = [keyColumnFactTable)) is even worse, as you are referencing the DimTable in each row of your fact table. Which would theroretically call it for each row unless you use a Table.Buffer before.
But with regards to the "Pro" approach: In standard star schemas is usually no place for fields from the dimension tables in fact tables. Fact tables should only contain the keyColumns to the dimension tables and values that are unique to the row in the fact table, like usually amounts and quantities.
If you need to reference values from a dimension table, do it in the data model like @lbendlin suggested.
If the references in the data model don't work, because every other row should use a reference to a different dimension table, then considering pivoting some columns in your fact table so that the shapes match the star schema.
Or consider merging the dimension tables into one (depending on the use case). This dimension table would have a column like "Type" with entries either "Country" or "Destination". Then your condition from above ("If FactTable[Destination] contains "EX" ") would be used to create the new (Composite-)keyColumn to that new dim table.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Hi @Numan_S ,
if you think merging tables is bad (for performance), the alternative (using a Table.SelectRows(YourDimTable, (dimTable)=> dimTable[keyColumn] = [keyColumnFactTable)) is even worse, as you are referencing the DimTable in each row of your fact table. Which would theroretically call it for each row unless you use a Table.Buffer before.
But with regards to the "Pro" approach: In standard star schemas is usually no place for fields from the dimension tables in fact tables. Fact tables should only contain the keyColumns to the dimension tables and values that are unique to the row in the fact table, like usually amounts and quantities.
If you need to reference values from a dimension table, do it in the data model like @lbendlin suggested.
If the references in the data model don't work, because every other row should use a reference to a different dimension table, then considering pivoting some columns in your fact table so that the shapes match the star schema.
Or consider merging the dimension tables into one (depending on the use case). This dimension table would have a column like "Type" with entries either "Country" or "Destination". Then your condition from above ("If FactTable[Destination] contains "EX" ") would be used to create the new (Composite-)keyColumn to that new dim table.
Imke Feldmann (The BIccountant)
If you liked my solution, please give it a thumbs up. And if I did answer your question, please mark this post as a solution. Thanks!
How to integrate M-code into your solution -- How to get your questions answered quickly -- How to provide sample data -- Check out more PBI- learning resources here -- Performance Tipps for M-queries
Avoid merges in Power Query wherever possible. Let the data model do the work for you.
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.
Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
| User | Count |
|---|---|
| 11 | |
| 10 | |
| 7 | |
| 7 | |
| 6 |