Power BI richtig modellieren: Sternschema, Beziehungen und DAX

Ein Umsatzbericht lässt sich in Power BI schnell erstellen. Ob seine Ergebnisse auch unter unterschiedlichen Filtern stimmen, entscheidet sich jedoch meist vor dem ersten Diagramm: im Datenmodell. Wenn Kundenmerkmale, Produktdaten und Buchungen ungeordnet in einer einzigen Tabelle stehen, werden Auswertungen unnötig kompliziert. Ein sauberes Star Schema schafft dagegen die Grundlage für verständliche Beziehungen, zuverlässige Measures und nachvollziehbare Zeitvergleiche.

Vom Excel-Export zum Datenmodell

Der Einstieg beginnt häufig mit einem Excel-Export: Jede Zeile enthält eine Rechnungsposition, ergänzt um Kundenname, Kundengruppe, Artikelbezeichnung und Warengruppe. Für eine erste Umsatzsumme genügt das oft.

Eine flache Tabelle ist nicht grundsätzlich falsch. Probleme entstehen vor allem, wenn unterschiedliche fachliche Ebenen vermischt werden. Steht beispielsweise der Rechnungsendbetrag in jeder Rechnungsposition, wird er beim Summieren mehrfach berücksichtigt. Enthält eine Tabelle zusätzlich Monatsbudgets, wiederholen sich diese möglicherweise für jede einzelne Buchung.

Weitere Schwierigkeiten zeigen sich später:

Kunden- und Produktmerkmale werden auf jeder Umsatzzeile wiederholt.
Unterschiedliche Schreibweisen erzeugen scheinbar verschiedene Kunden oder Warengruppen.
Kunden ohne Umsatz fehlen vollständig.
Weitere Fact Tables, etwa für Budget oder Bestand, lassen sich nicht sauber über gemeinsame Merkmale filtern.

Entscheidend ist deshalb zuerst die Frage: Was repräsentiert genau eine Zeile? Diese Granularität müssen Sie festlegen, bevor Sie Tabellen verbinden oder Measures schreiben.

Sternschema aufbauen: Fakten und Dimensionen trennen

In einem Star Schema steht eine Fact Table mit Geschäftsvorfällen im Mittelpunkt. Dimensionstabellen beschreiben, nach welchen Merkmalen Sie diese Vorgänge auswerten.

Für ein einfaches Umsatzmodell reichen zunächst vier Tabellen:

Tabelle	Inhalt	Granularität
Umsatz	Buchungsdatum, Kundenschlüssel, Produktschlüssel, Menge, Umsatzbetrag, Kostenbetrag	Eine gebuchte Rechnungsposition
Kunde	Kundenschlüssel, Kundenname, Kundengruppe, Region	Ein Datensatz je Kunde
Produkt	Produktschlüssel, Artikelnummer, Bezeichnung, Warengruppe	Ein Datensatz je Produkt
Datum	Datum, Jahr, Monat und weitere Kalenderattribute	Ein Datensatz je Kalendertag

Die Fact Table enthält die Schlüssel der Dimensionen sowie die benötigten Kennzahlen. Beschreibende Merkmale gehören überwiegend in die Dimensionen. Im Bericht verwenden Sie beispielsweise die Warengruppe aus Produkt und den Umsatz aus einem Measure.

Bereiten Sie diese Struktur möglichst bereits in der Datenquelle oder in Power Query auf. Entfernen Sie Dubletten in Dimensionen nicht blind: Zwei Datensätze mit gleichem Kundenschlüssel und unterschiedlichen Regionen erfordern zunächst eine fachliche Klärung.

Auch historische Änderungen brauchen eine Entscheidung. Soll die heutige Kundengruppe für alle Umsätze gelten, genügt häufig eine aktuelle Kundendimension. Soll die damalige Zuordnung erhalten bleiben, benötigen Sie eine entsprechend historisierte Dimension und passende Schlüssel in den Fakten.

Beziehungen richtig setzen

Zwischen einer Dimension und der Fact Table besteht normalerweise eine 1:n-Beziehung: Ein Kunde kann viele Umsatzpositionen haben, jede Umsatzposition verweist aber auf genau einen Kundendatensatz.

Dabei müssen Sie zwei Eigenschaften unterscheiden:

Kardinalität: Wie viele Zeilen können auf beiden Seiten denselben Schlüssel besitzen?
Filterrichtung: In welche Richtung wird ein Filter über die Beziehung weitergegeben?

Im üblichen Star Schema stehen die Dimensionen auf der 1-Seite. Die Filterrichtung verläuft einfach von der Dimension zur Fact Table. Wählen Sie eine Kundengruppe aus, filtert diese Auswahl die zugehörigen Kunden und darüber die Umsatzpositionen.

Die Schlüssel der 1-Seite müssen eindeutig sein. Verwenden Sie dafür stabile technische oder fachlich eindeutige Schlüssel, nicht Kundennamen. Prüfen Sie außerdem, ob jeder Fremdschlüssel der Fact Table einen passenden Dimensionseintrag besitzt. Fehlende Zuordnungen können unter einem leeren Dimensionseintrag erscheinen und Abstimmungen erschweren.

Bidirektionale Filter nicht als Reparatur verwenden

Bidirektionale Beziehungen wirken zunächst praktisch: Plötzlich beeinflussen sich mehrere Slicer gegenseitig. In größeren Modellen können dadurch jedoch mehrdeutige Filterpfade und schwer erklärbare Ergebnisse entstehen.

Verwenden Sie bidirektionale Filter deshalb nur mit einem konkreten fachlichen Grund. Eine unerwartet angebotene n:m-Beziehung ist ebenfalls kein Anlass, sie einfach zu bestätigen. Oft zeigt sie, dass ein vermeintlicher Dimensionsschlüssel nicht eindeutig ist.

Mehrere Datumsbezüge benötigen besondere Aufmerksamkeit. Buchungsdatum und Lieferdatum können dieselbe Datumstabelle verwenden; zwischen diesen beiden Tabellen kann jedoch nur eine Beziehung aktiv sein. Die andere lässt sich bei Bedarf gezielt mit USERELATIONSHIP in einem Measure nutzen.

Datumstabelle einrichten

Zeitvergleiche benötigen eine verlässliche Kalenderstruktur. Datumswerte ausschließlich aus der Fact Table reichen dafür nicht: Tage ohne Buchungen fehlen, und Kalendermerkmale sind nicht zentral definiert.

Eine klassische Datumstabelle enthält jeden Kalendertag genau einmal, ohne Lücken oder Leerwerte, und deckt die benötigten vollständigen Jahre ab. Für ein einfaches Modell mit nicht leerer Umsatzquelle können Sie sie so anlegen:

Datum =
VAR ErstesJahr =
    YEAR ( MIN ( 'Umsatz'[Buchungsdatum] ) )
VAR LetztesJahr =
    YEAR ( MAX ( 'Umsatz'[Buchungsdatum] ) )
RETURN
    ADDCOLUMNS (
        CALENDAR (
            DATE ( ErstesJahr, 1, 1 ),
            DATE ( LetztesJahr, 12, 31 )
        ),
        "Jahr", YEAR ( [Date] ),
        "Monat", FORMAT ( [Date], "MMM", "de-DE" ),
        "Monatsnummer", MONTH ( [Date] ),
        "JahrMonat", FORMAT ( [Date], "yyyy-MM" )
    )

Markieren Sie die Tabelle für die hier verwendete klassische Zeitintelligenz als Datumstabelle und wählen Sie Datum[Date] als Datumsspalte. Sortieren Sie Monat nach Monatsnummer. Für eine jahresübergreifende Monatsachse verwenden Sie JahrMonat statt des Monatsnamens allein.

Die aktive Beziehung verbindet Datum[Date] mit Umsatz[Buchungsdatum]. Enthält das Buchungsdatum zusätzlich Uhrzeiten, erzeugen Sie vorher eine reine Datumsspalte. Gleiche angezeigte Tage bedeuten sonst nicht zwangsläufig gleiche Schlüsselwerte.

Ein Vorjahresvergleich lässt sich anschließend auf einem Basis-Measure aufbauen:

Umsatz =
SUM ( 'Umsatz'[Umsatzbetrag] )

Umsatz Vorjahr =
CALCULATE (
    [Umsatz],
    SAMEPERIODLASTYEAR ( 'Datum'[Date] )
)

Verwenden Sie für Achsen und Zeitfilter die Datumstabelle. Beachten Sie außerdem: Ein laufender Monat ist ohne weitere Einschränkung nicht automatisch mit demselben bereits verstrichenen Zeitraum des Vorjahres vergleichbar.

Berechnete Spalten oder Measures?

Die wichtigste Entscheidungshilfe lautet: Benötigen Sie ein Merkmal pro Zeile oder eine Kennzahl im aktuellen Filterkontext?

Berechnete Spalten eignen sich beispielsweise für Kategorien, Sortierattribute oder zeilenweise Klassifizierungen. In Importmodellen werden ihre Werte gespeichert und bei der Aktualisierung neu berechnet. Sie reagieren nicht dynamisch auf die Slicerauswahl. Solche Aufbereitungen sind häufig bereits in der Datenquelle oder in Power Query besser aufgehoben.

Measures werden dagegen bei der Abfrage im jeweiligen Filterkontext ausgewertet. Sie sind die richtige Wahl für Umsatz, Deckungsbeitrag und Quoten:

Deckungsbeitrag =
[Umsatz] - SUM ( 'Umsatz'[Kostenbetrag] )

Deckungsbeitragsquote =
DIVIDE ( [Deckungsbeitrag], [Umsatz] )

Die Quote wird damit auch in der Gesamtsumme aus Gesamtdeckungsbeitrag und Gesamtumsatz berechnet. Ein einfacher Durchschnitt der einzelnen Positionsquoten wäre fachlich etwas anderes.

Liegt kein fertiger Umsatzbetrag vor, können Sie zeilenweise multiplizieren:

Umsatz aus Positionen =
SUMX (
    'Umsatz',
    'Umsatz'[Menge] * 'Umsatz'[Einzelpreis]
)

Das gilt hier unter der Annahme, dass Rabatte und weitere Erlöskorrekturen nicht berücksichtigt werden müssen. Das Produkt aus summierter Menge und summiertem Einzelpreis wäre dagegen keine korrekte Umsatzberechnung.

Typische Fehler und ihre Ursachen

Doppelte Summen entstehen häufig vor DAX. Wird eine Umsatzposition in Power Query mit mehreren passenden Zuordnungszeilen zusammengeführt, vervielfachen sich die Faktzeilen. Kontrollieren Sie nach solchen Zusammenführungen Zeilenzahl und Kontrollsummen. DISTINCT ist dafür keine pauschale Reparatur: Identische Beträge können legitime unterschiedliche Geschäftsvorfälle sein.

Ein Filter wirkt nicht wie erwartet. Prüfen Sie zuerst die verwendete Spalte, die aktive Beziehung und die Filterrichtung. Eine Kundengruppe aus einer unverbundenen Hilfstabelle filtert die Umsatzdaten nicht automatisch.

Die Gesamtsumme entspricht nicht der Summe sichtbarer Zeilen. Measures werden auch in der Gesamtzeile neu ausgewertet. Bei Quoten oder eindeutigen Kundenanzahlen ist das meist richtig. Ein Kunde, der zwei Produkte kauft, wird insgesamt einmal gezählt, nicht zweimal. Nur wenn die Fachlogik ausdrücklich eine Addition der dargestellten Gruppenwerte verlangt, ist eine entsprechende Iteration sinnvoll.

Praxis-Check: Das Umsatzmodell systematisch prüfen

Prüfen Sie Ihr Modell vor der Gestaltung des Berichts:

Granularität festhalten: Was bedeutet eine Zeile der Fact Table?
Schlüssel prüfen: Sind Dimensionsschlüssel eindeutig und Fremdschlüssel vollständig zugeordnet?
Beziehungen kontrollieren: Stimmen Kardinalität, aktive Beziehung und Filterrichtung?
Kalender prüfen: Sind alle benötigten Tage vorhanden und Zeitstempel bereinigt?
Basiswerte abstimmen: Entsprechen Umsatz und Positionszahl der Quelle?
Filter testen: Stimmen einzelne Kunden, Produkte und Monate?
Gesamtergebnisse erklären: Sind Quoten, Zählungen und Zeitvergleiche fachlich korrekt?

Nutzen Sie dafür zunächst einfache Tabellenvisuals. Sie machen Fehler schneller sichtbar als ein aufwendig gestaltetes Dashboard.

Fazit

Ein belastbares Power-BI-Modell beginnt mit klarer Granularität, getrennten Fakten und Dimensionen sowie eindeutigen Beziehungen. Eine zentrale Datumstabelle und bewusst eingesetzte Measures halten die Auswertungslogik nachvollziehbar.

Wenn Ergebnisse nicht stimmen, prüfen Sie zuerst Datenstruktur und Filterwege. Komplexerer DAX ist selten die beste Antwort auf ein unsauberes Modell.

Sie möchten tiefer einsteigen? In unseren Schulungen vermitteln wir SQL Server, Power BI und KI praxisnah – online oder bei Ihnen vor Ort. Fragen? Kontaktieren Sie uns oder buchen Sie ein kostenloses Info-Gespräch.