La dimension Client est probablement la dimension la plus compliquée d'un entrepôt de données. Dans une grande entreprise, la dimension Client peut être:
- profonde, avec des millions d'enregistrements
- large, avec des douzaines d'attributs
- avec des évolutions lentes, mais parfois des changements rapides
Pour aggraver les choses, dans les très grandes dimensions Clients nous avons souvent deux catégories de clients que j'appellerais Visiteurs et Clients.
Le visiteur est anonyme. Nous pouvons les voir plus d'une fois, mais nous ne savons pas leur nom ou quoi que ce soit à leur sujet. Sur un site web, tout ce que nous avons pour un visiteur est un cookie qui nous dit qu'il est de retour. Dans un commerce de détail, le visiteur s'engage dans une transaction anonyme. Peut-être que nous avons un numéro de carte de crédit ou d'une simple carte d'identité, mais nous supposons ici qu'aucune donnée démographique significative accompagne un visiteur.
Le client, en revanche, est parfaitement enregistré auprès de nous. Nous connaissons son nom, son adresse et d'autres informations que nous récupérons directement auprès d'eux ou que nous achetons à des tiers. Nous avons une adresse de livraison, un historique de paiement, et peut-être un historique de crédit pour chaque client.
Supposons qu'au niveau le plus fin, 80% des mesures de la table de faits concernent les visiteurs, et 20% les clients. Supposons en outre que nous accumulons de simples mesures de comportement pour les visiteurs consistant uniquement en la nouveauté (à quand remonte la dernière fois que nous les avons vus), la fréquence (combien de fois nous les avons vus) et l'intensité (le volume d'affaires que nous avons fait avec eux). Ainsi, dans cette conception simple, nous n'avons que trois attributs / mesures pour un visiteur.
D'autre part, nous allons supposer que nous avons 50 attributs / mesures pour un client, couvrant toutes les composantes de sa situation, le comportement de paiement et de crédit.
Faisons quelques hypothèses assez précises pour conserver l'intérêt d'un design épuré. Nous pourrons assouplir certaines de ces hypothèses plus tard ...
Tout d'abord, nous allons combiner visiteurs et clients en une seule dimension appelé Acheteur. Nous allons donner un ID Acheteur permanent pour chaque visiteur / client, mais la clé de la table est une clé de substitution afin que nous puissions suivre les changements à l'acheteur au fil du temps. Logiquement, notre dimension ressemble à cela:
- Attributs communs aux Visiteurs et aux Clients:
Clé de substitution Acheteur (nombre séquentiel pour chaque changement)
Clé Acheteur (identifiant permanent de l'acheteur)
Date de dernière visite (changement de type 1: écrasement)
Fréquence (nombre de visites, changement de type 1: écrasement)
Intensité (montant total des achats, changement de type 1)
- Attributs des Clients uniquement:
5 pour le nom (civilité, prénom, prénom secondaire, nom, genre)
10 pour la localisation (adresses)
5 pour le comportement de paiement
5 pour le comportement de crédit
10 informations récoltées auprès du client
15 informations achetés auprès de tiers
Une hypothèse forte que nous avons fait ici est d'inclure la dernière visite, la fréquence et l'intensité comme des attributs dimensionnels plutôt que comme des faits. De plus, nous les écrasons continuellement au fur et à mesure du temps (dimension à évolution lente de type 1). Cette hypothèse rend notre dimension Acheteur très puissante. Nous pouvons en faire la segmentation directement sur la dimension sans avoir à naviguer dans la table de faits d'une application complexe.
Si nous supposons que la plupart des 50 attributs des clients sont textuelles, nous pourrions avoir une largeur totale pour un enregistrement de 500 octets, ou plus.
Supposons que nous avons 20 millions d'acheteurs (16 millions de visiteurs et 4 millions de clients enregistrés). Evidemment, nous sommes inquiets que dans 80% de nos enregistrements, les 50 champs n'ont pas de données! Dans une dimension de 10 giga-octets, cela attire notre attention.
Il s'agit d'un cas évident où, selon la base de données, nous pourrions introduire un flocon de neige.
Dans les bases de données avec les enregistrements de largeur variable, comme Oracle, nous pouvons tout simplement construire une seule dimension Acheteur avec tous les champs ci-dessus, sans tenir compte de la question des champs vide. La majorité des enregistrements concernant de simples visiteurs, reste étroite, parce que dans ces bases de données, les champs null occupent zéro espace disque.
Mais dans les bases de données de largeur fixe, nous ne voulons probablement pas maintenir les champs vides pour tous les visiteurs, et c'est pourquoi nous divisons la dimension en une dimension de base et une sous-dimension en flocons:
- Base:
Clé Acheteur (identifiant permanent de l'acheteur)
Date de dernière visite (changement de type 1: écrasement)
Fréquence (nombre de visites, changement de type 1: écrasement)
Intensité (montant total des achats, changement de type 1)
Clé de substitution Client (nouveau champs vers le flocon)
- Flocon:
5 pour le nom (civilité, prénom, prénom secondaire, nom, genre)
10 pour la localisation (adresses)
5 pour le comportement de paiement
5 pour le comportement de crédit
10 informations récoltées auprès du client
15 informations achetés auprès de tiers
Dans une base de données de largeur fixe, en utilisant la modélisation ci-dessus, la dimension Acheteur est de 20 million * 25 octets = 500 MB, et le flocon est de 4 million * 475 octets = 1,9 GB. Nous avons ainsi économisés 8 GB.
Voici la conception de base pour une dimension Client de profondeur variable. Cependant, j'ai laissé beaucoup de questions sur la table:
- comment administrer les attributs changeants dans la partie Client de la dimension
- Comment ne pas perdre l'historique des mesures dernière visite-fréquence-intensité, que nous avons écrasé
- Comment ajouter des relations hiérarchiques dans tout cela si les clients sont des organisations
- Comment gérer la sécurité et les contraintes de conception liées à la vie privée qui peuvent être imposées
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #22: Variable Depth Customer Dimensions", publié le 9 avril 2001.
Aucun commentaire:
Enregistrer un commentaire