Rappelez-vous qu'une table de faits est un endroit où nous stockons des mesures émanant d'un processus métier particulier. Les tables de dimension entourent et décrivent ces mesures.
Rappelez-vous aussi que le grain d'une table de fait est la définition exacte de ce qu'un enregistrement d'un fait représente. Il est certainement vrai que la clé d'une table de fait définit le grain, mais souvent la déclaration la plus claire du grain est un concept métier plutôt qu'une liste technique de clés étrangères. Par exemple, le grain d'une table de fait représentant un processus de prise de commande peut être "la ligne d'un produit sur une commande", alors que la définition technique de la clé de cette table peut être "numéro de facture par produit par promotion".
Les milliers de représentations de table de faits qu'il m'ait été donné de voir, peuvent être classés en trois grains fondamentaux:
- Le grain de TRANSACTION, qui représente un point dans l'espace et le temps;
- Le grain de l'INSTANTANÉ PÉRIODIQUE, qui représente un laps de temps régulier répété à plusieurs reprises, et
- Le grain de l'INSTANTANÉ CUMULÉ, qui représente le cycle de vie complet d'une entité.
La table de faits de type instantané cumulé est spécial, d'une certaine façon. Contrairement aux autres grains, celui-ci a généralement un certain nombre de dimensions temporelles, représentant le moment spécifique d'une étape dans la vie de l'entité. Par exemple, une commande est:
- créé,
- engagé,
- expédié,
- livré,
- payé, et peut-être
- retourné.
Ainsi, la conception d'une table de faits Commande, de type instantané cumulé, pourrait commencer avec six clés temporelles, toutes étant des clés étrangères pointant sur des vues indépendantes de la dimension Calendrier. Ces six vues de la table Calendrier sont appelés "rôles" et sont sémantiquement indépendantes comme si c'était des tables physiques distinctes, parce que nous les avons définies comme des vues distinctes.
L'autre aspect inhabituel d'une table de faits de type instantané cumulé, est que nous revisitons les mêmes enregistrements à plusieurs reprises pour changer physiquement les clés étrangères et les faits mesurés, en fonction du déroulement de la vie (généralement de courte durée) de l'entité. Le processus des commandes est un exemple classique.
Maintenant que nous nous sommes rappelé les problèmes de conception des tables de faits d'instantanés cumulés, nous allons appliquer cette technique de conception à un processus de suivi (ou pipeline). Nous allons utiliser le suivi des admissions des étudiants, mais ceux d'entre vous intéressés par le suivi des ventes doivent être en mesure d'appliquer cette conception facilement.
Dans le cas du suivi des admissions, les futurs étudiants progressent grâce à un ensemble standard d'étapes. Nous sommes intéressés par suivre les activités de 15 étapes clés dans le processus, y compris 1) la réception des scores au test d'admission préliminaire, 2) l'information demandée (via le web ou autre), 3) l'information envoyée, 4) l'entretien réalisé, 5 ) la visite du campus, 6) la demande reçue, 7) la transcription reçue, 8) la réception les résultats aux tests, 9) les recommandations reçues, 10) première revue des admissions, 11) étude des demandes d'aide financière, 12) décision finale d'admission, 13) étudiant accepté, 14) étudiant admis et 15) élève inscrit. A tout moment, les gestionnaires des admissions et des départements d'inscription sont intéressés par combien de candidats sont à chaque étape du pipeline. C'est un peu comme un entonnoir où de nombreux candidats entrent dans le pipeline, mais beaucoup moins progressent jusqu'à la phase finale. Les gestionnaires veulent également analyser l'ensemble des candidats par une variété de caractéristiques. Dans cet exemple, les admissions, nous pouvons être sûrs qu'il existe une dimension Demandeur très riche, remplie avec des données démographiques intéressantes.
Le grain de l'instantané cumulé est une ligne par demandeur. Parce que c'est un instantané cumulé, nous révisons et actualisons l'enregistrement unique de chaque candidat dans la table de faits chaque fois que l'une des étapes est terminée.
Un élément clé de la conception est un ensemble de 15 faits numériques, chacun à 0 ou 1 selon que le candidat ait passé ou non chacune des 15 étapes énumérées ci-dessus. Bien que techniquement ces 15 faits 1/0 pourraient être déduits à partir des 15 clés de date, les faits numériques additifs rendent l'application élégante et facile à utiliser avec presque n'importe quelle requête ou outil de reporting.
Astuce supplémentaire, nous ajoutons quatre faits numériques additifs représentant des "retards" ou des écarts de temps entre les étapes particulièrement importantes du processus. Il s'agit notamment de:
- Renseignements demandés ==> envoyé en retard
- Demande présentée ==> présenté en retard
- Demande présentée ==> Décision finale retardée
- Décision finale ==> Accord ou refus reporté
Ces faits de retard sont à la fois de bons diagnostics pour l'analyse, mais ils aident les gestionnaires à affiner le processus en identifiant les goulots d'étranglement.
Notre conception finale de la table de faits ressemble à cela:
Clé de la date de réception des scores au test préliminaire (FK)
Clé de la date de demande d'informations (FK)
Clé de la date d'envoi des informations (FK)
Clé de la date de l'entrevue réalisée (FK)
Clé de la date de visite du campus (FK)
Clé de la date de présentation de la demande (FK)
Clé de la date de réception de la transcription (FK)
Clé de la date de réception des scores au test (FK)
Clé de la date de réception des recommandations (FK)
Clé de la date de première revue des admissions (FK)
Clé de la date de demande d'aide financière (FK)
Clé de la date d'admission finale (FK)
Clé de la date de réception de la décision du demandeur (FK)
Clé de la date d'admission (FK)
Clé de la date d'inscription (FK)
Clé du demandeur (FK)
Clé de la décision d'admission (FK)
Score au test préliminaire
Nombre d'informations demandées
Nombre d'informations envoyées
Nombre d'informations demandées - envoyé en retard
Nombre d'interviews réalisées
Nombre de visite du campus
Nombre de demandes présentées
Nombre de transcriptions Reçues
Score au test
Nombre de recommandations reçues
Nombre de demandes complètes
Nombre de demandes présentées - en retard
Nombre d'admissions après la première revue
Nombre d'évaluation pour une aide financière
Nombre de décisions d'admission finale
Nombre de demandes présentées - décision finale reportée
Nombre d'acceptés
Nombre de refus
Décision finale - Accord/refus reporté
Nombre d'admis
Nombre d'inscrits
Design intéressant! Imaginez combien il serait facile de résumer l'état du pipeline à n'importe quel moment dans le temps. Bien que les enregistrements soient évidemment large, ce n'est pas particulièrement une grande table. Si vous êtes une grande université avec 100 000 candidats par an, vous ne disposez 100 000 enregistrements par an. Supposons que les 17 clés étrangères soient toutes des entiers de 4 octets (clés de substitution), et les 21 quantités et les retards sont des petits entiers de 2 octets. Nos enregistrements sont alors de 17 x 4 + 21 x 2 = 110 octets. Cela fait environ 11 Mo de données par an dans cette table de faits. Vérifiez mes calculs. En fait, c'est un résultat commun pour des tables de faits de type instantanés cumulés. C'est le plus petit des trois types, et de loin.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #37: Modeling a pipeline with an accumulative snapshot", publié le 13 juin 2002.
Aucun commentaire:
Enregistrer un commentaire