Qlik Sense: Datenmodellierung und Load Script

• Tag 1: Das assoziative Modell und Load Script Grundlagen
• 1. Das assoziative Modell: Wie Qlik Daten anders behandelt
  • Assoziativ vs. Query-basiert: In SQL/Power BI definiert der Analyst eine Abfrage (JOIN, WHERE) und sieht das Ergebnis. In Qlik lädt der Entwickler alle Daten ins Speicher-Modell, und der Analyst exploriert frei - jede Selektion filtert sofort alle verknüpften Tabellen.
  • Automatische Assoziation: Tabellen werden über gleichnamige Felder verknüpft. Feld "KundenNr" in Tabelle A und Tabelle B erzeugt automatisch eine Beziehung. Vorteil: kein Beziehungsmanager nötig. Risiko: unbeabsichtigte Assoziationen über Felder die zufällig gleich heißen.
  • Data Model Viewer: Tabellen, Felder, Beziehungen, Kardinalitäten visualisieren. Synthetic Keys erkennen (gelbe Syn-Tabellen). Circular References erkennen. Information Density prüfen.
  • Grundregeln: Jede Assoziation läuft über genau ein gemeinsames Feld. Keine zusammengesetzten Schlüssel in den Rohdaten (Lösung: Concatenate-Key im Load Script). Keine Mehrfachverbindungen zwischen zwei Tabellen (Lösung: Link Table oder Rename).
  • Praxis-Übung: 3 Tabellen laden (Kunden, Bestellungen, Produkte), Data Model Viewer analysieren. Einen Synthetic Key provozieren (Tabelle mit 2 gemeinsamen Feldern), identifizieren, durch Concatenate-Key auflösen.
• 2. Load Script Grundlagen: Daten laden und transformieren
  • Script-Editor: Aufbau (Sections, Tabs), Ausführungsreihenfolge, Kommentare, Debugging (Partial Reload, Logfile, TRACE-Anweisung).
  • LOAD-Anweisung: LOAD FROM (Datei: CSV, Excel, QVD), LOAD SQL SELECT (Datenbank: ODBC/OLEDB), LOAD FROM (REST API, Web). Felder auswählen, umbenennen (as), berechnen. WHERE-Klausel, WHILE-Klausel (Subfield-Zerlegung).
  • Datentypen und Formatierung: Num#, Date#, Timestamp#, Text - explizite Typkonvertierung. Datumsformate harmonisieren (DE: 31.12.2025 vs. US: 12/31/2025 vs. ISO: 2025-12-31). Zahlenformate (Dezimalkomma vs. -punkt).
  • Basis-Transformationen: Concatenate (Tabellen untereinander anfügen), Join (Inner, Left, Right, Outer), Keep (wie Join, aber Tabellen bleiben separat), If/Pick/Match, Mapping und ApplyMap (Lookup-Tabellen für performante Zuordnung).
  • Praxis-Übung: E-Commerce-Datensatz laden: CSV-Dateien per LOAD FROM, Datumsformat harmonisieren, Kundenname zusammensetzen, Umsatz berechnen, fehlerhafte Zeilen per WHERE filtern, Data Model Viewer prüfen.
• 3. Fortgeschrittene Load-Script-Techniken
  • Preceding Load: Zwei LOAD-Anweisungen übereinander - die obere transformiert das Ergebnis der unteren. Für mehrstufige Berechnungen ohne Zwischen-Tabellen (Brutto, Rabatt, Netto in einer Ladesequenz).
  • Resident Load: Daten aus einer bereits geladenen Tabelle erneut laden. Für Aggregationen, Filterungen, Transformationen auf bereits geladenen Daten.
  • ApplyMap und Mapping Load: Die performanteste Art, Lookup-Werte zuzuordnen. Deutlich schneller als Join bei großen Datenmengen. Mapping Load erzeugt eine temporäre Mapping-Tabelle, ApplyMap wendet sie an.
  • Variablen im Script: LET und SET (Unterschied: LET wertet Ausdrücke aus, SET speichert den Text). Für Pfade, Datumsfilter, dynamische Ladelogik.
  • Fehlerbehandlung: ErrorMode, ScriptError, ScriptErrorDetails, ScriptErrorCount - Fehler im Script abfangen statt den gesamten Reload abbrechen lassen.
  • Praxis-Übung: E-Commerce-Datensatz erweitern: Preceding Load für mehrstufige Berechnung, ApplyMap für Produktkategorie-Zuordnung (statt Join - Performance vergleichen), Variable für Dateipfad und Datumsgrenzen, Fehlerbehandlung (was passiert wenn eine CSV fehlt?).
• Tag 2: Star Schema, QVD-Architektur und Datenqualität
• 4. Star Schema in Qlik Sense: Das optimale Datenmodell
  • Warum Star Schema? Qliks assoziatives Modell funktioniert am besten mit einem Star Schema: eine oder wenige Fakttabellen umgeben von Dimensionstabellen. Snowflake und normalisierte Modelle erzeugen Synthetic Keys und Performance-Probleme.
  • Fakttabellen: Nur Fremdschlüssel und Kennzahlen. Keine beschreibenden Felder (die gehören in die Dimension).
  • Dimensionstabellen: Beschreibende Felder + Primärschlüssel. Kalender-Dimension (Master Calendar: generiertes Datumsfeld mit Jahr, Quartal, Monat, Woche, Wochentag). Geografie-Dimension.
  • Master Calendar: Autogenerierung im Load Script - MinDate/MaxDate ermitteln, Schleife über alle Tage, Felder ableiten. Template das in jeder App wiederverwendbar ist.
  • Link Table: Wenn zwei Fakttabellen über dieselben Dimensionen verknüpft sind, entsteht ein Circular Reference. Lösung: Link Table mit generiertem Concatenate-Key.
  • Praxis-Übung: E-Commerce-Datensatz in Star Schema umbauen: Fact_Orders, Dim_Customer, Dim_Product, Dim_Date (Master Calendar generieren). Zweite Fakttabelle (Retouren) per Link Table verknüpfen. Data Model Viewer: sauberes Star Schema, keine Synthetic Keys.
• 5. QVD-Architektur: Bronze / Silver / Gold
  • Was sind QVD-Dateien? Qliks eigenes Datenformat - optimiert für schnelles Laden (10-100x schneller als CSV/Excel). Eine QVD pro Tabelle, versionierbar, inkrementell ladbar.
  • 3-Schichten-Architektur: Bronze/Raw (Rohdaten 1:1 aus den Quellen als QVD - keine Transformation), Silver/Cleansed (bereinigt, harmonisiert, verknüpft - Datenqualität sichergestellt), Gold/Model (Star Schema für die Analyse-Apps - die App lädt nur aus Gold-QVDs).
  • Warum 3 Schichten? Quellsystem-Entlastung (Bronze läuft einmal pro Nacht, Silver und Gold laden aus QVDs), Wiederverwendbarkeit (Silver-QVDs für mehrere Apps), Debugging (Problem lokalisieren: Gold, Silver oder Bronze?).
  • Verzeichnisstruktur: lib://RawData/Quelle/Tabelle.qvd, lib://CleanData/Tabelle.qvd, lib://ModelData/App/Tabelle.qvd. Namenskonventionen.
  • Reload-Kette: Scheduler konfiguriert: erst Bronze-App, dann Silver-App, dann Gold-Apps. Abhängigkeiten sicherstellen.
  • Praxis-Übung: QVD-Architektur aufbauen: Bronze-Script (3 Tabellen aus CSV in QVDs: STORE ... INTO), Silver-Script (QVDs laden, bereinigen, als Silver-QVDs speichern), Gold-Script (Silver-QVDs laden, Star Schema bauen). Reload-Kette testen.
• 6. Datenqualität und Bereinigung im Load Script
  • Fehlende Werte: Null() vs. leerer String in Qlik (Qlik unterscheidet beides - führt zu unerwartetem Filterverhalten). NullAsValue, NullInterpret. Strategie: in der Silver-Schicht behandeln.
  • Duplikate: DISTINCT in LOAD, Deduplizierung über RowNo() + Preceding Load + WHERE, First-/Last-Record per Gruppe.
  • Datentyp-Probleme: Mixed-Fields (Feld enthält Zahlen und Text - Qliks größter Stolperstein). Dual()-Funktion verstehen. Num() und Text() zur expliziten Konvertierung.
  • Feldnamen-Harmonisierung: Rename Fields, Qualify/Unqualify (automatische Tabellennamen-Präfixe).
  • Praxis-Übung: Absichtlich fehlerhafte Daten laden ("schmutzige" CSV mit fehlenden Werten, Duplikaten, Mixed-Fields, inkonsistenten Feldnamen): Probleme identifizieren, im Silver-Script systematisch bereinigen.
• Tag 3: Incremental Load, Performance und Praxis-Workshop
• 7. Incremental Load: Nur neue und geänderte Daten laden
  • Das Problem: Full Reload lädt alle Daten bei jedem Durchlauf neu. Bei 10 Millionen Zeilen dauert das Stunden. Incremental Load lädt nur neue und geänderte Zeilen - Sekunden statt Stunden.
  • Insert-Only Pattern: Neue Zeilen haben eine höhere ID oder ein jüngeres Datum. Max(ID) aus dem bestehenden QVD lesen, nur Zeilen mit ID > Max laden, an das QVD anfügen.
  • Insert/Update Pattern: Zeilen können sich ändern. Bestehende QVD laden, neue/geänderte Zeilen laden, per Concatenate anfügen, Duplikate entfernen (neueste Version behalten).
  • Insert/Update/Delete Pattern: Zusätzlich per LEFT JOIN prüfen, welche Zeilen nicht mehr existieren. Komplexeste Variante, aber für vollständige Synchronisation nötig.
  • Praktische Überlegungen: Wasserzeichen-Feld, Fehlerbehandlung (Rollback auf letztes vollständiges QVD), periodischer Full Reload als Sicherheitsnetz.
  • Praxis-Übung: Incremental Load für die Bestellungstabelle: Insert-Only, dann erweitern auf Insert/Update. 100 neue Zeilen zur CSV hinzufügen, Incremental Reload ausführen, prüfen ob nur die neuen Zeilen geladen wurden.
• 8. Performance-Optimierung
  • Datenmodell optimieren: Überflüssige Felder entfernen (DROP FIELD), Feldtypen optimieren (Text zu Zahl wo möglich), Granularität reduzieren (braucht die App jede Transaktion oder reicht eine Tagesaggregation?).
  • Load Script optimieren: QVD Optimized Load (LOAD aus QVD ohne WHERE und ohne Transformationen ist 10-100x schneller). Wann der Optimized Load bricht und wie man ihn erhält.
  • RAM und Kompression: Qlik Sense hält das gesamte Datenmodell im RAM. Symbol Tables und Bit-Stuffed Pointers - warum Low-Cardinality-Felder viel weniger Speicher brauchen.
  • Section Access: Row-Level-Security im Datenmodell. Benutzer sieht nur die Daten, für die er berechtigt ist. Section Access im Load Script definieren, REDUCTION-Felder, OMIT-Felder.
  • Praxis-Übung: Performance-Vergleich: denselben Datensatz laden (1) mit allen Feldern, (2) mit DROP FIELD, (3) als Tagesaggregation. Reload-Zeit und RAM-Verbrauch vergleichen. Section Access implementieren: 3 Benutzer mit verschiedenen Regionen-Berechtigungen testen.
• 9. Best Practices und Praxis-Workshop
• Best Practices (20 Min):
  • Coding Standards: Tab-Struktur (1 Tab pro Schicht: Variablen, Bronze, Silver, Gold, Exit Script), Kommentare, Einrückung, Namenskonventionen (Felder: CamelCase, Variablen: v-Präfix, Mapping-Tabellen: map-Präfix).
  • Wiederverwendbare Bausteine: Master Calendar als Include-Datei, Incremental-Load-Template als Include, Logging-Template.
  • Dokumentation: Inline-Kommentare, Data Lineage, Datenwörterbuch.
• Praxis-Workshop (60 Min):
  • Phase 1 - Eigenes Datenmodell bauen (40 Min): Eigenes Szenario (oder vorgegebenes: HR-Daten mit Mitarbeitern, Abteilungen, Gehaltsverlauf, Abwesenheiten aus 3 Quellen). End-to-End: Bronze-Extraktion, Silver-Bereinigung, Gold-Modell (Star Schema, Master Calendar, Incremental Load), Section Access, Reload-Kette.
  • Phase 2 - Peer-Review (15 Min): Datenmodell im Data Model Viewer vorstellen. Stresstest: "Euer Modell hat einen Synthetic Key - wo kommt der her und wie löst ihr ihn?" "Der Reload dauert 45 Minuten - wo optimiert ihr zuerst?" "Ein neuer Datenquellentyp kommt hinzu (REST API) - wie integriert ihr ihn in eure QVD-Architektur?" "Der Abteilungsleiter sieht Gehaltsdaten seiner Mitarbeitenden, obwohl Section Access aktiv ist - was ist schiefgelaufen?" "Die Bronze-QVD ist 3 GB groß, aber das Modell braucht nur 5 Felder daraus - wie ändert ihr das?"

LernzieleJede teilnehmende Person verlässt das Seminar mit dem Verständnis des assoziativen Modells (wie Qlik Daten verknüpft, warum Star Schema optimal ist, wie Synthetic Keys und Circular References entstehen und aufgelöst werden), der Beherrschung des Load Scripts (LOAD, Preceding Load, Resident, ApplyMap, Variablen, Fehlerbehandlung), der Fähigkeit, eine QVD-Architektur aufzubauen (Bronze/Silver/Gold, Reload-Ketten, Verzeichnisstruktur), der Kompetenz für Incremental Load (Insert-Only, Insert/Update, Insert/Update/Delete), dem Know-how für Performance-Optimierung (Optimized Load, RAM-Reduktion, DROP FIELD) und Section Access (Row-Level-Security), 5 eigenen Datenmodellen als Referenz und einem wiederverwendbaren Template-Set (Master Calendar, Incremental Load, Logging).Zielgruppen

• Qlik-Sense-Entwickler nach dem Einstiegskurs: Die über Drag-and-Drop-Dashboards hinaus eigene Datenmodelle bauen, Load Scripts schreiben und QVD-Architekturen entwerfen.
• BI-Analysten mit Qlik-Verantwortung: Die Daten aus verschiedenen Quellen zusammenführen, bereinigen und für Analysten aufbereiten - nicht nur Diagramme konfigurieren.
• Umsteiger von Power BI, Tableau oder QlikView: Die das assoziative Modell und die Load-Script-Sprache von Qlik Sense systematisch lernen.
• Data Engineers und ETL-Entwickler: Die Qlik Sense als Datenverarbeitungsplattform einsetzen und die QVD-basierte Datenarchitektur verstehen.

Voraussetzungen: Qlik-Sense-Grundkenntnisse (Visualisierungen erstellen, Sheets gestalten, Filterselektionen nutzen). Idealerweise Besuch von "Qlik Sense Einführung" (S3524, 2T) oder vergleichbare Praxiserfahrung. SQL-Grundkenntnisse sind hilfreich für den Load-Script-Teil.