Composite Model Power BI: so klappt der Mix aus Import und DirectQuery

Definition

Ein Composite Model in Power BI ist ein semantisches Modell, das Tabellen mit unterschiedlichen Storage Modes (Import, DirectQuery, Dual Mode) in einem gemeinsamen Dataset kombiniert. Es ist keine Abkürzung für schlechte Datenmodelle und kein Ersatz für eine klare Definition von Kennzahlen, Grain und Beziehungen.

Einleitung

Wenn ihr heute „schnell“ und „aktuell“ gleichzeitig wollt, landet ihr in Power BI oft im Zielkonflikt: Import ist schnell, DirectQuery ist aktuell, aber manchmal zäh. Ein Composite Model Power BI löst das, indem du pro Tabelle entscheidest, was wichtiger ist: Performance, Aktualität oder Wiederverwendung. Das Ergebnis sind Dashboards, die sich gut anfühlen und trotzdem bis ins Detail drillen können.

Wie Composite Models funktionieren (Import, DirectQuery, Dual Mode)

In Power BI Desktop bekommt jede Tabelle einen Storage Mode. Import lädt Daten in die VertiPaq-Engine und liefert schnelle DAX-Abfragen. DirectQuery schickt Queries an die Quelle (zum Beispiel SQL Server) und holt Ergebnisse live. Dual Mode ist für Tabellen gedacht, die je nach Abfragekontext wie Import oder wie DirectQuery arbeiten.

Der praktische Nutzen: Häufig genutzte Dimensionen (Kunde, Artikel, Kalender) können im Dual Mode stehen, damit sie bei DirectQuery-Fakten nicht jedes Mal die Quelle ausbremsen. Gleichzeitig können große Fakten entweder importiert (für Tempo) oder via DirectQuery angebunden werden (für Aktualität oder Volumen).

DirectQuery vs. Import im Composite Model: wann welches besser passt

Import ist meist die beste Wahl für wiederkehrende Management-KPIs: schnelle Interaktion, stabile Performance, weniger Abhängigkeit von Netzwerk und Quellsystem. DirectQuery ist sinnvoll, wenn sehr aktuelle Daten gebraucht werden oder wenn das Detailvolumen nicht sinnvoll importiert werden kann.

• Import: bestes Nutzererlebnis bei Standard-Reporting, ideal für „80% der Fragen“.

• DirectQuery: gut für „jetzt sofort“-Sichten und sehr große Detailtabellen, aber nur mit starker Quelle.

• Dual Mode: funktioniert als Brücke, damit Dimensionen sowohl zu Import- als auch zu DirectQuery-Tabellen sauber beitragen.

Wichtig: Ein Composite-Ansatz ist kein Freifahrtschein, beliebig Tabellen „dazuzufügen“ (add). Jede zusätzliche Quelle und Beziehung erhöht das Risiko für limited relationships, Mehrdeutigkeiten und schwer erklärbare Ergebnisse.

Architekturüberblick: so bleibt das Modell wartbar

Eine robuste BI-Architektur für Composite Models orientiert sich an einem Star Schema: klare Faktentabellen, saubere Dimensionen, wenige und eindeutige Relationships. Dazu kommt eine bewusste Trennung von „schnell“ und „detailreich“: Import für die verdichteten Auswertungen, DirectQuery für Details oder sehr aktuelle Daten.

Wenn Microsoft Fabric im Spiel ist, kann OneLake als zentraler Daten-Ort den Alltag vereinfachen: Nicht nur IT, sondern auch Fachanwender können auf saubere, kuratierte „Gold“-Daten zugreifen und daraus in Power BI (und oft auch in Excel) bauen, ohne jedes Mal neue Dateninseln zu schaffen. Composite Models profitieren davon, weil die Basisdaten stabiler und konsistenter sind.

Use Cases und Vorteile (1 Mini-Story)

Typisch ist ein CFO-Dashboard: Umsatz, Marge und Liquiditäts-KPIs müssen schnell reagieren, aber der Drilldown bis zur Buchung soll tagesaktuell sein. Das Modell importiert aggregierte Fakten für die Standardseiten, während Detailbuchungen per DirectQuery angebunden sind; Dimensionen laufen im Dual Mode. Ergebnis: Meetings werden schneller, Excel-Nachpflege sinkt, und Fragen lassen sich direkt im Bericht klären.

Leistung, Aggregationen und Skalierbarkeit

Performance entscheidet über Akzeptanz. Bei Composite Models sind Aggregations ein zentraler Hebel: Du legst eine importierte Aggregationstabelle (z. B. Umsatz pro Tag/Region/Produktgruppe) an, die die häufigsten Queries beantwortet. Nur wenn Nutzer wirklich ins Detail gehen, wird auf die DirectQuery-Detailtabelle gewechselt. So bleibt das Dashboard schnell, und die Quelle wird entlastet.

Weitere Praxisregeln: Der Grain (Detailgrad) jeder Tabelle muss eindeutig sein, sonst explodieren DAX-Komplexität und Abfragepfade. Außerdem sollten Measures auf Aggregationen ausgelegt sein, statt jede Kennzahl aus Detaildaten „live“ zu rechnen.

Getting Started: erste Implementierung ohne Overengineering

Startet klein und messbar. Nehmt einen Bericht, der heute am meisten Zeit frisst (z. B. monatliche Konsolidierung) und baut ein erstes Dataset mit klarem Zielbild.

• Schritt 1: Modellgrundlage bauen (Star Schema, Dimensionen, Measures, Datenvalidierung).

• Schritt 2: Storage Mode pro Tabelle festlegen (Import für KPI-Ebene, DirectQuery für Details, Dual Mode für zentrale Dimensionen).

• Schritt 3: Aggregationen ergänzen und Performance mit Performance Analyzer prüfen.

So bekommt ihr schnell ein Ergebnis, das im Alltag funktioniert, und erweitert danach strukturiert um weitere Datenquellen, bi datasets oder zusätzliche Fachfragen.

Typische Stolpersteine (und wie du sie vermeidest)

• Zu viele DirectQuery-Tabellen: Das fühlt sich „aktuell“ an, wird aber im Betrieb langsam und fragil.

• Unklare Relationships: Mehrdeutige Filterpfade führen zu falschen Zahlen oder schwer erklärbarem Verhalten.

• DAX ohne Modell-Disziplin: Wenn Kennzahlen Modellschwächen kompensieren sollen, wird Wartung teuer.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn mehrere Quellen kombiniert werden, eure Quelle bei DirectQuery nicht stabil genug wirkt oder ihr ein wiederverwendbares Master-Model-Pattern für viele Reports aufbauen wollt. Dann geht es nicht um „mehr Funktionen“, sondern um eine Entscheidungsvorlage: welches Storage-Design, welche Aggregationen, welche Governance und welcher Aufwand realistisch sind.