Kimball The Data Warehouse Toolkit 3rd Edition Pages 265 298

Machine Translated by Google
8 Client
Relation amoureuse
Gestion
Bien ales
vant
que le mot àc loncevaient
organisations a mode de ela géveloppaient
t d estion de la relation
client (d
des modèles CRM) n'existe, centrés sur le client pour
imensionnels
mieux comprendre le comportement de leurs clients. Pendant des décennies, ces modèles ont été utilisés
pour répondre aux demandes de la direction concernant les clients sollicités, qui ont répondu et quelle a
été l'ampleur de leur réponse. La valeur commerciale de la compréhension de l'éventail complet des
interactions et des transactions des clients a propulsé le CRM au sommet des classements. Le CRM inclut
non seulement les clients résidentiels et commerciaux familiers, mais aussi les citoyens, les patients, les
étudiants et de nombreuses autres catégories de personnes et d'organisations dont le comportement et
les préférences sont importants. Le CRM est une stratégie commerciale essentielle que beaucoup
considèrent comme essentielle à la survie d'une organisation.
Dans ce chapitre, nous commençons par une vue d'ensemble du CRM, y compris ses rôles
opérationnels et analytiques. Nous introduisons ensuite la conception de base de la dimension client, y
compris les attributs communs tels que les dates, les attributs de segmentation, les rôles de contact répétés
et les faits agrégés. Nous discutons de l'analyse du nom et de l'adresse du client, ainsi que des
considérations internationales. Nous vous rappelons les défis de la modélisation de hiérarchies complexes
lorsque nous décrivons différents types de hiérarchies de clients.
Le chapitre 8 aborde les concepts suivants :
■ Présentation du CRM
■ Analyse du nom et de l'adresse du client, y compris les considérations internationales ■
Gestion des dates, des faits agrégés et des attributs et scores de comportement de
segmentation dans une dimension client ■ Éléments de base pour les attributs à faible
cardinalité ■ Tables de pont pour les attributs clairsemés, ainsi que les compromis des tables
de pont contre
une conception
positionnelle ■ Tables de pont pour plusieurs contacts clients
■ Groupes d'étude de comportement pour capturer des groupes de cohortes de clients
230 Chapitre 8
■ Dimensions d'étape pour analyser le comportement séquentiel des
clients ■ Tables de faits Timepan avec dates d'effet et d'expiration ■
Embellissement des tables de faits avec des dimensions pour la satisfaction ou des scénarios
anormaux ■ Intégration des données client via la gestion des données de référence ou la conformité partielle
pendant le traitement ETL en aval ■ Avertissements
sur les jointures de table de fait à fait ■ Vérification de la
réalité en temps réel, exigences de faible latence
Parce que les problèmes et les modèles de modélisation centrés sur le client de ce chapitre sont pertinents
dans les industries et les domaines fonctionnels, nous n'avons pas inclus de matrice de bus.
Présentation du GRC
Quel que soit le secteur, les organisations ont afflué vers le concept de CRM.
Ils ont pris le train en marche pour tenter de passer d'une orientation centrée sur le produit à une orientation
axée sur les besoins des clients. Bien que des termes génériques tels que gestion de la relation client semblent
parfois ambigus et/ou trop ambitieux, le postulat derrière le CRM est loin d'être sorcier. Il est basé sur la simple
notion que mieux vous connaissez vos clients, mieux vous pouvez entretenir des relations durables et
précieuses avec eux. L'objectif du CRM est de maximiser les relations avec vos clients tout au long de leur vie.
Cela implique de concentrer tous les aspects de l'entreprise, depuis le marketing, les ventes, les opérations et
le service, sur l'établissement et le maintien de relations mutuellement bénéfiques avec les clients. Pour ce
faire, l'organisation doit développer une vue unique et intégrée de chaque client.
Le CRM promet des retours significatifs aux organisations qui l'adoptent, tant pour l'augmentation des
revenus que pour l'efficacité opérationnelle. Le passage à une perspective axée sur le client peut entraîner une
augmentation de l'efficacité des ventes et des taux de conclusion, une croissance des revenus, une amélioration
de la productivité des ventes à un coût réduit, une amélioration des marges de profitabilité des clients, une plus
grande satisfaction des clients et une fidélisation accrue des clients.
En fin de compte, chaque organisation veut des clients plus fidèles et plus rentables. Comme il faut souvent un
investissement conséquent pour attirer de nouveaux clients, on ne peut pas se permettre de faire partir les plus
rentables.
Dans de nombreuses organisations, la vision du client varie en fonction de l'unité commerciale de la gamme
de produits, de la fonction commerciale et/ou de l'emplacement géographique. Chaque groupe peut utiliser
différentes données client de différentes manières avec des résultats différents. L'évolution des silos existants
vers une perspective plus intégrée nécessite évidemment un engagement organisationnel. Le CRM est comme
un bâton de dynamite qui fait tomber les murs du silo. Elle nécessite la bonne intégration des processus métier,
des ressources humaines et de la technologie d'application pour être efficace.
Au cours de la dernière décennie, la croissance explosive des médias sociaux, de la technologie de
géolocalisation, de la surveillance de l'utilisation du réseau, des applications multimédias et des réseaux de capteurs
Gestion de la Relation Client 231
a fourni un océan de données sur le comportement des clients que même les entreprises de Main Street
reconnaissent comme fournissant des informations exploitables. Bien qu'une grande partie de ces
données se situent en dehors de la zone de confort des bases de données relationnelles, les nouvelles
techniques de « big data » peuvent ramener ces données dans le giron DW/BI. Chapitre 21 : Big Data
Analytics traite des meilleures pratiques pour intégrer ce nouveau type de Big Data dans l'environnement DW/BI.
Mais audelà des défis purement technologiques, le vrai message est la nécessité d'une intégration
profonde. Vous devez relever le défi d'intégrer jusqu'à 100 sources de données destinées aux clients,
dont la plupart sont externes. Ces sources de données sont à des grains différents, ont des attributs
client incompatibles et ne sont pas sous votre contrôle. Des questions?
Parce qu'il est dans la nature humaine de résister au changement, il n'est pas surprenant que les
problèmes liés aux personnes défient souvent les implémentations CRM. Le CRM implique de toutes
nouvelles façons d'interagir avec les clients et implique souvent des changements radicaux dans les
canaux de vente. Le CRM nécessite de nouveaux flux d'informations basés sur l'acquisition et la diffusion
complètes des données des « points de contact » des clients. Souvent, les structures organisationnelles
et les systèmes d'incitation sont radicalement modifiés.
Dans le Chapitre 17 : Présentation du cycle de vie de Kimball DW/BI, nous insisterons sur l'importance
d'avoir le soutien de la direction commerciale et informatique pour une initiative DW/BI.
Ce conseil s'applique également à une implémentation CRM en raison de son orientation transversale.
Le CRM nécessite une vision métier claire. Sans stratégie commerciale, adhésion et autorisation de
changement, le CRM devient un exercice futile. Ni le service informatique ni le monde des affaires ne
peuvent réussir à mettre en œuvre le CRM par euxmêmes ; Le CRM exige un engagement commun de
soutien.
CRM opérationnel et analytique On pourrait dire que le
CRM souffre d'un syndrome de dédoublement de la personnalité car il doit répondre à la fois à des
exigences opérationnelles et analytiques. Un CRM efficace repose sur la collecte de données à chaque
interaction que vous avez avec un client, puis sur l'exploitation de cette étendue de données par le biais
d'analyses.
Sur le plan opérationnel, le CRM appelle à la synchronisation des processus en contact avec le
client. Souvent, les systèmes opérationnels doivent être mis à jour ou complétés pour assurer la
coordination entre les ventes, le marketing, les opérations et le service. Pensez à toutes les interactions
avec les clients qui se produisent lors de l'achat et de l'utilisation d'un produit ou d'un service, depuis le
contact initial avec le prospect, la génération de devis, la transaction d'achat, l'exécution, la transaction
de paiement et le service client continu. Plutôt que de considérer ces processus comme des silos
indépendants (ou des silos multiples variant selon la gamme de produits), l'état d'esprit du CRM consiste
à intégrer ces activités client. Les mesures et les caractéristiques clés des clients sont collectées à
chaque point de contact et mises à la disposition des autres.
Comme les données sont créées du côté opérationnel de l'équation CRM, vous devez évidemment
stocker et analyser les métriques historiques résultant du client
232 Chapitre 8
systèmes d'interaction et de transaction. Cela semble familier, n'estce pas? Le système DW/BI est
au cœur du CRM. Il sert de référentiel pour collecter et intégrer l'étendue des informations client
trouvées dans les systèmes opérationnels, ainsi qu'à partir de sources externes. L'entrepôt de
données est la base qui prend en charge la vue panoramique à 360 degrés de vos clients.
Le CRM analytique est activé via des données client précises, intégrées et accessibles dans le
système DW/BI. Vous pouvez mesurer l'efficacité des décisions prises dans le passé pour optimiser
les interactions futures. Les données client peuvent être exploitées pour mieux identifier les
opportunités de vente incitative et de vente croisée, identifier les ineffi cacités, générer de la demande
et améliorer la fidélisation. De plus, les données historiques intégrées peuvent être exploitées pour
générer des modèles ou des scores qui ferment la boucle vers le monde opérationnel.
En rappelant les principaux composants d'un environnement DW/BI du Chapitre 1 : Introduction à
l'entreposage de données, à l'intelligence d'affaires et à la modélisation dimensionnelle, vous pouvez
imaginer que les résultats du modèle sont repoussés là où la relation est gérée de manière
opérationnelle (par exemple, le représentant, le centre d'appels ou site Web), comme illustré à la
Figure 81. La sortie du modèle peut se traduire par des tactiques proactives ou réactives spécifiques
recommandées pour le prochain point de contact avec le client, telles que la prochaine offre de
produit appropriée ou une réponse antiattrition. Les résultats du modèle sont également conservés
dans l'environnement DW/BI pour une analyse ultérieure.
Intégrer
(ETL)
Collecter
Boutique
(Opérationnel
(Présentation des données)
système source)
Modèle Analyser et
(Applications BI) Rapport
(Applications BI)
Figure 81 : CRM analytique en boucle fermée.
Dans d'autres situations, les informations doivent remonter vers le site Web opérationnel ou les
systèmes du centre d'appels en temps réel. Dans ce cas, la boucle fermée est beaucoup plus étroite que
la figure 81 car il s'agit d'une question de collecte et de stockage, puis de rétroaction vers le système de
collecte. Les processus opérationnels d'aujourd'hui doivent combiner la vue actuelle avec une vue
historique, afin qu'un décideur puisse décider, par exemple, d'accorder un crédit à un client en temps réel,
tout en tenant compte de l'historique de vie du client. Mais généralement, les exigences d'intégration pour
le CRM opérationnel ne sont pas aussi importantes que pour le CRM analytique.
De toute évidence, à mesure que l'organisation devient plus centrée sur le client, le système DW/BI
doit en faire de même. Le CRM entraînera inévitablement des changements dans l'entrepôt de données.
Les environnements DW/BI se développeront encore plus rapidement à mesure que vous collecterez de
plus en plus d'informations sur vos clients. Les processus ETL se compliqueront au fur et à mesure que
vous ferez correspondre et intégrerez des données provenant de plusieurs sources. Plus important encore,
le besoin d'une dimension client conforme devient encore plus primordial.
Attributs de dimension client
La dimension client conforme est un élément critique pour un CRM efficace. Une dimension client
conforme bien entretenue et bien déployée est la pierre angulaire d'une bonne analyse CRM.
La dimension client est généralement la dimension la plus difficile pour tout système DW/BI. Dans une
grande organisation, la dimension client peut être extrêmement profonde (avec plusieurs millions de
lignes), extrêmement large (avec des dizaines voire des centaines d'attributs) et parfois sujette à des
changements rapides. Les plus grands détaillants, les sociétés de cartes de crédit et les agences
gouvernementales ont des dimensions de clients monstres dont la taille dépasse 100 millions de lignes.
Pour compliquer davantage les choses, la dimension client représente souvent une fusion de données
provenant de plusieurs systèmes sources internes et externes.
Dans cette section suivante, nous nous concentrons sur de nombreuses considérations de conception
de la dimension client. Nous commencerons par l'analyse du nom/de l'adresse et d'autres attributs client
courants, y compris la couverture des stabilisateurs de dimension, puis nous passerons à d'autres attributs
client intéressants. Bien sûr, la liste des attributs client est généralement assez longue. Plus vous capturez
d'informations descriptives sur vos clients, plus la dimension client est robuste et plus les analyses sont
intéressantes.
Analyse du nom et de l'adresse Que vous traitiez
avec des êtres humains individuels ou des entités commerciales, les attributs de nom et d'adresse des
clients sont généralement capturés. La gestion opérationnelle des informations de nom et d'adresse est
généralement trop simpliste pour être très utile
234 Chapitre 8
dans le système DW/BI. De nombreux concepteurs estiment qu'une conception libérale de colonnes
à usage général pour les noms et les adresses, telles que Nom1 à Nom3 et Adresse1 à Adresse6,
peut gérer n'importe quelle situation. Malheureusement, ces colonnes fourretout sont pratiquement
sans valeur lorsqu'il s'agit de mieux comprendre et segmenter la clientèle. Concevoir les colonnes de
nom et d'emplacement de manière générique peut en fait contribuer à des problèmes de qualité des
données. Considérez le plan d'échantillonnage de la Figure 82 avec des colonnes à usage général.
Colonne Exemple de valeur de
Nom données Mme R. Jane Smith,
Adresse 1 Atty 123 Main Rd, North West, Ste 100A PO
Adresse 2 Box 2348
Ville Kensington
État Arche.
Code postal 888872348
Numéro de téléphone 8885553333 poste 776 principal, 5554444 télécopieur
Figure 82 : Exemple de données de nom/adresse de client dans des colonnes trop générales.
Dans cette conception, la colonne de nom est beaucoup trop limitée. Il n'y a pas de mécanisme
cohérent pour gérer les salutations, les titres ou les suffixes. Vous ne pouvez pas identifier le prénom
de la personne ni comment elle doit être adressée dans une salutation personnalisée. Si vous
examinez des exemples de données supplémentaires de ce système opérationnel, vous pourriez
potentiellement trouver plusieurs clients répertoriés dans un seul attribut de nom. Vous pouvez
également trouver des informations descriptives supplémentaires dans la colonne du nom, telles que
Confidentiel, Fiduciaire ou UGMA (Uniform Gift to Minors Act).
Dans les exemples d'attributs d'adresse, des abréviations incohérentes sont utilisées à divers
endroits. Les colonnes d'adresses peuvent contenir suffisamment d'espace pour n'importe quelle
adresse, mais il n'y a aucune discipline imposée par les colonnes qui puisse garantir la conformité aux
réglementations des autorités postales ou prendre en charge la correspondance d'adresses et
l'identification de latitude/longitude.
Au lieu d'utiliser quelques colonnes à usage général, les attributs de nom et d'emplacement doivent
être décomposés en autant de parties élémentaires que possible. Le processus d'extraction doit
effectuer une analyse significative des noms et adresses modifiés d'origine. Une fois les attributs
analysés, ils peuvent être standardisés. Par exemple, Rd deviendrait Road et Ste deviendrait Suite.
Les attributs peuvent également être vérifiés, par exemple en vérifiant que le code postal et la
combinaison d'état associée sont corrects. Heureusement, il existe sur le marché des outils de
nettoyage et de nettoyage des données de nom et d'adresse pour faciliter l'analyse, la normalisation
et la vérification.
Un exemple d'ensemble d'attributs de nom et d'emplacement pour des personnes aux ÉtatsUnis
est illustré à la figure 83. Chaque attribut est rempli avec des exemples de données pour rendre la
conception plus claire, mais aucune instance réelle ne ressemblerait à ceci. Bien sûr, les représentants
de la gouvernance des données métier doivent être impliqués dans la détermination de la valeur
analytique de ces éléments de données analysés dans la dimension client.
Colonne Exemple de valeur de données
Salutation Ms.
Nom de salutation informel Jeanne
Nom de salutation formel Mme Smith
Prénoms et deuxièmes prénoms R.Jane
Nom de famille Forgeron
Suffixe Jr.
Origine ethnique Anglais
Titre Avocat 123
Numéro de rue
Nom de rue Principale
Type de rue Route
Sens de la rue Nord Ouest
Ville Kensington
Quartier Cornouailles
Deuxième arrondissement Berkeleyshire
État Arkansas
Région Sud
De campagne ÉtatsUnis
Continent Amérique du Nord
Code postal principal 88887
Code postal secondaire 2348
Type de code postal ÉtatsUnis
Indicatif de pays du téléphone du bureau 1
Indicatif régional du téléphone du bureau 888
Numéro de téléphone du bureau 5553333
Extension du bureau 776
Indicatif du pays du téléphone portable 1
Indicatif régional du téléphone mobile 509
Numéro de téléphone mobile 5554444
Email RJSmith@ABCGenIntl.com
Site Internet www.ABCGenIntl.com
Authentification par clé publique X.509
Autorité de certification Verisign
Identifiant individuel unique 7346531
Figure 83 : Exemple de données de nom/adresse de client avec des éléments de nom et
d'adresse analysés.
236 Chapitre 8
Les clients commerciaux ont généralement plusieurs adresses, telles que des adresses physiques
et d'expédition ; chacune de ces adresses suivrait à peu près la même logique que la structure
d'adresse illustrée à la figure 83.
Considérations relatives aux noms et adresses internationaux
L'affichage et l'impression internationaux nécessitent généralement la représentation de caractères
étrangers, y compris non seulement les caractères accentués des alphabets d'Europe occidentale,
mais aussi le cyrillique, l'arabe, le japonais, le chinois et des dizaines d'autres systèmes d'écriture
moins familiers. Il est important de comprendre qu'il ne s'agit pas d'un problème de police. Il s'agit
d'un problème de jeu de caractères. Une police est simplement le rendu d'un artiste d'un ensemble
de caractères. Il existe des centaines de polices disponibles pour l'anglais standard, mais l'anglais
standard a un jeu de caractères relativement petit qui est suffisant pour être utilisé par n'importe qui,
sauf si vous êtes un typographe professionnel. Ce petit jeu de caractères est généralement codé en
American Standard Code for Information Interchange (ASCII), qui est un codage 8 bits qui a un
maximum de 255 caractères possibles. Seuls environ 100 de ces 255 caractères ont une interprétation
standard qui peut être invoquée à partir d'un clavier anglais normal, mais cela est généralement
suffisant pour les utilisateurs d'ordinateurs anglophones. Il devrait être clair que l'ASCII est
terriblement inadéquat pour représenter les milliers de caractères nécessaires aux systèmes d'écriture
non anglais.
Un organisme international d'architectes système, le Consortium Unicode, a défini une norme
connue sous le nom d'Unicode pour représenter les caractères et les alphabets dans presque toutes
les langues et cultures du monde. Leurs travaux sont accessibles sur le site www. unicode.org. La
norme Unicode, version 6.2.0 a défini des interprétations spécifi ques pour 110 182 caractères
possibles et couvre désormais les principales langues écrites des Amériques, de l'Europe, du Moyen
Orient, de l'Afrique, de l'Inde, de l'Asie et du Pacifique. Unicode est la base que vous devez utiliser
pour adresser les jeux de caractères internationaux.
Mais il est important de comprendre que la mise en œuvre des solutions Unicode se fait dans les
couches de base de vos systèmes. Tout d'abord, le système d'exploitation doit être compatible
Unicode. Heureusement, les versions les plus récentes de tous les principaux systèmes d'exploitation
sont compatibles Unicode.
Audessus du système d'exploitation, tous les périphériques qui capturent, stockent, transmettent
et impriment des caractères doivent être compatibles Unicode. Les outils d'arrièreboutique de
l'entrepôt de données doivent être conformes à Unicode, y compris les packages de tri, les langages
de programmation et les packages ETL automatisés. Enfin, les applications DW/BI, y compris les
moteurs de base de données, les serveurs d'applications BI et leurs rédacteurs de rapports et outils
de requête, les serveurs Web et les navigateurs doivent tous être compatibles Unicode. L'architecte
DW/BI doit non seulement parler aux fournisseurs de chaque package du pipeline de données, mais
doit également effectuer divers tests de bout en bout. Capturez des noms et des adresses avec des
caractères Unicode sur les écrans de capture de données de l'une des applications héritées et
envoyezles via le système. Demandezleur d'imprimer un rapport final ou une fenêtre de navigateur finale à partir de
le système DW/BI et voyez si les caractères spéciaux sont toujours là. Ce test simple résoudra
une grande partie de la confusion. Notez que même lorsque vous faites cela, le même caractère,
tel qu'un umlaut, est trié différemment dans différents pays comme la Norvège et l'Allemagne.
Même si vous ne pouvez pas résoudre toutes les variations dans les séquences de classement
internationales, au moins les Norvégiens et les Allemands conviendront que le caractère est un
umlaut.
Les attributs géographiques des clients deviennent plus compliqués si vous traitez avec des
clients de plusieurs pays. Même si vous n'avez pas de clients internationaux, vous devrez peut
être composer avec des noms et adresses internationaux quelque part dans le système DW/BI
pour les fournisseurs internationaux et les dossiers du personnel des ressources humaines.
REMARQUE Les dimensions client incluent parfois un attribut de bloc d'adresse complet.
Il s'agit d'une colonne spécialement conçue qui assemble une adresse postale valide pour le
client, y compris l'arrêt de courrier, le code postal et d'autres attributs nécessaires pour satisfaire
les autorités postales. Cet attribut est utile pour les emplacements internationaux où les adresses
ont des idiosyncrasies locales.
Objectifs internationaux DW/BI
Après avoir adopté une fondation Unicode, vous devez garder à l'esprit les objectifs suivants, en
plus des exigences d'analyse de nom et d'adresse évoquées précédemment :
■ Universel et cohérent. Comme on dit, pour un sou, pour une livre. Si vous envisagez de
concevoir un système à usage international, vous voulez qu'il fonctionne dans le monde
entier. Vous devez bien réfléchir si les outils de BI doivent produire des versions traduites
de rapports dans de nombreuses langues. Il peut être tentant de fournir des versions
traduites des dimensions pour chaque langue, mais les dimensions traduites posent
quelques problèmes subtils.
■ Les séquences de tri seront différentes, de sorte que soit les rapports seront triés
différemment, soit tous les rapports, à l'exception de ceux de la langue « racine »,
apparaîtront non triés. ■ Si les cardinalités des attributs ne sont pas fidèlement
préservées dans toutes les langues, soit les totaux des groupes ne seront pas les
mêmes dans les rapports, soit certains groupes dans différentes langues
contiendront des entêtes de ligne en double qui ressembleront à des erreurs.
Pour éviter le pire de ces problèmes, vous devez traduire les dimensions après
l'exécution du rapport ; le rapport doit d'abord être produit dans une seule langue
racine, puis le rapport doit être traduit dans les langues cibles prévues. ■ Tous les
messages et invites de l'outil BI doivent être traduits pour le bénéfice de l'utilisateur
professionnel. Ce processus est connu sous le nom de localisation et est décrit plus
en détail au Chapitre 12 : Transport.
238 Chapitre 8
■ Qualité des données de bout en bout et compatibilité en aval. L'entrepôt de données ne peut
pas être la seule étape du pipeline de données qui s'inquiète de l'intégrité des noms et
adresses internationaux. Une conception appropriée nécessite un soutien depuis la première
étape de saisie du nom et de l'adresse, en passant par les étapes de nettoyage et de
stockage des données, jusqu'aux étapes finales de réalisation d'analyses géographiques et
démographiques et d'impression de rapports.
■ Rectitude culturelle. Dans de nombreux cas, les clients et partenaires étrangers verront les
résultats de votre système DW/BI sous une forme ou une autre. Si nous ne comprenons
pas quel nom est un prénom et lequel est un nom de famille, et si vous ne comprenez pas
comment désigner une personne, vous risquez d'insulter ces personnes, ou à tout le moins,
l'air stupide. Lorsque les sorties sont mal ponctuées ou mal orthographiées, vos clients et
partenaires étrangers souhaiteront faire affaire avec une entreprise locale plutôt qu'avec
vous. ■ Réponse client en temps réel. Les systèmes DW/BI peuvent jouer un rôle
opérationnel en prenant en charge les systèmes de réponse client en temps réel. Un représentant
du service client peut répondre au téléphone et peut avoir 5 secondes ou moins pour
attendre qu'un message d'accueil apparaisse sur l'écran que l'entrepôt de données
recommande d'utiliser avec le client. La salutation peut inclure une salutation appropriée et
une utilisation appropriée du titre et du nom du client. Ce message d'accueil représente une
excellente utilisation d'un cache de réponse à chaud qui contient des réponses précalculées
pour chaque client.
■ Autres types d'adresses. Nous sommes au milieu d'une révolution dans la communication et
le réseautage. Si vous concevez un système d'identification des noms et adresses
internationaux, vous devez anticiper la nécessité de stocker les noms électroniques, les
jetons de sécurité et les adresses Internet.
Comme pour les adresses internationales, les numéros de téléphone doivent être présentés
différemment selon l'origine de l'appel téléphonique. Vous devez fournir des attributs pour représenter
la séquence de numérotation étrangère complète, la séquence de numérotation nationale complète
et la séquence de numérotation locale. Malheureusement, les séquences complètes de numérotation
à l'étranger varient selon le pays d'origine.
Dates centrées sur le client
Les dimensions client contiennent souvent des dates, telles que la date du premier achat, la date du
dernier achat et la date de naissance. Bien que ces dates puissent initialement être des colonnes
de type date SQL, si vous souhaitez résumer ces dates par vos attributs de calendrier uniques, tels
que les saisons, les trimestres et les périodes fiscales, les dates doivent être remplacées par des
références de clé étrangère à la dimension de date. Vous devez veiller à ce que toutes ces dates
soient comprises dans la durée de la dimension de date d'entreprise. Ces rôles de dimension de
date sont déclarés en tant que vues sémantiquement distinctes, telles qu'un premier achat
Table de dimension de date avec des étiquettes de colonne uniques. Le système se comporte comme
s'il existait une autre table de dates physique. Les contraintes sur l'une de ces tables n'ont rien à voir
avec les contraintes sur la table de dimension de date principale. Cette conception, illustrée à la Figure
84, est un exemple de stabilisateur de dimension, qui est abordé dans la section « Pilot pour un
ensemble d'attributs à faible cardinalité ».
Date du premier achat Dimension client Tableau des faits
Date du 1er achat Clé (PK) Clé client (PK) Clé de date de transaction (FK)

Date du 1er achat ID client (clé naturelle) Clé client (FK)
Date du 1er mois d'achat Message d'accueil du client Plus de FK…
Date de la 1ère année d'achat Prénom du client Faits …
Date du 1er mois fiscal d'achat Nom du client
Date du premier trimestre fiscal d'achat Ville du client
Date du 1er exercice d'achat État du client
Date de la 1ère saison d'achat …
… Date du 1er achat Clé (FK)
Figure 84 : Stabilisateur de dimension de date.
Faits agrégés en tant qu'attributs de dimension Les utilisateurs professionnels
souhaitent souvent restreindre la dimension client en fonction de mesures de performances agrégées,
telles que le filtrage de tous les clients qui ont dépensé plus d'un certain montant au cours de l'année
précédente. Ou pour aggraver les choses, peutêtre veulentils limiter en fonction du montant que le
client a acheté au cours de sa vie.
Fournir des faits agrégés en tant qu'attributs de dimension plaira à coup sûr aux utilisateurs
professionnels. Ils peuvent émettre une requête pour identifier tous les clients qui satisfont aux critères
de dépenses, puis émettre une autre requête factuelle pour analyser le comportement de ce sous
ensemble de dimension client. Mais plutôt que tout cela, vous pouvez à la place stocker un fait agrégé
en tant qu'attribut de dimension. Cela permet aux utilisateurs professionnels de limiter simplement
l'attribut de dépenses comme ils le feraient pour un attribut géographique.
Ces attributs sont destinés à être utilisés pour la contrainte et l'étiquetage ; ils ne doivent pas être utilisés
dans les calculs numériques. Bien que le stockage de ces attributs présente des avantages en termes
de convivialité et de performances des requêtes, la charge principale incombe aux processus ETL de
l'arrièreboutique pour garantir que les attributs sont exacts, à jour et cohérents avec les lignes de faits
réelles. Ces attributs peuvent nécessiter des soins et une alimentation importants. Si vous choisissez
d'inclure certains faits agrégés en tant qu'attributs de dimension, assurezvous de vous concentrer sur
ceux qui seront fréquemment utilisés. Efforcezvous également de minimiser la fréquence à laquelle ces
attributs doivent être mis à jour. Par exemple, un attribut pour les dépenses de l'année dernière
nécessiterait beaucoup moins de maintenance qu'un attribut fournissant un comportement depuis le début de l'année.
Plutôt que de stocker des attributs jusqu'à la valeur monétaire spécifique, ils sont parfois
240 Chapitre 8
remplacé (ou complété) par des valeurs descriptives plus significatives, telles que Dépense élevée,
comme indiqué dans la section suivante. Ces valeurs descriptives minimisent votre vulnérabilité que les
attributs numériques pourraient ne pas relier aux tables de faits appropriées. En outre, ils garantissent
que tous les utilisateurs disposent d'une défi nition cohérente pour les grands dépensiers, par exemple,
plutôt que de recourir à leurs propres règles commerciales individuelles.
Attributs et scores de segmentation Certains des attributs les plus
puissants dans une dimension client sont les classifications de segmentation. Ces attributs varient
évidemment considérablement selon le contexte commercial. Pour un client particulier, ils peuvent
comprendre :
■ Sexe ■
Origine
ethnique ■ Âge ou autres classifications
d'étape de la vie ■ Revenu ou autres
classifications de style de vie ■ Statut (tel que nouveau,
actif, inactif et fermé) ■ Source de référence ■ Segment
de marché spécifique à l'entreprise (tel qu'un identifiant de client privilégié euh)
De même, de nombreuses organisations notent leurs clients pour les caractériser.
Les modèles de segmentation statistique génèrent généralement ces scores qui regroupent les clients
de diverses manières, par exemple en fonction de leur comportement d'achat, de leur comportement
de paiement, de leur propension à se désabonner ou de leur probabilité de défaut. Chaque client est
étiqueté avec un score résultant.
Behavior Tag Time Series Une
approche populaire pour la notation et le profilage des clients examine la récence (R), la fréquence (F)
et l'intensité (I) du comportement du client. Cellesci sont connues sous le nom de mesures RFI; parfois
l'intensité est remplacée par monétaire (M), elle est donc également connue sous le nom de RFM. La
récence correspond au nombre de jours écoulés depuis la dernière commande ou visite de votre site
par le client. La fréquence correspond au nombre de fois que le client a commandé ou visité,
généralement au cours de l'année écoulée. Et l'intensité est combien d'argent le client a dépensé au
cours de la même période. Lorsqu'il s'agit d'une grande base de clients, le comportement de chaque
client peut être modélisé comme un point dans un cube RFI, comme illustré à la Figure 85. Dans cette
figure, les échelles le long de chaque axe sont des quintiles, de 1 à 5, qui répartissent les valeurs réelles
en groupes pairs.
Si vous avez des millions de points dans le cube, il devient difficile de voir des groupes significatifs
de ces points. C'est le bon moment pour demander à un professionnel de l'exploration de données où
se trouvent les clusters significatifs. Le professionnel de l'exploration de données peut revenir avec une
liste de balises de comportement comme celleci, qui est tirée d'un scénario légèrement plus compliqué
qui inclut le comportement de crédit et les retours :
A : Client régulier à volume élevé, bon crédit, peu de retours de produits
B : Client régulier à volume élevé, bon crédit, nombreux retours de produits
C : Nouveau client récent, pas de modèle de crédit établi
D : Client occasionnel, bon crédit
E : Client occasionnel, mauvais crédit
F : Ancien bon client, pas vu récemment
G : Lèchevitrines fréquent, généralement improductif
H : Autre
Le plus élevé 5
Récence 3 5 Plus haut
4
2
3 Intensité
2
Le plus bas 1
1 Le plus bas
1 2345
Le plus bas Plus haut
Fréquence
Figure 85 : Cube de récence, fréquence, intensité (RFI).
Vous pouvez désormais consulter les données chronologiques des clients et associer chaque client
de chaque période de rapport au cluster le plus proche. Le mineur de données peut aider à le faire.
Ainsi, les 10 dernières observations d'un client nommé John Doe pourraient ressembler à : John
Doe : CCCDDAAABB Cette série chronologique de balises de comportement est inhabituelle
car bien qu'elle provienne d'un processus de mesure périodique régulier, les « valeurs » observées
sont textuelles. Les balises de comportement ne sont pas numériques et ne peuvent pas être calculées
ou moyennées, mais elles peuvent être interrogées. Par exemple, vous pouvez rechercher tous les
clients qui étaient A à un moment donné au cours de la cinquième, quatrième ou troisième période
précédente et qui étaient B au cours de la deuxième ou de la première période précédente. Peutêtre
êtesvous préoccupé par de telles progressions et craignezvous de perdre un client précieux à cause
du nombre croissant de retours.
Les balises de comportement ne doivent pas être stockées comme des faits réguliers. L'utilisation principale des balises
de comportement consiste à formuler des modèles de requête complexes comme dans l'exemple du paragraphe précédent.
Si les balises de comportement étaient stockées dans des lignes de faits séparées, une telle requête
serait extrêmement difficile, nécessitant une cascade de sousrequêtes corrélées. La méthode
recommandée pour gérer les balises de comportement consiste à créer une série temporelle explicite
d'attributs dans la dimension client. Ceci est un autre exemple de conception positionnelle. Interfaces BI
242 Chapitre 8
sont simples car les colonnes se trouvent dans la même table et les performances sont bonnes car vous
pouvez créer des index bitmap sur cellesci.
En plus des colonnes séparées pour chaque période de balise de comportement, il serait judicieux de
créer un seul attribut avec toutes les balises de comportement concaténées, telles que CCCDDAAABB.
Cette colonne prendrait en charge les recherches par caractères génériques pour les modèles exotiques,
tels que "D suivi d'un B".
REMARQUE En plus de la série temporelle de balises de comportement de la dimension client, il serait
raisonnable d'inclure la valeur de la balise de comportement contemporaine dans une mini dimension
pour analyser les faits par la balise de comportement en vigueur au moment du chargement de la ligne
de faits.
Relation entre l'exploration de données et le système DW/BI L'équipe
d'exploration de données peut être un excellent client de l'entrepôt de données, et en particulier de grands
utilisateurs de données sur le comportement des clients. Cependant, il peut y avoir un décalage entre la
vitesse à laquelle l'entrepôt de données peut fournir des données et la vitesse à laquelle les mineurs de
données peuvent consommer des données. Par exemple, un outil d'arbre de décision peut traiter des
centaines d'enregistrements par seconde, mais un gros rapport d'exploration transversale qui produit des
« observations de clients » ne peut jamais fournir de données à de telles vitesses. Considérez l'exploration
à sept voies suivante dans un rapport qui pourrait produire des millions d'observations de clients à partir
de données de recensement, démographiques, de crédit externe, de crédit interne, d'achats, de retours et de sites Web :
SELECT Identifiant client, secteur de recensement, ville, comté, état, code postal, groupe
démographique, âge, sexe, état civil, années de résidence, nombre de personnes à
charge, profil d'emploi, profil d'éducation, indicateur de lecteur de magazine sportif,
indicateur de propriétaire d'ordinateur personnel, Indicateur de propriétaire de téléphone
cellulaire, cote de crédit actuelle, pire cote de crédit historique, meilleure cote de crédit
historique, date du premier achat, date du dernier achat, nombre d'achats l'année
dernière, variation du nombre d'achats par rapport à l'année précédente, nombre total
d'achats à vie, valeur totale des achats à vie , Nombre d'achats retournés sur la durée
de vie, Dette maximale, Âge moyen sur la durée de vie de la dette du client, Nombre de
retards de paiement, Nombre de paiements complets, Nombre de visites du site Web,
Changement de la fréquence d'accès au site Web, Nombre de pages visitées par session,
Durée de séjour moyenne par session, Nombre Commandes de produits Web, valeur des
commandes de produits Web, nombre de visites de sites Web sur des sites Web partenaires,
modification des visites de sites Web partenaires DE *** OÙ *** ORDER BY *** GROUP BY
***
Les équipes d'exploration de données aimeraient ces données ! Par exemple, un gros fichier de millions
de ces observations pourrait être analysé par un outil d'arbre de décision où l'outil est « destiné » à la
colonne Total Value Purchases Lifetime, qui est mise en évidence cidessus. Dans cette analyse, l'outil
d'arbre de décision déterminerait laquelle des autres colonnes « prédit la variance » du champ cible. La
réponse est peutêtre la meilleure cote de crédit historique et le nombre de personnes à charge. Armée de
cette réponse, l'entreprise dispose désormais d'un moyen simple de prédire qui sera un bon client à vie,
sans avoir besoin de connaître tous les autres contenus de données.
Mais l'équipe d'exploration de données souhaite utiliser ces observations encore et encore pour différents
types d'analyses, peutêtre avec des réseaux de neurones ou des outils de raisonnement basé sur des cas.
Plutôt que de produire cet ensemble de réponses à la demande comme une requête volumineuse et
coûteuse, cet ensemble de réponses doit être écrit dans un fichier et donné à l'équipe d'exploration de
données pour analyse sur ses serveurs.
Comptages avec modifications de dimension de type 2 Les entreprises
souhaitent souvent compter les clients en fonction de leurs attributs sans se joindre à une table de faits. Si
vous avez utilisé le type 2 pour suivre les modifications de la dimension client, vous devez faire attention à
éviter tout comptage excessif, car vous pouvez avoir plusieurs lignes dans la dimension client pour le même
individu. Faire un COUNT DISTINCT sur un identifiant client unique est une possibilité, en supposant que
l'attribut est effectivement unique et durable. Un indicateur de ligne actuelle dans la dimension client est
également utile pour effectuer des comptages basés sur les valeurs descriptives les plus récentes pour un
client.
Les choses se compliquent si vous devez effectuer un comptage de clients à un moment historique
donné en utilisant les dates d'effet et d'expiration dans la dimension client. Par exemple, si vous avez besoin
de connaître le nombre de clients que vous aviez au début de 2013, vous pouvez contraindre la date d'effet
de la ligne <= '1/1/2013' et la date d'expiration de la ligne >= '1/1/2013' pour limiter le jeu de résultats aux
seules lignes valides au 01/01/2013. Notez que les opérateurs de comparaison dépendent des règles métier
utilisées pour définir les dates d'effet/d'expiration des lignes. Dans cet exemple, la date d'expiration de la
ligne sur la ligne du client qui n'est plus valide est inférieure d'un jour à la date d'effet sur la nouvelle ligne.
Outrigger for Low Cardinality Attribute Set Dans le Chapitre 3 : Ventes au détail,
nous avons encouragé les concepteurs à éviter les flocons de neige lorsque les colonnes à faible cardinalité
de la dimension sont supprimées pour séparer les tables normalisées, qui sont ensuite liées à la table de
dimension d'origine. Généralement, le snowflaking n'est pas recommandé dans un environnement DW/BI
car il rend presque toujours la présentation de l'utilisateur plus complexe, en plus d'avoir un impact négatif
sur les performances de navigation. Malgré cette interdiction de faire du snowflake, il existe des
244 Chapitre 8
situations dans lesquelles il est permis de construire un stabilisateur de dimension qui commence à
ressembler à une table en flocons de neige.
Dans la Figure 86, le paramètre de dimension est un ensemble de données provenant d'un fournisseur
de données externe composé de 150 attributs démographiques et socioéconomiques concernant le comté
de résidence des clients. Les données de tous les clients résidant dans un département donné sont
identiques. Plutôt que de répéter ce grand bloc de données pour chaque client d'un comté, choisissez de
le modéliser comme un stabilisateur. Il y a plusieurs raisons de contourner la règle « pas de flocon de
neige ». Tout d'abord, les données démographiques sont disponibles à un niveau sensiblement différent
de celui des données de dimension primaire et elles ne sont pas aussi utiles d'un point de vue analytique.
Il est chargé à des moments différents du reste des données de la dimension client.
En outre, vous économisez de l'espace significatif dans ce cas si la dimension client sousjacente est
importante. Si vous disposez d'un outil de requête qui insiste sur un schéma en étoile classique sans
flocons de neige, l'outrigger peut être masqué sous une déclaration de vue.
Démographie du pays Dimension du stabilisateur Dimension client Tableau des faits
Clé démographique du comté (PK) Clé client (PK) Clé client (FK)

Population totale ID client (clé naturelle) Plus de FK...
Population de moins de 5 ans Message d'accueil du client Faits ...
% Population de moins de 5 ans Prénom du client
Population de moins de 18 ans Nom du client
% Population de moins de 18 ans Ville du client
Population de 65 ans et plus Comté du client
% de la population de 65 ans et plus Clé démographique du comté (FK)
Population féminine État du client
% de la population féminine ...
Population masculine
% de la population masculine
Nombre de diplômés du secondaire
Nombre de diplômés collégiaux
Nombre d'unités de logement
Taux d'accession à la propriété
...
Figure 86 : Paramètre de dimension pour un groupe d'attributs de faible cardinalité.
AVERTISSEMENT Les stabilisateurs de dimension sont autorisés, mais ils doivent être l'exception plutôt
que la règle. Un drapeau d'avertissement rouge devrait monter si votre conception est truffée de
stabilisateurs ; vous avez peutêtre succombé à la tentation de trop normaliser le design.
Considérations relatives à la hiérarchie des clients
L'un des aspects les plus difficiles des relations avec les clients commerciaux consiste à modéliser leur
hiérarchie organisationnelle interne. Les clients commerciaux ont souvent un
hiérarchie imbriquée d'entités allant des sites ou organisations individuels aux bureaux régionaux, aux
sièges sociaux des unités commerciales et aux sociétés mères ultimes.
Ces relations hiérarchiques peuvent changer fréquemment lorsque les clients se réorganisent en
interne ou sont impliqués dans des acquisitions et des cessions.
REMARQUE Au Chapitre 7 : Comptabilité, nous avons décrit comment gérer les hiérarchies fi xes,
les hiérarchies légèrement variables et les hiérarchies irrégulières de profondeur indéterminée.
Le chapitre 7 se concentre sur les cumuls des centres de coûts fi nanciers, mais les techniques sont
exactement transférables aux hiérarchies des clients. Si vous avez sauté le chapitre 7, vous devez
revenir en arrière pour lire ce chapitre afin de donner un sens aux recommandations suivantes.
Bien que relativement rare, les plus chanceux d'entre nous sont parfois confrontés à une hiérarchie
de clients qui a un nombre fi xe de niveaux hautement prévisible. Supposons que vous suiviez un
maximum de trois niveaux de cumul, tels que la société mère ultime, le siège de l'unité commerciale et
le siège régional. Dans ce cas, vous disposez de trois attributs distincts dans la dimension client
correspondant à ces trois niveaux. Pour les clients commerciaux avec des hiérarchies organisationnelles
compliquées, vous remplissez les trois niveaux pour représenter de manière appropriée les trois entités
diff érentes impliquées à chaque niveau de cumul. Il s'agit de l'approche de la hiérarchie à profondeur
fi xe du chapitre 7.
En revanche, si un autre client avait un mélange d'organisations à un, deux et trois niveaux, vous
dupliquez la valeur de niveau inférieur pour renseigner les attributs de niveau supérieur. De cette façon,
la somme de tous les sièges sociaux régionaux correspondrait à la somme de tous les sièges sociaux
des unités commerciales, qui correspondrait à la somme de toutes les sociétés mères ultimes.
Vous pouvez générer des rapports par n'importe quel niveau de la hiérarchie et voir la clientèle
complète représentée. C'est l'approche de la hiérarchie légèrement variable.
Mais dans de nombreux cas, les hiérarchies complexes de clients commerciaux sont des
hiérarchies irrégulières avec une profondeur indéterminée, vous devez donc utiliser une technique de
modélisation de hiérarchie irrégulière, comme décrit au chapitre 7. Par exemple, si une entreprise de
services publics conçoit un plan tarifaire personnalisé pour consommateurs de services publics qui font
partie d'un énorme client avec de nombreux niveaux de bureaux, succursales, sites de fabrication et
sites de vente, vous ne pouvez pas utiliser une hiérarchie fi xe. Comme indiqué au chapitre 7, la pire
conception est un ensemble de niveaux génériques nommés tels que Niveau1, Niveau2, etc. Cela
crée une dimension client inutilisable car vous ne savez pas comment contraindre ces niveaux lorsque
vous avez une hiérarchie irrégulière de profondeur indéterminée.
Tables de pont pour les dimensions à valeurs multiples
Un principe fondamental de la modélisation dimensionnelle est de décider du grain de la table de faits,
puis d'ajouter soigneusement des dimensions et des faits à la conception qui sont fidèles au grain. Par
exemple, si vous enregistrez les transactions d'achat des clients, le grain de
246 Chapitre 8
l'achat individuel est naturel et physiquement convaincant. Vous ne voulez pas changer ce grain. Ainsi,
vous avez normalement besoin que toute dimension attachée à cette table de faits prenne une valeur
unique, car il existe alors une seule clé étrangère propre dans la table de faits qui identifie un seul membre
de la dimension. Les dimensions telles que le client, l'emplacement, le produit ou le service et le temps
sont toujours à valeur unique. Mais vous pouvez avoir des dimensions "problématiques" qui prennent
plusieurs valeurs au niveau de la transaction individuelle. Voici des exemples courants de ces dimensions
à plusieurs valeurs :
■ Descripteurs démographiques tirés d'une multiplicité de sources ■ Adresses de
contact d'un client commercial ■ Compétences professionnelles d'un demandeur
d'emploi ■ Passetemps d'un individu ■ Diagnostics ou symptômes d'un patient ■
Caractéristiques optionnelles pour une automobile ou un camion ■ Titulaires d'un
compte conjoint dans une banque compte ■ Locataires d'un bien locatif
Face à une dimension multivaluée, deux choix de base s'offrent à vous : un plan positionnel ou un
plan de table de pont. Les conceptions positionnelles sont très intéressantes car la dimension à plusieurs
valeurs est répartie dans des colonnes nommées faciles à interroger.
Par exemple, si vous modélisez les passetemps d'un individu comme mentionné précédemment, vous
pourriez avoir une dimension de passetemps avec des colonnes nommées pour tous les passetemps
recueillis auprès de vos clients, y compris la philatélie, la numismatique, l'astronomie, la photographie et
bien d'autres ! Immédiatement, vous pouvez voir le problème. L'approche de conception positionnelle
n'est pas très évolutive. Vous pouvez facilement manquer de colonnes dans votre base de données et il
est difficile d'ajouter de nouvelles colonnes. De plus, si vous avez une colonne pour chaque passetemps
possible, la ligne de dimension de passetemps de n'importe quel individu contiendra principalement des
valeurs nulles.
L'approche de la table de pont aux dimensions multivaluées est puissante mais s'accompagne d'un
gros compromis. La table de pont supprime les objections d'évolutivité et de valeur nulle car les lignes de
la table de pont n'existent que si elles sont réellement nécessaires, et vous pouvez ajouter des centaines
voire des milliers de passetemps dans l'exemple précédent.
Mais la conception de la table résultante nécessite une requête complexe qui doit être masquée de la vue
directe par les utilisateurs professionnels.
AVERTISSEMENT Sachez que les requêtes complexes utilisant des tables de pont peuvent nécessiter
du SQL qui dépasse la portée normale des outils de BI.
Dans les deux sections suivantes, nous illustrons les conceptions de tables de pont à valeurs multiples
qui correspondent aux sujets centrés sur le client de ce chapitre. Nous reviendrons sur les ponts
multivalués au Chapitre 9 : Gestion des ressources humaines, Chapitre 10 : Services financiers, Chapitre
13 : Éducation, Chapitre 14 : Santé et Chapitre 16 : Assurances.
Nous décrirons ensuite comment construire ces ponts au Chapitre 19 : Soussystèmes et techniques ETL.
Table de pont pour les attributs clairsemés Les organisations
collectent de plus en plus des informations démographiques et d'état sur leurs clients, mais l'approche
traditionnelle de modélisation à colonne fi xe pour gérer ces attributs devient difficile à mettre à l'échelle
avec des centaines d'attributs.
Les conceptions positionnelles ont une colonne nommée pour chaque attribut. Les interfaces de l'outil
BI sont faciles à construire pour les attributs positionnels car les colonnes nommées sont facilement
présentées dans l'outil. Étant donné que de nombreuses colonnes contiennent un contenu de faible
cardinalité, les performances des requêtes utilisant ces attributs peuvent être très bonnes si des index
bitmap sont placés sur chaque colonne. Les conceptions positionnelles peuvent être mises à l'échelle
jusqu'à environ 100 colonnes avant que les bases de données et les interfaces utilisateur ne deviennent
gênantes ou difficiles à entretenir. Les bases de données en colonnes sont bien adaptées à ces types de
conceptions car de nouvelles colonnes peuvent être facilement ajoutées avec une perturbation minimale
du stockage interne des données, et les colonnes à faible cardinalité contenant seulement quelques
valeurs discrètes sont considérablement compressées.
Lorsque le nombre d'attributs diff érents dépasse votre zone de confort, et si de nouveaux attributs
sont ajoutés fréquemment, une table de pont est recommandée. En fin de compte, lorsque vous disposez
d'un ensemble très vaste et en expansion d'indicateurs démographiques, l'utilisation de stabilisateurs ou
de minidimensions ne s'adapte tout simplement pas gracieusement. Par exemple, vous pouvez collecter
des informations de demande de prêt sous la forme d'un ensemble de paires nomvaleur ouvertes,
comme illustré à la Figure 87. Les données de paire nomvaleur sont intéressantes car les valeurs
peuvent être numériques, textuelles, un pointeur de fichier, une URL ou même une référence récursive à
des données de paire nomvaleur incluses.
Sur une période de temps, vous pourriez collecter des centaines voire des milliers de variables de
demande de prêt diff érentes. Pour une véritable source de données à paire nomvaleur, le champ de
valeur luimême peut être stocké sous forme de chaîne de texte pour gérer la modalité ouverte des
valeurs, qui est interprétée par l'application d'analyse. Dans ces situations, chaque fois que le nombre de
variables est ouvert et imprévisible, une conception de table de pont est appropriée, comme illustré à la
Figure 88.
248 Chapitre 8
Demande de prêt NomValeur Données
photographiques : <image> Revenu primaire : 72 345 $
Autres revenus imposables : 2 345 $ Revenu libre d'impôt :
3 456 $ Gains à long terme : 2 367 $ Salaires saisis :
789 $ Potentiel de jugement en attente : 555 $ Pension
alimentaire : 666 $ Valeur estimée de l'immobilier en
copropriété : $123456 Image de l'immobilier en copropriété :
<image> Liste MLS de l'immobilier en copropriété : <URL>
Pourcentage de propriété de l'immobilier : 50 Nombre de
personnes à charge : 4 Invalidité médicale préexistante :
Blessure au dos Nombre de semaines perdues en raison
d'une invalidité : 6 Déclaration : <document archive> Type
de déclaration de faillite précédente : 11 ans depuis la
faillite : 8 Divulgation financière du conjoint : <paire nom
valeur> ... 100 autres paires nomvaleur...
Figure 87 : Données de la paire nomvaleur de la demande de prêt.
Fait sur la demande de prêt
Clé de date d'application (FK)
Clé du demandeur (FK)
Clé de type de prêt (FK)
Identifiant de l'application (DD) Dimension de divulgation de l'application Pont de divulgation d'application

Dimension de l'élément de divulgation
Clé de l'agent de crédit (FK) Clé de divulgation d'application (PK) Clé de divulgation d'application (FK)
Clé de souscripteur (FK) Description de la divulgation de l'application Clé d'élément de divulgation (FK) Clé d'élément de divulgation (PK)
Clé de succursale (FK) Nom de l'article
Clé d'état (FK) Type de valeur de l'élément
Clé de divulgation d'application (FK) Chaîne de texte de la valeur de l'élément
Figure 88 : Table de pont pour un ensemble de données de paire nomvaleur large et clairsemé.
Table de pont pour plusieurs contacts avec les clients Les grands
clients commerciaux ont de nombreux points de contact, y compris les décideurs, les
agents d'achat, les chefs de service et les liaisons avec les utilisateurs ; chaque point
de contact est associé à un rôle spécifi que. Étant donné que le nombre de contacts est
imprévisible mais peutêtre important, une conception de table de pont est un moyen
pratique de gérer cette situation, comme illustré à la Figure 89. Il convient de veiller à
ne pas exagérer la dimension contact et à en faire un dépotoir pour chaque employé,
citoyen, vendeur ou être humain avec lequel l'organisation interagit. Limitez la dimension
pour ce cas d'utilisation des contacts dans le cadre de la relation client.
Dimension client Dimension du groupe de contacts Contacter le Groupe Bridge Dimensions de contact
Clé client (PK) Clé de groupe de contacts (PK) Clé de groupe de contacts (FK) Clé de contact (PK)

Nom du client Nom du groupe de contacts Clé de contact (FK) Nom du contact
Type de client Rôle du contact Adresse postale du contact
Groupe de contact client (FK) ...
Date du premier contact
...
Figure 89 : Conception de table de pont pour plusieurs contacts.
Comportement client complexe
Le comportement des clients peut être très complexe. Dans cette section, nous aborderons la gestion
des groupes de cohorte de clients et la capture du comportement séquentiel. Nous couvrirons également
des tableaux de faits précis sur la durée et le balisage des événements factuels avec des indicateurs de
satisfaction client ou des scénarios anormaux.
Groupes d'étude du comportement pour les cohortes
Grâce à l'analyse des clients, des requêtes simples telles que la quantité vendue aux clients dans cette
zone géographique au cours de l'année écoulée évoluent rapidement vers des requêtes beaucoup plus
complexes, telles que le nombre de clients qui ont acheté plus le mois dernier que leur montant d'achat
mensuel moyen de l'année dernière. . Cette dernière question est trop complexe pour que les utilisateurs
professionnels puissent l'exprimer dans une seule requête SQL. Certains fournisseurs d'outils de BI
autorisent les sousrequêtes intégrées, tandis que d'autres ont implémenté des fonctionnalités
d'exploration transversale dans lesquelles les requêtes complexes sont divisées en plusieurs instructions
de sélection, puis combinées lors d'une passe ultérieure.
Dans d'autres situations, vous souhaiterez peutêtre capturer l'ensemble de clients à partir d'une
requête ou d'un rapport d'exception, comme les 100 meilleurs clients de l'année dernière, les clients qui
ont dépensé plus de 1 000 USD le mois dernier ou les clients qui ont reçu une sollicitation de test
spécifique, et utilisez ensuite ce groupe de clients, appelé groupe d'étude du comportement, pour des
analyses ultérieures sans retraitement afin d'identifier l'état initial. Pour créer un groupe d'étude de
comportement, exécutez une requête (ou une série de requêtes) pour identifier l'ensemble de clients que
vous souhaitez analyser plus en détail, puis capturez les clés durables du client de l'ensemble identifié
sous la forme d'une table physique réelle composée d'un seul client. colonne clé. En tirant parti des clés
durables des clients, la dimension du groupe d'étude est insensible aux modifications de type 2 de la
dimension client qui peuvent survenir après l'identification des membres du groupe d'étude.
REMARQUE Le secret de la création de requêtes de groupe d'étude comportementales complexes
consiste à capturer les clés des clients ou des produits dont vous suivez le comportement.
Vous utilisez ensuite les clés capturées pour contraindre ultérieurement d'autres tables de faits sans
avoir à réexécuter l'analyse comportementale d'origine.
250 Chapitre 8
Vous pouvez désormais utiliser cette table de dimension de groupe d'étude de comportement
spéciale des clés client chaque fois que vous souhaitez limiter toute analyse sur n'importe quelle
table à cet ensemble de clients spécialement définis. La seule exigence est que la table de faits
contienne une référence de clé client. L'utilisation de la dimension du groupe d'étude du comportement
est illustrée à la Figure 810.
Fait sur la transaction de vente au détail au point de vente
Dimension client
Étude du comportement client Clé de date (FK)
Dimension de groupe Clé client (PK) Clé client (FK)
ID client (clé durable) ID client (clé durable) Plus de FK...
... Quantité de vente
Montant des ventes en dollars
Figure 810 : Dimension groupe d'étude de comportement jointe à la clé durable de la
dimension client.
La dimension du groupe d'études de comportement est attachée avec une équijointure à la clé
durable de la dimension client (voir ID client dans la Figure 810). Cela peut même être fait dans une
vue qui masque la jointure explicite à la dimension de comportement. De cette façon, le modèle
dimensionnel résultant ressemble et se comporte comme une étoile simple. Si la table de dimension
spéciale est masquée sous une vue, elle doit être étiquetée pour l'identifier de manière unique comme
étant associée aux 100 meilleurs clients, par exemple. Pratiquement n'importe quel outil de BI peut
désormais analyser ce schéma particulièrement restreint sans payer de taxe de syntaxe ou de
pénalités d'interface utilisateur pour le traitement complexe qui définissait le sousensemble initial de
clients.
NOTE L'exceptionnelle simplicité des tables de groupes d'études permet de les combiner avec
des opérations d'union, d'intersection et de différence d'ensemble. Par exemple, un ensemble de
clients problématiques ce moisci peut être recoupé avec l'ensemble de clients problématiques du
mois dernier pour identifier les clients qui ont posé problème pendant deux périodes consécutives.
mois.
Les groupes d'étude peuvent être rendus encore plus puissants en incluant une date d'occurrence
dans une deuxième colonne corrélée à chaque clé durable. Par exemple, une étude par panel des
achats des consommateurs peut être menée lorsque les consommateurs entrent dans l'étude
lorsqu'ils présentent un comportement tel que le changement de marque de beurre de cacahuète.
Ensuite, d'autres achats peuvent être suivis après l'événement pour voir s'ils ont de nouveau changé de marque.
Pour y parvenir, ces événements d'achat doivent être suivis avec les bons horodatages pour obtenir
le comportement dans le bon ordre.
Comme de nombreuses décisions de conception, celleci représente certains compromis. Tout
d'abord, cette approche nécessite une interface utilisateur pour capturer, créer et administrer
tables du groupe d'étude du comportement physique réel dans l'entrepôt de données. Une fois qu'un
rapport d'exception complexe a été défini, vous devez être en mesure de capturer les clés résultantes
dans une applet pour créer la dimension de groupe d'étude de comportement spécial. Ces tables de
groupe d'étude doivent résider dans le même espace que la table de faits principale car elles vont
être jointes directement à la table de dimension client. Cela affecte évidemment les responsabilités
du DBA.
Dimension d'étape pour le comportement séquentiel La plupart des
systèmes DW/BI n'ont pas de bons exemples de processus séquentiels. Habituellement, les mesures
sont prises à un endroit particulier en surveillant le flux de clients ou de produits qui passent. Les
mesures séquentielles, en revanche, doivent suivre un client ou un produit à travers une série
d'étapes, souvent mesurées par différents systèmes de capture de données. L'exemple le plus
familier d'un processus séquentiel provient peutêtre des événements Web où une session est
construite en collectant des événements de page individuels sur plusieurs serveurs Web liés entre
eux via le cookie d'un client. Comprendre où une étape individuelle s'inscrit dans la séquence globale
est un défi majeur lors de l'analyse de processus séquentiels.
En introduisant une dimension d'étape, vous pouvez placer une étape individuelle dans le
contexte d'une session globale, comme illustré à la Figure 811.
Exemples de lignes de dimension d'étape :
Total Cette Pas

Marche d'escalier
Nombre Marche d'escalier
Jusqu'à
Fait de la transaction Clé Pas Nombre Fin
1 1 1 0
Clé de date de transaction (FK)
2 2 1 1
Clé client (FK)
3 2 2 0
Clé de session (FK) Dimension d'étape (3 rôles)
4 3 1 2
Numéro de transaction (DD)
Clé d'étape (PK)
5 3 2 1
Clé d'étape de session (FK)
Nombre total d'étapes
6 3 3 0
Clé d'étape d'achat (FK)
Ce numéro d'étape
7 4 1 3
Clé d'étape d'abandon (FK)
Étapes jusqu'à la fin
Plus de FK... 8 4 2 2
Faits... 9 4 3 1
dix 4 4 0
Figure 811 : Dimension d'étape pour capturer des activités séquentielles.
La dimension d'étape est une dimension abstraite définie à l'avance. La première ligne de la
dimension est utilisée uniquement pour les sessions en une étape, où l'étape actuelle est la première
étape et il ne reste plus aucune étape. Les deux lignes suivantes de la dimension d'étape sont
utilisées pour les sessions en deux étapes. La première ligne (Step Key = 2) est pour l'étape numéro
1 où il reste une étape à parcourir, et la ligne suivante (Step Key = 3) est pour l'étape numéro 2
252 Chapitre 8
où il n'y a plus de marches. La dimension de pas peut être prédéfinie pour accueillir des sessions d'au moins
100 pas. Dans la figure 811, vous voyez que la dimension d'étape peut être associée à une table de faits de
transaction dont le grain est l'événement de page individuel. Dans cet exemple, la dimension d'étape a trois
rôles. Le premier rôle est la session globale. Le deuxième rôle est une soussession d'achat réussie, où une
séquence d'événements de page mène à un achat confirmé. Le troisième rôle est le panier d'achat
abandonné, où la séquence d'événements de page se termine sans achat.
Grâce à la dimension d'étape, une page spécifique peut être immédiatement placée dans un ou plusieurs
contextes compréhensibles (session globale, achat réussi et panier abandonné). Mais plus intéressant
encore, une requête peut se limiter exclusivement à la première page des achats réussis. Il s'agit d'une
requête d'événement web classique, où la page « attracteur » des sessions réussies est identifiée.
Inversement, une requête pourrait se limiter exclusivement à la dernière page des paniers abandonnés, là
où le client est sur le point de décider d'aller ailleurs.
Une autre approche de modélisation du comportement séquentiel tire parti de codes fi xes spécifiques
pour chaque étape possible. Si vous suivez les achats de produits des clients dans un environnement de
vente au détail et si chaque produit peut être encodé, par exemple, sous la forme d'un numéro à 5 chiffres,
vous pouvez créer une seule colonne de texte large pour chaque client avec la séquence de codes de
produit. Vous séparez les codes par un caractère non numérique unique. Une telle séquence pourrait
ressembler à 11254|45882|53340|74934|21399|93636|36217|87952|…etc.
Désormais, en utilisant des caractères génériques, vous pouvez rechercher des produits spécifiques
achetés de manière séquentielle, ou achetés avec d'autres produits intervenant, ou des situations dans
lesquelles un produit a été acheté mais un autre n'a jamais été acheté. Les SGBD relationnels modernes
peuvent stocker et traiter de larges champs de texte de 64 000 caractères ou plus avec des recherches génériques.
Tables de faits sur la durée
Dans des applications plus opérationnelles, vous souhaiterez peutêtre récupérer le statut exact d'un client
à un instant arbitraire dans le passé. Le client étaitil en alerte à la fraude lorsqu'il s'est vu refuser une
extension de crédit ? Depuis combien de temps étaitil en alerte fraude ? Combien de fois au cours des deux
dernières années atil été en alerte à la fraude ? Combien de clients ont été en alerte à la fraude à un
moment donné au cours des deux dernières années ? Toutes ces questions peuvent être résolues si vous
gérez avec soin la table des faits de transaction contenant tous les événements client. L'étape de modélisation
clé consiste à inclure une paire d'horodatages, comme illustré à la Figure 812.
Le premier horodatage est le moment précis de la transaction, et le deuxième horodatage est le moment
exact de la transaction suivante. Si cela est fait correctement, l'historique des transactions client conserve
une séquence ininterrompue d'horodatages sans interruption. Chaque transaction réelle vous permet
d'associer
à la fois la démographie et le statut avec le client. Les tables de faits de transactions denses sont
intéressantes car vous pouvez potentiellement modifier les données démographiques et en particulier
le statut à chaque fois qu'une transaction se produit.
Fait de transaction client
Variable de date Clé de date de transaction (FK)
Clé client (FK) Dimension client
Dimension démographique Clé démographique (FK)
Clé d'état (FK) Variable de statut
Numéro de transaction (DD)
Plus de FK...
Date/heure de début d'effet
Date/heure de fin d'effet
Montant
Figure 812 : Horodatages jumeaux dans une table de faits d'intervalle de temps.
L'idée essentielle est que la paire d'horodatages sur une transaction donnée définit une période
de temps dans laquelle les données démographiques et le statut sont constants.
Les requêtes peuvent profiter de ce laps de temps « silencieux ». Ainsi si vous voulez savoir quel
était le statut de la cliente « Jane Smith » le 18 juillet 2013 à 6h33, vous pouvez émettre la requête
suivante :
Sélectionnez Customer.Customer_Name,
Status From Transaction_Fact, Customer_dim, Status_dim
Où Transaction_Fact_Customer_Key = Customer_dim.Customer_key And
Transaction_Fact.Status_key = Status_dim.Status_key And
Customer_dim.Customer_Name = 'Jane Smith'
Et #18 juillet 2013 6:33:00# >= Transaction_Fact.Begin_Eff_ DateTime Et
#18 juillet 2013 6:33:00# < Transaction_Fact.End_Eff_DateTime
Ces horodatages peuvent être utilisés pour effectuer des requêtes délicates sur votre clientèle.
Si vous souhaitez trouver tous les clients qui étaient en alerte à la fraude au cours de l'année 2013,
lancez la requête suivante :
Sélectionnez Customer.Customer_Name
From Transaction_Fact, Customer_dim, Status_dim Where
<joins> And Status_dim Status_Description = 'Fraud Alert'
Et Transaction_Fact.Begin_Eff_DateTime <= 31/12/2013:23:59:59 Et
Transaction_Fact.End_Eff_DateTime >= 01/01/2013:0:0:0
Étonnamment, cette requête gère tous les cas possibles de dates/heures effectives de début et
de fin chevauchant le début ou la fin de 2013, étant entièrement contenues avec 2013 ou
complètement chevauchant 2013.
254 Chapitre 8
Vous pouvez même compter le nombre de jours pendant lesquels chaque client a été en alerte fraude en 2013 :
Sélectionnez Customer.Customer_Name,
somme (le moins (31/12/2013:23:59:59, Transaction_Fact.End_Eff_ DateTime)
le plus grand (1/1/2013:0:0:0, Transaction_Fact.Begin_Eff_ DateTime))
From Transaction_Fact, Customer_dim, Status_dim Où <joins>
And Status_dim Status_Description = 'Fraud Alert'
Et Transaction_Fact.Begin_Eff_DateTime <= 12/31/2013:23:59:59 Et
Transaction_Fact.End_Eff_DateTime >= 1/1/2013:0:0:0 Regrouper par
Customer.Customer_Name
Administration de l'arrièreboutique des doubles horodatages Pour un
client donné, les horodatages sur la séquence des transactions doivent former une séquence
parfaite, ininterrompue et sans lacunes. Il est tentant de faire en sorte que la date/heure
effective de fin soit inférieure d'un "tick" à la date/heure effective de début de la prochaine
transaction, de sorte que la requête SQL puisse utiliser la syntaxe BETWEEN plutôt que les
contraintes plus laides présentées cidessus. Cependant, dans de nombreuses situations, le
petit écart défini par ce tick pourrait être important si une transaction pouvait se situer dans
l'écart. En faisant en sorte que la date/heure effective de fin soit exactement égale à la date et
heure de début de la prochaine transaction, vous éliminez ce risque.
L'utilisation de la paire d'horodatages nécessite un processus en deux étapes chaque fois qu'une nouvelle ligne
de transaction est saisie. Dans la première étape, la date/heure de fin effective de la transaction la plus récente doit
être définie sur une date/heure fictive éloignée dans le futur.
Bien qu'il soit sémantiquement correct d'insérer NULL pour cette date/heure, les valeurs nulles deviennent un casse
tête lorsque vous les rencontrez dans des contraintes car elles peuvent provoquer une erreur de base de données
lorsque vous demandez si le champ est égal à une valeur spécifique. En utilisant une date/heure fictive loin dans le
futur, ce problème est évité.
Dans la deuxième étape, une fois la nouvelle transaction entrée dans la base de données, le processus ETL
doit récupérer la transaction précédente et définir sa date/heure de fin effective sur la date/heure de la transaction
nouvellement saisie. Bien que ce processus en deux étapes soit un coût notable de cette approche double date/
heure, il s'agit d'un compromis classique et souhaitable entre une surcharge ETL supplémentaire dans l'arrière
boutique et une complexité de requête réduite dans la salle avant.
Balisage des tableaux de faits avec des indicateurs de satisfaction Bien que la rentabilité puisse
être l'indicateur de performance clé le plus important dans de nombreuses organisations, la satisfaction client vient
juste après. Et dans les organisations sans mesures de profit, telles que les agences gouvernementales, la
satisfaction est (ou devrait être) numéro un.
La satisfaction, comme la rentabilité, nécessite une intégration entre de nombreuses sources.
Pratiquement tous les processus en contact avec les clients sont une source potentielle d'informations sur la
satisfaction, qu'il s'agisse des ventes, des retours, du support client, de la facturation, de l'activité du site
Web, des médias sociaux ou même des données de géopositionnement.
Les données de satisfaction peuvent être numériques ou textuelles. Dans le Chapitre 6 : Gestion des
commandes, vous avez vu comment les mesures classiques de la satisfaction client pouvaient être modélisées
dans les deux sens simultanément. Les mesures de ponctualité peuvent être à la fois des faits numériques
additifs et des attributs textuels dans une dimension de niveau de service. D'autres mesures purement
numériques de la satisfaction comprennent le nombre de retours de produits, le nombre de clients perdus, le
nombre d'appels d'assistance et les mesures d'attitude envers les produits provenant des médias sociaux.
La figure 813 illustre une dimension de satisfaction des voyageurs fréquents qui pourrait être ajoutée aux
tableaux de faits sur les activités de vol décrits au chapitre 12. Les données textuelles sur la satisfaction sont
généralement modélisées de deux manières, selon le nombre d'attributs de satisfaction et la rareté des
entrées. Les données. Lorsque la liste des attributs de satisfaction est bornée et raisonnablement stable, un
plan positionnel est très efficace, comme le montre la figure 813.
Dimension Satisfaction
Clé de satisfaction (PK)
Indicateur d'arrivée retardée
Indicateur de déroutement vers un autre aéroport
Indicateur de bagages perdus
Échec de l'obtention de l'indicateur de mise à niveau
Indicateur de siège central
Indicateur de problème de personnel
Figure 813 : Dimension de la satisfaction positionnelle pour les voyageurs fréquents des compagnies aériennes.
Balisage des tables de faits avec anormal
Indicateurs de scénario
L'accumulation de tables de faits d'instantané dépend d'une série de dates qui implémentent le « scénario
standard » pour le processus de pipeline. Pour l'exécution des commandes, vous pouvez avoir les étapes de
création de commande, de commande expédiée, de commande livrée, de commande payée et de commande
retournée comme étapes standard dans le scénario de commande. Ce type de conception réussit lorsque
90% ou plus des commandes progressent à travers ces étapes (espéronsle sans retour) sans aucune
exception inhabituelle.
Mais si une situation occasionnelle s'écarte du scénario standard, vous n'avez pas de bon moyen de
révéler ce qui s'est passé. Par exemple, peutêtre lorsque la commande
256 Chapitre 8
a été expédié, le camion de livraison avait un pneu crevé. La décision a été prise de décharger
la livraison dans un autre camion, mais malheureusement, il a commencé à pleuvoir et la
cargaison a été endommagée par l'eau. Ensuite, il a été refusé par le client, et finalement il y a
eu un procès. Aucune de ces étapes inhabituelles n'est modélisée dans le scénario standard de
l'instantané cumulé. Ils ne devraient pas l'être non plus !
La façon de décrire les écarts inhabituels par rapport au scénario standard consiste à ajouter
une dimension de statut de livraison à la table de faits d'instantané cumulée. Dans le cas du
scénario de livraison bizarre, vous marquez cette ligne d'exécution de commande avec le statut
Bizarre. Ensuite, si l'analyste souhaite voir l'histoire complète, il peut se joindre à une table de
faits de transaction associée via le numéro de commande et le numéro de ligne qui contient
chaque étape de l'histoire. La table de faits de transaction est jointe à une dimension de
transaction, qui contient en effet Pneu crevé, Envoi endommagé et Poursuite comme transactions.
Même si cette dimension de transaction augmentera avec le temps avec des entrées
inhabituelles, elle est bien délimitée et stable.
Approches d'intégration des données client
Dans les environnements typiques avec de nombreux processus en contact avec les clients,
vous devez choisir entre deux approches : une seule dimension client dérivée de toutes les
versions des enregistrements du système source client ou plusieurs dimensions client liées entre
elles par des attributs conformes.
Gestion des données de base Création d'un seul
Dimension client
Dans certains cas, vous pouvez créer une dimension client unique qui est le choix "le meilleur
de la race" parmi un certain nombre de sources de données client disponibles. Il est probable
qu'une telle dimension client conforme soit une distillation de données provenant de plusieurs
systèmes opérationnels au sein de votre organisation. Mais il serait typique pour un client unique
d'avoir plusieurs identifiants dans plusieurs systèmes de points de contact. Pour aggraver les
choses, les systèmes de saisie de données n'intègrent souvent pas de règles de validation
adéquates. Évidemment, un objectif opérationnel du CRM est de créer un identifiant client unique
et de limiter la création d'identifiants inutiles. En attendant, l'équipe DW/BI sera probablement
chargée de trier et d'intégrer les sources disparates d'informations sur les clients.
Certaines organisations ont la chance de disposer d'un système centralisé de gestion des
données de base (MDM) qui prend la responsabilité de créer et de contrôler l'entité client unique
à l'échelle de l'entreprise. Mais une telle centralisation est rare dans le monde réel.
Plus fréquemment, l'entrepôt de données extrait plusieurs données client incompatibles
fichiers et construit un système MDM « en aval ». Ces deux styles de MDM sont illustrés à la Figure
814.
Entreprise
MDM
Opérationnel Opérationnel Opérationnel

EDW
Application #1 Application #2 Application #3
Opérationnel Opérationnel Opérationnel

Application #1 Application #2 Application #3
En aval
MDM
EDW
Figure 814 : Deux styles de gestion des données de référence.
Malheureusement, il n'y a pas d'arme secrète pour s'attaquer à cette consolidation des données.
Les attributs de la dimension client doivent représenter la "meilleure" source disponible dans l'entreprise.
Un processus national de changement d'adresse (PNCA) devrait être intégré pour s'assurer que les
changements d'adresse sont saisis. Une grande partie du travail lourd associé à la consolidation des
données client exige une logique de correspondance ou de déduplication des clients.
La suppression des doublons ou des adresses invalides des grandes listes de clients est essentielle
pour éliminer les coûts associés aux communications redondantes, mal acheminées ou non livrables,
éviter les décomptes de clients trompeurs et améliorer la satisfaction des clients grâce à une
communication de meilleure qualité.
La science de l'appariement des clients est plus sophistiquée qu'il n'y paraît à première vue.
Cela implique une logique floue, des algorithmes d'analyse d'adresses et d'énormes répertoires de
recherche pour valider les éléments d'adresse et les codes postaux, qui varient considérablement d'un
pays à l'autre. Il existe des logiciels spécialisés disponibles dans le commerce et des offres de services
qui effectuent une mise en correspondance des clients individuels ou des entités commerciales avec
une précision remarquable. Souvent, ces produits associent les composants d'adresse aux codes de
recensement normalisés, tels que les codes d'État, les codes de pays, les secteurs de recensement,
les groupes d'îlots, les zones statistiques métropolitaines (MSA) et la latitude/longitude, ce qui facilite la fusion.
258 Chapitre 8
de données externes. Comme indiqué au chapitre 10, il existe également des fonctionnalités
de foyer pour regrouper ou lier des clients partageant des informations de nom et/ou d'adresse
similaires. Plutôt que de simplement effectuer une correspondance intrafichier, certains services
maintiennent un énorme fichier de référence externe de tous les ÉtatsUnis à comparer. Bien
que ces produits et services soient coûteux et/ou complexes, il vaut la peine de faire
l'investissement si l'appariement des clients est stratégique pour l'organisation. En fin de
compte, une consolidation efficace des données client dépend d'un équilibre entre la capture
des données aussi précisément que possible dans les systèmes sources, associée à de
puissants outils de nettoyage/fusion de données dans le processus ETL.
Conformité partielle de plusieurs dimensions client Les entreprises créent aujourd'hui des
magasins de connaissances client qui collectent toutes les sources de données internes et
externes en contact avec les clients qu'elles peuvent trouver. Une grande organisation peut
avoir jusqu'à 20 sources de données internes et 50 sources de données externes ou plus,
toutes liées d'une manière ou d'une autre au client. Ces sources peuvent varier énormément en
termes de granularité et de cohérence. Bien sûr, il n'y a pas de clé client de haute qualité
garantie définie dans toutes ces sources de données et aucun attribut cohérent. Vous n'avez
aucun contrôle sur ces sources. Cela ressemble à un gâchis sans espoir.
Dans le Chapitre 4 : Inventaire, nous avons jeté les bases des dimensions conformes, qui
sont le ciment nécessaire pour réaliser l'intégration entre des sources de données distinctes.
Dans le cas idéal, vous examinez toutes les sources de données et définissez une seule
dimension globale que vous attachez à toutes les sources de données, soit simultanément dans
un seul tablespace, soit en répliquant sur plusieurs tablespaces. Une telle dimension conforme
et complète devient un merveilleux moteur pour la création de requêtes, d'analyses et de
rapports intégrés en rendant les étiquettes de ligne cohérentes disponibles pour les requêtes
d'exploration.
Mais dans le monde de l'intégration extrême avec des dizaines de dimensions liées au client
de granularité et de qualité différentes, une telle dimension client complète est impossible à
construire. Heureusement, vous pouvez implémenter une dimension client conforme plus
légère. N'oubliez pas que la condition essentielle pour que deux dimensions soient conformes
est qu'elles partagent un ou plusieurs attributs spécialement administrés qui ont les mêmes
noms de colonne et valeurs de données. Au lieu d'exiger que des dizaines de dimensions liées
au client soient identiques, vous exigez uniquement qu'elles partagent les attributs conformes
spécialement administrés.
Non seulement vous avez allégé la pression sur l'entrepôt de données en assouplissant
l'exigence que toutes les dimensions client de votre environnement soient égales de haut en
bas, mais en plus vous pouvez procéder de manière incrémentielle et agile pour planter les
attributs conformes spécialement administrés dans chacune des dimensions liées au client. Par
exemple, supposons que vous commenciez par définir un niveau assez élevé
catégorisation des clients appelée catégorie de clients. Vous pouvez procéder méthodiquement à travers
toutes les dimensions liées au client, en implantant cet attribut dans chaque dimension sans modifier le
grain d'une dimension cible et sans invalider les applications existantes qui dépendent de ces dimensions.
Au fil du temps, vous augmentez progressivement la portée de l'intégration à mesure que vous ajoutez les
attributs spéciaux aux dimensions client distinctes associées aux différentes sources. À tout moment, vous
pouvez arrêter et exécuter des rapports d'exploration à l'aide des dimensions dans lesquelles vous avez
inséré l'attribut de catégorie de client.
Lorsque l'attribut de catégorie de client a été inséré dans autant de dimensions liées au client que
possible, vous pouvez alors définir des attributs plus conformes. Les attributs géographiques tels que la
ville, le comté, l'état et le pays devraient être encore plus simples que la catégorie de client. Au fil du temps,
l'étendue et la puissance des dimensions clients conformes vous permettent de réaliser des analyses de
plus en plus sophistiquées. Ce développement incrémental avec ses livrables rapprochés correspond à
une approche agile.
Éviter les jointures de table facttofact
Les systèmes DW/BI doivent être construits processus par processus, et non service par service, sur une
base de dimensions conformes pour soutenir l'intégration. Vous pouvez imaginer interroger les tables de
faits de vente ou d'assistance pour mieux comprendre l'historique d'achat ou de service d'un client.
Étant donné que les tables de vente et de support contiennent toutes deux une clé étrangère client,
vous pouvez également imaginer de joindre les deux tables de faits à une dimension client commune pour
résumer simultanément les faits de vente ainsi que les faits de support pour un client donné.
Malheureusement, la jointure plusieursàunàplusieurs renverra la mauvaise réponse dans un
environnement relationnel en raison des différences de cardinalité des tables, même lorsque la base de
données relationnelle fonctionne parfaitement. Aucune combinaison de jointures internes, externes,
gauches ou droites ne produit la réponse souhaitée lorsque les deux tables de faits ont des cardinalités
incompatibles.
Considérez le cas dans lequel vous avez une table de faits des sollicitations des clients et une autre
table de faits avec les réponses des clients aux sollicitations, comme illustré à la Figure 815. Il existe une
relation unàplusieurs entre le client et la sollicitation, et une autre relation unàplusieurs entre le client et
la réponse. Les tables de faits de sollicitation et de réponse ont des cardinalités différentes ; en d'autres
termes, toutes les sollicitations n'aboutissent pas à une réponse (malheureusement pour le service
marketing) et certaines réponses sont reçues pour lesquelles il n'y a pas de sollicitation. Joindre
simultanément la table de faits des sollicitations à la dimension client, qui est, à son tour, jointe à la table
de faits des réponses, ne renvoie pas la bonne réponse dans un SGBD relationnel en raison des différences
de cardinalité. Heureusement, ce problème est facilement évité.
Vous émettez simplement la technique d'exploration transversale expliquée au chapitre 4 pour interroger le
260 Chapitre 8
table de sollicitations et table de réponses dans des requêtes distinctes, puis jointure externe des deux ensembles
de réponses. L'approche d'exploration transversale présente des avantages supplémentaires pour un meilleur
contrôle des paramètres de performance, en plus de prendre en charge les requêtes qui combinent des données
provenant de tables de faits dans différents emplacements physiques.
Fait de sollicitation client Dimension client Fait sur la réponse du client
Clé de date de sollicitation (FK) Clé client (PK) Clé de date de réponse (FK)

Clé client (FK) ID client (clé naturelle) Clé client (FK)
Plus de FK... ... Plus de FK...
Faits sur la sollicitation... Faits sur la réponse...
Figure 815 : Les tables jointes plusieursunplusieurs ne doivent pas être interrogées avec une
seule instruction SELECT.
AVERTISSEMENT Soyez très prudent lorsque vous joignez simultanément une table de dimension unique à deux
tables de faits de cardinalité différente. Dans de nombreux cas, les moteurs relationnels renvoient la « mauvaise
» réponse.
Si les utilisateurs métier combinent fréquemment des données provenant de plusieurs processus métier, une
dernière approche consiste à définir une table de faits supplémentaire qui combine les données une fois dans une
table de faits consolidée plutôt que de compter sur les utilisateurs pour combiner de manière cohérente et précise
les données par euxmêmes. , comme décrit au chapitre 7. Le simple fait d'utiliser SQL pour explorer les tables de
faits afin de combiner les résultats est plus logique lorsque les processus sousjacents sont moins étroitement
corrélés. Bien sûr, lors de la construction de la table de faits consolidée, vous devez toujours établir des règles métier
pour gérer les différences de cardinalité. Par exemple, la table de faits consolidée inclutelle toutes les sollicitations
et réponses ou uniquement celles pour lesquelles une sollicitation et une réponse ont eu lieu ?
Vérification de la réalité à faible latence
Le comportement d'un client au cours des dernières heures ou minutes peut être extrêmement intéressant. Vous
voudrez peutêtre même prendre des décisions tout en traitant avec le client en temps réel. Mais vous devez être
réfléchi pour reconnaître les coûts et les limites des données à faible latence. Généralement, la qualité des données
en pâtit car les données sont livrées plus près du temps réel.
Les utilisateurs professionnels peuvent automatiquement penser que plus les informations arrivent rapidement
dans le système DW/BI, mieux c'est. Mais diminuer la latence augmente la qualité des données
problèmes. La figure 206 résume les problèmes qui surviennent lorsque les données sont livrées plus rapidement.
Dans le monde conventionnel des lots, en téléchargeant peutêtre un fichier de lot une fois toutes les 24 heures,
vous obtenez généralement des ensembles de transactions complets. Par exemple, si un client commercial passe
une commande, il peut avoir à passer une vérification de crédit et à vérifier l'engagement final. Le téléchargement
par lots inclut uniquement les commandes où toutes ces étapes ont eu lieu. De plus, étant donné que le
téléchargement par lots n'est traité qu'une fois toutes les 24 heures, l'équipe ETL a le temps d'exécuter l'éventail
complet des contrôles de qualité des données, comme nous le décrirons au Chapitre 19 : Soussystèmes et
techniques ETL.
Si les données sont extraites plusieurs fois par jour, la garantie d'ensembles de transactions complets peut
devoir être abandonnée. Le client peut avoir passé la commande mais n'a pas passé la vérification de crédit. Il est
donc possible que les résultats doivent être ajustés après coup. Vous ne pouvez pas non plus exécuter l'éventail
complet des vérifications de la qualité des données, car vous n'avez pas le temps d'effectuer des recherches
multitables approfondies.
Enfin, vous devrez peutêtre publier des données dans l'entrepôt de données lorsque toutes les clés n'ont pas été
résolues. Dans ce cas, il peut être nécessaire d'utiliser des entrées dimensionnelles temporaires en attendant des
flux de données supplémentaires.
Enfin, si vous fournissez des données instantanément, vous n'obtiendrez peutêtre que des fragments de
transaction et vous n'aurez peutêtre pas le temps d'effectuer des contrôles de qualité des données ou d'autres
traitements des données.
La livraison de données à faible latence peut être très utile, mais les utilisateurs professionnels doivent être
informés de ces compromis. Une approche hybride intéressante consiste à fournir une livraison intrajournalière à
faible latence, mais à revenir ensuite à un extrait par lots la nuit, corrigeant ainsi divers problèmes de données qui
ne pouvaient pas être résolus pendant la journée. Nous discutons de l'impact des exigences de faible latence sur
le système ETL au Chapitre 20 : Processus et tâches de conception et de développement du système ETL.
Résumé
Dans ce chapitre, nous nous sommes concentrés exclusivement sur le client, en commençant par un aperçu des
bases de la gestion de la relation client (CRM). Nous nous sommes ensuite penchés sur les problèmes de
conception liés à la table de dimension client. Nous avons discuté de l'analyse des noms et des adresses où les
champs opérationnels sont décomposés en leurs éléments de base afin qu'ils puissent être standardisés et validés.
Nous avons exploré plusieurs autres types d'attributs de dimension client courants, tels que les dates, les attributs
de segmentation et les faits agrégés. Des stabilisateurs de dimension qui contiennent un grand bloc d'attributs de
cardinalité relativement faible ont été décrits.
Ce chapitre a présenté l'utilisation de tables de pont pour gérer les attributs de dimension imprévisibles et peu
remplis, ainsi que les attributs de dimension à plusieurs valeurs.
262 Chapitre 8
Nous avons également exploré plusieurs scénarios complexes de comportement des clients, notamment des activités
séquentielles, des tableaux de faits sur la durée et le marquage d'événements factuels avec des indicateurs pour
identifier les situations anormales.
Nous avons terminé le chapitre en discutant des approches alternatives pour identifier de manière cohérente les
clients et consolider un riche ensemble de caractéristiques à partir des données sources, soit via la gestion
opérationnelle des données de référence, soit par un traitement en aval dans l'arrièreboutique ETL avec une
conformité potentiellement partielle. Enfin, nous avons abordé les défis des exigences de données à faible latence.

Kimball The Data Warehouse Toolkit 3rd Edition Pages 265 298

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Kimball The Data Warehouse Toolkit 3rd Edition Pages 265 298

Transféré par

Droits d'auteur :

Formats disponibles

Machine Translated by Google

Date du premier achat Dimension client Tableau des faits

Date du 1er achat Clé (PK) Clé client (PK) Clé de date de transaction (FK)

Démographie du pays Dimension du stabilisateur Dimension client Tableau des faits

Clé démographique du comté (PK) Clé client (PK) Clé client (FK)

Population de moins de 5 ans Message d'accueil du client Faits ...

Identifiant de l'application (DD) Dimension de divulgation de l'application Pont de divulgation d'application

Clé de souscripteur (FK) Description de la divulgation de l'application Clé d'élément de divulgation (FK) Clé d'élément de divulgation (PK)

Dimension client Dimension du groupe de contacts Contacter le Groupe Bridge Dimensions de contact

Clé client (PK) Clé de groupe de contacts (PK) Clé de groupe de contacts (FK) Clé de contact (PK)

Type de client Rôle du contact Adresse postale du contact

Total Cette Pas

Fait de la transaction Clé Pas Nombre Fin

Opérationnel Opérationnel Opérationnel

Opérationnel Opérationnel Opérationnel

Fait de sollicitation client Dimension client Fait sur la réponse du client

Clé de date de sollicitation (FK) Clé client (PK) Clé de date de réponse (FK)

Vous aimerez peut-être aussi