topic How to remove circular reference using joins in QlikView

How to remove circular reference using joins

Wed, 25 Nov 2020 16:16:04 GMT

Hi All

i have below scenario

Tbl1:

LOAD Car,

City

Tbl2:

LOAD Person,

City

Tbl3:

LOAD Person,

Car

i want to remove circular reference using joins , Please help me on this scenario

Thanks and Regards

RamKumar

Re: How to remove circular reference using joins

sunny_talwar — Sat, 05 Mar 2016 15:59:22 GMT

By joins? Just join explicitly join them I guess

Tbl1:

LOAD Car,

City

Join (Tbl1)

LOAD Person,

City

Join (Tbl1)

LOAD Person,

Car

Re: How to remove circular reference using joins

settu_periasamy — Sat, 05 Mar 2016 16:30:01 GMT

See here, looks same scenario..

Circular References

See comments section also..

Re: How to remove circular reference using joins

Digvijay_Singh — Sat, 05 Mar 2016 16:46:30 GMT

You need to break circular association amongst tables either by joining tables or renaming field names.

Normally it happens when we wrongly give same name to fields having different business meaning, for example, Customer Address and Agent Address named as Address in different tables. In your case one of the Person could be named as Person1 as it could be different than Person in real business situation.

Re: How to remove circular reference using joins

HirisH_V7 — Sat, 05 Mar 2016 18:17:38 GMT

Hi,

Check this,

Why You sometimes should Load a Master Table several times

Re: How to remove circular reference using joins

johnw — Sat, 05 Mar 2016 18:32:29 GMT

Definitely read Henric Cronström's blog post mentioned above. Definitely read Radoslaw Korga's comment on that blog. And definitely look at what Sunny T posted above as well.

The primary question to ask yourself is what ROLE each of these fields are playing on each of their tables, what relationship they have to each other. Henric talks about one way the roles of these fields may be different in different tables, and how that might suggest a particular way of splitting the tables apart.

Radoslaw proposes a different way of storing the relationships, a more generic way, a way I find generally more appealing, though the two approaches will lend themselves better and worse to different sorts of analysis, so neither is strictly best. You use what best supports the particular needs of your users. If you're unsure what best supports them, understand better what sort of analysis they want to do, and experiment with both approaches to understand the differences.

But what if you've looked at the roles and relationships between the fields, and they simply are all the same? Well, if the relationship is always the same, then Radoslaw's star schema doesn't need the relationship field, and the whole thing can collapse down into a single fact table. And that, essentially, is what Sunny T is showing - what to do if the relationships between these tables are consistent, and you have the ability to join them all together with no ill effects, duplicated rows, etc.