Contexte
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.
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
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.
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.
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.
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.
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.