📚 Qlik Sense Kurs – Artikel 12 von 28

Was wirst Du über Link Tables für Many-to-Many-Beziehungen in Qlik lernen?

Nach diesem Guide kannst Du:

1. Many-to-Many-Beziehungen mit Link Tables korrekt modellieren
2. Synthetic Keys vermeiden durch Composite Keys
3. Performance-optimale Bridge Tables erstellen

Zeitinvestition: 20 Min Lesen + 3 Std Hands-on
Voraussetzung: Kenntnisse in Star Schema und Fact vs Dimension Design
Quick Win: In 15 Minuten verstehst Du wann und wie Du Link Tables einsetzt

Wie löse ich das Problem mit Synthetic Keys bei Many-to-Many in Qlik?

Was ist passiert?

Wenn zwei Tabellen mehr als ein gemeinsames Feld haben, weiß Qlik nicht welches Feld als Verknüpfung dienen soll. Also erstellt es automatisch einen künstlichen Schlüssel – den Synthetic Key.

// Beispiel-Szenario
Facts_Sales:                Dim_Customer:
- OrderID                   - CustomerID
- CustomerID  ────┐    ┌──> - CustomerID
- ProductID       │    │    - CustomerName
- Amount          │    │
                  │    │    Dim_Product:
                  └─ $Syn ─> - ProductID
                       └───> - ProductName

Wie erstelle ich meine erste Link Table Schritt für Schritt in Qlik?

Wie funktionieren Link Tables für Many-to-Many-Beziehungen in Qlik?

Ein Kunde kann mehrere Produkte präferieren, ein Produkt wird von mehreren Kunden präferiert. Klassisches Many-to-Many!

Wie bleiben die Dimensionen in Link Tables für Many-to-Many-Beziehungen in Qlik?

// Dimension: Kunden
Dim_Customer:
LOAD
    CustomerID,
    CustomerName,
    Region,
    Segment
FROM [DataCustomers.xlsx]
(ooxml, embedded labels);

Erklärung: Die Customer-Dimension bleibt unverändert – ein Record pro Kunde.

// Dimension: Produkte
Dim_Product:
LOAD
    ProductID,
    ProductName,
    Category,
    Brand
FROM [DataProducts.xlsx]
(ooxml, embedded labels);

Erklärung: Auch die Product-Dimension bleibt standard – ein Record pro Produkt.

Wie erstelle ich die Link Table in Qlik?

// Link Table: Customer-Product Preferences
Link_CustomerProduct:
LOAD
    CustomerID & '|' & ProductID as CompositeKey,  // Zusammengesetzter Schlüssel
    CustomerID,                                     // Einzeln für Referenz
    ProductID,                                      // Einzeln für Referenz
    PreferenceScore,                                // Attribut der BEZIEHUNG
    Date(FirstPurchaseDate) as FirstPurchaseDate,  // Zeitlicher Kontext
    TotalPurchases                                  // Historische Info
FROM [DataCustomerPreferences.xlsx]
(ooxml, embedded labels);

Erklärung der Elemente:

• CompositeKey: Verknüpft CustomerID und ProductID mit dem Trennzeichen ‚|‘. So wird «CUST001» + «PROD123» zu «CUST001|PROD123»
• CustomerID & ProductID einzeln: Ermöglichen die Verbindung zu den Dimensionen
• PreferenceScore, FirstPurchaseDate, TotalPurchases: Das sind Attribute der BEZIEHUNG zwischen Kunde und Produkt, nicht des Kunden oder Produkts selbst!

Wie verwendet die Fact Table einen Composite Key?

// Fact Table: Sales
Facts_Sales:
LOAD
    OrderID,
    CustomerID & '|' & ProductID as CompositeKey,  // Gleicher Schlüssel wie Link Table!
    Date(OrderDate) as OrderDate,
    Quantity,
    Amount
FROM [DataSales.xlsx]
(ooxml, embedded labels);

Erklärung: Die Fact-Tabelle erstellt denselben CompositeKey. So verbindet sie sich automatisch mit der Link Table.

Wann brauchst Du eine Link Table?

Nicht jede Beziehung braucht eine Link Table! Hier die Entscheidungshilfe:

Wie verwendet man Link Tables für Many-to-Many-Beziehungen in Qlik?

1. Echtem Many-to-Many

• Ein Kunde kauft mehrere Produkte UND ein Produkt wird von mehreren Kunden gekauft
• Ein Mitarbeiter arbeitet an mehreren Projekten UND ein Projekt hat mehrere Mitarbeiter
• Ein Student belegt mehrere Kurse UND ein Kurs hat mehrere Studenten

2. Beziehungs-spezifischen Attributen

• Die Beziehung selbst hat Eigenschaften (z.B. «Präferenz-Score», «Allocation-Prozent», «Rolle im Projekt»)
• Diese Attribute gehören weder zu Customer noch zu Product, sondern zur KOMBINATION

Warum gibt es keine Link Table bei Many-to-Many-Beziehungen in Qlik?

Einfachem 1:N (One-to-Many)

// Keine Link Table nötig!
Facts_Sales:
LOAD
    OrderID,
    CustomerID,    // Einfacher Foreign Key reicht
    Amount
FROM Sales;

Dim_Customer:
LOAD
    CustomerID,
    CustomerName
FROM Customers;

Erklärung: Eine Bestellung gehört zu genau einem Kunden → normaler Foreign Key reicht.

Wie funktioniert das Beispiel Employee-Territory Assignment in Qlik?

Ein realistischeres Szenario: Vertriebsmitarbeiter können mehrere Territories haben, jedes mit unterschiedlicher Allocation.

// Dimension: Mitarbeiter
Dim_Employee:
LOAD
    EmployeeID,
    EmployeeName,
    Department,
    Date(HireDate) as HireDate
FROM [DataEmployees.xlsx]
(ooxml, embedded labels);

// Dimension: Territories
Dim_Territory:
LOAD
    TerritoryID,
    TerritoryName,
    Region,
    Country
FROM [DataTerritories.xlsx]
(ooxml, embedded labels);

// Link Table: Employee-Territory Assignment mit Allocation
Link_EmployeeTerritory:
LOAD
    EmployeeID & '|' & TerritoryID as EmployeeTerritoryKey,
    EmployeeID,
    TerritoryID,
    Date(AssignmentStartDate) as AssignmentStartDate,
    Date(AssignmentEndDate) as AssignmentEndDate,
    AllocationPercentage,                              // z.B. 0.6 = 60% der Zeit
    If(Len(AssignmentEndDate) = 0, 1, 0) as IsCurrentAssignment
FROM [DataEmployeeTerritoryAssignments.xlsx]
(ooxml, embedded labels);

Erklärung der Besonderheiten:

• AssignmentStartDate / EndDate: Zeitliche Gültigkeit der Beziehung
• AllocationPercentage: Ein Mitarbeiter arbeitet zu 60% in Territory A, zu 40% in Territory B
• IsCurrentAssignment: Flag für aktuelle Assignments (EndDate ist leer)

// Fact Table: Sales mit Employee-Territory Key
Facts_Sales:
LOAD
    SaleID,
    EmployeeID & '|' & TerritoryID as EmployeeTerritoryKey,
    Date(SaleDate) as SaleDate,
    CustomerID,
    ProductID,
    Amount,
    Quantity
FROM [DataSales.xlsx]
(ooxml, embedded labels);

Wie kann ich AutoNumber zur Performance-Optimierung verwenden?

Composite Keys als Strings («CUST001|PROD123») verbrauchen mehr Speicher als nötig. Die Lösung: AutoNumber!

// Mit String Composite Key (Standard)
Link_CustomerProduct:
LOAD
    CustomerID & '|' & ProductID as CompositeKey,  // String
    CustomerID,
    ProductID,
    PreferenceScore
FROM Source;

// Memory: ~180 MB bei 100k Records

// Mit AutoNumber (optimiert)
Link_CustomerProduct:
LOAD
    AutoNumber(CustomerID & '|' & ProductID) as CompositeKey,  // Integer!
    CustomerID,
    ProductID,
    PreferenceScore
FROM Source;

Facts_Sales:
LOAD
    OrderID,
    AutoNumber(CustomerID & '|' & ProductID) as CompositeKey,  // Gleicher AutoNumber
    Amount
FROM Sales;

// Memory: ~125 MB bei 100k Records

Wichtig: Verwende AutoNumber für BEIDE Tabellen (Link Table UND Facts), damit die Zuordnung funktioniert.

Wie kann man typische Fehler bei Link Tables für Many-to-Many-Beziehungen in Qlik vermeiden?

Customer ← Link_CP → Product
   ↓                     ↓
   └──────> Sales ←──────┘

   = Loop!

Facts_Sales:
LOAD
    OrderID,
    CustomerID as Sales_CustomerID,  // Umbenennen!
    ProductID as Sales_ProductID,    // Umbenennen!
    CustomerID & '|' & ProductID as CompositeKey,  // Für Link Table
    Amount
FROM Sales;

CustomerID & ProductID as CompositeKey
// Problem: "12" + "34" = "1234" = "1" + "234"
// CustomerID=12, ProductID=34 hat gleichen Key wie CustomerID=1, ProductID=234!

CustomerID & '|' & ProductID as CompositeKey
// Eindeutig: "12|34" ≠ "1|234"

// Check für Duplicates
CheckDuplicates:
LOAD
    CompositeKey,
    Count(*) as DuplicateCount
RESIDENT Link_CustomerProduct
GROUP BY CompositeKey
HAVING Count(*) > 1;

// Wenn CustomerID + ProductID nicht eindeutig ist
CustomerID & '|' & ProductID & '|' & Text(Date) as CompositeKey

Link_CustomerProduct:
LOAD DISTINCT
    CustomerID & '|' & ProductID as CompositeKey,
    CustomerID,
    ProductID,
    FirstSortedValue(PreferenceScore, -Date) as PreferenceScore  // Neuester Wert
FROM Source
GROUP BY CustomerID, ProductID;

Wie funktioniert Revenue Allocation mit Gewichtung in Qlik?

Ein fortgeschrittenes Pattern: Umsätze auf mehrere Regions verteilen mit Allocation-Gewichtung.

// Fact Table: Sales
Facts_Sales:
LOAD
    OrderID,
    CustomerID,
    ProductID,
    Date(OrderDate) as OrderDate,
    Revenue
FROM [DataSales.xlsx]
(ooxml, embedded labels);

// Dimension: Customers
Dim_Customer:
LOAD
    CustomerID,
    CustomerName,
    PrimaryRegion
FROM [DataCustomers.xlsx]
(ooxml, embedded labels);

// Link Table: Customer-Region Allocation
// Ein Multi-Location-Customer kann mehrere Regions bedienen
Link_CustomerRegion:
LOAD
    CustomerID & '|' & RegionID as CustomerRegionKey,
    CustomerID,
    RegionID,
    AllocationWeight     // z.B. 0.6 = 60% des Umsatzes dieser Region
FROM [DataCustomerRegionAllocation.xlsx]
(ooxml, embedded labels);

// Dimension: Regions
Dim_Region:
LOAD
    RegionID,
    RegionName,
    Country
FROM [DataRegions.xlsx]
(ooxml, embedded labels);

Analyse-Expression für Revenue by Region:

// Im Chart:
Sum(Revenue * AllocationWeight)

Erklärung: Der Umsatz wird mit dem AllocationWeight multipliziert. So werden €100 Umsatz eines Kunden mit 60% Region A und 40% Region B als €60 für A und €40 für B gezählt.

Was sind die Best Practices für Link Tables in Many-to-Many-Beziehungen in Qlik?

✓ Naming Convention:

• [ ] Link Tables mit Prefix «Link_» benennen (z.B. Link_CustomerProduct)
• [ ] Composite Keys mit Suffix «Key» (z.B. CustomerProductKey, EmployeeTerritoryKey)

✓ Composite Key:

• [ ] Immer Delimiter verwenden (‚|‘ oder ‚-‚ oder ‚_‘)
• [ ] AutoNumber für Performance in Production
• [ ] String-Concat für Entwicklung/Debugging (besser lesbar)

✓ Link Table Content:

• [ ] Nur bei echtem Many-to-Many verwenden
• [ ] Beziehungs-Attribute in Link Table (nicht in Dimensionen)
• [ ] DISTINCT laden wenn Duplicates möglich

✓ Dokumentation:

• [ ] Kommentare im Skript: Was löst die Link Table auf?
• [ ] Welche Facts verwenden den Composite Key?

Was sind die nächsten Schritte für Link Tables in Many-to-Many-Beziehungen in Qlik?

Du kannst jetzt Many-to-Many-Beziehungen sauber modellieren! Als nächstes:

1. Zeitliche Dimension: Was wenn sich Beziehungen über die Zeit ändern? Ein Kunde war früher «Bronze», jetzt «Gold». Slowly Changing Dimensions zeigt Dir wie Du Historie modellierst.

2. Temporale Daten: Wie modellierst Du Gültigkeitszeiträume und Punkt-in-Zeit-Analysen? Temporale Daten & IntervalMatch erklärt’s.

3. Synthetic Keys auflösen: Noch mehr Details zum Vermeiden von Synthetic Keys und Circular References: Synthetic Keys & Circular References.

Slug: qlik-link-tables
Keywords: Qlik Link Tables, Many-to-Many Qlik, Bridge Tables Qlik, Composite Keys Qlik, Synthetic Keys vermeiden, Qlik Datenmodellierung, Link Table Performance, AutoNumber Qlik, Junction Tables Qlik, Qlik Beziehungen