3-A. Les tables de fait▲
Tout d'abord démystifions la chose... Une table de fait n'est rien d'autre qu'un ensemble de données structurées, composé de champs de type dimension (le contexte) et champs de type mesure (les faits).
Un processus d'entreprise peut être représenté à l'aide d'une ou plusieurs tables de fait. À ce jour on dénombre trois types de tables de fait(5) : les tables de fait de transaction, les tables de fait périodique et les tables de fait récapitulative.
3-A-1. Les règles d'or des tables de fait▲
Voici une série de conseils qui pourront vous être utiles lors de la mise en place de n'importe quelle table de fait (n'hésitez pas à les relire avant d'en concevoir une nouvelle, vous économiserez sans doute un temps précieux) :
- l'unicité d'une ligne d'une table de fait doit toujours pouvoir être garantie par la concaténation de ses champs dimensions. En effet, même si les concepteurs rajoutent souvent une clé physique de type « auto-incrémenté » la clé logique de table reste l'unicité du contexte. En d'autres termes, si un fait (une occurrence) a exactement le même contexte (même valeurs de dimensions) qu'un autre fait, cela doit être la même ligne ;
- une table de fait contient toujours la dimension temps. Bien que la durée de rétention varie en fonction de la granularité de la mesure, TOUTES vos mesures doivent comprendre un historique pour vous permettre de produire des tendances. Un entrepôt de données quel qu'il soit doit comprendre la dimension temps (c'est à l'équipe métier de juger de la durée minimale de rétention requise pour leur permettre de prendre des décisions et non pas aux administrateurs de base de données) ;
- les mesures stockées dans une table de fait sont (presque) toujours de types numériques et additifs. Cela implique les règles suivantes : les ratios sont toujours stockés à travers deux champs distincts (numérateur et dénominateur). Les mesures stockées ne correspondent jamais à une moyenne (la somme des moyennes ne correspond pas à la moyenne des sommes !). Prenez garde au calcul des délais, vous ne stockez pas les dates mais la durée effectif du délai calculé quel qu'en soit l'unité (jours, minutes ou secondes) ;
- les données d'une table de fait sont figées. Une table de fait stocke une situation passée et révolue (sauf table de fait récapitulative). Il ne doit pas y avoir d'opération de mise à jour sur la table une fois le chargement effectué et que ses données sont à disposition des utilisateurs (sauf correction). Si certains de vos utilisateurs génèrent le rapport « situation financière du 31 mars 2011 » le 5 avril et que d'autres utilisateurs génèrent ce même rapport le 10 mai, ils doivent absolument avoir accès aux mêmes chiffres ;
- une table de fait est toujours interrogée à partir d'un contexte donné. Sa volumétrie ainsi que sa nature transverse (multitude de dimensions) vous obligent à interroger une table de fait à partir d'un contexte bien particulier (filtre de dimensions) ;
- des vues d'une même table de fait peuvent être produites avec des filtres entièrement différents parce que les besoins d'un service à un autre sont entièrement différents. Ce qui importe, c'est que les deux services aient la même définition de la mesure, car les rapports sont produits à partir de la même source de données ;
- une table de fait ne doit pas contenir de ligne artificielle valorisée à zéro. Il faut donc éviter les alimentations de type « produit cartésien de dimension ». Exemple, si votre système opérationnelle ne contient pas d'information sur la vente du produit « REF-0001 » vendu dans l'agence « ABC » qu'il en soit ainsi ! Ne créez pas la ligne « REF-001 | ABC | ... | 0 » sous peine d'explosion du volume de données ;
- une table de fait ne comprend que les clés des dimensions, sous forme de clé étrangère (numérique de préférence et dénuée de sens pour faciliter la maintenance, cf. chapitre sur les tables de dimensions). Si les tables de fait peuvent être très longues en termes de nombre d'occurrences, elles doivent être étroites en largeur pour pouvoir les compresser en terme d'espace et être performante ;
- le volume d'une table de fait dépend (en partie) du nombre de dimensions AINSI QUE de la structure de celle-ci (profondeur, nombre d'occurrences). En d'autres termes plus le contexte est précis et plus votre table de fait sera volumineuse et difficile à maintenir.
3-A-2. Quelques patrons liés aux tables de fait▲
Comme nous l'avons déjà précisé le concepteur d'entrepôt de données distingue différents types de tables de fait : de transaction, périodique et récapitulative. Même si nous classons les tables de fait par type, le principe reste identique : c'est une structure contenant des champs « clé étrangère » de table de dimensions (contexte) et des champs de type mesure.
Connaître et maîtriser les différents types de tables de fait vous aidera tout au long de la conception de votre marché de l'information. Cela vous permettra de mettre en place plus rapidement un SID complet. En effet, malgré la transversalité du système, les besoins de reporting sont redondants. En connaissant les patterns à appliquer vous accélérerez la mise en place ainsi que la qualité et la pertinence de l'information fournie.
3-A-2-A. Table de fait de transaction▲
C'est le type le plus commun et le plus fondamental, l'ensemble de votre entrepôt repose sur les tables de fait de transaction.
Principe : comme son nom l'indique elle repose sur la transaction du système opérationnel. Vous devez définir les clés des dimensions de chacune des transactions opérationnelles et extraire les mesures qui vous intéressent. Ici, la difficulté provient de la gestion des dimensions (notamment le traitement des nouvelles occurrences) ainsi que du compromis volumétrie/précision du contexte fourni (cf. étape choix de la granularité de la table de fait).
Attention, il ne s'agit pas d'avoir une ligne par transaction, bien au contraire. Ici l'unicité de l'occurrence est marquée par l'unicité de son contexte (ensemble des clés de dimensions, cf. règle 1 des propriétés des tables de fait). Notez que plus vous agrégez les faits, moins il sera possible de proposer des dimensions dégénérées (cf. chapitre « Les Dimensions »).
Vous n'avez pas à faire d'opération de mise à jour sur une table de fait de transaction (sauf erreur de chargement). La table de fait de transaction représente le niveau le plus détaillé que peut proposer votre entrepôt sur le processus en question, c'est pourquoi le choix de la granularité de celle-ci est si importante.
3-A-2-B. Table de fait périodique▲
Une table de fait périodique est généralement construite à partir d'une table de fait de transaction. Elle représente soit l'image d'une table de fait de transaction à un moment T ; soit la synthèse d'une table de fait de transaction à travers l'agrégation des mesures sur ses dimensions.
Les tables de faits périodiques permettent d'analyser un volume de transaction beaucoup plus important et ainsi de dégager des tendances. En contrepartie, le nombre et les profondeurs des dimensions sont réduits. En d'autres termes, plus vous agrégez les mesures de la table de transaction plus votre contexte d'analyse sera limité mais plus vous pourrez traiter de transactions et dégager des tendances. Comme toujours tout est histoire de compromis...
Une bonne approche peut être de proposer une table de fait de transaction avec un contexte d'analyse très riche et très détaillé sur un axe de temps limité (trois mois) couplé à une table de fait périodique avec un contexte moins riche (profondeurs de dimension moins importante ou suppression de dimensions) mais un axe de temps plus important (36 mois).
Tout comme sur les tables de faits de transaction, hormis une erreur de chargement, les tables de fait périodiques ne doivent pas être soumises à des opérations de mise à jour, la production de ce type de tables consiste à agréger et à charger les données.
Si votre processus possède un nombre de dimensions restreint avec très peu d'occurrences, le volume traité par votre table de fait de transaction peut éventuellement vous permettre de proposer un axe temps suffisant à vos analystes, auquel cas la mise en place d'une table de fait périodique n'est pas nécessaire, voir déconseillée.
3-A-2-C. Table de fait récapitulatif▲
Très utile et complémentaire aux autres types de tables de fait, les tables de fait récapitulatives sont aussi plus complexes et plus difficiles à maintenir.
La table de fait récapitulative n'est pas fondée sur la transaction ou sur l'axe temps mais sur l'analyse détaillée d'une dimension. Exemple : l'activité d'un site de production. Dans les autres types de table de fait la référence d'un site de production était un axe d'analyse possible mais le but premier était l'analyse du processus à travers ses différentes mesures. Dans les tables de fait récapitulatives les rôles s'inversent, on souhaite analyser une dimension à travers différents processus. La table de fait récapitulative va donc contenir différentes mesures liées à différents processus pour une même occurrence de dimension.
Les tables de fait récapitulatives permettent une analyse transversale d'une dimension clé stratégique. Contrairement aux autres types de tables de fait, l'essentiel des opérations effectuées sur ce type de table sont des mises à jour. Les tables de fait récapitulatives sont complémentaires aux autres types de table fait et leur contenu repose entièrement sur les tables de fait de type transactionnelle.
La notion de table de fait récapitulative peut encore vous paraître abstraite, prenons un exemple basique pour illustrer ces propos. Imaginons que vous disposiez de deux tables de faits de type transaction. La première est liée à un processus de vente (dimensions utilisés : Temps, Magasin, Employé, Produit, Age client, Localité client). La seconde est liée à un processus de réclamation (dimensions utilisés : Temps, Produit). Vous pourriez donc créer une table de fait récapitulative « Mesure Produit » qui intègre pour chaque produit la notion de ventes et de réclamation.