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 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 .
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.
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:
- Wyświetl powiązaną zawartość modelu semantycznego w usługa Power BI.
- Zapoznaj się z widokiem pochodzenia danych w usługa Power BI.
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ę.
Powiązana zawartość
Aby uzyskać więcej informacji związanych z tym artykułem, zapoznaj się z następującymi zasobami: