Aktiivisten ja passiivisten suhteiden ohjeet
Tämä artikkeli koskee tietojen mallintajaa, joka käsittelee Power BI Desktopia. Artikkelissa on ohjeita siitä, milloin tulee luoda aktiivisia tai passiivisia mallisuhteita. Oletusarvon mukaan aktiiviset suhteet levittävät suodattimia muihin taulukoihin. Passiivinen suhde kuitenkin levittää suodattimia vain, kun DAX-lauseke aktivoi suhteen (käyttää suhdetta).
Muistiinpano
Tämä artikkeli ei johdata malliyhteyksiin. Jos et ole täysin perehtynyt suhteisiin, niiden ominaisuuksiin tai niiden määrittämiseen, suosittelemme, että luet ensin Mallien suhteet Power BI Desktopissa -artikkelin.
On myös tärkeää, että ymmärrät tähtirakenteen suunnittelun. Lisätietoja on kohdassa Tutustu tähtirakenteeseen ja sen merkitykseen Power BI:ssä.
Aktiiviset suhteet
Yleensä suosittelemme aktiivisten suhteiden määrittämistä aina kun mahdollista. Ne laajentavat mallisi käyttöaluetta ja mahdollisuuksia, joita raportin tekijät sekä Q&A:n kanssa työskentelevät käyttäjät voivat käyttää.
Otetaan esimerkiksi tuontimalli, joka on suunniteltu analysoimaan lentoyhtiön lennonaikaista suoritustehoa (OTP). Mallilla on faktatyyppinen Flight-taulukko , joka tallentaa yhden rivin kutakin lentoa kohti. Kullakin rivillä on kirjaa lennon päivämäärä, lennon numero, lähtö- ja saapumislentokenttä sekä mahdollinen viiveaika (minuutteina). Lisäksi dimensiotyyppisessä Airport-taulukossa on yksi rivi kutakin lentokenttää kohti. Kullakin rivillä on lentokentän koodi, lentokentän nimi sekä maa tai alue.
Tässä on kahden taulukon osittainen mallikaavio.
Flight- ja Airport-taulukoiden välillä on kaksi mallisuhdetta. Flight-taulukossa DepartureAirport- ja ArrivalAirport-sarakkeet liittyvät Airport-taulukon Airport-sarakkeeseen. Tähtirakenteessa Airport-taulukko kuvataan rooliulottuvuudeksi. Tässä mallissa kaksi roolia ovat departure airport (lähtökenttä ) ja arrival airport (kohdekenttä).
Tämä rakenne toimii hyvin suhteellisten tähtirakenteiden suunnittelussa, mutta ei Power BI -malleissa. Mallisuhteet ovat nimittäin suodattimen levittämispolkuja, ja polkujen on oltava deterministisiä. Lisätietoja siitä, että suodattimien levityspolut ovat deterministisiä , on artikkelissa Yhteyspolun moniselitteisyyden ratkaiseminen. Näin ollen – kuten tässä esimerkissä on kuvattu – yksi suhde on aktiivinen, kun taas toinen on passiivinen (esitetään katkoviivana). Aktiivisena on suhde ArrivalAirport-sarakkeeseen . Tämä tarkoittaa sitä, että Airport-taulukkoon käytetyt suodattimet leviävät automaattisesti Flight-taulukon ArrivalAirport-sarakkeeseen.
Tähän mallirakenteeseen liittyy vakavia rajoituksia sen mukaan, miten tietoja voidaan raportoida. Erityisesti ei ole mahdollista suodattaa Airport-taulukkoa niin, että se automaattisesti eristäsi lähtölentokentän lentotiedot. Koska raportointivaatimuksiin sisältyy suodattaminen (tai ryhmittely) lähtö- ja saapumislentokenttien mukaisesti samaan aikaan, tarvitaan kaksi aktiivista suhdetta. Tämän vaatimuksen kääntäminen Power BI -mallirakenteena tarkoittaa sitä, että mallissa on oltava kaksi lentokenttätaulukkoa.
Tässä on paranneltu mallirakenne.
Mallissa on nyt kaksi lentokenttätaulukkoa: Departure Airport ja Arrival Airport. Näiden taulukoiden ja Flight-taulukon väliset mallisuhteet ovat aktiivisia. Huomaa myös, että Departure Airport- ja Arrival Airport -taulukoiden sarakenimissä on etuliitteenä sana Departure tai Arrival.
Paranneltu mallirakenne tukee seuraavan raporttimallin tuottamista.
Raporttisivu on suodatettu niin, että lähtökenttänä on Melbourne, ja taulukon visualisointi ryhmittelee tiedot kohdelentokenttien mukaan.
Muistiinpano
Tuontimalleissa lisätaulukko on kasvattanut mallin kokoa ja pidentänyt päivitysaikoja. Näin ollen se on ristiriidassa niiden suositusten kanssa, jotka on kuvattu artikkelissa Tietojen vähentämisen tekniikat tuonnin mallinnusta varten. Tässä esimerkissä vaatimus vain aktiivisten suhteiden esittämisestä kuitenkin ohittaa nämä suositukset.
On myös yleistä, että dimensiotyyppisten taulukoiden rivimäärä on vähäinen suhteessa faktatyyppisten taulukoiden rivimääriin. Niinpä kasvanut mallin koko ja pidentyneet päivitysajat eivät todennäköisesti ole vielä kohtuuttoman suuria.
Muodostamismenetelmät
Tässä on menetelmä, jolla voidaan muodostaa malli yhdestä rooliulottuvuustyyppisestä taulukosta rakenteeseen, jossa on yksi taulukko roolia kohden.
Poista passiiviset yhteydet.
Harkitse rooliulottuvuustyyppisen taulukon nimeämistä uudelleen, niin että sen rooli kuvataan paremmin. Esimerkissä Airport-taulukko liittyy Flight-taulukon ArrivalAirport-sarakkeeseen, joten taulukon nimeksi annetaan Arrival Airport.
Luo kopio roolitaulukosta ja anna sille sen roolia vastaava nimi. Jos kyseessä on tuontitaulukko, suosittelemme lasketun taulukon määrittämistä. Jos kyseessä on DirectQuery-taulukko, voit monistaa Power Query -kyselyn.
Esimerkissä Departure Airport - taulukko luotiin käyttämällä seuraavaa lasketun taulukon määritystä.
Departure Airport = 'Arrival Airport'Luo aktiivinen suhde, joka yhdistää uuden taulukon.
Harkitse taulukoiden sarakkeiden nimeämistä uudelleen niin, että ne vastaavat sarakkeiden roolia. Esimerkissä kaikkien sarakkeiden etuliitteenä on sana Departure tai Arrival. Näiden nimien ansiosta raportin visualisoinneilla on oletusarvoisesti kuvaavat ja yksiselitteiset otsikot. Se myös parantaa Q&A-käyttökokemusta, jolloin käyttäjät voivat kirjoittaa kysymyksensä helposti.
Harkitse kuvausten lisäämistä roolitaulukoihin. (Kohdassa Kentät-ruudussa kuvaus tulee näkyviin työkaluvihjeessä, kun raportin tekijä siirtää kohdistimen taulukon päälle.) Näin voit välittää suodattimien lisätiedot raportin tekijöille.
Passiiviset yhteydet
Tietyissä tilanteissa passiiviset yhteydet voivat vastata raportoinnin erityisiin tarpeisiin.
Ajatellaan nyt toisenlaisia malli- ja raportointivaatimuksia:
- Myyntimalli sisältää Sales-taulukon, jossa on kaksi päivämääräsaraketta: OrderDate ja ShipDate
- Kukin Sales-taulukon rivi sisältää yhden tilauksen.
- Päivämääräsuodattimia käytetään lähes aina OrderDate-sarakkeeseen , joka tallentaa aina kelvollisen päivämäärän
- Vain yksi mittari edellyttää päivämääräsuodattimen levittämistä ShipDate-sarakkeeseen , joka voi sisältää tyhjiä kohtia (kunnes tilaus on lähetetty)
- Tilaus - ja lähetyspäivämääräjaksojen perusteella ei tarvitse samanaikaisesti suodattaa (tai ryhmitellä)
Tässä on kahden taulukon osittainen mallikaavio.
Myynti- ja Päivämäärä-taulukoiden välillä on kaksi mallisuhdetta. Sales-taulukossa OrderDate- ja ShipDate-sarakkeet liittyvät Date-taulukon Date-sarakkeeseen. Tässä mallissa Date-taulukon kaksi roolia ovat tilauspäivämäärä ja lähetyspäivämäärä. Suhde OrderDate-sarakkeeseen on aktiivinen.
Kaikki kuusi mittaria – yhtä lukuun ottamatta – on suodatettava OrderDate-sarakkeen mukaan. Orders Shipped -mittari on kuitenkin suodatettava ShipDate-sarakkeen mukaan.
Tässä on Orders-mittarin määritys. Se vain laskee Sales-taulukon rivit suodatinkontekstin mukaan. Kaikki Date-taulukkoon käytetyt suodattimet leviävät OrderDate-sarakkeeseen.
Orders = COUNTROWS(Sales)
Tässä on Orders Shipped -mittarin määritys. Se käyttää DAX-funktiota USERELATIONSHIP , joka aktivoi suodattimen leviämisen tietyssä suhteessa vain lausekkeen arvioinnin aikana. Tässä esimerkissä käytetään suhdetta ShipDate-sarakkeeseen.
Orders Shipped =
CALCULATE(
COUNTROWS(Sales)
,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)
Tämä mallirakenne tukee seuraavan raporttimallin tuottamista.
Raporttisivu suodattuu vuosineljänneksen 2019 Q4 mukaan. Taulukon visualisointi ryhmittelee kuukauden mukaan ja näyttää useita myyntitilastoja. Orders- ja Orders Shipped -mittarit tuottavat erilaisia tuloksia. Ne käyttävät samaa yhteenvetologiikkaa (Sales-taulukon rivien laskeminen), mutta erilaista Date-taulukon suodatuksen levittämistä.
Huomaa, että vuosineljänneksen osittaja sisältää tyhjän kohteen. Tämä osittajakohde tulee näkyviin taulukon laajennuksen seurauksena. Kullakin Sales-taulukon rivillä on tilauspäivämäärä, mutta joillakin riveillä on tyhjä lähetyspäivämäärä – näitä tilauksia ei vielä ole lähetetty. Taulukon laajennus ottaa huomioon myös passiiviset yhteydet, joten tyhjiä kohtia saattaa ilmestyä, jos suhteessa on monta puolta tai jos tiedoissa on eheysongelmia.
Muistiinpano
Rivitason suojauksen suodattimet leviävät vain aktiivisten suhteiden kautta. Rivitason suojauksen suodattimet eivät leviä passiivisille yhteyksille, vaikka UseRelationship lisäisiin eksplisiittisesti mittarimääritykseen.
Suosituksia
Yhteenvetona suosittelemme aktiivisten suhteiden määrittämistä aina kun mahdollista, erityisesti silloin, kun tietomallillesi on määritetty rivitason käyttöoikeusrooleja. Ne laajentavat mallisi käyttöaluetta ja mahdollisuuksia, joita raportin tekijät sekä Q&A:n kanssa työskentelevät käyttäjät voivat käyttää. Tämä tarkoittaa sitä, että rooliulottuvuustyyppiset taulukot tulee kahdentaa mallissasi.
Tietyissä tilanteissa voit kuitenkin määrittää yhden tai useamman passiivisen suhteen rooliulottuvuustyyppiselle taulukolle. Voit harkita tätä rakennetta seuraavassa:
- Raportin visualisointien ei tarvitse samanaikaisesti suodattua eri roolien mukaan
- Käytät DAX-funktiota USERELATIONSHIP aktivoidaksesi tietyn suhteen asiaan liittyville mallin laskutoimituksille.
Liittyvä sisältö
Saat lisätietoja tähän artikkeliin liittyen tutustumalla seuraaviin resursseihin: