Étude sur la mise en œuvre d'un entrepôt de données et conception d'un prototype en vue d'une intégration au sein de France Billet



3$5,6

0(02,5(

3UpVHQWpHQYXHGREWHQLU

OH',3/20(G,1*(1,(85&1$0

63(&,$/,7(,1)250$7,48(

237,21$5&+,7(&785((7,1*(1,(5,('(66<67(0(6(7

'(6/2*,&,(/6

3DU

%5,270LFKDsO

(WXGHVXUODPLVHHQ°XYUHG¶XQHQWUHS{WGHGRQQpHVHW

FRQFHSWLRQG¶XQSURWRW\SHHQYXHG¶XQHLQWpJUDWLRQDXVHLQ

GH)UDQFH%LOOHW



6RXWHQXOHPDUV

2

Résumé

France Billet, filiale du groupe Fnac est le leader de la distribution de spectacles en France. La direction des systèmes d’informations de l’entreprise, qui utilise traditionnellement des outils open sources, a mis en place en 2011 une solution décisionnelle basée autour d’un produit propriétaire ayant pour avantage de proposer une solution tout en un, permettant une réduction des coûts de mise en place. La solution a été victime de son succès auprès des utilisateurs ; de nouveaux besoins sont nés, dévoilant les limites en termes d’évolutivité du jeune système d’informations décisionnel de l’entreprise. Le but de l’étude réalisée dans ce mémoire est de proposer une amélioration du système existant et de démontrer l’intérêt pour l’entreprise d’acquérir un outil d’intégration de données et de construire un entrepôt de données ouvert. Un prototype a été réalisé afin de valider la faisabilité de la solution proposée.

Mots clés : Décisionnel, E.T.L., Entrepôt de données, Modélisation dimensionnelle.

Summary

France Billet is a subsidiary of Fnac’s group and is the leader of ticketing in France. The information technology service of the company, who traditionally uses open source tools, has implemented in 2011 a BI solution based around a proprietary product with the advantage of being an all in one solution that allows to reduce implementation costs. The BI’s solution was very successful with users ; new needs have emerged, revealing the scalability’s limits of the young’s BI’s information system of the company.

The purpose of the study in this document is to propose an improvement of the existing system and demonstrate interest for company to acquire an E.T.L. tool and build an open data warehouse. A prototype was made to validate the feasibility of the solution.

3

Je tiens d’abord à remercier mon entreprise, pour avoir accepté de me

confier cette étude que j’ai menée dans le cadre de ce mémoire.

J’exprime ma reconnaissance à Sophie Toqueboeuf, chef de projet

M.O.A. chez France Billet pour avoir accepté de m’accompagner durant le

déroulement de cette étude, pour ses recommandations et son assistance.

Je remercie Monsieur Yves Laloum, professeur associé au C.N.A.M., pour

avoir accepté de suivre ce mémoire, pour ses enseignements et ses précieux

conseils.

Je remercie également la D.O.S.I. Fnac ainsi que les entreprises Eulidia,

Genicorp et Ysance qui ont accepté d’échanger autour de cette étude.

J’adresse également mes remerciements à l’ensemble des enseignants

du C.N.A.M. qui m’ont accompagné durant le cycle d’ingénieur que j’ai suivi.

Un grand merci à ma famille et à mes proches pour leurs

encouragements et leur soutien tout au long de mon cycle d’enseignement au

C.N.A.M.

4

Table des illustrations ... 7

Glossaire ... 9 1. Introduction ... 11 1.1. Présentation de l’entreprise : ... 11 1.2. Présentation de la DSI : ... 13 1.3. Contexte du projet : ... 14 1.4. Objectif du projet : ... 15 1.5. Démarche de travail : ... 16 1.6. Déroulement du projet : ... 17

2. Etat de l’art des SI décisionnels ... 18

2.1. Les systèmes décisionnels : ... 18

2.2. Architecture d’un système décisionnel : ... 20

2.3. Les entrepôts de données : ... 21

2.4. Les bases de données pour le décisionnel : ... 24

2.5. Principes de la modélisation dimensionnelle : ... 27

2.6. Systèmes d’Extraction-Transformation-Chargement : ... 30

2.6.1. Le processus d’extraction : ... 31

2.6.2. Le processus de transformation : ... 32

2.6.3. Le processus de chargement : ... 33

2.6.4. Les différents types d’E.T.L. : ... 34

2.6.4.1. L’E.T.L. moteur : ... 34

2.6.4.2. L’E.L.T. utilisant les moteurs des bases de données : ... 34

2.6.4.3. L’E.T.L. générateur de code : ... 35

2.6.5. L’évolution des systèmes d’E.T.L. : ... 35

2.7. L’outil de restitution QlikView : ... 37

2.7.1. Script de chargement : ... 38

2.7.2. Base de données associative : ... 40

2.7.3. Interface graphique de restitution : ... 41

2.7.4. Bilan de l’outil : ... 42

2.8. Vers de nouveaux modèles de construction : ... 43

3. Etat de l’existant ... 44

3.1. Analyse du système décisionnel : ... 44

3.2. Architecture applicative : ... 47

5

3.2.4. Accès aux applications : ... 52

3.2.5. Administration : ... 52

3.3. Architecture technique : ... 53

3.4. Phase d’alimentation: ... 55

3.5. Bilan de la solution : ... 56

4. Analyse des besoins ... 57

4.1. La gestion de la relation client (CRM) : ... 57

4.2. Amélioration de la disponibilité : ... 59

4.2.1. Principes de sureté de fonctionnement : ... 59

4.2.2. Principe des systèmes à haute disponibilité : ... 59

4.2.3. Etat des lieux de la disponibilité du système : ... 61

4.3. L’entrepôt de données : ... 63

4.3.1. Outil d’E.T.L. : ... 64

4.4. Synthèse de l’analyse des besoins : ... 65

4.5. Cahier des charges: ... 67

4.5.1. Cahier des charges pour l’outil d’E.T.L. : ... 69

4.5.2. Cahier des charges pour le S.G.B.D. : ... 70

5. Etude et test des outils ... 71

5.1. Choix d’un outil d’intégration de données : ... 71

5.1.1. Pentaho Data Integration : ... 72

5.1.2. Talend Open Studio : ... 74

5.1.3. Comparatif et choix : ... 76

5.2. Choix du système de gestion de base de données : ... 78

5.2.1. MySQL : ... 78

5.2.2. Infobright : ... 80

5.2.3. Comparatif et choix : ... 81

5.3. Logiciels composant le système : ... 82

6. Conception du prototype ... 83 6.1. Introduction: ... 83 6.1.1. Environnement de développement : ... 84 6.1.2. Mode opératoire : ... 85 6.2. Modélisation dimensionnelle : ... 86 6.2.1. Conception logique : ... 86

6

6.3.2. Conception des dimensions : ... 93

6.3.2.1. Cas de la dimension contrôle : ... 93

6.3.2.2. Cas d’une dimension simple, la dimension temps : ... 94

6.3.2.3. Cas d’une dimension complexe, la dimension manifestation : ... 96

6.3.2.4. Cas d’une dimension changeante, la dimension vendeur : ... 97

6.3.3. Table des faits : ... 98

6.3.4. Modes de mise à jour : ... 100

6.3.5. Déploiement et automatisation du chargement : ... 101

6.4. Application de restitution pilote : ... 102

6.5. Bilan du prototype : ... 103

6.5.1. Déploiement : ... 103

6.5.2. Dimensionnement : ... 103

6.5.3. Sauvegarde et reprise sur incident: ... 104

6.5.4. Conduite du changement : ... 104

7. Bilan de l’étude... 105

7.1. Conduite de projet et coût de mise en place : ... 105

7.2. Résultat de l’étude : ... 106

7.3. Propositions d’architecture technique : ... 108

7.3.1. Proposition n°1 : utiliser le serveur B.I. ... 108

7.3.2. Proposition n°2 : solution à deux serveurs. ... 109

7.3.3. Proposition n°3 : mutualiser les serveurs BDD existants ... 110

7.3.4. Comparatif des différentes propositions : ... 111

7.4. Conclusion de l’étude : ... 111

7.5. Présentation à l’entreprise : ... 112

8. Conclusion ... 113

Bibliographie ... 114

Annexe 1 : Chartre d’utilisation de Talend Open Studio ... 115

7

Figure 1: Site internet fnacspectacles.com ... 11

Figure 2: Organigramme de France Billet ... 12

Figure 3: Organigramme de la D.S.I. ... 13

Figure 4: Niveaux de maturité d'un système décisionnel ... 19

Figure 5: Architecture à trois niveaux ... 20

Figure 6: Un entrepôt de données ... 22

Figure 7: Orientation en ligne et en colonne ... 25

Figure 8: Représentation d'un cube ... 26

Figure 9: Exemple de modélisation en étoile ... 27

Figure 10: Représentation d'un E.T.L. ... 30

Figure 11: Représentation d’une application Qlikview ... 38

Figure 12: Script de chargement ... 39

Figure 13: Base de données associative ... 40

Figure 14: Interface graphique de restitution ... 41

Figure 15: Positionnement du SI décisionnel ... 44

Figure 16: Cas d'utilisation du système décisionnel ... 46

Figure 17: Architecture applicative du système existant ... 47

Figure 18: Cas d'utilisation d’une application ... 50

Figure 19: Application de suivi pour les acheteurs ... 51

Figure 20: Architecture technique du système existant ... 53

Figure 21: Vérification préalable à l'alimentation du socle de données ... 55

Figure 22: Liste des défaillances éventuelles du système décisionnel ... 61

Figure 23: Diagramme de structure logique du système ... 66

Figure 24: Architecture logicielle cible ... 67

Figure 25: Phase de migration, coexistence des deux versions du système ... 68

Figure 26: Interface graphique de Pentaho Data Integration ... 72

Figure 27: Interface graphique de Talend Open Studio ... 74

Figure 28: Comparatif des outils d’E.T.L... 76

Figure 29: Grille de connaissance ... 80

8

Figure 33: Modélisation dimensionnelle ... 86

Figure 34: Chargement de données en masse sous Talend ... 92

Figure 35: Traitement de la dimension contrôle ... 93

Figure 36: Composant de génération de ligne ... 94

Figure 37: Mappage de la date... 94

Figure 38: Traitement peuplement dimension temps ... 95

Figure 39: Peuplement dimension manifestation ... 96

Figure 40: Composant adapté aux dimensions changeantes ... 97

Figure 41 : Affectation des clés subrogées avant peuplement de la table des faits ... 98

Figure 42: Peuplement table des faits ... 99

Figure 43: Déploiement d'un traitement ... 101

Figure 44: Charge de l'étude ... 105

Figure 45: Comparatif des systèmes décisionnels ... 107

Figure 46: Proposition n°1 utilisation du serveur B.I. ... 108

Figure 47: Proposition n°2 achat d'un nouveau serveur ...Erreur ! Signet non défini. Figure 48: Proposition n°3 mutualiser les serveurs B.D.D. du S.I. opérationnel ... 110

9

A.C.I.D. : Atomicité, cohérence, isolation, durabilité, il s’agit d’une norme de traitement

transactionnelle assurant que chaque transaction soit traitée de façon atomique, cohérente, isolée et durable.

Agrégat : Réunion d’un ensemble d’éléments hétérogènes. En base de données de

nombreuses fonctions permettent de fournir un agrégat à partir d’un ensemble de valeurs, par exemple la somme ou encore la moyenne.

B.I. : De l’anglais « business intelligence » communément utilisé pour désigner

l’informatique décisionnelle

Cluster : Groupe de systèmes informatiques indépendants interconnectés permettant

d’obtenir une plus grande puissance de traitement et une meilleure fiabilité de l’ensemble du système.

Contrôleur de domaine : Il s’agit du serveur gérant les authentifications sur un domaine en

centralisant l’ensemble des utilisateurs ainsi que leur habilitation.

Cube : Structure de stockage d’un ensemble de données multidimensionnel offrant des

temps de réponse rapide.

Dimension : Axe d’analyse permettant d’étudier les faits.

E.A.I. : En anglais « enterprise application integration », il s’agit d’une architecture

intergicielle (middleware) permettant à des applications hétérogènes de gérer leurs échanges en temps réel, typiquement utilisé pour mettre en œuvre l’urbanisation du système d’information.

E.L.T. : Extraction, chargement, transformation pour désigner les processus d’intégrations de

données utilisant le moteur des bases de données

E.T.L. : Désigne l’extraction, transformation, chargement appelé aussi intégration de

données désignant la synchronisation massive d’informations.

Fail fast : Principe de conception de système à haute disponibilité impliquant à tout module

défaillant un échec immédiat afin que les modules corrects puissent assurer la fourniture du service.

Fait : Mesure correspondant à l’activité à analyser.

I.T.I.L. : Ensemble de normes de bonne pratique de gouvernance des systèmes

d’informations.

LDAP : Protocole de communication permettant l’interrogation et la modification d’un

10

Mappage : Dérivé de l’anglais mapping. Il s’agit d’un procédé consistant à convertir les

données codées dans un format en un autre format. Ce procédé est très utilisé par les outils d’E.T.L. pour déplacer des données d’un système source vers un système cible.

Open source : Signifiant source ouverte en français, cette notion comprend les logiciels qui

ont un code source ouvert, c’est-à-dire consultable librement. Il existe de nombreuses licences permettant de fixer les usages. Il peut par exemple être possible de redistribuer librement le logiciel, de le modifier ou même de le vendre. La licence la plus connue est la GPL (General Public License). Elle est utilisée pour la majeure partie des projets Open Source. Elle permet de consulter, modifier et redistribuer le travail mais interdit de rediffuser le produit à des fins commerciales.

O.L.A.P. : Désigne le traitement analytique en ligne couramment utilisé en informatique

décisionnelle.

O.L.T.P. : Désigne le traitement transactionnel en ligne utilisé dans les activités

opérationnelles par exemple la vente de billets.

Point de défaillance unique : SPOF (Single Point Of Failure) est, au sein d’un système, un

élément dont la défaillance entraîne immédiatement le défaut de tout le système. Des exemples de points de défaillances uniques sont le système d’alimentation électrique pour un système ne disposant pas d’une alimentation électrique secourue ou le système d’exploitation pour un seul serveur.

P.R.A. : Plan de reprise d’activité dont la finalité est de restituer les moyens informatiques

permettant à l’entreprise d’assurer ses activités critiques en cas de sinistre.

RAID : Désigne les techniques permettant de répartir les données sur plusieurs disques durs

permettant par exemple d’améliorer les performances avec une répartition entrelacée (RAID 0) ou d’améliorer la tolérance aux pannes avec une répartition en miroir (RAID 1).

Reporting : Dans le cadre de cette étude, désigne l’activité qui consiste à rendre compte

périodiquement des performances de l’entreprise. Désigne les différents documents, interfaces et tableaux de bords permettant de suivre différentes activités de l’entreprise. Par exemple, le résultat de vente d’une opération commerciale, le chiffre d’affaire mensuel …

S.G.B.D. : Désigne le système de gestion de base de données qui est un ensemble de logiciels

permettant de manipuler les bases de données en masquant la complexité des opérations.

S.P.O.F. : Point de défaillance unique entrainant un risque pour la stabilité du système. Versionning : En français contrôle de version. Processus permettant de conserver une trace

des modifications successives apportées à un fichier numérique au travers d’un logiciel spécialisé. Il est ainsi possible de retrouver des données effacées, mais aussi d’effectuer diverses manipulations telles qu’obtenir la différence entre deux versions d’un même fichier.

11

1. Introduction

1.1.

Présentation de l’entreprise :

France Billet, filiale du groupe Fnac, est le premier réseau de distribution de billetterie en France avec plus de 14 millions de billets vendus en 2011. L’entreprise dispose également du premier catalogue en France avec plus de 60 000 manifestations couvrant des domaines variés de loisirs et de culture, entre autres : musique actuelle ou classique, opéra, théâtre, humour, parc de loisirs et de tourismes, musées et expositions, festivals, sport, cinéma, salons et foires.

Le réseau de vente est composé de plus de 700 points de ventes issus de différentes enseignes (Fnac, Carrefour, Géant Casino, Système U, Intermarché, Offices de tourismes, Comités d’entreprises …) et est présent dans trois pays : en France, en Belgique et en Suisse. La vente à distance complète le réseau physique : France Billet vend via son plateau téléphonique, via de nombreux sites internet tels que fnacspectacles.com, francebillet.com... et également via des applications pour les terminaux mobiles.

Figure 1: Site internet fnacspectacles.com

Le chiffre d’affaires « encaissé client » de France Billet s’est élevé à 419,25 millions d’euros en 2011.

12 L’organigramme ci-dessous détaille les différents services de l’organisation qui est composée d’une centaine de salariés.

Direction Vente Marketing Internet et mobile Point de vente Plateau Téléphonique Back Office Vente / Hotline / Suivi Billeterie Commercialisation Gestion D.S.I. Production Etude et développement M.O.A et support fonctionnel Finance Comptabilité Ressources humaines

Figure 2: Organigramme de France Billet

Le système informatique est compatible avec tous les systèmes de billetterie et de contrôle

d’accès de France. Il est développé en « propre » par l’entreprise et est composé

essentiellement de logiciels libres (système d’exploitation Linux, base de données MySQL, serveur d’application JBoss, serveur web Apache et environnement de développement Java). Ce choix permet d’offrir des avantages en termes de coûts et de flexibilité vis-à-vis de la politique d’un éditeur qui est plus standard, France Billet nécessitant des spécificités propres aux activités de l’entreprise.

Le système informatique gère de nombreuses fonctions : interfaçage avec de nombreux systèmes tiers (systèmes de gestion de salles de concert, de stades, chargés de commercialisations…), suivant les événements France Billet peut jouer un rôle de commercialisation ou de distributeur avec pour chaque cas des types de commissions et de tarifications différentes, la gestion des contraintes fiscales de chaque événement, la gestion du stock de places qui peut être géré en interne ou chez un partenaire.

13

1.2.

Présentation de la DSI :

La direction des systèmes d’informations (D.S.I.) est composée de trois équipes différentes :

Laurent Benintende D.S.I. Sallman Ouarrak Production Bureautique et hotline niveau 2 4 personnes Exploitation 3 personnes Stephane Van-Bosterhaudt Etude et développement Equipe agile 1 5 personnes Equipe agile 2 5 personnes

Equipe web et mobile

4 personnes

Volkan Altuntas M.O.A. et support fonctionnel

M.O.A.

2 personnes

Support fonctionnel

4 personnes

Figure 3: Organigramme de la D.S.I.

L’équipe M.O.A. (maitrise d’ouvrage) est en charge des relations avec les utilisateurs, de la récolte des besoins, de leur priorisation et du pilotage de leur mise en œuvre. L’équipe assure aussi le rôle de support fonctionnel, en fournissant l’assistance auprès des utilisateurs pour les besoins de support spécifiques concernant le système de billetterie.

L'équipe étude et développement mène les développements sur nos logiciels informatiques, elle joue le rôle de maitrise d’œuvre et est composée de développeurs et d’analystes, les développements sont effectués selon la méthode agile.

L’équipe production est en charge du système d’information de l’entreprise, de la conduite du changement et de la gestion de projets (architecture technique, infrastructure). J’appartiens à cette équipe en qualité de « chef de projet technique », j’occupe également le rôle de référent concernant la partie base de données.

Le projet décisionnel est mené par une personne de chaque équipe : un chef de projet (M.O.A.), en charge du suivi du projet et de la relation avec les utilisateurs et la direction, d’un développeur en charge de la partie restitution (conception de l’application QlikView destinée aux utilisateurs) et de moi-même, en charge de le partie collecte et transformation des données ainsi que de la partie infrastructure (administration, mise en production, suivi d’exploitation). Nous ne sommes pas affectés à temps plein sur la partie décisionnelle.

14

1.3.

Contexte du projet :

Jusqu’en 2011, l’entreprise disposait pour piloter son activité de différents états et outils de reporting, dont des états disponibles dans l’application de billetterie issus des développements de la D.S.I. et des solutions de reporting développées directement par les utilisateurs sous Excel et Access.

En 2011, France Billet a souhaité se doter d’une infrastructure décisionnelle afin de répondre principalement aux besoins d’analyses des activités de l’organisation, demandés par les utilisateurs du système d’information. Cette solution devant permettre principalement de gagner en efficacité et de limiter l’utilisation des solutions crées directement par les utilisateurs qui entrainent des risques de maintenabilité et fiabilité.

Un appel d’offre a été lancé entre différentes solutions du marché (Jasper, Pentaho, Qlikview, Microstrategy). La proposition de la société Ysance basée sur le produit Qlikview a été retenue.

Ysance a proposé deux solutions d’implémentation :

 Solution n°1 : Mise en place de la plate-forme décisionnelle avec acquisition d’une solution d’intégration de données, la construction d’un entrepôt de données et le développement de deux applications de restitution sous Qlikview.

 Solution n°2 : Mise en place de la plate-forme décisionnelle sans acquisition d’un outil d’intégration de données et sans construction d’un entrepôt de données. Utilisation du module E.T.L. intégré à Qlikview pour constituer un socle de données et le développement de deux applications de restitution sous Qlikview.

Ysance nous a recommandé la solution n° 1 car elle offre un système décisionnel de meilleure robustesse et souplesse quant à l’évolutivité de la plate-forme pour les parties d’intégration et d’entreposage des données. Cependant, pour des raisons de coûts, c’est la solution n° 2 qui a été retenue par l’entreprise car les dirigeants voulaient constater les bénéfices pouvant concrètement être apportés aux utilisateurs ainsi que leur engouement dans l’outil livré avant d’investir d’avantage.

15 Les développements de la solution n° 2 menés en collaboration avec la société Ysance ont abouti dans les délais prévus.

Les utilisateurs ont été satisfaits de cette solution et l’ont très vite adoptée. Ils apprécient notamment la facilité de prise en main de l’outil, la fiabilité des données centralisées et partagées par tout le monde, ainsi que le gain de temps engendré et les nouveaux axes d’analyses rendus possible.

Le succès de la solution auprès des utilisateurs a amené une augmentation du nombre d’utilisateurs et des besoins. Certains de ces besoins ne peuvent être mis en place sur la plateforme actuelle pour des raisons de faisabilité, de maintenabilité ou de performance.

L’entreprise a donc besoin de se doter progressivement d’une architecture B.I. industrialisée afin de continuer de fournir un service performant à ses utilisateurs et de supporter les nouveaux besoins décisionnels qui amènent à une migration d’un usage de reporting vers un vrai pilotage de l’activité via l’outil décisionnel.

Par conséquent, afin de pouvoir faire évoluer convenablement sa plate-forme décisionnelle, l’entreprise doit progressivement l’amener vers la solution n° 1, évolution qui fait l’objet de cette étude.

1.4.

Objectif du projet :

L’objectif de ce projet est de mener une étude aboutissant à une proposition d’évolution de la plate-forme décisionnelle existante, particulièrement pour les parties d’intégration et d’entreposage de données.

Ce projet a pour but d’améliorer l’efficacité du système décisionnel de l’entreprise (maintenabilité, évolutivité et disponibilité) et d’apporter l’interopérabilité nécessaire à la conduite de nouveaux projets décisionnels (gestion de la relation client, rapprochement des données des sites internet, diminution du temps d’alimentation, augmentation de la fréquence d’alimentation…).

16 L’outil de restitution Qlikview sera abordé au cours de cette étude pour des besoins de compréhension; néanmoins, la partie restitution de données sera peu abordée car elle est jugée satisfaisante par l’entreprise.

Cette étude devra notamment répondre aux questions suivantes :

 Faut-il acquérir un outil d’intégration de données ?

 Faut-il construire un entrepôt de données ?

 Quel est l’intérêt pour l’organisation, quelles opportunités ?

 Quel est le coût du projet ? Et intégrer les contraintes suivantes :

 La migration vers la nouvelle solution doit être transparente pour les utilisateurs.

 Il faut privilégier les solutions open source dans le choix des outils conformément à la culture de l’entreprise.

1.5.

Démarche de travail :

J’ai choisis de mener cette étude à travers six étapes qui représentent les différentes parties du mémoire. La première partie est consacrée à établir un état de l’art à date sur les systèmes d’informations décisionnels, avec un focus particulier sur les entrepôts de données, la modélisation dimensionnelle et les systèmes d’intégration de données dit « E.T.L. ».

Pour réaliser cette partie, différentes sources bibliographiques et ressources en ligne ont été consultées. J’ai également rencontré quelques acteurs du monde décisionnel : des sociétés proposant des prestations de service Eulidia, Genicorp et Ysance ; ainsi qu’en interne, avec le service décisionnel faisant partie de la direction des systèmes d’information du groupe Fnac.

Pour la seconde partie, j’ai établi un état des lieux du système décisionnel existant, notamment concernant les aspects métiers, fonctionnels et techniques. Les missions du système sont établies et je situe le niveau de maturité du système décisionnel ainsi que les limites rencontrées.

17 La troisième partie porte sur l’établissement du cahier des charges nécessaire au choix de la solution adéquate. Les besoins qui ne peuvent être satisfaits avec la solution décisionnelle actuelle sont récoltés puis analysés.

La quatrième partie est consacrée d’une part à l’étude de solutions d’intégration de données, permettant de constater l’utilité des outils du marché et d’en sélectionner une. D’autre part à une étude de systèmes de gestion de base de données indiquant si le produit MySQL suffit pour héberger l’entrepôt de données ou s’il faut se tourner vers un produit plus spécifique.

Dans la cinquième partie la solution proposée est mise en application au travers de la réalisation d’un prototype du nouveau système décisionnel.

Enfin, la dernière partie est dédiée au bilan de l’étude avec les propositions de mise en place accompagnées des recommandations ainsi que de l’estimation du coût du projet.

1.6.

Déroulement du projet :

Je suis en charge de l’étude sous la direction du chef de projet MOA. La durée de l’étude est d’une année pour un détachement de la moitié de mon temps de travail.

18

2. Etat de l’art des SI décisionnels

Cette partie est consacrée à l’établissement d’un état de l’art sur les différents aspects des systèmes d’informations décisionnels. Ce travail est important et nécessaire pour bien se situer par rapport à l’état actuel de la technique.

2.1.

Les systèmes décisionnels :

On appelle « décisionnel », « aide à la décision » ou également « business intelligence » (B.I.) un ensemble de méthodes et de solutions permettant de collecter, consolider, modéliser, restituer et analyser des données de l’entreprise permettant ainsi d’apporter une vue d’ensemble dans le but d’aider les décideurs dans leur prises de décisions stratégiques.

En effet, pour faire face à la concurrence, les entreprises se doivent d'être de plus en plus performantes et réactives. Les décideurs, chacun à leur niveau de responsabilité, doivent pouvoir accéder aux informations qui leurs sont utiles le plus rapidement possible. L’efficacité d’une décision est liée d’une part à la rapidité d’obtention des informations utiles mais essentiellement à leur fiabilité. Une décision, prise sur la base d’informations pas ou peu fiables, peut être une catastrophe pour la bonne marche de l’organisation.

Le décideur doit, en toutes circonstances, engager la bonne marche de l’entreprise et s’équiper de tous les moyens lui permettant une prise de décision pertinente.

C’est pourquoi toute entreprise possède un système décisionnel, plus ou moins complexe et sophistiqué, allant du tableau simple sous Excel aux systèmes plus évolués tel que l’entrepôt de données.

19 L’entreprise peut selon le niveau de maturité de son système répondre à des besoins de plus en plus complexes. Le schéma suivant fait apparaître les différentes utilisations possibles du système d’information décisionnel en fonction de sa maturité.

Décisionnel stratégique (définir la stratégie)

Décisionnel tactique (évaluation dynamique, gestion)

Etape 1 Tableaux

de bord

Que s’est-il passé?

Requêtes pré-définies Etape 2 Analyse Pourquoi? Requêtes Ad hoc Etape 3 Prédiction Que va t’il se passer? Modélisation analytique Etape 4 Aide opérationnelle Qu’est-il en train de se passer? Màj continue intéractivité Etape 5 Entrepôt actif Que faire? Déclenchement sur évènement Importance de la connaissance

Figure 4: Niveaux de maturité d'un système décisionnel

Reproduit d’après le document les 5 étapes du décisionnel de Teradata [6]

x Etape 1 et 2 : Que s’est-il passé ? Pourquoi ? C’est un mode réactif : suivi des ventes au niveau de chacun des points de vente, des stocks au niveau de chaque manifestation… x Etape 3 : Que va t’il se passer ? C’est un mode pré-actif : visibilité et projection de la

situation au niveau de l’ensemble des sites, dans un mode simulation.

x Etape 4 : Qu’est-il en train de se passer ? C’est un mode interactif : vision globale et détaillée des situations en temps réel en prenant en compte tous les acteurs y compris les partenaires extérieurs dans un schéma collaboratif.

x Etape 5 : Que faire ? C’est un mode proactif : Actions d’optimisation technique (grosse charge sur le SI), d’optimisation financière (opération marketing, promotion…), augmentation ou diminution des stocks…

20

2.2.

Architecture d’un système décisionnel :

Un système décisionnel est généralement composé d’une architecture à trois niveaux :

x Les sources d’information correspondant aux bases de données de production, aux fichiers, …, d’où sont extraites les informations décisionnelles.

x L’entrepôt de données qui contient l’ensemble des données extraites des sources. x Les magasins (souvent appelé datamart) qui représentent un extrait de l’entrepôt et

sont dédiés aux différents groupes de décideurs.

Les 3 niveaux d’architecture ne sont pas nécessairement présents dans les systèmes décisionnels, on peut citer l’exemple des logiciels commerciaux qui permettent de constituer directement des magasins à partir des sources. L’architecture à trois niveaux assure l’indépendance de l’entrepôt par rapport aux diverses manipulations faites par les décideurs.[4]

Sources Entrepôt Magasins Décideurs

Figure 5: Architecture à trois niveaux

Le schéma démontre l’approche séparée en trois différentes parties avec l’intégralité des informations présentes dans l’entrepôt puis au niveau des magasins, on y retrouve une réduction de ces renseignements, en condensant uniquement ce qui est utile à chaque métier.

21

2.3.

Les entrepôts de données :

Les bases de données de production contiennent les informations des différentes applications nécessaires à la gestion de l’entreprise. Chaque système gère des métiers différents de l’entreprise et possède donc sa propre structure de données ainsi que sa propre politique d’accès. Par exemple, le système des achats diffère du système de gestion des employés.

De plus, les bases de données de production, bien qu’étant au cœur du système d’information de l’entreprise, ne contiennent qu’une partie des informations utiles aux décideurs qui doivent pouvoir consulter l’ensemble des données situées dans l’environnement de l’entreprise. Quelques exemples : les informations disponibles chez les partenaires (clients et fournisseurs), les données stockées sur internet, les données législatives.

En outre, les volumes de données des entreprises suivent un accroissement continu pouvant atteindre des millions voir des milliards d’enregistrements pour certaines entreprises telles que AXA ou SANOFI par exemple.

Par conséquent, tous ces éléments entrainent un manque de cohérence ainsi que des difficultés d’accès et de synthèse de l’information, allongeant le temps de prise de décision et posant une des problématiques auxquelles les systèmes d’informations décisionnels doivent répondre :

Comment prendre des décisions sur la base d’informations issues de différents systèmes n’ayant pas la possibilité de communiquer simplement ou de façon normalisée entre eux ?

Le système d’information décisionnel a pour but de fournir un ensemble de moyens permettant de répondre à ces difficultés. Parmi les différentes solutions, les entrepôts de données ont une place primordiale car ils renferment les données de toute l’activité de l’entreprise.

22 Un entrepôt de données est un prolongement des bases de données classiques, il peut être défini comme une base de données utilisée spécifiquement dans le cadre de l’informatique décisionnelle. Les données présentes dans cet entrepôt sont des données dérivées des sources d’informations de l’entreprise qui régissent les activités de celle-ci, elles sont périodiquement intégrées et réunies au sein de l’entrepôt.

Entrepôt

de

données

Figure 6: Un entrepôt de données

L’utilité de cet outil est de stocker sur de longues périodes des mesures/faits sur certaines activités de l’entreprise afin de pouvoir les étudier ultérieurement. Par exemple, l’historique des ventes des différents produits de l’entreprise permet d’étudier l’évolution des ventes d’un produit, de certains produits, de la globalité des produits dans le temps. Ainsi, les décideurs, doivent accéder à ces données qui leur permettront de réaliser des choix et de mettre en place des stratégies.

Un entrepôt de données se démarque d’une base de données relationnelle classique de par son fonctionnement et ses utilisateurs. En effet, les bases de données relationnelles sont conçues pour les traitements transactionnels en ligne et sont utilisées par les applications de gestion habituelles. Les requêtes concernent généralement un petit nombre d’enregistrements et sont fréquentes aussi bien en lecture qu’en écriture. A l’inverse, les requêtes lancées dans un entrepôt de données portent généralement sur un nombre très important de lignes avec des opérations d’agrégation mais sont exécutées à une fréquence bien moindre.

23 Le stockage des informations dans l’entrepôt doit être fait de façon normalisée et structurée, il doit permettre aux décideurs de poser interactivement des requêtes de façon simple, cohérente et conforme à leur métier. Le résultat de chaque requête doit être présenté de manière adaptée à la prise de décision et à la vue globale, c’est-à-dire de manière synthétique. Les données de l’entrepôt sont le plus souvent utilisées par des logiciels permettant l’analyse de données qui les sélectionnent selon certains critères et agrégations.

L’entrepôt doit non seulement pouvoir répondre rapidement à chacune de ces demandes mais également garantir l’intégrité, l’historisation et la mise à disposition des données à l’ensemble des décideurs habilité. Les modèles des bases de données relationnelles étant inadaptés, il faut utiliser des méthodes de modélisation dimensionnelle (voir 2.5) permettant de réaliser des analyses et des visualisations complexes dans des délais raisonnables.

Concernant l’alimentation de l’entrepôt, l’information doit être puisée à partir de diverses sources de données telles que des bases de données, des fichiers ou des sites web. Il faut s’assurer de la cohérence de l’ensemble des données et permettre la mise à jour régulière selon les besoins des décideurs.

La mise en œuvre et l’exploitation d’un entrepôt de données au sein d’une entreprise suivent des processus bien particuliers, différents de ceux habituellement utilisés pour l’élaboration des bases de données relationnelles. Il faut entre autres, mettre en place des processus d’alimentation industrialisés pour récupérer fréquemment les données à partir des sources de données variées (bases de données, fichiers, progiciels, sites web, …) , s’assurer de la cohérence de l’ensemble des données, les stocker de façon normalisée et organiser le stockage des informations.

Enfin, un entrepôt de données n’est pas uniquement figé à l’alimentation reçue des données sources, il doit pouvoir évoluer au fil du temps afin de s’adapter à l’évolution des processus d’analyse et des besoins.

24

2.4.

Les bases de données pour le décisionnel :

Les bases de données sont généralement utilisées selon deux approches distinctes :

La première, l’approche O.L.T.P. (On Line Transaction Processing) correspond aux bases de données transactionnelles avec un schéma relationnel, supportant un très grand nombre de transactions simples effectuées à des fins de gestion courante. L’efficacité est mesurée en nombre de transactions par seconde.

La seconde, l’approche O.L.A.P. (On Line Analytical Processing) correspond généralement aux usages analytiques avec l’utilisation de schéma dimensionnels. Elle est caractérisée par un nombre bien plus faible de transactions mais des requêtes souvent très complexes, portant sur un large ensemble de données et impliquant des agrégations. Le temps de réponse est une mesure d’efficacité.

L’approche O.L.A.P. correspond aux usages dimensionnels, différents types de moteur de bases de données peuvent supporter ce mode de fonctionnement : les moteurs relationnels, multidimensionnels, orientés colonnes et vectoriels.

Les moteurs relationnels bien que conçu généralement pour l’approche O.L.T.P. peuvent être utilisés pour des usages dimensionnels grâce à des modélisations adaptées. On utilise alors généralement des outils R.O.L.A.P. (R pour relationnel) qui requêtent directement sur l’entrepôt de données. Ce type de S.G.B.D. à l’avantage de supporter un volume de données important mais nécessite une forte expertise de la base de données particulièrement en terme d’optimisation.

Les moteurs orientés colonnes stockent les données par colonne et non par ligne, cette orientation permet une compression importante par colonne ainsi qu’une lecture plus efficace des données pour les usages analytiques.

25

Identifant Ville Pays Continent

1 Paris France Europe

2 Reims France Europe

3 Miami Etat-Unis Amérique

4 Berlin Allemagne Europe

5 Porto Portugal Europe

6 Pekin Chine Asie

F 2 R i E U Fra F France Orientation colonne Orientation ligne

Requête: Nombre de ville en France

Figure 7: Orientation en ligne et en colonne

Comme on peut voir sur la figure 7, lors d’une requête, seule la ou les colonnes concernées sont parcourues, à l’inverse des moteurs orientés lignes qui doivent parcourir la ligne entière.

L'orientation en ligne est efficace si toutes les colonnes sont requises, également si le traitement est transactionnel.

L’orientation colonne est efficace si seulement certaines colonnes sont nécessaires, aussi, si les opérations portent massivement sur des agrégations (somme, maximum, moyenne, etc).

Les moteurs vectoriels en plus des moteurs orientés colonnes, ont pour principe de stocker séparément les tables et les données. Les données sont extraites des tables puis sont ensuite déboulonnées et numérotées pour ne contenir plus qu’un numéro de référence associé à chaque donnée. L’avantage d’un tel système permet d’éviter de stocker plus d’une fois une même valeur. Autre avantage, la comparaison des données se fait avec des nombres manipulés bien plus rapidement que du texte. Les répétitions étant fréquentes dans une base de données, le taux de compression peut atteindre un facteur important.

26 Les moteurs multidimensionnels qu’on appelle les cubes, sont basés principalement sur une technologie de blocs denses indexés. Tous les agrégats et indicateurs possibles sont pré-calculés et stockés afin de produire des résultats instantanés et une navigation très confortable. Les inconvénients sont une mauvaise tolérance aux fortes volumétries et le fait de devoir prédéfinir les axes de calculs, ce qui peut être très gênant pour les requêtes ad hoc sur les entrepôts avec un nombre de tables et de champs importants. Les outils permettant de lire les cubes sont appelés des outils M.O.L.A.P. (M pour multidimensionnel).

Magasin Téléphone Internet Janvier Février Mars Avril Mai Prix de vente Prix

d’achat Quantité Profit

Figure 8: Représentation d'un cube

Les données organisées, indexées et agrégées permettent aux utilisateurs des temps de réponse rapide mais quand le besoin d’accéder à des données plus détaillées se fait sentir des accès à une base de données relationnelle deviennent inévitables.

Les entrepôts de données devant permettre un niveau d’analyse assez fin sont généralement conçus avec une approche relationnelle (avec stockage en ligne ou colonne). Pour les magasins les données sont pré-agrégées (voir 2.2), des cubes peuvent être construits ou des tables agrégées (pour la technologie R.O.L.A.P.) qui peuvent être stockées dans le même espace que l’entrepôt de données.

27

2.5.

Principes de la modélisation dimensionnelle :

[1] Le modèle relationnel normalisé ne s’avère pas adapté pour le décisionnel car son

objectif est de normaliser les données afin d’éviter la redondance, ce qui permet de maximiser les performances et de garantir la cohérence des données. L’objectif de l’entrepôt de données est en premier lieu d’offrir une structure compréhensible aux utilisateurs finaux et d’augmenter la performance des requêtes décisionnelles, ainsi, d’autres modèles de conception ont vu le jour. La modélisation dimensionnelle repose sur les concepts de fait, de dimension et de hiérarchie. Nous allons étudier le modèle le plus courant qui est la modélisation en étoile.

Le principe du schéma en étoile est de décrire l’objet analysé au travers d’un fait. Celui-ci est défini par un nom et un ensemble d’attributs appelés mesures ou indicateurs (commande, prix, article, nombre d’articles achetés…). Les faits peuvent ensuite être analysés autour d’axes d’analyses que l’on appelle des dimensions. Ainsi on peut par exemple analyser les ventes au travers de la dimension (l’indicateur) montant.

Les dimensions comportent un ou plusieurs attributs qui sont le plus souvent organisés suivant des hiérarchies. Une hiérarchie modélise les niveaux de granularité auxquels les mesures sont observées. Par exemple, une dimension temporelle comporte des attributs tels que l’année, le trimestre, le mois, la semaine ou le jour. Le mois amène une granularité plus élevée que la semaine, elle-même plus générale que le jour.

Temps id_date année trimestre mois semaine jour Article1 id_article nom type marque Magasin1 id_magasin nom ville pays Faits1 id_produit id_magasin id_date nb_article montant Temps id_date année trimestre mois semaine jour Article id_article nom type marque Magasin id_magasin nom ville pays Faits id_produit id_magasin id_date nb_article montant

28 Le schéma en étoile est composé d’une table centrale, la table des faits elle-même reliée aux tables de dimensions ; ainsi, le montant des ventes peut s’analyser selon une dimension temporelle, une dimension géographique ou encore une dimension représentant les articles.

Tout élément d’une table de dimension peut être associé à zéro, un ou plusieurs faits. A l’inverse, un fait est associé à un seul élément d’une table de dimension.

Pour conclure :

 A chaque dimension correspond une relation de même nom dont les attributs sont dérivés des paramètres et attributs les plus faibles de la dimension. Celui ayant le niveau de granularité le plus fin forme la clé primaire.

 A chaque fait correspond une relation constituée d’attributs, les dimensions qui sont liées au fait par des clés étrangères. La clé primaire est soit constituée de la concaténation des différentes clés étrangères soit par un attribut supplémentaire permettant de distinguer les enregistrements.

La modélisation multidimensionnelle intègre donc des concepts spécifiques pour lesquels les notations habituelles (entité relation) s’avèrent imparfaites. Notamment dans la représentation des hiérarchies associées à chaque dimension.

Il faut proscrire autant que possible les flocons dans la modélisation. On dit qu’une dimension est en flocons lorsque ses champs à faible cardinalité ont été déplacés dans des tables séparées, reliées à la table d’origine au moyen de clés. Cette modélisation fait perdre en performance et peut intimider les utilisateurs.

Néanmoins, les flocons sont recommandés dans certains cas particuliers. Par exemple, le cas de tables de dimensions particulièrement volumineuses avec une sous dimension contenant de nombreux attributs à faible cardinalité. Pour illustrer, prenons le cas d’une dimension client avec une sous dimension traitant des attributs démographiques de résidence du client. Il est recommandé de stocker chaque combinaison des différents attributs démographiques dans la sous dimension et de la relier à la dimension via une clé.

29 La conception logique d’un schéma dimensionnel s’effectue en quatre étapes :

 La première, choisir le magasin de données, l’activité à modéliser, quelque soient les sources opérationnelles (des ventes au détail, des facturations, …).

 La seconde, la granularité de la table des faits, en général, on utilise le niveau le plus fin pour offrir un degré de détail important. Par exemple, un article passé en caisse, une ligne d’une facture…

 La troisième, le choix des dimensions. Elles découlent des faits, il faut que le niveau le plus fin puisse corresponde au niveau de granularité des faits, des mesures. On peut reprendre l’exemple de la figure 9 pour les dimensions d’un fait de vente. La date par exemple aura pour niveau de détail le plus fin, le jour, et la dimension magasin, le terminal qui a encaissé la vente.

 La quatrième, les faits. Le choix des faits met en évidence la portée qu’ils doivent avoir. Par exemple, un article passé en caisse, une transaction perçue, le montant encaissé par jour pour un magasin…

Lors de la phase d’alimentation, le peuplement des tables de dimension doit être effectué préalablement à celui des tables des faits. Les dimensions contiennent les clés primaires référencées comme clés étrangères dans les tables de faits. Il est nécessaire de faire correspondre les faits avec les dimensions lors du peuplement des tables de faits. On peut soit utiliser des jointures SQL ou des méthodes équivalentes, proposées, par des outils d’intégration de données.

Les clés utilisées pour le système dimensionnel doivent être différentes de celles définies dans le système de production. Il faut utiliser des clés de substitutions appelées également clés subrogées. Ces clés sont dépourvues de valeur sémantique et permettent de prévenir l’entrepôt de données contre toute modification des clés du système source : fusion de la société, changement de système source, réutilisation d’une même clé purgée antérieurement.

En effet, les clés de production peuvent être réutilisées au bout de quelques années (cas d’une dimension purgée chaque année) alors que l’entrepôt de donnée stocke des informations pour une plus longue période qui doivent être indépendantes du système de production.

30

2.6.

Systèmes d’Extraction-Transformation-Chargement :

Dans un projet décisionnel, l’objectif de la phase d’alimentation est d’assurer la continuité entre le schéma transactionnel et le schéma décisionnel. Le système d’alimentation permet de récupérer les données auprès de divers systèmes source, d’appliquer des règles de gestion propres à l’entreprise puis, d’intégrer ces informations consolidées au sein de l’entrepôt de données. Les sources sont très souvent composées de systèmes différents disséminés géographiquement. Le processus d’intégration des données constitue la partie immergée de l’iceberg d’un projet d’entrepôt de données. Il occupe entre 70 et 80 % de l’effort consacré à la mise en place [1]. La préparation des données est un processus essentiel à fort degré de criticité. Il est conseillé de réaliser ces traitements dans une zone de préparation située en amont de l’entrepôt de données.

L’outil d’extraction, transformation, chargement de données, plus connu sous l’acronyme anglais E.T.L. (Extraction, Transformation, Loading) ou outil d’intégration de données est un middleware ayant pour objectif la synchronisation massive d’informations entre différentes sources de données. Ces solutions permettent de normaliser l’ensemble des flux de données.

E.T.L.

Données sources Données cibles

Extraction Transfomation Loading (Chargement)

31 La technologie des E.T.L. repose sur trois outils majeurs :

 des connecteurs servant à exporter ou importer des données dans les applications (exemple : Connecteur MySQL ou Excel…),

 des transformateurs qui modifient les données (agrégations, conversions …),

 des dispositifs de mise en correspondance entre les différentes données (mappages). Nous allons étudier plus en détail chacune des étapes de l’extraction, transformation et chargement.

2.6.1.

Le processus d’extraction :

L’extraction des données sources est la première étape d’un outil d’alimentation. Son rôle, comme son nom l’indique, est de lire et d’extraire les données des systèmes source qui se trouvent le plus souvent dans des bases de données de production ou dans des fichiers. L’E.T.L. utilise des connecteurs pour interagir avec les bases de données ou les fichiers.

Il existe deux possibilités pour effectuer l’extraction : via un flux ou via un fichier. Le flux désigne le transfert unique des données du système source vers le moteur de transformation puis vers la cible. L’extraction en mode fichier quant à elle, se déroule en plusieurs étapes : création du fichier, transfert du fichier, lecture du fichier et transformation des données puis chargement vers la cible.

Bien que l’extraction par flux soit la plus attirante, l’extraction sous forme de fichier n’est pas sans avantages. Elle peut être relancée à partir de plusieurs points du moment que l’on dispose du fichier source. Le fichier peut également être compressé limitant ainsi l’impact sur la bande passante dans le cas de sources distantes.

Il faut sélectionner avec attention les données à importer sans pêcher par l’excès au risque de pénaliser lourdement le système et ne pas importer trop peu d’informations qui ne permettront pas de refléter la réalité ni de répondre aux questions précises des décideurs. Il faut, dans la mesure du possible, extraire seulement les données utiles et étudier s’il est possible d’interroger le système source par incrément. Il faut également connaitre la politique de purge du système source pour ne pas risquer de perdre de données.

32 L’étape d’extraction peut s’avérer critique particulièrement dans le cas où un ou plusieurs systèmes doivent être disponibles 7 jours sur 7 et 24 heures sur 24. L’opération, habituellement coûteuse en ressources, doit être réalisée sans entrainer d’indisponibilité du système source et couramment être effectuée dans un laps de temps précis requis par les équipes d’exploitation de ce système source. Il peut également y avoir un niveau de sécurité requis pour le transfert de données jugées sensibles.

2.6.2.

Le processus de transformation :

La transformation est une tâche complexe qui nécessite beaucoup de réflexion et de ressource. Après avoir extrait les données, il faut effectuer plusieurs traitements en vue de les :

 Dénormaliser : Dans un système décisionnel, la duplication délibérée de certaines données peut s’avérer utile, particulièrement en termes de performance.

 Nettoyer : Certaines données du système de production peuvent être fausses, par exemple une erreur de frappe sur le nom d’une ville. Les erreurs doivent pouvoir être détectées et corrigées afin de ne pas entrainer de répercussion sur les analyses.

 Réconcilier : Un vendeur est un vendeur, il ne doit y avoir qu’une seule dimension vendeur avec toutes les informations le concernant même si elles proviennent de source de données différentes.

 Préparer : Les données doivent respecter le format requis par les systèmes cible, par exemple, la modélisation en étoile ; ou encore être préparées de façon à pouvoir suivre ultérieurement, l’évolution d’un changement d’état dans le temps.

Voici des exemples de transformations qui peuvent également avoir lieu :

L’affectation des clés de substitution qui consiste à remplacer chaque clé primaire par une clé numérique sans signification, améliorant les performances et garantissant l’indépendance du système décisionnel.

33 Autre exemple, la recherche d’équivalent textuel, qui consiste à faire correspondre des noms ou des adresses à certaines valeurs déjà enregistrées et qui peuvent parfois ne pas concorder à cause de différences orthographiques. Dans ce cas, il faut détecter ces différences et les corriger afin de faire correspondre les valeurs.

Enfin, on peut également citer les opérations de calcul, la gestion des tables de dimension et la gestion des tables de faits.

2.6.3.

Le processus de chargement :

La dernière étape consiste à charger les données préalablement extraites, transformées et préparées dans des cibles hétérogènes. Il s’agit le plus souvent d’un entrepôt de données.

Le chargement consiste à insérer ou mettre à jour les données cibles tout en conservant les données modifiées devant l’être, afin de conserver une traçabilité des informations (desquelles découlent les décisions prises). Les informations stockées dans un entrepôt de données ne doivent jamais disparaitre dans la mesure du possible. Cette étape peut être complexe : il faut ajouter les nouvelles lignes, détecter si des lignes ont été modifiées ou supprimées ; il faut notifier ces modifications et veiller à ne pas charger des données en double.

On peut en déduire l’existence de deux types de chargement de données:

 Le chargement complet ou initial,

 Le chargement incrémental correspondant aux mises à jour périodiques.

Le chargement initial est obligatoire pour le 1er peuplement puis les chargements incrémentaux peuvent ensuite être mis en place. Dans le cas où l’intégralité des données est extraite à chaque rafraichissement on parle de rechargement complet.

L’étape de chargement est relativement simple à exécuter dans les cas où les données ont été correctement préparées. Pour les fortes volumétries, il est recommandé d’utiliser l’utilitaire de chargement de masse (appelé aussi mode bulk) de la base de données, la plupart des S.G.B.D. proposent ce mode qui offre de bien meilleures performances.

34

2.6.4.

Les différents types d’E.T.L. :

2.6.4.1.

L’E.T.L. moteur :

Sur ce type d’E.T.L., toutes les transformations sont effectuées sur un ou plusieurs serveur(s) E.T.L. dédié(s). L’outil dispose en général d’un référentiel assurant notamment la persistance des métadonnées.

Ce type d’E.T.L. présente l’avantage de permettre d’effectuer des opérations multi-sources, par exemple, une jointure entre une table de deux bases de données différentes, ou entre une table d’une base de données et un fichier Excel. Cette souplesse d’utilisation fournit un gain non négligeable sur la productivité.

Les limitations sont d’une part dues au coût qui est souvent élevé et dépend du nombre de connecteur et de serveur moteur. D’autre part, le moteur de transformation est rarement accessible, ce qui provoque un effet « boite noire » pouvant être handicapant en cas de recherche d’optimisation.

Liste de produits du marché : Powercenter, Datastage, Genio, Business Object Data integrator, Ab Initio et Pentaho Data Integration.

2.6.4.2.

L’E.L.T. utilisant les moteurs des bases de données :

Sur ce type d’outil d’intégration de données, les transformations sont effectuées au sein de la base de données cible (via du code SQL/PLSQL) d’où le nom E.L.T. (extraction, chargement et transformation) en opposition au traitement E.T.L. classique qui opère les transformations avant le chargement dans la cible.

Les solutions E.L.T. sont généralement moins onéreuses, le moteur de transformation est accessible (S.G.B.D.) et les traitements portant sur des volumes de données conséquents sont plus performants que via les E.T.L de type moteur.

35 Le chargement préalable des données ainsi que l’utilisation obligatoire du moteur de la base de données pour les transformations rajoutent de la complexité particulièrement dans le cas de sources hétérogènes et peut amener certaines limites ainsi que des baisses de performance pour des opérations qui sont moins performantes sur une base de données.

Par exemple, Il n’est pas possible de faire de transformations à la volée depuis les sources (en mode flux). Le mode E.L.T. requiert des ressources sur le S.G.B.D. pendant les opérations de transformations, ce qui peut être handicapant si celui-ci est déjà fortement sollicité.

Liste de produits du marché : Oracle Data Integrator et DB2 Warehouse Manager.

2.6.4.3.

L’E.T.L. générateur de code :

Un autre type d’E.T.L. est le générateur de code. Les transformations sont conçues dans l’outil, un code est généré et peut être déployé dans n’importe quel environnement équipé des prérequis nécessaire.

Le code de transformation généré peut être analysé, il n’y’a donc pas d’effet « boite noire ». De plus, cette solution permet de combiner l’utilisation des différents modes de transformation E.L.T. et E.T.L. ; ce qui offre une grande souplesse de conception et d’optimisation.

Ce mode de fonctionnement facilite l’adoption d’une approche d’exécution répartie sur plusieurs machines évitant ainsi l’achat d’un serveur onéreux avec les risques d’évolutivité à mesure de l’augmentation des traitements entrainant une saturation du serveur.

Liste de produit du marché : Talend

2.6.5.

L’évolution des systèmes d’E.T.L. :

Depuis leur création, les systèmes d’E.T.L. n’ont cessé d’évoluer, on dénombre cinq générations :

 La génération 1 date de l’époque des mainframes, les outils E.T.L. généraient du code COBOL à partir des données extraites. Cette solution était coûteuse et encombrante.

36

 La génération 2 avec l’avènement du client/serveur a utilisé le langage de requête SQL comme format de destination. Ces solutions atteignent rapidement leurs limites avec l’avènement des applications packagées comme les progiciels de gestions (SAP…). Il faut extraire la logique métier au niveau de la couche applicative pour correspondre au modèle de données stocké dans la base relationnelle.

 La génération 3 a vu l’apparition d’adaptateurs spécifiques livrés avec les E.T.L. afin de fournir une intégration plus étroite avec les applications. En effet, chaque application gérant différemment les logiques métiers. Les interfaces permettant de modéliser graphiquement les échanges et les transformations se sont imposées ainsi que les consoles d’administrations centralisées intégrant le référentiel de données. La gestion de l’hétérogénéité de plus en plus importante pour les S.I., est facilitée.

 La génération 4 est née de la nécessité d’être plus réactif, de raccourcir les délais de décisions. Les outils E.T.L. sont désormais capables de gérer simultanément des flux de données en temps réel et en différé. Une série de composants veille en attendant l’arrivée de requêtes pour les traiter. L’E.T.L. se dote d’un distributeur de messages en empiétant sur les systèmes E.A.I. (Entreprise Application Integration).

 La génération 5 présente une vocation plus large. En effet les générations précédentes se destinaient à l’utilisation des données dans un cadre décisionnel, avec un entrepôt de données centralisé, localisé ou généraliste. Les adaptateurs sont maintenant bidirectionnels, capables d’écrire aussi bien dans l’application cible que dans l’application source. Les données exploitées à des fins analytiques restent mises à jour en différé du fait de leur volume important ; celles à caractère opérationnel dont les applications ont besoin pour rendre compte de la situation présente de l’activité sont par contre injectées en temps réel ou quasi temps réel dans l’application cible.

L’E.T.L. ne cesse d’évoluer et se rapproche de plus en plus de l’E.A.I. en intégrant le distributeur de messages et en faisant du temps réel. Cependant des différences perdurent, avec l’E.T.L. des données sont échangées, l’E.A.I. permet en plus à une application de commander l’exécution d’une tâche à une autre selon un processus métier défini ce que ne fait pas l’E.T.L.

37

2.7.

L’outil de restitution QlikView :

Qlikview faisant partie intégrante de la solution décisionnelle actuelle, il se doit d’être présenté. C’est un logiciel commercial édité par la société Qliktech, permettant de concevoir et de mettre à disposition des utilisateurs, des applications d’aide à la décision (tableaux de bord, reporting…), leurs donnant les moyens d’analyser les données de l’entreprise.

Ce produit contient un module d’E.T.L. intégré et permet la réalisation de tableau de bord directement à partir des sources de données en cas d’absence d’entrepôt de données. Le module E.T.L. intégré à Qlikview se situe entre la 2e et la 3e génération. Il permet des transformations un peu plus complexes que le langage SQL et possède quelques connecteurs spécifiques pour les sources. Il ne propose cependant pas d’interface graphique permettant la modélisation des échanges et des transformations, et propose un référentiel de gestion des données source très limité.

Qlikview n’est compatible qu’avec les plates-formes Windows. Il est composé d’un client lourd dans sa forme la plus simple servant à la fois à la conception et à la consultation des applications par les utilisateurs. Un mode serveur est également disponible, il permet de partager plusieurs applications, de prendre en charge leurs rafraichissements et de les rendre accessibles par l’intermédiaire d’un client léger, c’est-à-dire via un navigateur internet.

Contrairement à la plupart des outils de restitution, Qlikview ne sollicite pas de base de données ou de cube pour les analyses. Il possède son propre système de base de données vectorielle associative en mémoire. Cette technologie consiste à intégrer toutes les données dans un S.G.B.D. propre optimisé et chargé intégralement en mémoire. Cela permet de bénéficier des performances de ce support (temps bien plus rapide que pour de l’accès disque) et ainsi profiter de ces avantages pour associer toutes les données entre elles.

Ainsi chaque colonne devient un axe d’analyse exploitable. En contrepartie, Qlikview nécessite de par son mode de fonctionnement, d’une quantité importante de mémoire vive.