|
|
Forums, dernières contributions
Modélisation - Comment compter une dimension (1 seule dimension hiérarchique ou plusieur mini-dimensions) ?
Supposons une table de dimension client en Slowly Changing Dimension (Kimball) composée hiérarchiquement de groupe client, client. (un groupe client = groupe RENAULT,Groupe PSA,...), inutile de gérer le lien 1 client plusieurs groupes, ce n'est pas ma problématique qui m'interresse ici.
Il y a moins de groupes que de clients.
Selon Kimball, il faudrait faire une unique dimension client pour eviter les mini-dimensions mais COMMENT ensuite DENOMBRER LE NOMBRE DE GROUPES, LE NOMBRE DE CLIENTS ?
Après plusieures heures passées sur le Net, je vous livre l'état de ma reflexion :
Pour le client : pas de probème : créer une table de fait (table de fait sans fait selon Kimball) avec un 1 pour chaque client. Id_date,id_client, nb_cli.
La table de fait ne contient une ligne avec nb_cli à 1 que pour les versions courantes de la dimension client.
Pour le groupe : problème !
A moins que l'unique table de dimension ne contienne 2 niveaux (ajout d'un champ niveau qui contient Groupe ou client )càd quelle soit la fusion d'une table groupe (les données clients sont à blanc) et d'une table clients avec les groupes renseignés. => C'est à dire que l'alimentation en SCD se fait en 2 temps : 1) sur le niveau groupe 2) sur le niveau client.
Il serait possible de créer une table de Fait unique: id_date, d_client, nb_groupe à l'image de la table de fait client.
A moins que l'on crée :
1) un snow-flake Groupe -> client mais cela ajoute une jointure et donc des temps de requêtes plus longs.
2) Une mini-dimension Groupe càd que la dimension unique est éclatée en 2 dimensions l'une pour le groupe et l'autre pour le client. ces 2 tables n'étant pas jointes l'une à l'autre mais directement sur les faits.
Je ne vois que peu d'inconvénients : il sera toujours possible de recréer l'illusion de la hiérarchie dans l'univers ou le catalogue fourni aux utilisateurs.
Comment gerez-vous cette problématique, j'aimerais éviter de créer des tables de faits à mille pates !
Merci Stefan, pour ta réponse et tes autres contributions.
Effectivement, le count distinct(sur ID_CLIENT ou ID_GROUPE) fournit simplement la réponse et permet d'avoir le nombre de clients (ou de groupes) LORSQUE la requête fait intervenir une table de fait (factures par exemple).
Mais, si je veux juste avoir le nombre de clients à un instant t INDEPENDAMMENT de toute table de faits, un 2 éme indicateur comportant un PROMPT pour renseigner la date est à créer, c'est ça ? Ce qui permet ensuite en l'utilsant 2 fois au niveau du rapport de faire des variations entre 2 dates. Je ne sais pas si ces rapports se rafraîchissent ensuite facilement les mois suivants avec les prompts ?
La volumétrie sur une des tables à dénombrer sera de 500 000, ce ne sont pas des clients mais la problématique reste la même.
Ma difficulté première portait surtout sur le peuplement de la dimension hiérarchique client : je ne savais pas s'il était possible d'y faire figurer des groupes sans clients et des clients sans groupe. A priori, c'est possible en remplacant au chargement les données absentes avec des clés arbitraires (0 ou -1) et des valeurs arbitraires (groupe inexistant , client inexistant). Du coup, adieu flocons !
|
Ecrire une réponse
