The answer is not so simple (there are many cases), but a simple example may shed some light on the need for a LinkTable.
Imagine you have a QlikView model that loads an Orders table and a Budget table. Both tables can be connected using multifield keys, like for example Period-Product-Region. Both tables will contain a Period field, a Region field, and a Product field. They cannot have the same name, so they will either be eliminated in one of the tables or one of those sets of fields will be translated e.g. Period & BudgetPeriod, etc.
The first solution presents a serious problem in that the table chosen to contain the dimensions will act as a filter to the other table. For example, if we choose to keep the dimensions in Orders, products for which no orders have been placed yet will show no budget.
The second solution will present a different problem. To view information from both tables, you have to make selections in two sets of different dimensions. And selections in one set of dimensions will propagate via the key field to the other set, turning it into a hassle to get decent output. And very unfriendly, un-QlikView like.
The same applies to two facts tables where each one has a data value. Which of both tables gets the connection to the calendar table?
The solution is to create a LinkTable that contains keys to both Facts tables, and all dimension fields used in these keys as well as all dimension fields used in the interface but nog in the keys (as long as they exist in both tables). In effect, you're turning your "snowflake" model inside out: dimensions move from the outside to the inside, and facts tables(s) move from the inside to the outside. And suddenly your QlikView model starts working as expected.
Hope this is clear. Otherwise, just ask.
Peter
