- Mémoire de fin d’études (M2) -
Développer, Automatiser et Optimiser un
Data Mart
sans l’aide de logiciels spécialisés, d...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
3
TABLE DES MATIERES
TABLE D...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
4
TAILLE ET COMPLEXITE DES D...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
5
Livres et documents..........
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
6
REMERCIEMENTS
Je tiens tou...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
7
GLOSSAIRE
Clé primaire : T...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
8
(Exemple : Tableau, Cognos...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
9
INTRODUCTION ET PROBLEMATI...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
10
Dans le cadre d’un logici...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
11
NOTIONS DE BASE
Préambule...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
12
La donnée
Définition et v...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
13
valeur de la donnée. Si l...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
14
La description et les mét...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
15
caractéristique difficile...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
16
mensuelles et suivant plu...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
17
présence de quelques doub...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
18
1. « nombre de crédits im...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
19
ou des langages informati...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
20
1. Définition du périmètr...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
21
de documenter son fonctio...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
22
ETAT DE L’ART ET ANALYSE
...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
23
Le Data Mart peut parfois...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
24
derniers subissent. Il es...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
25
Data Mart, notamment la p...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
26
Implémentation : les étap...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
27
Construction
La phase de ...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
28
Recette
La recette est la...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
29
Automatisation
L’automati...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
30
Ce niveau d’optimisation ...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
31
HYPOTHESES ET CADRE DE L’...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
32
Autrement dit, si les don...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
33
Résultats souhaités et ac...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
34
METHODE
Cette partie prop...
Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014
35
Gantt21
a été créé. Il a ...
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Memoire_Julien_Diennet_20140905
Prochain SlideShare
Chargement dans…5
×

Memoire_Julien_Diennet_20140905

266 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
266
Sur SlideShare
0
Issues des intégrations
0
Intégrations
13
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Memoire_Julien_Diennet_20140905

  1. 1. - Mémoire de fin d’études (M2) - Développer, Automatiser et Optimiser un Data Mart sans l’aide de logiciels spécialisés, dans le but de fournir des indicateurs de performance Julien DIENNET Master 2 ID Apprentissage 5 septembre 2014 Responsable Master : Mr M. Ali Aloulou Maître d’apprentissage : Mr G. Bretnacher Tuteur enseignant : Mme M. J. Bellosta
  2. 2. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 3 TABLE DES MATIERES TABLE DES MATIERES .......................................................................................................................................3 REMERCIEMENTS .............................................................................................................................................6 GLOSSAIRE .......................................................................................................................................................7 INTRODUCTION ET PROBLEMATIQUE...............................................................................................................9 NOTIONS DE BASE.......................................................................................................................................... 11 PREAMBULE : INFORMATION ET DONNEES................................................................................................................... 11 L’information................................................................................................................................................ 11 Définition ................................................................................................................................................................... 11 But et bonne pratique................................................................................................................................................ 11 La donnée ..................................................................................................................................................... 12 Définition et valeur.................................................................................................................................................... 12 Qualité de données.................................................................................................................................................... 13 Les métadonnées....................................................................................................................................................... 15 LES INDICATEURS : UNE VISION TRAITEE ET CONCISE DE L’INFORMATION............................................................................ 15 Définition...................................................................................................................................................... 15 Avantages .................................................................................................................................................................. 16 Inconvénients ............................................................................................................................................................ 16 Caractéristiques recherchées........................................................................................................................ 16 Axes d’analyse .............................................................................................................................................. 17 Les « KPI » : notion ....................................................................................................................................... 18 L’AUTOMATISATION DU TRAITEMENT DE DONNEES ....................................................................................................... 19 Définition...................................................................................................................................................... 19 Méthodologie possible ................................................................................................................................. 19 Les différents niveaux d’automatisation ...................................................................................................... 20 Inconvénients................................................................................................................................................ 20 Lois et règles en vigueur sur les traitements automatisés............................................................................ 21 ETAT DE L’ART ET ANALYSE ............................................................................................................................ 22 DATA MART ......................................................................................................................................................... 22 Définitions et principes................................................................................................................................. 22 Définition ................................................................................................................................................................... 22 Structure physique et théorique................................................................................................................................ 22 En quoi un Data Mart est-t-il différent d’un Data Warehouse ?................................................................................ 23 Pourquoi développer un Data Mart ? Quelle en est la limite ?.................................................................................. 23 DataMarts dépendants et indépendants................................................................................................................... 24 Implémentation : les étapes......................................................................................................................... 26 Design ........................................................................................................................................................................ 26 Construction .............................................................................................................................................................. 27 Extractions et transformations .................................................................................................................................. 27 Calcul des indicateurs (optionnel).............................................................................................................................. 27 Recette....................................................................................................................................................................... 28 Accès et diffusion....................................................................................................................................................... 28 Automatisation .......................................................................................................................................................... 29 Maintenance.............................................................................................................................................................. 29 Optimisation................................................................................................................................................. 29 HYPOTHESES ET CADRE DE L’ETUDE ............................................................................................................... 31 L’ENTREPRISE........................................................................................................................................................ 31 TYPE DE DATA MART.............................................................................................................................................. 31
  3. 3. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 4 TAILLE ET COMPLEXITE DES DONNEES ......................................................................................................................... 31 ENVIRONNEMENT DE DEVELOPPEMENT ...................................................................................................................... 32 OUTILS UTILISES..................................................................................................................................................... 32 RESULTATS SOUHAITES ET ACCES AUX DONNEES ........................................................................................................... 33 RESUME............................................................................................................................................................... 33 METHODE ...................................................................................................................................................... 34 PREMIERE PHASE : PLAN D’ACTION ET RECUEIL DES BESOINS ........................................................................................... 34 Mise en place du plan d’action..................................................................................................................... 34 Définition du périmètre ............................................................................................................................................. 34 Définition des acteurs................................................................................................................................................ 34 Planning projet........................................................................................................................................................... 34 Recueil des besoins fonctionnels et techniques............................................................................................ 35 Recueil des besoins fonctionnels............................................................................................................................... 35 Définition des outils techniques ................................................................................................................................ 35 Obtention des accès aux environnements................................................................................................................. 36 DEUXIEME PHASE : DESIGN...................................................................................................................................... 36 Processus logique ......................................................................................................................................... 37 Identifier les sources et modéliser les extractions ........................................................................................ 37 Modéliser les transformations...................................................................................................................... 38 Modéliser les liaisons et le chargement ....................................................................................................... 40 Méthodes de calculs des indicateurs............................................................................................................ 40 Créer les axes d’analyse................................................................................................................................ 41 Préparer les reportings................................................................................................................................. 42 Design physique............................................................................................................................................ 43 TROISIEME PHASE : CONSTRUCTION, SPECIFICATIONS DETAILLEES ET CAHIER DE RECETTE...................................................... 44 Construction de l’environnement ................................................................................................................. 44 Création des fichiers programmes et reportings .......................................................................................... 44 Programmes............................................................................................................................................................... 44 Reportings.................................................................................................................................................................. 45 Documentation détaillée des futurs programmes........................................................................................ 45 Cahier de recette .......................................................................................................................................... 45 QUATRIEME PHASE : DEVELOPPEMENT ...................................................................................................................... 46 Script............................................................................................................................................................. 46 SAS................................................................................................................................................................ 46 Inclusions de sous-programmes ................................................................................................................................ 46 Macros variables et macros fonctions ....................................................................................................................... 47 Etapes « DATA »......................................................................................................................................................... 48 Procédures................................................................................................................................................................. 48 Reportings.................................................................................................................................................................. 49 Automatisation............................................................................................................................................. 50 Optimisation................................................................................................................................................. 50 Optimisation pour la lecture et l’écriture .................................................................................................................. 50 Optimisation pour l’exécution ................................................................................................................................... 51 CINQUIEME PHASE : RECETTE................................................................................................................................... 52 Recette technique......................................................................................................................................... 52 Recette fonctionnelle.................................................................................................................................... 53 SIXIEME PHASE : MAINTENANCE ET EVOLUTIONS.......................................................................................................... 54 RESULTATS..................................................................................................................................................... 55 DISCUSSION ................................................................................................................................................... 56 CONCLUSION.................................................................................................................................................. 58 BIBLIOGRAPHIE .............................................................................................................................................. 59
  4. 4. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 5 Livres et documents...................................................................................................................................... 59 Sites web....................................................................................................................................................... 59 ANNEXES........................................................................................................................................................ 60
  5. 5. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 6 REMERCIEMENTS Je tiens tout d’abord à remercier Cedric Sarinena pour m’avoir recruté au sein de BNP Paribas Personal Finance. Une grande pensée à toute l’équipe du Système d’Aide à la Décision dont une partie m’a aidé à monter l’étude de ce mémoire. Je tiens également à faire part de ma reconnaissance envers tout le corps enseignant du Master 2 ID Apprentissage de Dauphine, notamment à Mohamed Ali Aloulou (responsable de master), Patricia Lavagna (correspondante au CFA AFIA), et Marie-Jo Bellosta (tutrice enseignante) qui m’a grandement aidé dans la réalisation de ce mémoire. Finalement, mes remerciements les plus profonds iront à Gilles Bretnacher qui fut mon maître d’apprentissage et mon responsable entreprise durant cette année. Il m’a épaulé durant mes missions professionnelles et pendant la rédaction de ce mémoire.
  6. 6. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 7 GLOSSAIRE Clé primaire : Terme utilisé dans les bases de données pour définir un ou plusieurs champs qui servent d’identifiant unique de la table dans laquelle il se trouve. Par exemple, une clé primaire possible d’une table contenant le référentiel des individus est : nom + prénom + date de naissance. Data Warehouse : Entrepôt de données qui regroupe une partie ou l'ensemble des données fonctionnelles en provenance des bases de données opérationnelles d'une entreprise. Son but est de fournir un ensemble de données valides servant de référence unique. Elles sont utilisées, entre autres, pour la prise de décisions lorsqu’il s’agit de créer des « Cubes OLAP » à l’aide de bases de faits et de dimensions. D’un point de vue technique, il sert aussi à « délester » les bases de données opérationnelles des requêtes pouvant nuire à leurs performances. Son périmètre d’action est large car il couvre plusieurs domaines d’activités de l’entreprise. ERP : Un « Enterprise Resource Planning » permet la planification des ressources de l’entreprise. Par « ressources » est entendu tout actif de l’entreprise, par exemple : les ressources humaines (RH), les ressources comptables (Comptabilité), l’information et les données (Informatique), etc. Un ERP est ainsi un « progiciel de gestion intégré » qui permet la gestion d’un domaine d’activité de l’entreprise. ETL : Acronyme de « Extract-Transform-Load ». Il sert à extraire les données de bases sources, les transformer (appliquer des calculs, changer le format, etc.) et les charger dans des bases cibles. C’est la première partie d’un Data Warehouse ou d’un Data Mart. Des logiciels comme « Talend » sont spécialisés dans cette activité. Fichiers plats : Un fichier plat est un fichier de données qui n’est pas dans un format complexe type base de données. Par « format » est entendu l’extension du fichier et donc l’encodage de ce dernier. Par exemple un fichier texte regroupant des données en lignes est un fichier plat. Les fichiers Excel ou CSV (Comma Separated Value) sont aussi des fichiers plats. Les fichiers .bdd (base de données) et .sas7bdat (base de données SAS) ne sont pas des fichiers plats. Granularité de l’information : La granularité de l’information définit la taille du plus petit élément, le niveau de détail le plus profond, qui sera utilisé. Hardware : Mot anglais pour parler des composants physiques d’un ordinateur. Exemple : disque dur, carte graphique, processeur, etc. Indexage : Technique utilisée dans les bases de données pour accélérer les traitements (notamment les requêtes). Des indexs sont créés sur les clés primaires pour pouvoir accélérer les jointures entre plusieurs tables. Log : Fichier généré pendant l’exécution d’un programme qui recense l’historique des évènements : les résultats et les erreurs qui sont survenues. Il peut être sous la forme de texte (fichier plat) ou de données sauvegardées dans une base. Logiciels BI : Logiciels spécialisés dans le traitement de la « Business Intelligence » (informatique décisionnelle), à savoir : la gestion de grand volumes de données (ETL, Data Warehouse, Data Mart), la fouille de données, les analyses, les reportings. Exemples : Cognos, SAP BI Analytics, Talend, SAS Enterprise Suite, Microsoft SQL Server, Oracle EPM et BI, Hadoop… Reporting : Compte-rendu alimenté de données et d’analyses qui peut être présenté sous la forme de fichiers (Excel, CSV, etc.), de page web (HTML), ou de pages intégrées dans un logiciel spécialisé
  7. 7. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 8 (Exemple : Tableau, Cognos, SAP…). Il sert à diffuser et mettre en forme l’information pour un utilisateur, la rendre compréhensible et utilisable. SAS : SAS est avant tout une entreprise. Elle a mis au point un langage de programmation ainsi que plusieurs types de solutions spécialisées dans le management de données en général (exemple : SAS Enterprise Guide, SAS Enterprise Miner…). Le langage de programmation permet de créer, modifier et supprimer des bases de données SAS. Il permet aussi de coder tout un processus incluant des fonctions, des variables dynamiques, etc. pour traiter les données. Schéma en étoile : Les schémas en étoiles sont des types de représentations de plusieurs tables en relation (une au centre reliée à toutes les autres, alors que ces dernières n’ont pas de liens entre elles). Il est souvent utilisé dans les Data Warehouse et Data Mart. Le modèle en étoile permet une économie de jointures à l'interrogation, ce qui le rend optimisé pour les requêtes d'analyse. SGBD : Un « Système de Gestion de Bases de Données » est un logiciel système permettant de stocker et gérer des bases de données. Il est composé de plusieurs bases de données, contenant elles-mêmes plusieurs tables reliées entre elles par des relations. Deux SGBD connus sont « MySQL » et « SQL Server ». Software : Mot anglais pour parler des applications et logiciels. Ce sont donc les éléments informatiques légers d’un ordinateur (à la différence des hardware). SQL : « Structured Query Language » est un langage informatique destiné à créer, modifier, supprimer et interroger les bases de données. C’est un langage dédié, spécialisé dans ce type de fonctions. On parle souvent de « requêtes SQL ».
  8. 8. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 9 INTRODUCTION ET PROBLEMATIQUE « Si l’on numérisait toutes les communications et les écrits depuis l’aube de l’humanité jusqu’en 2003, il faudrait 5 milliards de gigabits pour les mettre en mémoire. Aujourd’hui ce volume d’informations numériques est produit en deux jours. »1 Cette phrase, répétée par Eric Schmidt l’ex-PDG de Google, résume assez bien la problématique générale que subit le monde informatique d’aujourd’hui : le nombre de données générées dans les domaines publiques et privés devient vertigineux. Il s’agit de trouver comment stocker et analyser ces données dans des temps raisonnables. Les termes Big Data, Smart Data, Business Intelligence (BI) etc. font parler d’eux car ils tentent, à tort ou à raison, de répondre à ce problème qui ne cesse de croître. Pour comprendre ce domaine, il faut d’abord commencer par assimiler les notions d’information, de données, de qualité de données, d’indicateurs et d’automatisation. L’expression « technologies de l’information » n’est pas utilisée au hasard car le but premier de l’informatique est de récolter, traiter et diffuser l’information. De là émane le terme « Informatique Décisonnelle » (traduction de Business Intelligence) qui signifie « l’informatique au service des données, pour la prise de décisions ». Cette spécialisation vient du fait que, de plus en plus, les dirigeants souhaitent connaître l’activité de leur entreprise. L’accès à des résumés et analyses de l’activité devient essentiel pour piloter son organisation. Un autre aspect de l’Informatique Décisionnelle est la gestion des sources de données multiples au sein d’une entreprise : comment regrouper les informations éparpillées dans différentes bases d’une entreprise ? Comment faire en sorte que ces données soient cohérentes et de qualité (complètes, sans doublons, etc.) ? Pour répondre à cette demande, les notions d’« Analytics » et de « Data Warehouse » sont apparues. L’Analytics n’est autre que l’analyse de données qui comprend : les statistiques, les indicateurs et la fouille de données (« Data Mining »). Tandis que le Data Warehouse est un entrepôt de données central, chargé de regrouper et de formaliser toutes les données fonctionnelles de l’entreprise. Des acteurs connus comme SAS, Oracle, IBM, SAP, Microsoft, Talend etc. ont développé des logiciels BI qui offrent des suites intégrées pour implémenter ces solutions, qui sont en concurrence comme le montre l’étude annuelle « Magic Quadrant » de Gartner. Mais ces solutions sont souvent très coûteuses (de l’ordre de plusieurs milliers d’euros par utilisateur, en comptant la somme des coûts de licence, d’implémentation et de maintenance). Qu’en est-il alors de l’obtention d’une solution type « Data Warehouse » lorsque le budget à disposition est limité ? De plus, le besoin d’avoir accès à un référentiel de données de qualité peut parfois provenir de plus petites entités. Par exemple, au sein d’une même entreprise, la fonction « Ventes » peut émettre un besoin plus urgent que la fonction « Ressources Humaines », et leurs attentes en termes d’analyses seront différentes. Serait-il alors possible de construire rapidement et à coûts réduits un « Data Warehouse » spécialisé dans les Ventes ? Cette solution existe et est appelée « Data Mart » (magasin de données). C’est une sorte de Data Warehouse réduit et spécialisé sur un périmètre donné (branche d’activité, fonction...). Un Data Mart regroupe, consolide et traite les données d’un secteur d’activité spécifique. Il est généralement facile, rapide et donc peu coûteux à mettre en place. 1 Citation d’Eric Schmidt, ex-PDG de Google.
  9. 9. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 10 Dans le cadre d’un logiciel BI déjà installé sur le système, il est assez intuitif de mettre en place un Data Mart. Les phases de développement, d’automatisation et de diffusion des résultats sont alors guidées par le logiciel. Cependant, lorsqu’il n'y a pas de logiciel spécialisé à disposition, il est toujours possible de mettre en place un Data Mart par ses propres moyens. Des langages de programmation comme SAS, UNIX et SQL peuvent permettre de générer la structure du Data Mart, de le fournir en données, et de calculer des indicateurs qui pourront être analysés. Le mémoire s’inscrit dans ce deuxième cas, lorsque nous ne possédons pas de logiciel BI déjà installé. De ce fait, la problématique est la suivante : Pourquoi et comment créer, implémenter et optimiser un Data Mart, sans l’aide de logiciel spécialisé, dans le but de fournir des indicateurs de performances. Pour tenter de répondre à cette problématique, le mémoire est divisé en deux parties : une première partie faisant l’état de l’art et une deuxième partie décrivant la méthode utilisée pour apporter une solution au développement, à l’automatisation et à l’optimisation d’un Data Mart. Dans la première partie sont introduites les notions d’information, de données, de qualité de données, d’indicateurs et d’automatisation. Il y est aussi fait une présentation du Data Mart : la définition, les intérêts, les deux types possibles, et une méthode d’implémentation globale.2 La deuxième partie présente la méthode mise en place, à savoir : les hypothèses de notre étude, les différentes phases d’implémentation du Data Mart sans l’aide de logiciel spécialisé, en passant par les solutions d’automatisation et d’optimisation, et les spécificités des différents logiciels de programmation utilisés. Finalement, avant de commencer la lecture du mémoire il est conseillé de prendre connaissance des mots et termes qui sont utilisés tout au long du document : cf. « Glossaire » page 7. 2 Faute de pertinence apportée dans la proposition, certains points ne sont pas abordés comme notamment : les définitions plus poussées des critères de qualité de données, leurs algorithmes de résolution et les « Master Data » ; la gestion fine des bases de données, des métadonnées et de l’indexage ; des exemples de Data Mart et de leurs techniques d’automatisation et d’optimisation, dû à la confidentialité de ceux-ci.
  10. 10. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 11 NOTIONS DE BASE Préambule : information et données L’information Définition L’information c’est « le renseignement porté à la connaissance d'un public plus ou moins large, sous forme d'images, de textes, de discours ou de sons »3 . Plus précisément en informatique, c’est « l’Élément de connaissance susceptible d'être représenté à l'aide de conventions pour être conservé, traité ou communiqué »4 . L’information est donc un terme général qui permet d’identifier un renseignement sur un sujet spécifique, mis en forme, et pour une audience déterminée. Elle peut être normalisée et sauvegardée sous forme de donnée, dont certaines propriétés sont regardées (cf. partie suivante « La donnée »). Et finalement, une nouvelle information peut émaner d’un traitement de données, que ce soit par transformation, agrégation ou interprétation (cf. partie « Les indicateurs : une vision traitée et concise de l’information »). But et bonne pratique Le but de l’information est bien entendu de communiquer des connaissances pour les assimiler, l’historiser, prendre des décisions etc. Mais son objectif est aussi de faire l’état des lieux des connaissances en termes d’identité, de fiabilité, de structure et d’accessibilité. On parle alors de « bonne » information.  Identité : L’auteur est-il facilement identifiable ? Cite-t-il à son tour ses sources ?  Fiabilité : o L’information a-t-elle été vérifiée ? Est-elle précise et exacte ? o Est-elle mise à jour et donc apporte-t-elle du nouveau ? (Ce qui est la fonction même de l’information : « enrichit-elle les connaissances ? »)  Structure : L’information est-elle bien présentée ? Bien rédigée ? Sur quels critères se base-t- on ?  Accessibilité : Elle doit être facilement localisée et retrouvée à une adresse stable et par différents moyens. Toutes ces propriétés assurent, lorsqu’elles sont bien gérées, une information de qualité et donc une information de valeur, reconnue par le public. Aussi, Il faut bien différencier l’information de la communication. La communication est le support de diffusion de l’information. Elle est composée d’un ensemble de moyens et techniques permettant la transmission de l’information auprès d’une audience. 3 Citation : http://www.larousse.fr/dictionnaires/francais/information 4 Idem
  11. 11. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 12 La donnée Définition et valeur Une donnée c’est « ce qui est connu ou admis comme tel, sur laquelle on peut fonder un raisonnement, qui sert de point de départ pour une recherche »5 . C’est aussi « une représentation conventionnelle d’une information en vue de son traitement informatique »6 . Les données peuvent être de différentes formes : papier, alphabétique, numérique, sons, images, etc. Les données se regroupent généralement dans des bases de données qui sont des conteneurs permettant de stocker et de retrouver l'intégralité des informations en rapport avec une activité. Une base de donnée peut être modélisée par beaucoup de choses (bibliothèque, archives, web, etc.) mais par vulgarisation, on appelle « base de données » un élément informatique qui sauvegarde les données de manière hiérarchisée et structurée, en vue de collecter les données, de les stocker et de les restituer. Ces données sont généralement reliées entre elles dans différentes tables par des méthodes de jointures. La gestion des bases de données est un chantier volumineux en informatique, mais il n’est pas abordé dans ce mémoire car il constitue un sujet à lui seul. Il existe aussi les données non structurées, qui sont définies de la manière suivante par Bill Inmon7 : « tout document, fichier, image, rapport, formulaire, etc. qui n’a pas de structure standard définie qui permettrait de le stocker facilement dans un dispositif de traitement automatisé. Il ne peut pas être défini en termes de lignes et de colonnes ou d’enregistrements. (...) Les données non structurées sont les e-mails, les feuilles de calcul, les documents, etc. Certaines des informations les plus précieuses de l’entreprise résident dans ses données non structurées. »8 Une donnée peut être figée (par exemple lorsqu’elle décrit une réalité absolue qui n’est pas censée bouger dans le temps), mais elle peut aussi apparaître suite à un évènement. C’est le principe d’une donnée dynamique mise à jour régulièrement et, si possible, automatiquement. On parle alors de données « chaudes » (mises à jour dans la journée ou même dans l’heure) par rapport aux données « froides » (qui datent depuis plusieurs semaines voire plusieurs mois). Les données chaudes ont généralement plus de valeurs que les données froides car elles sont plus récentes et sont donc censées mieux représenter la réalité actuelle. Cependant, suivant le type de donnée, une donnée froide peut avoir tout autant de valeur qu’une donnée chaude. Par exemple : les historiques (dont la plupart des données sont « froides » mais qui sont essentielles quand il s’agit d’effectuer un retour sur l’activité, des prévisions, des estimations, etc.). D’une manière plus générale, on définit la valeur d’une donnée comme la différence entre son bénéfice et son coût. Ces deux aspects peuvent être calculés sur plusieurs critères :  Son identité : source, date de création, date de mise à jour  Sa forme et ses métadonnées (cf. partie « Les métadonnées » ci-dessous)  Sa qualité (cf. partie « Qualité de données » ci-dessous)  Son stockage : méthodes de sauvegardes et d’entretiens  Son analyse : information dégagée Le critère qui sera détaillé ici sera celui de la qualité, car c’est un élément déterminant dans la construction d’indicateurs et l’analyse de données. C’est aussi le critère le plus important dans la 5 Citation : http://www.larousse.fr/dictionnaires/francais/donnée 6 Idem 7 Bill Inmon : Un des principaux théoricien de l’Informatique Décisionnelle, avec Ralph Kimball. 8 http://www.information-management.com/glossary/u.html
  12. 12. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 13 valeur de la donnée. Si la donnée n’est pas de qualité dès le départ, alors tout ce qui en découle est biaisé. C’est le cas pour un Data Mart. Qualité de données La qualité de donnée est définie de la manière suivante par la réglementation ISO 90000:2005 : « C’est l’ensemble des caractéristiques intrinsèques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins implicites, ou exprimés en interne (pilotage, prise de décision, etc.) ou en externe (réglementations, etc.) ». Sachant que les données contribuent au succès de l’activité de l’entreprise, leur qualité représente un enjeu critique pour l’entreprise dans les trois étapes de leur cycle de vie :  Lors de la saisie  Au cours des transformations et agrégations  Pendant l’analyse et la présentation des résultats Les caractéristiques intrinsèques des données sont les suivantes : 1. Unicité 2. Complétude 3. Exactitude 4. Conformité 5. Cohérence 6. Intégrité
  13. 13. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 14 La description et les méthodes mises en œuvre pour assurer la qualité de données sur ces critères sont résumées dans le Tableau 1 suivant, à l’aide du document de l’Université Paris Dauphine rédigé par Dario Colazzo « La donnée et sa dimension de valeur », 10 décembre 2013 : Tableau 1 : Récapitulatif des différents critères de qualité de données Critères Description Méthodes possibles pour assurer la qualité Unicité Assurer l’absence de doublons Processus déterministe : vérifier des propriétés de rapprochement simples sur des champs discriminant précis. Processus probabiliste : utilisation d'algorithmes de rapprochement prenant en compte les composants syntaxiques et les informations complémentaires. (exemples : Jaccard Similarity, Cosine Similarity...) Complétude Présence de données indispensables au niveau objet ou jeu de données Vérifications manuelles Exactitude La valeur de la donnée est la représentation exacte de sa grandeur dans le monde réel Vérifications manuelles Conformité Sous dimension de l'exactitude. C'est le respect d'un ensemble de contraintes de format. Vérification manuelles. Possibilités de les faire en masse. Cohérence Pas d'informations conflictuelles ou contradictoires Vérification manuelles. Possibilités de les faire en masse. Intégrité Respect des contraintes d'intégrités du modèle de données (clés primaires, clés externes, etc.) Vérification manuelles. Rapides au niveau des descriptions de données (métadonnées etc.) De plus, la qualité de donnée repose aussi sur des critères de services, plus généraux, qui sont :  Actualité : une donnée est périmée à l’instant t si elle est incorrecte à cet instant, mais qu’elle était correcte auparavant. o Exemple : plus de 3 millions de foyers déménagent en France chaque année. Cela implique que 5% des adresses d’un fichier client n’est plus d’actualité après un an.  Accessibilité : facilité d’accès aux données. Accessible sur différentes plateformes, à différents endroits, et suivant les droits d’accès.  Pertinence : la granularité de l’information doit correspondre aux besoins.  Compréhensibilité : chaque utilisateur, chaque processus, chaque application trouve facilement l’information souhaitée.9 Les aspects plus poussés de la Qualité de données (tels que la Master Data, le Problème de qualité de donnée, les Algorithmes de résolutions, etc.) ne sont pas abordés dans ce mémoire. L’objectif ici est d’avoir une vision d’ensemble des principes de Qualité en prenant connaissances des 6 caractéristiques intrinsèques qui sont regardées dans ce milieu. L’Unicité est souvent une 9 « La donnée et sa dimension de valeur », Chercheur Dario Colazzo, Université Paris Dauphine, 10 décembre 2013
  14. 14. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 15 caractéristique difficile à gérer. Nous le verrons dans la partie « pratique » du mémoire, lorsqu’il s’agit de dé-doublonner des listes de données pour le calcul des indicateurs. Les métadonnées Une métadonnée est une donnée à propos d’une donnée (mot composé du préfixe grec « meta », indiquant l'auto-référence10 ). Par exemple, la métadonnée « taille » de la donnée « code postal » peut prendre la valeur 5, pour définir que la donnée « code postal » doit faire exactement 5 chiffres (75015, 92500, etc.). Les métadonnées sont un aspect très important des bases de données car elles permettent de définir en détails la nomenclature des données. Elles servent à la fois à blinder les saisies de manière brute et donc à assurer une partie de la qualité de l’information (un code postal à 6 chiffres sera rejeté par la base de données et celle-ci renverra une erreur), mais aussi à renseigner plusieurs informations essentielles comme :  Le type (entier, réel, caractères, date, etc.)  La longueur o Longueur max/min o Longueur fixe (exemple code postale)  Le nom (l’identifiant informatique de la donnée)  Le label (nom affiché lors des résultats de requêtes)  Et d’autres, comme le nombre de décimales pour un type « réel », ou l’encodage du texte pour un type « caractères », etc. L’ensemble des métadonnées est appelé le « dictionnaire de données ». Dans le cadre d’un Data Mart, les métadonnées jouent un rôle important quand il s’agit de définir les indicateurs qui seront créés. Dans notre proposition nous nous attachons à répondre à la question suivante : quelles sont les métadonnées de nos indicateurs ? Les indicateurs : une vision traitée et concise de l’information Définition En informatique décisionnelle, un indicateur est une nouvelle donnée créée pour fournir une information supplémentaire à partir de données traitées suivant des règles. C’est un outil d’évaluation et d’aide à la décision à partir duquel on va pourvoir mesurer une situation ou une tendance. Un indicateur peut être perçu comme une sorte de résumé d'informations complexes offrant la possibilité à des acteurs différents de comprendre leurs environnements et de dialoguer entre eux. Par exemple, dans le domaine du crédit, un indicateur simple peut être le « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés dans le mois ». Une liste de dossiers éparpillés dans la base de données sera donc résumé en un nombre (ex : 2700). Dans la pratique, beaucoup d’indicateurs simples sont utilisés pour avoir une vision rapide de l’activité quotidienne de l’entreprise, mais aussi d’autres plus complexes sont pensés : calculs sur plusieurs données 10 Source : http://fr.wikipedia.org/wiki/Métadonnée
  15. 15. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 16 mensuelles et suivant plusieurs règles, indicateurs imbriqués (indicateurs agrégés à partir d’autres), etc. L’utilité d’un indicateur dépend naturellement de sa capacité à refléter la réalité, mais aussi de sa simplicité de compréhension et d’acquisition. Les indicateurs peuvent être de différentes formes : binaires (oui/non), quantitatif (numériques), qualitatif (caractères), etc. Ils sont calculés à partir de règles qui s’appliquent sur un ensemble de données. Par exemple : « si un dossier porte le nom ‘immobilier’ et une valeur initiale supérieur à 100 000 €, alors on le comptabilise ». Avantages  Fournis un accès rapide à l’information.  Orienté pilotage pour les directions.  Coût de stockage faible, bénéfice à l’analyse fort.  Modulable (création et modification rapide).  Historisable puis comparable. Inconvénients  S’ils sont regardés seuls : perte de l’information de base, vision « trop globale ».  Ne prend pas en compte certaines données environnementales temporelles : si par exemple les référentiels de données changent mais pas les méthodes de calculs, alors l’historique de l’indicateur est biaisé. Caractéristiques recherchées Beaucoup de sites internet d’entreprises, de publications et de blogs sont convergents sur les caractéristiques d’un « bon indicateur »11 . De façon générale, plusieurs critères sont regardés : 1. Pertinent : Doit correspondre à une attente de l’organisation qui le met en place, doit avoir un but bien défini pour la mesure et l’analyse. Dans la pratique, beaucoup d’indicateurs sont créés et seulement une poignée est réellement utilisée. Le but d’un indicateur pertinent est d’éviter cela, même si, au vu de leurs coûts faibles et de leurs potentiels forts, il est préférable d’avoir dès le départ une longue liste d’indicateurs à sa disposition (quitte à y attribuer un niveau de pertinence). 2. Réalisable : Une fois pensé, l’indicateur doit pouvoir être construit à partir des données à disposition. Il est rare de pouvoir imaginer un indicateur sans pouvoir le mesurer dans la pratique, mais il faut garder en tête qu’un indicateur conceptuellement parfait mais difficilement mesurable n’est pas très utile. 3. Représentatif : L’indicateur doit bien évidemment être précis dans sa définition, mais aussi dans sa mesure. Il doit représenter le plus parfaitement possible la grandeur qu’il cherche à mesurer. Ce critère n’est pas des plus simples à respecter puisque suivant les méthodes de calculs qui peuvent être difficiles, ou la qualité de donnée qui peut faire défaut (comme la 11 Sources : - http://www.gbo.tn/index.php?option=com_fsf&view=faq&Itemid=189&catid=2&faqid=3 - http://www.qualiblog.fr/objectifs-indicateurs-et-tableaux-de-bord/comment-definir-des-indicateurs- pertinents-pour-mesurer-lefficacite-des-systemes-de-management/ - http://www.has-sante.fr/portail/upload/docs/application/pdf/2013- 02/suivi_indicateurs_qualite_fiche_technique_2013_01_31.pdf - http://www.blog.saeeed.com/2009/11/les-caracteristiques-dun-bon-indicateur/
  16. 16. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 17 présence de quelques doublons par exemple), il sera difficile d’avoir une valeur parfaitement juste. Plus le jeu de données sur lequel se base l’indicateur est grand, et plus les risques de biais augmentent. a. Sensible : La sensibilité est l’équivalent de la représentativité sur les variations de l’indicateur. Il doit refléter le plus parfaitement possible les variations de ce qu’il cherche à mesurer. Si la grandeur évolue, alors l’indicateur est censé évoluer dans les mêmes proportions. b. Robuste : A l’instar de la sensibilité, un indicateur doit être suffisamment stable pour ne pas être altéré par les fluctuations aléatoires et temporelles. Il faut donc trouver l’équilibre entre sensibilité et robustesse. Dans la pratique, un indicateur très représentatif entraine à la fois une bonne sensibilité ainsi qu’une bonne robustesse. Il faut cependant garder en tête que l’indicateur parfait n’existe pas. Il faut coupler et comparer plusieurs indicateurs pour avoir une représentation complète et qualitative de la réalité. 4. Disponible : Un indicateur doit avant tout être vu et utilisé. S’il est sauvegardé quelque part mais laissé à l’abandon, alors il devient inutile. C’est pourquoi les indicateurs doivent pouvoir être accessibles facilement par les utilisateurs intéressés. Cela peut être sous forme de compte d’accès à une base, ou sous forme de reportings générés automatiquement. Cet aspect rejoint aussi la disponibilité des données, qui elles, doivent être produites suffisamment rapidement avec une bonne fréquence pour garantir la mise à jour de l’indicateur en temps utile. 5. Compréhensible : Si un indicateur n’est pas compris par la personne qui l’utilise, il perd tout son sens. Il doit être intelligible : simple, clairement défini et compréhensible. Son interprétation doit être commune et partagée pour pouvoir l’utiliser confortablement dans le milieu opérationnel. Dans la pratique, une méthode simple pour satisfaire ce critère est de rédiger un référentiel qui décrit en détails le but, les paramètres, et les règles de calculs des indicateurs. Il peut même être plus complet pour l’équipe technique en affichant clairement les requêtes utilisées pour les construire. 6. Traçable : Finalement, lorsque les 5 premiers critères sont respectés, il est important de pouvoir justifier la source. La construction de l’indicateur doit être documentée et identifiée. Par exemple si des modifications ont été apportées, il est important de savoir pourquoi (à la suite de quelle anomalie et les états avant/après), par qui et quand ont été faites ces modifications. Axes d’analyse Les axes d’analyse apportent la notion de dimension aux indicateurs. Ils sont similaires aux « dimensions » que l’on retrouve dans un Cube OLAP (cf. Glossaire). Si on reprend l’exemple du « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés », c’est un chiffre global, défini par une méthode de calcul générique. Tel quel, il apporte une information de valeur mais ne permet pas non plus de piloter le crédit immobilier dans le détail. Il est possible de fragmenter ce chiffre pour affiner l’indicateur et répartir le résultat : c’est ce que les axes d’analyse permettent de faire. La formule usuelle d’un indicateur soumis à un axe d’analyse est « indicateur par axe ». Par exemple, si l’organisation se divise en plusieurs agences A, B, C, D et E qui appartiennent à deux pôles 1 et 2, alors il est possible de soumettre l’indicateur aux deux axes :
  17. 17. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 18 1. « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés, par agence » 2. « nombre de crédits immobiliers d’une valeur supérieur à 100 000 € signés, par pôle » L’axe 1 par agence est l’axe le plus fin, tandis que l’axe 2 par pôle est l’axe de niveau supérieur, qui intègre l’axe 1. D’une manière générale, un axe d’analyse est en fait une hiérarchie de plusieurs sous-axes. C’est à partir de ces axes d’analyse que l’agrégation d’un indicateur va être réalisée. Dans notre exemple, il est possible d’appeler l’axe d’analyse général : « axe_entité_gestionnaire ». On obtient alors le tableau suivant qui donne un exemple de l’utilisation des axes d’analyse : Tableau 2 : Exemple d’indicateurs et d’axes d’analyse axe_entité_gestionnaire Indicateurs Pôles Agences Nb de crédits immobiliers sup. à 100 000 € signés Indicateur 2 Indicateur 3 1 A 120 … … B 230 … … C 90 … … 2 D 160 … … E 210 … … A partir d’une répartition par axe d’analyse, il devient donc possible de faire des totaux généraux ou des sous-totaux (sommes, moyennes). Le total général n’est autre que la valeur de l’indicateur sans axe d’analyse. Les « KPI » : notion KPI est l’acronyme de « Key Performance Indicator ». Il est traduit par ICP : « Indicateur Clef de Performance ». Il est important de connaître cet acronyme car il est beaucoup utilisé, surtout dans les domaines du marketing, de la finance et du risque. Initialement, un KPI est un indicateur très important car très regardé pour le pilotage de l’organisation, mais il est de plus en plus utilisé comme raccourci pour définir n’importe quel indicateur d’aide à la décision. Les KPI sont censés être les quelques indicateurs regardés fréquemment à partir desquelles des conclusions importantes sont tirées. Par exemple, dans une entreprise de marketing web, des KPI peuvent être : le nombre de visites quotidiennes, le taux de transformation12 quotidien, le panier moyen d’un acheteur, etc. Les indicateurs de moins grande importance sont par exemple le « nombre de clics quotidiens sur telle rubrique », le « temps moyen passé par page », etc. Les indicateurs sont, en partie, le résultat du développement d’un Data Mart. Ils doivent être pensés et créés en respectant les caractéristiques citées ci-dessus, et le Data Mart doit être développé en suivant ces idées. Un autre aspect important dans cette démarche est l’automatisation. Tout au long du processus, les traitements doivent être automatisés pour garantir une fiabilité et une rapidité maximale. Un indicateur est l’agrégation de plusieurs données, il est donc impossible de le générer « à la main » lorsque la base de données sur laquelle il se base dépasse une certaine taille. On doit alors avoir recours à des logiciels (Progiciels intégrés spécialisés dans la BI, Excel à petite échelle, etc.) 12 Taux de transformation : c’est le rapport entre le nombre de personnes qui achètent effectivement sur le site, et le nombre total de visites. Il est généralement très faible.
  18. 18. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 19 ou des langages informatiques de traitements de tables et de données (SQL, SAS, UNIX…) pour développer et mettre en forme tous les programmes nécessaires. L’automatisation du traitement de données Définition L’automatisation est la « suppression totale ou partielle de l'intervention humaine dans l'exécution de tâches diverses »13 . Elle vise à accélérer et consolider les processus qui y sont soumis. C’est l’essence même de l’informatique (les principes fondamentaux de l'informatique identifiés par Peter Denning sont : computation, communication, coordination, automatisation, évaluation, conception14 ). L'automatisation ne consiste pas simplement à remplacer l'homme par un automate, mais conduit à repenser plus ou moins profondément le processus considéré et à remettre en question les habitudes acquises et les solutions traditionnelles. Prenant en charge tout ou partie des fonctions intellectuelles intervenant dans la conduite d'un processus, elle se situe à un niveau supérieur à la simple mécanisation. Partie intégrante de la conception et de la gestion des grands ensembles industriels, administratifs et commerciaux, elle constitue l'un des facteurs d'accroissement de la productivité et d'amélioration de la qualité.15 Cette description de l’automatisation donnée par Larousse est très large car elle introduit les sujets de refonte des processus contre les solutions traditionnelles, de la différentiation par rapport à la mécanisation, et de son apport d’améliorations dans la productivité et la qualité. C’est ce dernier point d’améliorations de la productivité et de la qualité qui est le plus recherché lorsqu’on décide d’automatiser un processus, et c’est celui qui est détaillé dans ce mémoire. En informatique, la mise en automatisation est un investissement avant tout. Le fait de mettre en place un projet pour automatiser un ou plusieurs processus requiert des fonds (humains et financiers). Le fait d’automatiser est coûteux et doit répondre à des besoins de temps et d’efficacité. C’est pourquoi il est important d’avoir une méthodologie adaptée pour formaliser ce qui est voulu (besoin) et ce qui est fait (recette). Méthodologie possible Le souhait d’automatiser un processus vient souvent du fait que ce processus est connu, redondant et long à réaliser. Par exemple, dans une équipe d’aide à la décision, les statisticiens peuvent être chargés de sortir chaque mois des reportings pour les équipes opérationnelles. Pour cela ils peuvent utiliser SQL, interroger la base de données directement, et retravailler la mise en forme et l’analyse via un tableur (exemple : Excel). Il est aussi possible d’utiliser un logiciel spécialisé qui permet de faire la même chose de façon plus intuitive (exemple : SAP, Cognos, Talend, SAS Enterprise Guide, etc.). Dans les deux cas, ce sont des processus qui sont réalisés « à la main », qui demandent du temps et qui peuvent être sources d’erreurs. L’automatisation, grâce à ses deux principaux avantages qui sont la rapidité d’exécution et l’exactitude des résultats, est une solution à ce problème. La méthodologie d’automatisation qui est globalement utilisée est la suivante : 13 http://www.larousse.fr/encyclopedie/divers/automatisation/24386 14 “Great Principles of Computing” : http://cs.gmu.edu/cne/pjd/GP/GP-site/welcome.html 15 http://www.larousse.fr/encyclopedie/divers/automatisation/24386
  19. 19. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 20 1. Définition du périmètre et des besoins : qu’est-ce qui est fait jusqu’à présent ? Des évolutions métiers sont-elles prévues ? Qu’est-ce qui doit être automatisé ? 2. Analyse du ratio bénéfices/coûts : il faut s’assurer que sur le long terme, les bénéfices de temps et de qualité seront supérieurs aux coûts de développement et d’entretien. Lorsque les moyens humains sont disponibles, cette analyse est rarement faite car un processus automatique est plus rentable dans quasiment tous les cas. 3. Outils utilisés : comment allons-nous automatiser, avec quels langages informatiques et/ou quels logiciels ? 4. Forme des résultats : se mettre d’accord avec les équipes opérationnelles qui profiteront des résultats pour s’assurer de leurs besoins dès le départ. 5. Développement : via des langages de programmation pour créer son propre logiciel ou via un logiciel spécialisé (moins flexible, plus ergonomique). 6. Recette et validation : tester le programme et valider les résultats avec le métier. Ce qu’on obtient est-il juste ? N’y a-t-il pas de régression par rapport à l’ancienne méthode ? 7. Mise en production : une fois les tests validés, il faut définir les paramètres temporels du logiciel (lancé automatiquement chaque jour, chaque mois, à la main ?) et passer le processus en production. Les différents niveaux d’automatisation Il existe plusieurs niveaux d’automatisation suivant le nombre d’intervention et leur type :  Automatisation complète : le processus se lance tout seul depuis un serveur à des horaires définis. Tout le processus est automatique, jusqu’à la diffusion des résultats.  Automatisation quasi-complète : le processus nécessite une intervention humaine simple, que ce soit au début pour lancer le programme, ou à la fin pour diffuser les résultats.  Automatisation fragmentée : une grande partie du processus est automatique et plusieurs interventions humaines simples sont nécessaires comme par exemple alimenter un référentiel utilisé par le programme mais donné par les équipes métiers, transférer les résultats obtenus avant l’envoi vers un template de mise en forme, etc.  Automatisation partielle : certaines parties du processus sont automatiques mais d’autres ne le sont pas. L’humain doit intervenir dans la modification des programmes pour mettre à jour une variable par exemple, puis lancer manuellement le processus. Inconvénients Mise à part les avantages cités dans la définition de l’automatisation, celle-ci peut avoir certains inconvénients, moins importants, mais dont il est bon d’avoir connaissance. Comme pour les indicateurs, l’automatisation impose un certain recul par rapport aux données de bases qui sont traitées, et ce recul est d’autant plus important que l’automatisation intervient à un niveau plus élevé : elle intègre des processus et traitements imbriqués et pas seulement des agrégations de données. Les automatisations font souvent place à des « boites noires », c’est-à-dire des programmes qui fonctionnent, mais dont on ne connait pas vraiment les détails de l’exécution. Le jour où un problème survient, il devient difficile de le corriger car nous n’avons pas connaissance du programme et de son fonctionnement. Il est donc important, voire primordial, de commenter le programme et
  20. 20. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 21 de documenter son fonctionnement, de manière fonctionnelle et détaillée. Les commentaires figurent à l’intérieur du programme tandis que le document peut être un document texte qui explique les fonctions du programme, avec des schémas par exemple. Il existe aussi une 3ème aide à la résolution des problèmes qui se met à jour à chaque exécution du programme : la « log » (appelé « journal d’exécution » en français). Ce fichier sert de vérification et permet d’identifier les erreurs rapidement (et même de les comprendre lorsque la génération de la log est bien faite). La log peut être générée soit automatiquement par les logiciels spécialisés ou même certains langages comme SAS, soit par le développeur via des instructions dans le programme. Dans les deux cas, il est important de la sauvegarder à chaque exécution car elle peut s’avérer très utile. Lois et règles en vigueur sur les traitements automatisés Il est important de prendre connaissance des réglementations en vigueur lorsqu’on souhaite automatiser des traitements de données, car il se peut qu’ils soient soumis à des conventions. Par exemple, en Europe, le traitement automatique de données à caractères personnel est soumis à une convention dont le but est de « garantir, sur le territoire de chaque Partie, à toute personne physique, quelles que soient sa nationalité ou sa résidence, le respect de ses droits et de ses libertés fondamentales, et notamment de son droit à la vie privée, à l'égard du traitement automatisé des données à caractère personnel la concernant »16 . Par « traitement automatisé s'entend des opérations suivantes effectuées en totalité ou en partie à l'aide de procédés automatisés : enregistrement des données, application à ces données d'opérations logiques et/ou arithmétiques, leur modification, effacement, extraction ou diffusion ». Dans le cadre du développement d’un Data Mart par exemple, des extractions, des opérations logiques et arithmétiques, et des diffusions sont réalisées. Il faut donc s’assurer que le projet que nous mettons en place a été validé sous un angle juridique. 16 « Convention pour la protection des personnes à l'égard du traitement automatisé des données à caractère personnel », Strasbourg, 28.I.1981. Lien : http://conventions.coe.int/treaty/fr/treaties/html/108.htm
  21. 21. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 22 ETAT DE L’ART ET ANALYSE Data Mart Tout au long de ce chapitre, les notions énoncées se basent sur les expériences personnelles et sur les écrits de documents et livres officiels rédigés par des acteurs principaux de la BI17 . Définitions et principes Définition Le Data Mart (DM) est un « magasin » qui regroupe et traite les données d’un domaine spécifique. Les deux principaux théoriciens de l’Informatique Décisionnelle en ont fait une définition formelle :  Définition de Ralph Kimball : « Le Data Mart est un sous-ensemble du Data Warehouse, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise est censé constituer le Data Warehouse. »  Définition de Bill Inmon : « Le Data Mart est issu d’un flux de données provenant du Data Warehouse. Contrairement à ce dernier qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée fonctionnellement. » Un DM est souvent créé et géré par un seul département dans l’organisation. Par exemple, le département Marketing gère le Data Mart marketing, les Finances le DM finance, etc. De par son aspect « domaine d’activité », il récolte généralement les données de peu de sources. Ces sources peuvent provenir d’un Data Warehouse central, de systèmes opérationnels internes, ou de systèmes externes à l’organisation. On parle alors de DataMarts dépendants (Data Warehouse) ou indépendants (autres sources internes ou externes). Généralement les DataMarts fournissent aussi des données traitées et agrégées pour le métier, comme des indicateurs. Ces processus de calculs doivent être automatisés pour garantir un certain niveau de performances. Structure physique et théorique Les DataMarts peuvent être stockés physiquement sur des disques durs hébergés sur un serveur. Le support théorique quant à lui peut être de plusieurs formes :  Soit par un Système de Gestion de Base de Données (SGBD) : le Data Mart n’est autre qu’un SGBD relationnel.  Soit par un système de dossiers contenants des fichiers plats (CSV, etc.).  Soit finalement par un mélange des deux : un système de dossiers contenants des fichiers aux formats bases de données (par exemple SAS avec ses bases de données sous formes de fichiers mobiles .sas7bdat) 17 - « Building the Data Warehouse » – William H. (Bill) Inmon. 3 rd edition, John Wiley & Sons, 2002. - « The Data Warehouse Toolkit » – Ralph Kimball & Margy Ross. 2 nd edition, John Wiley & Sons, 2002. - « Business Intelligence Standard » – Oracle®. Edition one, 2007. Lien : http://docs.oracle.com/html/E10312_01/dm_concepts.htm - « Data Mart Consolidation : getting control of your enterprise information » – IBM®, Redbooks. 2005. Lien : http://www.redbooks.ibm.com/redbooks/pdfs/sg246653.pdf
  22. 22. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 23 Le Data Mart peut parfois être confondu avec la notion de Cube OLAP. Il peut par exemple être représenté par un modèle en étoile dans une base de données (notamment lorsqu'il s'agit de données brutes non agrégées). En quoi un Data Mart est-t-il différent d’un Data Warehouse ? Un Data Warehouse, contrairement à un Data Mart, traite des données de plusieurs domaines d’activités et est souvent contrôlé par une entité centrale au sein de l’organisation (par exemple la Direction des Systèmes d’Information). On parle alors de Data Warehouse central de l’entreprise. Il va tirer ses données de plusieurs sources à travers l’organisation et de ce fait être volumineux. Rien n’empêche un Data Mart d’être lui aussi complexe ou volumineux mais, ne cherchant pas à regrouper toutes les données de l’organisation mais plutôt à se spécialiser dans un domaine d’activité, il sera généralement moins volumineux qu’un Data Warehouse. Il peut aussi différer sur plusieurs caractéristiques comme sa granularité, son partitionnement de données, etc. Il est de ce fait plus facile à créer et maintenir que le Data Warehouse. Le tableau suivant présente les principales différences entre un Data Mart et un Data Warehouse. Tableau 3 : Principales différences entre un Data Warehouse et un Data Mart Catégorie Data Warehouse Data Mart Périmètre Toute l’organisation Par domaine d’activité Thèmes Plusieurs Un seul Sources de données Beaucoup Peu Taille (moyenne) 100 Go à plusieurs To < 100 Go Temps d’implémentation Plusieurs mois voire années Quelques mois Une autre des principales différences entre un Data Warehouse et un Data Mart vient du fait que lorsque le Data Mart est implémenté dans un environnement munis d’un Data Warehouse, il est souvent généré après celui-ci. C’est-à-dire qu’il tire ses sources de données du Data Warehouse (cf. partie « DataMarts dépendants et indépendants » ci-dessous). C’est alors là que la définition de Ralph Kimball prend tout son sens. Pourquoi développer un Data Mart ? Quelle en est la limite ? Le but premier d’un Data Mart est de regrouper de manière spécialisée les données d’un domaine d’activité de l’entreprise. Il va chercher les données liées aux applications métiers pour les regrouper dans une même base exhaustive et récapitulative. Par ce biais, il permet de classer et de clarifier les données pour les métiers. Chaque métier, appartenant au domaine d’activité choisi, aura ainsi accès aux données qui l’intéresse, sans être affecté par des données contiguës. C’est d’ailleurs de là que découle l’intérêt technique d’un Data Mart : délester les systèmes opérationnels d’où il tire ses données (Data Warehouse ou autres bases de données) des requêtes répétitives que ces
  23. 23. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 24 derniers subissent. Il est plus facile pour les utilisateurs et le système de gérer un Data Mart qui ne contient que l’essentiel de l’information car il est plus rapide à l’exécution et moins coûteux pour le SI. Le deuxième but, tout aussi important, est de fournir une base de qualité pour l’analyse et la construction d’indicateurs. Les données contenues dans le Data Mart sont généralement dans l’état le plus « pur » pour le secteur d’activité qui les utilise (c’est du moins ce qui est visé lors de la partie « Extractions et transformations »). De ce fait, il est possible de diffuser des rapports d’analyse pour le métier, et d’implémenter une partie qui regroupe tous les indicateurs et leur historique (cf. partie « Les indicateurs : une vision traitée et concise de l’information »). Mais le premier point de simplification présente certaines limites. Le fait de ne contenir que des données spécifiques à un domaine d’activité peut parfois entrainer des complications, notamment lorsqu’il s’agit de vouloir expliquer une problématique plus globale et que cela impose de sortir de son cadre d’analyse habituel. L’accès aux autres données est alors requis ce qui entraine des coûts de développement importants pour des requêtes éphémères. Le problème peut devenir encore plus grave lorsque les DataMarts ne constituent que l’unique accès aux données pour toute l’organisation. DataMarts dépendants et indépendants Comme introduit dans la définition, il existe deux types de Data Mart : les DataMarts dépendants et les DataMarts indépendants. La principale différence vient du mode d’importation des données : d’où et comment ?  « D’où ? » : Les DM dépendants prennent leurs données d’un Data Warehouse central qui est déjà construit. Tandis que les DM indépendants récoltent directement leurs données de systèmes opérationnels internes et/ou externes à l’entreprise.  « Comment ? » : L’ETL (Extraction-Transformation-Loading) mis en place pour déplacer les données est simplifié dans le cadre d’un DM dépendant car il a déjà eu lieu en tout ou partie lors du chargement des données dans le Data Warehouse. Le travail de la partie ETL est alors principalement de l’identification de données utiles pour le domaine d’activité du DM. Cependant, dans le cadre d’un DM indépendant, tout le processus ETL doit être mis en place lors du chargement des données. Puisque le DM traite un seul sujet, il prend ses données de sources moins nombreuses que le Data Warehouse, mais ceci n’empêche pas d’avoir un travail délicat à réaliser d’extraction, de transformation, de traitements automatisés et d’optimisation. Mais le mode d’importation des données n’est pas le seul point divergent entre les deux types de Data Mart. L’autre question qu’apporte cette différence est : pourquoi ?  Les DM dépendants sont généralement créés dans le but de fragmenter de Data Warehouse et ainsi d’assurer un meilleur contrôle et une réduction des coûts d’utilisation des données (cf. partie « Pourquoi développer un Data Mart ? Quelle en est la limite ? » ci-dessus).  La construction de DM indépendants est souvent motivée par un besoin d’obtenir une solution dans un délai court, par exemple lorsque le Data Warehouse n’est pas encore mis en place. Il peut aussi provenir d’une envie de contrôler complètement tout le processus du
  24. 24. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 25 Data Mart, notamment la partie d’extraction des données, normalement gérée en majeur partie par le Data Warehouse. Figure 1 : Schéma représentatif de DataMarts « dépendants » Figure 2 : Schéma représentatif de DataMarts « indépendants »
  25. 25. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 26 Implémentation : les étapes Design L’étape de Design est la première étape du processus d’implémentation d’un Data Mart. Elle couvre toute les tâches allant de de l’initiation de l’idée, au design des structures physiques et logiques. Elle comprend ainsi les tâches suivantes :  Mise en place du plan d’action dans le but d’énumérer le besoin, la fonctionnalité et la finalité du futur Data Mart : o Obtenir l’autorisation de la hiérarchie pour commencer d’étude. o Définir le périmètre du projet. Il détermine les limites du projet et doit souvent être pensé en fonction de l’organisation. Pour quel domaine d’activité ? o Identifier les risques (par exemple que le DM devienne vite obsolète). o Estimer les coûts (humains, techniques, risques) o Créer le planning projet (à l’aide de diagrammes de Gantt ou Pert par exemple) et prévoir les livrables qui valideront les différents phases du projet.  Définition des besoins fonctionnels et techniques : o Faire un recueil des besoins fonctionnels. Connaître en détail ce que l’utilisateur souhaite avoir pour ensuite définir les données qui seront importées et les indicateurs qui seront créés. Il s’agit de trouver un compromis entre détail, efficacité et budget. o Définir les outils techniques qui seront utilisés (software, langages informatiques, etc.) et les composants physiques pour la sauvegarde des données en estimant la taille du Data Mart (hardware, serveurs, etc.) o Obtenir l’accès aux environnements physiques qui permettront de matérialiser le Data Mart et d’y stocker les données.  Mise en place du Design : o Définir la liste des données qui seront importées et ainsi identifier les sources. o Choisir les méthodes de classification des données pour définir le schéma du Data Mart.  Modèle en étoile avec tables de faits + dimensions. (cf. Glossaire)  Ou modèle SGBD relationnelle. (cf. Glossaire) o Dans les deux cas, il faut détailler le schéma en définissant les tables qui seront créées, leurs liens entre elles, les données qu’elles contiendront, leurs métadonnées (cf. partie « Les métadonnées »), et la granularité (c’est-à-dire le niveau de détail du stockage des données). o Créer le design logique, c’est-à-dire le fonctionnement du DM dans sa globalité. Cette étape peut être réalisée par un diagramme de processus18 . Il est aussi possible de le compléter avec un pseudo-code (code compréhensible pour des non- informaticiens) dans le cas d’un DM développé sans l’aide d’un logiciel spécialisé. Le Design est l’étape la plus importante car il définit la structure et les fonctions principales du Data Mart. Un Data Mart bien pensé est un Data Mart qui sera efficient et évolutif. Cette étape reste généralement en parallèle de toutes les autres phases de l’implémentation car le design peut avoir besoin d’être modifié à tout stade du projet. 18 Un diagramme de processus est un schéma destiné à représenter le processus dans son ensemble avec un enchaînement d’états et de fonctions. Cf. Figure 3
  26. 26. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 27 Construction La phase de construction n’est autre que l’acquisition du support physique et le développement de la structure du Data Mart. Que ce soit par le biais d’outils intégrés directement dans un logiciel BI ou par une méthode personnalisée, le but est de :  Créer la base de données physique du Data Mart, les structures de stockage etc. Par exemple, utiliser les logiciels comme SQL Server, MySQL…  Créer les schémas des objets comme les tables ou les interfaces. Référencer les schémas et en faire des schémas génériques, réutilisables pour une future automatisation. Extractions et transformations Cette partie appelée « ETL » (Extract-Transform-Load) consiste à importer, filtrer, transformer (mettre dans le bon format), calculer (concaténer, agréger, additionner…) et charger les données dans le Data Mart. C’est un travail qui peut être réalisé de nombreuses manières différentes. Certains logiciels intègrent directement l’outil, mais il est aussi possible d’utiliser des solutions ETL indépendantes. Encore une fois, lorsque la solution est développée « à la main », il est possible de créer son propre ETL via des langages de gestion de données (SQL, SAS…). Les étapes d’un ETL à mettre en place sont :  L’extraction des données : créer les liens vers les bases de données et développer les requêtes nécessaires.  Le « mapping » des données sources vers les données cibles : quelles données sources vont permettre d’alimenter quelles données cibles ?  Filtrer et transformer les données : définir les nouveaux formats des données, implémenter les données calculées, ne garder que l’information utile.  Générer les métadonnées associées aux données cibles du Data Mart.  Charger les données dans l’environnement du Data Mart, en cohérence avec les schémas développés précédemment. Calcul des indicateurs (optionnel) Mettre à disposition des indicateurs dans un Data Mart apporte une forte valeur ajoutée au projet. Le but étant d’apporter des chiffres et ratios permettant une évaluation rapide de l’activité du métier (cf. partie « Les indicateurs : une vision traitée et concise de l’information »). Une fois que la partie ETL est effectuée, il est possible de mettre en place ce système. Il faut alors suivre les étapes suivantes :  Reprendre les besoins énoncés dans la partie Design concernant les indicateurs. S’assurer que la liste est exhaustive.  Définir en détail les méthodes de calculs et les codes qui y sont affectés.  Regrouper les indicateurs par métier et ainsi créer les axes d’analyse. Les axes d’analyse définissent les critères d’agrégation des indicateurs (cf. partie « Erreur ! Source du renvoi ntrouvable. »). Ils sont ce qui permet d’encadrer l’indicateur et de lui donner son sens.
  27. 27. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 28 Recette La recette est la phase de test du Data Mart. Elle permet d’assurer la cohérence et la validité des données et indicateurs qui y sont présents. Pour ce faire, une méthode simple et efficace consiste à fournir des lots de données et d’indicateurs aux acteurs métiers, qui sont censés valider les résultats fournis avec ce qu’il observe réellement sur les applications. Durant cette phase il est possible de revoir tout ou partie du Data Mart en passant par les étapes suivantes :  Recette technique : est-ce-que tout le processus fonctionne sans bug informatique ?  Recette fonctionnelle : o Le spectre de données est-il complet ? o Le support physique réservé sera-t-il suffisant à long terme ? o Les données sont-elles correctes ? Si non, est-ce le processus ETL qui est défaillant ? o Les indicateurs reflètent-ils la réalité ? Si non, revoir les définitions avec le métier, les méthodes de calculs et d’agrégation. o Etc. Tout le processus technique doit être balayé et toutes les données et indicateurs doivent être validés. Ceci permet de passer le Data Mart en production et de faire aboutir la première grande partie du projet. Accès et diffusion Il existe deux types d’accès aux données : 1. L’accès direct via un identifiant à renseigner dans une interface de connexion par exemple. L’utilisateur peut alors naviguer à travers les données en fonction de ses droits. Par vulgarisation on appellera cela un « accès ». 2. Et l’accès indirect comme par exemple la diffusion et la publication de reportings. Ces derniers sont utilisés pour les requêtes périodiques qui nécessitent l’affichage d’un rapport avec souvent plusieurs informations, des graphiques, etc. (cf. Glossaire). La phase d’accès et de diffusion implique théoriquement que la phase de recette soit validée. En réalité, les premiers accès et premières publications se font pendant la phase de recette. On parle « d’accès en environnement de recette » : les acteurs métiers qui sont mobilisés pour la phase de recette obtiennent des accès provisoires et reçoivent des publications de test. Dans tous les cas, il est recommandé de suivre les étapes suivantes :  Instaurer un système de « labels » pour rendre les informations du Data Mart compréhensible pour un utilisateur métier (labels de bases, de données et d’indicateurs). Prenons une donnée dans le domaine du crédit bancaire dont l’identifiant est « str11 ». Il faut par exemple lui attribuer le label « situation comptable » pour qu’elle devienne identifiable et compréhensible. Ce processus est facilement réalisable via la gestion des métadonnées puisque le label est une métadonnée.  Créer et distribuer les accès aux interfaces pour les utilisateurs métiers.  Définir les diffusions qui seront faites : les reportings. Créer les requêtes, les calculs, les templates associés, etc. Pour le dernier point, les logiciels BI (exemple SAS Information MAP) sont très efficaces car ils proposent un « tout en un » en partant des requêtes jusqu’à l’édition des reportings dans le format voulu (Web, Excel, CSV, etc.).
  28. 28. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 29 Automatisation L’automatisation présente enfin la dernière phase cruciale dans le développement d’un Data Mart. Comme décrit dans la partie « L’automatisation du traitement de données », c’est un investissement avant tout. L’automatisation nécessite des ressources (humaines et financières) mais son utilité est double : accélérer et consolider les processus qui y sont soumis. Un processus automatisé est un processus rapide et informatiquement stable qui laisse peu de place à l’erreur humaine. Pour un Data Mart, tout son traitement, que ce soit de l’extraction des données jusqu’à l’édition des reportings, est automatisable. Un Data Mart automatisé est un Data Mart efficace et durable. Encore une fois, les solutions apportées par les logiciels spécialisés sont intuitives donc relativement faciles à mettre en œuvre, tandis que pour un Data Mart personnalisé cette phase est plus délicate et très chronophage. Pour obtenir une automatisation complète, par exemple pour faire en sorte que le Data Mart se lance tout seul la nuit, il est possible d’utiliser une méthode très répandue : le batch processing (traitement par lots, cf. Glossaire). Maintenance Finalement, lorsque tout le système est mis en place il faut en assurer la maintenance, ce qui implique :  Un accès sécurisé aux données, en accords avec les accès déjà mis en place sur les systèmes opérationnels d’où le Data Mart tire ses sources.  Contrôler l’évolution de l’espace de stockage.  Assurer la disponibilité des données même lorsque le système tombe en panne. Par exemple par des systèmes de bases de Back-Up, archives consultables sur demande.  Et optimiser le système pour des meilleures performances. Optimisation Le dernier point relatif à la maintenance du Data Mart est très rarement diffusé auprès du public. C’est pourquoi il est délicat de donner des exemples concrets de cette partie, alors qu’elle joue un rôle crucial dans l’efficacité et la disponibilité du Data Mart. Il existe deux niveaux d’optimisation : 1. L’optimisation de l’impact du Data Mart sur l’existant : Il va de soi qu’un DM qui met 20h à tourner tous les jours n’est pas un DM de très bonne qualité. Mais en prenant un exemple plus concret : un DM qui met 6h à tourner la nuit n’est pas forcément très optimisé non plus car il encombre les bases de données qu’il requête pendant un long moment, tandis que celles-ci sont sollicitées par d’autres processus. Le but de ce niveau d’optimisation est donc d’accélérer la mise à jour quotidienne, hebdomadaire, ou mensuelle du DM. Elle permet aussi d’assurer l’évolutivité de la partie ETL. 2. L’optimisation du Data Mart en lui-même : Puisqu’un Data Mart est avant tout conçu pour subir des requêtes de plusieurs utilisateurs, il est important qu’il dégage une sensation de rapidité lors de son utilisation. Pour cela, il est notamment possible de passer par des techniques d’indexage et de pré-calcul des données comme les indicateurs.
  29. 29. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 30 Ce niveau d’optimisation requiert aussi une très bonne qualité de données (cf. partie « Qualité de données »). Il est important de mettre en place un bon système de dédoublonnage car une Unicité défaillante entraîne des indicateurs biaisés. D’une manière générale plus les aspects techniques seront intégrés en amont du projet de création du Data Mart, plus sa maintenance et son évolution seront aisées et moins coûteuses. Comme tout projet d’industrialisation, l’arbitrage entre le coût d’investissement et le coût de maintenance sera un élément clé de pérennité et de réussite.
  30. 30. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 31 HYPOTHESES ET CADRE DE L’ETUDE Cette partie permet d’identifier les différentes hypothèses possibles en termes d’organisation, d’environnement, de besoin, de résultat souhaité et d’outils utilisés. L’entreprise L’organisation dans laquelle on développe un Data Mart peut être de n’importe quel type. Par exemple, on peut très bien vouloir le développer dans le secteur Bancaire comme dans le secteur de l’Industrie. Le seul prérequis vient de la taille des données générées qui doit être grande (de l’ordre de plusieurs centaines de Mo19 par jour). Un Data Mart dans une petite organisation sera généralement trop coûteux par rapport au bénéfice dégagé : puisqu’il doit couvrir un secteur d’activité spécifique, si ce secteur génère peu de données alors son utilité devient très limitée. Si l’entreprise, petite ou grande, a un découpage par domaine d’activité bien défini et que ceux-ci génèrent un grand nombre de données, alors il est recommandé de procéder à l’implémentation du Data Mart. Ce DM doit être géré par une équipe d’aide à la décision spécialisée et non pas par les acteurs métiers directement. C’est dans ces hypothèses là que nous nous basons. Type de Data Mart Le type de Data Mart peut être dépendant ou indépendant, ceci n’influe pas vraiment sur sa finalité. La modification se fera au niveau de l’extraction et de la transformation. Un Data Mart dépendant, qui tire ses sources d’un Data Warehouse, aura moins d’extractions et de transformations à faire qu’un Data Mart indépendant. Lors de la méthode proposée dans la section suivante, nous n’expliquons pas un cas en particulier. Les deux types de Data Mart (dépendants et indépendants) dont identifiables dans notre méthode. Taille et complexité des données Le système de données initial doit avoir un certain niveau de complexité. On part du principe que le Data Mart va interroger plusieurs tables dont la taille est de plusieurs Go20 . Ces tables suivent généralement le modèle de bases de données relationnelles, et des fichiers plats peuvent s’y ajouter (cf. partie « DataMarts dépendants et indépendants »). De ce fait, on peut soit se connecter à un Data Warehouse existant, soit être indépendant. En qualité de données il y a 3 niveaux d’hypothèses identifiables : 1. Indispensable car insolvable par la Data Mart : Complétude, Exactitude 2. Complexe à résoudre : Unicité (pas de champs discriminants), Intégrité 3. Facile à résoudre : Unicité (présence de champs discriminants), Conformité, Cohérence 19 « Mo » veut dire « Méga octects ». Les octets sont l’unité de mesure de la taille d’un élément informatique. Ils déterminent ce que l’élément va réquisitionner comme mémoire (sur le disque dur par exemple). 1 Mo = 1 000 000 octets. 20 « Go » = « Giga octects » = 1 000 Mo.
  31. 31. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 32 Autrement dit, si les données que l’on extrait à l’aide du Data Mart ne sont ni complètes ni exactes, il nous serait impossible de les corriger dans ce processus et elles influeraient négativement sur les résultats. Généralement, les qualités qui sont toujours vérifiées sont l’exactitude, la complétude et l’intégrité (cf partie « Qualité de données »). Les qualités qui seront traitées dans notre étude sont l’unicité (doublons) et la conformité (format). Environnement de développement L’environnement se divise en deux types :  L’environnement physique.  Et l’environnement logique. L’environnement physique qui accueil notre Data Mart doit être un serveur ayant une mémoire suffisante pour la taille maximum du DM sous 1 an. Bien entendu, des accès de lecture, d’écriture et d’exécution doivent être fournis par le service informatique pour ce serveur. L’environnement logique quant à lui peut être polyvalent. Pour les données du Data Mart il est possible de les conserver dans un SGBD ou dans un système d’environnement de dossiers. Pour ce qui est des résultats (reportings, processus d’analyses, etc.) il est recommandé de les stocker dans un environnement de dossiers, mais il est aussi possibles de les sauvegarder dans des bases de données (ce qui donne des données « non structurées », cf. partie « La donnée »). Ces hypothèses-là sont donc flexibles. Dans notre cas on se basera exclusivement dans un système de gestion de dossiers (répertoires) avec des bases de données mobiles (qui ne sont pas soumises à un SGBD type « MySQL », « SQL Server », etc.). Outils utilisés L’hypothèse maitresse de ce mémoire vient du fait que nous souhaitons développer un Data Mart sans l’aide de logiciel spécialisé. C’est-à-dire que les outils qui sont utilisés ne sont pas des solutions intégrées (par exemples des logiciels BI comme Talend, Cognos, etc.). Dans notre expérience, nous utiliserons trois langages informatiques (UNIX, SQL, SAS) et un logiciel (Excel) :  Pour la gestion de l’environnement physique et le lancement automatique : UNIX.  Pour les transferts de données : SQL.  Pour le traitement des données : SAS, SQL.  Pour la gestion des reportings : SAS, Excel. Ces langages et logiciels fonctionnent très bien ensemble mais sont donnés à titre d’exemple. D’une manière générale il faut que ceux qu’on choisit puissent remplir les 4 fonctions énoncés ci-dessus.
  32. 32. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 33 Résultats souhaités et accès aux données Les résultats que doit fournir le Data Mart sont donnés par le métier du domaine d’activité. C’est donc une phase de recueil de besoin qui déterminera les résultats souhaités. Dans notre cas, nous faisons l’hypothèse que les besoins du métier sont d’obtenir des reportings d’indicateurs et de listes de données, à une fréquence définie (notamment mensuelle). Les accès aux bases de données du Data Mart seront réservés à l’équipe d’aide à la décision qui le développe et l’utilise pour la génération des rapports. Résumé Les hypothèses sur lesquelles se base notre étude sont les suivantes :  Entreprise : les secteurs d’activité sont clairement définis et ils produisent un grand nombre de données quotidiennement.  Gestion du Data Mart : faite par une équipe d’aide à la décision spécialisée.  Type de Data Mart : indépendant puis dépendant.  Taille des données : plusieurs Go de données sont utilisées.  Modèle de données et qualité : les données sont relationnelles, et elles vérifient l’exactitude, la complétude, la conformité et l’intégrité. Une table globale regroupant toutes les données est créée pour faciliter les calculs.  L’environnement physique : un serveur pouvant stocker plusieurs Go.  L’environnement logique : système de répertoires avec bases de données mobiles.  Outils utilisés : pas de logiciel avec solutions intégrées. Langages SQL, UNIX et SAS. Logiciel Excel.  Automatisation : réalisée car définie comme indispensable.  Résultats souhaités : indicateurs et listes de données.  Accès aux données : réservés à l’équipe d’aide à la décision qui gère le Data Mart. Diffusion des résultats sous forme de reportings.
  33. 33. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 34 METHODE Cette partie propose une méthode de résolution de la problématique. Elle permet d’expliquer ce qui a été mis en œuvre de manière logique et pratique. Première phase : plan d’action et recueil des besoins Pour cette première phase nous partons du principe que l’autorisation de la hiérarchie a déjà été obtenue. Mise en place du plan d’action Définition du périmètre Le lancement du projet Data Mart commence par la définition du périmètre qu’il va couvrir au sein du secteur d’activité. Il faut « faire passer le message » aux acteurs métiers et leur faire savoir qu’un Data Mart va être créé. De ce fait, ils pourront dire s’ils souhaitent faire partie du projet ou non. Par exemple, dans le domaine du crédit bancaire, le secteur d’activité « Recouvrement » peut être subdivisé en plusieurs pôles : « recouvrement amiable », « recouvrement judiciaire », « surendettement », etc. Il s’agit de définir lesquels seront effectivement inclut dans le Data Mart « recouvrement ». Bien entendu, il est toujours possible d’inclure de nouveaux pôles ultérieurement, lorsque le Data Mart sera mis en production et évolutif, mais le but ici est de définir les limites initiales du projet. Pour mener à bien cette partie, des réunions collectives pour présenter le projet dans sa globalité ont été réalisées auprès des équipes métiers. Nous nous sommes rendu compte que le métier était très intéressé et qu’il introduisait d’ailleurs l’étape de « Recueil des besoins fonctionnels » pendant ces réunions, impatient de connaître les fonctions et les résultats du Data Mart. Définition des acteurs Après le périmètre fonctionnel vient le périmètre organisationnel. Il faut définir quels seront les acteurs qui participeront au projet en allant du chef de projet aux développeurs, en passant par les acteurs métiers qui interviennent lors du recueil des besoins, de la préparation des reportings et de la validation de la recette. Dans notre cas, le projet a été construit et mené à l’aide d’un chef de projet, de deux développeurs, de deux « recetteurs », et d’un grand nombre d’acteurs métiers. Planning projet Pour cette partie du projet il s’agit de définir le planning du projet, allant du recueil des besoins à la mise en production. En fonction du périmètre et des acteurs actifs sur le projet, un diagramme de
  34. 34. Mémoire - Développer, Automatiser et Optimiser un Data Mart - Julien Diennet - Septembre 2014 35 Gantt21 a été créé. Il a bien évidemment été revu tout au long du projet en fonction des avancements et des imprévus. L’ordre des tâches a suivi le plan de la « Méthode ». Recueil des besoins fonctionnels et techniques Recueil des besoins fonctionnels Le recueil des besoins fonctionnels est une partie très importante du projet. Elle consiste à déterminer ce dont le métier aura besoin à l’aide du Data Mart, et donc ce qui devra être développé. Pour ce faire, nous avons passé des entretiens avec chaque manager de chaque pôle inclut dans le périmètre, ainsi qu’avec la direction. La première réunion avec la direction nous a permis de guider les autres réunions avec les opérationnels. Nous avons posé les questions et reçu les besoins suivants :  Questions à la direction : o Quelle utilité doit remplir le Data Mart ? o A quelle fréquence est souhaitée la mise à jour des données ?  Besoins de la direction : o Regrouper les données dans un référentiel unique o Mise à jour à chaque début de mois pour avoir la « photo fin de mois » du mois passé o Historique des mois passés par le stockage des anciennes bases  Questions au métier : o Que doit fournir le Data Mart ? o Sous quelle forme ? o Souhaitez-vous des accès directs aux données ?  Besoins du métier : o Des indicateurs de performances à chaque début de mois, sur l’activité du mois passé. Ces indicateurs doivent pouvoir être fragmentés par axes d’analyse. o Des listes de données spécifiques permettant d’avoir l’essentiel des détails de l’activité du mois passé. o Obtenir ces résultats sous forme de reportings via Excel, dont la forme sera discutée ultérieurement. o Certains accès aux données du Data Mart par des acteurs ayant des connaissances techniques. A la fin de chaque réunion il est important de faire un compte rendu (par exemple par mail) en définissant un secrétaire de séance au début de la réunion et qui est chargé de prendre les notes. Un tel procédé permet de récapituler et dater ce qui a été dit. L’information est alors retrouvable et traçable. Définition des outils techniques Ici nous souhaitons connaître avec quels outils nous allons travailler. Sachant que notre projet ne se base pas sur un logiciel avec solution intégrée, il faut choisir des langages de programmations et des 21 Un diagramme de Gantt est un type de diagramme qui permet de représenter, suivant un axe temporelle, les étapes qui devront être réalisées. Ainsi, la liste des étapes est dressée et leur ordre d’exécution est spécifié.

×