@akila789’s point about speed is a good one, but unless your dataset is quite large probably not the overriding reason why long and thin for fact table works best. The columnar aspect is the key. Think about most DAX measures, which follow a pattern similar to this:
Sales Not Red =
CALCULATE(
SUM( Sales[Amount] ),
Product[Category] <> "Furniture"
)
The measure totals down the Amount column in the fact table, filtered by an adjacent column linked via relationship to the Products dimension table. This is inherently a long and thin structure. You can add a million more rows to the data and measure doesn’t change, even if those rows include a bunch of new categories.
But imagine if the data instead were structured with separate columns for each product category’s sales. Now your measure has to explicitly sum each column that isn’t red, and the measure breaks if you add additional data with new categories.
Here’s a thread that has a real-world example of how much easier the DAX becomes when dealing with a long and thin structure, and embedded in that post is a second example of a different scenario showing the same result.
In terms of your particular structure, I can’t tell enough just from looking at the screenshots you provided – I really need to look at the data, the data model and the measures together. Thus, if you can please send aa PBIX file, I will be able to provide more specific guidance. If your data includes any sensitive information, here’s a video on simple techniques for masking confidential data to allow posting in the forum.
I hope this is helpful
- Brian