Partie I: Synthèse Bibliographique
Chapitre 5: Conception de la zone « Alimentation »
IV. Processus de chargement
IV.1 Processus de chargement de dimension
Les tables de dimension constituent le contexte de la table de faits. Elles représentent le point d’entrée au Data Warehouse. Une dimension est généralement constituée : d’une clé artificielle, d’une clé naturelle et des attributs.
Le processus de chargement de dimension doit, outre le chargement des données, assurer :
• La gestion des clés artificielles: affectation des clés et mise en correspondance avec les clés naturelles.
• La gestion de l’évolution de dimension : gérer les changements que subissent les dimensions. Il existe trois types de traitement par rapport à l’évolution d’une dimension :
o Type 1 « écrasement » : consiste à mettre à jour l’attribut subissant un changement.
o Type 2 « création d’un nouvel enregistrement » : consiste à créer un nouvel enregistrement afin de sauvegarder tout le cycle d’évolution de la dimension.
o Type 3 « déplacement de la valeur a changé dans un attribut ancien » : consiste à prévoir des attributs pour enregistrer les changements éventuels.
Il permet de sauvegarder un nombre défini de changements.
Le digramme suivant illustre la politique que nous avons retenue :
Figure II.30 : diagramme d’activité du processus de chargement de dimension.
La stratégie adoptée pour la détection des changements se fait grâce à la comparaison entre le dernier chargement et le chargement actuel. Cette méthode, comme décrite lors de la synthèse bibliographique, est la plus fiable pour la capture des changements.
Les mises à jour de type 3 sont traitées comme de nouvelles insertions, avec la mise à jour de la table références.
IV.2 Processus de chargement des tables de faits
L’extraction des faits se fait avec les clés naturelles utilisées dans les systèmes sources.
L’étape qui précède le chargement de la table des faits consiste à remplacer les clés naturelles par les clés artificielles. La substitution peut se faire directement par le biais des tables de dimension, ce qui est correct mais très lent. Pour cela on utilise des tables de référencement.
Le processus de chargement des tables des faits doit garantir l’intégrité référentielle vis-à-vis des tables de dimensions.
Le diagramme d’activité suivant illustre le processus de chargement adopté pour une table de faits :
Figure II.31 : diagramme d’activité du processus de chargement de faits.
Le chargement de la table de fait peut être une insertion, ou une mise à jour des tables de faits.
IV.3 Processus de chargement particulier
Dans un entrepôt de données il y a des tables particulières, soit : la table de la dimension temps et les tables d’agrégats, nécessites un traitement à part.
IV.3.1 Processus de chargement de la dimension temps
Contrairement aux autres dimensions, la dimension temps contient uniquement des dates qui ne sont pas forcément extraites à partir des systèmes sources. Cette dimension doit contenir, en effet, toutes les dates qui coïncident, ou coïncideront, avec un fait donné. Elle participe à toutes les étoiles et assure l’historisation. Dès lors, il est préférable de construire un calendrier :
« La dimension date est plus souvent construite comme étant un calendrier avec une granularité journalière ». [Kimball, 2004].
IV.3.2 Processus de construction d’agrégats
Après le chargement d’une étoile, les tables d’agrégats doivent être chargées par le biais de l’ETL et à partir des données détaillées. En plus du calcul des agrégats et de leur insertion, des mises à jour fréquentes de ces tables sont indispensables.
V. Conclusion
Un processus E.T.L a pour mission d’assurer la livraison de données conformes, cohérentes et correctes tout en assurant des performances acceptables. Lors de la conception du processus de l’ETL il a été envisagé d’atteindre les objectifs suivants:
• Assurer le chargement des données et leur qualité,
• Assurer la transparence des processus de chargement et de consolidation qui assure la qualité des données,
• Ne pas nuire aux performances des systèmes sources,
• Utiliser des sources, autres que les sources opérationnelles pour donner une valeur ajoutée aux informations,
• Permettre un suivi de l’avancement des chargements, et corrections en cas d’erreur,
• Offrir une documentation complète du processus, afin de faciliter la maintenance ainsi que l’amélioration,
• Offrir une performance optimale grâce aux chargements parallèles et séparation des données selon l’opération de chargement (mise à jour ou nouvelle insertion),
• Mettre en œuvre des solutions secours pour faire face aux problèmes réseau,
• Mise à jour des Meta data, pour la maintenance et l’assurance de la qualité de données,
Conception des cubes dimensionnels
I. Introduction
niveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d’offrir une représentation abstraite d'informations multidimensionnelles à des fins d’analyse.Le choix des cubes à construire, des mesurables qu’ils contiendront, des dimensions participantes dans chacun d’entre eux et des hiérarchies qui constituera chaque dimension dépend essentiellement des besoins recensés et de l’utilisation finale.
II. Définition des niveaux et des hiérarchies
La définition des différentes hiérarchies présente dans une dimension est une étape cruciale et indispensable pour la conception des cubes. En effet, c’est grâce à ces hiérarchies que l’utilisateur pourra naviguer et explorer à bon escient les informations offertes par un cube donné.
Cette étape se déroule en deux phases:
• Identification des attributs d’un même niveau pour chaque dimension.
• Construction des hiérarchies (Une dimension peut avoir plusieurs hiérarchies).
Au final nous obtiendrons le tableau récapitulatif suivant :
Dimension Colonne Niveaux Hiérarchies
dim_activite
code_activitelibele_activite Niveau_1 : N1 Hierarchy_1 :
N1 ALL
Niveau_1 : N1 Hierarchy_1 :
N1 ALL
dim_client
code_client reference_lc
type
Niveau_1 : N1 Hierarchy_1 :
N1 N2 N3 ALL
Niveau_1 : N1 Hierarchy_1 :
N1 N2 N3 N4 ALL
lib_nature Niveau_1 : N1 Hierarchy_1 :
N2 N1 ALL
Niveau_1 : N1 Hierarchy_1 :
N1 ALL
dim_temps
dim_zone
code_zone code_commune
commune
Niveau_1 : N1
Hierarchy_1 :
N1 N2 N3 N4
N5 ALL
code_agence
agence Niveau_2 : N2
code_dr
dr Niveau_3 : N3
code_wilaya
wilaya Niveau_4 : N4 code_filiale
filiale adresse_filiale
tel_filiale
Niveau_5 : N5
Tableau II.28 : Tableau donnant les niveaux et les hiérarchies de chaque dimension.
Le niveau « All » : Ce niveau représente le niveau le plus haut d’une hiérarchie. De ce fait, il est le niveau le plus agrégé. Le niveau « ALL » n’apparaît pas systématiquement dans toutes les hiérarchies.
III. La liste des cubes
Dans ce qui suit nous allons dresser la liste des cubes à mettre en place. Pour chaque cube on donnera les dimensions participantes ainsi que les mesurables présents dans ces cubes. Il est à signaler aussi que la dimension « dim_nature » n’apparaitra nul part dans la description des cubes. En effet, cette dimension a été remplacée par l’utilisation de mesurables dans les cubes concernés. Le tableau suivant donne le détail de la conception de ces cubes :
Nom du cube Les mesurables Les dimensions Les Hiérarchies de la dimension
Suivi des ventes 1. Chiffre d’affaires 2. Nombre de factures
Suivi des
résiliations 1. Nombre de résiliations
Dim_type_abonné Hierarchy_1
Suivi des affaires 1. Nombre d’affaires 2. Durée
Tableau II.29 : Liste des cubes dimensionnels.
IV. Présentation des cubes dimensionnels
Figure II.32 : Cube dimensionnel « Suivi des ventes ».
Cube_suivi_vente - Dim_client
Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ».
Figure II.34 : Cube dimensionnel « Suivi des abonnés ».
Figure II.35 : Cube dimensionnel « Suivi des recouvrements ».
Cube_suivi_des_abonnes - Dim_zone Cube_suivi_des_abonnes - Dim_temps
type_client_paiement <N3>
Hierarchie_1 <Default> <h>
Cube_suivi_recouvrement - Dim_client
Figure II.36 : Cube dimensionnel « Suivi des affaires ».
V. Conclusion
Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse.
C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données contenues dans l’entrepôt de données de manière correcte et intuitive.
Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini, pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui composent ces dernières.
Meta Data
I. Les « Méta Data » ou « métas données » de l’entrepôt
Un entrepôt de données, étant en production constante, doit être suivi de prés.
L'administration d'un Data Warehouse revient à mettre en place des processus et des mécanismes de gestion. Ces mécanismes sont là pour assurer un meilleur fonctionnement de l’entrepôt. Aussi ils doivent garantir l’alimentation en données quelques soient les circonstances.
Afin d’assurer la mise à jour de l’entrepôt de données, il est nécessaire de suivre son alimentation au jour le jour, surtout dans le cas présent où les sources de données sont géographiquement dispersées. Un tel suivi peut être garantie grâce au recours au méta data de l’entrepôt.
II. Rôle des métas données
Les métas données ont un rôle très important dans le cycle de vie d’un entrepôt de données. En effet, elles donnent une description ainsi qu’un sens aux données contenues dans l’entrepôt, afin que l’utilisateur comprenne et puisse utiliser au mieux ces données.
Cependant, leur rôle peut dépasser le cadre de cette description en se présentant comme un moyen de supervision et de suivi de l’évolution de l’entrepôt. Le diagramme illustré sur la figure II.37 montre la conception des métas données.
Ce diagramme représente, de manière claire, la structure de l’entrepôt de données, renseignant de ce fait sur sa contenance en données. En plus de cela, il offre la possibilité de superviser les chargements en donnant une vue générale sur l’alimentation de l’entrepôt de données.
Figure II.37 : Diagramme de classe des métas données.
III. Exploitation des métas données
III.1 Présentation de la partie navigation
La fonction première des métadonnées est d’offrir un catalogue complet et détaillé sur le contenu de l’entrepôt. Ce catalogue est bien sûr appelé à évoluer. De ce fait l’utilisateur doit être en mesure de consulter ce catalogue et d’y proposer des mises à jour, si cela est nécessaire. Le diagramme des cas d’utilisation suivant illustre ces différents volets :
Figure II.38 : DCU navigation dans les métas données.
III.2 Présentation de la partie supervision
Vu le nombre de sources de données et leurs dispersions géographiques, il se peut que l’alimentation en données d’une des directions de distribution ne se déroule pas comme prévu.
Dans ce cas, l’administrateur doit être en mesure de détecter les erreurs survenues lors de l’alimentation et avoir la possibilité de recourir à des solutions secours. Ces solutions de supervision et de chargement secours sont :
III.2.1 Supervision : l’administrateur aura la possibilité de suivre l’état des chargements journaliers de l’entrepôt de données. Ainsi, il aura une situation précise des chargements par direction de distribution, lui offrant de ce fait la possibilité de détecter les chargements échoués et la date de l’échec de manière à recouvrir les données non chargées.
III.2.2 Solutions secours : lors d’un chargement échoué l’administrateur de l’entrepôt de données pourra utiliser l’une des méthodes suivantes pour mettre à jour les données de l’entrepôt :
a. Le chargement paramétré : le chargement peut se faire à distance en spécifiant les directions concernées par ce chargement et le jour du chargement concerné.
Cependant, cette solution n’est utilisable que pour le jour suivant l’échec du chargement et cela, soit à cause de la volatilité des données, soit à cause de la quantité trop importante des données. Le paramètre de ce chargement n’est autre que les Directions de distribution concernées par le chargement.
b. Le chargement à partir des fichiers de sauvegarde : durant la présentation de la partie « alimentation de l’entrepôt » nous avons évoqué les fichiers de sauvegarde.
Ces fichiers sont utilisés afin de charger les données manquantes en cas de problèmes. Ces fichiers, qui sont générés après chaque extraction de données au niveau des directions de distribution, sont transférés et utilisés. Une durée de sauvegarde de ces fichiers est nécessaire, cette durée a été arrêtée à une semaine.
Le diagramme des cas d’utilisation suivant illustre les cas cités précédemment :
Figure II.39 : DCU supervision.
IV. Conclusion
La couche méta données est très importante dans un projet Data Warehouse, dans la mesure où elle en permet la maintenance de ce dernier, garantit son intégrité et facilite son expansion.
Ainsi il est plus que nécessaire de concevoir les métas données et de développer une couche applicative permettant de les maintenir. Dans ce chapitre nous avons essayé de concevoir un sous système d’administration de l’entrepôt de données qui répond aux exigences d’un tel projet.
Partie III :
Réalisation et déploiementRéalisation et déploiementRéalisation et déploiementRéalisation et déploiementI. Introduction
Pour la réalisation et la mise en place de la solution, il a été nécessaire de recourir à un certain nombre d’outils et mettre en place des environnements d’exécution.
Ce chapitre a pour objectif, de décrire l’environnement mis en place et les outils utilisés, ainsi que de décrire l’environnement existant (matériels et logiciels), et dans lequel évoluera notre système.
II. Implémentation
II.1 Périmètre technique et fonctionnel
Cette partie décrit les infrastructures déjà en place. En effet, cette dernière est une étape à ne pas négliger, car la diversité des sources et leurs plateformes techniques pourront engendrer des problèmes de compatibilité.
II.1.1 Matériel
Les systèmes sources sont installés sur différentes plateformes :
• Machine IBM,
• Machine INTEL : HP ou DELL, II.1.2 Systèmes d’exploitation
Lors de notre étude il a été recensé les systèmes suivants :
• AIX 5.1, 5.2 pour les machines IBM,
• LINUX : RedHat 4.5,
• Windows Server 2003,
• Solaris Sparc,
L’étude du matériel existant nous a permis de prévoir des solutions à certains problèmes, tels que la non compatibilité des machines AIX 5.2 avec la version du JRE nécessaire pour l’exécution des programmes d’extractions.
II.2 Architecture
La figure suivante illustre la structure
Figure III
II.3 Zone de stockage
Lors de la conception, il données : la base de données
Le choix du système de gestion de base de données s’est fait de chaque base de données, de son utilisation et d
1) Base de données «
La base de données, Data Warehouse, a été implémentée sous l source PostgresPlus. C
connu pour ses performances par rapport aux bases de données volumineuses intègre un ensemble d’outil
pré configuré pour la mise en place d’un Data Warehouse.
19 Voir annexe F.
Architecture technique de la solution
La figure suivante illustre la structure et l’architecture technique de la solution proposée
Figure III.1 : Architecture technique de la solution.
Zone de stockage
conception, il a été question de concevoir et mettre en place deux bases de : la base de données de la zone d’entreposage et celle des Meta data.
Le choix du système de gestion de base de données s’est fait en fonction de de données, de son utilisation et des données qu’elle contiendra.
Data Warehouse » :
La base de données, Data Warehouse, a été implémentée sous l source PostgresPlus. Cette distribution de PostgreSQL, en plus du
connu pour ses performances par rapport aux bases de données volumineuses intègre un ensemble d’outils d’administration et de configuration. Aussi ce SGBD est
configuré pour la mise en place d’un Data Warehouse.
technique de la solution proposée :
été question de concevoir et mettre en place deux bases de et celle des Meta data. d’administration et de configuration. Aussi ce SGBD est
2) Base de données Meta Data :
La base de données, Meta data, a été implémentée sous le SGBD MySQL, qui est un SGBD open source simple d’utilisation et performant pour les petites bases de données.
II.4 Zone d’alimentation de l’entrepôt
L’implémentation du processus de chargement peut se faire par le biais d’outils disponibles sur le marché. Une multitude de choix s’offre à nous. Cependant, et vu l’orientation de l’entreprise vers l’open source notre étude s’est limité à cette classe de produit.
Après une étude comparative, le choix a été porté sur « Talend Open Studio » dans sa version « 3.1.4r2 », connu comme l’outil le plus performant de sa catégorie open source [Daan, 2007]. Ce dernier basé sur l’IDE « Eclipse » intègre un ensemble de composants implémentés en JAVA et permet de rajouter son propre code JAVA.
Les points forts de cet outil sont :
• Assurer une indépendance totale vis-à-vis du SGBD source, ou celui implémentant l’entrepôt de données.
• Sa richesse en nombre de composants, permet l’extraction de toute source de données connue et standard.
• Génère des programmes en java s’exécutant sur différentes plateformes.
• Développé par une communauté importante qui ne cesse d’augmenter.
• Permet d’ajouter du code java afin d’implémenter notre solution telle qu’elle a été conçue.
II.5 Zone de restitution
Cette zone représente l’interface entre l’utilisateur et le Data Warehouse. Elle est constituée d’un ensemble d’outils qui doivent permettre aux utilisateurs d’exploiter le système mis en place dans les meilleures conditions possibles. . Ainsi plusieurs outils et serveurs ont été mis en place:
• Un serveur web Apache permettant un accès distant.
• Une plateforme BI « SpagoBI » pour la gestion et la diffusion des documents, ainsi que pour son module de création de requêtes à la demande « Querry by exemple ».
• Un moteur ROLAP « Mondrian », pour l’implémentation des cubes conçus pour l’analyse multidimensionnelle. Ce dernier est connu comme leader des moteurs ROLAP open source.
• Un serveur de reporting « JasperReports », pour l’édition des rapports préétablis.
Ces derniers sont conçus séparément et intégrés dans la plateforme « SpagoBI ».
• Un serveur SMTP, pour la diffusion des rapports.
• Implémentation des tableaux de bord conçus avec l’outil « Open Slazio » pour une représentation graphiques efficace et compréhensible.
Même si ces outils se présentent comme des solutions clé en main, ils nécessitent un travail d’intégration et de conception afin de donner une valeur ajoutée aux états implémentés.
En plus de la mise en place de ces outils, il était nécessaire de développer certains volets:
• Gestion des utilisateurs : ce module permettra la gestion des utilisateurs et des droits d’accès.
• Administration et supervision de l’entrepôt de données :
• Navigation dans les Meta data : cela offrira un support aux utilisateurs finaux.
Ces deux modules ont été développés en JavaServer Pages (JSP), qui est l’extension web du langage Java. Le développement s’est fait avec la version 6.5 de l’IDE NetBeans. Le choix de ce langage est en rapport avec les points suivants :
• Les possibilités offertes par ce langage.
• La portabilité des modules développés.
• L’intégration au sein du même serveur web.
• L’intégration dans la plateforme SpagoBI. Cette dernière étant développée en JSP.
• L’exécution au niveau serveur, offrant un niveau de sécurité optimum.
III. Déploiement
Pour mieux décrire le déploiement de la solution, on utilise le modèle de déploiement U.M.L qui permet de présenter l’architecture de déploiement d’une manière simple et compréhensible.
Comme on peut le voir, notre solution comporte trois zones : zone d’alimentation, zone de stockage et zone de restitution. Afin d’illustrer cela, on propose deux diagrammes de déploiements : Un diagramme pour la zone d’alimentation et un autre diagramme pour la zone de restitution. La zone de stockage étant liée directement aux deux autres zones sera décrite dans les deux modèles.
III.1 Déploiement de la zone d’alimentation
Figure III.2 : Digramme de déploiement de la zone d’alimentation.
III.2 Déploiement de la zone de restitution
Figure III.3 : Diagramme de déploiement de la zone de restitution.
IV. Conclusion
La partie de restitution est la partie sur laquelle l’utilisateur final aura à interagir. Cette dernière a été mise en place en intégrant des solutions « Open Source », et en développant certains volets de manière à assurer une bonne utilisation du système.
Des programmes ont été développés, au préalable, en JAVA, afin d’assurer l’alimentation de la zone de stockage en données. Cette dernière a été implémentée sous le SGBD PostgreSQL, dans sa distribution « PostgreSQLPLUS ».
Le déploiement de la solution se fait suivant les diagrammes de déploiement illustrés dans la figure III.2 et la figure III.3, et se divise en deux parties :
• Déploiement de la zone d’alimentation.
• Déploiement de la zone de restitution.
Le déploiement se fait pour le moment sur trois sites pilotes, et sera étendu à l’ensemble du territoire des que les résultats des tests fonctionnels auront été approuvés.
C
onclusion générale et perspectivesConclusion générale et Perspectives
Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur ajoutée, tel est le défi des entreprises modernes.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise de décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettre la mise en place d’un système décisionnel fiable et efficace.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise de décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettre la mise en place d’un système décisionnel fiable et efficace.