Can I define a relationship without re-naming fields?

[datagrrl]

I have read a number of data modeling articles about Qlikview, and I am pretty sure I know the answer, but I can't seem to find a definitive yes/no. Basically I keep getting the reply "No, changing the field names can't be the only way to create a relationship." when I am explaining the tool to someone.

I am pretty sure I can not define relationships other than by giving my keys the same field names in each table. I would like to say this with 100% confidence, or actually give them the right answer if I am wrong.

Please point me in the direction of some documentation if I am wrong.

Thanks!

[cspencer3]

In my professional opinion, you cannot create a relationship without having the same field names. This is how QlikView automatically associates the tables based on field name. If you do not want to rename a field for a specific reason you could either create another field used as a key that would be renamed to the same name in both tables.

IE:

Load

KeyWithNameIWantToKeep,

KeyWithNameIWantToKeep as NewKey

;

Again, I don't believe there is another way to link tables. Does this help?

[datagrrl]

Yes, this is exactly how I do things now. I am getting pretty good at the associative data model, but everytime I try and bring a new person on board I get this question. I think I am just not saying this is the answer with the confidence I need.

I have googled this subject a lot, and I am pretty sure I am right. There is always the chance that I just don't know what to google and there is a different answer. I figured asking the question outright was a good way to go.

[JonnyPoole · Accepted solution]

A major part is that data models don't really exist as a separate entity.  They are the product of the script and not vice versa. Since the associations come only after the fact they need to be tagged during the load in some way for the engine to make the right associations at the end of the routine.  The mechanism of that tagging is by renaming the field or create a duplicate copy with an alias.   This often aligns with making sure that the fields match up with a business context (IE: Date <> Order Date <. FulfilmentDate) . 

Its a simple approach for an ETL workflow that lacks a visual flow editor where users can edit a flow diagram along the way.

Keep in mind you can RENAME fields along the way in the script, to accomplish something similar to an ETL flow diagram, but the last name is what is used to snap together the associative model.

All in all,  since its an ETL routine,  I find that Qlik's approach is a little unexpected to BI Report Developers who have experience with 'pass  through SQL query tools' where there is no ETL routine, just a flat model meant to show how SQL should get generated. 

I find is slightly more understandable to users who build OLAP which often involves multiple queries and then some link at one or more levels of the hierarchies. Cognos OLAP Transformer for example used 'like name aliases or fields' for this (same as QLIK).

Developers used to ETL understand the premise even though QlikView lacks a visual data flow diagram (just an end state model viewer). The flow diagram exists in QLIK but only in Expressor which can feed QlikView.

Speaking very generally here, i actually find BI skills transfer very well with a small tweak.