Power BI-Datenmodellierung: Star-Schema-Design für Business Intelligence

Das Datenmodell ist die Grundlage jedes Power BI-Berichts. Ein gut gestaltetes Modell macht DAX-Messungen einfach, die Abfrageleistung schnell und die Berichtsentwicklung intuitiv. Ein schlecht entworfenes Modell macht alles schwierig – Maßnahmen erfordern komplizierte Problemumgehungen, Abfragen werden langsam ausgeführt und Entwickler verbringen mehr Zeit damit, das Modell zu bekämpfen, als Erkenntnisse zu gewinnen.

Das Sternschema ist seit Jahrzehnten der Goldstandard für analytische Datenmodelle. Die relationalen Datenbanken, die Ihre ERP- und CRM-Systeme antreiben, sind auf Transaktionseffizienz ausgelegt und nutzen normalisierte Schemata mit Dutzenden miteinander verbundenen Tabellen. Dieses Design eignet sich optimal für die Aufzeichnung einzelner Transaktionen, ist jedoch für Aggregation, Vergleich und Trendanalyse schlecht geeignet. Das Star-Schema restrukturiert dieselben Daten für die analytische Leistung, indem es sie in Faktentabellen (was passiert ist) und Dimensionstabellen (den Kontext rund um das, was passiert ist) unterteilt.

Dieser Leitfaden behandelt Star-Schema-Designprinzipien speziell für Power BI, einschließlich der Erstellung von Fakten- und Dimensionstabellen, der Konfiguration von Beziehungen, dem Schreiben effizienter DAX-Kennzahlen, der Nutzung von Berechnungsgruppen, der Implementierung von Zeitintelligenz und der Verwendung zusammengesetzter Modelle zur Verbindung mit mehreren Datenquellen.

Wichtige Erkenntnisse

– Das Sternschema trennt Daten in Faktentabellen (numerische Maße, Fremdschlüssel) und Dimensionstabellen (beschreibende Attribute) – diese Struktur ist für die VertiPaq-Engine von Power BI optimiert – Jede Beziehung in einem Power BI-Modell sollte von der Dimension zum Fakt fließen (eins-zu-viele), mit Kreuzfilterung nur in eine Richtung

• DAX-Kennzahlen schneiden bei Sternschemata deutlich besser ab, da VertiPaq Dimensionsspalten effizient komprimieren und Fakten durch Beziehungen filtern kann – Berechnungsgruppen ersetzen Dutzende redundanter Kennzahlen (YTD, QTD, MTD, Vorjahr) durch ein einziges Muster, das auf alle Basiskennzahlen angewendet wird – Zeitintelligenz erfordert eine dedizierte Datumsdimensionstabelle – verwenden Sie niemals automatische Datums-/Uhrzeitangaben und verlassen Sie sich nicht auf Datumsspalten in Faktentabellen – Mit zusammengesetzten Modellen können Sie importierte Daten mit DirectQuery-Verbindungen kombinieren und so die Leistung von In-Memory mit der Aktualität von Live-Abfragen erhalten – Rollenspieldimensionen (eine Tabelle wird in mehreren Beziehungsrollen verwendet) erfordern die USERELATIONSHIP-Funktion von DAX

---

Grundlagen des Star-Schemas

Warum Star Schema für Power BI

Die In-Memory-Engine von Power BI, VertiPaq, verwendet spaltenorientierte Komprimierung zum Speichern von Daten. Jede Spalte wird unabhängig voneinander komprimiert, und Spalten mit geringer Kardinalität (wenige eindeutige Werte) werden dramatisch komprimiert – eine „Land“-Spalte mit 40 eindeutigen Werten über 10 Millionen Zeilen wird auf fast nichts komprimiert. Spalten mit hoher Kardinalität (viele eindeutige Werte) wie Transaktions-IDs oder Zeitstempel lassen sich schlecht komprimieren.

Das Star-Schema nutzt dies aus, indem es Transaktionsdaten mit hoher Kardinalität (Daten, Beträge, Mengen) in schmalen Faktentabellen isoliert und beschreibende Daten mit niedriger Kardinalität (Namen, Kategorien, Regionen) in separaten Dimensionstabellen platziert. Das Ergebnis ist ein Datenmodell, das sowohl weniger Speicher benötigt als auch schneller abzufragen ist.

Bedenken Sie den Unterschied. Eine denormalisierte flache Tabelle für ein Einzelhandelsunternehmen könnte 50 Spalten haben: OrderDate, CustomerName, CustomerEmail, CustomerCity, CustomerCountry, CustomerSegment, ProductName, ProductCategory, ProductSubcategory, Brand, Supplier, SupplierCountry, Quantity, UnitPrice, Discount, TotalAmount und so weiter. In jeder Zeile wird „USA“ tausende Male, „Elektronik“ hunderte Male und der vollständige Kundenname für jede Bestellung wiederholt, die der Kunde jemals aufgegeben hat.

Das Sternschema-Äquivalent unterteilt dies in:

FactSales (schmal, eine Zeile pro Bestellzeile): OrderDateKey, CustomerKey, ProductKey, Quantity, UnitPrice, Discount, TotalAmount.

DimCustomer: CustomerKey, CustomerName, E-Mail, Stadt, Land, Segment.

DimProduct: ProductKey, ProductName, Kategorie, Unterkategorie, Marke.

DimDate: DateKey, Datum, Jahr, Quartal, Monat, MonthName, DayOfWeek.

Die Faktentabelle hat nur 7 statt 50 Spalten. Jede Dimensionstabelle speichert jeden eindeutigen Wert genau einmal. VertiPaq komprimiert diese Struktur 3–5x besser als die flache Tabelle und Abfragen werden 2–10x schneller ausgeführt, da die Engine kleine Dimensionstabellen filtert und dann nur die übereinstimmenden Zeilen in der Faktentabelle auflöst.

Faktentabellen: Designprinzipien

Faktentabellen zeichnen Geschäftsereignisse auf – Verkäufe, Bestellungen, Lieferungen, Support-Tickets, Webbesuche, Fertigungsläufe. Jede Zeile stellt ein Ereignis oder eine Einzelposition eines Ereignisses dar.

Körnungsdefinition. Die Körnung ist der Detaillierungsgrad in der Faktentabelle. Definieren Sie es genau und setzen Sie es konsequent durch. Eine Verkaufsfaktentabelle könnte eine Unterteilung wie „eine Zeile pro Bestellposition“ oder „eine Zeile pro tägliche Produktverkaufszusammenfassung“ haben. Das Mischen von Körnern in einer einzelnen Faktentabelle (einige Zeilen sind einzelne Transaktionen, andere sind Tagesaggregate) führt zu Berechnungsfehlern, die äußerst schwer zu debuggen sind.

Nur Fremdschlüssel. Die Faktentabelle enthält Fremdschlüssel zu Dimensionstabellen, keine beschreibenden Attribute. Eine Faktentabelle sollte weder „CustomerName“ noch „ProductCategory“ enthalten – diese gehören in die Dimensionstabellen. Die Faktentabelle verfügt über CustomerKey und ProductKey, die mit den Dimensionen verknüpft sind, in denen sich die beschreibenden Details befinden.

Additive Maße. Die numerischen Spalten in einer Faktentabelle sollten additiv sein – Werte, die sinnvoll über jede Dimension summiert werden können. Umsatz, Menge, Kosten und Rabatt addieren sich. Prozentsätze, Verhältnisse und Stückpreise sind nicht additiv (Sie können die Stückpreise nicht über Produkte hinweg summieren). Speichern Sie die Komponenten (Zähler und Nenner) in der Faktentabelle und berechnen Sie das Verhältnis in einem DAX-Maß.

Vermeiden Sie berechnete Spalten in Fakten. Das Hinzufügen berechneter Spalten zu einer Faktentabelle erhöht den Speicherbedarf der Tabelle und erhöht die Verarbeitungszeit während der Aktualisierung. Berechnen Sie stattdessen abgeleitete Werte in DAX-Kennzahlen, die zur Abfragezeit berechnet werden und keinen Speicher verbrauchen.

Dimensionstabellen: Designprinzipien

Dimensionstabellen beschreiben das „Wer, Was, Wo, Wann, Warum“ von Geschäftsveranstaltungen. Sie enthalten die Attribute, nach denen Benutzer filtern, gruppieren und segmentieren.

Ersatzschlüssel. Verwenden Sie ganzzahlige Ersatzschlüssel (CustomerKey, ProductKey) als Primärschlüssel in Dimensionstabellen, keine natürlichen Schlüssel (Kunden-E-Mail, Produkt-SKU). Ersatzschlüssel sind kleiner, lassen sich besser komprimieren und schützen das Modell vor Änderungen in den Schlüsseln des Quellsystems.

Dimensionen denormalisieren. In einem Sternschema werden Dimensionstabellen absichtlich denormalisiert. Eine DimProduct-Tabelle enthält Kategorie, Unterkategorie und Marke als Spalten in derselben Tabelle und nicht als separate normalisierte Tabellen mit eigenen Schlüsseln. Dies ist das Gegenteil des transaktionalen Datenbankdesigns und beabsichtigt. Denormalisierte Dimensionen führen zu schnelleren Abfragen und einfacherem DAX, da die VertiPaq-Engine eine einzelne Tabelle scannt, anstatt mehrere Tabellen zu verbinden.

Beschreibende Hierarchien einbeziehen. Wenn Benutzer einen Drilldown von der Kategorie zur Unterkategorie und zum Produkt durchführen, sollten alle drei Ebenen Spalten in DimProduct sein. Erstellen Sie im Power BI-Modell ein Hierarchieobjekt, das diesen Drill-Pfad definiert.

Dimensionen ändern sich langsam. Wenn sich Dimensionsattribute im Laufe der Zeit ändern (ein Kunde zieht in die Stadt, ein Produkt ändert die Kategorie), benötigen Sie eine Strategie. Typ 1 (Überschreiben) ist am einfachsten: Aktualisieren Sie die Dimensionszeile mit dem neuen Wert. Typ 2 (Neue Zeile hinzufügen) behält den Verlauf bei. Fügen Sie eine neue Zeile mit einem gültigen Datumsbereich hinzu, sodass historische Transaktionen den zu diesem Zeitpunkt aktuellen Attributwerten zugeordnet werden. Typ 2 ist komplexer, aber notwendig, wenn es auf historische Genauigkeit ankommt (Finanzprüfungen, regulatorische Berichterstattung).

---

Beziehungen konfigurieren

Beziehungsregeln für Power BI

Power BI-Beziehungen definieren, wie Tabellen verbunden werden und wie sich Filter verbreiten. Die richtigen Beziehungen sind von entscheidender Bedeutung – falsche Beziehungen führen stillschweigend zu falschen Zahlen, was schlimmer ist als zu Fehlern.

Nur Eins-zu-viele. Jede Beziehung in einem Sternschema verbindet eine Dimensionstabelle (eine Seite) mit einer Faktentabelle (viele Seite). Die Dimensionstabelle enthält eindeutige Werte in der Schlüsselspalte. Die Faktentabelle enthält wiederholte Werte. Power BI validiert dies und markiert Verstöße. Wenn Power BI eine Viele-zu-Viele-Beziehung erkennt, müssen Sie ein Modellierungsproblem beheben.

Einzelrichtungs-Kreuzfilterung. Stellen Sie die Kreuzfilterrichtung für alle Beziehungen auf „Einzeln“ ein. Dies bedeutet, dass Filter von der Dimension zum Fakt fließen (wenn Sie einen Kunden in einem Slicer auswählen, werden nur die Zeilen dieses Kunden in den Faktentabellenvisualisierungen angezeigt), aber nicht vom Fakt zurück zur Dimension. Bidirektionale Filterung führt in Modellen mit mehreren Faktentabellen zu mehrdeutigen Filterpfaden und sollte außer in sehr spezifischen Szenarien vermieden werden.

Aktive vs. inaktive Beziehungen. Power BI erlaubt nur eine aktive Beziehung zwischen zwei beliebigen Tabellen. Wenn eine Faktentabelle mehrere Datumsspalten enthält (OrderDate, ShipDate, DeliveryDate), erstellen Sie eine aktive Beziehung (normalerweise OrderDate zu DimDate) und inaktive Beziehungen für die anderen. Verwenden Sie die Funktion USERELATIONSHIP in DAX-Kennzahlen, um die inaktive Beziehung bei Bedarf zu aktivieren:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

Rollenspieldimensionen

Eine Rollendimension ist eine einzelne Dimensionstabelle, die im Modell mehrere Rollen erfüllt. Die Datumsdimension ist das häufigste Beispiel: Sie stellt eine Verbindung zu OrderDate, ShipDate und DeliveryDate in der Faktentabelle her und spielt in jeder Beziehung eine andere „Rolle“.

In Power BI können Sie Rollenspieldimensionen auf zwei Arten handhaben:

Inaktive Beziehungen + USERELATIONSHIP (empfohlen). Behalten Sie eine einzelne DimDate-Tabelle mit einer aktiven Beziehung (zu OrderDate) und inaktiven Beziehungen zu den anderen Datumsspalten. Erstellen Sie Kennzahlen, die USERELATIONSHIP für die alternativen Datumsperspektiven verwenden. Dadurch bleibt das Modell kompakt und eine Datenduplizierung wird vermieden.

Doppelte Dimensionstabellen. Erstellen Sie separate Kopien von DimDate (DimOrderDate, DimShipDate, DimDeliveryDate), jeweils mit einer aktiven Beziehung zu ihrer jeweiligen Faktenspalte. Dieser Ansatz ist aus DAX-Sicht einfacher (keine USERELATIONSHIP erforderlich), erhöht aber die Modellgröße und den Wartungsaufwand.

Für die meisten Implementierungen wird der Ansatz der inaktiven Beziehung bevorzugt. Es erzeugt ein saubereres Modell und einen geringeren Speicherbedarf auf Kosten eines etwas ausführlicheren DAX.

Viele-zu-viele-Beziehungen

Einige Geschäftsszenarien erfordern tatsächlich Viele-zu-Viele-Beziehungen. Ein Kunde kann mehreren Segmenten angehören, ein Produkt kann in mehreren Werbekampagnen enthalten sein, ein Verkäufer kann mehrere Gebiete abdecken. Das Star-Schema verarbeitet diese über Bridge-Tabellen.

Eine Brückentabelle befindet sich in einer Viele-zu-Viele-Beziehung zwischen den beiden Tabellen und enthält eine Zeile für jede Kombination:

BridgeCustomerSegment: CustomerKey, SegmentKey

DimCustomer stellt eine Verbindung zu BridgeCustomerSegment her (eins-zu-viele auf CustomerKey). DimSegment stellt eine Verbindung zu BridgeCustomerSegment her (eins-zu-viele auf SegmentKey). Die Brückentabelle ermöglicht das Filtern von FactSales nach Segmenten und gleichzeitig die korrekte Behandlung von Kunden in mehreren Segmenten.

Seien Sie bei Brückentabellen vorsichtig – sie können zu Doppelzählungen führen, wenn sie nicht mit geeigneten DAX-Kennzahlen gepaart werden, die die Viele-zu-Viele-Zuordnung handhaben. Testen Sie gründlich mit bekannten Daten, um sicherzustellen, dass die Gesamtwerte korrekt sind.

---

DAX-Kennzahlen: Muster und Leistung

Basismaßnahmen

Jedes Analysemodell benötigt eine Reihe von Basiskennzahlen, die einfache Aggregationen für Faktentabellenspalten durchführen. Definieren Sie diese zuerst – sie dienen als Bausteine ​​für komplexere Berechnungen.

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

Beachten Sie, dass „Durchschnittlicher Bestellwert“ und „Bruttomarge“ auf andere Kennzahlen verweisen und nicht die Aggregationslogik wiederholen. Dies ist beabsichtigt – wenn sich die Definition des Gesamtumsatzes ändert (z. B. um Retouren auszuschließen), spiegeln die nachgelagerten Kennzahlen die Änderung automatisch wider.

BERECHNEN: Der Kern von DAX

CALCULATE ist die wichtigste DAX-Funktion. Es wertet einen Ausdruck in einem geänderten Filterkontext aus. CALCULATE zu verstehen bedeutet, DAX zu verstehen.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Diese Kennzahl nimmt die Gesamtumsatzkennzahl und wertet sie in einem Filterkontext aus, in dem der Datumsbereich um ein Jahr nach hinten verschoben wird. Wenn der aktuelle Filterkontext „Januar 2026“ ist, ändert CALCULATE ihn in „Januar 2025“ und wertet den Gesamtumsatz in diesem geänderten Kontext aus.

CALCULATE akzeptiert mehrere Filterargumente und diese interagieren je nach Typ unterschiedlich:

Tabellenfilter (wie SAMEPERIODLASTYEAR) ersetzen den vorhandenen Filter für die Spalten dieser Tabelle. Wenn das Visual bereits über einen Monatsfilter verfügt, überschreibt SAMEPERIODLASTYEAR diesen mit dem entsprechenden Monat des Vorjahres.

Boolesche Filter (wie DimProduct[Category] = "Electronics") ergänzen den vorhandenen Kontext. Wenn das Bild nach 2026 gefiltert wird, zeigt das CALCULATE-Ergebnis den Elektronikumsatz 2026 an.

REMOVEFILTERS löscht vorhandene Filter. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) gibt den Gesamtumsatz über alle Kategorien zurück, unabhängig davon, welche Kategoriefilter aktiv sind.

Variablen für Lesbarkeit und Leistung

Variablen (VAR) berechnen einen Wert einmal und referenzieren ihn mehrmals. Sie machen komplexe Kennzahlen lesbar und machen redundante Berechnungen überflüssig:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

Ohne Variablen würde diese Kennzahl [Gesamtumsatz] und [Umsatz letztes Jahr] mehrmals berechnen (einmal für die Subtraktion, einmal für die Division), was den Berechnungsaufwand verdoppeln würde. Variablen stellen sicher, dass jede genau einmal berechnet wird.

Iteratorfunktionen: Wann man sie verwendet

Iteratorfunktionen (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX) werten einen Ausdruck Zeile für Zeile in einer Tabelle aus. Sie sind leistungsstark, aber teuer – sie scannen jede Zeile in der angegebenen Tabelle.

Verwenden Sie Iteratoren, wenn Sie vor der Aggregation Berechnungen auf Zeilenebene benötigen:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

Dies kann mit einfacher SUMME nicht erreicht werden, da Sie vor der Summierung in jeder Zeile die Menge mit dem Einheitspreis multiplizieren müssen. Der Iterator SUMX übernimmt diese zeilenweise Multiplikation.

Vermeiden Sie Iteratoren, wenn ein einfaches Aggregat ausreicht. SUMX(FactSales, FactSales[TotalAmount]) entspricht funktional SUM(FactSales[TotalAmount]), ist jedoch langsamer, da der Iterator Zeile für Zeile scannt, während SUM die Spaltenkomprimierung nutzt.

---

Berechnungsgruppen

Welche Berechnungsgruppen lösen

Vor Berechnungsgruppen erforderte ein Datenmodell mit 10 Basiskennzahlen (Umsatz, Menge, Kosten, Marge usw.) und 5 Time-Intelligence-Variationen (YTD, QTD, MTD, Vorjahr, Vorjahres-YTD) 50 separate Kennzahlen. Das Hinzufügen eines neuen Basismaßes bedeutete die Erstellung von fünf weiteren Time-Intelligence-Varianten. Das Hinzufügen eines neuen Time-Intelligence-Musters erforderte die Erstellung von zehn weiteren Kennzahlen. Diese kombinatorische Explosion machte die Wartung von Modellen schwierig.

Berechnungsgruppen lösen dieses Problem, indem sie Zeitintelligenzmuster einmal definieren und sie dynamisch auf eine beliebige Kennzahl anwenden.

Aufbau einer Zeitintelligenz-Berechnungsgruppe

Erstellen Sie in Power BI Desktop eine Berechnungsgruppe über die Modellansicht oder mit externen Tools wie dem Tabelleneditor (der mehr Kontrolle bietet).

Definieren Sie Berechnungselemente für jedes Zeitintelligenzmuster:

Aktuell: Keine Änderung --- gibt die Kennzahl unverändert zurück.

SELECTEDMEASURE()

YTD (Jahr bis heute):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

Vorjahr:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Vorjahr YTD:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

Veränderung im Jahresvergleich:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

Veränderung im Jahresvergleich:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

Nach der Definition platzieren Benutzer die Berechnungsgruppe in der Spalten- oder Zeilenachse eines Visuals, und Power BI wendet jedes Berechnungselement auf die Kennzahl im Wertefeld an. Eine Berechnungsgruppe mit 6 Items ersetzt 60 Einzelmaßnahmen (für 10 Basismaßnahmen).

String-Ausdrücke formatieren

Jedes Berechnungselement kann einen Formatzeichenfolgenausdruck haben, der das Zahlenformat basierend auf der Berechnung dynamisch ändert:

Für absolute Kennzahlen (Aktuell, YTD, Vorjahr): Verwenden Sie das Format der Basiskennzahl. Für Prozentmaße (Änderung im Jahresvergleich in %): Format als Prozentsatz.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

Dadurch wird sichergestellt, dass die Formatierung korrekt ist, ohne dass ein manueller Eingriff erforderlich ist, wenn ein Benutzer zwischen „Aktuell“ (Anzeige 1.234.567 USD) und „Jahresvergleich % Änderung“ (Anzeige 12,5 %) wechselt.

---

Zeitintelligenz

Die Datumsdimensionstabelle

Zeitintelligenz in Power BI erfordert eine dedizierte Datumsdimensionstabelle. Verlassen Sie sich nicht auf die Funktion „Automatisches Datum/Uhrzeit“ (deaktivieren Sie sie unter „Datei“ → „Optionen“ → „Daten laden“) – sie erstellt versteckte Datumstabellen für jede Datumsspalte, was Ihr Modell aufbläht und Ihre Kontrolle einschränkt.

Erstellen Sie eine Datumsdimensionstabelle, die den gesamten Bereich Ihrer Daten sowie mindestens ein Jahr auf jeder Seite abdeckt. Wenn Ihre früheste Transaktion Januar 2020 ist, beginnen Sie mit der Datumstabelle im Januar 2019. Wenn Ihre Analyse Prognosen für 2027 umfasst, enden Sie im Dezember 2027.

Wesentliche Spalten für eine Datumsdimensionstabelle:

Erstellen Sie die Datumstabelle in Power Query oder als DAX-berechnete Tabelle:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

Markieren Sie die Tabelle als Datumstabelle in Power BI (Tabellentools → Als Datumstabelle markieren → Spalte „Datum“ auswählen). Dadurch werden die integrierten Zeitintelligenzfunktionen aktiviert.

Gemeinsame Muster der Zeitintelligenz

Mit einer geeigneten Datumsdimension verarbeiten die Zeitintelligenzfunktionen von Power BI die gängigsten Zeitberechnungen:

Jahr bis heute: DATESYTD(DimDate[Date]) Stammquartal: DATESQTD(DimDate[Date]) Monat bis heute: DATESMTD(DimDate[Date]) Gleicher Zeitraum im letzten Jahr: SAMEPERIODLASTYEAR(DimDate[Date]) Rollierende 12 Monate: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) Parallelperiode: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (Fenster gleicher Größe nach hinten verschoben)

Diese Funktionen ändern den Datumsfilterkontext, wenn sie in CALCULATE verwendet werden. Sie funktionieren nur dann ordnungsgemäß, wenn die Datumsspalte aus einer als Datumstabelle markierten Tabelle mit einem zusammenhängenden, vollständigen Datumsbereich stammt.

Unterstützung für den Finanzkalender

Wenn das Geschäftsjahr Ihrer Organisation nicht mit dem Kalenderjahr übereinstimmt, ändern Sie die Zeitintelligenzberechnungen, um den Geschäftskalender zu verwenden:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

Das zweite Argument von DATESYTD gibt das Enddatum des Geschäftsjahres an. Alle YTD-Berechnungen verwenden dann die Geschäftsjahresgrenze anstelle des 31. Dezember.

---

Zusammengesetzte Modelle

Wann man zusammengesetzte Modelle verwendet

Zusammengesetzte Modelle kombinieren importierte Daten (in VertiPaq gespeichert) mit DirectQuery-Daten (live von der Quelle abgefragt) in einem einzigen Modell. Dieser hybride Ansatz ist wertvoll, wenn Sie die Leistung importierter Daten für historische Analysen und die Aktualität von Live-Daten für Betriebsmetriken benötigen.

Häufige Szenarien:

Historisch + Echtzeit. Importieren Sie historische Verkaufsdaten aus 3 Jahren zur Trendanalyse (schnelle Abfragen, keine Auswirkungen auf die Quelldatenbank). Stellen Sie über DirectQuery eine Verbindung zu den Daten des aktuellen Monats her, um aktuelle Betriebsansichten zu erhalten.

Zentrales Modell + lokale Anreicherung. Stellen Sie über DirectQuery eine Verbindung zu einem zentral verwalteten Datensatz her (wobei sichergestellt wird, dass Sie die geregelten Definitionen der Organisation verwenden). Fügen Sie lokal importierte Tabellen für abteilungsspezifische Daten (Budgetziele, benutzerdefinierte Klassifizierungen) hinzu, die im zentralen Modell nicht vorhanden sind.

Mehrere Quellsysteme. Importieren Sie Daten aus einem Cloud Data Warehouse (Snowflake, Azure Synapse) und stellen Sie über DirectQuery eine Verbindung zu einer Betriebsdatenbank (PostgreSQL, SQL Server) in einem einzigen Bericht her, ohne eine separate ETL-Pipeline zu ihrer Konsolidierung aufzubauen.

Zusammengesetzte Modellarchitektur

In einem zusammengesetzten Modell verfügt jede Tabelle über einen Speichermodus:

Importieren: Daten werden in den VertiPaq-Speicher geladen. Höchste Abfrageleistung, zur Aktualisierung ist jedoch eine geplante Aktualisierung erforderlich.

DirectQuery: Daten werden live von der Quelle abgefragt. Immer aktuell, hängt jedoch von der Leistung der Quelldatenbank ab.

Dual: Die Tabelle wird sowohl importiert als auch für DirectQuery verfügbar. Wird für Dimensionstabellen verwendet, die sich sowohl auf Import- als auch auf DirectQuery-Faktentabellen beziehen müssen.

Stellen Sie Dimensionstabellen, die Import- und DirectQuery-Fakten verbinden, auf den „Dual“-Modus ein. Dadurch kann die VertiPaq-Engine beim Filtern von Importfakten die speicherinterne Kopie verwenden und beim Filtern von DirectQuery-Fakten SQL-Abfragen generieren.

Leistungsüberlegungen

Zusammengesetzte Modelle führen zu Komplexität. Abfragen, die Import- und DirectQuery-Tabellen umfassen, erfordern, dass Power BI Ergebnisse von zwei verschiedenen Engines zusammenführt, was langsam sein kann, wenn die DirectQuery-Quelle nicht optimiert ist.

Minimieren Sie quellenübergreifende Verknüpfungen, indem Sie Ihr Modell so strukturieren, dass die meisten analytischen Abfragen auf Importtabellen treffen. Verwenden Sie DirectQuery nur für die spezifischen Tabellen, die Echtzeitaktualität erfordern. Indizieren Sie die DirectQuery-Quelltabellen anhand der in Beziehungen und Filtern verwendeten Spalten.

Für Unternehmen, die komplexe Power BI-Datenmodelle erstellen, bieten die Datenmodellierungsdienste von ECOSIRE fachkundige Beratung zum Star-Schema-Design, zur DAX-Optimierung und zur zusammengesetzten Modellarchitektur, die auf Ihre spezifische Datenlandschaft und Leistungsanforderungen zugeschnitten ist.

---

Modelloptimierung

Reduzierung der Modellgröße

Große Modelle verbrauchen mehr Speicher, werden langsamer aktualisiert und fragen weniger schnell ab. Optimieren Sie die Modellgröße mit diesen Techniken:

Nicht verwendete Spalten entfernen. Wenn eine Spalte in keiner visuellen, Kennzahl-, Beziehungs- oder RLS-Regel verwendet wird, entfernen Sie sie. Jede Spalte verbraucht Speicher, auch wenn keine visuelle Referenz darauf vorhanden ist. Zu den häufigsten Übeltätern gehören automatisch generierte Spalten, Prüfspalten (CreatedBy, ModifiedDate) und technische Kennungen, die keinem Analysezweck dienen.

Kardinalität reduzieren. Spalten mit Millionen eindeutiger Werte (Zeitstempel, GUIDs, Freitextfelder) lassen sich schlecht komprimieren. Runden Sie Zeitstempel auf die entsprechende Granularität (täglich, stündlich). Ersetzen Sie GUIDs durch ganzzahlige Ersatzschlüssel. Verschieben Sie Freitextfelder in eine separate Detailtabelle, die nur beim Drillthrough abgefragt wird.

Verwenden Sie geeignete Datentypen. Power BI speichert „Ganzzahl“ effizienter als „Dezimalzahl“. Wenn eine Spalte nur Ganzzahlen (Mengen, Zählungen) enthält, legen Sie ihren Typ auf Ganze Zahl fest. Textspalten verbrauchen mehr Speicher als numerische Spalten mit derselben Kardinalität. Kodieren Sie Textkategorien nach Möglichkeit als Ganzzahlen mit einer Nachschlagedimension.

Automatisches Datum/Uhrzeit deaktivieren. Die Funktion „Automatisches Datum/Uhrzeit“ erstellt eine ausgeblendete Datumstabelle für jede Datumsspalte im Modell. Bei einem Modell mit 10 Datumsspalten sind das 10 versteckte Datumstabellen, die Speicher verbrauchen. Deaktivieren Sie diese Funktion und verwenden Sie stattdessen eine einzelne explizite Datumsdimension.

Abfrageleistungsdiagnose

Verwenden Sie DAX Studio, um die Abfrageleistung zu analysieren, die über das hinausgeht, was der integrierte Leistungsanalysator von Power BI anzeigt. DAX Studio enthüllt:

Speicher-Engine-Abfragen. Wie viele Abfragen an die VertiPaq-Engine gesendet werden und wie viele Daten sie scannen. Weniger Abfragen, die weniger Daten scannen, bedeuten eine bessere Leistung.

Aktivität der Formel-Engine. Wie viel Arbeit die Formel-Engine leistet (zeilenweise Berechnungen, komplexe Ausdrücke). Eine hohe Formel-Engine-Zeit weist auf Maßnahmen hin, die neu geschrieben werden sollten, um mehr Arbeit an die Speicher-Engine zu übertragen.

Abfrageplan. Der logische und physische Ausführungsplan für eine DAX-Abfrage, der zeigt, wie Power BI eine Kennzahl in Speicher-Engine-Abfragen und Formel-Engine-Vorgänge zerlegt.

Zielen Sie auf Abfragezeiten unter 500 ms für interaktive Visuals. Abfragen über 2 Sekunden fühlen sich träge an und schrecken von der Nutzung des Dashboards ab. Wenn ein bestimmtes Bild dauerhaft länger als 2 Sekunden dauert, vereinfachen Sie dessen DAX, reduzieren Sie das verarbeitete Datenvolumen oder verschieben Sie es auf eine Drill-Through-Seite, auf der Benutzer eine kurze Wartezeit akzeptieren.

---

FAQ

Soll ich in Power BI das Sternschema oder das Schneeflockenschema verwenden?

Das Sternschema ist fast immer die bessere Wahl für Power BI. Das Snowflake-Schema normalisiert Dimensionstabellen in Untertabellen (Kategorie → Unterkategorie → Produkt), was in relationalen Datenbanken gut funktioniert, aber unnötige Verknüpfungen in der VertiPaq-Engine von Power BI erzeugt. VertiPaq komprimiert denormalisierte Dimensionsspalten äußerst effizient, sodass die Platzeinsparungen durch Snowflaking vernachlässigbar sind, während die Leistungseinbußen durch zusätzliche Beziehungen real sind. Reduzieren Sie Ihre Dimensionen in ein Sternschema, es sei denn, Sie haben einen bestimmten technischen Grund dagegen (z. B. eine sehr große Dimensionstabelle mit einer selten verwendeten Spalte mit hoher Kardinalität, die Sie isolieren möchten).

Was ist die maximale Datensatzgröße in Power BI?

Power BI Pro unterstützt komprimierte Datensätze mit einer Größe von bis zu 1 GB. Premium pro Benutzer unterstützt bis zu 100 GB. Die Premium-Kapazität (P1 und höher) unterstützt bis zu 400 GB bei aktivierter Speicherung großer Datensätze. Diese Grenzwerte beziehen sich auf die komprimierte In-Memory-Größe, nicht auf die Quelldatengröße. VertiPaq komprimiert Daten normalerweise im Verhältnis 10:1, sodass ein komprimierter Datensatz von 1 GB möglicherweise 10 GB Quelldaten darstellt. Für Datensätze, die sich diesen Grenzwerten nähern, sollten Sie Aggregationen, inkrementelle Aktualisierungen oder zusammengesetzte Modelle mit DirectQuery für Daten auf Detailebene in Betracht ziehen.

Wie gehe ich mit Viele-zu-Viele-Beziehungen in einem Sternschema um?

Verwenden Sie eine Brückentabelle (auch faktenlose Faktentabelle oder Verbindungstabelle genannt). Die Brückentabelle verfügt über eine Zeile für jede Kombination in der Viele-zu-Viele-Beziehung – beispielsweise eine Zeile für jede Kundensegmentzuweisung. Erstellen Sie Eins-zu-viele-Beziehungen von jeder Dimension zur Brückentabelle. Beachten Sie, dass Brückentabellen zu Doppelzählungen führen können. Kombinieren Sie sie mit DISTINCTCOUNT-Kennzahlen oder verwenden Sie CROSSFILTER in DAX, um die Filterausbreitung zu steuern. Testen Sie gründlich mit bekannten Daten, um sicherzustellen, dass die Gesamtwerte korrekt sind.

Soll ich berechnete Spalten oder DAX-Kennzahlen erstellen?

Ziehen Sie in fast allen Fällen Kennzahlen gegenüber berechneten Spalten vor. Kennzahlen werden zum Zeitpunkt der Abfrage berechnet und belegen keinen Speicher. Berechnete Spalten werden während der Aktualisierung berechnet und im Speicher gespeichert, wodurch die Modellgröße zunimmt. Verwenden Sie berechnete Spalten nur, wenn Sie den verfügbaren Wert zum Filtern, Sortieren oder für Beziehungen benötigen (Sie können in einem Slicer nicht nach einer Kennzahl filtern, wohl aber nach einer berechneten Spalte). Eine häufige Ausnahme ist eine verkettete Spalte für Beschriftungen auf Zeilenebene (FullName = FirstName + „ “ + LastName), die Benutzer in Slicern oder Tabellenvisualisierungen benötigen.

Wie interagieren Berechnungsgruppen mit vorhandenen Kennzahlen?

Berechnungsgruppen fangen die Maßauswertung ab, indem sie das Maß in den Ausdruck des Berechnungselements einschließen. Wenn ein Visual eine Kennzahl und eine Berechnungsgruppe enthält, wendet Power BI das Berechnungselement über die Funktion SELECTEDMEASURE() auf die Kennzahl an. Das bedeutet, dass Ihre Basismaße nicht geändert werden müssen. Bei Kennzahlen, die bereits Zeitintelligenz enthalten (z. B. eine hartcodierte YTD-Kennzahl), wird die Berechnungsgruppe jedoch oben angewendet, was möglicherweise zu einer doppelten Anwendung führt. Um dies zu vermeiden, definieren Sie nur Basiskennzahlen (einfache Aggregationen) und verwenden Sie Berechnungsgruppen ausschließlich für All-Time-Intelligence und Vergleichslogik.