Modélisation dimensionnelle - Étude de cas

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 bords pour piloter l’activité de la chaîne.

Votre service est en charge de la modélisation dimensionnelle de l’entrepôt de données sur lequel se baseront les tableaux de bords. Un consultant confirmé a déjà animé plusieurs réunions de travail avec différents interlocuteurs de Quiventou pour explorer son activité cœur, à savoir la vente de produits en magasins. Il a appliqué la méthode BEAM✲ pour recueillir le plus d’informations possibles pour une bonne compréhension de ce processus métier.

Suite à ces séances de travail, le consultant a réalisé un premier schéma dimensionnel. Mais très récemment, le client Quiventou est revenu vers le consultant pour évoquer un ensemble d’exigences qui lui sont apparues nécessaires suite à leurs échanges. Le consultant a noté chacune de ces exigences afin d’évaluer leur impact sur le schéma dimensionnel actuel.

En tant que consultant junior récemment embauché, vous héritez de la lourde tâche de mener à bien cette étude. Vous avez à votre disposition le schéma dimensionnel tel que proposé par le consultant sénior. Celui-ci, pris par un autre projet, vous a néanmoins laissé un résumé des derniers échanges qu’il a eus avec le client.

Schéma dimensionnel des ventes de produits en magasins Quiventou

Le schéma dimensionnel est construit autour du processus de vente de l’entreprise. Ce processus est centré sur l’acte de paiement, en caisse, des produits achetés par un client dans un des supermarchés Quiventou.

Le consultant a mis en œuvre la méthode BEAM✲. Il s’agit de la méthode présentée dans le livre Corr, Laurence, and Jim Stagnitto. Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema. DecisionOne Press, 2011.

La méthode BEAM✲ est une méthode qui combine des techniques de questionnement (méthode appelée QQOQCP (Qui, Quoi, Où, Quand, Comment, Pourquoi, Combien) en français ou la méthode des 7 W (Who, What, Where, When, hoW many, Why, How) en anglais), et des techniques de modélisation de données.

Le consultant l’a mise en œuvre à deux fins. Premièrement pour recueillir le plus d’informations possibles auprès du client Quiventou pour une bonne compréhension de leur processus métier. Et deuxièmement pour concevoir son schéma dimensionnel. Il a ainsi enrichi son schéma dimensionnel avec un certain nombre d’annotations BEAM✲ qui devraient vous aider à appréhender plus facilement son schéma (l’explication des annotations est donnée dans le livre Agile Data Warehouse Design, pages 287 - 292)

Dans ce schéma, le niveau de détail le plus fin correspond à un type de produit acheté par un client lors d’un passage en caisse. Cependant, il n’est pas possible, d’un point de vue métier, d’utiliser la notion de client car tous les clients ne sont pas identifiés lors de leur passage en caisse. Toutefois, chaque passage en caisse aboutit à un paiement, le grain est donc défini au moyen de la dimension PRODUIT et de la dimension dégénérée ID PAIEMENT. Il aurait pu être également défini de manière équivalente par l’ensemble des dimensions PRODUIT, CALENDRIER, TEMPS, CAISSE et MAGASIN.

Analyse du schéma dimensionnel

Nous allons commencer par analyser le schéma dimensionnel en nous aidant des diverses annotations BEAM✲ qu’il contient.

La table de faits

Pour vous aider, utilisez l’acronyme indiqué à côté du nom de la table de faits dans le schéma dimensionel et référez-vous au livre Agile Data Warehouse Design, Event Story and Fact Table Types, page 287.

Les dimensions

Certains attributs de dimensions sont associés à une des annotations suivantes : CV, PV et HV dont la signification est détaillée dans Agile Data Warehouse Design, Dimensional Attribute Types, pages 290-291. S’il n’y a aucune mention, l’attribut est considéré par défaut comme étant de type FV. La présence d’un attribut de type HV induit une dimension de type HV, à défaut la présence d’un attribut de type CV induit une dimension de type CV (voir Agile Data Warehouse Design, Dimension Table Types, pages 288).

Les demandes à traiter

Pour chacune de ces demandes vous devrez proposer une solution qui s’exprimera sous la forme :

• D’une modification de la matrice de bus.
• D’une modification du schéma dimensionnel, annoté correctement : modification dans la table de faits, dans les dimensions ou ajout d’une nouvelle table de faits avec des dimensions à identifier. Vous pouvez partir de ce schéma partagé et le dupliquer pour y apporter vos modifications.
• D’une explication nécessaire à la compréhension de la solution proposée.

Multiples moyens de paiement

Le client Quiventou souhaiterait que la solution proposée prenne en compte le fait que les clients peuvent utiliser deux moyens de paiement différents lors d’une même transaction (liquide, chèque bancaire, carte bleue ou chèque déjeuner/restaurant/vacances).

Les promotions

Le client Quiventou veut analyser les performances des promotions. Pour cela, il veut pouvoir analyser les produits en promotion qui n’ont pas été vendus.

Les clients

A la lecture du document, votre responsable vous fait part de ses inquiétudes sur la dimension Client. Selon lui, elle risque d’être trop volumineuses. Actuellement Quiventou possède 2 millions de clients (avec un numéro de fidélité) et prévoit une augmentation (linéaire) de 50% tous les 3 ans. Des campagnes sont réalisées tous les ans et permettent de mettre à jour les informations de 15% des clients.

Les livraisons

Le client Quiventou se demande si la solution proposée permettrait aussi de gérer leur service Quiventou Courses en ligne, depuis la prise de commande sur Internet jusqu’à la livraison des produits.