Pokyny k aktivní a neaktivní relaci

Tento článek se zaměřuje na vás jako modelátor dat, který pracuje s Power BI Desktopem. Poskytuje návod, kdy vytvářet aktivní nebo neaktivní relace 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 tím, jak je konfigurovat, doporučujeme, abyste si nejprve přečetli článek Model vztahů v Power BI Desktop.

Je také důležité, abyste porozuměli návrhu hvězdicového schématu. Další informace najdete v sekci Pochopení hvězdicového schématu a jeho 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 navrženého k analýze dochvilnosti letů leteckých společností (OTP). Model má tabulku Flight, což je faktografická tabulka , 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 Airport, což je dimenzionální tabulka , která ukládá jeden řádek pro každé 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. V tabulce Flight se sloupce DepartureAirport a ArrivalAirport vztahují k Airport sloupci tabulky Airport. V návrhu hvězdicového schématu je tabulka Airport popsána jako dimenze role. V tomto modelu jsou 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, nefunguje dobře pro modely Power BI. Je to proto, že relace modelu jsou cesty pro šíření filtru a tyto cesty musí být deterministické. Další informace o zajištění, že cesty šíření filtru jsou deterministické, najdete v tématu řešení nejednoznačnosti cesty relace. Proto, jak je znázorněno v tomto příkladu, je jedna relace aktivní, zatímco druhá je neaktivní (znázorněná přerušovanou čárou). Konkrétně se jedná o relaci s aktivním sloupcem ArrivalAirport, což znamená, že filtry použité u tabulky Airport se automaticky rozšíří do ArrivalAirport sloupce tabulky Flight.

Tento návrh modelu má závažná omezení způsobu hlášení dat. Konkrétně není možné filtrovat tabulku Airport a automaticky izolovat podrobnosti letu pro odletové letiště. Protože zprávy musí být filtrovány (nebo seskupeny) podle letiště odletu a letiště příletu současně, jsou vyžadovány dva 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šť: Departure Airport a Arrival Airport. Každá relace modelu mezi těmito tabulkami a tabulkou Flight je aktivní. Všimněte si také, že názvy sloupců v tabulkách Departure Airport a Arrival Airport mají předponu slovo odletu nebo příjezdu .

Vylepšený návrh modelu podporuje vypracování tohoto návrhu sestavy.

Stránka zprávy filtruje podle letiště odletu Melbourne a tabulkový vizuál seskupuje podle letišť příletu.

Poznámka

U modelů importu způsobil přidání další tabulky dimenzí větší velikost modelu a delší dobu aktualizace. Proto je v rozporu s doporučeními popsanými v článku o technikách redukce dat pro modelování importu. V tomto příkladu však požadavek mít pouze aktivní vztahy převládá nad těmito doporučeními.

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

Metodologie refaktoringu

Tady je metodologie refaktorování modelu z jedné tabulky pro roli k návrhu s jednou tabulkou proroli.

1. Odeberte všechny neaktivní relace.

2. Zvažte přejmenování tabulky dimenzí rolí, abyste lépe popsali její roli. V příkladu v tomto článku souvisí tabulka Airport se sloupcem ArrivalAirport tabulky Flight, takže je přejmenována na Arrival Airport.

3. Vytvořte kopii RPG tabulky, dejte jí název, který odráží její účel. Pokud se jedná o tabulku Import, doporučujeme vytvořit počítanou tabulku. Pokud se jedná o tabulku DirectQuery, můžete dotaz Power Query duplikovat.

   V příkladu byla tabulka Departure Airport vytvořena pomocí následující definice výpočtové tabulky.

   Departure Airport = 'Arrival Airport'
   

4. Vytvořte aktivní relaci s novou tabulkou.

5. Zvažte přejmenování sloupců v tabulkách, aby přesně odrážely jejich roli. V příkladu v tomto článku 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 mít popisy, které jsou samopopisné a nejednoznačné. Vylepšuje také prostředí Q&A, což uživatelům umožňuje snadno psát přesné otázky.

6. Zvažte přidání popisů do tabulek rolí. (V podokně Data se zobrazí popis, když autor sestavy najede svým kurzorem na tabulku.) Tímto způsobem můžete autorům sestav sdělit další podrobnosti o šíření filtrů.

Neaktivní relace

Za určitých okolností mohou neaktivní vztahy řešit konkrétní potřeby sestavování zpráv.

Zvažte různé požadavky na model a ohlašování.

• Prodejní model obsahuje tabulku Sales se dvěma sloupci kalendářních dat: OrderDate a ShipDate.
• 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 OrderDate, který vždy ukládá platné datum.
• Pouze jedno měření vyžaduje šíření datového filtru do sloupce ShipDate, který může obsahovat prázdné hodnoty (dokud se objednávka neodešle).
• Neexistuje žádný požadavek na souběžné filtrování (nebo seskupení) objednávek a období data expedice.

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

Mezi tabulkami Sales a Date existují dvě relace modelu. V tabulce Sales se sloupce OrderDate a ShipDate vztahují k Date sloupci tabulky Date. V tomto modelu jsou dvě role pro tabulku Datedatum objednávky a datum expedice. To je vztah ke sloupci OrderDate, který je aktivní.

Všech šest měr (kromě jedné) musí filtrovat podle sloupce OrderDate. Míra Orders Shipped však musí filtrovat podle sloupce ShipDate.

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

Orders = COUNTROWS(Sales)

Tady je definice míry Orders Shipped. Používá USERELATIONSHIP funkci DAX, která aktivuje šíření filtru pro konkrétní relaci, ale pouze během vyhodnocení výrazu. V tomto příkladu se použije vztah 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 seskupuje podle měsíců a zobrazuje různé statistiky prodeje. Míry Orders a Orders Shipped produkují různé výsledky. Každá z nich používá stejnou logiku souhrnu (počet řádků tabulky Sales), ale liší se šíření filtru tabulky Date.

Všimněte si, že kráječ na čtvrtiny obsahuje možnost BLANK. Tato možnost průřezu se zobrazí v důsledku rozšíření tabulky . Zatímco každý řádek tabulky Sales má platné datum objednávky, některé řádky mají prázdné datum expedice – tyto objednávky se ještě nedoručují. Rozšíření tabulky také bere v úvahu neaktivní relace, takže se mohou objevit BLANKy kvůli BLANKům na straně s mnoha prvky relace (nebo kvůli problémům s integritou dat).

Poznámka

Filtry zabezpečení na úrovni řádků (RLS) se šíří pouze prostřednictvím aktivních relací. Filtry RLS se nikdy nešíří u neaktivních relací, i když funkci DAX USERELATIONSHIP používá definice měření.

Doporučení

Doporučujeme definovat aktivní relace, kdykoli je to možné, zejména pokud jsou role RLS definovány ve vašem datovém modelu. Zvětšují rozsah a možnosti toho, jak mohou model používat autoři sestav a uživatelé při práci s Q&A. Znamená to, ž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 přístup můžete zvážit v těchto případech:

• Vizuály sestav není potřeba filtrovat podle různých rolí současně.
• 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
• Pochopit hvězdicové schéma a důležitost pro Power BI
• Pokyny pro řešení problémů ve vztahu
• Otázky? Zkuste se zeptat komunity Fabric
• Návrhy? Přispět nápady k vylepšení Fabric