Udvidede tabeller i LuckyTemplates

I denne vejledning skal vi tage et kig på et meget specifikt scenarie, som jeg er sikker på, at I alle allerede er stødt på, mens I arbejdede med DAX – den udvidede tabel . Udvidede tabeller kan ødelægge din beregning, hvis du ikke ved, hvordan de rent faktisk fungerer. Du kan se den fulde video af denne tutorial nederst på denne blog.

Til dette eksempel bruger vi Contoso-databasen, som indeholder salgstabellen , kundetabel , datotabel , produkttabel , produktkategoritabel og produktunderkategoritabel .

I venstre ende har vi et-til-mange forhold mellem produkter, kategori, underkategori og salgstabeller. Vi har også en-til-mange forhold mellem kunde og salg, samt datoer og salg.

Indholdsfortegnelse

• Eksempel #1
• Eksempel #2
• Rødt salg #1
• Rødt salg #2
• Rødt salg #3
• Bekræftelse af udvidede tabeller
• Definition af udvidede tabeller
• Skæring af kategorikolonnen og brug af udvidede tabeller
• Forklaring af rødt salg 2
• Forklaring af rødt salg 3
• Brug af DAX Studio til at bekræfte udvidede tabeller
• Konklusion

Eksempel #1

Lad os sige, at vi vil lave en rapport fra denne kategorikolonne i kategoritabellen, og bruge et mål, som beregner, hvor mange kunder der er i kundetabellen. Vi ønsker at opdele nummeret til kundens bord efter kategori.

Hvis jeg sætter et filter på kategoritabellen, vil det filter gå til underkategoritabellen, derefter vil det nå produkttabellen, og til sidst vil det nå og filtrere salgstabellen. Men det filter vil ikke være i stand til at filtrere kundens tabel, medmindre vi slår tovejsfiltreringen til.

Lad os gå tilbage til rapporten for at rette denne beregning. Vi kan pakke denne beregning ind i funktionen CALCUATE og derefter skrive Sales. Vi kan se, at vi denne gang ikke gentager det samme tal for hver celle i det visuelle.

For at kontrollere, om denne beregning er korrekt, kan vi hente kundenøglen fra salgstabellen for at aggregere, og derefter foretage en optælling (Distinct) over det.

Du kan se, at vi returnerer den samme værdi for hver række. Ved at bruge salgstabellen inde i BEREGN-funktionen var vi i stand til at rette beregningen.

Eksempel #2

Lad os gå videre til næste eksempel. For denne ønsker vi at identificere salgsbeløbet for de røde produkter i 2007, 2008 eller 2009. Afhængigt af valget af skæremaskinen vil jeg også gå et år tilbage.

For eksempel, hvis jeg vælger 2009, vil jeg rapportere det røde salg for 2008. Hvis jeg vælger 2008, vil jeg også rapportere det røde salg for 2007.

Rødt salg #1

Beregningen af ​​vores samlede salg er som udgangspunkt en sum af salgsdataene. I rækkesammenhæng skal vi gange mængden med nettoprisen.

Lad os oprette et nyt mål og navngive det som Red Sales. Vi skal skrive BEREGN og derefter Salg i alt. Vi går til salgstabellen for at vise, at produkternes farve er lig med rød.

Så vil vi skrive over datoerne i datokolonnen.

Når vi bringer den udregning i et kortvisuelt, får vi en blank.

Rødt salg #2

Hvad sker der her? Lad os prøve at omskrive den beregning og se, om vi er i stand til at få et resultat. Vi vil oprette et nyt mål og navngive det som Red Sales 2 og bruge den første del af beregningen for Red Sales 1.

Vi vil igangsætte endnu en CALCUATE i løbet af den første CALCUATE.

Lad os bringe dette mål i matricen og se resultaterne. Hvis vi vælger 2008, får vi 51.947. Hvis vi vælger 2009, får vi 24.343. Til sidst, hvis vi vælger 2010, får vi 39.724.

Rødt salg #3

Der er en anden måde at skrive denne beregning på. Vi skriver et nyt mål og kalder det Red Sales 3, og brug derefter funktionen CALCUATE.

Vi skal beregne det samlede salg og skrive, at for produkterne er farven lig med rød. Brug derefter SAMEPERIODLASTYEAR-funktionen på datoerne.

Hvis vi trækker mål #3 ind i kortets visualisering, kan du se, at disse to kortværdier returnerer den samme værdi, hvilket er korrekt.

Men der er noget galt med vores første beregning, fordi vi returnerer en blank og ikke den korrekte værdi.

Lad os se, hvad der rent faktisk sker her. Nu hvor vi har set et par beregninger på udvidede tabeller, lad os forstå teorien bag dem.

Før du forstår, hvad en udvidet tabel er, skal du forstå, at alle de tabeller, vi har her, kaldes basistabeller .

Så hvornår bliver disse tabeller udvidede tabeller? Når du har oprettet et mange-til-en-forhold mellem en tabel og en anden tabel, bliver basistabellen den udvidede tabel.

Bekræftelse af udvidede tabeller

Men hvordan kan vi verificere, at en tabeludvidelse rent faktisk sker? Nå, du kan bruge det relaterede søgeord på enhver tabel. Hvis du er i stand til at få adgang til kolonnen fra den ene side, vil du vide, at en tabeludvidelse kan ske.

Lad os gå til salgstabellen og oprette en ny beregnet kolonne.

Lad os sige, at vi ønsker at hente produktfarven fra produkttabellen for netop denne produktnøgle. Vi bruger RELATED, som kun vil give listen over kolonner i IntelliSense, som faktisk kan udvides fra salgstabellen.

Vi kan se, at kundebordet og salgsbordet har et mange-til-en forhold. Vi kan også se listen over kundetabelkolonner, datotabelkolonner og produktkolonner.

Når vi vælger Produkter[Farve], kan vi oprette en ny kolonne i salgstabellen ved hjælp af det RELATEDE søgeord. RELATED giver os kun adgang til kolonnerne i tabellen, som basistabellen faktisk kan udvides til.

Hvis vi ændrer karakteren af ​​det forhold fra mange-til-en til mange-til-mange, vil den beregning holde op med at virke.

Lad os ændre karakteren af ​​dette forhold til mange-til-mange. Vi kan se i bunden, at vi får et advarselssymbol.

Når vi går tilbage til salgstabellen, ser vi fejlmeddelelsen, der siger, at kolonnen Produkter[Farve] enten ikke eksisterer eller ikke har en relation til nogen tabel.

I den nuværende sammenhæng er den advarsel, vi får, ikke særlig brugervenlig. Grundlæggende betyder det, at salgstabellen ikke kan udvides til produkttabellen, fordi vi ikke kun har adgang til én enkelt værdi for den pågældende rækkevare.

Og da vi bruger mange-til-mange-relationen, sker tabeludvidelsen ikke, og RELATED virker ikke.

Lad os gå tilbage til diagramvisningen og rette denne beregning. Vi ændrer karakteren af ​​forholdet til mange-til-en og aktiverer dette forhold for at få beregningen til at fungere.

Definition af udvidede tabeller

Før vi begynder at se på de beregninger, som vi allerede har lavet i rapporten, lad os gentage definitionen af ​​den udvidede tabel.

Hvis du har en datamodel med et stjerneskema , udvides faktatabellen til alle tabellerne i datamodellen, hvis der er en mange-til-en-relation mellem dimensionerne og faktatabellen.

Hvis du har et snefnugskema , så udvides produktunderkategoritabellen og kategoritabellen til basistabellen, som i dette tilfælde er produkttabellen. Salgsbordet er basisbordet, som udvides til alle de andre borde.

Bag scenen vil salgstabellen have alle kolonnerne i én enkelt tabel. Bemærk, at tabeludvidelse kun er et logisk koncept, så det kommer ikke til at udvide og øge størrelsen af ​​din datamodel.

Den udvidede tabel kommer kun ind i billedet, når du refererer til en tabel (som er basistabellen), og når du har et mange-til-en forhold til andre tabeller.

Skæring af kategorikolonnen og brug af udvidede tabeller

Lad os prøve at rette de beregninger, vi allerede har lavet i rapportvisningen. I dette eksempel skærer vi efter kategorikolonnen fra produktkategoritabellen, og vi forsøger at tælle, hvor mange kunder der er.

Så hvad laver vi egentlig her? Vi bruger den udvidede salgstabel som reference. Når filterkonteksten indeholder en værdi fra kategoritabellen, vil filteret nå salgstabellen fra underkategorien produkter og direkte til salget.

Da salg er en udvidet tabel, og vi bruger denne reference inde i CALCUATE-funktionen, vil salgstabellen også indeholde kolonnen i kundetabellen. Når vi indirekte anvender et filter over salgstabellen, filtrerer vi også kundetabellen.

Lad os gå tilbage til vores røde salgsberegninger og prøve at forstå, hvad der rent faktisk sker. Vi starter med den tomme beregning. Hvis vi vælger det mål, kan du se, at vi skriver en indlejret kode. Vi har BEREGNET, derefter det samlede salg, FILTER over salget og SAMEPERIODLASTÅR.

Lad os bryde den beregning trin for trin. Først skal vi identificere den eksterne filterkontekst, der eksisterer ud af beregningen.

Vi har valgt 2008 i sliceren for kalenderårstal.

Fra denne filterkontekst vil salgstabellen blive evalueret. Salgstabellen vil kun indeholde rækken for kalenderårsnummeret 2008, og produktfarven vil være rød. Vi har to filtre her: et, der oprettes af filterkonteksten , og et, der bliver oprettet af filteret .

SAMEPERIODLASTYEAR bliver evalueret i filterkonteksten, hvor året er 2008. Det vil modtage en liste over datoer i 2008, og det vil flytte disse datoer i 2008 til 2007. Tabellen, der vil blive returneret af dette, vil kun indeholde datoerne for 2007.

Når disse to operationer er afsluttet, forbereder funktionen CALCULATE filterkonteksten og anvender disse to filtre i filterkonteksten. Når vi anvender det, har vi en filterkontekst, hvor produktfarven er lig med rød, og på kolonnen år har vi et filter over 2007 og 2008.

Så for denne datamodel er der ingen enkelt transaktion, der eksisterer i to forskellige år. Når CALCULATE forsøger at slå disse to filtre sammen i en og- tilstand, vil der stå, at året skal være 2008 og 2007, og at produktfarven skal være rød.

Når vi filtrerer salgstabellen med filterkonteksten fra år 2008, filtrerer vi også indirekte datotabellen. Salgsstalden har et forhold på mange-til-en til datostabiliteten.

Lad os lave en ny beregning for at identificere, hvor mange rækker der er i datotabellen for de relaterede datoer. Vi kommer til at skrive CALCUATE, derefter af datotabellen. Så vil vi FILTRERE HELE salgstabellen, og vi vil sige, at de RELATEREDE datoer i kalenderårsnummeret skal være lig med 2008.

Inde i CALCUATE har vi ikke henvist til noget filter over datotabellen. Vi tjekker blot, at datoerne i kalenderårsnummeret skal være fra 2008. Ideelt set skulle dette filter ikke kunne filtrere datotabellen. Vi bruger også funktionen, som vil ignorere filterkonteksten, der kommer fra udsnitteren.

Lad os oprette et nyt kort til denne beregning. du kan se, at vi returnerer 348 rækker.

Så hvordan er det muligt, at vi fra en datotabel med 2500 rækker kun returnerer 348 rækker? Hvis vi skal bruge en udvidet tabel, vil vi også indirekte filtrere den anden tabel, som er forbundet gennem en mange-til-en-relation.

Selvom vi ikke har noget filter i løbet af det aktuelle år, begrænser vi stadig antallet af rækker, der er synlige for den dimensionstabel, vi har på den ene side.

Når vi returnerer salgstabellen, returnerer vi også en filtreret version af datotabellen, kundetabellen, produkttabellen, produktkategoritabellen og produktunderkategoritabellen.

Forklaring af rødt salg 2

Lad os gå videre til den næste beregning, som er Red Sales 2. Vi starter med den ydre CALCUATE, fordi hvis vi indlejrer denne funktion i ethvert scenarie, skal den ydre CALCUATE forberede filterkonteksten til den indre CALCUATE.

På sliceren vælger vi kalenderåret 2008. Når SAMEPERIODLASTYEAR-funktionen får datoen for 2008, vil den flytte disse datoer i 2007, og det vil være FILTER-konteksten for den indre beregning. Denne indre CALCUATE vil evaluere året 2007.

FILTER-funktionen vil filtrere salgstabellen, og salgstabellen vil kun være begrænset for rækken, hvor året er 2007. Når vi har rækkerne for 2007, skal vi kontrollere, at de relaterede produkter er lig med rød.

I modsætning til den første beregning returnerer vi ikke to forskellige niveauer. Disse to forskellige niveauer bliver ikke anvendt på FILTER-konteksten, så tabellen returneret af FILTER-funktionen vil indeholde hele rækken i salgstabellen.

Når dette filter er anvendt, vil vi få salgsbeløbet for år 2007, samt de produkter, der er lig med rødt, mens vi i den første beregning returnerede år 2008 og 2007.

Denne gang har vi forberedt filterkonteksten for salgstabellen ved at bruge SAMEPERIODLASTYEAR-funktionen og ved at indlejre CALCULATE-funktionen i en anden CALCULATE.

Forklaring af rødt salg 3

For det tredje eksempel har vi en meget simpel CALCUATE-funktion med to udsagn: den ene er produktfarve er lig med rød, og derefter SAMEPERIODLASTYEAR på datoer.

SAMEPERIODLASTYEAR-funktionen vil blive evalueret i en filterkontekst, som kun vil indeholde datoerne fra 2007. Produkternes farve vil anvende en filterkontekst med rød over produkttabellen, som igen vil filtrere salgstabellen og kun indeholde rækkerne for de røde produkter.

Når disse to værdier anvendes i filterkonteksten, vil de filtrere salgstabellen, men ikke den udvidede salgstabel. du kan se, at ingen steder i koden henviste vi til den udvidede salgstabel.

Dette er det ideelle scenarie, som du bør bruge, hvis du forsøger at referere til den udvidede tabel. Når du bruger den udvidede tabel, kan beregningerne blive virkelig indviklede, og nogle gange er du ikke i stand til at identificere, hvorfor dine beregninger giver et forkert resultat.

Hvis du ikke forstår konceptet med udvidede tabeller, kan du udvikle denne særlige kode som en modelforanstaltning og derefter implementere den i produktionen. Andre brugere begynder måske at lave andre mål over denne foranstaltning, og de kan måske ikke finde ud af, hvorfor beregningerne ikke virker, fordi de ikke blot har det niveau af forståelse for DAX-sproget.

Hvis du arbejder med DAX, så prøv altid at placere filteret over en enkelt kolonne, fordi når du bruger en enkelt kolonne, anvendes konceptet med udvidede tabeller ikke. Når du f.eks. bruger PRODUKTER [Farve] = "Rød" , når filteret salgstabellen, men det filter kan ikke nå kundens tabel, fordi vi ikke bruger den udvidede salgstabel.

Når vi bruger en enkelt kolonne, henviser vi ikke til begrebet udvidede tabeller. Vi anvender blot et grundlæggende filter over salgstabellen, som ikke forplanter sig til de andre tabeller.

Brug af DAX Studio til at bekræfte udvidede tabeller

Inden vi afslutter, skal vi bruge DAX studio til at bekræfte vores kode til Red Sales 3. Lad os gå til fanen Vis, klik på Performance Analyzer, og start derefter optagelsen. Vi opdaterer det visuelle billede og vælger et tomt kort.

Fra de eksterne værktøjer vil vi lancere DAX studio

Vi kan se, at i resultatskærmen nederst, får vi en tom.

Vi slår Server Timings til for at forstå de forespørgsler, der genereres bag scenen. Vi går til fanen Server Timings og udvider den for at se alt.

Vi udfører en JOIN på salgsbordet i venstre side. Vi udfører også en JOIN på produktnøglen fra produkttabellen.

I WHERE-klausulen står der, at datoerne i kalenderårsnummeret skal være lig med 2008, og at produktfarven skal være rød.

Så har vi en anden betingelse, som siger Datoer[Dato], derefter efterfulgt af et datointerval. Så hvad er disse datoer? Ideelt set skal disse datoer tilhøre 2008, men de er fra 2007, når vi ændrer formateringen af ​​disse tal i Excel.

Det er derfor, vi returnerer en tom værdi. Vi siger, at kalenderåret skal være 2008 og anvender en OG-betingelse om, at datoerne skal være i 2007. Dette 2007 er på grund af SAMEPERIODLASTYEAR-funktionen, vi brugte i beregningen.

Lad os ændre mål og reference til Red Sales 2. Når vi udfører koden, kan du se, at vi får datoerne fra datotabellen, så filtrerer vi datokolonnen for kalenderårsnummeret 2008.

Denne gang er vi i stand til at returnere et resultat, fordi vi ikke anvender et filter på WHERE-sætningen, og vi siger, at datoerne i kalenderårstallet skal være lig med 2008.

Konklusion

Forhåbentlig var denne tutorial nyttig til at forstå, hvad en udvidet tabel er, og hvordan den kan ødelægge dine beregninger. Udvidede tabeller er ikke rigtig intuitive, og de er heller ikke nemme at forstå.

For mere information om udvidede borde, glem ikke at abonnere på LuckyTemplates tv-kanal. Vi har en enorm mængde indhold, der kommer ud hele tiden fra mig selv og en række indholdsskabere, alle dedikeret til at forbedre den måde, du bruger LuckyTemplates og Power Platform på.