Forum Discussion
Context Filter is not working as expected
You need to transform your single-table model in a proper star schema.
Add a dimension for sets of related attributes you want to slice and filter for, and leave the fact table with numbers to aggregate.
Autoexist is applied to columns in the same table, not to columns of different tables. This is why a star schema would work just fine.
At the end, data modeling is quite easy: Star schema all the things.
Have fun with DAX!
Alberto Ferrari
http://www.sqlbi.com
You are touching two separate topics:
- Star schema is old
- Autoexist should be changed
While I agree with the latter, and I hope Microsoft is actively working on a solution, I totally disagree with the former. Currently, there are no viable workarounds in DAX for Autoexist, this is why I guess Microsoft will work on changing the behavior.
On the other topic, I read multiple sources claiming that the "modern" way of managing data should not rely on the "old" star schema methodology. All the sources I read so far fail in providing a new paradigm that is ir could be better than a star schema.
Star schema versus the rest of the models mostly turns into a religious war. I am not into it. If there were a better paradigm, I would happily study that. However, so far I only read criticism without good alternatives. Therefore, I stick with the star schema.
Hi Alberto,
thanks for the quick reply. When it comes to the star schema I agree with you that it is convoluted and there are probably multiple ways to address the symptom: For me, the symptom is that I have source data with around 300 rows edit: colums by which my "users" potentially want to filter in their own dashboards and I am for sure not going to create a dimension table for each of these.
Now you may say how is this a represenatative scenario? And I would say, that is actually very common when teams are continously working with new data, sources change, new questions get asked etc. and you don't have the time and ressourced to always click through new relationships in PBI.
Could this be solved with a more programmatic / generative approach to data modeling in PBI? Absolutely yes! But it could also be solved with allowing, even enouraging the users to break with the star schema in scenarios, where performance and memory requirements are secondary to workflow and speed considerations. And what the above source implies is, that with todays database engines and functional programming languages, many of the memory and computation drawbacks could potentially be optimized to make this workflow perfectly fine for a number of everyday tasks.
So maybe let me be more nuanced: of course noone should get rid of the star schema per se. We should just be encouraged to build fatter tables for purposes of work-flow management and development speed and the engines should be optimized for this reality as well.
Cheers, aabtra