Entrepôt de données - Table de dimension - Modèles courants

Lors du référencement de données provenant d’un registre de métadonnées tel que ISO/IEC 11179, des termes de représentation tels qu’Indicateur (une valeur booléenne vrai/faux), Code (un ensemble de valeurs énumérées non superposées) sont généralement utilisés comme dimensions. Par exemple, en utilisant le modèle national d’échange d’informations (NIEM), le nom de l’élément de données serait PersonGenderCode et les valeurs énumérées seraient masculin, féminin et inconnu.

Table de dimension

Dans l’entreposage de données, une table de dimension est l’une des tables associées à une table de faits.

La table de faits contient des faits métier (ou mesures) et des clés étrangères qui font référence à des clés candidates (généralement des clés primaires) dans les tables de dimension.

Contrairement aux tables de faits, les tables de dimension contiennent des attributs descriptifs (ou champs) qui sont généralement des champs textuels (ou des nombres discrets qui se comportent comme du texte). Ces attributs sont conçus pour servir deux objectifs essentiels : la restriction et/ou le filtrage des requêtes et l’étiquetage des ensembles de résultats de requête.

Les attributs de dimension doivent être :

Verbeux (étiquettes composées de mots entiers)
Descriptifs
Complets (sans valeurs manquantes)
À valeur discrète (avec une seule valeur par ligne de table de dimension)
De qualité garantie (sans fautes d’orthographe ni valeurs impossibles)

Les lignes de la table de dimension sont identifiées de manière unique par un seul champ clé. Il est recommandé que le champ clé soit un entier simple, car une valeur clé n’a pas de sens, utilisée uniquement pour joindre des champs entre les tables de faits et de dimension. Les tables de dimension utilisent souvent des clés primaires qui sont également des clés de substitution. Les clés de substitution sont souvent générées automatiquement (par exemple, une « colonne d’identité » Sybase ou SQL Server, un numéro de série PostgreSQL ou Informix, une SEQUENCE Oracle ou une colonne définie avec AUTO_INCREMENT dans MySQL).

L’utilisation de clés de dimension de substitution présente plusieurs avantages, notamment :

Le traitement des jointures est rendu beaucoup plus efficace en utilisant un seul champ (la clé de substitution)
Mise en mémoire tampon des pratiques de gestion des clés opérationnelles. Cela évite les situations dans lesquelles des lignes de données supprimées peuvent réapparaître lorsque leurs clés naturelles sont réutilisées ou réaffectées après une longue période d’inactivité
Mappage pour intégrer des sources disparates
Gestion des connexions inconnues ou non applicables
Suivi des modifications des valeurs d’attribut de dimension

Bien que l’utilisation de clés de substitution représente une charge pour le système ETL, le traitement du pipeline peut être amélioré et les outils ETL ont intégré un traitement amélioré des clés de substitution.

L’objectif d’une table de dimension est de créer des dimensions standardisées et conformes qui peuvent être partagées dans l’environnement d’entrepôt de données de l’entreprise et permettre la jointure à plusieurs tables de faits représentant divers processus métier.

Les dimensions conformes sont importantes pour la nature d’entreprise des systèmes DW/BI car elles favorisent :

Cohérence. Chaque table de faits est filtrée de manière cohérente, de sorte que les réponses aux requêtes sont étiquetées de manière cohérente.
Intégration. Les requêtes peuvent explorer différentes tables de faits de processus séparément pour chaque table de faits individuelle, puis joindre les résultats sur des attributs de dimension communs.
Réduction du temps de développement jusqu’au marché. Les dimensions communes sont disponibles sans les recréer.

Au fil du temps, les attributs d’une ligne donnée dans une table de dimension peuvent changer. Par exemple, l’adresse de livraison d’une entreprise peut changer. Kimball appelle ce phénomène Dimensions à évolution lente. Les stratégies pour gérer ce type de changement sont divisées en trois catégories :

Type 1. Il suffit de remplacer les anciennes valeurs.
Type 2. Ajoutez une nouvelle ligne contenant les nouvelles valeurs et faites la distinction entre les lignes à l’aide de techniques de versionnage de tuple.
Type 3. Ajoutez un nouvel attribut à la ligne existante.

Modèles courants

Date et heure

Étant donné que de nombreuses tables de faits dans un entrepôt de données sont des séries chronologiques d’observations, une ou plusieurs dimensions de date sont souvent nécessaires. L’une des raisons d’avoir des dimensions de date est de placer les connaissances du calendrier dans l’entrepôt de données au lieu de les coder en dur dans une application. Bien qu’une simple date/horodatage SQL soit utile pour fournir des informations précises sur l’heure à laquelle un fait a été enregistré, elle ne peut pas donner d’informations sur les jours fériés, les périodes fiscales, etc. Une date/horodatage SQL peut toujours être utile à stocker dans la table de faits, car elle permet des calculs précis.

Le fait d’avoir à la fois la date et l’heure du jour dans la même dimension peut facilement donner lieu à une dimension énorme avec des millions de lignes. Si une grande quantité de détails est nécessaire, il est généralement judicieux de diviser la date et l’heure en deux ou plusieurs dimensions distinctes. Une dimension temporelle avec un grain de secondes dans une journée n’aura que 86 400 lignes. Un grain plus ou moins détaillé pour les dimensions date/heure peut être choisi en fonction des besoins. Par exemple, les dimensions de date peuvent être précises à l’année, au trimestre, au mois ou au jour et les dimensions d’heure peuvent être précises à l’heure, à la minute ou à la seconde.

En règle générale, la dimension d’heure de la journée ne doit être créée que si des regroupements hiérarchiques sont nécessaires ou s’il existe des descriptions textuelles significatives pour les périodes de la journée (par exemple, « pointe du soir » ou « premier quart de travail »).

Si les lignes d’une table de faits proviennent de plusieurs fuseaux horaires, il peut être utile de stocker la date et l’heure à la fois en heure locale et en heure standard. Cela peut être fait en ayant deux dimensions pour chaque dimension date/heure nécessaire : une pour l’heure locale et une pour l’heure standard. Le stockage de la date/heure à la fois en heure locale et en heure standard permettra d’analyser le moment où les faits sont créés dans un contexte local et dans un contexte global également. L’heure standard choisie peut être une heure standard mondiale (par exemple, UTC), l’heure locale du siège social de l’entreprise ou tout autre fuseau horaire qu’il serait judicieux d’utiliser.

Source: Drew Bentley, Business Intelligence and Analytics. © 2017 Library Press, License CC BY-SA 4.0. Traduction et adaptation: Nicolae Sfetcu. © 2024 MultiMedia Publishing, L’informatique décisionnelle et l’analyse exploratoire des données dans les entreprises, Collection Sciences de l’information