Používanie zložených modelov v službe Power BI

Power BI sémantické modely môžu zahŕňať tabuľky z jedného alebo viacerých dátových zdrojov pomocou ktoréhokoľvek podporovaného režimu ukladania tabuliek. Keď tabuľky používajú rôzne režimy ukladania, model je zložený sémantický model. Pre režim ukladania tabuliek DirectQuery je model kompozitný, keď tabuľky DirectQuery používajú rôzne zdroje dát.

Napríklad, ak sa pripojíte k inému sémantickému modelu Power BI pomocou DirectQuery (ktorý pridáva tabuľky v režime ukladania DirectQuery) a zároveň máte lokálne tabuľky v režime importu, váš model sa stane kompozitným modelom, pretože obsahuje tabuľky s rôznymi režimami ukladania.

Poznámka

Importované tabuľky z jedného alebo viacerých dátových zdrojov nie sú kompozitné modely, kým ich nezmiešate s neimportovanými tabuľkami. Rovnaké pravidlo platí pre sémantické modely s tabuľkami Direct Lake z jedného alebo viacerých dátových zdrojov.

Poznámka

Pre kompozitné modely sa predpokladá, že režim ukladania Direct Lake na stole je Direct Lake na OneLake. Režim ukladania tabuliek Direct Lake v tabuľke SQL je len z jedného zdroja a nemožno ho pridať do žiadneho zloženého modelu. Pre viac informácií o rozdieloch medzi režimom ukladania stola Direct Lake pozri aka.ms/DirectLake.

Typy kompozitných modelov

Existujú rôzne typy kompozitných modelov v závislosti od kombinácie režimov ukladania tabuliek v sémantickom modeli. Každý typ má svoje vlastné požiadavky na funkčnosť a vybavenie.

Typ zloženého modelu	K dispozícii sú nástroje	Notes
Režim DirectQuery do iného sémantického modelu služby Power BI s ďalšími tabuľkami alebo bez nich v režime úložiska importu alebo režimu úložiska DirectQuery	Len Power BI Desktop	Pripojte sa k Power BI sémantickému modelu, potom vyberte Urobte zmeny v tomto modeli alebo pripojte po pridaní tabuľky v režime importu alebo DirectQuery ukladania.
Tabuľky DirectQuery pochádzajúce z rôznych zdrojov údajov	Power BI Desktop a Power BI service	Napríklad tabuľka A pochádza z databázy SQL A a tabuľka B pochádza z databázy SQL B
Import tabuliek a tabuliek DirectQuery v rovnakom sémantickom modeli	Power BI Desktop a Power BI service
Import a tabuľky Direct Lake v rovnakom sémantickom modeli	Len webové modelovanie služby Power BI	Tabuľky Import alebo Direct Lake je možné pridať v aplikácii Desktop, ale iba kombinovať v rámci webového modelovania.
Tabuľky DirectQuery a Direct Lake v rovnakom sémantickom modeli	Iba XMLA	Kombinujte pomocou skriptu XMLA alebo komunitných nástrojov XMLA. Dá sa otvoriť vo webovom modelovaní iba pre úpravy sémantického modelu bez akýchkoľvek možností obnovenia alebo zmeny tabuliek.

Vytváranie zložených modelov v aplikácii Power BI Desktop

V Power BI Desktop môžete lokálne vytvárať sémantické modely pomocou importných alebo DirectQuery tabuliek. Potom môžete pridať ďalšie tabuľky z tlačidla Získať dáta v druhom režime úložiska a vytvoriť tak kompozitný model.

Poznámka

Ak sú importné a DirectQuery tabuľky obe v sémantickom modeli a pochádzajú z rovnakého dátového zdroja, je dostupný režim dvojitého úložiska. Duálny režim použitý namiesto režimu DirectQuery sa môže vyhnúť obmedzeným vzťahom s tabuľkami importu. Pre viac informácií pozri režim dvojitého úložiska.

Pridanie tabuliek DirectQuery z iného sémantického modelu Power BI má niekoľko rôznych ciest vytvárania.

1. V prázdnom súbore služby Power BI sa najprv pripojte k sémantickému modelu služby Power BI. Po živom pripojení máte možnosť vykonať zmeny v tomto modeli. Výberom možnosti Urobiť zmeny tohto modelu z pásky alebo päty sa živé pripojenie prevedie na DirectQuery pripojenie. Pripojenie DirectQuery vytvorí nový lokálny sémantický model s tabuľkami v režime úložiska DirectQuery. Nové tabuľky môžete pridať v režime importu alebo úložiska DirectQuery, ako aj možnosť prepísať niektoré vlastnosti stĺpcov v zdrojovom sémantickom modeli.

2. V sémantickom modeli s importovanými alebo DirectQuery tabuľkami sa pripojte k Power BI sémantickému modelu a vybrané tabuľky sa pridajú ako DirectQuery.

Sémantické modely vytvorené pomocou tabuliek Direct Lake sa dynamicky upravujú v aplikácii Power BI Desktop. Môžete pridať viac tabuliek Direct Lake. Ak chcete pridať importné tabuľky, otvorte sémantický model v Power BI webmodelovaní. Na pridanie tabuliek DirectQuery použite XMLA.

Môžeš live editovať Direct Lake a importovať sémantický model v desktope, ale nemôžeš pridať ďalšie tabuľky. Tabuľky môžete pridávať len z Power BI webového modelovania pre Direct Lake a importovať kompozitné modely.

Vytváranie zložených modelov vo webovom modelovaní

Vo Power BI webového modelovania môžete vytvárať sémantické modely s tabuľkami importu, DirectQuery alebo Direct Lake. V inom režime ukladania môžete pridať ďalšie tabuľky a vytvoriť tak kompozitný model.

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ť Power BI model, napríklad jednoduchý súbor .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.

Sémantický model kombinujúci tabuľky z viacerých zdrojov DirectQuery alebo kombinujúci DirectQuery, Direct Lake a import tabuliek je kompozitný sémantický 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 ukladania si môžete pozrieť a upraviť v paneli Vlastnosti . Pre zobrazenie režimu ukladania:

1. V zobrazení modelu vyberte tabuľku.
2. V paneli Vlastnosti rozbalte sekciu Pokročilé a potom rozšírte zoznam režimov Ukladania .

Režim ukladania si môžete pozrieť aj v tooltipe pre každú tabuľku, keď naň prejdete kurzorom v dátovom paneli.

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 sa vždy importujú a ich dáta sa obnovujú pri obnove 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žbe Power BI pomocou tejto funkcie, pokiaľ nesplníte špecifické požiadavky. Pre viac informácií pozri sekciu Práca s kompozitným modelom založeným na sémantickom modeli v tomto článku.

Vplyv na zabezpečenie

Zložené modely majú určité vplyvy na zabezpečenie. Dotaz zaslaný jednému zdroju dát môže obsahovať dátové hodnoty získané z iného zdroja. V predchádzajúcom príklade vizuál, ktorý zobrazuje (Suma predaja)produktového manažéra , odošle dotaz SQL do relačnej databázy predaja. 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ý administrátor databázy, ktorý môže vidieť stopy alebo auditné záznamy, môže tieto informácie vidieť, aj bez oprávnení na pôvodné údaje v ich pôvodnom zdroji. V tomto príklade administrátor potrebuje oprávnenia na Excel súbor.

• Nastavenia š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.

Na potvrdenie, že ste zohľadnili akékoľvek bezpečnostné dôsledky, Power BI Desktop zobrazí varovné hlásenie pri vytváraní kompozitného modelu.

Navyše, ak autor pridá Tabuľku 1 z Modelu A do kompozitného modelu (pre referenciu nazvime Model C ), používateľ prezerajúci report postavený na Modeli C môže dotazovať akúkoľvek tabuľku v Modeli A , ktorá nie je chránená bezpečnosťou na úrovni riadkov (RLS).

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 získa z jedného zdroja pomocou prihlasovacích údajov používateľa, ktorý súbor otvoril, sú odoslané inému zdroju dát ako súčasť dotazu. Škodlivý autor súboru Power BI Desktop mohol tieto informácie vidieť. 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

Keď používate DirectQuery, vždy zvážte výkon. Uistite sa, že back-end zdroj má dostatok zdrojov na poskytovanie kvalitného zážitku 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 posielať dotazy na viacero zdrojov. Často jeden dotaz odovzdá výsledky druhému zdroju. Táto situácia môže viesť k nasledujúcim formám realizácii:

• Zdrojový dotaz, ktorý obsahuje veľké množstvo literálnych hodnôt: Napríklad vizuál, ktorý žiada celkovú sumu predaja pre skupinu vybraných produktových manažérov , by najskôr musel zistiť, ktoré produkty títo produktoví manažéri spravujú. Táto sekvencia sa musí uskutočniť predtým, ako vizuál odošle dotaz SQL, ktorý obsahuje všetky ID produktov 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á.

• Viacnásobné zdrojové dotazy, jeden na každú skupinu podľa hodnoty: Keď agregácia používa DistinctCount a je zoskupená stĺpcom z iného zdroja, a ak externý zdroj nepodporuje efektívne odovzdávanie mnohých literálnych hodnôt, ktoré definujú zoskupenie, musíte poslať jeden SQL dotaz na každú skupinu podľa hodnoty.

  Vizualizácia, ktorá vyžaduje jasný počet CustomerAccountNumber z tabuľky SQL Server importovanými produktovými manažérmi z tabuľky, musí odovzdať detaily z tabuľky Product Managers do dotazu zaslaného SQL Serveru. 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 kardinálnosť stĺpcov používaných vo vzťahu spájajúcom oba zdroje zostáva nízka (niekoľko tisíc), výkon by nemal byť ovplyvnený. Ako táto kardinálnosť rastie, venujte 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á tabuľková vizualizácia s celkmi posiela dva zdrojové dotazy namiesto jedného.

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 pridáte ďalšie DirectQuery pripojenie k inému zdroju, napríklad DirectQuery spojenie k SQL Server databáze nazvanej Inventory, položky z tohto zdroja sa pridajú ako ďalšia zdrojová skupina:

Poznámka

Import dát z iného zdroja nepridáva ďalšiu zdrojovú skupinu, pretože všetky položky zo všetkých importovaných zdrojov sú v jednej zdrojovej skupine. Tabuľky Direct Lake a import sa tiež považujú za rovnakú zdrojovú skupinu.

Skupiny zdrojov a vzťahy

Kompozitný model má dva typy vzťahov:

• Vzťahy v rámci skupiny zdrojov. Tieto vzťahy spájajú položky v rámci zdrojovej skupiny. 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.

Napríklad na nasledujúcom obrázku sme pridali tri vzťahy medzi zdrojovými skupinami, ktoré prepájajú tabuľky naprieč rôznymi zdrojovými skupinami:

Lokálne a vzdialené

Každá položka v zdrojovej skupine, ktorá je zdrojovou skupinou DirectQuery, je vzdialená, pokiaľ ju nedefinujete lokálne ako súčasť rozšírenia alebo obohatenia zdroja DirectQuery a nie je súčasťou vzdialeného zdroja, napríklad ako miera alebo vypočítaná tabuľka. Vypočítaná tabuľka založená na tabuľke zo zdrojovej skupiny DirectQuery patrí do zdrojovej skupiny "Import" a je lokálna. Každá položka v zdrojovej skupine "Import" je lokálna. Napríklad, ak definujete nasledujúcu mieru v kompozitnom modeli, ktorý používa DirectQuery spojenie so zdrojom Inventára, meranie je lokálne:

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

Skupiny výpočtov, dotazy a vyhodnocovanie mierok

Výpočtové skupiny vám pomáhajú znížiť počet redundantných mier a zoskupiť výrazy spoločných mier dokopy. Typické prípady použitia sú výpočty časovej inteligencie, kde chcete prejsť z reálnych výpočtov na mesačné, štvrťročne alebo od začiatku 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 sa miera vzťahuje len na položky z jednej vzdialenej zdrojovej skupiny a vzdialený model definuje výpočtovú skupinu, ktorá ovplyvňuje meranie, výpočtová skupina sa aplikuje, aj keď definujete mieru v vzdialenom modeli alebo v lokálnom modeli. Ak však meranie neodkazuje výlučne na položky z jednej vzdialenej zdrojovej skupiny, ale na položky zo vzdialenej zdrojovej skupiny, na ktorú sa aplikuje vzdialená výpočtová skupina, výsledky merania môžu byť stále ovplyvnené vzdialenou výpočtovou skupinou. Zoberme si nasledujúci príklad:

• Predaj predajcu je mierka definovaná vo vzdialenom modeli.
• Vzdialený model obsahuje výpočtovú skupinu, ktorá mení výsledok predaja cez predaj.
• 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 meranie internetového predaja ovplyvnené výpočtovou skupinou definovanou v vzdialenom modeli, pretože nie sú súčasťou toho istého modelu. Avšak výpočtová skupina môže zmeniť výsledok ukazovateľa predaja predajcov , pretože sú v rovnakom modeli. To znamená, že výsledky vrátené mierkou Celkový predaj sa musia starostlivo vyhodnotiť. Predstavte si, že použijete výpočtovú skupinu v vzdialenom modeli na vrátenie výsledkov od začiatku roka. 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

Použitím kompozitných modelov s Power BI sémantickými modelmi a Analysis Services môžete vytvoriť kompozitný model pomocou DirectQuery pripojenia k Power BI sémantickým modelom, Azure Analysis Services (AAS) a SQL Server 2022 Analysis Services. S kompozitným modelom môžete dáta z týchto zdrojov kombinovať s inými DirectQuery a importovanými dátami. Autori reportov, ktorí chcú kombinovať dáta zo svojho podnikového sémantického modelu s inými údajmi, ktoré vlastnia, napríklad Excel tabuľkou, alebo chcú personalizovať či obohatiť metadáta zo svojho podnikového sémantického modelu, považujú túto funkcionalitu za obzvlášť užitočnú.

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

Na vytváranie a používanie kompozitných modelov na sémantických modeloch Power BI musí mať váš tenant povolené nasledujúce prepínače:

• Povoliť koncové body XMLA a funkciu Analyzovať v Exceli s lokálnymi sémantickými modelmi. Ak tento prepínač vypnete, nemôžete vytvoriť DirectQuery spojenie s Power BI sémantickým modelom.
• Používatelia môžu pracovať so sémantickými modelmi služby Power BI v Exceli pomocou dynamického pripojenia. Ak tento prepínač vypnete, používatelia nemôžu robiť živé pripojenia k Power BI sémantickým modelom, takže tlačidlo Zmeniť tento model nie je dostupné.
• 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, pre prémiové kapacity a prémiové na používateľa by malo byť povolené nastavenie "XMLA endpoint" a nastavené na "Iba na čítanie" alebo "Čítanie/zápis".

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. Hoci je toto nastavenie predvolene povolené, jeho vypnutie zabraňuje používateľom publikovať nové kompozitné modely na Power BI sémantické modely do služby.

Existujúce správy, ktoré používajú kompozitný model na sémantickom modeli Power BI, naďalej fungujú. Používatelia môžu stále vytvárať kompozitný model v Power BI Desktop, ale nemôžu ho publikovať do služby. Namiesto toho, keď vytvoríte DirectQuery spojenie s Power BI sémantickým modelom výberom Urobte zmeny v tomto modeli, zobrazí sa nasledujúce varovné hlásenie:

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. Avšak správu nemôžete službe zverejniť. Keď zverejníte správu a model, zobrazí sa nasledujúca chybová správa a publikácia je zablokovaná:

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 spojenia fungujú bez ohľadu na nastavenie prepínača. Tiež akékoľvek publikované správy, ktoré používajú kompozitný model na Power BI sémantickom modeli, fungujú aj v prípade, že je prepínač po ich zverejnení vypnutý.

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

Na vytvorenie kompozitného modelu na Power BI sémantickom modeli alebo Analysis Services modeli potrebujete 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.

Aby ste videli, ktoré pripojenia sa používajú vo vašom modeli, skontrolujte stavový panel v pravom dolnom rohu 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 Power BI sémantickému modelu, zobrazí sa vám správa, ktorá vám povie, ku ktorému sémantickému modelu 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. V sekcii Report View sa tlačidlo Urob zmeny tohto modelu nachádza v záložke Modelovanie . V Model View je tlačidlo v záložke Domov .

Keď vyberiete tlačidlo, zobrazí sa dialóg, ktorý potvrdzuje pridanie lokálneho modelu. Vyberte Pridať lokálny model , aby ste umožnili vytvárať nové stĺpce alebo upravovať metadáta pre polia z Power BI sémantických modelov alebo Analysis Services. Nasledujúci obrázok zobrazuje dialóg.

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žby Power BI, publikuje sa aj sémantický model pre tento lokálny model.

Reťazenie

Sémantické modely a sémantické modely, na ktorých sú založené, tvoria reťazec. Tento proces, ktorý sa nazýva reťazenie, umožňuje publikovať zostavu a sémantický model založený na iných sémantických modeloch služby Power BI.

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). Potom vytvoríte a publikujete kompozitný sémantický model a report, nazvaný Sales and Budget Europe, používajúc sémantický model Sales and Budget Power BI s vlastnými úpravami. Tento sémantický model je tretí v reťazci.

1. Prvým reťazcom je model služieb Sales Analysis Services.
2. Druhým reťazcom je zložený sémantický model služby Power BI pre predaj a rozpočet .
3. Tretím reťazcom je zložený sémantický model služby Power BI pre predaj a rozpočet v Európe .

Nasledujúci obrázok vizualizuje tento proces reťazenia.

Dĺžka reťaze na predchádzajúcom obrázku je tri, čo je maximálna dĺžka. 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 reportom pomocou kompozitného modelu, potrebujú správne oprávnenia ku všetkým sémantickým modelom a modelom v reťazci.

Vlastník kompozitného modelu potrebuje Build povolenie na sémantické modely používané ako zdroje, aby ostatní používatelia mohli k týmto modelom pristupovať v mene vlastníka. V dôsledku toho vytvorenie spojenia kompozitného modelu v Power BI Desktop alebo vytvorenie správy v Power BI vyžaduje Build oprávnenia na sémantické modely používané ako zdroje.

Používateľia, ktorí prezerajú reporty pomocou kompozitného modelu, zvyčajne potrebujú oprávnenia na čítanie samotného kompozitného modelu a sémantických modelov používaných 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.

Nasledujúci príklad ilustruje požadované povolenia:

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

  • Zdroj údajov A1: Sémantický model B.
    Vlastník Amusí mať stavebné povolenie na Semantic Model B , aby používatelia mohli vidieť report, ktorý používa Composite Model A.

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

  • Zdroj údajov C1: Sémantický model D
    Vlastník Cmusí mať stavebné povolenie na Semantic Model D , aby používatelia mohli vidieť report, ktorý používa Composite Model 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ľ prezerajúci správy využívajúce Kompozitný model A musí mať oprávnenia na čítanie pre kompozitný model A aj sémantický model B, zatiaľ čo používateľ prezerajúci správy využívajúce kompozitný model Cmusí mať čítacie oprávnenia na kompozitný model C, sémantický model D, kompozitný model A a sémantický model B.

Poznámka

Pre viac informácií pozri povolenia požadované pre kompozitné modely v Power BI sémantických modeloch a modeloch Analysis Services.

Ak je akýkoľvek sémantický model v reťazci v pracovnom priestore Premium Per User, používateľ k nemu potrebuje licenciu Premium Per User. Ak je akýkoľvek sémantický model v reťazci v Pro workspace, používateľ, ktorý k nemu pristupuje, potrebuje Pro licenciu. Ak sú všetky sémantické modely v reťazci na prémiových kapacitách alebo Fabric F64 či vyššej kapacite, používateľ k nim môže pristupovať pomocou bezplatnej licencie.

Upozornenie zabezpečenia

Keď použijete kompozitné modely v Power BI sémantické modely a funkciu Analysis Services models , uvidíte varovné okno s bezpečnosťou, ktoré je znázornené na nasledujúcom obrázku.

Dáta môžu byť presúvané z jedného zdroja do druhého. Toto bezpečnostné varovanie sa vzťahuje na kombinovanie DirectQuery a importovaných zdrojov v dátovom modeli. Pre viac informácií o tomto správaní pozri použitie kompozitných modelov v Power BI Desktop.

Podporované scenáre

Kompozitné modely môžete vytvárať pomocou dát z Power BI sémantických modelov alebo Analysis Services modelov na obsluhu nasledujúcich scenárov:

• Pripájajte sa k dátam z rôznych zdrojov: import (napríklad súbory), Power BI sémantické modely, modely Analysis Services
• Vytváranie vzťahov medzi rôznymi zdrojmi dát
• Píšte miery, ktoré využívajú polia z rôznych dátových zdrojov
• Vytvorte nové stĺpce pre tabuľky z Power BI sémantických modelov alebo modelov Analysis Services
• Vytvárajte vizuály využívajúce stĺpce z rôznych zdrojov dát
• Odstráňte tabuľku z modelu pomocou zoznamu polí, aby boli modely čo najstručnejšie a najštíhlejšie (ak sa pripojíte k perspektíve, tabuľky z modelu odstrániť nemôžete).
• Špecifikuj, ktoré tabuľky sa načítajú, namiesto toho, aby si musel načítať všetky tabuľky, keď chceš len určitú podmnožinu tabuliek. Pozrite si časť Načítavanie podmnožiny tabuliek ďalej v tomto dokumente.
• Špecifikuj, či pridávaš tabuľky, ktoré neskôr pridáš do sémantického modelu po vytvorení spojenia v modeli.

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.

• Na vytvorenie reportov v službe Power BI na kompozitnom modeli založenom na inom sémantickom modeli musíte nastaviť všetky prihlasovacie údaje.

• 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 Power BI používajú jednotné prihlásenie. Overovanie pomocou objektu služby nie je momentálne podporované.

• Pravidlá RLS platia na zdroji, na ktorom sú definované, ale neplatia pre žiadne iné sémantické modely v modeli. RLS definovaný v správe sa nevzťahuje na vzdialené zdroje a RLS nastavené na vzdialené zdroje sa nevzťahuje na iné zdroje dát. Zabezpečenie na úrovni riadkov tiež nemôžete definovať 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í dátumovej hierarchie do vizuálu môžete prejsť na stĺpec dátumu výberom dole v názve poľa a následným výberom názvu tohto poľa namiesto použitia dátumovej hierarchie:

  

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

• Na modeli môžete nastaviť príznak "odrádzať od reťazenia", aby ste zabránili 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.

• Power Query nezobrazuje spojenie s Power BI sémantickým modelom alebo modelom Analysis Services.

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 externému modelu služby Analysis Services (Azure Analysis Services/SQL Server Analysis Services), nie je momentálne podporované.
• Publikovanie správy na web pomocou funkcie publikovať na web 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 po nastavení DirectQuery pripojenia premenujete pracovný priestor, musíte aktualizovať dátový zdroj v Power BI Desktop, aby report mohol pokračovať v práci.
• 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 sémantického modelu, ktorý používa funkciu DirectQuery na iné sémantické modely , momentálne nie je podporované.
• Rovnako ako pri každom zdroji dát DirectQuery, hierarchie definované v modeli Analysis Services alebo Power BI sémantickom modeli sa nezobrazujú pri pripojení k modelu alebo sémantickému modelu v režime DirectQuery pomocou Excelu.

Pri práci s DirectQuery pre sémantické modely a analytické služby Power BI zvážte nasledujúce odporúčania:

• 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

Musíte publikovať akýkoľvek model s pripojením DirectQuery k Power BI sémantickému modelu alebo do Analysis Services v tom istom tenante. Táto požiadavka je obzvlášť dôležitá pri prístupe k sémantickému modelu Power BI alebo modelu Analysis Services pomocou B2B hosťovských identít, ako je znázornené na nasledujúcom diagrame.

Zvážte nasledujúci diagram. Číslované kroky v diagrame sú popísané v nasledujúcich odstavcoch.

Na diagrame Ash spolupracuje s Contoso a pristupuje k údajom poskytnutým Fabrikamom. V Power BI Desktop Ash vytvára DirectQuery spojenie s modelom Analysis Services, ktorý Fabrikam hostuje.

Na autentifikáciu Ash používa B2B identitu hosťujúceho používateľa (krok 1 na diagrame).

Ak Ash zverejní správu do Power BI služby Contoso (krok 2), sémantický model publikovaný v nájomcovi Contoso sa nemôže úspešne autentifikovať proti modelu Analysis Services od Fabrikam (krok 3). V dôsledku toho zostava nefunguje.

V tomto prípade, keďže Fabrikam hostí model Analysis Services, musíte report publikovať aj v tenante Fabrikamu. 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ť.

Bezpečnosť na úrovni objektov (OLS) umožňuje autorom modelov skryť objekty, ktoré tvoria schému modelu (teda tabuľky, stĺpce, metadáta a podobne) pred konzumentmi modelu (napríklad tvorcom reportov alebo autorom 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. Nemôžete ho definovať pre kompozitný model postavený na zdrojovom modeli.

Keď vytvoríte kompozitný model na vrchu OLS-chráneného Power BI sémantického modelu alebo modelu Analysis Services cez DirectQuery pripojenie, skopírujete modelovú schému zo zdrojového modelu do kompozitného modelu. To, čo skopírujete, závisí od toho, čo podľa pravidiel OLS môžete vidieť v zdrojovom modeli. Dáta nekopírujete do kompozitného modelu – vždy ich získavate cez DirectQuery zo zdrojového modelu, keď je to potrebné. Inými slovami, načítanie údajov sa vždy vráti do zdrojového modelu, kde platia pravidlá OLS.

Keďže kompozitný model nie je zabezpečený pravidlami OLS, objekty, ktoré vidia používatelia kompozitného modelu, sú tie, ktoré by ste mohli vidieť v zdrojovom modeli, nie tie, ku ktorým by mohli mať prístup oni sami. Táto situácia môže viesť k nasledujúcim výsledkom:

• 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 publikuje podnikový sémantický model využívajúci sémantický model Power BI alebo model Analysis Services, ktorý má tabuľku zákazníka a tabuľku území. 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.
• Nemôžete definovať OLS pravidlá priamo na kompozitnom modeli.
• Konzument kompozitného modelu nikdy nevidí skutočné dáta, ktoré by nemal vidieť, pretože relevantné pravidlá OLS na zdrojovom modeli ich blokujú, keď sa DirectQuery snaží získať dáta pomocou ich prihlasovacích údajov.
• 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

Keď sa pripojíte k Power BI sémantickému modelu alebo modelu Analysis Services pomocou DirectQuery pripojenia, vyberiete, ku ktorým tabuľkám sa pripojíte. 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

Tento dialóg sa zobrazí len vtedy, ak pridáte DirectQuery spojenie do Power BI sémantického modelu alebo Analysis Services modelu k existujúcemu modelu. Tento dialóg môžete tiež otvoriť zmenou spojenia DirectQuery na Power BI sémantický model alebo model Analysis Services v nastaveniach zdroja dát 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 '(marketing)' ako príponu k akejkoľvek tabuľke alebo názvu miery, ktorá je v konflikte s iným zdrojom v kompozitnom modeli. Môžete vykonávať nasledujúce činnosti:

• Zadajte text, ktorý pridáte k názvu konfliktných tabuliek alebo mier.
• Špecifikujte, či chcete, aby bol text pridaný do tabuľky alebo názov miery ako prefix či prípona.
• Aplikujte pravidlo deduplikácie na tabuľky, miery 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 miera z marketingového zdroja, ktorá nemá duplikát v predajnom zdroji, nedostane zmenu názvu.

Po vytvorení spojení a nastavení pravidla deduplikácie váš zoznam polí zobrazuje "Customer" aj "Customer (marketing)" podľa pravidla deduplikácie nastaveného v našom príklade:

Ak nešpecifikujete pravidlo deduplikácie, alebo pravidlá deduplikácie, ktoré zadáte, nevyriešia konflikt názvov, štandardné pravidlá deduplikácie sa stále uplatňujú. Štandardné pravidlá na odstránenie údajov pridávajú k názvu konfliktnej položky číslo. Ak je v tabuľke 'Zákazník' konflikt názvov, jedna z týchto tabuliek sa premenuje na 'Zákazník 2'.

Úpravy XMLA a zložené modely

Keď zmeníte sémantický model pomocou XMLA, aktualizujte kolekcie ChangedProperties a PBI_RemovedChildren pre zmenený objekt tak, aby zahŕňali akékoľvek upravené alebo odstránené vlastnosti. Ak tieto kolekcie neaktualizujete, Power BI modelovacie nástroje môžu pri ďalšej synchronizácii schémy so zdrojom dát prepísať vaše zmeny.

Pre viac informácií o sémantických modelových objektových lineage tagoch pozri lineage tagy pre Power BI sémantické modely.

Dôležité informácie a obmedzenia

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

Spojenia v zmiešanom režime – Keď používate spojenie v zmiešanom režime, ktoré obsahuje online dáta (napríklad sémantický model Power BI) a lokálny sémantický model (napríklad pracovný zošit v Exceli), musíte nastaviť mapovanie brány, aby sa vizuály správne zobrazovali.

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 bezpečnosť na úrovni riadkov v kompozitnom modeli s niektorými tabuľkami v režime DirectQuery, musíte obnoviť model na aplikáciu nových aktualizácií z tabuliek DirectQuery. Napríklad, ak má tabuľka Users v režime DirectQuery nové používateľské záznamy v zdroji, nové záznamy sú 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