Rapport du Projet de Fin d’Année

Réalisé par :

 Ayoub MANAR
 Omar OUKILI Mise en place d’une base de données
décisionelle pour des actions
téléspectateurs

Encadré par :

 Mr ABOUABDELLAH
Année Universitaire : 2009 - 2010
 Remerciements

En préambule à ce mémoire, Nous souhaitons adresser ici nos

remerciements à toutes les personnes qui nous ont apporté leur soutien et
leur aide et qui ont ainsi contribué à l’élaboration de ce mémoire.

Nos remerciements les plus sincères sont adressés à notre encadrant Mr

ABOUABDELLAH pour le soutien, l’aide et le temps qu’il a bien voulu
nous consacrer et sans qui ce mémoire n’aurait jamais vu le jour.

Nos remerciements s’adressent également à nos professeurs, ainsi qu’à

tous ceux qui nous ont fait l’honneur de bien vouloir évaluer mon travail.

Nous exprimons notre gratitude à nos parents, et notre famille qui nous
ont toujours soutenue et encouragé tout au long de nos études.

Enfin, nous adressons nos plus sincères remerciements à tous nos amis
qui ont rendu ce travail possible par leurs conseils, remarques et
encouragements.

3
 Résumé

Dans le cadre des projets de fin d’années organisé par l’Ecole Marocaine des Sciences de
l’ingénieur, on nous a chargé de la conception et la réalisation de la partie décisionnelle du
module télévision de l’opérateur BreeFox qui est destinée aux manager de la société.

Durant toutes les séances d’encadrement et les heures de travail chez nous, on avait pour
mission dans une première étape d’étudier la Business Intelligence ou en français l’informatique
décisionnelle, qui est une solution qui permet d'utiliser les données transitant par le Système
d'information en informations susceptibles, d'être exploitées à des fins décisionnelles.

La deuxième étape consistait en l’analyse du cahier de charge et des indicateurs qui seront
utilisé pour générer un Schéma décisionnelle, et plus précisément les informations des Foyer, des
chaines, des actions et des émissions, qui constituent les axes principaux du module télévision de
l’opérateur BreeFox. Après cette analyse et conception du système, on a abouti à une base de
production.

La troisième étape consiste à la génération du cube, et à la fin la mise en place de la solution

retenue pour l’élaboration des tableaux de bord.

4
5
 A b s t ra c t

As part of year-end projects hosted by the School of Moroccan Engineering Sciences, we

were responsible for designing and implementing the party's decision-making module BreeFox
television operator that is intended to manager Society.

Throughout the coaching sessions and hours of work with us, it was charged in a first step to
study the French business intelligence or business intelligence, which is a solution which allows to
use the data passing through System information into information that, to be used for decision
making purposes.

The second phase involved the analysis of the specifications and indicators that will be used to
generate a decision diagram, specifically information from Foyer, chains, stocks and emissions,
which are the main components of the module Television BreeFox operator. Following this
analysis and system design, it has led to a production base.

The third step is to generate the cube, and eventually to the establishment of the solution for the
development of dashboards

6
 Liste des Figures

Figure 1 : Organisation d’un système décisionnel.............................................................................. 15

Figure 2 : Diagramme des uses cases ................................................................................................ 20

Figure 3 : Diagramme de classes ....................................................................................................... 22

Figure 4 : Cube................................................................................................................................. 24

Figure 5 : Exemple de rapport 1 ....................................................................................................... 25

Figure 6 : Exemple de rapport 2 ....................................................................................................... 26

Figure 7 : Exemple rapport 3............................................................................................................ 26

Figure 8 : Exemple de graphe 1 ........................................................................................................ 27

Figure 9 : Exemple de graphe 2 ........................................................................................................ 28

7
 Liste des Abréviations

BI Business Intelligence

ETL Extract Transform Loading

OLAP Online Analytical Processing

OLTP Online Transaction Processing

DM datamart

UML Unified Modeling Language

RG Règle de gestion

8
 Table des Matères

Remerciements ....................................................................................................................................... 3
Résumé .................................................................................................................................................... 4
Abstract ................................................................................................................................................... 6
Liste des Figures ...................................................................................................................................... 7
Liste des Abréviations ............................................................................................................................. 8
Table des Matières .................................................................................................................................. 9
Introduction Générale ........................................................................................................................... 11
Chapitre I Présentation générale........................................................................................................ 12
I. Contexte général du projet ............................................................................................... 12

II. Objectifs du projet ............................................................................................................. 12

Chapitre II Conception technique ....................................................................................................... 14

I. Système décisionnel .......................................................................................................... 14

II. ETL ..................................................................................................................................... 16

II.1. Définition d’un ETL .................................................................................................... 16

II.2. Les fonctionnalités d’un ETL ...................................................................................... 16

III. Entrepôt de données ......................................................................................................... 17

III.1. Analyse des types d’utilisation des entrepôts de données ....................................... 17

IV. Reporting ........................................................................................................................... 17

IV.1. Définition du Reporting ............................................................................................. 17

IV.2. Modes de restitution ................................................................................................. 17

V. Analyse des données : Cube OLAP .................................................................................... 18

VI. Solution adoptée ............................................................................................................... 18

Chapitre III Conception ....................................................................................................................... 19

I. Base de production............................................................................................................ 19

I.1. Base de production........................................................................................................ 19

I.2. Détermination des faits ................................................................................................. 22

9
 I.3. Modélisation de l’entrepôt :.......................................................................................... 23

Chapitre IV Réalisation ....................................................................................................................... 25

Conclusion Générale ............................................................................................................................. 29
Bibliographie / Webographie ................................................................................................................ 30

10
 Introduction Générale

L'informatique ne cesse de s'innover, rendant ainsi la prévision et le recueil du "feed back"

du "business" choses aisées. Actuellement, et grâce aux outils de la Business Intelligence [BI], on
peut facilement et automatiquement créer des processus adaptés à la structure traitée, qui
pourront en plus de faciliter la vie aux gérants, rendre la collecte des feed back et l'amélioration
des services une tâche systématique.

Dans notre cas, l’opérateur BreeFox cherche à améliorer le rendement de ses services et sa
position dans le marché. Le Reporting relatif à toutes ses activités s’avère nécessaire. En fait, les
outils d’aide à la décision proposés doivent répondre à trois critères : Le premier s’agit de
collecter, nettoyer et consolider les différentes données de l’entreprise ; quant au deuxième, il
assure le stockage de ses données et finalement le troisième exploite la richesse informationnelle
que les données recèlent. Cette exploitation passe par des analyses, permettant la prise des
décisions adéquates pour la correction et l’amélioration des situations.

L’objectif de notre projet fut donc de réaliser un Datawarehouse qui permettra d’avoir une
visibilité sur les données vitales et sur les indicateurs mis en point pour aider le manager de
BreeFox dans sa prise de décision.

Le présent rapport constitue une synthèse des travaux réalisés pour atteindre les objectifs
précités. Ses différents chapitres retracent les étapes de réalisation de notre projet. Il est organisé
en quatre chapitres :

Le premier porte sur une description générale du projet.

Le deuxième est consacré à la modélisation des spécifications fonctionnelles générales de

l’application.

Le troisième présente les outils techniques utilisés.

Et enfin le dernier chapitre décrit les détails de la solution développée.

11
 Chapitre I Présentation générale

I. Contexte général du projet

L'opérateur BreeFox propose à ses abonnés un boitier routeur ADSL qui groupe
un accès à IP, le téléphone et un bouquet de chaînes de télévision interactives. Nous ne
nous intéresserons qu'à cette dernière fonction dans notre entrepôt de données.

Les chaînes de télévision proposées par BreeFox dans son bouquet sont des
chaînes nationales et des chaînes à péage. Seulement, les interruptions publicitaires (des
chaînes nationales et à péage) peuvent être personnalisées en fonction du profil du foyer
(ou des adultes du foyer quand le contrôle parental est déverrouillé). Le téléspectateur
peut réagir (interactivement) de plusieurs manières aux émissions et aux publicités qu'il
reçoit au moyen de sa télécommande (ie Zapette):

• A tout moment, il peut zapper vers une autre chaîne

• A tout moment, il peut éteindre son poste

• Pendant une publicité, il peut zapper à la pub suivante sans attendre la fin de la
publicité en cours (la durée de visualisation est importante).

• Pendant une publicité, il peut demander plus d'information sur le produit présenté
(la durée de visualisation est importante) puis revenir à l'émission en cours.

II. Objectifs du projet

Le projet proposé s’inscrit dans la catégorie de ces nouveaux systèmes d’aide à la

décision.

12
 Il s’agit de créer un entrepôt de données centré sur les actions du téléspectateur.
L'objectif de cet entrepôt est de profiler au plus précis le foyer (ou plutôt le téléspectateur
qui détient la télécommande) afin de maximiser la demande d'information sur les produits
présentés par les publicités.

En effet, l'opérateur perçoit plus d'argent de la part de l'annonceur quand le

spectateur demande plus d'information au moment ou l'annonce est passée.

Le projet vise donc à réaliser :

- Une base de données qui permet d’arriver à cet entrepôt de données,

- Mettre en place le cube de cet entrepôt de données,
- Réaliser un tableau de bord sur les téléspectateurs selon différents indicateurs :
durée d’émission, nombre d’actions par date, nombre de chaines zappées … et qui permet
d’imprimer les différents états possible aidant le manager dans sa prise de décision.

13
 Chapitre II Conception
technique

I. Système décisionnel

Le décisionnel est un ensemble de solutions informatiques permettant l’analyse des

données de l’entreprise, afin d’en dégager les informations qualitatives, qu’elles soient
tactiques ou stratégiques nécessaires à la prise de décision.

Les bases de données de production et Datawarhouse ont des objectifs différents. Ils
stockent les données de manière différente et font l’objet de requêtes différentes. Ils sont
ainsi basés sur deus systèmes différents : OLTP et OLAP.

OLTP(On line Transaction Processing) est le modèle utilisé par les SGBD. Le mode
de travail est transactionnel. L’objectif est de pouvoir insérer, modifier et interroger
rapidement et en sécurité la base de données. Ces actions doivent pouvoir être effectuées
très rapidement par de nombreux utilisateurs simultanément. Chaque transaction travaille
sur de faibles quantités d’informations, et toujours sur les versions les plus récentes des
données.

Par contre les Datawarehouses reposent sur le système OLAP(On Line Analytical
Processing).Ce système travaille en lecture seulement. Les programmes consultent
d’importantes quantités de données pour procéder à des analyses des objectifs principaux
sont de regrouper, organiser des informations provenant de sources diverses, les intégrer
et les stocker pour donner à l’utilisateur une vue orientée métier, retrouver et analyser
l’information facilement et rapidement. Cela nécessite de consulter des versions
historiques de la base et peut se permettre d’ignorer temporairement les dernières mises à
jour. Ces bases sont souvent d’un ordre de grandeur nettement supérieur à celle des bases
OLTP, du fait de la conversation de l’historique.

14
 Il est important de séparer les bases de production du Datawarhouse. Pour des raisons
de performance. Premièrement car les systèmes de production ne sont pas prévus pour
répondre efficacement aux requêtes des systèmes d’aide à la décision. De plus les systèmes
de production ne conservent pas leurs données, alors qu’un Datawahouse repose sur des
données historiées. Aussi un Datawarhouse repose sur des systèmes de production
différents dont les données ne sont pas nécessairement uniformisées.

-Les démarches à suivre :

Pour élaborer un projet décisionnel il faut passer par les étapes suivantes représentées
dans la figure suivante :

Figure 1 : Organisation d’un système décisionnel

1. La collecte et le nettoyage des données via un ETL (Extract Transform Loading)

 C’est l’étape qui va permettre l’extraction des données des systèmes de production,
pour les préparer à l’alimentation des bases décisionnelles.

2. Le stockage des données dans le système décisionnel (Data Warehouse, Data Marts)

 Permet de conserver les données, sous forme relationnelle ou le plus souvent

multidimensionnelle, prêtes à être inclues dans des rapports.

15
 3.La restitution et l’analyse des données sous la forme de rapports et de tableaux de bord.

II. ETL
II.1. Définition d’un ETL

Tout Projet décisionnel ou d’intégration de donnée se base sur l’implémentation

des processus d’ETL qui consiste à extraire des données depuis des sources divers pour
ensuite effectuer des insertions ou des mises à jour vers des cibles.

II.2. Les fonctionnalités d’un ETL

Un processus d’ETL efficaces et fiables comprend de nombreux challenges:

 Les volumes de données sont en croissance exponentielle, et les processus d’ETL

doivent traiter des quantités importantes de données granulaires (produits vendus,
appels téléphoniques, transactions bancaires,…)
 Alors que les systèmes d’information se complexifient, la variété des sources de
données s’accroît également. Les processus d’ETL doivent disposer d’une large
palette de connecteurs à des progiciels (ERP, CRM, etc.), des bases de données
(Oracle, MySQL..), des mainframes, des fichiers (CSV, Excel…), des Services Web
etc.
 Les structures et applications décisionnelles incluent des entrepôts de données, des
applications OLAP pour l’analyse etc.

Toutes ces structures cibles présentent des besoins différents en termes de

transformation de données, ainsi que des latences différentes.

Les transformations des processus d’ETL peuvent être très complexes. Les
données doivent être agrégées, converties, calculées, traitées statistiquement, etc. Certaines
transformations spécifiques au décisionnel sont aussi requises, comme les Dimensions à
Evolution Lente

16
III. Entrepôt de données
III.1. Analyse des types d’utilisation des entrepôts de données

Nous avons généralement trois types d’utilisation d’entrepôt de données :

 L’entrepôt de données en temps réel qui est devenu populaire ces dernières années,
principalement à cause d’un désir croissant de disposer de l’information la plus
récente possible pour battre la concurrence.
 L’entrepôt de données traditionnel qui, comme son nom l’indique, est le type
d’utilisation auquel on pense le plus souvent quand on parle d’entrepôts de données.
Brassant de gros volumes de données, soumis à des taux de rafraîchissement peu
fréquents (qui ne sont pas définis en termes d’heures, et parfois ne sont même pas
quotidiens) et desservant un public important et varié.
 L’entrepôt de données historiques est relativement nouveau et est apparu à la suite
de lois assez récentes qui obligent de nombreuses entreprises à conserver de grandes
quantités d’informations à la disposition du gouvernement ou pour répondre à
d’autres contraintes de conformité.

Dans notre projet nous sommes amenez à concevoir un entrepôt de données

traditionnel avec des rafraichissements quotidiens (à partir de minuit) et nous sommes
amené à conserver ces données les trois derniers mois.

IV. Reporting
IV.1. Définition du Reporting

Le terme restituer ou bien « Reporting » représente le moyen technique, applicatif qui

permet la consommation d'information basée directement sur les outils de production ou
en aval d'une chaîne décisionnelle.

IV.2. Modes de restitution

Il est commun de distinguer trois modes de restitution :

Rapport statique : il s'agit d'un rapport dont la structure est figée tant en termes de
présentation que du périmètre des données présentées.

17
 Rapport dynamique : il s'agit d'un rapport ayant une structure de présentation semi
statique au sein duquel le périmètre des données peut varier. Cela en offrant à l'utilisateur
final la possibilité de choisir les valeurs de paramètres dynamiques intégrés dans le
rapport.

Rapport Ad hoc : il s'agit d'un rapport librement aménagé par l'utilisateur final. Il
aménage les données qui l'intéressent dans une structure type tableau ou graphique en
définissant le périmètre de consultation de ses axes et indicateurs.

V. Analyse des données : Cube OLAP

L’approche OLAP (On-Line Analytical Processing) qui désigne non seulement le
concept de la structure de modélisation des données, mais également la technologie
d’analyse de ces données.

Notre modèle dimensionnel permet l'analyse des mesures de la table de faits à partir
de plusieurs axes. Pour effectuer ces analyses on a opté a la création des cube OLAP qui
fournisse des réponses rapides à des requêtes interrogeant une grande quantité de
données et de permettre une interaction en temps réel avec ces données.

VI. Solution adoptée

Nous avons conçu à utiliser SQL Server 2008 et Visual Studio vu qu’ ils fournissent
un environnement unique regroupant plusieurs modules couvrant tous les besoins
d’analyses et d’aide à la décision depuis l’intégration des données à l’aide de son service
d’intégration et les outils ETL (Extraction, Transformation et Chargement de donnée)
qu’il utilise, suivi par le service d’analyse qui permet entre autre de représenter les
données de façon multidimensionnelle dans le but d’accélérer les requêtes lors de la
génération de rapport , jusqu’au le service de Reporting de SQL Server 2008 .

18
 Chapitre III Conception

I. Base de production

I.1. Base de production

Le but de la conceptualisation est de comprendre et structurer les besoins du
client, il ne faut pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins.
Une fois identifiés et structurés, ces besoins :

o définissent le contour du système à modéliser (ils précisent le but à atteindre),

o permettent d'identifier les fonctionnalités principales (critiques) du système.

Le modèle conceptuel doit permettre une meilleure compréhension du système, et

servir d'interface entre tous les acteurs du projet.

Les besoins des clients sont des éléments de traçabilité dans un processus intégrant UML

I.1.1. Modèle fonctionnel

il s'agit de la solution UML pour représenter le modèle conceptuel.
Les use cases permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d'un système. La figure 1 représente le modèle des use cases pour notre
system :

19
 Figure 2 : Diagramme des uses cases

I.1.2. Modèle de données

 Dictionnaire des données

N° Identificateur Description Format

1 adresse Adresse de l’annonceur string
2 catégorie Categorie de l emission String

3 dateNaissance Date de naissance du père du foyer Date

4 dateCréation La date de la creation de la chaine Date

5 duréeAct Durée de l’action Integer

6 duréeRestante Durée restante de la pub Integer

7 drapeauContParen Drapeau du contrôle parental Boolean

8 durée Durée de l émission Integer

9 dateDebutEmis Date du début de l’émission Date
10 email Email de l’annonceur String

20
 11 Montant Montant a payé pour une chaine Entier

12 numFoyer Numéro du foyer String

13 nomAbonné Le nom de l abonné String

14 numCha Numéro de la chaine String

15 nomCha Nom de la chaine String

16 numAction Numéro d’action String

17 numAnno Numéro d’annonceur String
18 nomAnno Nom d’annonceur String
19 numEmis Numéro d’émission String
20 numType Numéro du type de l’action String
21 nomAction Le nom de l’action String
22 Profession La profession de l abonné String
23 Telephone Tel de l abonné String
24 Ville Ville de l abonné String

 Règle de gestion
- RG1 : Les chaînes de télévision proposées par BreeFox dans son bouquet sont des
chaînes nationales et
- des chaînes à péage
- RG2 : Seulement, les interruptions publicitaires (des chaînes nationales et à péage)
peuvent être personnalisées en fonction du profil du foyer (ou des adultes du foyer quand
le contrôle parental est déverrouillé).
- RG3 : Le téléspectateur peut réagir (interactivement) de plusieurs
- manières aux émissions et aux publicités qu'il reçoit au moyen de sa télécommande
(ie Zapette)
- RG4 : Le téléspectateur peut à tout moment, zapper vers une autre chaîne
- RG5 : A tout moment, le téléspectateur peut éteindre son poste
- RG6 : Pendant une publicité, il peut zapper à la pub suivante sans attendre la fin de
la publicité en cours (la durée de visualisation est importante).
- RG7 : Pendant une publicité, il peut demander plus d'information sur le produit
présenté (la durée de visualisation est importante) puis revenir à l'émission en cours.

21
  Diagramme de classes :

Un diagramme de classes est un diagramme UML représentant un ensemble d'éléments

déclaratifs (statics) du modèle comme les classes, les types ainsi que leurs contenus et
relations. Ce dernier (figure 3) a été établit après une étude profonde de notre cahier de
charges :

Figure 3 : Diagramme de classes

I.2. Détermination des faits

La table de fait sur la quelle s’effectue toutes les mesures est << T_Action>>.

22
 Les dimensions

T_Emission, T_Chaine, T_publicité, T_Foyer, T_date, T_Annonceu et T_Typeaction.

Les indicateurs
- Durée d’émission par foyer/date
- Nombre de chaine par ville/date
- Nombre d’action par ville/date
- Nombre de chaine par foyer/date
- Nombre de demande d’info par date/foyer/chaine
- Nombre d’action par foyer
- Nombre de chaines zappées par foyer/date/ville
- Nombre de publicités zappées par foyer/date/ville
- Nombre d’action par foyer/ville

I.3. Modélisation de l’entrepôt :

Ce cube (Figure 4) présente les différentes informations à analyser qui sont stockées
dans la table de faits « T_Action ». Ces informations sont appelées des mesures :

Le nombre et le pourcentage des actions.

L’analyse est toujours faite selon un axe d’analyse :

Le foyer, les chaines zappés, les émissions, les villes, les types d’actions, les date
des émissions.

Toutes les dimensions sont directement reliées à la table de faits, qui contient les données
à analyser :

 La table de faits est reliée aux dimensions par des relations (1, n).

 Pour analyser une ligne de fait par Foyer par exemple, il faut qu'il y ait une relation
entre cette ligne et la dimension T_Foyer.

 Chaque ligne de la table de fait à une relation avec chacune des dimensions.

23
Figure 4 : Cube

24
 Chapitre IV Réalisation

Les états de sortie sont sous format de diagrammes, de graphes et de tableaux, le

présent chapitre fait l’objet de la description de quelques uns.

Figure 5 : Exemple de rapport 1

Cette fenêtre [figure 5] présente un rapport synthétique des durées totales des actions
effectuées, filtré par Foyer , qui est composé d’une hiérarchie : Nom abonné, Date de
naissance, Profession, Téléphone, Ville et le total calculé.

25
 Figure 6 : Exemple de rapport 2

La [figure 6] présente un rapport synthétique des durée totales des actions effectuées
filtré par ville et Foyer, composé d’une hiérarchie : Ville, Nom abonné, Date de naissance,
Profession, Téléphone et la durée total calculé.

Figure 7 : Exemple rapport 3

La figure ci-dessus [figure 7] représente un rapport des actions effectuées filtré par
Foyer, qui est composé d’une hiérarchie : Nom abonné, Date de naissance, Profession,

26
Téléphone, ville et le nombre d’actions calculées. En bas est mentionné le total de toutes
les actions.

Figure 8 : Exemple de graphe 1

Ce graphe nous retourne le nombre de demandes d’informations par année et par

chaine. Dans notre cas nous avons 12 demandes pour la RTM en 2005, 4 en 2006 et 2
seulement en 2007.

27
 Figure 9 : Exemple de graphe 2

Ci-avant, une présentation graphique, du total des durées d’actions filtrées par foyer.

28
 Conclusion Générale

A travers ce rapport, nous avons essayé de présenter les différentes étapes de

notre travail pour notre projet de fin d’année. Un projet qui consistait à établir un
module décisionnel destiné à la gestion des actions des téléspectateurs pour la
société BreeFox.

L’implémentation des différentes phases de la chaine décisionnelle constituant

l’architecture de l’application, facilitent la réalisation du projet.

Le projet fût une occasion d’or pour, aussi bien mettre en pratique nos

connaissances académiques, que d’en acquérir, et de développer de nouvelles

notions informatiques complémentaires à celles acquises au sein de l’Ecole
Marocaine des Sciences de l’Ingénieur. On a du donc approfondi nos
connaissances à analyser les problèmes et les besoins et à les reformuler afin de
pouvoir les modéliser

Au terme de ce travail, nous pouvons dire que ce projet facilitera la prise de

décision pour le garant de BreeFox, et permettra d’améliorer la qualité des services
de la société offerts à ses clients.

29
 Bibliographie / Webographie

Bibliographie

 [KIMBALL, 2001] Ralph KIMBALL, Concevoir et déployer un Data Warehouse,

EYROLLES, 2001

Webographie

 [SystemeETL.com] http://www.systemeetl.com/plan_projet.htm, Décisionnel

 [Developpez.com, 2000] Guillaume ROSSOLONI, 2000, 2009, Disponible sur
http://www.developpez.com, 20 Mai 2009
 [INMON] http://www.commentcamarche.com, datawarehouse et datamarts

30