Synthetic Keys & Circular References auflösen

Was kann man in 18 Minuten über Synthetic Keys & Circular References lernen?

Nach diesem Guide können Sie:

1. Synthetic Keys erkennen und in 5 Minuten durch bewusste Feldumbenennung auflösen
2. Circular References diagnostizieren und durch gezielte Architektur-Änderungen eliminieren
3. Präventive Naming Conventions implementieren die 90% aller Modellierungsprobleme verhindern

Zeitinvestition: 18 Min Lesen + 2 Std Hands-on
Voraussetzung: Grundkenntnisse in Table Relationships und einfache Datenmodelle
Quick Win: In 3 Minuten Synthetic Keys identifizieren und verstehen warum sie problematisch sind

Wie kann ich Synthetic Keys schnell identifizieren?

Das Problem: Ihr Datenmodell zeigt mysteriöse $Syn-Tabellen und Performance wird unerklärlich langsam.

Lösung in 3 Schritten:

1. Öffnen Sie das Datenmodell-Viewer (Datenmodell-Symbol in der App)
2. Suchen Sie nach Tabellen mit Namen «$Syn1», «$Syn2» etc.
3. Prüfen Sie welche Felder diese Synthetic Keys verursachen

// Typische Situation die Synthetic Keys erzeugt
Customers:
LOAD
    CustomerID,
    CustomerName,
    Region,
    CountryCode
FROM [lib://Data/customers.csv];

Orders:
LOAD
    OrderID,
    CustomerID,
    OrderDate,
    Region,        // Problem: Gemeinsame Felder CustomerID UND Region
    CountryCode    // Problem: Drei gemeinsame Felder = Synthetic Key
FROM [lib://Data/orders.csv];

Erklärung:

• Synthetic Key Ursache: Mehr als ein Feld mit gleichem Namen zwischen Tabellen → Qlik erstellt automatisch $Syn-Tabelle
• Performance Impact: Jede Expression muss über Synthetic Table gehen → 2-5x langsamere Berechnungen
• Model Complexity: Statt 2 Tabellen entstehen 3-4 Tabellen → schwer verständlich

Performance: 1M Rows ohne Synthetic: Expressions 2-3s → Mit Synthetic: 8-15s

Checkpoint: Sehen Sie $Syn-Tabellen im Datenmodell? → Problem identifiziert! Keine $Syn-Tabellen? → Alles optimal oder mehrere Circular References. Siehe Troubleshooting.

Für systematische Lösung siehe Synthetic Keys auflösen.

Welche Lösung für Ihr Problem?

Identifizieren Sie zuerst das Problem-Pattern, dann wählen Sie die passende Lösungsstrategie:

Wie löse ich Synthetic Keys & Circular References in Qlik Sense?

Haben Sie $Syn-Tabellen im Datenmodell?

• JA → Problem: Synthetic Keys → Methode 1: Synthetic Keys auflösen
• NEIN → Können Sie von jeder Tabelle zu jeder anderen über mehrere Pfade navigieren?
  • JA → Problem: Circular References → Methode 2: Circular References auflösen
  • NEIN → Modell ist korrekt → Methode 3: Prävention implementieren

Legende:

• Zeitaufwand: Durchschnittlicher Aufwand für typische Business-Datenmodelle (10-20 Tabellen)
• Complexity: Technische Schwierigkeit und erforderliche Architektur-Kenntnisse
• Häufigkeit: Anteil an realen Qlik-Projekten mit diesem Problem-Pattern

Wie kann man Synthetic Keys in Qlik Sense auflösen?

Das Problem

Zwei oder mehr Tabellen teilen sich mehrere Felder mit identischen Namen. Qlik interpretiert dies als Multi-Field-Key und erstellt automatisch Synthetic Keys ($Syn1, $Syn2). Das führt zu Performance-Problemen und unverständlichen Datenmodellen.

Die Lösung

Bewusste Feldumbenennung: Nur echte Verknüpfungsfelder (Keys) behalten identische Namen, alle anderen Felder werden umbenannt um ihre semantische Rolle zu verdeutlichen.

// Problematischer Code (erzeugt Synthetic Keys)
Customers:
LOAD
    CustomerID,
    CustomerName,
    Region,        // Problem: Region in beiden Tabellen
    CountryCode,   // Problem: CountryCode in beiden Tabellen
    CreatedDate    // Problem: CreatedDate in beiden Tabellen
FROM [lib://Data/customers.csv];

Orders:
LOAD
    OrderID,
    CustomerID,    // OK: Verknüpfungsfeld
    OrderDate,
    Region,        // Problem: Erzeugt Synthetic Key
    CountryCode,   // Problem: Erzeugt Synthetic Key
    CreatedDate    // Problem: Erzeugt Synthetic Key
FROM [lib://Data/orders.csv];

// Korrekte Lösung (vermeidet Synthetic Keys)
Customers:
LOAD
    CustomerID,                    // Key: Identisch lassen
    CustomerName,
    Region as CustomerRegion,      // Umbenannt: Semantik verdeutlicht
    CountryCode as CustomerCountry,
    CreatedDate as CustomerCreatedDate
FROM [lib://Data/customers.csv];

Orders:
LOAD
    OrderID,
    CustomerID,                    // Key: Identisch lassen für Association
    OrderDate,
    Region as OrderRegion,         // Umbenannt: Andere semantische Bedeutung
    CountryCode as ShipToCountry,  // Umbenannt: Präzisere Beschreibung
    CreatedDate as OrderCreatedDate
FROM [lib://Data/orders.csv];

Erklärung der Strategie:

• Key-Felder unverändert: CustomerID bleibt CustomerID für automatische Association
• Semantische Umbenennung: Region in Orders kann Lieferregion sein, in Customers Kundenregion
• Präfix-Strategy: Tabellenname als Präfix (Customer*, Order*) für sofortige Zuordnung

Performance-Kontext:

• 2M Orders + 50k Customers mit Synthetic: Chart-Berechnung 12-18s
• Gleiche Daten ohne Synthetic: Chart-Berechnung 3-5s
• Memory-Reduktion: 25-40% weniger RAM durch eliminierte $Syn-Tabellen

Best Practices

• Key-Feld-Identifikation: Dokumentieren Sie bewusst welche Felder Verknüpfungsfelder sind (1:1, 1:N, M:N). Nur diese behalten identische Namen. Business-Rule: Ein Feld ist Key wenn es für JOINs oder Lookup-Zwecke verwendet wird.
• Semantische Präfixe: Nutzen Sie Tabellennamen als Präfix (Customer*, Order*, Product*). Alternative: Funktionale Präfixe (Billing*, Shipping*, Reporting*). Konsistenz wichtiger als spezifische Convention.
• Documentation in Skript: Kommentieren Sie Umbenennungen: // CustomerRegion: Kunde's Heimatregion vs OrderRegion: Lieferregion. Für Nachfolge-Entwickler essentiell zur Verständlichkeit.
• Validation nach Änderung: Prüfen Sie Datenmodell: Keine $Syn-Tabellen mehr? Row-Counts vor/nach identisch? Test-Charts funktionieren wie erwartet? Systematische Validierung verhindert unentdeckte Seiteneffekte.

✓ Checkpoint: Warum sollten nur Key-Felder identische Namen haben, aber nicht alle anderen?

→ Nächster Schritt: Bei sehr komplexen Modellen mit vielen Tabellen reicht Feldumbenennung nicht. Circular References auflösen zeigt Architektur-basierte Lösungen.

Wie löse ich Circular References in Qlik Sense?

Das Problem

Multiple Pfade zwischen Tabellen entstehen durch komplexe Business-Beziehungen. Beispiel: Customer → Orders → Product und Customer → Territory → Product. Qlik kann nicht entscheiden welcher Pfad für Berechnungen verwendet werden soll, was zu falschen Aggregationen führt.

Die Lösung

Architekturelle Ent-kopplung durch bewusste Pfad-Unterbrechung: Entweder Denormalisierung oder Link-Tabellen verwenden, um eindeutige Beziehungen zu schaffen.

// Problematische Struktur (Circular Reference)
Customers:
LOAD CustomerID, CustomerName, TerritoryID FROM customers.csv;

Territory:
LOAD TerritoryID, TerritoryName, RegionID FROM territory.csv;

Orders:
LOAD OrderID, CustomerID, ProductID, TerritoryID FROM orders.csv;  // Circular: Customer→Territory UND Orders→Territory

Products:
LOAD ProductID, ProductName, RegionID FROM products.csv;  // Circular: Territory→Region UND Products→Region

// Lösung 1: Denormalisierung (einfachste Lösung)
Customers:
LOAD
    CustomerID,
    CustomerName,
    TerritoryID as CustomerTerritoryID,  // Umbenennung unterbricht Pfad
    ApplyMap('TerritoryMap', TerritoryID, 'Unknown') as CustomerTerritory
FROM customers.csv;

// Territory Map erstellen
TerritoryMap:
MAPPING LOAD TerritoryID, TerritoryName FROM territory.csv;

Orders:
LOAD OrderID, CustomerID, ProductID, TerritoryID as OrderTerritoryID FROM orders.csv;

Products:
LOAD ProductID, ProductName, RegionID as ProductRegionID FROM products.csv;

// Lösung 2: Link-Tabelle für komplexe M:N-Beziehungen
Customer_Territory_Link:
LOAD
    CustomerID & '|' & TerritoryID as Customer_Territory_Key,
    CustomerID,
    TerritoryID,
    ValidFrom,
    ValidTo
FROM customer_territory_assignments.csv;

Erklärung der Strategie:

• Denormalisierung: Redundante Datenaufnahme verhindert komplexe Joins. Performance-Vorteil durch weniger Tabellen.
• Pfad-Unterbrechung: Bewusste Feldumbenennung zerstört automatische Associations wo nicht gewünscht.
• Link-Tabellen: Für echte M:N-Beziehungen mit zusätzlichen Attributen (Zeit-Gültigkeit, Gewichtung).

Performance-Kontext:

• 5 Tabellen mit Circular Reference: Expressions 15-25s, unpredictable Ergebnisse
• 3 Tabellen nach Denormalisierung: Expressions 4-8s, eindeutige Berechnungen
• Trade-off: Mehr Datenredundanz vs. bessere Performance und Verständlichkeit

Best Practices

• Architecture Decision Documentation: Dokumentieren Sie bewusst warum welcher Pfad unterbrochen wurde. Business-Regel: Welche Beziehung ist primär, welche sekundär? Für Nachfolge-Entwickler und zukünftige Erweiterungen essentiell.
• Star Schema als Ziel-Architektur: Denormalisierung führt natürlich zu Star Schema (1 Fact, mehrere Dimensions). Planen Sie bewusst in diese Richtung statt Ad-hoc-Fixes. Langfristig wartbarer und performance-optimaler.
• Staged Refactoring: Lösen Sie Circular References schrittweise, nicht alles auf einmal. Testen Sie nach jedem Schritt dass Berechnungen noch korrekt sind. Rollback-Strategie für jeden Refactoring-Schritt.
• Business Rule Validation: Nach Architektur-Änderung: Validieren Sie mit Business Users dass Aggregationen noch der Erwartung entsprechen. Circular References führen oft zu subtil falschen Zahlen die erst spät entdeckt werden.

✓ Checkpoint: Wann sollten Sie Denormalisierung vs. Link-Tabellen wählen?

→ Nächster Schritt: Statt reaktive Problem-Lösung ist Prävention besser. Naming Conventions implementieren verhindert 90% aller Modellierungsprobleme.

Wie helfen präventive Naming Conventions bei Synthetic Keys & Circular References in Qlik Sense?

Das Problem

Reactive Problem-Lösung ist zeitaufwändig und fehleranfällig. Teams entwickeln unterschiedliche Modellierungs-Ansätze, was zu inkonsistenten und schwer wartbaren Datenmodellen führt.

Die Lösung

Proaktive Naming Conventions und Modellierungs-Standards die automatisch korrekte Assoziationen erzeugen und problematische Patterns verhindern.

// Naming Convention Template
// Format: [TableName]_[FieldType]_[BusinessEntity]

// 1. Key-Felder: Immer mit "ID" suffix, Tabellenbezug im Namen
Customers:
LOAD
    CustomerID,           // Standard Key Format
    CustomerName,         // Business Attribute
    CustomerRegion,       // Prefix = Tabellenzugehörigkeit
    CustomerCreatedDate   // Prefix + beschreibender Name
FROM customers.csv;

Orders:
LOAD
    OrderID,              // Eigener Key
    CustomerID,           // Foreign Key - identisch für Association
    OrderDate,            // Prefix für Eindeutigkeit
    OrderRegion,          // Anders als CustomerRegion - keine Synthetic Key
    OrderAmount
FROM orders.csv;

// 2. Fact vs Dimension Pattern
Fact_Sales:               // Fact Tables mit "Fact_" Prefix
LOAD
    SalesID,
    CustomerID,           // FK zu Dimension
    ProductID,            // FK zu Dimension
    SalesDate,
    SalesAmount,          // Measure in Fact
    SalesQuantity         // Measure in Fact
FROM sales.csv;

Dim_Customers:            // Dimension Tables mit "Dim_" Prefix
LOAD
    CustomerID,           // PK
    CustomerName,         // Attribute
    CustomerSegment,      // Attribute
    CustomerRegion        // Attribute
FROM customers.csv;

// 3. Avoid Generic Names
LOAD
    ID as CustomerID,                    // Konkret statt generisch
    Name as CustomerName,               // Kontext hinzufügen
    Type as CustomerType,               // Präzise Benennung
    Status as CustomerStatus,           // Eindeutige Zuordnung
    Date as CustomerRegistrationDate    // Volle semantische Klarheit
FROM customers.csv;

Erklärung der Strategie:

• Prefix-System: Tabellenname als Präfix verhindert versehentliche Name-Collisions
• Suffix-Standards: ID = Key, Date = Datum, Amount = Geld-Betrag, Count = Anzahl
• Fact/Dim-Trennung: Klare Unterscheidung zwischen transaktionalen und dimensionalen Daten

Performance-Kontext:

• Team-Effizienz: 50-70% weniger Zeit für Datenmodell-Debugging
• Onboarding: Neue Entwickler verstehen Modell in 30 Min statt 3 Std
• Wartung: Strukturänderungen in 15 Min statt 2 Std (keine unerwarteten Seiteneffekte)

Best Practices

• Template-Driven Development: Erstellen Sie Template-Apps mit korrekten Naming Patterns. Neue Projekte kopieren Template statt from-scratch development. Beinhaltet Standard-Tabellen (Kalender, Lookup-Tables) mit korrekten Namen.
• Code Review Integration: Naming Convention Checklist für alle Pull Requests. Automatisierte Checks wo möglich (Prefix-Validation, Reserved-Words-Check). Cultural Change: Conventions sind nicht optional sondern Quality-Standard.
• Living Documentation: Conventions-Dokument mit Real-Examples aus aktuellen Apps. Regular Updates wenn neue Patterns entstehen. FAQ-Section für häufige Edge-Cases und deren approved Solutions.
• Tooling Support: Include-Files mit Standard-Mappings und Lookup-Tables. Code-Snippets für IDE/Text-Editoren. Validation-Scripts die Modell auf Convention-Compliance prüfen.

✓ Checkpoint: Warum sind Präfixe besser als Suffixe für Tabellenzugehörigkeit?

→ Nächster Schritt: Mit soliden Naming Conventions können Sie saubere Star Schemas aufbauen. Star Schema Implementation zeigt optimale Datenmodell-Architektur.

Wie vergleiche ich alle Lösungsansätze für Synthetic Keys & Circular References in Qlik Sense?

Diese Bewertung basiert auf typischen Enterprise-Projekten (10-30 Tabellen, 2-5 Entwickler, 2-3 Jahre Projektlaufzeit).

Legende:

• Problem-Lösung: Wie effektiv wird das konkrete Problem adressiert
• Implementierung: Erstmaliger Zeitaufwand bis zur funktionsfähigen Lösung
• Maintenance: Langfristiger Aufwand für Wartung und Anpassungen
• Team-Skalierung: Wie gut funktioniert der Ansatz mit mehreren Entwicklern
• Performance: Auswirkung auf Qlik-App-Performance und User Experience

Interpretation: Reactive Fixes sind verlockend wegen der schnellen Implementierung, führen aber zu Technical Debt. Präventive Conventions haben hohe Initial-Investition, zahlen sich aber exponentiell aus bei Team-Arbeit und langfristiger Wartung.

Wie löse ich Synthetic Keys & Circular References in Qlik Sense?

Alphabetischer Index:

• Associations verschwunden nach Fieldumbenennung
• Circular Reference bleibt trotz Umbenennungen
• Performance schlechter nach Synthetic Key Auflösung
• Star Schema wird nicht automatisch erkannt
• Synthetic Keys kommen nach Reload zurück
• Falsche Aggregationen trotz korrektem Modell

Wie löse ich das Problem mit Synthetic Keys nach dem Reload in Qlik Sense?

Symptom: $Syn-Tabellen erscheinen wieder obwohl Felder umbenannt wurden

Häufigste Ursachen:

1. Neues Feld in Source-Daten → Lösung: Prüfen Sie neue Spalten in CSV/Database, passen Sie Umbenennungen an
2. Andere Tabelle lädt gleichen Feldnamen → Lösung: Systematisch alle LOAD-Statements prüfen, nicht nur die zwei problematischen
3. Include-File oder Subroutine überschreibt Umbenennung → Lösung: Prüfen Sie Include-Files auf Feld-Aliase

Debug-Schritte:

1. Aktivieren Sie Field-Value-Tracing: SET TraceValueFields = 1;
2. Suchen Sie im Load-Script nach allen Vorkommen des problematischen Feldnamens
3. Prüfen Sie Recent-Changes in Source-Systemen (neue Spalten, geänderte Namen)

Code-Fix:

// Debug: Alle Felder tracken
TRACE "=== BEFORE LOAD ===";
FOR i = 1 to NoOfTables()
    TRACE "Table: $(TableName($(i)-1))";
    FOR j = 1 to NoOfFields(TableName($(i)-1))
        TRACE "  Field: $(FieldName($(j), TableName($(i)-1)))";
    NEXT j
NEXT i

Wie löse ich das Problem mit verschwundenen Associations nach Fieldumbenennung?

Symptom: Tabellen sind isoliert, keine automatischen Verknüpfungen mehr sichtbar

Häufigste Ursachen:

1. Verknüpfungsfeld wurde versehentlich umbenannt → Lösung: Key-Felder müssen identisch bleiben
2. Datentyp-Mismatch nach Umbenennung → Lösung: Prüfen Sie Datentypen der Key-Felder

Debug-Schritte:

1. Prüfen Sie Datenmodell: Sind Key-Felder in beiden Tabellen vorhanden?
2. Testen Sie mit Beispiel-Daten: TRACE Distinct(CustomerID); in beiden Tabellen
3. Checken Sie Datentypen: String vs Number kann Association verhindern

Code-Fix:

// Ensure consistent data types
LOAD
    Text(CustomerID) as CustomerID,  // Force string type
    CustomerName
FROM customers.csv;

LOAD
    Text(CustomerID) as CustomerID,  // Force same type
    OrderDate
FROM orders.csv;

Wie kann ich die Performance nach der Synthetic Key Auflösung verbessern?

Symptom: Charts und Expressions sind langsamer trotz eliminierter $Syn-Tabellen

Häufigste Ursachen:

1. Denormalisierung führt zu größeren Tabellen → Lösung: QVD-Optimierung und Memory-Management
2. Mehr Felder durch Umbenennung → Lösung: Prüfen Sie ob alle umbenannten Felder tatsächlich benötigt werden

Debug-Schritte:

1. Vergleichen Sie Memory-Verbrauch vor/nach mit DocumentSize()
2. Profiling: Welche Charts sind am langsamsten geworden?
3. Row-Count-Vergleich: Sind Tabellen durch Denormalisierung explodiert?

Code-Fix:

// Reduce redundant fields
LOAD
    CustomerID,
    CustomerName,
    // CustomerRegion,    // Drop if not used in expressions
    // CustomerCountry    // Drop if derivable from other fields
FROM customers.csv;

Siehe auch: QVD-Performance Optimization für Memory-effiziente Lösungen

Was sind die nächsten Schritte zur Lösung von Synthetic Keys & Circular References in Qlik Sense?

Sie können jetzt saubere, performante Datenmodelle ohne Synthetic Keys und Circular References erstellen. Für Production-Ready Apps vertiefen Sie diese Themen:

1. Optimale Modell-Architektur: Naming Conventions sind der erste Schritt zu systematischer Modellierung. Star Schema Design zeigt Ihnen wie Sie Enterprise-taugliche Datenmodelle aufbauen.

2. Performance-Optimierung: Saubere Modelle sind die Basis für schnelle Apps. QVD-Optimierung maximiert Load-Performance und Memory-Effizienz Ihrer Modelle.

3. Enterprise-Standards: Bei größeren Teams brauchen Sie systematische Governance. Data Governance Framework etabliert Standards und Qualitätssicherung für komplexe Projekte.