.png){kind=small}
Semantische Modelle in Power BI
Aktualisiert: 27. Aug.
Ein Power-BI-Bericht zeigt Visualisierungen. Ein semantisches Modell entscheidet dagegen, was Umsatz bedeutet, wie Kunden mit Aufträgen verbunden sind, welche Daten ein Nutzer sehen darf und wie aus technischen Tabellen eine verständliche Geschäftssicht entsteht. Genau deshalb ist das semantische Modell häufig wichtiger für die Qualität einer Power-BI-Lösung als das eigentliche Dashboard.
Microsoft bezeichnet den früheren Inhaltstyp „Dataset“ inzwischen als semantisches Modell. Technisch handelt es sich nicht um ein völlig neues Produkt, sondern um eine Bezeichnung, die die tatsächliche Funktion besser beschreibt: Das Modell bildet die fachliche Bedeutung der Daten ab.
Was ist ein semantisches Modell in Power BI?
Ein semantisches Modell ist die Schicht zwischen Datenquelle und Analyse. Daten können beispielsweise aus SAP, einem Data Warehouse, Microsoft Fabric, SQL Server, Excel oder mehreren Quellen stammen. Das Modell übersetzt diese technischen Strukturen in eine Form, mit der Fachanwender arbeiten können.
Typische Bestandteile sind:
Fakt- und Dimensionstabellen
Beziehungen zwischen Tabellen
Measures und Kennzahlen
Hierarchien und fachliche Strukturen
Formatierungen, Namen und Beschreibungen
Berechnungslogik
Row-Level und Object-Level Security
Metadaten für Reporting und zunehmend auch KI
Microsoft beschreibt Fabric-Semantikmodelle entsprechend als logische Beschreibung eines analytischen Geschäftsbereichs mit Kennzahlen und fachlich verständlicher Terminologie. Der Bericht ist damit nicht die Wahrheitsschicht. Das semantische Modell ist die Stelle, an der festgelegt wird, was die Zahlen bedeuten.
Warum semantische Modelle wichtiger sind als einzelne Reports
Ohne zentrale Modelle entsteht schnell dieselbe Kennzahl mehrfach. Der Vertrieb berechnet Umsatz anders als Controlling, ein zweiter Report verwendet eine andere Kundendefinition und ein drittes Team baut dieselbe DAX-Logik erneut. Technisch funktionieren alle Berichte – fachlich liefern sie unterschiedliche Wahrheiten.
Ein zentrales semantisches Modell verlagert diese Logik aus einzelnen Reports in eine wiederverwendbare Schicht: Datenquelle → semantisches Modell → viele Reports und Analysewerkzeuge. Damit können mehrere Berichte dieselben Measures, Beziehungen und Sicherheitsregeln verwenden. Das ist einer der wichtigsten Hebel für skalierbares Self-Service BI.
Ein gutes semantisches Modell beginnt meist mit einem Sternschema
Microsoft empfiehlt für Power-BI-Modelle weiterhin ein Sternschema. Dimensionstabellen dienen primär zum Filtern und Gruppieren, Faktentabellen zur Aggregation. Beziehungen verbinden beide Ebenen. Ein gut strukturiertes Modell trennt diese Rollen bewusst und hält Faktentabellen auf einem konsistenten Detaillierungsgrad.
Beispiel Vertriebsmodell:
Dimensionen: Kunde, Produkt, Verkäufer, Datum, Region
Faktentabelle: Verkäufe
Measures: Umsatz, Absatz, Marge, Umsatz Vorjahr, Wachstum %
Der Bericht muss dann nicht wissen, wie Umsatz technisch berechnet wird. Er verwendet einfach das zentrale Measure. Das klingt banal, ist aber eine wesentliche Architekturentscheidung.
Measures gehören ins Modell – nicht immer wieder in den Report
Ein semantisches Modell zentralisiert nicht nur Daten, sondern auch Geschäftslogik. Ein Measure wie Umsatz, EBIT oder Auftragseingang sollte deshalb möglichst dort definiert werden, wo es für alle Konsumenten eindeutig zur Verfügung steht.
Die Governance-Frage lautet deshalb nicht: „Kann ich diese Kennzahl im Report berechnen?“ Sondern: „Soll diese Kennzahl für alle Nutzer dieselbe Bedeutung haben?“ Wenn ja, gehört sie meistens ins zentrale Modell.
Vier wichtige Möglichkeiten, wie das Modell auf Daten zugreift
Import – Daten werden in das Power-BI-Semantikmodell geladen. Das bietet in der Regel sehr schnelle interaktive Abfragen, erfordert aber regelmäßige Aktualisierungen.
DirectQuery – die Daten bleiben in der Quelle. Power BI sendet Abfragen zur Laufzeit an das zugrunde liegende System. Performance und Verfügbarkeit hängen damit stärker von der Quelle ab.
Direct Lake – in Microsoft Fabric kann das Modell Delta-Daten in OneLake direkt für die Power-BI-Engine nutzen, ohne einen klassischen Import oder jede Abfrage wie bei DirectQuery an ein Warehouse zu schicken.
Composite Models – ein Modell kombiniert verschiedene Speichermodi oder Datenquellen. So kann ein zentrales Modell wiederverwendet und mit lokalen Tabellen ergänzt werden. Das erhöht Flexibilität, aber auch Komplexität.
Import, DirectQuery oder Direct Lake?
Anforderung | Häufig sinnvoll |
Maximale interaktive Performance | Import |
Daten dürfen nicht kopiert werden | DirectQuery |
Große Fabric-/OneLake-Datenbestände | Direct Lake |
Zentrale Modelle plus lokale Erweiterungen | Composite Model |
Mehrere heterogene Quellen | Import oder Composite |
Nahezu aktuelle Daten | DirectQuery / Direct Lake – je nach Architektur |
Der richtige Speichermodus ergibt sich aus Datenmenge, Aktualitätsanforderung, Architektur, Performance und Governance – nicht daraus, welcher Modus moderner klingt.
Semantisches Modell und Bericht sollten getrennt gedacht werden
Historisch wurden Modell und Bericht häufig gemeinsam in einer PBIX entwickelt. Für größere Umgebungen ist eine bewusstere Trennung meist sinnvoller. Ein zentrales Modell kann einmal im Workspace betrieben werden; verschiedene Teams erstellen anschließend Thin Reports, die dieses Modell konsumieren.
Ein Modell – viele Reports.
einheitliche Measures
weniger redundante Modelle
weniger unnötige Refreshes
klarere Ownership
zentrale Security
einfachere Qualitätssicherung
Über die Build-Berechtigung kann festgelegt werden, wer neue Inhalte auf einem bestehenden semantischen Modell erstellen darf. Build ermöglicht unter anderem neue Reports, Analyze in Excel, Composite Models und weitere Wiederverwendungsszenarien.
Sicherheit gehört ebenfalls ins Modell
Semantische Modelle können auch eine zentrale Security-Ebene bilden. Mit Row-Level Security lässt sich beispielsweise festlegen, dass ein Regionalleiter nur seine Region sieht. Object-Level Security kann Tabellen oder Spalten vollständig vor bestimmten Rollen verbergen.
Dabei muss die Berechtigungskette insgesamt stimmen. Workspace-Rollen, Read-/Build-/Write-Rechte und RLS beziehungsweise OLS lösen unterschiedliche Aufgaben. Den Deep Dive dazu findest du in Berechtigungen in Power BI verstehen.
Power BI Desktop ist nicht mehr der einzige Modellierungsort
Semantische Modelle müssen nicht mehr ausschließlich in Power BI Desktop bearbeitet werden. Microsoft baut die Webmodellierung im Power BI Service und in Fabric kontinuierlich aus. Dort lassen sich unter anderem Beziehungen bearbeiten, Measures hinzufügen und Sicherheitsregeln konfigurieren.
Zusätzlich bietet die TMDL View eine textbasierte Darstellung des Tabular-Modells. Die Desktop-Variante ist inzwischen allgemein verfügbar; die Web-Version entwickelt Microsoft weiter. Damit wird das semantische Modell zunehmend von einer einzelnen PBIX-Komponente zu einem eigenständig verwalteten Analytics-Artefakt.
Fabric erstellt nicht mehr automatisch für jedes Datenobjekt ein Default-Modell
Seit dem 5. September 2025 werden für neue Lakehouses, Warehouses und Mirroring-Items nicht mehr automatisch Power-BI-Default-Semantikmodelle erstellt. Bestehende Default-Semantikmodelle wurden anschließend von ihren ursprünglichen Fabric-Items entkoppelt und sind eigenständige Modelle.
Nicht jedes Datenobjekt braucht automatisch ein eigenes semantisches Modell. Stattdessen sollte bewusst entschieden werden, welche Modelle fachlich benötigt werden und welche Business-Domäne sie abbilden.
Ein semantisches Modell sollte ein Datenprodukt sein
Ein gutes Modell braucht deshalb mehr als Tabellen und DAX. Es braucht Ownership. Für ein zentrales Modell sollten beispielsweise folgende Fragen geklärt sein:
Welche Business-Domäne bildet es ab?
Wer verantwortet die Definitionen?
Welche Kennzahlen sind offiziell?
Wer darf Änderungen vornehmen?
Welche Reports verwenden das Modell?
Welche Security gilt?
Wie werden Änderungen getestet?
Welche Aktualitäts- und Performanceanforderungen bestehen?
Wenn diese Fragen nicht beantwortet werden, wird das Modell zwar technisch wiederverwendbar – aber nicht automatisch vertrauenswürdig.
Was gehört nicht in jedes semantische Modell?
Ein häufiger Fehler besteht darin, möglichst viel in ein einziges Modell zu packen. Das klingt zunächst effizient, führt aber schnell zu einem schwer verständlichen Enterprise-Monolithen. Ein gutes Modell sollte eine kohärente fachliche Domäne abbilden.
Sales, Finance und HR müssen nicht zwangsläufig dasselbe Modell verwenden, nur weil Daten miteinander verbunden werden könnten. Umgekehrt sind zehn fast identische Sales-Modelle ebenfalls kein gutes Ziel.
So zentral wie fachlich sinnvoll, so getrennt wie organisatorisch nötig.
Sonderfall: Ein bestehendes semantisches Modell erweitern
Der ursprüngliche Inhalt dieses Artikels zeigte einen technischen Weg, Tabellen aus einem bestehenden Modell auszulesen und erneut zu importieren. Das kann in Spezialfällen funktionieren, sollte heute aber nicht der erste Architekturansatz sein.
Wenn ein bestehendes Modell erweitert werden soll, gibt es mehrere Optionen:
Thin Report: das zentrale Modell unverändert wiederverwenden.
Composite Model: das bestehende Modell anbinden und mit eigenen Tabellen ergänzen.
XMLA Endpoint: das Modell mit kompatiblen Tools lesen oder – mit passenden Rechten – administrieren.
Gezielter Re-Import: nur wenn Daten wirklich als eigene Kopie benötigt werden und Governance, Berechtigungen und Technik dies zulassen.
Das folgende Video zeigt den ursprünglichen technischen Spezialfall: den gezielten Import von Tabellen aus einem bestehenden Power-BI-Semantikmodell über den Analysis-Services-Zugriff und eine DAX-Query.
Der Ansatz bleibt nützlich, wenn du bewusst eine eigene Datenkopie für weitere Transformationen benötigst. Für Wiederverwendung und Erweiterung sollte aber zuerst geprüft werden, ob Thin Reports oder Composite Models die sauberere Architektur liefern.
Semantische Modelle werden auch für KI wichtiger
Copilot, Data Agents und andere AI-Systeme verändern die Rolle des Semantic Models nochmals. KI braucht nicht nur Daten, sondern verständliche Geschäftsbegriffe, eindeutige Measures, gute Beschreibungen, konsistente Beziehungen und belastbare Security.
Damit wird das Semantic Model zunehmend zur Schnittstelle zwischen Unternehmensdaten und generativer KI. Wie ein Modell dafür vorbereitet wird, behandeln wir ausführlich unter Semantische Modelle AI-ready.
Fazit: Das semantische Modell ist die eigentliche Analytics-Schicht
Ein Power-BI-Report beantwortet eine konkrete Analysefrage. Ein gutes semantisches Modell schafft dagegen die Grundlage dafür, dass viele Analysefragen auf denselben fachlichen Definitionen beantwortet werden.
Es verbindet Datenstruktur, Geschäftslogik, Kennzahlen, Beziehungen, Security, Performance und Wiederverwendung.
Genau deshalb sollten Unternehmen semantische Modelle nicht als technisches Nebenprodukt eines Reports behandeln. Sie sind die zentrale fachliche Analytics-Schicht zwischen Datenplattform und Nutzung.
Der nächste sinnvolle Schritt
Wenn ihr mehrere Power-BI-Berichte betreibt und Kennzahlen, Datenmodelle oder Security immer wieder neu aufgebaut werden, lohnt sich der Blick auf eure Semantic-Model-Architektur.
Im Power BI Coaching können wir konkrete Modelle, Beziehungen, DAX und Performance gemeinsam verbessern. Wenn es stärker um Plattform, Wiederverwendung und Governance geht, ist die Power BI Beratung der passendere Einstieg.
