Qlik Community

New to Qlik Sense

Discussion board where members can get started with Qlik Sense.

Not applicable

Concatenation of tables with different types of facts

Hello, after reading several conversation about this subject, i still have some questions, unfortunately.

Let us suppose the following scenario:

I want to build a data model for a company that offers services through a card. This card is activated associating it first to a person (table "cards").  Packages containing services are sold (associating them to the card) (table "Sales") and the user can use these services in different places (table "Usages").

Therefore, the information that we currently have is:


Option 1:

A unique table of facts where all the actions, which can be done using the card, are stored. These actions can be differentiated by means of a new field (Type Fact) on the table.


all the tables share common fields such as “Center, Cards… despite we have Dimension-Tables such as“Center” or “Card”  und they are with the Fact-Table associated.

But in this case I find a problem, maybe because of my inexperience or because it is not an optimal solution.

The problem is that I can not connect facts of different types. For example:

How many times the cards activated on April 2016 have been used?

Is it smart enough to create a field called Type in order to distinguish all the records that come from other tables? Or is it absurd, on the contrary?


Option 2:

Several Fact Tables:


8 Replies
MVP & Luminary
MVP & Luminary

Re: Concatenation of tables with different types of facts

If the amounts of your data aren't quite huge (of course related to the resources of your environment) I would probably go with option 2 but avoiding the synthetic key by renaming some of the fields, for example Center into [Center Sales] and [Center Usage] and doubling the dimension-tables to them if really necessary.

Option 1 is in general possible because asymetric fact-tables aren't a problem in Qlik but your fact-tables seems to have far more differences than similarities so that it doesn't look very sensible. Are your data huge and/or you experienced performance issues you need to reduce the number of tables and to merge as many data as possible in one big fact-table - but in this case with mapping/joining and conatenating the tables.

Quite common is also to create a link-table between the fact-tables which contained their common fields - but in my opinion it makes the things not really easier and link-table models have often a poor performance.

- Marcus

Not applicable

Re: Concatenation of tables with different types of facts

Hello Marcus, Thanks a lot for your answer.

About Option 1:

I have many records corresponding to usages of the card, that is, mainly the largest table is the Table “Usages”.

I cannot test the performance issues because I'm testing my model with a small part of the data in order to be able to verify what works and what does not and to see if it makes sense and the data is displayed correctly.

The three fact tables are different because they are not the same kind of fact. I thought of it as "Actions / Facts on the card", with fields in common:

  • What kind of action is carried out (FaktTyp)
  • Where the action is carried out (Center)
  • Exactly from which terminal the action ist carried out (Terminal)
  • When the action occurs (Date)
  • On which card (Card-id)

But it is also true that there are other fields that have nothing to do because they are specific to each kind/typ of facts

Option 2 and other alternative Options for Option 1:

we have model with 3 fact-tables

  • Example 1: (Link-table)


  • Example 2: (mapping)


we can also have model with 1 fact-table, with Join-table or Concat-Table


I have 3 fact-Tables that are different und sharing some dimensions but no others und the 3 fact-tables are related.

- Doppel Dimension-Tables sind optimal?

- Facktable with a lot of columns is optimal?

- with only 1 Facttable can i make relations between the files of the table?

- If I keep the 3 tables without grouping it is better to make a link table or put the data of the dimensions in the fact tables?

MVP & Luminary
MVP & Luminary

Re: Concatenation of tables with different types of facts

It's quite difficult to estimate which approach might be the most suitable in your case. I would tend in the direction of option 2 although it looked easier to connect the tables with some combined-keys (concat of several key-fields) or to create a link-table.

Each of the methods have their benefits and disadvantages and unfortunately there is no optimal datamodel: A perfect datamodel?

If I get unknown data with certain requirements which I couldn't really judge at the moment I would develop two or even three datamodels parallel - starting with a small dataset and loading the tables in the easiest way and then using some pivot-tables and tableboxes to check if the data look plausible and then trying to apply the most challenging view which is required - and this quite roughly without implementing a nice looking gui or integrating it in the environment-structures.

If I get the needed results I increase the amount of data to the real one and if it is performant enough I build a real application. If it don't work I need to adjust my doings and maybe switch to a different model.

It sounds a bit like trial & error and yes it is - but a systematically one. The more you understand the data and the requirements the more you could avoid the trials and just thinking some minutes/hours and to sketch the essential points on a white paper and afterwards is just some typing work (and tests of course).

- Marcus

Valued Contributor

Re: Concatenation of tables with different types of facts

Hi Sofia,

Just for the first example, if the card is activated the first time that is used, why you don't create a flag in the usages fact table? It would be easier that use another fact table. (if not, you can create a map table and create the flag).

I always use one single fact table, and normally is a concatenation of several ones and I never had been problems to obtain the data.


Not applicable

Re: Concatenation of tables with different types of facts

Hola Jose,

contesto en espanol.

La tarjeta se activa luego el usuario puede usarla o no.

En un centro se activa la tarjeta y se asigna a un usuario, despues desde ese mismo u otro centro se le asigna un paquete a la tarjeta (venta). El usuario puede usar en otros centros los servicios que contiene el paquete o paquetes asociados a su tarjeta.

En la opción 1 (única tabla de hechos) he metido todas las acciones posibles sobre la tarjeta diferenciandolas por un campo "Tipo de hecho". Se conserva el modelo de estrella y funciona correctamente salvo cuando quiero relacionar los distintos hechos.

Por ejemplo: Cuantas ventas se hicieron con las tarjetas activadas en un periodo en concreto?

En la opcion 2 (varias tablas de hechos con linktable) puedo relacionar los datos por numero de tarjeta pero necesito duplicar las tablas de dimensiones.

Luego tengo campos distintos y no se hacer un unico filtro. Por ejemplo:

Tabla Centro 1 --> Campo "numero de camas"

Tabla Centro 2 --> campo " numero de camas"

Quiero tener un único filtro "numero de camas" con los posibles valores (comunes a ambas tablas). De modo que si selecciono un valor del filtro se va a considerar en aquellos datos que usen tabla centro 1 y tabla centro 2.

Valued Contributor

Re: Concatenation of tables with different types of facts

Hola Sofía

Yo sinceramente tiraría por la opción 1. Ese problemilla seguro que lo puedes solucionar con Set Analysis. Échale un vistazo al documento que está en este hilo Set Analysis: syntaxes, examples‌ creo que lo que aparece a partir de la página 13 podría servirte.

Si no, para este ejemplo concreto que pones, lo podrías arreglar fácilmente con un mapeo, mapeando las fechas de alta en el resto de tipos de hechos.

Un Saludo

Not applicable

Re: Concatenation of tables with different types of facts


vielen vielen Dank für deine Mühe.

Ich versuche nicht nur ein Datenmodell zu erstellen, sondern auch Qlik Sense zu lernen.

Ich bin neu in Qlik Sense und manchmal ist es für mich schwierig zu unterscheiden, was einfach nicht möglich ist und was ich nicht weiß.

Vermutlich ist das Problem falsch angegangen worden.  Ich hoffe, dass es Ok ist, wenn ich noch mal frage.

Option 1 -  wenn man eine einzige Fakttabelle hat, und es in dieser Fakttabelle verschiedene Fakten gibt (Spalte "Fakten Typen") kann man trotzdem Daten verbinden? Ich meine, kann ich folgende Auswertung machen?

Wie viele Nutzungen (Fakten Typen = "Nutzung") sind mit den Karten in Zeitraum x aktiviert (Fakten Typen = "Aktivierung")?

Ich benötige nur die Summe der Nutzungen von den Karten, die in diesem bestimmten Zeitraum aktiviert sind.

Option 2 - Mehrere Faktentabellen mit Link-Table

Wenn man eine Dimensionstabelle für jede Fakttabelle dupliziert, kann man trotzdem einen einzigen Filter haben oder man muss ein Filter pro Tabelle haben?

z.B.: Tabellen Center1 und Center2 haben beide das Feld "Anzahl-Betten". Ich habe Anzahl-Betten1 und Anzahl-Betten2 als Filter für meine Auswertungen aber ich würde gerne nur einen Filter "Anzahl-Betten" haben. Ist das möglich?

MVP & Luminary
MVP & Luminary

Re: Concatenation of tables with different types of facts

Hallo Sofia,

beide Varianten sind möglich. Vergleichsweise häufig können auch mehrere verschiedene Varianten erfolgreich implementiert werden und die Frage jetzt, welche Variante am Besten zu den gegebenen Anforderungen passt, ist wirklich nicht einfach und kann auch nicht immer bereits im Vorfeld ermittelt werden.

In der Regel ist es eine Art "Bauchentscheidung" basierend auf (jahrelanger) Erfahrung und dem Umfang bzw. der Gründlichkeit der Vorarbeiten (Kenntnisse über die Daten - was, wie viele, woher, Daten-Qualität, ... - und der Anforderungen an die Reports - was soll für wen wie und wie häufig abgebildet werden) mit welchem Datenmodell man startet.

Tendenziell gehe ich in Richtung von Option 1, da diese Art Datenmodell meist vergleichsweise einfach zu erstellen ist und auch eine gute Skript- und GUI-Performance aufweist. Dabei kann man sowohl mit einer breiten oder auch einer langen Fakten-Tabelle arbeiten, wobei eine breite Fakten-Tabelle performance-technisch besser ist, aber auch aufwändiger in der Generierung ist, hier mal ein kurzes Beispiel:


load * inline [

ID, Date, Sales, Budget

1, 2017/01/01, 100, 110

... ];


load * inline [

ID, Date, Type, Value

1, 2017/01/01, Sales, 100

1, 2017/01/01, Budget, 110

... ];

Bei der breiten FaktenTabelle kann man dann in den Formeln direkt auf das jeweilige Feld zugreifen und bei der schmalen benötigt man eine Set Analysis, wie: sum({< Type = {'Sales'}>} Value) um die gewünschten Fakten auszugeben.

Re: Data Model Question - Fat or Thin Fact table?

Bei einem Linktable-Model müssen sämtliche, sich zwischen den Faktentabelle überschneidenen, Felder in die Linktable integriert werden. Ich persönlich nutze das wegen des Aufwandes und der Performance nur sehr selten und gehe dann noch eher in die Richtung mehrere Faktentabellen im Datenmodell zu behalten, sofern die Keys entsprechend zu einander passen oder dass sie auch als eine Art Dimensionstabelle an einer anderen Faktentabelle hängen.

Sofern bei Dir noch kein großer Produktionsdruck dahinter steckt (bis Zeitpunkt X - meistens gestern - muss das fertig sein), probiere doch einfach zwei/drei Varianten parallel aus - viel von dem oben genannten kann man nicht bzw. nicht ausschließlich theoretisch lernen, man braucht wirklich praktische Erfahrungen und vor allem aus den Varianten, die nicht funktionierten, lernt man besonders viel.

- Marcus