Einführung in das Power BI-Dashboard
Power BI ist eine komplette Berichtslösung, die in vielen Organisationen verwendet wird, um visuell ansprechende Berichte zu erstellen. Sobald Berichte im Power BI-Service veröffentlicht wurden, stehen sie Geschäftsbenutzern zur Verfügung und helfen ihnen bei der Durchführung von Geschäftsanalysen zu vielen wichtigen Geschäftsproblemen. Mit Power BI können Benutzer auf einfache Weise deskriptive Analysen durchführen, z. B. historische Daten analysieren, um Trends und Muster zu verstehen. Die Erstellung eines Berichts umfasst einige Schritte, deren Komplexität von Fall zu Fall abhängt. Zunächst sollte ein Entwickler festlegen, welche Daten aufgenommen werden sollen, und daraus ein Modell erstellen. Sobald ein Modell fertig ist, kann ein Entwickler beginnen, anhand von Daten mithilfe einer großen Auswahl an Grafiken eine Geschichte zu erzählen. Es muss darauf hingewiesen werden, dass bei der Berichtsentwicklung in der Regel zwischen Gebäudemodell und Gebäudevisualisierung iteriert wird, bis eine zufriedenstellende Reaktionsfähigkeit des Berichts erreicht ist.
Modelldesign für Power BI Dashboard
Ein Entwickler kann mithilfe von Power Query eine Datenintegration aus verschiedenen Quellen durchführen. Es unterstützt viele Quellen wie SharePoint, Azure SQL Server oder Databricks. Die vollständige Liste finden Sie hier. Daten aus verschiedenen Quellen können in einem Bericht als eine oder mehrere Tabellen verwendet werden. Wenn zusätzlich zu den geladenen Daten zusätzliche Transformationen erforderlich sind, können diese mit Power Query auf Low-Code-/No-Code-Weise durchgeführt werden:
Im oberen Menü werden mögliche Transformationen angezeigt (Tabs Home, Transformieren, Spalte hinzufügen). Auf der linken Seite sehen Sie eine Liste aller Power Query-Abfragen in einem Bericht. Der Abschnitt Angewandte Schritte listet alle Schritte für die Abfrage Produkt auf. Jedes Abfrageergebnis ist ein Skalar oder eine Tabelle. In der folgenden Beispielabfrage Products handelt es sich um eine Tabelle, deren Vorschau in der Mitte der Abbildung zu sehen ist. Im einfachsten Szenario erstellt ein Entwickler ein Modell als eine Tabelle. Dieser Ansatz funktioniert für sehr kleine Berichte mit sehr geringem Datenvolumen. In den meisten Fällen muss ein Entwickler jedoch ein Sternmodell mit einer oder mehreren Faktentabellen wie dieser erstellen:
In diesem Beispiel ist die Tabelle Sales eine Faktentabelle und speichert Geschäftsinformationen, die später in den Grafiken des Berichts zusammengefasst werden. Die Faktentabelle ist von Dimensionstabellen umgeben, die im Bericht als Filter verwendet werden und die Aggregation in Grafiken definieren. Die häufigste Verbindung zwischen Tabellen ist 1-*, was auch als „eins zu viele“ bezeichnet wird. Das Symbol 1 befindet sich auf der Seite der Dimensionstabelle und der Tabelle (*), was bedeutet, dass Tabellen durch Spalten verknüpft sind, für die es in der Dimensionstabelle nur Einzelwerte gibt, die sich aber in einer Faktentabelle wiederholen können. Fast alle Verbindungen sind durch durchgezogene Linien definiert, was bedeutet, dass sie aktiv sind und in den Grafiken verwendet werden (sofern sie nicht durch eine Kennzahl geändert werden). In der folgenden Beispieltabelle ist das Datum eine Rollenspieldimension, was bedeutet, dass in der Datumsspalte je nach Situation das Versanddatum oder das Bestelldatum angegeben werden kann. Die gestrichelte Linie im Diagramm zeigt an, dass die Verbindung standardmäßig inaktiv ist und auf der Ebene einer Kennzahl aktiviert werden muss. Im obigen Beispiel ist nur eine Faktentabelle im Modell vorhanden. In einem allgemeineren Fall kann es mehrere Faktentabellen geben, die über eine oder mehrere Dimensionstabellen miteinander verbunden sind. Meistens erstellt ein Entwickler Tabellen im Importmodus, was die beste Leistung garantiert. Wenn das Datenvolumen groß ist, z. B. ein paar hundert Millionen Datensätze oder mehr, oder wenn eine Geschäftsanforderung darin besteht, nahezu in Echtzeit darauf zuzugreifen, ist der optimale Speichermodus die direkte Abfrage. Mit der jüngsten Version der MS Fabric-Plattform ist ein neuer leistungsstarker Speichermodus ins Spiel gekommen: Direct Lake. In Direct Lake stellt ein Bericht eine direkte Verbindung zu spaltenbasierten Parquet-Dateien in Lakehouse her und bietet so die Leistung des Imports und die Aktualität der Daten einer Direktabfrage.
Datensicherheit in Power BI-Dashboards
Bei der Arbeit mit Daten in der Unternehmenswelt ist Sicherheit in der Regel eine der wichtigsten Geschäftsanforderungen. Power BI-Entwickler können ihre Berichte sichern, indem sie sie nur für die erforderlichen Benutzer freigeben. Normalerweise wird der Zugriff auf Berichte von Sicherheitsgruppen und Azure Active Directory implementiert. In einigen Fällen sollte ein Zugriff trotzdem eingeschränkt werden und Benutzer sollten nur einen Teil eines Berichts sehen. Dies kann durch RLS-Rollen (Row Level Security) erreicht werden. Sobald RLS eingerichtet ist, kann beispielsweise ein Benutzer nur Daten für Europa und ein anderer nur Daten für die USA sehen. Rollen können in Power BI Desktop mithilfe von Rollen verwalten definiert werden:
Datenvisualisierung
Sobald das Modell erstellt und gesichert ist, kann ein Entwickler beginnen, Grafiken mit Daten zu füllen.
Bericht
Berichte sind die gängigste Methode, mit der Entwickler Daten visualisieren. Ein Entwickler kann zwischen vielen leistungsstarken Grafiken wählen:
Man kann Linien- und Balkendiagramme verwenden, um kategoriale Informationen oder Zeitreiheninformationen anzuzeigen. In fast jedem Bericht verwendet der Entwickler visuelle Filter, wodurch Berichte dynamisch werden. Tabellen können als Tabellen- oder Matrixgrafiken dargestellt werden. Es gibt auch viele spezielle visuelle Elemente, die in verschiedenen Situationen verwendet werden. Für die Verwaltung von KPIs können zum Beispiel Grafikkarten verwendet werden:
Sobald ein Entwickler eine angemessene Zeit verbringt, kann eine Berichtsseite wie folgt aussehen:
Innerhalb von Berichten kann man viele Seiten erstellen. Um den Bericht mit Benutzern zu teilen, veröffentlicht ein Entwickler ihn im Power BI-Dienst.
Armaturenbrett
Um Berichte auf einer Seite zusammenzufassen, können Sie das interaktive Dashboard im Power BI-Dienst verwenden:
Alle Grafiken können aus einem oder mehreren Berichten stammen. An das Dashboard angeheftete Grafiken zeigen den aktuellen Status der Grafiken aus übergeordneten Berichten.
BI für Mobilgeräte
Normalerweise konsumieren Benutzer Berichte auf großen Bildschirmen, z. B. 14“ >=. Es besteht jedoch auch die Möglichkeit, sie mit Smartphones zu konsumieren:
Man muss bedenken, dass die mobile Ansicht nicht automatisch erstellt wird und ein Entwickler sie zuvor aus ausgewählten Berichtsbildern erstellen muss. Außerdem sollte eine spezielle App installiert werden, um die Nutzung von Berichten auf einem Smartphone zu ermöglichen.
Power BI-App
Normalerweise müssen Benutzer Zugriff auf viele Berichte haben. Jeder Bericht hat seinen eigenen Link. Um die Anzahl der Links zu reduzieren, mit denen ein Benutzer umgehen muss, kann ein Entwickler Berichte in der Power BI-App gruppieren:
Ein weiterer Vorteil der Power BI App besteht darin, dass sie Entwicklungs- und Produktionsumgebungen für Berichte voneinander trennt: Änderungen an der Berichtsdarstellung sind für Benutzer erst sichtbar, nachdem die App aktualisiert wurde. Dies kann sehr nützlich sein, wenn ein Entwickler mit ausgewählten Geschäftsanwendern ein neues Bild in einem Bericht besprechen möchte, aber nicht möchte, dass alle Benutzer es in einem so frühen Stadium sehen.
CI/CD für Power BI-Berichte
Power Bi-Entwickler können Versionierungssysteme wie Git und den CI/CD-Ansatz verwenden, um die Qualität von Berichten zu verbessern. Kürzlich wurde dem Power BI-Desktop eine neue Funktion hinzugefügt, die es ermöglicht, einen Bericht als einzelne Klartextdateien in einem intuitiven Strukturordner zu speichern. Um dies zu tun, sollte ein Entwickler beim Speichern die Option Power BI-Projekt (PBIP) wählen:
Sobald ein Bericht als PBIP gespeichert ist, wird er als hierarchische Ordnerstruktur gespeichert, die sowohl das semantische Modell als auch den Bericht enthält:
Ein Entwickler kann ein Azure DEV OPS-Repo erstellen und jede Änderung eines Berichts darin festschreiben. In einem Fabric-fähigen Arbeitsbereich kann man das Berichtselement mit dem Repo synchronisieren
Ein Entwickler kann lokale Änderungen in PBIP an Azure DEV OPS Git übertragen und dann Fabric Workspace besuchen und sie mit Repo synchronisieren. Ein Entwickler kann bei Bedarf im Fabric Workspace zwischen Git-Branches wechseln. Um dem CI/CD-Ansatz (Continuous Integration and Continues Deployment) zu folgen, kann ein Entwickler eine Bereitstellungspipeline mit drei Umgebungen wie der folgenden erstellen:
Für jede Umgebung wird ein anderer Power BI Premium- oder Fabric-Arbeitsbereich verwendet. Das folgende Bild zeigt ein Beispiel für eine solche Pipeline:
Normalerweise werden für die Entwicklungsumgebung nur Beispieldaten in Berichte geladen und alle Daten in Test- und Produktionsumgebungen. Wenn eine neue Funktion zur Entwicklungsumgebung hinzugefügt wird, kann sie in der Testumgebung bereitgestellt werden. Sobald sie getestet wurde, kann sie in der Produktionsumgebung bereitgestellt werden. Im Falle einer Produktionsumgebung kann ein Entwickler die Power BI-App verwenden, um Berichte mit Benutzern zu teilen.
Datenqualitätsmanagement: Best Practices & Tools.
