Cette activité a pour objectif d’introduire les éléments essentiels de la modélisation dimensionnelle en mettant en oeuvre la méthode 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✲
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 :
A faire :
Attendez de voir cet encart pour analyser la partie de dialogue qui vient de se dérouler.
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.
Note :
Les actions (ou événements, terme employé dans la méthode BEAM✲) correspondent aux réponses pouvant être faites à la question « Qui fait quoi ? » [Who does What?]
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é. »
A faire :
Dans la méthode BEAM✲ il s’agit maintenant de commencer à créer une table BEAM✲ qui va décrire cet événement. Recopiez la table BEAM✲ ci-dessous au tableau, en laissant un peu de place sur la gauche, pour pouvoir ajouter par la suite le thème devant chaque Data Story de la table 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 »
A faire :
Mettez à jour dans la table BEAM✲ les informations que nous venons d’obtenir.
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. »
A faire :
Ajoutez la Data Story correspondant à Paule Dupont, en indiquant qu’il s’agit du thème typique.
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. »
A faire :
Mettez à jour la table BEAM✲, en indiquant qu’il s’agit de Data Stories du thème Différent.
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. »
A faire :
Mettez à jour la table BEAM✲, en indiquant qu’il s’agit des Data Stories du thème ‘Répétition’. Mais attention, n’ajoutez pas de colonne [How Many] pour l’instant. Ce détail n’est abordé que plus tard, après le détail [Where].
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. »
A faire :
Mettez à jour la table BEAM✲, en indiquant qu’il s’agit de la Data Story du thème Manquant.
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. »
A faire :
Mettez à jour la table BEAM✲.
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. »
A faire :
Mettez à jour la table BEAM✲ en ajoutant la colonne EMPLOYE DE CAISSE et complétez chacune des Data Stories.
Note :
A partir de maintenant, s’il vous manque des informations vous pouvez appeler un enseignant qui jouera le rôle du client Quiventou. Vous n’avez le droit qu’à 2 questions par passage pour permettre une rotation rapide.
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. »
A faire :
Ajoutez la colonne adéquate dans la table BEAM✲ et complétez les différentes data stories déjà présentes.
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é. »
A faire :
Ajoutez la colonne adéquate dans la table BEAM✲ et complétez les différentes data stories déjà présentes.
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. »
A faire :
Ajoutez les colonnes et complétez chacune des Data Stories (en prenant bien en compte le thème qui les définit) pour décrire les mesures.
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. »
A faire :
Ajoutez les colonnes adéquates dans la table BEAM✲ et complétez les différentes data stories déjà présentes.
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’. »
Note :
Voir la section ‘Détail de détail’ dans Agile Data Warehouse Design, page 47.
A faire :
Ajoutez la mention nécessaire indiquée par le consultant.
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. »
A faire :
Ajoutez la colonne adéquate dans la table BEAM✲ et complétez les différentes data stories déjà présentes.
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. »
A faire :
Le consultant sénior étant obligé de s’absenter momentanément, il vous revient de devoir aider le client de Quiventou à identifier la ou les combinaisons de détails permettant d’identifier de manière unique les data stories. Vous devrez aussi reporter le résultat dans la table BEAM✲ (Agile Data Warehouse Design, page 54)
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. »
A faire :
Ajoutez le nom de l’événement au dessus à gauche de la table BEAM*, suivi de son type entre crochets ([DE])
A faire :
Pour résumer les informations principales de l’événement, le consultant sénior vous demande d’ajouter les informations suivantes sous la table BEAM✲ :
- Détails obligatoires
- Détails non obligatoires
- Granularité de l’événement (Liste des combinaisons de détails formant un identifiant d’événement)
- Fréquence de mise à jour des données
- Durée d’historisation
- Détails concernés par la Data Story du thème Groupe
- Data Story générique reprenant la Data Story du thème Typique, en réordonnant quand cela est nécessaire certain des détails (Agile Data Warehouse Design, page 56-57)
Définition des dimensions de l’événement
Note :
Cette fois-ci, c’est vous qui ne pouvez rester plus longtemps à la réunion de travail. Vous ne participez donc pas au modelstorming concernant les dimensions.
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.
A faire :
Le consultant sénior vous demande de faire le diagramme de hiérarchie qu’il n’a pas eu le temps de faire (Agile Data Warehouse Design, page 78).
A faire :
Le consultant sénior vous demande ensuite de mettre à jour le résumé de la dimension en bas de page. Afin de monter en compétence, il vous demande de lire les différents concepts dans le livre de référence : la clef naturelle BK (Agile Data Warehouse Design, page 63), les attributs obligatoires MD (page 69) et l’historique des attributs FV, CV, PV, HV (pages 84-88) dont les évolutions sont documentées par les 3 dernières colonnes.
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
A faire :
Maintenant que les principales dimensions de l’événement ‘VENTES PRODUITS’ sont définies, créez la matrice d’événements (Agile Data Warehouse Design, page 103) à partir de tous les détails de l’événement ‘VENTES PRODUITS’. Préoccupez-vous uniquement des colonnes ‘Details/Dimensions BEAM✲ Sequence’ en ajoutant la colonne [when] et sa granularité (par exemple Année, Mois, Jour …). La première et seule ligne de la matrice sera l’événement ‘VENTES PRODUITS’.
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).