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
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- On ne peut pas gouverner ce qu’on ne peut pas voir : pourquoi la visibilité doit-elle passer avant la gouvernance en matière de sécurité des identités ?
- L’IA amplifie les risques sur les API
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Nomios accélère sur la cybersécurité industrielle avec un SOC renforcé et une Factory OT immersive
Articles les + lus
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 Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- 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 Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
