Design skalerbare beregninger

Modellen din er strukturert. Nå designer du beregningene som holder den ytelsesdyktig og vedlikeholdbar etter hvert som dataene og teamet ditt vokser. I liten skala fungerer en modell med dupliserte mål og inkonsekvent navngivning fortsatt, selv om det ikke er ideelt. I stor skala går den i stykker. En modell med hundrevis av målinger krever strukturelle designbeslutninger som forhindrer duplisert logikk, reduserer spørringstiden på store datasett og gjør det mulig for nye teammedlemmer å forstå og utvide modellen uten å introdusere feil.

Denne enheten dekker tre mønstre: beregningsgrupper for å redusere målspredning, DAX-lesbarhetsdisiplin for teamvedlikehold, og aggregeringer for spørringsytelse på store faktatabeller.

Beregningsgrupper

Beregningsgrupper er modellobjekter som anvender det samme beregningsmønsteret på flere mål. I stedet for å lage separate takter for hver variasjon, definerer du mønsteret én gang og anvender det dynamisk.

Problemberegningsgruppene løser

Tenk på en organisasjon med 50 basismål (som totalsalg, total kostnad, fortjeneste og solgte enheter). Hver måling krever beregninger for år-til-dato, kvartal-til-dato og måned-til-dato. Uten beregningsgrupper er det 50 × 3 = 150 ekstra mål. Legg til sammenligninger fra tidligere år, og du ser på 250+ mål å opprettholde.

Med beregningsgrupper oppretter du én gruppe med beregningselementer for hvert tidsintelligensmønster. Disse elementene gjelder automatisk for alle mål i modellen.

Hvordan beregningsgrupper fungerer

En beregningsgruppe inneholder beregningselementer, hvor hver definerer et DAX-uttrykk som endrer det nåværende målet ved hjelp av SELECTEDMEASURE(). Her er en gruppe for tidsintelligens-beregning:

// Year-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD('Date'[Date])
)

// Quarter-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESQTD('Date'[Date])
)

// Month-to-Date
CALCULATE(
    SELECTEDMEASURE(),
    DATESMTD('Date'[Date])
)

Når en bruker legger til beregningsgruppen i et visuelt format, kan de bytte mellom YTD, QTD og MTD for hvilken som helst måling (som totalsalg, fortjeneste eller solgte enheter) uten separate mål for hver kombinasjon.

Dynamiske formatstrenger

Dynamiske formatstrenger endrer visningsformatet basert på konteksten for beregningsobjektet. For eksempel bør en prosentberegning vises som en prosentandel, mens valutaberegninger skal vises som valuta, selv når den brukes på samme basismål.

// In the format string expression for a YoY % calculation item:
"0.0%"

Dynamiske formatstrenger reduserer behovet for separate formaterte mål og holder formateringen konsistent på tvers av modellen.

Når skal man bruke beregningsgrupper

Bruk beregningsgrupper når du har tre eller flere mål som trenger samme beregningsmønster. Vanlige bruksområder inkluderer tidsinnsikt (YTD, QTD, MTD), valutakonvertering og variansberegninger (faktisk vs. budsjett).

DAX lesbarhetsdisiplin

I stor skala med et team som opprettholder 200+ målinger, er lesbarhet et designvalg, ikke en personlig preferanse. Konsistent, lesbar DAX reduserer vedlikeholdsfeil og gjør det enklere for nye teammedlemmer å forstå modellen.

Variabler

Variabler lagrer mellomliggende resultater, forbedrer lesbarheten, og forhindrer at motoren evaluerer det samme uttrykket flere ganger:

Profit Margin =
VAR TotalRevenue = SUM(Sales[Revenue])
VAR TotalCost = SUM(Sales[Cost])
VAR ProfitAmount = TotalRevenue - TotalCost
RETURN
    DIVIDE(ProfitAmount, TotalRevenue)

Uten variabler kan det samme SUM(Sales[Revenue]) uttrykket forekomme tre ganger i et komplekst mål. Variabler evaluerer uttrykket én gang og gjenbruker resultatet.

Navnekonvensjoner

Konsistent navngivning er avgjørende når modellen din har hundrevis av målinger som vedlikeholdes av flere personer. Etabler konvensjoner for:

• Mål navn: Bruk klare, beskrivende navn som «Total Sales» eller «YoY Revenue Growth». Unngå forkortelser som bare den opprinnelige forfatteren forstår.
• Variabelnavn: Bruk beskrivende navn som forklarer mellomverdien (for eksempel TotalRevenue i stedet for x eller temp).
• Beregningsgruppeelementer: Navngi elementer etter hva de gjør, ikke hvordan de fungerer (for eksempel "Year-to-Date" i stedet for "DATESYTD Wrapper").

Beskrivende navngivning har også betydning for AI-forbruket. Når Copilot eller en dataagent spør modellen din, bruker den målnavn og beskrivelser for å avgjøre hvilke beregninger som skal inkluderes. Et mål kalt «YoY Revenue Growth» gir bedre AI-resultater enn «Calc7_v2».

Iteratorer vs. aggregeringsfunksjoner

Iteratorfunksjoner (SUMX, AVERAGEX, ) MAXXevaluerer et rad-for-rad-uttrykk over en tabell. Aggregeringsfunksjoner (SUM, AVERAGE, ) MAXopererer på én enkelt kolonne. Ved store datavolumer er valget viktig:

• Bruk aggregeringsfunksjoner når du oppsummerer en enkelt kolonne. De er raskere fordi motoren kan bruke forhåndsbygde datastrukturer.
• Bruk iteratorer når beregningen krever et radnivåuttrykk (for eksempel Quantity × UnitPrice per rad).

Informasjonsfunksjoner for forsvarsmønstre

Informasjonsfunksjoner som ISBLANK, HASONEVALUE, og ISINSCOPE lager forsvarsmønstre for mål som brukes av flere rapporter med ulike filterkontekster:

Sales per Customer =
IF(
    HASONEVALUE(Customer[CustomerID]),
    DIVIDE(SUM(Sales[Amount]), 1),
    DIVIDE(SUM(Sales[Amount]), DISTINCTCOUNT(Sales[CustomerID]))
)

Disse mønstrene forhindrer uventede resultater når målinger brukes i sammenhenger den opprinnelige forfatteren ikke hadde forutsett.

Aggregeringer

Aggregeringer er sammendragstabeller som lagrer forhåndsberegnede totaler med høyere korn enn detaljdataene. Spørringene treffer disse tabellene først, noe som forbedrer ytelsen på store faktatabeller. Når en spørring matcher en aggregering, returnerer motoren resultater fra den mindre oppsummeringstabellen i stedet for å skanne millioner av detaljrader.

Aggregeringer som en designbeslutning

Å bestemme når aggregeringer skal legges til og hvor detaljert det er, er en designbeslutning. Ytelsesovervåking og tuning er separate operative bekymringer, men du tar det strukturelle valget under modelldesignet.

Vurder aggregering når:

• Faktatabeller overstiger millioner av rader, og vanlige spørringer oppsummerer data med høyere korn (som månedlige totaler etter region).
• Brukere opplever trege svartider på oppsummeringsnivå-visualiseringer.
• De fleste rapportinteraksjoner trenger ikke radnivå-detaljer.

Hvordan aggregeringsatferd varierer mellom lagringsmodus

I importmodus lagres aggregeringer som separate skjulte tabeller. Motoren ruter automatisk matchende spørringer til aggregeringstabellen.

I Direct Lake-modus kan Delta-tabellene selv fungere som aggregeringskilder. Fordi Direct Lake leser kolonneformede Parquet-filer, kan motoren håndtere større datavolumer uten aggregeringer i mange scenarioer. Legg til aggregeringer kun når spørringsmønstre bekrefter behovet.