Conception Dun Systeme dAide a La Decision

5/11/2018 Conception Dun Systeme dAide a La Decision - slidepdf.com

http://slidepdf.com/reader/full/conception-dun-systeme-daide-a-la-decision 1/58

ROYAUME DU MAROC

-Mars 2006-

Les effectifs budgétaires du personnel de l’Etat

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

RAPPORT POUR L’AVANCEMENT AU GRADEPRINCIPAL DU CADRE D’INGENIEUR D’ETAT

Réalisé par

Badr TALAGHZIIngénieur d’Etat premier grade à la Direction du Budget



Système d’Aide à la Décision DB/DB2/DSI/SCD

1

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.




2

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 9II.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 16I. 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" 32III.4. Modèle physique de données 33




3

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




4

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




5

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




6

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 partenairesconstitué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




7

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.




8

CHAPITRE I

Contexte du projet




9

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.




10

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.




11

CHAPITRE II

Etude du système existant




12

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 publiquependant 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 pardé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.




13

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.




14

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.




15

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 del’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.




16

CHAPITRE III

Notions générales




17

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




18

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é enplusieurs 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.




19

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 toujoursretourner 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 pointunique 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.




20

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éesElles 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.




21

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.




22

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




23

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.




24

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

Effectif

Grade

Echelle

Département

Année LF

….

Portail décisionnel SIAD




25

CHAPITRE IVAnalyse et conception




26

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 à latable 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.




27

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

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

DIMENSION1

Clé1

Info

DIMENSION4

Clé4

Clé41

Clé42Info

DIMENSION42

Clé42

Info

DIMENSION41

Clé41

Info

T-FAITS

Clé1

Clé2

Clé3

Clé4

Mesure1

DIMENSION3

Clé3

Info

DIMENSION2

Clé2

Info

DIMENSION1

Clé1

Info

T-FAITSClé1

Clé2

Clé3

Clé4

Mesure1

DIMENSION3

Clé3

Info

DIMENSION4

Clé4

Clé41

Clé42

Info

DIMENSION2

Clé2

Info




28

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 besoinsont é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




29

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




30

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 descriptionAnlf_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’exercicebudgétaire

Efct_desp Colonne numérique indiquant l’effectif disponible à la fin de l’exercicebudgétaire

Efct_cree Colonne numérique indiquant l’effectif crée au cours de l’annéebudgétaire

Efct_supp Colonne numérique indiquant l’effectif supprimé au cours de l’annéebudgé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.




31

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çondont 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).




32

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 lasuivante :

Nom de

l’axeExercice Département TPB Echelle

Niveau Année Type budget Catégorie Classe d’échelles

Loi Département Corps Echelle Article CadreService TPB




33

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.

TF_Effectif

Dim_Anlf Dim_Catg

Dim_Corp

Dim_Cadr

Dim_Artl

Dim_Serv

Dim_dept

Dim_Typb

Dim_TPB

Dim_Echl

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_Cl_Echl

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




34

CHAPITRE V

Réalisation de la plate formedécisionnelle




35

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.




36

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 ensuitepublié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.




37

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(INGRES)

DESTINATION(MSQL SERVER 2000)

OBSERVATION

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 dimensionEchl Dim_Echl Table de dimension




38

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 TRAITEMENTAnlf_an Efct.Anlf_an Copie de colonne de la table Efct

Anlf_num Efct.Anlf_num Copie de colonne de la table EfctTypb_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 tableMvt (type de mouvement est ‘F’ ou ‘MF’)

Mvt_tf Mvt.mvt_eff Mise à jour de l’effectif Transféré/Transformé à partir dela 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




39

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.




40

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




41

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 lesdimensions 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




42

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




43

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.




44

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,




45

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.




46

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




47

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.




48

Conclusion & recommandations




49

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é.




50

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.




51

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/




52

Annexes




53

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 twheret.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 twheret.crea_typ <> 'S' and -- S = Suppression 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 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




54

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 twheret.crea_typ = 'S' and -- S = Suppression 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 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 twherec.[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')




55

--transformationupdate TF_Effectif set mvt_f = - c.mvt_eff from mvt c , TF_Effectif twherec.[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 ('F','MF')

-- transfert transformation

update TF_Effectif set mvt_tf = - c.mvt_eff from mvt c , TF_Effectif twherec.[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 ('TF','MTF')

-- destination-- changement du dep et tpbupdate TF_Effectif set mvt_tf = mvt_tf + c.mvt_eff from mvt c , TF_Effectif twherec.[typb_typ2]= t.typb_typ and c.[dept_cd2] = t.dept_cd and c.[artl_cd2] = t.artl_cd and

c.[serv_cd2] = t.serv_cd and c.[catg_cd2] = t.catg_cd and c.[corp_cd2] = t.corp_cd and c.[cadr_cd2] = t.cadr_cd and c.[tpb_cd2] = t.tpb_cd and c.[anlf_an]= t.anlf_an and c.[anlf_num]= t.anlf_num and c.mvt_typ in ('TF','MTF')

-- changement du departementupdate TF_Effectif set mvt_t = mvt_t + c.mvt_eff

from mvt c , TF_Effectif twherec.[typb_typ2]= t.typb_typ and




56

c.[dept_cd2] = t.dept_cd and c.[artl_cd2] = t.artl_cd and c.[serv_cd2] = 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')

---changement du tpbupdate TF_Effectif set mvt_f = mvt_f + c.mvt_eff from mvt c , TF_Effectif twherec.[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_cd2] = t.catg_cd and c.[corp_cd2] = t.corp_cd and c.[cadr_cd2] = t.cadr_cd and c.[tpb_cd2] = t.tpb_cd and c.[anlf_an]= t.anlf_an and c.[anlf_num]= t.anlf_num and c.mvt_typ in ('F','MF')




57

Annexe –B-

Exemple de fichier (iqd) du modèle « TF_Effectif »

COGNOS QUERYSTRUCTURE,1,1DATABASE,effectifTITLE,[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 SQLCOLUMN,0,anlf_anCOLUMN,1,anlf_numCOLUMN,2,typb_typCOLUMN,3,dept_cdCOLUMN,4,artl_cdCOLUMN,5,serv_cdCOLUMN,6,catg_cdCOLUMN,7,corp_cdCOLUMN,8,cadr_cdCOLUMN,9,tpb_cdCOLUMN,10,echelle_cdCOLUMN,11,efct_initCOLUMN,12,efct_dispCOLUMN,13,efct_cree

COLUMN,14,efct_suppCOLUMN,15,mvt_tCOLUMN,16,mvt_fCOLUMN,17,mvt_tf

Documents

Conception Dun Systeme dAide a La Decision