Skip to main content
Announcements
Accelerate Your Success: Fuel your data and AI journey with the right services, delivered by our experts. Learn More
cancel
Showing results for 
Search instead for 
Did you mean: 
valpassos
Creator III
Creator III

Not another mixed granularity fact tables...

Hi community   I know this type of question sounds repetitive but I'm really newbie at Qlik and I just need a minimal guidance, because I've read so much techniques and best practices that I'm kind of lost now...

I have the following hierarchies in different files:

Table1:

Date

GrandFather

Father

Child

GrandChild

Fact1

...

Table2:

Date

Father

Child

Fact2

Fact3

...

Table3:

Date

GrandFather

RandomPerson1

Father

RandomPerson2,

RandomPerson3,

Fact4

...

I want to associate the three tables, so I created a composite key (AutoNumber) between Date, Father and Child to associate the first two tables, and it worked fine. In a fact table I have put all the different facts and this key that links the two tables, and dropped the fields from the respective tables. I also have a Master Calendar with the Date key field.

But now I'm tring to do the same thing between table1 and table3, but somehow the Date, GrandFather and Father composite key is not the same in the two tables, so it doesn't link them...

What are the options in terms of modeling this type of situationn? Generic Keys and Link Tables?

Please offer some advice, however trivial it may sound.


Lisa

12 Replies
valpassos
Creator III
Creator III
Author

Hi Vishnu,

Thanks for your input

I've looked into the reference site and I don't really think that Hierarchy is what I need, since my kind-of-hierarchy is already taken care of with a file master that links the fields (parent and child). What I was struggling with was with the facts that these hierararchy members contained.

Lisa

ogster1974
Partner - Master II
Partner - Master II

Hi Lisa

In your example where customer had a number of attiributes relating to it then you would still have your facts structured in a central table you would however create a seperate table for the customer specific attibutes and join the two together using a key. 

The reason for the split is why would you want to duplicate those values against your individual transactions as they wouldn't change. you would make the app larger and so longer to perform tasks.

Caveat: Unless your requirement meant it was important to track changes of location at a transaction level due to the fact the customers were transient and it was useful to track this

Glad I could help.

Regards

Andy

valpassos
Creator III
Creator III
Author

Hi Andy,

Maybe you can help me with this issue I'm facing right now. It's about granularity again (I think).

So, I have my fact table with everything concatenated into it. You can see a glimpse into my Customer and Warehouse values, and the facts they are producing.

InkedInkedDifferentGranularity_LI.jpg

You can see that Fact2 is only at the level of the Warehouse, and Fact1 is at the level of both the Customer and the Warehouse.

My Customer and Warehouse values come in fact from the same column in the source table, and in the qlik script I'm just doing a WHERE filter on their ID code to know what is a Customer and what is a Warehouse, and them I'm joining them into one table.

The thing is, I have a situation where I need to have the Fact2 in the same line, associated with the Customer, because I need to compare these two facts in a scatter plot where I'm using Customer as a dimension. So, I need to have that 10 score in fact2 in every line for the same Warehouse but different Customer, as I've drawn in the image.

Can you help me?

Thanks!,

Lisa