Power BI Consulting – Datenmodelle, DAX und Governance aus einer Hand

Positionierung

Power BI hat die Art, wie Unternehmen ihre Daten auswerten und präsentieren, tiefgreifend verändert. Was früher monatelange BI-Projekte mit starren Berichtswerkzeugen und eigenem IT-Aufwand erforderte, lässt sich heute in Power BI schnell und visuell aufbauen. Diese Zugänglichkeit ist eine der größten Stärken des Werkzeugs – und zugleich die Quelle seiner häufigsten Probleme. Wer Power BI nur als Drag-and-drop-Visualisierungstool betrachtet, baut Berichte, die im Kleinen funktionieren und im Großen versagen: langsam, inkonsistent, schwer zu pflegen und anfällig für Fehler im Filterkontext.

Mein Schwerpunkt liegt deshalb nicht auf dem visuellen Endprodukt, sondern auf dem Fundament, das darunter liegt. Ein Power-BI-Modell, das sauber aufgebaut ist – mit einem Sternschema als Grundlage, wohldefinierten Measures, einem verlässlichen Sicherheitskonzept und einem klaren Governance-Rahmen –, liefert nicht nur heute korrekte Zahlen, sondern bleibt auch dann wartbar und erweiterbar, wenn neue Anforderungen hinzukommen oder das Team wechselt. Genau dieses Fundament zu legen, ist der Kern meiner Arbeit mit Power BI.

Meine Power-BI-Erfahrung wurzelt in jahrelanger Arbeit mit SSAS Tabular und DAX, lange bevor Power BI Desktop in seiner heutigen Form existierte. Die Engine hinter Power BI – das tabulare Modell und die DAX-Formelsprache – ist dieselbe wie hinter SSAS Tabular. Wer diese Grundlagen wirklich versteht, denkt nicht in Berichtselementen, sondern in Datenmodellen, in Beziehungen, in Filterkontexten und in der Auswertungsreihenfolge von Measures. Dieses Verständnis unterscheidet einen nachhaltigen Power-BI-Aufbau von einer Sammlung von Workarounds.

In meinen Projekten habe ich Power BI in sehr unterschiedlichen Kontexten eingesetzt: für Clearing-Prozesse im Loyaltybereich mit komplexen RLS-Regeln und DSGVO-konformer Anonymisierung, für Reports und Apps in einem Textil- und Servicedienstleister mit HR-, Finance- und Controlling-Daten, und für SSAS-Tabular-Modelle in Engineering- und Beratungsprojekten mit anspruchsvollen DAX-Berechnungen. Diese Breite hilft: Muster, die sich in einem Kontext bewährt haben, lassen sich auf neue Anforderungen übertragen.

Was gutes Power BI ausmacht

Power BI ist mehr als ein Visualisierungswerkzeug. Hinter jedem Bericht steckt ein semantisches Modell – ein tabulares Datenmodell, das Tabellen, Beziehungen, Measures und Sicherheitsregeln vereint. Wer dieses Modell als Herzstück versteht und nicht als nachrangiges Detail, baut Power-BI-Lösungen, die skalieren, verlässliche Ergebnisse liefern und von anderen gepflegt werden können. Wer es ignoriert, sammelt Berichte an, die immer langsamer werden, immer schwerer zu verstehen sind und bei jeder neuen Anforderung mehr Aufwand verursachen.

Semantisches Modell als Fundament

Das semantische Modell – früher als Power-BI-Dataset bezeichnet, heute offiziell Semantic Model genannt – ist die zentrale Wissensbasis. Hier leben die Tabellen und ihre Beziehungen, hier werden Measures definiert, die den Fachbegriff 'Umsatz' verbindlich festlegen, und hier wird festgelegt, wer welche Daten sehen darf. Ein sauber gepflegtes semantisches Modell entkoppelt die fachliche Logik von einzelnen Berichten: Jeder Report, der das Modell verwendet, bekommt dieselben korrekten Zahlen – ohne dass jeder Report seine eigene Umsatzberechnung mitbringt.

Sternschema als Designprinzip

Das Datenmodell folgt idealerweise einem Sternschema: eine oder mehrere Faktentabellen im Zentrum, umgeben von Dimensionstabellen, die die Analysedimensionen beschreiben. Dieses Muster ist nicht nur performant, weil die VertiPaq-Engine es besonders effizient komprimiert und auswertet, sondern auch verständlich: Jeder, der das Modell liest, erkennt sofort, welche Tabellen Messgrößen enthalten und welche den Kontext liefern. Ein normalisiertes Schneeflockenschema, das direkt aus einer relationalen Datenbank übernommen wird, ist selten eine gute Idee – es erschwert das Schreiben von DAX erheblich.

DAX als Präzisionsinstrument

DAX, die Formelsprache von Power BI und SSAS Tabular, ist mächtig und subtil. Sie folgt einer eigenen Logik rund um den Filterkontext: Welche Zeilen sind sichtbar, wenn ein Measure ausgewertet wird? Wer DAX intuitiv schreibt, bekommt gelegentlich die richtige Antwort – und häufiger eine falsch erscheinende, weil der Filterkontext sich anders verhält als erwartet. Wer DAX versteht, schreibt Measures, die in jedem visuellen Kontext korrekt sind, die performant sind und die von anderen gelesen werden können.

• Semantisches Modell als verbindliche Wissensquelle für alle Reports
• Sternschema: Faktentabellen im Zentrum, Dimensionen als Kontext
• DAX-Measures für alle fachlichen Kennzahlen – einmal, korrekt, nachvollziehbar
• Row-Level-Security für datengetriebene Zugriffskontrolle
• Wahl des Speichermodus (Import/DirectQuery/Composite) nach Anforderung
• Governance über Apps, Workspaces und Deployment-Pipelines

Governance schließt die Lücke

Ein technisch hervorragendes Modell nützt wenig, wenn es niemand findet, wenn jeder Fachbereich sein eigenes Gegenstück baut oder wenn nach einem halben Jahr niemand mehr weiß, wie die RLS-Regeln zu warten sind. Governance in Power BI bedeutet: klare Workspace-Strukturen, eine definierte Lebensrolle für zertifizierte vs. persönliche Berichte, Deployment-Pipelines, die Änderungen von Entwicklung über Test bis Produktion sicher transportieren, und eine nachvollziehbare Dokumentation der Modellstruktur und der Sicherheitsregeln. Erst diese Rahmenbedingungen machen aus einzelnen Berichten eine konsistente, gepflegte BI-Landschaft.

Was alle diese Bausteine verbindet, ist ein Ende-zu-Ende-Verständnis: von der Quelldatenstruktur über das Datenmodell bis zum sichtbaren Bericht. Wer nur den Report kennt, optimiert am falschen Ende. Wer Modell, DAX und Governance zusammendenkt, baut eine Lösung, die nicht nur heute funktioniert, sondern auch in einem Jahr noch trägt.

Vom Rohdatum zum Bericht

Der Weg von einer Quelltabelle bis zu einem verlässlichen Dashboard in Power BI ist kein einzelner Schritt, sondern eine Kette klar getrennter Stufen. Jede Stufe hat eine definierte Verantwortung, und Probleme in einer frühen Stufe pflanzen sich unerbittlich durch alle folgenden fort. Ein typisches Power-BI-Projekt durchläuft diese Phasen: Datenintegration und Transformation, Datenmodellierung, Measure-Entwicklung, Sicherheitskonzept, Report-Entwicklung und schließlich Deployment und Betrieb.

In der ersten Phase, der Datenintegration, werden die Quellen angebunden und die Daten in eine für Power BI geeignete Form gebracht. Das geschieht entweder über Power Query (M) direkt im Power BI Desktop oder – bei größeren Projekten – über eine vorgelagerte ETL-Schicht in SQL Server, Azure Data Factory oder einem vergleichbaren Werkzeug. Ich bevorzuge für produktive, belastbare Systeme eine externe Aufbereitungsschicht: Die Quelldaten werden bereinigt, denormalisiert und als einfaches Sternschema bereitgestellt. Power Query ist dann kein Transformationswerkzeug mehr, sondern nur noch ein dünner Ladevorgang.

Der Weg von Rohdaten über Datenintegration, Modellierung und Measure-Entwicklung bis zum veröffentlichten Report in einem Power-BI-Workspace mit Deployment-Pipeline.

In der Modellierungsphase entsteht das semantische Modell: Faktentabellen und Dimensionen werden geladen, Beziehungen gezogen, Datumstabellen angelegt und die ersten Basismeasures definiert. Diese Phase ist die wichtigste und die am häufigsten unterschätzte: Was hier sauber gemacht wird, trägt das gesamte Projekt. Was hier schief geht – falsche Beziehungsrichtungen, fehlende Datumstabellen, normalisierte Dimensionen –, erzeugt Folgefehler in DAX und in der Performance, die sich später nur schwer korrigieren lassen.

Erst nach der Modellierung folgt die Report-Entwicklung. Visuelles und narratives Design stehen im Dienst der fachlichen Aussage: Ein guter Bericht führt den Leser, ohne ihn zu überfordern. Er zeigt die richtige Kennzahl im richtigen Kontext und macht Abweichungen sofort sichtbar. Deployment-Pipelines transportieren den fertigen Bericht von der Entwicklungsumgebung über Test bis Produktion, ohne manuelle Eingriffe und ohne das Risiko, dass versehentlich ein unfertiger Stand veröffentlicht wird.

Sternschema im Datenmodell

Das tabulare Modell hinter Power BI ist eine hochoptimierte In-Memory-Engine, die VertiPaq heißt. Diese Engine komprimiert Spaltendaten und kann Millionen von Zeilen in Millisekunden aggregieren – aber nur dann, wenn das Modell so aufgebaut ist, dass VertiPaq seine Stärken ausspielen kann. Das Sternschema ist das Designprinzip, das genau das ermöglicht.

Faktentabelle und Dimensionen

Die Faktentabelle enthält die Messgrößen – Umsatz, Menge, Kosten, Buchungsbeträge – und die Fremdschlüssel zu den Dimensionstabellen. Sie ist typischerweise schmal (wenige Spalten) und lang (viele Zeilen). Die Dimensionstabellen beschreiben den Kontext: Zeit, Produkt, Kunde, Region, Kostenstelle. Sie sind breit (viele Attribute) und vergleichsweise kurz. Die Beziehungen zwischen Fakten und Dimensionen sind Eins-zu-Viele-Beziehungen, in denen die Dimension die Eins-Seite bildet. DAX-Filter propagieren in dieser Richtung natürlich, ohne dass Hilfsformeln nötig wären.

Datumstabelle ist Pflicht

Eine explizite Datumstabelle ist kein optionales Extra, sondern Voraussetzung für korrekte Zeitintelligenz in DAX. Power BI kann eine automatische Datumstabelle generieren, aber diese erzeugt versteckte Tabellen, macht das Modell schwerer verständlich und führt zu unerwarteten Ergebnissen bei DAX-Zeitfunktionen. Ich lege Datumstabellen immer explizit an – entweder in der Datenquelle, in Power Query oder als berechnete Tabelle – und markiere sie als Datumstabelle, damit DAX die Zeitintelligenzfunktionen korrekt nutzen kann. Die Datumstabelle umfasst alle benötigten Attribute: Jahr, Quartal, Monat, Woche, Wochentag, Geschäftsjahr und ggf. Feiertage.

Normalisierung und Denormalisierung im richtigen Maß

Die Quelldatenbank ist oft stark normalisiert – das ist gut für eine transaktionale Datenbank, aber problematisch für ein Analysemodell. Im Power-BI-Modell sollten Dimensionstabellen flach und denormalisiert sein. Eine Produktdimension mit Produktname, Kategorie, Unterkategorie und Marke als eigene Spalten ist besser als drei normalisierte Tabellen, die über Fremdschlüssel verbunden sind. Das Flachmachen dieser Hierarchien geschieht idealerweise in der ETL-Schicht oder in Power Query – nicht über berechnete Spalten im Modell, die die VertiPaq-Komprimierung belasten.

• Faktentabellen schmal halten: nur Kennzahlen und Fremdschlüssel
• Dimensionstabellen flach denormalisieren – kein Schneeflockenschema
• Explizite Datumstabelle, als Datumstabelle markiert
• Beziehungsrichtung: Dimension filtert Faktentabelle (1:n)
• Surrogatschlüssel als Integer-Typ für schnellen Join
• Keine berechneten Spalten für Felder, die in der Quelle bereits vorhanden sind

Berechnete Spalten versus Measures

Eine häufige Verwechslung ist der Einsatz berechneter Spalten dort, wo Measures besser passen. Berechnete Spalten werden bei jedem Datenaktualisierungsvorgang materialisiert, belegen Arbeitsspeicher und verhindern eine optimale Komprimierung durch VertiPaq. Measures hingegen werden nur dann berechnet, wenn ein Visual sie anfordert, und das immer im aktuellen Filterkontext. Als Regel gilt: Alles, was einen Zeilenwert beschreibt (z. B. eine kategorisierende Spalte), kann eine berechnete Spalte sein. Alles, was eine Aggregation darstellt (Summe, Durchschnitt, Zählung), gehört in ein Measure.

Der Aufbau eines sauberen Sternschemas zahlt sich mehrfach aus: Die Modellgröße sinkt, weil VertiPaq gleichmäßige Spalten mit niedrigem Kardinalitätswert besonders gut komprimiert. Die Abfrageperformance steigt, weil Beziehungen direkt über Integer-Schlüssel aufgelöst werden. Und die DAX-Entwicklung wird einfacher, weil der Filterfluss im Sternschema intuitiv und vorhersehbar ist – ein Filter auf der Produktdimension filtert automatisch alle Faktentabellen, die über eine Beziehung angebunden sind, ohne explizite USERELATIONSHIP-Aufrufe in jedem Measure.

DAX-Measures sauber bauen

DAX ist die Formelsprache von Power BI, SSAS Tabular und Power Pivot. Sie ist ausdrucksstark, präzise und subtil. Das Herzstück von DAX ist der Filterkontext: die Menge der Zeilen, die in jeder Tabelle sichtbar ist, wenn ein Measure ausgewertet wird. Dieser Filterkontext wird von Slicern, Zeilen- und Spaltenfeldern in Matrix-Visuals, Kreuzfilterung zwischen Visuals und expliziten DAX-Funktionen wie CALCULATE gesteuert. Wer diesen Mechanismus versteht, schreibt korrekte Measures. Wer ihn ignoriert, schreibt Measures, die manchmal die richtige Antwort geben – und manchmal eine schwer erklärbare falsche.

CALCULATE als Schlüssel zum Filterkontext

CALCULATE ist die zentrale Funktion in DAX. Sie wertet einen Ausdruck in einem modifizierten Filterkontext aus: Sie kann Filter hinzufügen, bestehende Filter entfernen oder ersetzen. Beinahe jedes nichttriviale Measure verwendet CALCULATE, oft mehrfach verschachtelt. Das Verständnis der Auswertungsreihenfolge – zürst werden die Filtermodifikatoren verarbeitet, dann der Filterkontext übergeben, schließlich der innere Ausdruck bewertet – ist der Schlüssel zu korrekten Zeitvergleichen, Anteilen, Rankings und kumulierten Werten.

-- Umsatz seit Jahresbeginn (Year-to-Date)
-- TOTALYTD erwartet eine als Datumstabelle markierte Tabelle.
Umsatz YTD :=
TOTALYTD(
    [Umsatz],          -- Basismeasure
    Datum[Datum]       -- Datumsspalte der markierten Datumstabelle
)

-- Gleichwertiges Measure ohne TOTALYTD, mit explizitem CALCULATE:
Umsatz YTD v2 :=
CALCULATE(
    [Umsatz],
    DATESYTD( Datum[Datum] )   -- Filtert auf alle Tage seit Jahresbeginn
)

Beide Varianten liefern dasselbe Ergebnis. Die CALCULATE-Variante ist flexibler, etwa wenn das Geschäftsjahr nicht am 1. Januar beginnt: DATESYTD(Datum[Datum],"30-06") verwendet den 30. Juni als Jahresende.

CALCULATE für Vorperioden und Zeitvergleiche

Zeitvergleiche – Vorjahreswert, rollierender 12-Monats-Durchschnitt, Monatsvergleich – gehören zu den häufigsten Anforderungen in Dashboards. In DAX werden sie durch Zeitintelligenzfunktionen wie SAMEPERIODLASTYEAR, PREVIOUSYEAR, DATEADD oder PARALLELPERIOD realisiert. Diese Funktionen funktionieren korrekt nur, wenn eine ordnungsgemäß markierte Datumstabelle vorhanden ist und wenn der Filterkontext durch CALCULATE korrekt manipuliert wird.

-- Umsatz derselben Periode im Vorjahr
Umsatz VJ :=
CALCULATE(
    [Umsatz],
    SAMEPERIODLASTYEAR( Datum[Datum] )
)

-- Abweichung zum Vorjahr in Prozent
Umsatz vs VJ % :=
VAR vUmsatz    = [Umsatz]
VAR vUmsatzVJ  = [Umsatz VJ]
RETURN
    IF(
        NOT ISBLANK( vUmsatzVJ ) && vUmsatzVJ <> 0,
        DIVIDE( vUmsatz - vUmsatzVJ, ABS( vUmsatzVJ ) ),
        BLANK()
    )

VAR/RETURN verbessert die Lesbarkeit und verhindert mehrfache Auswertung desselben Ausdrucks. DIVIDE vermeidet einen Divisionsfehler bei Vorjahreswert = 0 und gibt BLANK() statt eines Fehlers zurück.

Measures mit VAR/RETURN sauber strukturieren

Komplexe Measures mit mehreren Zwischenergebnissen werden mit VAR/RETURN strukturiert. Das verbessert die Lesbarkeit erheblich, verhindert mehrfache Auswertung desselben Teilausdrucks und erleichtert das Debuggen. Variablen in DAX werden einmalig im aktuellen Filterkontext ausgewertet und eingefroren – ein wichtiger Unterschied zu einer Funktion, die bei jeder Verwendung neu ausgewertet würde.

-- Deckungsbeitrag und prozentualer Anteil am Gesamtumsatz
-- Zeigt den Anteil der aktuellen Auswahl am ungefilterten Gesamtumsatz.
Deckungsbeitrag % Gesamt :=
VAR vDB          = [Deckungsbeitrag]
VAR vDBGesamt    = CALCULATE(
                       [Deckungsbeitrag],
                       ALL( Produkt )     -- entfernt jeden Filter auf der Produktdimension
                   )
VAR vAnteil      = DIVIDE( vDB, vDBGesamt )
RETURN
    IF(
        NOT ISBLANK( vDB ),
        vAnteil,
        BLANK()
    )

ALL() entfernt den Produktfilter und berechnet den Gesamtdeckungsbeitrag ohne Einschränkung auf die aktuell ausgewählten Produkte. Der Anteil zeigt, welchen Teil des Ganzen die aktuelle Auswahl ausmacht.

Ein weiteres häufiges Muster ist die Verwendung von RANKX für Rankings, von TOPN für die Top-N-Analyse und von SELECTEDVALUE bzw. HASONEVALUE für parametrisierte Measures, die sich an die Wahl im Slicer anpassen. Diese Bausteine lassen sich kombinieren, um dynamische Berichte zu bauen, die sich ohne Codeänderungen an unterschiedliche Analyseperspektiven anpassen.

Row-Level-Security

Row-Level-Security (RLS) steuert in Power BI, welche Zeilen einer Tabelle ein Benutzer sehen darf. Sie ist der Mechanismus, um ein einziges Modell und einen einzigen Bericht für Benutzer mit unterschiedlichen Datenzugriffsbefugnissen zu nutzen – ohne separate Berichte je Region, Kostenstelle oder Hierarchieebene bauen zu müssen. RLS wird im semantischen Modell definiert, nicht im Report, und greift auf allen Ebenen: in Visuals, in Measures und in exportierten Daten.

Statische und dynamische RLS

Statische RLS-Regeln sind fest codierte Filter: Eine Rolle 'Nord' filtert die Regionstabelle auf [Region] = 'Nord'. Das ist einfach zu implementieren, aber schlecht skalierbar: Für jede neue Region braucht man eine neue Rolle. Dynamische RLS löst das eleganter: Eine einzige Rolle verwendet DAX-Ausdrücke, die auf die Identität des angemeldeten Benutzers zugreifen – über USERNAME() oder USERPRINCIPALNAME() – und diese gegen eine Berechtigungstabelle prüfen, die im Modell selbst oder in einer separaten Tabelle hinterlegt ist.

-- Rollenfilter auf der Regionstabelle.
-- Der Benutzer sieht nur Regionen, fuer die sein UPN in der Berechtigungstabelle steht.
-- Schritt 1: Rollenfilter-Ausdruck (wird als DAX-Ausdruck in der Rolle hinterlegt)

[Region] IN
    CALCULATETABLE(
        VALUES( Berechtigung[Region] ),           -- alle erlaubten Regionen des Benutzers
        Berechtigung[UPN] = USERPRINCIPALNAME()   -- gefiltert auf den aktuellen Benutzer
    )

USERPRINCIPALNAME() liefert die E-Mail-Adresse des angemeldeten Benutzers. Die Berechtigungstabelle ordnet UPNs den erlaubten Regionen zu. Neue Benutzer werden durch einen Eintrag in der Berechtigungstabelle berechtigt, ohne dass die Rolle geändert werden muss.

Hierarchische RLS

In Projekten mit Vertriebshierarchien, Kostenstellen oder Organisationsstrukturen reicht eine flache Berechtigungstabelle oft nicht aus. Ein Regionalleiter soll alle Filialen seiner Region sehen, ein Filialleiter nur seine eigene. Hierarchische RLS löst das über eine PATH-basierte Berechtigungsstruktur oder über eine flache Hilfstabelle, die für jeden Benutzer alle sichtbaren Hierarchieknoten auflistet. Diese Hilfstabelle wird in der ETL-Schicht vorab aufgelöst und ins Modell geladen.

Eine wichtige Regel: RLS-DAX-Ausdrücke sollten so einfach wie möglich sein und auf möglichst kleinen Tabellen operieren. Komplexe Ausdrücke, die über mehrere Tabellen navigieren, können die Abfrageperformance spürbar belasten, weil sie bei jeder Abfrage neu ausgewertet werden. Eine vorberechnete Berechtigungstabelle mit flachen Benutzer-Schlüssel-Paaren ist in der Praxis fast immer die performantere und wartbarere Lösung als ein komplexer DAX-Ausdruck zur Laufzeit.

RLS testen und dokumentieren

RLS sollte systematisch getestet werden: Mit dem 'Als Rolle anzeigen'-Feature in Power BI Desktop lässt sich der Bericht aus der Perspektive einer Rolle oder eines bestimmten Benutzers betrachten. Wichtig ist, dass Measures, die Gesamtzahlen berechnen – etwa Marktanteile oder Rankings –, korrekt mit der RLS interagieren. Ein Measure, das ALL() verwendet, um den Gesamtumsatz zu berechnen, kann unter RLS das falsche Ergebnis liefern, wenn ALL() den RLS-Filter aufhebt. ALLSELECTED() oder KEEPFILTERS() sind in solchen Fällen die richtigen Werkzeuge.

Speichermodi: Import, DirectQuery, Composite

Power BI bietet drei grundlegende Speichermodi, die bestimmen, wo und wie Daten für Abfragen bereitgestellt werden. Die Wahl des richtigen Modus ist eine der wichtigsten Architekturentscheidungen für ein Power-BI-Modell – sie beeinflusst Performance, Aktualität, Modellgröße und die Komplexität der DAX-Entwicklung.

Vergleich der drei Speichermodi in Power BI: Import hält Daten im Arbeitsspeicher, DirectQuery fragt die Quelle bei jeder Abfrage ab, Composite kombiniert beide Ansätze.

Import-Modus: Höchste Performance

Im Import-Modus werden die Daten vollständig in das semantische Modell geladen und dort von der VertiPaq-Engine im Arbeitsspeicher gehalten. Abfragen gehen nicht mehr an die Quelle, sondern werden direkt im Modell beantwortet. Das Ergebnis ist eine außergewöhnlich hohe Abfrageperformance, auch bei Millionen von Zeilen, und volle DAX-Unterstützung. Der Preis: Daten sind nur so aktuell wie der letzte Aktualisierungsvorgang, und die Modellgröße ist durch den verfügbaren Arbeitsspeicher begrenzt.

DirectQuery-Modus: Immer aktuelle Daten

Im DirectQuery-Modus werden Abfragen in Echtzeit an die Quelldatenbank weitergeleitet. Jede Interaktion mit einem Visual erzeugt SQL- oder native Abfragen, die unmittelbar ausgeführt werden. Das garantiert immer aktuelle Daten ohne Aktualisierungsvorgänge – ideal für operative Berichte, bei denen Aktualität kritisch ist. Der Nachteil: Die Performance hängt vollständig von der Quelldatenbank ab, viele DAX-Funktionen sind eingeschränkt oder nicht verfügbar, und berechnete Tabellen und Spalten aus DAX sind nicht möglich.

Composite-Modus: Das Beste aus beiden Welten

Der Composite-Modus erlaubt es, Tabellen unterschiedlich zu behandeln: Dimensionstabellen werden im Import-Modus gehalten (klein, selten geändert, ideal für schnelle Filter), während große Faktentabellen im DirectQuery-Modus verbleiben (immer aktuell, keine Größenbeschränkung). Die Abfrageperformance verbessert sich gegenüber reinem DirectQuery erheblich, weil Dimensionsfilter im Modell aufgelöst werden und nur die gefilterten Faktenanfragen an die Quelle gehen. Aggregationstabellen im Import-Modus können Abfragen auf Faktentabellen vollständig im Modell beantworten, wenn die gewünschte Granularität vorhanden ist.

• Import: Maximale Performance, volle DAX-Unterstützung, Daten per Aktualisierung
• DirectQuery: Immer aktuelle Daten, keine Modellgröße, eingeschränkte DAX-Funktionen
• Composite: Dimensionen im Import, Fakten per DirectQuery, Aggregationstabellen als Optimierung
• Dual-Modus: Tabellen, die je nach Abfragekontext import- oder direktabfragebasiert genutzt werden
• Aggregationstabellen im Import decken häufige Granularitätsstufen ab und beschleunigen DirectQuery

In der Praxis ist der Import-Modus für die meisten analytischen Workloads die erste Wahl: Performance und DAX-Flexibilität sind unübertroffen. DirectQuery eignet sich, wenn Aktualität im Minutentakt nötig ist oder wenn Datenmengen die Modellgröße sprengen würden. Der Composite-Modus ist die Antwort auf Anforderungen, die keiner der beiden reinen Modi allein erfüllen kann – er erfordert aber ein tiefes Verständnis des Filterfluss-Mechanismus, um keine Performance-Fallen zu bauen.

Performance und Modelloptimierung

Ein langsames Power-BI-Modell frustiert Nutzer und untergräbt das Vertrauen in die Daten. Performance-Probleme entstehen auf drei Ebenen: im Datenmodell selbst, in den DAX-Measures und in der Report-Schicht. Alle drei Ebenen müssen im Blick behalten werden, denn ein Engpass auf einer Ebene lässt sich durch Optimierungen auf den anderen nicht vollständig kompensieren.

Performance beginnt im Modell

Die VertiPaq-Engine komprimiert Spalten einzeln, basierend auf ihrer Kardinalität: Eine Spalte mit 10 verschiedenen Werten komprimiert besser als eine mit 10 Millionen. Deshalb sind hohe Kardinalitätsspalten – Zeitstempel mit Sekundenauflösung, freie Texte, GUIDs als Schlüssel – die typischen Modellschwergewichte. Lösungen: Zeitstempel auf Tagesebene reduzieren, wenn Sekundenauflösung nicht benötigt wird. Integer-Surrogatschlüssel statt GUIDs verwenden. Freie Texte aus der Faktentabelle in Dimensionen auslagern.

Unnötige Spalten und Zeilen entfernen

Das sinnvollste Performance-Werkzeug in Power BI ist die Delete-Taste. Jede Spalte, die nicht in einem Report verwendet wird, belegt Arbeitsspeicher und verlangsamt den Aktualisierungsvorgang. Power Query sollte so konfiguriert werden, dass nur die Spalten geladen werden, die das Modell tatsächlich braucht. Veraltete Daten, die nie abgefragt werden, sollten über Filterzeilen in Power Query ausgeschlossen werden. Inkrementelle Aktualisierung reduziert die Menge der Daten, die bei jeder Aktualisierung verarbeitet werden müssen.

DAX-Performance mit dem Performance Analyzer messen

Der Performance Analyzer in Power BI Desktop zeigt für jedes Visual, wie lange die DAX-Abfrage, die Rendering-Zeit und die Datenbankabfrage dauern. Teure Measures lassen sich mit dem DAX Studio External Tool weiter untersuchen: Server-Timings zeigen, wie viel Zeit in der Storage Engine und wie viel im Formula Engine verbracht wird. Abfragen, die hauptsächlich in der Formula Engine laufen, sind oft ein Zeichen für Iteratorfunktionen (SUMX, AVERAGEX, FILTER), die über große Tabellen iterieren und optimiert werden sollten.

• Hohe Kardinalitätsspalten identifizieren und reduzieren (z. B. Zeitstempel -> Datum)
• Nicht benötigte Spalten in Power Query entfernen, bevor sie ins Modell gelangen
• Inkrementelle Aktualisierung für große Faktentabellen konfigurieren
• Integer-Surrogatschlüssel statt GUIDs oder zusammengesetzter Schlüssel
• DAX-Iteratoren (SUMX, FILTER) auf große Tabellen vermeiden oder durch Aggregationen ersetzen
• Performance Analyzer und DAX Studio für systematische Ursachenanalyse nutzen

Ein besonderes Augenmerk gilt bidirektionalen Beziehungen. Power BI erlaubt es, Beziehungen in beide Richtungen filtern zu lassen – ein Feature, das verlockend ist und Performance-Fallen öffnet. Bidirektionale Beziehungen können unbeabsichtigte Filterinteraktionen erzeugen, das Modell schwerer verständlich machen und die Performance bei komplexen Abfragen erheblich verschlechtern. Die Regel lautet: Bidirektionale Beziehungen nur dort einsetzen, wo sie wirklich notwendig sind, und den DAX-Alternativansatz über CROSSFILTER kennen.

Apps, Workspaces und Deployment-Pipelines

Power BI ist kein isoliertes Werkzeug, sondern Teil eines Ökosystems. Wer mehrere Berichte, mehrere Fachbereiche und mehrere Entwicklungsstufen managen muss, braucht eine durchdachte Governance: Workspaces, die klar nach Zweck strukturiert sind, Apps als Auslieferungskanal an Endnutzer, Deployment-Pipelines, die Änderungen sicher von Entwicklung nach Produktion transportieren, und eine Zertifizierungsstrategie, die unterscheidet zwischen verifizierten Unternehmens-Datasets und persönlichen Analysen.

Workspace-Strukturierung

Workspaces in Power BI sind Container für Semantic Models, Reports und Dashboards. Eine bewährte Struktur trennt nach Funktion und Umgebung: ein Workspace für die Entwicklung, einer für den Test und einer für die Produktion. Zusätzlich kann nach Fachbereich oder Domäne getrennt werden. Berechtigungen werden auf Workspace-Ebene vergeben: Wer darf Reports bearbeiten, wer nur anzeigen, wer das Semantic Model bearbeiten? Diese Trennung verhindert, dass versehentliche Änderungen in die Produktion gelangen.

Apps als Auslieferungskanal

Power-BI-Apps sind kuratierte Sammlungen von Reports und Dashboards, die an eine definierte Nutzergruppe ausgeliefert werden. Im Gegensatz zu einem direkten Workspace-Zugang sehen App-Nutzer nur genau das, was die App enthält – keine Entwurfsversionen, keine internen Arbeitsdateien. Apps lassen sich mit Berechtigungen und einer Navigationsstruktur versehen, die den Nutzern hilft, den richtigen Bericht zu finden. Die App trennt die Auslieferungsperspektive (was sollen Nutzer sehen?) von der Arbeitsperspektive (wie wird entwickelt?).

Deployment-Pipelines

Deployment-Pipelines in Power BI ermöglichen einen strukturierten Übergang von Reports und Semantic Models von einer Umgebung zur nächsten. Änderungen werden im Entwicklungs-Workspace vorgenommen, dort getestet und dann über die Pipeline in die Test- und schließlich Produktionsumgebung übernommen. Regeln für automatische Parameterersetzung – etwa unterschiedliche Datenbankverbindungen je Umgebung – werden in der Pipeline konfiguriert. Das Ergebnis: keine manuellen Downloads und Uploads, keine vergessenen Verbindungszeichenfolgen, kein versehentliches Überschreiben von Produktionsinhalten.

Zertifizierung und Endorsement

Power BI unterscheidet zwischen 'Gefördert' (Promoted) und 'Zertifiziert' (Certified) für Semantic Models und Reports. Geförderte Inhalte signalisieren: 'Dieser Inhalt ist gut genug für den breiten Einsatz.' Zertifizierte Inhalte sind das höchste Vertrauenslevel: Sie wurden von einer designierten Stelle auf Korrektheit und Qualität geprüft. Diese Kennzeichnung hilft Nutzern, sich im Self-Service-BI-Dschungel zurechtzufinden – und unterscheidet verlässliche Unternehmens-Datasets von persönlichen Analyseexperimenten.

• Workspace-Trennung nach Umgebung (Dev/Test/Prod) und ggf. nach Fachbereich
• Apps für die Auslieferung an Endnutzer – keine direkte Workspace-Freigabe
• Deployment-Pipelines für kontrollierte Übergänge zwischen Umgebungen
• Zertifizierung für unternehmensweite, geprüfte Semantic Models
• Datenfluss-Konzept: Shared Semantic Models als zentrale Quelle für mehrere Reports
• Lineage-Ansicht in Power BI Service für Nachvollziehbarkeit der Datenflüsse

In Projekten, in denen ich Power-BI-Governance aufgebaut habe, waren die häufigsten Schmerzen nicht technischer, sondern organisatorischer Natur: Jeder Fachbereich baute sein eigenes Semantic Model, jedes Modell hatte eine eigene Umsatzdefinition, und niemand wusste, welcher der 'offizielle' Bericht war. Das Gegenmittel ist ein bewusstes Governance-Konzept: wer darf zertifizierte Modelle anlegen, welche Datasets sind Unternehmens-Standard, wie werden Änderungen kommuniziert und getestet, bevor sie produktiv gehen.

Vorgehen in der Zusammenarbeit

Jedes Power-BI-Projekt beginnt mit Verständnis, nicht mit Technologie. Bevor ich ein Datenmodell anlege oder ein Measure schreibe, verschaffe ich mir ein klares Bild der fachlichen Fragen, die beantwortet werden sollen, der Quelldatenstrukturen, die zur Verfügung stehen, der Nutzer, die die Berichte verwenden werden, und der Einschränkungen, die aus IT-Sicherheit, DSGVO oder vorhandener BI-Infrastruktur folgen.

• Fachliche Analyse: Kennzahlen, Dimensionen, Berechtigungskonzept und Aktualitätsanforderung klären
• Datenquellen: Datenqualität, Quelldatenstrukturen und geeigneten Integrationspfad bewerten
• Modelldesign: Sternschema entwerfen, Datumstabelle planen, Speichermodus wählen
• DAX-Entwicklung: Basismeasures definieren, Zeitintelligenz aufbauen, RLS implementieren
• Report-Entwicklung: Visuals, Layouts und Navigation nach fachlichem Bedarf gestalten
• Deployment und Governance: Workspace-Struktur, Apps, Deployment-Pipelines, Dokumentation

Ich arbeite remote, hybrid und vor Ort, je nach Projektbedarf. In vielen Projekten bin ich in ein bestehendes Team eingebettet und bringe spezifische Expertise mit, die im Team nicht vorhanden ist – tiefes DAX-Wissen, Erfahrung mit SSAS Tabular, Performance-Diagnose oder RLS-Konzeption. In anderen Projekten verantworte ich das gesamte Power-BI-Thema von der Datenmodellierung bis zur Governance.

Ein wichtiger Aspekt meiner Arbeit ist die Dokumentation. Ein semantisches Modell, das nur sein Erbauer versteht, ist ein Risiko für das Unternehmen. Ich dokumentiere das Modell, die Measures, das RLS-Konzept und die Governance-Entscheidungen so, dass ein nachfolgendes Team das Modell eigenständig warten und erweitern kann. Dazu gehören beschreibende Measure-Kommentare, ein Glossar der fachlichen Begriffe und eine Dokumentation der Datenquellen und Transformationsschritte.

Typische Leistungen rund um Power BI

Je nach Projektphase und Bedarf übernehme ich unterschiedliche Aufgaben rund um Power BI – vom ersten Architekturworkshop bis zur fertigen, produktiv betriebenen BI-Lösung.

• Konzeption und Aufbau semantischer Modelle (Sternschema, Datumstabellen, Beziehungen)
• DAX-Entwicklung: Basismeasures, Zeitintelligenz, Filterkontext, VAR/RETURN
• Row-Level-Security: dynamische RLS über Berechtigungstabellen, hierarchische Berechtigungen
• Wahl und Konfiguration des Speichermodus (Import, DirectQuery, Composite)
• Performance-Analyse und Modelloptimierung mit Performance Analyzer und DAX Studio
• Apps, Workspace-Governance und Deployment-Pipelines in Power BI Service
• Power-Query-Transformationen (M) und Anbindung von Datenquellen
• Integration mit Azure-Datenplattformen: Synapse, Azure SQL, Databricks
• SSAS-Tabular-Modelle als Basis für Power BI (Analysis Services Live Connection)
• Schulung und Knowledge Transfer für interne Power-BI-Teams

In der Praxis bedeutet das häufig: Ich übernehme ein bestehendes Power-BI-Modell, das gewachsen und schwer wartbar geworden ist, und bringe es in einen strukturierten, nachvollziehbaren Zustand. Das umfasst das Bereinigen unnötiger berechneter Spalten, das Zusammenführen redundanter Measures, das Neuaufbauen des Datumstabellenkonzepts, die Implementierung einer validen RLS und die Einführung einer Workspace-Governance. Dieses 'Aufräumen' eines bestehenden Modells ist oft schneller und wertvoller als ein Neubau von Grund auf.

Neben der rein technischen Arbeit gehört die Abstimmung mit Fachbereichen und IT zu meinem Vorgehen. Kennzahlen sind nur dann verlässlich, wenn der Fachbereich der Definition zustimmt. RLS-Regeln sind nur dann korrekt, wenn der Berechtigungsbedarf wirklich verstanden wurde. Deployment-Entscheidungen setzen voraus, dass die IT-Governance-Richtlinien bekannt sind. All das erfordert Kommunikation über technische Grenzen hinaus – und eine Arbeitsweise, die sowohl technische als auch fachliche Gesprächspartner abholt.

Ergänzend zur Power-BI-Arbeit kann ich die vorgelagerten Strecken mitabdecken: Data Warehouses in SQL Server oder Azure, ETL-Prozesse mit SSIS oder Azure Data Factory, SSAS-Tabular-Modelle und Staging-Schichten. Wer das gesamte Bild kennt, entwirft die Power-BI-Schicht passend zur Datenbasis – und sieht frühzeitig, wo ein Problem seinen eigentlichen Ursprung hat.

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zum Power BI Consulting