Pokyny k aktivní a neaktivní relaci

Tento článek se zaměřuje na modelátora dat, který pracuje s Power BI Desktopem. Poskytuje pokyny k vytváření aktivních nebo neaktivních relací modelu. Ve výchozím nastavení aktivní relace šíří filtry do jiných tabulek. Neaktivní relace ale rozšíří filtry pouze v případě, že výraz DAX aktivuje (použije) relaci.

Poznámka:

Úvod do relací modelu není popsaný v tomto článku. Pokud nejste úplně obeznámeni s relacemi, jejich vlastnostmi nebo jejich konfigurací, doporučujeme, abyste si nejdřív přečetli relace modelu v článku Power BI Desktopu .

Je také důležité, abyste porozuměli návrhu hvězdicového schématu. Další informace najdete v tématu Vysvětlení hvězdicového schématu a důležitosti pro Power BI.

Aktivní relace

Obecně doporučujeme definovat aktivní relace, kdykoli je to možné. Rozšiřují rozsah a potenciál toho, jak můžou model používat autoři sestav a uživatelé pracující s Q&A.

Představte si příklad modelu importu, který je navržený k analýze výkonu letecké společnosti při běhu (OTP). Model obsahuje tabulku flight , což je tabulka typu fakta, která ukládá jeden řádek na let. Každý řádek zaznamenává datum letu, číslo letu, letiště odletu a příletu a čas zpoždění (v minutách). K dispozici je také tabulka Letiště , což je tabulka typu dimenze, která ukládá jeden řádek na letiště. Každý řádek popisuje kód letiště, název letiště a zemi nebo oblast.

Tady je částečný modelový diagram dvou tabulek.

Mezi tabulkami Flight a Airport existují dvě relace modelu. Sloupce FlightAirport a ArrivalAirport se v tabulce Let vztahují ke sloupci Letiště v tabulce Letiště. V návrhu hvězdicového schématu je tabulka Letiště popsaná jako dimenze role. V tomto modelu jsou tyto dvě role letiště odletu a letiště příletu.

I když tento návrh funguje dobře pro návrhy relačních hvězdicových schémat, nejedná se o modely Power BI. Je to proto, že relace modelu jsou cesty pro šíření filtru a tyto cesty musí být deterministické. Další informace o tom, jak zajistit, aby cesty šíření filtru byly deterministické, naleznete v tématu nejednoznačnost cesty vztahu. Tak, jak je popsáno v tomto příkladu, je jedna relace aktivní, zatímco druhá je neaktivní (reprezentovaná přerušovanou čárou). Konkrétně se jedná o relaci se sloupcem ArrivalAirport , který je aktivní. To znamená, že filtry použité na tabulku Letiště se automaticky rozšíří do sloupce ArrivalAirport tabulky Flight.

Tento návrh modelu má závažná omezení způsobu hlášení dat. Konkrétně není možné filtrovat tabulku Letiště a automaticky izolovat podrobnosti letu pro letiště odletu. Vzhledem k tomu, že požadavky na vytváření sestav zahrnují filtrování (nebo seskupení) podle letiště odletu a příletu ve stejnou dobu, jsou potřeba dvě aktivní vztahy. Převod tohoto požadavku do návrhu modelu Power BI znamená, že model musí mít dvě tabulky letiště.

Tady je vylepšený návrh modelu.

Model má nyní dvě tabulky letiště: Letiště odletu a letiště příletu. Relace modelu mezi těmito tabulkami a tabulkou Flight jsou aktivní. Všimněte si také, že názvy sloupců v tabulkách Letiště odletu a příletu mají předponu slovo Odlet nebo Příjezd.

Vylepšený návrh modelu podporuje vytvoření následujícího návrhu sestavy.

Stránka sestavy filtruje podle Melbourne jako letiště odletu a vizuál tabulky seskupuje podle letiště příletu.

Poznámka:

U modelů importu způsobila další tabulka větší velikost modelu a delší dobu aktualizace. Proto je v rozporu s doporučeními popsanými v technikách redukce dat pro článek o modelování importu . V tomto příkladu však požadavek, aby tyto doporučení přepsaly pouze aktivní relace.

Kromě toho je běžné, že tabulky typu dimenze obsahují nízké počty řádků vzhledem k počtu řádků tabulky typu fakta. Proto větší velikost modelu a časy aktualizace pravděpodobně nebudou příliš velké.

Metodologie refaktoringu

Tady je metodologie pro refaktoring modelu z jedné tabulky dimenzí rolí na návrh s jednou tabulkou pro každou roli.

1. Odeberte všechny neaktivní relace.

2. Zvažte přejmenování tabulky typu dimenze role, abyste lépe popsali její roli. V příkladu se tabulka Letiště vztahuje ke sloupci ArrivalAirport tabulky Flight, takže se přejmenuje na Letiště příletu.

3. Vytvořte kopii tabulky rolí, která jí poskytne název, který odpovídá jeho roli. Pokud se jedná o tabulku importu, doporučujeme definovat počítanou tabulku. Pokud se jedná o tabulku DirectQuery, můžete dotaz Power Query duplikovat.

   V příkladu byla vytvořena tabulka Letiště odletu pomocí následující definice počítané tabulky.

   Departure Airport = 'Arrival Airport'
   

4. Vytvořte aktivní relaci, která vytvoří relaci s novou tabulkou.

5. Zvažte přejmenování sloupců v tabulkách, aby přesně odrážely jejich roli. V příkladu mají všechny sloupce předponu slova Odlet nebo Příjezd. Tyto názvy ve výchozím nastavení zajišťují, že vizuály sestavy budou obsahovat popisky, které nejsou nejednoznačné. Zlepšuje také možnosti Q&A, což uživatelům umožňuje snadno psát své otázky.

6. Zvažte přidání popisů do tabulek rolí. (V Podokno Pole , popis se zobrazí v popisu, když autor sestavy najede kurzorem na tabulku.) Tímto způsobem můžete autorům sestav sdělit jakékoli další podrobnosti šíření filtru.

Neaktivní relace

Za určitých okolností můžou neaktivní relace řešit zvláštní potřeby vytváření sestav.

Teď se podíváme na různé požadavky na model a vytváření sestav:

• Prodejní model obsahuje tabulku Sales (Prodej ) se dvěma sloupci kalendářních dat: OrderDate (DatumObjednávky) a ShipDate (Datum expedice).
• Každý řádek v tabulce Sales zaznamenává jednu objednávku.
• Filtry kalendářních dat se téměř vždy použijí na sloupec DatumObjednávky , který vždy ukládá platné datum.
• Pouze jedna míra vyžaduje šíření filtru kalendářních dat do sloupce ShipDate , který může obsahovat prázdné hodnoty (dokud nebude objednávka odeslána).
• Neexistuje žádný požadavek na souběžné filtrování (nebo seskupení podle) období objednávky a data expedice.

Tady je částečný modelový diagram dvou tabulek.

Mezi tabulkami Sales a Date existují dvě relace modelu. V tabulce Sales (Prodej) se sloupce DatumObjednávky a Datum expedice vztahují ke sloupci Date (Datum) tabulky Date (Datum). V tomto modelu jsou dvě role pro tabulku Date (Datum ) datum objednávky a datum expedice. Jedná se o relaci se sloupcem OrderDate , který je aktivní.

Všechny šest měr (kromě jedné) musí filtrovat podle sloupce DatumObjednávky . Míra Expedované objednávky však musí filtrovat podle sloupce Datum expedice.

Tady je definice míry Orders . Jednoduše spočítá řádky tabulky Sales v kontextu filtru. Všechny filtry použité v tabulce Date se rozšíří do sloupce DatumObjednávky .

Orders = COUNTROWS(Sales)

Tady je definice míry Expedované objednávky. Používá funkci USERELATIONSHIP DAX, která aktivuje šíření filtru pro konkrétní relaci pouze během vyhodnocení výrazu. V tomto příkladu se použije relace ke sloupci ShipDate .

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Tento návrh modelu podporuje vytvoření následujícího návrhu sestavy.

Stránka sestavy filtruje podle čtvrtletí 2019 Q4. Vizuál tabulky seskupí podle měsíců a zobrazí různé statistiky prodeje. Míry Objednávky a Objednávky expedované vygenerují různé výsledky. Každá z nich používá stejnou logiku sumarizace (počet řádků tabulky Sales ), ale jiné šíření filtru tabulky Kalendářní data .

Všimněte si, že průřez čtvrtletí obsahuje prázdnou položku. Tato položka průřezu se zobrazí jako výsledek rozšíření tabulky. Zatímco každý řádek tabulky Sales má datum objednávky, některé řádky mají prázdné datum expedice – tyto objednávky se ještě mají expedovat. Rozšíření tabulky také bere v úvahu neaktivní relace, takže se prázdné hodnoty můžou objevit kvůli sítím BLAN na straně N relace nebo kvůli problémům s integritou dat.

Poznámka:

Filtry zabezpečení na úrovni řádků se šíří pouze prostřednictvím aktivních relací. Filtry zabezpečení na úrovni řádků se nerozšířou pro neaktivní relace, i když se do definice míry přidá explicitně UseRelationship.

Doporučení

V souhrnu doporučujeme definovat aktivní relace, kdykoli je to možné, zejména pokud jsou pro datový model definovány role zabezpečení na úrovni řádků. Rozšiřují rozsah a potenciál toho, jak můžou model používat autoři sestav a uživatelé pracující s Q&A. Znamená to, že tabulky dimenzí rolí by měly být v modelu duplikované.

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

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

Související obsah

Další informace týkající se tohoto článku najdete v následujících zdrojích informací:

• Relace modelu v Power BI Desktopu
• Vysvětlení hvězdicového schématu a důležitosti pro Power BI
• Pokyny k řešení potíží s relacemi
• Otázky? Zkuste se zeptat Komunita Power BI
• Návrhy? Přispívání nápadů ke zlepšení Power BI