Forum Discussion
Creating Relationships with duplicative values
Hi Anonymous
The issue likely stems from bidirectional filtering in your many-to-one relationship. When relationships are set to filter in both directions, especially in a many-to-one setup, it can cause context propagation issues and inflated aggregations, leading to incorrect calculations like the 27.17 ratio you're seeing. Even though you created a composite key, if the relationship is still ambiguous or if the data model allows both tables to filter each other, Power BI might be duplicating values during evaluation.
Use TREATAS to control context explicitly: Instead of relying on automatic relationship filtering, use TREATAS to apply the correct filter context in your measure.
If you are still facing the issue, it is advisable to reach out to Microsoft Support for better assistance
You can submit a ticket through the Microsoft Power BI Support Portal:
https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket.
Thanks
Hi Anonymous
Power BI can accurately calculate total values for cross-table ratios, but only when relationships, filter directions, and context are modeled correctly. In scenarios with multiple fact tables or ambiguous filter paths, totals may appear incorrect not due to a system limitation, but due to the underlying data model. If the total still seems off, it's a signal to revisit the model structure. Common fixes include introducing a proper date or country-month dimension table, adjusting relationship directions, or using revised DAX with clearer filter context. With the right design, totals and row-level results will align consistently. It's better to reach out to Microsoft Support for Better Assistance.
If this post helps, kindly mark it as Accepted Solution.
Thank You.
Hi Anonymous
Welcome to the Microsoft Fabric Forum.
Thank You sergej_og for responding on this topic.
The issue occurs because the relationship between the two tables relies only on the 'Country' column. This works initially but fails when time-series data is introduced, as there are multiple rows per country for different months.
This makes the 'Country' field no longer unique in either table, creating a many-to-many relationship that Power BI struggles to handle due to ambiguity in the joins. The core problem is the use of a non-unique key, which becomes problematic as the data complexity increases.
To address this, it's recommended to create a composite key using both 'Date' and 'Country', ensuring each row remains unique and the relationship between tables is clearly defined.
Create a calculated column in both tables (e.g., CountryDateKey) that combines Date and Country:
CountryDateKey = [Date] & "-" & [Country]
Then establish the relationship using this new CountryDateKey column.
If this post helps , kindly mark it as Accepted Solution.
Thank You!
v-karpurapud that did work
So the next step would divide sessions by clicks
For march the table with sessions is 1,368,209 and the other table clicks is showing 1,444,106 which should show 0.95 but is instead showing 27.17.
Hi Anonymous
To get the correct sessions-to-clicks ratio, create a DAX measure (not a calculated column) that sums both values before dividing. This avoids row-level calculation errors.
Since your session data is in SessionsTable and click data in ClicksTable, and both are linked by CountryDateKey, use this DAX measure:
SessionToClickRatio = DIVIDE( SUM(SessionsTable[Sessions]), SUM(ClicksTable[Clicks]), 0 )
This ensures the division is based on total sessions and clicks in the current context (e.g., by month or country), and gives you the correct result like 0.95 for March.
If this post helps, kindly mark it as Accepted Solution.
Thank You!Unfortunley , I am still getting the same 27.17. I have a many to one relationship that has the data flowing in both directions. I've been messing around with it but seems creating the key didnt help
heres how to session table is set up
Hi Anonymous
While I may not have full visibility into the specific structure of your dataset, I have created a sample .pbix file to demonstrate one possible approach to implementing the desired logic. I have included relevant screenshot and attached the .pbix file for your reference.Please take a moment to review them and see if this solution aligns with your requirements.
If this doesn’t fully meet your needs, could you kindly share a sample of your data and more detailed context? That would help us provide a more accurate solution. If this post helps, kindly, mark it as Accepted Solution.
Thank You!