Wer sich mit modernen BI-Architekturen beschäftigt, stößt früher oder später auf eine zentrale Frage: Kann ich mein bestehendes Semantic Model – etwa aus dbt, AtScale oder einem anderen Tool – direkt in Power BI nutzen? Die kurze Antwort: Nein. Die längere Antwort erklärt, warum das keine willkürliche Entscheidung von Microsoft ist, sondern ein technisches Problem, das sich nicht einfach wegpatchen lässt.
Chris Webb, einer der erfahrensten Microsoft-BI-Experten weltweit, hat die technischen Hintergründe kürzlich in einem lesenswerten Artikel aufgeschlüsselt. In diesem Beitrag machen wir seine Analyse greifbar – und zeigen, welcher Weg in der Praxis tatsächlich funktioniert.
Was ist ein Semantic Model – und warum ist es wichtig?
Ein Semantic Model ist die Schicht zwischen Rohdaten und Bericht. Es definiert, wie Kennzahlen berechnet werden, wie Tabellen zusammenhängen und welche Geschäftslogik gilt. Wenn Ihr Controller „Umsatz YTD nach Region“ sieht, hat das Semantic Model entschieden, was „Umsatz“ bedeutet, was „YTD“ heißt und wie „Region“ zugeordnet wird.
Power BI bringt ein eigenes Semantic Model mit – gebaut auf der Tabular-Engine, die Microsoft seit über 25 Jahren entwickelt. Heute nutzen laut Microsoft 35 Millionen Anwender monatlich Power BI, die dabei auf 20 Millionen Semantic Models zugreifen. Das macht es zur am weitesten verbreiteten Semantic-Layer-Technologie am Markt.
Daneben gibt es Alternativen: dbt Semantic Layer, AtScale, Cube, Looker – alle mit eigenen Stärken. Die Frage ist: Können diese Modelle als Datenquelle für Power BI dienen?
Drei Ansätze – alle gescheitert
Webb beschreibt drei Wege, die Anbieter versucht haben, um ihre Semantic Models in Power BI einzubinden. Keiner funktioniert zuverlässig.
1. Import: Daten aus dem fremden Modell importieren
Der naheliegendste Ansatz: Power BI importiert die Daten aus dem Drittanbieter-Modell. Das Problem liegt in der Aggregationslogik. Wenn ein externes System eine Kennzahl wie „Marktanteil in Prozent“ oder eine Zeitintelligenz-Berechnung vorberechnet hat, kann Power BI diese nach dem Import nicht korrekt weiter aggregieren. Subtotale und Gesamtsummen werden falsch – und falsche Zahlen im Controlling sind schlimmer als fehlende.
Ein Semantic Model berechnet Kennzahlen nicht vorab, sondern zur Abfragezeit. Genau das macht es mächtig – und genau das geht beim Import verloren.
2. XMLA-Connector: So tun als wäre es Analysis Services
XMLA ist ein offener Standard, den Microsoft seit 25 Jahren für Analysis Services nutzt. Einige Drittanbieter haben versucht, XMLA-Schnittstellen zu implementieren, damit Power BI sie wie eine Analysis-Services-Datenquelle behandelt. Webb bringt es auf den Punkt:
„Using the SQL Server Analysis Services connector to connect to something that isn’t SQL Server Analysis Services is not supported and not wholly reliable.“
Das Problem: XMLA wurde spezifisch für die Microsoft Tabular- und Multidimensional-Engines gebaut. Eine Drittanbieter-Implementierung kann die Oberfläche nachahmen, aber nicht das vollständige Verhalten garantieren. Das Ergebnis sind schwer reproduzierbare Fehler – die Art von Fehlern, die erst auffallen, wenn der Vorstand die falschen Zahlen auf dem Tisch hat.
3. DirectQuery: Ein Semantic Model auf dem anderen
Der dritte Ansatz stapelt Power BI per DirectQuery auf das externe Semantic Model. Webb ist hier besonders deutlich:
„No other semantic model would work well with another semantic model as its source.“
Die technischen Gründe: Die meisten externen Modelle unterstützen keine Star-Schema-Joins, wie Power BI sie erwartet. Kennzahlen, die im unteren Modell definiert sind, propagieren nicht sauber in Subtotale und Gesamtsummen des oberen Modells. Und zwei Schichten Semantic-Logik übereinander – eine im Drittanbieter-Tool, eine in Power BI – erzeugen eine Komplexität, die niemand mehr debuggen kann.
Das ist kein Power-BI-spezifisches Problem. Es gilt in beide Richtungen: Auch umgekehrt würde kein Semantic Model ein anderes sinnvoll als Quelle nutzen können.
Ist das Microsofts Schuld?
Eine berechtigte Frage. Wenn Microsoft keine Third-Party Semantic Models unterstützt, schützt das natürlich den eigenen Marktanteil. Webb ist langjähriger Microsoft MVP und arbeitet als Mitarbeiter bei Microsoft in der Power BI Produktgruppe – er kennt die Plattform also von innen. Seine Argumente sind technisch fundiert und nachvollziehbar. Aber es wäre naiv, den Wettbewerbsaspekt auszublenden.
Die ehrliche Antwort: Beides stimmt. Die technischen Hürden sind real – Semantic Models sind architektonisch nicht dafür gebaut, aufeinander zu sitzen. Gleichzeitig hat Microsoft wenig Anreiz, diese Hürden aktiv abzubauen. Das ist kein Widerspruch, sondern Realität in einem Markt, den ein Anbieter dominiert.
Für die praktische Entscheidung im Unternehmen ändert das wenig: Der Weg funktioniert technisch nicht, unabhängig vom Motiv dahinter.
Was stattdessen funktioniert: Synchronisation
Wenn Import, XMLA und DirectQuery scheitern – was bleibt? Der Ansatz, den Webb empfiehlt und den Anbieter wie Tabular Editor bereits umsetzen: Synchronisation.
Das Prinzip: Kennzahlen und Geschäftslogik, die in einem externen System definiert sind, werden in DAX übersetzt und in das Power BI Semantic Model geschrieben. Nicht als Kopie der Daten, sondern als Kopie der Berechnung. Power BI bleibt die Single Source of Truth für die Berichtsschicht.
Webb formuliert es so: Jede Kennzahl, die in einem Third-Party Semantic Model definiert ist, lässt sich in DAX nachbauen – wobei DAX für viele Anwendungsfälle die bessere Sprache ist als SQL.
In der Praxis
- dbt definiert Geschäftslogik in SQL → Tabular Editor synchronisiert die Definitionen als DAX-Measures ins Power BI Modell
- AtScale stellt einen virtualisierten Semantic Layer bereit → Die relevanten Metriken werden als DAX-Measures übernommen
- Eigene Berechnungen in Python oder Notebooks → Fabric Semantic Link ermöglicht den Zugriff auf Power BI Modelle aus Python heraus
Der Aufwand ist vertretbar, wenn man es von Anfang an richtig aufsetzt. Nachträglich zwei gewachsene Semantic Layers zu konsolidieren ist deutlich schmerzhafter.
Was bedeutet das für Ihr Unternehmen?
Für Unternehmen, die auf dem Microsoft-Stack arbeiten – ob 50 oder 5.000 Mitarbeiter –, ist die Empfehlung klar:
Nutzen Sie Power BI Semantic Models als zentrale Definitionsschicht für Kennzahlen und Geschäftslogik. Nicht, weil Microsoft es so will, sondern weil es technisch der Weg ist, der funktioniert – mit der breitesten Tool-Unterstützung, der größten Community und der tiefsten Integration in den Microsoft-Stack.
Konkret heißt das:
- Kennzahlen in DAX definieren, nicht in SQL-Views oder externen Tools. DAX wurde genau dafür gebaut und deckt Zeitintelligenz, bedingte Aggregationen und kontextsensitive Berechnungen nativ ab.
- Star-Schema als Datenmodell nutzen. Power BI ist für dimensionale Modellierung optimiert – flache Tabellen oder denormalisierte Exports bremsen die Performance und machen das Modell fragil.
- Externe Definitionen synchronisieren, nicht stapeln. Wenn dbt oder ein anderes Tool im Einsatz ist: Brücke bauen statt Modell auf Modell stellen.
- Direct Lake als Zukunftsinvestition. Wer Microsoft Fabric nutzt, profitiert von Direct Lake – einem Speichermodus, der die Performance von Import mit der Aktualität von DirectQuery verbindet. Das funktioniert allerdings nur mit OneLake als Datenquelle.
Praxisbeispiel: Kennzahlen-Chaos durch zwei Semantic Layers
Ein mittelständischer Fertigungsbetrieb mit 800 Mitarbeitern hatte sein Data Warehouse in Azure aufgebaut. Das Data-Engineering-Team definierte Kennzahlen wie „Auslastungsgrad“ und „Liefertreue“ als SQL-Views in dbt. Das BI-Team baute parallel eigene Measures in Power BI – mit leicht abweichender Logik.
Das Ergebnis: Die Geschäftsführung sah je nach Tool unterschiedliche Zahlen für dieselbe Kennzahl. Nicht dramatisch unterschiedlich – 2–3 Prozentpunkte. Aber genug, um das Vertrauen in beide Systeme zu untergraben.
Die Lösung: Alle Kennzahlen-Definitionen wurden konsolidiert und als DAX-Measures im Power BI Semantic Model zentralisiert. dbt blieb für die Datentransformation zuständig, aber die Berichtslogik liegt jetzt an einer Stelle. Der Aufwand: drei Personentage. Die Diskussionen über „welche Zahl stimmt“ – seitdem erledigt.
Häufig gestellte Fragen
Kann ich dbt-Metriken direkt in Power BI nutzen?
Nicht als native Datenquelle. dbt bietet eine Power BI-Integration über den Semantic Layer, aber diese befindet sich im Preview-Status und basiert auf DirectQuery – mit den beschriebenen Einschränkungen bei Subtotalen und Aggregationen. Der zuverlässigere Weg ist die Synchronisation der Metrik-Definitionen nach DAX über Tools wie Tabular Editor.
Lohnt sich ein externer Semantic Layer neben Power BI?
Nur wenn Power BI nicht das einzige Reporting-Frontend ist. Wenn mehrere BI-Tools auf denselben Kennzahlen arbeiten sollen, kann ein externer Semantic Layer als Abstraktionsschicht Sinn machen – mit dem Bewusstsein, dass die Power-BI-Integration Kompromisse erfordert. Für reine Microsoft-Umgebungen überwiegen die Nachteile.
Was passiert mit meinen Power BI Reports, wenn Microsoft die Semantic-Model-Architektur ändert?
Power BI Semantic Models basieren auf der Tabular-Engine, die Microsoft seit über zwei Jahrzehnten weiterentwickelt. DAX und das tabellarische Modell sind langfristig stabil. Fabric bringt neue Speichermodi wie Direct Lake, aber das Grundprinzip – Kennzahlen in DAX, Modell in Star-Schema – bleibt das gleiche.
Fazit
Power BI unterstützt keine Third-Party Semantic Models – nicht aus Boshaftigkeit, sondern weil Semantic Models architektonisch nicht dafür gebaut sind, aufeinander zu sitzen. Import bricht die Aggregationslogik, XMLA-Hacks sind unzuverlässig, DirectQuery-Stacking erzeugt unkontrollierbare Komplexität. Der richtige Weg ist Synchronisation: Definitionen übersetzen statt Systeme stapeln. Für Unternehmen im Microsoft-Stack bedeutet das eine klare Empfehlung – DAX als zentrale Kennzahlen-Sprache, Power BI Semantic Models als Single Source of Truth für die Berichtsschicht.
Sie stehen vor der Frage, wie Sie Ihre BI-Architektur zukunftssicher aufstellen? Wir beraten Unternehmen seit über 20 Jahren beim Aufbau skalierbarer BI-Lösungen auf dem Microsoft-Stack. Vereinbaren Sie ein kostenfreies Erstgespräch.
