Używanie modeli złożonych w usłudze Power BI Desktop

Wcześniej w programie Power BI Desktop, gdy w raporcie użyto trybu DirectQuery, żadne inne połączenia danych, niezależnie od tego, czy tryb DirectQuery, czy import, były dozwolone dla tego raportu. W przypadku modeli złożonych to ograniczenie jest usuwane. Raport może bezproblemowo zawierać połączenia danych z więcej niż jednego zapytania bezpośredniego lub importowania połączenia danych, w dowolnej wybranej kombinacji.

Możliwości modeli złożonych w programie Power BI Desktop składają się z trzech powiązanych funkcji:

• Modele złożone: umożliwia raportowi posiadanie co najmniej dwóch połączeń danych z różnych grup źródłowych. Te grupy źródłowe mogą być co najmniej jednym połączeniem DirectQuery i połączeniem importu, co najmniej dwoma połączeniami trybu DirectQuery lub dowolną kombinacją tych połączeń. W tym artykule szczegółowo opisano modele złożone.

• Relacje wiele-do-wielu: w przypadku modeli złożonych można ustanowić relacje wiele-do-wielu między tabelami. To podejście usuwa wymagania dotyczące unikatowych wartości w tabelach. Usuwa również wcześniejsze obejścia, takie jak wprowadzanie nowych tabel tylko w celu ustanowienia relacji. Aby uzyskać więcej informacji, zobacz Stosowanie relacji wiele-do-wielu w programie Power BI Desktop.

• Tryb przechowywania: możesz teraz określić, które wizualizacje wysyłają zapytania do źródeł danych zaplecza. Ta funkcja pomaga zwiększyć wydajność i zmniejszyć obciążenie zaplecza. Wcześniej nawet proste wizualizacje, takie jak fragmentatory, inicjowały zapytania do źródeł zaplecza. Aby uzyskać więcej informacji, zobacz Zarządzanie trybem przechowywania w programie Power BI Desktop.

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.

Model, który łączy dane z więcej niż jednego źródła DirectQuery lub łączy tryb DirectQuery z danymi importu, jest nazywany modelem 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.

Uwaga

W kontekście modeli złożonych wszystkie zaimportowane tabele są skutecznie jednym źródłem, niezależnie od rzeczywistych bazowych źródeł danych.

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, kliknij prawym przyciskiem myszy tabelę na liście Pola , a następnie wybierz polecenie Właściwości. Na poniższej ilustracji przedstawiono tryb przechowywania tabeli SalesTargets .

Tryb przechowywania można również wyświetlić na etykietce narzędzia dla każdej tabeli.

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.

Uwaga

Tryb przechowywania mieszanego można używać w programie Power BI Desktop i w usługa Power BI.

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.

Ważne

Tabele obliczeniowe nie są obsługiwane w usługa Power BI przy użyciu tej funkcji, chyba że spełniasz określone wymagania. Aby uzyskać więcej informacji na ten temat, zobacz sekcję Praca z modelem złożonym na podstawie semantycznego modelu w tym artykule.

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 zostały pobrane z innego źródła. We wcześniejszym przykładzie wizualizacja pokazująca (Sales Amount) by Product Manager 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 będzie potrzebować uprawnień do pliku programu Excel.

• Należy wziąć pod uwagę 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 zezwolić na potwierdzenie, że zostały uznane za wszelkie implikacje dotyczące zabezpieczeń, program Power BI Desktop wyświetla komunikat ostrzegawczy podczas tworzenia modelu złożonego.

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

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, zostaną wysłane do innego źródła danych w ramach zapytania. Te informacje mogą być wyświetlane przez złośliwego autora pliku programu Power BI Desktop. 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 należy zawsze rozważyć wydajność, przede wszystkim w celu zapewnienia, że źródło zaplecza ma wystarczające zasoby, 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 spowodować wysyłanie zapytań do wielu źródeł, które często przekazują wyniki z jednego zapytania 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 całkowitej kwoty sprzedaży dla zestawu wybranych menedżerów produktów, musi najpierw znaleźć, które produkty były zarządzane przez tych menedżerów produktów. Ta sekwencja musi nastą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, konieczne jest wysłanie jednego zapytania SQL na grupę według wartości.

  Wizualizacja, która żąda odrębnej liczby kolumn CustomerAccountNumber z tabeli programu SQL Server zaimportowanych z arkusza kalkulacyjnego przez menedżerów produktów, musi przekazać szczegóły z tabeli Product Manager (Menedżerowie produktów) 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 mieć wpływu na wydajność. W miarę wzrostu kardynalności należy zwrócić większą uwagę na wpływ na wynikowej wydajności.

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łaby 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 dodano kolejne połączenie DirectQuery z innym źródłem, takie jak połączenie directQuery z bazą danych programu SQL Server o nazwie Inventory, elementy z tego źródła zostaną dodane do innej grupy źródłowej:

Uwaga

Importowanie danych z innego źródła nie spowoduje dodania innej grupy źródłowej, ponieważ wszystkie elementy ze wszystkich zaimportowanych źródeł znajdują się w jednej grupie źródłowej.

Grupy źródłowe i relacje

Istnieją dwa typy relacji w modelu złożonym:

• 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 grupami źródłowymi, odnoszące się do tabel między różnymi grupami źródłowymi:

Lokalne i zdalne

Każdy element należący do grupy źródłowej, która jest grupą źródłową DirectQuery, jest uważany za zdalny, chyba że element został zdefiniowany 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 uważana za lokalną. Każdy element, który znajduje się w grupie źródłowej "Importuj", jest uznawany za 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 uważana za lokalną:

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

Grupy obliczeń, zapytania i ocena miar

Grupy obliczeń umożliwiają zmniejszenie liczby nadmiarowych miar i grupowanie wspólnych wyrażeń miar. Typowe przypadki użycia to obliczenia analizy czasowej, w których chcesz mieć możliwość przełączenia się z wartości rzeczywistych do daty, kwartału lub obliczeń od początku roku do daty. 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ę, ta grupa obliczeń jest stosowana, nawet jeśli miara została zdefiniowana w modelu zdalnym lub w modelu lokalnym. Jeśli jednak miara nie odwołuje się 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ż znajdują się one w tym samym modelu. Oznacza to, że wyniki zwrócone przez miarę Total Sales muszą być dokładnie ocenione. Załóżmy, że używamy grupy obliczeń w modelu zdalnym do zwracania wyników od roku do daty. 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. Korzystając z modelu złożonego, można połączyć dane 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 umożliwić tworzenie i zużycie modeli złożonych w modelach semantycznych 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 ten przełącznik jest wyłączony, nie można nawiązać połączenia trybu DirectQuery z semantycznym modelem 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 ten przełącznik jest wyłączony, użytkownicy nie mogą nawiązać połączeń na żywo z modelami semantycznymi usługi Power BI, aby nie można było uzyskać dostępu do przycisku Wprowadź zmiany w tym modelu .
• 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. Mimo że ta opcja jest domyślnie włączona, 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ą, a użytkownicy mogą nadal tworzyć model złożony przy użyciu programu Desktop, ale nie mogą publikować go 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 zobaczysz następujący komunikat o błędzie i publikacja jest zablokowana:

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. Nadal działają niezależnie od tego, czy przełącznik został wyłączony. Ponadto wszystkie opublikowane raporty korzystające z modelu złożonego w modelu semantycznym usługi Power BI będą nadal działać, nawet jeśli przełącznik został wyłączony po ich opublikowaniu.

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

Utworzenie modelu złożonego w modelu semantycznym usługi Power BI lub modelu usług Analysis Services wymaga, aby raport miał model lokalny. 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 z informacją 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 widokuraportu przycisk Wprowadź zmiany w tym modelu na karcie Modelowanie . W widoku modelu przycisk znajduje się na karcie Narzędzia główne .

Wybranie przycisku powoduje wyświetlenie okna dialogowego potwierdzającego dodanie modelu lokalnego. Wybierz pozycję Dodaj model lokalny, aby włączyć tworzenie nowych kolumn lub modyfikowanie metadanych dla pól z modeli semantycznych usługi Power BI lub usług Analysis Services. Na poniższej ilustracji przedstawiono wyświetlone 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. Po opublikowaniu raportu z modelem lokalnym w usługa Power BI zostanie opublikowany model semantyczny 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, funkcji, która wcześniej nie była możliwa.

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).

Podczas publikowania nowego raportu (i modelu semantycznego) o nazwie Sales and Budget Europe na podstawie semantycznego modelu sprzedaży i budżetu usługi Power BI opublikowanego przez współpracownika, wprowadzając kolejne modyfikacje lub rozszerzenia w ten sposób, skutecznie dodajesz raport i model semantyczny do łańcucha o długości trzech, co zaczęło się od modelu usług Sales Analysis Services, i kończy się semantycznym modelem usługi Power BI Sales and Budget Europe . Na poniższej ilustracji przedstawiono wizualizację tego procesu tworzenia łańcucha.

Łańcuch na poprzedniej ilustracji ma długość 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 wymaga uprawnienia 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 korzystające z modelu złożonego, zazwyczaj będą wymagać 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.

Wymagane uprawnienia można zilustrować przy użyciu następującego przykładu:

• 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 w modelu semantycznym B , aby użytkownicy mogli wyświetlać raport przy użyciu 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 tworzenia modelu semantycznego D , aby użytkownicy mogli wyświetlać raport przy użyciu 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żytkownik wyświetlający raporty korzystające z modelu złożonego A musi 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.

Uwaga

Zapoznaj się z tym wpisem w blogu, aby uzyskać ważne informacje o uprawnieniach wymaganych do modeli złożonych w modelach semantycznych usługi Power BI i modelach usług Analysis Services.

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 W sieci szkieletowej F64 lub większej pojemności, użytkownik może uzyskać do niego dostęp przy użyciu licencji Bezpłatnej.

Ostrzeżenie o zabezpieczeniach

Korzystanie z modeli złożonych w semantycznych modelach usługi Power BI i funkcjach modeli usług Analysis Services przedstawia okno dialogowe ostrzeżenia o zabezpieczeniach pokazane na poniższej ilustracji.

Dane mogą być wypychane z jednego źródła danych do innego, co jest tym samym ostrzeżeniem o zabezpieczeniach w celu połączenia trybu DirectQuery i importu źródeł w modelu danych. Aby dowiedzieć się więcej 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:

• Połączenie do danych 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
• Tabelę można usunąć z modelu przy użyciu listy pól, aby zachować zwięzłe modele i jak najwięcej pochylić się (jeśli łączysz się z perspektywą, nie możesz usunąć tabel z modelu)
• Możesz określić, 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.
• Możesz określić, czy po nawiązaniu połączenia w modelu chcesz dodać wszystkie tabele, które zostaną później dodane do modelu semantycznego.

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ługa Power BI na modelu złożonym na podstawie innego modelu semantycznego, należy ustawić wszystkie poświadczenia.

• Połączenie do lokalnego serwera usług SQL Server 2022 i nowszych usług Analysis Services lub IAAS wymagają lokalnej bramy danych (tryb standardowy).

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

• Reguły zabezpieczeń na poziomie wiersza są stosowane w źródle, na którym są zdefiniowane, ale nie są stosowane do żadnych innych modeli semantycznych w modelu. Zabezpieczenia na poziomie wiersza zdefiniowane w raporcie nie są stosowane do źródeł zdalnych, a zabezpieczenia na poziomie wiersza ustawione na źródłach zdalnych nie są stosowane 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, klikając strzałkę w dół w nazwie pola, a następnie klikają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.

• Niechętna flaga tworzenia łańcucha może być ustawiona na modelu, aby zapobiec tworzeniu lub rozszerzaniu łańcucha. Aby uzyskać więcej informacji, zobacz Zarządzanie połączeniami DirectQuery z opublikowanym modelem semantycznym.

• Połączenie z semantycznym modelem usługi Power BI lub modelem usług Analysis Services nie jest wyświetlane w dodatku Power Query.

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 zawierają połączenie DirectQuery z modelem usług 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 kontynuował pracę.
• 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 semantycznych modeli 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.

Istnieje kilka innych kwestii, które należy wziąć pod uwagę podczas pracy z trybem DirectQuery dla modeli semantycznych usługi Power BI i usług Analysis Services:

• 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

Każdy model z połączeniem DirectQuery z semantycznym modelem usługi Power BI lub usługą Analysis Services musi być opublikowany w tej samej dzierżawie, co jest szczególnie ważne w przypadku uzyskiwania dostępu do modelu semantycznego usługi Power BI lub modelu usług Analysis Services przy użyciu tożsamości gości B2B, jak pokazano na poniższym diagramie. Zobacz Użytkownicy-goście, którzy mogą edytować zawartość i zarządzać nią, aby znaleźć adres URL dzierżawy do publikowania.

Rozważmy poniższy diagram. Ponumerowane kroki na diagramie opisano w kolejnych akapitach.

Na diagramie Ash współpracuje z firmą Contoso i uzyskuje dostęp do danych dostarczonych przez firmę Fabrikam. W programie Power BI Desktop Ash tworzy połączenie DirectQuery z modelem usług Analysis Services hostowanymi w dzierżawie firmy Fabrikam.

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

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

W tym scenariuszu, ponieważ używany model usług Analysis Services jest hostowany w dzierżawie firmy Fabrikam, raport musi być również opublikowany w dzierżawie 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 itp.) 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.

Gdy model złożony jest oparty na modelu semantycznym usługi Power BI chronionym przez usługę OLS lub modelu usług Analysis Services za pośrednictwem połączenia DirectQuery, schemat modelu z modelu źródłowego jest kopiowany do modelu złożonego. To, co jest kopiowane, zależy od tego, co autor modelu złożonego może zobaczyć w modelu źródłowym zgodnie z regułami OLS, które tam mają zastosowanie. Dane nie są kopiowane do modelu złożonego — w razie potrzeby są zawsze pobierane za pośrednictwem zapytania bezpośredniego z modelu źródłowego. 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 autor modelu złożonego mógł zobaczyć w modelu źródłowym, a nie do tego, do czego sami mogą mieć dostęp. Może to spowodować następujące sytuacje:

• 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. Administracja_user opublikowano semantyczny model 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). Administracja_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 Administracja_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 w samym modelu złożonym.
• Użytkownik modelu złożonego nigdy nie zobaczy rzeczywistych danych, których nie powinien zobaczyć, ponieważ odpowiednie reguły OLS w modelu źródłowym blokują je, gdy zapytanie bezpośrednie próbuje pobrać dane przy użyciu 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 możesz zdecydować, z którymi tabelami chcesz się połączyć. 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.

Uwaga

To okno dialogowe będzie wyświetlane tylko w przypadku dodania połączenia DirectQuery do modelu semantycznego usługi Power BI lub modelu usług Analysis Services do istniejącego modelu. Możesz również otworzyć to okno dialogowe, zmieniając połączenie DirectQuery z semantycznym modelem usługi Power BI lub modelem usług Analysis Services w ustawieniach źródła danych po jego utworzeniu.

Konfigurowanie reguł deduplikacji

Możesz określić reguły deduplikacji, aby zachować unikatowe nazwy miar i tabel 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 jest w konflikcie z innym źródłem w modelu złożonym. Masz następujące możliwości:

• wprowadź tekst, który ma zostać dodany do nazwy tabel lub miar powodujących konflikt
• określ, czy tekst ma zostać dodany do tabeli, czy nazwy miary jako prefiks, czy sufiks
• stosowanie reguły deduplikacji do tabel, miar lub obu
• 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óre nie ma duplikatu w źródle sprzedaży, nie otrzyma zmiany nazwy.

Po utworzeniu połączeń i skonfigurowaniu reguły deduplikacji na liście pól będą wyświetlane 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. W przypadku konfliktu nazw w tabeli "Customer" jedna z tabel "Customer" ma zmienioną nazwę "Customer 2".

Rozważania i ograniczenia

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

Połączenia w trybie mieszanym — w przypadku korzystania z połączenia trybu mieszanego zawierającego dane online (takie jak model semantyczny usługi Power BI) i lokalny model semantyczny (taki jak skoroszyt programu Excel), musisz mieć utworzone 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 live Połączenie 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 Quick Szczegółowe informacje 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órych tabel 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 ma nowe rekordy użytkownika w źródle, nowe rekordy zostaną uwzględnione tylko 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