Inline-Tabellen verstecken gemeinsame Wahrheit

Drei Apps joinen sales_otc über denselben Statuscode — die Wahrheit steckt nur in einem Qlik-INLINE. Inline-Tabellen sind Implementierungsdetail, bis mehrere Consumer von derselben kodierten Wahrheit abhängen.

zweiter Consumer dieselbe Kodierung teilt, driftet sie.

Lösung: Geteilte Steuerdaten als Produkt führen, sobald mehr als ein Consumer dieselbe Kodierung braucht — Inline bleibt lokal, bis genau dieser Fall eintritt.

In einem Satz: Inline ist Detail, bis ein zweiter Consumer dieselbe Wahrheit braucht.

Problem

Steuerdaten verstecken sich in vielen Formen offen sichtbar:

• Qlik-LOAD INLINE-Blöcke für Statusmaps, Regionsgruppen und „Fix“-Werte;
• SQL-VALUES / UNION ALL-Literaltabellen in Views und Prozeduren;
• dbt-Seeds, die als temporäre Fixtures starteten und ohne Stewardship zu produktiven Crosswalks wurden;
• Python- oder Notebook-Dictionaries und -Listen als Join-Keys in geplanten Jobs;
• Power-Query-„Enter data“-Tabellen, die in ein semantisches Modell eingefügt wurden.

Jedes Muster ist schnell für eine einzelne App. Geteilte Steuerdaten driften dann:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Qlik app     INLINE status 90 = Cancelled
Warehouse    VALUES status 90 = Cancelled, 95 = Void
dbt seed     status 90 = Cancelled (old label)
Power Query  Enter data: status 90 = Canceled (US spelling, different code set)

Entwickler kopieren den Block in die nächste App. Stewards können nicht an einer Stelle ändern. Kataloge sehen die Tabelle nie. Lineage-Tools melden „kein Upstream“. Auditoren finden fachliche Bedeutung in Source-Control-Kommentaren statt in einem besessenen Dataset.

Teil 1 hat Steuerdaten als Asset-Klasse gerahmt. Teil 2 isoliert das Inline-Muster, weil es der häufigste Weg ist, wie gemeinsame Wahrheit unsichtbar wird — und dabei trotzdem „in der Plattform“ aussieht.

Inline ist nicht immer falsch. Falsch ist es als System of Truth für Steuerdaten, die geteilt, sensitiv, historisch relevant oder von mehr als einem Delivery-Pfad konsumiert werden. Das deckt sich mit Fachliche Logik außerhalb der BI-Apps halten: gemeinsame Bedeutung außerhalb des Consumer-Artefakts; tool-lokales Verhalten darf lokal bleiben.

Entscheidung

Inline = Implementierungsdetail. Nie die Source of Truth für geteilte Steuerdaten.

Erlaubte Nutzungen von Inline-/Literaltabellen:

• Wegwerf-Prototypen und Spikes mit benanntem Sunset-Datum;
• echt app-lokale Präsentationslabels, die kein anderer Nutzer wiederverwenden muss;
• synthetische Demo-Daten, klar als Non-Production markiert;
• temporäre Bridges während einer Migration mit explizitem Exportdatei-Ticket;
• Unit-Test-Fixtures, die nicht als produktive Kontrollregel-Tabellen deployt werden.

Extrahieren Sie, wenn eine der folgenden Bedingungen zutrifft:

• zwei oder mehr Apps, Modelle oder Jobs brauchen dasselbe Mapping oder denselben Reference-Satz;
• Finance, Risk oder regulatorisches Reporting hängt von den Codes ab;
• Berechtigung oder personenbezogene Daten-verknüpfte Keys sind involviert (Access & Security Governance);
• Änderungshistorie zählt (wer hat was geändert, valid_from / valid_to);
• der Katalog oder eine Richtlinie benennt das Konzept bereits;
• Reload- oder Publish-Fehler wurden bereits durch eine Inline-Änderung verursacht;
• ein Steward außerhalb des Entwicklerteams muss die Werte pflegen.

Extraktionsziel ist eine governte Control-Tabelle (oder eine freigegebene API/UI über diese Tabelle). Das Skript darf die Tabelle weiterhin laden; es darf sie nicht besitzen. dbt-Seeds dürfen nur dann Packaging-Format bleiben, wenn der Seed aus dem besessenen Store generiert oder strikt dazu synchronisiert wird — nicht, wenn die CSV in Git die einzige Editor-Oberfläche für Fach-Stewards ist.

Verwechseln Sie diese Entscheidung nicht mit einem Verbot von Excel-Analyse (Excel-Schatten-BI und Kennzahlen-Drift). Inline-Extraktion betrifft kodierte geteilte Tabellen, nicht das Entfernen jeder consumerseitigen Formel.

Checkliste

Führen Sie ein Inline-Inventar durch, bevor Sie Architektur umschreiben:

• durchsuchen Sie Repos und Skriptbibliotheken nach INLINE, LOAD * INLINE, VALUES (, Seed-Ordnern, Enter data, hardcodierten dict( / Mapping-Arrays;
• erfassen Sie Dateipfad, Objektname, Zeilenanzahl-Band und Taxonomieklasse aus Teil 1;
• zählen Sie Nutzer und Duplikatskopien;
• markieren Sie Sensitivität und ob Änderungen fachliche Freigabe brauchen;
• entscheiden Sie: keep-local, extract, deduplicate-then-extract, retire;
• benennen Sie für jedes extract den Ziel-Store und Steward;
• ersetzen Sie Inline-Loads durch einen einzigen Read von der besessenen Tabelle;
• ergänzen Sie eine CI- oder Scan-Regel, damit neue geteilte Inlines nicht unbemerkt landen;
• aktualisieren Sie Katalogeinträge und Lineage, sobald die Tabelle real ist;
• führen Sie eine kurze Exception-Liste für freigegebene lokale Inlines mit Ownern und Review-Daten.

Bevorzugen Sie langweilige Konsistenz: ein Extract-Muster pro Plattform (Qlik Resident aus der Control-DB, dbt ref auf Control-Modell, Power Query aus zertifizierter Quelle).

Artefakt

Erstellen Sie Inline Inventory Scan Rules — ein lebendes Regelwerk plus Scan-Output, keine einmalige Spreadsheet.

Minimales Regelpaket:

Scan-Output-Felder: Rule ID, Location, Hash/Fingerprint, Klasse, Consumers, Owner, Disposition, Ticket-Link.

Wiederholen Sie den Scan im Zeitplan und bei Pull Requests, die Skriptpfade berühren.

Tools

Nutzen Sie ripgrep / CI-Scanner im Secret-Stil, adaptiert für INLINE und VALUES. Nutzen Sie dbt-Projektparser für Seeds. Nutzen Sie Qlik- und Power-BI-Source-Control-Diffs. Nutzen Sie Report Inventory, um Consumers anzubinden. Nutzen Sie Katalog-Bulk-Import, sobald extrahierte Tabellen existieren. Abgleichen Sie mit dem Control Data Risk Register aus Teil 1.

Ressourcen

Skriptbibliotheken, Transformations-Repos, Semantic-Model-PBIX/PQ-Traces, Notebook-Job-Definitionen, frühere Incidents zu „falschem Code-Mapping“ und Steward-Listen.

Schwesterlektüre: Fachliche Logik außerhalb der BI-Apps halten, Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen, Building a Modern Data Warehouse, Catalog Deep Dive.