Business-Intelligence-Reporting: von der Quelle zum Report

Business-Intelligence-Reporting ist die Pipeline, die Daten aus einem Quellsystem in einen Report verwandelt, den ein Mensch wirklich öffnet und liest. In Power BI und Microsoft Fabric hat diese Pipeline fünf Stufen: Daten laden, modellieren, den Report bauen, ihn in einem Workspace als App bündeln und verteilen, sodass die Leser ihn sehen, ohne danach suchen zu müssen.

Dieser Leitfaden geht jede Stufe durch und zeigt, wie der Aufbau aussieht. Er behandelt weder die Arten von Reports, die ein Unternehmen erstellt (operativ, strategisch, finanziell und so weiter), noch wie man einen schreibt. Dazu finden Sie unsere Leitfäden zu Report-Arten und KPI-Reports. Wenn Sie noch nicht entschieden haben, was Sie bauen oder wie der Rollout ablaufen soll, beginnen Sie mit unserem Leitfaden zur BI-Strategie.

Die fünf Stufen

1. Ingestion. Daten aus einem Quellsystem in eine Form bringen, die Power BI nutzen kann.

2. Semantic Model. Die Tabellen, Beziehungen und Measures festlegen, auf denen der Report läuft.

3. Report. Die Seiten und Visuals bauen, mit denen ein Leser arbeitet.

4. Workspace und App. Den Report veröffentlichen und für eine Zielgruppe bündeln.

5. Distribution. Den Report nach Zeitplan zu den Lesern bringen oder sie benachrichtigen, wenn sich etwas ändert.

Stufe 1: Ingestion

Power Query ist die Ingestion-Schicht in Power BI Desktop. Es verbindet sich mit einer Quelle, wendet eine Folge von Transformationsschritten an und lädt das Ergebnis ins Modell. Jeder Schritt wird aufgezeichnet, sodass dieselbe Transformation bei jedem Refresh erneut läuft, statt von Hand wiederholt zu werden.

let
    Source = Sql.Database("sales-server.database.windows.net", "Sales"),
    Orders = Source{[Schema = "dbo", Item = "Orders"]}[Data],
    FilteredRows = Table.SelectRows(Orders, each [OrderDate] >= #date(2026, 1, 1)),
    ChangedType = Table.TransformColumnTypes(
        FilteredRows,
        {{"OrderDate", type date}, {"Amount", type number}}
    )
in
    ChangedType

Für einen Report, den eine Person nutzt, reicht eine solche Abfrage in der .pbix-Datei. Brauchen mehrere Reports dieselbe bereinigte Quelle, verlagern Sie die Transformation in einen Dataflow Gen2 in Fabric. Sie läuft dann einmal, und jeder Report verweist auf das Ergebnis, statt dieselben Power-Query-Schritte zu wiederholen. Unser Leitfaden zu Dataflows Gen2 vs. Notebooks zeigt, wann ein Dataflow das richtige Werkzeug ist und wann ein Notebook besser zur Transformation passt.

Stufe 2: Das Semantic Model

Im Semantic Model (Power BI nannte es Dataset, bevor Microsoft den Begriff änderte) werden die Tabellen miteinander verknüpft, und jede Berechnung, die ein Report verwendet, wird einmal als Measure definiert, statt in jedem Visual neu gebaut zu werden.

Die meisten Modelle haben die Form eines Sternschemas: eine oder mehrere Faktentabellen mit Transaktionen, verbunden mit Dimensionstabellen mit den Dingen, nach denen Sie aufteilen, etwa Date, Product oder Customer. Unser Leitfaden zu Sternschema vs. Snowflake Schema zeigt, warum diese Form besser performt als eine einzelne breite Tabelle.

Measures werden in DAX geschrieben und im Modell gespeichert, nicht in der Bearbeitungsleiste einer Tabellenkalkulation:

Total Revenue = SUM('Sales'[Amount])

Revenue YoY % =
VAR CurrentRevenue = [Total Revenue]
VAR PriorYearRevenue =
    CALCULATE([Total Revenue], SAMEPERIODLASTYEAR('Date'[Date]))
RETURN
    DIVIDE(CurrentRevenue - PriorYearRevenue, PriorYearRevenue)

SAMEPERIODLASTYEAR funktioniert nur, wenn die Date-Tabelle in Power BI Desktop als Datumstabelle markiert ist, mit einem durchgehenden Datumsbereich ohne Lücken. Unser vollständiger DAX-Leitfaden behandelt Measures, Zeilenkontext und Filterkontext ausführlich.

Stufe 3: Der Report

Der Report ist die Menge der Seiten, die auf dem Semantic Model aufbauen. Jedes Visual auf einer Seite ist an ein oder mehrere Measures und Spalten aus dem Modell gebunden, nicht an eine eigene Kopie der Daten. Beim Bauen des Reports werden Layout, Filter und Interaktivität festgelegt. Der Report selbst enthält aber keine eigenen Daten mehr, sobald er im Service live ist. Er fragt jedes Mal das Semantic Model dahinter ab, wenn ein Leser ihn öffnet oder einen Filter ändert.

Stufe 4: Workspace und App

Ein Workspace ist der Ort, an dem ein Report liegt, sobald er aus Power BI Desktop veröffentlicht wurde. Jeder, der mit dem Report zu tun hat, von der Person, die ihn baut, bis zur Person, die ihn nur ansieht, hat in diesem Workspace eine von vier Rollen:

Ein Workspace ist nicht das, was ein Fachanwender öffnet. Dafür wird der Workspace zu einer App gebündelt: eine kuratierte Sammlung der Reports und Dashboards, die Sie auswählen, mit eigener Navigation, veröffentlicht für eine oder mehrere Zielgruppen. Eine App zu erstellen oder zu aktualisieren, braucht eine Power-BI-Pro- oder Premium-Per-User-Lizenz (PPU). Ein Leser ohne Pro- oder PPU-Lizenz kann diese App nur ansehen, wenn der Workspace dahinter auf einer Premium-Kapazität oder einer Fabric-Kapazität ab F64 läuft. Andernfalls braucht jeder Betrachter eine eigene kostenpflichtige Lizenz. Unser Leitfaden zu Power-BI-Workspaces und Apps und der Leitfaden zu Workspace-Zugriffsrollen behandeln beides genauer.

Stufe 5: Distribution

Bei einer veröffentlichten App muss der Leser sie weiterhin selbst öffnen. Drei Mechanismen bringen Inhalte ohne diesen Schritt zum Leser, und jeder passt zu einer anderen Art von Report:

Um sich selbst auf einen Report zu abonnieren, brauchen Sie nur Zugriff darauf und einen Workspace mit Pro, PPU oder bezahlter Kapazität. Um andere Personen zu abonnieren, brauchen Sie zusätzlich die Rolle Contributor, Member oder Admin in diesem Workspace. Eine Datenwarnung löst nur bei numerischen Karten-, KPI- und Gauge-Kacheln aus, und erst nach dem Refresh der zugrunde liegenden Daten. Auf einem statischen Export funktioniert sie nicht. Mit Power BI Goals legen Sie ein Ziel für einen KPI fest und sehen seinen Status auf einen Blick, ohne dass der Leser Zahlen von Hand vergleicht. Wie ein KPI-Report Scorecards nutzt, behandelt unser Leitfaden zu KPI-Reports.

Wo die Mechanik endet und der Inhalt beginnt

Alles bisher ist die Technik dahinter: wie eine Zahl aus einem Quellsystem in einen Report kommt, den jemand abonnieren kann. Was in diesen Report gehört und welche der fünf Report-Arten er sein soll, ist eine eigene Entscheidung, die unser Leitfaden zu Report-Arten behandelt. Wofür BI-Reporting auf Unternehmensebene gedacht ist, bevor eine dieser fünf Stufen beginnt, behandelt unser Leitfaden zum Aufbau einer BI-Strategie.

FAQs

Was ist BI-Reporting?

BI-Reporting ist der Prozess, Daten aus einem Quellsystem über ein Semantic Model in einen Report zu bringen, den ein Leser öffnen kann, und diesen Report dann nach Zeitplan oder als Benachrichtigung zum Leser zu bringen, statt als einmaligen Export.

Brauche ich Power BI Premium, um Reports an Personen ohne Pro-Lizenz zu verteilen?

Ja, wenn eine App ohne einzelne Pro- oder PPU-Lizenzen angesehen werden soll. Der Workspace hinter der App muss auf einer Premium-Kapazität oder einer Fabric-Kapazität ab F64 laufen. Darunter braucht jeder Betrachter eine eigene kostenpflichtige Lizenz.

Was ist der Unterschied zwischen einem Abonnement und einer Datenwarnung?

Ein Abonnement schickt nach festem Zeitplan einen Snapshot eines Reports oder Dashboards per E-Mail, unabhängig davon, ob sich etwas geändert hat. Eine Datenwarnung benachrichtigt Sie nur, wenn ein bestimmter numerischer Wert auf einer Karten-, KPI- oder Gauge-Kachel eine von Ihnen gesetzte Schwelle überschreitet, und erst nach dem Refresh der Daten dahinter.

Quellen

• Email subscriptions for reports and dashboards - Microsoft Learn

• Set data alerts in the Power BI service - Microsoft Learn

• Publish an app in Power BI - Microsoft Learn

• Roles in workspaces in Power BI - Microsoft Learn