Mi trovi abbastanza d'accordo su questo, nel senso che non puoi andare più di tanto per "tentativi". C'è bisogno di avere delle basi teoriche legate sia al DAX che alla modellizzazione dei dati.
Per tornare al tuo problema, il riferimento circolare è dovuto proprio dal context transition e dal fatto che non esiste una chiave univoca. Nel senso che come dicevo prima i singoli valori di riga diventano dei filtri attivi nel contesto, quindi se hai più colonne calcolate che generano un context transition allora ognuna di queste dipenderà dal valore dell'altra.
Per intenderci:
I° Colonna Calcolata --> utilizza il Context Transition e dunque necessita di sapere quali sono i filtri generati da essa (i valori dei singoli campi per ciascuna riga)
II° Colonna Calcolata --> Utilizza anche lei il Context Transition e dunque non solo necessiterà dei valori di riga della tabella originale, ma anche di quelli della Colonna Calcolata I, che a sua volta dipenderà anche dal valore della colonna calcolata II.
Dunque si crea una dipendenza circolare.
L'utilizzo di FILTER modifiers come REMOVEFILTERS() o ALLEXCEPT() aiuta nel risolvere questa cosa.
Parlavo della chiave univoca perché se fosse presente all'interno della tabella, in realtà ogni riga è a se stante e dunque per il contesto filtro alla singola colonna calcolata non importerebbe nulla del valore assunto dagli altri campi all'interno della riga, perché per sapere a quale riga fa riferimento il contesto filtro basta sapere che valore assume, per la specifica riga, il campo univoco.
Comunque ti lascio il riferimento ad un articolo che spiega meglio di me cosa si intende per dipendenza circolare:
https://www.sqlbi.com/articles/avoiding ... rs-in-dax/
Andrea