Gestion des clés primaires et clés étrangères

Dans un modèle multidimensionnel, les relations entre faits et dimensions jouent un rôle prépondérant dans la précision analytique et la performance des requêtes.

Que ce soit dans un modèle en étoile ou en flocon, la qualité de ces relations repose sur une gestion efficace des clés.

Les dimensions peuvent utiliser des clés entreprises, qu’elles soient simples, composites ou encore des clés artificielles (surrogate keys). Ces clés doivent faire référence à une et une seule ligne de la dimension.

La table de fait quant à elle va utiliser cette clé sous forme d’une clé étrangère pour garantir un lien exact entre l’agrégat et les jointures. C’est-à-dire que chaque ligne de la table de fait devra faire référence à une clé primaire valide dans la table de dimension. Cette correspondance garantira l’exactitude des résultats analytiques.

Voici les types de clés primaires dans une dimension.

1. Clés entreprises simples

Une clé entreprise simple correspond à l’identifiant naturel donné par le système source pour identifier, de façon unique, une entité.

Exemple

La table source des produits utilise un code produit unique alphanumérique fourni par l’ERP de l’entreprise.

Code_Produit	Nom_Produit	Catégorie	Marque
P12345	Ordinateur Portable	Informatique	Acer
P12346	Souris Bluetooth	Accessoires	Logitech

Dans ce cas-là, le code produit sera utilisé dans la dimension puis reproduit dans la table de fait en tant que clé étrangère.

Cependant, d’un point de vue architectural, s’appuyer structurellement sur une clé naturelle présente de lourdes limites :

Problématique d’historisation (SCD) : la traçabilité historique devient impossible à gérer. Si un produit change de catégorie ou de nom mais conserve le même code métier, il est impossible de créer une nouvelle ligne d’historique dans la dimension.
Risque de collision multi-sources : si l’entrepôt intègre demain un second système source, le même code naturel pourrait désigner deux...

Relations entre plusieurs tables de faits

1. Drill-across et gestion des niveaux de granularité

Dans les structures décisionnelles élaborées, on rencontre souvent plusieurs tables de faits, chacune étant associée à des processus d’affaires spécifiques ou à différents niveaux de détail.

L’approche du drill-across autorise un utilisateur à examiner plusieurs tables de faits simultanément, en les liant par le biais de leurs dimensions partagées.

À la différence du drill-down qui explore en profondeur une même table, le drill-across permet de naviguer horizontalement d’une table de faits à une autre.

Exemple

Supposons une entreprise de distribution qui possède deux tables de faits :

Table des ventes quotidiennes :

Date	Magasin	Produit	Quantité_Vendue	Chiffre_Affaires
2025-06-01	Paris	P12345	5	250
2025-06-01	Lyon	P67890	3	90

Table des retours produits mensuels :

Mois	Catégorie	Nombre_Retours
2025-06	Informatique	15
2025-06	Accessoires	4

Pour pouvoir croiser les données de la table des ventes quotidiennes avec la table des retours produits mensuels, il faudra utiliser une dimension commune de la même granularité (ici, une dimension temps au mois) afin d’uniformiser les niveaux de détail des deux tables.

Pour le faire, nous devons agréger la table la plus détaillée (ici la table des ventes quotidiennes) au mois.

TSQL : 
SELECT 
   FORMAT(Date, 'yyyy-MM') AS Periode, 
   Catégorie, 
   SUM(Quantité_Vendue) AS Total_Ventes, 
   SUM(Chiffre_Affaires) AS CA 
FROM Ventes 
JOIN Produit ON Ventes.Produit = Produit.Code_Produit  
GROUP BY FORMAT(Date, 'yyyy-MM'), Catégorie;

Periode	Catégorie	Quantité_Vendue	Chiffre_Affaires
2025-06	Informatique	5	250
2025-06	Accessoires	3	90

En résultat, nous pouvons donc faire apparaître les retours de commandes ainsi que les ventes d’articles par catégorie dans un seul tableau.

Periode	Catégorie	Quantité_ Vendue	Chiffre_ Affaires	Nombre_ Retours
2025-06	Informatique	5	250	15
2025-06	Accessoires	3	90	4

Le drill-across est une fonctionnalité très puissante pour les analyses mais reste très dépendante...

Relations plusieurs-à-plusieurs dans un modèle OLAP

Les modèles OLAP classiques partent du principe que chaque fait est associé à une instance unique dans chaque dimension. Toutefois, des situations plus compliquées se présentent, en particulier quand un fait doit être associé à plusieurs éléments d’une dimension donnée.

Prenons l’exemple d’une vente à distance : une seule commande globale peut inclure plusieurs produits différents. Si notre table de faits est modélisée au grain de la commande (1 ligne = 1 commande), nous sommes face à une relation plusieurs-à plusieurs (N-n) avec la dimension Produit.

Relation n-n

Pour modéliser cette situation, différentes techniques existent.

1. Table de pont (bridge table)

La table de pont, ou bridge table, est une structure intermédiaire utilisée en modélisation multidimensionnelle pour représenter une relation de type many-to-many entre une table de faits et une dimension. Elle permet de relier ces deux tables lorsque, par exemple, un enregistrement de faits peut correspondre à plusieurs éléments d’une dimension, et inversement. Ce dispositif offre la possibilité de conserver la granularité souhaitée tout en assurant un lien précis vers les dimensions concernées. Dans le cadre d’analyses...

Réduction des jointures complexes et optimisation des performances

Les jointures sont très utiles. Néanmoins, elles peuvent devenir coûteuses en termes de performance, et spécialement lorsque les tables de faits et dimensions sont massives, nombreuses ou hiérarchisées.

Les stratégies les plus utilisées pour optimiser ces situations sont les suivantes.

1. Dénormalisation

La dénormalisation consiste à ajouter de la redondance aux tables pour éviter les jointures. Au lieu de stocker les données dans des tables séparées pour des raisons de normalisation, on les regroupe dans une seule table.

Bien que la dénormalisation puisse augmenter les volumes de données stockées, elle permet de simplifier les requêtes et améliore la performance des lectures et accélère le temps d’exécution.

Par exemple :

Tables normalisées :

Table dénormalisé :

2. Vues matérialisées

Une vue matérialisée est une vue qui stocke les résultats de sa requête sous forme de table physique. Contrairement à une vue standard qui exécute sa requête à chaque fois qu’elle est interrogée, une vue matérialisée précalcule les données et les stocke, ce qui peut accélérer considérablement les requêtes...

Optimiser les relations faits et dimensions