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

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
