Trennen von Berichten und Modellen in Power BI Desktop

  • Artikel

Wenn Sie eine neue Power BI Desktop-Lösung erstellen besteht einer der ersten Schritte in der Datenbeschaffung. Die Datenbeschaffung kann zu zwei deutlich unterschiedlichen Ergebnissen führen. Folgendes ist möglich:

  • Erstellen Sie eine Liveverbindung mit einem bereits veröffentlichten Modell, das entweder ein Power BI semantisches Modell (zuvor als Dataset bezeichnet) oder ein aus der Ferne gehostetes Analysis Services-Modell sein kann.
  • Sie können mit der Entwicklung eines neuen Modells beginnen, bei dem es sich entweder um ein Importmodell, ein DirectQuery-Modell oder ein zusammengesetztes Modell handeln kann.

In diesem Artikel wird das zweite Szenario behandelt. Er bietet Entscheidungshilfen, ob ein Bericht und ein Modell in einer einzigen Power BI Desktop-Datei kombiniert werden sollten.

Lösung mit einer einzelnen Datei

Eine Lösung mit einer einzelnen Datei funktioniert gut, wenn nur ein einzelner Bericht auf Grundlage des Modells vorhanden ist. In diesem Fall ist es wahrscheinlich, dass sowohl das Modell als auch der Bericht von derselben Person stammen. Wir definieren das als persönliche BI-Lösung, obwohl der Bericht für andere freigegeben werden könnte. Solche Lösungen können Berichte für bestimmte Rollen oder einmalige Bewertungen einer geschäftlichen Herausforderung sein. Diese werden häufig als Ad-hoc-Berichte beschrieben.

A single file contains a model and report, developed by the same person.

Separate Berichtsdateien

Es ist in folgenden Fällen sinnvoll, die Modell- und Berichtsentwicklung in separate Power BI Desktop-Dateien aufzuteilen:

  • wenn es sich bei den Datenmodellierern und Berichtsautoren um verschiedene Personen handelt
  • wenn bekannt ist, dass das Modell jetzt oder zukünftig als Quelle für mehrere Berichte eingesetzt wird

There are three PBIX files. The first contains only a model. The other two contain only reports, and they live connect to the model hosted in the Power BI service. The reports are developed by different people.

Datenmodellierer können weiterhin die Power BI Desktop-Features für die Berichterstellung verwenden, um Ihre Modellentwürfe zu testen und zu validieren. Allerdings sollten sie den Bericht direkt nach der Veröffentlichung der Datei im Power BI-Dienst aus dem Arbeitsbereich entfernen. Sie müssen außerdem daran denken, den Bericht jedes Mal zu entfernen, wenn das semantische Modell überschrieben oder erneut veröffentlicht wird.

Beibehalten der Modellschnittstelle

Manchmal sind Modelländerungen unvermeidlich. Datenmodellierer müssen darauf achten, dass die Modellschnittstelle weiterhin funktioniert. Andernfalls kann die Funktionsweise von abhängigen Berichtsvisuals oder Dashboardkacheln beeinträchtigt werden. Fehlerhafte Visuals werden als Fehler angezeigt und können für Berichtsautoren und Anwender frustrierend sein. Schlimmer noch: Sie können das Vertrauen in die Daten schmälern.

Gehen Sie bei Modelländerungen daher sorgfältig vor. Vermeiden Sie nach Möglichkeit die folgenden Änderungen:

  • das Umbenennen von Tabellen, Spalten, Hierarchien, Hierarchieebenen oder Measures
  • das Ändern von Spaltendatentypen
  • das Ändern von Measureausdrücken, sodass diese einen anderen Datentyp zurückgeben
  • Das Verschieben von Measures in eine andere Hometabelle, da sonst berichtsbezogene Measures nicht mehr funktionieren könnten, die Measures mit ihrem Hometabellennamen vollständig qualifizieren. Es wird nicht empfohlen, DAX-Ausdrücke mithilfe von vollqualifizierten Measurenamen zu schreiben. Weitere Informationen finden Sie unter DAX: Spalten- und Measureverweise.

Das Hinzufügen neuer Tabellen, Spalten, Hierarchien, Hierarchieebenen oder Measures ist mit einer Ausnahme sicher: Es ist möglich, dass ein neuer Measurename in Konflikt mit einem Measurenamen im Bereich des Berichts steht. Es wird empfohlen, dass Berichtsautoren beim Definieren von Measures in ihren Berichten eine Benennungskonvention anwenden, um Konflikte zu vermeiden. Sie können berichtsbezogenen Measurenamen einen Unterstrich oder andere Zeichen voranstellen.

Wenn Sie Breaking Changes an Ihren Modellen vornehmen müssen, empfehlen wir Ihnen Folgendes:

Beide Optionen ermöglichen es Ihnen, alle zugehörigen Berichte und Dashboards schnell zu identifizieren. Die Ansicht „Datenherkunft“ ist wahrscheinlich die bessere Wahl, da Sie dort schnell und einfach die Kontaktperson für jedes zugehörige Element ermitteln können. Tatsächlich handelt es sich um einen Hyperlink, der eine E-Mail-Nachricht öffnet, die an den Kontakt gerichtet ist.

Es wird empfohlen, dass Sie sich an den Besitzer jedes zugehörigen Elements wenden, damit diese über alle geplanten Breaking Changes Bescheid wissen. Auf diese Weise können sie sich darauf vorbereiten, ihre Berichte zu korrigieren und erneut zu veröffentlichen, um Ausfallzeiten und Unzufriedenheit auf Anwenderseite zu minimieren.

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Ressourcen: