Progettare calcoli scalabili

Il modello è strutturato. Progettare ora i calcoli che lo mantengono efficiente e gestibile man mano che aumentano i dati e il team. Su scala ridotta, un modello con misure duplicate e denominazione incoerente funziona ancora, anche se non è ideale. Su larga scala, si interrompe. Un modello con centinaia di misure richiede decisioni di progettazione strutturale che impediscono la logica duplicata, riducono il tempo di query su set di dati di grandi dimensioni e consentono ai nuovi membri del team di comprendere ed estendere il modello senza introdurre errori.

Questa unità illustra tre modelli: i gruppi di calcolo per ridurre la proliferazione delle misure, la disciplina di leggibilità DAX per la gestibilità del team e le aggregazioni per le prestazioni delle query in tabelle dei fatti di grandi dimensioni.

Gruppi di calcolo

I gruppi di calcolo sono oggetti modello che applicano lo stesso modello di calcolo tra più misure. Anziché creare misure separate per ogni variante, definire il modello una sola volta e applicarlo in modo dinamico.

I gruppi di calcolo risolvono il problema

Si consideri un'organizzazione con 50 misure di base, ad esempio Total Sales, Total Cost, Profit e Units Sold. Ogni misura richiede calcoli cumulati dall'inizio dell'anno, dall'inizio del trimestre e dall'inizio del mese. Senza gruppi di calcolo, si tratta di 50 × 3 = 150 misure aggiuntive. Aggiungi confronti con l'anno precedente e si ha a che fare con oltre 250 misure da gestire.

Con i gruppi di calcolo, si crea un gruppo con gli elementi di calcolo per ogni modello di intelligenza temporale. Tali elementi si applicano automaticamente a qualsiasi misura nel modello.

Funzionamento dei gruppi di calcolo

Un gruppo di calcolo contiene elementi di calcolo, ognuno dei quali definisce un'espressione DAX che modifica la misura corrente usando SELECTEDMEASURE(). Ecco un gruppo di calcolo di intelligenza temporale:

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

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

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

Quando un utente aggiunge il gruppo di calcolo a un oggetto visivo, può passare tra YTD, QTD e MTD per qualsiasi misura (ad esempio Total Sales, Profit o Units Sold) senza misure separate per ogni combinazione.

Stringhe di formato dinamico

Le stringhe di formato dinamico modificano il formato di visualizzazione in base al contesto dell'elemento di calcolo. Ad esempio, un calcolo percentuale deve essere visualizzato come percentuale, mentre i calcoli di valuta devono essere visualizzati come valuta, anche se applicati alla stessa misura di base.

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

Le stringhe di formato dinamico riducono la necessità di misure formattate separate e mantenere la formattazione coerente nel modello.

Quando usare i gruppi di calcolo

Usare i gruppi di calcolo quando sono presenti tre o più misure che richiedono lo stesso modello di calcolo applicato. I casi d'uso comuni includono l'intelligence temporale (YTD, QTD, MTD), la conversione di valuta e i calcoli di scostamenti (effettivo rispetto al budget).

Disciplina di leggibilità DAX

Su larga scala con un team che gestisce più di 200 misure, la leggibilità è una decisione di progettazione, non una preferenza personale. DAX coerente e leggibile riduce gli errori di manutenzione e semplifica la comprensione del modello da parte dei nuovi membri del team.

Variabili

Le variabili archiviano i risultati intermedi, migliorano la leggibilità e impediscono al motore di valutare più volte la stessa espressione:

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

Senza variabili, la stessa SUM(Sales[Revenue]) espressione potrebbe apparire tre volte in una misura complessa. Le variabili valutano l'espressione una sola volta e riutilizzano il risultato.

Convenzioni di denominazione

La denominazione coerente è fondamentale quando il modello ha centinaia di misure gestite da più persone. Stabilire convenzioni per:

• Nomi delle misure: usare nomi descrittivi chiari, ad esempio "Total Sales" o "YoY Revenue Growth". Evitare abbreviazioni che solo l'autore originale capisce.
• Nomi delle variabili: usare nomi descrittivi che spiegano il valore intermedio , ad esempio TotalRevenue anziché x o temp.
• Elementi del gruppo di calcolo: denominare gli elementi in base a ciò che fanno, non come funzionano ,ad esempio "Year-to-Date" anziché "DATESYTD Wrapper").

La denominazione descrittiva è importante anche per il consumo di intelligenza artificiale. Quando Copilot o un agente dati esegue una query sul modello, usa nomi di misura e descrizioni per determinare quali calcoli includere. Una misura denominata "YoY Revenue Growth" produce risultati di intelligenza artificiale migliori rispetto a "Calc7_v2".

Iteratori e funzioni di aggregazione

Le funzioni iteratore (SUMX, AVERAGEX, MAXX) valutano un'espressione riga per riga su una tabella. Le funzioni di aggregazione (SUM, AVERAGE, MAX) operano su una singola colonna. In volumi di dati di grandi dimensioni, la scelta è importante:

• Usare le funzioni di aggregazione quando si riepiloga una singola colonna. Sono più veloci perché il motore può usare strutture di dati predefinite.
• Usare gli iteratori quando il calcolo richiede un'espressione a livello di riga, ad esempio Quantity × UnitPrice per riga.

Funzioni informative per i modelli difensivi

Funzioni informative come ISBLANK, HASONEVALUE e ISINSCOPE creano modelli difensivi per le misure utilizzate da più report con contesti di filtro diversi:

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

Questi modelli impediscono risultati imprevisti quando le misure vengono usate nei contesti che l'autore originale non prevede.

Aggregations

Le aggregazioni sono tabelle di riepilogo che archiviano totali precalcolati a un livello più elevato rispetto ai dati di dettaglio. Le query raggiungono prima queste tabelle, migliorando così le prestazioni nelle tabelle dei fatti di grandi dimensioni. Quando una query corrisponde a un'aggregazione, il motore restituisce i risultati dalla tabella di riepilogo più piccola anziché analizzare milioni di righe di dettaglio.

Aggregazioni come decisione di progettazione

Decidere quando aggiungere aggregazioni e la granularità è una decisione di progettazione. Il monitoraggio e l'ottimizzazione delle prestazioni sono problematiche operative separate, ma si fa la scelta strutturale durante la progettazione del modello.

Prendere in considerazione le aggregazioni quando:

• Le tabelle dei fatti superano milioni di righe e le query comunemente usate riepilogano i dati a un livello più elevato ,ad esempio i totali mensili per area.
• Gli utenti riscontrano tempi di risposta lenti alle query nelle visualizzazioni riepilogative.
• La maggior parte delle interazioni dei report non richiede dettagli a livello di riga.

Differenze del comportamento delle aggregazioni in base alla modalità di archiviazione

In modalità importazione le aggregazioni vengono archiviate come tabelle nascoste separate. Il motore instrada automaticamente le query corrispondenti alla tabella di aggregazione.

In modalità Direct Lake le tabelle Delta possono fungere da origini di aggregazione. Poiché Direct Lake legge i file Parquet a colonne, il motore può gestire volumi di dati di dimensioni maggiori senza aggregazioni in molti scenari. Aggiungere aggregazioni solo quando i modelli di query confermano la necessità.