Datenqualitäts-Cockpit in Qlik und Power BI — Von der Kennzahl bis zur Behebung

Wie eine standardisierte Data-Quality-Historie in Qlik und Power BI zu einem operativen Management-Cockpit mit Quality Score, Failure Rate, Trends, Verantwortung, SLA, Maßnahmen und Drill-down auf fehlerhafte Datensätze wird.

Category: Datenqualität
Author: Thomas Lindackers
Reading time: 16 min
Published: Jun 3, 2026
Tags: data-quality operational-data-quality data-quality-cockpit qlik-sense power-bi quality-score failure-rate drill-down drillthrough sla remediation ownership data-governance

267 Views

Download PDF

Begriffe vor dem Lesen

DQ auf der Plattform — Umsetzung von Datenqualitaetsregeln in Fabric, dbt, Databricks oder vergleichbaren Stacks.
Rule-ID — Stabile Kennung einer fachlichen Erwartung ueber Tools hinweg.
Result Table — Standardisierte Tabelle für Regel-Lauf, Status, Fehlerrate, Owner und Nachweis.
Quellkorrektur — Behebung im fuehrenden System, wenn der Fehler dort entsteht.
Transformation — Nachgelagerte Bereinigung; sie braucht Kennzeichnung, Grund und Nachweis.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Ein Dashboard ist erst dann ein Data Quality Cockpit, wenn daraus gehandelt wird

Die vorherigen Teile dieser Serie haben gezeigt, wie technische Tests in Microsoft Fabric, dbt und Databricks standardisierte, historische Ergebnisse erzeugen.

Damit existiert die Grundlage:

Ein operatives Data Quality Cockpit ergänzt die Steuerungsebene:

Das Cockpit muss deshalb mehr leisten als eine grüne oder rote Übersicht.

Es muss beantworten:

Wie entwickelt sich die Datenqualität?
Welche Data Products verschlechtern sich?
Welche kritischen Regeln schlagen fehl?
Welche Tabelle und Spalte sind betroffen?
Wie viele Datensätze sind fehlerhaft?
Wer ist verantwortlich?
Welche Maßnahme ist offen?
Wird das vereinbarte SLA eingehalten?
Welche konkreten Datensätze müssen untersucht werden?
Hat die Behebung den nächsten Testlauf verbessert?

Das gemeinsame Datenmodell hinter Qlik und Power BI

BI-Tools als Beispiele (z. B. Qlik oder Power BI) sollten dieselben kuratierten Fakten verwenden.

Ein belastbares Modell besteht aus mindestens vier fachlichen Objekten:

Optional ergänzt:

DQ_RUN
DQ_DATA_PRODUCT
DQ_OWNER
DQ_SLA_POLICY
DQ_DATE

`DQ_RULE`

Eine Zeile je versionierter Qualitätsregel.

Typische Felder:

Rule ID
Rule Version
Rule Name
Business Description
Data Product
Table
Column
Test Type
Threshold
Schweregrad
verantwortliche Person
Active From
Active To
Execution Platform
Details Link

`DQ_TEST_RESULT`

Eine Zeile je Regelausführung.

Typische Felder:

Run ID
Rule ID
Rule Version
Status
Rows Tested
Rows Failed
Failure Rate
Executed At
Platform
Execution Method
Duration
Metric Completeness
verantwortliche Person Snapshot
Schweregrad Snapshot

`DQ_FAILURE_DETAIL`

Null bis viele Fehlerdatensätze je Regelausführung.

Typische Felder:

Run ID
Rule ID
Entity ID
Failure Code
Failure Reason
Detected Value
Source System
Load ID
Detail Timestamp

`DQ_ACTION`

Eine Zeile je Maßnahme oder Ticket.

Typische Felder:

Action ID
Rule ID
Run ID
verantwortliche Person
Action Status
Created At
Due At
Resolved At
Resolution
Ticket URL
Re-Test Run ID
SLA Status

Die Ergebnisfaktentabelle und die Fehlerdetailtabelle besitzen unterschiedliche Grains.

Das Data Quality Management Cockpit

Ein vollständiges Cockpit benötigt mehrere Perspektiven.

1. Management-KPIs

Die oberste Ebene zeigt wenige belastbare Kennzahlen:

Quality Score
Failure Rate
ausgeführte Regeln
fehlgeschlagene Prüfungen
geprüftes Datenvolumen
SLA-Konformität
offene Maßnahmen
überfällige Maßnahmen

Diese KPIs benötigen immer:

einen Zeitraum
einen Vergleichszeitraum
einen klaren Filterkontext
eine dokumentierte Berechnung
einen Zeitstempel der letzten Aktualisierung

2. Entwicklung über Zeit

Zeitreihen zeigen:

Quality Score je Tag oder Run
Failure Rate
bestandene und fehlgeschlagene Regeln
Warnungen
technische Errors
verworfene Datensätze
offene und überfällige Maßnahmen

Ein einzelner aktueller Wert kann eine systematische Verschlechterung verbergen.

3. Regeln nach Schweregrad

Severity hilft bei der Priorisierung:

Critical
High
Medium
Low

Severity beschreibt die fachliche Auswirkung.

Sie ist nicht dasselbe wie:

Teststatus
technische Action wie Warn, Drop oder Fail
Anzahl fehlerhafter Zeilen
SLA-Status

Eine kritische Regel kann nur wenige Datensätze betreffen und trotzdem sofortige Reaktion erfordern.

4. Data Product, Tabelle und Spalte

Das Cockpit muss von einer unternehmensweiten Übersicht zu den betroffenen Datenobjekten führen:

Die Ebenen müssen dem Datenmodell und den Verantwortlichkeiten der Organisation entsprechen.

5. Owner

Owner-Dimensionen ermöglichen:

Fehler nach verantwortlichem Team
offene Maßnahmen je verantwortliche Person
SLA-Verstöße
wiederkehrende Fehler
nicht zugeordnete Regeln
Regeln mit veraltetem verantwortliche Person

Der Owner sollte aus der historischen Ergebniszeile oder einer zeitabhängigen Zuordnung kommen. Nur der aktuelle Owner einer Stammtabelle kann historische Verantwortlichkeit falsch darstellen.

6. SLA und offene Maßnahmen

Das Cockpit wird operativ, wenn es nicht nur Fehler, sondern deren Bearbeitung zeigt:

offen
in Analyse
in Behebung
wartet auf Quelle
bereit für Re-Test
gelöst
akzeptiertes Risiko
geschlossen

Dazu gehören:

Fälligkeitsdatum
Alter der Maßnahme
verantwortlicher verantwortliche Person
letzter Kommentar
Ticket oder Workflow-Link
Resolution
Re-Test-Ergebnis

Failure Rate und Quality Score sind unterschiedliche Kennzahlen

Die beiden Kennzahlen beantworten unterschiedliche Fragen.

Failure Rate

Die zeilengewichtete Failure Rate lautet:

Sum(Rows Failed) / Sum(Rows Tested)

Sie beantwortet:

Die Kennzahl eignet sich besonders für Regeln mit sinnvoll vergleichbarem Zeilengrain.

Sie darf nicht als einfacher Durchschnitt gespeicherter Prozentwerte berechnet werden.

Beispiel:

Test A:
1 Fehler / 10 Zeilen = 10 %

Test B:
100 Fehler / 100.000 Zeilen = 0,1 %

Einfacher Durchschnitt:
5,05 %

Zeilengewichtete Failure Rate:
101 / 100.010 ≈ 0,101 %

Rule Pass Rate

Passed Rule Runs / Executed Rule Runs

Sie beantwortet:

Ein Test mit zehn geprüften Zeilen hat hier dasselbe Gewicht wie ein Test mit zehn Millionen Zeilen.

Quality Score

Ein Quality Score ist keine universell standardisierte Kennzahl. Die Organisation muss seine Semantik dokumentieren.

Ein einfaches, transparentes Beispiel verwendet status- und severitygewichtete Regelresultate.

Statuswerte:

Status	Score
Passed	1,00
Warning	0,50
Filtered	0,25
Failed	0,00
Failed Early	0,00
Error	separat behandeln
Skipped	aus dem Nenner ausschließen

Severity-Gewichte:

Severity	Gewicht
Critical	8
High	4
Medium	2
Low	1

Berechnung:

Quality Score =
Sum(Status Score × Severity Weight)
/
Sum(Severity Weight)
× 100

Beispiel:

Critical Passed:
1,00 × 8

High Failed:
0,00 × 4

Medium Warning:
0,50 × 2

Low Passed:
1,00 × 1

Quality Score:
(8 + 0 + 1 + 1) / (8 + 4 + 2 + 1)
= 66,7 %

Dieses Beispiel ist bewusst einfach.

Alternativ kann die Organisation:

Threshold-Abweichungen einbeziehen
Data-Product-Kritikalität gewichten
Regelabdeckung berücksichtigen
technische Errors als eigene KPI behandeln
Quality Dimensions wie Completeness, Validity und Timeliness getrennt bewerten

Errors und Skipped Tests nicht verstecken

Eine hohe Quality Score kann irreführend sein, wenn viele Tests technisch nicht ausgeführt wurden.

Deshalb sollten zusätzlich sichtbar sein:

Test Coverage
Error Rate
Skipped Rate
Metric Completeness
letztes erfolgreiches Ergebnis
Alter des letzten Tests

Beispiel:

100 definierte Regeln
80 Passed
5 Failed
15 Error

Rule Pass Rate bezogen auf alle Regeln:
80 %

Rule Pass Rate nur auf ausgeführte Qualitätsresultate:
94,1 %

Beide Werte erzählen eine andere Geschichte.

Technische Errors gehören nicht automatisch in die Failure Rate der Fachdaten. Sie benötigen eine separate operative Perspektive.

Qlik-Modell und Kennzahlen

Qlik eignet sich besonders für associative Selections über:

Data Product
Table
Column
Rule
Owner
Severity
Run
Status
Action

Ein mögliches logisches Modell:

DQ_TEST_RESULT
  ↕ RuleKey
DQ_RULE

DQ_TEST_RESULT
  ↕ RunID
DQ_RUN

DQ_FAILURE_DETAIL
  ↕ RunRuleKey
DQ_TEST_RESULT

DQ_ACTION
  ↕ RuleKey / RunRuleKey
DQ_TEST_RESULT

Synthetische Schlüssel und unkontrollierte Many-to-many-Verbindungen sollten vermieden werden.

Empfohlene technische Schlüssel:

RuleKey =
Rule ID & '|' & Rule Version

RunRuleKey =
Run ID & '|' & Rule ID & '|' & Rule Version

Qlik Failure Rate

Num(
    Sum(rows_failed)
    /
    Sum(rows_tested),
    '0.00%'
)

Null-sicher:

If(
    Sum(rows_tested) > 0,
    Num(
        Sum(rows_failed) / Sum(rows_tested),
        '0.00%'
    )
)

Qlik Rule Pass Rate

Num(
    Count({
        <test_status = {'Passed'}>
    } DISTINCT run_rule_key)
    /
    Count({
        <test_status -= {'Skipped'}>
    } DISTINCT run_rule_key),
    '0.0%'
)

Qlik offene Maßnahmen

Count({
    <action_status -= {'Resolved', 'Closed', 'Accepted Risk'}>
} DISTINCT action_id)

Qlik überfällige Maßnahmen

Count({
    <
        action_status -= {'Resolved', 'Closed', 'Accepted Risk'},
        due_date = {"<$(=Date(Today()))"}
    >
} DISTINCT action_id)

Qlik Set Analysis für Critical Failures

Count({
    <
        severity = {'Critical'},
        test_status = {'Failed', 'Failed Early'}
    >
} DISTINCT run_rule_key)

Qlik Drill-down

Eine Master-Dimension kann beispielsweise enthalten:

Domain
Data Product
Table
Column
Rule Name

Qlik wechselt innerhalb einer Drill-down-Dimension automatisch auf die nächste Ebene, wenn durch Selektionen nur noch ein Wert der aktuellen Ebene möglich ist.

Für den Weg bis zum einzelnen Fehlerdatensatz sind häufig getrennte Sheets sinnvoll:

Management Overview
Data Product and Rule Analysis
Failure Records
Action and SLA Management

Selections und Buttons können den Kontext zwischen den Sheets erhalten.

Power-BI-Modell und Kennzahlen

Power BI sollte ein sauberes Sternschema verwenden.

Fakten:

Fact DQ Test Result
Fact DQ Failure Detail
Fact DQ Action

Dimensionen:

Dim Rule
Dim Data Product
Dim verantwortliche Person
Dim Schweregrad
Dim Platform
Dim Date
Dim Run

Beziehungen sollten bevorzugt von Dimension zu Fakt in eine Richtung filtern.

DAX Failure Rate

Failure Rate =
DIVIDE(
    SUM('Fact DQ Test Result'[Rows Failed]),
    SUM('Fact DQ Test Result'[Rows Tested])
)

DAX Rule Pass Rate

Rule Pass Rate =
DIVIDE(
    CALCULATE(
        DISTINCTCOUNT(
            'Fact DQ Test Result'[Run Rule Key]
        ),
        'Fact DQ Test Result'[Test Status] = "Passed"
    ),
    CALCULATE(
        DISTINCTCOUNT(
            'Fact DQ Test Result'[Run Rule Key]
        ),
        'Fact DQ Test Result'[Test Status] <> "Skipped"
    )
)

DAX offene Maßnahmen

Open Actions =
CALCULATE(
    DISTINCTCOUNT('Fact DQ Action'[Action ID]),
    NOT (
        'Fact DQ Action'[Action Status]
            IN { "Resolved", "Closed", "Accepted Risk" }
    )
)

DAX überfällige Maßnahmen

Overdue Actions =
CALCULATE(
    DISTINCTCOUNT('Fact DQ Action'[Action ID]),
    'Fact DQ Action'[Due At] < TODAY(),
    NOT (
        'Fact DQ Action'[Action Status]
            IN { "Resolved", "Closed", "Accepted Risk" }
    )
)

DAX SLA-Konformität

SLA Compliance =
DIVIDE(
    CALCULATE(
        DISTINCTCOUNT('Fact DQ Action'[Action ID]),
        'Fact DQ Action'[SLA Status] = "Within SLA"
    ),
    CALCULATE(
        DISTINCTCOUNT('Fact DQ Action'[Action ID]),
        NOT ISBLANK('Fact DQ Action'[SLA Status])
    )
)

Drillthrough in Power BI

Eine Drillthrough-Seite kann auf folgende Felder gefiltert werden:

Rule ID
Run ID
Data Product
Table
Column
verantwortliche Person

Dadurch navigiert ein Nutzer von einer aggregierten Regel direkt zu einer Detailseite im ausgewählten Kontext.

Geeignete Seiten:

Executive Overview
Data Product Quality
Rule Details
Failure Records
Action and SLA Details

Vom KPI bis zum fehlerhaften Datensatz

Ein sinnvoller Analysepfad besteht aus sieben Ebenen.

1. KPI

Der Nutzer erkennt:

Quality Score = 92,4 %
Failure Rate = 7,6 %

Diese Ebene zeigt das Ausmaß, aber noch keine Ursache.

2. Entwicklung über Zeit

Die Zeitreihe beantwortet:

einmaliger Ausreißer oder Trend?
seit welchem Run?
nach welchem Release?
Verbesserung nach einer Maßnahme?
wiederkehrendes Muster?

3. Schweregrad

Der Nutzer fokussiert kritische und hohe Fehler.

4. Data Product, Tabelle und Spalte

Der betroffene fachliche und technische Bereich wird lokalisiert.

5. Regeldetail

Die Regelansicht zeigt:

Business Description
Rule ID und Version
Threshold
Test Type
Ausführungsplattform
letzte Runs
Fehlerrate
verantwortliche Person
Schweregrad
offene Maßnahmen
technische Details

6. Fehlerhafte Datensätze

Die Detailtabelle zeigt nur relevante Spalten:

Entity ID
betroffene Werte
Failure Reason
Source System
Load ID
Detected At

7. Einzelner Datensatz

Die tiefste Ebene zeigt den vollständigen kontrollierten Kontext:

Business Key
relevante Attribute
Quellsystem
Load- und Batch-Information
Regelverletzung
vorheriger und aktueller Wert
zuständiger verantwortliche Person
Ticket oder Maßnahme
Re-Test-Status

Drill-down und Datenschutz

Fehlerdetails können sensible Informationen enthalten.

Das Cockpit benötigt deshalb getrennte Zugriffslevel.

Management-Level

Sieht:

Scores
Trends
Data Products
Schweregrad
verantwortliche Person
aggregierte Fehlermengen

Data Steward und Data Owner

Sieht zusätzlich:

Rule Details
Business Keys
Fehlerursachen
Maßnahmen
kontrollierte Fehlerdetails

Technische Spezialisten

Sieht zusätzlich:

Source System
Load ID
technische Events
Pipeline- oder Job-Information
Quarantäne- oder Evidenzlink

Schutzmaßnahmen:

personenbezogene Daten maskieren
unnötige Attribute nicht laden
Detaildaten zeitlich begrenzen
Section Access in Qlik oder Row-Level Security in Power BI einsetzen
Exportberechtigungen begrenzen
Zugriffe auditieren
Detailseiten getrennt berechtigen

SLA-Modell

SLA beginnt nicht erst mit dem Ticket.

Ein mögliches SLA-Modell:

Severity	Acknowledge	Analyse begonnen	Behebung oder akzeptierter Plan
Critical	1 Stunde	4 Stunden	1 Arbeitstag
High	4 Stunden	1 Arbeitstag	3 Arbeitstage
Medium	1 Arbeitstag	3 Arbeitstage	10 Arbeitstage
Low	3 Arbeitstage	nach Planung	nach Roadmap

Die konkreten Zeiten müssen von der Organisation definiert werden.

Sinnvolle Zeitpunkte:

Detected At
Assigned At
Acknowledged At
Analysis Started At
Resolved At
Re-Tested At
Closed At

Daraus entstehen Kennzahlen:

Time to Assign
Time to Acknowledge
Time to Resolve
Time to Re-Test
SLA Compliance
Overdue Age
Reopen Rate

Ein Fehler ist nicht mit der Datenkorrektur abgeschlossen

Ein vollständiger Abschluss benötigt:

Ohne Re-Test bleibt unklar, ob die Maßnahme wirksam war.

Maßnahmen und Tickets

Die DQ_ACTION-Tabelle kann aus einem Workflow- oder Ticketsystem kommen.

Ein Data Quality Cockpit sollte mindestens verlinken können auf:

ServiceNow
Jira
Azure DevOps
Microsoft Planner
Power Automate Workflow
Qlik Application Automation
internes Governance-Portal

Das BI-Tool muss nicht das führende Ticket-System werden.

Besser:

Die führende Quelle für Maßnahmenstatus muss eindeutig sein.

Alerting

Alerts sollten gezielt eingesetzt werden.

Sinnvolle Trigger:

Critical Rule Failed
Failure Rate über Threshold
Quality Score fällt stärker als definierter Grenzwert
Regel schlägt in mehreren Läufen hintereinander fehl
Data Product wurde nicht geprüft
Test endet mit Error
Maßnahme wird überfällig
Re-Test schlägt erneut fehl

Nicht jede einzelne fehlerhafte Zeile benötigt eine Benachrichtigung.

Qlik

Qlik Cloud kann datenbasierte Alerts für definierte Bedingungen und Schwellenwerte auswerten. Qlik Alerting bietet ebenfalls datenbezogene und komplexere Alert-Bedingungen, abhängig von der eingesetzten Qlik-Umgebung und Lizenzierung.

Power BI

Power BI unterstützt Datenwarnungen für bestimmte Dashboard-Kacheln wie KPIs, Karten und Gauges. Zusätzlich stehen je nach Umgebung weitere Report-Alert-Funktionen zur Verfügung. Die aktuell verfügbare Funktionalität und Preview-Kennzeichnung sollte vor der Umsetzung geprüft werden.

Für komplexe operative DQ-Alerts ist häufig eine vorgelagerte Workflow-Logik robuster als ausschließlich visuelles Alerting.

Performance und Datenvolumen

Fehlerdetailtabellen können sehr groß werden.

Empfehlungen:

Cockpit standardmäßig auf aggregierte Fakten setzen
Fehlerdetails erst bei Drill-down laden
aktuelle Detaildaten von historischer Evidenz trennen
Partitionierung nach Datum oder Run
inkrementelles Laden
nur relevante Spalten bereitstellen
große Fehlergruppen samplen oder paginieren
Detail-Retention begrenzen
aggregierte Historie länger aufbewahren

Beispiel:

DQ_TEST_RESULT:
36 Monate

DQ_FAILURE_DETAIL:
30 bis 90 Tage

Quarantäne:
abhängig von Fachprozess und Datenschutz

Die konkreten Fristen müssen durch Governance, Datenschutz und operative Anforderungen festgelegt werden.

Aktualität des Cockpits

Das Cockpit sollte sichtbar ausweisen:

Last Result Loaded At
Last Source Refresh
Last Successful Test Run
Result Latency
Action Status Sync Time

Ein Quality Score von 100 Prozent ist wertlos, wenn die Daten seit drei Tagen nicht aktualisiert wurden.

Deshalb ist die Aktualität des Monitorings selbst eine Kontrollkennzahl.

Empfohlene Cockpit-Seiten

Seite 1 — Management Overview

Quality Score
Failure Rate
Rule Pass Rate
Trends
Schweregrad
Top Data Products
SLA
offene Maßnahmen

Seite 2 — Data Product Analysis

Domain und Data Product
Tabelle und Spalte
Quality Dimensions
Regeln
Plattform
zeitliche Entwicklung

Seite 3 — Rule Details

Regeldefinition
Threshold
Version
verantwortliche Person
letzte Läufe
Statushistorie
technische Herkunft
Maßnahmen

Seite 4 — Failure Records

Fehlerdatensätze
Quellsystem
Load ID
Ursache
Evidenz
Export nur bei Berechtigung

Seite 5 — Actions and SLA

offene Maßnahmen
überfällige Maßnahmen
verantwortliche Person
Alter
Status
Re-Test
Ticket-Link

Abnahmekriterien für ein operatives Cockpit

Ein Cockpit ist bereit für den Betrieb, wenn:

Jede KPI-Formel dokumentiert ist.
Failure Rate und Rule Pass Rate getrennt sind.
Errors und Skipped Tests sichtbar bleiben.
Zeit-, Data-Product-, Regel- und Owner-Filter konsistent funktionieren.
Der Drill-down bis zur Regel möglich ist.
Berechtigte Nutzer Fehlerdetails sehen können.
Owner und Severity historisch nachvollziehbar sind.
Maßnahmen und SLA mit den Fehlern verbunden sind.
Ein Re-Test-Ergebnis den Abschluss bestätigt.
Qlik und Power BI dieselbe fachliche Semantik verwenden.
Detailzugriffe datenschutzkonform sind.
Cockpit-Aktualität und Datenlatenz sichtbar sind.

Typische Fehlentscheidungen

Einen nicht dokumentierten Quality Score verwenden

Dann ist die Kennzahl nicht auditierbar und kann nicht verlässlich verglichen werden.

Prozentwerte mitteln

Failure Rates müssen auf Basis ihrer Zähler und Nenner aggregiert werden.

Errors ausblenden

Ein nicht ausführbarer Test ist kein bestandener Test.

Management und Fehlerdetails auf dieselbe Seite laden

Das verschlechtert Performance, Bedienbarkeit und Datenschutz.

Owner nur als aktuellen Stammdatenwert verwenden

Historische Verantwortlichkeit kann dadurch falsch erscheinen.

Maßnahmen ohne Re-Test schließen

Die tatsächliche Verbesserung bleibt unbewiesen.

Qlik- und Power-BI-Logik getrennt entwickeln

Dann entstehen unterschiedliche Quality Scores für dieselben Daten.

Jede Warnung als Ticket erzeugen

Das erzeugt Alert Fatigue und überlastet den Prozess.

Details ohne Zugriffskontrolle bereitstellen

Datenqualität darf Datenschutz und Berechtigungskonzepte nicht umgehen.

Die zentrale Erkenntnis

Die standardisierte DQ-Historie liefert:

Regeln
Testläufe
Status
Mengen
Fehlerraten
verantwortliche Person
Schweregrad

Qlik und Power BI ergänzen:

Quality Score
Trends
Selektionen und Drill-down
Data-Product- und Regelperspektiven
SLA- und Maßnahmensteuerung
kontrollierten Zugriff auf Fehlerdetails

Der Prozess wird geschlossen durch:

Damit endet die Serie nicht bei einer Visualisierung. Sie endet bei einem wiederholbaren Betriebsmodell für messbare Datenqualität.

Passende Playbooks

Part 1 — From Tests to Data Quality Monitoring
Part 2 — Data Quality in Microsoft Fabric
Part 3 — Data Quality with dbt
Part 4 — Data Quality in Databricks
Part 5 — One Rule, Three Platforms
Data Quality & Governance
KPI Definition and Versioning
Governance-App Deep Dive — Tool-Historie laden, Outcomes, drei Adapter; Tableau im selben Vertrag.

Quellen und weiterführende Dokumentation

DQ on the platform

Part 5 of 5

View series

Part 1: Data Quality in Microsoft Fabric — Operationalizing Tests and Centralizing Results Part 2: Data Quality with dbt — From Tests and Failure Tables to Historical Monitoring Part 3: Data Quality in Databricks — Expectations, Event Logs and Historical DQ Monitoring Part 4: One Rule, Three Platforms — A Business Data Quality Rule in Fabric, dbt and Databricks Part 5: Data Quality Cockpit in Qlik and Power BI — From Metrics to Remediation