Kurz gesagt: Laden Sie nur, was Sie wirklich brauchen – und tippen Sie Ihre Daten sauber an. So legen Sie die Basis für Performance und Stabilität.
So gehen Sie vor:
Quellen anbinden (SQL, Excel/CSV, APIs) und „Transform Data“ öffnen.
Nur benötigte Spalten auswählen (statt alles zu laden).
Frühe Filter setzen (z. B. nur letzte 24–36 Monate).
Datentypen sofort korrekt definieren (Datum, Ganzzahl, Dezimal, Text).
Parameter für Server/Schema/Pfade anlegen – erleichtert Dev/Test/Prod-Wechsel.
Abfrageabhängigkeiten prüfen und Staging-Abfragen klar benennen (z. B. stg_Customer).
Tipps
Nutzen Sie „Spalten auswählen“ statt „Andere entfernen“, damit neue Quellspalten nicht heimlich ins Modell rutschen.
Achten Sie auf Query Folding: Transformationen bevorzugen, die die Quelle ausführen kann (schneller, skalierbarer).
Einheitliche Datumslogik (UTC vs. Lokalzeit) festlegen – spätestens hier entscheiden!
Legen Sie eine kleine Validierungsabfrage mit ein paar Stichprobenzeilen an, um früh Format- und Wertefehler zu entdecken.
Häufige Fehler:
Alles laden „für alle Fälle“ → großes PBIX, träge Berichte.
Datentypen erst am Schluss setzen → unklare Aggregation und DAX-Probleme.
Staging- und Modellierungslogik in einer Abfrage mischen → schwer zu testen und zu warten.
2) Struktur bereinigen – Schlüssel, Duplikate, Merges/Appends, Dimensionen vs. Fakten
Ziel ist eine robuste, normalisierte Struktur: eindeutige Schlüssel, keine Duplikate und eine klare Trennung in Dimensionstabellen (Stammdaten) und Faktentabellen (Transaktionen).
So gehen Sie vor:
Primär- und Fremdschlüssel identifizieren (z. B. Customer_ID, Product_ID).
Duplikate entfernen und Datenvalidität prüfen (z. B. Anti‑Join für fehlende Referenzen).
Tabellen kombinieren: Merge/Join (Left/Inner/Anti) und Append (Union).
Breite Kreuztabellen ggf. unpivoten (Monate von Spalten → Zeilen).
Dimensionen (Stammdaten) und Fakten (Bewegungen) klar trennen.
Tipps
Surrogate Keys (kompakte Ganzzahlen) in Fakten beschleunigen Beziehungen und sparen Speicher.
Left‑Anti‑Join als Datenqualitäts‑Werkzeug nutzen: Was matcht nicht? Warum?
Einheitliche Spaltennamen (…_ID, …_Name) helfen DAX und Lesbarkeit.
Häufige Fehler:
Unentdeckte Dubletten im Schlüssel → Beziehungsfehler im Modell.
Viele‑zu‑viele‑Joins als „Quickfix“ → unerklärliche Summen im Bericht.
Dimensionen/Fakten vermischen → unüberschaubare Modelle.
3) Modell bauen (Modellansicht) – Sternschema, 1:n, einseitige Filter, Datumstabelle
In der Modellansicht verbinden Sie die Tabellen logisch. Ein Sternschema (Dimension → Fakt) mit einseitiger Filterrichtung macht Verhalten vorhersagbar und Berichte schnell. Eine vollständige Datumstabelle ist Pflicht für Time‑Intelligence.
So gehen Sie vor:
Dimensionen (z. B. DimCustomer, DimProduct, DimDate) und Fakten (z. B. FactSales) anlegen.
Beziehungen definieren: Dimension (1) → Fakt (n), Filterrichtung: einseitig (single).
Datumstabelle erstellen (ohne Lücken) und als Datumstabelle markieren.
Rollen‑Datumstabellen bei Bedarf (Bestell‑ vs. Lieferdatum) mit USERELATIONSHIP in Measures aktivieren.
Nicht benötigte Spalten/Tabellen ausblenden – nur wirklich nutzbare Felder sichtbar lassen.
Tipps
Bidirektionale Filter nur wo zwingend nötig – sonst bleibt single‑direction robuster.
„Sort by Column“ nutzen (Monatsname → Monat‑Nr.), damit Achsen logisch sortieren.
RLS früh denken: Filter über Dimensionen modellieren, nicht ad‑hoc in Visuals.
Praxis‑Beispiel (Customer ↔ Sales)
Dimension: DimCustomer(Customer_ID, Segment, Signup_Date, …)
Fakt: FactSales(Order_ID, Customer_ID, Order_Date, Net_Revenue, Channel, …)
Beziehung: DimCustomer[Customer_ID] → FactSales[Customer_ID] (1:n, single)
Häufige Fehler:
Viele‑zu‑viele‑Beziehungen normalisieren statt kompensieren.
Fehlende Datumstabelle → Time‑Intelligence (YTD/YoY) funktioniert nicht zuverlässig.
Zu viele sichtbare Felder → unruhige, schwer bedienbare Berichte.
4) Kennzahlen definieren (DAX) – nur Measures, Time‑Intelligence, Kontext beachten
Kennzahlen gehören als Measures ins Modell – nicht als berechnete Spalten. Nutzen Sie VAR, CALCULATE und Time‑Intelligence (z. B. DATESYTD, DATEADD), um robuste und verständliche Formeln zu erstellen.
So gehen Sie vor:
Eigene Measure‑Tabelle (z. B. _Measures) für Ordnung anlegen.
Namenskonventionen definieren (z. B. Sales, Sales YTD, Δ Sales YoY %).
VAR für Zwischenergebnisse verwenden – besser lesbar & performanter.
DIVIDE statt „/“ einsetzen, um Division‑durch‑Null sauber zu handhaben.
Time‑Intelligence‑Funktionen auf Basis der Datumstabelle verwenden.
Tipps
Eine Validierungsseite anlegen (Karten, Tabellen mit Stichproben) – jede neue Measure kurz gegenprüfen.
Zeilen‑ vs. Filterkontext verstehen: CALCULATE ändert den Filterkontext.
Iteratoren (SUMX) nur wenn nötig – Spaltenaggregate (SUM/AVERAGE) sind meist schneller.
Einheitliche Formatierung (Währung, %, Dezimalstellen) sparsam und konsistent einsetzen.
Mini‑Beispiel (Measures)
Sales := SUM(FactSales[Net_Revenue])
Sales YTD := CALCULATE([Sales], DATESYTD(DimDate[Date]))
Sales YoY := CALCULATE([Sales], DATEADD(DimDate[Date], -1, YEAR))
Δ Sales YoY % := DIVIDE([Sales] – [Sales YoY], [Sales YoY])
Häufige Fehler
Aggregationen als berechnete Spalten statt als Measures → unflexibel und speicherhungrig.
Komplexe FILTER‑Kaskaden ohne Performance‑Blick → langsame Visuals.
Fehlende Schutzlogik gegen Division‑durch‑Null → unsaubere Darstellungen.
5) Bericht gestalten (Berichtsansicht) – Slicer, KPIs, Tooltips; Performance prüfen
Die Berichtsansicht ist Ihr Arbeitsbereich für Visualisierung, Interaktion und schnelle Checks. Fokussieren Sie sich auf Klarheit und Geschwindigkeit – Stakeholder sollen Antworten in Sekunden finden.
So gehen Sie vor:
Layout mit Raster (Ansicht → Rasterlinien) und z. B. 12‑Spalten‑Grid planen.
Start mit 2–3 KPI‑Karten (Umsatz, Marge, #Kunden) für Sofort‑Orientierung.
Trend (Linie) und Struktur (Balken/Matrix) ergänzen; Slicer sparsam einsetzen.
Tooltip‑Seite für Kontextinfos (z. B. Top‑3‑Produkte) anlegen.
Performance Analyzer nutzen; langsame Visuals identifizieren und vereinfachen.
Tipps
Corporate Theme (JSON) verwenden – konsistente Farben/Typografie ohne Fummelei.
„Interaktionen bearbeiten“: Nur sinnvolle Kreuzfilter zulassen.
Bedingte Formatierung gezielt für Abweichungen (z. B. Rot/Grün) einsetzen.
Beschriftungen prägnant halten, Einheiten konsistent (k, Mio., %).
Nützliche Praxis‑Setups
Validierungsseite: KPI‑Karten (Gesamtumsatz, #Bestellungen, #Kunden) • Top‑10‑Kunden (Balken) • Stichprobentabelle • Slicer (Jahr/Region/Produkt).
Management‑Seite: KPI (Umsatz MTD/YTD, Δ vs. Plan) • Liniendiagramm (YTD) • Matrix (Region×Monat, bedingte Formatierung) • Tooltip‑Seite mit Top‑3‑Produkten.
Häufige Fehler
Zu viele Visuals pro Seite → kognitive Überladung.
Slicer‑Inflation → unklare Filterlogik.
Keine Validierungsseite → Fehler bleiben länger unentdeckt.
Wenn Sie diese fünf Schritte konsequent umsetzen, entsteht aus heterogenen Rohdaten ein wartbares, performantes Power‑BI‑System: früh reduzieren, sauber modellieren, Kennzahlen diszipliniert pflegen und Visuals mit Bedacht wählen. So liefern Ihre Dashboards verlässlich Antworten – im Alltag und unter Last.
