Avant de lire ce contenu, vous devez obligatoirement maîtriser les notions de base en modélisation dimensionnelle :
- Modélisation dimensionnelle - Introduction
- Modélisation dimensionnelle - Notions de base
Les différents types de tables de faits
Diaporama Les différents types de tables de faits
Dans un schéma dimensionnel, la table de faits contient ce que l’on appelle des faits qui correspondent aux mesures que les utilisateurs vont utiliser pour construire les indicateurs dans leurs tableaux de bord. Ces faits peuvent ensuite être agrégés suivant différentes dimensions qui correspondent à autant d’axes d’analyse.
Lors de la conception de votre schéma dimensionnel il est essentiel, pour commencer, de définir le type de la table de faits ce qui va de pair avec la définition de sa granularité.
Afin de déterminer le type de la table de faits, une méthode consiste à identifier le type d’événement qu’elle décrit, ce que nous allons détailler.
Table de faits de transactions
Les tables de faits de transactions (TF pour Transaction Fact table) sont basées sur des événements discrets. Chacune de leurs lignes correspond à un “point dans le temps” ou à un événement de très courte durée. Il s’agit souvent du niveau de détail atomique dans les systèmes opérationnels sources.
L’information temporelle doit être disponible lors du rafraichissement périodique de l’entrepôt de données et il n’y a pas de sens à ce qu’elle soit modifiée.
A titre d’exemples on pourrait citer :
- Un client qui achète un produit dans un magasin
- Un visiteur d’une page internet
- Un employé qui répond à un appel au support technique
Source : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema. Laurence Corr and Jim Stagnitto. DecisionOne Press, 2011, page 28
Lecture Table de faits de transactions : Star Schema. Christopher Adamson. pages 260-265
Lecture Table de faits de transactions : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema Laurence Corr, and Jim Stagnitto. pages 228-229
Table de faits “instantané récapitulatif”
Les tables de faits “instantané récapitulatif” (AS pour Accumulating Snapshot) sont basées sur des événements évolutifs. Chacune de leurs lignes correspond à un événement qui évolue dans le temps. Un événement évolutif peut ainsi durer plusieurs jours/semaines et changer plusieurs fois d’état.
L’information temporelle est partiellement disponible lors du rafraîchissement périodique de l’entrepôt de données en fonction de l’état d’avancement de l’événement.
A titre d’exemples on pourrait citer :
- Une commande en ligne qui traverse différentes phases : commandée, préparée, expédiée, livrée
- Un étudiant qui postule à une université : effectué, en cours de traitement, accepté/refusé
Source : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema. Laurence Corr and Jim Stagnitto. DecisionOne Press, 2011, page 28
Lecture Table de faits instantané récapitulatif : Star Schema. Christopher Adamson. pages 274-287
Lecture Table de faits instantané récapitulatif : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema Laurence Corr, and Jim Stagnitto. pages 231-232
Table de faits “instantané périodique”
Les tables de faits “instantané périodique” (PS pour Periodic Snapshot) sont basées sur des événements récurrents. Chacune de leur lignes correspond à un événement qui se répète à une fréquence régulière et qui résume ce qu’il s’est passé sur une période de temps.
Les tables de faits périodiques ne sont donc pas mises à jour lors de chaque rafraichissement de l’entrepôt de données.
A titre d’exemples on pourrait citer :
- Un inventaire des stocks qui se déroule chaque soir
- La consolidation de son solde bancaire chaque mois
- La quantité de pluie tombée sur une heure
Les événements récurrents sont souvent utilisés pour agréger des événements discrets (l’inventaire des stocks le soir prend en compte toutes les ventes de la journée) ou des événements dont la mesure est naturellement observée périodiquement (le cumul d’eau de pluie relevé toute les heures par capteur d’une station météo).
Source : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema. Laurence Corr and Jim Stagnitto. DecisionOne Press, 2011, page 28
Lecture Table de faits instantané périodique : Star Schema. Christopher Adamson. pages 265-274
Lecture Table de faits instantané périodique : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema Laurence Corr, and Jim Stagnitto. pages 229-231
Table de faits sans faits
Diaporama Table de faits sans faits
Les tables de faits sans faits sont très utiles dans deux différents types de situations :
- Modéliser des événements qui ne sont pas mesurés par des faits : la seule existence de l’événement nous intéresse (inscription à un cours ou à une conférence par exemple).
- Modéliser des informations où ce qui nous intéresse est de mettre en lien différentes dimensions (affectation d’un conseiller à un client, éligibilité pour avoir accès à une offre/un produit par exemple).
Dans ces situations, nous créons alors une table de faits sans faits qui ne possède que des attributs qui sont des clefs dimensionnelles ou des dimensions dégénérées. Il n’y a donc aucun fait rattaché à cette table.
Modéliser des événements sans faits
Cette première situation concerne les processus dont la seule mesure qui nous intéresse est le nombre d’événements ayant eu lieu. Ces processus peuvent être modélisés par une table de faits sans faits dont le grain correspond à un événement. Aucun fait n’est alors requis et la seule analyse possible est le comptage du nombre de lignes. À cette fin, il est parfois possible de trouver dans ce type de table de faits sans faits un attribut de comptage dont l’unique valeur possible est 1.
De nombreuses situations peuvent faire appel à une table de faits sans faits de ce type :
- Pour faire le comptage de documents : nombre de contrats passés, nombre de candidatures …
- Pour suivre l’activité d’un service : nombre de contacts avec les clients, nombre de tickets ouverts/fermés …
- Pour suivre des campagnes : nombre d’annonces diffusées, nombre d’ouvertures de mails, nombre de vues
- Pour suivre la fréquentation : nombre de pages vues, nombre de clics
- Pour suivre des inscriptions : nombre d’étudiants inscrits, présents ou absents
Prenons l’exemple d’une entreprise qui désire piloter sa gestion de la relation client et désire suivre les contacts avec ces derniers. Les informations utiles pour créer des indicateurs sont la date/heure du contact, le client concerné et la façon dont le contact a été initié. Un contact peut être décrit par le moyen utilisé (mail, téléphone, courrier), le sens (initié par l’entreprise ou le client), le fait qu’il soit automatisé ou non et son contexte (campagne de pub, support technique, newsletter …). Toutes ces informations sont donc des axes d’analyses : la seule chose qui va nous intéresser est de pouvoir faire des requêtes pour savoir combien de ces situations ont eu lieu en fonction des critères choisis.
La figure suivante illustre ainsi la solution où nous avons un schéma en étoile avec, au centre, une table de faits sans faits CONTACT_FACTS et les différentes dimensions DAY, TIME, CUSTOMER et CONTACT_TYPE qui vont nous permettre de configurer les comptages.
Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 293
Modéliser des informations sans lien direct avec un processus métier
Parfois, il est nécessaire de suivre des informations sans lien direct avec un processus métier. Il s’agit par exemple de représenter des conditions, une couverture ou une éligibilité. Par exemple :
- Les vendeurs associés à un client
- L’accès des étudiants à des offres ou solutions logicielles
- Les conditions de déclenchement d’une alerte
- Les campagnes en cours à un moment donné
Prenons l’exemple classique de la commande d’un produit. Nous avons ainsi le schéma dimensionnel ci-dessous qui permet de modéliser les commandes effectuées ORDER_FACTS d’un produit PRODUCT, par un client CUSTOMER, par l’intermédiaire d’un vendeur SALESREP à un moment donné DAY dans le contexte d’une commande ORDER_ID. Ici la table ORDER_FACTS est une table de faits de transaction permettant de mesurer la valeur de la commande order_dollars mais on peut imaginer aussi son coût, le nombre de produits … Le grain de cette table est PRODUCT, ORDER_ID car chaque ligne correspond à la commande d’un type de produit dans le contexte d’une commande.
Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 298
Considérons maintenant que l’entreprise associe à ses commerciaux un portefeuille de prospects ou clients, c’est une situation très classique notamment en B2B. Le problème que l’on va rencontrer avec la modélisation sous forme de table de faits ORDER_FACTS est qu’il va être impossible de distinguer les situations suivantes (voir schéma ci-dessous) :
- Les clients affectés à un vendeur qui n’ont pas commandé (aucune observation possible dans la table de faits).
- Les clients qui ont passé une commande et qui étaient affectés à un vendeur.
- Les clients qui ont passé une commande sans qu’ils aient été affectés à un vendeur.
Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 299
Pour analyser une de ces situations en détail, par exemple les commandes des clients qui n’ont pas de vendeur affecté, nous allons avoir besoin de cette information d’affectation. Pour cela, nous créons une table de faits sans faits CUSTOMER_ASSIGNEMENT_FACTS comme l’illustre l’image ci-dessous.
Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 300
Cette modélisation permet de modéliser les conditions d’affectation d’un vendeur à un client (ici une période avec la date de début et la date d’expiration).
Il est possible de contester le fait que cette table de fait sans faits ne soit pas liée à un processus métier. Le processus métier pourrait être l’affectation d’un portefeuille de clients à chaque vendeur. En soi, cela ne changerait pas la solution proposée.
Cependant, ce qu’il faut comprendre, c’est qu’une table de faits sans faits représentant des conditions, une couverture ou une éligibilité, n’est utile que pour apporter une information dans le contexte de l’analyse d’un autre processus métier. Cette information est présente, par ailleurs, dans le système opérationnel, mais nous en avons besoin ici dans le système décisionnel pour donner un éclairage sur un autre processus.
Lecture Table de faits sans faits : Star Schema. Christopher Adamson. pages 291-300
Lecture Table de faits sans faits : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema Laurence Corr, and Jim Stagnitto. pages 248-249