Université Cadi Ayyad Marrakech

Ecole Supérieure de Technologie Essaouira

LP ISIL Semestre 6

Module 8
Bases de Données Avancées

Chapitre II
Business Intelligence
Conception de data warehouse
Pr: A. Guezzaz
Année: 2019 -2020
I.Introduction au Business Intelligence (BI)
1. Introduction à l’aide de décision
2. Transactionnel vers Décisionnel
3. Entrepôts de données (DW) Data Warehouse
4. Cycle de vie d’un projet BI

II.Conception d’un entrepôt de données (DW)

1. Analyse de l’entrepôt de données
2. Modélisation de l’entrepôt de données
 Modèle en Étoile (Star Schema)
 Modèle en Flocons de neige (Snowflack Schrma)
 Modèle Mixte (Mixed Shema)
 Modèle en Constellation (Fact Constellation Schema)
3. Evolution des dimensions
2
Introduction au Business Intelligence (BI)

3
Introduction à l’aide de décision
 Décider des actions à conduire,
 Contrôle l’exécution des travaux,
 Analyse l’environnement,
Système de Pilotage
 Contrôle le système opérant,

 Collecter,
 Mémoriser,
 Traiter, Système
d’INFORMATION
 Distribuer l’information.

 Fabriquer les produits

Système
 Facturer les clients,. …
OPERANT
 Exécutent les ordres du système de pilotage
Quels outils donner au décideur pour comprendre, piloter et gérer ?
4
Introduction à l’aide de décision

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.
5
Transactionnel vers Décisionnel
 Caractéristiques du Transactionnel
 « 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. Il n’y a pas de données d’archives dans les systèmes
transactionnels».

 Opérations d’un système transactionnel:

 Ajout;
 Suppression;
 Mise à jour des enregistrements;
 Requêtes simples, ………

9
Transactionnel vers Décisionnel
 Contraintes du Transactionnel
 Nombre élevé de tables donc nombre élevé de jointures.
 Élaboration complexe des requêtes.
 Temps de traitement long.
 Les processus de décision nécessitent :

 Données agrégées (résumées) provenant de différentes BD

dispersées et intégrées.

 Données historiques (historisées).

 Réponses rapides (requêtes surtout de type agrégatif).

 Interfaces faciles à utiliser par l’utlisateur.

10
Transactionnel vers Décisionnel

11
Entrepôts de données (DW)

13
Entrepôts de données (DW)
 Data Marts (DM)
 Data Marts: sous-ensembles d’un entrepôt de données destinés à
répondre aux besoins d’un secteur ou d’une fonction particulière
ou d’un utilisateur particulier.
 Moins de données que DW et plus facile à comprendre et à
manipuler.
 Amélioration des temps de réponse.
 Utilisateurs plus ciblés: DM plus facile à définir.

DMs
Service Marketing
DW de
l’entreprise
DM
Service Ressources Humaine
14
Cycle de vie d’un projet BI

15
Cycle de vie d’un projet BI
 Planification du projet
 La planification aborde la définition et l’extension du projet BI.

 Elle se concentre sur les besoins en terme de ressources et de

niveau de qualification, couplés aux affectations des tâches, à leur
durées et à leur séquencement. La planification dépend bien
évidemment des besoins.

 Description des besoins

 Il est essentiel de bien comprendre les utilisateurs et leurs besoins,
sinon l'entrepôt devient simplement un exercice de la part des
concepteurs.
16
Cycle de vie d’un projet BI
 Définition des besoins de l’entreprise
 Etude du domaine métier: pour connaître le métier de
l'entreprise, se familiariser avec les termes utilisés et découvrir les
informations cachées et avec les différents logiciels utilisés dans
l'entreprise.

 Interview des acteurs clés du métier (connaître l'organigramme

de l'entreprise et savoir qui s'occupe de quoi).

 Découpage des besoins en sujets: A partir des synthèses établies

après interview. Il faut classer les besoins en sujets d'analyse.

17
Cycle de vie d’un projet BI
 Modélisation dimensionnelle
 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.

 Modèle physique
 Définition des structures nécessaires pour l'implémentation
physique du modèle dimensionnel (Environnement de la BD).

 La conception du modèle physique est fortement

dépendante du système utilisé pour l'entrepôt.
18
 Cycle de vie d’un projet BI
 Préparation des données
 La conception de la zone de préparation (staging area) est une
tâche importante dans un projet BI qui se déroule en trois phases
majeures :
1. Extraction,
2. Transformation,
3. Chargement.
 Architecture technique
 L'architecture technique nécessite la prise en compte des besoins
de l'environnement: plateformes matérielles et logicielles
 SGBD,
 Outils d'extraction,
 Outils de restitution. 19
Cycle de vie d’un projet BI
 Applications des utilisateurs
 Définition d’une série d'applications standard destinées aux
utilisateurs finaux (maquettes, les états, etc…).

 Déploiement
 Une planification est indispensable pour gérer le déploiement:

 la formation des utilisateurs,

 le support utilisateur,

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

20
Cycle de vie d’un projet BI

21
Conception d’un entrepôt de données (DW)

22
Analyse de l’entrepôt 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
(Restitution).

 Zone de préparation
 Zone temporaire de stockage des données extraites pour faire
le nettoyage, la normalisation et d’autres transformations.
 Données souvent détruites après chargement dans le DW.
23
Analyse de l’entrepôt de données
 Zone de stockage (DW)
 On y transfère les données nettoyées.

 Stockage permanent des données.

 Zone de présentation
 Accès aux données contenues dans DW, elle peut contenir
des outils d’analyse programmés: Rapports, Requêtes…

24
Analyse de l’entrepôt de données

25
Analyse de l’entrepôt de données

 Le but est de déterminer

 Les dimensions: ou les axes d'analyses avec leurs attributs.
 Les faits: ou les éléments à analyser.

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

 Faire un travail d'acteur et détailler chaque utilisateur

 Savoir comment les analystes organisent leurs raisonnements.
 Savoir ce que voient les décideurs avant de décider.

26
Analyse de l’entrepôt de données
 Table de Fait
 Un fait est la plus petite information analysable.

 La table de fait contient les données observables (faits) sur un sujet

qu’on veut étudier, selon divers axes d'analyse (dimensions).

 Ce qu’on souhaite mesurer: quantités vendues, montant des ventes…

 Trois types de faits:

Additif.

Semi additif.

Non additif.
28
Analyse de l’entrepôt de données
 Table de Fait
 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.
Sommation des comptes: on connaît ce qu’on possède en
banque.

 Non additif: fait non additionnable quelque soit la dimension.

• Prix unitaire: l’addition sur n’importe quelle dimension donne la
même valeur. 29
Analyse de l’entrepôt de données
 Table de Fait

 Table principale du modèle dimensionnel.

Table de faits des ventes

Clés étrangères Clé date (CE)
vers les dimensions
Clé produit (CE)
Clé magasin (CE)
Mesure1: Quantité vendue
Faits
Mesure2: Coût
Mesure3: Montant des ventes

30
Analyse de l’entrepôt de données
 Table de Fait
 Mesures: valeurs numériques des mesures désirées.

 Clés étrangères: clés associées aux dimensions.

 Une table de faits contient un petit nombre de colonnes et plus

d'enregistrements qu'une table de dimension.

 Les informations dans une table de faits sont numériques et

utilisées pour faire des SUM, AVG... et doivent être additives ou
semi additives.
 Les mesures doivent référer et avoir un lien direct avec les clés des
dimensions dans la même table.
31
Analyse de l’entrepôt de données
 Table de Fait
 La granularité répond à 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

Précision des analyses

ti + Finesse

Taille de l’entrepôt
32
Analyse de l’entrepôt de données
 Table de dimension
 Une dimension est une table qui représente un axe d'analyse selon
lequel on veut étudier les faits qui donnent des renseignements
nécessaires à la prise de décision.

 Il s'agit des clients ou des produits d'une entreprise et du temps.

Clé de substitution Dimension produit

(Surrogate Clef) Clé produit (PK)
Code produit
Description du produit
Attributs de la dimension
Famille du produits
Marque
Poids 33
Analyse de l’entrepôt de données
 Table de dimension
 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 moins d’enregistrements qu’une table de faits

Composant 1 : clé de substitution (Surrogate key).

Composante 2 : Atributs.

Composante 3 : Clés spéciales.

34
Analyse de l’entrepôt de données
 Table de dimension
 Exemple:
Surrogate key
(clé de substitution)

Produit
Clé Naturelle Code_Prd
(clé artificielle)
Designation
Description
Prix_uni

Table d'une
BD de production
Table d'une
BD multidimensionnelle 35
Analyse de l’entrepôt de données
 Table de dimension
 Remplacer la clé naturelle en utilisation: ce n'est pas elle qui est
utilisée pour les jointures avec les tables de faits et de dimension.

 Compléter l'information : la clé de substitution est utilisée dans le

DW seulement, la clé artificielle dans la dimension est toujours
nécessaire pour pouvoir faire la correspondance entre la dimension
et la table opérationnelle.

 Historique des changements: pour garder l'historique des

changements de la dimension selon certains critères, on doit gérer
la clé de substitution.
36
Analyse de l’entrepôt de données
 Table de dimension
 En plus de la clé de substitution ou naturelle, d'autres attributs sont
ajoutés à la dimension.

 Ces attributs sont des descripteurs qui représentent l'information

utile sur la dimension, généralement de type caractère.

Clé de substitution

Atributs
(descripteurs )

37
Analyse de l’entrepôt de données
 Table de dimension
 Date effective: la date de création d‘un enregistrement.

 Date retrait : la date de retrait d’un enregistrement.

 Indicateur effectif: 'O' si l'enregistrement est toujours actif (Date

retrait est nulle), 'N' sinon.

Clé de substitution

Atributs (descripteurs )

Clés spéciales
38
Analyse de l’entrepôt de données
 Table de dimension

Dimension Temps
Clé temps (CP)
 Commune à l’ensemble des DW.
Jour
 Reliée à toute table de faits. Mois
Trimestre
Semestre
Année
Num_jour_dans_année
Num_semaine_ds_année

39
Analyse de l’entrepôt de données
 Table de dimension

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

Chacun des membres appartient à un niveau hiérarchique

(niveau de granularité) particulier.

Granularité d’une dimension: nombre de niveaux

hiérarchiques.

Temps:

 Année – Semestre – Trimestre - Mois

40
Modélisation de l’entrepôt de données
 Nouvelle Modélisation

 Modèle en étoile (Star Schema).

 Modèle en flocon de neige (Snowflake Schema).

 Modèle mixte (Mixed Schema).

 Modèle en constellation (Fact constellation Schema).

41
Modélisation de l’entrepôt de données
 Modèle en étoile (Star Schema)
 Le schéma en étoile tire son nom de sa configuration:
• Une table de fait centrale et des dimensions
• Les dimensions n’ont pas de liaison entre elles.

 Avantages:
• Facilité de navigation.
• Nombre de jointures limité.

 Inconvénients:
• Redondances dans les dimensions
• Alimentation complexe.

42
Modélisation de l’entrepôt de données
 Modèle en étoile (Star Schema)

43
Modélisation de l’entrepôt de données
 Modèle en étoile (Star Schema)
Dimension Temps
ID temps
année
mois
jour Dimension produit
… ID produit
Dimension Magasin nom
ID magasin code
description Table de faits Achat
prix
ville ID client
poids
surface ID temps
groupe
… ID magasin
famille
ID région
…
ID produit
Quantité achetée
Dimension Region Montant des achats Dimension Client
ID région ID client
pays nom
description prénom
district vente adresse 44
…. …
Modélisation de l’entrepôt de données
 Modèle en flocon de neige (Snowflack Schema)
 Une table de fait et des dimensions décomposées.

 La table de dimension de niveau hiérarchique le plus bas est reliée

à la table de fait. On dit qu’elle a une granularité la plus fine.
 Modèle floconné = Modèle en étoile + Dimensions normalisées.
 Avantages:
 Normalisation des dimensions.
 Inconvénients:
 Modèle plus complexe (jointure).
 Requêtes moins performantes.

45
Modélisation de l’entrepôt de données
 Modèle en flocon de neige (Snowflack Schema)

46
Modélisation de l’entrepôt de données
 Modèle en flocon de neige (Snowflack Schema)
Dimension produit
Dimension Temps ID produit
ID temps ID groupe
annee nom
mois code
Dimension Magasin jour prix Dimension groupe
ID magasin … poids ID groupe
description … ID famille
ville Table de faits Achat nom
surface ID client …
… ID temps
ID magasin
Dimension Region ID région
Dimension Famille
ID région ID produit
ID famille
ID division vente Quantité achetée
nom
pays Montant des achats
…
description
…. Dimension Client
Dimension ID client
Division vente nom
ID division vente prénom
description adresse 47
…. …
Modélisation de l’entrepôt de données
 Modèle Mixte (Mixed Schema)
 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 plus de redondances.

48
Modélisation de l’entrepôt de données
 Modèle en constellation (Fact constellation Schema)
 Il consiste à fusionner plusieurs modèles en étoile qui peuvent
utiliser des dimensions communes.

 Il comprend donc plusieurs tables de faits et des tables de

dimensions communes ou non à ces tables de faits.

49
Modélisation de l’entrepôt de données
 Modèle en constellation (Fact constellation Schema)

50
Evolution des dimensions
 Dimensions à évolution lente
 Dimensions à évolution lente (SCD: Slowly Changing Dimension)

• Un client peut se marier, avoir des enfants…

• Un produit peut changer de noms ou de formulation:

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

 Gestion de la situation, 3 solutions:

1. Écrasement de l’ancienne valeur.

2. Ajout d’un nouvel enregistrement.

3. Valeur d’origine / valeur courante.

51
Evolution des dimensions
 Dimensions à évolution lente
 Écrasement de l’ancienne valeur :
• Correction des informations erronées.

• Facile à mettre en œuvre.

• Perte de la trace des valeurs antérieures des attributs.

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

Clé produit Description du produit Groupe de produits

12345 IntellitiKids Logiciel

Jeux éducatifs

52
Evolution des dimensions
 Dimensions à évolution lente
 Ajout d’un nouvel enregistrement:
• Utilisation d’une clé de substitution.

• Permet de suivre l’évolution des attributs.

• Permet de segmenter la table de faits en fonction de l’historique.

• Accroit le volume de la table.

Clé produit Description du produit Groupe de produits

12345 IntellitiKids Logiciel

25963 IntellitiKids Jeux éducatifs

53
Evolution des dimensions
 Dimensions à évolution lente
 Ajout d’un nouvel attribut:
• Valeur origine /valeur courante.
• 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.
• Inadapté pour suivre plusieurs valeurs d’attributs intermédiaires

Clé produit Description du Groupe de Nouveau groupe de

produit produits produits
12345 IntellitiKids Logiciel Jeux éducatifs

54
Evolution des dimensions
 Dimensions à évolution rapide

 Dimensions à évolution rapide (RCD: Rapid Changing Dimension) :

• 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 se changent rapidement.

55
Evolution des dimensions
 Dimensions à évolution rapide
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 (1er juillet par
exemple au Canada).

 La dimension Clients devient dans ce cas une dimension à

évolution rapide.

56
Evolution des dimensions
 Dimensions à évolution rapide
Dim client

Faits Clé_client
Dim client
Nom Faits
Clé_client Clé_client
… Prénom Clé_client
Nom
Adresse Clé_démog
Prénom
Date_naissance
Adresse
…
Date_nais
… Dim_démographique
Revenus Clé_démog
Niveau_étude Revenus
Nb_enfants Niveau_étude
Statut_marital Nb_enfants
Profil_financier Statut_marital
Profil_achat Profil_financier
57
Profil_achat
fin
58