1
votes

This is a continuation of a thread I started in a past here

After some time I'm coming back with kind of similar question, but this time would like to get the full understanding on the problem to get it solved finally.

Let's say I use the following Power BI data model:

enter image description here

Based on the model, I have build the following report:

enter image description here

As you can see, on the visual I combine attributes from ProductCategory and Product tables. I'm also adding a measure, here named [Some Measure], that is defined like:

IF (
    ItemStockHistory[# ItemStockCurrent] <= 0;
    "No Stock";
        DIVIDE (
            ItemStockHistory[# ItemStockCurrent];
            [Σ SalesUnitQuantity_Last30Days]
    )
)

The goal of such measure construction is to show explicit value for ALL products belonging to the specific category, to the analyst, in case measure evaluates to BLANK.

Unfortunately, I discovered that overwriting "natural" blanks in the measure might have a side effects on the data displayed in the table visual: filtering using slicer is not working properly - when I select specific product category like "Office", I get the cartesian product of this category and all SKUs (also these outside of filtered category)

For me this is quite suprising behaviour of tabular modelling. Why overwriting measure BLANK result with explicit value affects filtering?

Most of the operational reports, that are based on the ProductSku level, share the similar visual setup and I really would like to have support for formatting blanks measure with some technical values that would still allow established relationships to work properly, without the strange effects, like the cartesian products or ingoring filters coming from the other visuals, like slicers

Or maybe I do not understand tabular modelling prime paradigms and want to get what is prohibited by default in this technology?

EDIT1

Missing ItemStockHistory table was added to the data model diagram

2
what is "ItemStockHistory"? It's not in the data model you describedRADO
@RADO I have updated the diagram.kamilzet_

2 Answers

2
votes

Replacing blanks with specific values can definitely lead to this sort of thing. A result can be blank because there are no corresponding data rows in your fact table or it can be blank because that combination isn't even possible in the dimension tables and you can't tell just from looking at a blank which of these which, so replacing a blank will apply to both or neither of these cases.

We'd like to ignore the impossible combinations. As @sergiom correctly points out, they occur as a result of auto-exist not kicking in because category and SKU don't exist in the same table. Because they are in different tables, the internal logic uses the more brute-force approach of cross-joining and filtering down. However, you've interfered with the filtering down part by replacing blanks with something else.

The way to get around this if you can't create a cleaner model is to check for an empty cross-join before evaluating the measure.

For example, instead of

IF ( ISBLANK ( [Measure] ); "No Stock"; [Measure] )

You might write something with an extra check:

IF (
    ISEMPTY ( Product ),
    BLANK (),
    IF ( ISBLANK ( [Measure] ); "No Stock"; [Measure] )
)

This way, you only evaluate the measure for cases that actually make sense.

1
votes

I'm afraid that the problem is that you have a snowflake schema. Therefore the SUMMARIZECOLUMNS in the client generated query that calls the measure doesn't trigger the auto-exist, and the result is the equivalent of CROSSJOIN on the fields of the Product and ProductCategory tables, followed by a filter on the result of the measure being blank. This explains why you are seeing the cartesian product of the two fields.

The best solution to avoid this kind of problems is to merge the ProductCategory table into the Product table to have a Star Schema instead of a Snowflake. This way your query will trigger the auto-exists and only existing combinations of the columns will be used.

If it's not possible to change the snowflake schema to a star schema, then the measure should be modified to return blank when the combination of fields generated by SUMMARIZECOLUMS (behaving like CROSSJOIN) do not exist. I think that ISEMPTY might be used to perform this test.