📚 Qlik Sense Kurs – Artikel 3 von 28

← Vorheriger Artikel: Load-Strategien – RESIDENT vs PRECEDING vs INLINE
→ Nächster Artikel: Mapping Tables vs JOINs – Performance-Optimierung

JOINs vs KEEPs – Wann was verwenden

Was kann man in 10 Minuten über JOINs vs KEEPs lernen?

Die Verknüpfung von Tabellen ist das Herzstück jedes Datenmodells. In Qlik gibt es dafür verschiedene Techniken, die weit über den klassischen SQL-JOIN hinausgehen. Dieser Guide zeigt Ihnen, welche Strategie für Ihr Ziel die beste ist.

1. Die richtige Verknüpfungsstrategie für Ihr Datenmodell wählen (JOIN, KEEP oder CONCATENATE).
2. Performance-Unterschiede verstehen: Warum ein `KEEP` bis zu 5x schneller sein kann als ein `JOIN`.
3. Das WHERE EXISTS()-Pattern als hocheffiziente Filteralternative implementieren.

Zeitinvestition: 10 Min Lesen + 1 Std Hands-on
Voraussetzung: Load-Strategien verstanden
Quick Win: In 5 Minuten einen performanten `KEEP` zur Filterung implementieren

Wie filtert man Tabellen schnell, ohne sie zu verschmelzen?

Das Problem: Sie haben eine große Faktentabelle (Orders) und eine kleinere Dimensionstabelle (Customers). Sie möchten nur die Bestellungen von aktiven Kunden in Ihr Datenmodell laden, aber beide Tabellen für flexible Analysen getrennt halten.

Die Lösung mit KEEP: Anstatt die Tabellen mit einem JOIN zu einer einzigen, großen Tabelle zu verschmelzen, verwenden wir KEEP, um die eine Tabelle durch die andere zu filtern.

Analogie: Stellen Sie sich vor, JOIN ist das Zusammenkopieren von zwei Excel-Tabellen in ein einziges, breites Arbeitsblatt. KEEP hingegen ist, als würden Sie eine Gästeliste (Customers) nehmen, um in einer anderen Liste (Orders) alle Personen zu streichen, die nicht auf der Gästeliste stehen. Am Ende haben Sie immer noch zwei separate Listen.

Zuerst laden wir die Dimensionstabelle und filtern sie vorab auf die für uns relevanten «aktiven» Kunden.

Customers:
LOAD
    CustomerID,
    CustomerName,
    Region,
    Status
FROM [lib://DataFiles/customers.csv]
(txt, utf8, embedded labels, delimiter is ';')
WHERE Status = 'Active';

Danach laden wir die Faktentabelle vollständig in den Speicher.

Orders:
LOAD
    OrderID,
    CustomerID,
    OrderDate,
    Amount
FROM [lib://DataFiles/orders.csv]
(txt, utf8, embedded labels, delimiter is ';');

Jetzt kommt der entscheidende Schritt: Wir weisen Qlik an, in der bereits geladenen Orders-Tabelle nur die Zeilen zu **behalten (KEEP)**, deren CustomerID auch in der Customers-Tabelle existiert. Die Tabellen selbst bleiben getrennt.

INNER KEEP (Customers)
LOAD * RESIDENT Orders;

Erklärung:

• Getrennte Tabellen: Das Ergebnis sind zwei schlanke Tabellen. Dies ist die Grundlage für das performante Star Schema in Qlik.
• INNER KEEP: Behält nur die Schnittmenge in der Ziel-Tabelle (hier Orders).
• Automatische Assoziation: Qlik erkennt das gemeinsame Feld CustomerID und verknüpft die beiden Tabellen im Datenmodell automatisch.

Checkpoint: Sehen Sie im Datenmodell-Viewer zwei separate Tabellen, die durch eine Linie bei CustomerID verbunden sind? Perfekt!

Wann welche Verknüpfungsstrategie?

Die richtige Wahl hängt von einer zentralen Frage ab: Was ist das Ziel Ihrer Operation?

Wann sollte man JOINs statt KEEPs für Denormalisierung verwenden?

Ein JOIN kombiniert Spalten aus zwei Tabellen in eine einzige neue Tabelle. Dieser Prozess wird Denormalisierung genannt, weil er die normalisierte Struktur eines Datenbankmodells aufhebt. Dies kann die Komplexität für den Endanwender reduzieren, geht aber oft auf Kosten der Performance und Flexibilität.

Im folgenden Beispiel werden die Kundeninformationen direkt an jede Zeile der Orders-Tabelle angehängt. Das Ergebnis ist eine einzige, breite Tabelle.

Orders:
LOAD
    OrderID, CustomerID, OrderDate, Amount
FROM [lib://DataFiles/orders.csv];

LEFT JOIN (Orders)
LOAD
    CustomerID, CustomerName, Region, Segment
FROM [lib://DataFiles/customers.csv];

Welche JOIN-Arten gibt es und wann verwendet man sie im Vergleich zu KEEPs?

Die verschiedenen JOIN-Typen lassen sich am besten mit Venn-Diagrammen visualisieren.

• INNER JOIN: Behält nur Zeilen, die in beiden Tabellen einen passenden Schlüssel haben (die Schnittmenge).
• LEFT JOIN: Behält alle Zeilen aus der linken (ersten) Tabelle und fügt die passenden Daten aus der rechten Tabelle hinzu. Wo keine Übereinstimmung gefunden wird, entstehen NULL-Werte.
• RIGHT JOIN: Behält alle Zeilen aus der rechten (zweiten) Tabelle. Das Gegenteil von LEFT JOIN.
• OUTER JOIN: Behält alle Zeilen aus beiden Tabellen und fügt sie zusammen.

Achtung, Performance-Killer: Ein JOIN kann zu einem kartesischen Produkt führen, wenn der Schlüssel in der anzuhängenden Tabelle nicht eindeutig ist. Beispiel: Wenn ein Kunde in der Kundentabelle zweimal vorkommt, wird jede Bestellung dieses Kunden verdoppelt. Dies führt zu falschen Kennzahlen und explodierendem Speicherbedarf.

Wann sollten JOINs und KEEPs im Star Schema verwendet werden?

Der Hauptzweck von KEEP ist die Beibehaltung eines sauberen und performanten Star Schemas. Ein Star Schema besteht aus einer zentralen Faktentabelle (z.B. Orders), die von mehreren Dimensionstabellen (Customers, Products, etc.) umgeben ist. Dieses Modell ist für die assoziative Engine von Qlik hochoptimiert.

KEEP filtert eine Tabelle basierend auf den Schlüsseln einer anderen, ohne sie zu verschmelzen.

Zuerst laden wir beide Tabellen in den Speicher.

Customers:
LOAD * FROM customers.csv;

Orders:
LOAD * FROM orders.csv;

INNER KEEP behält in der Orders-Tabelle nur die Zeilen, deren CustomerID auch in Customers existiert.

INNER KEEP (Customers)
LOAD * RESIDENT Orders;

RIGHT KEEP behält in der Customers-Tabelle nur die Zeilen, deren CustomerID auch in Orders existiert (also nur Kunden mit Bestellungen).

RIGHT KEEP (Orders)
LOAD * RESIDENT Customers;

LEFT KEEP würde in der `Orders`-Tabelle alle Zeilen behalten, deren `CustomerID` in `Customers` existiert, sowie alle Zeilen aus der Original-`Orders`-Tabelle. Da `Orders` hier die Zieltabelle ist, hat dieser Befehl oft wenig praktischen Nutzen.

Wann sollte man CONCATENATE für vertikales Verbinden von Tabellen verwenden?

CONCATENATE ist das vertikale Gegenstück zu `JOIN`. Anstatt Spalten nebeneinander zu stellen, hängt es Zeilen untereinander. Es ist Qlik’s Äquivalent zu `UNION ALL` in SQL.

Wenn Sie zwei Tabellen laden, die exakt die gleichen Spaltennamen und die gleiche Anzahl an Spalten haben, führt Qlik eine automatische Verkettung durch.

Sales_Q1:
LOAD 'Q1' as Quarter, * FROM [lib://DataFiles/sales_q1.csv];

Sales_Q2:
LOAD 'Q2' as Quarter, * FROM [lib://DataFiles/sales_q2.csv];

Im obigen Beispiel wird der Inhalt von Sales_Q2 automatisch an Sales_Q1 angehängt. Um dies explizit zu steuern oder wenn die Spalten nicht exakt übereinstimmen, verwenden Sie den Befehl CONCATENATE. Um die automatische Verkettung zu verhindern, verwenden Sie NoConcatenate.

NoConcatenate
HistoricalOrders:
LOAD * FROM historical_orders.csv;

Wann sollte man WHERE EXISTS() als Filteralternative verwenden?

WHERE EXISTS() ist eine extrem effiziente Alternative zu `INNER KEEP`. Der Hauptunterschied liegt in der Ausführung:

• INNER KEEP: Lädt erst beide Tabellen vollständig in den Speicher und führt dann die Filterung durch.
• WHERE EXISTS(): Filtert die zweite Tabelle Zeile für Zeile, während sie geladen wird. Es werden nur die Zeilen in den Speicher geladen, die den Filter passieren. Dies ist oft speicherschonender und schneller.

Die Reihenfolge ist entscheidend: Die Tabelle, die die gültigen Schlüssel enthält (die «Whitelist»), muss zuerst geladen werden.

Zuerst laden wir die «Whitelist» der aktiven Kunden.

Customers:
LOAD CustomerID, CustomerName, Region
FROM [lib://DataFiles/customers.csv]
WHERE Status = 'Active';

Danach laden wir die Orders-Tabelle. Die WHERE EXISTS(CustomerID)-Klausel sorgt dafür, dass nur Zeilen geladen werden, deren CustomerID bereits im gleichnamigen Feld in einer zuvor geladenen Tabelle existiert.

Orders:
LOAD
    OrderID, CustomerID, OrderDate, Amount
FROM [lib://DataFiles/orders.csv]
WHERE EXISTS(CustomerID);

Dieses Muster ist besonders stark bei der hierarchischen Filterung über mehrere Ebenen (Kategorie → Produkt → Verkauf).

Wie löse ich Probleme mit JOINs und KEEPs – Wann verwende ich was?

Was ist das kartesische Produkt bei JOINs?

Problem: Nach einem `JOIN` hat Ihre Tabelle plötzlich Millionen von Zeilen mehr als erwartet und die Kennzahlen sind viel zu hoch.

Ursache: Der Join-Schlüssel ist in der zweiten Tabelle nicht eindeutig. Dadurch wird jede Zeile der ersten Tabelle mit jeder passenden Zeile der zweiten Tabelle multipliziert.

Lösung: Stellen Sie sicher, dass der Schlüssel in der Dimensionstabelle eindeutig ist. Verwenden Sie Aggregationen (GROUP BY) oder eine QUALIFY-Anweisung, um Duplikate zu bereinigen, bevor Sie den JOIN durchführen.

Warum funktioniert KEEP nicht bei JOINs vs KEEPs?

Problem: Der `KEEP`-Befehl filtert keine Zeilen, obwohl er sollte.

Checkliste:

1. Gleiche Feldnamen? Das Schlüsselfeld muss in beiden Tabellen exakt gleich heißen (CustomerID vs. Customer_ID funktioniert nicht).
2. Gleiche Datentypen? Ein numerischer Schlüssel kann nicht mit einem Text-Schlüssel verglichen werden. Stellen Sie sicher, dass die Formate übereinstimmen.
3. Reihenfolge korrekt? Die Tabelle, auf die sich KEEP bezieht (z.B. Customers in `INNER KEEP (Customers)`), muss bereits vollständig geladen sein.

Was sind die nächsten Schritte im Kurs zu JOINs vs KEEPs?

Als nächstes: Mapping Tables vs JOINs – Performance-Optimierung

Verwandte Themen:

• Load-Strategien – RESIDENT vs PRECEDING vs INLINE
• Star Schema in Qlik – Performance & Klarheit
• Synthetic Keys & Circular References auflösen