Oddzielanie raportów od modeli w programie Power BI Desktop

Podczas tworzenia nowego rozwiązania programu Power BI Desktop jedno z pierwszych zadań, które należy wykonać, to "pobieranie danych". Pobieranie danych może skutkować dwoma różnymi wynikami. Może to:

  • Utwórz połączenie na żywo z już opublikowanym modelem, który może być modelem semantycznym usługi Power BI (wcześniej znanym jako zestaw danych) lub modelem usług Analysis Services hostowanych zdalnie.
  • Rozpoczynanie opracowywania nowego modelu, który może być modelem importowym, directquery lub złożonym.

Ten artykuł dotyczy drugiego scenariusza. Zawiera wskazówki dotyczące łączenia raportu i modelu w jeden plik programu Power BI Desktop.

Rozwiązanie do pojedynczego pliku

Pojedyncze rozwiązanie do tworzenia plików działa dobrze, gdy istnieje tylko jeden raport oparty na modelu. W takim przypadku prawdopodobne jest, że zarówno model, jak i raport to wysiłki tej samej osoby. Definiujemy go jako rozwiązanie do analizy biznesowej osobistej, choć raport może być udostępniany innym osobom. Takie rozwiązania mogą reprezentować raporty o zakresie ról lub jednorazowe oceny wyzwania biznesowego — często określane jako raporty ad hoc .

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

Oddzielne pliki raportów

Warto oddzielić tworzenie modeli i raportów na osobne pliki programu Power BI Desktop w następujących przypadkach:

  • Osoby modelające dane i autorzy raportów są różnymi osobami.
  • Rozumie się, że model będzie źródłem wielu raportów, teraz lub w przyszłości.

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.

Osoby modelujące dane mogą nadal używać środowiska tworzenia raportów programu Power BI Desktop do testowania i weryfikowania swoich projektów modeli. Jednak tuż po opublikowaniu pliku w usługa Power BI powinni usunąć raport z obszaru roboczego. Należy pamiętać o usunięciu raportu za każdym razem, gdy ponownie opublikują i zastąpią model semantyczny.

Zachowywanie interfejsu modelu

Czasami zmiany modelu są nieuniknione. Osoby modelające dane muszą zachować ostrożność, a nie przerwać interfejsu modelu. Jeśli tak, możliwe, że powiązane wizualizacje raportu lub kafelki pulpitu nawigacyjnego zostaną przerwane. Uszkodzone wizualizacje pojawiają się jako błędy i mogą powodować frustrację autorów raportów i użytkowników. I gorzej — mogą zmniejszyć zaufanie do danych.

Dlatego ostrożnie zarządzaj zmianami modelu. Jeśli to możliwe, unikaj następujących zmian:

  • Zmiana nazw tabel, kolumn, hierarchii, poziomów hierarchii lub miar.
  • Modyfikowanie typów danych kolumn.
  • Modyfikowanie wyrażeń miar w taki sposób, aby zwracały inny typ danych.
  • Przenoszenie miar do innej tabeli głównej. Wynika to z faktu, że przeniesienie miary może spowodować przerwanie miar o zakresie raportu, które w pełni kwalifikują miary z nazwą tabeli głównej. Nie zalecamy pisania wyrażeń języka DAX przy użyciu w pełni kwalifikowanych nazw miar. Aby uzyskać więcej informacji, zobacz DAX: column and measure references (Język DAX: odwołania do kolumn i miar).

Dodawanie nowych tabel, kolumn, hierarchii, poziomów hierarchii lub miar jest bezpieczne, z jednym wyjątkiem: istnieje możliwość, że nowa nazwa miary może zderzyć się z nazwą miary o zakresie raportu. Aby uniknąć kolizji, zalecamy autorom raportów przyjęcie konwencji nazewnictwa podczas definiowania miar w raportach. Mogą one poprzedzać nazwy miar o zakresie raportu z podkreśleniami lub innymi znakami.

Jeśli musisz wprowadzić zmiany powodujące niezgodność w modelach, zalecamy wykonanie następujących czynności:

Obie opcje umożliwiają szybkie identyfikowanie powiązanych raportów i pulpitów nawigacyjnych. Widok pochodzenia danych jest prawdopodobnie lepszym wyborem, ponieważ można łatwo zobaczyć osobę kontaktową dla każdego powiązanego elementu. W rzeczywistości jest to hiperlink, który otwiera wiadomość e-mail skierowaną do kontaktu.

Zalecamy skontaktowanie się z właścicielem każdego powiązanego elementu, aby poinformować go o wszelkich planowanych zmianach powodujących niezgodność. W ten sposób można je przygotować i przygotować do naprawy i ponownego opublikowania swoich raportów, pomagając zminimalizować przestoje i frustrację.

Aby uzyskać więcej informacji związanych z tym artykułem, zapoznaj się z następującymi zasobami: