Utforma skalbara beräkningar

Din modell är strukturerad. Utforma nu de beräkningar som håller den högpresterande och underhållsbar när dina data och team växer. I liten skala fungerar fortfarande en modell med duplicerade mått och inkonsekvent namngivning, även om den inte är idealisk. I stor skala går den sönder. En modell med hundratals mått behöver strukturella designbeslut som förhindrar duplicerad logik, minskar frågetiden för stora datamängder och gör det möjligt för nya teammedlemmar att förstå och utöka modellen utan att införa fel.

Den här enheten omfattar tre mönster: beräkningsgrupper för att minska måttspridning, DAX-läsbarhetsdisciplin för att underlätta teamunderhåll, och aggregeringar för frågeprestanda i stora faktatabeller.

Beräkningsgrupper

Beräkningsgrupper är modellobjekt som använder samma beräkningsmönster i flera mått. I stället för att skapa separata mått för varje variant definierar du mönstret en gång och tillämpar det dynamiskt.

Problemberäkningsgrupperna löser

Överväg en organisation med 50 basmått (till exempel Total försäljning, Total kostnad, Vinst och Sålda enheter). Varje mått behöver beräkningar från år till datum, kvartal till datum och månad till datum. Utan beräkningsgrupper är det 50 × 3 = 150 extra mått. Lägg till jämförelser för föregående år så har du över 250 mättal att underhålla.

Med beräkningsgrupper skapar du en grupp med beräkningsobjekt för varje tidsinformationsmönster. Dessa objekt gäller för alla mått i modellen automatiskt.

Så här fungerar beräkningsgrupper

En beräkningsgrupp innehåller beräkningsobjekt som var och en definierar ett DAX-uttryck som ändrar det aktuella måttet med hjälp av SELECTEDMEASURE(). Här är en tidsinformationsberäkningsgrupp:

// 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 användare lägger till beräkningsgruppen i ett visuellt objekt kan de växla mellan YTD, QTD och MTD för valfritt mått (till exempel Total försäljning, Vinst eller Sålda enheter) utan separata mått för varje kombination.

Strängar i dynamiskt format

Dynamiska formatsträngar ändrar visningsformatet baserat på kontexten för beräkningsobjektet. En procentberäkning bör till exempel visas som en procentandel, medan valutaberäkningar ska visas som valuta, även när de tillämpas på samma basmått.

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

Dynamiska formatsträngar minskar behovet av separata formaterade mått och håller formateringen konsekvent i hela modellen.

När du ska använda beräkningsgrupper

Använd beräkningsgrupper när du har tre eller flera mått som behöver samma beräkningsmönster. Vanliga användningsfall är tidsinformation (YTD, QTD, MTD), valutakonvertering och variansberäkningar (faktisk kontra budget).

DAX-läsbarhetsdisciplin

I stor skala med ett team som upprätthåller över 200 mått är läsbarhet ett designbeslut, inte en personlig preferens. Konsekvent, läsbar DAX minskar underhållsfelen och gör det enklare för nya teammedlemmar att förstå modellen.

Variabler

Variabler lagrar mellanliggande resultat, förbättrar läsbarheten och förhindrar att motorn utvärderar samma uttryck flera gånger:

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

Utan variabler kan samma SUM(Sales[Revenue]) uttryck visas tre gånger i ett komplext mått. Variabler utvärderar uttrycket en gång och återanvänder resultatet.

Namngivningskonventioner

Konsekvent namngivning är viktigt när din modell har hundratals mått som underhålls av flera personer. Upprätta konventioner för:

• Måttnamn: Använd tydliga, beskrivande namn som "Total försäljning" eller "Intäkttillväxt i år". Undvik förkortningar som bara den ursprungliga författaren förstår.
• Variabelnamn: Använd beskrivande namn som förklarar mellanliggande värde (till exempel TotalRevenue snarare än x eller temp).
• Beräkningsgruppobjekt: Namnge objekt efter vad de gör, inte hur de fungerar (till exempel "Hittills i år" snarare än "DATESYTD Wrapper").

Beskrivande namngivning är också viktigt för AI-förbrukning. När Copilot eller en dataagent frågar din modell använder den måttnamn och beskrivningar för att avgöra vilka beräkningar som ska inkluderas. Ett mått med namnet "YoY Revenue Growth" ger bättre AI-resultat än "Calc7_v2".

Iteratorer jämfört med sammansättningsfunktioner

Iteratorfunktioner (SUMX, AVERAGEX, MAXX) utvärderar ett uttryck rad för rad över en tabell. Sammansättningsfunktioner (SUM, AVERAGE, MAX) körs på en enda kolumn. Vid stora datavolymer är valet viktigt:

• Använd aggregeringsfunktioner när du sammanfattar en enda kolumn. De är snabbare eftersom motorn kan använda fördefinierade datastrukturer.
• Använd iteratorer när beräkningen kräver ett uttryck på radnivå (till exempel Quantity × UnitPrice per rad).

Informationsfunktioner för defensiva mönster

Informationsfunktioner som ISBLANK, HASONEVALUE och ISINSCOPE skapar defensiva mönster för mått som används av flera rapporter med olika filterkontexter:

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

Dessa mönster förhindrar oväntade resultat när mått används i kontexter som den ursprungliga författaren inte förväntade sig.

Aggregations

Sammansättningar är sammanfattningstabeller som lagrar förberäknade summor med ett högre korn än detaljdata. Frågorna når dessa tabeller först, vilket förbättrar prestandan för stora faktatabeller. När en fråga matchar en aggregering returnerar motorn resultat från den mindre sammanfattningstabellen i stället för att skanna miljontals detaljrader.

Sammansättningar som ett designbeslut

Att bestämma när du ska lägga till aggregeringar och på vilken detaljnivå är ett designbeslut. Prestandaövervakning och justering är separata driftsproblem, men du gör det strukturella valet under modelldesignen.

Överväg aggregeringar när:

• Faktatabeller överskrider miljontals rader och vanliga frågor sammanfattar data med högre kornighet (till exempel månatliga summor per region).
• Användare upplever långsamma svarstider för frågor i visuella objekt på sammanfattningsnivå.
• De flesta rapportinteraktioner behöver inte information på radnivå.

Hur sammansättningsbeteendet skiljer sig åt beroende på lagringsläge

I importläge lagras sammansättningar som separata dolda tabeller. Motorn dirigerar automatiskt matchande frågor till sammansättningstabellen.

I Direct Lake-läge kan deltatabellerna själva fungera som aggregeringskällor. Eftersom Direct Lake läser columnar Parquet-filer kan motorn hantera större datavolymer utan aggregeringar i många scenarier. Lägg bara till aggregeringar när frågemönster bekräftar behovet.