Používanie zložených modelov v aplikácii Power BI Desktop

Pokiaľ ste v minulosti v aplikácii Power BI Desktop použili v zostave režim DirectQuery, žiadne iné pripojenia údajov pre danú zostavu neboli povolené, či už išlo o režim DirectQuery alebo Import. V prípade zložených modelov sa toto obmedzenie odstránilo. Zostava tak môže bez problémov zahŕňať údajové pripojenia z viac než jedného režimu údajového pripojenia DirectQuery alebo Import, a to v ľubovoľnej kombinácii.

Funkcia zložených modelov v aplikácii Power BI Desktop sa skladá z troch súvisiacich funkcií:

• Zložené modely: Umožňujú, aby zostava mala dve alebo viac pripojení údajov z rôznych skupín zdrojov. Týmito skupinami zdrojov môže byť jedno alebo viac pripojení v rámci režimu DirectQuery a pripojenie importu, dve alebo viac pripojení v rámci režimu DirectQuery alebo ľubovoľná kombinácia. Tento článok sa podrobne popisuje zložené modely.

• Vzťahy typu many-to-many: Pomocou zložených modelov môžete medzi tabuľkami vytvoriť vzťahy typu many-to-many. Tento prístup odstraňuje požiadavky na jedinečné hodnoty v tabuľkách. Týmto sa odstránia aj predchádzajúce riešenia, ktoré sa vyžadovali napríklad na vytvorenie vzťahov (vytvorením nových tabuliek). Ďalšie informácie nájdete v téme Použitie vzťahov typu many-many v aplikácii Power BI Desktop.

• Režim úložiska: Odteraz môžete zadať, ktoré vizuály dotazujú serverové zdroje údajov. Táto funkcia pomáha zlepšiť výkon a znížiť počet načítaní na serverovej verzii. V minulosti dokonca aj jednoduché vizuály, ako napríklad rýchle filtre, vytvárali dotazy na serverové zdroje. Ďalšie informácie nájdete v téme Spravovanie režimu úložiska v aplikácii Power BI Desktop.

Používanie zložených modelov

Vďaka zloženým modelom sa môžete pri používaní aplikácie Power BI Desktop alebo služba Power BI pripojiť k rôznym typom zdrojov údajov. Tieto údajové pripojenia môžete vytvoriť niekoľkými spôsobmi:

• Údaje do služby Power BI importujete, čo je najbežnejší spôsob získania údajov.
• K údajom sa môžete prostredníctvom režimu DirectQuery pripojiť priamo v ich pôvodnom zdrojovom odkladacom priestore. Ďalšie informácie o režime DirectQuery nájdete v téme Režim DirectQuery v Power BI.

Keď používate režim DirectQuery, zložené modely umožňujú vytvoriť model služby Power BI (napríklad jednoduchý súbor aplikácie Power BI Desktop s príponou .pbix , ktorý umožňuje jednu alebo obe nasledujúce akcie:

• Kombinovanie údajov z jedného alebo viacerých zdrojov režimu DirectQuery.
• Kombinovanie údajov zo zdrojov režimu DirectQuery a importovanie údajov.

Pomocou zložených modelov môžete napríklad vytvoriť model, ktorý kombinuje nasledujúce typy údajov:

• Údaje o predaji z podnikového skladu údajov.
• Údaje o cieľoch predaja z databázy SQL Servera podľa oddelení.
• Údaje importované z tabuľkového hárka.

Model, ktorý spája údaje z viacerých zdrojov režimu DirectQuery alebo kombinuje údaje režimu DirectQuery s údajmi režimu Import, sa označuje ako zložený model.

Aj napriek tomu môžete vytvoriť vzťahy medzi tabuľkami, a to dokonca aj vtedy, ak dané tabuľky pochádzajú z rôznych zdrojov. Všetky vzťahy zo krížového zdroja sa vytvárajú s kardinalitou many-to-many, bez ohľadu na ich aktuálnu kardinalitu. Môžete ich zmeniť na možnosti One-to-many, Many-to-one alebo One-to-one. Podľa toho, akú kardinalitu nastavíte, vzťahy medzi zdrojmi majú odlišné správanie. Na načítanie hodnôt na one strane zo many strany nie je možné použiť funkcie jazyka DAX (Data Analysis Expressions). Môžete tiež vidieť vplyv na výkon v porovnaní so vzťahmi Many-to-many v rámci toho istého zdroja.

Poznámka

Pokiaľ ide o zložené modely, jediným zdrojom sú prakticky všetky importované tabuľky bez ohľadu na ich skutočný základný zdroj údajov.

Príklad zloženého modelu

Ako príklad zloženého modelu si predstavte zostavu, ktorá sa pripája k podnikovým skladom údajov v SQL Serveri pomocou režimu DirectQuery. V tejto inštancii sklad údajov obsahuje údaje tabuľky Predaj podľa krajiny, Štvrťrok a Bicykel (produkt ), ako je to znázornené na nasledujúcom obrázku:

Teraz by ste mohli vytvoriť jednoduché vizuály s použitím polí z tohto zdroja. Na nasledujúcom obrázku je zobrazený celkový predaj za vybratý štvrťrok podľa názvu Produktu.

Čo však v prípade, ak máte v excelovom tabuľkovom hárku údaje o produktovom manažérovi priradenom ku každému produktu spolu s marketingovú prioritou? Ak chcete zobraziť Čiastku predaja podľa Produktového manažéra, pridanie týchto lokálnych údajov do podnikového skladu údajov možno nebude možné. Alebo by to pri najlepšom čase mohlo trvať mesiace.

Údaje o predaji by sa mohli dať importovať zo skladu údajov namiesto použitia režimu DirectQuery. A potom by sa mohli skombinovať s údajmi importovanými z tabuľkového hárka. Tento postup je však nerozumný z dôvodov, ktoré v prvom rade viedli k použitiu režimu DirectQuery. Medzi tieto dôvody môže patriť:

• Kombinácia pravidiel zabezpečenia vynútených v základnom zdroji.
• Potreba zobrazovať najnovšie údaje.
• Celkový objem údajov.

A tu prichádzajú na rad zložené modely. Zložené modely vám umožňujú pripojiť sa k skladu údajov pomocou režimu DirectQuery a potom použiť možnosť Získať údaje pre ďalšie zdroje. V tomto príklade najskôr vytvoríme pripojenie režimu DirectQuery k podnikového skladu údajov. Potom použijeme možnosť Získať údaje, vyberieme Excel a prejdeme do tabuľkového hárka obsahujúceho naše lokálne údaje. Nakoniec importujeme tabuľkový hárok, ktorý obsahuje Názvy produktov, priradeného Manažéra predaja a Prioritu.

V zozname Polia môžete vidieť dve tabuľky: pôvodnú tabuľku Bicykel z SQL Servera a novú tabuľku ProduktovíManažéri. Nová tabuľka obsahuje údaje importované z Excelu.

Podobne aj v zobrazení Vzťahy v aplikácii Power BI Desktop vidíme ďalšiu tabuľku s názvom ProduktovíManažéri.

Teraz musíme tieto tabuľky priradiť k iným tabuľkám v modeli. Ako vždy vytvoríme vzťah medzi tabuľkou Bicykel z SQL Servera a importujúnou tabuľkou ProduktovíManažéri . To znamená, že ide o vzťah medzi tabuľkami Bicykel[NázovProduktu] a ProduktovíManažéri[NázovProduktu]. Ako už bolo spomenuté, všetky vzťahy, ktoré prechádzajú cez zdroj, majú predvolenú kardinalitu typu Many-to-many.

Keď sme vzťah vytvorili, podľa očakávaní sa zobrazuje v zobrazení vzťahov v aplikácii Power BI Desktop.

Teraz môžete vytvárať vizuály pomocou ktoréhokoľvek poľa v zozname Polia . Tento prístup umožňuje bezproblémové miešanie údajov z viacerých zdrojov. Nasledujúci obrázok napríklad zobrazuje celkovú ČiastkuPredaja pre každého Produktového manažéra :

Nasledujúci príklad zobrazuje bežný prípad tabuľky dimenzií, ako sú napríklad tabuľky Produkt alebo Zákazník, ktorú rozširujú dodatočné údaje importované z iného zdroja. Taktiež je možné tabuľky pomocou režimu DirectQuery pripojiť k rôznym zdrojom. Pokračujme v našom príklade. Predstavte si, že hodnoty Cieľov predaja na Krajinu a obdobie sú uložené v samostatnej databáze jednotlivých oddelení. Ako vidíte na nasledujúcom obrázku, na pripojenie k údajom môžete použiť možnosť Získať údaje :

Ako predtým, tak aj teraz môžeme vytvoriť vzťahy medzi novou tabuľkou a inými tabuľkami v modeli. Potom môžeme vytvoriť vizuály, ktoré kombinujú údaje tabuľky. Opäť sa pozrime na zobrazenie vzťahov , v ktorom sme vytvorili nové vzťahy:

Nasledujúci obrázok vychádza z nových údajov a vzťahov, ktoré sme vytvorili. Na vizuáli naľavo dole sa zobrazuje celková Čiastka predaja v porovnaní s Cieľom a výpočet odchýlky zobrazuje rozdiel. Údaje v Čiastke predaja a Cieli pochádzajú z dvoch rôznych databáz SQL Servera.

Nastavenie režimu úložiska

Každá tabuľka v zloženom modeli má režim úložiska, ktorý označuje, či je tabuľka založená na režime DirectQuery alebo na režime Import. Režim úložiska môžete zobraziť a upraviť na table Vlastnosť . Ak chcete zobraziť režim úložiska, kliknite pravým tlačidlom myši na tabuľku v zozname Polia a potom vyberte položku Vlastnosti. Nasledujúci obrázok zobrazuje režim úložiska pre tabuľku CielePredaja.

Režim úložiska môžete zobraziť aj na popise pre každú tabuľku.

Pri všetkých súboroch aplikácie Power BI Desktop (súbor s príponou .pbix ), ktoré obsahujú tabuľky z režimu DirectQuery a niekoľko importovaných tabuliek, sa režim úložiska v stavovom riadku zobrazuje s názvom Kombinované. Tento výraz môžete vybrať v stavovom riadku a jednoducho zmeniť všetky tabuľky na tabuľky režimu Import.

Ďalšie informácie o režime úložiska nájdete v téme Spravovanie režimu úložiska v aplikácii Power BI Desktop.

Poznámka

Režim kombinovaného úložiska môžete použiť v aplikácii Power BI Desktop a v služba Power BI.

vypočítané tabuľky,

V aplikácii Power BI Desktop, ktorý používa režim DirectQuery, môžete do modelu pridať vypočítané tabuľky. Výrazy DAX (Data Analysis Expressions), ktoré definujú vypočítané tabuľky, môžu odkazovať buď na importované tabuľky, na tabuľky režimu DirectQuery alebo na kombináciu oboch typov.

Vypočítané tabuľky sú vždy importované a ich údaje sa obnovia pri obnovení tabuliek. Ak vypočítaná tabuľka odkazuje na tabuľku režimu DirectQuery, vizuály odkazujú na tabuľku režimu DirectQuery vždy zobrazujú najnovšie hodnoty v základnom zdroji. Na druhej strane vizuály odkazujú na vypočítanú tabuľku, zobrazujú hodnoty z času, keď bola vypočítaná tabuľka naposledy obnovená.

Dôležité

Vypočítané tabuľky nie sú podporované v služba Power BI používaní tejto funkcie, pokiaľ nespĺňate konkrétne požiadavky. Ďalšie informácie o tomto modeli nájdete v časti Práca so zloženým modelom na základe sémantického modelu v tomto článku.

Vplyv na zabezpečenie

Zložené modely majú určité vplyvy na zabezpečenie. Dotaz odoslaný do jedného zdroja údajov môže zahŕňať hodnoty údajov získané z iného zdroja. V predchádzajúcom príklade vizuál, ktorý zobrazuje (Sales Amount) (Čiastku predaja) podľa Product Manager (Produktového manažéra ), odošle dotaz SQL do relačnej databázy Sales (Predaj). Daný dotaz SQL môže obsahovať mená Produktových manažérov a im priradené Produkty.

Informácie uložené v tabuľkovom hárku sú teraz zahrnuté v dotaze odoslanom do relačnej databázy. Ak sú tieto informácie dôverné, mali by ste zvážiť vplyvy zabezpečenia. Obzvlášť by ste sa mali zaoberať týmito bodmi:

• Každý správca databázy, ktorý môže zobrazovať sledovania alebo denníky auditu, si tieto informácie môže zobraziť, dokonca aj bez povolenia prístupu k údajom v ich pôvodnom zdroji. V tomto príklade by správca potreboval povolenie do excelového súboru.

• Mali by ste zvážiť nastavenie šifrovania pre každý zdroj. Vyhnete sa tak získaniu informácií z jedného zdroja pomocou šifrovaného pripojenia a potom tieto informácie neúmyselne zahrniete do dotazu odoslaného do iného zdroja prostredníctvom nešifrovaného pripojenia.

Keď vytvoríte zložený model, aplikácia Power BI Desktop zobrazí upozorňujúcie hlásenie, kde potvrdíte, že ste zohľadnili všetky možné vplyvy na zabezpečenie.

Okrem toho, ak autor pridá tabuľku1 z modelu A do zloženého modelu (nazvime ho model C), potom používateľ, ktorý si prezerá zostavu vytvorenú v modeli C by mohol dotazovať ľubenú tabuľku v modeli A, ktorá nie je chránená zabezpečením na úrovni riadkov.

Z podobných dôvodov by ste mali byť pri otváraní súboru aplikácie Power BI Desktop odoslaného z nedôveryhlivého zdroja opatrní. Ak súbor obsahuje zložené modely, informácie, ktoré niekto načíta z jedného zdroja pomocou poverení používateľa otvárajúceho súbor, budú odoslané do iného zdroja údajov ako súčasť dotazu. Tieto informácie by tak mohol zobraziť autor súboru aplikácie Power BI Desktop, ktorý by mohol mať škodlivé úmysly. Pri prvom otvorení súboru aplikácie Power BI Desktop, ktorý obsahuje viacero zdrojov, sa zobrazí upozornenie. Toto upozornenie sa podobá na to, ktoré sa zobrazuje pri otváraní súboru obsahujúceho natívne dotazy SQL.

Vplyv na výkon

Pri používaní režimu DirectQuery by ste mali vždy dbať na výkon, aby mal serverový zdroj dostatok prostriedkov na zabezpečenie dobrého výkonu pre používateľov. Pokiaľ funguje dobre, vizuály sa obnovia za 5 sekúnd alebo za kratší čas. Ďalšie rady týkajúce sa výkonu nájdete v téme Režim DirectQuery v službe Power BI.

Používanie zložených modelov so sebou prináša ďalšie faktory týkajúce sa výkonu. Jeden vizuál môže odosielať dotazy do viacerých zdrojov, čo často prenesie výsledky jedného dotazu do druhého zdroja. Táto situácia môže viesť k nasledujúcim formám realizácii:

• Zdrojový dotaz obsahujúci veľké množstvo hodnôt literálu: Napríklad vizuál, ktorý vyžaduje celkovú Čiastku predaja pre množinu vybratých Produktových manažérov by najskôr musel zistiť, ktoré Produkty títo produktoví manažéri spravovali. Táto sekvencia sa musí uskutočniť ešte predtým, ako vizuál odošle dotaz SQL obsahujúci všetky kódy Product ID v klauzule WHERE .

• Zdrojový dotaz dotazuje na nižšej úrovni granularity a s údajmi je potom lokálne agregovaný: Keďže počet Produktov , ktoré spĺňajú kritériá filtra Produktového manažéra , stále rastie, bolo by neefektívne prípadne neuskutočniteľné zahrnúť všetky produkty WHERE do klauzuly . Namiesto toho môžete vytvoriť dotaz relačného zdroja na nižšej úrovni Produktu a potom výsledky agregovať lokálne. Ak kardinalita Produktov prekročí limit 1 milión, dotaz zlyhá.

• Viacero zdrojových dotazov, jeden na skupinu podľa hodnoty: Pokiaľ agregácia používa funkciu DistinctCount a je zoskupená podľa stĺpca z iného zdroja, a ak externý zdroj nepodporuje efektívne odovzdávanie viacerých explicitných hodnôt literálu, ktoré zoskupenie definujú, je potrebné odoslať jeden dotaz SQL na skupinu podľa hodnoty.

  Vizuál, ktorý vyžaduje jedinečný počet v tabuľke CustomerAccountNumber (ČísloKontaZákazníka) z tabuľky SQL Servera podľa tabuľky Product Managers (Produktoví manažéri ) importovaná z tabuľkového hárka, by musel preniesť podrobnosti z tabuľky Product Managers (Produktoví manažéri ) do dotazu odoslaného do SQL Servera. Na rozdiel od iných zdrojov, ako je napríklad Redshift, táto akcia nie je možná. Namiesto toho sa odošle jeden dotaz SQL na Manažéra predaja – až do určitého limitu, pri ktorom by dotaz zlyhal.

Každý z týchto prípadov má svoje vlastné vplyvy na výkon a presné podrobnosti sa pri jednotlivých zdrojoch údajov líšia. Hoci kardinalita stĺpcov použitých vo vzťahu, ktorý spája dva zdroje, ostáva nízka (niekoľko tisíc), výkon by to ovplyvniť nemalo. Ako kardinalita rastie, mali by ste venovať väčšiu pozornosť vplyvu na výsledný výkon.

Okrem toho využitie vzťahov typu many-to-many znamená, že je skôr potrebné odoslať samostatné dotazy do základného zdroja pre každý súčet alebo medzisúčet, než aby sa agregácia podrobných hodnôt odosielala lokálne. Jednoduchý vizuál tabuľky so súčtami by mal radšej odoslať dva zdrojové dotazy než jeden.

Skupiny zdrojov

Skupina zdrojov je kolekcia položiek, ako sú napríklad tabuľky a vzťahy, zo zdroja DirectQuery alebo zo všetkých zdrojov importu zapojených do dátového modelu. Zložený model je vyrobený z jednej alebo viacerých skupín zdrojov. Zvážte nasledujúce príklady:

• Zložený model, ktorý sa pripája k sémantickému modelu služby Power BI s názvom Predaj a obohatí sémantický model pridaním mierky Sales YTD , ktorá nie je k dispozícii v pôvodnom sémantickom modeli. Tento model pozostáva z jednej skupiny zdrojov.
• Zložený model, ktorý kombinuje údaje importovaním tabuľky z excelového hárka s názvom Ciele a súbor CSV s názvom Oblasti a vytvorením pripojenia DirectQuery k sémantickému modelu služby Power BI s názvom Predaj. V tomto prípade existujú dve skupiny zdrojov, ako je to znázornené na nasledujúcom obrázku:
  • Prvá skupina zdrojov obsahuje tabuľky z excelového hárka Targets (Ciele ) a súbor CSV Regions (Oblasti ).
  • Druhá skupina zdrojov obsahuje položky zo sémantického modelu služby Sales Power BI.

Ak ste pridali ďalšie pripojenie DirectQuery k inému zdroju, napríklad pripojenie DirectQuery k databáze SQL Servera s názvom Inventory, položky z tohto zdroja sa pridajú do ďalšej skupiny zdrojov:

Poznámka

Import údajov z iného zdroja nepridá ďalšiu skupinu zdrojov, pretože všetky položky zo všetkých importovaných zdrojov sa nachádzajú v jednej skupine zdrojov.

Skupiny zdrojov a vzťahy

V zloženom modeli existujú dva typy vzťahov:

• Vzťahy v rámci skupiny zdrojov. Tieto vzťahy navzájom súvisia s položkami v rámci skupiny zdrojov. Tieto vzťahy sú vždy normálnymi vzťahmi, pokiaľ nie sú typu Many-to-many, v takom prípade sú obmedzené.
• Vzťahy medzi skupinami zdrojov. Tieto vzťahy sa začínajú v jednej skupine zdrojov a končia v inej skupine zdrojov. Tieto vzťahy sú vždy obmedzené vzťahy.

Prečítajte si viac o rozdiele medzi normálnymi a obmedzenými vzťahmi a ich vplyvom.

Na nasledujúcom obrázku sme napríklad pridali tri vzťahy medzi skupinami zdrojov, ktoré navzájom súvisia s tabuľkami v rôznych skupinách zdrojov:

Lokálne a vzdialené

Každá položka, ktorá je v skupine zdrojov, ktorá je skupinou zdrojov DirectQuery, sa považuje za vzdialenú, pokiaľ táto položka nebola definovaná lokálne ako súčasť rozšírenia alebo obohatenia o zdroj DirectQuery a nie je súčasťou vzdialeného zdroja, ako je napríklad mierka alebo vypočítaná tabuľka. Vypočítaná tabuľka založená na tabuľke zo skupiny zdrojov DirectQuery patrí do skupiny zdrojov Import a považuje sa za lokálnu. Každá položka, ktorá je v skupine zdrojov Import, sa považuje za lokálnu. Ak napríklad definujete nasledujúcu mierku v zloženom modeli, ktorý používa pripojenie DirectQuery k zdroju inventára, mierka sa považuje za lokálnu:

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

Skupiny výpočtov, dotazy a vyhodnocovanie mierok

Skupiny výpočtov poskytujú spôsob, ako znížiť počet nadbytočných mierok a zoskupiť spoločné výrazy mierok. Typickými prípadmi použitia sú výpočty časovej inteligencie, pri ktorých chcete prejsť zo skutočných údajov na výpočty typu od mesiaca k dnešnému dňu, od štvrťroka k dátumu alebo od aktuálneho roka. Pri práci so zloženými modelmi je dôležité mať na pamäti interakciu medzi skupinami výpočtov a to, či mierka odkazuje len na položky z jednej skupiny vzdialených zdrojov. Ak mierka odkazuje len na položky z jednej skupiny vzdialených zdrojov a vzdialený model definuje skupinu výpočtov, ktorá ovplyvní mierku, použije sa táto skupina výpočtov, a to aj vtedy, ak bola mierka definovaná vo vzdialenom modeli alebo v lokálnom modeli. Ak však mierka neodkazuje na položky z jednej skupiny vzdialených zdrojov výhradne, ale odkazuje na položky zo vzdialenej skupiny zdrojov, v ktorej sa používa vzdialená skupina výpočtov, výsledky mierky môžu byť stále ovplyvnené vzdialenou skupinou výpočtov. Zoberme si nasledujúci príklad:

• Predaj predajcu je mierka definovaná vo vzdialenom modeli.
• Vzdialený model obsahuje skupinu výpočtov, ktorá mení výsledok Predaja predajcu
• Internetový predaj je mierka definovaná v lokálnom modeli.
• Celkový predaj je mierka definovaná v lokálnom modeli a má nasledujúcu definíciu:

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

V tomto scenári nie je mierka Internetový predaj ovplyvnená skupinou výpočtov definovanou vo vzdialenom modeli, pretože nie sú súčasťou toho istého modelu. Skupina výpočtov však môže zmeniť výsledok mierky Predaj predajcu, pretože sú v tom istom modeli. To znamená, že výsledky vrátené mierkou Celkový predaj sa musia starostlivo vyhodnotiť. Predstavte si, že používame skupinu výpočtov vo vzdialenom modeli na vrátenie výsledkov od roka k dátumu. Výsledok vrátený funkciou Predaj predajcu je teraz hodnotou od roku do súčasnosti, zatiaľ čo výsledok vrátený funkciou Internetový predaj je stále skutočným. Výsledok celkového predaja je teraz pravdepodobne neočakávaný, pretože pridáva skutočnosť k výsledku roka k dnešnému dňu.

Zložené modely v sémantických modeloch Služby Power BI a Analysis Services

Pomocou zložených modelov so sémantickými modelmi služby Power BI a analysis services môžete vytvoriť zložený model pomocou pripojenia DirectQuery, aby ste sa mohli pripojiť k sémantickým modelom služby Power BI, službám Azure Analysis Services (AAS) a SQL Server 2022 Analysis Services. Pomocou zloženého modelu môžete skombinovať údaje z týchto zdrojov s inými režimami DirectQuery a importovanými údajmi. Túto funkciu ocenia najmä autori zostáv, ktorí chcú kombinovať údaje zo svojho podnikového sémantického modelu s inými údajmi, ktoré vlastnia, napríklad s excelovým tabuľkovým hárkom, prípadne chcú prispôsobiť či obohatiť metaúdaje zo svojho podnikového sémantického modelu.

Spravovanie zložených modelov v sémantických modeloch power BI

Nájomník musí mať povolené nasledujúce prepínače, aby bolo možné vytvárať a používať zložené modely v sémantických modeloch Power BI:

• Povoliť koncové body XMLA a funkciu Analyzovať v Exceli s lokálnymi sémantickými modelmi. Ak je tento prepínač zakázaný, pripojenie DirectQuery k sémantickému modelu služby Power BI nie je možné vykonať.
• Používatelia môžu pracovať so sémantickými modelmi služby Power BI v Exceli pomocou dynamického pripojenia. Ak je tento prepínač zakázaný, používatelia nemôžu vykonávať dynamické pripojenia k sémantickým modelom Power BI, takže sa nedá dosiahnuť tlačidlo Vykonať zmeny v tomto modeli .
• Povoliť pripojenie DirectQuery k sémantickým modelom Power BI. Ďalšie informácie o tomto prepínači a jeho vypnutí nájdete v nasledujúcich odsekoch.

Okrem toho by v prípade kapacít Premium a Premium na používateľa malo byť povolené nastavenie "Koncový bod XMLA" a nastavené na "Iba na čítanie" alebo "Iba na čítanie/zapisovaie".

Správcovia nájomníkov môžu povoliť alebo zakázať pripojenia DirectQuery k sémantickým modelom služby Power BI na portáli na správu. Keď je táto možnosť predvolene povolená, jej zakázaním sa používateľom zastaví publikovanie nových zložených modelov v sémantických modeloch Power BI do služby.

Existujúce zostavy, ktoré používajú zložený model v sémantickom modeli služby Power BI, naďalej fungujú a používatelia môžu naďalej vytvárať zložený model pri používaní aplikácie Desktop, ale nemôžu ho publikovať v službe. Namiesto toho, keď vytvoríte pripojenie DirectQuery k sémantickému modelu Power BI výberom položky Vykonať zmeny v tomto modeli , zobrazí sa nasledujúce upozornenie:

Týmto spôsobom môžete stále preskúmať sémantický model v lokálnom prostredí aplikácie Power BI Desktop a vytvoriť zložený model. Zostavu však nemôžete publikovať do služby. Pri publikovaní zostavy a modelu sa zobrazí nasledujúce chybové hlásenie a publikácia je blokovaná:

Prepínač neovplyvňuje dynamické pripojenia k sémantickým modelom Služby Power BI, ani dynamické pripojenia ani pripojenia DirectQuery k službe Analysis Services. Tieto funkcie budú naďalej fungovať bez ohľadu na to, či bol prepínač vypnutý. Všetky publikované zostavy, ktoré používajú zložený model v sémantickom modeli služby Power BI, budú fungovať aj po publikovaní prepínača.

Vytvorenie zloženého modelu v sémantickom modeli alebo modeli

Vytvorenie zloženého modelu v sémantickom modeli služby Power BI alebo modeli Analysis Services vyžaduje, aby vaša zostava mala lokálny model. Môžete začať dynamickým pripojením a pridať lokálny model, prípadne na ne inovovať. Môžete tiež začať pripojením DirectQuery alebo importovanými údajmi, čím sa v zostave automaticky vytvorí lokálny model.

Ak chcete zistiť, ktoré pripojenia sa vo vašom modeli používajú, skontrolujte stavový riadok v pravom dolnom rohu aplikácie Power BI Desktop. Ak ste pripojení len k zdroju Analysis Services, zobrazí sa správa ako na nasledujúcom obrázku:

Ak ste pripojení k sémantickému modelu služby Power BI, zobrazí sa správa s informáciou o tom, ku ktorému sémantickému modelu služby Power BI ste pripojení:

Ak chcete prispôsobiť metaúdaje polí v dynamicky pripojenej sémantickom modeli, v stavovom riadku vyberte položku Vykonať zmeny v tomto modeli . Prípadne môžete na páse s nástrojmi vybrať tlačidlo Vykonať zmeny v tomto modeli , ako je to znázornené na nasledujúcom obrázku. Tlačidlo Vykonať zmeny v tomto modeli sa v zobrazení zostavy nachádza na karte Modelovanie. V zobrazení modelu sa tlačidlo nachádza na karte Domov.

Po výbere tlačidla sa zobrazí dialógové okno potvrdzujúce pridanie lokálneho modelu. Ak chcete povoliť vytváranie nových stĺpcov alebo úpravu metaúdajov pre polia zo sémantických modelov služby Power BI alebo Analysis Services, vyberte položku Pridať lokálny model . Dialógové okno sa zobrazuje na nasledujúcom obrázku.

Keď ste dynamicky pripojení k zdroju Analysis Services, lokálny model neexistuje. Ak chcete používať DirectQuery pre dynamicky pripojené zdroje, ako sú napríklad sémantické modely služby Power BI a Analysis Services, musíte do svojej zostavy pridať lokálny model. Keď publikujete zostavu s lokálnym modelom do služba Power BI, publikuje sa sémantický model pre daný lokálny model.

Reťazenie

Sémantické modely a sémantické modely, na ktorých sú založené, tvoria reťazec. Tento proces nazývaný reťazenie vám umožňuje publikovať zostavu a sémantický model založený na iných sémantických modeloch Power BI, čo je funkcia, ktorá predtým nebola možná.

Predstavte si napríklad, že váš kolega publikuje sémantický model služby Power BI s názvom Predaj a rozpočet na základe modelu služby Analysis Services s názvom Sales (Predaj) a skombinuje ho s excelovým hárkom s názvom Budget (Rozpočet).

Keď publikujete novú zostavu (a sémantický model) s názvom Sales and Budget Europe na základe sémantického modelu služby Power BI pre predaj a rozpočet , ktorý publikoval váš kolega. Vykonáte tak ďalšie úpravy alebo rozšírenia, efektívne pridávate zostavu a sémantický model do reťazca s tromi reťazcami, ktorý sa začal s modelom Sales Analysis Services, a končí s sémantickým modelom služby Power BI Sales and Budget Europe . Nasledujúci obrázok vizualizuje tento proces reťazenia.

Reťazec na predchádzajúcom obrázku má tri položky, čo predstavuje maximálnu dĺžku. Dĺžka prekračujúca tri položky nie je podporovaná a po jej prekročení sa vyskytnú chyby.

Povolenia a licencie

Používatelia, ktorí pristupujú k zostavám pomocou zloženého modelu, musia mať správne povolenia na všetky sémantické modely a modely v reťazci.

Vlastník zloženého modelu vyžaduje povolenie na vytváranie sémantických modelov používaných ako zdroje, aby ostatní používatelia mohli pristupovať k týmto modelom v mene vlastníka. V dôsledku toho vytvorenie pripojenia zloženého modelu v aplikácii Power BI Desktop alebo vytvorenie zostavy v službe Power BI vyžaduje povolenia na vytváranie v sémantických modeloch používaných ako zdroje.

Používatelia, ktorí zobrazujú zostavy pomocou zloženého modelu, budú vo všeobecnosti vyžadovať povolenia na čítanie pre samotný zložený model a sémantické modely používané ako zdroje. Ak sa zostavy nachádzajú v pracovnom priestore Pro, môžu sa vyžadovať povolenia na vytváranie. Tieto prepínače nájomníka by mali byť povolené pre používateľa.

Požadované povolenia je možné ilustrovať v nasledujúcom príklade:

• Zložený model A (vo vlastníctve vlastníka A)

  • Zdroj údajov A1: Sémantický model B.
    Vlastník A musí mať povolenie na vytváranie v sémantickom modeli B, aby používatelia mohli zobraziť zostavu pomocou zloženého modelu A.

• Zložený model C (vlastnený vlastníkom C)

  • Zdroj údajov C1: Sémantický model D
    Vlastník C musí mať povolenie na vytváranie v sémantickom modeli D, aby používatelia mohli zostavu zobraziť pomocou zloženého modelu C.
  • Zdroj údajov C2: Zložený model A
    Vlastník C musí mať povolenie na vytváranie v kompozitnom modeli A a povolenie na čítanie v sémantickom modeli B.

Používateľ, ktorý zobrazuje zostavy pomocou zloženého modelu A, musí mať povolenia na čítanie pre zložený model A aj Sémantický model B, zatiaľ čo používateľ, ktorý zobrazuje zostavy pomocou zloženého modelu C, musí mať povolenia na čítanie pre zložený model C, sémantický model D, zložený model A a sémantický model B.

Poznámka

V tomto blogovom príspevku nájdete dôležité informácie o povoleniach požadovaných pre zložené modely v sémantických modeloch služby Power BI a modeloch služby Analysis Services.

Ak sa niektorá množina údajov v reťazci nachádza v pracovnom priestore Premium na používateľa, používateľ, ktorý pristupuje, potrebuje licenciu na Premium na používateľa. Ak sa niektorá množina údajov v reťazci nachádza v pracovnom priestore Pro, používateľ, ktorý k nej pristupuje, potrebuje licenciu Pro. Ak sú všetky množiny údajov v reťazci v kapacitách Premium alebo kapacite služby Fabric F64 alebo vyššej, používateľ k nej môže získať prístup pomocou bezplatnej licencie.

Upozornenie zabezpečenia

Používanie zložených modelov v sémantických modeloch služby Power BI a modeloch Analysis Services vám zobrazí dialógové okno s upozornením zabezpečenia, ktoré je znázornené na nasledujúcom obrázku.

Údaje sa môžu presunúť z jedného zdroja údajov do druhého, čo predstavuje rovnaké upozornenie zabezpečenia ako pri kombinovaní režimu DirectQuery a importovaných zdrojov v dátovom modeli. Ďalšie informácie o tomto správaní nájdete v téme Používanie zložených modelov v aplikácii Power BI Desktop.

Podporované scenáre

Na vytvorenie zložených modelov pomocou údajov zo sémantických modelov služby Power BI alebo modelov služby Analysis Services môžete využívať nasledujúce scenáre:

• Pripojenie k údajom z rôznych zdrojov: Importovanie (napríklad súborov), sémantické modely služby Power BI, modely služby Analysis Services
• Vytváranie vzťahov medzi rôznymi zdrojmi údajov
• Zapisovať mierky, ktoré používajú polia z rôznych zdrojov údajov
• Vytváranie nových stĺpcov pre tabuľky zo sémantických modelov služby Power BI alebo modelov služby Analysis Services
• Vytváranie vizuálov, ktoré používajú stĺpce z rôznych zdrojov údajov
• Tabuľku môžete z modelu odstrániť pomocou zoznamu polí, aby boli modely čo najvýstižnejšie a najklonnejšie (ak sa pripojíte k perspektíve, nemôžete odstrániť tabuľky z modelu)
• Môžete určiť, ktoré tabuľky sa majú načítať a nemusíte načítať všetky tabuľky, ak chcete iba konkrétnu podmnožinu tabuliek. Pozrite si časť Načítavanie podmnožiny tabuliek ďalej v tomto dokumente.
• Po vytvorení pripojenia v modeli môžete určiť, či sa majú do sémantického modelu pridať tabuľky, ktoré sa neskôr pridajú.

Práca so zloženým modelom založeným na sémantickom modeli

Pri práci s režimom DirectQuery pre sémantické modely služby Power BI a Analysis Services zvážte nasledujúce informácie:

• Ak obnovíte zdroje údajov a zobrazia sa chyby s konfliktnými názvami polí alebo tabuliek, služba Power BI dané chyby vyrieši za vás.

• V tom istom sémantickom modeli služby Power BI alebo zdroji Analysis Services nemôžete nové vzťahy upravovať, odstraňovať ani vytvárať. Ak máte k týmto zdrojom prístup na úpravy, môžete vykonať zmeny priamo v zdroji údajov.

• Nie je možné zmeniť typy údajov stĺpcov, ktoré sa načítajú zo sémantického modelu služby Power BI alebo zdroja služby Analysis Services. Ak potrebujete zmeniť typ údajov, zmeňte ho v zdroji alebo použite vypočítaný stĺpec.

• Ak chcete vytvárať zostavy v služba Power BI na základe zloženého modelu založeného na inom sémantickom modeli, musia byť nastavené všetky poverenia.

• Pripojenia k SQL Serveru 2022 a novšiemu lokálnemu serveru analysis services alebo IAAS vyžadujú lokálnu bránu údajov (štandardný režim).

• Všetky pripojenia k vzdialeným sémantickým modelom služby Power BI sa vytvárajú pomocou jediného prihlásenia. Overovanie pomocou objektu služby nie je momentálne podporované.

• Pravidlá zabezpečenia na úrovni riadkov sa použijú na zdroj, v ktorom sú definované, ale nepoužívajú sa na žiadne iné sémantické modely v modeli. Zabezpečenie na úrovni riadkov definované v zostave sa nepoužije na vzdialené zdroje a zabezpečenie na úrovni riadkov nastavené vo vzdialených zdrojoch sa nepoužije na iné zdroje údajov. Nemôžete tiež definovať zabezpečenie na úrovni riadkov v tabuľke načítanej zo vzdialeného zdroja a zabezpečenie na úrovni riadkov definované v lokálnych tabuľkách nefiltruje žiadne tabuľky načítané zo vzdialeného zdroja.

• Kľúčové ukazovatele výkonu, zabezpečenie na úrovni riadkov a preklady sa neimportujú zo zdroja.

• Pri používaní hierarchie dátumov sa môže zobraziť neočakávané správanie. Tento problém môžete vyriešiť tak, že namiesto toho použijete stĺpec dátumov. Po pridaní hierarchie dátumov do vizuálu môžete prepnúť na stĺpec dátumov tak, že v názve poľa kliknete na šípku nadol a potom namiesto použitia hierarchie dátumov kliknete na názov daného poľa:

  

  Ďalšie informácie o používaní stĺpcov dátumov v porovnaní s hierarchiou dátumov nájdete v téme Použitie automatického dátumu a času v aplikácii Power BI Desktop.

• Maximálna dĺžka reťazca modelov je tri. Dĺžka prekračujúca tri položky nie je podporovaná a po jej prekročení sa vyskytnú chyby.

• Príznak na odradenie reťazenia môžete nastaviť v modeli, aby sa zabránilo vytvoreniu alebo rozšíreniu reťazca. Ďalšie informácie nájdete v téme Spravovanie pripojení DirectQuery k publikovanému sémantickému modelu.

• Pripojenie k sémantickému modelu služby Power BI alebo modelu služby Analysis Services sa nezobrazuje v doplnku Power Query.

Pri práci s režimom DirectQuery pre sémantické modely služby Power BI a Analysis Services platia nasledujúce obmedzenia :

• Parametre pre databázy a názvy serverov sú momentálne zakázané.
• Definovanie zabezpečenia na úrovni riadkov v tabuľkách zo vzdialeného zdroja nie je podporované.
• Používanie ktoréhokoľvek z nasledujúcich zdrojov ako zdroja DirectQuery nie je podporované:
  • Tabuľkové modely služby SQL Server Analysis Services (SSAS) pred verziou 2022
  • Multidimenzionálne modely SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Sémantické modely v reálnom čase
  • Vzorové sémantické modely
  • Obnovenie v Exceli Online
  • Údaje importované z Excelu alebo súborov CSV v službe
  • Metriky používania
  • Sémantické modely uložené v mojom pracovnom priestore
• Používanie služby Power BI Embedded so sémantickými modelmi, ktoré obsahujú pripojenie DirectQuery k modelu služby Analysis Services, nie je momentálne podporované.
• Publikovanie zostavy na webe pomocou funkcie publikovať na webe nie je podporované.
• Skupiny výpočtov vo vzdialených zdrojoch nie sú podporované s nedefinovanými výsledkami dotazu.

• Vypočítavané tabuľky a vypočítané stĺpce, ktoré odkazujú na tabuľku DirectQuery zo zdroja údajov s overovaním jediným prihlásením (SSO), sú podporované v služba Power BI s priradeným zdieľateľným cloudovým pripojením a/alebo podrobnou kontrolou prístupu.

• Ak pracovný priestor po nastavení pripojenia DirectQuery premenujete, je potrebné v aplikácii Power BI Desktop aktualizovať zdroj údajov, aby zostava naďalej fungovala.
• Automatické obnovenie strany je podporované len v niektorých scenároch v závislosti od typu zdroja údajov. Ďalšie informácie nájdete v téme Automatické obnovenie strany v službe Power BI.
• Prevzatie kontroly nad sémantickým modelom, ktorý používa funkciu DirectQuery k iným sémantickým modelom , sa momentálne nepodporuje.
• Hierarchie definované v modeli Analysis Services alebo sémantickom modeli Power BI sa nezobrazujú pri pripájaní k modelu alebo sémantickému modelu v režime DirectQuery pomocou Excelu, podobne ako v prípade iných zdrojov údajov DirectQuery.

Pri práci s režimom DirectQuery pre sémantické modely služby Power BI a Analysis Services je potrebné vziať do úvahy ešte niekoľko ďalších vecí:

• Použitie stĺpcov s nízkou kardinalitou vo vzťahoch medzi skupinami zdrojov: Keď vytvoríte vzťah v dvoch rôznych skupinách zdrojov, stĺpce, ktoré sa zúčastňujú vzťahu (nazývajú sa aj stĺpce spojenia), by mali mať nízku kardinalitu v ideálnom prípade 50 000 alebo menej. Toto hľadisko sa vzťahuje na kľúčové stĺpce bezreťazcov; Pre kľúčové stĺpce reťazca je potrebné vziať do úvahy nasledujúce faktory.
• Nepoužívajte veľké stĺpce s reťazcami vo vzťahoch medzi skupinami zdrojov: Pri vytváraní vzťahu medzi skupinami zdrojov nepoužívajte veľké stĺpce reťazcov ako stĺpce vzťahu, najmä pre stĺpce, ktoré majú väčšiu kardinalitu. Keď musíte použiť stĺpce reťazcov ako stĺpec vzťahov, vypočítajte očakávanú dĺžku reťazca pre filter vynásobením kardinality (C) priemernou dĺžkou stĺpca reťazca (A). Uistite sa, že očakávaná dĺžka reťazca je nižšia ako 250 000, t. j. ∗ C < 250 000.

Ďalšie informácie a pokyny nájdete v pokynoch k zloženému modelu.

Dôležité informácie týkajúce sa nájomníka

Každý model s pripojením DirectQuery k sémantickému modelu služby Power BI alebo k službe Analysis Services musí byť publikovaný v tom istom nájomníkovi, čo je obzvlášť dôležité pri prístupe k sémantickému modelu služby Power BI alebo modelu služby Analysis Services pomocou hosťovských identít B2B, ako je znázornené v nasledujúcom diagrame. Pozrite si tému Hosťovskí používatelia, ktorí môžu upravovať a spravovať obsah, a vyhľadajte URL adresu nájomníka na publikovanie.

Zvážte nasledujúci diagram. Očíslované kroky v diagrame sú popísané v odsekoch, ktoré nasledujú.

Ash v diagrame spolupracuje so spoločnosťou Contoso a pristupuje k údajom, ktoré poskytla spoločnosť Fabrikam. Ash v aplikácii Power BI Desktop vytvorí pripojenie DirectQuery k modelu služby Analysis Services, ktorý je hosťovaný v nájomníkovi spoločnosti Fabrikam.

Na overenie používa Ash identitu hosťovského používateľa B2B (krok 1 v diagrame).

Ak je zostava publikovaná v služba Power BI spoločnosti Contoso (krok 2), sémantický model publikovaný v nájomníkovi Contoso sa nedá úspešne overiť v modeli Analysis Services spoločnosti Fabrikam (krok 3). V dôsledku toho zostava nefunguje.

V tomto scenári, keďže použitý model služby Analysis Services je hosťovaný v nájomníkovi spoločnosti Fabrikam, musí byť zostava publikovaná aj v nájomníkovi spoločnosti Fabrikam. Po úspešnej publikácii v nájomníkovi fabrikam (krok 4) môže sémantický model úspešne pristupovať k modelu služby Analysis Services (krok 5) a zostava funguje správne.

Práca so zabezpečením na úrovni objektu

Keď zložený model získa údaje zo sémantického modelu služby Power BI alebo služby Analysis Services prostredníctvom režimu DirectQuery a tento zdrojový model je zabezpečený zabezpečením na úrovni objektu, spotrebitelia zloženého modelu môžu spozorovať neočakávané výsledky. V nasledujúcej časti je vysvetlené, ako sa môžu tieto výsledky zobraziť.

Zabezpečenie na úrovni objektu (Object-Level Security, OLS) umožňuje autorom modelov skryť objekty, ktoré tvoria schému modelu (teda tabuľky, stĺpce, metaúdaje atď.) od spotrebiteľov modelu (napríklad zostavovača zostáv alebo autora zloženého modelu). Pri konfigurácii služby OLS pre objekt autor modelu vytvorí rolu a potom odstráni prístup k objektu pre používateľov, ktorí sú priradení k danej role. Z pohľadu týchto používateľov skrytý objekt jednoducho neexistuje.

OLS je definovaný pre zdrojový model a používa sa na ne. Nie je možné ho definovať pre zložený model vytvorený na zdrojovom modeli.

Keď je zložený model vytvorený na základe sémantického modelu služby Power BI chráneného systémom OLS alebo modelu služby Analysis Services prostredníctvom pripojenia DirectQuery, schéma modelu zo zdrojového modelu sa skopíruje do zloženého modelu. To, čo sa skopíruje, závisí od povoleného autora zloženého modelu v zdrojovom modeli podľa pravidiel OLS, ktoré sa tu uplatňujú. Údaje sa neskopírujú do zloženého modelu. V prípade potreby sa vždy načítajú prostredníctvom režimu DirectQuery zo zdrojového modelu. Inými slovami, načítanie údajov sa vždy vráti do zdrojového modelu, kde platia pravidlá OLS.

Keďže zložený model nie je zabezpečený pravidlami OLS, objekty, ktoré používatelia zloženého modelu vidia, sú tie, ktoré mohol autor zloženého modelu vidieť v zdrojovom modeli a nie to, ku ktorým by mohol mať sám prístup. Môže to viesť k nasledujúcim situáciám:

• Niekto, kto si prezerá zložený model, môže vidieť objekty, ktoré sú pred nimi v zdrojovom modeli skryté službou OLS.
• A naopak, v zloženom modeli sa im nemusí zobrazovať objekt, ktorý môžu vidieť v zdrojovom modeli, pretože tento objekt bol pred autorom zloženého modelu skrytý pravidlami OLS určujúcimi prístup k zdrojového modelu.

Dôležitou vecou je, že napriek prípadu opísanému v prvej odrážky spotrebitelia zloženého modelu nikdy nevidia skutočné údaje, ktoré by nemali vidieť, pretože údaje sa nenachádzajú v zloženom modeli. Z dôvodu režimu DirectQuery sa načíta podľa potreby zo zdrojového sémantického modelu, kde OLS blokuje neoprávnený prístup.

Vzhľadom na toto pozadie zvážte nasledujúci scenár:

1. Admin_user publikovala podnikový sémantický model pomocou sémantického modelu služby Power BI alebo modelu služby Analysis Services, ktorý obsahuje tabuľku Zákazník a tabuľku Territory. Admin_user publikuje sémantický model do služba Power BI a nastaví pravidlá OLS, ktoré majú nasledujúci účinok:

   • Používatelia financií nemôžu zobraziť tabuľku Zákazník
   • Používatelia marketingu nemôžu zobraziť tabuľku Territory (Územie)

2. Finance_user publikuje sémantický model s názvom Sémantický model financií a zostavu s názvom Finančná zostava, ktorá sa pripája prostredníctvom režimu DirectQuery k podnikového sémantickému modelu publikovanému v kroku 1. Zostava Financie obsahuje vizuál, ktorý používa stĺpec z tabuľky Territory (Územie).

3. Marketing_user otvorí zostavu Financie. Zobrazí sa vizuál používajúci tabuľku Territory (Územie), ale vráti chybu, pretože pri otvorení zostavy sa DirectQuery pokúsi načítať údaje zo zdrojového modelu pomocou poverení Marketing_user, pre ktoré je zablokované zobrazovanie tabuľky Territory podľa pravidiel OLS nastavených v podnikovom sémantickom modeli.

4. Marketing_user vytvorí novú zostavu s názvom Marketingová zostava, ktorá ako zdroj používa sémantický model financie. V zozname polí sa zobrazujú tabuľky a stĺpce, ku ktorým Finance_user prístup. Tabuľka Territory sa preto zobrazuje v zozname polí, ale tabuľka Zákazník nie. Keď sa však Marketing_user pokúsi vytvoriť vizuál, ktorý používa stĺpec z tabuľky Territory (Územie), vráti sa chyba, pretože v tomto bode sa DirectQuery pokúša načítať údaje zo zdrojového modelu pomocou poverení Marketing_user a pravidlá OLS sa opäť naštartujú a zablokujú prístup. To isté sa stane, keď Marketing_user vytvorí nový sémantický model a zostavu, ktorá sa pripojí k sémantickému modelu služby Finance s pripojením DirectQuery – tabuľka Territory sa im zobrazí v zozname polí, pretože to je to, čo by Finance_user mohli vidieť, ale keď sa pokúsia vytvoriť vizuál, ktorý používa danú tabuľku, sú blokované pravidlami OLS v podnikovom sémantickom modeli.

5. Teraz povedzme, že Admin_user aktualizuje pravidlá OLS pre podnikový sémantický model a zastaví financie v zobrazení tabuľky Territory.

6. Aktualizované pravidlá systému OLS sa prejavia len v sémantickom modeli financie pri obnovení. Preto keď Finance_user obnoví sémantický model financie, tabuľka Territory sa už nezobrazuje v zozname polí a vizuál v zostave financie, ktorý používa stĺpec z tabuľky Territory, vráti chybu pre Finance_user, pretože teraz nemajú prístup k tabuľke Territory (Územie).

Zhrnutie:

• Spotrebitelia zloženého modelu vidia výsledky pravidiel OLS, ktoré sa vzťahujú na autora zloženého modelu pri vytváraní modelu. Preto po vytvorení novej zostavy na základe zloženého modelu sa v zozname polí zobrazujú tabuľky, ku ktorým mal autor zloženého modelu prístup pri vytváraní modelu, bez ohľadu na to, k čomu má aktuálny používateľ v zdrojovom modeli prístup.
• Pravidlá OLS nie je možné definovať v samotnom zloženom modeli.
• Používateľ zloženého modelu nikdy neuvidí skutočné údaje, ktoré by nemal vidieť, pretože príslušné pravidlá systému OLS týkajúce sa zdrojového modelu ich blokujú, keď sa režim DirectQuery pokúsi načítať údaje pomocou jeho poverení.
• Ak zdrojový model aktualizuje svoje pravidlá OLS, tieto zmeny ovplyvnia zložený model len pri jeho obnovení.

Načítavanie podmnožiny tabuliek zo sémantického modelu služby Power BI alebo modelu služby Analysis Services

Pri pripájaní k sémantickému modelu služby Power BI alebo modelu služby Analysis Services pomocou pripojenia DirectQuery môžete rozhodnúť, ku ktorým tabuľkám sa chcete pripojiť. Môžete sa tiež rozhodnúť, že po vytvorení pripojenia k modelu automaticky pridáte do sémantického modelu alebo modelu ľubovoľnú tabuľku. Keď sa pripojíte k perspektíve, váš model obsahuje všetky tabuľky v sémantickom modeli a všetky tabuľky, ktoré nie sú v perspektíve zahrnuté, sú skryté. Okrem toho sa každá tabuľka, ktorá sa môže pridať do perspektívy, pridá automaticky. V ponuke Nastavenia sa môžete rozhodnúť, že sa po prvom nastavení pripojenia automaticky pripojíte k tabuľkám, ktoré sú pridané do sémantického modelu.

Toto dialógové okno sa nezobrazuje pre dynamické pripojenia.

Poznámka

Toto dialógové okno sa zobrazí iba vtedy, ak pridáte pripojenie DirectQuery k sémantickému modelu služby Power BI alebo modelu služby Analysis Services k existujúcemu modelu. Toto dialógové okno môžete otvoriť aj tak, že zmeníte pripojenie DirectQuery k sémantickému modelu služby Power BI alebo modelu služby Analysis Services v nastaveniach zdroja údajov po jeho vytvorení.

Nastavenie pravidiel deduplication

Môžete zadať pravidlá deduplication, aby názvy mierok a tabuliek v zloženom modeli boli jedinečné, a to pomocou možnosti Nastavenia v predchádzajúcom dialógovom okne:

V predchádzajúcom príklade sme pridali príponu tabuľky alebo mierky, ktorá je v konflikte s iným zdrojom v zloženom modeli, ako príponu . Môžete vykonávať nasledujúce činnosti:

• zadajte text, ktorý sa má pridať do názvu konfliktných tabuliek alebo mierok
• zadajte, či chcete, aby sa text pridal do názvu tabuľky alebo mierky ako predpona alebo prípona.
• použitie pravidla deduplication na tabuľky, mierky alebo oboje,
• Vyberte, či chcete použiť pravidlo deduplication iba v prípade, ak sa vyskytne konflikt názvu alebo ho použijete stále. Pravidlo sa predvolene používa iba v prípade, že nastane duplicita. V našom príklade žiadna tabuľka alebo mierka z marketingového zdroja, ktorá nemá duplikát v zdroji predaja, nedostane zmenu názvu.

Keď vytvoríte pripojenie a nastavíte pravidlo deduplication, v zozname polí sa podľa pravidla deduplication nastaveného v našom príklade zobrazia výraz Zákazník aj Zákazník (marketing):

Ak nezadáte pravidlo deduplication alebo zadané pravidlá deduplication neriešia konflikt názvov, aj tak sa budú uplatňovať štandardné pravidlá deduplication. Štandardné pravidlá na odstránenie údajov pridávajú k názvu konfliktnej položky číslo. Ak na tabuľke Zákazník nastane konflikt v názve, jedna z tabuliek Zákazník sa premenuje na Customer 2.

Úpravy XMLA a zložené modely

Pri zmene sémantického modelu pomocou XMLA musíte aktualizovať kolekciu ChangedProperties a PBI_RemovedChildren pre zmenený objekt tak, aby obsahoval akékoľvek upravené alebo odstránené vlastnosti. Ak túto aktualizáciu nevykonáte, nástroje na modelovanie služby Power BI môžu prepísať všetky zmeny pri nasledujúcej synchronizácii schémy s priradenou službou Lakehouse.

Podporované modely na zmenu sémantického modelu pomocou XMLA sú nasledovné:

• Premenovanie tabuľky/stĺpca (ChangeProperty = názov)
• Odstrániť tabuľku (pridať tabuľku do PBI_RemovedChildren komentár vo výraze dotazu)

Dôležité informácie a obmedzenia

Zložené modely predstavujú niekoľko dôležitých informácií a obmedzení:

Pripojenia v kombinovanom režime – ak sa používa pripojenie v kombinovanom režime, ktoré obsahuje online údaje (napríklad sémantický model služby Power BI) a lokálny sémantický model (napríklad excelový zošit), musíte mať vytvorené priradenie brány, aby sa vizuály zobrazili správne.

V súčasnosti je prírastkové obnovenie podporované len pre zložené modely pripojené k zdrojom údajov SQL, Oracle a Teradata.

Nasledujúce tabuľkové zdroje Live Connect nie je možné používať so zloženými modelmi:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services staršia ako verzia 2022
• Metriky používania (Môj pracovný priestor)

Používanie sémantických modelov streamovania v zložených modeloch nie je podporované.

Pri používaní zložených modelov aj naďalej platia existujúce obmedzenia režimu DirectQuery. Mnohé z týchto obmedzení sa teraz týkajú jednotlivých tabuliek v závislosti od ich režimu úložiska. Napríklad vypočítaný stĺpec v tabuľke importu môže odkazovať na iné tabuľky, ktoré nie sú v režime DirectQuery, ale vypočítaný stĺpec v tabuľke DirectQuery stále môže odkazovať iba na stĺpce v tej istej tabuľke. Ďalšie obmedzenia sa vzťahujú na model ako celok, ak je niektorá z tabuliek v rámci modelu v režime DirectQuery. Napríklad funkcia Rýchle prehľady nie je v modeli k dispozícii, ak niektorá z tabuliek v ňom má režim úložiska typu DirectQuery.

Ak používate zabezpečenie na úrovni riadkov v zloženom modeli s niektorými tabuľkami v režime DirectQuery, musíte model obnoviť, aby sa nové aktualizácie z tabuliek DirectQuery použili. Ak napríklad tabuľka Používatelia v režime DirectQuery obsahuje nové záznamy o používateľovi v zdroji, nové záznamy budú zahrnuté až po ďalšom obnovení modelu. Služba Power BI ukladá dotaz Používatelia do vyrovnávacej pamäte dotaz na zlepšenie výkonu a do nasledujúceho manuálneho alebo plánovaného obnovenia nenačítá údaje zo zdroja.

Súvisiaci obsah

Ďalšie informácie o zložených modeloch a režime DirectQuery nájdete v nasledujúcich článkoch:

• Použitie vzťahov typu many-to-many v aplikácii Power BI Desktop
• Spravovanie režimu úložiska v aplikácii Power BI Desktop
• Režim DirectQuery v Power BI
• Zdroje údajov služby Power BI
• Vzťahy modelov v aplikácii Power BI Desktop