Dans le système transactionnel, les attributs et hiérarchies sont souvent parfaitement normalisés en tables distinctes qui utilisent des clés étrangères pour la liaison avec les produits. Nous créons des tables de dimension sur la plate-forme relationnelle en dénormalisant les attributs descriptifs et hiérarchies en une table pour chaque dimension. Ces
Faits et dimensions (3)
dimensions dénormalisées continuent de présenter les mêmes informations et relations que le modèle normalisé. Rien n’est perdu en cours de route, si ce n’est la complexité.
Même avec une simple dimension Product, telle que celle de la figure 2, il est facile d’imaginer de quelle manière les attributs seront utilisés en tant qu’en-têtes de lignes et de colonnes dans une requête ou un rapport. Par exemple, la demande d’un utilisateur de voir les montants des commandes par couleur et taille révélerait des modèles de commande entre la taille et la couleur. Les moyens naturels employés par les utilisateurs finaux pour décrire leur activité doivent trouver leur place dans les attributs de dimension.
La dimension Product de la figure 2 semble avoir deux clés : ProductKey (clé produit) et ProductBusinessKey (clé activité produits). La première est la clé primaire de la table de dimension et constitue une clé de substitution, généralement un entier, qui est ajoutée dans le cadre du processus de création de la table de dimension. ProductBusinessKey est la clé provenant du système transactionnel.
Même si l’inclusion des deux clés peut sembler redondante, il existe plusieurs raisons essentielles pour affecter et gérer vos propres clés de substitution :
• Elles permettent d’isoler le système de data warehouse et d’analyse décisionnelle des changements opérationnels tels qu’une fusion, une acquisition ou une migration du système.
• Vous pouvez ajouter des lignes de dimension pour des valeurs telles que Not Applicable (non applicable) ou Date TBD (Date à définir), absentes du système transactionnel.
• Les clés de substitution vous permettent d’intégrer les données de multiples sources susceptibles d’avoir différentes clés métier pour la même entité, par exemple un client.
• Dans certains cas, la clé de substitution à entier simple fournit de meilleures performances de jointure qu’une clé alphanumérique plus complexe. Si ces raisons ne suffisent pas, vous devez employer une clé de substitution si vous envisagez de suivre les changements des valeurs d’attributs au fil du temps.
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Mythos révèle les limites d’un Zero Trust centré sur le réseau
- Faire évoluer la souveraineté des données du statut d’ambition politique à son application opérationnelle
- Mythos et modèles-frontières : quel avenir pour la cybersécurité en France et en Europe face à l’IA ?
- IA agentique : des investissements massifs freinés par des données insuffisamment préparées
Articles les + lus
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Avril 2026
À la une de la chaîne Tech
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Avril 2026
