Concevoir des calculs évolutifs

Votre modèle est structuré. Concevez maintenant les calculs qui le conservent performant et gérable à mesure que vos données et votre équipe augmentent. À petite échelle, un modèle avec des mesures dupliquées et un nommage incohérent fonctionne toujours, même s'il n'est pas idéal. À grande échelle, il tombe en panne. Un modèle avec des centaines de mesures a besoin de décisions de conception structurelle qui empêchent la logique dupliquée, réduisent le temps de requête sur les jeux de données volumineux et permettent aux nouveaux membres de l’équipe de comprendre et d’étendre le modèle sans introduire d’erreurs.

Cette unité couvre trois modèles : les groupes de calcul pour réduire la prolifération des mesures, la discipline de lisibilité DAX pour faciliter la maintenance par l’équipe, et les agrégations pour améliorer les performances des requêtes sur des tables de faits volumineuses.

Groupes de calcul

Les groupes de calcul sont des objets de modèle qui appliquent le même modèle de calcul sur plusieurs mesures. Au lieu de créer des mesures distinctes pour chaque variante, vous définissez le modèle une fois et l’appliquez dynamiquement.

Le problème que résolvent les groupes de calcul

Considérez une organisation avec 50 mesures de base (par exemple, Total Sales, Total Cost, Profit et Units Sold). Chaque mesure a besoin des calculs Année à Date, Trimestre à Date et Mois à Date. Sans groupes de calcul, il s’agit de 50 × 3 = 150 mesures supplémentaires. Ajoutez des comparaisons d’année précédente et vous examinez 250 mesures de maintien.

Avec les groupes de calcul, vous créez un groupe avec des éléments de calcul pour chaque modèle d’intelligence temporelle. Ces éléments s’appliquent automatiquement à n’importe quelle mesure dans le modèle.

Fonctionnement des groupes de calcul

Un groupe de calcul contient des éléments de calcul, chacun définissant une expression DAX qui modifie la mesure actuelle à l’aide de SELECTEDMEASURE(). Voici un groupe de calcul d'intelligence temporelle :

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

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

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

Lorsqu’un utilisateur ajoute le groupe de calcul à un visuel, il peut basculer entre YTD, QTD et MTD pour n’importe quelle mesure (par exemple, Total Sales, Profit ou Units Sold) sans mesures distinctes pour chaque combinaison.

Chaînes de format dynamique

Les chaînes de format dynamique modifient le format d’affichage en fonction du contexte de l’élément de calcul. Par exemple, un calcul de pourcentage doit s’afficher sous la forme d’un pourcentage, tandis que les calculs monétaires doivent s’afficher en tant que devises, même lorsqu’ils sont appliqués à la même mesure de base.

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

Les chaînes de format dynamique réduisent la nécessité de mesures mises en forme distinctes et maintiennent la cohérence de la mise en forme à travers le modèle.

Quand utiliser des groupes de calcul

Utilisez des groupes de calcul lorsque vous avez trois mesures ou plus qui ont besoin du même modèle de calcul appliqué. Les cas d’usage courants incluent l’intelligence temporelle (YTD, QTD, MTD), la conversion monétaire et les calculs de variance (réel et budget).

Discipline de lisibilité DAX

À grande échelle, avec une équipe qui maintient plus de 200 mesures, la lisibilité est une décision de conception, et non une préférence personnelle. DAX cohérent et lisible réduit les erreurs de maintenance et facilite la compréhension du modèle par les nouveaux membres de l’équipe.

Variables

Les variables stockent des résultats intermédiaires, améliorent la lisibilité et empêchent le moteur d’évaluer la même expression plusieurs fois :

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

Sans variables, la même SUM(Sales[Revenue]) expression peut apparaître trois fois dans une mesure complexe. Les variables évaluent l’expression une fois et réutilisent le résultat.

Conventions de dénomination

Le nommage cohérent est essentiel lorsque votre modèle comporte des centaines de mesures maintenues par plusieurs personnes. Établissez des conventions pour :

• Noms de mesures : utilisez des noms clairs et descriptifs tels que « Total Sales » ou « YoY Revenue Growth ». Évitez les abréviations que seul l’auteur d’origine comprend.
• Noms de variables : utilisez des noms descriptifs qui expliquent la valeur intermédiaire (par exemple, plutôt que TotalRevenuex ou ).temp
• Éléments du groupe de calcul : nommez les éléments selon ce qu’ils font, et non pas leur fonctionnement (par exemple, « Année à jour » plutôt que « Wrapper DATESYTD »).

Le nommage descriptif est également important pour la consommation de l’IA. Quand Copilot ou un agent de données interroge votre modèle, il utilise des noms de mesures et des descriptions pour déterminer les calculs à inclure. Une mesure nommée « YoY Revenue Growth » produit de meilleurs résultats d’IA que « Calc7_v2 ».

Itérateurs et fonctions d’agrégation

Les fonctions d’itérateur (SUMX, , AVERAGEXMAXX) évaluent une expression de ligne par ligne sur une table. Les fonctions d’agrégation (SUM, AVERAGE, MAX) fonctionnent sur une seule colonne. Au niveau des volumes de données volumineux, le choix est important :

• Utilisez des fonctions d’agrégation lorsque vous résumez une seule colonne. Ils sont plus rapides, car le moteur peut utiliser des structures de données prédéfinies.
• Utilisez des itérateurs lorsque le calcul nécessite une expression au niveau des lignes (par Quantity × UnitPrice exemple, par ligne).

Fonctions d’information pour les modèles défensifs

Les fonctions d’information telles que ISBLANK, HASONEVALUEet ISINSCOPE créent des modèles défensifs pour les mesures consommées par plusieurs rapports avec différents contextes de filtre :

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

Ces modèles empêchent les résultats inattendus lorsque les mesures sont utilisées dans les contextes que l’auteur d’origine n’a pas prévu.

Aggregations

Les agrégations sont des tables récapitulatives qui stockent des totaux précalculés à un grain supérieur aux données de détail. Les requêtes atteignent d’abord ces tables, ce qui améliore les performances des tables de faits volumineuses. Lorsqu’une requête correspond à une agrégation, le moteur retourne les résultats de la table récapitulative plus petite plutôt que d’analyser des millions de lignes de détails.

Agrégations en tant que décision de conception

Décider quand ajouter des agrégations et à quelle granularité est une décision de conception. La surveillance et le réglage des performances sont des préoccupations opérationnelles distinctes, mais vous faites le choix structurel pendant la conception du modèle.

Tenez compte des agrégations quand :

• Les tables de faits dépassent des millions de lignes et les requêtes couramment utilisées résument les données à un grain plus élevé (par exemple, les totaux mensuels par région).
• Les utilisateurs rencontrent des temps de réponse de requête lents sur les visuels de niveau résumé.
• La plupart des interactions de rapport n’ont pas besoin de détails au niveau des lignes.

Différences entre le comportement d’agrégation et le mode de stockage

En mode Importation, les agrégations sont stockées sous forme de tables masquées distinctes. Le moteur achemine automatiquement les requêtes correspondantes vers la table d’agrégation.

En mode Direct Lake, les tables Delta elles-mêmes peuvent servir de sources d’agrégation. Étant donné que Direct Lake lit les fichiers Parquet en colonnes, le moteur peut gérer des volumes de données plus volumineux sans agrégations dans de nombreux scénarios. Ajoutez des agrégations uniquement lorsque les modèles de requête confirment le besoin.