InvalidUnconstrainedJoin — sibling tables sharing same hub

Hi all,

Thank you @Azadsingh and @Kiran-7312 for confirming this is a modeling limitation rather than a relationship configuration issue.

After further discussion internally, we've settled on a solution: since end users don't functionally need KPIs or a proper star schema (fact/dimension). we will not build (or allow) any report/visual that pulls data simultaneously from the three tables that have a 1:m relationship with the Projet hub table.

In practice this means:

• Visuals can combine Projet with one of the "many" child tables (Commande FTTO, Gouv, or Task) at a time, which works fine since there's a single, unambiguous filter path.
• The 1:1 tables (Commande BTE, Modules SFP) can still be freely combined with each other and with the hub, as already confirmed.
• We're not attempting a model-level fix (bridge table, flattening, etc.) since it's not required by the actual reporting needs — we're just constraining what combinations are exposed to end users, either through separate pages/visuals per child table or by governing which fields can be used together.

This avoids the InvalidUnconstrainedJoin error and the cartesian product issue entirely, without requiring end users to add measures.

Thanks again for the insight — it helped confirm that this is fundamentally a data granularity/modeling issue, not something fixable purely through relationship settings.