Relace modelu v Power BI Desktopu

Tento článek cílí na import modelů dat pracujících s Power BI Desktopem. Je to důležité téma návrhu modelu, které je nezbytné k poskytování intuitivních, přesných a optimálních modelů.

Podrobnější informace o optimálním návrhu modelu, včetně rolí a relací tabulek, najdete v tématu Vysvětlení hvězdicového schématu a důležitosti pro Power BI.

Účel vztahu

Relace modelu šíří filtry použité ve sloupci jedné tabulky modelu do jiné tabulky modelu. Filtry se rozšíří tak dlouho, dokud existuje cesta relace, která může zahrnovat šíření do více tabulek.

Cesty relací jsou deterministické, což znamená, že filtry se vždy šíří stejným způsobem a bez náhodné variace. Relace ale můžou být zakázané nebo mohou mít kontext filtru upravený výpočty modelu, které používají konkrétní funkce JAZYKA DAX. Další informace najdete v tématu Relevantní funkce jazyka DAX dále v tomto článku.

Důležité

Relace modelu nevynucuje integritu dat. Další informace najdete v tématu vyhodnocení relace dále v tomto článku, které vysvětluje, jak se relace modelu chovají, když jsou problémy s integritou dat.

Tady je postup šíření filtrů pomocí animovaného příkladu.

V tomto příkladu se model skládá ze čtyř tabulek: Category(Kategorie), Product ( Produkt), Year (Rok) a Sales (Prodej). Tabulka Category se vztahuje k tabulce Product (Produkt ) a tabulka Product (Produkt ) se vztahuje k tabulce Sales (Prodej ). Tabulka Year se také vztahuje k tabulce Sales (Prodej ). Všechny relace jsou 1:N (podrobnosti, které jsou popsány dále v tomto článku).

Dotaz, který je pravděpodobně vygenerován vizuálem karty Power BI, požaduje celkové množství prodeje prodejních objednávek provedených pro jednu kategorii, Cat-A a jeden rok CY2018. Proto vidíte filtry použité v tabulkách Kategorie a Rok . Filtr v tabulce Kategorie se rozšíří do tabulky Product a izoluje dva produkty přiřazené kategorii Cat-A. Potom se filtry tabulky Product rozšíří do tabulky Sales (Prodej), aby se pro tyto produkty izolovaly jenom dva řádky prodeje. Tyto dva řádky prodeje představují prodej produktů přiřazených k kategorii Cat-A. Jejich kombinované množství je 14 jednotek. Ve stejnou dobu se filtr tabulky Year rozšíří, aby dále filtroval tabulku Sales , což vede pouze k jednomu řádku prodeje, který je určený pro produkty přiřazené kategorii Cat-A a který byl seřazen v roce CY2018. Hodnota množství vrácená dotazem je 11 jednotek. Všimněte si, že když se na tabulku použije více filtrů (jako je tabulka Sales v tomto příkladu), je to vždy operace AND, která vyžaduje, aby všechny podmínky byly pravdivé.

Použití principů návrhu hvězdicového schématu

Doporučujeme použít principy návrhu hvězdicového schématu k vytvoření modelu, který obsahuje tabulky dimenzí a faktů. Power BI je běžné nastavit tak, aby vynucuje pravidla, která filtrují tabulky dimenzí, což umožňuje efektivní šíření těchto filtrů do tabulek faktů.

Následující obrázek je diagram modelu datového modelu analýzy prodeje společnosti Adventure Works. Zobrazuje návrh hvězdicového schématu, který obsahuje jednu tabulku faktů s názvem Sales(Prodej). Další čtyři tabulky jsou tabulky dimenzí, které podporují analýzu měr prodeje podle data, stavu, oblasti a produktu. Všimněte si relací modelu, které propojují všechny tabulky. Tyto relace šíří filtry (přímo nebo nepřímo) do tabulky Sales .

Odpojené tabulky

Je neobvyklé, že tabulka modelu nesouvisí s jinou tabulkou modelu. Taková tabulka v platném návrhu modelu je popsána jako odpojená tabulka. Odpojená tabulka není určená k šíření filtrů do jiných tabulek modelu. Místo toho přijímá "uživatelský vstup" (třeba s vizuálem průřezu), což umožňuje výpočtům modelu smysluplně používat vstupní hodnotu. Představte si například odpojenou tabulku, která je načtena s rozsahem hodnot směnného kurzu měny. Pokud je filtr použit k filtrování podle hodnoty jedné sazby, výraz míry může tuto hodnotu použít k převodu hodnot prodeje.

Parametr citlivostní analýzy v Power BI Desktopu je funkce, která vytvoří odpojenou tabulku. Další informace najdete v tématu Vytvoření a použití parametru Citlivostní analýza k vizualizaci proměnných v Power BI Desktopu.

Vlastnosti relace

Relace modelu spojuje jeden sloupec v tabulce s jedním sloupcem v jiné tabulce. (Existuje jeden specializovaný případ, kdy tento požadavek není pravdivý a vztahuje se pouze na relace s více sloupci v modelech DirectQuery. Další informace najdete v článku o funkci COMBINEVALUES DAX.)

Poznámka:

Sloupec není možné propojit s jiným sloupcem ve stejné tabulce. Tento koncept se někdy zaměňuje se schopností definovat omezení cizího klíče relační databáze, na které odkazuje sama tabulka. Tento koncept relační databáze můžete použít k ukládání vztahů mezi nadřazeným a podřízeným vztahem (například každý záznam zaměstnance souvisí se "sestavami" zaměstnance). Relace modelu ale nemůžete použít k vygenerování hierarchie modelu na základě tohoto typu relace. Pokud chcete vytvořit hierarchii nadřazený-podřízený, přečtěte si téma Funkce Nadřazený a Podřízený.

Datové typy sloupců

Datový typ pro sloupec "from" i "to" relace by měl být stejný. Práce s relacemi definovanými ve sloupcích DateTime se nemusí chovat podle očekávání. Modul, který ukládá data Power BI, používá pouze datové typy DateTime ; Datové typy Date, Time a Date/Time/Time/Timezone jsou konstrukty formátování Power BI implementované nahoře. Všechny objekty závislé na modelu se v modulu budou stále zobrazovat jako DateTime (například relace, skupiny atd.). Pokud uživatel pro tyto sloupce vybere možnost Datum na kartě Modelování , stále se nezaregistruje jako stejné datum, protože časová část dat je stále považována za modul. Přečtěte si další informace o tom, jak se zpracovávají typy data a času. Pokud chcete chování opravit, datové typy sloupců by se měly aktualizovat v Editor Power Query, aby se z importovaných dat odebrala část Čas, takže když modul zpracovává data, zobrazí se stejné hodnoty.

Kardinalita

Každá relace modelu je definována typem kardinality. Existují čtyři možnosti typu kardinality, které představují charakteristiky dat souvisejících sloupců "from" a "to". Strana "jeden" znamená, že sloupec obsahuje jedinečné hodnoty; strana "N" znamená, že sloupec může obsahovat duplicitní hodnoty.

Poznámka:

Pokud se operace aktualizace dat pokusí načíst duplicitní hodnoty do sloupce na straně "jedna", celá aktualizace dat selže.

Čtyři možnosti, společně s jejich zkratkami, jsou popsány v následujícím seznamu s odrážkami:

• 1:*)
• M:1 (*:1)
• 1:1 (1:1)
• M:N (*:*)

Když v Power BI Desktopu vytvoříte relaci, návrhář automaticky rozpozná a nastaví typ kardinality. Power BI Desktop dotazuje model, aby věděl, které sloupce obsahují jedinečné hodnoty. Pro modely importu používá interní statistiku úložiště; pro modely DirectQuery odesílá dotazy profilace do zdroje dat. Někdy se ale Power BI Desktop může pokazit. Může se pokazit, když se tabulky ještě nenačtou s daty, nebo protože sloupce, u kterých očekáváte, že budou obsahovat duplicitní hodnoty, aktuálně obsahují jedinečné hodnoty. V obou případech můžete aktualizovat typ kardinality, pokud všechny sloupce na straně "jedna" obsahují jedinečné hodnoty (nebo tabulka se ještě nenačítá s řádky dat).

Kardinalita 1:N (a M:1)

Možnosti kardinality 1:N a M:1 jsou v podstatě stejné a jsou to také nejběžnější typy kardinality.

Při konfiguraci relace 1:N nebo N:1 zvolíte relaci, která odpovídá pořadí, ve kterém sloupce souvisejí. Zvažte, jak byste nakonfigurovali relaci z tabulky Product (Produkt ) s tabulkou Sales (Prodej ) pomocí sloupce ProductID nalezeného v každé tabulce. Typ kardinality by byl 1:N, protože sloupec ProductID v tabulce Product obsahuje jedinečné hodnoty. Pokud jste tabulky v relaci v opačném směru, Sales to Product, kardinalita by byla M:1.

Kardinalita 1:1

Relace 1:1 znamená, že oba sloupce obsahují jedinečné hodnoty. Tento typ kardinality není běžný a pravděpodobně představuje neoptimální návrh modelu kvůli ukládání redundantních dat.

Další informace o použití tohoto typu kardinality najdete v doprovodných materiálech k relaci 1:1.

Kardinalita M:N

Relace M:N znamená, že oba sloupce můžou obsahovat duplicitní hodnoty. Tento typ kardinality se často používá. Obvykle je užitečné při návrhu složitých požadavků na model. Můžete ho použít ke spojení faktů M:N nebo k relaci vyšších faktů. Například pokud jsou fakta cíle prodeje uložena na úrovni kategorie produktu a tabulka dimenzí produktu je uložena na úrovni produktu.

Pokyny k použití tohoto typu kardinality najdete v pokynech k relacím M:N.

Poznámka:

Typ kardinality M:N je podporován pro modely vyvinuté pro Server sestav Power BI leden 2024 a novější.

Tip

V zobrazení modelu Power BI Desktopu můžete typ kardinality relace interpretovat tak, že se podíváte na indikátory (1 nebo *) na obou stranách čáry relace. Pokud chcete určit, které sloupce souvisejí, budete muset vybrat nebo najet myší na řádek relace, aby se sloupce zvýraznily.

Směr křížového filtru

Každá relace modelu je definována směrem křížového filtru. Vaše nastavení určuje směry šíření filtrů. Možné možnosti křížového filtru jsou závislé na typu kardinality.

Typ kardinality	Možnosti křížového filtru
1:N (nebo M:1)	Jeden Oba
One-to-one	Oba
N:N	Jedna (tabulka1 až tabulka2) Jedna (tabulka2 do tabulky1) Oba

Směr jednoduchého křížového filtru znamená "jeden směr" a oba znamená "oba směry". Relace, která filtruje v obou směrech, se běžně popisuje jako obousměrná.

U relací 1:N je směr křížového filtru vždy ze strany "jeden" a volitelně ze strany "N" (obousměrný). U relací 1:1 je směr křížového filtru vždy z obou tabulek. V případě relací M:N může být směr křížového filtru z jedné z tabulek nebo z obou tabulek. Všimněte si, že když typ kardinality obsahuje stranu "jedna", budou se filtry vždy šířit z této strany.

Pokud je směr křížového filtru nastaven na Obě, bude k dispozici další vlastnost. Když Power BI vynucuje pravidla zabezpečení na úrovni řádků (RLS), může použít obousměrné filtrování. Další informace o zabezpečení na úrovni řádků (RLS ) v Power BI Desktopu.

Směr křížového filtru relace, včetně zakázání šíření filtru, můžete upravit pomocí výpočtu modelu. Toho dosáhnete pomocí funkce CROSSFILTER DAX.

Mějte na paměti, že obousměrné relace můžou mít negativní vliv na výkon. Pokus o konfiguraci obousměrné relace by navíc mohl vést k nejednoznačným cestám šíření filtru. V takovém případě se power BI Desktopu nemusí podařit potvrdit změnu relace a upozorní vás na chybovou zprávu. Power BI Desktop vám ale někdy umožní definovat nejednoznačné cesty relací mezi tabulkami. Řešení nejednoznačnosti cesty relace je popsáno dále v tomto článku.

Obousměrné filtrování doporučujeme používat jenom podle potřeby. Další informace najdete v tématu Pokyny k obousměrným relacím.

Tip

V zobrazení modelu Power BI Desktopu můžete interpretovat směr křížového filtru relace tak, že na čáře relace zjistíte šipky. Jedna šipka představuje jednosměrný filtr ve směru šipky; Dvojitá šipka představuje obousměrnou relaci.

Aktivovat tuto relaci

Mezi dvěma tabulkami modelu může existovat pouze jedna aktivní cesta šíření filtru. Je ale možné zavést další cesty relací, i když tyto relace musíte nastavit jako neaktivní. Neaktivní relace je možné aktivovat pouze během vyhodnocení výpočtu modelu. Toho dosáhnete pomocí funkce USERELATIONSHIP DAX.

Obecně doporučujeme definovat aktivní relace, kdykoli je to možné. Rozšiřují rozsah a potenciál toho, jak můžou autoři sestav váš model používat. Použití pouze aktivních relací znamená, že tabulky dimenzí rolí by měly být ve vašem modelu duplikovány.

Za určitých okolností však můžete definovat jednu nebo více neaktivních relací pro tabulku dimenzí rolí. Tento návrh můžete zvážit v těchto případech:

• Vizuály sestav není nutné filtrovat podle různých rolí současně.
• Pomocí USERELATIONSHIP funkce DAX aktivujete konkrétní relaci pro relevantní výpočty modelu.

Další informace najdete v tématu Aktivní vs. Pokyny k neaktivním relacím.

Tip

V zobrazení modelu Power BI Desktopu můžete interpretovat aktivní a neaktivní stav relace. Aktivní relace je reprezentována plnou čárou; Neaktivní relace je reprezentována přerušovanou čárou.

Předpokládat referenční integritu

Vlastnost Předpokládat referenční integritu je k dispozici pouze pro relace 1:N a 1:1 mezi dvěma tabulkami režimu úložiště DirectQuery, které patří do stejné zdrojové skupiny. Tuto vlastnost můžete povolit pouze v případě, že sloupec na straně N neobsahuje hodnoty NUL.

Pokud je tato možnost povolená, nativní dotazy odeslané do zdroje dat spojí dvě tabulky dohromady pomocí metody INNER JOIN a nikoli .OUTER JOIN Obecně platí, že povolení této vlastnosti zlepšuje výkon dotazů, i když závisí na specifikách zdroje dat.

Tuto vlastnost vždy povolte, pokud mezi těmito dvěma tabulkami existuje omezení cizího klíče databáze. I když omezení cizího klíče neexistuje, zvažte povolení vlastnosti, pokud jste si jistí integritou dat.

Důležité

Pokud by se měla ohrozit integrita dat, vnitřní spojení eliminuje chybějící řádky mezi tabulkami. Představte si například tabulku Prodej modelu s hodnotou sloupce Idproduktu, která v související tabulce Product neexistuje. Šíření filtru z tabulky Product (Produkt) do tabulky Sales (Prodej) eliminuje řádky prodeje pro neznámé produkty. Výsledkem by bylo podhodnocené výsledky prodeje.

Další informace najdete v tématu Předpokládat nastavení referenční integrity v Power BI Desktopu.

Relevantní funkce jazyka DAX

Existuje několik funkcí DAX, které jsou relevantní pro relace modelu. Každá funkce je stručně popsána v následujícím seznamu s odrážkami:

• RELATED: Načte hodnotu ze strany 1 relace. Je užitečné při výpočtech z různých tabulek, které se vyhodnocují v kontextu řádku.
• RELATEDTABLE: Načte tabulku řádků ze strany N relace.
• USERELATIONSHIP: Umožňuje výpočet použít neaktivní relaci. (Technicky vzato tato funkce upraví váhu určitého neaktivního vztahu modelu, který pomáhá ovlivnit jeho použití.) Je užitečné, když váš model obsahuje tabulku dimenzí rolí a vy se rozhodnete vytvořit neaktivní relace z této tabulky. Tuto funkci můžete také použít k vyřešení nejednoznačnosti v cestách filtru.
• CROSSFILTER: Upraví směr křížového filtru relace (na jeden nebo oba) nebo zakáže šíření filtru (žádný). Je užitečné, když potřebujete změnit nebo ignorovat relace modelu během vyhodnocení konkrétního výpočtu.
• COMBINEVALUES: Spojí dva nebo více textových řetězců do jednoho textového řetězce. Účelem této funkce je podporovat relace s více sloupci v modelech DirectQuery, když tabulky patří do stejné zdrojové skupiny.
• TREATAS: Použije výsledek výrazu tabulky jako filtry na sloupce z nesouvisející tabulky. V pokročilých scénářích je užitečné, když chcete během vyhodnocení určitého výpočtu vytvořit virtuální vztah.
• Nadřazené a podřízené funkce: Řada souvisejících funkcí, které můžete použít k vygenerování počítaných sloupců pro naturalizaci hierarchie nadřazený-podřízený. Tyto sloupce pak můžete použít k vytvoření hierarchie s pevnou úrovní.

Vyhodnocení relace

Relace modelu z hlediska vyhodnocení jsou klasifikovány jako normální nebo omezené. Nejedná se o konfigurovatelnou vlastnost relace. Ve skutečnosti je odvozena z typu kardinality a zdroje dat dvou souvisejících tabulek. Je důležité pochopit typ vyhodnocení, protože může dojít k důsledkům nebo důsledkům, pokud by došlo k ohrožení integrity dat. Tyto důsledky a důsledky integrity jsou popsány v tomto tématu.

Za prvé, některé teorie modelování je nutná k úplnému pochopení vyhodnocení vztahů.

Model importu nebo DirectQuery zjišťuje všechna data z mezipaměti Vertipaq nebo zdrojové databáze. V obou případech dokáže Power BI určit, že existuje strana 1 relace.

Složený model ale může obsahovat tabulky pomocí různých režimů úložiště (import, DirectQuery nebo duální) nebo více zdrojů DirectQuery. Každý zdroj, včetně mezipaměti Vertipaq importovaných dat, se považuje za zdrojovou skupinu. Relace modelu je pak možné klasifikovat jako uvnitř zdrojové skupiny nebo mezi zdrojovou skupinou. Relace uvnitř zdrojové skupiny spojuje dvě tabulky ve zdrojové skupině, zatímco relace mezi zdrojovými skupinami spojuje tabulky mezi dvěma zdrojovými skupinami. Mějte na paměti, že relace v modelech importu nebo DirectQuery jsou vždy uvnitř zdrojové skupiny.

Tady je příklad složeného modelu.

V tomto příkladu se složený model skládá ze dvou zdrojových skupin: zdrojové skupiny Vertipaq a zdrojové skupiny DirectQuery. Zdrojová skupina Vertipaq obsahuje tři tabulky a zdrojová skupina DirectQuery obsahuje dvě tabulky. Jedna relace mezi zdrojovými skupinami existuje k propojení tabulky ve zdrojové skupině Vertipaq s tabulkou ve zdrojové skupině DirectQuery.

Pravidelné relace

Relace modelu je běžná , když dotazovací modul dokáže určit stranu relace "jedna". Obsahuje potvrzení, že sloupec na straně "jeden" obsahuje jedinečné hodnoty. Všechny relace 1:N uvnitř zdrojové skupiny jsou pravidelné relace.

V následujícím příkladu existují dvě běžné relace, obě jsou označené jako R. Relace zahrnují relaci 1:N obsaženou ve zdrojové skupině Vertipaq a relaci 1:N obsaženou ve zdroji DirectQuery.

Pro modely importu, kde jsou všechna data uložená v mezipaměti Vertipaq, vytvoří Power BI datovou strukturu pro každou běžnou relaci v době aktualizace dat. Datové struktury se skládají z indexovaných mapování všech hodnot sloupců na sloupec a jejich účelem je zrychlit spojování tabulek v době dotazu.

V době dotazu běžné relace umožňují rozšíření tabulky. Rozšíření tabulky vede k vytvoření virtuální tabulky zahrnutím nativních sloupců základní tabulky a následným rozbalením do souvisejících tabulek. Pro tabulky importu se rozšíření tabulky provádí v dotazovacím stroji; pro tabulky DirectQuery se provádí v nativním dotazu odeslaném do zdrojové databáze (pokud není povolená vlastnost Předpokládat referenční integritu ). Dotazovací modul pak funguje s rozbalenou tabulkou a použije filtry a seskupování podle hodnot ve sloupcích rozbalené tabulky.

Poznámka:

Neaktivní relace jsou rozbalené i v případě, že relace není používána výpočtem. Obousměrné relace nemají žádný vliv na rozšíření tabulky.

U relací 1:N se rozšíření tabulky provádí z "N" na stranu "jeden" pomocí LEFT OUTER JOIN sémantiky. Pokud neexistuje odpovídající hodnota z "N" na stranu "jeden", přidá se do boční tabulky "jeden" prázdný virtuální řádek. Toto chování platí jenom pro běžné relace, ne pro omezené relace.

K rozšíření tabulky dochází také u relací 1:1 v rámci zdrojové skupiny, ale pomocí FULL OUTER JOIN sémantiky. Tento typ spojení zajistí, že se prázdné virtuální řádky v případě potřeby přidají na obě strany.

Prázdné virtuální řádky jsou v podstatě neznámé členy. Neznámé členy představují porušení referenční integrity, kde hodnota strany N nemá odpovídající hodnotu strany 1. V ideálním případě by tyto prázdné hodnoty neměly existovat. Mohou být eliminovány čištěním nebo opravou zdrojových dat.

Tady je postup, jak rozšíření tabulky funguje s animovaným příkladem.

V tomto příkladu se model skládá ze tří tabulek: Category (Kategorie), Product (Produkt) a Sales (Prodej). Tabulka Kategorie se vztahuje k tabulce Product s relací 1:N a tabulka Product se vztahuje k tabulce Sales s relací 1:N. Tabulka Category (Kategorie ) obsahuje dva řádky, tabulka Product (Produkt ) obsahuje tři řádky a tabulky Sales (Prodej ) obsahují pět řádků. Na obou stranách všech relací existují odpovídající hodnoty, což znamená, že neexistují žádná porušení referenční integrity. Zobrazí se rozbalená tabulka s časem dotazu. Tabulka se skládá ze sloupců ze všech tří tabulek. Jedná se o denormalizovaný pohled na data obsažená ve třech tabulkách. Nový řádek se přidá do tabulky Sales (Prodej ) a má hodnotu identifikátoru produkce (9), která nemá v tabulce Product žádnou odpovídající hodnotu. Jedná se o porušení referenční integrity. V rozbalené tabulce má nový řádek (prázdné) hodnoty pro sloupce tabulky Category a Product .

Omezené relace

Relace modelu je omezená , pokud neexistuje žádná zaručená "jedna" strana. K omezenému vztahu může dojít ze dvou důvodů:

• Relace používá typ kardinality M:N (i když jeden nebo oba sloupce obsahují jedinečné hodnoty).
• Relace je mezi zdrojovými skupinami (což může být pouze případ složených modelů).

V následujícím příkladu existují dvě omezené relace, obě jsou označené jako L. Tyto dvě relace zahrnují relaci M:N obsaženou ve zdrojové skupině Vertipaq a relaci 1:N mezi zdrojovými skupinami.

U modelů importu se datové struktury nikdy nevytvořily pro omezené relace. V takovém případě Power BI vyřeší spojení tabulek v době dotazu.

K rozšíření tabulky nikdy nedojde u omezených relací. Spojení tabulek se dosahuje pomocí INNER JOIN sémantiky a z tohoto důvodu se nepřidají prázdné virtuální řádky, aby se kompenzuje porušení referenční integrity.

Existují další omezení související s omezenými relacemi:

• Funkci RELATED DAX nelze použít k načtení hodnot sloupce na straně 1.
• Vynucení zabezpečení na úrovni řádků má omezení topologie.

Tip

V zobrazení modelu Power BI Desktopu můžete interpretovat relaci jako omezenou. Omezený vztah je reprezentován závorkami () za indikátory kardinality.

Řešení nejednoznačnosti cesty relace

Obousměrné relace mohou představovat více, a proto nejednoznačné cesty šíření filtru mezi tabulkami modelu. Při vyhodnocování nejednoznačnosti vybere Power BI cestu šíření filtru podle priority a váhy.

Priorita

Vrstvy priority definují posloupnost pravidel, která Power BI používá k překladu nejednoznačnosti cesty relace. První shoda pravidla určuje cestu, kterou bude Power BI následovat. Každé pravidlo níže popisuje, jak filtruje tok ze zdrojové tabulky do cílové tabulky.

1. Cesta skládající se z relací 1:N.
2. Cesta skládající se z relací 1:N nebo M:N.
3. Cesta skládající se z relací M:1.
4. Cesta skládající se z relací 1:N ze zdrojové tabulky do zprostředkující tabulky následovaná relacemi M:1 z zprostředkující tabulky do cílové tabulky.
5. Cesta skládající se z relací 1:N nebo M:N ze zdrojové tabulky do zprostředkující tabulky následovaná relacemi M:1 nebo N:N z zprostředkující tabulky do cílové tabulky.
6. Jakákoli jiná cesta.

Pokud je relace zahrnutá do všech dostupných cest, odebere se z hlediska všech cest.

Hmotnost

Každá relace v cestě má váhu. Ve výchozím nastavení je každá váha relace rovna, pokud se nepoužije funkce USERELATIONSHIP . Váha cesty je maximální závaží relací podél cesty. Power BI používá váhy cesty k vyřešení nejednoznačnosti mezi více cestami ve stejné vrstvě priority. Nevybere cestu s nižší prioritou, ale zvolí cestu s vyšší váhou. Počet relací v cestě nemá vliv na váhu.

Pomocí funkce USERELATIONSHIP můžete ovlivnit váhu relace. Váha je určena úrovní vnoření volání této funkce, kde nejvnitřnější volání obdrží nejvyšší hmotnost.

Představte si následující příklad. Míra Prodej produktů přiřadí relaci mezi Sales[ProductID] a Product[ProductID], za kterou následuje vztah mezi Inventory[ProductID] a Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Poznámka:

Pokud Power BI zjistí více cest, které mají stejnou prioritu a stejnou váhu, vrátí nejednoznačný chybu cesty. V tomto případě musíte vyřešit nejednoznačnost ovlivněním váhy relace pomocí funkce USERELATIONSHIP nebo odebráním nebo úpravou relací modelu.

Předvolba výkonu

Následující seznam obsahuje pořadí výkonu šíření filtru od nejrychlejšího po nejpomalejší výkon:

1. Relace 1:N v rámci zdrojové skupiny
2. Relace modelu M:N dosažené pomocí zprostředkující tabulky, které zahrnují alespoň jednu obousměrnou relaci
3. Relace kardinality M:N
4. Vztahy mezi zdrojovými skupinami

Související obsah

Další informace o tomto článku najdete v následujících zdrojích informací:

• Vysvětlení hvězdicového schématu a důležitosti pro Power BI
• Pokyny pro relaci 1:1
• Pokyny k relacím M:N
• Pokyny k aktivní a neaktivní relaci
• Pokyny k obousměrnému vztahu
• Pokyny k řešení potíží s relacemi
• Video: The Do's and Don's of Power BI Relationships
• Otázky? Zkuste se zeptat Komunita Power BI
• Návrhy? Přispívání nápadů ke zlepšení Power BI