Conception D'un Système D'aide À La Décision

ROYAUME DU MAROC
Conception d’un Système d’Aide à la Décision
Les effectifs budgétaires du personnel de l’Etat
RAPPORT POUR L’AVANCEMENT AU GRADE

PRINCIPAL DU CADRE D’INGENIEUR D’ETAT
Réalisé par
Badr TALAGHZI
Ingénieur d’Etat premier grade à la Direction du Budget
-Mars 2006-
Système d’Aide à la Décision
DB/DB2/DSI/SCD
Remerciements
Au terme de ce travail, je tiens à exprimer ma Haute gratitude à Mr
Abdellatif BENNANI, le Directeur du Budget au sein du ministère des finances
et de la privatisation.
Je tiens à remercier aussi toute personne qui a aidé à réaliser ce projet. Ainsi,
Mes sincères et chaleureux remerciements s’adressent aussi à :
Mr Mohammed ERRAHALI, Chef de la Division des Systèmes d’Information
et directeur du projet décisionnel, pour ses directives pertinentes.
Mr Abdellali FATHI, Chef du Service Communication et Décisionnel pour
son implication à la réalisation de ce projet, et ses conseils pour la
rédaction de ce rapport.
L’équipe informatique du Service Communication et Décisionnel pour sa
participation à la réalisation du projet.
L’équipe d’assistance technique de ARCHOS – CONSEIL, pour leur soutient
technique tout au long de ce projet.
Messieurs les membres de jury, pour avoir bien accepté d’évaluer et de
juger ce travail.
Que toute personne ayant contribué de près ou de loin à l’élaboration de ce
travail, trouve ici l’expression de ma grande reconnaissance.
1
DB/DB2/DSI/SCD
SOMMAIRE
Liste des abréviations 4
Liste des figures 5
Introduction 6
CHAPITRE I: Contexte du projet 8

I. Objectif du rapport 9
II. Contexte du projet 9
II.1. Objectif du projet 9
II.2. Démarche du projet 10
CHAPITRE II: Etude du système existant 11

I. Processus et fonctionnement 12
II. Architecture fonctionnelle 13
II.1. L’application « OTOR » 13
II.2. Les bases de données 14
III. Insuffisances du système existant 15
CHAPITRE III: Notions générales 16

I. Le décisionnel 17
II. Le datawarehouse 18
II.1. Définition du datawarehouse 18
II.2. La structure du datawarehouse 20
III. Composition du système d'information décisionnel 21
III.1. Les sources de données 21
III.2. Le système d’alimentation (ETL) 21
III.3. Datawarehouse, datamart, entrepôt de données 23
III.4. Analyse multidimensionnelle OLAP 23
III.5. Système de diffusion et de présentation 23
CHAPITRE IV: Analyse et conception 25

I. Modélisation multidimensionnelle 26
II. Spécification des dimensions et des mesures 28
II.1. Indicateurs 28
II.2. Axes 29
III. Conception du modèle décisionnel 30
III.1. Tables de faits 30
III.2. Tables des Dimensions 31
III.3. Modèle du cube "Effectif" 32
III.4. Modèle physique de données 33
2
DB/DB2/DSI/SCD
CHAPITRE V: Réalisation de la plate forme décisionnelle 34

I. La plate forme matériel 35
II. La plate forme logiciel 35
III. Les sources de données 36
IV. Le chargement de l’entrepôt des données 36
IV.1. Extraction des données 36
IV.2. Traitement des données 38
IV.3. Chargement des données 39
V. La création et la publication des cubes 40
V.1. Le modèle des métadonnées 40
V.2. La création des cubes 41
V.3. La publication des cubes 42
VI. L’utilisation et l’administration 43
VI.1. La sécurité 43
VI.2. L’utilisation 43
VI.3. Les prérequis 45
VI.4. L’administration 47
Conclusion & recommandations 48
Bibliographie 51
Annexes 52
Annexe –A- 53
Annexe -B- 57
3
DB/DB2/DSI/SCD
Liste des abréviations
BI Business intelligence
CED Control des engagements et des dépenses
CLI Comité de Liaison Informatique
CP Création accordée par le Premier ministre
CR Création de Régularisation
CT Création Titularisation
DB Direction du Budget
DSI Division du Système d’information
DTS Data Transformation Services
ETL Extract Transform Load
F Transformation
ODBC Open Data Base Connectivité
OLAP On-Line Analytical Processing
PPES PowerPlay Entreprise Server
SIAD Système d’information d’aide à la Décision
SQL Structured Query Language
T Transfert
T/F Transfert/Transformation
4
DB/DB2/DSI/SCD
Liste des figures
Figure 1 : Le processus décisionnel 17
Figure 2 : Schéma de principe du datawarehouse 19
Figure 3 : La structure du datawarehouse (source EDS-Prométhéus) 20
Figure 4 : Le système d'alimentation 22
Figure 5 : Représentation de la modélisation et la présentation 24
Figure 6 : Exemple d’un modèle en étoile 27
Figure 7 : Exemple d’un modèle en Flocon 27
Figure 8 : Modèle en Flocon du DataMart "Effectif" 33
Figure 9: Lot DTS : Chargement des données de INGRES 37
Figure 10 : Lot DTS : Traitements des données de la Table de fait 39
Figure 11 : Framework Manager : Modèle des effectifs Budgétaires 40
Figure 12 : Transformer: Modèle des effectifs Budgétaires 41
Figure 13 : PowerPlay Entreprise Server : Administration des serveurs 42
Figure 14 : Cognos Access Manager : Connexion à UpFront 43
Figure 15 : Cognos UpFront : Gestion des rapports et des cubes 44
Figure 16 : Cognos PowerPlay Web 45
Figure 17 : Cognos PowerPlay Web : Exemple d’affichage graphique 46
5
DB/DB2/DSI/SCD
Introduction
La direction du Budget (DB) est chargée de la mise en oeuvre de la politique

budgétaire nationale. Elle se trouve au centre d'un réseau de partenaires
constitués essentiellement d'Administrations, de Collectivités Locales,
d'Etablissements Publics, d'Administrations Publiques étrangères et
d'Organisations Internationales.
Sa mission embrasse un vaste éventail d'attributions dont notamment la

préparation de la Loi des Finances et le suivi de son exécution, le suivi des
budgets des Collectivités Locales et des Etablissements Publics, l'examen des
statuts des personnels et leurs régimes de retraite, l'étude des textes juridiques
ayant une incidence sur les finances publiques et la mise en oeuvre du
financement extérieur des projets publics.
Depuis 1987, la division du système d’information (DSI) de la DB assure

l’évolution de son système d’information, aussi bien sur le plan applicatif que sur
le plan architecture logiciel. Pendant cette période deux transitions clés ont été
enregistrées, le passage de l’architecture Terminal/Server à l’architecture
Client/Server et celui de l’architecture Client/Server à l’environnement Web.
Ainsi, la DSI dessert ; via son système d’information ; les différents partenaires
internes et externes de la DB.
Le système d’information de la DB se décline des missions et attributions de

cette dernière. En effet, il dessert les métiers de gestion budgétaire dans ses
volets crédits et effectifs, les Finances Locales, les statuts du personnel et la
rémunération ainsi que le suivi Financement des Projets Publics. Il a ; au fil du
temps ; crée un patrimoine informationnel très riche : une base de données
opérationnelle qui contient les informations annuelles, cette dernière alimente la
base de données informationnelles qui contient les informations multi annuelles.
Le patrimoine informationnel budgétaire étant difficile à exploiter, la mise en

place d'outils décisionnels pour l'exploitation de ce patrimoine informationnel
constitue un axe prioritaire. Cette priorité s'explique d'une part par la demande
6
DB/DB2/DSI/SCD
croissante exprimée par les partenaires, aussi bien internes qu'externes, et

d'autre part par les recommandations de la commission qui a réalisé l’audit des
systèmes d’information du département des Finances et de la privatisation.
Vu la diversité des métiers de la DB, on se limitera dans ce rapport à

l’application du système décisionnel au domaine de la gestion des effectifs
budgétaires.
Ce rapport présente les démarches et les principales étapes établies pour la

conception et la mise en place d’un système décisionnel et en particulier qui
permettra aux décideurs de suivre l’évolution des effectifs budgétaires.
Ce rapport est composé de trois parties principales :
La première partie pointe sur la nécessité de mettre en place un système

décisionnel au sein de la Direction du Budget.
La seconde partie étudie les différents choix techniques de la modélisation du

système décisionnel relatif aux effectifs budgétaires.
La troisième partie détaille les méthodes et les techniques de la réalisation du

dite système décisionnel.
7
DB/DB2/DSI/SCD
CHAPITRE I
Contexte du projet
8
DB/DB2/DSI/SCD
I. Objectif du rapport
Le présent document a pour objectif la mise en valeur du travail élaboré pour

la conception et la réalisation du système décisionnel de la Direction de Budget.
Ce document établit donc une description détaillée des déroulements des travaux
réalisés à savoir:
Une présentation du système informatique de la gestion des postes
budgétaires.
Une documentation sur l’étude de conception de la plate décisionnelle.
Une description des étapes de la réalisation de cette plate forme
décisionnelle.
II. Contexte du projet
Dans le cadre de l’exécution de ses attributions, la Direction du Budget est

appelée à jouer un rôle important dans la maîtrise de l’évolution de la masse
salariale du personnel de l’Etat. Pour s’acquitter convenablement de cette mission,
la Direction du Budget a besoin notamment d’un outil informatique convivial,
simple à utiliser et facile à maintenir pour exploiter et valoriser son patrimoine
informationnel relatif au personnel de l’Etat.
Le système décisionnel de la DB sera composé d’un système décisionnel global
commun et des modules décisionnels particuliers pour les entités décisionnelles
qui auront des besoins d’analyse métier très fins et des besoins très spécifiques.
II.1. Objectif du projet
L’objectif essentiel de ce travail est de développer un système décisionnel

basé sur les outils Web qui aidera la Direction du Budget à mieux suivre
l’évolution des effectifs budgétaires.
Les principales composantes de ce travail s’articulent autour :
La conception et la modélisation d’un datawarehouse qui stocke les données
des effectifs budgétaires.
La conception et la création des cubes selon les différentes axes d’analyse et
indicateurs pour une analyse multidimensionnelle des effectifs budgétaires.
9
DB/DB2/DSI/SCD
Le développement et la publication des interfaces Web, pour une navigation

facile qui permet de faire des analyses selon différents critères et d’accéder
rapidement aux détails expliquant les synthèses résultantes.
II.2. Démarche du projet
Ce projet s’est focalisé sur la conception et la réalisation du système

décisionnel relatif aux effectifs budgétaires.
En premier lieu, il a été procédé à l’analyse du système informatique de la
gestion des effectifs budgétaires et à la spécification des besoins. Cette étape
consiste à recenser les besoins des utilisateurs en énumérant la liste des
demandes formulées par ces utilisateurs et en étudiant le système informatique
existant (bases de données et applications informatiques).
La seconde étape a consisté à l’étude et la conception de la plate forme
décisionnelle à mettre en place, on a alors identifié les différents indicateurs et
axes d’analyses pertinents qui permettront aux décideurs d’accéder aux données
d’analyse d’une manière simple et conviviale.
Ensuite, on a conçu une base de données décisionnelle qui constitue la plate-
forme d’aide à la décision et qui regroupe tout le patrimoine informationnel de la
Direction de Budget en vue de mieux suivre l’évolution des effectifs budgétaires.
Cette étape consiste à modéliser la conception déterminée lors de l’étape
précédente et à définir l’architecture de la plate-forme de la DB en identifiant les
systèmes de production comme sources de données, la zone de stockage comme
base de données décisionnelles et les méthodes d’extraction, de transformation et
de chargement des données.
La dernière étape est la présentation des informations sous une forme
conviviale et simple à exploiter par l’utilisateur final ; elle consiste à modéliser les
cubes, les construire et les publier dans le portail décisionnel de la DB.
10
DB/DB2/DSI/SCD
CHAPITRE II
Etude du système existant
11
DB/DB2/DSI/SCD
I. Processus et fonctionnement
La gestion des postes budgétaires permet à la direction Budget de bien

maîtriser l’évolution de l’effectif du personnel exerçant dans la fonction publique
pendant un exercice budgétaire (année budgétaire). Les effectifs de personnel
pour une année budgétaire sont classés par département et service ou par grade
et échelle.
L’avancement dans le grade est le passage d’un grade à un autre supérieur

selon le statut régissant ce type de poste budgétaire, ceci est autorisé par le
mouvement de la loi de finances nommée transformation du poste budgétaire.
La mutation d’un poste budgétaire d’un département vers un autre ou d’un
article vers un autre est autorisée par un transfert du type de poste budgétaire.
Les postes budgétaires alloués à un département et non occupés au cours de
l’année doivent être déduits de l’effectif budgétaires théorique du ministère. C’est
le CED qui détient la situation des postes vacants pour un ministère.
Les postes budgétaires sont supprimés suite aux départs en retraite, ou suite à
une vacance d’emploi.
La loi cadre est la situation des effectifs des postes budgétaires par
département pour l’année budgétaire en cours, elle définit la répartition des
postes budgétaires créés par la Loi de Finance du même exercice budgétaires. Elle
est édité une fois chaque année budgétaire.
Le système OTOR s’occupe de la prise en charge de la gestion de la loi cadre,

il est composé des modules suivants :
La nomenclature des postes budgétaires et administratives.
La prise en charge des effectifs budgétaires qui donne les nombres des
postes budgétaires, des fonctions de responsabilité et des échelles.
Les mouvements concernant les postes budgétaires de la loi de finances à
savoir les transferts et les transformations.
Les errata qui étaient pris en charge par la Direction de Budget avant
Janvier 2005.
12
DB/DB2/DSI/SCD
II. Architecture fonctionnelle
II.1. L’application « OTOR »

L’application « OTOR » consigne toutes les données concernant l’effectif
théorique, une fois qu’il est validé par la Loi de Finance.
Les données de cette application sont stockées dans une base de données sous
le SGBDR Ingres.
L’exercice de l’année N démarre au 1er janvier avec comme effectif initial celui
de l’année N-1.
Il est ensuite mis à jour selon un certain nombre de mouvements prévus par la
Loi de Finance au niveau des différents départements.
Les mouvements
Différents types de mouvements sont possibles au niveau des postes

budgétaires :
Transferts (T): Changement de types de postes budgétaires entre

services ou départements ;
Transformations (F): Changement d’un type de poste budgétaire vers un

autre type de poste budgétaire;
Transferts / Transformations (T/F): Changement combinant le transfert

et la transformation ;
Suppressions : Départs en retraite ou titularisation des postes

permanents ;
Créations :
• Créations normales : Nouveaux postes ;
• Créations régularisations (CR) : Titularisations des permanents ;
• Créations par le 1er Ministre (CP) : Créations de postes accordées

par le 1er Ministre ;
• Créations Titularisations (CT) : Titularisations prévues par la Loi de

Finance.
Errata : Transformations de postes vacants en cours d’exercice.
13
DB/DB2/DSI/SCD
La consultation
Les utilisateurs disposent d’une application annexe qui permet la consultation
des données de « OTOR ». Ils peuvent consulter par Département, chapitre ou
type de mouvement. Ainsi, ils peuvent produire leurs propres rapports et les
exporter vers Excel et les retravailler.
II.2. Les bases de données
Les données du système d’information sont réparties dans des tables selon les
règles de gestion de la Loi Cadre ou des tables de nomenclatures budgétaires :
Les tables de gestion de la Loi de Cadre :
Effectif : Elle contient la répartition des effectifs initiaux (au début de
l’année budgétaire) et des effectifs disponibles des postes budgétaires
par département.
Mouvement : Elle contient tous les mouvements des postes budgétaires,
l’effectif concerné et le type de ces mouvements.
Création : Elle contient tous les créations des postes budgétaires,
l’effectif concerné et le type de ces créations.
Les tables de nomenclatures budgétaires :

Année Loi de Finance : Elle contient une liste des exercices budgétaires.
Type de budget : Elle contient les différents type de budget.
Département : Elle contient la liste des départements ministériels.
Article : Elle contient la liste des articles appartement aux départements
ministériels.
Service : Table de service, soit central ou Extérieur, pour les
départements qui ont des délégations à l’extérieur de Rabat.
Catégorie : Elle contient la liste des catégories regroupant les corps des
types de poste budgétaires.
Corps : Elle contient la liste des corps regroupant les cadres des types
de postes budgétaires.
Cadre : Elle contient la liste des cadres regroupant les types de postes
budgétaires.
Type de poste budgétaires : Elle contient la nomenclature des grades.
14
DB/DB2/DSI/SCD
Les données sont stockées sous le SGBD INGRES, dans deux bases de données
différentes BUDGET_EXP et BUDGET_INFO :
« BUDGET_EXP » :
C’est la base d’exploitation qui gère les données des effectifs budgétaires de
l’exercice budgétaire en cours et enregistre les données des exercices budgétaires
précédents.
« BUDGET_INFO » :
C’est la base de données d’archivage, les données sont volatiles (non
modifiées dans le temps).
III. Besoin d’un système décisionnel
Le système de gestion de la loi cadre a pour objectif principal, la prise en

charge de la nomenclature budgétaire et administrative ainsi que et la gestion des
effectifs budgétaires, les mouvements et les errata. La DB a cumulé un patrimoine
informationnel très important. Ainsi, des écrans de consultations ont été
développés, ces consultations sont prédéfinies, L’utilisateur est amené à faire des
choix et des critères de son tableau de bord avant de le charger.
Les informations recueillies lors des réunions avec le Comité de Liaison

Informatique (CLI) et les requêtes fréquemment demandés par les responsables
des divisions sectorielles de la DB permettent de conclure qu’un système d’aide à
la décision est indispensable pour générer des rapports plus conviviaux, des
tableaux de bord plus adaptés et des graphiques plus signifiantes. Ainsi, le portail
décisionnel sera un outil de travail quotidien qui permettra aux utilisateurs de
gagner du temps dans leurs analyses multidimensionnelles.
15
DB/DB2/DSI/SCD
CHAPITRE III
Notions générales
16
DB/DB2/DSI/SCD
I. Le décisionnel
Le système d'information décisionnel est un ensemble de données organisées

de façon spécifique, facilement accessible et appropriées à la prise de décision ou
encore une représentation intelligente de ces données au travers d'outils
spécialisés. La finalité d'un système décisionnel est le pilotage de l'entreprise.
Les systèmes décisionnels sont dédiés au management de l'entreprise pour

l'aider au pilotage de l'activité, et indirectement opérationnels car n'offrant que
rarement le moyen d'appliquer les décisions. Ils constituent une synthèse
d'informations opérationnelles, internes ou externes, choisies pour leur pertinence
et leur transversalité fonctionnelles, et sont basés sur des structures particulières
de stockage volumineux (datawarehouse, bases OLAP). Le principal intérêt d'un
système décisionnel est d'offrir au décideur une vision transversale de l'entreprise
intégrant toutes ses dimensions.
Figure 1 : Le processus décisionnel
17
DB/DB2/DSI/SCD
II. Le datawarehouse
II.1. Définition du datawarehouse
Le datawarehouse est un entrepôt de données. Il s'agit d'un stockage

intermédiaire des données issues des applications de production, dans lesquelles
les utilisateurs finaux puisent avec des outils de restitution et d'analyse.
«Un datawarehouse est une collection de données thématiques, intégrées, non
volatiles et historiées pour la prise de décisions». Définition énoncée par Bill Inmon
Orientées sujet
Le datawarehouse est organisé autour des sujets majeurs et des métiers de

l'entreprise. Les données sont organisées par thème. L'intérêt de cette
organisation réside dans le fait qu'il devient possible de réaliser des analyses sur
des sujets transversaux aux structures fonctionnelles et organisationnelles de
l'entreprise. Cette orientation permet également de faire des analyses par
itération, sujet après sujet.
L'intégration dans une structure unique est indispensable pour éviter aux
données concernées par plusieurs sujets d'être dupliqué. Cependant dans la
pratique il existe également des datamarts. Le datawarehouse est fragmenté en
plusieurs bases qui supportent l'orientation sujet.
Données intégrées
Un datawarehouse est un projet d'entreprise. Il concerne les différents

services et métiers de l'entreprise. Avant d'être intégrées dans le datawarehouse,
les données doivent êtres mises en forme et unifiées afin d'avoir un état cohérent.
L'intégration nécessite une forte normalisation, une bonne gestion des référentiels
et de la cohérence, une parfaite maîtrise de la sémantique et des règles de
gestion s'appliquant aux données manipulées. C'est ainsi que l'on pourra donner
une bonne vision de l'entreprise via l'utilisation d'indicateurs.
Données historisées
L'historisation est nécessaire pour suivre dans le temps l'évolution des

différentes valeurs des indicateurs à analyser. Ainsi, un référentiel temps doit être
associé aux données afin de permettre l'identification dans la durée de valeurs
précises.
18
DB/DB2/DSI/SCD
Données non volatiles
Afin de conserver la traçabilité des informations et des décisions prises, les

informations stockées au sein du datawarehouse ne peuvent pas être supprimées.
Une requête lancée à différentes dates sur les mêmes données doit toujours
retourner les mêmes résultats. Une donnée introduite dans le datawarehouse ne
pourra donc plus être supprimée ni même modifiée. Dans le cas présent les
données ne sont pas volatiles.
Figure 2 : Schéma de principe du datawarehouse
Le datawarehouse est donc une sorte de point focal stockant en un point

unique toute l'information utile provenant des systèmes de production et des
sources externes. Avant d'être intégré dans le datawarehouse, l'information doit
être extraite des bases propriétaires et «nettoyée». Ensuite, elle doit être mise en
forme de manière à devenir compréhensible par l'utilisateur final.
19
DB/DB2/DSI/SCD
II.2. La structure du datawarehouse
Figure 3 : La structure du datawarehouse (source EDS-Prométhéus)
Un datawarehouse peut se structurer en quatre classes de données,

organisées selon un axe historique et un axe de synthèse.
Les données détaillées
Elles reflètent les événements les plus récents. Les intégrations régulières des
données issues des systèmes de production vont habituellement être réalisées à
ce niveau.
Les données agrégées
Elles correspondent à des éléments d’analyse représentatifs des besoins

utilisateurs. Elles constituent déjà un résultat d’analyse et une synthèse de
l’information contenue dans le système décisionnel, et doivent être facilement
accessibles et compréhensibles.
Les métadonnées
Très souvent les données à fédérer dans le datawarehouse proviennent de

sources très hétérogènes. Cela rend indispensable la présence d'un dictionnaire
unique qui sait gérer l'ensemble des fonctions du datawarehouse. Cette cohérence
du dictionnaire est décrite au sein des métadonnées du dictionnaire du
datawarehouse.
20
DB/DB2/DSI/SCD
Les métadonnées constituent l'ensemble des données qui décrivent des règles
ou des processus attachés à d'autres données. Ces dernières constituent la finalité
du système d'information.
Les données historisées
Chaque nouvelle insertion de données provenant du système de production ne

détruit pas les anciennes valeurs, mais créée une nouvelle occurrence de la
donnée.
III. composition du système d'information décisionnel
III.1. Les sources de données
Ces sources de données sont multiples : données internes (bases de données

de production, applications métiers…) ou données externes (bases de données des
partenaires tel que le CED, la PPR, la DEPG, ou tous autres informations
économiques non produites par la direction de Budget)
III.2. Le système d’alimentation (ETL)
Le système d'alimentation ou l’ETL (Extract Transform Loading), recouvre à la

fois des outils et le processus d’alimentation. Il s’agit d’un élément clé dans
l’intégration d’applications, en particulier dans le domaine du décisionnel et du
datawarehouse.
L’outil ETL récupère toutes ces données et les centralise dans une base de
données particulière appelée datawarehouse, datamarts ou entrepôt de données.
Les outils ETL permettent de récupérer les données quels que soient leurs sources
et les systèmes qui les supportent (système d’exploitation, SGBD, formats…),
d’automatiser et d’industrialiser le processus d’alimentation, de faciliter la
maintenance des données et de limiter les développements spécifiques.
Le processus ETL est une opération de migration de données qui représente

une part majeure des traitements et nécessite une attention régulière tout au long
du cycle de vie du système. Un processus ETL se décompose en trois phases :
l'extraction, la préparation/transformation et le chargement.
21
DB/DB2/DSI/SCD
L’extraction des données :

Il s’agit en premier lieu d'aller chercher les données là où elles se trouvent.
L'outil ETL a la capacité de se connecter aux différentes applications, bases de
données ou fichiers.
La transformation et le contrôle des données :
Les ETL sont des ateliers spécialisés dans la migration de données. La
transformation des données est leur fonctionnalité principale. Ils disposent d’une
fonction permettant de vérifier qu’une donnée est cohérente par rapport aux
données déjà existantes dans la base cible, ils ont des outils de conversion de
données et ils sont conçus pour manipuler de gros volumes de données. L’étape
de contrôle s’effectue par application de règles adaptées sur les flux de données
entrant.
Le chargement et le transfert des données :
Le chargement prend en compte la gestion du format final des données. Pour
la mise en oeuvre du transfert de données.
Figure 4 : Le système d'alimentation
22
DB/DB2/DSI/SCD
III.3. Datawarehouse, datamart, entrepôt de données
Il s’agit de la base ou des bases dédiées recueillant et gérant toutes les

données collectées, transformées et préparées à des fins de traitement
décisionnel. Les outils d’analyse accèdent directement à ces données.
III.4. Analyse multidimensionnelle OLAP
Les outils OLAP (On-Line Analytical Processing) permettent de modéliser

l'activité d'une entreprise suivant des axes. Par exemple, le chiffre d'affaires par
catégorie de client sur un produit donné se décline en trois axes au minimum:
chiffre d'affaires, catégorie de clients et produit.
On appelle « cube OLAP » une représentation en axes. Cette structure
présente de nombreux avantages. En effet, un utilisateur peut rechercher une
représentation du chiffre d'affaires par produit et par région. Puis, après réflexion,
préférer une représentation par région et par produit.
III.5. Système de diffusion et de présentation
Les portails décisionnels permettent de créer un point d'accès unique vers les
informations hétérogènes de l'entreprise. C'est l'élément le plus important pour
l'utilisateur car il correspond à la partie visible du système. Quelles que soient les
solutions retenues, elles doivent être simples à utiliser et être compatibles avec
les outils bureautiques existants.
Un SIAD (Système Interactif d'Aide à la Décision) est un outil d'analyse et de
modélisation des données de l'entreprise qui permet de créer des représentations
multidimensionnelles de l'information.
23
DB/DB2/DSI/SCD
Portail décisionnel SIAD
Effectif
Grade
Echelle
Département
Année LF
….
Figure 5 : Représentation de la modélisation et la présentation
24
DB/DB2/DSI/SCD
CHAPITRE IV
Analyse et conception
25
DB/DB2/DSI/SCD
I. Modélisation multidimensionnelle
Une caractéristique du décisionnel est que les utilisateurs cherchent

fréquemment à mettre en relation des éléments qui à priori ne sont pas corrélés
au départ. Pour y parvenir, des demandes complexes sont nécessaires
interrogeant un grand nombre de tables. Ces demandes nécessitent un temps
important pour être résolues.
Plusieurs solutions ont été proposées par les chercheurs pour répondre aux
besoins des utilisateurs en améliorant les temps de réponse, parmi elles,
l’adoption de la modélisation multidimensionnelle. Cette modélisation se base sur
l'application au Datawarehouse les concepts de dimensions et de mesures :
Chaque table de dimension donnera les différentes informations pour

construire l'axe.
Pour ce qui est des mesures, on aura une table des faits qui regroupe pour
chaque n-uplet (dim1, dim2, dim3...) la valeur désirée.
Une requête consistera donc à sélectionner les n-uplets correspondant aux
dimensions et à agréger les données.
Parmi les modèles de la modélisation multidimensionnelle, on peut citer le

schéma en étoile et le schéma en flocon.
La modélisation en étoile est une structure dans laquelle les données sont
conservées dans une table de faits unique au centre du schéma avec des données
de dimensions supplémentaires stockées dans des tables dites tables des
dimensions. Chaque une de ces tables des dimensions est directement liée à la
table de faits par une colonne de clé.
La modélisation en flocon est une modélisation en étoile pour laquelle en

éclate les tables des dimensions en sous-tables selon la hiérarchie de cette
dimension, ce qui signifie une conservation de la forme dimensionnelle normale
existante au niveau de la base de production.
26
DB/DB2/DSI/SCD
DIMENSION1
Clé1
Info
T-FAITS
Clé1
DIMENSION2 Clé2 DIMENSION3
Clé2 Clé3 Clé3
Info Clé4 Info
Mesure1
Mesure2
DIMENSION4
Clé4
Clé41
Clé42
Info
Figure 6 : Exemple d’un modèle en étoile.
DIMENSION1
Clé1
Info
T-FAITS
Clé1
DIMENSION2 Clé2 DIMENSION3
Clé2 Clé3 Clé3
Info Clé4 Info
Mesure1
Mesure2
DIMENSION4
Clé4
Clé41
Clé42
Info
DIMENSION41 DIMENSION42
Clé41 Clé42
Info Info
Figure 7 : Exemple d’un modèle en Flocon.
27
DB/DB2/DSI/SCD
II. Spécification des dimensions et des mesures
Afin de déterminer les différentes dimensions et axes d’analyse du cube à

réaliser, nous avons tenus a des réunions avec des CLI et nous avons étudié les
différentes demandes et requêtes formulés par les utilisateurs finaux. Ces besoins
ont été formalisés selon la démarche suivante :
Identification des domaines d’analyse ou Préoccupations,
Conception des mesures de performances,
Identification des dimensions (ou axes d’analyse des mesures retenues),
Hiérarchisation des dimensions en niveaux de manière à affiner l’analyse.
II.1. Indicateurs
Un indicateur est une combinaison de deux ou plusieurs données qui renseigne

sur les changements d’une variable donnée dans le temps et dans l’espace. En
d’autres termes, l’indicateur est une mesure objective (vérifiable et indicative) qui
reflète l’état (le statut) d’une variable qu’on voudrait mesurer. Enfin l’indicateur
peut être un chiffre, un taux, un ratio, une moyenne.
Les indicateurs relevés lors de cette phase d’analyse sont :
Effectif initial : c’est l’effectif des postes budgétaires au début de

l’exercice budgétaires en cours, il est égal à l’effectif des postes budgétaires
à la fin de l’exercice budgétaires précédent.
Effectif crée : c’est le nombre des postes budgétaires crée depuis le début
de l’année budgétaire jusqu’au jour j. Il ne doit pas être dépassé le nombre
arrêté par la Loi de Finance.
Effectif supprimé : c’est l’effectif des postes budgétaires supprimés suite

au départ à la retraite.
Effectif disponible : c’est l’effectif des postes budgétaires actuel au jour j.
Effectif transféré : c’est Effectif des postes budgétaires transférés vers un

autre département.
Effectif transformé : c’est Effectif des postes budgétaires transformés

vers un type de poste budgétaire
28
DB/DB2/DSI/SCD
Effectif transféré/transformé : Effectif des postes budgétaires transférés

et transformés vers un autre département et un autre TPB.
II.2. Axes
Un ensemble de données du même type, permettant de structurer la base

multidimensionnelle. Une dimension est parfois appelée un axe. Chaque cellule
d'une mesure est associée à une seule position de chaque dimension. Les axes
d’analyses représentent les dimensions construisant le cube de donnée. Les
différents axes relevés sont :
Exercices : L’exercice ou Année Loi de Finances est l’année budgétaire

pour laquelle l’ensemble des ressources et des charges de l’Etat sont
prévues, évaluées et autorisées. Cette dimension sera hiérarchisée selon le
niveau Année et Mois en fonction des cubes.
Départements : Le département correspond à un ministère du royaume,

exemple le « Ministère des Finances et de la Privatisation ». Il peut être
composé de plusieurs articles (essentiellement les directions), lesquels
appartiennent à un service soit central (à Rabat), soit extérieur (ayant une
délégation dans d’autres villes du royaume). Cet axe peut être décliné selon
quatre niveaux :
Type de budget : deux différents types de budget : budget général et

budget annexe qui en voie d’extinction.
Département : représentant l’ensemble des ministères,
Article,
Service.
TPB : Cette dimension dont la structure est conforme à la nomenclature

des types de postes budgétaires est composée de quatre niveaux d’analyse :
Catégorie : Les catégories se situent au premier niveau de groupement

des postes, elles correspondent aux départements dont elles portent les
mêmes codes, hormis les catégories (96, 97, 98, 99) dont les postes
sont communs à plusieurs départements.
Corps : Second niveau de groupement
29
DB/DB2/DSI/SCD
Cadre : Troisième niveau
TPB : dernier niveau qui correspond aux postes eux-mêmes.
Echelle : Cette dimension représente la classification du personnel de

l’administration publique. Elle est regroupé selon la classe d’échelles : agents
d’exécution, agents de maîtrise, cadres et cadres supérieurs.
III. Conception du modèle décisionnel
III.1. Tables de faits

Chaque Datawarehouse ou DataMart comprend une ou plusieurs tables de
faits (table des mesures). Située au centre d'un schéma en étoile ou en flocon,
une table de faits capture les données qui mesurent les activités de l'entreprise.
Elle peut contenir des événements de mouvements, tels que les créations, les
transformations, les transferts ou les suppressions. Les tables de faits comportent
généralement une multitude de lignes, représentant souvent des millions
d'enregistrements lorsqu'elles couvrent une ou plusieurs années de l'historique.
Dans le cadre de ce projet, la table de fait « TF_effectif » du DataMart
« effectif » contient les colonnes suivantes :
Nom du champ description
Anlf_an Clé étrangère de la table de dimension Dim_Anlf
Anlf_num Clé étrangère de la table de dimension Dim_Anlf
Typb_typ Clé étrangère de la table de dimension Dim_Typb
Dept_cd Clé étrangère de la table de dimension Dim_Dept
Artl_cd Clé étrangère de la table de dimension Dim_Artl
Serv_cd Clé étrangère de la table de dimension Dim_Serv
Catg_cd Clé étrangère de la table de dimension Dim_Catg
Corp_cd Clé étrangère de la table de dimension Dim_Corp
Cadr_cd Clé étrangère de la table de dimension Dim_Cadr
Tpb_cd Clé étrangère de la table de dimension Dim_Tpb
Echelle_cd Clé étrangère de la table de dimension Dim_Echl
Efct_ini Colonne numérique indiquant l’effectif initial au début de l’exercice
budgétaire
Efct_desp Colonne numérique indiquant l’effectif disponible à la fin de l’exercice
budgétaire
Efct_cree Colonne numérique indiquant l’effectif crée au cours de l’année
budgétaire
Efct_supp Colonne numérique indiquant l’effectif supprimé au cours de l’année
budgétaire
Mvt_t Effectif transféré vers un autre département.
Mvt_f Effectif transformé vers un autre type de poste budgétaire.
Mvt_tf Effectif transféré et transformé vers un autre département et un autre
TPB.
30
DB/DB2/DSI/SCD
III.2. Tables de dimensions
Les tables de dimension contiennent des attributs qui décrivent les

enregistrements qui sont mesurés dans la table de faits. Certains de ces attributs
fournissent des informations descriptives ; d'autres servent à spécifier la façon
dont les données de la table de faits doivent être synthétisées afin de fournir des
informations pertinentes à l'analyste. Les tables de dimension contiennent des
hiérarchies d'attributs qui facilitent la synthèse. Par exemple, une dimension
comprenant des informations sur les types de postes budgétaires contient
souvent une hiérarchie qui répartit les TPB en catégories, telles que personnels
communs à l’administration ou personnel du ministère des finances, chacune
d'elles comportant des corps, des cadres jusqu'au dernier niveau qui représente
le type de poste budgétaires.
L’analyse du système de gestion des postes budgétaires a distingués les tables

de dimensions suivantes :
Dim_Anlf : Table de dimension de l’année de Loi de Finance, elle définit

l’année de Loi de Finance ainsi que le numéro de Loi.
Dim_Catg: Table de dimension regroupant les catégories des postes
budgétaires.
Dim_Corp: Table de dimension qui contient la liste des corps des postes
budgétaires.
Dim_Cadr: Table de dimension qui contient la liste des cadres des postes
budgétaires.
Dim_Tpb: Table de dimension des types de postes budgétaires ou grades
tells qu’ils sont définis par la nomenclature budgétaires.
Dim_Typb : Table de dimension des types de budget général ou annexe.
Dim_Dept: Table de dimension des départements ministériels.
Dim_Artl: Table de dimension des articles appartenant aux départements
ministériels.
Dim_Serv: Table de dimension qui regroupe les services soit central (à
Rabat), soit extérieur (ayant une délégation dans d’autres villes du royaume).
31
DB/DB2/DSI/SCD
Dim_Echl: Table de dimension qui regroupe la liste des échelles de la

fonction publique.
Dim_Cl_Echl : Table de dimension qui classe les échelles du personnel de
l’Etat en quatre catégorie : agents d’exécution, agents de maîtrise, cadres et
cadres supérieurs.
III.3. Modèle du cube « Effectif »
La conception du cube effectif a relevé le modèle basé sur les mesures et

les dimensions suivantes :
Les Mesures :
Effectif initial, Effectif crée, Effectif supprimé, Effectif disponible, Effectif

transféré, Effectif transformé et l’Effectif Transféré/Transformé.
Les dimensions :
La structure de la hiérarchisation des niveaux des dimensions est la

suivante :
Nom de
Exercice Département TPB Echelle
l’axe
Niveau Année Type budget Catégorie Classe d’échelles
Loi Département Corps Echelle
Article Cadre
Service TPB
32
DB/DB2/DSI/SCD
III.4. Modèle physique de données
Le modèle physique de données est un modèle en flocon, il est décrit sur la

figure suivante.
Modèle Physique de Données

Modèle : Modele_en_Flocon du DataMart "Effectif"
Package :
Diagramme : Diagramme_1
Auteur : TALAGHZI Badr Date : 23/02/2006
Version :
Dim_dept
Dim_TPB
Dim_Cadr Dim_Typb
Dim_Artl
TF_Effectif
Dim_Corp
Dim_Serv
Dim_Anlf
Dim_Catg
Dim_Echl
Dim_Cl_Echl
Figure 8 : Modèle en Flocon du DataMart "Effectif"
33
DB/DB2/DSI/SCD
CHAPITRE V
Réalisation de la plate forme
décisionnelle
34
DB/DB2/DSI/SCD
Suite à l’appel d’offre 65/2004/MFP/DB/INF, la Direction Budget a acquis par

l’intermédiaire de ARCHOS CONSEIL, une plate forme décisionnelle Cognos.
La réalisation et le suivi du projet est assuré par une équipe informatique du
service Décisionnel et Communication de la direction de Budget de quatre
personnes dont je suis le chef de projet.
Une assistance technique a été assurée par une équipe technique de ARCHOS
CONSEIL.
I. La plate forme matériel
L’installation du serveur décisionnel a été faite sur un serveur IBM XSERIES

345 dont les caractéristiques sont les suivantes :
Processeur : Bi-processeur Intel XEON 2.4 Ghz
RAM : 1Go
Disque Dur : 3 disques de 73.4 Go en RAID 5
Système d’exploitation : Windows 2000 Advanced Server service pack 4
Serveur de base de données : Microsoft SQL Server 2000 service pack 3
II. La plate forme logiciel
Les outils Cognos qui ont été installés sur le serveur DECISIONNEL sont les
suivants :
Cognos ReportNet: c’est une solution de reporting basée sur le Web, il
est composé des modules suivants :
Framework Manager : ce module est utilisé pour créer et publier les

modèles de métadonnées sur les quels les rapports sont basés. Ces
modèles de métadonnées servent aussi comme source de données pour la
création des cubes.
Cognos Connection : il s’agit du portail Web qui donne accès à toutes

les informations ReportNet.
35
DB/DB2/DSI/SCD
Query Studio : ce composant est utilisé pour créer des rapports Ad

Hoc.
Report Studio : ce module sert pour créer des rapports plus
perfectionnés.
Cognos PowerPlay : c’est une solution qui permet d’analyser les données
stratégiques de la DB sous différents angles et selon plusieurs combinaisons. Il
se compose de :
PowerPlay Entreprise Server : (PPES) est le serveur d’applications, il

traite et synthétises les données au niveau de la couche d’application. Il ne
présente que la couche des résultats. Partant du récapitulatif des
informations, les utilisateurs peuvent étudier les tendances et effectuer des
analyses descendantes, limitant le nombre des requêtes et le accès eux
entrepôts de données.
PowerPlay Transformation Server : Le moteur de transformation de
PowerPlay est l’outil de Cognos de modélisation des données et de création
de cubes. il lit et manipule les données des différentes bases et fichiers. Il
est accessible via une interface graphique. Les cubes créés sont ensuite
publiés et visualisés via une interface Web.
III. Les sources de données
Comme il a été déjà cité dans l’étude de l’existant, les sources de données
sont hébergées par le système de gestion de bases de données INGRES dans un
environnement UNIX.
IV. Le chargement de l’entrepôt des données
IV.1. Extraction des données
L’extraction des données de sources des tables de dimensions et de la table de

fait est exécutée par un lot DTS (Data Transformation Services) de Microsoft SQL
SERVER sur le serveur DECISIONNEL.
36
DB/DB2/DSI/SCD
Figure 9 : Lot DTS : Chargement des données de INGRES
Ce lot contient deux connexions, deux tâches d’exécutions de requêtes SQL et

seize tâches de transformations de données schématisées par des flèches noires
entre la Connexion BUD_EXP(INGRES) et effectif(DECISIONNEL)
Ce lot DTS permet d’extraire les données de la source vers le DataMart

hébergé sous MSQL SERVER, le tableau suivant décrit les différentes extractions :
SOURCE DESTINATION OBSERVATION

(INGRES) (MSQL SERVER
2000)
Anlf Dim_Anlf Table de dimension
Artl Dim_Artl Table de dimension
Catg Dim_Catg Table de dimension
Corp Dim_Corp Table de dimension
Cadr Dim_Cadr Table de dimension
Tpb Dim_Tpb Table de dimension
Dept Dim_Dept Table de dimension
Serv Dim_Serv Table de dimension
Echl Dim_Echl Table de dimension
37
DB/DB2/DSI/SCD
Typb Dim_Typb Table de dimension

Efct Efct Table source pour le chargement de la table de fait
Creation Creation Table source pour le chargement de la table de fait
Mvt Mvt Table source pour le chargement de la table de fait
Mvt_type Mvt_type Table source pour le chargement de la table de fait
IV.2. Traitement des données
Ce lot permet de charger la table de fait « TF_Effecif », de mettre à jour les

informations sur les échelles, les effectifs créé, supprimé et mouvementé. Le
tableau suivant décrit les différents traitements de cette étape :
TF_EFFECTIF SOURCE TRAITEMENT

Anlf_an Efct.Anlf_an Copie de colonne de la table Efct
Anlf_num Efct.Anlf_num Copie de colonne de la table Efct
Typb_typ Efct.Typb_typ Copie de colonne de la table Efct
Dept_cd Efct.Dept_cd Copie de colonne de la table Efct
Artl_cd Efct.Artl_cd Copie de colonne de la table Efct
Serv_cd Efct.Serv_cd Copie de colonne de la table Efct
Catg_cd Efct.Catg_cd Copie de colonne de la table Efct
Corp_cd Efct.Corp_cd Copie de colonne de la table Efct
Cadr_cd Efct.Cadr_cd Copie de colonne de la table Efct
Tpb_cd Efct.Tpb_cd Copie de colonne de la table Efct
Echelle_cd Dim_Tpb.echl_cd Mise à jour de l’échelle à partir de la table Dim_Tpb
Efct_ini Efct.Efct_ini Copie de colonne de la table Efct
Efct_disp Efct.Efct_disp Copie de colonne de la table Efct
Efct_cree Creation.crea_eff Mise à jour de l’effectif créé à partir de la table Creation
(type de Creation <> ‘S’)
Efct_supp Creation.crea_eff Mise à jour de l’effectif supprimé à partir de la table
Creation (type de Creation = ‘S’)
Mvt_t Mvt.mvt_eff Mise à jour de l’effectif Transféré à partir de la table Mvt
(type de mouvement est ‘T’ ou ‘MT’)
Mvt_f Mvt.mvt_eff Mise à jour de l’effectif Transformé à partir de la table
Mvt (type de mouvement est ‘F’ ou ‘MF’)
Mvt_tf Mvt.mvt_eff Mise à jour de l’effectif Transféré/Transformé à partir de
la table Mvt (type de mouvement est ‘TF’ ou ‘MTF’)
Le script SQL de traitement et de chargement de la table de fait TF_Effectif est

joint dans l’annexe A
38
DB/DB2/DSI/SCD
Figure 10 : Lot DTS : Traitements des données de la Table de fait
IV.3. Chargement des données
Le chargement des données est fait dans le DataMart « Effectif » sur le

serveur DECISIONNEL.
39
DB/DB2/DSI/SCD
V. La création et la publication des cubes
V.1. Le modèle des métadonnées
Le modèle des métadonnées a été conçu avec Cognos Framework Manager,

on se base sur le modèle en flocon.
La publication du modèle nous permet aussi de créer des fichiers (*.iqd) qui
servent comme sources de données pour la création des cubes plus tard par
Cognos Transformation Server.
Ces fichiers (*.iqd) ou « définition d’interrogation d’impromptu » sont de
simples requêtes SQL qui interrogent l’entrepôt de données. Vous trouverez dans
l’annexe B un exemple de fichier (*.iqd).
Figure 11 : Framework Manager : Modèle des effectifs Budgétaires
40
DB/DB2/DSI/SCD
V.2. La création des cubes
La conception et la création du cube sont faites par l’outil Cognos PowerPlay

Transformation Server, il s’agit d’abord de définir les sources de données (les
fichiers iqd) identifier les mesures, définir leurs propriétés et construire les
dimensions avec leurs différents niveaux.
Les formats d’affichages et les profils de sécurité doivent être identifiés à ce

stade, avant la génération et la création des cubes.
Figure 12 : Transformer: Modèle des effectifs Budgétaires
41
DB/DB2/DSI/SCD
V.3. La publication des cubes
La dernière étape avant l’exploitation du cube est sa publication sur le portail

d’analyse décisionnel (PPES).
L'utilitaire Administration des serveurs fournit un point d'accès unique aux

outils d'administration et indique l'ordre à suivre pour configurer et exécuter une
application serveur Cognos. Il agit comme une console pour les utilitaires
d'administration appropriés, notamment PowerPlay Entreprise Server. C’est
l’utilitaire qui permet de publier les cubes sur le portail PPES.
L’accès aux cubes est possible par deux voies , le premier c’est Cognos
UpFront produit du PPES, le second est le portail de Cognos ReportNet.
Figure 13 : PowerPlay Entreprise Server : Administration des serveurs
42
DB/DB2/DSI/SCD
VI. L’utilisation et l’administration
VI.1. La sécurité
L’utilisation du portail PPES de Cognos est sécurisée par une authentification
Figure 14 : Cognos Access Manager : Connexion à UpFront
Les informations de sécurité pour les applications de Cognos BI sont gérées

par l’utilitaire Cognos Access Manager, il fournit un environnement centralisé qui
permet de définir, de stocker et de gérer toutes ces informations.
VI.2. L’utilisation
L'application UpFront de Cognos est une interface utilisateur personnalisable

qui permet de publier, rechercher, organiser et afficher des données sur le Web.
43
DB/DB2/DSI/SCD
Figure 15 : Cognos UpFront : Gestion des rapports et des cubes
PowerPlay Web Explorer autorise une approche multidimensionnelle de

l'analyse. Il rassemble les dimensions clés et permet d'explorer toute combinaison
de données : vers les niveaux supérieurs, inférieurs ou au sein des dimensions
critiques.
Dans le navigateur Web, vous pouvez :
explorer des informations, soit dans une seule dimension à la fois, soit en
utilisant plusieurs niveaux pour différentes dimensions ou pour les mêmes
(catégories imbriquées),
comparer des données à l'aide de mesures quantitatives telles que le
revenu ou la marge bénéficiaire,
ajouter vos propres calculs aux résultats,
afficher des informations sous forme de valeurs réelles, de pourcentages
ou dans d'autres monnaies,
44
DB/DB2/DSI/SCD
filtrer des données,

supprimer, mettre en évidence et trier des valeurs,
choisir le type de graphique, tel qu'un tableau ou un graphique circulaire
ou à barres, ainsi que la quantité de données à afficher,
échanger les lignes et les colonnes, limiter le nombre de lignes et de
colonnes du graphique, réorganiser les mesures de vos données,
accéder aux catégories de niveau inférieur,
publier, exporter ou imprimer des rapports.
Figure 16 : Cognos PowerPlay Web
VI.3. Les prérequis
Pour une bonne visualisation du portail d’analyse décisionnel PPES, il est

recommandé :
Une utilisation de Microsoft Internet Explorer Version 6 et plus.
Une résolution d’écran 800/600 pixels minimum.
L’installation de l’Adobe Acrobat Reader et/ou Ms Excel pour
l’exportation des rapports confectionnés.
45
DB/DB2/DSI/SCD
Figure 17 : Cognos PowerPlay Web : Exemple d’affichage graphique
46
DB/DB2/DSI/SCD
VI.4. L’administration
L’administration de la plate forme décisionnelle assure la continuité de

l’exploitation des données multidimensionnelles. En collaboration avec le service
exploitation et support les tâches suivantes ont été mise en action :
Structurer les répertoires qui contiennent les fichiers de métadonnées et

les fichiers de données,
Mettre un plan de sauvegarde périodique de tous ces répertoires et tous
les bases de données qui contiennent l’entrepôt de données,
Définir des procédures de restaurations,
La mise à jour des données multidimensionnelles par l’alimentation des
nouvelles données, la création et la distribution des cubes.
47
DB/DB2/DSI/SCD
Conclusion &
recommandations
48
DB/DB2/DSI/SCD
Tout au long de ce travail, nous avons tenté de concevoir et de réaliser une

plate forme décisionnelle basée sur le métier des effectifs budgétaires. En effet, le
présent rapport relate les différentes étapes réalisées pour réussir ce travail. En
l’occurrence, l’étude du système opérationnel existant, la conception du datamart
et la création des cubes et leur distribution sur le Web. Ainsi, l’exploitation du
portail Décisionnel et la navigation dans les données multidimensionnelles
agrégées nous a permis de confectionner des tableaux de bord concis et des
situations explicatifs chiffrées couplés de graphiques, et ce en un temps réduit.
Compte tenu du périmètre de ce travail, une étude a été faite sur l’ensemble
des métiers de la direction de budget pour la réalisation d’une plate forme
décisionnelle globale et un datawarehouse général. Cependant, il est recommandé
de réaliser des DataMarts plus spécialisés, chacune ciblant un métier de la
Direction de Budget, avant de les regrouper et concevoir un datawarehouse qui
englobe tout son patrimoine informationnel.
Le périmètre d’application de ce projet peut aussi s’étendre aux techniques de

simulation et de prévisions à travers la mise à contribution d’autres outils tiers.
Cependant, la réussite de ce projet ne peut être complète que par une

introduction de la culture décisionnelle auprès des utilisateurs et informaticiens et
ce par des formations continues sur les concepts décisionnels et sur l’utilisation du
portail décisionnel.
L’Internet peut élargir le spectre des utilisateurs potentiels de ce système. En

effet, destinées jusqu’à présent aux seuls utilisateurs de la DB, le système
connaître une extension aux partenaires de la DB à travers un extra net sécurisé.
49
DB/DB2/DSI/SCD
Ce travail peut être étendue par l’intégration de nouveaux critères et axes

d’analyses. Ces informations doivent être mobilisées auprès des partenaires
externes tel que la Direction des statistiques pour recouper avec l’effectif de la
population selon différents profils. D’autres échanges de données avec d’autres
partenaires externes doivent être automatisés pour enrichir le datawarehouse
d’une manière régulière.
Par ailleurs, l’utilisation des techniques de datamining permettrait d’extraire

des connaissances à partir des informations du datawarehouse et des règles de
gestion à implémenter dans ce datamining.
50
DB/DB2/DSI/SCD
Bibliographie
[1] La construction du datawarehouse, du datamart au dataweb;
Jean-François Goglin;
Nouvelles Technologies Informatiques;
Ed. HERMES.
[2] SQL Server2000, Manuel de formation
[3] Manuel Cognos PowerPlay Web Explorer
Archos – Conseil
[4] Cognos PowerPlay Entreprise Server Administration
Guide de l’étudiant
Archos – Conseil
[5] Cognos Access Manager – Administration
Guide de l’étudiant
Archos – Conseil
Lien :
http://www.cognos.fr
http://www.guideinformatique.com
http://www.decisionnel.net/
51
DB/DB2/DSI/SCD
Annexes
52
DB/DB2/DSI/SCD
Annexe –A-
Script SQL pour la mise à jour de l’échelle
Tache d’exécution MAJ_ECHELLE
update TF_Effectif
set echelle_cd = t.echl_cd
from TF_effectif e , dim_tpb t
where
t.anlf_an = e.anlf_an and
t.anlf_num = e.anlf_num and
t.catg_cd = e.catg_cd and
t.corp_cd = e.corp_cd and
t.cadr_cd = e.cadr_cd and
t.tpb_cd = e.tpb_cd
Script SQL pour la mise à jour de l’effectif créé
Tache d’exécution MAJ_Efct_cree
update TF_Effectif
set efct_cree = t.crea_eff
from TF_effectif e , creation t
where
t.crea_typ <> 'S' and -- S = Suppression
t.tpb_cd = e.tpb_cd and
t.typb_typ =e.typb_typ and
t.dept_cd = e.dept_cd and
t.artl_cd = e.artl_cd and
t.serv_cd = e.serv_cd
53
DB/DB2/DSI/SCD
Script SQL pour la mise à jour de l’effectif supprimé
Tache d’exécution MAJ_Efct_supp
update TF_Effectif
set efct_supp = t.crea_eff
from TF_effectif e , creation t
where
t.crea_typ = 'S' and -- S = Suppression
t.tpb_cd = e.tpb_cd and
t.typb_typ =e.typb_typ and
t.dept_cd = e.dept_cd and
t.artl_cd = e.artl_cd and
t.serv_cd = e.serv_cd
Script SQL pour la mise à jour de l’effectif mouvementé
Tache d’exécution MAJ_MVT
--Depart
--Transfert
update TF_Effectif
set mvt_t = - c.mvt_eff
from mvt c , TF_Effectif t
where
c.[typb_typ1]= t.typb_typ and
c.[dept_cd1] = t.dept_cd and
c.[artl_cd1] = t.artl_cd and
c.[serv_cd1] = t.serv_cd and
c.[catg_cd1] = t.catg_cd and
c.[corp_cd1] = t.corp_cd and
c.[cadr_cd1] = t.cadr_cd and
c.[tpb_cd1] = t.tpb_cd and
c.[anlf_an]= t.anlf_an and
c.[anlf_num]= t.anlf_num and
c.mvt_typ in ('T','MT')
54
DB/DB2/DSI/SCD
--transformation
update TF_Effectif
set mvt_f = - c.mvt_eff
where
c.mvt_typ in ('F','MF')
-- transfert transformation
update TF_Effectif
set mvt_tf = - c.mvt_eff
where
c.mvt_typ in ('TF','MTF')
-- destination
-- changement du dep et tpb
update TF_Effectif
set mvt_tf = mvt_tf + c.mvt_eff
where
c.mvt_typ in ('TF','MTF')
-- changement du departement
update TF_Effectif
set mvt_t = mvt_t + c.mvt_eff
where
55
DB/DB2/DSI/SCD

c.mvt_typ in ('T','MT')
---changement du tpb
update TF_Effectif
set mvt_f = mvt_f + c.mvt_eff
where
c.mvt_typ in ('F','MF')
56
DB/DB2/DSI/SCD
Annexe –B-
Exemple de fichier (iqd) du modèle « TF_Effectif »
COGNOS QUERY
STRUCTURE,1,1
DATABASE,effectif
TITLE,[effectif].[TF_Effectif]
BEGIN SQL
{select "TF_Effectif"."anlf_an" AS "anlf_an",
"TF_Effectif"."anlf_num" AS "anlf_num",
"TF_Effectif"."typb_typ" AS "typb_typ",
"TF_Effectif"."dept_cd" AS "dept_cd",
"TF_Effectif"."artl_cd" AS "artl_cd",
"TF_Effectif"."serv_cd" AS "serv_cd",
"TF_Effectif"."catg_cd" AS "catg_cd",
"TF_Effectif"."corp_cd" AS "corp_cd",
"TF_Effectif"."cadr_cd" AS "cadr_cd", "TF_Effectif"."tpb_cd"
AS "tpb_cd", "TF_Effectif"."echelle_cd" AS "echelle_cd",
"TF_Effectif"."efct_init" AS "efct_init",
"TF_Effectif"."efct_disp" AS "efct_disp",
"TF_Effectif"."efct_cree" AS "efct_cree",
"TF_Effectif"."efct_supp" AS "efct_supp",
"TF_Effectif"."mvt_t" AS "mvt_t", "TF_Effectif"."mvt_f" AS
"mvt_f", "TF_Effectif"."mvt_tf" AS "mvt_tf"
from "effectif"."dbo"."TF_Effectif" "TF_Effectif"}
END SQL
COLUMN,0,anlf_an
COLUMN,1,anlf_num
COLUMN,2,typb_typ
COLUMN,3,dept_cd
COLUMN,4,artl_cd
COLUMN,5,serv_cd
COLUMN,6,catg_cd
COLUMN,7,corp_cd
COLUMN,8,cadr_cd
COLUMN,9,tpb_cd
COLUMN,10,echelle_cd
COLUMN,11,efct_init
COLUMN,12,efct_disp
COLUMN,13,efct_cree
COLUMN,14,efct_supp
COLUMN,15,mvt_t
COLUMN,16,mvt_f
COLUMN,17,mvt_tf
57

Conception D'un Système D'aide À La Décision

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception D'un Système D'aide À La Décision

Transféré par

Droits d'auteur :

Formats disponibles

ROYAUME DU MAROC

Conception d’un Système d’Aide à la Décision

Les effectifs budgétaires du personnel de l’Etat

RAPPORT POUR L’AVANCEMENT AU GRADE

Au terme de ce travail, je tiens à exprimer ma Haute gratitude à Mr

Abdellatif BENNANI, le Directeur du Budget au sein du ministère des finances

Mes sincères et chaleureux remerciements s’adressent aussi à :

Mr Mohammed ERRAHALI, Chef de la Division des Systèmes d’Information

et directeur du projet décisionnel, pour ses directives pertinentes.

Mr Abdellali FATHI, Chef du Service Communication et Décisionnel pour

son implication à la réalisation de ce projet, et ses conseils pour la

L’équipe informatique du Service Communication et Décisionnel pour sa

participation à la réalisation du projet.

L’équipe d’assistance technique de ARCHOS – CONSEIL, pour leur soutient

technique tout au long de ce projet.

Messieurs les membres de jury, pour avoir bien accepté d’évaluer et de

Que toute personne ayant contribué de près ou de loin à l’élaboration de ce

travail, trouve ici l’expression de ma grande reconnaissance.

Liste des abréviations 4

Liste des figures 5

CHAPITRE I: Contexte du projet 8

CHAPITRE II: Etude du système existant 11

CHAPITRE III: Notions générales 16

CHAPITRE IV: Analyse et conception 25

CHAPITRE V: Réalisation de la plate forme décisionnelle 34

Conclusion & recommandations 48

Liste des abréviations

Liste des figures

Figure 1 : Le processus décisionnel 17

Figure 2 : Schéma de principe du datawarehouse 19

Figure 3 : La structure du datawarehouse (source EDS-Prométhéus) 20

Figure 4 : Le système d'alimentation 22

Figure 5 : Représentation de la modélisation et la présentation 24

Figure 6 : Exemple d’un modèle en étoile 27

Figure 7 : Exemple d’un modèle en Flocon 27

Figure 8 : Modèle en Flocon du DataMart "Effectif" 33

Figure 9: Lot DTS : Chargement des données de INGRES 37

Figure 10 : Lot DTS : Traitements des données de la Table de fait 39

Figure 11 : Framework Manager : Modèle des effectifs Budgétaires 40

Figure 12 : Transformer: Modèle des effectifs Budgétaires 41

Figure 13 : PowerPlay Entreprise Server : Administration des serveurs 42

Figure 14 : Cognos Access Manager : Connexion à UpFront 43

Figure 15 : Cognos UpFront : Gestion des rapports et des cubes 44

Figure 16 : Cognos PowerPlay Web 45

Figure 17 : Cognos PowerPlay Web : Exemple d’affichage graphique 46

La direction du Budget (DB) est chargée de la mise en oeuvre de la politique

Sa mission embrasse un vaste éventail d'attributions dont notamment la

Depuis 1987, la division du système d’information (DSI) de la DB assure

Le système d’information de la DB se décline des missions et attributions de

Le patrimoine informationnel budgétaire étant difficile à exploiter, la mise en

croissante exprimée par les partenaires, aussi bien internes qu'externes, et

Vu la diversité des métiers de la DB, on se limitera dans ce rapport à

Ce rapport présente les démarches et les principales étapes établies pour la

Ce rapport est composé de trois parties principales :

La première partie pointe sur la nécessité de mettre en place un système

La seconde partie étudie les différents choix techniques de la modélisation du

La troisième partie détaille les méthodes et les techniques de la réalisation du

Le présent document a pour objectif la mise en valeur du travail élaboré pour

II. Contexte du projet

Dans le cadre de l’exécution de ses attributions, la Direction du Budget est

II.1. Objectif du projet

L’objectif essentiel de ce travail est de développer un système décisionnel

Le développement et la publication des interfaces Web, pour une navigation