Lorsque nous commençons un projet d'entreposage de données, la première chose que nous faisons est de définir les tables dimensionnelles. Les tableaux dimensionnels sont les éléments intéressants, le cadre autour duquel nous construisons nos mesures. Ils viennent dans de nombreuses formes et tailles. Dans cet article, nous allons examiner de plus près chaque type de tableau dimensionnel.
Les tableaux dimensionnels fournissent un contexte aux processus métier que nous souhaitons mesurer. Ils nous disent tout ce que nous devons savoir sur un événement. Puisqu'ils donnent de la substance aux mesures (c'est-à-dire aux tables de faits) du système d'entrepôt de données (DWH), nous passons plus de temps sur leur définition et leur identification que sur tout autre aspect du projet. Tables de faits définir les mesures; les tableaux dimensionnels donnent le contexte. (Pour en savoir plus sur les tables de faits, consultez ces articles sur l'entreposage de données, le schéma en étoile, le schéma en flocon de neige et les faits sur les tables de faits).
La principale caractéristique des tables de dimension est leur multitude d'attributs . Les attributs sont les colonnes que nous résumons, filtrons ou agrégeons. Ils ont une faible cardinalité et sont généralement textuels et temporels. Les tables dimensionnelles ont une clé primaire basée sur la clé métier sous-jacente ou une clé de substitution . Cette clé primaire est la base pour joindre la table de dimension à une ou plusieurs tables de faits.
Par rapport aux tables de faits, les tables de dimension sont de petite taille, faciles à stocker et ont peu d'impact sur les performances.
Examinons maintenant certaines des tables de dimensions que vous rencontrerez dans un environnement d'entrepôt de données.
Un tableau dimensionnel commun :la dimension conforme
Commençons par un type de base :la dimension conformée. Ceux-ci contiennent plusieurs attributs, qui peuvent être adressés dans plusieurs tables source mais qui font référence au même domaine (client, contrat, transaction, etc.) Les dimensions conformes sont utilisées avec de nombreux faits et doivent être uniques pour la valeur du grain/domaine dans l'entrepôt de données.
Exemple :
Regardons une table dimensionnelle typique, DIM_CUSTOMER .
Nous définissons :
id– La clé primaire de la table de dimension.cust_natural_key– La clé naturelle pour le client.first_name– Le prénom du client.last_name– Le nom de famille du client.address_residence– L'adresse résidentielle du client.date_of_birth– La date de naissance du client.marital_status– Le client est-il marié ? Défini comme O (oui) ou N (non).gender– Le sexe du client, M (homme) ou F (femme).
Les attributs de la table de dimension dépendent des besoins de l'entreprise. Nous pouvons étendre ce type de tableau pour contenir des informations spécifiques à l'industrie (date de défaut, activité, etc.)
Tableaux dimensionnels à évolution lente
Au fil du temps, les dimensions peuvent changer leurs valeurs. Dans les paragraphes suivants, nous examinerons les dimensions classées selon la manière dont elles stockent (ou ne stockent pas) les données historiques.
Disons que vous avez une dimension client. Certains attributs changeront probablement au cours de la vie du client - par ex. numéro de téléphone, adresse, état civil, etc. Ce type de tableau est ce que Ralph Kimball appelle une dimension à évolution lente, ou SCD.
Le SCD se décline en plusieurs types; huit d'entre eux sont assez courants. Parmi ceux-ci, vous verrez le plus les types 0 à 4; les types 5, 6 et 7 sont des hybrides des cinq premiers. (Remarque :le schéma de numérotation de ces SCD commence par un 0 au lieu d'un 1.)
Les détecteurs SCD hybrides offrent plus de flexibilité et de meilleures performances, mais au détriment de la simplicité. Nous utilisons ces types de tableaux lorsque nous devons effectuer une analyse analytique de courant données avec quelques historiques considérations.
Type 0 de SCD :remplissage unique
Il s'agit du type le plus basique de tableau de dimensions :vous le remplissez une fois et jamais remplissez-le à nouveau. Considérez cela comme des données de référence. Un exemple typique de ceci est la dimension de date. Nous n'avons pas besoin de remplir cette dimension avec chaque charge DWH. La table dimensionnelle ne change pas avec le temps. Vous ne pouvez pas obtenir plus de dates ou modifier les dates.
La table de faits se connecte aux attributs d'origine de la dimension.
Exemple
Regardons la dimension temporelle :
La structure est assez simple :
id– Clé de substitutiontime_date– Date réelletime_day– Jour du moistime_week– Semaine dans l'annéetime_month– Mois dans une annéetime_year– Représentation numérique d'une année
Type 1 de SCD :réécriture des données
Comme son nom l'indique, nous réécrivons ce type de tableau dimensionnel à chaque charge DWH. Nous n'avons pas besoin d'en garder un historique, mais nous nous attendons à ce qu'il y ait des changements.
La différence entre un SCD de type 0 et un type 1 n'est pas dans la structure du tableau. Cela a à voir avec le rafraîchissement des données. Vous ne rafraîchissez jamais les données dans un Type 0, mais vous le faites parfois dans un Type 1.
Une table réinscriptible est le moyen le plus simple de gérer les modifications (suppression/insertion), mais elle ajoute peu de valeur commerciale. Une fois que vous avez défini une table de dimension comme celle-ci, il est difficile d'installer le traçage historique.
La table de faits se connecte aux attributs actuels de la dimension.
Exemple
Examinons la dimension du compte :
Sa structure est la suivante :
id– La clé de substitution de la tableaccount_name– Le nom du compteaccount_type– La catégorie du compteaccount_activity– Signale différents types d'activité
Si nous examinons les données avant le changement, nous verrions ceci :
Si le type de compte a changé, les données seraient simplement écrasées :
Type 2 de SCD :suivi des attributs historiques par ligne
Il s'agit de la forme la plus courante de suivi historique dans un système DWH. Les tableaux SCD de type 2 ajoutent de nouvelles lignes pour chaque changement historique d'attributs dimensionnels entre Charges ECS . Dans ce type, nous définissons la clé primaire comme une clé de substitution car la clé métier aura plusieurs représentations dans le temps. Lorsque les lignes contenant le changement de données sont modifiées, nous définissons une nouvelle valeur pour la clé de substitution qui correspond à la valeur dans la table de faits. Nous devons ajouter au moins deux colonnes, valid_from et valid_to , pour stocker l'historique de cette manière.
La table de faits se connecte aux attributs historiques de la dimension via la clé de substitution. L'agrégation se fait sur la clé naturelle .
Exemple
Examinons le tableau de dimension client précédent, maintenant élargi avec deux colonnes de date :
Regardons les données :
Points à considérer :
- Comment pouvons-nous marquer la ligne actuelle,
valid_to? (Généralement avec 31.12.9999, ou NULL .) - Comment pouvons-nous marquer la première ligne,
valid_from? (Généralement avec 01.01.1900, ou la date de la première insertion). - Définissez-vous une ligne inclusive ou exclusive ? (Ci-dessus, nous utilisons un
valid_frominclusif et unvalid_toexclusif ).
Type 3 de SCD :suivi des attributs historiques par colonne
Comme avec le SCD de type 2, ce type ajoute quelque chose pour représenter les valeurs historiques. Dans ce cas, cependant, nous ajoutons de nouvelles colonnes. Ceux-ci représentent la valeur d'un attribut de ligne dimensionnelle avant qu'il ne change. Habituellement, nous ne conservons que la version précédente de l'attribut.
Remarque :Ce SCD est rarement utilisé.
La table de faits se connecte aux attributs actuels et précédents de la dimension.
Exemple
Examinons la dimension client, cette fois avec une ancienne adresse résidentielle :
Dans cet exemple, nous avons ajouté une nouvelle colonne, previous_address_residence , pour représenter l'ancienne adresse du client. Si nous regardons notre exemple initial, les données de ce tableau ressembleraient à ceci :
Toutes les informations historiques, à l'exception de l'adresse précédente du client, sont perdues.
Type 4 de SCD :ajout d'une mini-dimension
Ce type de dimension n'est pas basé sur des modifications structurelles (Type 3) ou sur des valeurs (Type 2). Au contraire, il est basé sur les modifications de conception du modèle. Si notre tableau dimensionnel contient des données très volatiles - c'est-à-dire des données qui changent fréquemment - la taille du tableau dimensionnel augmentera considérablement.
Afin d'atténuer cela, nous extrayons les attributs volatils dans une mini-dimension . Ces mini-dimensions pourraient ensuite être agrégées au niveau pertinent pour l'entreprise. Cependant, cette agrégation ne devrait pas être confondu avec l'agrégation de faits . L'exemple éclaircira cela.
La table de faits se connecte aux attributs historiques de la dimension.
Exemple
Regardons un exemple tiré d'un simple magasin de données financières. Supposons que vous ayez besoin de suivre le retard de paiement de certains clients. Appelons cet attribut jours de retard ou DPD. Si nous devions suivre DPD tous les jours dans une dimension de type 2, la taille du tableau exploserait bientôt au-delà des limites gérables. Nous extrayons donc l'attribut et trouvons des périodes de DPD pertinentes pour l'entreprise - disons par incréments de 30 jours (0-30 DPD, 30-60 DPD, 60-90 DPD, etc.)
Nous pouvons prendre d'autres attributs à forte volatilité, tels que l'âge, et leur construire également des périodes pertinentes pour l'entreprise (par exemple, 20-30 ans, 30-40 ans, etc.)
Si nous examinons les données dans la mini-dimension client, nous aurions quelque chose comme ceci :
Les attributs sont :
id– Clé primaire de substitutionDPD_period– Jours de retard de paiementDEM_period– Période démographique
Le schéma en étoile simple ressemblerait à ceci :
Notez que pour effectuer des analyses sur les attributs des deux tables, nous devons les relier via la table de faits.
SCD Type 5 :Création d'une mini-dimension avec une extension réinscriptible
Il s'agit de la première de nos constructions de tables dimensionnelles hybrides. Dans un SCD de type 5, nous ajoutons la version actuelle des données mini-dimensionnelles à la table dimensionnelle. Nous devons garder à l'esprit que nous n'ajouterons que le courant représentation de la mini-dimension à la dimension principale.
Nous rechargeons cette extension de mini-dimension à chaque chargement (le SCD "réinscriptible" de type 1).
Bien que l'historisation de cette extension puisse très bien entraîner des problèmes de taille, nous les avons déjà atténués avec le tableau des mini-dimensions.
Nous utilisons cette technique lorsque nous voulons faire des analyses directement sur les tables de dimensions.
Exemple
En développant l'exemple précédent avec la mini-dimension actuelle, nous obtenons :
Le dim_mini_customer_current table contient les valeurs d'attribut les plus récentes qui correspondent au dim_customer table. Nous pouvons désormais effectuer des analyses spécifiques au client sans passer par la table des faits (ce qui est très lent).
La table de faits se connecte aux attributs historiques de la dimension.
Type 6 :dimension de type 2 (ligne historique) avec un attribut réinscriptible
Il s'agit d'une construction dimensionnelle très courante. Nous ajoutons un attribut qui stocke une chose, généralement la dernière valeur connue, que nous réécrivons à chaque chargement. Cela nous permet de regrouper tous les faits par leur valeur actuelle, tandis que l'attribut historique affiche les données telles qu'elles étaient lorsque les événements se sont produits.
La table de faits se connecte aux valeurs dimensionnelles au moment de l'événement avec des valeurs dimensionnelles actuelles supplémentaires.
Exemple
Développons la table client précédente avec un current_address_residence colonne.
Nous avons maintenant un attribut que nous allons mettre à jour à la valeur actuelle, en utilisant la clé naturelle (cust_natural_key ).
Type 7 :Dimensions de type 2 (ligne historique) avec un miroir actuel
Nous ne pouvons utiliser ce type que s'il existe une clé naturelle dans la dimension du tableau. La clé ne doit pas changer pendant la durée de vie de l'entité.
L'idée est simple :nous ajoutons une représentation actuelle de la table dimensionnelle au schéma en flocon de neige. Ensuite, nous insérons la clé naturelle de la nouvelle dimension dans la table de faits. (La clé de substitution de la dimension historique est toujours présente.)
La table de faits se connecte aux valeurs dimensionnelles au moment de l'événement et aux valeurs dimensionnelles actuelles.
Exemple
Regardons notre schéma en étoile de compte client. Nous ajoutons la nouvelle dimension, dim_current_customer , à la table de faits. Cette table est connectée à la table de faits via une clé naturelle, cust_natural_key .
Cette construction nous permet de faire des requêtes analytiques sur le schéma en étoile avec les valeurs actuelles et historiques des attributs client.
Dimensions du domaine
Une dimension de domaine est une forme simple de table dimensionnelle. Il contient des informations sur le domaine de la mesure sous-jacente d'un attribut dimensionnel. Ces tables stockent divers codes et valeurs explicatives.
Exemple
Un exemple simple serait une table de devises.
Dans ce tableau, nous stockons des informations descriptives sur diverses unités monétaires.
À mon avis, la meilleure utilisation de la dimension de domaine est dans la documentation des valeurs de données que nous trouvons dans le système DWH.
Dimensions indésirables
Les systèmes sources transactionnels génèrent de nombreux indicateurs et drapeaux. Ces attributs peuvent être considérés comme des données catégorielles, mais ils ne sont ni pertinents pour l'entreprise ni explicites. Nous pouvons classer tous ces indicateurs et drapeaux dans un tableau unidimensionnel appelé dimension indésirable . La dimension indésirable est l'alternative à l'utilisation de dimensions dégénérées. Si nous ne voulons pas alourdir la table de faits avec de nombreuses dimensions dégénérées, nous créons une dimension indésirable.
Il convient de noter que nous ne remplissons pas toutes les combinaisons possibles d'indicateurs et de drapeaux. Nous ne remplissons que ceux qui existent dans le système source.
Exemple
Les tables de dimension sont les squelettes du monde de l'entreposage de données :tout est construit autour d'elles. Elles ne sont pas aussi grandes que les tables de faits, mais leur structure peut être plus complexe.
Vous pouvez assembler de nombreux types de tableaux de dimensions, même au-delà de ceux dont nous venons de parler. Qu'en est-il de votre entreprise et de votre industrie? Si vous avez combiné des types de tableaux dimensionnels en quelque chose de nouveau, parlez-nous-en !
