Calculated table derived from a fact table
"Calculated table derived from a fact table" is one of the performance checks Auditabi runs on a Power BI semantic model. n calculated table(s) are built from a fact table with SUMMARIZE, DISTINCT or FILTER. It is a medium-severity finding: the model still works, but results are wrong in some filter contexts, slow, or fragile under change. Build the table upstream in Power Query or the warehouse, where it is computed once and compresses better.
What is detected
n calculated table(s) are built from a fact table with SUMMARIZE, DISTINCT or FILTER. The table is materialised at every refresh, doubles the memory of the columns it copies, and drifts from the source.
Why it matters
Wrong in some filter contexts, slow, or fragile under change. Fix in the next iteration.
How to fix it
Build the table upstream in Power Query or the warehouse, where it is computed once and compresses better.
Does your model fail this check?
Free static audit with the exact objects, no account, nothing stored.
More DAX checks
- Arithmetic or comparison on a measure that returns text
- Measure returning text in one branch and a number in another
- Share denominator clears a fact-table column instead of the dimension
- "Previous period" window overlaps the current one
- Percentage label built without ×100
- Percentages and amounts summed together