QV data model - challenge with facts on different grains

[#1]

Hello,

I am currently implementing a new QlikView document that will be used as a management dashboard, but will also contain detailed analyses to see what is going on. Now i am running into a problem with how to use linked tables in the most optimal way.

What i have understood so far when reading a lot of material on this community forum about linked tables is that they should be created at the finest grain possible (which makes sense), but how does one do this when certain facts are at a higher grain and have to be in the same document?

For example here is a small cleaned-up model of what i have now when everything is linked on the finest grain.

But now i want to add a fact called SalesBudget which will not be on a product/customer base but instead on groupings of them (productgroup & customersegment).

Now i can see 2 paths to follow to complete this:
1 - Add productgroup and customersegment as keys to the linked table. This will mean that the customer and product dimension won't have a link to those groupings unless there is a fact containing them. This could be fixed by concatenating the complete dimension mapping into the linked table.

2 - Adding dummy records into the customer & product dimensions which doesn't contain any extra information but directly links to the customersegment & producthierarchy dimensions. This will mean that one is adding non-existing data into the customer & product dimension which could lead to wrong analyses when business users are creating own charts. (ofc they get the overall qv data model and the explanation, but they aren't developers).

I assume the problem described above is quite a common problem, but i have found minimal information when looking for a combination of linked table and different granularities.

Now my questions are:
- Is there maybe another solution to solve the above case?
- What is the best-practise to follow in the above case?
- Does this best-practise depend on the amount of data in the dimensions/facts?
- Is there a noticable difference in performance between different solutions?

[#2]

After quite a few internal discussions and going through the different options we decided to solve the problem by moving the aggregated dimensions into the LinkTable while keeping them in their original dimensions as well. However we renamed the column in those dimension tables to Cust.SegmentName and Prod.GroupName.

This so we didn't have to create any dummy records in the customer/products dimensions and we didn't have to create entries in the LinkTable either that wasn't based on a fact.

It sounds a little like the best of both worlds.