NF26 Data warehouse et Outils Décisionnels Printemps 2010

NF26 Data warehouse et Outils Décisionnels Printemps 2010 Rapport Modélisation Datamart VU Xuan Truong LAURENS Francis

Analyse des données Avant de proposer un modèle dimensionnel, une analyse exhaustive des données venant de différentes sources doit être effectuée. Cette analyse nous permet d avoir un bilan concret sur l état ainsi que l importance des données présentes vis-à-vis de la problématique de départ à savoir ici d augmenter les ventes. Cette première analyse a aussi pour objectif de classifier les données et donc d'écarter celles qui sont à priori inutiles ou inexploitables. Dans le contexte de ce projet, les données nous sont livrées a priori. Au contraire dans un contexte réel, c est essentiellement aux réalisateurs de rechercher les données nécessaires qui peuvent exister et trainer dans l organisation. Les caractères «+» et «-» traduisent l ordre de l utilité et de la qualité des données. Utilité Qualité ++ Très utile pour des analyses et études Très propre et typé stratégiques prévisionnelles + Utile pour donner plus de détails ou des Typé mais peu propre informations supplémentaires vis-à-vis des requêtes possibles - Peu utile Données à traiter, format varié, manque d unicité -- Pas utile du tout Pas exploitable du tout, trop de valeur nulle La principale difficulté de cette étape réside dans le fait de choisir de garder des données ou non. En effet, lorsque les données sont très utiles mais de mauvaise qualité ou lorsqu'elles sont de très bonne qualité mais on une utilité moyenne, il faudra mûrement réfléchir avant de prendre la décision de les garder ou non. Pour cela, nous devons alors effectuer un choix en l'absence de contraintes explicitées clairement par le client ou par le biais d'un cahier des charges par exemple. En cas de discorde totale avec le client, un compromis pourrait être trouvé. On pourrait par exemple demander au client des données de meilleure qualité sous peine de ne pouvoir réaliser ses demandes. Catalogue (base Oracle) Donnée Type Utilité Qualité Commentaire Attribut conservé CODE Integer ++ ++ Clé primaire Oui TYPE String + + 14 types différents Non (*) ISBN String -- - ISBN : numéro international normalisé Non du livre ISSN String -- -- ISSN : International Standard Serial Non Number LANGUE String + - 25 langues différentes ; Erreur Oui d'encoding et 624 valeurs null PAYS String - + 53 pays différents - 987 valeurs null Non 2

TITRE String - + Inutile selon nous pour répondre à Non l'objectif EDITION String -- -- n.a. Non LIEUPUBLI String -- + n.a. Non EDITEUR String + - 4488 éditeurs ; 3057 valeurs null Oui DATEEDITION Integer + ++ 66 valeurs null Oui PAGINATION String -- -- Différents types de représentation Non COLLECTION String - -- Trop de valeur s null: 13674 Non COLLECTIONNUM String - -- n.a. Non SUJET String - - 3341 valeur s null Non AUTEUR String ++ -- Trop de valeurs null: 13043 Oui COAUTEUR String - -- Trop de valeurs null : 16236 Non DOMAINE (code) String ++ + 2633 valeurs null Oui COTE String -- - 1881 valeurs null Non PRIX String ++ -- La question de la monnaie unique se pose; il y a un manque d'unicité flagrant et de même des valeurs semblent erronées Oui Il s agit ici de la collection de données la moins propre. Par exemple, les caractères accentués ont été transformés en points d interrogations, ce qui prévoit un énorme travail de nettoyage. Les informations devront être retravaillées pour devenir utilisables. L'attribut prix pose ici le plus de problème car il est d'une très grande importance mais il est d'une qualité très mauvaise. (*) Nous n avons pas gardé l attribut type car il y avait 17932 «Monographie imprim e» sur 20489 enregistrements. Ainsi, il y a plus de 87% des livres qui ont «Monographie imprim e» comme valeur pour l attribut type. Départements (Base Access) Donnée Type Utili té Qualité Commentaire Attribut conservé DEPARTEMENT (ref)i Integer ++ ++ Clé primaire Oui NBMAGASINS Integer ++ ++ Analyse sur l'implantation des Oui magasins RAYONBESTSELLER Bool + ++ Permet d'étudier l'impact de la Oui présence d'un rayon bestseller TYPERAYONNAGE Char + ++ Permet d'étudier l'influence du type de rayonnage Oui Ces données sont très intéressantes d un point de vue de l analyse sur la vente de chacun des départements. Par contre, le type de rayonnage et la présence d un rayon de bestseller ne sont pas très pertinents. En effet, tous les magasins d un département partagent le même type de rayonnage ainsi que la présence d'un rayon bestseller. 3

Ventes (fichier csv) Donnée Type Utilité Qualité Commentaire Attribut conservé DATE (jour de l'année) Integer ++ ++ Référence Oui REF PRODUIT Integer ++ ++ Référence Oui REF DEPARTEMENT Integer ++ ++ Référence Oui REF MAGASIN Integer ++ ++ Référence Oui Cette table sera la source centrale pour répondre à la plupart des questions analytiques portant notamment sur l analyse sur le ticket caisse. Cette table nous permet d établir une analyse des ventes à partir des tickets de caisse. En plus, elle est en parfait état, les champs sont très propres. Domaines (fichier ods) Donnée Type Utilité Qualité Commentaire Attribut conservé CODE LC string + ++ Clé primaire Oui DEWEY string - ++ Utile mais obsolète Non DOMAINE string + ++ Intéressant car cet attribut permet de retrouver le nom complet du domaine Oui Cette table nous permet de faire la liaison avec les domaines présents dans la table «Catalogue» vu précédemment. Les champs présents dans cette table sont propres. Départements INSEE (fichier csv) Donnée Type Utilité Qualité Commentaire Attribut conservé CODE-NOM string + - Intéressant pour retrouver le Oui DEPARTEMENT département correspondant POPULATION Integer ++ ++ Permet d'étudier l'implantation ou l'extension des magasins par exemple Oui Ces données sont utiles pour l analyse et parfaitement exploitables. La donnée Département devra cependant être modifiée afin d extraire le numéro du département et son nom. A partir de cette analyse nous pouvons déduire que les données sont plus ou moins propres en fonction de leur origine. Ceci va entraîner un travail conséquent de nettoyage. 4

Modèle relationnel existant Telles qu'elles existent : Modèle normalisée : Remarque : La table Magasin n est pas donnée. On ne dispose que du numéro du magasin relatif au département stocké dans le fichier CSV «Ventes». De plus, la base Access des départements montre l analogie du type de rayonnage ainsi que la présence du rayon «Best Seller» des magasins implantés dans un même département. 5

Analyse des besoins Une analyse des besoins permet d'exprimer les requêtes cibles. Ces requêtes sont à la base d une construction d un data warehouse optimal. Nous allons exprimer ces requêtes cibles en nous mettant à la place du client avec comme objectif d'augmenter les ventes. Ci-dessous, nous allons donner des requêtes possibles ainsi que des questions possibles auquel notre système doit répondre. Requêtes possibles : Quantité de ventes - Nombre de produits vendus Par magasin d un département Par département Par produit Par période temporelle (congés, vacances scolaire, jour s fériés, ) Par domaine Par auteur Par langue Chiffre d affaire Selon deux ou plusieurs critères à la fois (exemple : par domaine et période) Du magasin avec ou sans le rayon «Best Seller» Du magasin pour un certain type de rayonnage Du département Population d un département Questions typiques : Rapport entre la population et le nombre de magasins Nombre de livres achetés en moyenne par un habitant Chiffre d affaire moyen d un habitant Quelles sont les périodes durant lesquelles on vend le plus? Quelles sont les domaines de livres les plus vendus? Où vend-on? Qu en est-il des paramètres linguistiques? 6

Modèle dimensionnel proposé Nous avons conservé dans ce modèle uniquement les attributs qui ont pour valeur «oui» dans la colonne «attribut conservé» issus de l analyse des données. La table «Date» contient les informations nécessaires pour non seulement situer une vente dans le temps (jour, semaine, mois, ) mais aussi pour l adapter dans le contexte de vente grand public (weekend, jours fériés, vacances selon les zones). A partir du code, on peut déterminer tous les autres attributs de la table «Produit» 7

Remarques : Le prix unitaire, ici, est une information partielle et non fiable. Par conséquent, il est incorrect de calculer certaines mesures (exemple: le montant total d'un ticket) en fonction de cet attribut. La quantité vendue deviendra l unité essentielle pour tous les calculs ultérieurs. La table «Date» contient toutes les informations permettant de situer une vente dans le temps, c est-à-dire d obtenir la date complète à partir du jour de l année. On pourra ainsi, dans les requêtes, faire des statistiques sur une semaine donnée, un jour de la semaine, un mois, un trimestre, etc... Dans le schéma, nous avons arrêté la granularité au trimestre, pour des raisons de place. En plus, l objectif explicit du modèle est de faire une grande étude portée uniquement sur les ventes de 2005. La table «Départements» est une agrégation de deux tables existantes : la table «Départements» fournie par l entreprise et le fichier csv de l INSEE trouvé par le stagiaire. En effet, il n est pas utile de séparer ces deux tables, la clé primaire de ces deux tables étant la même sémantiquement. Il est à noter que l'on suppose que la population dans les départements en 2003 est similaire à la population présente en 2005 pour que les calculs soit correcte. La table «Catalogue» est, elle aussi, une agrégation de deux tables existantes. D une part, la table «Catalogue» qui contient toutes les informations sur les produits et d autre part les informations sur «domaines» des produits contenues dans le fichier Excel. En effet, il n y avait qu une seule information (domaine) exploitable dans ce dernier fichier Excel et ainsi il n'était point nécessaire d ajouter une nouvelle table. Dans la table «Ventes», nous avons décidé de ne pas rajouter l information Quantité. En effet, cette information, si elle permet de se passer d un certain nombre d enregistrements, pourra être facilement recalculée à partir de fonctions SQL simples. Il ne s agit pas d une modification profonde du modèle. Ce choix est justifié par le fait que généralement, une même vente (à la même date, dans un même magasin d un département et avec un numéro d achat identique) ne contiendra pas plusieurs fois le même livre. Après calcul, en regroupant par Quantité, le gain est de 9218 enregistrements sur les 205934 existants, soit au maximum 4.5%. Le regroupement par Quantité ne semble donc pas essentiel. 8

Datamarts Datamart «Ticket de caisse» utilisé pour produire l information liée aux caractéristiques d une commande ou d'un ticket de caisse. Ainsi, les informations générées permettent de voir s il y a une tendance d acheter des livres selon certains critères portant sur les caractéristiques des livres. Datamart départemental utilisé pour produire l information liée à la vente dans les départements en prenant compte les deux facteurs primordiaux : leur population, leur nombre de magasins implantés. Une étude sur le rapport entre ces deux derniers attributs invitera éventuellement à effectuer une réimplantation des sites dans les départements les moins efficaces en termes de rentabilité. Nb de Nb départements magasins possédant un tel nombre de magasins 0 37 1 37 2 6 3 2 4 6 5 4 6 1 7 1 20 1 9

Regroupement des départements selon la densité de magasins : 1 : avoir un seul magasin 2 : de 2 à 3 3 : de 4 à 7 4 : plus de 8 Datamart temporel utilisé pour estimer et trouver les périodes durant lesquelles il y a le plus de ventes dans l année (jours fériés, vacances, weekend, etc ). On peut s appuyer sur un tel planning pour lancer des stratégies temporelles. 10

Implémentation SQL CREATE TABLE DATE ( Jour integer PRIMARY KEY, Semaine integer, Mois integer, Trimestre integer, Weekend integer(1) CHECK IN {0,1}, Ferie integer(1) CHECK IN {0,1}, VacancesA integer(1) CHECK IN {0,1}, VacancesB integer(1) CHECK IN {0,1}, VacancesC integer(1) CHECK IN {0,1} ) CREATE TABLE LOCATION ( Magasin integer, Num integer, NomDepartement varchar2(100), NbMagasins integer, RayonBS integer, TypeRayon varchar2(1), Population long, DensiteMag integer(1) CHECK IN {1,2,3,4}, PRIMARY KEY (Magasin, Num) ) CREATE TABLE PRODUIT ( Code integer PRIMARY KEY, Langue varchar2(20), Auteur varchar2(50), IntituleDomaine varchar2(50), Editeur varchar2(50), AnneeEdition integer, Prix float, ) CREATE TABLE VENTES ( NumTicket integer, NumMagasin integer, DateVente integer, Departement integer, Produit integer, FOREIGN KEY (DateVente) REFERENCES DATE(Jour), FOREIGN KEY (NumMagasin, Departement) REFERENCES DEPARTEMENT(Magasin, Num), FOREIGN KEY (Produit) REFERENCES DIM_Produit(Code), PRIMARY KEY (NumTicket, NumMagasin, DateVente, Departement, Produit) ) 11

Conclusion A partir de l'ensemble des données mises à notre disposition, nous avons déduit un modèle dimensionnel pour notre data warehouse. Ces données qui étaient présentes sous différent formats (Oracle, Access, ODS, CSV) ont été sélectionnées en fonction de leur propreté et de leur importance par rapport à l objectif initial. Les données mises à notre disposition traduisent bien le monde réel dans lequel le stockage des données est réalisé de manière plus ou moins correcte. Par exemple, des erreurs d'encodage au niveau du prix, nous empêchent de connaître la devise utilisée et ainsi d'effectuer de nombreuses analyses intéressantes au niveau du montant total des tickets de caisse. Il est important de noter que ce modèle a été construit à partir de nombreux choix subjectifs. Ainsi, notre modèle pourrait être modifié si de nouveaux éléments venaient à s'opposer aux décisions préalablement prises. Par exemple, nous pourrions rajouter le type dans la table «Produit». 12