Cette activité a pour objectif d’introduire les éléments essentiels de la modélisation dimensionnelle en mettant en oeuvre la méthode BEAM✲
Pré-requis

Avant de participer à cette activité, vous devez obligatoirement lire les documents suivants :
- Modélisation dimensionnelle - Introduction
- Modélisation dimensionnelle - Notions avancées : faits
- Modélisation dimensionnelle - Notions avancées : dimensions
- Approche BEAM✲

Introduction à l’activité

Contexte

La chaîne de supermarchés Quiventou possède un système d’information permettant de gérer tout l’aspect opérationnel de son activité. Votre société de conseil a obtenu un contrat afin de concevoir une solution décisionnelle permettant de générer des tableaux de bord pour piloter l’activité de la chaîne.

Votre service est en charge de la modélisation de l’entrepôt de données sur lequel se baseront les tableaux de bords. En tant que consultant junior récemment embauché (ce matin même !) on vous a proposé d’assister à un rendez-vous entre un consultant sénior et le chef de projet chez le client pour un atelier de modélisation dimensionnelle en suivant la méthode BEAM✲.

Cette activité est volontairement simplifiée pour vous permettre de découvrir la méthode. Elle présente un dialogue entre les différentes parties prenantes lors duquel vous vous efforcerez de produire les diagrammes types utilisés dans la méthode BEAM✲ (Agile Data Warehouse Design, page 25).

La démarche qui est mise en oeuvre est présentée dans le document Modélisation dimensionnelle : approche BEAM✲

Comment conduire cette activité ?

Il est recommandé d’effectuer cette activité en groupe où chaque membre incarne un des rôles suivants :

  • un animateur (qui lit le sujet et les notes à haute voix),
  • le consultant (qui lit les questions à haute voix),
  • le client (qui lit les réponses à haute voix),
  • le scribe qui note l’avancement des diagrammes au tableau blanc,
  • le secrétaire qui note l’avancement du travail sous forme électronique (un Google Sheets partagé dans votre espace Google Drive).

Préparez également quelques livres afin de consulter les références quand elles sont données.

Objectif de cette activité

Cette activité a pour objectif de vous introduire la méthodologie BEAM✲ en montrant le cheminement pour aboutir à un schéma en étoile et la matrice de bus associée. Les notions de modélisation dimensionnelle que vous avez du préparer ne seront pas forcément utiles pour le moment (même si elles vous permettent de contextualiser les choses) mais le deviendront dès la prochaine activité.

Cette activité est conçue pour lire les phases de dialogues comme si vous écoutiez une discussion, puis à s’interroger sur ce qu’il vient de se passer en répondant aux questions dans les encarts comme celui ci-dessous :

Ouvrages recommandés pour préparer et participer à cette activité

Adamson, Christopher. Star Schema. Osborne/McGraw-Hill, 2010.

Corr, Laurence, and Jim Stagnitto. Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema. DecisionOne Press, 2011.

Kimball, Ralph. Entrepôts de Données. Guide Pratique de Modélisation Dimensionnelle, 2ème Édition. Vuibert, 2003.

Recherche des événements

La première chose à effectuer est de cerner le périmètre de l’atelier. Nous allons donc tout d’abord lister les actions liées aux activités de l’entreprise qui seront à explorer pour en choisir une, la plus importante ou évidente.

Consultant : « Quelles sont les différentes actions liées aux activités des magasins que vous voulez analyser ? »
Quiventou : « Des clients achètent des produits.
Des magasins réceptionnent des produits.
Des clients demandent une carte de fidélité.
Des magasins mettent des produits au rebut.
Un employé met des produits au rebut.
Une campagne de promotion est lancée.
Le retour de marge brute sur investissement en Stock est demandé chaque soir. »

Définition du premier événement

Choix du 1er événement à définir et création de la table BEAM✲

Consultant : « Je vous propose de nous concentrer sur l’événement Des clients achètent des produits qui correspond à l’action majeure liées à votre activité. »

Table évènement BEAM✲

Nous allons maintenant passer en revue les 7Ws, c’est à dire mettre en oeuvre une démarche de questionnement systématique (Agile Data Warehouse Design, page 31c).

Identifions le “Quand ?” [When?]

Consultant : « Quand un client achète-t-il un produit ? »
Quiventou : « Quand il vient faire ses courses »
Consultant : « Comment ce moment pourrait-il être appelé ? »
Quiventou : « Date de paiement »

On peut maintenant s’interroger s’il y a besoin d’un niveau de granularité plus fin.

Consultant : « Faut-il descendre jusqu’au niveau de l’heure ? de la minute ? »
Quiventou : « Oui, jusqu’à la minute »

Table évènement BEAM✲

Définissons les histoires relatives au “Qui ? Quoi ? Quand ?” [Who? What? Where?]

Nous allons ici détailler les data stories qui vont permettre d’illustrer et expliciter les différentes situations relatives à l’événement sur lequel nous travaillons. Ces data stories sont structurées autour de 5 thèmes : Typique, Différent, Répétition, Manquant et Groupe (Agile Data Warehouse Design, page 39).

Consultant : « Quel exemple d’achat de produits pourriez-vous donner pour décrire le cas typique ? »
Quiventou : « Pour le cas typique : Paule Dupont a acheté de la bière Breizheff le 10/10/2017 à 12h15. »

Table évènement BEAM✲

Consultant : « Connaît-on toujours le nom de l’acheteur ? »
Quiventou : « Non, bien sûr ! On ne connaît que le nom des personnes qui présentent leur carte de fidélité. »
Consultant : « Pouvez vous, alors, donner un exemple, avec le thème Différent, pour le cas où l’acheteur n’a pas ou ne présente pas sa carte de fidélité? Vous donnerez au nom du client une valeur comme ‘Anonyme’ ou ‘Inconnu’. Vous pouvez profiter de cet exemple pour indiquer de quelle fréquence de rafraîchissement de données vos analyses de données ont besoin. Une fréquence de rafraîchissement à la semaine ? A la journée ? Par exemple, en précisant comme date ‘la semaine dernière’, vous indiquez que le rafraîchissement des données du Data Warehouse n’a besoin d’être effectué que toutes les semaines. »
Quiventou : « Voici un exemple différent : Anonyme a acheté de la Lessive BreizhClean hier. »
Consultant : « Avec un autre exemple, toujours avec le thème Différent, vous pouvez préciser la durée maximale de l’historique que vous voulez garder. »
Quiventou : « Durand Pierre a acheté du Chocolat BreizhSweet il y a 5 ans. »
Consultant : « On va maintenant traiter le cas du thème Répétition. Pour déterminer l’ensemble des détails qui permettent de différencier de manière unique les différentes histoires, vous devez donner un ou plusieurs exemples (autant que nécessaire) en reprenant le plus de détails possibles identiques à l’exemple du thème Typique. Par exemple, est-ce que Paule Dupont peut acheter de nouveau de la bière Breizheff le 10/10/2017 toujours à 12h15? »
Quiventou : « Non. Si elle achète par exemple 2 packs de bière Breizheff à la fois, cela correspondra à un seul achat de bière Breizheff, avec une quantité de 2. »
Consultant : « Donc, pour une même personne et un même produit, la date d’achat est forcément différente ? »
Quiventou : « Oui. Et pour une même date d’achat, le produit est forcément différent. »
Consultant : « Heu … le produit est forcément différent … mais seulement s’il s’agit du même client, c’est bien cela ? »
Quiventou : « Oui, bien sûr ! Un même produit peut bien évidemment être acheté deux fois, exactement au même moment, mais par deux clients différents. »
Consultant : « Donc, pouvez vous donner des exemples, mettant en évidence ces différentes contraintes ? »
Quiventou : « En gardant comme cas typique ‘Paule Dupont a acheté de la bière Breizheff le 10/10/2017 à 12h15’, on peut alors avoir les exemples suivants :
- Paule Dupont a acheté de la bière Breizheff le 10/10/2017 à 13h00
- Paule Dupont a acheté de la Lessive BreizhClean le 10/10/2017 à 12h15.
- Le 3ème exemple pouvant être Pierre Durand a acheté de la bière Breizheff le 10/10/2017 à 12h15 »
Consultant : « Avec ces trois exemples, nous pourrons plus facilement, tout à l’heure, déterminer le grain de l’événement. »
Consultant : « Quel(s) exemple(s) pouvez-vous donner pour indiquer les détails obligatoires et ceux qui ne le sont pas (car inconnus, non applicables ou pas disponibles), en donnant la donnée à afficher (dans les tableaux de bord ou rapports) en cas de valeur non renseignée (par exemple, inconnu, non applicable) ? Ces exemples se rapportent au thème ‘Manquant. On indiquera par MD les détails obligatoires. »
Quiventou : « Anonyme a acheté de la Biere Breizheff le 10/10/2017 à 12h15. Le produit et la date sont obligatoires. »
Consultant : « Nous allons maintenant traiter le cas du thème Groupe. Ce thème permet de mettre en évidence les détails qui sont complexes en ce sens qu’ils regroupent des variations de sens (impliquant des propriétés pour les définir, qui sont propres à chaque sens). Par exemple, dans le cas qui nous intéresse, est-ce qu’un client est toujours une personne physique ? ou bien est-ce qu’il peut représenter une association ou en entreprise ? »
Quiventou : « Oui, un client est toujours une personne physique. »
Consultant : « De même, concernant les produits, est-ce qu’il est possible d’acheter un lot de plusieurs produits ? »
Quiventou : « Oui, mais finalement, c’est comme s’il s’agissait d’un seul produit, car un code produit est alors créé pour le lot de produits. »
Consultant : « Pour la Data Story du thème Groupe, il suffit alors de recopier la Data Story du thème Typique, pour mettre en évidence qu’il n’y a pas de détails complexes. »

D’autres détails relatifs au “Quand ?” [When?]

Consultant : « Y a-t-il d’autres dates qui concernent l’achat de produits »
Quiventou : « Non, je ne vois pas. »

D’autres détails relatifs au “Qui ?” [Who?]

Consultant : « Y a-t-il d’autres ‘Qui ?’ [Who] qui concernent l’achat de produits ? »
Quiventou : « Oui, il y a l’employé de caisse qui enregistre le paiement. »

D’autres détails relatifs au “Quoi ?” [What?]

Consultant : « Y a-t-il d’autres ‘Quoi ?’ [What] qui concernent l’achat de produits ? L’achat de produits par un client met-il en jeu d’autres ‘objets’ ? »
Quiventou : « Non, je ne vois pas. »

Détails relatifs au “où ?” [Where?]

Consultant : « Où un client achète-t-il un produit ?  »
Quiventou : « Dans un des magasins du groupe. »
Consultant : « Y a-t-il d’autres ‘Où ?’ [Where] qui concernent l’achat de produits »
Quiventou : « Non, je ne vois pas. »
Consultant : « Il n’y a pas d’endroit plus précis ? comme par exemple l’endroit où est enregistré le paiement ?  »
Consultant : « Oui, effectivement, il est intéressant de savoir avec quelle caisse le paiement a été enregistré.  »

Détails relatifs au “Combien ?” [How Many?]

Consultant : « Combien de produits achète un client ? Ou plus exactement quel mot voulez-vous utiliser pour représenter la quantité de produits achetés ?  »
Quiventou : « La quantité achetée. »
Consultant : « Y a-t-il d’autres ‘mesures’ de type [How Many?], [How Much?] et même [How Long?] qui vous intéressent concernant l’achat de produits par un client ? »
Quiventou : « Oui, le prix du produit, et ce que paie réellement le client. Et puis, le système fournit aussi le coût unitaire d’achat, et on en aura besoin pour certains rapports. »
Consultant : « Quels sont les unités de mesure à utiliser ? »
Quiventou : « Pour tous les montants, l’unité est l’euro. Pour les quantités, il s’agit simplement de l’unité de vente. »

Détails relatifs au “Pourquoi ?” [Why?]

Les détails relatifs au ‘Pourquoi ?’ [Why?] permettent de déterminer les causalités de l’événement.

Consultant : « Pourquoi un client achète-t-il un produit avec cette quantité et à ce prix ? »
Quiventou : « Parfois, c’est pour bénéficier de promotions sur les produits. »
Consultant : « En plus du détail ‘Promotion’, qui est de type ‘Pourquoi ?’ [Why], y aurait-il d’autres détails qui vous intéresseraient, comme par exemple de type ‘Combien ?’ [How Many?] »
Quiventou : « Oui, la réduction réalisée sur le produit, si le produit est en promotion. Et aussi, concernant le montant total, il serait bien d’avoir le montant avant réduction et le montant après réduction. »

Détails relatifs au “Comment ?” [How?]

Les détails relatifs au ‘Comment ?’ [How?] se rapportent aux mécanismes de l’événement.

Consultant : « Qu’est-ce qui différencie deux transactions d’achat ? ou disons, qu’est-ce qui identifie un achat ? »
Quiventou : « Le N° de transaction ou N° d’achat. »
Consultant : « Comment ou par quel moyen le client réalise-t-il le paiement de son achat ? »
Quiventou : « En payant en liquide, par chèque, ou par carte bancaire. Le client peut aussi présenter sa carte de fidélité. »
Consultant : « Oui, mais la carte de fidélité ne sert pas à payer l’achat fait par le client ? N’est-ce pas ? »
Quiventou : « Oui, effectivement. La carte de fidélité est en fait utilisée pour identifier le client. »
Consultant : « Dans ce cas, la carte de fidélité est une information qui correspond à un détail du ‘CLIENT’. Elle sera prise en compte lors de la définition de la dimension ‘Client’. Mais si vous voulez, pour être sûr de ne pas oublier ce détail lors de l’étude de la dimension ‘Client’, on peut dès à présent noter ‘Carte de fidélité’, juste au dessus de la table BEAM✲ au niveau de la colonne ‘Client’. »
Consultant : « Concernant le moyen de paiement, vous suffit-il de savoir que le client a payé au moyen d’une carte bancaire, ou voulez-vous descendre à un niveau de granularité plus bas comme par exemple connaître le type de carte bancaire ? »
Quiventou : « Oui, effectivement savoir que le client a payé avec une carte Visa plutôt qu’une Master Card peut être utile. »

Identifions la granularité de l’événement

Maintenant que l’on a passé en revue les 7Ws, nous allons déterminer la granularité de cet événement. Pour ce faire, nous allons pouvoir nous aider des Data Stories du thème Répétition.

Consultant : « Quels sont les différents détails de l’événement qui permettent d’identifier de manière unique une Data Story? Il est possible que différentes combinaisons de détails puissent faire office d’identifiant. »

Trouvons un nom pertinent pour l’événement

Nous avons pu déterminer la granularité de l’événement, cela indique donc que l’on a suffisamment de détails pour bien décrire l’événement. Mais il sera toujours possible par la suite d’ajouter des détails pertinents qui auraient été oubliés.

Consultant : « Quel nom voudriez-vous donner à l’événement ? »
Quiventou : « Achats de produits. »
Consultant : « Il serait peut-être plus judicieux de centrer l’événement sur la société Quiventou. Avec un tel nom d’événement, on pourrait penser que c’est Quiventou qui achète des produits, alors qu’en début de ‘modelstorming’, on avait intitulé l’événement ‘Des clients achètent des produits’. »
Quiventou : « Oui, effectivement. On pourrait alors nommer l’événement ‘VENTES PRODUITS’. »
Consultant : « Très bien. Au vu des différents détails de type [When], on peut définir l’événement comme étant un événement discret. »

Définition des dimensions de l’événement

Dimension produit

Le lendemain matin vous devez vous approprier la table BEAM✲ qui a été faite pour la dimension Produit, la veille pendant la réunion. Consultez la dimension Produit produite en votre absence.

Interrogez-vous sur les questions qui vous aurait permis d’obtenir ces informations.

Autres dimensions

Le consultant sénior a terminé les dimensions suivantes, que vous pouvez consulter :

Définition de la matrice d’événements

Modélisation du schéma en étoile

Les dernières étapes pour finir une modélisation sont les suivantes :

  • Étudier les données sources, leur qualité et volumétrie (Agile Data Warehouse Design, page 130). Dans le contexte de cet atelier nous ne traitons pas cette étape que vous devrez mettre en oeuvre dans le cadre de votre projet.
  • Dans chacune des dimensions ajouter la clef primaire (Agile Data Warehouse Design, page 149) et compléter les valeurs dans la nouvelle colonne.
  • Produire la table de faits à partir de la table de l’événement (Agile Data Warehouse Design, page 152) :
    • Indiquer les valeurs des clefs référentielles.
    • Indiquer le type de table de faits.
    • Identifier les dimensions dégénérées.
    • Identifier les propriétés d’additivité de chacun des faits (Agile Data Warehouse Design, page 153).
  • Produire le schéma en étoile (Agile Data Warehouse Design, page 154).