Informatique Décisionnelle

et
Entrepôt de Données
Informatique Décisionnelle et Entrepôt de Données

Objectifs :
A la fin de ce cours, l’étudiant devra :

- Connaitre comme un journaliste, les notions d’entrepôt de données, d’informatique

décisionnelle, le lien entre les deux, le jargon de la BI.
- Appréhender la singularité des entrepôts comparativement aux bases de données standards.
- Maitriser la modélisation et la conception d’un entrepôt de données.
- Assimiler le langage d’interrogation des entrepôts.
- D’implémenter un entrepôt de données.

Contenu
Chapitre I - Entrepôts de données et Informatique Décisionnelle : Concepts de base et architecture

Chapitre II – Des bases de données aux entrepôts.

Chapitre III – Modélisation et Conception.

Chapitre IV – Requêtes sur un entrepôt.

Chapitre V – Réalisation d’un entrepôt de données.

Organisation du cours
- CM : 30 Heures
- TD : 10 Heures
- TP : 15 Heures
- TPE : 05 Heures
1 CONCEPTS ET ARCHITECTURE DE BASE ................................................................................................... 1

1.1 NOTION DE DECISION ET D’AIDE A LA DECISION............................................................................ 1

1.1.1 Qu’est-ce que la décision ?......................................................................................................... 1

1.1.2 Les étapes de la prise de décision. ............................................................................................. 1

1.1.3 Recours à l’aide .......................................................................................................................... 2

1.2 ORGANISATION DES DONNEES POUR L’AIDE A LA DECISION......................................................... 2

1.2.1 La donnée ................................................................................................................................... 3

1.2.2 L’Information .............................................................................................................................. 3

1.2.3 La connaissance .......................................................................................................................... 3

1.2.4 Le bon sens populaire................................................................................................................. 4

1.2.5 Base de données et Entrepôts .................................................................................................... 4

1.3 L’AIDE A LA DECISION, UNE NECESSITE POUR LES ENTREPRISES ................................................... 5

1.3.1 Qu’est-ce qu’une entreprise....................................................................................................... 5

1.3.2 Vue systémique de l’entreprise .................................................................................................. 5

1.3.3 Besoin des entreprises ............................................................................................................... 7

1.4 INFORMATIQUE DECISIONELLE ...................................................................................................... 7

1.4.1 Définition et objectif................................................................................................................... 7

1.4.2 Un bref historique ...................................................................................................................... 8

1.4.3 Application typique de l’Informatique Décisionnel .................................................................. 10

1.4.4 Architecture type d’un système décisionnel ............................................................................ 11

2 BASES DE DONNEES ET ENTREPOTS ...................................................................................................... 13

2.1 Enoncé du problème modèle ....................................................................................................... 13

2.2 Préoccupation des décideurs ....................................................................................................... 13

2.3 Constat.......................................................................................................................................... 14

2.4 Entrepôts de Données .................................................................................................................. 14

2.4.1 Définition .................................................................................................................................. 14

2.4.2 Caractéristiques des données .................................................................................................. 15

2.5 Magasins de données (DataMart) ................................................................................................ 16

2.6 Vues logique et conceptuelle d’un entrepôt ................................................................................ 16

2.7 Conception d’un entrepôt de données ........................................................................................ 16

3 CONCEPTION LOGIQUE ......................................................................................................................... 17

3.1 Introduction .................................................................................................................................. 17

 3.2 Tables du modèle ......................................................................................................................... 17

3.2.1 Table de faits ............................................................................................................................ 18

3.2.2 Table de dimension .................................................................................................................. 18

3.3 Modèle logique ............................................................................................................................. 19

3.3.1 Schéma en étoile ...................................................................................................................... 19

3.3.2 Schéma en flocon ..................................................................................................................... 20

3.3.3 Schéma en constellation .......................................................................................................... 21

3.4 Quelques caractéristiques ............................................................................................................ 22

3.4.1 La dimension Temps ................................................................................................................. 22

3.4.2 Grande dimension .................................................................................................................... 23

3.4.3 Evolution d’une dimension ....................................................................................................... 23

3.4.4 Dimension à plusieurs rôles...................................................................................................... 23

3.5 Démarche de conception ............................................................................................................. 24

4 LE MULTIDIMENSIONNEL ...................................................................................................................... 25

4.1 Définitions et exemple.................................................................................................................. 25

4.1.1 Données multidimensionnelles ................................................................................................ 25

4.1.2 Modèle cubique........................................................................................................................ 25

4.1.3 Exemple de cube 3D ................................................................................................................. 25

4.2 Concepts de base.......................................................................................................................... 26

4.2.1 Hiérarchie ................................................................................................................................. 26

4.2.2 Granularité de dimension ......................................................................................................... 26

4.2.3 Agrégation de données ............................................................................................................ 27

4.2.4 Importance du choix du granule .............................................................................................. 27

4.3 Navigation dans les cubes ............................................................................................................ 28

4.3.1 Opération sur les cubes ............................................................................................................ 28

4.4 Mise en œuvre.............................................................................................................................. 32

1 CONCEPTS ET ARCHITECTURE DE BASE
1.1 NOTION DE DECISION ET D’AIDE A LA DECISION
1.1.1 QU’EST-CE QUE LA DECISION ?
Vous employez régulièrement ce terme, certes. Mais actuellement vous devez être un peu confus à la suite
de cette question. Avant de continuer la lecture, sortez votre calepin et écrivez votre définition de la
décision.

Lorsque nous sommes confrontés à un problème, plusieurs pistes de solutions émergent parfois de notre
réflexion. En fin de compte, nous adoptons et réalisons une de ces solutions, celle dont nous avons décidé
au terme de notre analyse.

On peut alors admettre qu’une décision est l’accomplissement d’un choix. C’est le fait d'un acteur qui
effectue un choix entre plusieurs solutions susceptibles de résoudre le problème, ou la situation, auquel il
est confronté.

1.1.2 LES ETAPES DE LA PRISE DE DECISION.

La prise de décision est un processus cognitif complexe, différent de la réaction instinctive et immédiate,
visant à la sélection d'un type d'action parmi différentes alternatives. Ce processus est théoriquement basé
sur des critères de choix, et sur une analyse des enjeux et des options et conduit à un choix final.

Ainsi que l’a affirmé Alain Fernandez dans son ouvrage « Piloter la performance de l’entreprise innovante »,
décider n’est pas une affaire de tout repos. Celui qui décide s’engage et doit donc assumer les risques. En
effet, la pression de la concurrence, l’incertitude ambiante caractéristique du monde des affaires, la rapidité
des changements ne laissent que peu de temps aux délibérations et ne permettent pas d’envisager toutes
les éventualités. Et comme le décideur doit agir vite du fait que les opportunités n’attendent pas, la prise
de décision s’assimile alors à une prise de risque.

Le processus de prise de décision peut se décomposer en 4 phases.

1. Phase de formalisation du désir ou prise en compte de l'alerte

o Prise de conscience de la situation
o Un événement nécessite une réaction ou une opportunité mérite que l'on s'y attarde
2. Phase d'instruction
o Collecte d'informations
o Analyse des situations antérieures
o Étude des bonnes pratiques et des solutions éprouvées pour des cas similaires
o Collecte d'avis
o Appel à expert
3. Phase de choix
o Les différentes alternatives sont analysées
o Les contraintes et conditions d'application ont été correctement précisées

1
 o Le plan d'exécution est évalué
o Les risques d'échec sont calculés
o Les facteurs de succès sont identifiés
o La solution est choisie, elle est théoriquement viable
4. Phase d'exécution
o Passage à l'action
o Désignation des acteurs concernés
o liste précise des actions à engager, des objectifs à suivre, de la métrique et
des indicateurs de performance
o Définition des responsabilités

1.1.3 RECOURS A L’AIDE

Avant de prendre une décision, un responsable peut collecter des avis, il peut faire appel à des experts, il
peut recourir à la documentation des solutions éprouvées concernant des cas similaires. En bref, il peut
recourir à de l’aide.

Toute personne susceptible d’apporter une aide intéressante au décideur doit au moins posséder l’une des
caractéristiques suivantes :

- avoir de bonnes connaissances relatives au problème en cours de résolution,

- être expérimentée.

Actuellement, les machines fournissent aussi un support pour l’aide à la décision. Pour cela, les
caractéristiques évoquées ci-dessus doivent être implémentées en termes de base de connaissances et
d’archive.

L’automatisation de l’aide à la décision n’est envisageable que dans le contexte d’un système d’information
automatisé. Le système construit et accumule alors ses connaissances à partir des informations provenant
des transactions qui émanent du fonctionnement de l’application de gestion.

1.2 ORGANISATION DES DONNEES POUR L’AIDE A LA

DECISION
Lorsque l’on parle de stockage, plusieurs termes peuvent être évoqués : stockage des données, stockage
des informations, stockage des connaissances. Mais quels sont donc les différences ou les similitudes entre
ces termes ? Nous allons tenter de clarifier ces notions en reprenant ici une présentation de J.P. Malle dans
le site https://cleverm8.org

2
1.2.1 LA DONNEE

Selon wikipedia : « Une donnée est une description élémentaire d’une réalité. C’est par exemple une
observation ou une mesure ».

La donnée est une notion abstraite typée. Il y a des données numériques, symboliques, textuelles,
logiques, … La donnée ne porte pas de sens en elle-même. Si je code une fonction y = sinus(x), l’angle
représenté par la valeur x n’a pas d’importance. Il peut s’agir d’un angle fait par un meuble dans une
pièce, d’un angle de trajectoire d’une comète, de la pente d’une courbe d’évolution d’un cours de
bourse, tout ceci n’est pas impactant sur la fonction sinus.

Lorsque je range des données dans une base de données, peu importe leur signification. La
performance de l’algorithme de stockage et de restitution est uniquement liée au type et au volume
des données, à la fréquence et à la nature des accès à ces données.

On peut dire que la grande majorité des traitements réalisés par les informaticiens concernent des
données dont le sens porté par leurs valeurs n’est pas déterminant au sein du traitement. Mais il ne
s’agit généralement pas des traitements les plus compliqués. Les traitements deviennent plus
compliqués lorsqu’il est nécessaire de différentier les données en fonction de leur sens, quand ces
données deviennent des informations.

1.2.2 L’INFORMATION

Selon Wikipédia : Au sens étymologique, l’information est ce qui donne une forme à l’esprit. Elle vient
du verbe latin informare, qui signifie « donner forme à » ou « se former une idée de ».

L’information est aussi une notion abstraite, mais d’un niveau d’abstraction supérieur à celui de la
donnée. On peut dire pour simplifier que l’information est une donnée + un sens.

Si je compare deux adresses en considérant qu’il s’agit de données, il me suffit de faire appel à une
fonction qui va comparer les deux chaines de caractères, octet par octet. Mais nous savons bien que
les deux adresses peuvent être identiques sans que leurs représentations le soit. Un code postal peut
être écrit 91000 ou F91000, Boulevard peut être abrégé en Bd, Monsieur en M., le nom et le prénom
peuvent être écrits dans des ordres différents, etc.

Comparer deux informations s’avère bien plus complexe que comparer deux données. En confondant
les deux termes, des incompréhensions apparaissent, un maitre d’ouvrage peut s’attendre à un
traitement au sens des informations et un fournisseur peut livrer un traitement sur la base de simples
données.

De fait, utiliser le bon terme n’est jamais suffisant, il faut préciser la définition des deux termes pour
interpeler le lecteur et éviter l’interprétation. C’est primordial.

1.2.3 LA CONNAISSANCE

Selon wikipedia : » La connaissance est une notion aux sens multiples à la fois utilisée dans le langage
courant et objet d’étude poussée de la part des philosophes contemporains ».

3
La connaissance est aussi une notion abstraite, d’un niveau d’abstraction supérieur à celui de
l’information. La connaissance à la différence de l’information est partagée et s’appuie sur un
référentiel collectif.

Mais attention, des informations peuvent être communiquées sans pour autant devenir des
connaissances. Il faut alors les accompagner de leur référentiel puisque celui-ci ne sera pas partagé
(non-implicite).

Si je vous communique un code postal, je n’ai pas besoin de vous expliquer ce dont il s’agit, vous
disposer d’un référentiel pour interpréter ce code, par exemple pour savoir si le département est
maritime, montagneux, campagnard en vue de segmenter une offre de produits. Le code postal
s’apparente à une connaissance largement partagée en France. Mais si je communique ce code postal
à une équipe en Inde, il est fort probable qu’il sera considéré simplement comme une information, en
l’absence de référence de connaissance, ou pire de simple donnée.

La connaissance peut être spécifique à un métier, donc partagée seulement par les experts du métier.

1.2.4 LE BON SENS POPULAIRE

Il est intéressant de noter que dans les expressions spontanées le bon terme est généralement présent.
Notre cerveau effectue naturellement la distinction entre les 3 notions.

Mon web designer va me demander : « comment veux-tu que je présente tes données techniques sous
la photo des moteurs ? ». Il me spécifie ainsi que la signification des chiffres communiqués n’est pas
de son ressort.

Mon client va me dire : « j’ai regardé votre catalogue de moteur à la recherche du nombre de cylindre
et je n’ai pas trouvé cette information !« . Il me signifie ainsi qu’il sait à quoi correspond un nombre
de cylindre et qu’il était tout à fait capable de le relever quelle que soit la forme sous laquelle il aurait
pu être écrit dans le catalogue.

Mon DRH va recruter un collaborateur en lui demandant : »avez-vous des connaissances sur la
mécanique automobile ? ». Il précise ainsi le cadre dans lequel le collaborateur doit s’inscrire et se
sentir à l’aise. Ainsi le collaborateur recruté sera plus à même d’interpréter les informations techniques
des moteurs que je souhaite proposer sur mon site internet BtoB.

1.2.5 BASE DE DONNEES ET ENTREPOTS

Nos systèmes d’informations sont supportés par des systèmes informatiques qui traitent uniquement des
données (création, recherche, transformation, visualisation, etc.). La première couche de ce modèle est la
donnée et leur implémentation conduit au développement d’applications transactionnelles en ligne (OLTP)
reposant sur des bases de données.

Les applications OLTP se caractérisent par un grand nombre de transactions relativement simples.
Habituellement, les transactions retrouvent et mettent à jour un nombre d’enregistrements qui sont
contenus dans plusieurs tables distinctes. Les relations entre ces tables sont généralement simples

Cependant, ce qui est attendu de la technologie de l’information d’aujourd’hui c’est la possibilité d’aider
les utilisateurs de connaissances (gestionnaires, analystes, décideurs) dans la prise de décision. Les

4
requêtes typiques de ce type de besoin concernent l’analyse des données ou la mise en évidence de
connaissance.

Les bases de données traditionnelles ne sont plus indiquées, tout comme les applications OLTP. Pour
satisfaire les besoins des décideurs, les données doivent être organisées sous une forme qui facilite la
déduction rapide des connaissances. Cette organisation est la pierre angulaire du récipient de données
pour la décision : les entrepôts.

Le système d’information décisionnel (SID) spécialise le système d’information de l’entreprise pour

prendre les besoins des décideurs. Leur automatisation conduit au développement d’application
analytique en ligne (OLAP) reposant sur des entrepôts de données.

1.3 L’AIDE A LA DECISION, UNE NECESSITE POUR LES

ENTREPRISES

1.3.1 QU’EST-CE QU’UNE ENTREPRISE

Une entreprise est une organisation devant gérer sa pérennité au travers des objectifs de sécurité, de
développement et de rentabilité. Ces objectifs généraux se déclinent en de sous-buts opérationnels tels
que l’améliorer ses performances, l’opposition à la concurrence, le développement des parts de marché,
l’amélioration de la connaissance de ses clients et de son environnement, l’agilité et la prise rapide des
décisions. Pour y parvenir, elle doit être dotée d’un centre de décision.

1.3.2 VUE SYSTEMIQUE DE L’ENTREPRISE

La figure ci-dessous illustre l’architecture systémique d’une entreprise. Elle est constituée de 3 sous-
systèmes : le sous-système opérant (SO), le sous-système de pilotage (SP) et le sous-système d’information
et d’aide à la décision.

5
Le système opérant (SO) est le siège de l’activité productive (réalisation du projet) : transformation de
matières, production de biens matériels, production de services.

Le système de pilotage (SP) est le siège de l’activité décisionnelle et de contrôle. Il fixe les objectifs, contrôle
l’activité du SO, régule et fait évoluer l’organisation.

Le système d’Information et d’Aide à la Décision(SIAD) assure la liaison entre SO et SP. Il met à disposition
de ces sous-systèmes toutes les informations nécessaires à la réalisation de leurs objectifs.

FIG. 2 : Relation entre données, information et connaissance dans un SIAD

Le SIAD comporte deux parties, le système d’information (SI) et le système décisionnel (SD). Le SI est
l’intermédiaire entre le SO et le SP. Il effectue l’acquisition, le stockage, le traitement et la distribution des
informations que s’échangent ces unités. Les principaux traitements dans ce sous-système sont de type
transactionnel. Ils sont mis en œuvre à l’aide d’applications transactionnelles dites OLTP et reposent sur
des bases de données transactionnelles.

6
Le SD agrège les données transactionnelles contenues dans le SI puis les stocke dans des entrepôts selon
une organisation typique pour satisfaire les besoins des décideurs. Ces besoins sont mis en œuvre à l’aide
d’applications analytiques dites OLAP.

1.3.3 BESOIN DES ENTREPRISES

Au fil du temps, l’entreprise dispose d’une masse importante de données collectées par ses nombreux
systèmes d’information. Cette surabondante Information est en général hétérogène, non organisée,
codifiée différemment selon les services et éparpillée dans les branches de l’entreprise où elle est collectée.

De ces données, parfois acquise durant des décennies, l’on peut extraire des connaissances enfouies et
susceptible de booster le pouvoir économique de l’entreprise ou d’aider à la prise de décision. Leur maîtrise
est donc un impératif. Ce qui nécessite l’adoption de technologies pour l’accès, le regroupement et
l’exploitation de données disséminées.

1.4 INFORMATIQUE DECISIONELLE

1.4.1 DEFINITION ET OBJECTIF
De l’anglais Business Intelligence (BI) l’informatique décisionnelle est la branche de l’informatique qui
s’intéresse aux moyens, outils et méthodes permettant de collecter, consolider, modéliser et restituer les
données d'une entreprise en vue d’offrir une aide à la décision.

Le BI a pour objectifs d’offrir une vision globale de l’activité et un support pour l’aide à la décision. Elle est
basée sur un entrepôt de données pour le stockage des données.

Le terme entrepôt de données ou EDD (ou base de données décisionnelle ; en anglais, data warehouse ou
DWH) désigne une base de données utilisée pour collecter, ordonner, journaliser et stocker des
informations provenant de base de données opérationnelles et fournir ainsi un socle à l'aide à la décision
en entreprise

Une application OLAP doit permettre de produire des rapports qui répondent aux questions :

 Que s’est-il passé ?

 Que se passe-t-il en ce moment ?
 Pourquoi est-ce que cela s’est passé ?
 Que va-t-il se passer ?
 …

7
1.4.2 UN BREF HISTORIQUE
Le contenu de cette section est tiré de l’ouvrage Internet/Intranet et bases de données de Georges
Gardarin.

Les architectures et techniques pour l’aide à la décision fondée sur l’analyse de grandes bases de données
nécessite de stocker les données extraites de sources de données hétérogènes sur des serveurs spécialisés
dédiés au décisionnel. Alors que les bases de données de production sont mises à jour en transactionnel
(On Line Transaction Processing, OLTP) les bases de données décisionnelles sont consultées en interactif
pour l »analyse des données (On Line Analysis Processing, OLAP).

OLTP et OLAP sont deux modes de travail interactif radicalement différents. L’OLTP a été la cible essentielle
des systèmes de base de données relationnelles jusqu’au milieu des années 90. Il est centré sur la mise à
jour ponctuelle de données. Seules quelques lignes de tables sont traitées par chaque transaction, à partir
d’écrans fixes préprogrammés. Les transactions échangent de faibles quantités d’informations avec
l’utilisateur et travaillent toujours sur les versions les plus récentes des données.

Au contraire, l’OLAP qui s’est développé depuis le début des années 80 travaille en lecture seulement. Les
programmes consultent d’importantes parties des bases de données pour procéder à l’analyse, par
exemple l’élaboration d’histogrammes. C »est un mode de travail global sans écran fixe, par navigation dans
la base selon diverses dimensions constituées par des attributs de tables. Il nécessite de consulter des
versions historiques de la base et peut se permettre d’ignorer temporairement les toutes dernières mises
à jour. La taille des bases OLAP est d’un ordre de grandeur supérieur à celle des bases OLTP du fait de la
conservation des données historiques.

Les systèmes du début des années 80 ont déjà permis d »e constater l’opposition entre OLTP et OLAP. Les
bases de données manipulées demandent en effet des structures différentes, des modes de verrouillage
incompatibles, voire des modèles différents.

On a ainsi inventé l’infocentre dans les années 85, une technologie consistant à recopier des bases de
données ou des parties de bases pour assurer les traitements décisionnels.

Le data warehouse ou entrepôt de données est un prolongement de l’infocentre dans un contexte réparti.
Il date du début des années 90. Dès le début, il s’agit de matérialiser des vues de multiples sources de
données, de les maintenir sur une machine séparée et de les exploiter pour le décisionnel.

Les développements récents rendent possible le support de larges bases de données pour l’OLAP et pour
des techniques plus évoluées comme le data mining. Tous ces développements se sont accompagnés d’un
passage graduel de la donnée à l’information puis à la compétence.

Comparaison OLTP et OLAP

8
9
1.4.3 APPLICATION TYPIQUE DE L’INFORMATIQUE DECISIONNEL
Banque et assurance

 Détermination de profils de clients (risques de prêt, nouveaux services)

 Suivi des clients, gestion de portefeuilles
 Mailing ciblés pour le marketing…

Logistique

 Adéquation demande/production

Santé

 Etudes épidémiologiques
 Recherche de nouveaux médicaments…

Grande distribution

 Ciblage de clientèle, habitudes d’achat, secteurs géographiques…

 Opportunités de promotions, produits à succès, modes…
 Agencements de magasins (sur la base de corrélations entre produits)

Econométrie

 Prévisions de trafics routiers

 Prévisions de mouvements boursiers…

Télécommunications

 Gestion des pannes, détection fraudes

 Classification des clients

Fig.3 : Utilisation du décisionnel en entreprise

10
1.4.4 ARCHITECTURE TYPE D’UN SYSTEME DECISIONNEL
La figure suivante représente l’architecture type d’un système décisionnel.

Fig.4 : architecture type d’un système décisionnel

Sources de données

 Informations internes : Données de production, données commerciales, données comptables,

données sur le personnel
 Informations externes : Informations sur la concurrence, informations produites par des
organismes nationaux ou internationaux, informations économiques…
 Mode de stockage : SGBD, documents texte, images, multimédia, web…

Outils ETL

 Préparation des données en vue de leur intégration

 Extraction, nettoyage, transformation, combinaison, standardisation, chargement des données…

Entrepôt de données

 Optimiser l’accès aux informations

 Stockage des données
 Support du processus d’aide à la décision
 Vision multidimensionnelle

DataMart

 Magasin de données

11
  Sous-ensemble des données de l’entrepôt
 Dédié à un secteur d'activité ou à un métier particulier

Méta-données

 Informations sur les données de l‘entrepôt

 Organisées dans un référentiel
 Structure des données, règles de transformation, règles de dérivation, règles de filtrage…
 A quelle donnée de base se réfère cette information

Cubes OLAP

 Vues multidimensionnelles
 Cubes à plusieurs dimensions
 Fins d’analyse et de décision

Reporting

 Génération de rapports, de tableaux de bord

 Outils statistiques
 Tableaux, indicateurs, graphiques…
 Analyse multidimensionnelle
 Navigation dans les cubes OLAP
 Data Mining

Fouille de données

 Extraire de la connaissance cachée dans les données

 Règles d’association, classification supervisée, non-supervisée, visualisation, segmentation…

12
2 BASES DE DONNEES ET ENTREPOTS
Ce chapitre aborde en premier la création d’une base de données dans l’objectif d’effectuer une mise à jour
de vos connaissances dans le domaine. La deuxième section concerne le traitement de requêtes. On verra
alors que les BD ne sont pas outillées pour le type de requêtes qui correspondent principalement aux
préoccupations de décideurs. Le modèle d’entrepôt sera alors présenté comme palliatif à cette limite des
BD.

2.1 Enoncé du problème modèle

Une entreprise commerciale possède plusieurs magasins dans différentes villes. Les ventes qu’elle effectue
dans chaque magasin sont enregistrées dans un serveur central. Le sous-système d’information
correspondant à cette activité met à disposition les informations suivantes :

- le détail de chaque vente : produits et quantité de produits associés à la vente,

- le lieu de la vente,
- le total de la vente
- …

Concevoir la base de données sous-jacente de manière à répondre aux requêtes suivantes :

- Nombre de magasins de l’entreprise.

- Nombre de ventes du 10-05-2018.
- Liste des produits non vendu le 15-10-2019.
- Total des ventes par magasin le 20-04-2020.

Avant d »écrire les requêtes SQL correspondantes aux besoins ci-dessus, remplir les tables de votre base
avec suffisamment de données pour agrémenter son utilisation.

2.2 Préoccupation des décideurs

L’objectif d’un décideur est d’obtenir des rapports pour lui permettre de répondre aux questions du type :

 Que s’est-il passé ?

 Que se passe-t-il en ce moment ?
 Pourquoi est-ce que cela s’est passé ?
 Que va-t-il se passer ?
 …

Dans le contexte particulier de transactions commerciales ces questions d’ordre générales peuvent se
décliner en questions spécifiques telles que :

 Quelles sont les ventes du produit X pendant le trimestre A de l'année B dans la région C ?
 Quel est le volume des ventes par produit et par région durant le 3ème trimestre 2006 ?
 Quels sont les types de produit s dont le volume des ventes baisse constamment dans les 6 derniers
mois de l’année en cours ?

13
  Comment se comportent les ventes du produit X par rapport aux ventes du produit Y ?
 Comment se comportent les ventes du produit X au cours de la période 2005-2007 par rapport à la
période 2003-2005 ?
 Est-ce qu’une baisse de prix de 10% par rapport à la concurrence ferait redémarrer les ventes du
produit X?
 Quelles sont les composantes des machines de production ayant eu le plus grand nombre
d’incidents imprévisibles l’an dernier ?
 Combien de clients l’entreprise a-t-elle perdue l’an dernier et pourquoi ?
 Quel type de client peut bien acheter mon produit Z ?
 Quels sont les clients les plus rentables ?
 Quelles actions faut-il mettre en œuvre pour pérenniser, voire accroître leur fidélité ?
 Quels éléments concourent à l’amélioration de leur satisfaction ?
 Dispose-t-on d’indicateurs permettant de qualifier l’impact du niveau de satisfaction des clients sur
la rentabilité de l’entreprise ?
 Quel est le niveau de satisfaction des collaborateurs et quels en sont les paramètres déterminants
?

2.3 Constat
A vouloir trouver des requêtes SQL, vous avez certainement constaté la difficulté de l’exercice. Ce qui est
normal car les SGBD traditionnels ne sont pas outillés pour répondre à de telles questions.

Pour déterminer le volume des ventes du produit X durant le trimestre A dans la région C, il faut :
- Isoler toute les ventes de X dans la région C.
- Spécifier l’intervalle de temps souhaité.
- Extraire toutes les ventes réalisées dans cet intervalle de temps.
- Synthétiser le résultat.
Cette opération doit être répétée pour chaque produit si l’on s’intéresse aux volumes de vente par produit.
Ce qui est coûteux en temps de calcul. Les entrepôts de données permettent de résoudre ces problèmes
de complexité.

2.4 Entrepôts de Données

2.4.1 DEFINITION
Un entrepôt de données est une collection de données multidimensionnelles, orientées sujet, intégrées,
non volatiles et historisées, organisées pour le support d’un processus d’aide à la décision.

14
 Fig. 1 : illustration d’un entrepôt de données

2.4.2 CARACTERISTIQUES DES DONNEES

Données orientées sujet
L’entrepôt est organisé autour des sujets majeurs et des métiers de l’entreprise.
Intérêt :
- Disposer de l’ensemble des informations utiles sur un sujet le plus souvent transversal aux
structures fonctionnelles et organisationnelles de l’entreprise.
- Réaliser des analyses sur ces sujets transversaux.
- Développer son système décisionnel via une approche par itérations successives, sujet après sujet.
- Dans la pratique, un datamart peut être créé pour supporter l’orientation sujet.

Données intégrées
Les données proviennent de sources hétérogènes ou d'origines diverses et peuvent intéressées différents
services de l’entreprise. Pour réaliser un référentiel commun, les données doivent être intégrées. Mais
avant d’être intégrées, les données doivent au préalables être mises en forme et unifiées afin d’avoir un
état cohérent.
L’intégration nécessite une forte normalisation de données. Une donnée doit avoir une description et un
codage unique. Cette phase d’intégration est très complexe et représente 60 à 90 % de la charge totale
d’un projet.

Données historisées
Un entrepôt est comme une archive. Les données ne nécessitent pas de mise à jour (chargement de masse).
Un référentiel temps est associé à chaque donnée. Cette historisation est nécessaire pour suivre dans le
temps l'évolution des différentes valeurs des indicateurs à analyser.

Données non volatiles

En conséquence de l’historisation, une même requête effectuée à quelques mois d’intervalle en précisant
la date de référence de l’information recherchée donnera le même résultat. Ainsi, les informations stockées
au sein de l’entrepôt de données ne peuvent être supprimées.

15
2.5 Magasins de données (DataMart)
Les entrepôts de données nécessitent de puissantes machines afin de gérer de grandes bases de données
contenant les données historisées. A côté et souvent en complément se développent des bases de données
ciblées sur quelques sujets limités, appelés magasin de données ou datamart. Ces petits entrepôts offrent
des données aux décideurs de l’entreprise pour l’analyse, celles-ci pouvavt provenir des data warehouse,
ou plus généralement des bases existantes.
Les magasins sont donc des entrepôts qui présentent l’avantage de nécessiter une infrastructure plus
légère, de pouvoir être mis en œuvre plus rapidement et d’être mieux centrés sur un problème.

2.6 Vues logique et conceptuelle d’un entrepôt

Les figures ci-dessous représentent respectivement un modèle logique et une organisation
multidimensionnelle des données d’un entrepôt.

Fig. 1 : modèle logique et modèle multidimensionnel

2.7 Conception d’un entrepôt de données

En vous inspirant du schéma ci-dessus, concevoir le modèle logique de l’entrepôt de données pour notre
problème exemple. Proposer ensuite une vue multidimensionnelle de cet entrepôt.

16
3 CONCEPTION LOGIQUE
3.1 Introduction
Les techniques de conception appliquées aux entrepôts sont basées sur la modélisation
multidimensionnelle des données. Le concepteur identifie dans un premier temps les faits à analyser puis
il détermine ensuite les dimensions d’analyse qui leur sont associées.
Les faits sont les données numériques (économique) à analyser. Ils servent de base à la définition des
indicateurs. Un fait peut par exemple correspondre au nombre de ventes, au chiffre d’affaire, ou à une
quantité stockée.
Les axes d’analyse associés aux indicateurs sont appelés dimensions. Une dimension peut être par exemple
le temps, le client, la géographie, un produit, etc.
La figure suivante montre une représentation multidimensionnelle sous la forme d’un cube, des données
correspondantes à la vente de produits dans le temps et par région.

Le fait considéré est le total des ventes. Il est étudié par rapport à 3 dimensions : le Temps, les Pays et les
Produits.

3.2 Tables du modèle

Comme pour le modèle relationnelle, des tables sont nécessaires pour représenter les données. Le modèle
d’entrepôts comporte 2 types de tables, les tables de fait et les tables de dimension.

17
3.2.1 TABLE DE FAITS
La table de faits est la clef de voûte du modèle dimensionnel où sont stockés les indicateurs de
performances. Les indicateurs étant les données les plus volumineuses d’un système d’information, il faut
les rationaliser au sein des tables de faits.
La table de fait comporte typiquement :
- Un ou plusieurs attributs de dimension servant à caractériser les attributs de faits et permettant
de conduire les analyses.
- Zéro ou plusieurs attributs de faits.
- Eventuellement un attribut spécifique clé primaire s’il est nécessaire d’identifier chaque tuple.
- Peu de colonnes mais beaucoup de lignes.
La figure suivante représente un modèle graphique de table de fait. Elle se présente sous la forme d’un
rectangle comportant 2 parties, une pour le titre et l’autre pour les attributs.

Fig. 1 : schéma d’une table de fait

La conception d’une table de faits nécessite de :

- Identifier les faits (mesures de performance à considérer)
- Identifier les différentes dimensions
- Déterminer si ces faits peuvent être rassemblés dans une même table
- Déterminer l’opportunité de matérialiser les faits calculés
- Choisir le grain de la table de faits

3.2.2 TABLE DE DIMENSION

Les dimensions sont des entités complémentaires à la conception des tables de faits. Elles jouent le rôle de
référentiel à l’entrepôt. Chaque axe du cube est représenté par une table de dimension. Si la table de
dimension n’existe pas on dit que la dimension est dégénérée.
La table de dimension comporte typiquement :
- La clé primaire de la dimension qui est une clé étrangère dans la table de faits.
- D’autres attributs (textuelles ou numériques) appelés membres permettant de caractériser la
dimension.
- Peu de lignes mais beaucoup de colonnes.

18
Les tables de dimension sont schématisées comme le montre la figure ci-dessous :

Fig. 2 : schéma d’une table de dimension

Les membres d’une table de dimension sont généralement dépendants et organisés en hiérarchie
(dépendances fonctionnelles). Par exemple :
- Référence  Famille
- Famille  Type
- Type  Gamme
Dans la conception d’une table de dimension, il faut éviter la présence de circuits dans une hiérarchie. Les
membres impliqués dans une hiérarchie guident les opérations ROLL/UP et DRILL/DOWN. Un membre peut
être caractérisé par des attributs spécifiques (qui ne guident pas les agrégations mais qui peuvent servir
pour des sélections).
La hiérarchie entre attributs peut servir de base pour la normalisation de la dimension.

3.3 Modèle logique

On peut modéliser un entrepôt de 3 manières : en étoile, en flocon ou en constellation.

3.3.1 SCHEMA EN ETOILE

Exemple de modèle

19
 Caractéristiques
- Une table de faits centrale reliée par clés primaires aux tables de dimensions.
- Chaque dimension est décrite par une seule table dont les attributs représentent les diverses
granularités possibles.

Avantages
- Facilité de navigation, gestion des agrégats.
- Peu de jointures.

Inconvénients
- Toutes les dimensions ne concernent pas toutes les mesures.
- Redondances dans les dimensions.

3.3.2 SCHEMA EN FLOCON

Exemple de modèle

20
 Caractéristiques
- Une table de faits centrale reliée par clés primaires aux tables de dimensions.
- Les dimensions sont décrites par une succession de tables (à l’aide de clefs étrangères)
représentant la granularité de l'information.

Avantages
- Economie de place de stockage.
- Evite les redondances.

Inconvénients
- Complexité du modèle.
- Plus de jointures.

3.3.3 SCHEMA EN CONSTELLATION

Exemple de modèle

21
 Caractéristiques
- Plusieurs tables de faits à dimensions partagées

Avantages
- Meilleure gestion des données creuses.

Inconvénients
- Complexité du modèle.

3.4 Quelques caractéristiques

3.4.1 LA DIMENSION TEMPS
Cette dimension est toujours présente et souvent reliée à toute les tables de fait. Elle permet de différencier
les dates et les périodes.
Elle offre diverses possibilités pour repérer le temps. Notamment :
- Attribut de type DATE géré avec les fonctions SQL.
- Codification spécifique gérée directement par l’application.
- Table Temps + Calendrier
o Informations supplémentaires : événements, jours fériés, vacances, période fiscale, saison
haute, saison basse…
Elle offre la possibilité de gérer des échelles de temps différentes (ex : calendrier civil / fiscal) avec deux
tables de dimensions différentes.

22
3.4.2 GRANDE DIMENSION
En présence de tables de dimensions avec de nombreux attributs et de nombreux tuples (Clients,
Produits…), une solution consiste à :
- Evoluer vers un schéma en flocon
- Introduire une nouvelle table de dimension contenant des intervalles de valeurs

3.4.3 EVOLUTION D’UNE DIMENSION

Les tables de dimension doivent pouvoir être mises à jour même si leur évolution est généralement lente.
L »évolution concerne par exemple le changement d’adresse d’un client ou l’appellation d’un produit.
Diverses solutions existent pour prendre en compte ces évolutions :
- Ecrasement de l’ancienne valeur
- Versionnement
- Valeur initiale / valeur courante
- Valeur antérieure / valeur courante

3.4.4 DIMENSION A PLUSIEURS ROLES

Il est fréquent qu’une dimension joue plusieurs rôles relativement à la même table des faits. Une solution
consiste en l’introduction dans la table de faits d’une clé étrangère différente pour chaque rôle.

23
3.5 Démarche de conception
Etude des besoins
- Décrire les objectifs visés, situer les types d’analyse à effectuer et les types de rapports à produire
- Identifier les sources et évaluer les difficultés d’intégration, les volumes de données concernés
(approximatifs)…
Conception du schéma
- Approche guidée par les besoins
- Approche guidée par les sources
Vérification du schéma

24
4 LE MULTIDIMENSIONNEL
4.1 Définitions et exemple
4.1.1 DONNEES MULTIDIMENSIONNELLES
Les données décisionnelles sont perçues à travers plusieurs dimensions. Elles sont qualifiées de données
multidimensionnelles, indépendamment de leur support.

4.1.2 MODELE CUBIQUE

Le modèle cubique est un modèle abstrait pour formaliser la manipulation de données
multidimensionnelles. Dans ce modèle,
 chaque axe est associé à une dimension ;
 chaque cellule est associée à un fait (une mesure) ;
 diverses implémentations et visualisations sont possibles

4.1.3 EXEMPLE DE CUBE 3D

La figure ci-dessus montre un cube étendu dont les mesures de base correspondent aux cellules noires. Les
autres cellules ont été ajoutées simplement pour mettre en évidence quelques types d’opérations que l’on
peut rapidement effectuer sur un cube.

25
4.2 Concepts de base
4.2.1 HIERARCHIE
Les données décisionnelles sont perçues à travers plusieurs dimensions qui servent d’axes d’analyse. Les
dimensions sont caractérisées par un ou plusieurs attributs qui peuvent être organisés en une hiérarchie.
La figure suivante montre un exemple de hiérarchie.

Fig. 1 : organisation hiérarchique d’une dimension

4.2.2 GRANULARITE DE DIMENSION

On peut associer une mesure primitive ou une mesure calculée à chacune des valeurs d’une dimension.
La granularité des dimensions caractérise la finesse de la décomposition en niveaux. Des exemples de
granularité de dimensions sont figurés ci-dessous.

Fig. 2 : granularité de dimensions

26
La granularité d’une dimension est dite à petit grain si le niveau associé à une mesure est le plus bas possible
dans la hiérarchie. Par contre, elle est dite grossière ou à gros grain lorsque le niveau associé à une mesure
est élevé.

4.2.3 AGREGATION DE DONNEES

Les mesures du niveau le plus détaillé doivent être obligatoirement mémorisées. Ceci permet de déduire
les mesures associées aux valeurs de plus haut niveau dans la hiérarchie. Ces mesures de niveau supérieur
sont obtenues par agrégation des mesures de plus bas niveau. L’agrégation des données est illustrée par la
figure ci-dessous.

Fig. 3 : niveau d’agrégation

4.2.4 IMPORTANCE DU CHOIX DU GRANULE

Le volume d’un entrepôt est fonction du nombre et de la graduation considérée pour chaque dimension.
En effet, le nombre de cellules élémentaires de la table de fait est le produit des gabarits de dimension. Le
gabarit étant ici considéré comme le nombre de graduation dans une dimension.
Comme pour une dimension le gabarit dépend du niveau hiérarchique considéré, le choix du granule affecte
en conséquence :
- le volume de l’entrepôt,
- le type de requêtes possibles,
- les développements à réaliser…
L’exemple du suivi des consommations chez un opérateur de télécommunications relève cette importance
du choix de granule.
 Suivi de la facturation détaillée
o 100 appels/mois, 50 octets/appel, historique d’un an, 10 millions d’abonnés
o 600 Go : Volume important mais possibilités d’analyse importantes

27
  Suivi de la consommation mensuelle seulement
o !1 info/mois, 50 octets/info, historique d’un an, 10 millions d’abonnés
o 6 Go : Volume plus réduit possibilités d’analyse beaucoup plus limitées

4.3 Navigation dans les cubes

4.3.1 OPERATION SUR LES CUBES
Le modèle cubique est un modèle abstrait pour formaliser la manipulation de données
multidimensionnelles. Les opérations sur le cube ainsi définies constituent les bases des manipulations
multidimensionnelles. Ces opérations peuvent être combinées (enchaînées) pour résoudre des opérations
plus complexes. Les mises en œuvre de ces opérations sont très diversifiées. Certains systèmes les
implémentent complètement, d’autres les implémentent partiellement.

On peut regrouper les opérations sur des cubes en trois catégories : les opérations de structure, les
opérations sur le contenu et les opérations entre cubes.

Roll-up
- Forage vers le haut
- Agréger selon une dimension
- Ex : Semaine #Mois
- Synthèse des informations en fonction d'une dimension
Drill-down
- Forage vers le bas
- Opération inverse du roll-up
- Détailler selon une dimension
- Ex : Mois #Semaine
- Possibilité de « zoomer » sur une dimension

28
Rotate
- Pivot, rotation par rapport à l’un des axes de dimension

Switch
Permutation de valeurs de dimensions

Split

29
Nest / Unnest

PUSH / PULL

30
Slice / Scope

Dice

Union

31
4.4 Mise en œuvre
Un entrepôt de données est une BD dédiée pour l’aide à la décision et maintenue séparément du système
de production. Leur essor est dû aux limites des SGBD relationnels classiques :
- Orienté vers le transactionnel (OLTP)
- Manque d’expressivité des requêtes SQL pour le décisionnel (OLAP)
- Structures et algorithmes inadaptés à la charge de travail
Malgré cela, certaines techniques de mise en œuvre physique s’appuie encore sur les approches du
relationnel. !  Il existe trois approches différentes pour stocker les données décisionnelles
- Le M-OLAP (Multidimensional OLAP) qui implémente une approche multidimensionnelle au niveau
physique. Ses performances sont optimales pour les requêtes OLAP et son couplage est aisé avec
les outils d’analyse.
- Le R-OLAP (Relationnal OLAP) qui implémente une approche relationnelle au niveau physique.sa
mise en œuvre repose sur des bases de données relationnelles munies d’extension OLAP.
- Le H-OLAP (Hybrid OLAP) qui combine les deux approches précédentes.

32