Zdieľať cez


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

Tento článok je určený pre modelárov údajov, ktorí pracujú 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.

Nota

Ú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 Vzťahy modelov 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 Vysvetlenie hviezdicovej schémy a dôležitosti prePower 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 Import určeného na analýzu času letov (OTP) leteckých spoločností. Model obsahuje tabuľku Flight, ktorá je tabuľkou faktov, ktorá uchováva jeden riadok na 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 Airport, ktorá je tabuľkou dimenzií, ktorá uchováva jeden riadok na letisko. Každý riadok popisuje kód letiska, názov letiska a krajinu alebo oblasť.

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

Diagram znázorňujúci model obsahujúci dve tabuľky: Let a Letisko. Návrh vzťahu je popísaný v nasledujúcom odseku.

Medzi tabuľkami Flight a Airport existujú dva modelové vzťahy. V tabuľke Flight sa stĺpce DepartureAirport a ArrivalAirport vzťahujú na Airport stĺpec tabuľky Airport. V návrhu hviezdicovej schémy sa tabuľka Airport popisuje 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 dobre. 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 vyriešenie nejednoznačnosti cesty vzťahov. Preto – ako je uvedené 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 aktívnemu stĺpcu ArrivalAirport, čo znamená, že filtre použité v tabuľke Airport sa automaticky šíria do stĺpca ArrivalAirport tabuľky Flight.

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 Airport tak, aby automaticky izolovala podrobnosti o lete pre letisko odletu. Keďže zostavy musia filtrovať (alebo zoskupiť) podľa letiska odletu a letiska príletu zároveň, vyžadujú sa 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.

diagram znázorňujúci model obsahujúci štyri tabuľky: Dátum, Let, Letisko odletu a Letisko príletu.

Model má teraz dve tabuľky pre letisko: Departure Airport a Arrival Airport. Každý modelový vzťah medzi týmito tabuľkami a tabuľkou Flight je aktívny. Všimnite si tiež, že názvy stĺpcov v tabuľkách Departure Airport a Arrival Airport obsahujú slovo odchodu alebo tabuľky Arrival.

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

diagram znázorňujúci, že strana zostavy má dva rýchle filtre a vizuál tabuľky. Rýchle filtre sú Mesiac a Letisko odletu.

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

Nota

V prípade modelov importu má pridanie ďalšej tabuľky dimenzií 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í ukladajú nízke počty riadkov v porovnaní s počtami riadkov tabuľky 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 jednu tabuľku naroly.

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

  2. Ak chcete lepšie opísať jej rolu, zvážte premenovanie tabuľky dimenzií, ktorá má funkciu roly, aby ste jej rolu opísali lepšie. V príklade tohto článku tabuľka Airport súvisí so stĺpcom ArrivalAirport tabuľky Flight, takže sa premenuje na Arrival Airport.

  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 vytvoriť vypočítanú tabuľku. Ak ide o tabuľku DirectQuery, môžete dotaz Power Query duplikovať.

    V príklade Departure Airport tabuľka bola vytvorená 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 v tomto článku majú všetky stĺpce 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ť presné otázky.

  6. Zvážte pridanie popisov k tabuľkám, ktoré majú funkciu roly. (Na table Údaje sa zobrazí popis v popise, keď autor zostavy ukáže kurzorom na tabuľku.) Týmto spôsobom môžete komunikovať ďalšie podrobnosti o šírení filtrov autorom zostáv.

Neaktívne vzťahy

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

Zvážte rôzne požiadavky na modely a zostavy:

  • Model predaja obsahuje tabuľku Sales, ktorá obsahuje dva stĺpce dátumov: OrderDate a ShipDate.
  • Každý riadok v tabuľke Sales zaznamená jedno poradie.
  • Filtre dátumov sa takmer vždy použijú na stĺpec OrderDate, v ktorom je vždy uchovávaný platný dátum.
  • Iba jedna mierka vyžaduje šírenie filtra dátumu do stĺpca ShipDate, ktorý môže obsahovať PRÁZDNE hodnoty (kým sa objednávka nevráti).
  • Neexistujú žiadne požiadavky na súbežné filtrovanie (alebo zoskupenie) objednávok a obdobia dátumu odoslania.

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

diagram znázorňujúci model obsahujúci dve tabuľky: Predaj a Dátum. Tabuľka Sales (Predaj) obsahuje šesť mierok.

Medzi tabuľkami Sales a Date existujú dva modelové vzťahy. V tabuľke Sales sa stĺpce OrderDate a ShipDate vzťahujú na Date stĺpec tabuľky Date. V tomto modeli dve roly pre tabuľku Date dátumov objednávok a dátum odoslania. Aktívny je vzťah k stĺpcu OrderDate.

Všetky zo šiestich mierok – okrem jednej – sa musia filtrovať podľa stĺpca OrderDate. Mierka Orders Shipped sa však musí filtrovať podľa stĺpca ShipDate.

Tu je definícia mierky Orders. Jednoducho spočíta riadky tabuľky Sales v rámci kontextu filtra. Všetky filtre použité v tabuľke Date sa rozšíria do stĺpca OrderDate.

Orders = COUNTROWS(Sales)

Tu je definícia mierky Orders Shipped. Používa funkciu USERELATIONSHIP jazyka DAX, ktorá aktivuje šírenie filtra pre konkrétny vzťah, ale len počas vyhodnocovania výrazu. V tomto príklade sa používa vzťah k stĺpcu ShipDate.

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

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

diagram znázorňujúci stranu zostavy s jedným rýchlym filtrom a vizuálom tabuľky. Rýchly filter je Štvrťrok a vo vizuáli tabuľky sa uvádzajú mesačné štatistiky predaja.

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 Orders a Orders Shipped majú rôzne výsledky. Každá z nich používa rovnakú logiku súhrnu (počet riadkov tabuľky Sales), ale rôzne Date šírenie filtra tabuľky.

Všimnite si, že rýchly filter štvrťroka obsahuje možnosť PRÁZDNE. Táto možnosť rýchleho filtra sa zobrazí ako výsledok rozšírenia tabuľky. Hoci každý Sales riadku tabuľky má platný dátum objednávky, niektoré riadky majú 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).

Nota

Filtre zabezpečenia na úrovni riadkov sa šíria len prostredníctvom aktívnych vzťahov. Filtre zabezpečenia na úrovni riadkov sa pre neaktívne vzťahy nikdy nešíria, dokonca ani vtedy, ak je funkcia DAX USERELATIONSHIP použitá definíciou mierky.

Odporúčania

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í zohrávať roly definovať jeden alebo viac neaktívnych vzťahov. Tento prístup môžete zvážiť 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.

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