Modèle multidimensionnel vs tabulaire

Différences fondamentales entre les deux approches

Un modèle multidimensionnel, dont le cube OLAP reste un classique utilisé dans les plateformes comme SQL Server Analysis Services (SSAS) ou Oracle Essbase, organise les données autour de mesures agrégées et de dimensions hiérarchisées.

On y trouve plusieurs éléments permettant de favoriser les agrégations rapides sur des axes multiples :

Des mesures précalculées : ce sont des valeurs numériques, comme le chiffre d’affaires ou le nombre de ventes, qui sont agrégées et stockées à l’avance dans le cube OLAP pour garantir des temps de réponse ultra-rapides lors des requêtes.
Des hiérarchies d’attributs : elles organisent les données de manière logique et arborescente (par exemple, année → trimestre → mois → jour). Ces structures facilitent l’exploration des données à différents niveaux de granularité, permettant de passer facilement du général au particulier.

Exemple :

(Date → Année → Trimestre → Mois → Jour, Produit → Catégorie - Famille - Article)

Des membres calculés : des éléments de données qui n’existent pas dans les données brutes, mais qui sont créés à l’aide de formules basées sur d’autres membres. Par exemple : un membre « marge brute » pourrait être calculé en soustrayant les « Coûts » des « Revenus »
Des jeux nommés : il s’agit de membres qui sont définis et enregistrés...

Langages de requêtage : MDX vs DAX

Le MDX, langage natif des cubes, est puissant et permet d’exprimer une requête en termes d’axes (colonnes, lignes, pages), de membres, de tuples et d’ensembles, mais reste très complexe. On peut définir des membres calculés sur les axes ou interroger des mesures, ou également des règles de calcul spécifiques pour une partie de la hiérarchie. L’évaluation est donc dite multi-pass, où le moteur gère les conflits. On peut définir une règle générale puis la surcharger pour une partie de la hiérarchie.

Par exemple, dans la gestion des ressources humaines : on peut définir une règle de commission de 10 % sur les ventes pour tous les commerciaux, et ensuite la surcharger pour un ou deux commerciaux clés qui bénéficient d’une commission de 15 %. Ceci permet de gérer ces cas spécifiques sans avoir à ajouter une colonne commission qui sera la même pour toutes les lignes à l’exception d’un ou deux commerciaux.

Cette flexibilité a un coût, le MDX est un langage dense et peut être difficile à maîtriser, car les erreurs de granularité sont fréquentes. Si une formule est conçue pour un niveau de détail, mais qu’elle est appliquée à un autre niveau, cela peut coûter cher en performance.

Lors d’une optimisation d’un cube, il faut regarder autant les index et les agrégations...

Stockage : OLAP en colonnes vs stockage en ligne

Comme évoqué durant ce chapitre, la principale différence entre les deux modèles réside dans la façon dont les données sont posées sur disque et en mémoire, et comment cela influe sur les requêtes.

L’idée est de voir à travers un exemple concret comment décliner ces différences pour ces trois angles :

Stockage en ligne : SGBD relationnel classique
Stockage en colonnes : que ce soit en VertiPaq/ xVelocity côté tabulaire ou en columnstore côté SQL (cf. chapitre Optimisation des performances des cubes OLAP - Indexation et partitionnement des tables).
Cubes multidimensionnels : MOLAP, ROLAP ou HOLAP.

L’idée est de se concentrer sur le stockage et ses effets mécaniques avec du SQL, MDX ou DAX là où cela aide à bien remarquer les différences.

Pour cet exemple, on choisira un schéma en étoile simple qui servira de jeu de données de référence pour la suite :

-- Tables de dimensions
CREATE TABLE dbo.DimDate (
    DateKey       int        NOT NULL PRIMARY KEY,   -- 20250131
    Date          date       NOT NULL,
    Year          smallint   NOT NULL,
    Quarter       tinyint    NOT NULL,
    Month         tinyint    NOT NULL,
    MonthName     varchar(10) NOT NULL
);
 
CREATE TABLE dbo.DimProduct (
    ProductKey    int         NOT NULL PRIMARY KEY,
    SKU           varchar(25) NOT NULL,      -- souvent cardinalité élevée
    Brand         varchar(40) NOT NULL...

Performance et gestion des relations dans un modèle tabulaire

1. Contexte, périmètre et modèle de référence

Cette section ne traite pas du format de stockage (colonnes vs lignes, cf. Modèle multidimensionnel vs tabulaire - Stockage : OLAP en colonnes vs stockage en ligne), mais de l’interaction entre le graphe de relations, la propagation des filtres et la sémantique des mesures DAX. Une modélisation imprécise peut décupler les temps de réponse, tandis qu’une architecture sobre et maîtrisée maintient des latences faibles et des résultats fiables.

Afin d’éviter l’abstraction pure, l’argumentation s’appuie sur un modèle en étoile volontairement concret :

Table de faits : faitVentes avec DateKey, ProduitKey, ClientKey, 
MagasinKey, Quantité, Prix Unitaire, Montant 
Dimensions Principales : 
DimDate : DateKey, Date, Année, Mois,... 
DimProduit : ProduitKey, Catégorie, Marque, ... 
DimClient : ClientKey, Secteur,....
DimMagasin : MagasinKey, Region, ... 
Dimension comportementale : DimSegment, destinée à représenter 
des segmentations marketing et à introduire des situations plusieurs à 
plusieurs contrôlées avec les clients.

Le schéma de départ est une étoile classique, avec des relations unidirectionnelles 1-n, dans toute la suite, nous nous concentrons sur :

la propagation des filtres sur le graphe relationnel,
la définition et l’évaluation des mesures DAX,
la stabilité des résultats (exactitude, non doublons) et la scalabilité, c’est-à-dire stabiliser le temps de réponse même lors de pics de charge.

Les filtres doivent se propager de la dimension vers la table de faits, dans un seul sens. Car les relations bidirectionnelles créent plusieurs chemins de propagation, ouvrant la porte aux doublons et aux agrégats incohérents. Aussi, elles forcent le moteur à explorer davantage de combinaisons, ce qui augmente la latence souvent...

Cas pratique : migration d’un cube OLAP vers un modèle tabulaire

La transition d’un modèle multidimensionnel, souvent perçu comme rigide et complexe, vers un modèle tabulaire, plus souple et performant, représente une évolution majeure dans le domaine de l’informatique décisionnelle. Ce n’est pas simplement un changement technique. C’est une transformation dans la manière d’interroger et d’interagir avec la donnée. Pour illustrer ce processus, un cas d’étude concret est présenté : celui d’une entreprise de vente au détail fictive, « Au Bon Marché », qui souhaite moderniser son système de rapport sur les ventes.

Actuellement, « Au Bon Marché » utilise un cube OLAP SQL Server Analysis Services (SSAS) multidimensionnel nommé « VentesCube ». Ce cube est la source de vérité pour tous les rapports de ventes, mais il montre des signes de vieillesse : les temps de traitement nocturnes s’allongent, certaines requêtes complexes prennent plusieurs minutes à s’exécuter, et les analystes métier se sentent limités par la structure prédéfinie des hiérarchies. La décision est prise de migrer vers un modèle tabulaire, qui sera hébergé sur Power BI, afin de bénéficier de la puissance du moteur VertiPaq et de la flexibilité du langage DAX. L’objectif de ce cas pratique est de détailler, de manière pragmatique, les étapes de cette migration, en mettant en lumière les défis et les solutions apportées.

1. L’analyse et la compréhension du modèle existant

La toute première phase, et sans doute la plus critique, consiste à réaliser une autopsie complète du cube OLAP existant. Il est impossible de reconstruire une maison sans connaître ses plans originaux. Cette étape implique de documenter chaque élément du cube «VentesCube ». Quelles sont les dimensions (Temps, Produit, Magasin, Client) ? Quels sont les attributs et les hiérarchies dans chaque dimension (par exemple, dans Produit : Produit → Sous-catégorie → Catégorie) ? Et surtout, quelles...