Volet « Suivi des abonnés »

a) Présentation de l’activité « Suivi des abonné »

Un abonnement électrique (ou gazier) est une contrepartie aux services qui sont rendus par le gestionnaire du réseau public de distribution. Principalement l’acheminement de l’électricité, et du gaz de la centrale au lieu de consommation de l’abonné.

L’abonné est la partie bénéficiaire du service, en contrepartie il doit honorer ses engagements relatifs au contrat d’abonnement.

Lors de notre étude des besoins, un des sujets auquel s’intéressent les décideurs est le suivi des abonnés : abonnement, mise en service, résiliation…. En effet, le nombre d’abonnés se présente comme un des indicateurs de performances de l’entreprise, d’où l’intérêt de suivre la réalisation des objectifs tracés.

b) Grain de l’activité :

Le grain le plus fin de l’activité correspond à :

L’historique complet d’un abonné par type, zone géographique et par activité.

c) Les dimensions participantes du modèle : 1. Les dimensions communes

Le tableau suivant nous donne la liste des dimensions communes entre toutes les étoiles :

Etoile Vente Recouvrement Suivi des

abonnés

Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,

« Recouvrement », « Suivi des affaires » et « Suivi des abonnés ».

2. Dimension type abonné

Dans ce cas on se retrouve avec une table de faits

tracer l’historique d’un abonné du jour de son abonnement à son éventuel Dimension type abonné

La dimension type abonné contient une description d’un abonné par paiement (domicilié ou non domicilié) et par rapport au type du lieu de consommation.

la Dimension Type abonné de l’activité « Suivi des abonné Détails

Clé artificielle du type abonné Type abonné selon ses paiements

Type abonné selon le lieu de consommation

: Tableau descriptif de la dimension « Type abonné ».

Dans ce cas on se retrouve avec une table de faits sans faits. Cette table tracer l’historique d’un abonné du jour de son abonnement à son éventuelle

La dimension type abonné contient une description d’un abonné par le type de ) et par rapport au type du lieu de consommation.

Suivi des abonnés ».

Type abonné selon le lieu de consommation

Tableau descriptif de la dimension « Type abonné ».

sans faits. Cette table a pour objectifs de le résiliation.

e) Le modèle en étoile de l’activité « Suivi des abonnés »

Figure II.26 : Modèle en étoile de l’activité « Suivi des abonnés ».

f) Les agrégats

1. Les agrégats potentiels

Dimension Agrégats potentiels

Nombre d’agrégats

possibles

Temps Mois, trimestre, année, saison 4

Type abonné Lieu, paiement 2

Activité Code activité 1

Zone Tournée, agence, commune, DR, wilaya, filiale 6 Client Numéro, commune, agence, DR, wilaya, filiale, activité,

débit gaz, débit électricité, type 10

Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « suivi abonnés ».

2. Les agrégats utiles

Dimension Agrégats utiles Nombre d’agrégats possibles

Temps Mois, trimestre, année, saison 4

Activité Code activité 1

Zone Commune, agence, DR, wilaya, filiale 6

Type abonné Lieu, paiement 2

Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « suivi abonnés ».

On va arrêter la liste des agrégats suivants :

• Nombre d’abonnements par commune par jour.

• Nombre de résiliations par commune par jour.

• Nombre de mises en service par commune par jour.

III. Conclusion

La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation de cette zone se fait grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre aux utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de manipuler les données, détaillées ou agrégées, sans difficulté afin de satisfaire leurs besoins en analyse.

La finalisation de la conception d’une étoile de l’entrepôt, nous permet de passer à la construction de la zone d’alimentation. Cette zone d’alimentation constitue l’objet du prochain chapitre.

C

onception de la zone « alimentation »

I. Introduction

L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dans un projet Data Warehouse, elle représente 80% de la charge de travail. Cette étape a pour objectif d’assurer l’acheminement des données des systèmes sources jusqu’à l’entrepôt de données, en passant par les différentes phases de nettoyage et de transformations nécessaires.

La conception du processus d’alimentation nécessite les étapes suivantes :

• Etude et planification,

• Choix de l’architecture,

• Conception des processus de chargement :

o Processus de chargement des tables de dimension, o Processus de chargement des tables de faits, o Processus de chargement de table temps,

II. Etude et planification :

Cette phase représente une phase préliminaire à l’ensemble du processus. Elle consiste en :

• L’étude des sources de données,

• La détection des emplacements des données source,

• La Définition de la périodicité du chargement,

II.1 Les sources de données :

Les sources de données de notre entrepôt sont :

• Le système SGC, avec ses 35 modules (voire annexe C),

• Le système de gestion de la distribution HT/HP,

• Les fichiers plats, en provenance d’autres structures (pour les achats), ou d’organismes externes (le ministère des finances),

Les sources de données en chiffres:

• 58 sources de données, éparpillées sur l’ensemble du territoire national,

• Plus de 6 millions de clients,

• Plus de cent trente intégrations d’abonnés jour,

• Soixante-dix mille factures jour,

II.2 Détection des emplacements des données sources :

Afin de définir l’emplacement des informations dans les différents systèmes source et d’en choisir les emplacements les plus fiables, nous avons travaillé de manière étroite avec les DBA et les gestionnaires.

Le nombre important de tables, la redondance des données et l’intervention de différents systèmes, rendent cette tâche très ardue. Afin de mener à bien cette détection, nous devons :

• Lister les données nécessaires à partir des étoiles conçues,

• Lister les emplacements de chaque donnée,

• Choisir la source la plus fiable et la valider comme source de chargement,

• Dresser un tableau¹⁴ qui établi le lien entre données sources et donnée cibles avec les transformations nécessaires,

Cette étape s’achève par l’élaboration d’une carte logique entre données sources et données cibles¹⁵.

Il est important de valider les sources de données (donc le tableau cité précédemment), afin de vérifier leurs intégrités et leurs fiabilités.

II.3 Définition de la périodicité de chargement

La périodicité de chargement est étudiée pour chaque étoile séparément. , ce qui n’empêche pas une synchronisation dans les chargements des dimensions communes.

Avant de décider de la périodicité du chargement, les contraintes suivantes doivent être prises considération :

• La quantité de données à charger,

• Le temps de non activité des systèmes sources,

L’étoile qui engendrera les chargements les plus importants, en termes de volume, n’est autre que l’étoile des ventes. En effet, le système de facturation, établit annuellement plus de six millions de factures, ce qui représente plus de dix millions de lignes de faits

« ventes ». Ce processus s’exécute de façon journalière (soixante-dix mille lieux de consommation par jour). Aussi, le module de gestion des affaires (Système source) présente une forte volatilité de ses données. Cette volatilité est due au fait que le passage, d’une affaire donnée, d’une phase à une autre, ne laisse aucune trace sur la base de données opérationnelle.

14 Ce tableau est décrit dans le livre [Kimball 2004].

15 Voire Annexe D

De ce fait, l’idéal est de procéder à des chargements journaliers, pendant les heures de non activité des systèmes sources, c'est-à-dire, durant la période qui s’étend entre dix-huit heures et huit heures du matin.

Pourquoi pas des chargements hebdomadaires

Même si pendant les week-ends le nombre d’heures de non activité des systèmes est plus important, la quantité de données à charger sera, elle, plus conséquente, et affectera les performances du processus de chargement. Par ailleurs, la volatilité de certaines données nous contraint à appliquer une telle politique de chargement

III. Architecture du processus d’alimentation

L’élaboration d’une architecture du processus de l’alimentation « ETL » dès le début du projet est très importante. En effet, le choix d’une architecture affecte pratiquement toutes les composantes du projet. Tout changement de celle-ci engendrera nécessairement d’importants changements dans l’ensemble du projet.

Partant de ce constat, il est nécessaire de mettre en place une architecture consistante à même de prendre en charge toutes les contraintes auxquelles on doit faire face.

Le processus de l’ETL peut se faire de différentes manières. Dans le cas d’espèce nous avons choisi la méthode « Push-Pull ». En plus des avantages qu’elle présente, cette méthode pallie aux contraintes rencontrées au sein de l’entreprise et permet d’exploiter toutes les opportunités offertes. Parmi les contraintes et opportunités il peut être cité :

• L’impossibilité d’accès distant aux systèmes source : l’entreprise n’autorise pas des accès distants aux systèmes sources. L’accès se fera par le biais d’une base de données intermédiaire. Cette restriction est due à la structure organisationnelle de l’entreprise¹⁶.

• Les problèmes du réseau actuel¹⁷ : le réseau actuel subi des perturbations au niveau de quelques directions de distribution. Ces dernières ne sont pas encore équipées de connexion ADSL¹⁸.

• Le nombre important des sources de données et la quantité des données : Cette politique (push-pull) permettra le lancement de chargements parallèles.

• L’existence de serveurs au niveau sources : les cinquante-huit directions de distribution disposent de matériel informatique important, permettant de lancer des processus de préparation de données au niveau des « DD ».

• Maintenance facile: même si les sites sont éparpillés, la tâche d’une éventuelle maintenance sera facilitée par le biais des équipes informatiques en place.

16 Le découpage juridique de l’entreprise ne permet pas aux filiales de partager des informations d’une façon directe.

17 Voire annexe F.

18 Plus de quarante D.D sont équipées de connexion ADSL.

Pourquoi adopter cette architecture ?

Outre un chargement sûr, Cette architecture permet de:

• Réduire les temps de chargement : grâce au chargement parallèle, le temps de traitements sera réduit.

• L’impact réduit d’un chargement échoué : l’échec d’un chargement aura un impact réduit sur les données du Data Warehouse.

• La possibilité de mise en place d’une nouvelle façon d’accès : dans une architecture

« Push-Pull » il est préférable de faire un transfert de fichiers, par exemple via FTP.

cette méthode très performante « testée » est difficile à déployer, elle sera donc mise en perspective. La figure suivante illustre l’architecture du processus d’alimentation adoptée :

Figure II.27 : Architecture globale du processus E.T.L.

Dans la zone de préparation« Staging area » les données sont extraites à partir des sources de données, transformées et préparées pour le chargement final. Au niveau du serveur « ELIT » il est procédé à l’affectation de clés artificielles et à quelques transformations nécessaires avant le chargement final dans la zone d’entreposage. Après chaque chargement, une mise à jour des Meta Data doit être faite.

IV. Processus de chargement

Le diagramme d’activités suivant décrit le processus général de l’alimentation de l’entrepôt de données dés sa mise en service :

Figure II.29 : Diagramme d’activité du processus d’alimentation.

Deux types de tables dans l’entrepôt de données « faits, dimensions » doivent être distingués. Chaque type de table diffère dans les d’informations qu’il contient, et d’où donc l’adoption de deux processus de chargement.

La stratégie d’extraction adoptée consiste à comparer des chargements successifs afin de détecter les changements. Cette stratégie, étant la plus fiable, est incontournable pour la capture des changements pour des raisons de non fiabilité des champs date, généralement non renseignés. Cette détection se fait au niveau de la zone de préparation améliorant sensiblement les performances.

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_activite

libele_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,

Ce diagramme représente, de manière claire, la structure de l’entrepôt de données,

Dans le document Mémoire de fin d études. Thème Conception et réalisation d un Data Warehouse pour la mise en place d un système décisionnel (Page 107-0)