Schaalbare berekeningen ontwerpen

Uw model is gestructureerd. Ontwerp nu de berekeningen die het presterend en onderhoudbaar houden naarmate uw gegevens en team groeien. Op kleine schaal werkt een model met dubbele metingen en inconsistente naamgeving nog steeds, zelfs als het niet ideaal is. Bij opschaling faalt het. Een model met honderden metingen heeft structurele ontwerpbeslissingen nodig die dubbele logica voorkomen, de querytijd voor grote gegevenssets verminderen en het mogelijk maken dat nieuwe teamleden het model begrijpen en uitbreiden zonder fouten te introduceren.

In deze eenheid worden drie patronen behandeld: berekeningsgroepen voor het verminderen van de verspreiding van metingen, DAX-leesbaarheidsdiscipline voor teamonderhoud en aggregaties voor queryprestaties op grote feitentabellen.

Berekeningsgroepen

Berekeningsgroepen zijn modelobjecten die hetzelfde berekeningspatroon toepassen op meerdere metingen. In plaats van afzonderlijke metingen te maken voor elke variatie, definieert u het patroon eenmaal en past u het dynamisch toe.

Het probleem dat berekeningengroepen oplossen

Overweeg een organisatie met 50 basismetingen (zoals totale verkoop, totale kosten, winst en verkochte eenheden). Elke meting heeft berekeningen van jaar tot heden, kwartaal tot heden en maand tot heden nodig. Zonder berekeningsgroepen is dat 50 × 3 = 150 extra metingen. Voeg vergelijkingen voor het voorgaande jaar toe en u heeft te maken met meer dan 250 metingen om te beheren.

Met calculatiegroepen maakt u één groep met calculatie-items voor elk time intelligence-patroon. Deze items zijn automatisch van toepassing op elke meting in het model.

Hoe berekeningsgroepen werken

Een berekeningsgroep bevat berekeningsitems, die elk een DAX-expressie definiëren die de huidige meting wijzigt met behulp van SELECTEDMEASURE(). Hier is een tijdintelligentie-calculatorgroep.

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

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

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

Wanneer een gebruiker de berekeningsgroep toevoegt aan een visual, kunnen ze schakelen tussen YTD, QTD en MTD voor elke meting (zoals totale verkoop, winst of verkochte eenheden) zonder afzonderlijke metingen voor elke combinatie.

Tekenreeksen met dynamische opmaak

Dynamische opmaakreeksen wijzigen de weergave-indeling op basis van de context van het rekenitem. Een percentageberekening moet bijvoorbeeld worden weergegeven als een percentage, terwijl valutaberekeningen moeten worden weergegeven als valuta, zelfs als deze worden toegepast op dezelfde basismeting.

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

Tekenreeksen met dynamische opmaak verminderen de behoefte aan afzonderlijke opgemaakte metingen en houden opmaak consistent in het model.

Wanneer u berekeningsgroepen gebruikt

Gebruik berekeningsgroepen wanneer u drie of meer metingen hebt waarvoor hetzelfde berekeningspatroon moet worden toegepast. Veelvoorkomende use cases zijn time intelligence (YTD, QTD, MTD), valutaconversie en variantieberekeningen (werkelijk versus budget).

DAX-leesbaarheidsdiscipline

Op schaal met een team dat meer dan 200 metingen onderhoudt, is de leesbaarheid een ontwerpbeslissing, geen persoonlijke voorkeur. Consistente, leesbare DAX vermindert onderhoudsfouten en maakt het voor nieuwe teamleden gemakkelijker om het model te begrijpen.

Variabelen

Variabelen slaan tussenliggende resultaten op, verbeteren de leesbaarheid en voorkomen dat de engine dezelfde expressie meerdere keren evalueert:

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

Zonder variabelen kan dezelfde SUM(Sales[Revenue]) expressie drie keer in een complexe meting worden weergegeven. Variabelen evalueren de expressie eenmaal en hergebruiken het resultaat.

Naamgevingsconventies

Consistente naamgeving is essentieel wanneer uw model honderden metingen heeft die door meerdere personen worden onderhouden. Conventies opstellen voor:

• Namen van meten: gebruik duidelijke, beschrijvende namen zoals 'Totale verkoop' of 'YoY Revenue Growth'. Vermijd afkortingen die alleen de oorspronkelijke auteur begrijpt.
• Namen van variabelen: gebruik beschrijvende namen die de tussenliggende waarde uitleggen (zoals TotalRevenue in plaats x van of temp).
• Items van berekeningsgroepen: Benoem items naar wat ze doen, niet hoe ze werken (zoals 'Jaar-tot-nu-toe' in plaats van 'DATESYTD Wrapper').

Beschrijvende naamgeving is ook belangrijk voor AI-verbruik. Wanneer Copilot of een gegevensagent query's uitvoert op uw model, worden metingsnamen en beschrijvingen gebruikt om te bepalen welke berekeningen moeten worden opgenomen. Een meting met de naam YoY Revenue Growth produceert betere AI-resultaten dan 'Calc7_v2'.

Iterators versus aggregatiefuncties

Iterator-functies (SUMX, AVERAGEX, MAXX) evalueren een rij-op-rij-expressie over een tabel. Aggregatiefuncties (SUM, AVERAGE, MAX) werken op één kolom. Bij grote gegevensvolumes is de keuze van belang:

• Gebruik aggregatiefuncties wanneer u één kolom samenvat. Ze zijn sneller omdat de engine vooraf gemaakte gegevensstructuren kan gebruiken.
• Gebruik iterators wanneer voor de berekening een expressie op rijniveau is vereist (zoals Quantity × UnitPrice per rij).

Informatiefuncties voor defensieve patronen

Informatiefuncties zoals ISBLANK, HASONEVALUEen ISINSCOPE maken defensieve patronen voor metingen die worden gebruikt door meerdere rapporten met verschillende filtercontexten:

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

Deze patronen voorkomen onverwachte resultaten wanneer metingen worden gebruikt in contexten die de oorspronkelijke auteur niet had verwacht.

Aggregations

Aggregaties zijn samenvattingstabellen waarin vooraf berekende totalen worden opgeslagen met een hogere korrel dan de detailgegevens. Query's raken deze tabellen eerst, waardoor de prestaties van grote feitentabellen worden verbeterd. Wanneer een query overeenkomt met een aggregatie, retourneert de engine resultaten uit de kleinere samenvattingstabel in plaats van miljoenen detailrijen te scannen.

Aggregaties als ontwerpbeslissing

Bepalen wanneer aggregaties moeten worden toegevoegd en welke granulariteit een ontwerpbeslissing is. Prestatiebewaking en afstemming zijn afzonderlijke operationele problemen, maar u maakt de structurele keuze tijdens het ontwerpen van het model.

Overweeg aggregaties wanneer:

• Feitentabellen overschrijden miljoenen rijen en veelgebruikte query's geven een overzicht van gegevens met een hoger graan (zoals maandelijkse totalen per regio).
• Gebruikers ervaren trage reactietijden bij query's op samenvattingsvisualisaties.
• De meeste rapportinteracties hebben geen details op rijniveau nodig.

Hoe aggregatiegedrag verschilt per opslagmodus

In de importmodus worden aggregaties opgeslagen als afzonderlijke verborgen tabellen. De engine stuurt automatisch overeenkomende query's naar de aggregatietabel.

In de Direct Lake-modus kunnen de Delta-tabellen zelf fungeren als aggregatiebronnen. Omdat Direct Lake columnaire Parquet-bestanden leest, kan de engine grotere gegevensvolumes verwerken zonder aggregaties in veel scenario's. Voeg alleen aggregaties toe wanneer querypatronen de noodzaak bevestigen.