Datenqualität in Power BI prüfen: Regeln als DAX-Abfragen

Weil ein Bericht jede Zahl zeigt, die das Modell ihm liefert, auch eine falsche. Ein Data & AI Berater übernimmt für ein Team ein Power-BI-Modell. Ein Data Warehouse gibt es nicht. Die Daten kommen als Export aus drei Quellsystemen. Power Query bereitet sie auf, das Modell lädt sie.

Das Team traut den Zahlen nicht mehr. In einer Besprechung fragt jemand, warum die Summe der Aufträge nicht zur Summe je Kunde passt. Niemand kann es sagen. Der Fehler liegt nicht im Measure. Er liegt in Zeilen, die keinem Kunden zugeordnet sind.

Der Berater sucht deshalb nicht im Bericht. Er prüft die Daten dort, wo der Bericht sie liest: im geladenen Semantikmodell. Dafür schreibt er jede Erwartung des Teams als Regel auf und lässt sie zählen. Am Ende des ersten Laufs steht im Beispiel ein Score von 86 von 100.

Die Tabelle zeigt, was Teams im Bericht sehen und was dahinter steckt. Jede Zeile führt zu einem Regeltyp. Welche Typen es gibt, zeigt der Abschnitt Acht Regeltypen.

Power BI prüft an drei Stellen selbst, aber keine davon misst gegen einen Zielwert. Der Berater geht sie mit dem Team durch, bevor er etwas Neues baut.

Die erste Stelle ist Power Query. Die Spaltenqualität zeigt je Spalte, wie viele Werte gültig, fehlerhaft oder leer sind. In der Voreinstellung rechnet sie auf den ersten 1.000 Zeilen. Wer die ganze Tabelle sehen will, stellt die Profilerstellung auf das gesamte Dataset um. Das Ergebnis bleibt ein Bild im Editor und wird nirgends gespeichert.

Die zweite Stelle ist die Aktualisierung. Lädt sie doppelte Werte in die Spalte auf der Eins-Seite einer Beziehung, schlägt sie fehl. Das schützt Schlüssel, die in einer Beziehung stehen. Für alle anderen Spalten gilt es nicht.

Die dritte Stelle ist die Beziehung selbst. Sie erzwingt keine Integrität. Findet ein Auftrag keinen Kunden, ergänzt Power BI in der Kundentabelle eine leere Zeile. Im Bericht steht dann „(Leer)“. Der Auftrag zählt mit, nur zu keinem Kunden.

Der Best Practice Analyzer in Tabular Editor gehört nicht in diese Reihe. Er prüft das Modell: Namen, Beziehungen, Beschreibungen. Zeilen sieht er nicht. Wie man ein Modell gegen einen Regelsatz prüft, zeigt Power BI Dokumentation und Regelprüfung. Die Tabelle unter der Kurzantwort stellt die Stellen gegenüber. Ihre Angaben folgen der Dokumentation der Hersteller, Stand November 2026.

Eine Regel ist ein Satz mit Zielwert, die Abfrage ist derselbe Satz in DAX. Der Berater schreibt die Regeln nicht in den Code. Sie stehen in einer Datei, dem Regelkatalog. Wer eine Regel ändern will, ändert dort eine Zeile.

Je Regel hält der Katalog sechs Angaben fest, die Tabelle nennt sie. Ein Skript liest den Katalog und baut aus jedem Eintrag eine Abfrage. Die Abfrage beginnt mit EVALUATE und gibt eine Zeile zurück. Darin stehen zwei Zählwerte: geprüfte Zeilen und verletzte Zeilen. Mehr braucht die Rechnung nicht.

Vor dem Lauf prüft das Skript den Katalog selbst. Es liest die Spalten des Modells mit INFO.VIEW.COLUMNS und vergleicht sie mit den Regeln. Nennt eine Regel eine Spalte, die es nicht gibt, läuft sie nicht. Sie steht im Ergebnis als Fehler und nicht als bestanden.

Das Beispiel am Ende des Abschnitts zeigt die Regel „Jeder Auftrag nennt einen Kunden“ als Abfrage. Wer sie von Hand ausprobieren will, fügt sie in die DAX-Abfrageansicht von Power BI Desktop ein.

Acht Typen decken fast alles ab, was ein Fachbereich über seine Daten sagen kann. Sieben sind Muster: Der Berater trägt nur Tabelle, Spalte und Grenzen ein. Der achte ist eine frei geschriebene Abfrage für alles, was in kein Muster passt.

Die Typen folgen den Dimensionen. Aktualität fragt nach dem jüngsten Datum. Vollständigkeit fragt nach gefüllten Feldern. Plausibilität fragt nach möglichen Werten. Eindeutigkeit und Konsistenz fragen nach Schlüsseln und Gegenstücken.

Ein Detail entscheidet über die Vollständigkeit: was als leer gilt. Ein Feld mit einem Leerzeichen ist für DAX nicht leer, für den Fachbereich schon. Dasselbe gilt für Platzhalter wie „unbekannt“ oder „n/a“. Der Katalog führt deshalb eine Liste solcher Werte. Die Abfrage zählt sie wie ein leeres Feld.

Jede Regel kann ihre Zählwerte nach einer Spalte aufteilen, zum Beispiel nach der Auftragsart. Dann zeigt das Ergebnis, wo die Verstöße liegen. Oft steckt der ganze Fehler in einer einzigen Gruppe.

Über dieselbe Engine, die auch der Bericht fragt. Öffnet jemand eine Datei in Power BI Desktop, startet im Hintergrund eine Instanz von Analysis Services und lädt das Modell. Sie bekommt einen zufällig vergebenen Port. Ein Skript, das diesen Port kennt, stellt DAX-Abfragen und liest die Antwort.

Für die erste Messung reicht das. Der Berater öffnet den Bericht, aktualisiert die Daten und startet den Lauf. Der Lauf dauert Sekunden und sendet nur Abfragen. Am Modell ändert er nichts.

Wichtig ist, welchen Stand das Skript sieht. Es sieht, was im Modell geladen ist. Ohne Aktualisierung ist das der Stand des letzten Speicherns. Nach einer Aktualisierung sind es die frischen Daten aus der Quelle. Der Berater schreibt deshalb zu jedem Lauf dazu, wann das Modell zuletzt geladen wurde.

Für ein veröffentlichtes Modell gibt es weitere Wege. Die Tabelle nennt, was jeder braucht und wo er endet. Für eine einzelne Abfrage von Hand genügt die DAX-Abfrageansicht.

In drei Schritten, und jeder lässt sich von Hand nachrechnen. Erstens der erfüllte Anteil: eins minus verletzt durch geprüft. Zweitens der Score der Regel: der erfüllte Anteil geteilt durch den Zielwert, höchstens 100. Drittens das Mittel, erst über die Regeln einer Dimension, dann über die Dimensionen. Wichtige Regeln tragen dabei ein höheres Gewicht.

Im Beispiel prüft die Regel 4.000 Aufträge, 200 nennen keinen Kunden. Erfüllt sind 95,0 %. Das Ziel liegt bei 98 %. Der Score der Regel ist 95,0 geteilt durch 98, also 96,9 von 100. Dieselbe Rechenregel beschreibt Datenqualität messen für ein Warehouse.

Zum Score gehört ein Status. Er sagt, wie weit die Regel vom Ziel entfernt ist. Das Beispiel liegt drei Prozentpunkte unter dem Ziel und ist damit knapp verfehlt. Erst ab zehn Prozentpunkten Abstand gilt eine Regel als verfehlt.

Zwei Zahlen stehen immer neben dem Gesamtscore. Die erste sagt, auf wie vielen Regeln er beruht. Die zweite sagt, wie viele Zielwerte noch Vorschläge sind. Solange der Fachbereich sie nicht bestätigt hat, vergleicht der Score zwei Läufe miteinander. Ein Urteil über die Daten ist er dann noch nicht.

Jeder Lauf schreibt einen Ordner mit Zeitstempel. Darin liegen das Ergebnis je Regel, dieselben Zählwerte je Gruppe, die Liste der betroffenen Sätze und eine Zusammenfassung. Dazu kommt eine Zeile im Verlauf. Die Tabelle nennt, wer was liest.

Die Liste der betroffenen Sätze ist der Teil, mit dem jemand arbeiten kann. Sie nennt je Verstoß die Kennung des Objekts, das Feld und den Wert. Damit geht der Fehler an die Stelle, die ihn beheben kann: ins Quellsystem. Wer zuständig ist und was zuerst behoben wird, regelt das Datenqualitätsmanagement.

Diese Liste ist auch die einzige Datei mit einzelnen Datensätzen. Alle anderen enthalten nur Zählwerte. Der Berater hält sie deshalb getrennt. Sie bleibt beim Team und kommt in kein Repository.

Der Verlauf macht aus einzelnen Läufen eine Linie. Ein Bericht in Power BI kann den Ordner lesen und zeigt dann immer den jüngsten Lauf. So steht die Datenqualität neben den Zahlen, die sie betrifft. Was auf die erste Seite eines solchen Berichts gehört, zeigt Data Observability.

Ein Agent, der Fragen auf dem Modell beantwortet, erbt jeden Fehler in den Daten. Fragt jemand nach dem Umsatz je Kunde, fehlen in der Antwort die Aufträge ohne Kunden. Die Antwort klingt trotzdem sicher. Die Lücke nennt er nur, wenn er von ihr weiß.

Das Ergebnis des Laufs gibt ihm dieses Wissen. Es ist eine kleine Datei mit Regel, Status und Zählwerten. Liest der Agent sie vor der Antwort, kann er sagen: Die Zahl gilt für 95 % der Aufträge, 200 haben keinen Kunden.

Auch beim Aufbau des Katalogs hilft ein Agent. Er liest die Struktur des Modells und schlägt Regeln vor: ein Pflichtfeld für jeden Schlüssel, eine Abdeckung für jede Beziehung. Die DAX-Abfrage dazu schreibt er ebenfalls. Den Zielwert bestätigt ein Mensch.

Geprüft wird fest. Die Abfrage liefert bei gleichem Datenstand immer dieselben Zählwerte. Ein Sprachmodell darf erklären und vorschlagen. Entscheiden soll es nicht. Sonst weiß niemand, ob sich die Daten geändert haben oder nur das Urteil.

Der Lauf zeigt, ob die geladenen Daten die vereinbarten Regeln einhalten. Ob eine Regel fachlich richtig ist, klärt weiter der Fachbereich. Sechs Grenzen sollte ein Team kennen, bevor es sich auf den Score verlässt.

• Der Lauf sieht nur geladene Tabellen. Zwischenschritte in Power Query, die nicht ins Modell laden, erreicht keine DAX-Abfrage. Regeln dafür bleiben als „nicht prüfbar“ im Katalog.
• Er sieht den Stand der letzten Aktualisierung. Ohne Aktualisierung prüft er alte Daten. Deshalb gehört der Zeitpunkt des Ladens zu jedem Ergebnis.
• Das geöffnete Modell ist kein Betrieb. Für einen Lauf nach Zeitplan braucht es das veröffentlichte Modell. Der Weg führt über XMLA, REST oder ein Notebook in Fabric, je nach Lizenz (Stand November 2026).
• Plausibel ist nicht richtig. Ein Wert im erlaubten Bereich kann falsch sein. Die Regel findet das Unmögliche, nicht das Falsche.
• Der Lauf prüft Daten, nicht das Modell. Ob ein Measure richtig rechnet oder eine Beziehung falsch gesetzt ist, zeigt er nicht. Dafür gibt es die Regelprüfung des Modells.
• Die Prüfung ist ein Skript, keine Funktion von ABIS. ABIS liest das Modell als Graph aus Tabellen, Spalten und Measures. Zeilen prüft es nicht.