Použití složených modelů v Power BI Desktop

Dříve v Power BI Desktopu, když jste v sestavě použili DirectQuery, nebyla pro tuto sestavu povolená žádná jiná datová připojení, ať už DirectQuery nebo import. U složených modelů se toto omezení odebere. Sestava může bez problémů zahrnovat datová připojení z více než jednoho DirectQuery nebo import datového připojení v libovolné kombinaci, kterou zvolíte.

Funkce složených modelů v Power BI Desktopu se skládá ze tří souvisejících funkcí:

• Složené modely: Umožňuje sestavě mít dvě nebo více datových připojení z různých zdrojových skupin. Těmito zdrojovými skupinami může být jedno nebo více připojení DirectQuery a připojení importu, dvě nebo více připojení DirectQuery nebo jakákoli jejich kombinace. Tento článek podrobně popisuje složené modely.

• Relace M:N: Ve složených modelech můžete mezi tabulkami vytvořit relace M:N. Tento přístup odebere požadavky na jedinečné hodnoty v tabulkách. Zároveň to eliminuje předchozí alternativní řešení, například zavedení nových tabulek jen za účelem vytvoření relací. Další informace najdete v tématu Použití relací M:N v Power BI Desktopu.

• Režim úložiště: Teď můžete určit, které vizuály dotazují back-endové zdroje dat. Tato funkce pomáhá zlepšit výkon a snížit zatížení back-endu. Dříve dokonce i jednoduché vizuály, jako jsou průřezy, iniciovaly dotazy do back-endových zdrojů. Další informace najdete v tématu Správa režimu úložiště v Power BI Desktopu.

Použití složených modelů

Ve složených modelech se můžete připojit k různým druhům zdrojů dat, když používáte Power BI Desktop nebo služba Power BI. Tato datová připojení můžete nastavit několika způsoby:

• Importem dat do Power BI, což je nejběžnější způsob, jak získat data.
• Připojením přímo k datům v původním zdrojovém úložišti pomocí DirectQuery. Další informace o DirectQuery najdete v tématu DirectQuery v Power BI.

Při použití DirectQuery umožňují složené modely vytvořit model Power BI, například jeden soubor .pbix Power BI Desktopu, který provede jednu nebo obě následující akce:

• Kombinuje data z jednoho nebo více zdrojů DirectQuery.
• Kombinuje data ze zdrojů DirectQuery a importuje data.

Pomocí složených modelů můžete například vytvořit model, který kombinuje následující typy dat:

• Prodejní data z podnikového datového skladu
• Prodejní cílová data z databáze SQL Serveru oddělení
• Data importovaná z tabulky

Model, který kombinuje data z více než jednoho zdroje DirectQuery nebo kombinuje DirectQuery s importovými daty, se nazývá složený model.

Relace mezi tabulkami můžete vytvářet tak, jak jste vždy měli, i když tyto tabulky pocházejí z různých zdrojů. Všechny relace, které jsou mezi zdroji, se vytvářejí s kardinalitou M:N bez ohledu na jejich skutečnou kardinalitu. Můžete je změnit na 1:N, M:1 nebo 1:1. Bez ohledu na kardinalitu, kterou nastavíte, mají relace mezi zdroji jiné chování. Funkce DAX (Data Analysis Expressions) nemůžete použít k načtení hodnot na one straně ze many strany. Můžete také vidět dopad na výkon oproti relacím M:N ve stejném zdroji.

Poznámka:

V kontextu složených modelů jsou všechny importované tabulky efektivně jediným zdrojem bez ohledu na skutečné podkladové zdroje dat.

Příklad složeného modelu

Jako příklad složeného modelu zvažte sestavu, která je připojená k podnikovému datovému skladu na SQL Serveru pomocí DirectQuery. V tomto případě datový sklad obsahuje data Sales by Country, Quarter a Bike (Product), jak je znázorněno na následujícím obrázku:

V tomto okamžiku můžete vytvářet jednoduché vizuály pomocí polí z tohoto zdroje. Následující obrázek znázorňuje celkový prodej podle ProductName pro vybrané čtvrtletí.

Ale co když máte data v excelové tabulce o produktovém manažerovi, který je přiřazený k jednotlivým produktům, spolu s prioritou marketingu? Pokud chcete zobrazit prodejní částku podle produktového manažera, nemusí být možné tato místní data přidat do podnikového datového skladu. Nebo to může trvat měsíce v nejlepším.

Místo použití DirectQuery může být možné importovat prodejní data z datového skladu. Data o prodeji se pak dají zkombinovat s daty, která jste naimportovali z tabulky. Tento přístup je však nepřiměřený z důvodů, které vedly k používání DirectQuery na prvním místě. Mezi důvody může patřit:

• Některá kombinace pravidel zabezpečení vynucovaných v podkladovém zdroji.
• Je potřeba zobrazit nejnovější data.
• Horizontální měřítko dat.

Tady jsou složené modely. Složené modely umožňují připojit se k datovému skladu pomocí DirectQuery a pak použít Získat data pro další zdroje. V tomto příkladu nejprve vytvoříme připojení DirectQuery k podnikovému datovému skladu. Používáme Získat data, zvolte Excel a pak přejdeme do tabulky, která obsahuje naše místní data. Nakonec naimportujeme tabulku, která obsahuje názvy produktů, přiřazeného manažera prodeje a prioritu.

V seznamu Pole můžete vidět dvě tabulky: původní tabulku Bike z SQL Serveru a novou tabulku ProductManagers. Nová tabulka obsahuje data importovaná z Excelu.

Podobně v zobrazení Relace v Power BI Desktopu teď vidíme další tabulku s názvem ProductManagers.

Teď musíme tyto tabulky propojit s ostatními tabulkami v modelu. Jako vždy vytvoříme relaci mezi tabulkou Bike z SQL Serveru a importovanou tabulkou ProductManagers. To znamená, že relace je mezi Bike[ProductName] a ProductManagers[ProductName]. Jak je popsáno dříve, všechny relace, které přecházejí mezi zdroji, mají výchozí kardinalitu M:N.

Teď, když jsme vytvořili tuto relaci, se zobrazí v zobrazení Relace v Power BI Desktopu, jak bychom očekávali.

Vizuály teď můžeme vytvářet pomocí libovolného pole v seznamu Pole . Tento přístup bezproblémově kombinuje data z více zdrojů. Například celkový objem prodeje pro každého produktového manažera se zobrazí na následujícím obrázku:

Následující příklad ukazuje běžný případ tabulky dimenzí , například Product nebo Customer, která se rozšiřuje o další data importovaná z jiného někam jinam. K připojení k různým zdrojům je také možné použít DirectQuery. Abychom mohli pokračovat v našem příkladu, představte si, že prodejní cíle na zemi a období jsou uložené v samostatné databázi oddělení. Jako obvykle můžete pomocí funkce Získat data připojit k datům, jak je znázorněno na následujícím obrázku:

Stejně jako dříve můžeme vytvořit relace mezi novou tabulkou a dalšími tabulkami v modelu. Pak můžeme vytvořit vizuály, které kombinují data tabulky. Pojďme se znovu podívat na zobrazení Relace , kde jsme vytvořili nové relace:

Další obrázek vychází z nových dat a relací, které jsme vytvořili. Vizuál v levém dolním rohu zobrazuje celkovou částku prodeje a cíl a výpočet odchylky ukazuje rozdíl. Data Sales Amount a Target pocházejí ze dvou různých databází SQL Serveru.

Nastavení režimu úložiště

Každá tabulka ve složeného modelu má režim úložiště, který označuje, jestli je tabulka založená na DirectQuery nebo importu. Režim úložiště lze zobrazit a upravit v podokně Vlastností . Pokud chcete zobrazit režim úložiště, klikněte pravým tlačítkem myši na tabulku v seznamu Pole a pak vyberte Vlastnosti. Následující obrázek ukazuje režim úložiště pro tabulku SalesTargets .

Režim úložiště je také možné zobrazit v popisu pro každou tabulku.

U libovolného souboru Power BI Desktopu (souboru .pbix ), který obsahuje některé tabulky z DirectQuery a některých importovaných tabulek, se na stavovém řádku zobrazí režim úložiště s názvem Smíšený. Tento termín můžete vybrat na stavovém řádku a snadno přepnout všechny tabulky k importu.

Další informace o režimu úložiště najdete v tématu Správa režimu úložiště v Power BI Desktopu.

Poznámka:

Režim smíšeného úložiště můžete použít v Power BI Desktopu a v služba Power BI.

Počítané tabulky

Počítané tabulky můžete přidat do modelu v Power BI Desktopu, který používá DirectQuery. Jazyk DAX (Data Analysis Expressions), který definuje počítanou tabulku, může odkazovat na importované tabulky nebo tabulky DirectQuery nebo na jejich kombinaci.

Počítané tabulky se vždy importují a jejich data se aktualizují při aktualizaci tabulek. Pokud počítaná tabulka odkazuje na tabulku DirectQuery, vizuály, které odkazují na tabulku DirectQuery, vždy zobrazují nejnovější hodnoty v podkladovém zdroji. Případně vizuály, které odkazují na počítanou tabulku, zobrazují hodnoty v době poslední aktualizace počítané tabulky.

Důležité

Počítané tabulky se v služba Power BI pomocí této funkce nepodporují. Další informace najdete v části Práce se složeným modelem založeným na sémantickém modelu v tomto článku.

Vliv na zabezpečení

Složené modely mají určité dopady na zabezpečení. Dotaz odeslaný do jednoho zdroje dat může obsahovat hodnoty dat načtené z jiného zdroje. V předchozím příkladu vizuál, který zobrazuje (Sales Amount) podle produktového manažera , odešle dotaz SQL do relační databáze Sales. Tento dotaz SQL může obsahovat názvy produktových manažerů a jejich přidružených produktů.

Informace, které jsou uložené v tabulce, se teď zahrnou do dotazu odeslaného do relační databáze. Pokud jsou tyto informace důvěrné, měli byste zvážit důsledky zabezpečení. Zejména zvažte následující body:

• Tyto informace může zobrazit jakýkoli správce databáze, který může zobrazit trasování nebo protokoly auditu, i bez oprávnění k datům v původním zdroji. V tomto příkladu by správce potřeboval oprávnění k excelovém souboru.

• Je třeba zvážit nastavení šifrování pro každý zdroj. Chcete se vyhnout načtení informací z jednoho zdroje šifrovaným připojením a pak neúmyslně zahrnout do dotazu, který je odesílá do jiného zdroje nešifrovaným připojením.

Pokud chcete povolit potvrzení, že jste zvážili všechny dopady na zabezpečení, Power BI Desktop při vytváření složeného modelu zobrazí zprávu s upozorněním.

Kromě toho, pokud autor přidá Tabulku1 z modelu A do složeného modelu (pojďme ho volat Model C pro referenci), pak uživatel, který zobrazí sestavu postavenou na modelu C, může dotazovat jakoukoli tabulku v modelu A, která není chráněná zabezpečením na úrovni řádků.

Z podobnýchdůvodůch Pokud soubor obsahuje složené modely, informace, které někdo načte z jednoho zdroje pomocí přihlašovacích údajů uživatele, který soubor otevře, by se v rámci dotazu odeslaly do jiného zdroje dat. Informace může zobrazit autor souboru Power BI Desktopu se zlými úmysly. Při počátečním otevření souboru Power BI Desktopu, který obsahuje více zdrojů, power BI Desktop zobrazí upozornění. Upozornění je podobné upozornění, které se zobrazí při otevření souboru, který obsahuje nativní dotazy SQL.

Vliv na výkon

Při použití DirectQuery byste měli vždy zvážit výkon, především proto, aby back-endový zdroj měl dostatek prostředků pro zajištění dobrého prostředí pro uživatele. Dobrý zážitek znamená, že se vizuály aktualizují za pět sekund nebo méně. Další rady k výkonu najdete v tématu DirectQuery v Power BI.

Použití složených modelů přidává další aspekty výkonu. Jeden vizuál může vést k odesílání dotazů do více zdrojů, což často předává výsledky z jednoho dotazu do druhého zdroje. Tato situace může mít za následek následující formy provádění:

• Zdrojový dotaz, který obsahuje velký počet hodnot literálů: Například vizuál, který požaduje celkovou částku prodeje pro sadu vybraných produktových manažerů , by nejprve potřeboval zjistit, které produkty byly spravovány těmito produktovými manažery. K této sekvenci musí dojít před odesláním dotazu SQL, který obsahuje všechna ID produktů v WHERE klauzuli.

• Zdrojový dotaz, který se dotazuje na nižší úroveň členitosti, s tím, jak se data později agregují místně: S rostoucím počtem produktů , které splňují kritéria filtru pro ProduktOvý manažer , může být neefektivní nebo neproveditelné zahrnout všechny produkty do WHERE klauzule. Místo toho můžete dotazovat relační zdroj na nižší úrovni produktů a pak výsledky agregovat místně. Pokud kardinalita produktů překročí limit 1 milion, dotaz selže.

• Více zdrojových dotazů, jeden na skupinu podle hodnoty: Pokud agregace používá DistinctCount a je seskupené podle sloupce z jiného zdroje, a pokud externí zdroj nepodporuje efektivní předávání mnoha hodnot literálů, které definují seskupení, je nutné odeslat jeden dotaz SQL na skupinu podle hodnoty.

  Vizuál, který požaduje jedinečný počet CustomerAccountNumber z tabulky SQL Server od produktových manažerů importovaných z tabulky, by potřeboval předat podrobnosti z tabulky Product Managers v dotazu odeslaném na SQL Server. U jiných zdrojů je například tato akce neproveditelná. Místo toho by se na manažera prodeje odeslal jeden dotaz SQL, a to až do určitého praktického limitu, kdy dotaz selže.

Každý z těchto případů má své vlastní důsledky na výkon a přesné podrobnosti se u každého zdroje dat liší. I když kardinalita sloupců použitých v relaci, která spojuje tyto dva zdroje, zůstává nízká, nemělo by to mít vliv na výkon několika tisíc. S rostoucí kardinalitou byste měli věnovat větší pozornost dopadu na výsledný výkon.

Kromě toho použití relací M:N znamená, že samostatné dotazy musí být odeslány do podkladového zdroje pro každou celkovou nebo mezisoučtovou úroveň, a nikoli agregace podrobných hodnot místně. Jednoduchý vizuál tabulky se součty by odeslal dva zdrojové dotazy, nikoli jeden.

Zdrojové skupiny

Zdrojová skupina je kolekce položek, jako jsou tabulky a relace, ze zdroje DirectQuery nebo všech zdrojů importu zahrnutých v datovém modelu. Složený model se skládá z jedné nebo více zdrojových skupin. Zvažte následující příklady:

• Složený model, který se připojuje k sémantickému modelu Power BI s názvem Prodej a rozšiřuje sémantický model přidáním míry Sales YTD , která není k dispozici v původním sémantickém modelu. Tento model se skládá z jedné zdrojové skupiny.
• Složený model, který kombinuje data importem tabulky z excelového listu s názvem Cíle a soubor CSV s názvem Oblasti a vytvoření připojení DirectQuery k sémantickému modelu Power BI s názvem Prodej. V tomto případě existují dvě zdrojové skupiny, jak je znázorněno na následujícím obrázku:
  • První zdrojová skupina obsahuje tabulky z excelového listu Cíle a soubor CSV oblasti .
  • Druhá zdrojová skupina obsahuje položky z sémantického modelu Sales Power BI.

Pokud jste přidali další připojení DirectQuery k jinému zdroji, například připojení DirectQuery k databázi SQL Serveru s názvem Inventory, položky z tohoto zdroje se přidají jako jiná zdrojová skupina:

Poznámka:

Import dat z jiného zdroje nepřidá jinou zdrojovou skupinu, protože všechny položky ze všech importovaných zdrojů jsou v jedné zdrojové skupině.

Zdrojové skupiny a relace

Složený model obsahuje dva typy relací:

• Vztahy uvnitř zdrojové skupiny. Tyto relace vzájemně souvisejí s položkami ve zdrojové skupině. Tyto relace jsou vždy běžné, pokud nejsou M:N, v takovém případě jsou omezené.
• Vztahy mezi zdrojovými skupinami Tyto relace začínají v jedné zdrojové skupině a končí jinou zdrojovou skupinou. Tyto relace jsou vždy omezené.

Přečtěte si další informace o rozlišení mezi pravidelnými a omezenými relacemi a jejich dopadem.

Například na následujícím obrázku jsme přidali tři relace mezi zdrojovými skupinami, které vzájemně souvisí s tabulkami napříč různými zdrojovými skupinami:

Místní a vzdálené

Jakákoli položka, která je ve zdrojové skupině, která je zdrojovou skupinou DirectQuery, se považuje za vzdálenou, pokud nebyla položka definována místně jako součást rozšíření nebo rozšiřování zdroje DirectQuery a není součástí vzdáleného zdroje, jako je míra nebo počítaná tabulka. Počítaná tabulka založená na tabulce ze zdrojové skupiny DirectQuery patří do zdrojové skupiny Import a považuje se za místní. Každá položka, která je ve zdrojové skupině Import, se považuje za místní. Pokud například ve složeného modelu definujete následující míru, která používá připojení DirectQuery ke zdroji inventáře, bude míra považována za místní:

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

Skupiny výpočtů, dotazování a vyhodnocení míry

Skupiny výpočtů představují způsob, jak snížit počet redundantních měr a seskupit společné výrazy měr. Typické případy použití jsou výpočty časového měřítka, ve kterých chcete být schopni přepínat od skutečných hodnot k datu, čtvrtletí k datu nebo výpočtům mezi rokem a rokem. Při práci s složenými modely je důležité vědět o interakci mezi skupinami výpočtů a o tom, jestli míra odkazuje jenom na položky z jedné vzdálené zdrojové skupiny. Pokud míra odkazuje pouze na položky z jedné vzdálené zdrojové skupiny a vzdálený model definuje skupinu výpočtů, která má vliv na míru, použije se tato skupina výpočtů, i když byla míra definovaná ve vzdáleném modelu nebo v místním modelu. Pokud však míra neodkazuje na položky z jedné vzdálené zdrojové skupiny výhradně, ale odkazuje na položky ze vzdálené zdrojové skupiny, na které se používá vzdálená skupina výpočtů, mohou být výsledky míry stále ovlivněny vzdálenou skupinou výpočtů. Představte si následující příklad:

• Reseller Sales je míra definovaná ve vzdáleném modelu.
• Vzdálený model obsahuje skupinu výpočtů, která mění výsledek prodeje prodejců.
• Internet Sales je míra definovaná v místním modelu.
• Total Sales je míra definovaná v místním modelu a má následující definici:

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

V tomto scénáři není míra Internet Sales ovlivněna skupinou výpočtů definovanou ve vzdáleném modelu, protože nejsou součástí stejného modelu. Skupina výpočtů ale může změnit výsledek míry Reseller Sales , protože jsou ve stejném modelu. Tento fakt znamená, že výsledky vrácené mírou Total Sales musí být pečlivě vyhodnoceny. Představte si, že pomocí skupiny výpočtů ve vzdáleném modelu vrátíme výsledky od roku k datu. Výsledek vrácený reseller sales je nyní hodnotou od roku do data, zatímco výsledek vrácený internetovým prodejemje stále skutečný. Výsledek celkového prodeje je teď pravděpodobně neočekávaný, protože přidá skutečný výsledek od roku do data.

Složené modely v sémantických modelech Power BI a službě Analysis Services

Pomocí sémantických modelů Power BI a Analysis Services můžete vytvořit složený model pomocí připojení DirectQuery pro připojení k sémantickým modelům Power BI, Azure Analysis Services (AAS) a SQL Serveru 2022 Analysis Services. Pomocí složeného modelu můžete kombinovat data v těchto zdrojích s jinými DirectQuery a importovanými daty. Autoři sestav, kteří chtějí kombinovat data ze svého podnikového sémantického modelu s jinými daty, která vlastní, jako je excelová tabulka, nebo chtějí přizpůsobit nebo rozšířit metadata ze svého podnikového sémantického modelu, budou tyto funkce zvlášť užitečné.

Správa složených modelů v sémantických modelech Power BI

Pokud chcete povolit vytváření a spotřebu složených modelů v sémantických modelech Power BI, musí mít váš tenant povolené následující přepínače:

• Povolit koncové body XMLA a analyzovat v aplikaci Excel pomocí místních sémantických modelů Pokud je tento přepínač zakázaný, nejde vytvořit připojení DirectQuery k sémantickému modelu Power BI.
• Uživatelé můžou pracovat s sémantických modelů Power BI v Excelu pomocí živého připojení. Pokud je tento přepínač zakázaný, uživatelé nemůžou provádět živá připojení k sémantickým modelům Power BI, aby tlačítko Provést změny tohoto modelu nebylo možné dosáhnout.
• Povolte připojení DirectQuery k sémantickým modelům Power BI. Další informace o tomto přepínači a jeho účinku najdete v následujících odstavcích.

U kapacit Premium a Premium na uživatele by navíc mělo být povolené nastavení koncový bod XMLA a nastaveno na hodnotu Jen pro čtení nebo Zápis.

Správci tenantů můžou na portálu pro správu povolit nebo zakázat připojení DirectQuery k sémantickým modelům Power BI. I když je tato možnost ve výchozím nastavení povolená, zakázání zabrání uživatelům v publikování nových složených modelů v sémantických modelech Power BI do služby.

Stávající sestavy, které využívají složený model v sémantickém modelu Power BI, budou fungovat i nadále a uživatelé můžou složený model vytvářet v Desktopu, ale nebudou moct publikovat do služby. Když místo toho vytvoříte připojení DirectQuery k sémantickému modelu Power BI výběrem možnosti Provést změny v tomto modelu , zobrazí se následující zpráva s upozorněním:

Tímto způsobem můžete stále zkoumat sémantický model v místním prostředí Power BI Desktopu a vytvořit složený model. Sestavu ale nebudete moct publikovat do služby. Při publikování sestavy a modelu se zobrazí následující chybová zpráva a publikace bude blokovaná:

Mějte na paměti, že živá připojení k sémantickým modelům Power BI nejsou ovlivněná přepínačem ani živými nebo DirectQuery připojeními ke službě Analysis Services. Budou fungovat i nadále bez ohledu na to, jestli je přepínač vypnutý. Všechny publikované sestavy, které využívají složený model v sémantickém modelu Power BI, budou fungovat i v případě, že je přepínač po publikování vypnutý.

Vytvoření složeného modelu na sémantickém modelu nebo modelu

Vytvoření složeného modelu na sémantickém modelu Power BI nebo modelu Analysis Services vyžaduje, aby sestava měla místní model. Můžete začít z živého připojení a přidat nebo upgradovat na místní model nebo začít s připojením DirectQuery nebo importovanými daty, které automaticky vytvoří místní model v sestavě.

Pokud chcete zjistit, která připojení se v modelu používají, zkontrolujte stavový řádek v pravém dolním rohu Power BI Desktopu. Pokud jste připojení jenom ke zdroji analysis Services, zobrazí se zpráva podobná následujícímu obrázku:

Pokud jste připojení k sémantickému modelu Power BI, zobrazí se zpráva, ke které sémantickému modelu Power BI jste připojení:

Pokud chcete přizpůsobit metadata polí v živém připojeném sémantickém modelu, na stavovém řádku vyberte Provést změny tohoto modelu . Alternativně můžete vybrat tlačítko Provést změny tohoto modelu na pásu karet, jak je znázorněno na následujícím obrázku. V zobrazení sestavy proveďte změny tohoto tlačítka modelu na kartě Modelování. V zobrazení modelu je tlačítko na kartě Domů.

Výběrem tlačítka se zobrazí dialogové okno s potvrzením přidání místního modelu. Výběrem možnosti Přidat místní model povolíte vytváření nových sloupců nebo úpravu metadat pro pole z sémantických modelů Power BI nebo Analysis Services. Následující obrázek znázorňuje zobrazené dialogové okno.

Když jste živě připojení ke zdroji Analysis Services, neexistuje žádný místní model. Pokud chcete directQuery použít pro živé připojené zdroje, jako jsou sémantické modely Power BI a Analysis Services, musíte do sestavy přidat místní model. Když publikujete sestavu s místním modelem do služba Power BI, publikuje se dobře sémantický model pro tento místní model.

Řetězení

Sémantické modely a sémantické modely, na kterých jsou založené, tvoří řetězec. Tento proces označovaný jako řetězení umožňuje publikovat sestavu a sémantický model založený na jiných sémantických modelech Power BI, což byla funkce, která dříve nebyla možná.

Představte si například, že váš kolega publikuje sémantický model Power BI s názvem Prodej a rozpočet založený na modelu Analysis Services s názvem Prodej a kombinuje ho s excelovým listem s názvem Rozpočet.

Když publikujete novou sestavu (a sémantický model) s názvem Sales and Budget Europe , která je založená na sémantickém modelu Sales and Budget Power BI publikovaném vaším kolegou, provedete další úpravy nebo rozšíření, takže efektivně přidáváte sestavu a sémantický model do řetězce délky 3, který začal modelem Sales Analysis Services. a končí sémantickým modelem Power BI pro prodej a rozpočet v Evropě . Následující obrázek vizualizuje tento proces řetězení.

Řetězec na předchozím obrázku má délku tři, což je maximální délka. Rozšíření nad rámec délky řetězce tří se nepodporuje a vede k chybám.

Oprávnění a licencování

Uživatelé, kteří přistupují k sestavám pomocí složeného modelu, musí mít správná oprávnění pro všechny sémantické modely a modely v řetězu.

Vlastník složeného modelu vyžaduje oprávnění k sestavení pro sémantické modely používané jako zdroje, aby k těmto modelům mohli přistupovat jiní uživatelé jménem vlastníka. V důsledku toho vytvoření připojení složeného modelu v Power BI Desktopu nebo vytvoření sestavy v Power BI vyžaduje oprávnění k sestavení pro sémantické modely používané jako zdroje.

Uživatelé, kteří zobrazují sestavy používající složený model, budou obecně vyžadovat oprávnění ke čtení u samotného složeného modelu a sémantických modelů používaných jako zdroje. Oprávnění k sestavení se můžou vyžadovat, pokud jsou sestavy v pracovním prostoru Pro. Tyto přepínače tenanta by měly být pro uživatele povolené.

Požadovaná oprávnění je možné ilustrovat pomocí následujícího příkladu:

• Složený model A (vlastněný vlastníkem A)

  • Zdroj dat A1: Sémantický model B.
    Vlastník A musí mít oprávnění k sestavení pro sémantický model B , aby uživatelé mohli zobrazit sestavu pomocí složeného modelu A.

• Složený model C (vlastněný vlastníkem C)

  • Zdroj dat C1: Sémantický model D
    Vlastník C musí mít oprávnění k sestavení pro sémantický model D , aby uživatelé mohli zobrazit sestavu pomocí složeného modelu C.
  • Zdroj dat C2: Složený model A
    Vlastník C musí mít oprávnění k sestavení pro složený model A a oprávnění ke čtení pro sémantický model B.

Uživatel, který zobrazuje sestavy používající složený model A , musí mít oprávnění ke čtení pro složený model A i sémantický model B, zatímco uživatel prohlížející sestavy používající složený model C musí mít oprávnění ke čtení pro složený model C, sémantický model D, složený model A a sémantický model B.

Poznámka:

Důležité informace o oprávněních požadovaných pro složené modely v sémantických modelech Power BI a modelech Analysis Services najdete v tomto blog příspěvku.

Pokud je nějaká datová sada v řetězci v pracovním prostoru Premium na uživatele, uživatel, který k ní přistupuje, potřebuje licenci Premium na uživatele. Pokud je nějaká datová sada v řetězci v pracovním prostoru Pro, uživatel, který k ní přistupuje, potřebuje licenci Pro. Pokud jsou všechny datové sady v řetězci v kapacitách Premium nebo Fabric F64 nebo větší kapacitě, může k ní uživatel přistupovat pomocí bezplatné licence.

Upozornění zabezpečení

Když použijete DirectQuery pro sémantické modely Power BI a funkci Analysis Services, zobrazí se dialogové okno upozornění zabezpečení, které je znázorněno na následujícím obrázku.

Data se můžou nasdílet z jednoho zdroje dat do jiného, což je stejné upozornění zabezpečení pro kombinování DirectQuery a import zdrojů v datovém modelu. Další informace o tomto chování najdete v Power BI Desktopu pomocí složených modelů.

Podporované scénáře

Složené modely můžete vytvářet pomocí dat z sémantických modelů Power BI nebo modelů Analysis Services, které budou obsluhovat následující scénáře:

• Připojení dat z různých zdrojů: Import (například soubory), sémantické modely Power BI, modely Analysis Services
• Vytváření vztahů mezi různými zdroji dat
• Psaní měr, které používají pole z různých zdrojů dat
• Vytváření nových sloupců pro tabulky z sémantických modelů Power BI nebo modelů Analysis Services
• Vytváření vizuálů, které používají sloupce z různých zdrojů dat
• Tabulku můžete ze svého modelu odebrat pomocí seznamu polí, aby byly modely co nejpřesnější a nejpřesnější (pokud se připojíte k perspektivě, nemůžete z modelu odebrat tabulky).
• Můžete určit, které tabulky se mají načíst, a nemusíte načítat všechny tabulky, pokud chcete jenom konkrétní podmnožinu tabulek. Viz Načtení podmnožina tabulek dále v tomto dokumentu.
• Můžete určit, zda se mají přidat jakékoli tabulky, které se následně přidají do sémantického modelu po vytvoření připojení v modelu.

Práce se složeným modelem založeným na sémantickém modelu

Při práci s DirectQuery pro sémantické modely Power BI a Analysis Services zvažte následující:

• Pokud aktualizujete zdroje dat a dojde k chybám s konfliktními názvy polí nebo tabulek, Power BI chyby vyřeší za vás.

• Nemůžete upravovat, odstraňovat ani vytvářet nové relace ve stejném sémantickém modelu Power BI nebo ve zdroji Analysis Services. Pokud máte k těmto zdrojům přístup pro úpravy, můžete změny provést přímo ve zdroji dat.

• Nemůžete změnit datové typy sloupců načtených ze sémantického modelu Power BI nebo ze zdroje Analysis Services. Pokud potřebujete datový typ změnit, změňte ho ve zdroji nebo použijte počítaný sloupec.

• Pokud chcete vytvářet sestavy v služba Power BI na složeném modelu založeném na jiném sémantickém modelu, musí být nastaveny všechny přihlašovací údaje.

• Připojení na místní server SQL Server 2022 a novější analysis Services nebo IAAS vyžadují místní bránu dat (režim Standard).

• Všechna připojení ke vzdáleným sémantickým modelům Power BI se vytváří pomocí jednotného přihlašování. Ověřování pomocí instančního objektu se v současné době nepodporuje.

• Pravidla zabezpečení na úrovni řádků se použijí na zdroj, na kterém jsou definovány, ale nebudou použita pro žádné jiné sémantické modely v modelu. Zabezpečení na úrovni řádků definované v sestavě se nepoužije na vzdálené zdroje a zabezpečení na úrovni řádků nastavené na vzdálené zdroje se nepoužije u jiných zdrojů dat. Nemůžete také definovat zabezpečení na úrovni řádků v tabulce načtené ze vzdáleného zdroje a zabezpečení na úrovni řádků definované v místních tabulkách nebude filtrovat žádné tabulky načtené ze vzdáleného zdroje.

• Klíčové ukazatele výkonu, zabezpečení na úrovni řádků a překlady se ze zdroje neimportují.

• Při použití hierarchie kalendářních dat se může zobrazit neočekávané chování. Pokud chcete tento problém vyřešit, použijte místo toho sloupec kalendářních dat. Po přidání hierarchie kalendářních dat do vizuálu můžete přepnout do sloupce kalendářního data kliknutím na šipku dolů v názvu pole a následným kliknutím na název tohoto pole místo použití hierarchie kalendářních dat:

  

  Další informace o používání sloupců kalendářních dat a hierarchií kalendářních dat najdete v tématu Použití automatického data nebo času v Power BI Desktopu.

• Maximální délka řetězce modelů je tři. Rozšíření nad rámec délky řetězce tří se nepodporuje a vede k chybám.

• U modelu je možné nastavit příznak od řetězení, aby se zabránilo vytvoření nebo rozšíření řetězu. Další informace najdete v tématu Správa připojení DirectQuery k publikovanému sémantickému modelu .

• Připojení k sémantickému modelu Power BI nebo modelu Analysis Services se v Power Query nezobrazí.

Při práci s DirectQuery pro sémantické modely Power BI a Analysis Services platí následující omezení :

• Parametry pro názvy databází a serverů jsou aktuálně zakázané.
• Definování zabezpečení na úrovni řádků u tabulek ze vzdáleného zdroje se nepodporuje.
• Použití některého z následujících zdrojů jako zdroje DirectQuery se nepodporuje:
  • tabulkové modely Služba Analysis Services serveru SQL (SSAS) před verzí 2022
  • Multidimenzionální modely SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Sémantické modely v reálném čase
  • Ukázkové sémantické modely
  • Aktualizace Excelu Online
  • Data importovaná ze souborů Excelu nebo CSV ve službě
  • Metriky využití
  • Sémantické modely uložené v pracovním prostoru
• Použití Power BI Embedded s sémantických modelů, které obsahují připojení DirectQuery k modelu Analysis Services, se v současné době nepodporuje.
• Publikování sestavy na web pomocí funkce publikovat na webu se nepodporuje.
• Skupiny výpočtů ve vzdálených zdrojích nejsou podporovány s nedefinovanými výsledky dotazů.
• Počítané tabulky nejsou ve službě podporovány pomocí této funkce. Při pokusu o aktualizaci sémantického modelu s počítanou tabulkou nebo počítaným sloupcem, který odkazuje na zdroj dat DirectQuery, se zobrazí chybová zpráva "Jednotné přihlašování (SSO) není zadané".
• Pokud po nastavení připojení DirectQuery přejmenujete pracovní prostor, budete muset aktualizovat zdroj dat v Power BI Desktopu, aby sestava pokračovala v práci.
• Automatická aktualizace stránky (APR) se podporuje jenom v některých scénářích v závislosti na typu zdroje dat. Další informace najdete v článku Automatická aktualizace stránky v Power BI .
• Převzetí sémantického modelu, který používá DirectQuery k jiným funkcím sémantických modelů , se v současné době nepodporuje.
• Stejně jako u jakéhokoli zdroje dat DirectQuery se hierarchie definované v modelu Analysis Services nebo sémantickém modelu Power BI nezobrazí při připojování k modelu nebo sémantickému modelu v režimu DirectQuery pomocí Excelu.

Při práci s DirectQuery pro sémantické modely Power BI a Analysis Services je potřeba vzít v úvahu několik dalších věcí:

• Ve vztazích mezi různými zdrojovými skupinami používejte sloupce s nízkou kardinalitou: Při vytváření relace mezi dvěma různými zdrojovými skupinami by sloupce, které se účastní relace (označované také jako sloupce spojení), měly mít nízkou kardinalitu, ideálně 50 000 nebo méně. Tento faktor platí pro sloupce klíčů, které nejsou řetězcové; Pro sloupce s klíči řetězce se podívejte na následující aspekty.
• Vyhněte se použití velkých řetězců klíčových sloupců v relacích mezi zdrojovými skupinami: Při vytváření relace mezi zdrojovými skupinami nepoužívejte velké řetězcové sloupce jako sloupce relací, zejména pro sloupce s větší kardinalitou. Pokud jako sloupec relace musíte použít sloupce řetězců, vypočítejte očekávanou délku řetězce filtru vynásobením kardinality (C) průměrnou délkou sloupce řetězce (A). Ujistěte se, že očekávaná délka řetězce je nižší než 250 000, aby hodnota A ∗ C < 250 000.

Další informace a pokyny najdete v pokynech ke složenému modelu.

Aspekty tenanta

Každý model s připojením DirectQuery k sémantickému modelu Power BI nebo službě Analysis Services musí být publikován ve stejném tenantovi, což je zvlášť důležité při přístupu k sémantickému modelu Power BI nebo modelu Analysis Services pomocí identit hosta B2B, jak je znázorněno v následujícím diagramu. Podívejte se na uživatele typu host, kteří můžou upravovat a spravovat obsah a najít adresu URL tenanta pro publikování.

Představte si následující diagram. Očíslované kroky v diagramu jsou popsány v následujících odstavcích.

V diagramu pracuje Ash se společností Contoso a přistupuje k datům poskytovaným společností Fabrikam. Pomocí Power BI Desktopu Vytvoří Ash připojení DirectQuery k modelu Analysis Services, který je hostovaný v tenantovi Fabrikam.

K ověření používá Ash identitu uživatele typu host B2B (krok 1 v diagramu).

Pokud je sestava publikovaná v služba Power BI společnosti Contoso (krok 2), sémantický model publikovaný v tenantovi Contoso se nemůže úspěšně ověřit v modelu Analysis Services společnosti Fabrikam (krok 3). V důsledku toho sestava nebude fungovat.

V tomto scénáři, protože použitý model Analysis Services je hostovaný v tenantovi společnosti Fabrikam, musí být sestava také publikovaná v tenantovi společnosti Fabrikam. Po úspěšném publikování v tenantovi společnosti Fabrikam (krok 4) může sémantický model úspěšně získat přístup k modelu služby Analysis Services (krok 5) a sestava bude správně fungovat.

Práce se zabezpečením na úrovni objektů

Když složený model získá data z sémantického modelu Power BI nebo analysis Services prostřednictvím DirectQuery a tento zdrojový model je zabezpečený zabezpečením na úrovni objektů, můžou si spotřebitelé složeného modelu všimnout neočekávaných výsledků. Následující část vysvětluje, jak můžou tyto výsledky nastat.

Zabezpečení na úrovni objektů (OLS) umožňuje autorům modelů skrýt objekty, které tvoří schéma modelu (tj. tabulky, sloupce, metadata atd.) od příjemců modelu (například tvůrce sestav nebo autor složeného modelu). Při konfiguraci OLS pro objekt vytvoří autor modelu roli a pak odebere přístup k objektu pro uživatele, kteří jsou k této roli přiřazeni. Z hlediska těchto uživatelů skrytý objekt prostě neexistuje.

OLS je definována pro zdrojový model a použita pro zdrojový model. Nelze jej definovat pro složený model založený na zdrojovém modelu.

Pokud je složený model postaven na sémantickém modelu Power BI chráněném OLS nebo modelu Analysis Services prostřednictvím připojení DirectQuery, schéma modelu ze zdrojového modelu se zkopíruje do složeného modelu. To, co se zkopíruje, závisí na tom, co autor složeného modelu umožňuje zobrazit ve zdrojovém modelu podle pravidel OLS, která tam platí. Samotná data se nekopírují do složeného modelu – v případě potřeby se vždy načtou přes DirectQuery ze zdrojového modelu. Jinými slovy, načítání dat se vždy vrátí ke zdrojovému modelu, kde platí pravidla OLS.

Vzhledem k tomu, že složený model není zabezpečený pravidly OLS, objekty, které uživatelé složeného modelu vidí, jsou ty, které by autor složeného modelu mohl vidět ve zdrojovém modelu, a ne to, k čemu by sami měli přístup. To může vést k následujícím situacím:

• Někdo, kdo se dívá na složený model, může vidět objekty, které jsou před nimi skryté ve zdrojovém modelu pomocí OLS.
• Naopak nemusí ve složeného modelu vidět objekt, který vidí ve zdrojovém modelu, protože tento objekt byl skrytý od autora složeného modelu pravidly OLS, která řídí přístup ke zdrojovému modelu.

Důležitým bodem je, že i přes případ popsaný v první odrážce uživatelé složeného modelu nikdy neuvidí skutečná data, která by neměli vidět, protože data nejsou ve skutečnosti umístěná ve složeného modelu. Kvůli DirectQuery se načítá podle potřeby ze zdrojového sémantického modelu, kde OLS blokuje neoprávněný přístup.

S ohledem na toto pozadí zvažte následující scénář:

1. Správa_user publikoval podnikový sémantický model pomocí sémantického modelu Power BI nebo modelu Analysis Services, který má tabulku Customer a Territory. Správa_user publikuje sémantický model do služba Power BI a nastaví pravidla OLS, která mají následující účinek:

   • Finanční uživatelé nevidí tabulku Customer (Zákazník)
   • Uživatelé marketingu nevidí tabulku Territory

2. Finance_user publikuje sémantický model s názvem Finance sémantický model a sestavu s názvem Finance report, která se připojuje přes DirectQuery k podnikovému sémantickému modelu publikovanému v kroku 1. Sestava Finance obsahuje vizuál, který používá sloupec z tabulky Territory.

3. Marketing_user otevře sestavu Finance. Vizuál, který používá tabulku Territory, se zobrazí, ale vrátí chybu, protože při otevření sestavy se DirectQuery pokusí načíst data ze zdrojového modelu pomocí přihlašovacích údajů Marketing_user, který je zablokovaný v zobrazení tabulky Territory podle pravidel OLS nastavených v podnikovém sémantickém modelu.

4. Marketing_user vytvoří novou sestavu s názvem Marketing Report, která jako zdroj používá sémantický model Finance. Seznam polí zobrazuje tabulky a sloupce, ke kterým Finance_user má přístup. Proto je tabulka Territory zobrazena v seznamu polí, ale tabulka Zákazník není. Když se ale Marketing_user pokusí vytvořit vizuál, který využívá sloupec z tabulky Territory, vrátí se chyba, protože v tomto okamžiku se DirectQuery pokusí načíst data ze zdrojového modelu pomocí přihlašovacích údajů Marketing_user a pravidla OLS znovu zahajují a blokují přístup. Totéž se stane, když Marketing_user vytvoří nový sémantický model a sestavu, která se připojí k sémantickému modelu Finance s připojením DirectQuery – v seznamu polí uvidí tabulku Territory, protože to Finance_user vidět, ale když se pokusí vytvořit vizuál, který tuto tabulku využívá, budou blokovány pravidly OLS v podnikovém sémantickém modelu.

5. Teď řekněme, že Správa_user aktualizuje pravidla OLS v podnikovém sémantickém modelu, aby se finance přestaly zobrazovat v tabulce Territory.

6. Aktualizovaná pravidla OLS se projeví pouze v sémantickém modelu Finance při aktualizaci. Když tedy Finance_user aktualizuje sémantický model Finance, tabulka Territory se už nebude zobrazovat v seznamu polí a vizuál v sestavě Finance, který používá sloupec z tabulky Territory, vrátí chybu pro Finance_user, protože teď nemá povolený přístup k tabulce Territory.

Shrnutí:

• Příjemci složeného modelu uvidí výsledky pravidel OLS, která se po vytvoření modelu vztahují na autora složeného modelu. Když se tedy vytvoří nová sestava založená na složeného modelu, zobrazí se v seznamu polí tabulky, ke kterým měl autor složeného modelu přístup při vytváření modelu bez ohledu na to, k čemu má aktuální uživatel ve zdrojovém modelu přístup.
• Pravidla OLS nelze definovat na samotném složeného modelu.
• Spotřebitel složeného modelu nikdy neuvidí skutečná data, která by neměli vidět, protože příslušná pravidla OLS ve zdrojovém modelu je zablokují, když se DirectQuery pokusí načíst data pomocí svých přihlašovacích údajů.
• Pokud zdrojový model aktualizuje pravidla OLS, ovlivní tyto změny pouze složený model při aktualizaci.

Načtení podmnožina tabulek z sémantického modelu Power BI nebo modelu Analysis Services

Při připojování k sémantickému modelu Power BI nebo modelu Analysis Services pomocí připojení DirectQuery se můžete rozhodnout, ke kterým tabulkám se chcete připojit. Po připojení k modelu můžete také automaticky přidat libovolnou tabulku, která se může přidat do sémantického modelu nebo modelu. Když se připojíte k perspektivě, bude váš model obsahovat všechny tabulky v sémantickém modelu a všechny tabulky, které nejsou zahrnuty do perspektivy, budou skryté. Kromě toho se automaticky přidá jakákoli tabulka, která by mohla být přidána do perspektivy. V nabídce Nastavení se můžete rozhodnout, že se po prvním nastavení připojení automaticky připojíte k tabulkám, které se přidají do sémantického modelu.

Toto dialogové okno se nezobrazí pro živá připojení.

Poznámka:

Toto dialogové okno se zobrazí jenom v případě, že do existujícího modelu přidáte připojení DirectQuery k sémantickému modelu Power BI nebo modelu Analysis Services. Toto dialogové okno můžete otevřít také tak, že po vytvoření změníte připojení DirectQuery k sémantickému modelu Power BI nebo modelu Analysis Services v nastavení zdroje dat.

Nastavení pravidel odstranění duplicitních dat

Pravidla odstranění duplicitních dat můžete zadat tak, aby názvy měr a tabulek byly ve složeného modelu jedinečné pomocí možnosti Nastavení v dialogovém okně zobrazeném výše:

V předchozím příkladu jsme se rozhodli přidat "(marketing)" jako příponu k libovolné tabulce nebo názvu míry, která je v konfliktu s jiným zdrojem ve složeném modelu. Všimněte si, že můžete:

• zadejte text, který se má přidat do názvu konfliktních tabulek nebo měr.
• určete, zda má být text přidán do tabulky nebo názvu míry jako předpona nebo přípona.
• použití pravidla odstranění duplicitních dat u tabulek, měr nebo obojího
• Zvolte, že se pravidlo odstranění duplicitních dat použije jenom v případě, že dojde ke konfliktu názvů nebo ho použijete po celou dobu. Výchozí hodnota je použít pravidlo pouze v případě, že dojde k duplikaci. V našem příkladu se žádná tabulka nebo míra z marketingového zdroje, které nemají v prodejním zdroji duplikát, nezobrazí změnu názvu.

Po vytvoření připojení a nastavení pravidla odstranění duplicitních dat se v seznamu polí zobrazí jak Zákazník, tak Zákazník (marketing) podle pravidla odstranění duplicit nastavených v našem příkladu:

Pokud nezadáte pravidlo odstranění duplicitních dat nebo zadaná pravidla odstranění duplicitních dat nevyřeší konflikt názvů, budou se nadále používat standardní pravidla odstranění duplicitních dat. Standardní pravidla odstranění duplicitních dat přidávají číslo k názvu konfliktní položky. V případě konfliktu názvů v tabulce Customer (Zákazník) se jedna z tabulek Customer (Zákazník) přejmenuje na Customer 2 (Zákazník 2).

Úvahy a omezení

Složené modely představují několik aspektů a omezení:

Připojení ve smíšeném režimu – Pokud používáte připojení ve smíšeném režimu, které obsahuje online data (například sémantický model Power BI) a místní sémantický model (například excelový sešit), musíte mít vytvořené mapování brány, aby se vizuály správně zobrazily.

V současné době se přírůstková aktualizace podporuje jenom u složených modelů připojujících se ke zdrojům dat SQL, Oracle a Teradata.

Následující živé Připojení tabulkové zdroje nelze použít se složenými modely:

• SAP HANA
• SAP Business Warehouse
• Služba Analysis Services serveru SQL starší než verze 2022
• Metriky využití (Můj pracovní prostor)

Použití sémantických modelů streamování ve složených modelech se nepodporuje.

Stávající omezení DirectQuery se stále vztahují při použití složených modelů. Mnohé z těchto omezení jsou teď na tabulce v závislosti na režimu úložiště tabulky. Počítaný sloupec v tabulce importu může například odkazovat na jiné tabulky, které nejsou v DirectQuery, ale počítaný sloupec v tabulce DirectQuery může stále odkazovat pouze na sloupce ve stejné tabulce. Další omezení platí pro model jako celek, pokud některé z tabulek v modelu jsou DirectQuery. Například funkce Quick Přehledy není v modelu dostupná, pokud některá z tabulek v něm má režim úložiště DirectQuery.

Související obsah

Další informace o složených modelech a DirectQuery najdete v následujících článcích:

• Použití relací M:N v Power BI Desktopu
• Správa režimu úložiště v Power BI Desktopu
• DirectQuery v Power BI
• Zdroje dat Power BI
• Relace modelu v Power BI Desktopu