Qlik sense synthetic key

[firoz24]

Hi Guys,

I am new to qlik sense and I am trying to solve the synthetic key here. I received three synthetic key in this data 

what I am trying to achieve is joining the data from various excel sheet and creating some common fields in all table because when I filter a model , points , date I need to lookup the trend of OK VES, UCF and MSRD.

I have attached the qvf format of the application please check and solve the script .

[Nicolae_Alecu]

Hello,

This might help : https://community.qlik.com/t5/QlikView-App-Dev/What-is-Synthetic-key-And-how-to-avoid-it/td-p/93585 

Best Regards,

[RafaelBarrios]

Hello @firoz24 

you should try JOIN on tables, Qlik will join tables by using same field names

https://help.qlik.com/en-US/sense/August2023/Subsystems/Hub/Content/Sense_Hub/Scripting/combine-tabl...

try here

in the load on table line 94

join(OK_VES)
load .......
RESIDENT UCF_BDR1;

DROP TABLE UCF_BDR1;

if you wish to keep in separated tables, you will need to rename or not load the 4 common field in one of the table and create a key field in the two tables

table1:
LOAD
   autonumber(type&Points&MODEL&Concern) as key,
   ....,
   ....

table2:
LOAD
   autonumber(type&Points&MODEL&Concern) as key,
   ....,
   ....

Hope this helps.

Best,

help users find answers! Don't forget to mark a solution that worked for you & to smash the like button! 

[firoz24]

@RafaelBarrios  

I am new to qlik sense, I just want to know if I add autonumber as key in all four tables still I cannot do filter with the tables like I have a common field called model, Date, Type, points ,Concern in all tables.

Let me explain the process as user request

   * First, I will click a model 

   * Second, The concern List should display according to the filter

   * Third, I will filter the points to see the trend according to it.

[marcus_sommer]

Within the most scenarios you could not link multiple fact-tables because of missing key-values on both sides and probably even more important not having common dimension-tables between them else each fact would need it's own which is technically possible but rather a nightmare to the UI usability.

Therefore I suggest to follow the official recommendation for a data-model which is a star-scheme which means all facts are (per join/mapping and/or concatenate) merged within a single fact-table by harmonizing all field-names and data-structures as much as possible.