Check your eligibility for this 50% exam voucher offer and join us for free live learning sessions to get prepared for Exam DP-700.
Get StartedDon't miss out! 2025 Microsoft Fabric Community Conference, March 31 - April 2, Las Vegas, Nevada. Use code MSCUST for a $150 discount. Prices go up February 11th. Register now.
Hi all,
I'd be interested to learn from anyone's experience (good or bad) in applying data which only changes once per year to a broader model where other fact data tables may change daily. Consider the alternatives shown in the (simplified) example below, where YearDate contains a many to one relationship to unique DateKey in a calendar, but requires other DAX techniques to overcome the many-to-many relationship to the year. YearInt contains a many to one releationship to a unique YearTable, which in turn has a one to many relationship back down to the calendar (YearKey).
The desired outcome for many of the downstream measures, and calculations between various tables in the model is that the "Price" for a particular "Commodity" applies for the entire year (all dates within that year) and not just on the 1/1/20XX. In the case of the YearDate alternative, any calculation which doesn't include all dates in the relationship back to the date table programmatically will return blank.
Any comments greatfully appreciated.
Maybe something like this - I'm sure there's an easier way. The key is to iterate over your date table so you return a value for every date.
IF ( HASONEVALUE (MasterDate_PBI[DateKey], SUMX(MasterDate_PBI, CALCULATE (YearIntData[Price]) ) )
Thanks @austinsense - so it really doesn't matter if the price reference is contained in a table configured with a YearDate or a table configured with a YearInt ?
So long as the (aggregation)x function iterates over the MasterDate table and the fact / reference table has some form of relationship to the MasterDate (either directly using datekey or indirectly using YearTable yearkey) ?
Would there be any performance differences / benefits in either approach ?
According to your description, you just need to achieve a slow change dimension for Prodcut. So in my opionion, it's not necessary to have that YearDateData table. You can use Year() function get year part from date column when you apply filters in CALCULATE() functon. See:
If you really need that table, try to use LOOKUP() function to populate Price into a date based table with Year() function on column.
Regards,
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Prices go up Feb. 11th.
Check out the January 2025 Power BI update to learn about new features in Reporting, Modeling, and Data Connectivity.
User | Count |
---|---|
143 | |
85 | |
65 | |
51 | |
45 |
User | Count |
---|---|
218 | |
88 | |
83 | |
65 | |
56 |