Pokyny na prístup k aktívnym a neaktívnym vzťahom

Tento článok je určený pre modelárov údajových pracujúcich s aplikáciou Power BI Desktop. Nájdete v ňom pokyny týkajúce sa toho, kedy sa majú vytvárať aktívne alebo neaktívne modelové vzťahy. V predvolenom nastavení aktívne vzťahy šíria filtre do iných tabuliek. Neaktívny vzťah však šíri filtre iba vtedy, keď výraz DAX aktivuje (použije) vzťah.

Poznámka

Úvod o vzťahoch v modeloch nie je zahrnutý v tomto článku. Ak nie ste úplne oboznámení so vzťahmi, ich vlastnosťami alebo o tom, ako ich konfigurovať, odporúčame si najprv prečítať článok Modelové vzťahy v aplikácii Power BI Desktop .

Dôležité je aj to, aby ste pochopili návrh hviezdicovej schémy. Ďalšie informácie nájdete v téme Vysvetlenie hviezdicovej schémy a dôležitosti pre Power BI.

Aktívne vzťahy

Vo všeobecnosti odporúčame definovať aktívne vzťahy vždy, keď je to možné. Rozširujú rozsah a potenciál toho, ako môžu váš model používať autori zostáv a používatelia pracujúci s funkciou Q&A.

Zoberme si príklad modelu importu určeného na analýzu času letov (OTP) leteckých spoločností. Model obsahuje tabuľku Let , čo je tabuľka faktov s jedným riadkom na každý let. V každom riadku sa zaznamenáva dátum letu, číslo letu, letisko odletu a letisko príletu a akýkoľvek čas oneskorenia (v minútach). K dispozícii je aj tabuľka Letisko , čo je tabuľka dimenzií s jedným riadkom na jedno letisko. Každý riadok popisuje kód letiska, názov letiska a krajinu alebo oblasť.

Tu je čiastkový diagram modelu týchto dvoch tabuliek.

Medzi tabuľkami Let a Letisko existujú dva modelové vzťahy. V tabuľke Let stĺpce LetiskoOdletu a LetiskoPríletu súvisia so stĺpcom Letisko tabuľky Letisko. V návrhu hviezdicovej schémy je tabuľka Letisko opísaná ako dimenzia, ktorá má funkciu roly. V tomto modeli sú dvomi rolami letisko odletu a letisko príletu.

Hoci tento návrh dobre funguje s návrhmi relačnej hviezdicovej schémy, nefunguje s modelmi Power BI. Príčinou je, že modelové vzťahy sú cestami šírenia filtra, pričom tieto cesty musia byť deterministické. Ďalšie informácie o zabezpečení toho, aby cesty šírenia filtrov boli deterministické, nájdete v téme Riešenie nejednoznačnosti cesty vzťahov. Preto – ako je popísané v tomto príklade – jeden vzťah je aktívny, zatiaľ čo druhý je neaktívny (reprezentovaný prerušovanou čiarou). Konkrétne ide o vzťah k stĺpcu LetiskoPríletu, ktorý je aktívny. To znamená, že filtre použité na tabuľku Letisko sa automaticky šíria do stĺpca LetiskoPríletu tabuľky Let.

Tento návrh modelu obsahuje prísne obmedzenia možných spôsobov hlásenia údajov. Konkrétne nie je možné filtrovať tabuľku Letisko tak, aby automaticky izolovala podrobnosti o lete pre letisko odletu. Keďže požiadavky na hlásenie zahŕňajú filtrovanie (alebo zoskupenie) podľa letiska odletu a letiska príletu zároveň, sú potrebné dva aktívne vzťahy. Prenesenie tejto požiadavky do návrhu modelu Power BI znamená, že model musí mať dve tabuľky pre letisko.

Tu je vylepšený návrh modelu.

Model má teraz dve tabuľky pre letisko: Letisko odletu a Letisko príletu. Modelové vzťahy medzi týmito tabuľkami a tabuľkou Let sú aktívne. Všimnite si tiež, že názvy stĺpcov v tabuľkách Letisko odletu a Letisko príletu obsahujú slovo odletu alebo príletu.

Vylepšený návrh modelu podporuje tvorbu nasledujúceho návrhu zostavy.

Stránka zostavy sa filtruje podľa mesta Melbourne ako letiska odletu a vizuál tabuľky sa zoskupuje podľa letísk príletu.

Poznámka

V prípade modelov importu má ďalšia tabuľka za následok zvýšenú veľkosť modelu a dlhšie časy obnovenia. V dôsledku toho je to v rozpore s odporúčaniami opísanými v článku Techniky znižovania objemu údajov na modelovanie importu . V uvedenom príklade však požiadavka mať iba aktívne vzťahy tieto odporúčania prepíše.

Okrem toho je bežné, že tabuľky dimenzií obsahujú nízke počty riadkov v porovnaní s počtami riadkov v tabuľkách faktov. Preto nie je pravdepodobné, že väčšia veľkosť modelu a čas obnovenia budú príliš veľké.

Metodológia refaktorovania

Táto metodológia slúži na refaktorovanie modelu z jednej tabuľky dimenzií, ktorá má funkciu roly, do návrhu s jednou tabuľkou na rolu.

1. Odstráňte všetky neaktívne vzťahy.

2. Ak chcete lepšie opísať jeho rolu, zvážte premenovanie tabuľky dimenzií, ktorá má funkciu roly, aby ste jej rolu opísali lepšie. V príklade tabuľka Letisko súvisí so stĺpcom LetiskoPríletu tabuľky Let , takže sa premenuje na Letisko príletu.

3. Vytvorte kópiu tabuľky, ktorá má funkciu roly, a dajte jej názov, ktorý vyjadruje jej rolu. Ak ide o tabuľku importu, odporúčame definovať vypočítanú tabuľku. Ak ide o tabuľku DirectQuery, môžete dotaz Power Query duplikovať.

   V príklade sa tabuľka Letisko odletu vytvorila pomocou nasledujúcej definície vypočítanej tabuľky.

   Departure Airport = 'Arrival Airport'
   

4. Vytvorte aktívny vzťah týkajúci sa novej tabuľky.

5. Zvážte premenovanie stĺpcov v tabuľkách tak, aby presne vyjadrovali ich rolu. V príklade majú všetky stĺpce pred sebou slovo odletu alebo príletu. Tieto názvy zabezpečia, že vizuály zostáv budú mať predvolene popisné a jednoznačné označenia. Zlepšuje sa tým aj prostredie funkcie Q&A, čo používateľom umožňuje jednoducho písať svoje otázky.

6. Zvážte pridanie popisov k tabuľkám, ktoré majú funkciu roly. (V Tabla Polia , keď autor zostavy podrží kurzor nad tabuľkou, zobrazí sa popis. Týmto spôsobom môžete komunikovať všetky ďalšie podrobnosti o šírení filtrov pre autorov zostáv.

Neaktívne vzťahy

Za určitých okolností môžu neaktívne vzťahy riešiť špeciálne potreby vytvárania zostáv.

Pozrime sa teraz na rôzne požiadavky na modely a zostavy:

• Model predaja obsahuje tabuľku Predaj, ktorá má dva stĺpce dátumov: DátumObjednávky a DátumOdoslania
• V každom riadku v tabuľke Predaj sa zaznamená jedna objednávka
• Filtre dátumov sa takmer vždy použijú na stĺpec DátumObjednávky , v ktorom je vždy uchovávaný platný dátum.
• Iba jedna mierka vyžaduje šírenie filtra dátumu do stĺpca DátumOdoslania , ktorý môže obsahovať PRÁZDNE hodnoty (kým sa objednávka doručuje)
• Neexistujú žiadne požiadavky na súbežné filtrovanie (alebo zoskupenie podľa) období dátumu objednávky a dátumu odoslania

Tu je čiastkový diagram modelu týchto dvoch tabuliek.

Medzi tabuľkami Sales (Predaj ) a Date (Dátum ) existujú dva modelové vzťahy. V tabuľke Sales (Predaj) stĺpce OrderDate (DátumObjednávky) a ShipDate (DátumOdoslania) súvisia so stĺpcom Date (Dátum) tabuľky Date (Dátum). V tomto modeli dve roly pre tabuľku Date sú dátum objednávky a dátum odoslania. Aktívny je vzťah k stĺpcu DátumObjednávky .

Všetky zo šiestich mierok – okrem jednej – sa musia filtrovať podľa stĺpca DátumObjednávky . Mierka Odoslané objednávky sa však musí filtrovať podľa stĺpca DátumOdoslania .

Tu je definícia mierky Objednávky . Jednoducho spočíta riadky tabuľky Predaj v rámci kontextu filtra. Všetky filtre použité v tabuľke Dátum sa rozšíria do stĺpca DátumObjednávky.

Orders = COUNTROWS(Sales)

Tu je definícia mierky Odoslané objednávky. Používa funkciu USERELATIONSHIP DAX, ktorá aktivuje šírenie filtrov iba pre konkrétny vzťah počas vyhodnocovania výrazu. V tomto príklade sa používa vzťah k stĺpcu DátumOdoslania .

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

Tento návrh modelu podporuje tvorbu nasledujúceho návrhu zostavy.

Strana zostavy sa filtruje podľa 4. štvrťroka 2019. Vizuál tabuľky sa zoskupuje podľa mesiaca a zobrazuje rôzne štatistiky predaja. Mierky Objednávky a Odoslané objednávky produkujú rôzne výsledky. Každá z nich používa rovnakú logiku súhrnu (počet riadkov tabuľky Predaj ), ale rôzne šírenie filtra tabuľky Dátum .

Všimnite si, že rýchly filter štvrťroka obsahuje PRÁZDNU položku. Táto položka rýchleho filtra sa zobrazí ako výsledok rozšírenia tabuľky. Hoci každý riadok tabuľky Sales (Predaj ) obsahuje dátum objednávky, niektoré riadky obsahujú PRÁZDNY dátum odoslania – tieto objednávky sa ešte len majú odoslať. Rozšírenie tabuľky berie do úvahy aj neaktívne vzťahy, preto sa môžu zobrazovať PRÁZDNE položky v dôsledku PRÁZDNYCH prvkov na strane "many" vzťahu alebo v dôsledku problémov s integritou údajov.

Poznámka

Filtre zabezpečenia na úrovni riadkov sa šíria len prostredníctvom aktívnych vzťahov. Filtre zabezpečenia na úrovni riadkov sa nebudú šíriť pre neaktívne vzťahy ani v prípade, ak je funkcia UseRelationship explicitne pridaná do definície mierky.

Odporúčania

V súhrne odporúčame definovať aktívne vzťahy vždy, keď je to možné, a to najmä v prípade, keď sú roly zabezpečenia na úrovni riadkov definované pre váš dátový model. Rozširujú rozsah a potenciál toho, ako môžu váš model používať autori zostáv a používatelia pracujúci s funkciou Q&A. Znamená to, že v modeli by sa mali duplikovať tabuľky dimenzií, ktoré majú funkciu roly.

Za určitých okolností však môžete pre tabuľku dimenzií, ktorá má funkciu roly, definovať jeden alebo viac neaktívnych vzťahov. Tento návrh môžete brať do úvahy v týchto prípadoch:

• Pre vizuály zostáv neexistuje žiadna požiadavka na súbežné filtrovanie podľa rôznych rolí
• Funkciu USERELATIONSHIP DAX používate na aktiváciu konkrétneho vzťahu pre príslušné výpočty modelu

Súvisiaci obsah

Ďalšie informácie súvisiace s týmto článkom nájdete v nasledujúcich zdrojoch:

• Vzťahy modelov v aplikácii Power BI Desktop
• Vysvetlenie hviezdicovej schémy a jej dôležitosti pre Power BI
• Pokyny na riešenie problémov so vzťahmi
• Máte nejaké otázky? Skúste sa spýtať Komunita Power BI
• Návrhy? Prispejte nápadmi na zlepšenie služby Power BI