Torsdag formiddag. CFO'en:
"Smukt - nu vil jeg se omsætningen brudt ned på produktkategori. Audio, Ergonomi, Software. Kan jeg få det i en søjle?"
Du tænker: "Selvfølgelig - drag-and-drop." Du trækker Produkter[Kategori] ind på x-aksen, Total Omsætning som værdi. Det virker.
Men så får du en idé. Du vil også lave en beregnet kolonne på Salg der viser hvilken kategori hver ordre tilhører - så du kan filtrere ordrerne direkte uden at gå via en relation. Det ville være nemmere i Power Query, men du vil prøve at gøre det i DAX.
Du prøver:
Power BI klager. Fejlmeddelelsen lyder noget i retning af "En enkelt værdi for kolonnen Kategori i tabellen Produkter kan ikke bestemmes."
Det er fordi du står i Salg-tabellen, kigger ud i Produkter, og DAX'en aner ikke hvilken af de 80 produktrækker du mener. Du skal følge relationen.
Det er præcis hvad RELATED gør.
RELATED - opslag på tværs af én-til-mange¶
RELATED er DAX' svar på Excels VLOOKUP - bare uden kolonnenumre, og uden IFERROR. Den bruger relationen du allerede har defineret.
Syntaks¶
Det er det. Du peger på den kolonne i den relaterede tabel du vil hente, og DAX følger automatisk relationen.
Løsningen¶
Vigtigt: Det her er en beregnet kolonne - ikke et mål. Højreklik på Salg-tabellen → Ny kolonne.
For hver række i Salg følger DAX relationen til Produkter, finder den rigtige produktrække (matcher på ProduktID), og henter Kategori.
Hvornår er RELATED uundværlig?¶
I ovenstående eksempel kunne du have klaret dig uden - du kunne trække Produkter[Kategori] ind direkte i visuals. Men RELATED bliver uundværlig inde i SUMX-iterationer.
Husk fra modul 5 vores omsætningsberegning:
Hvad nu hvis du vil bruge produktets listepris i beregningen - fx for at sammenligne den faktiske pris med katalogprisen?
Listepris-Omsætning =
SUMX(
Salg,
Salg[Antal] * RELATED( Produkter[Listepris] )
)
Inde i SUMX' iteration, i hver række af Salg, slår RELATED den rigtige listepris op. Du kunne ikke skrive Produkter[Listepris] direkte - DAX ville ikke vide hvilken række.
Hvornår RELATED ikke virker¶
Forestil dig at du står på Produkter-tabellen (én-siden) og vil hente noget fra Salg-tabellen (mange-siden). Det går ikke med RELATED - der er potentielt mange salgsrækker pr. produkt, så hvilken skulle den vælge?
I det tilfælde har du to muligheder:
- Aggregér via et almindeligt mål:
CALCULATE( SUM( Salg[Antal] ) )påProdukter-tabellen virker, fordi filterkonteksten allerede gør arbejdet. - Brug RELATEDTABLE - som returnerer en tabel af relaterede rækker, ikke en enkelt værdi:
Antal Salg = COUNTROWS( RELATEDTABLE( Salg ) )
| Side du står på | Funktion | Returnerer |
|---|---|---|
Mange-siden (Salg) |
RELATED | En værdi |
Én-siden (Produkter) |
RELATEDTABLE | En tabel |
Almindelig fejl - relationen er inaktiv¶
Power BI tillader flere relationer mellem to tabeller, men kun én kan være aktiv ad gangen. Hvis du har sat to relationer op (fx både OrdreDato og LeveringsDato peger på en kalendertabel), så bruger RELATED automatisk den aktive.
Skal du bruge den inaktive, må du pakke det ind i CALCULATE + USERELATIONSHIP. Det ligger uden for kurset - bare ved at det findes hvis du støder på det.
Øvelse - produktnavn på ordrelinjen¶
Lav en beregnet kolonne på Salg der hedder Produktbeskrivelse og som indeholder produktnavnet sammen med kategorien i formatet "Skærmholder X1 (Ergonomi)".
Løsningsforslag
Produktbeskrivelse =
RELATED( Produkter[Produktnavn] ) & " (" & RELATED( Produkter[Kategori] ) & ")"
To RELATED-opslag, sammenklistret med &-operatoren. Pænt og kort.
Hvad du har lært¶
- RELATED henter en værdi fra én-siden af en relation, set fra mange-siden.
- Den er uundværlig inde i SUMX/AVERAGEX-iterationer, hvor du har brug for opslag pr. række.
- Den modsatte retning kræver RELATEDTABLE eller en aggregering.
Næste problem: CFO'en vil kun se de store handler.