June 5, 2019 at 2:00 pm
edit
June 5, 2019 at 7:39 pm
You may be missing the purpose of a role-playing dimension. In the case of a Date dimension, you only need to consider creating multiple versions of the dimension if you have different date attributes in your fact that the users want to use in their analysis.
A good example of this is an Order fact table with Order Date, Delivery Date & Ship Date. A common approach is to then create a different Date dimension for each of these date attributes in your fact, or create multiple relationships and control which one is active by using DAX formulas.
What you're describing above is that you want to create a separate Date dimension for each fact table, which shouldn't be necessary. If you think it is, please provide more info about your design.
June 6, 2019 at 1:07 pm
It's difficult to give accurate advice without knowing the data or your requirements, but it seems odd to have a many-to-many relationship between your two facts.
Do you need to use attributes in your factRack table to filter the data in the factKabel table, and if so why aren't those in separate dimensions? I'd try to get to a regular star-schema first, if that's at all possible...the fact that you have ambiguous paths is concerning, even if you're able to work around it by using the USERELATIONSHIP function in DAX. Some data and report examples would be helpful.
Also read this: https://www.sqlbi.com/articles/many-to-many-relationships-in-power-bi-and-excel-2016/
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply