République de Côte d’Ivoire

Année académique : 2022 - 2023

Ministère de l’Économie Numérique et de
la Poste

Master of Science eBIHAR de l’ESTIA

Stage en entreprise

oinfoiensifonoisfiof
OPTIMISATION DE L’ETL POUR UNE REPRISE
EFFICACE DES DONNEES HISTORIQUES DANS
LE DATAWAREHOUSE DE LA SOCIETE
GENERALE CAMEROUN

Du 01 mars 2023 au 28 août 2023

Proposé par
VOUHO Jonathan Ange-Emmanuel

Encadrant Académique : Maître de stage :

Dr. KONAN Hyacinthe Mr. BOSSON Wilfried
 République de Côte d’Ivoire

Année académique : 2022 - 2023

Ministère de l’Économie Numérique et de
la Poste

Master of Science eBIHAR de l’ESTIA

Stage en entreprise

Du 01 mars 2023 au 28 août 2023

Proposé par
VOUHO Jonathan Ange-Emmanuel

Encadrant Académique : Maître de stage :

Dr. KONAN Hyacinthe Mr. BOSSON Wilfried
DEDICACE

A ma famille

I
 REMERCIEMENTS

Un travail intellectuel, est le concours de plusieurs interventions. Ce présent mémoire

n’y échappe pas. C’est pourquoi nous ne pourrions continuer sans remercier ces
personnes sans lesquelles ce mémoire n’aurait pu se réaliser :

• Medani TEWFIK, Directeur Général de SGABS Abidjan,

• Desiré NTAMACK, Manager du service Bureau technique pour son accueil
• Wilfried BOSSON, notre encadreur professionnel ;
• L’ensemble de l’équipe du Bureau Technique.

Nous tenons également à remercier tout le personnel académique et technique de

l’ESATIC grâce auquel nous avons effectué notre cursus. Il s’agit notamment de :

• Professeur KONATE Adama, Directeur général de l’ESATIC, pour toutes ses

actions effectuées dans le but de faire de l’ESATIC une école rayonnante et ainsi
permettre aux étudiants d’être compétitifs sur le marché de l’emploi.
• L’ensemble du corps administratif de l’ESATIC, pour la formation académique
et humaine dispensée durant notre parcours ;
• Dr Konan Hyacinthe, enseignant-chercheur à l’Ecole Supérieure des
Technologies de l’Information et de la Communication, Notre encadrant
académique pour son soutien moral et intellectuel, ainsi que la correction de ce
document ;

• Nos remerciements vont aussi à notre famille, pour son soutien, ses
encouragements, et ses sacrifices durant toute notre cursus scolaire et
académique ;

Enfin, nous remercions tous ceux qui, de près ou de loin ont contribué à notre
accomplissement personnel et professionnel ;

II
 SOMMAIRE

DEDICACE................................................................................................................................................ I
REMERCIEMENTS ................................................................................................................................ II
SOMMAIRE ............................................................................................................................................ III
ABREVIATIONS ..................................................................................................................................... V
LISTE DES TABLEAUX ....................................................................................................................... VI
LISTE DES FIGURES ........................................................................................................................... VII
INTRODUCTION ...................................................................................................................................... 1
PARTIE 1 : PRESENTATION DU STAGE ....................................................................................................... 1
Chapitre 1 : Contexte.............................................................................................................................. 3
I. Historique ................................................................................................................................... 3
II. Présentation de l’entreprise ........................................................................................................ 4
Chapitre 2 : Problématique ..................................................................................................................... 7
I. Domaine ..................................................................................................................................... 7
II. Problème à résoudre ................................................................................................................... 7
III. Objectifs.................................................................................................................................. 8
Partie 2 : Concepts théoriques et état de l’art ....................................................................................... 3
Chapitre 3 : Concepts du Datawarehouse ............................................................................................. 10
I. Les composants de base du Datawarehouse ............................................................................. 10
II. Processus de base du Datawarehouse ....................................................................................... 12
Chapitre 4 : La gestion du projet .......................................................................................................... 14
I. La méthode du cycle de vie du projet BI par Ralph Kimball [3] ............................................. 14
II. La méthodologie GIMSI........................................................................................................... 17
III. Choix de la méthodologie de gestion de projet .................................................................... 19
Partie 3 : Analyse du système existant .................................................................................................. 10
Chapitre 5 : Etude de l’existant ............................................................................................................ 21
I. Présentation du système existant .............................................................................................. 21
Chapitre 6 : Résultats de l’étude de l’existant ...................................................................................... 34
I. ETL........................................................................................................................................... 34
II. La base de données Datawarehouse ......................................................................................... 34
Partie 4 : Conception et mise en œuvre ................................................................................................ 21
Chapitre 7 : Conception ........................................................................................................................ 37
I. Optimisation de la base de données Datawarehouse ................................................................ 38
II. Optimisation des ETL .............................................................................................................. 39
Chapitre 8 : Mise en œuvre .................................................................................................................. 40

III
 I. Environnements de travail et choix des outils d’implémentation............................................. 40
II. Réalisation et déploiement des solutions .................................................................................. 41
III. Résultats et coûts du projet ................................................................................................. 44
CONCLUSION ........................................................................................................................................ 45
BIBLIOGRAPHIE .................................................................................................................................... XI
WEBOGRAPHIE ..................................................................................................................................... XII
TABLE DES MATIERES .............................................................................................................................. XIII
RESUME ................................................................................................................................................XVI
ABSTRACT ...........................................................................................................................................XVI

IV
 ABREVIATIONS

B
BI : Business Intelligence ;
BO : Business Object ;
D
DWC : Projet Datawarehouse Cameroun
E
ETL : Extract Transform Load ;
G
GIMSI : Généralisation Information Méthode et Mesure Système et Systémique
Individualité et Initiative
J
JH : Jour/Homme ;
O
ODBC : Open Database Connectivity;
S
SG : Société Générale ;
SGCAM : Société Générale Cameroun ;
SSMS : SQL Serveur Management studio;
SSDT : SQL Server Data Tools ;
SSIS : SQL Server Integration Services
T
TFJ : Traitement de Fin de Journée

V
 LISTE DES TABLEAUX
Tableau 1: Etapes de la méthodologie GIMSI .......................................................................................... 17
Tableau 2: Critères de choix de la méthode de gestion du projet ........................................................... 19
Tableau 3:Comparaison des deux méthodologies de gestion de projet .................................................. 19
Tableau 4: Architecture technique du Datawarehouse ........................................................................... 21
Tableau 5: Contrainte d'intégrité sur les tables ....................................................................................... 25
Tableau 6: Contraintes d'intégrité sur les colonnes ................................................................................. 25
Tableau 7: Type de données..................................................................................................................... 26
Tableau 8:Description de l'ETL journalier................................................................................................. 28
Tableau 9: Description de l'ETL mensuel .................................................................................................. 29
Tableau 10: Comparaison modèles dimensionnel et entité-relation....................................................... 31
Tableau 11: Interactions entre les relations............................................................................................. 31
Tableau 12: Analyse des scénarios ........................................................................................................... 32
Tableau 13: Pistes d'amélioration ETL...................................................................................................... 34
Tableau 14: Pistes d'amélioration Datawarehouse.................................................................................. 35
Tableau 15: Architecture technique de la nouvelle infrastructure .......................................................... 37
Tableau 16: Matrice de l'architecture du Datawarehouse ...................................................................... 38
Tableau 17: Ordre de lancement des containers ..................................................................................... 39
Tableau 18:Résultats de l'optimisation des ETL du Datawarehouse ....................................................... 44
Tableau 19: Coûts du projet DWC ............................................................................................................ 44

VI
 LISTE DES FIGURES

Figure 1: Organigramme de SG ABS Abidjan .............................................................................................. 5

Figure 2:Architecture du Datawarehouse ................................................................................................ 10
Figure 3: Schéma du cycle de vie dimensionnel ....................................................................................... 14
Figure 4: : Architecture du Datawarehouse ............................................................................................. 21
Figure 5: Contrainte de priorité sur les packages SSIS ............................................................................. 22
Figure 6: Contrainte de container de séquence sur les packages SSIS .................................................... 23
Figure 7: Modèle de synthèse de la base de données ............................................................................. 24
Figure 8: Fonctionnement global ETL journalier ...................................................................................... 27
Figure 9: Fonctionnement global ETL mensuel ........................................................................................ 29
Figure 10: Diagramme de la table des faits Opérations étrangères......................................................... 38
Figure 11: principe de chargement des ETL ............................................................................................. 39
Figure 12: Capture d'écran du menu SSMS .............................................................................................. 41
Figure 13: capture de la création de la BD de SSIS ................................................................................... 42
Figure 14: capture de l'interface SSIS sous visual studio.......................................................................... 42
Figure 15: capture du déploiement de la solution ................................................................................... 43
Figure 16: capture des scripts batch créés ............................................................................................... 43

VII
 INTRODUCTION

Les données engendrées, qualifiées puis analysées par une entreprise lui permettent
d’affiner sa stratégie commerciale, avec pour bénéfice un meilleur positionnement sur le
marché. De nos jours, nombreuses sont celles qui ont opté pour la technologie du
datawarehouse, ou entrepôt de données comme outil d’aide à la décision. Ce dernier qui
se matérialise par une infrastructure à but analytique, tire son alimentation des sources
de données variées de l’entreprise. Par conséquent, il importe qu’un processus soit mis
en place en vue d’Extraire les données des sources diverses, de les nettoyer et les
transformer dans le but de les unifier et les rendre compatibles à la destination et enfin
de charger ledit datawarehouse. Ce processus ainsi décrit se nomme ETL (Extract
Transform Load).
La Société Générale, consciente de l’importance de l’analyse des données dans ses
activités à mis en place en 2005 un datawarehouse au sein de sa filiale camerounaise.
Cependant, avec le temps et les différentes avancées technologiques, l’infrastructure
actuelle tend à l’obsolescence technique et applicative, mettant ainsi en danger les
activités de la banque. Dans ce cadre, a été initié le projet de migration du
datawarehouse Cameroun (DWC), consistant à migrer non seulement le socle technique
et applicatif de l’entrepôt vers des versions plus récentes et plus performantes, mais
également l’ensemble des données qui y sont contenues. C’est ainsi que nous nous
sommes vu attribuer le thème : « Optimisation d’un ETL avec reprise des données
historiques : Cas du Datawarehouse de la SOCIETE GENERALE CAMEROUN ». De
ce fait, comment mettre en œuvre cette opération qui permettra d’alimenter la nouvelle
structure sans altérer la qualité des données?
Il s’agit en effet pour nous :

• D’étudier la structure de la base de données du Datawarehouse

• D’étudier le fonctionnement des ETL depuis les chargements aux sources de
données, jusqu’aux types de tables qui sont chargées;
• De proposer un modèle adéquat pour la base de données Datawarehouse;
• De suggérer un meilleur processus de chargement du Datawarehouse;
• De repeupler la nouvelle structure avec les anciennes données en s’assurant que
leur volumétrie reste inchangée.
Le présent document qui présente notre contribution au projet s’articule autour de
quatre parties successives. La première s’évertue à présenter le contexte de notre étude
et la problématique qui en découle. La deuxième partie quant à elle est consacrée aux
concepts théoriques du datawarehouse et fera l’état de l’art. La troisième partie, se base
sur une présentation du système existant puis sur son analyse afin d’en ressortir ses
anomalies. Enfin la quatrième partie est celle de la conception et la mise en œuvre de
notre projet.

1
 PARTIE 1 : PRESENTATION DU STAGE

Cette partie du document aborde le contexte dans lequel l'étude a été réalisée, ainsi que
les questions soulevées par le sujet. Elle est divisée en deux chapitres. Le premier
chapitre situe le contexte du thème en présentant d'abord l'historique de l'informatique
décisionnelle et des migrations de données, puis en décrivant la structure d'accueil. Le
deuxième chapitre soulève les problèmes qui doivent être résolus dans le cadre de notre
réflexion.
Chapitre 1 : Contexte

L’objectif de ce chapitre est de situer le choix d’étude. Elle comprend l’historique et la

structure d’accueil.
I. Historique
Les dirigeants d'entreprise se posent de nombreuses questions sur les activités de leur
structure, notamment sur la connaissance des clients et la compétitivité de l'entreprise
sur le marché. Pour obtenir ces informations, de plus en plus d'entreprises se tournent
vers le traitement et l'exploitation des données qu'elles génèrent. Ces données se
présentent sous deux formes : les systèmes opérationnels gérant les flux de données
quotidiens et le Datawarehouse.
Le Datawarehouse est une base de données regroupant les données fonctionnelles d'une
entreprise. Il fait partie de l'informatique décisionnelle et vise à fournir un ensemble de
données de référence utilisées pour la prise de décisions grâce à des statistiques et des
rapports générés par des outils de reporting. Il permet également de soulager les bases
de données opérationnelles en évitant des requêtes susceptibles de nuire à leurs
performances.
L'origine du Datawarehouse remonte aux années 60 avec un projet impliquant General
Mills et l'université de Dartmouth, où la modélisation dimensionnelle a été abordée pour
la première fois. En 1983, Teradata introduit un système exclusivement dédié à la prise
de décisions dans sa base de données managériale, suivi par d'autres entreprises qui
mettent en place des systèmes décisionnels. Le terme "Datawarehouse" est ensuite
employé par Barry Devlin et Paul Murphy.
Plusieurs ouvrages, tels que "Building the Data Warehouse" de Bill Inmon en 1991 et
"The Data Warehouse toolkit" de Ralph Kimball en 1996, contribuent à l'engouement
des entreprises pour la construction de Datawarehouses dans leur stratégie
décisionnelle.
Cependant, les Datawarehouses font partie de l'infrastructure informatique de
l'entreprise et peuvent devenir obsolètes sur le plan technologique et applicatif, ce qui
nécessite des migrations vers de nouveaux systèmes avec des améliorations.
Société Générale Cameroun, une entité du groupe bancaire Société Générale, s'est dotée
d'un Datawarehouse dans le cadre de sa stratégie décisionnelle. Le projet de mise en
place de cet entrepôt de données a été confié à la Société Générale African Business
Services (SGABS), où nous avons effectué notre stage et contribué à un chantier de
migration, en optimisant les ETL et en reprenant les données historiques.

3
II. Présentation de l’entreprise
L’entreprise Société Générale African Business Services (SG ABS) est une filiale du
groupe SOCIETE GENERALE. Fondée en 2019, elle a pour vocation de fournir aux
filiales du groupe les services du domaine des technologies de l’information en Afrique.
Elle est issue de la fusion des Centres de Services Mutualisés CSM qui étaient présents
à Dakar, Douala et Abidjan, chargés auparavant de la direction opérationnelle des
systèmes d’information sur le continent. Elle fait suite à la stratégie du groupe de mettre
en place un hub technologique, référencé en matière d’IT bancaire. SGABS est basée
sur ses deux sites, celui de Casablanca au Maroc et d’Abidjan, en Côte d’Ivoire. Forte
de plus de 500 collaborateurs, elle a sa tête HERNEST KUETCHE, le Directeur
Général. Le site de SGABS nous ayant accueilli durant notre stage est celui d’Abidjan.
1. Les domaines d’activités et missions de SG ABS Abidjan
La mission principale des collaborateurs de SG ABS Abidjan est la gestion du système
bancaire de base ou Core Banking System (CBS), le logiciel prenant en charge les
transactions de la banque. Ainsi, les différents métiers de SG ABS Abidjan sont la
maintenance, les traitements, et l’exploitation du CBS. Cette fonction se décline en
plusieurs missions qui sont :

• La résolution des besoins clients en matière de demande technologique ;

• La prévoyance et le traitement des menaces de cyber sécurité ;
• La gestion les infrastructures bancaires du périmètre ;

• L’étude et développement de projets.

Tout ceci, en faveur des filiales Africaines du groupe SG. La clientèle de SG ABS
Abidjan se situe dans un périmètre de12 filiales qui sont :
• SGCI (Côte d’Ivoire) ;
• SGCAM (Cameroun) ;
• SGBF (Burkina Faso) ;
• SGG (Guinée Conakry) ;
• SGM (Mauritanie) ;
• SGT (Tchad) ;
• SGTG (Togo) ;
• SGB (Bénin) ;
• SGGH (Ghana) ;
• SGC (Congo) ;
• SGSN (Sénégal) ;
• BFV-SG (Madagascar) ;

4
 2. Organisation de SGABS Abidjan
Les différents métiers de SG ABS Abidjan sont structurés, selon leur domaine d’activité,
suivant ce qu’on appelle des Business Unit. Ainsi, nous distinguons pour cette filiale
l’organigramme présenté à la figure 1 :

Figure 1: Organigramme de SG ABS Abidjan

Le site de SG ABS Abidjan est divisé en domaines, regroupant en leur sein des services.
• Le support
Il comprend tous les différents services qui coordonnent le bon fonctionnement de SGABS. Il
s’agit des ressources humaines, du support informatique et du Desk, dont les membres sont les
gestionnaires de l’outil de création, de suivi des tickets nécessaires à la supervision des
demandes de services émis dans le cadre des activités de l’entreprise.

• Les infrastructures et production

- Gestionnaire d’application

Il s’agit du premier métier impliqué dans la gestion du CBS, il est chargé de son paramétrage, de
la mise en place de nouvelles transactions et de la gestion et résolution des incidents pouvant s’y
déclarer.

- L’exploitation

C’est un service chargé du monitoring et de la gestion des incidents lors des traitements de fin de
journées, des scripts et autres jobs, s’effectuant sur les bases de données du CBS. Mais
également de de la gestion des environnements techniques.

- Le Bureau technique

Il a en charge le maintien en condition opérationnelle des environnements de production et

d’homologation par les installations du socle technique. Ses charges quotidiennes sont entre
autres l’évaluation technique et la préparation des environnements lors de projets, les différentes
installations sur ceux-ci, et enfin la gestion des incidents sur les environnements.

5
 • La Testing Factory

C’est une usine de test logiciel ayant pour but la sécurisation des Mises en production et la
réduction des budgets projets. Il se scinde en deux : le front office et le back office.

- Front Office

Le front Office est constitué de chefs de projets tests chargés de la gestion du portefeuille
projet et de l’arbitrage durant le déroulement des tests.

- Back Office

Il est constitué d’ingénieurs chargés d’effectuer les tests par des processus
d’automatisation. Ils ont également comme tâche la gestion des environnements de tests
et des données de tests.

• Les Etudes et Développement

- La gestion des spécifiques

Ce service est chargé de l’étude et du développement des applications satellites dont les
filiales ont besoin, en parallèle du système cœur bancaire. Ils ont également en charge, leur
maintien et gestion des incidents sur ces dernières.

- Le Reporting et Editique

✓ L’Editique

Ce domaine se définit comme l’ensemble des processus, flux et moyens informatiques mis en
œuvre et appliqués à l’édition massique de documents. Ces documents peuvent être des
bordereaux, des factures, des mails personnalisés pour les clients des filiales.

✓ Le Reporting

Le but de cette activité est la production, l’analyse et la restitution de données et d’indicateurs

dont les traitements concourent à une meilleure prise de décision grâce à la compréhension de
l’évolution des activités et une meilleure prise de décisions. Pour ce faire, les ingénieurs du R/E
ont recourt à des outils de Reporting. En parallèle, ils sont impliqués dans le pilotage et la
réalisation de Business intelligence et Data.

• Outils du Reporting

Lors de ses activités, il a recours aux interfaces SQL pour l’exécution de scripts sur les bases de
données opérationnelles. Mais aussi d’outils BI tels que Power BI ou Business Object (BO).
C’est d’ailleurs BO qui est l’outil de datavisualisation employé afin de restituer les données du
Datawarehouse, notamment celui de la SG CAM.

6
Chapitre 2 : Problématique

Cette section présente la problématique dans laquelle s’inscrit notre sujet, et définit
les objectifs que nous nous fixerons dans la suite de l’étude.

I. Domaine

Le travail que nous avons réalisé au cours de notre stage s’inscrit dans le cadre du projet
de migration de l’infrastructure technique et applicative du Datawarehouse de la Société
Générale Cameroun. L’infrastructure actuelle étant vieillissante, les serveurs ont été
migrés vers de nouveaux, avec l’installation de versions applicatives plus récentes.
Notre contribution à ce travail a été l’optimisation des chargements Quotidiens et
mensuels de la base de données et la reprise de ces données historiques.

II. Problème à résoudre

Une migration en informatique est le passage d’un état existant d’un système
d’information ou d’une application vers une cible, dans le cadre d’un projet. Elle est
nécessaire lorsque les organisations procèdent au changement de système informatique
ou à leur mise à niveau. De plus, une migration peut également impliquer, comme dans
notre cas, une migration des données.
Dans un Datawarehouse, la disponibilité des données est très importante car elles
servent de base à l’analyse des décideurs afin d’orienter leurs choix. C’est ainsi que les
chargements de la base de données ont été optimisés, afin de réduire le temps de
traitement. Ces améliorations s’effectuent suivant deux aspects :

• L’optimisation des processus en charge de l’Extraction, la Transformation et le

traitement des données dans la base ;
• L’amélioration de la base de données en vue de réduire le temps de restitution
des données lors de la phase d’analyse par les utilisateurs.
Toujours dans la perspective d’amélioration des performances du système existant, il est
nécessaire d’effectuer une migration correcte des données. En effet, la structure de la
base de données sera modifiée. Il faudra donc veillez à corriger les inexactitudes et
incohérences pouvant survenir lors du changement. C’est la raison pour laquelle il
importe d’assurer la reprise des données historiques du Datawarehouse.

7
 III. Objectifs

Les différents problèmes de la migration applicative et technique du Datawarehouse de

la Société Générale Cameroun ayant été soulevés, nous avons définis nos objectifs dans
le cadre de la résolution de ceux-ci.
L’objectif principal de notre contribution est l’amélioration de la disponibilité des
données lors des analyses effectuées par les utilisateurs du Datawarehouse. Ce dernier
se décline en objectifs spécifiques qui sont:
• L’amélioration du temps des chargement mensuel et journalier du
Datawarehouse ;
• L’optimisation du temps de réponse du Datawarehouse à la suite de requêtes ;
• La restitution totale des données présentes sur l’ancien serveur ;
• La gestion de la qualité des données.

8
 Partie 2 : Concepts théoriques et état de l’art

Le but de cette partie est de définir les notions relatives à notre thème, en vue de mieux le
cerner. Elle est constituée de deux chapitres. L’un sur les concepts de datawarehouse,
l’autre sur la méthodologie à adapter pour la gestion d’un tel projet de BI.
Chapitre 3 : Concepts du Datawarehouse

Un Datawarehouse est une base de données relationnelle, consolidant les données de

sources hétérogènes : Bases de données relationnelles et non relationnelles, fichiers
plats, ERP etc. A la différence des bases de données opérationnelles qui stockent les
intrants liés à l’activité d’une entreprise, il est utilisé en vue de l’analyse des données
relatives à ses activités et aide au processus de prise de décision.
Selon Bill INMON, l’un des précurseurs de la discipline, le concept de Datawarehouse
est régi par des caractéristiques distinctes. L’orientation sujet, l’évolution temporelle, la
non-volatilité, et l’intégrabilité. [2]
• L’orientation-sujet : Les données présentes dans la base de données sont
organisées selon un thème, un sujet, plutôt que des indications succinctes sur les
activités en cours de l’entreprise.
• L’évolution temporelle : Les données enregistrées dans un Datawarehouse sont
référencées, de manière explicite ou implicite en fonction d’une unité temporelle
(jour, mois, année etc.), offrant ainsi des informations d’un point de vue
historique.
• La non-volatilité : Les données d’un Datawarehouse ne sont pas destinées à être
supprimées. Les opérations qui y sont autorisées sont le chargement et l’accès
aux données.
• L’intégrabilité : Les données similaires, bien que provenant de sources éparses,
sont uniformisées, afin de correspondre à une même unité de mesure. De plus,
ces données sont stockées dans le Datawarehouse en suivant une modélisation
dite dimensionnelle.

I. Les composants de base du Datawarehouse

Le Datawarehouse respecte une structure qui est présentée dans la figure 2

Figure 2:Architecture du Datawarehouse

10
 1. Le système source

Il s’agit des applications de gestions de gros systèmes qui génèrent des données. Leur
but est l’enregistrement des transactions liées à l’activité. Les données y sont peu
historisées et ne sont pas adéquates à la génération d’états.
2. La zone de préparation des données

Elle est constituée de l’ensemble des processus d’extraction de données vers les sources,
de nettoyage et transformation en vue de leur intégration dans le serveur de présentation
des données. Cette zone est le théâtre d’opérations de tris et de traitements séquentiels et
ne nécessite pas obligatoirement d’être basée sur les technologies relationnelles.
3. Serveur de présentation du Datawarehouse

Il s’agit de la machine cible sur laquelle est stocké l’entrepôt de données. Elle est
soumise aux requêtes émises par les utilisateurs, les générateurs d’états etc. Si l’entrepôt
de données repose sur un SGBD relationnel, alors les données présentes sur ce dernier
seront stockées sous forme dimensionnelle. Les tables sont alors organisées sous la
forme de schéma en étoile.
4. Modèle dimensionnel

C’est une manière de modéliser les données, comme pourrait le faire le modèle entité
relation par exemple. Par ailleurs, il contient les mêmes informations que ce dernier. La
différence réside dans le fait que premièrement dans le modèle dimensionnel, les
données ne sont pas organisées sous la forme d’entités et de relations qui les lient mais
plutôt comme des faits associés à leurs dimensions. Et deuxièmement, dans le modèle
dimensionnel, les données ne sont pas normalisées.

• Les tables de faits :

Elles contiennent les données destinées à mesurer l’activité d’une entreprise. Ce
sont des valeurs généralement de nature numérique et cumulative.
• Les tables dimensionnelles :
Elles accompagnent les tables de fait et sont dotées de clés primaires assurant
l’intégrité référentielle avec la ou les tables de faits auxquelles elles sont liées.
Elles contiennent des attributs textuels décrivant les activités et portent les
conditions des requêtes effectuées par les utilisateurs.

11
5. Datamart et entrepôts de données

Un datamart est un sous-ensemble logique d’un entrepôt de données. Il représente un

processus métier en particulier. L’entrepôt de données est la réunion de tous les
datamarts qui le composent. Cependant, les datamarts doivent respecter des dimensions
conformes afin que l’ensemble final soit cohérent.
6. OLAP

Online Analytic Processing désigne une technologie non relationnelle et basée sur un
cube de données multidimensionnel. Une base de données OLAP ou
multidimensionnelle est une base dans laquelle les données sont présentées sous
plusieurs dimensions.
7. ROLAP

Ce sont les applications, interfaces utilisateurs qui s’appuient sur des bases de données
relationnelles tout en leur donnant une vision dimensionnelle.
8. MOLAP

Il s’agit d’applications, d’interfaces utilisateurs et de technologies de bases de données

propriétaires dont l’aspect dimensionnel est évident.

9. Outil d’accès aux données

Il s’agit d’un client de l’entrepôt de données. Ce dernier maintient une session auprès du
serveur de présentation en envoyant un flux de requêtes SQL.
II. Processus de base du Datawarehouse

1. ETL

Il concerne la préparation des données avant leur insertion dans l’entrepôt de données. Il
comprend les étapes suivantes :

• L’extraction
C’est l’étape de récupération des données dans le système source.

12
 • La transformation
Les données extraites se retrouvent la zone de préparation des données. S’en
suivent alors plusieurs étapes de transformation, à savoir :
- Le nettoyage des données (correction des fautes d’orthographe,
conversion de données)
- La purge des champs du système transactionnel, inutiles au système
décisionnel ;
- Création de clés de substitution pour les enregistrements dimensionnel et
leurs équivalents (clés étrangères) dans les tables des faits ;
- Construction des agrégats pour l’optimisation de la performance des
requêtes.

• L’alimentation et l’indexation
A la fin des différentes transformations, les données sont prêtes à être chargées
dans l’entrepôts, au sein des tables de faits et de dimensions. Par la suite les
données sont indexées en vue d’optimiser les requêtes.

2. Contrôle qualité et sécurisation

Il est important de pouvoir vérifier que les données chargées dans le Datawarehouse
sont cohérentes avec celles déjà enregistrées. De plus, Il faut limiter l’accès de
l’entrepôt aux personnes qui n’y sont pas autorisées.

3. Sauvegarde et restauration

En cas d’incident, il serait judicieux d’avoir accès aux données depuis une zone de
sauvegarde.

13
Chapitre 4 : La gestion du projet

I. La méthode du cycle de vie du projet BI par Ralph Kimball [3]

Le cycle de vie dimensionnel a vu le jour chez Metaphor Computer Systems au milieu

des années 80. C’est une entreprise pionnière dans le développement de systèmes
décisionnels. A cette époque, la notion de Datawarehouse n’était pas encore d’actualité.
Les auteurs de cette méthodologie, employés chez Metaphor l’ont mise en place afin de
répondre au besoin de mettre en place une pratique industrielle optimale et une
méthodologie officielle de gestion de projets décisionnels. Ses concepts de base sont
toutefois restés stables au fil des années et cette méthodologie continue d’être appliquée
aujourd’hui.
L’approche globale de l’implémentation d’entrepôts de données par le cycle de vie
dimensionnel est illustrée dans la figure suivante. Cette dernière représente une
succession de macro-tâches nécessaires à la conception, au développement, et au
déploiement de Datawarehouse efficaces. Elle souligne les contraintes tant au niveau
technologique qu’au niveau des données et des applications. La figure 3 ci-dessous en
schématise les macro-étapes.

Figure 3: Schéma du cycle de vie dimensionnel

14
1. Planification du projet

La première étape est la planification du projet. Elle permet de définir le projet et de

donner sa portée. Elle justifie l’importance de sa réalisation dans l’entreprise et la
capacité de le mettre en place. Dans cette partie, il est également question d’identifier les
ressources nécessaires à la mise en place du projet, planifier les tâches de ces dernières et
l’ordre dans lequel ces tâches seront effectuées. Elle dépend de la définition des besoins.

2. Définition des besoins

Cette phase consiste à interroger les futurs décideurs de l’entreprise ainsi que les
utilisateurs finaux du Datawarehouse. Elle exprime les besoins analytiques qu’auront
ceux-ci. La définition des besoins est très importante afin de choisir quel type de
données sera nécessaire aux besoins des utilisateurs.
3. Modélisation dimensionnelle

Il s’agit ici d’identifier les données dont ont besoin les utilisateurs pour faire leurs
analyses. La première étape consiste à mettre en place une matrice couplant les
processus métiers et leurs dimensionnalités. Il faudra ensuite analyser les différentes
sources de données opérationnelles, qui couplée à la définition des besoins serviront de
base à la conception du modèle dimensionnel. Ce modèle identifie la granularité de la
table des faits, les dimensions associées, les attributs, et leur hiérarchisation. L’étape
actuelle est complétée par les relations appropriées entre les structures des tables et les
clés principales et extérieures.
4. Conception du modèle physique de données

Il s’agit de mettre en œuvre les structures physiques nécessaires à l’implémentation de

la base de données logique. Cela passe par la détermination des règles de nommage, le
plan d’indexation, le partitionnement.
5. Conception et développement des ETL

Le processus de préparation des données se déroule en trois étapes qui sont :

L’Extraction, la Transformation et le Chargement. La première étape qui consiste à
extraire les données des sources opérationnelles doit se faire de manière répétée. C’està-
dire qu’il faut prévoir l’extraction de peuplement de l’entrepôt et une seconde pour les
chargements réguliers. Cette étape est toujours suivie du nettoyage des données et de
leur transformation en vue de garantir la qualité des données.
6. Définition de l’architecture technique
C’est une étape qui donne la vision globale de l’infrastructure technique qui sera mise
en œuvre. Elle prend en compte trois aspect : la définition des besoins, l’architecture
technique existante, et les orientations techniques qui ont été planifiées.
15
7. Choix techniques et mise en œuvre

Cette phase implémente les choix qui auront été faits dans la définition de l’architecture
technique
Il s’agit de mettre en place les infrastructures matérielles, le système de gestion de base
de données, les outils ETL. Ces différents outils auront fait l’objet de comparaison sur
une même base et le choix sera suivi de plusieurs phases de tests. Une fois les produits
testés, ceux-ci devront être évalués.
8. Développement de l’application utilisateur

Il s’agit de faire le choix d’une application utilisateur, étant donné que ceux-ci ne
devraient pas avoir accès à l’entrepôt. Elle devra répondre aux besoins analytiques des
décideurs, en leur fournissant les interfaces nécessaires à leurs besoins.
9. Le déploiement

Il est le point de convergence des activités de développement. Il met en commun la

technologie, les données et les applications utilisateurs, accessibles depuis un poste de
travail. En outre, il est important de mettre à disposition des utilisateurs des processus
de communication, un support utilisateurs et la prise en compte de leurs demandes de
maintenance et croissance.
10. Maintenance et croissance

Après avoir déployé l’entrepôt des données, il est nécessaire d’assurer un

accompagnement aux utilisateurs en les formant à l’utilisation des outils, en leur
fournissant également un support utilisateurs. Aussi, il importe de mettre en place une
évaluation et un suivi des performances des processus de chargements de l’entrepôt.
Enfin, il faudrait entrevoir des perspectives d’évolutions en hiérarchisant des processus
de priorités se basant sur les demandes de l’utilisateur en termes de demande
d’évolution et de croissance.

16
 11. La gestion du projet

Elle garantit que les activités du cycle dimensionnel suivent le bon plan. Ses activités
sont étalées tout au long du cycle de vie. Ces dernières concernent le contrôle de l’état
d’avancement du projet, la détection et la résolution des problèmes et le contrôle des
changements afin de rester dans la limite des objectifs et du périmètre. Enfin, la gestion
du projet inclut le développement d’un plan de communication détaillé abordant à la
fois les services informatiques et utilisateurs.
II. La méthodologie GIMSI

[4]GIMSI (Généralisation Information Méthode et Mesure Système et Systémique

Individualité et Initiative) est une marque déposée d’Alain Fernandez. Elle définit un
cadre méthodologique permettant de mettre en œuvre des projets de business
intelligence centrés sur la problématique du tableau de bord. Elle adopte une démarche
coopérative qui met en avant les décideurs afin de mieux s’aligner selon leur vision.
Cette méthodologie permet l’analyse du risque en cas de doutes lors d’une prise de
décision. Elle comprend dix étapes, traitant chacune d’une préoccupation du projet. Ces
étapes sont structurées autour de quatre phases afin de faciliter l’étude. Ces phases
s’enchaînent de façon autonome.
Le tableau1 permet de présenter de manière synthétique les étapes de GIMSI.
Phase N° Etape Objectifs
Identification 1 Environnement de Analyse de l’environnement économique et de la
l’entreprise stratégie de l’entreprise afin de définir le périmètre et la
portée du projet
2 Identification de Analyse des structures de l’entreprise pour identifier les
l’entreprise processus, activités et acteurs concernés
Conception 3 Définition des Sélection des objectifs tactiques de chaque équipe
objectifs
4 Construction du Définition du tableau de bord de chaque équipe
tableau de bord
5 Choix des Choix des indicateurs en fonction des objectifs choisis
indicateurs
6 Collecte des Identification des informations nécessaires à la
informations construction des indicateurs
7 Le système de Construction du système de tableaux de bord, contrôle
tableau de bord de la cohérence des indicateurs
Mise en œuvre 8 Le choix des Elaboration de la grille de sélection pour le choix des
progiciels progiciels adéquats
9 Intégration et Implantation des progiciels, déploiement à l’entreprise
déploiement
Amélioration permanente 10 Audit Suivi permanent du système
Tableau 1: Etapes de la méthodologie GIMSI

Ces dernières sont regroupées selon les phases que nous définissons à présent.

17
1. L’identification

Elle fait l’étude de l’environnement stratégique de l’entreprise et sa structure interne.

C’est elle qui définit le contexte du projet. Cette phase comprend les étapes 1 et 2.
Durant le déroulement du projet, la communication est assurée entre les différentes
parties grâce à la production de documents de synthèse. Chacun doit connaitre les
enjeux, les poids de contrainte.
2. La conception

Elle comprend les étapes 3, 4, 5, 6 et 7, et définit les objectifs tactiques qui permettront
de concevoir le tableau de bord ainsi que les indicateurs sur lesquels se baseront les
futures analyses. La suite sera consacrée à la collecte des informations nécessaires au
tableau de bord.
3. Mise en œuvre

Les objectifs et les indicateurs étant définis, les données collectées, il est
question dans cette phase de choisir un progiciel du marché répondant
spécifications fournies. Ensuite viendra l’étude de l’intégration et du
déploiement de la solution trouvée. Les étapes de la méthodologie
concernées sont les étapes 8 et 9.
4. Suivi paiement

Il permet de faire au mieux correspondre le système aux attentes des utilisateurs. Il

assure le processus d’amélioration permanente et l’adéquation du système aves les
nouveaux besoins des décideurs. Il traite de l’étape 10, celle de l’audit.

18
III. Choix de la méthodologie de gestion de projet

Les deux méthodologies que nous avons eu à analyser dans la partie des concepts théoriques et
état de l’art sont la méthode du cycle de vie dimensionnel et la méthodologie GIMSI. Après
avoir montré les cas d’utilisation de ces deux approches, leurs forces et limites, nous avons fait
un état synthétique permettant de faire notre choix. Ainsi, nous disposons du tableau suivant
faisant état de la comparaison des deux méthodes. Mais avant toute chose, il serait judicieux de
définir nos critères de choix de l’approche optimale.
Les critères de choix sont Renseignés dans le tableau2 :
N° Critère Description
Etant donné que les budgets sont alloués en fonctions du temps de
1 La Gestion des délais
travail, il est important de respecter les délais.
La gestion des ressources L’importance du qui fait quoi ici a tout son sens dans la mesure où
2
cela a un impact sur la qualité du travail.
Il est important de bien saisir les attentes du métier car leurs
Gestion de la
3 prises de décisions dépendront fortement de la pertinence du
communication
travail fourni.
Concordance besoins
Il faudrait que les données provenant du système soient capables
4 analytiques et données
de répondre aux besoins d’analyse.
fournies
Des données de qualité sont celles qui seront restituées sous le
5 Qualité des données
format adéquat.
Amélioration des Elle se fait dans le cadre de la croissance du projet, à la demande
6 indicateurs de performances des utilisateurs ou en procédant à la correction de certaines
anomalies.
Tableau 2: Critères de choix de la méthode de gestion du projet

A la suite de l’élaboration des critères de choix, et la description des différentes méthodologies,

nous procédons à la comparaison suivante dont l’issue sera le choix de l’approche adéquate.
Le tableau 3 suivant fait état du respect des critères de choix par les deux méthodologies
présentées. Le 1 signifie que la méthodologie respecte le critère et le 0, qu’elle ne le respecte
pas. A la fin, la méthodologie qui respecte le plus de critères sera celle choisie.

Délais Ressource Communication Concordance Qualité Evolution Total

Cycle
1 1 1 1 1 1 6
de vie

GIMSI 1 0 1 1 1 0 4
Tableau 3:Comparaison des deux méthodologies de gestion de projet

A la suite de cette comparaison, notre choix se porte sur la méthode du cycle de vie
dimensionnel.

19
 Partie 3 : Analyse du système existant

Après avoir définit le problème et le travail à mettre en œuvre, dans cette partie nous
mettrons en exergue les causes des problèmes rencontrés dans le Datawarehouse en se
basant sur une étude du système existant. Ensuite nous dirons pourquoi ces situations
sont problématiques et enfin proposerons des pistes de solutions.
Chapitre 5 : Etude de l’existant

Cette partie consiste à décrire l’existant : son infrastructure et la description du

processus ETL, jusqu’à la restitution des données. Ensuite, une interprétation de cette
analyse permettra de ressortir les limites de cet existant, et la proposition de solutions.

I. Présentation du système existant

Le Datawarehouse Cameroun a été mis en place en vue de répondre aux besoins

analytiques de la filiale quant à ses activités. Ce dernier fait partie intégrante d’un
système d’information dont il serait intéressant de présenter les interactions.
L’architecture du Datawarehouse est présentée dans la figure 5 suivante :

Figure 4: : Architecture du Datawarehouse

Nous présenterons dans un premier temps l’architecture technique, puis dans un second
temps l’architecture fonctionnelle.
1. Architecture technique
Les composants de base du Datawarehouse sont présentés dans le tableau 4:
Tableau 4: Architecture technique du Datawarehouse

Composant Machine physique Système installé

Amplitude (Bank, paie,
Informix
Système source Non précisé achat)
P-Lease SQL Server
Zone de préparation des BD SQL server 2005
WINDOWS Server 2003
données ETL SSIS 2005
Zone de présentation des
WINDOWS Server 2003 SQL Server 2005
données
Application utilisateur Non précisé Business Object

21
a. Description des composants
Le système source est basé sur des SGBD de type INFORMIX (de l’éditeur IBM) et
SQL Server de Microsoft.
La zone de préparation de données est constituée d’une Base de données SQL Server 2005
en guise d’espace de stockage et de deux ETL mensuel et journalier implémentés par la
technologie SSIS.
b. SSIS

Microsoft SQL Server Integration Services (SSIS) est une plate-forme permettant de créer des
solutions d'intégration de données hautes performances, notamment des packages d'extraction, de
transformation et de chargement (ETL) pour l'entreposage de données. [5] Ses caractéristiques
principales sont les suivantes :
• SSIS comprend des outils graphiques et des assistants pour la création et le débogage de
packages ;
• Il permet la création de gestionnaires de connexions pour se connecter à la source ou à la
destination ;

• Il comporte une fonction d’ajout de tâche de flux de données, telles que dans certain cas,
des opérations FTP, ou encore l’exécution d’instructions SQL définissant le moteur de
flux qui déplace les données entre la source et la destination, en effectuant des
transformations, des nettoyages, des traitements ;
• Il dispose d’une base de données de gestion SSISDB pour administrer l’exécution et le
stockage des packages.
• Il est possible d’utiliser pour le développement des packages SSIS l’outil de Microsoft
Visual Studio dénommé SQL Server Data Tools (SSDT) fournissant à l’utilisateur une
interface basée sur le « glisser-déposer » ;
Ainsi on dispose d’outils graphiques pour développer les éléments cités plus haut, à
savoir :
- Les flux de données ;
- Les sources de données ;
• SSIS comporte des outils inclus tels que DTEXEC pour l’exécution des packages, où
qu’ils soient stockés, avec la ligne de commande.
• SSIS prend en compte la gestion des priorités. C’est-à-dire que certaines tâches sont liées
par des contraintes de priorités.
- Première contrainte : Les tâches sont liées par des contraintes de priorité. La
contrainte de priorité précédant une tâche particulière doit être satisfaite avant que
cette tâche ne s'exécute. Confère la figure 6 ci-dessous

Figure 5: Contrainte de priorité sur les packages SSIS

22
 - Deuxième contrainte : Certaines tâches sont regroupées dans des
containers de séquence dont l’exécution lance celle de toutes les tâches
qu’il contient. Comme l’indique la figure 7 suivante :

Figure 6: Contrainte de container de séquence sur les packages SSIS

Après avoir passé en revue l’architecture technique et applicative, penchons-nous vers

l’architecture fonctionnelle du Datawarehouse.
2. Architecture Fonctionnelle
a. Sources de données

Les sources de données sont les Base de données des applications utilisées par la
banque. Ces applications sont les suivantes :
• Premièrement, nous avons Amplitude Bank : qui gère les transactions bancaires.
Son SGBD est de type Informix, de l’éditeur IBM ;
• Deuxièmement, on trouve la base de données d’Amplitude paie : Cette
application gère la paie des employés de la banque ; Il s’agit également d’une
base Informix ;
• Troisièmement, nous rencontrons la base de données d’Amplitude achats qui
gère les fournisseurs de la banque ;
• Quatrièmement, nous avons la base de données PLEASE, il s’agit d’une base
SQL SERVER. Elle renferme toutes les données relatives au fonctionnement
interne de la banque telles que la comptabilité, les ressources humaines, la
finance…

23
 b. Les connexions de données

ODBC (Open Database Connectivity) est un protocole qui permet de connecter une
base de données Microsoft à une source de données externes [6], telle que Microsoft
SQL Server ou INFORMIX. Une source de données est une combinaison des
informations de connexions nécessaires à une application Microsoft pour accéder aux
données d’une autre source. Ces informations concernent l’emplacement du serveur, ses
informations d’authentification et diverses options de pilote ODBC qui expliquent
comment se connecter à la source de données.
Dans l’architecture ODBC, une application se connecte au gestionnaire ODBC qui à son
tour utilise le pilote spécifique (INFORMIX ou SQL Server) pour se connecter à la
source.

c. La base de données Datawarehouse

Afin de procéder à l’étude de la base de données et pour des raisons de confidentialité

qui nous empêchent de modéliser explicitement la base de données, nous allons la
schématiser selon l’ensemble des services que la banque propose [7]. La modélisation
se fait selon la figure8 :

Figure 7: Modèle de synthèse de la base de données

Ainsi, les tables sont regroupées de la façon suivante :

• Tables de bases (agences, gestionnaires, dates comptables, dates de valeur, dates

d’intégration…) ;
• Clients ;
• Prêts ;
• Produits clientèles ;
• Devises ;
• Transactions ;
• Soldes ;
• Opérations étrangères.

24
Le dictionnaire des données

Les tables, de même que les données renseignées au sein de celles-ci, suivent une
Mnémonique similaire à celle employée dans les bases transactionnelles sources.
La conception du modèle de données est la pierre angulaire des applications BI et
analytiques.
Les données ont différents contextes en fonction de leur usage dans les processus d’une
organisation. Par conséquent, il importe d’étudier le modèle de données adopté dans
notre Datawarehouse.

Modèle logique de données

Les types de données :
Les principaux types de données caractérisant les différentes entités sont les suivants :
• Entiers ;
• Chaines de caractères ;
• Entiers relatifs ;
• Date.
Contraintes d’intégrité :
Sur les tables, les contraintes de clés sont identifiées dans le tableau 5

Type de contrainte Occurrence

Clé primaire Aucune

Clé étrangère Aucune

Check(condition) Aucune
Tableau 5: Contrainte d'intégrité sur les tables

Sur les colonnes, les contraintes de clés sont identifiées dans le tableau 6

Type de contrainte Occurrence

Clé primaire Aucune

Clé étrangère Aucune

Dates de dernier chargement :

Check(condition)
Tableau 6: Contraintes d'intégrité sur les colonnes

25
Modèle physique

Les données identifiées dans le modèle logique de données sont associées aux types de
données indiquées dans le tableau 7, selon le SGBD choisit :

Type de données Equivalent SGBD SQL Server

Entiers Int

Chaine de caractères Nchar

Entiers relatifs Float

Date Date
Tableau 7: Type de données

Aspects de performance
Les index :
Seules quelques tables de grande volumétrie sont référencées par des index. Il s’agit
d’index non groupés (non clustered) ascendants. Ce sont des index sur une ou plusieurs
colonnes.

Les partitions :
Il n’existe pas de plan de partitionnement sur la base de données. Certaines tables,
historiques pour la plupart, possèdent une grande volumétrie de l’ordre de 200 Gb pour
une profondeur allant jusqu’à 2008.

Rôles et Utilisateurs (sécurité) : Des Utilisateurs ont été défini afin de limiter l’accès
aux serveurs à des personnes non habilitées. Pour chaque utilisateur, des rôles ont été
définis selon les habilitations.
Suivant le chargement des tables dans la base des données, nous les avons classifiées.
Ainsi, nous distinguons :
• Les tables historiques : Elles sont chargées quotidiennement ou mensuellement et
servent à l’analyse de l’activité de l’entreprise.
• Les tables archivées : Ce sont des tables qui ne sont plus destinées à évoluer ;
• Les tables temporaires : Elles sont chargées de façon temporaire, en sorte de
charger d’autres tables historiques dans l’entrepôt.
• Dimensions à évolution lente (SCD) : Ce sont des tables, évoluant très peu, qui
servent pour les transformations.

Suivant le chargement des tables dans la base des données, nous les avons classifiées.
Ainsi, nous distinguons :

26
 • Les tables historiques : Elles sont chargées quotidiennement ou mensuellement
et servent à l’analyse de l’activité de l’entreprise.
• Les tables archivées : Ce sont des tables qui ne sont plus destinées à évoluer ;
• Les tables temporaires : Elles sont chargées de façon temporaire, en sorte de
charger d’autres tables historiques dans l’entrepôt.
• Dimensions à évolution lente (SCD) : Ce sont des tables, évoluant très peu, qui
servent pour les transformations.

d. ETL

Les ETL ont pour rôle d’extraire les données depuis les différentes sources et les rendre
conformes à la structure chargée de les accueillir. Selon le chargement qu’ils effectuent,
nous distinguons deux types :
• Les ETL Journaliers ;
• Les ETL Mensuels.
Les ETL sont implémentés sous forme de packages SSIS.
• ETL Journalier
Il Comprend 9 containers regroupant chacun des flux de données. Ces flux sont
organisés relativement aux domaines auxquels ils se réfèrent :
- Trésorerie ;
- Assiette fiscale ;
- Budget ;
- Faits ;
- Tables utiles
La figure 9 suivante présente les packages d’ETL journalier :

Figure 8: Fonctionnement global ETL journalier

27
Les initialisations exécutent une requête SQL spécifique et les différents chargements
comportent des Data Flow task permettant de faire circuler des flux de données d’une
source vers une table du Datawarehouse.
Le tableau8 suivant fait état de la synthèse des différents traitements effectués dans
chaque bloc.
Chargement Scenario Source Traitement Destination

Container1 :
Chargement des
S1 Amplitude Bank Copie simple de données DWC table temporaire
tables
descriptives

Amplitude Bank
S1 Copie simple de données DWC table temporaire
Container2 :
Chargement de
la monétique
S2 Amplitude Bank Copie avec transformations DWC table temporaire

Container3 :
Chargement des
S1 Amplitude Bank Copie simple de données DWC table temporaire
impôts

S3 DWC table temporaire Copie simple de données DWC table historique

Container4 : Copie avec conversion de

S4 Amplitude Bank DWC table historique
Chargement des données
produits clientèle
Copie avec conversion de
S2 Amplitude Bank DWC table temporaire
données

Container5 : Copie avec conversion de

Chargement de la S5 Amplitude Bank données DWC table historique
Trésorerie
S6 DWC tables temporaires Agrégation de données DWC table historique

Container6 :
Chargement de
S6 DWC tables temporaires Agrégation de données DWC table historique
la Direction
Financière
Container7 :
Chargement
Direction des S2 Amplitude Bank Conversion de données DWC table temporaire
Opérations
Etrangères
Container8 :
Chargement des S7 DWC table historique Ajout d’informations DWC table historique
prêts
Container9 :
Chargement de la
S6 DWC tables temporaires DWC table historique
Direction Agrégation de données
Générale
Tableau 8:Description de l'ETL journalier

28
 • ETL mensuel
A l’instar de l’ETL journalier, il comporte des containers classifiés selon les flux de
données qu’ils comprennent.
La figure 10 suivante présente les packages d’ETL mensuel :

Figure 9: Fonctionnement global ETL mensuel

De même que pour l’ETL journalier, nous ferons une synthèse des différents types de
traitements effectués par l’ETL mensuel.
Le tableau 9 en donne la description.
Chargement Scénario Source Traitement Destination

Container 1 : Chargement S1 Amplitude Bank Copie de donnéesDWC table temporaire

des Historiques des
comptes et Soldes

Container 2 : Chargement S1 Amplitude Achat Copie de donnéesDWC table temporaire

de la
Trésorerie
Container 3 : Chargement S2 DWC Copie de données DWC tables
de la Tables temporaires avec conversion de historiques
Direction données
Financière
Container 4 : Chargement S3 DWC Copie de données ; Conversion
DWC tables
de données
de la Tables temporaires historiques
Direction
Générale
Container 5: S4 Amplitude Bank Copie de données DWC Table historique
Chargement de la des ; Agrégation de
Direction Risques et données
conformité
Container 6: S5 Amplitude Paie Copie de données DWC table historique
Chargement du avec des unions
Reporting
commercial DWC tables historiques Copie de données DWC tables
avec agrégation de historiques
S6 données, conversion
de données

PLEASE Copie de données

Container 7: S4 Amplitude Bank Copie de données ; Agrégation

DWC Table
de données
historique
Chargement des
Produits et
Services
Tableau 9: Description de l'ETL mensuel

29
Analyse du système existant

L’objectif que nous nous sommes fixés tout au long de ce projet est l’optimisation du
chargement des données dans le Datawarehouse. Cela passe par l’amélioration du
traitement des ETL et une amélioration de structure de la base de données
Datawarehouse. Nos axes d’analyse s’articuleront donc autour de ces deux points. En
découlera enfin la restitution des données adaptées à la nouvelle base de données.
Après avoir présenté les différentes architectures, nous allons faire ressortir les pistes
d’améliorations basées sur l’existant.

1. La base de données datawarehouse

a. Le modèle
La conception logique et physique de la base de données est prépondérante car elle
favorise l’extraction et les étapes de transformations de données. L’analyse de la base
de données du Datawarehouse est le moyen de relever les anomalies qui enfreignent le
bon chargement des données.
La base de données existante est construite autour d’un modèle entité/relation.
Il s’agit d’une technique de conception logique de données.

• Tout d’abord la modélisation entité-relation définit les micros relations entre les
données.
• Ensuite, elle représente au sein d’un même schéma des processus qui ne
coexistent pas forcément au sein d’un même service de la banque.
• Aussi, la restitution de données provenant de cette base peut se montrer
complexe car les tables sont liées entre elles par de nombreuses jointures.
• Enfin, c’est une modélisation dont la structure finale n’est pas très prévisible, ce
qui ne facilite pas les prévisions telles que les optimisations de requêtes des
utilisateurs finaux.
Nous opposons ce modèle au modèle dimensionnel qui est également une technique de
conception logique et physique répandues des Datawarehouse.
• Premièrement, les attributs des tables dimensionnelles sont créés en fonction des
contraintes d’analyse des utilisateurs finaux.
• Deuxièmement, ce modèle scinde en plusieurs schémas les processus métiers,
représentés par des tables de dimensions et de faits, liées entre eux par domaine.
Ceci facilite ainsi la navigation dans le système car les contraintes utilisateurs
proviennent des attributs des dimensions.
• Aussi, la structure de ce modèle est prévisible car toutes les dimensions sont
équivalentes.

30
 • Pour terminer, il peut accueillir de nouvelles données et des besoins d’analyses
imprévus initialement. Cela passe par l’ajout de nouveaux faits, de nouvelles
dimensions, de nouveaux attributs dimensionnels.
En somme, les caractéristiques de ces deux méthodes sont consignées dans le tableau 10 :

Modèle entité-relation Modélisation dimensionnelle

Favorable aux applications Orientation analytique selon les processus

transactionnelles métiers

Navigation simple due au fait que les

Navigation rendue complexe en raison des contraintes utilisateurs sont des attributs
multiples jointures des dimensions

Extensibilité rendue difficile en raison de la

structure non prévisible des schémas Forte résistance aux changements du fait de
la symétrie du modèle

Tableau 10: Comparaison modèles dimensionnel et entité-relation

b. Les interactions entre les relations

Elles sont consignées dans le tableau 11 suivant :

Spécificité Tables

Date comptable, date de valeur, Date

Dimensions multi-rôles
d’intégration historique

Dimensions plusieurs à plusieurs Clients/prêts

Tableau 11: Interactions entre les relations

A présent, procédons à l’explication de ces différentes spécificités.

Dimensions multi-rôles :
C’est une situation au cours de laquelle une dimension apparait plusieurs fois dans une
même tables des faits.
La dimension date figure en plusieurs exemplaires dans certains faits. On retrouve la
date comptable, la date de valeur, la date d’intégration historique…
Chacune de ces dimensions constitue une clé étrangère de la table des faits vers laquelle
pointe la dimension. Rappelons que les attributs des dimensions constituent les
contraintes lors de requêtes. Une séparation logique des dimensions multi-rôles
reviendrait à effectuer de multiples jointures. Le langage SQL reviendrait à interpréter
cette tentative de jointures multiples comme l’exigence que les dates sont identiques. Il
serait donc plus approprié d’utiliser de multiples tables logiques, pour les dates.

31
Les dimensions plusieurs-à-plusieurs :
Cette situation fait référence aux cas où certaines dimensions peuvent prendre une ou
plusieurs valeurs pour un même enregistrement dans la table des faits. Pouvant ainsi
complexifier les requêtes sur un tel schéma.

c. Les contraintes d’intégrité

Les contraintes d’intégrités sur les tables du système existant concernent la réutilisation
des clés de production comme clés du Datawarehouse. Dans la modélisation
dimensionnelle, Toutes les tables de dimensions possèdent des clés uniques, appelées
clés primaires et les tables de faits, possèdent les clés étrangères se référant aux clés
primaires de chaque table dimensionnelle qui lui est liée. Toutes les clés du modèle
dimensionnel seront des clés de substitution. C’est-à-dire qu’elles sont dépourvues de
signification, différentes des clés de production et présentant des valeurs numériques.
Les raisons de ce choix sont les suivantes :
• Les clés de substitution sont le plus souvent des entiers de 4 octets, le stockage s’en retrouve
moins impacté;
• La réutilisation des clés de la production dans le Datawarehouse peut générer un conflit
d’intégrité dans le cas où la production décide d’utiliser à nouveau les mêmes clés en cas de
purge du système;

2 . L’ETL

L’ETL Journalier présente différents types de chargement sur lesquels nous allons
porter notre critique.
Les Données sont extraites depuis la source et sont directement chargées dans les tables
historiques, dont la volumétrie a un taux d’accroissement entre 3 et 5 %. C’est le cas des
scénarios S6, S8 et S11.
Les données sont extraites des bases de données sources avec des transformations telles
que des procédures stockées et des fonctions d’agrégat. C’est le cas des scénarios S3,
S6, S7 et S11.
Les scénarios sont analysés dans le tableau 12 ci-dessous :

Scénario Analyse du scénario

S6, S8 et S11 Données chargées depuis la source vers les tables historiques

S3, S6, S7 et S11 Données transformées depuis la source (Procédures stockées, fonctions
d’agrégation, conversion de données)
Les données extraites résultant de l’union de plusieurs tables, effectuée sur la
S2, S3 base transactionnelle avant le chargement de la table historique.

Tableau 12: Analyse des scénarios

32
De même, nous rencontrons les mêmes cas de figure pour l’ETL Mensuel.
• Le premier aspect de l’analyse est cause de lenteur car les tables historiques sont
des tables à grande volumétrie.
• Le deuxième aspect La source et la destination (Datawarehouse) sont situés sur
des serveurs distants, occasionnant ainsi des latences réseau. De plus, la
technologie employée sur la base source (Informix) est différente de celle
employée sur la base cible (SQL Server).
• Le troisième aspect de l’analyse n’est pas optimal dans la mesure où l’extraction
se fait sur une réunion de tables transactionnelles situées sur un serveur distant.

33
Chapitre 6 : Résultats de l’étude de l’existant

En se rappelant que l’objectif principal de notre travail est l’amélioration de la

disponibilité des données dans le Datawarehouse, avec des optimisations tant au niveau
des ETL que de la base de données, après l’analyse de notre système existant, nous
parvenons aux résultats qui suivent :
I. ETL

Les pistes d’amélioration suggérées à la suite de l’analyse de notre ETL sont énoncées
dans le tableau 13 ci-dessous :

Analyse Résultat

Transformation des données depuis la source Création d’une zone de préparation des
données sur le Datawarehouse
Chargement depuis la zone de préparation vers
Données chargées depuis la source vers les
les tables historiques du Datawarehouse.
tables historiques

Extraire les données dans des tables de la zone

Extraction des données depuis la réunion de
de préparation de données puis faire les unions
plusieurs tables sources
depuis cette zone
Tableau 13: Pistes d'amélioration ETL

II. La base de données Datawarehouse

Les interactions entre relations

A la suite de notre analyse, nous avons ressorti les problèmes de performance liés à la
base de données Datawarehouse. La suite de notre réflexion consiste à suggérer les
pistes de solutions adéquates qui permettront de palier à ces problèmes :
• Les dimensions multi-rôles : Le problème causé par ces dimensions peut être
résolu par la création de vues portant des noms différents sur une unique table
physique qui est notre dimension multi-rôles. Donnant ainsi l’impression que
différentes tables sont créées tout en s’affranchissant des jointures multiples.
• Les dimensions plusieurs-à-plusieurs : Dans ce cas, la solution consiste à insérer
une table intermédiaire entre les tables liées par la relation plusieurs à plusieurs,
qui permettra d’établir des relations (1, n) , plus prévisibles.
Finalement, le tableau 14 recense les aspects d’optimisations que nous appliquerons à
notre datawarehouse après analyse.

34
 Interaction entre les relations Pistes d’optimisation

Création de vues portant des noms distincts sur

Dimensions multi-rôle
la table physique

Dimensions plusieurs à plusieurs Insertion de table intermédiaire

Tableau 14: Pistes d'amélioration Datawarehouse

Après avoir étudié l’existant, faisons place à la conception de notre solution, puis à sa
mise en œuvre.

35
 Partie 4 : Conception et mise en œuvre

A la suite de l’analyse du système existant, nous procédons à la conception de notre

solution basée sur les recommandations de l’analyse de l’existant. A la suite de cela,
nous montrerons les étapes de mise en place.
Chapitre 7 : Conception

Avant de présenter notre travail d’optimisation, il serait intéressant de présenter la

nouvelle architecture technique globale de notre nouvelle infrastructure.
Elle se compose de :
• Un serveur applicatif ;
• Un serveur de base de données.
Les versions applicatives et les plateformes techniques sont définies dans le tableau 15
suivant :

Composant Machine physique Système installé

Amplitude (Bank,
paie, achat) Informix
Système source Non précisé
P-Lease SQL Server

BD SQL server 2016

Zone de préparation des
WINDOWS Server 2016
données
ETL SSIS 2016

Zone de présentation
des données WINDOWS Server 2016 SQL Server 2016

Application utilisateur
Non précisé Business Object

Tableau 15: Architecture technique de la nouvelle infrastructure

Pour la nouvelle architecture mise en place, les zones de préparation de données et de

présentation de données se trouvent sur deux serveurs physique distincts : Un serveur
applicatif et un serveur de base de données.
Le serveur applicatif, comporte tous les scripts, packages et outils de monitoring
permettant de lancer et superviser les chargements mensuel et quotidien servant à
alimenter le Datawarehouse.
Le serveur de base de données quant à lui est la machine physique abritant le
Datawarehouse. Il Sert à stocker les données et les restituer.

37
 I. Optimisation de la base de données Datawarehouse

1. Modélisation de la base de données

Le cycle de vie dimensionnel définit les étapes de modélisation de base de données.

Ce modèle comporte les mêmes informations que le modèle dimensionnel mais sous
une forme différente.
La première étape de la modélisation consiste à lister les dimensions et les faits. La
matrice conçue au tableau 16 qui suit est une carte de l’élaboration des dimensions.

Devises Clients Soldes Dates

Prêts X X X

Opération
X X X
étrangère

Transaction X X X X

Produit
X X
clientèle
Tableau 16: Matrice de l'architecture du Datawarehouse

Les lignes du tableau 16 font référence aux processus métiers de la banque et les colonnes sont
les dimensions.
La deuxième étape consiste à la modélisation de chaque processus métier. La granularité des
tables de faits restera la même que celle de l’ancien modèle afin de conserver les données.
La troisième étape est celle du choix des faits.
En se basant sur le tableau 12 on obtient le diagramme de la table des faits pour le cas des
opérations étrangères à la figure 11:

Figure 10: Diagramme de la table des faits Opérations étrangères

38
 2. Gestions des dimensions multi-rôles

Nous avions identifié la dimensions Date comme dimension multi-rôles

On procède donc à la création des vues suivantes :
• Date comptable ;
• Date de valeur ;
• Date d’intégration historique.
II. Optimisation des ETL

Choix des tables : Les tables retenues sont celles qui font suite au processus de
modélisation.
Ordre de chargement : Certains chargements étant interdépendants, il est nécessaire de
respecter l’ordre des chargements présenté dans l’analyse, nous avons mis en place
l’ordre de chargement (tableau 17) :

Ordre de lancement Container à exécuter

1 Container1, container8, Container7

2 Container2

3 Container3

4 Container4

5 Container5

6 Container6, container9
Tableau 17: Ordre de lancement des containers

Suivant l’usage des tables résultant de la modélisation, nous avons classifié la zone de préparation des
données sur un premier serveur, et la zone de présentation des données sur un second serveur.
Finalement, le schéma 11 de chargement pour les ETL est le suivant :

Figure 11: principe de chargement des ETL

39
Chapitre 8 : Mise en œuvre

Cette partie montre les différentes étapes de la réalisation du projet et la capture des
résultats.
La mise en œuvre de notre travail a nécessité l’utilisation d’environnements de travail
que nous présentons dans la section ci-dessous.

I. Environnements de travail et choix des outils d’implémentation

Nous avons eu recours à trois environnements qui sont les suivants :

• Développement ;
• Homologation ;
• Production.

1. L’environnement de développement

Il comporte tous les outils nécessaires au codage et la création du processus ETL et à la

restauration et la modification de la base de données. Il est constitué de deux machines
physiques, serveur applicatif et le serveur de base de données. Le serveur applicatif fera
office de zone de préparation des données et le second serveur hébergera la base de
données du Datawarehouse.

a. Outils de préparation de données : SSIS 2016

Son choix se justifie par les raisons suivantes :

• Il est facilement déployable en présence d’instance SQL Server car il est
également un produit de l’éditeur Microsoft ;
• SSIS est complètement intégré dans Visual Studio.
• Nombreux connecteurs disponibles (Oracle, Teradata, SAP…).
• Grande facilité de prise en main.
• C'est un outil très visuel.
• Il offre la possibilité de créer de nouveaux modules.
• Gestion des événements.

b. SQL Serveur Management studio (SSMS)

C’est un environnement intégré pour la gestion de toute infrastructure SQL, telle que
SQL Server. De plus, il fournit des outils pour configurer, surveiller et administrer des
instances de SQL Server et des bases de données. Il permet de déployer, surveiller et
mettre à niveau les composants de la couche données utilisés par les applications et
créer des requêtes et des scripts.

40
 2. L’environnement d’homologation

C’est une zone de test de toutes les solutions développées en production. Il comprend
des jeux de données qui seront utilisées à des fins d’essais. Il comprend également un
serveur applicatif et un serveur de base de données.
3. L’environnement de production

C’est sur ce dernier que sera déployée la solution finale avec l’utilisation des données
de production. La solution finale sera lancée chaque jour ‘ETL jour) et chaque mois
(ETL mois) par un ordonnanceur.

• Il a été employé pour l’exécution des scripts de lancement des ETL mensuel et
journalier car c’est le même ordonnanceur qui est utilisé en production par la
banque pour lancer les TFJ. Or le lancement de nos ETL dépend fortement de
l’exécution de ces TFJ.

II. Réalisation et déploiement des solutions

Nous avons d’abord effectué les développements des différents packages d’ETL
mensuels et journaliers. Les packages sont créés au sein d’un projet.
A la fin du développement, le projet est construit puis déployé, on obtient un fichier
d’extension ispac.
Afin d’exécuter les ETL de façon mensuelle et journalière, il faut automatiser le
processus. L’automatisation suit les étapes ci-dessous
1. Etape 1 : Création du catalogue d’intégration de service sur sql server

Figure 12: Capture d'écran du menu SSMS

41
Après la création du catalogue, on remarque qu’une nouvelle base de données a été
créée. Ce sont ses tables qui serviront pour le monitoring des ETL déployés.

Figure 13: capture de la création de la BD de SSIS

2. Etape 2 : Insertion des services dans le catalogue

Figure 14: capture de l'interface SSIS sous visual studio

A la suite du déploiement de la solution, l’assistant du service d’intégration guide

l’utilisateur jusqu’à la création des ETL dans sql server.

42
 Figure 15: capture du déploiement de la solution

Les ETL Sont à présent exécutables depuis SSMS.

3. Etape 3 : Création de script batch pour exécuter les services

Figure 16: capture des scripts batch créés

4. Etape 4 : Automatisation du script batch

L’ordonnanceur controlM lancera les exécutions juste à la fin du TFJ.

43
 III. Résultats et coûts du projet
Le projet qui nous a été confié a pour objet l’optimisation du temps de chargement
du Datawarehouse de la SGCAM. Il serait donc intéressant de visualiser les résultats
obtenus à la fin de notre travail et les coûts engendrés.

1. Résultats

Les résultats de notre travail ont eu un impact sur les temps des processus indiqués dans
le tableau 17 ci-dessous :

Ancien Datawarehouse Nouveau Datawarehouse

Chargement journalier 4h 2h

Chargement mensuel 10 8h

Exécution de rapport simple

Instantané Instantané
sur BO
Exécution de rapport complexe
1h 30min
sur BO
Tableau 18:Résultats de l'optimisation des ETL du Datawarehouse

2. Coûts

La SGCAM a un partenaire qui lui fournit un catalogue d’infrastructures et de licence

pour la somme mensuelle de 3000 euros. L’ensemble de l’infrastructure du
Datawarehouse figurant dans ce catalogue, le prix des dépenses côtés infrastructures est
nul.
Côté ressources humaines, selon la planification au chapitre 4, le projet s’est déroulé sur
une période de 151 Jh, un jour/homme valant 350 euros le coût final du projet s’élève à
: 52850 Euros. Le tableau 19 ci-dessous synthétise les coûts.

Ressource Coût en euros

Ressource matérielle 0

Ressource humaine 52850

Tableau 19: Coûts du projet DWC

44
 CONCLUSION

Au terme de notre travail, rappelons que le projet auquel nous avons pris part a été mis
en place dans le cadre de la migration de la montée en version du Datawarehouse de la
SOCIETE GENERALE Cameroun. Notre travail a consisté en l’optimisation du
chargement de ce Datawarehouse. Les missions qui nous ont été assignées ont été entre
autres l’optimisation des processus ETL en vue de réduire le temps des chargements
journalier et mensuel de la base et l’amélioration de la structure de la base de données
toujours dans le but de réduire le temps des chargements, mais également la réduction
du temps de réponse aux requêtes utilisateurs qui se font via les rapports Business
Object. En suivant la méthodologie du cycle de vie dimensionnel pour les projets de
construction de Datawarehouse, nous avons premièrement revu le modèle de la base de
données en adoptant, un schéma dimensionnel. Deuxièmement, nous avons revu les
zones de chargement et les scenarios de chargement des ETL afin que ceux-ci soient
moins chronophages.

Ainsi, à l’issue de notre travail, le temps de chargement du Datawarehouse a été réduit

de moitié pour les chargements journaliers et de 2h pour les chargements mensuels.
Aussi, le modèle dimensionnel mis en place permet une meilleure restitution de
l’information à travers des rapports Business Object dont l’exécution a été améliorée à
l’aide des dimensions qui sont les contraintes de recherche.

En termes de perspective, un plan de partitionnement reste à mettre en œuvre en vue de

limiter la volumétrie des tables du Datawarehouse et accroitre un peu plus les
indicateurs de performance.

45
 BIBLIOGRAPHIE

[1] B. INMON, Développer l'entrepôt de données, John Wiley and sons inc., 2005.
[2] R. Kimball, La Datawarehouse guide de conduite de projet, EYROLLES, 2015.

XI
 WEBOGRAPHIE

• «Documents SQL,» 15 07 2023. [En ligne].

Available:https://docs.microsoft.com/en-us/sql/integration-services/ssis-how-to-
create-an-etlpackage?view=sql-server-ver15.
• Microsoft, [En ligne]. Available:
https://support.microsoft.com/frfr/office/administrer-des-sources-de-
donn%C3%A9es-odbc-b19f856b-5b9b-48c9-8b93-
07484bfab5a7#:~:text=ODBC%20(Open%20Database%20Connectivity)%20est,tell
e%20que%20Microsoft%20SQL%20Server.. [Accès le 07 07 2023].
• «developpez.com,» [En ligne]. Available:
https://laurentaudibert.developpez.com/Cours-BD/?page=bases-de-donnees-
relationnelles. [Accèsle 25 07 2023].

XII
 TABLE DES MATIERES
DEDICACE................................................................................................................................................ I
REMERCIEMENTS ................................................................................................................................ II
SOMMAIRE ............................................................................................................................................ III
ABREVIATIONS ..................................................................................................................................... V
LISTE DES TABLEAUX ....................................................................................................................... VI
LISTE DES FIGURES ........................................................................................................................... VII
RESUME ................................................................................................................................................XVI
ABSTRACT ...........................................................................................................................................XVI
PARTIE 1 : PRESENTATION DU STAGE ....................................................................................................... 1
Chapitre 1 : Contexte.............................................................................................................................. 3
I. Historique ................................................................................................................................... 3
II. Présentation de l’entreprise ........................................................................................................ 4
1. Les domaines d’activités et missions de SG ABS Abidjan .................................................... 4
2. Organisation de SGABS Abidjan ............................................................................................... 5
Chapitre 2 : Problématique ..................................................................................................................... 7
I. Domaine ..................................................................................................................................... 7
II. Problème à résoudre ................................................................................................................... 7
III. Objectifs.................................................................................................................................. 8
Partie 2 : Concepts théoriques et état de l’art ....................................................................................... 3
Chapitre 3 : Concepts du Datawarehouse ............................................................................................. 10
I. Les composants de base du Datawarehouse ............................................................................. 10
1. Le système source................................................................................................................. 11
2. La zone de préparation des données ..................................................................................... 11
3. Serveur de présentation du Datawarehouse .......................................................................... 11
4. Modèle dimensionnel ........................................................................................................... 11
5. Datamart et entrepôts de données ......................................................................................... 12
6. OLAP.................................................................................................................................... 12
7. ROLAP ................................................................................................................................. 12
8. MOLAP ................................................................................................................................ 12
9. Outil d’accès aux données .................................................................................................... 12
II. Processus de base du Datawarehouse ....................................................................................... 12
1. ETL ....................................................................................................................................... 12
2. Contrôle qualité et sécurisation ............................................................................................ 13
3. Sauvegarde et restauration .................................................................................................... 13
Chapitre 4 : La gestion du projet .......................................................................................................... 14

XIII
 I. La méthode du cycle de vie du projet BI par Ralph Kimball [3] ............................................. 14
1. Planification du projet .......................................................................................................... 15
2. Définition des besoins .......................................................................................................... 15
3. Modélisation dimensionnelle................................................................................................ 15
4. Conception du modèle physique de données ........................................................................ 15
5. Conception et développement des ETL ................................................................................ 15
6. Définition de l’architecture technique .................................................................................. 15
7. Choix techniques et mise en œuvre ...................................................................................... 16
8. Développement de l’application utilisateur .......................................................................... 16
9. Le déploiement ..................................................................................................................... 16
10. Maintenance et croissance ................................................................................................ 16
11. La gestion du projet .......................................................................................................... 17
II. La méthodologie GIMSI........................................................................................................... 17
1. L’identification ..................................................................................................................... 18
2. La conception ....................................................................................................................... 18
3. Mise en œuvre ...................................................................................................................... 18
4. Suivi paiement ...................................................................................................................... 18
III. Choix de la méthodologie de gestion de projet .................................................................... 19
Partie 3 : Analyse du système existant .................................................................................................. 10
Chapitre 5 : Etude de l’existant ............................................................................................................ 21
I. Présentation du système existant .............................................................................................. 21
1. Architecture technique.......................................................................................................... 21
a. Description des composants ............................................................................................. 22
b. SSIS .................................................................................................................................. 22
2. Architecture Fonctionnelle ................................................................................................... 23
a. Sources de données.......................................................................................................... 23
b. Les connexions de données .............................................................................................. 24
c. La base de données Datawarehouse ................................................................................. 24
Le dictionnaire des données ............................................................................................. 25
Modèle logique de données .............................................................................................. 25
Modèle physique .............................................................................................................. 26
Aspects de performance ................................................................................................... 26
d. ETL ................................................................................................................................... 27
II. Analyse du système existant ..................................................................................................... 30
1. La base de données datawarehouse ...................................................................................... 30
a. Le modèle ......................................................................................................................... 30

XIV
 b. Les interactions entre les relations.................................................................................... 31
c. Les contraintes d’intégrité ................................................................................................ 32
2 . L’ETL ...................................................................................................................................... 32
Chapitre 6 : Résultats de l’étude de l’existant ...................................................................................... 34
I. ETL........................................................................................................................................... 34
II. La base de données Datawarehouse ......................................................................................... 34
Partie 4 : Conception et mise en œuvre ................................................................................................ 21
Chapitre 7 : Conception ........................................................................................................................ 37
I. Optimisation de la base de données Datawarehouse ................................................................ 38
1. Modélisation de la base de données ..................................................................................... 38
2. Gestions des dimensions multi-rôles .................................................................................... 39
II. Optimisation des ETL .............................................................................................................. 39
Chapitre 8 : Mise en œuvre .................................................................................................................. 40
I. Environnements de travail et choix des outils d’implémentation............................................. 40
1. L’environnement de développement .................................................................................... 40
a. Outils de préparation de données : SSIS 2016 ................................................................. 40
b. SQL Serveur Management studio (SSMS)....................................................................... 40
2. L’environnement d’homologation ........................................................................................ 41
3. L’environnement de production ........................................................................................... 41
II. Réalisation et déploiement des solutions .................................................................................. 41
1. Etape 1 : Création du catalogue d’intégration de service sur sql server .............................. 41
2. Etape 2 : Insertion des services dans le catalogue ................................................................ 42
3. Etape 3 : Création de script batch pour exécuter les services ............................................... 43
4. Etape 4 : Automatisation du script batch .............................................................................. 43
III. Résultats et coûts du projet ................................................................................................. 44
1. Résultats ............................................................................................................................... 44
2. Coûts..................................................................................................................................... 44
CONCLUSION ........................................................................................................................................ 45
BIBLIOGRAPHIE .................................................................................................................................... XI
WEBOGRAPHIE ..................................................................................................................................... XII
TABLE DES MATIERES ............................................................................................................................... XII

XV
 RESUME
L’Informatique décisionnelle aide les entreprises à trouver réponses à leurs questions à
partir de données mises en scène, analysées puis exploitées. Encore faudrait-il que ces
données soient disponibles au moment voulu par les décideurs. La SOCIETE
GENERALE CAMEROUN soucieuse de garantir cette disponibilité des données a mis
en place un projet de migration de l’infrastructure de son Datawarehouse, élément phare
de son architecture décisionnelle. Avec à la clé une optimisation de restitution des
données dans ce Datawarehouse. L’objectif de ce mémoire est de présenter le travail
réalisé afin d’aboutir à cette optimisation. Notre implication s’inscrivant dans le cadre
d’un projet de migration d’infrastructure décisionnelle, nous avons opté pour la
méthode du cycle de vie dimensionnel qui suggère une succession de macro-tâches
conduisant à la conception, au développement et au déploiement de Datawarehouses
efficaces. Aussi, cette méthodologie souligne les contraintes aux niveaux des
technologies, des données et des applications. Au cours de ce travail, nous avons
procédé dans un premier temps à l’optimisation des ETL qui alimentent le
Datawarehouse quotidiennement et mensuellement, afin que les chargements
n’excèdent pas la période des traitements de fin de journée (TFJ).Dans un deuxième
temps, nous avons amélioré la structure de la base de données en passant d’un modèle
entité-relation, à un modèle dimensionnel, plus adapté aux bases de données de
Datawarehouse, afin qu’elle restitue dans de meilleurs délais les informations après
qu’elle eût été interrogée.
Mots clefs : Informatique décisionnelle, Datawarehouse, ETL, Cycle de vie
dimensionnel, Business Object, SSIS

ABSTRACT

Business intelligence helps organizations find answers to their questions from data that
is staged, analyzed, and then exploited. However, this data should be available at the
time required by decision-makers. SOCIETE GENERALE CAMEROUN, keen to
guarantee the availability of data, has set up a migration project for the infrastructure of
its Datawarehouse, a flagship element of its decision-making architecture. With the key
to an optimization of data restitution in this Datawarehouse. The objective of this
dissertation is to present the work carried out to achieve this optimization. Our
involvement being part of a decision-making infrastructure migration project, we opted
for the dimensional life cycle method which suggests a succession of macro-tasks
leading to the design, development, and deployment of Datawarehouse. effective. Also,
this methodology underlines the constraints at the levels of technologies, data, and
applications. During this work, we first proceeded to optimize the ETLs that feed the
Datawarehouse daily and monthly, so that the loads do not exceed the end-of-day
processing period (TFJ). Secondly, we improved the structure of the database so that it
returned information as quickly as possible after it had been queried.
Keywords : Business Intelligence, Datawarehouse, ETL, dimensional modeling life
cycle, Business Object, SSIS
XVI