Introduction

Dans un contexte où la performance des rapports Power BI est devenue un critère de qualité incontournable, les développeurs BI optimisent constamment leurs modèles sémantiques et requêtes DAX. Pourtant, un piège de modélisation subtil passe souvent inaperçu : l’utilisation des clés primaires dans les visuels Power BI.

Cette pratique transforme une requête optimisée SPARSE en requête DENSE coûteuse, multipliant les temps d’exécution par plusieurs centaines. Le moteur DAX itère alors sur toutes les combinaisons possibles au lieu de traiter uniquement les données existantes.

SPARSE vs DENSE : comprendre la différence

Qu’est-ce qu’une requête SPARSE ?

C’est une requête optimisée qui traite uniquement les combinaisons de données qui existent réellement dans votre table de faits. C’est l’approche par défaut du moteur DAX lorsque vous utilisez des colonnes d’attributs (non-clés) dans vos visuels.

Exemple :

• Table Clients : 1000 clients
• Table Ventes : Seulement 300 clients ont fait des achats
• → Une requête SPARSE traite uniquement ces 300 clients et les 700 autres clients sont ignorés

Qu’est-ce qu’une requête DENSE ?

C’est une requête qui force le moteur DAX à parcourir toutes les combinaisons possibles des colonnes groupées, même celles qui n’existent pas dans les données. Cette situation se produit lorsqu’une clé primaire d’une table de dimension est incluse dans le regroupement.

Exemple :

• Table Clients : 1000 clients (avec CustomerKey comme clé primaire)
• Table Ventes : Seulement 300 clients ont fait des achats
• → Une requête DENSE itère sur les 1000 clients et vérifie pour chacun s’il a des ventes.
• Jette 700 résultats vides → Perte de temps et ressources énorme

Conséquences :

• Table intermédiaire volumineuse avec toutes les combinaisons
• Événements de stockage supplémentaires non filtrés
• Gaspillage de CPU et mémoire
• Temps d’exécution multiplié par des centaines

Critère	SPARSE ✅	DENSE ❌
Déclencheur	Colonnes d’attributs	Clés primaires incluses
Traitement	Données existantes uniquement	Toutes les combinaisons
Plan de requête	Agrégation directe	Outer join + itérations
Temps d’exécution	Millisecondes	Secondes/Minutes
Scalabilité	Excellente	Très mauvaise

Pourquoi les clés primaires posent problème et comment les éviter

Le mécanisme technique

Lorsqu’une clé primaire est incluse dans un visuel, le moteur DAX bascule automatiquement en mode DENSE : il identifie la clé primaire, introduit une jointure externe (outer join), génère une table avec toutes les valeurs possibles de la clé, teste chaque combinaison contre la table de faits, puis élimine la majorité des lignes vides. Ce phénomène est particulièrement critique pour les tables de dimension avec haute cardinalité (>100k lignes), les modèles en mode DUAL ou IMPORT, et les visuels combinant plusieurs dimensions.

Les bonnes pratiques

Pratique	Action	Pourquoi
✅ Masquer les clés	Masquer toutes les clés primaires et étrangères dans le modèle	Empêche leur utilisation accidentelle dans les visuels
✅ Attributs métier uniquement	Exposer seulement les colonnes descriptives (Pays, Catégorie, Nom…)	Interface claire et performance optimale
✅ Former les utilisateurs	Sensibiliser les équipes aux colonnes à utiliser	Adoption des bonnes pratiques
✅ Utiliser DAX Studio	Analyser régulièrement les requêtes lentes avec DAX Studio (outil gratuit)	Détection rapide des requêtes DENSE et problèmes de performance
❌ Pas de clés dans les visuels	Ne jamais utiliser CustomerKey, ProductID, etc. dans les axes ou slicers	Évite le mode DENSE

Solution de contournement

Dans les rares cas où afficher une valeur de clé est nécessaire :

Exemple : // Créer une colonne calculée non reconnue comme clé
CustomerKey_Display = DimCustomer[CustomerKey]

Cas réel : analyse d’un problème de performance

Contexte

Un rapport Power BI en production présentait des ralentissements sur un visuel affichant les ventes par pays : 850 000 clients dans DimCustomer, 300 000 clients actifs dans FactSales

Aspect	❌ Avant (avec clé primaire)	✅ Après (sans clé primaire)
Code DAX	SUMMARIZECOLUMNS ( DimCustomer[CustomerKey], DimCustomer[Country], "Sales", SUM(Sales[Amount]))	SUMMARIZECOLUMNS ( DimCustomer[Country], "Sales", SUM(Sales[Amount]))
Temps d’exécution	38 000 ms (38 secondes)	74 ms
Lignes traitées	831 278 lignes	~50 lignes
Mode de requête	DENSE (toutes combinaisons)	SPARSE (données existantes)
Lignes jetées	~530 000 lignes éliminées	0
Amélioration		513× plus rapide

Signal détecté dans DAX Studio

• ⚠️ Scan de dimension sans agrégation
• ⚠️ Table intermédiaire volumineuse (831k lignes)
• ⚠️ Grande section jaune dans Timeline = temps perdu

→ Action corrective : Masquage de CustomerKey dans le modèle.