Erzeugen Ihre Qlik Apps immer wieder synthetische Schlüssel?

Synthetische Schlüssel und zirkuläre Referenzen sind Qlik, das genau das verknüpft, was es bekommen hat. Sie entstehen, weil die Daten ohne konforme Dimensionen oder echte Schlüssel ankommen, und deshalb muss jede App sie selbst erfinden.

Erzeugen Ihre Qlik Apps immer wieder synthetische Schlüssel?

Die Data Warehouse Automation Plattform, der Datenteams aus vielen Branchen vertrauen

Petr Beles Petr Beles Co-Founder · Veröffentlicht in Lösungen für BI Tool Herausforderungen LinkedIn

Kommt Ihnen das bekannt vor?

  • Der Datenmodell Viewer ist voller $Syn Tabellen, die niemand anlegen wollte.
  • Ein Reload warnt vor einer zirkulären Referenz, und eine Tabelle wird am Ende lose gekoppelt.
  • Am Anfang jedes Ladeskripts steht ein Block aus Umbenennungen, QUALIFY Anweisungen und Link Tabellen.
  • Eine einzige neue Tabelle in einer App zerlegt Verknüpfungen, die gestern noch funktioniert haben.

Ein synthetischer Schlüssel ist Qlik, das mit den übergebenen Tabellen genau das tut, was es tun soll. Wenn mehrere Tabellen mehrere Feldnamen teilen, muss die Engine sie irgendwie verknüpfen.

Was Ihnen die synthetischen Schlüssel sagen

  • Mehrere Tabellen teilen mehrere Felder. Qlik baut für jede Kombination eine $Syn Tabelle, und der Datenmodell Viewer füllt sich damit.
  • Zwei Wege führen zur selben Tabelle. Das ist eine zirkuläre Referenz, und Qlik koppelt eine Tabelle lose, um die Schleife aufzubrechen.
  • Die Fixes sind strukturell. Link Tabellen, konkatenierte Fakten, QUALIFY, Umbenennen mit AS, zusammengesetzte Schlüssel mit AutoNumber.
  • Jeder Fix ist lokal. Er löst das Problem in dieser App, und die nächste App auf denselben Quellen fängt von vorne an.

Jeder davon ist ein Schlüssel, der hätte existieren sollen, bevor die Daten Qlik erreichen.

Warum es bei Ihnen landet

  • Die Extrakte kamen mit den Feldnamen, die das jeweilige Quellsystem zufällig verwendet.
  • Niemand weiter oben hat entschieden, welche CustomerID der Kunde ist, also muss es das Ladeskript tun.
  • Sie können ein Feld in Qlik umbenennen. Die Dimension, aus der es stammt, konform machen können Sie nicht.

Die Arbeit passiert am falschen Ort

  • Festzulegen, wie Tabellen zusammenhängen, ist Warehouse Arbeit. In Qlik wird sie im Ladeskript jeder App neu erledigt.
  • Sie gehört an einen zentralen Ort: ein Data Warehouse oder einen Data Hub, einmal gebaut und von jeder App gelesen.
  • Wenn das teuer klingt, geht die Schätzung vermutlich von handgebauten Pipelines aus. Eine spezialisierte Automatisierungsplattform generiert sie aus einem Modell. Das ändert Kosten und Dauer.

Was sich ändert, wenn das Modell fertig ankommt

Datavault Builder generiert Vault und dimensionale Schicht nativ in der Datenbank, die Sie bereits haben, ob Snowflake, Databricks, SQL Server, Fabric, Oracle oder PostgreSQL.

  • Konforme Dimensionen bedeuten eine Kundentabelle und einen Kundenschlüssel, geteilt von jeder Faktentabelle.
  • Surrogatschlüssel verknüpfen über ein einziges Feld, damit bleibt für Qlik nichts mehr zu synthetisieren.
  • Fakten mit festgelegter Granularität ersetzen die Link Tabelle, die Sie von Hand gepflegt haben.
  • Das Ladeskript wird zu einem einfachen LOAD aus fertigen Tabellen, ohne Umbenennungsblock obendrauf.
  • Eine neue App startet vom Modell, nicht von einer Kopie des letzten Fixes.

Worum Sie bitten sollten

Nicht “Qlik erzeugt ständig synthetische Schlüssel”, sondern:

“Unsere Apps brauchen Link Tabellen und umbenannte Felder, weil Aufträge, Rechnungen und Lieferungen jeweils eigene Kunden und Datumsschlüssel mitbringen. Kann das Warehouse konforme Dimensionen mit Surrogatschlüsseln liefern, damit jede App dasselbe Star Schema lädt?”

Falls die Antwort lautet, dass konforme Dimensionen ein Quartal Entwicklungszeit kosten: genau diesen Einwand räumt Datavault Builder aus.

Sehen Sie es mit Ihren eigenen Daten

Buchen Sie eine kostenlose Demo und bringen Sie den Report mit, der Ihnen die meisten Probleme macht.

Kostenlose Demo buchen

In drei Schritten zu Zahlen, die aufgehen

  1. Bestehende Logik herauslösen

    Sammeln Sie Berechnungen, Joins und Filter, die heute in Ihren Reports stecken.

  2. An einem Ort zentralisieren

    Die Logik kommt einmal ins Warehouse Modell, und jeder Report liest dieselbe Definition.

  3. Zahlen, die aufgehen

    Jeder Report zeigt dieselbe Zahl, und “Woher kommt diese Zahl” hat eine sichtbare Antwort.

Wie Datavault Builder Ihrem Report ein fertiges Modell liefert

  • Das Modell kommt fertig an

    Datavault Builder generiert Vault und Star Schema so, dass sie nativ in der Datenbank laufen, die Sie bereits haben: SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks oder BigQuery.

  • Die Arbeit verlässt den Report

    Kein Merge, kein Parsen, kein Fuzzy Match. Diese Arbeit ist aus dem Report verschwunden.

  • Quellen kommen integriert an

    Kunden aus ERP, CRM und Webshop werden zu einem Satz konformer Dimensionen zusammengeführt. Der Join passiert einmal im Warehouse, nicht erneut in jedem Report.

  • Historie, die abfragbar ist

    Jede Änderung wird so festgehalten, wie sie eintrifft. Sie können den Stand von damals genauso auswerten wie den von heute, auch wenn das Quellsystem seine eigenen Sätze überschreibt.

  • Jede Zahl hat Lineage

    Die Logik bekommt Lineage. “Woher kommt diese Zahl” hat damit eine sichtbare Antwort.

  • Historisierung im Warehouse

    Historisierung übernimmt das Warehouse als Vault Satelliten, statt sie zu approximieren.

Ausgezeichnet von BARC im Data Fabric Survey 26

Sprechen Sie mit unserem Experten

Zwanzig Minuten mit unserem Sales Director und eine ehrliche Antwort, ob das zu Ihrer Situation passt.

Matt Collett

Matt Collett

Sales Director

Was suchen Sie?

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Weitere Probleme in dieser Serie

  • Zeigen Ihre Qlik Apps und Power BI Reports unterschiedliche Zahlen?

    Weder Qlik noch Power BI liegt falsch. Jedes Tool hat seine eigene Ladelogik, seine eigenen Definitionen und seine eigene Lineage, also wird dieselbe Kennzahl zweimal berechnet und niemand kann sie abgleichen. Die Regeln gehören in ein gesteuertes Warehouse Modell, das beide Tools lesen.

  • Bereinigen Sie dieselben Daten in jedem Qlik Ladeskript erneut?

    Dieselben Mapping Loads, String Korrekturen und Deduplizierungen werden in jeder App und jeder QVD Schicht neu geschrieben, und die Kopien laufen auseinander. Die Bereinigung wiederholt sich pro Skript, weil keine integrierte Warehouse Schicht sie einmal erledigt.

  • Sind Ihre Qlik Set Analysis Ausdrücke zu lang und zu langsam?

    Set Analysis ist präzise für echte Vergleiche. Die meisten langen Ausdrücke in Ihrer App stehen dort, weil das Modell nie Historie, Flags oder eine einheitliche Granularität geliefert hat, und das Diagramm baut sie bei jeder Selektion neu.