Modélisation de données Power BI : conception de schémas en étoile pour la Business Intelligence

Le modèle de données constitue la base de chaque rapport Power BI. Un modèle bien conçu rend les mesures DAX simples, les performances des requêtes rapides et le développement de rapports intuitif. Un modèle mal conçu rend tout difficile : les mesures nécessitent des solutions de contournement alambiquées, les requêtes s'exécutent lentement et les développeurs passent plus de temps à lutter contre le modèle qu'à générer des informations.

Le schéma en étoile est la référence en matière de modèles de données analytiques, et ce depuis des décennies. Les bases de données relationnelles qui alimentent vos systèmes ERP et CRM sont conçues pour l'efficacité transactionnelle à l'aide de schémas normalisés avec des dizaines de tables interconnectées. Cette conception est optimale pour enregistrer des transactions individuelles mais terrible pour l'agrégation, la comparaison et l'analyse des tendances. Le schéma en étoile restructure ces mêmes données pour des performances analytiques en les séparant en tableaux de faits (ce qui s'est passé) et en tableaux de dimensions (le contexte autour de ce qui s'est passé).

Ce guide couvre les principes de conception de schémas en étoile spécifiquement pour Power BI, notamment comment créer des tables de faits et de dimensions, configurer des relations, écrire des mesures DAX efficaces, exploiter des groupes de calcul, mettre en œuvre l'intelligence temporelle et utiliser des modèles composites pour se connecter à plusieurs sources de données.

Points clés à retenir

• Le schéma en étoile sépare les données en tables de faits (mesures numériques, clés étrangères) et tables de dimensions (attributs descriptifs) --- cette structure est optimisée pour le moteur VertiPaq de Power BI
• Chaque relation dans un modèle Power BI doit passer d'une dimension à un fait (un vers plusieurs), avec un filtrage croisé dans une seule direction.
• Les mesures DAX fonctionnent considérablement mieux sur les schémas en étoile, car VertiPaq peut compresser efficacement les colonnes de dimensions et filtrer les faits à travers les relations.
• Les groupes de calcul remplacent des dizaines de mesures redondantes (YTD, QTD, MTD, Année précédente) par un modèle unique appliqué à toutes les mesures de base
• L'intelligence temporelle nécessite une table de dimension de date dédiée --- n'utilisez jamais de date/heure automatique et ne vous fiez pas aux colonnes de date dans les tables de faits
• Les modèles composites vous permettent de combiner des données importées avec des connexions DirectQuery, vous offrant ainsi les performances en mémoire avec la fraîcheur des requêtes en direct
• Les dimensions de jeu de rôle (une table utilisée dans plusieurs rôles relationnels) nécessitent la fonction USERELATIONHIP de DAX.

---

Principes fondamentaux du schéma en étoile

Pourquoi un schéma en étoile pour Power BI

Le moteur en mémoire de Power BI, VertiPaq, utilise la compression en colonnes pour stocker les données. Il compresse chaque colonne indépendamment et les colonnes avec une faible cardinalité (peu de valeurs uniques) se compressent de manière spectaculaire --- une colonne "Pays" avec 40 valeurs uniques sur 10 millions de lignes se compresse en presque rien. Les colonnes avec une cardinalité élevée (de nombreuses valeurs uniques) comme les ID de transaction ou les horodatages sont mal compressées.

Le schéma en étoile exploite cela en isolant les données transactionnelles à cardinalité élevée (dates, montants, quantités) dans des tableaux de faits étroits et en plaçant les données descriptives à faible cardinalité (noms, catégories, régions) dans des tableaux de dimensions séparés. Le résultat est un modèle de données à la fois plus petit en mémoire et plus rapide à interroger.

Considérez la différence. Un tableau plat dénormalisé pour une entreprise de vente au détail peut comporter 50 colonnes : OrderDate, CustomerName, CustomerEmail, CustomerCity, CustomerCountry, CustomerSegment, ProductName, ProductCategory, ProductSubcategory, Brand, Supplier, SupplierCountry, Quantity, UnitPrice, Discount, TotalAmount, etc. Chaque ligne répète « États-Unis » des milliers de fois, « Électronique » des centaines de fois et le nom complet du client pour chaque commande passée par ce client.

L'équivalent du schéma en étoile divise cela en :

FactSales (étroit, une ligne par ligne de commande) : OrderDateKey, CustomerKey, ProductKey, Quantity, UnitPrice, Discount, TotalAmount.

DimCustomer : CustomerKey, CustomerName, Email, Ville, Pays, Segment.

DimProduct : ProductKey, ProductName, Catégorie, Sous-catégorie, Marque.

DimDate : DateKey, Date, Année, Trimestre, Mois, MonthName, DayOfWeek.

La table de faits ne comporte que 7 colonnes au lieu de 50. Chaque table de dimensions stocke chaque valeur unique exactement une fois. VertiPaq compresse cette structure 3 à 5 fois mieux que la table plate et les requêtes s'exécutent 2 à 10 fois plus rapidement car le moteur filtre les tables de petites dimensions, puis résout uniquement les lignes correspondantes dans la table de faits.

Tableaux de faits : principes de conception

Les tableaux de faits enregistrent les événements commerciaux : ventes, commandes, expéditions, tickets d'assistance, visites Web, cycles de fabrication. Chaque ligne représente un événement ou un élément de campagne d'un événement.

Définition du grain. Le grain est le niveau de détail dans la table de faits. Définissez-le avec précision et appliquez-le de manière cohérente. Un tableau de faits sur les ventes peut avoir un grain de « une ligne par élément de ligne de commande » ou « une ligne par résumé quotidien des ventes de produits ». Mélanger des grains dans une seule table de faits (certaines lignes sont des transactions individuelles, d'autres sont des agrégats quotidiens) crée des erreurs de calcul extrêmement difficiles à déboguer.

Clés étrangères uniquement. La table de faits contient des clés étrangères vers les tables de dimensions, et non des attributs descriptifs. Une table de faits ne doit pas contenir « CustomerName » ou « ProductCategory » --- ceux-ci appartiennent aux tables de dimensions. La table de faits contient CustomerKey et ProductKey, qui renvoient aux dimensions où se trouvent les détails descriptifs.

Mesures additives. Les colonnes numériques d'une table de faits doivent être des valeurs additives qui peuvent être additionnées de manière significative dans n'importe quelle dimension. Les revenus, la quantité, le coût et la remise s’additionnent. Les pourcentages, les ratios et les prix unitaires ne sont pas additifs (vous ne pouvez pas additionner les prix unitaires des produits). Stockez les composants (numérateur et dénominateur) dans la table de faits et calculez le ratio dans une mesure DAX.

Évitez les colonnes calculées dans les faits. L'ajout de colonnes calculées à une table de faits augmente l'empreinte mémoire de la table et ajoute du temps de traitement lors de l'actualisation. Calculez plutôt les valeurs dérivées dans les mesures DAX, qui sont calculées au moment de la requête et ne consomment pas de stockage.

Tableaux de dimensions : principes de conception

Les tableaux de dimensions décrivent « qui, quoi, où, quand, pourquoi » des événements professionnels. Ils contiennent les attributs que les utilisateurs filtrent, regroupent et découpent.

Clés de substitution. Utilisez des clés de substitution entières (CustomerKey, ProductKey) comme clé primaire dans les tables de dimensions, et non des clés naturelles (e-mail client, SKU du produit). Les clés de substitution sont plus petites, se compressent mieux et isolent le modèle des modifications apportées aux clés du système source.

Dénormaliser les dimensions. Dans un schéma en étoile, les tables de dimensions sont délibérément dénormalisées. Une table DimProduct inclut Category, Subcategory et Brand sous forme de colonnes dans la même table, et non sous forme de tables normalisées distinctes avec leurs propres clés. C’est le contraire de la conception d’une base de données transactionnelle, et c’est intentionnel. Les dimensions dénormalisées produisent des requêtes plus rapides et un DAX plus simple, car le moteur VertiPaq analyse une seule table plutôt que de joindre plusieurs tables.

Inclure des hiérarchies descriptives. Si les utilisateurs souhaitent passer de la catégorie à la sous-catégorie jusqu'au produit, les trois niveaux doivent être des colonnes dans DimProduct. Créez un objet de hiérarchie dans le modèle Power BI qui définit ce chemin d'exploration.

Dimensions qui évoluent lentement. Lorsque les attributs d'une dimension changent au fil du temps (un client change de ville, un produit change de catégorie), vous avez besoin d'une stratégie. Le type 1 (écrasement) est le plus simple : mettez à jour la ligne de dimension avec la nouvelle valeur. Le type 2 (ajouter une nouvelle ligne) préserve l'historique --- ajoute une nouvelle ligne avec une plage de dates effective, afin que les transactions historiques soient associées aux valeurs d'attribut qui étaient actuelles à ce moment-là. Le type 2 est plus complexe mais nécessaire lorsque l’exactitude historique est importante (audits financiers, rapports réglementaires).

---

Configuration des relations

Règles de relation pour Power BI

Les relations Power BI définissent la façon dont les tables se connectent et comment les filtres se propagent. Il est essentiel d’établir de bonnes relations : des relations incorrectes produisent silencieusement des chiffres erronés, ce qui est pire que de produire des erreurs.

Un-à-plusieurs uniquement. Chaque relation dans un schéma en étoile connecte une table de dimensions (un côté) à une table de faits (plusieurs côtés). La table de dimensions a des valeurs uniques dans la colonne clé. La table de faits a des valeurs répétées. Power BI valide cela et signale les violations. Si Power BI détecte une relation plusieurs-à-plusieurs, vous devez résoudre un problème de modélisation.

** Filtrage croisé dans une seule direction. ** Définissez la direction du filtre croisé sur « Unique » pour toutes les relations. Cela signifie que les filtres vont de la dimension au fait (lorsque vous sélectionnez un client dans un segment, seules les lignes de ce client apparaissent dans les visuels de la table de faits), mais pas du fait à la dimension. Le filtrage bidirectionnel crée des chemins de filtre ambigus dans les modèles comportant plusieurs tables de faits et doit être évité, sauf dans des scénarios très spécifiques.

Relations actives ou inactives. Power BI autorise une seule relation active entre deux tables. Si une table de faits comporte plusieurs colonnes de date (OrderDate, ShipDate, DeliveryDate), créez une relation active (généralement OrderDate à DimDate) et des relations inactives pour les autres. Utilisez la fonction USERELATIONHIP dans les mesures DAX pour activer la relation inactive si nécessaire :

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

Dimensions du jeu de rôle

Une dimension de jeu de rôle est une table de dimension unique qui remplit plusieurs rôles dans le modèle. La dimension date est l'exemple le plus courant : elle se connecte à OrderDate, ShipDate et DeliveryDate dans la table de faits, jouant un « rôle » différent dans chaque relation.

Dans Power BI, vous pouvez gérer les dimensions du jeu de rôle de deux manières :

Relations inactives + USERELATIONSHIP (recommandé). Conservez une seule table DimDate avec une relation active (avec OrderDate) et des relations inactives avec les autres colonnes de date. Créez des mesures qui utilisent USERELATIONHIP pour les perspectives de date alternatives. Cela maintient le modèle compact et évite la duplication des données.

Tables de dimensions en double. Créez des copies distinctes de DimDate (DimOrderDate, DimShipDate, DimDeliveryDate), chacune avec une relation active avec sa colonne de faits respective. Cette approche est plus simple du point de vue DAX (aucun USERELATIONSHIP n'est nécessaire) mais augmente la taille du modèle et la charge de maintenance.

Pour la plupart des implémentations, l'approche de relation inactive est préférée. Il produit un modèle plus propre et une empreinte mémoire plus petite au prix d'un DAX légèrement plus verbeux.

Relations plusieurs-à-plusieurs

Certains scénarios commerciaux nécessitent véritablement des relations plusieurs-à-plusieurs. Un client peut appartenir à plusieurs segments, un produit peut faire partie de plusieurs campagnes promotionnelles, un vendeur peut couvrir plusieurs territoires. Le schéma en étoile les gère via des tables de pont.

Une table pont se situe entre les deux tables dans une relation plusieurs-à-plusieurs et contient une ligne pour chaque combinaison :

BridgeCustomerSegment : CustomerKey, SegmentKey

DimCustomer se connecte à BridgeCustomerSegment (un-à-plusieurs sur CustomerKey). DimSegment se connecte à BridgeCustomerSegment (un-à-plusieurs sur SegmentKey). La table de pont permet de filtrer FactSales par segment tout en gérant correctement les clients dans plusieurs segments.

Soyez prudent avec les tableaux de pont : ils peuvent produire un double comptage s'ils ne sont pas associés à des mesures DAX appropriées qui gèrent l'allocation plusieurs-à-plusieurs. Testez minutieusement avec des données connues pour valider que les totaux sont corrects.

---

Mesures DAX : modèles et performances

Mesures de base

Chaque modèle analytique nécessite un ensemble de mesures de base qui effectuent des agrégations simples sur les colonnes des tables de faits. Définissez-les d'abord : ils servent de base à des calculs plus complexes.

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

Notez que la valeur moyenne des commandes et la marge brute font référence à d'autres mesures plutôt que de répéter la logique d'agrégation. Ceci est délibéré : si la définition du revenu total change (par exemple, pour exclure les retours), les mesures en aval reflètent automatiquement le changement.

CALCULER : Le cœur de DAX

CALCULATE est la fonction DAX la plus importante. Il évalue une expression dans un contexte de filtre modifié. Comprendre CALCULATE, c'est comprendre DAX.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Cette mesure prend la mesure Revenu total et l'évalue dans un contexte de filtre où la plage de dates est décalée d'un an. Si le contexte de filtre actuel est « Janvier 2026 », CALCULATE le modifie en « Janvier 2025 » et évalue le revenu total dans ce contexte modifié.

CALCULATE accepte plusieurs arguments de filtre, et ils interagissent différemment selon leur type :

Les Filtres de table (comme SAMEPERIODLASTYEAR) remplacent le filtre existant sur les colonnes de cette table. Si le visuel possède déjà un filtre mensuel, SAMEPERIODLASTYEAR le remplace par le mois correspondant de l’année précédente.

Les Filtres booléens (comme DimProduct[Category] = "Electronics") s'ajoutent au contexte existant. Si le visuel est filtré jusqu'en 2026, le résultat CALCULER affiche les revenus de l'électronique pour 2026.

REMOVEFILTERS efface les filtres existants. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) renvoie les revenus totaux dans toutes les catégories, quels que soient les filtres de catégorie actifs.

Variables pour la lisibilité et les performances

Les variables (VAR) calculent une valeur une fois et la référencent plusieurs fois. Ils rendent lisibles les mesures complexes et éliminent les calculs redondants :

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

Sans variables, cette mesure calculerait le [Revenu total] et le [Revenu de l'année dernière] plusieurs fois (une fois pour la soustraction, une fois pour la division), doublant ainsi le coût de calcul. Les variables garantissent que chacune est calculée exactement une fois.

Fonctions d'itérateur : quand les utiliser

Les fonctions itératrices (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX) évaluent une expression ligne par ligne dans une table. Ils sont puissants mais coûteux : ils analysent chaque ligne du tableau spécifié.

Utilisez des itérateurs lorsque vous avez besoin de calculs au niveau des lignes avant l'agrégation :

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

Cela ne peut pas être réalisé avec une simple SUM car vous devez multiplier la quantité par UnitPrice sur chaque ligne avant de faire la somme. L'itérateur SUMX gère cette multiplication ligne par ligne.

Évitez les itérateurs lorsqu’un simple agrégat suffit. SUMX(FactSales, FactSales[TotalAmount]) est fonctionnellement équivalent à SUM(FactSales[TotalAmount]) mais plus lent car l'itérateur analyse ligne par ligne tandis que SUM exploite la compression en colonnes.

---

Groupes de calcul

Ce que les groupes de calcul résolvent

Avant les groupes de calcul, un modèle de données avec 10 mesures de base (Revenu, Quantité, Coût, Marge, etc.) et 5 variations d'intelligence temporelle (YTD, QTD, MTD, Année précédente, Année précédente YTD) nécessitait 50 mesures distinctes. L'ajout d'une nouvelle mesure de base impliquait la création de 5 variantes supplémentaires d'intelligence temporelle. L’ajout d’un nouveau modèle d’intelligence temporelle impliquait la création de 10 mesures supplémentaires. Cette explosion combinatoire rendait les modèles difficiles à maintenir.

Les groupes de calcul résolvent ce problème en définissant une seule fois des modèles d’intelligence temporelle et en les appliquant dynamiquement à n’importe quelle mesure.

Création d'un groupe de calcul de Time Intelligence

Dans Power BI Desktop, créez un groupe de calcul via la vue Modèle ou à l'aide d'outils externes tels que l'éditeur tabulaire (qui offre plus de contrôle).

Définissez les éléments de calcul pour chaque modèle d'intelligence temporelle :

Actuel : Aucune modification --- renvoie la mesure telle quelle.

SELECTEDMEASURE()

** Cumul annuel (année à ce jour) :**

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

Année précédente :

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Année précédente depuis le début de l'année :

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

Changement annuel :

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

% de variation sur un an :

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

Une fois défini, les utilisateurs placent le groupe de calcul dans l’axe des colonnes ou des lignes d’un visuel, et Power BI applique chaque élément de calcul à n’importe quelle mesure contenue dans le puits de valeurs. Un groupe de calcul avec 6 éléments remplace 60 mesures individuelles (pour 10 mesures de base).

Formater les expressions de chaîne

Chaque élément de calcul peut avoir une expression de chaîne de format qui modifie dynamiquement le format numérique en fonction du calcul :

Pour les mesures absolues (actuelle, cumulée, année précédente) : utilisez le format de la mesure de base. Pour les mesures en pourcentage (% de variation sur une année) : format en pourcentage.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

Cela garantit que lorsqu'un utilisateur bascule entre « Actuel » (affichant 1 234 567 $) et « % de changement en glissement annuel » (affichant 12,5 %), le formatage est correct sans intervention manuelle.

---

Intelligence temporelle

La table des dimensions de date

L’intelligence temporelle dans Power BI nécessite une table de dimension de date dédiée. Ne comptez pas sur la fonction de date/heure automatique (désactivez-la dans Fichier → Options → Chargement de données) --- elle crée des tables de dates cachées pour chaque colonne de date, ce qui gonfle votre modèle et limite votre contrôle.

Créez une table de dimension de date qui couvre toute la gamme de vos données plus au moins une année de chaque côté. Si votre première transaction date de janvier 2020, commencez le tableau des dates en janvier 2019. Si votre analyse inclut des prévisions pour 2027, terminez-la en décembre 2027.

Colonnes essentielles pour une table de dimensions de date :

Créez la table de dates dans Power Query ou en tant que table calculée DAX :

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

Marquez la table comme table de dates dans Power BI (Outils de table → Marquer comme table de dates → sélectionnez la colonne Date). Cela active les fonctions d’intelligence temporelle intégrées.

Modèles courants d'intelligence temporelle

Avec une dimension de date appropriée, les fonctions d'intelligence temporelle de Power BI gèrent les calculs temporels les plus courants :

Courriel à ce jour : DATESYTD(DimDate[Date]) Trimestre à ce jour : DATESQTD(DimDate[Date]) Courriel mensuel : DATESMTD(DimDate[Date]) Même période l'année dernière : SAMEPERIODLASTYEAR(DimDate[Date]) 12 mois glissants : DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) Période parallèle : PARALLELPERIOD(DimDate[Date], -1, QUARTER) (fenêtre de même taille décalée vers l'arrière)

Ces fonctions modifient le contexte du filtre de date lorsqu'elles sont utilisées dans CALCULATE. Ils ne fonctionnent correctement que lorsque la colonne de date provient d'une table marquée comme table de dates avec une plage de dates contiguë et complète.

Prise en charge du calendrier fiscal

Si l'exercice financier de votre organisation ne correspond pas à l'année civile, modifiez les calculs de Time Intelligence pour utiliser le calendrier fiscal :

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

Le deuxième argument de DATESYTD spécifie la date de fin d'exercice. Tous les calculs cumulatifs utilisent alors la limite de l’exercice financier au lieu du 31 décembre.

---

Modèles composites

Quand utiliser des modèles composites

Les modèles composites combinent des données importées (stockées dans VertiPaq) avec des données DirectQuery (interrogeées en direct à partir de la source) dans un seul modèle. Cette approche hybride est précieuse lorsque vous avez besoin des performances des données importées pour l'analyse historique et de la fraîcheur des données en direct pour les mesures opérationnelles.

Scénarios courants :

Historique + temps réel. Importez 3 ans de données de ventes historiques pour l'analyse des tendances (requêtes rapides, aucun impact sur la base de données source). Connectez-vous aux données du mois en cours via DirectQuery pour des vues opérationnelles à la minute près.

Modèle central + enrichissement local. Connectez-vous à un ensemble de données géré de manière centralisée via DirectQuery (en garantissant que vous utilisez les définitions gouvernées de l'organisation). Ajoutez des tables importées locales pour les données spécifiques au département (objectifs budgétaires, classifications personnalisées) qui n'existent pas dans le modèle central.

Systèmes sources multiples. Importez des données à partir d'un entrepôt de données cloud (Snowflake, Azure Synapse) et connectez-vous via DirectQuery à une base de données opérationnelle (PostgreSQL, SQL Server) dans un seul rapport, sans créer de pipeline ETL distinct pour les consolider.

Architecture de modèle composite

Dans un modèle composite, chaque table possède un mode de stockage :

Importer : Les données sont chargées dans la mémoire du VertiPaq. Performances de requête les plus rapides, mais nécessite une actualisation planifiée pour la mise à jour.

DirectQuery : Les données sont interrogées en direct à partir de la source. Toujours à jour mais dépend des performances de la base de données source.

Dual : La table est à la fois importée et disponible pour DirectQuery. Utilisé pour les tables de dimensions qui doivent être liées aux tables de faits Import et DirectQuery.

Définissez les tables de dimensions qui relient les faits Import et DirectQuery en mode « Double ». Cela permet au moteur VertiPaq d'utiliser la copie en mémoire lors du filtrage des faits d'importation et de générer des requêtes SQL lors du filtrage des faits DirectQuery.

Considérations sur les performances

Les modèles composites introduisent de la complexité. Les requêtes qui couvrent les tables Import et DirectQuery nécessitent que Power BI fusionne les résultats de deux moteurs différents, ce qui peut être lent si la source DirectQuery n'est pas optimisée.

Réduisez les jointures entre sources en structurant votre modèle de manière à ce que la plupart des requêtes analytiques atteignent les tables d'importation. Utilisez DirectQuery uniquement pour les tables spécifiques qui nécessitent une actualisation en temps réel. Indexez les tables sources DirectQuery sur les colonnes utilisées dans les relations et les filtres.

Pour les organisations qui créent des modèles de données Power BI complexes, les services de modélisation de données d'ECOSIRE fournissent des conseils d'experts sur la conception de schémas en étoile, l'optimisation DAX et l'architecture de modèles composites adaptés à votre paysage de données spécifique et à vos exigences de performances.

---

Optimisation du modèle

Réduire la taille du modèle

Les modèles volumineux consomment plus de mémoire, s'actualisent plus lentement et interrogent moins rapidement. Optimisez la taille du modèle grâce à ces techniques :

Supprimez les colonnes inutilisées. Si une colonne n'est utilisée dans aucun visuel, mesure, relation ou règle RLS, supprimez-la. Chaque colonne consomme de la mémoire même si aucun visuel n'y fait référence. Les contrevenants courants incluent les colonnes générées automatiquement, les colonnes d'audit (CreatedBy, ModifiedDate) et les identifiants techniques qui ne servent à aucun objectif analytique.

Réduisez la cardinalité. Les colonnes contenant des millions de valeurs uniques (horodatages, GUID, champs de texte libre) se compressent mal. Arrondissez les horodatages à la granularité appropriée (quotidiennement, horaire). Remplacez les GUID par des clés de substitution entières. Déplacez les champs de texte libre vers une table détaillée distincte qui est interrogée uniquement lors de l'exploration amont.

Utilisez les types de données appropriés. Power BI stocke le « nombre entier » plus efficacement que le « nombre décimal ». Si une colonne contient uniquement des nombres entiers (quantités, nombres), définissez son type sur Nombre entier. Les colonnes de texte consomment plus de mémoire que les colonnes numériques de même cardinalité --- si possible, codez les catégories de texte sous forme d'entiers avec une dimension de recherche.

Désactivez la date/heure automatique. La fonction date/heure automatique crée un tableau de dates masqué pour chaque colonne de date du modèle. Pour un modèle avec 10 colonnes de dates, cela représente 10 tables de dates cachées consommant de la mémoire. Désactivez cette fonctionnalité et utilisez plutôt une seule dimension de date explicite.

Diagnostic des performances des requêtes

Utilisez DAX Studio pour analyser les performances des requêtes au-delà de ce que montre l'analyseur de performances intégré de Power BI. DAX Studio révèle :

Requêtes du moteur de stockage. Combien de requêtes sont envoyées au moteur VertiPaq et quelle quantité de données elles analysent. Moins de requêtes analysant moins de données signifie de meilleures performances.

Activité du moteur de formule. Quantité de travail effectuée par le moteur de formule (calculs ligne par ligne, expressions complexes). Un temps de moteur de formule élevé indique que les mesures doivent être réécrites pour transférer davantage de travail vers le moteur de stockage.

Plan de requête. Plan d'exécution logique et physique pour une requête DAX, montrant comment Power BI décompose une mesure en requêtes de moteur de stockage et opérations de moteur de formule.

Ciblez des temps de requête inférieurs à 500 ms pour les visuels interactifs. Les requêtes de plus de 2 secondes semblent lentes et découragent l'utilisation du tableau de bord. Si un visuel spécifique dépasse systématiquement 2 secondes, simplifiez son DAX, réduisez le volume de données qu'il traite ou déplacez-le vers une page d'accès au détail où les utilisateurs acceptent une brève attente.

---

##FAQ

Dois-je utiliser un schéma en étoile ou un schéma en flocon de neige dans Power BI ?

Le schéma en étoile est presque toujours le meilleur choix pour Power BI. Le schéma Snowflake normalise les tables de dimensions en sous-tables (Catégorie → Sous-catégorie → Produit), ce qui fonctionne bien dans les bases de données relationnelles mais crée des jointures inutiles dans le moteur VertiPaq de Power BI. VertiPaq compresse les colonnes de dimensions dénormalisées de manière extrêmement efficace, de sorte que les économies d'espace liées au flocon de neige sont négligeables alors que le coût en termes de performances des relations supplémentaires est réel. Aplatissez vos dimensions dans un schéma en étoile, sauf si vous avez une raison technique spécifique de ne pas le faire (comme une très grande table de dimensions avec une colonne à cardinalité élevée rarement utilisée que vous souhaitez isoler).

Quelle est la taille maximale de l'ensemble de données dans Power BI ?

Power BI Pro prend en charge les ensembles de données compressés jusqu’à 1 Go. Premium par utilisateur prend en charge jusqu'à 100 Go. La capacité Premium (P1 et supérieure) prend en charge jusqu'à 400 Go avec le stockage de grands ensembles de données activé. Ces limites font référence à la taille compressée en mémoire, et non à la taille des données source. VertiPaq compresse généralement les données selon un rapport de 10 : 1, donc un ensemble de données compressé de 1 Go peut représenter 10 Go de données sources. Pour les ensembles de données proches de ces limites, envisagez des agrégations, une actualisation incrémentielle ou des modèles composites avec DirectQuery pour les données de niveau détail.

Comment gérer les relations plusieurs-à-plusieurs dans un schéma en étoile ?

Utilisez une table de pont (également appelée table de faits factuels ou table de jonction). La table de pont comporte une ligne pour chaque combinaison dans la relation plusieurs-à-plusieurs --- par exemple, une ligne pour chaque affectation de segment client. Créez des relations un-à-plusieurs de chaque dimension vers la table de pont. Sachez que les tables de transition peuvent entraîner un double comptage ; associez-les à des mesures DISTINCTCOUNT ou utilisez CROSSFILTER dans DAX pour contrôler la propagation du filtre. Testez minutieusement avec des données connues pour vous assurer que les totaux sont corrects.

Dois-je créer des colonnes calculées ou des mesures DAX ?

Préférez les mesures aux colonnes calculées dans presque tous les cas. Les mesures sont calculées au moment de la requête et ne consomment pas de stockage. Les colonnes calculées sont calculées lors de l'actualisation et stockées en mémoire, augmentant ainsi la taille du modèle. Utilisez les colonnes calculées uniquement lorsque vous avez besoin de la valeur disponible pour le filtrage, le tri ou les relations (vous ne pouvez pas filtrer par mesure dans un slicer, mais vous pouvez filtrer par colonne calculée). Une exception courante est une colonne concaténée pour les étiquettes au niveau des lignes (FullName = FirstName + " " + LastName) dont les utilisateurs ont besoin dans les segments ou les visuels de tableau.

Comment les groupes de calcul interagissent-ils avec les mesures existantes ?

Les groupes de calcul interceptent l’évaluation de la mesure en encapsulant la mesure dans l’expression de l’élément de calcul. Lorsqu'un visuel contient une mesure et un groupe de calcul, Power BI applique l'élément de calcul à la mesure via la fonction SELECTEDMEASURE(). Cela signifie que vos mesures de base n'ont pas besoin d'être modifiées. Cependant, pour les mesures qui contiennent déjà une intelligence temporelle (comme une mesure YTD codée en dur), le groupe de calcul sera appliqué en haut, ce qui pourrait produire une double application. Pour éviter cela, définissez uniquement des mesures de base (agrégations simples) et utilisez des groupes de calcul exclusivement pour toute l'intelligence temporelle et la logique de comparaison.