I.

Business intelligence (BI)

Vision globale d’une entreprise :

Introduction
L’enjeu des années 2000 pour les entreprises :

• Augmentation de la réactivité.
• Augmentation de la concurrence.
• Diversité des produits.
• Ouverture des marchés, etc.

Quels outils donner au décideur pour comprendre, piloter et gérer ?

Contexte de la BI
Besoin: Améliorer les performances décisionnelles de l'entreprise :

• Décisions stratégiques

• Décisions rapides

Pourquoi: besoin de réactivité face à la concurrence.

Qui : les décideurs (non informaticiens)

Comment: en répondant aux demandes d’analyse.

Problématique
Problèmes à prendre en compte

– Une grande masse de données :

Distribuée

Hétérogène

Très Détaillée

– A traiter :

Synthétiser / Résumer

Visualiser

Analyser

– Pour une utilisation par :

des experts et des analystes d'un métier

NON informaticiens

Les entreprises passent à l’ère de l’information.

Défi : Transformer leur système d’information qui avait une vocation de production à un SI
décisionnel dont la vocation de pilotage devient majeure.

Applications
Banque, Assurance

– déterminer les profils client

– Risque d'un Prêt, Prime plus précise

Commerce

– ciblage de clientèle

– déterminer les promotions

– aménagement des rayons (2 produits en corrélation)

Économétrie

– prédiction de trafic autoroutier

Web
 – Restructuration des sites

Quelques métiers du décisionnel

Customer Relationship Management (gestion de la relation client) :

Améliorer la connaissance client, identifier et prévoir la rentabilité client, accroitre

l’efficacité du marketing client.

Supplier Relationship Management (gestion de la relation fournisseur):

Classifier et évaluer l’ensemble des fournisseurs. Planifier et piloter la stratégie Achat.

Human Capital Management (gestion de la relation avec les employés):

Aligner les stratégies RH, les processus et les technologies.

Systèmes transactionnels
Le transactionnel réfère à un mode d’exploitation de données tourné vers la saisie, le
stockage, la mise à jour, la sécurité et l’intégrité des données.

Par exemple, les systèmes de gestion des transactions boursières ou bancaires,

Le système transactionnel est généralement une base de données, développée par

application, stockant les données courantes d’une organisation, c’est-à-dire qu’il n’y
a pas de données d’archives dans les systèmes transactionnels » (Bédard et al. 1997)

Le système transactionnel réfère aux bases de données développées afin de gérer les
transactions quotidiennes

Ces bases de données supportent habituellement des applications particulières

telles que les inventaires de magasins, les réservations d’hôtel, etc.

Le contenu est fait de données actuelles, pas d’archives

Les données sont très détaillées (détails de chacune des transactions)

La mise à jour s’effectue par de nouvelles transactions

Très souvent plusieurs de ces systèmes existent indépendamment les uns des autres
dans les grandes organisations

Opérations dans les systèmes transactionnels

Ajout

Effacement

Mise à jour des enregistrements

Requêtes simples
Obstacles à l’analyse dans les systèmes transactionnels
Les bases de données transactionnelles sont habituellement normalisées de telle
sorte que la duplication des données est minimum :

– Assure l’intégrité des données

– Simplifie la mise à jour des données

Cependant, une très forte normalisation complexifie l’analyse des données:

– Nombre élevé de tables donc nombre élevé de jointures nécessaires entre les
tables (performance pauvre)

– Temps de traitement long

– Élaboration complexe des requêtes

Difficulté d’optimiser le fonctionnement des systèmes transactionnels.

De plus, les types d’analyses servant aux processus de décision des organisations
nécessitent:

– Données sommaires (agrégées ou résumées) sur l’ensemble de l’organisation

(provenant des différentes BD dispersées de l’organisation et intégrées)

– Données historiques

– Réponses rapides (requêtes surtout de type agrégatif), interfaces à l’usager

faciles à utiliser
Système de production vers système décisionnelle

Entrepôts de données
Origine de deux besoins distincts mais complémentaires :

Besoin pour une entreprise d’avoir un panorama complet de son

information

Besoin pour un département de mieux gérer les données de

l’entreprise

D’après BILL Inmon :

“Un DataWarhouse (DW) est une collection de données thématiques, intégrées, non
volatiles et historisées, organisées pour la prise de décision.”

Caractéristiques :

orientation sujets («métiers»): à la différence des organisations traditionnelles

organisées par processus fonctionnel

données intégrées: divers sources de données ;

données non volatiles: ne pas supprimer les données du DW;

données datées: trace des données

Le business intelligence :
regroupe l’ensemble des moyens pour répondre aux besoins utilisateurs, de mise à
disposition et d’analyse des données relatives à leurs activités.
Fonctions essentielles de l’Informatique Décisionnelle

Datamart
Sous-ensemble d’un entrepôt de données

Destiné à répondre aux besoins d’un secteur ou d’une fonction particulière de

l’entreprise

DW de l’entreprise

Intérêt des datamart

Nouvel environnement structuré et formaté en fonction des besoins d’un métier ou
d’un usage particulier

Moins de données que DW

– Plus facile à comprendre, à manipuler

– Amélioration des temps de réponse

 Utilisateurs plus ciblés: DM plus facile à définir

Les flux de données

Flux entrant

– Extraction: multi-source, hétérogène

– Transformation: filtrer, trier, homogénéiser, nettoyer

– Chargement: insertion des données dans l’entrepôt

Flux sortant:

– Mise à disposition des données pour les utilisateurs finaux

Les différentes zones de l’architecture

Zone de préparation (Staging area)

– Zone temporaire de stockage des données extraites

– Réalisation des transformations avant l’insertion dans le DW:

Nettoyage

Normalisation…

– Données souvent détruites après chargement dans le DW

Zone de stockage (DW, DM)

– On y transfère les données nettoyées

– Stockage permanent des données

Zone de présentation

– Donne accès aux données contenues dans le DW

– Peut contenir des outils d’analyse programmés:

Rapports

Requêtes…
Cycle de vie décisionnel

La planification

La planification aborde la définition et l'étendue du projet de l'entrepôt, y compris

l'appréciation du niveau de maturité de l'organisation face à ce type d'approche.

Elle se concentre sur les besoins en termes de ressources et de niveau de qualification,

couplés aux affectations des tâches, à leurs durées et à leur séquence.

La planification dépend bien évidemment des besoins.

Définition des besoins

Il est essentiel de bien comprendre les utilisateurs et leurs besoins, sinon l'entrepôt
deviendra rapidement un exercice vain de la part de l'équipe des concepteurs.

Les besoins une fois définis constituent le point de départ de trois trajectoires parallèles que
sont la technologie, les données et les interfaces utilisateurs.

Etude du domaine métier :

Cette étape est fondamentale. En effet il n'y a pas de secret. Si vous voulez travailler dans le
décisionnel vous êtes obligé de connaître le métier de l'entreprise pour laquelle vous
travaillez. Alors si vous êtes nouveaux, familiarisez-vous avec les termes utilisés, regardez sur
l'intranet de l'entreprise ou sur leur site. Il y'a beaucoup d'informations cachées là dedans. Et
une astuce qui m'a beaucoup aidé c'est de se familiariser avec les différents
logiciels/progiciels utilisés dans l'entreprise. Ne les utilisez pas en environnement de
production mais créez plutôt votre propre environnement de test sur lequel vous êtes libre
pour vos tests. Je peux vous assurer que cela est très utile ! Vous pouvez aussi utiliser le bon
vieux SQL pour faire de petites requêtes afin de se faire une idée des données disponibles
dans le référentiel métier.

Interview des acteurs clés du métier

Un autre élément tout aussi important que l'étude de l'environnement est la connaissance
et l'interview des acteurs métiers. Bien évidemment il faudra tout d'abord bien connaître
l'organigramme de l'entreprise et savoir qui s'occupe de quoi. Et si on ne connaît pas bien
l'organigramme on pourrait prévoir les bonnes questions à poser aux bonnes personnes.

Après interview, il est toujours bien de faire un compte rendu de réunion. A partir des
comptes rendus de réunion il faudra d'abord classer les besoins en thèmes ou sujets
d'analyse.

Chaque département ou secteur de l'entreprise a ses propres besoins et ces besoins peuvent
faire appel au même processus. Par exemple, les marketeurs (département marketing)
peuvent avoir besoin d'analyser l'intéressement des jeunes à une catégorie de produits. De
même, les commerciaux (département vente) peuvent avoir besoin de connaître le chiffre
d'affaire de la région Ile-de-France en termes d'achat de portables par exemple. Ces deux
catégories de besoins utilisent tous les deux le processus " commande ". On risque de
répéter le même processus si l'on tient compte de la demande de chacun des deux
départements séparément.

Cycle de vie décisionnel : Modèle dimensionnel

C'est la définition des besoins qui détermine quelles sont les données requises pour
répondre aux besoins d'analyse des utilisateurs.

Le résultat de cette analyse est le modèle dimensionnel.

Structure physique

Définition des structures physiques nécessaires pour l'implémentation physique du modèle

dimensionnel.

o Détermination des règles de nommage des objets

o Environnement de la base de données.
o Indexation primaire
o La conception du modèle physique est fortement dépendante du système utilisé
pour l'entrepôt.

Préparation des données

La conception de la zone de préparation des données (staging area) constitue

généralement la tache la plus sous-estimée du projet entrepôt de données.

Le processus de préparation se déroule en trois phases majeures :

 o Extraction
o Transformation
o Chargement

Architecture technique

La définition de l'architecture technique globale à mettre en œuvre nécessite la prise

en compte :

o des besoins

o de l'environnement existant

Composants

A partir de l'étude de l'architecture technique il faut sélectionner les composants

spécifiques

o Plate-forme(s) matérielle(s) et logicielle(s)

o SGBD

o Outils d'extraction

o Outils de restitution

Une fois les produits évalués et sélectionnés, ceux-ci doivent être installés et testés
afin de garantir une intégration adéquate d'un bout à l'autre de l'environnement de
l'entrepôt.

Applications utilisateurs

Définition d’une série d’application standard destinée aux utilisateurs finaux.

Les spécifications de l'application décrivent les maquettes d'états, les critères de

sélection laissés à l'utilisateur et les calculs nécessaires.

Déploiement

Le déploiement est le point de convergence de :

o La technologie

o Des données

o Des applications utilisateurs.

Une planification est indispensable pour gérer le déploiement qui comprend

également

o la formation des utilisateurs,

 o le support utilisateur,

o la prise en compte des demandes d'évolution et de correction.

II. La Modélisation
Cycle de vie décisionnel

L’analyse
Le but du jeu est de déceler les axes d'analyses (les dimensions) avec leurs attributs
ainsi que les éléments à analyser (les faits).

L'étude approfondie de ce qui se passe dans l'entreprise :

Documents échangés, rapports périodiques, interviews des personnes clés, étude

des besoins.

Il faut vraiment faire un travail d'acteur, et rentrer dans la peau de chaque

utilisateur :

Savoir comment les analystes organisent leurs raisonnements, savoir ce que voient
les décideurs avant de décider, connaître les indicateurs de bonne santé de
l'entreprise et de la concurrence.

Une manière très pratique de modéliser un cas en BI se fait comme suit (table
décisionnelle) :
Modélisation Entité/Association
Avantages:

– Normalisation:

Éliminer les redondances

Préserver la cohérence des données

– Optimisation des transactions

– Réduction de l’espace de stockage

Inconvénients pour un utilisateur final:

– Schéma très/trop complet:

Contient des tables/champs inutiles pour l’analyse

– Pas d’interface graphique capable de rendre utilisable le modèle E/A

– Inadapté pour l’analyse

Modélisation des DW
Nouvelle méthode de conception autour des concepts métiers

– Ne pas normaliser au maximum

Introduction de nouveaux types de table:

– Table de faits
 – Table de dimensions

Introduction de nouveaux modèles:

– Modèle en étoile

– Modèle en flocon

Faits (définition)
Fait:

– Un fait est la plus petite information analysable.

– C'est une information qui contient les données observables (les faits) que l'on
possède sur un sujet et que l'on veut étudier, selon divers axes d'analyse(les
dimensions).

Fait:

– Ce que l’on souhaite mesurer

Quantités vendues, montant des ventes…

– Trois types de faits:

Additif

Semi additif

Non additif

Additif: additionnable suivant toutes les dimensions

– Quantités vendues, chiffre d’affaire

– Peut être le résultat d’un calcul:

Bénéfice = montant vente - coût

Semi additif: additionnable suivant certaines dimensions

– Solde d’un compte bancaire:

Pas de sens d’additionner sur les dates

Σ sur les comptes: on connaît ce que nous possédons en banque

Non additif: fait non additionnable quelque soit la dimension

– Prix unitaire: l’addition sur n’importe quelle dimension donne un nombre

dépourvu de sens
Structure de base d'une ''table‘’ de fait
Table principale du modèle dimensionnel

Contient les données observables (les faits) sur le sujet étudié selon divers axes
d’analyse (les dimensions)

Caractéristiques d'une ''table‘’ des faits

Une table de faits contient les valeurs numériques de ce qu'on désire mesurer.

Une table de faits contient les clés associées aux dimensions. Il s'agit des clés
étrangères vers les dimensions.

En général une table de faits contient un petit nombre de colonnes

Une table de faits contient plus d'enregistrements qu'une table de dimension

Les informations dans une ''table'‘ de faits sont caractérisées:

Elles sont numériques et sont utilisées pour faire des SUM, AVG...

Les données doivent être additives ou semi additives

Les mesures (Mes1, Mes2,…Mesn) doivent référer et avoir un lien direct avec les clés des
dimensions (Date Cal, Id Dim1, Id Dim2, ..., Id DIM) dans la même table.

Granularité de la table de faits

Répondre à la question :

– Que représente un enregistrement de la table de faits?

La granularité définit le niveau de détails de la table de faits:

– Exemple: une ligne de commande par produit, par client et par jour
Dimension: définition
Une dimension est une ''table'‘ qui représente un axe d'analyse selon lequel on veut
étudier les données observables(les faits) qui, donnent aux utilisateurs des
renseignements nécessaires à la Prise de décision.

On appelle donc ''dimension'' un axe d'analyse. Il peut s'agir des Clients ou des
Produits d'une entreprise, d'une Période de temps.

Table de dimension
Axe d’analyse selon lequel vont être étudiées les données observables (faits)

Contient le détail sur les faits

Dimension = axe d’analyse

– Client, produit, période de temps…

Contient souvent un grand nombre de colonnes

– L’ensemble des informations descriptives des faits

Contient en général beaucoup moins d’enregistrements qu’une table de faits

Dimension-composantes
Composante 1 : surrogate key ou clé de substitution

Exemple:

Une clé de substitution (Surrogate key) est une clé non significative utilisée afin de
substituer la clé naturelle (Business Key) qui provient des systèmes opérationnels.

Dans un système opérationnel, on utilise une clé artificielle afin d'identifier d'une
façon unique un élément de l'entité : (client_id pour l'entité client, emp_id pour
l'entité Employé).

La clé de substitution ne doit pas être confondue avec la clé artificielle attribuée par
les systèmes opérationnels.

La clé de substitution est alors utilisée dans un entrepôt de données pour remplacer
et compléter la clé artificielle du système opérationnel.

Les Fonctionnalités

Remplacer la clé artificielle ou naturelle : Effectivement une clé de substitution

remplace la clé artificielle en terme d'utilisation, ce n'est plus la clé naturelle qui sera
utilisée pour faire les jointures avec les tables de faits et les autres tables de
dimension.

Compléter l'information : La clé de substitution n'a aucun sens en terme d'affaire,

elle est utilisée dans l'ED seulement, La clé artificielle ou naturelle dans la dimension
est toujours nécessaire pour pouvoir faire la correspondance entre l'élément de
dimension (un client par exemple) dans l'ED et l'élément de la table (des clients) dans
le système opérationnel.

Les avantages
 Performance : Accélère l'accès aux données du moment où l'on va utiliser un index
numérique vu que le type de données de la clé de substitution est numérique.

Indépendance du système source : On ne peut garantir que la clé d'affaire ne change

pas dans les systèmes sources.

Historique des changements et granularité infinie : Si l'on désire garder l'historique

des changements de la dimension selon certains critères, on doit gérer la clé de
substitution. On se retrouve facilement avec plusieurs enregistrements de la même
clé d'affaire dans la dimension.

Dimension: Composante 2 : attributs

En plus de la clé de substitution ou de la clé naturelle, d'autres attributs sont ajoutés

à la dimension. Ces attributs sont descriptifs et représente l'information utile sur la
dimension (Le salaire d'un employé, l'adresse d'un client...)

Dimension: Composante 3: clés specials

Date effective : Date à la quelle l'enregistrement à été créé, de préférence dans le

système d'enregistrements (System of records).

Date retrait : Date à laquelle l'enregistrement a été retiré du système

d'enregistrements.

Indicateur effectif : En général est 'O' si l'enregistrement est toujours actif (Date
retrait est nulle), 'N' sinon.

La dimension Temps
Commune à l’ensemble du DW

Reliée à toute table de faits

 Dimension Temps

Clé temps (CP)

Jour

Mois

Trimestre

Semestre
Année

Num_jour_dans_année

Num_semaine_ds_année

Granularité d’une dimension

Une dimension contient des membres organisés en hiérarchie :

– Chacun des membres appartient à un niveau hiérarchique (ou niveau de

granularité) particulier

– Granularité d’une dimension : nombre de niveaux hiérarchiques

– Temps :

Année – semestre – trimestre – mois

Évolution des dimensions

Dimensions à évolution lente (SCD: Slowly Changing Dimension)

– Un client peut se marier, avoir des enfants…

– Un produit peut changer de noms ou de formulation:

« Raider » en « Twix »

« yagourt à la vanille » en « yagourt saveur vanille »

– Gestion de la situation, 3 solutions:

Écrasement de l’ancienne valeur

Versionnement (Ajout d’un nouvel enregistrement)

Valeur d’origine / valeur courante

Écrasement de l’ancienne valeur :

 – Correction des informations erronées

Avantage:

– Facile à mettre en œuvre

Inconvénients:

– Perte de la trace des valeurs antérieures des attributs

– Perte de la cause de l’évolution dans les faits mesurés

Ajout d’un nouvel enregistrement:

– Utilisation d’une clé de substitution

Avantages:

– Permet de suivre l’évolution des attributs

– Permet de segmenter la table de faits en fonction de l’historique

Inconvénient:

– Accroit le volume de la table

Ajout d’un nouvel attribut:

– Valeur origine/valeur courante

Avantages:

– Avoir deux visions simultanées des données :

Voir les données récentes avec l’ancien attribut

Voir les données anciennes avec le nouvel attribut

– Voir les données comme si le changement n’avait pas eu lieu

Inconvénient:

– Inadapté pour suivre plusieurs valeurs d’attributs intermédiaires

Dimensions à évolution rapide

– Subit des changements très fréquents (par ex tous les mois) des attributs dont
on veut garder l’historique.

– Solution:

Isoler les attributs qui changent rapidement

Exemple :
 Si l'on veut préserver l'historique des changements d'adresse dans la dimension
«Clients» dans un pays où 70% de la population déménage une fois par année (le 1er
juillet par exemple au Canada).

La dimension «Clients» devient dans ce cas une dimension à évolution rapide (RCD:
Rapid Changing Dimension)

Modélisation d’un DW
Modèle en étoile

Le schéma en étoile tire son nom de sa configuration

o Une table de fait centrale et des dimensions

o Les dimensions n’ont pas de liaison entre elles

o Avantages:

Facilité de navigation

Nombre de jointures limité

o Inconvénients:

Redondance dans les dimensions

Toutes les dimensions ne concernent pas les mesures

Alimentation complexe.

Modèle en flocon
Une table de fait et des dimensions décomposées en sous hiérarchies.

On a un seul niveau hiérarchique dans une table de dimension.

La table de dimension de niveau hiérarchique le plus bas est reliée à la table de fait. On dit
qu’elle a la granularité la plus fine.

Modèle floconné = Modèle en étoile + normalisation des dimensions

o Avantages:

Normalisation des dimensions

Économie d’espace disque

o Inconvénients:

Modèle plus complexe (jointure)

Requêtes moins performantes

Modèle mixte

Il s’agit d’une structure qui résulte de la meilleure combinaison des deux types de
modèles précédents.

Seules quelques dimensions seront normalisées, souvent il s’agit des plus grandes
tables et celles contenant le plus de redondance.
Modèle en constellation

La modélisation en constellation consiste à fusionner plusieurs modèles en étoile qui

peuvent utiliser des dimensions communes.

Un modèle en constellation comprend donc plusieurs tables de faits et des tables de

dimensions communes ou non à ces tables de faits.

Modélisation multidimensionnelle
Exemples :

– Grandes distribution :

CA annuel : 80 000 M

Prix moyen d’un article d’un ticket : 5

Nombre d’articles vendus pour un an : 80 * 109 / 5 = 16 * 109

Volume du DW :

16*109 *3 ans * 24 octets = 1,54 To (1,54*1024 = 1 540 Go)

– Téléphonie :

Nombre d’appels quotidiens : 100 millions

Historique : 3 ans * 365 jours= 1 095 jours

Volume du DW :
 – 100 millions * 1 095 jours * 24 octets = 3,94 To

– Cartes de crédit :

Nombre de clients : 50 millions

Nombre moyen mensuel de transactions : 30

Volume :

– 50 millions * 26 mois * 30 transactions * 24 octets = 1,73 To

III. L'analyse en ligne: OLAP

OLAP

• Un cube OLAP est une structure de données supérieure aux bases de données
relationnelles grâce à une analyse rapide des données.
• Les cubes peuvent afficher et additionner de grandes quantités de données.
• OLAP est un type d'application informatique orienté vers l'analyse sur-le-champ
d'informations selon plusieurs axes.
• Cette structure est prévue à des fins d'analyses interactives par une ou plusieurs
personnes (souvent ni informaticiens ni statisticiens) du métier que ces données sont
censées représenter.
 ⇒ « Il s’agit d’une catégorie de logiciels axés sur l’exploration et l’analyse rapide des
données selon une approche multidimensionnelle à plusieurs niveaux d’agrégation »
(Caron, 1998)

Objectifs attendus
Catégorie de logiciels : S’exprime par une grande quantité de produits logiciels disponibles
sur le marché ;

Exploration et analyse rapide : OLAP vise à assister l’usager dans son analyse en lui facilitant
l’exploration de ses données et en lui donnant la possibilité de le faire rapidement ;

Facilité : L’usager n’a pas à maîtriser des langages d’interrogation et des interfaces
complexes, et il interroge directement les données, en interagissant avec celles-ci

Rapidité :

• OLAP exploite une pré-agrégation des données;

• L’usager devient opérationnel en très peu de temps
⇒ L’usager peut se concentrer sur son analyse et non sur le processus (les moyens
utilisés pour l’analyse)

Approche multidimensionnelle: Visualisation multidimensionnelle des données.

Plusieurs niveaux d’agrégation : Les données peuvent être groupées à différents niveaux de
granularité (niveau de détail des données emmagasinées dans une base de données).

⇒ les regroupements sont pré-calculés, par exemple, le total des ventes pour le mois
dernier calculé à partir de la somme de toutes les ventes du mois.

Les règles
Edgar .Frank. Codd définit 12 règles de base permettant de qualifier le concept global
nommé OLAP :

1. Une vue multidimensionnelle des données.

2. La transparence vis à vis de l'utilisateur qui doit accéder à la BD par l'intermédiaire
d'outils simples (tableur, par ex).
3. La BD doit disposer d'un modèle et d'outils permettant d'accéder à de multiples
sources, d'effectuer les conversions et extractions nécessaire pour alimenter la Base
OLAP.
4. Le modèle de données, le nombre de dimensions ou le nombre de niveaux
d'agrégation doivent pouvoir changer, sans remettre en cause le fonctionnement de
la base.
5. Architecture Client/serveur.
6. Toutes les dimensions définies dans le modèle de données doivent être accessibles
pour chacune des données.
7. Gestion des matrices creuses. Les parties vides du cube multidimensionnel doivent
être stockées de manière à ne pas détériorer les temps d'accès.
 8. Accessibilité simultanément par plusieurs utilisateurs.
9. Toutes les données stockées ou calculées dans le cube doivent être accessibles.
Toutes les tranches de cube doivent être visualisées.
10. Manipulation aisée dans les données pour les utilisateurs.
11. Outil de présentation des données (Simplicité des rapports).
12. Nombre illimité de dimensions et de niveaux d'agrégation (nombre illimité
d'éléments sur les dimensions).

Vocabulaire OLAP
Dimension :

Une dimension peut être définie comme un axe d’analyse selon lequel les données seront
analysées

- Exemple : Temps, Découpage administratif, Produits.

Une dimension contient des membres organisés en hiérarchie, chacun des membres
appartenant à un niveau hiérarchique (ou niveau de granularité) particulier

- Ex. Pour la dimension Temps, les années, les mois et les jours peuvent être des
exemples de niveaux hiérarchiques. 1998 est un exemple de membre du niveau
Année.

Fait/Mesure :

Une mesure est un élément de donnée sur lequel portent les analyses, en fonction des
différentes dimensions

- Exemple : coût des travaux, nombre d’accidents, ventes, dépenses.

Un fait représente la valeur d’une mesure

Cube :

Un ensemble de mesures organisées selon un ensemble de dimensions (aussi hyper cube)

- Ex. Un cube de ventes qui comprend :

Les dimensions Temps, Produit, Magasin;
La mesure Ventes en Dh.

Les cubes OLAP ont les caractéristiques suivantes :

• obtenir des informations déjà agrégées selon les besoins de l’utilisateur ;

• simplicité et rapidité d’accès ;
• capacité à manipuler les données agrégées selon différentes dimensions ;
• un cube utilise les fonctions classiques d’agrégation : min, max, count, sum, avg.

Exemple de cube OLAP

Dans notre exemple, nous allons nous intéresser aux ventes de tous les magasins "XXX".

Voyons maintenant comment peut-on utiliser ce cube. Pour cela, nous allons nous intéresser
aux différentes vues de ce cube.

Vue n° 1 : On s'intéresse à toutes les ventes du magasin d'ANNECY (toutes catégories

confondues durant toute les mois).

Vue n° 2 : On s'intéresse aux ventes de la catégorie "vêtements pour enfants" (tous les
magasins durant toute les mois)

Vue n° 3 : On s'intéresse à toutes les ventes durant le mois de Février (toutes catégories
confondues et dans tous les magasins)
Vue n° 4 : On s'intéresse aux ventes du magasin d'ANNECY dans la catégorie "vêtements
pour enfants" durant le mois de Février)

Opérateurs OLAP
• Opérateurs liés à la structure
• Opérateurs liés à la granularité
• Opérateurs ensemblistes

Multi-représentations du cube vente

Les différentes opérations d’agrégation
Roll up ou drill up

Roll up / Forage vers le haut / Agrégation de données : Passage de mesures détaillées à

résumées en remontant dans la hiérarchie de la dimension. (Exemple : visualiser les ventes
par année au lieu de par mois).

Roll up sur la dimension ‘’Produits’’

Roll up sur les dimensions ‘’Produits’’ et ''Dates''

Roll up sur les 3 dimensions ''Produits'',''Dates'' et ''Villes''

Drill down :

Drill down: forage de données vers le bas

Drill down sur la mesure ‘CA’ selon la dimension ‘’ville ‘’

Résultat du drill down :

Drill down sur la mesure ‘CA’ selon la valeur ''Lyon'‘ de la dimension ‘’ville ‘’

Le résultat du Drill down donne:

Rotate :
Pivoter (pivot, swap) : Rotation des axes du cube pour fournir une vue alternative des
données (Exemple: interchanger 2 dimensions).

Les composantes OLAP

L’architecture OLAP consiste en trois services :

Base de données :

• Doit supporter les données agrégées ou résumées

• Les données qu’il contient peuvent provenir d’un entrepôt ou d’un marché de
données
• Doit posséder une structure multidimensionnelle c’est-a-dire basée sur
• un SGDB multidimensionnel ou relationnel)

Serveur OLAP :

• Gère la structure multidimensionnelle dans le SGBD

• Gère l’accès aux données de la part des usagers

Module client :

• Permet aux usagers de manipuler et d’explorer les données

• Affiche les données sous forme de graphiques statistiques et de tableaux

Selon le type de base de données accédé, plusieurs configurations sont possibles :

multidimensionnelles, relationnelle ou hybride :

1. MOLAP (OLAP multidimensionnel)

Les données détaillées de base ainsi que les données agrégées de l’entrepôt sont
stockées dans une base de données multidimensionnelle (souvent appelée cube
ou hypercube)
Une base de données multidimensionnelle utilise une structure propriétaire au
logiciel utilisé (≈ matrice)
Le serveur MOLAP extrait les données de l’hypercube et les présente directement
au module client
 2. ROLAP (OLAP Relationnel)
Les données détaillées de base ainsi que les données agrégées de l’entrepôt sont
stockées sous forme de tables dans une base de données relationnelle
La base de données relationnelle doit être structurée selon un modèle particulier
(étoile, flocon, …)
Le serveur extrait les données par des requêtes SQL et interprète les données selon
une vue multidimensionnelle avant de les présenter au module client

Serveur ROLAP
Client OLAP
Base de données
relationnelle
(étoile ou flocon) Vue
multidimensionnelle

3. HOLAP (OLAP Hybride)

Architecture qui consiste en un croisement des architectures MOLAP et ROLAP;

Les données détaillées de base de l’entrepôt sont stockées dans une base de
données relationnelle et les données agrégées sont stockées dans une base de
données multidimensionnelle;

Le serveur HOLAP accède à les deux bases de données et les présente au module
client, selon une vue multidimensionnelle dans le cas des données de la BD
relationnelle ;

4. MOLAP vs ROLAP vs HOLAP

Critère de ROLAP MOLAP HOLAP
comparaison

Stockage des données BD relationnelle BD BD relationnelle

de base (détaillées) multidimensionnelle

Stockage des BD relationnelle BD BD

agrégations multidimensionnelle multidimensionnelle
Performance des Le moins performant Le plus performant Performance moyenne
requêtes
(habituellement)

Structure multidimensionnelle
OLTP vs OLAP

Les Outils
Un marché fragmenté :

– Constitution du DataWarehouse

– Stockage

– Extraction d’Information
 – Outils Métier

Quelques systèmes
• Intelligent miner d’IBM (couplé avec le SGBD DB2) : Classification, association,
régression, analyse de séquences, regroupement
• Entreprise miner de SAS : Multiples outils d’analyse statistique, classification, …
• Mine set de Silicon graphics. : Classification, association et divers outils statistiques.
Très puissant en termes de visualisation
• Clémentine de SPSS : En plus des fonctionnalités classiques, l’utilisateur peut y
rajouter ses propres algorithmes
• DBMiner de DBMiner technologie. : Il se distingue par le fait qu’il incorpore les
fonctionnalités d’OLAP

IV. Charger le DW : ETL

Le processus ETL
Le plan ETL est comme suit :

• Phase d'ETL ;
Extraction de données ;
Transformation de données ;
Alimentation d'un ED ;
• ETL sous SQL server.
Après avoir conçu le modèle des données, comment alimenter l'ED ?

Processus d'ETL
(Extracting – Transforming – Loading)
Il est important de savoir que la réalisation de l'ETL constitue 70% d'un projet décisionnel en
moyenne. Et ce n'est pas pour rien, ce système est complexe et ne doit rien laisser
s'échapper.

Avoir une Des données

mauvaise fausses, Décisions
information donc erronées.
dans l'entrepôt inutilisables

Définition d’un ETL

• Offre un environnement de développement
• Offre des outils de gestion des opérations et de maintenance
• Permet de découvrir, analyser et extraire les données à partir de sources
hétérogènes
• Permet de nettoyer et standardiser les données
• Permet de charger les données dans un entrepôt
• Pour alimenter le DataWareHouse, on utilise un ETL (Extract, Transform and Load),
outil basé sur le principe de métabases.
• Décrit les données, leur provenance et les transformations effectuées.
• Permet d’agréger, classifier, normaliser et nettoyer les données extraites.
• Les concepteurs doivent mettre en place une stratégie de mise à jour pour
l’historisation et prévoir la volumétrie.
• L’alimentation peut être en batch ou file de l’eau. Les ETL peuvent être intégrés aux
outils de modélisations ou de restitution.
• Les ETL peuvent se concevoir de 2 manières :
manuellement : en lançant des scripts (PL/SQL, …)
avec des logiciels (qui sont chers)
• Permet d’analyser, décrire, expliquer et exposer
Etapes à suivre
1. Identifier les sources
Où ? Fichiers, SGBDR, ERP, Internet, …
Comment ? Réseau local, MAN, WAN, transferts des fichiers.
Quand ?
2. Construire le référentiel
3. Définir la fréquence des chargements
4. Décrire le niveau d’historisation
5. Expliquer la volumétrie
6. Analyser la qualité des données
7. Exposer la complexité des transformations
8. Considérer la reprise des données
9. Gérer les rejets
10. Mettre en place les sauvegardes/restaurations

Problèmes rencontrés
• Souvent peu d’entreprises ont des logiciels qui permettent la création d’ETL, car ce
sont des outils coûteux. Il faut souvent réaliser l’alimentation à la main.
• La fréquence de mise à jour du DataWareHouse (quotidiennement,
hebdomadairement, mensuellement, …) peut influencer sa structure.
• Penser à la volumétrie des sources de données et à la fréquence de mise à jour.
• Faire attention aux environnements trop mouvants, c’est à dire aux mises à jour trop
fréquentes.
• Synchroniser l’alimentation des différents Data Mart qui composent son outil
décisionnel sinon on peut obtenir des rapports dans la phase de RESTITUTION
faussés.

Extraction
• Extraire des données des systèmes de production
• Dialoguer avec différentes sources:
Base de données,
Fichiers,
……
• Utilise divers connecteurs :
ODBC,
SQL natif,
Fichiers plats

Transformation
• Rendre cohérentes les données des différentes sources ;
Transformer, nettoyer, trier, unifier les données ;
 Exemple: unifier le format des dates
(MM/JJ/AA JJ/MM/AA).
• Etape très importante, garantit la cohérence et la fiabilité des données ;

Chargement
• Insérer ou modifier les données dans l’entrepôt
• Utilisation de connecteurs:
ODBC,
SQL natif,
Fichiers plats

ETL avec SQL Server

SQL Server Intégration Services (SSIS):un outil de gestion de flux de données.

Exemple ETL : Charger les données d’une table (dbo.clients) d’une BD(source) vers une autre
table (dbo.custumer) d’une autre BD(destination) avec modification des données.

1. Dans BIDS, cliquez sur "Fichier", sur "Nouveau" puis sur "Project".
2. nous allons donc choisir Projet Integration Services, Après validation par OK.

3. la fenêtre ci-dessous apparait

4. Pour commencer, vous allez glisser l’outil tache de flux de données (Data Flow
Task) sur votre espace de travail dans l'onglet flux de contrôle (Control Flow). Puis
double cliquez dessus.

5. Vous vous trouvez désormais dans l'onglet flux de contrôle (Data Flow), dans cet
onglet, sélectionner l’outil Source OLE DB et le faire glisser sur l’espace de travail.
6. . Double cliquer dessus, vous êtes maintenant dans le menu OLE DB Source editor ,
dans l'onglet gestionnaire de Connexions (Connexion manager) , sélectionner la
base de données et la table dont vous voulez exporter les données.

7. Puis passer dans l'onglet Colonnes (Column) vérifier que les colonnes de la table sont
bien toutes présentes et sélectionner celles dont vous voulez exporter le contenue.
8. Ensuite, sélectionner l'outil colonne dérivée (Derived Column) , reliez le à
l’outil Source OLE DB puis double cliquez dessus
9. Vous vous trouverez ensuite dans le menu éditeur de transformation de la colonne
dérivée (Derived Column Transformation Editor), c'est dans ce menu que la
modification des données se fait, vous pouvez insérer une colonne ou effectuer des
modifications grâce aux différents outils se trouvant à droite de la fenêtre. Il vous
suffit de remplir les champs se trouvant en bas de la fenêtre, donnez un nom à votre
colonne, choisir d'en créer une ou d'en remplacer une, puis choisir le contenu de
votre colonne. Dans notre cas, nous allons modifier le nom des clients, dans la table
destinataire, la colonne nom indiquera les noms en majuscule.

10. Sélectionner ensuite l'outil Destination OLE DB et le faire glisser sur l'espace de
travail et relier l'outil colonne dérivée (Derived Column) à l'outil Destination OLE DB
Puis double cliquer dessus.
11. Dans le menu éditeur de destination OLE DB (OLE DB Destination Editor), dans
l'onglet gestionnaire de Connexions (Connexion manager), choisissez la table
destinataire du chargement.

12. Puis dans l'onglet Mappages, vérifier que les colonnes soient bien reliées
correctement.
13. Puis lancer le chargement par un clic droit sur la tache de flux de données (Data
Flow Task) et cliquer sur Exécuter la tâche, vous constaterez que le transfert de
données sous SSIS 2008 à bien été fait (la tache de flux de données devient verte)
et que la modification de la colonne a été prise en compte et chargée dans la table
destinataire.
Vérifier le chargement des données dans la bd destination.
V. Bibliographie
Sites Web
• http://www.dw-institute.com/
The Data Warehouse Institute
• http://pwp.starnetic.com/larryg/
Infos dont accès à des livres blancs sur le DW
• http://www.promotheus.eds-fr/themes/dw/
Institut Promotheus, thème DW
• http://www.cait.wustl.edu/cait/papers/prism/
Société Prisme fondée par W.H. Inmon
• http://www.olapcouncil.org/
Outils OLAP
• http://www.mediatid.fr/datawarehouse
forum concernant le Data Warehouse

Livres
• Jean Michel Franco, «Le Data Warehouse / Le Data Mining», Eyrolles, 1997
• Ralph Kimball, «Entrepôts de Données», Intl Thomson Pub.,1997, ISBN 2-84180-
021-0
• Rob Mattison,» Data Warehousing -Strategies, Technologies and Technics», IEEE
Computer Society 1996, ISBN 0-07- 041034-8
• W. H. Inmon, «Building the Data Warehouse», ed. Wiley, 1996
• W. H. Inmon, «Managing the Data Warehouse», ed. Wiley,1997