This largely depends on the kind of analysis you need to perform with those two tables.
Basically, there are three ways:
1. Link Table - you build a table connecting those two, with all the common keys concatenated. This table will look a lot like your currebt Synthetic key table, only you generate the concatenated key explicitly.
2. Concatenate the two tables into a single "Fact table"
Those two methods are described in the standard "Developer II" training class, and also mentioned several times within this forum.
3. There is a relatively recent thinking that these kinds of synthetic keys are harmless, and are not so bad to live with. Personally, I'm of the opinion that we are still better off building our data models explicitly and not leaving the job of generating keys to QlikView, but the option of not worrying about it exists.
This largely depends on the kind of analysis you need to perform with those two tables.
Basically, there are three ways:
1. Link Table - you build a table connecting those two, with all the common keys concatenated. This table will look a lot like your currebt Synthetic key table, only you generate the concatenated key explicitly.
2. Concatenate the two tables into a single "Fact table"
Those two methods are described in the standard "Developer II" training class, and also mentioned several times within this forum.
3. There is a relatively recent thinking that these kinds of synthetic keys are harmless, and are not so bad to live with. Personally, I'm of the opinion that we are still better off building our data models explicitly and not leaving the job of generating keys to QlikView, but the option of not worrying about it exists.
Thank you both for the responses , i guess i can live with the synthetic keys as i dont see any performance issues and data issues as of now with my data model..
