Korzystanie z modeli złożonych w usłudze Power BI

Semantyczne modele usługi Power BI mogą zawierać tabele z co najmniej jednego źródła danych przy użyciu dowolnego z obsługiwanych trybów przechowywania tabel. Gdy tabele używają różnych trybów przechowywania, model jest modelem semantycznym złożonym. W przypadku trybu przechowywania tabel DirectQuery model jest złożony, gdy tabele DirectQuery używają różnych źródeł danych.

Jeśli na przykład łączysz się z innym modelem semantycznym usługi Power BI przy użyciu trybu DirectQuery (który dodaje tabele w trybie przechowywania DirectQuery), a także tabele lokalne w trybie importu, model staje się modelem złożonym, ponieważ zawiera tabele z różnymi trybami przechowywania.

Typy modeli złożonych

Różne typy modeli złożonych istnieją w zależności od kombinacji trybów przechowywania tabel w modelu semantycznym. Każdy typ ma własne zagadnienia dotyczące funkcjonalności i narzędzi.

Tworzenie modeli złożonych w programie Power BI Desktop

W programie Power BI Desktop można tworzyć modele semantyczne przy użyciu tabel importu lub trybu DirectQuery lokalnie. Następnie możesz dodać więcej tabel za pomocą przycisku wstążki Pobierz dane w innym trybie przechowywania, aby utworzyć model złożony.

Dodanie tabel Trybu DirectQuery z innego modelu semantycznego usługi Power BI ma kilka różnych ścieżek tworzenia.

1. W pustym pliku usługi Power BI najpierw połącz się z semantycznym modelem usługi Power BI. Po nawiązaniu połączenia na żywo możesz wprowadzić zmiany w tym modelu. Wybranie pozycji Wprowadź zmiany w tym modelu na wstążce lub stopce konwertuje połączenie na żywo na połączenie DirectQuery. Połączenie DirectQuery tworzy nowy lokalny model semantyczny z tabelami w trybie przechowywania DirectQuery. Możesz dodawać nowe tabele w trybie przechowywania import lub DirectQuery, a także umożliwiać zastąpienie niektórych właściwości kolumn w modelu semantycznym źródła.

2. W modelu semantycznym z tabelami już zaimportowanymi lub DirectQuery połącz się z semantycznym modelem usługi Power BI, a wybrane tabele zostaną dodane jako DirectQuery.

Semantyczne modele utworzone za pomocą tabel usługi Direct Lake są edytowane na żywo w programie Power BI Desktop. Możesz dodać więcej tabel usługi Direct Lake. Aby dodać tabele importu, otwórz model semantyczny w modelowaniu internetowym usługi Power BI. Aby dodać tabele DirectQuery, użyj kodu XMLA.

Możesz edytować na żywo Direct Lake i importować model semantyczny w aplikacji Desktop, ale nie można dodać więcej tabel. Tabele można dodawać tylko z modelowania internetowego usługi Power BI dla usługi Direct Lake i importować modele złożone.

Tworzenie modeli złożonych w modelowaniu internetowym

W modelowaniu internetowym usługi Power BI można tworzyć modele semantyczne z tabelami importu lub Direct Lake. Nie można dodawać tabel DirectQuery. Aby utworzyć model złożony, możesz dodać więcej tabel w innym trybie przechowywania.

Korzystanie z modeli złożonych

Modele złożone umożliwiają łączenie się z różnymi rodzajami źródeł danych w przypadku korzystania z programu Power BI Desktop lub usługa Power BI. Te połączenia danych można nawiązać na kilka sposobów:

• Importując dane do usługi Power BI, która jest najczęstszym sposobem pobierania danych.
• Łącząc się bezpośrednio z danymi w oryginalnym repozytorium źródłowym przy użyciu zapytania bezpośredniego. Aby dowiedzieć się więcej na temat trybu DirectQuery, zobacz Zapytanie bezpośrednie w usłudze Power BI.

W przypadku korzystania z trybu DirectQuery modele złożone umożliwiają utworzenie modelu usługi Power BI, takiego jak pojedynczy plik pbix programu Power BI Desktop, który wykonuje jedną lub obie następujące akcje:

• Łączy dane z co najmniej jednego źródła trybu DirectQuery.
• Łączy dane ze źródeł trybu DirectQuery i importuje dane.

Na przykład przy użyciu modeli złożonych można utworzyć model, który łączy następujące typy danych:

• Dane sprzedaży z magazynu danych przedsiębiorstwa.
• Dane docelowe sprzedaży z działu bazy danych programu SQL Server.
• Dane zaimportowane z arkusza kalkulacyjnego.

Semantyczny model łączący tabele z więcej niż jednego źródła DirectQuery lub łączący tabele DirectQuery, Direct Lake i importujące jest modelem semantycznym złożonym.

Relacje między tabelami można tworzyć tak, jak zawsze, nawet jeśli te tabele pochodzą z różnych źródeł. Wszystkie relacje, które są źródłem krzyżowym, są tworzone z kardynalnością wiele-do-wielu, niezależnie od ich rzeczywistej kardynalności. Można je zmienić na jeden do wielu, wiele do jednego lub jeden do jednego. Niezależnie od ustawionej kardynalności relacje między źródłami mają inne zachowanie. Nie można używać funkcji języka DAX (Data Analysis Expressions) do pobierania wartości one po many stronie strony. Może być również widoczny wpływ na wydajność w porównaniu z relacjami wiele-do-wielu w tym samym źródle.

Przykład modelu złożonego

Przykładem modelu złożonego jest raport łączący się z firmowym magazynem danych w programie SQL Server przy użyciu trybu DirectQuery. W tym przypadku magazyn danych zawiera dane Sales by Country, Quarter i Bike (Product), jak pokazano na poniższej ilustracji:

W tym momencie można utworzyć proste wizualizacje przy użyciu pól z tego źródła. Na poniższej ilustracji przedstawiono łączną sprzedaż według productName dla wybranego kwartału.

Ale co zrobić, jeśli masz dane w arkuszu kalkulacyjnym programu Excel dotyczące menedżera produktu przypisanego do każdego produktu wraz z priorytetem marketingu? Jeśli chcesz wyświetlić kwotę sprzedaży według Menedżera produktu, może nie być możliwe dodanie tych danych lokalnych do magazynu danych firmowych. Może to potrwać miesiące w najlepszym razie.

Może być możliwe zaimportowanie tych danych sprzedaży z magazynu danych zamiast używania trybu DirectQuery. Dane sprzedaży można następnie połączyć z danymi zaimportowanymi z arkusza kalkulacyjnego. Jednak takie podejście jest nieuzasadnione, ze względów, które doprowadziły do korzystania z trybu DirectQuery w pierwszej kolejności. Przyczyny mogą obejmować:

• Niektóre kombinacje reguł zabezpieczeń wymuszanych w bazowym źródle.
• Musi być w stanie wyświetlić najnowsze dane.
• Sama skala danych.

Tutaj pojawiają się modele złożone. Modele złożone umożliwiają nawiązywanie połączenia z magazynem danych przy użyciu trybu DirectQuery, a następnie używanie funkcji Pobierz dane w celu uzyskania większej liczby źródeł. W tym przykładzie najpierw ustanowimy połączenie DirectQuery z firmowym magazynem danych. Użyjemy pozycji Pobierz dane, wybierz pozycję Excel, a następnie przejdź do arkusza kalkulacyjnego zawierającego nasze dane lokalne. Na koniec zaimportujemy arkusz kalkulacyjny zawierający nazwy produktów, przypisany menedżer sprzedaży i priorytet.

Na liście Pola można wyświetlić dwie tabele: oryginalną tabelę Rower z programu SQL Server i nową tabelę ProductManagers. Nowa tabela zawiera dane zaimportowane z programu Excel.

Podobnie w widoku Relacja w programie Power BI Desktop zobaczymy teraz kolejną tabelę o nazwie ProductManagers.

Teraz musimy powiązać te tabele z innymi tabelami w modelu. Jak zawsze tworzymy relację między tabelą Bike (Rower) z programu SQL Server i zaimportowaną tabelą ProductManagers (Menedżerowie produktów). Oznacza to, że relacja jest między Bike[ProductName] i ProductManagers[ProductName]. Jak wspomniano wcześniej, wszystkie relacje, które przechodzą przez domyślną wartość źródłową do kardynalności wiele do wielu.

Po ustanowieniu tej relacji jest ona wyświetlana w widoku Relacja w programie Power BI Desktop, zgodnie z oczekiwaniami.

Teraz możemy tworzyć wizualizacje przy użyciu dowolnego pola na liście Pola . Takie podejście bezproblemowo łączy dane z wielu źródeł. Na przykład łączna kwota SalesAmount dla każdego Menedżera produktu jest wyświetlana na poniższej ilustracji:

W poniższym przykładzie przedstawiono typowy przypadek tabeli wymiarów, na przykład Product (Produkt) lub Customer (Klient), która została rozszerzona o dodatkowe dane zaimportowane z innego miejsca. Tabele mogą również używać trybu DirectQuery do łączenia się z różnymi źródłami. Aby kontynuować pracę z naszym przykładem, załóżmy, że cele sprzedaży na kraj i okres są przechowywane w oddzielnej bazie danych działu. Jak zwykle możesz użyć opcji Pobierz dane , aby nawiązać połączenie z danymi, jak pokazano na poniższej ilustracji:

Tak jak wcześniej, możemy utworzyć relacje między nową tabelą a innymi tabelami w modelu. Następnie możemy utworzyć wizualizacje, które łączą dane tabeli. Przyjrzyjmy się ponownie widokowi Relacje , w którym utworzyliśmy nowe relacje:

Następny obraz jest oparty na nowo utworzonych danych i relacjach. Wizualizacja w lewym dolnym rogu pokazuje łączną kwotę sprzedaży w porównaniu z wartością Target, a obliczenie wariancji pokazuje różnicę. Dane Sales Amount i Target pochodzą z dwóch różnych baz danych programu SQL Server.

Ustawianie trybu przechowywania

Każda tabela w modelu złożonym ma tryb przechowywania, który wskazuje, czy tabela jest oparta na trybie DirectQuery, czy importowaniu. Tryb przechowywania można wyświetlić i zmodyfikować w okienku Właściwości . Aby wyświetlić tryb przechowywania:

1. W widoku Model wybierz tabelę.
2. W okienku Właściwości rozwiń sekcję Zaawansowane , a następnie rozwiń listę Tryb przechowywania .

Tryb przechowywania można również wyświetlić w etykietce narzędzia dla każdej tabeli po umieszczeniu wskaźnika myszy na niej w okienku Dane .

W przypadku dowolnego pliku programu Power BI Desktop ( pliku pbix ), który zawiera niektóre tabele z trybu DirectQuery i niektórych tabel importu, na pasku stanu jest wyświetlany tryb przechowywania o nazwie Mieszane. Możesz wybrać ten termin na pasku stanu i łatwo przełączyć wszystkie tabele do zaimportowania.

Aby uzyskać więcej informacji na temat trybu przechowywania, zobacz Zarządzanie trybem przechowywania w programie Power BI Desktop.

tabele obliczeniowe,

Tabele obliczeniowe można dodać do modelu w programie Power BI Desktop, który używa trybu DirectQuery. Wyrażenia analizy danych (DAX), które definiują tabelę obliczeniową, mogą odwoływać się do zaimportowanych lub bezpośrednich tabel albo kombinacji tych dwóch tabel.

Tabele obliczeniowe są zawsze importowane, a ich dane są odświeżane podczas odświeżania tabel. Jeśli tabela obliczeniowa odwołuje się do tabeli DirectQuery, wizualizacje odwołujące się do tabeli DirectQuery zawsze pokazują najnowsze wartości w bazowym źródle. Alternatywnie wizualizacje odwołujące się do tabeli obliczeniowej pokazują wartości w czasie ostatniego odświeżenia tabeli obliczeniowej.

Implikacje dotyczące zabezpieczeń

Modele złożone mają pewne konsekwencje w zakresie zabezpieczeń. Zapytanie wysyłane do jednego źródła danych może zawierać wartości danych, które są pobierane z innego źródła. We wcześniejszym przykładzie wizualizacja przedstawiająca (Sales Amount) według Menedżera produktu wysyła zapytanie SQL do relacyjnej bazy danych Sales. To zapytanie SQL może zawierać nazwy menedżerów produktów i skojarzonych z nimi produktów.

Dlatego informacje przechowywane w arkuszu kalkulacyjnym są teraz uwzględniane w zapytaniu wysyłanym do relacyjnej bazy danych. Jeśli te informacje są poufne, należy wziąć pod uwagę implikacje dotyczące zabezpieczeń. W szczególności należy wziąć pod uwagę następujące kwestie:

• Każdy administrator bazy danych, który może wyświetlać ślady lub dzienniki inspekcji, może wyświetlać te informacje, nawet bez uprawnień do danych w oryginalnym źródle. W tym przykładzie administrator musi mieć uprawnienia do pliku programu Excel.

• Ustawienia szyfrowania dla każdego źródła. Chcesz uniknąć pobierania informacji z jednego źródła przez zaszyfrowane połączenie, a następnie przypadkowo dołączać je do zapytania wysłanego do innego źródła przez nieszyfrowane połączenie.

Aby potwierdzić, że rozważyłeś wszelkie implikacje związane z bezpieczeństwem, program Power BI Desktop wyświetla komunikat ostrzegawczy, gdy tworzysz model złożony.

Ponadto jeśli autor dodaje tabelę Table1 z modelu A do modelu złożonego (nazwijmy go modelem C do celów referencyjnych), wówczas użytkownik wyświetlający raport oparty na modelu C może wykonać zapytanie względem dowolnej tabeli w modelu A , która nie jest chroniona przez zabezpieczenia na poziomie wiersza (RLS).

Z podobnych powodów należy zachować ostrożność podczas otwierania pliku programu Power BI Desktop wysłanego ze źródła niezaufanego. Jeśli plik zawiera modele złożone, informacje pobierane przez osobę z jednego źródła przy użyciu poświadczeń użytkownika, który otwiera plik, są wysyłane do innego źródła danych w ramach zapytania. Złośliwy autor pliku programu Power BI Desktop może wyświetlić informacje. Po początkowym otwarciu pliku programu Power BI Desktop zawierającego wiele źródeł program Power BI Desktop wyświetli ostrzeżenie. Ostrzeżenie jest podobne do wyświetlanego podczas otwierania pliku zawierającego natywne zapytania SQL.

Implikacje dotyczące wydajności

W przypadku korzystania z trybu DirectQuery zawsze należy wziąć pod uwagę wydajność. Upewnij się, że źródło zaplecza ma wystarczającą ilość zasobów, aby zapewnić użytkownikom dobre środowisko pracy. Dobre środowisko oznacza, że wizualizacje są odświeżane w ciągu pięciu sekund lub mniej. Aby uzyskać więcej porad dotyczących wydajności, zobacz Zapytanie bezpośrednie w usłudze Power BI.

Użycie modeli złożonych dodaje inne zagadnienia dotyczące wydajności. Pojedyncza wizualizacja może wysyłać zapytania do wielu źródeł. Często jedno zapytanie przekazuje wyniki do drugiego źródła. Taka sytuacja może spowodować wykonanie następujących form:

• Zapytanie źródłowe zawierające dużą liczbę wartości literałów: na przykład wizualizacja, która żąda łącznej kwoty sprzedaży dla zestawu wybranych menedżerów produktów , najpierw będzie musiała znaleźć , którymi produktami zarządzają menedżerowie produktów. Ta sekwencja musi wystąpić, zanim wizualizacja wyśle zapytanie SQL zawierające wszystkie identyfikatory produktów w klauzuli WHERE .

• Zapytanie źródłowe, które wykonuje zapytania na niższym poziomie szczegółowości, a dane są później agregowane lokalnie: W miarę wzrostu liczby produktów spełniających kryteria filtrowania w Menedżerze produktu może stać się nieefektywne lub niewykonalne, aby uwzględnić wszystkie produkty w WHERE klauzuli . Zamiast tego możesz wykonać zapytanie względem źródła relacyjnego na niższym poziomie produktów , a następnie zagregować wyniki lokalnie. Jeśli kardynalność produktów przekroczy limit 1 miliona, zapytanie zakończy się niepowodzeniem.

• Wiele zapytań źródłowych, po jednej na grupę według wartości: jeśli agregacja używa funkcji DistinctCount i jest grupowana według kolumny z innego źródła, a źródło zewnętrzne nie obsługuje wydajnego przekazywania wielu wartości literałów definiujących grupowanie, należy wysłać jedno zapytanie SQL na grupę według wartości.

  Wizualizacja, która żąda odrębnej liczby wartości CustomerAccountNumber z tabeli programu SQL Server, musi przekazać szczegóły z tabeli menedżerów produktów zaimportowanych z arkusza kalkulacyjnego w zapytaniu wysłanym do programu SQL Server. Na przykład w przypadku innych źródeł redshift ta akcja jest niewykonalna. Zamiast tego będzie wysyłane jedno zapytanie SQL na menedżera sprzedaży, do pewnego praktycznego limitu, w którym zapytanie zakończy się niepowodzeniem.

Każdy z tych przypadków ma własne konsekwencje dla wydajności, a dokładne szczegóły różnią się w zależności od źródła danych. Mimo że kardynalność kolumn używanych w relacji, która łączy dwa źródła, pozostaje niska (kilka tysięcy), nie powinno to wpływać na wydajność. W miarę wzrostu kardynalności należy zwrócić większą uwagę na wpływ na wydajność.

Ponadto użycie relacji wiele-do-wielu oznacza, że oddzielne zapytania muszą być wysyłane do bazowego źródła dla każdego poziomu sumy lub sumy częściowej, a nie agregowania szczegółowych wartości lokalnie. Prosta wizualizacja tabeli z sumami wysyła dwa zapytania źródłowe, a nie jedno.

Grupy źródłowe

Grupa źródłowa to kolekcja elementów, takich jak tabele i relacje, ze źródła trybu DirectQuery lub wszystkich źródeł importu zaangażowanych w model danych. Model złożony składa się z co najmniej jednej grupy źródłowej. Rozważ następujące przykłady:

• Model złożony łączący się z semantycznym modelem usługi Power BI o nazwie Sales i wzbogaca model semantyczny przez dodanie miary Sales YTD , która nie jest dostępna w oryginalnym modelu semantycznym. Ten model składa się z jednej grupy źródłowej.
• Model złożony, który łączy dane, importując tabelę z arkusza programu Excel o nazwie Targets i plik CSV o nazwie Regiony oraz tworząc połączenie DirectQuery z semantycznym modelem usługi Power BI o nazwie Sales. W tym przypadku istnieją dwie grupy źródłowe, jak pokazano na poniższej ilustracji:
  • Pierwsza grupa źródłowa zawiera tabele z arkusza Programu Excel Targets i plik CSV Regionów .
  • Druga grupa źródłowa zawiera elementy z modelu semantycznego usługi Power BI Sales .

Jeśli dodasz kolejne połączenie DirectQuery z innym źródłem, takie jak połączenie zapytania bezpośredniego z bazą danych programu SQL Server o nazwie Inventory, elementy z tego źródła zostaną dodane jako inna grupa źródłowa:

Grupy źródłowe i relacje

Model złożony ma dwa typy relacji:

• Relacje wewnątrz grupy źródłowej. Te relacje łączą elementy w grupie źródłowej. Te relacje są zawsze zwykłymi relacjami, chyba że są one relacjami wiele-do-wielu, w tym przypadku są one ograniczone.
• Relacje między grupami źródłowymi. Te relacje rozpoczynają się w jednej grupie źródłowej i kończą się w innej grupie źródłowej. Te relacje są zawsze ograniczone.

Przeczytaj więcej na temat rozróżnienia między regularnymi i ograniczonymi relacjami a ich wpływem.

Na przykład na poniższej ilustracji dodaliśmy trzy relacje między różnymi grupami źródeł, łączące tabele w różnych grupach źródłowych.

Lokalne i zdalne

Każdy element w grupie źródłowej, która jest grupą źródłową DirectQuery, jest zdalny, chyba że element jest definiowany lokalnie jako część rozszerzenia lub wzbogacania źródła DirectQuery i nie jest częścią źródła zdalnego, takiego jak miara lub tabela obliczeniowa. Tabela obliczeniowa oparta na tabeli z grupy źródłowej DirectQuery należy do grupy źródłowej "Importuj" i jest lokalna. Każdy element w grupie źródłowej "Importuj" jest lokalny. Jeśli na przykład zdefiniujesz następującą miarę w modelu złożonym, który używa połączenia DirectQuery ze źródłem spisu, miara jest lokalna:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Grupy obliczeń, zapytania i ocena miar

Grupy obliczeń pomagają zmniejszyć liczbę nadmiarowych miar i grupować wspólne wyrażenia miar. Typowe przypadki użycia to obliczenia inteligencji czasowej, w których chcesz przełączyć się z danych rzeczywistych do obliczeń miesiąc do dnia, kwartał do dnia lub rok do dnia. Podczas pracy z modelami złożonymi należy pamiętać o interakcji między grupami obliczeń i o tym, czy miara odnosi się tylko do elementów z pojedynczej zdalnej grupy źródłowej. Jeśli miara odwołuje się tylko do elementów z pojedynczej zdalnej grupy źródłowej, a model zdalny definiuje grupę obliczeń, która ma wpływ na miarę, zostanie zastosowana grupa obliczeń, nawet jeśli zdefiniujesz miarę w modelu zdalnym lub w modelu lokalnym. Jeśli jednak miara nie odwołuje się wyłącznie do elementów z pojedynczej zdalnej grupy źródłowej, ale odwołuje się do elementów z zdalnej grupy źródłowej, na której jest stosowana zdalna grupa obliczeń, wyniki miary mogą nadal mieć wpływ na zdalną grupę obliczeń. Rozważmy następujący przykład:

• Reseller Sales to miara zdefiniowana w modelu zdalnym.
• Model zdalny zawiera grupę obliczeń, która zmienia wynik sprzedaży odsprzedawcy.
• Sprzedaż internetowa to miara zdefiniowana w modelu lokalnym.
• Total Sales to miara zdefiniowana w modelu lokalnym i ma następującą definicję:

[Total Sales] = [Internet Sales] + [Reseller Sales]

W tym scenariuszu miara Sprzedaż internetowa nie ma wpływu na grupę obliczeń zdefiniowaną w modelu zdalnym, ponieważ nie są one częścią tego samego modelu. Jednak grupa obliczeń może zmienić wynik miary Reseller Sales, ponieważ znajduje się w tym samym modelu. Oznacza to, że wyniki zwrócone przez miarę Total Sales muszą być dokładnie ocenione. Wyobraź sobie, że używasz grupy obliczeń w zdalnym modelu do zwracania wyników od początku roku. Wynik zwrócony przez odsprzedawcę Sales jest teraz wartością od roku do daty, podczas gdy wynik zwrócony przez sprzedaż internetową jest nadal rzeczywisty. Wynik łącznej sprzedaży jest teraz prawdopodobnie nieoczekiwany, ponieważ dodaje wartość rzeczywistą do wyniku od początku roku.

Modele złożone w semantycznych modelach usługi Power BI i usługach Analysis Services

Korzystając z modeli złożonych z semantycznymi modelami usługi Power BI i usługami Analysis Services, można utworzyć model złożony przy użyciu połączenia DirectQuery w celu nawiązania połączenia z modelami semantycznymi usługi Power BI, usługami Azure Analysis Services (AAS) i usługami SQL Server 2022 Analysis Services. Model złożony umożliwia łączenie danych w tych źródłach z innymi zapytaniami bezpośrednimi i zaimportowanymi danymi. Autorzy raportów, którzy chcą połączyć dane z modelu semantycznego przedsiębiorstwa z innymi danymi, które są właścicielami, takimi jak arkusz kalkulacyjny programu Excel, lub chcą personalizować lub wzbogacać metadane z modelu semantycznego przedsiębiorstwa, znajdą tę funkcję szczególnie przydatną.

Zarządzanie modelami złożonymi w modelach semantycznych usługi Power BI

Aby tworzyć i używać modeli złożonych w semantycznych modelach usługi Power BI, dzierżawa musi mieć włączone następujące przełączniki:

• Zezwalaj na używanie punktów końcowych XMLA i analizowania w programie Excel przy użyciu lokalnych modeli semantycznych. Jeśli wyłączysz ten przełącznik, nie możesz nawiązać połączenia trybu DirectQuery z modelem semantycznym usługi Power BI.
• Użytkownicy mogą pracować z semantycznymi modelami usługi Power BI w programie Excel przy użyciu połączenia na żywo. Jeśli wyłączysz ten przełącznik, użytkownicy nie będą mogli na żywo nawiązać połączeń z modelami semantycznymi usługi Power BI, aby przycisk Wprowadź zmiany w tym modelu nie był dostępny.
• Zezwalaj na połączenie DirectQuery z semantycznymi modelami usługi Power BI. Zobacz następujące akapity, aby uzyskać więcej informacji na temat tego przełącznika i wpływu jego wyłączenia.

Ponadto w przypadku pojemności Premium i Premium na użytkownika należy włączyć ustawienie "Punkt końcowy XMLA" i ustawić wartość na wartość "Tylko do odczytu" lub "Odczyt/zapis".

Administratorzy dzierżawy mogą włączać lub wyłączać połączenia DirectQuery z semantycznymi modelami usługi Power BI w portalu administracyjnym. To ustawienie jest domyślnie włączone, ale wyłączenie uniemożliwia użytkownikom publikowanie nowych modeli złożonych w semantycznych modelach usługi Power BI w usłudze.

Istniejące raporty korzystające z modelu złożonego w modelu semantycznym usługi Power BI nadal działają. Użytkownicy nadal mogą utworzyć model złożony w programie Power BI Desktop, ale nie mogą go opublikować w usłudze. Zamiast tego podczas tworzenia połączenia DirectQuery z modelem semantycznym usługi Power BI, wybierając pozycję Wprowadź zmiany w tym modelu, zostanie wyświetlony następujący komunikat ostrzegawczy:

W ten sposób można nadal eksplorować model semantyczny w lokalnym środowisku programu Power BI Desktop i utworzyć model złożony. Nie można jednak opublikować raportu w usłudze. Podczas publikowania raportu i modelu zostanie wyświetlony następujący komunikat o błędzie i publikacja jest blokowana:

Połączenia na żywo z modelami semantycznymi usługi Power BI nie mają wpływu na przełącznik ani nie mają wpływu na połączenia na żywo ani directQuery z usługami Analysis Services. Te połączenia nadal działają niezależnie od ustawienia przełącznika. Ponadto wszystkie opublikowane raporty korzystające z modelu złożonego w modelu semantycznym usługi Power BI nadal działają, nawet jeśli przełącznik jest wyłączony po ich opublikowaniu.

Tworzenie modelu złożonego na modelu semantycznym lub modelu

Aby utworzyć model złożony w modelu semantycznym usługi Power BI lub modelu usług Analysis Services, raport wymaga modelu lokalnego. Możesz rozpocząć od połączenia na żywo i dodać lub uaktualnić do modelu lokalnego albo rozpocząć od połączenia DirectQuery lub zaimportowanych danych, które automatycznie tworzą model lokalny w raporcie.

Aby sprawdzić, które połączenia są używane w modelu, sprawdź pasek stanu w prawym dolnym rogu programu Power BI Desktop. Jeśli masz połączenie tylko ze źródłem usług Analysis Services, zostanie wyświetlony komunikat podobny do poniższego obrazu:

Jeśli masz połączenie z semantycznym modelem usługi Power BI, zostanie wyświetlony komunikat informujący o tym, z którym modelem semantycznym usługi Power BI masz połączenie:

Jeśli chcesz dostosować metadane pól w modelu semantycznym połączonym na żywo, wybierz pozycję Wprowadź zmiany na tym modelu na pasku stanu. Alternatywnie możesz wybrać przycisk Wprowadź zmiany w tym modelu na wstążce, jak pokazano na poniższej ilustracji. W widoku raportu przycisk Wprowadź zmiany w tym modelu znajduje się na karcie Modelowanie . W widoku modelu przycisk znajduje się na karcie Narzędzia główne .

Po wybraniu przycisku zostanie wyświetlone okno dialogowe potwierdzające dodanie modelu lokalnego. Wybierz pozycję Dodaj model lokalny, aby włączyć tworzenie nowych kolumn lub modyfikowanie metadanych dla pól z semantycznych modeli usługi Power BI lub usług Analysis Services. Na poniższej ilustracji przedstawiono okno dialogowe.

Po nawiązaniu połączenia na żywo ze źródłem usług Analysis Services nie ma modelu lokalnego. Aby użyć trybu DirectQuery dla źródeł połączonych na żywo, takich jak modele semantyczne usługi Power BI i usługi Analysis Services, należy dodać model lokalny do raportu. Podczas publikowania raportu z modelem lokalnym w usłudze Power BI również jest publikowany semantyczny model dla tego modelu lokalnego.

Łączenie w łańcuchy

Modele semantyczne i semantyczne modele, na których są oparte, tworzą łańcuch. Ten proces, nazywany łańcuchem, umożliwia publikowanie raportu i modelu semantycznego na podstawie innych modeli semantycznych usługi Power BI.

Załóżmy na przykład, że współpracownik publikuje model semantyczny usługi Power BI o nazwie Sales and Budget na podstawie modelu usług Analysis Services o nazwie Sales (Sprzedaż) i łączy go z arkuszem programu Excel o nazwie Budget (Budżet). Następnie utworzysz i opublikujesz złożony semantyczny model i raport o nazwie Sales and Budget Europe, używając semantycznego modelu Sales and Budget Power BI z własnymi modyfikacjami. Ten semantyczny model jest trzeci w łańcuchu.

1. Pierwszy łańcuch to model usług analizy sprzedaży Analysis Services.
2. Drugi łańcuch to złożony model semantyczny Sprzedaż i Budżet Power BI.
3. Trzeci łańcuch to kompozytowy model semantyczny Sales and Budget Europe w usłudze Power BI.

Na poniższej ilustracji przedstawiono wizualizację tego procesu tworzenia łańcucha.

Długość łańcucha na poprzednim obrazie wynosi trzy, czyli maksymalną długość. Rozszerzanie się poza długość łańcucha o długości trzech nie jest obsługiwane i powoduje błędy.

Uprawnienia i licencjonowanie

Użytkownicy, którzy uzyskują dostęp do raportów przy użyciu modelu złożonego, muszą mieć odpowiednie uprawnienia do wszystkich modeli semantycznych i modeli w łańcuchu.

Właściciel modelu złożonego potrzebuje uprawnień do tworzenia modeli semantycznych używanych jako źródeł, aby inni użytkownicy mogli uzyskiwać dostęp do tych modeli w imieniu właściciela. W związku z tym utworzenie połączenia modelu złożonego w programie Power BI Desktop lub utworzenie raportu w usłudze Power BI wymaga uprawnień do tworzenia modeli semantycznych używanych jako źródeł.

Użytkownicy, którzy wyświetlają raporty przy użyciu modelu złożonego, zazwyczaj potrzebują uprawnień do odczytu dla samego modelu złożonego i modeli semantycznych używanych jako źródła. Uprawnienia do kompilacji mogą być wymagane, jeśli raporty znajdują się w obszarze roboczym Wersji Pro. Te przełączniki dzierżawy powinny być włączone dla użytkownika.

Poniższy przykład ilustruje wymagane uprawnienia:

• Model złożony A (należący do właściciela A)

  • Źródło danych A1: Semantyczny model B.
    Właściciel A musi mieć uprawnienie do tworzenia modelu semantycznego B , aby użytkownicy mogli wyświetlać raport korzystający z modelu złożonego A.

• Model złożony C (należący do właściciela C)

  • Źródło danych C1: Model semantyczny D
    Właściciel C musi mieć uprawnienie do kompilacji w modelu semantycznym D, aby użytkownicy mogli zobaczyć raport korzystający z modelu złożonego C.
  • Źródło danych C2: Model złożony A
    Właściciel C musi mieć uprawnienia do tworzenia modelu złożonego A i uprawnienia do odczytu w modelu semantycznym B.

Użytkownicy wyświetlający raporty korzystające z modelu złożonego A muszą mieć uprawnienia do odczytu zarówno do modelu złożonego A , jak i modelu semantycznego B, podczas gdy użytkownik wyświetlający raporty korzystające z modelu złożonego C musi mieć uprawnienia do odczytu dla modelu złożonego C, modelu semantycznego D, modelu złożonego A i modelu semantycznego B.

Jeśli dowolny zestaw danych w łańcuchu znajduje się w obszarze roboczym Premium na użytkownika, użytkownik, do którego uzyskuje dostęp, potrzebuje licencji Premium na użytkownika. Jeśli jakikolwiek zestaw danych w łańcuchu znajduje się w obszarze roboczym Pro, użytkownik, do którego uzyskuje dostęp, potrzebuje licencji Pro. Jeśli wszystkie zestawy danych w łańcuchu znajdują się w pojemnościach Premium lub Fabric F64 lub większej pojemności, użytkownik może uzyskać do niego dostęp za pomocą bezpłatnej licencji.

Ostrzeżenie o zabezpieczeniach

Jeśli używasz modeli złożonych w modelach semantycznych usługi Power BI i funkcjach modeli usług Analysis Services , zostanie wyświetlone okno dialogowe ostrzeżenia o zabezpieczeniach pokazane na poniższej ilustracji.

Dane mogą być wypychane z jednego źródła danych do innego źródła danych. To ostrzeżenie o zabezpieczeniach dotyczy łączenia źródeł DirectQuery i importu w modelu danych. Aby uzyskać więcej informacji na temat tego zachowania, zobacz Używanie modeli złożonych w programie Power BI Desktop.

Obsługiwane scenariusze

Modele złożone można tworzyć przy użyciu danych z modeli semantycznych usługi Power BI lub modeli usług Analysis Services w celu obsługi następujących scenariuszy:

• Nawiązywanie połączenia z danymi z różnych źródeł: importowanie (na przykład plików), modele semantyczne usługi Power BI, modele usług Analysis Services
• Tworzenie relacji między różnymi źródłami danych
• Pisanie miar używających pól z różnych źródeł danych
• Tworzenie nowych kolumn dla tabel na podstawie modeli semantycznych usługi Power BI lub modeli usług Analysis Services
• Tworzenie wizualizacji korzystających z kolumn z różnych źródeł danych
• Usuń tabelę z modelu przy użyciu listy pól, aby modele były tak zwięzłe i odchudzone, jak to możliwe (jeśli łączysz się z perspektywą, nie można usuwać tabel z modelu)
• Określ, które tabele mają być ładowane, zamiast ładować wszystkie tabele, gdy chcesz tylko określony podzbiór tabel. Zobacz Ładowanie podzestawu tabel w dalszej części tego dokumentu.
• Określ, czy chcesz dodać wszystkie tabele, które później zostaną dodane do modelu semantycznego po nawiązaniu połączenia w modelu.

Praca z modelem złożonym na podstawie modelu semantycznego

Podczas pracy z trybem DirectQuery dla modeli semantycznych usługi Power BI i usług Analysis Services należy wziąć pod uwagę następujące informacje:

• Jeśli odświeżysz źródła danych i wystąpią błędy powodujące konflikt nazw pól lub tabel, usługa Power BI rozwiąże błędy.

• Nie można edytować, usuwać ani tworzyć nowych relacji w tym samym modelu semantycznym usługi Power BI ani źródle usług Analysis Services. Jeśli masz dostęp do edycji tych źródeł, możesz wprowadzić zmiany bezpośrednio w źródle danych.

• Nie można zmienić typów danych kolumn ładowanych z semantycznego modelu usługi Power BI lub źródła usług Analysis Services. Jeśli musisz zmienić typ danych, zmień go w źródle lub użyj kolumny obliczeniowej.

• Aby tworzyć raporty w usłudze Power BI na podstawie modelu złożonego na podstawie innego modelu semantycznego, należy ustawić wszystkie poświadczenia.

• Połączenia z programem SQL Server 2022 lub nowszym serwerem usług Analysis Services lokalnie lub IAAS wymagają lokalnej bramy danych (tryb standardowy).

• Wszystkie połączenia z zdalnymi modelami semantycznymi usługi Power BI używają logowania jednokrotnego. Uwierzytelnianie za pomocą jednostki usługi nie jest obecnie obsługiwane.

• Reguły zabezpieczeń na poziomie wiersza (RLS) mają zastosowanie do źródła, na którym są zdefiniowane, ale nie mają zastosowania do żadnych innych modeli semantycznych w tym samym modelu. Zabezpieczenia na poziomie wiersza zdefiniowane w raporcie nie dotyczą źródeł zdalnych, a zabezpieczenia na poziomie wiersza ustawione w źródłach zdalnych nie mają zastosowania do innych źródeł danych. Ponadto nie można zdefiniować zabezpieczeń na poziomie wiersza w tabeli załadowanej ze źródła zdalnego, a zabezpieczenia na poziomie wiersza zdefiniowane w tabelach lokalnych nie filtrują żadnych tabel załadowanych ze źródła zdalnego.

• Kluczowe wskaźniki wydajności, zabezpieczenia na poziomie wiersza i tłumaczenia nie są importowane ze źródła.

• Podczas korzystania z hierarchii dat może wystąpić nieoczekiwane zachowanie. Aby rozwiązać ten problem, użyj kolumny daty. Po dodaniu hierarchii dat do wizualizacji możesz przełączyć się do kolumny dat, wybierając strzałkę w dół w nazwie pola, a następnie wybierając nazwę tego pola zamiast używać hierarchii dat:

  

  Aby uzyskać więcej informacji na temat używania kolumn dat i hierarchii dat, zobacz Stosowanie automatycznej daty lub godziny w programie Power BI Desktop.

• Maksymalna długość łańcucha modeli wynosi trzy. Rozszerzenie poza długość łańcucha trzech nie jest obsługiwane i powoduje błędy.

• Możesz ustawić flagę zniechęcającą do tworzenia łańcucha w modelu, aby zapobiec tworzeniu lub rozszerzaniu łańcucha. Aby uzyskać więcej informacji, zobacz Zarządzanie połączeniami DirectQuery z opublikowanym modelem semantycznym.

• Dodatek Power Query nie pokazuje połączenia z modelem semantycznym Power BI ani modelem usługi Analysis Services.

Podczas pracy z trybem DirectQuery dla modeli semantycznych usługi Power BI i usług Analysis Services obowiązują następujące ograniczenia :

• Parametry nazw baz danych i serwerów są obecnie wyłączone.
• Definiowanie zabezpieczeń na poziomie wiersza w tabelach ze źródła zdalnego nie jest obsługiwane.
• Używanie dowolnego z następujących źródeł jako źródła zapytania bezpośredniego nie jest obsługiwane:
  • Modele tabelaryczne usług SQL Server Analysis Services (SSAS) przed wersją 2022
  • Modele wielowymiarowe usług SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modele semantyczne w czasie rzeczywistym
  • Przykładowe modele semantyczne
  • Odświeżanie usługi Excel Online
  • Dane importowane z plików PROGRAMU Excel lub CSV w usłudze
  • Metryki użycia
  • Modele semantyczne przechowywane w obszarze "Mój obszar roboczy"
• Korzystanie z usługi Power BI Embedded z modelami semantycznymi, które obejmują połączenie DirectQuery z zewnętrznym modelem usług Analysis Services (Azure Analysis Services/SQL Server Analysis Services) nie jest obecnie obsługiwane.
• Publikowanie raportu w Internecie przy użyciu funkcji publikowania w sieci Web nie jest obsługiwane.
• Grupy obliczeń w źródłach zdalnych nie są obsługiwane z niezdefiniowanymi wynikami zapytania.
• Tabele obliczeniowe i kolumny obliczeniowe odwołujące się do tabeli DirectQuery ze źródła danych z uwierzytelnianiem logowania jednokrotnego (SSO) są obsługiwane w usługa Power BI z przypisanym połączeniem chmury z możliwością udostępniania i /lub szczegółową kontrolą dostępu.
• Jeśli zmienisz nazwę obszaru roboczego po skonfigurowaniu połączenia DirectQuery, musisz zaktualizować źródło danych w programie Power BI Desktop, aby raport nadal działał.
• Automatyczne odświeżanie strony (APR) jest obsługiwane tylko w niektórych scenariuszach, w zależności od typu źródła danych. Aby uzyskać więcej informacji, zobacz Automatyczne odświeżanie strony w usłudze Power BI.
• Przejęcie modelu semantycznego korzystającego z trybu DirectQuery do innych funkcji modeli semantycznych nie jest obecnie obsługiwane.
• Podobnie jak w przypadku dowolnego źródła danych DirectQuery hierarchie zdefiniowane w modelu usług Analysis Services lub modelu semantycznego usługi Power BI nie są wyświetlane podczas nawiązywania połączenia z modelem lub modelem semantycznym w trybie DirectQuery przy użyciu programu Excel.

Podczas pracy z trybem DirectQuery dla modeli semantycznych usługi Power BI i usług Analysis Services należy wziąć pod uwagę następujące wskazówki:

• Użyj kolumn o niskiej kardynalności w relacjach między grupami źródłowymi: podczas tworzenia relacji między dwiema różnymi grupami źródłowymi kolumn uczestniczących w relacji (nazywanej również kolumnami sprzężenia) powinna mieć niską kardynalność, najlepiej 50 000 lub mniej. Ta kwestia dotyczy kolumn kluczy nieciągujących; aby zapoznać się z kolumnami klucza ciągu, zapoznaj się z poniższymi zagadnieniami.
• Unikaj używania dużych kolumn kluczy ciągów w relacjach między grupami źródłowymi: podczas tworzenia relacji między grupami źródłowymi unikaj używania dużych kolumn ciągów jako kolumn relacji, zwłaszcza w przypadku kolumn o większej kardynalności. Jeśli musisz użyć kolumn ciągów jako kolumny relacji, oblicz oczekiwaną długość ciągu dla filtru, mnożąc kardynalność (C) przez średnią długość kolumny ciągu (A). Upewnij się, że oczekiwana długość ciągu jest niższa niż 250 000, tak aby ∗ C < 250 000.

Aby uzyskać więcej informacji i wskazówek, zapoznaj się ze wskazówkami dotyczącymi modelu złożonego.

Zagadnienia dotyczące dzierżawy

Należy opublikować dowolny model z połączeniem DirectQuery z semantycznym modelem usługi Power BI lub usługami Analysis Services w tej samej dzierżawie. To wymaganie jest szczególnie ważne w przypadku uzyskiwania dostępu do modelu semantycznego usługi Power BI lub modelu usług Analysis Services za pomocą tożsamości gości B2B, jak pokazano na poniższym diagramie.

Rozważmy poniższy diagram. Ponumerowane kroki na diagramie zostały opisane w poniższych akapitach.

Na diagramie Ash współpracuje z firmą Contoso i uzyskuje dostęp do danych dostarczonych przez firmę Fabrikam. W Power BI Desktop Ash tworzy połączenie DirectQuery z modelem Analysis Services, który hostuje Fabrikam.

Aby się uwierzytelnić, Ash używa tożsamości użytkownika-gościa B2B (krok 1 na diagramie).

Jeśli Ash publikuje raport w usłudze Power BI firmy Contoso (krok 2), model semantyczny opublikowany w dzierżawie Contoso nie może się pomyślnie uwierzytelnić przy użyciu modelu usług Analysis Services firmy Fabrikam (krok 3). W związku z tym raport nie działa.

W tym scenariuszu, ponieważ Fabrikam hostuje model usług Analysis Services, należy również opublikować raport w dzierżawie należącej do firmy Fabrikam. Po pomyślnej publikacji w dzierżawie firmy Fabrikam (krok 4) model semantyczny może pomyślnie uzyskać dostęp do modelu usług Analysis Services (krok 5), a raport działa prawidłowo.

Praca z zabezpieczeniami na poziomie obiektu

Gdy model złożony pobiera dane z semantycznego modelu usługi Power BI lub usług Analysis Services za pośrednictwem zapytania bezpośredniego, a model źródłowy jest zabezpieczony przez zabezpieczenia na poziomie obiektu, użytkownicy modelu złożonego mogą zauważyć nieoczekiwane wyniki. W poniższej sekcji opisano, jak mogą wystąpić te wyniki.

Zabezpieczenia na poziomie obiektu (OLS) umożliwiają autorom modeli ukrywanie obiektów tworzących schemat modelu (czyli tabele, kolumny, metadane itd.) od użytkowników modelu (na przykład konstruktora raportów lub autora modelu złożonego). Podczas konfigurowania usługi OLS dla obiektu autor modelu tworzy rolę, a następnie usuwa dostęp do obiektu dla użytkowników przypisanych do tej roli. Z punktu widzenia tych użytkowników ukryty obiekt po prostu nie istnieje.

Usługa OLS jest definiowana dla modelu źródłowego i stosowana do tego modelu. Nie można go zdefiniować dla modelu złożonego utworzonego na podstawie modelu źródłowego.

Podczas tworzenia modelu złożonego na podstawie modelu semantycznego usługi Power BI chronionego przez usługę OLS lub modelu usług Analysis Services za pośrednictwem połączenia DirectQuery należy skopiować schemat modelu z modelu źródłowego do modelu złożonego. To, co kopiujesz, zależy od tego, co wolno ci zobaczyć w modelu źródłowym, zgodnie z mającymi tam zastosowanie zasadami OLS. Nie kopiujesz danych do modelu złożonego — zawsze pobierasz je za pośrednictwem trybu DirectQuery z modelu źródłowego w razie potrzeby. Innymi słowy pobieranie danych zawsze wraca do modelu źródłowego, w którym mają zastosowanie reguły OLS.

Ponieważ model złożony nie jest zabezpieczony przez reguły OLS, obiekty widoczne dla użytkowników modelu złożonego to te, do których można zobaczyć w modelu źródłowym, a nie to, do czego sami mogą mieć dostęp. Taka sytuacja może spowodować następujące wyniki:

• Ktoś przeglądający model złożony może zobaczyć obiekty ukryte przed nimi w modelu źródłowym przez usługę OLS.
• Z drugiej strony mogą nie widzieć obiektu w modelu złożonym, który może zobaczyć w modelu źródłowym, ponieważ ten obiekt został ukryty przed autorem modelu złożonego przez reguły OLS kontrolujące dostęp do modelu źródłowego.

Ważnym punktem jest to, że pomimo przypadku opisanego w pierwszym punkcie konsumenci modelu złożonego nigdy nie widzą rzeczywistych danych, których nie powinni zobaczyć, ponieważ dane nie znajdują się w modelu złożonym. Zamiast tego ze względu na tryb DirectQuery jest pobierany zgodnie z potrzebami z modelu semantycznego źródłowego, w którym usługa OLS blokuje nieautoryzowany dostęp.

Mając to na uwadze, rozważmy następujący scenariusz:

1. Admin_user publikuje model semantyczny przedsiębiorstwa przy użyciu semantycznego modelu usługi Power BI lub modelu usług Analysis Services, który ma tabelę Customer (Klient) i tabelę Territory (Terytorium). Admin_user publikuje semantyczny model w usługa Power BI i ustawia reguły OLS, które mają następujący efekt:

   • Użytkownicy finansów nie widzą tabeli Customer (Klient)
   • Użytkownicy marketingowi nie widzą tabeli Territory

2. Finance_user publikuje semantyczny model o nazwie "Model semantyczny finansów" i raport o nazwie "Raport finansowy", który łączy się za pośrednictwem trybu DirectQuery z semantycznym modelem przedsiębiorstwa opublikowanym w kroku 1. Raport Finanse zawiera wizualizację, która używa kolumny z tabeli Territory.

3. Marketing_user otwiera raport Finanse. Zostanie wyświetlona wizualizacja używająca tabeli Territory, ale zwraca błąd, ponieważ po otwarciu raportu zapytanie bezpośrednie próbuje pobrać dane z modelu źródłowego przy użyciu poświadczeń Marketing_user, który nie może zobaczyć tabeli Territory zgodnie z regułami OLS ustawionymi w modelu semantycznym przedsiębiorstwa.

4. Marketing_user tworzy nowy raport o nazwie "Marketing Report", który używa modelu semantycznego Finanse jako źródła. Lista pól zawiera tabele i kolumny, do których Finance_user ma dostęp. W związku z tym tabela Territory jest wyświetlana na liście pól, ale tabela Customer nie jest. Jeśli jednak Marketing_user próbuje utworzyć wizualizację, która używa kolumny z tabeli Territory, zostanie zwrócony błąd, ponieważ w tym momencie zapytanie bezpośrednie próbuje pobrać dane z modelu źródłowego przy użyciu poświadczeń Marketing_user, a reguły OLS po raz kolejny rozpoczynają się i blokują dostęp. Dzieje się tak samo, gdy Marketing_user tworzy nowy model semantyczny i raport, który łączy się z modelem semantycznym Finanse z połączeniem DirectQuery — widzą tabelę Territory na liście pól, ponieważ jest to, co Finance_user może zobaczyć, ale podczas próby utworzenia wizualizacji korzystającej z tej tabeli są blokowane przez reguły OLS w modelu semantycznym przedsiębiorstwa.

5. Teraz powiedzmy, że Admin_user zaktualizować reguły OLS w modelu semantycznym przedsiębiorstwa, aby uniemożliwić usłudze Finance wyświetlanie tabeli Territory.

6. Zaktualizowane reguły OLS są odzwierciedlane tylko w modelu semantycznym Finanse po odświeżeniu. W związku z tym, gdy Finance_user odświeży model semantyczny Finanse, tabela Territory nie jest już wyświetlana na liście pól, a wizualizacja w raporcie Finanse używająca kolumny z tabeli Territory zwraca błąd dla Finance_user, ponieważ nie mogą teraz uzyskać dostępu do tabeli Territory.

Podsumowując:

• Konsumenci modelu złożonego widzą wyniki reguł OLS, które miały zastosowanie do autora modelu złożonego podczas tworzenia modelu. W związku z tym po utworzeniu nowego raportu na podstawie modelu złożonego lista pól pokazuje tabele, do których autor modelu złożonego miał dostęp podczas tworzenia modelu, niezależnie od tego, do czego ma dostęp bieżący użytkownik w modelu źródłowym.
• Nie można zdefiniować reguł OLS dla samego modelu złożonego.
• Konsument modelu złożonego nigdy nie widzi rzeczywistych danych, których nie powinien zobaczyć, ponieważ stosowne zasady OLS w modelu źródłowym blokują dostęp, gdy DirectQuery próbuje pobrać dane z użyciem ich poświadczeń.
• Jeśli model źródłowy aktualizuje reguły OLS, zmiany te wpływają tylko na model złożony po odświeżeniu.

Ładowanie podzbioru tabel z modelu semantycznego usługi Power BI lub modelu usług Analysis Services

Podczas nawiązywania połączenia z semantycznym modelem usługi Power BI lub modelem usług Analysis Services przy użyciu połączenia DirectQuery należy wybrać tabele do nawiązania połączenia. Możesz również automatycznie dodać dowolną tabelę, która może zostać dodana do modelu semantycznego lub modelu po nawiązaniu połączenia z modelem. Po nawiązaniu połączenia z perspektywą model zawiera wszystkie tabele w modelu semantycznym, a wszystkie tabele, które nie są uwzględnione w perspektywie, są ukryte. Ponadto każda tabela, która może zostać dodana do perspektywy, zostanie dodana automatycznie. W menu Ustawienia możesz zdecydować się na automatyczne łączenie się z tabelami dodanymi do modelu semantycznego po pierwszym skonfigurowaniu połączenia.

To okno dialogowe nie jest wyświetlane dla połączeń na żywo.

Konfigurowanie reguł deduplikacji

Możesz określić reguły deduplikacji, aby zachować nazwy miar i tabel unikatowe w modelu złożonym przy użyciu opcji Ustawienia w wyświetlonym wcześniej oknie dialogowym:

W poprzednim przykładzie dodaliśmy wartość " (marketing)" jako sufiks dowolnej tabeli lub nazwy miary, która powoduje konflikt z innym źródłem w modelu złożonym. Masz następujące możliwości:

• Wprowadź tekst, aby dodać go do nazwy konfliktowych tabel lub miar.
• Określ, czy tekst ma zostać dodany jako prefiks lub sufiks do tabeli lub nazwy miary.
• Zastosuj regułę deduplikacji do tabel, miar lub obu tych metod.
• Wybierz zastosowanie reguły deduplikacji tylko wtedy, gdy wystąpi konflikt nazw lub zastosuj ją przez cały czas. Ustawieniem domyślnym jest zastosowanie reguły tylko wtedy, gdy wystąpi duplikacja. W naszym przykładzie każda tabela lub miara ze źródła marketingu, która nie ma duplikatu w źródle sprzedaży, nie otrzymuje zmiany nazwy.

Po utworzeniu połączeń i skonfigurowaniu reguły deduplikacji lista pól zawiera zarówno "Klient" jak i "Klient (marketing)" zgodnie z regułą deduplikacji skonfigurowaną w naszym przykładzie:

Jeśli nie określisz reguły deduplikacji lub określone reguły deduplikacji nie rozwiążą konfliktu nazw, nadal są stosowane standardowe reguły deduplikacji. Standardowe reguły deduplikacji dodają liczbę do nazwy elementu powodującego konflikt. Jeśli w tabeli "Customer" występuje konflikt nazw, jedna z tabel "Customer" ma nazwę "Customer 2".

Modyfikacje XMLA i modele złożone

Po zmianie modelu semantycznego przy użyciu xmlA zaktualizuj kolekcje ChangedProperties i PBI_RemovedChildren dla zmienionego obiektu, aby zawierał wszelkie zmodyfikowane lub usunięte właściwości. Jeśli te kolekcje nie zostaną zaktualizowane, narzędzia do modelowania usługi Power BI mogą zastąpić zmiany przy następnym synchronizowaniu schematu ze źródłem danych.

Aby uzyskać więcej informacji na temat tagów pochodzenia obiektów modelu semantycznego, zobacz Tagi pochodzenia dla modeli semantycznych usługi Power BI.

Rozważania i ograniczenia

Modele złożone zawierają kilka zagadnień i ograniczeń:

Połączenia w trybie mieszanym — w przypadku korzystania z połączenia w trybie mieszanym zawierającego dane online (takie jak model semantyczny usługi Power BI) i lokalny model semantyczny (np. skoroszyt programu Excel), należy ustanowić mapowanie bramy, aby wizualizacje były prawidłowo wyświetlane.

Obecnie odświeżanie przyrostowe jest obsługiwane tylko w przypadku modeli złożonych łączących się z źródłami danych SQL, Oracle i Teradata.

Następujących źródeł tabelarycznych programu Live Connect nie można używać z modelami złożonymi:

• SAP HANA
• SAP Business Warehouse
• Usługi SQL Server Analysis Services starsze niż wersja 2022
• Metryki użycia (Mój obszar roboczy)

Używanie modeli semantycznych przesyłania strumieniowego w modelach złożonych nie jest obsługiwane.

Istniejące ograniczenia trybu DirectQuery nadal mają zastosowanie w przypadku korzystania z modeli złożonych. Wiele z tych ograniczeń jest teraz na tabelę, w zależności od trybu przechowywania tabeli. Na przykład kolumna obliczeniowa w tabeli importu może odwoływać się do innych tabel, które nie znajdują się w trybie DirectQuery, ale kolumna obliczeniowa w tabeli DirectQuery nadal może odwoływać się tylko do kolumn w tej samej tabeli. Inne ograniczenia dotyczą modelu jako całości, jeśli którakolwiek z tabel w modelu to Zapytanie bezpośrednie. Na przykład funkcja QuickInsights nie jest dostępna w modelu, jeśli którakolwiek z tabel w niej ma tryb przechowywania trybu DirectQuery.

Jeśli używasz zabezpieczeń na poziomie wiersza w modelu złożonym z niektórymi tabelami w trybie DirectQuery, musisz odświeżyć model, aby zastosować nowe aktualizacje z tabel DirectQuery. Jeśli na przykład tabela Users w trybie DirectQuery zawiera nowe rekordy użytkownika w źródle, nowe rekordy są uwzględniane dopiero po następnym odświeżeniu modelu. Usługa Power BI buforuje zapytanie Użytkownicy w celu zwiększenia wydajności i nie ładuje ponownie danych ze źródła do momentu następnego ręcznego lub zaplanowanego odświeżania.

Powiązana zawartość

Aby uzyskać więcej informacji na temat modeli złożonych i trybu DirectQuery, zobacz następujące artykuły:

• Stosowanie relacji wiele do wielu w programie Power BI Desktop
• Zarządzanie trybem przechowywania w programie Power BI Desktop
• Zapytanie bezpośrednie w usłudze Power BI
• Źródła danych usługi Power BI
• Relacje modelu w programie Power BI Desktop