Chaque fois que nous construisons une table de faits contenant des mesures de notre entreprise, nous entourons la table de faits avec "tout ce que nous savons être vrai". Dans un modèle dimensionnel, ce "tout-ce-que-nous-savons" est emballé dans un ensemble de dimensions. Concrètement, nous insérons les clés étrangères, une par dimension, dans notre table de faits, et relions ces clés étrangères aux clés primaires correspondantes de chaque dimension. Chaque dimension (comme produit ou client) contient un ensemble détaillé d'attributs textuels fortement corrélés représentant des membres individuels de la dimension (comme des produits individuels ou des clients).
Nous pouvons étendre cette approche "tout-ce-que-nous-savons" à la conception de la table de faits en incluant des éléments clés de métadonnées qui sont connus pour être vrai quand un fait relevé individuel est créé. Par exemple, lorsque nous créons un enregistrement de la table de fait, nous devrions connaître des choses telles que
- quel système source a fourni les données de faits (plusieurs attributs si plusieurs systèmes sources).
- quelle version du logiciel d'extraction à créé l'enregistrement.
- quelle logique d'allocation (le cas échéant) a été utilisé pour créer l'enregistrement.
- si un champ de la table de fait comportant la valeur "code NA" est effectivement inconnu, impossible, corrompu, ou non-disponible pour le moment.
- si un fait précis a été modifié après le chargement initial, et si oui, pourquoi.
- si l'enregistrement contient des faits de plus de 2, 3 ou 4 fois l'écart-type de la moyenne, ou de manière équivalente, en dehors de diverses limites de confiance provenant d'une autre analyse statistique.
Les trois premiers points décrivent la traçabilité provenance) de l'enregistrement de la table de fait. En d'autres termes, d'où les données proviennent-elles? Les trois derniers points décrivent notre confiance dans la qualité des données pour cet enregistrement de la table de faits.
Une fois que nous commençons à penser de cette façon, nous pouvons arriver à une longue liste d'éléments de métadonnées décrivant la traçabilité des données et la confiance de la qualité des données. Mais pour cet article, nous nous arrêterons à ces six là.
Bien que ces six indicateurs pourraient être codées de diverses façons, je préfère que cela soit sous forme textuelle. En fin de compte, nous allons requêter et faire des rapports sur ces différents attributs d'audit, et nous voulons que nos interfaces utilisateurs et nos libellés de rapport affichent un texte compréhensible. Alors, peut-être la version du logiciel d'extraction (point n ° 2) peut contenir la valeur «Informatica version 6.4, extrait de Revenue v 5.5.6". Le point n ° 5 pourrait contenir des valeurs telles que "pas modifiée" ou "altéré en raison de retraitement".
Le moyen le plus efficace pour ajouter les informations sur la traçabilité et la confiance à une table de fait est de créer une clé étrangère d'audit dans la table de faits. Une clé représentant un entier de 4 octets est plus que suffisant, car la dimension d'audit correspondante pourrait avoir jusqu'à 4 milliards d'enregistrements. Nous n'aurons pas autant d'enregistrements!
Nous construisons la dimension Audit comme une simple dimension contenant 7 champs:
- Clé Audit (clé primaire, entier de 4 octets)
- Système source (text)
- Logiciel d'extraction (text)
- Logique d'allocation (text)
- Statut de la valeur (text)
- Statut valeur altérée (text)
- Statut hors limite (text)
Dans notre processus ETL (extract-transform-load), nous suivons l'ensemble de ces indicateurs et les tenons prêts à l'emploi lorsque l'enregistrement de la table de fait est assemblé dans son état final. Si les six champs d'audit existent déjà dans la dimension Audit, nous allons chercher la clé primaire appropriée dans la dimension Audit et nous l'utilisons comme clé étrangère dans la table de faits. Si nous n'avons aucun enregistrement dans la dimension Audit applicable à notre enregistrement de la table de fait, nous ajoutons 1 à la valeur maximale de la clé primaire de la dimension Audit, et nous créons un nouvel enregistrement dans la dimension Audit. Il s'agit d'un processus de clé de substitution standard. Ensuite, nous procédons comme pour le premier cas. De cette façon, nous construisons la dimension d'audit au fur et à mesure du temps.
Notez que si nous chargeons un grand nombre d'enregistrements chaque jour, presque tous les enregistrements auront la même clé étrangère d'audit, puisque sans doute la quasi-totalité des enregistrements seront "normaux". Nous pouvons modifier le traitement du paragraphe précédent pour profiter de cela en mettant en cache la clé d'audit de l'enregistrement "normal", et le éviter la recherche pour tous les enregistrements normaux.
Maintenant que nous avons construit la dimension d'audit, comment l'utilisons-nous?
La beauté de cette conception est que les métadonnées sur la traçabilité et la confiance sont maintenant devenus des données régulières, et peuvent maintenant être interrogées et analysées avec les autres dimensions. Il existe deux approches de base pour enrichir vos requêtes et vos rapports avec les indicateurs de la dimension d'audit.
L'approche "pauvre", ajoute simplement les attributs d'audit souhaités directement dans le SELECT d'une requête SQL. Voici un exemple pour une requête sur les ventes:
SELECT Produit, Statut de la valeur, sum(Ventes), count(*)
Maintenant, votre rapport affichera une ligne supplémentaire à chaque fois qu'une condition anormale apparaîtra. Vous obtiendrez un total qui vous permet de juger de la gravité de l'erreur.
L'approche "riche" exécute des requêtes produisant des colonnes distinctes (et non des lignes séparées) avec des indicateurs plus sophistiqués de la traçabilité ou de la qualité. Par exemple, avec notre requête sur les ventes de l'exemple ci-dessus:
Produit >> sum(Ventes) >> % de données provenant de l'ancien système >> % de données corrompues
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #26: Adding an Audit Dimension to Track Lineage and Confidence", publié le 1 août 2001.
Aucun commentaire:
Enregistrer un commentaire