Séance4 - Cours SID - Master

Système d’information décisionnel
Master : Big Data & Internet des Objets

Semestre 2
Pr. Abderrahim Danine

Université Hassa II
ENSAM-Casablanca
Printemps 2021
Séance 4
Pr. Abderrahim Danine Master BDIO 2 Cours SID

Note
Ce cours est préparé à l’aide de plusieurs références dans le
domaine, que ce soient des sites Web, page Web, ouvrage de
référence, dictionnaires, livre, notes de cours, présentations des
cours et aussi de mes activités comme enseignant-chercheur dans
le but de présenter un cours aux étudiants plus complet. Toutes
ces références sont citées à la fin du cours, je tiens à remercier
toutes les personnes derrières ces publications sans qui ce cours
n'aurait pu être présenté de cette manière.
Voir références (fin de cours)

Plan de la séance
⚫ Rappels
⚫ Modélisation et conception
– Modélisation dimensionnelle
⚫ Applications : étude des cas

Rappels

Cycle de vie d’un projet de système décisionnel
⚫ Lifecycle approach to DW/BI (Kimball, 2008, p3)
Conception de Sélection et
l’architecture installation des
Croissance
technique produits
Définition
des besoins
d’affaires
Planification Conception et
Modélisation des Conception
de projet / développement Déploiement
données physique
programme du système ETL
Conception des Développement des

application de SID applications de SID Maintenance
Gestion de projet / programme

Conception d'un système décisionnel
⚫ Un projet de système décisionnel se structure selon quatre grands axes :
1. Étude des besoins et de l'existant
• Étude des besoins utilisateurs
• Étude des données existantes
2. Modélisation et conception
• Modélisation dimensionnelle
• Architecture technique
• Spécification des outils d'exploitation
3. Implémentation du data Warehouse
• Implémentation du DW et des DM
• Mise en place de l'ETL
4. Implémentation des outils d'exploitation
• Implémentation des outils de reporting
• Implémentation des outils d'exploration
• Implémentation des outils de prédiction

Cycle de vie d’un projet de système décisionnel
⚫ Diagramme de flux de travail:
Conception de Sélection et
l’architecture installation des
Croissance
technique produits
Définition
Planification des besoins Conception et
Modélisation Conception
de projet / d’affaires des données physique développement Déploiement
programme du système ETL
Conception des Développement

application de BI des applications de Maintenance
BI
Gestion de projet / programme

Processus de conception
1. Choisir le processus d'affaires:
─ Se base sur la matrice en bus de données et le diagramme de priorisation;
─ Doit impliquer les cadres supérieurs.
2. Définir le grain:
─ Question: "à quoi correspond une ligne de la table de faits ?";
─ Dépend des réalités physiques des sources de données.
3. Identifier les dimensions:
─ Découle directement de la définition du grain;
─ Colonnes servant à restreindre l'analyse.
4. Identifier les faits:
─ Colonnes représentant des valeurs numériques de mesure.

Processus d’affaires
⚫ Processus d’affaires (business process / subject area):
─ Ensemble de faits observables (métriques) représentant des activités de l’entreprise
• Exemple: vente, facturation, livraison, commande, etc.
─ Typiquement supportés par un système opérationnel

• Exemple: système de facturation, système CRM, etc.
─ Fournissent des indicateurs clés de performance (key performance indicator - KPI)

• Exemple: profits (vente), taux de rétention (CRM), délai moyen de livraison (livraison), etc.

⚫ Exemples:
Domaine Processus / sujet Faits
• Prix de vente
Ventes • Prix suggéré du
Automobile manufacturier
• Prix des options
• Crédits du concessionnaire
• ...
Maintenance …
• Chambres occupées
• Chambres vacantes
Occupation hôtelière
Tourisme • Vacantes non-disponibles
• Nombre d’occupants
• Recettes
• ...
Vols …

Matrice en bus de données et
le diagramme de priorisation

Matrice en bus de données
⚫ Décrit les dimensions d’analyse requises pour chaque processus d’affaires.
Fournisseur
Processus / dimension
Vendeur
Magasin
Produit
Région
Client
Date
X X X X X X
Vente et Marketing
X X X X X X
Finance et comptabilité
X X X X X
Approvisionnement
X X X
Inventaire
X X X
Ressources Humaines

Diagramme de priorisation des processus
⚫ En entreprise comme dans la vie, on a tout un tas de problèmes.
⚫ Comment reconnaître ceux dont il faut s’occuper ?
 BP1  BP6
impact potentiel
BP4
BP3
 
BP2 BP5
faisabilité
⚫ Permet d’identifier les processus d’affaires faisables ayant le plus grand impact pour
l’entreprise.
Exemple : Adventure Works Cycles
⚫ Tiré de: The Microsoft Data Warehouse Toolkit, 2nd Edition et de
https://flylib.com/books/en/4.65.1.17/1/
⚫ Ventes de produits dans quatre catégories: bicyclettes, pièces, vêtements,
accessoires
⚫ Données de juillet 2005 à juin 2008
TotalSales Column Labels

Row Labels 2006 2007 2008 Grand Total
Accessories 36,815 124,433 1,077,065 1,238,313
Bikes 22,090,618 28,179,554 44,350,354 94,620,526
Clothing 66,328 750,716 1,283,474 2,100,517
Components 1,166,765 4,629,101 6,003,210 11,799,077
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Total ventes par année fiscale et catégorie de produit

United States 15,535,349 20,563,610 25,963,721 62,062,681
United Kingdom 550,507 5,083,062 6,257,260 11,890,829
Canada 3,591,852 2,763,865 5,147,140 11,502,857
Australia 2,568,701 2,099,585 5,805,290 10,473,577
France 414,245 2,021,672 4,714,497 7,150,415
Germany 513,353 593,247 3,574,747 4,681,348
NA 186,518 558,762 1,251,447 1,996,727
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Commandes par pays / région

Internet 7,072,084 5,762,134 16,473,618 29,307,837
Reseller 16,288,442 27,921,671 36,240,485 80,450,597
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Commandes par canal de ventes

⚫ Matrice en bus de données:
Dimensions
Territoire de vente
Client (revendeur)
Client (Internet)
Canal de vente
Raison d’appel
Installation
Promotion
Monnaie
Employé
Produit
Date
Prévision des ventes X X X X X X X
Commandes X X X X X X X X X
Suivi d’appels X X X X X X X
Retours X X X X X X X X
… …

 
 

Questions
⚫ Quel serait le grain, les dimensions et les faits correspondant aux processus d’affaires
suivants d’une entreprise de télécommunications?
1. Facturation clients
2. Gestion du traffic d’appel
3. Inventaire
4. Service à la clientèle

Modélisation dimensionnelle

Questions
⚫ À quoi correspond la modélisation dimensionnelle?

⚫ Quels sont les avantages du modèle dimensionnel par rapport au modèle ER?

Modèle dimensionnel vs ER
⚫ Modèle entité-relation (ER):
─ Représente les données sous la forme d'entités (tables) et de relations (références ou tables);
─ Normalisation du schéma (ex: 3FN).
⚫ Modèle dimensionnel:
─ Représenteles donnéescomme des faits et des dimensions;
─ Les dimensionsne sont pas normalisées.
⚫ Avantages du modèle dimensionnel:
─ Compréhensibilité:
⚫ Les données sont regroupées selon des catégories d'affaires qui ont un sens pour les utilisateurs d'affaires;
─ Performance:
⚫ La dénormalisation évite les jointures coûteuses;
⚫ Autres optimisations (ex: index de jointure en étoile).

La modélisation dimensionnelle
⚫ Définition:
─ Technique de conception logique permettant de structurer les données de manière à les
rendre intuitives aux utilisateurs d'affaires et offrir une bonne performance aux requêtes.
⚫ Caractéristiques:
─ Divise les données en faits et dimensions;
─ Les faits (mesures) sont généralement des valeurs numériques provenant des processus
d'affaires;
─ Les dimensions fournissent le contexte (qui, quoi, quand, où, pourquoi et comment) des faits;
─ Schéma en étoile: une table de faits entourée de plusieurs tables de dimension (normalement
entre 8 et 15).

Tables de faits
Tables de faits
Tables de dimension Commande Tables de dimension
DateCommande idDateCommande (FK)
idDateEnvoiDemandée (FK) DateEnvoiDemandée
Produit idProduit (FK)
idClientVenduÀ (FK) ClientVenduÀ
ClientExpediéÀ idClientExpediéÀ (FK)
idClientChargéÀ (FK) ClientChargéÀ
ReprésentantVente idReprésentantVente (FK)
idTypeCommande (FK) TypeCommande
TypeEnvoi idTypeEnvoi (FK)
noCommande (DD)
noLigneCommande (DD)
quantitéCommandée
totalBrut mesures
totalNet

Tables de faits
⚫ Correspondent normalement à un seul processus d'affaires:
─ 1 table de faits = 1 processus.
⚫ Stockent des mesures générées par les événements du processus;

─ Ex: réception d'une commande, envoi d'une commande, etc.
─ Les faits "prennent leur valeur" au moment où l'évènement d'affaires survient (aspect temporel
important).
⚫ Contiennent typiquement un très grand nombre de lignes:

─ Jusqu'à plusieursmilliards de lignes;
─ Souvent plus de 90% des données du modèle.

Tables de faits
⚫ Comprennent deux types de colonnes:
─ Clés étrangères vers des tables de dimension;
─ Valeurs numériques souvent additives (mesures).
⚫ Modélisent des relations de type plusieurs-à-plusieurs (table de jointure en relationnel)

Tables de faits
⚫ Exemple: Commande
idDateCommande (FK)
idDateEnvoiDemandée (FK)
idProduit (FK)
idClientVenduÀ (FK)
idClientExpediéÀ (FK) Clés étrangères
idClientChargéÀ (FK)
idReprésentantVente (FK)
idTypeCommande (FK)
idTypeEnvoi (FK)
noCommande (DD)
noLigneCommande (DD) ???
quantitéCommandée
totalBrut mesures
totalNet

Question
⚫ Une mesure doit-elle toujours être une valeur numérique?

⚫ Une mesure peut-elle toujours être additionnée sur plusieurs lignes?

Types de mesure
⚫ Mesures additives:
– Peuvent être agrégées selon n'importe quelle dimension;
– Exemple: montant de vente, quantité commandée, etc.
⚫ Mesures semi-additives:
– Peuvent être agrégées selon certaines dimensions seulement;
– Exemple: solde de compte agrégeable selon les clients, pas le temps.
⚫ Mesures non-additives:
– Valeurs numériques ne pouvant être agrégées selon aucune dimension;
– Exemple: pourcentages ou ratios.

Question
⚫ Mesure additive, semi-additive ou non-additive ?
1. Quantité en inventaire
2. Pourcentage de profit : 100*(vente – coût) / vente
3. Nombre d’items vendus
4. Produit en vente (valeur binaire)

Question
⚫ Comment peut-on différencier une mesure d’un attribut de dimension?

1. Coût unitaire du produit (provient du fournisseur)
2. Dimensions du produit
3. Prix de vente du produit
4. Produit en vente (valeur binaire)

Mesures versus attributs de dimension
⚫ Mesures:
─ Dépendent d'un événement d'affaires;
─ Ont souvent des valeurs continues (ou un grand nombre de valeurs discrètes possibles);
─ Servent dans le calcul d’indicateurs de performance;
─ Exemple: montant total et quantité d'une commande.
⚫ Attributs (numériques) de dimension:
─ Indépendants des événements d'affaires;
─ Ont souvent des valeurs discrètes;
─ Servent à filtrer ou étiqueter les faits;
─ Exemple: jour et heure d'une transaction, âge d'un client, etc.

Clés d’une table de faits
⚫ Clés primaires:
─ La clé primaire est typiquement une clé composée, formée d'un sous-ensemble des clés
étrangères vers les tables de dimension:
⚫ Exemple: (idDateTransaction, idClient, idProduit).
⚫ Clés étrangères:
─ Les clés étrangères ne devraient jamais être nulles
⚫ Sinon on peut violer le principe d'intégrité référentielle;
⚫ Utiliser plutôt une valeur spéciale dans la table de dimension;
⚫ Exemple: une ligne "Aucun spécial" dans la dimension RabaisSpécial si le client n'a eu droit
à aucun rabais lors d'une transaction)

Grain d’une table de faits
⚫ Le grain est la définition de l'événement d'affaires produisant les lignes de la table de
faits;
⚫ Toutes les lignes de la table doivent avoir le même grain;
⚫ Doit être le plus fin possible (atomique) pour le processus d'affaires:

─ Permet de faire des requêtes plus précises et imprévues;
─ Déterminé par les réalités physiques des sources de données.
⚫ Détermine les dimensions du modèle.

Questions
⚫ Que renferme une table de dimension?

⚫ À quoi servent les attributs d’une dimension?

Tables de dimension
⚫ Ensemble hautement corrélé d'attributs (jusqu'à plusieurs dizaines) regroupés selon les
objets clés d'une entreprise:
─ Exemple: produits, clients, employés, installations, etc.
⚫ Propriétés des attributs:
─ Descriptif (ex: chaînes de caractères);
─ De qualité (ex: aucune valeur manquante, obsolète, erronée, etc.);

─ Principalement des valeurs discrètes (ex: jour, âge d'un client);
⚫ Rôles des attributs:
─ Filtrer / restreindre les requêtes (ex: ville, catégorie produit, etc.);
─ Étiqueter les résultats (ex: champs descripteurs).

⚫ La puissance analytique de l'entrepôt est proportionnelle à la richesse et la qualité des
attributs dimensionnels

Hiérarchies dimensionnelles
⚫ Un ensemble d'attributs ayant une relation hiérarchique (x est inclus dans y);
⚫ Définissent les chemins d'accès dans les données (drill-down paths);

⚫ Simples:
─ Temps: année ) mois ) semaine ) jour ) heure;
─ Produit: famille ) catégorie ) marque ) produit;
─ Lieu: pays ) province ) région ) ville ) code postal.
⚫ Multiples:
1 * 1 * 1
année trimestre mois
*
jour
1 * 1 * 1 *
année fiscale trimestre fiscal mois fiscal
⚫ Normalement dans une seule table de dimension.

Questions
⚫ Hiérarchie pour les dimensions suivantes?

1. Client
2. Vendeur
3. Canal de vente

Choix des dimensions
⚫ Demande le jugement et l'intuition du modélisateur;
⚫ Plus on a d'attributs non-corrélés dans une dimension plus la table correspondante aura
de lignes (explosion combinatoire):
─ Exemple: 10,000 produits x 100 magasins = 1,000,000 de lignes dans une table de
dimension ProduitMagasin.
⚫ Règles:
─ Les dimensions sont observables au niveau du grain de la table de faits (font partie
de l’évènement d’affaires);
─ Les attributs non-corrélés vont dans des dimensions séparées.

Question
⚫ Vente: doit on mettre Région comme un attribut de Client ou une dimension séparée ?
⚫ Enseignement: doit on mettre Département, Professeur et Cours dans une même dimension ?

Clés d'une table de dimension
⚫ Clé primaire:
─ La clé primaire devrait toujours être une clé artificielle composée d'une seule colonne
(surrogate key);
─ Exemple: mécanisme de séquence dans Oracle;
─ Avantages:
⚫ Performance:accès par index et jointures accélérés;
⚫ Robustesse: ne change jamais contrairement à une clé naturelle;
⚫ Cohérence: permet d'identifierla même entité dans deux tables même si les tables ont des
colonnesdifférentes.

Question
⚫ Qu’est-ce qu’une dimension conforme?

⚫ À quoi servent ces dimensions?

Dimensions conformes
⚫ Également appelées master dimensions ou common reference dimensions;
⚫ Dimensions potentiellement partagées par des tables de faits modélisant des processus
d'affaires différents;
⚫ Avantages:
– Cohérence: les différentes tables de faits sont filtrées et étiquetés de manière de cohérente;
– Intégration: permet à l'entrepôt de données d'opérer comme un seul bloc uni;
– Productivité: favorise l'extension de l'entrepôt d'une itération de développement à l'autre.

Question
⚫ Deux tables de faits peuvent-elles être reliées par une dimension

conforme si elles n’ont pas le même grain?

Dimensions conformes
⚫ Des dimensions peuvent être conformes si les attributs d'une table de dimension
sont un sous-ensemble des attributs d'une autre table;
⚫ Exemple: dimensions représentant des niveaux de granularité différents
Dimension: Produit
Dimension: Marque
idProduit (PK)
idMarque(PK)
descriptionProduit
Faits: Vente descriptionMarque
NuméroSKU
descriptionSousCatégorie
idMarque
descriptionCatégorie
descriptionMarque
descriptionSousCatégorie
descriptionCatégorie
couleur Faits : PrédictionVentes
taille

Dimension temporelle
⚫ Centrale, car la plupart des faits correspondent à des événements d'affaires de l'entreprise;
Dimension: Date
idDate (PK)
date
jourDeSemaine
jourDuMois
jourDeAnnée
jourDansMoisFiscal
jourDansAnnéeFiscale
congéFérié
jourDeTravail
semaineDuMois
...
⚫ Mettre toutes ces valeurs même si la plupart peuvent être déduites des autres.
Question
⚫ Y a-t-il un problème à définir la dimension suivante ?
Dimension: Date
idDate (PK)
date
jour
mois
semaine
année
heure
minute
seconde
...

Dimension temporelle
⚫ Avoir un grain trop fin dans la dimension temporelle (ex: temps du jour) peut causer l'explosion
du nombre de rangées:
─ Exemple: 31,000,000 secondes différentes dans une année.
⚫ Solution 1: mettre le temps du jour (time of day) dans une dimension séparée:
─ Dimension 1: année ) mois ) semaine ) jour;
─ Dimension 2: heure ) minute ) secondes;
─ 86,400 + 365 lignes VS 31,000,000 lignes.
⚫ Solution 2: mettre le temps du jour comme un fait et garder le jour, mois, année dans une
dimension;
⚫ La solution 2 est normalement préférable à moins d’avoir des attributs supplémentaires (ex:
descripteur texte).

Question
⚫ À quoi servent ces colonnes?
⚫ Sont elles nécessaires dans la table de faits?
Commande
idDateCommande (FK)
...
noCommande (DD)
???
noLigneCommande (DD)
quantitéCommandée
...

Dimensions dégénérées
⚫ Clés de la table de faits n'ayant aucun attribut autre qu'elles-mêmes;
⚫ Correspondent souvent à des identifiants dans les systèmes sources:

─ Exemple: no de commande, no de billet, etc.
⚫ Il faut toujours laisser ces colonnes dans la table de faits:

─ Elles sont la colle qui "tient ensemble" les items d'une ligne de la table de faits;
─ Permettent de répondre à des questions plus générales comme "quel est le nombre
moyen de lignes correspondant à un même commande ?";
─ Permettent également de retracer la provenance d'une ligne à une source de données.

Question
⚫ Que fait-on si un attribut dimensionnel change?
1. Adresse du client
2. Description du produit
3. Catégorie du produit
4. Status d’un client

Dimensions à évolution lente
⚫ Slowly Changing Dimensions (SCD);
⚫ Même si elles sont plus statiques que les faits, les dimensions peuvent également
changer:
─ Exemple: adresse/status d'un client, catégorie d'un produit, etc.
⚫ Plusieurs stratégies d'historisation:
─ SCD Type 1: Écraser l'ancienne valeur avec la nouvelle;
─ SCD Type 2: Ajouter une ligne dans la table de dimension pour la nouvelle valeur;
─ SCD Type 3: Avoirdeux colonnesdans la table de dimension correspondant à l'ancienne et la

nouvelle valeur.
─ Hybride: On combine les Types 2 et 3.

Question
⚫ Quels sont les avantages / limitationsdes stratégies d’historisation

SCD1, SCD2 et SCD3 ?

⚫ SCD Type 1:
idProduit description code département
1001 'BébéLala' 'ABC999-Z' 'Éducation'
idProduit description code département
1001 'BébéLala' 'ABC999-Z' 'Stratégie'
─ Impossible de faire des analyses sur l'ancienne valeur;

─ À utiliser seulement pour faire des corrections ou lorsque l'ancienne valeur n'est pas significative
pour les besoins d'affaires;
─ Exige de mettre à jour les données agrégées avec l'ancienne valeur.
⚫ SCD Type 2:
idProduit description code département dateEffective dateExpirée
1001 'BébéLala' 'ABC999-Z' 'Éducation' '2007-10-08' '9999-12-31'
idProduit description code département dateEffective dateExpirée
1001 'BébéLala' 'ABC999-Z' 'Éducation' '2007-10-08' '2008-10-31'
1002 'BébéLala' 'ABC999-Z' 'Stratégie' '2008-11-01' '9999-12-31'
─ L'approche la plus employée;

─ Permet de faire des analyses historiques;
─ Demande l'ajout d'une nouvelle ligne par changement;
─ À utiliser lorsque l'ancienne valeur a une signification analytique ou si le changement est une
information en soi.
⚫ SCD Type 3:
idProduit description code oldDépartement newDépartement dateModif
1001 'BébéLala' 'ABC999-Z' 'Éducation' 'Éducation' '9999-12-31'
idProduit description code oldDépartement newDépartement dateModif
1001 'BébéLala' 'ABC999-Z' 'Éducation' 'Stratégie' '2008-11-01'
─ Moins employé;
─ Profondeur de l'historique est d'un seul changement;
─ À utiliser lorsqu'on veut vouloir comparer les faits avec l'ancienne ou la nouvelle valeur;
─ Peut rajouter d'autres colonnes pour avoir une plus grande profondeur.
Question
⚫ Sachant que le profil d’un client change souvent (âge, salaire, emploi, situation familiale,
etc.), que peut-on faire pour éviter le plus possible la mise à jour de la table Client ?
⚫ Mettre dans la table de faits ?

Mini-dimensions
⚫ Sert lorsque qu'une dimension renferme des attributs qui peuvent changer souvent et
sont souvent analysés ensemble:
─ Exemple: le profil démographique des clients (âge, revenu, etc.).
⚫ Solution: mettre les attributs potentiellement volatiles dans une dimension séparée (mini-
dimension) où le grain est différent;
Dimension: Client Dim: GroupeDémographique
idClient (PK) idGroupeDémographique(PK)
nom groupeAge
adresse sexe mini-dimension
dateDeNaissance groupeSalaire
sexe groupeNombreEnfants
... étatCivil

Dimensions à rôles multiples (role playing)
⚫ Dimensions ayant des rôles logiques différents dans une même table de faits;
⚫ Typiquement la dimension temporelle:
─ Exemple: dateCommande, dateEnvoiDemandé, dateEnvoiRéel, etc.
⚫ Une seule table physique référencée par plusieurs tables logiques (ex: à l'aide de
vues ou d'alias);
─ Exemple: CREATE VIEW DateEnvoiRéel AS SELECT * FROM Date.

Question
⚫ Que doit-on faire avec les attributs qui ne correspondent à aucune dimension (ex: flags
divers) ?
1. Les ignorer?
2. Les mettre dans la table de faits?
3. Les mettre dans une dimension séparée (ne contenant que l’attribut correspondant)?
4. Autre solution?

Dimensions poubelles (junk dimensions)
⚫ Proviennent des attributs ne correspondant à aucune dimension:
─ Exemple: descripteurs texte ou flags divers.
⚫ À éviter:
─ Les laisser dans la table de faits:
⚫ La table de faits peut exploser en taille;
─ Mettre chacun dans une dimension séparée:
⚫ Explosion du nombre de dimensionset clés étrangères;
─ Les éliminer:
⚫ Peuvent avoir une signification analytique.
⚫ Solution:
─ Créer une seule table regroupant tous ces attributs orphelins (junk dimension).

Tables sans fait (factless tables)
⚫ Correspondent aux événements d'affaires représentant une relation plusieurs-à-
plusieurs,mais qui n'ont pas de mesures quantifiables:
─ Exemple: la présence d’un étudiant en classe (vrai ou faux).
⚫ On peut imaginer la mesure d'une telle table comme une colonne fictive dont la valeur est
toujours à 1;
⚫ Exemple:
PrésenceEnClasse
idDate (FK)
idÉtudiant (FK)
idProfesseur (FK)
idCours (FK)
colonneFicitive = 1

Question
⚫ Que faire lorsqu’une transaction s’étale sur plusieurs lignes (ex: une ligne par produit)?
⚫ Comment peut-on éviter de répéter les mêmes informations pour chaque ligne de
la transaction?

Table de pont (bridge table)
⚫ Sert notamment à modéliser les dimensions multi-valuées;
⚫ Exemple: factures médicales pouvant avoir plusieurs diagnostics
Faits : FacturesMédicales
Dim: Diagnostic
idDateTraitement (FK) Bridge: GroupeDiagnostic
Dim: GroupeDiagnostic idDiagnostic (PK)
idPatient (FK) idGroupeDiagnostic (PK,FK)
idGroupeDiagnostic description
... idDiagnostic (PK,FK)
(PK) catégorie
idGroupeDiagnostic (FK) facteurPondération
type
montantTotal
⚫ La table GroupeDiagnostic peut être pré-générée (si peu de combinaisons possibles)

ou populée au fur et à mesure.
⚫ facteurPondération représente la contribution relative d’un diagnostic dans le groupe

Schéma en flocon
⚫ Provient de la normalisation des tables de dimension;
⚫ Exemple:

Question
⚫ Quels sont les avantages / inconvénients du schéma en flocon par rapport au schéma
en étoile?

Schéma en flocon
⚫ Avantages:
─ Petite économie d'espace;
─ Plus facile de mettre à jour les dimensions en cas de changement.

⚫ Désavantages:
─ Schéma moins intuitif aux utilisateurs d'affaires;
─ Dégradation de la performance à cause des jointures additionnelles.

⚫ En général, on préfère ne pas normaliser les tables de dimension.

Exemple de modélisation
⚫ Cas d'étude en télécommunications : Tiré du livre The Data Warehouse Toolkit 2ème édition
─ Matrice en bus de données:
Représentant
Appel service
d'utilisatio
Ligne tél.
de vente
Employé
Canal de
Produit
Client
vente
Processus /
Date
Relai
Plan
Dimension
n
Facturation client X X X X X X
Gestion du trafic X X X X X X X
d'appels
Inventaire X X X
Service à la clientèle X X X X X X X
...

⚫ Choix du processus d'affaires:
Facturation Trafic d'appels
Évènement d'affaires: Envoi de facture une fois par Appel fait par un client
mois
Potentiel analytique: Bon Excellent
Complexité: Moyenne Grande
─ La gestion du trafic d'appels permet des analyses très détaillées (niveau appel), mais comporte
une plus grande complexité technologique (ETL, stockage, etc.);
─ Processus retenu: Facturation client.

Dim : Client Dim : Facture
Faits : Facturation
⚫ Modèle préliminaire:
noClient (PK naturelle)

noFacture (FK) noFacture (PK naturelle)
nomClient
noClient (FK) dateFacturation
ville
noVendeur (FK) noLigne (FK)
province
codePlan (FK)
codePostal Dim : LigneTél
datePremierService nbAppels
noLigne (PK naturelle)
... totalMinutes
codeRégional
minutesLongueDistance
Dim: ReprésentantVente dateActivation
minutesSoir
noVendeur (PK naturelle) minutesWeekend
Dim : PlanUtilisation
nomVendeur fraisService
idDépartement (FK) fraisServiceCumulatifs codePlan(PK naturelle)
fraisLongueDistance abbréviationPlan
Dim: Département taxes minutesSemaine
idDépartement (PK) minutesSoir

total minutesWeekend
directeur
...
...
⚫ Problèmes avec le modèle préliminaire:
1. Granularité:
⚫ Le grain le plus fin correspond réellement à la facturation d'une ligne d'un client;
⚫ Solution:
─ Mettre la clé de la dimension Ligne dans la table de faits.
2. Clés primaires des dimensions:

⚫ Les clés primaires des dimensions doivent être artificielles (surrogate keys);
⚫ Solution:
─ Remplacer les clés primaires par des clés artificielles;
─ Lorsque nécessaire, mettre les clés naturelles dans la table de faits comme dimensions dégénérées
(DD).

3. Dimension temporelle:
⚫ La date de facturation est modélisée comme un attribut de Facture au lieu d'être une dimension
conforme;
⚫ Solution:
– Créer une dimension à rôles multiples DateFacturation, basée sur la dimension conforme de Date.
4. Dimensions normalisées:
⚫ La hiérarchie ReprésentantVente – Département est normalisée, causant des jointures inutiles;
⚫ Solution:
– Mettre les attributs de Département directement dans ReprésentantVente (i.e., dénormaliser).

5. Attributs non-descriptifs:
⚫ Certaines dimensions ont des attributs peu informatifs (exemple: abbréviationPlan);
⚫ Solution:
– Rajouter des attributs descriptifs pour rendre les données plus compréhensibles aux utilisateurs
d'affaires.
6. Faits non-additifs:
⚫ Le fait fraisServiceCumulatifs n'est pas additif;
⚫ Solution:
– Retirer cette colonne de la table de fait et calculer les valeurs cumulatives sur demande.

Exemple de modélisation Nouveau modèle:
Dim : DateFacturation
Faits : Facturation
Dim : Client idDateFacture (FK) idDateFacture (PK)
idClient (PK) dateFacture
idLigne (FK) mois
noClient
nomClient idClient (FK) année
ville ...
province idVendeur (FK)
codePostal idPlan (FK)
datePremierService Dim : LigneTél
... noFacture (DD) idLigne (PK)
nbAppels noLigne
totalMinutes codeRégional
dateActivation
minutesLongueDistance Dim : PlanUtilisation
Dim: ReprésentantVente minutesSoir idPlan (PK)

minutesWeekend codePlan
idVendeur (PK)
abbréviationPlan
noVendeur fraisService descriptionPlan
nomVendeur
fraisLongueDistance minutesSemaine
idDépartement
minutesSoir
nomDépartement
taxes minutesWeekend
directeurDépartement
...
Pr. Abderrahim Danine total Master BDIO 74 Cours SID

Séance4 - Cours SID - Master

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Séance4 - Cours SID - Master

Transféré par

Droits d'auteur :

Formats disponibles

Système d’information décisionnel

Master : Big Data & Internet des Objets

Pr. Abderrahim Danine

Pr. Abderrahim Danine Master BDIO 2 Cours SID

Pr. Abderrahim Danine Master BDIO 3 Cours SID

Pr. Abderrahim Danine Master BDIO 4 Cours SID

Pr. Abderrahim Danine Master BDIO 5 Cours SID

Conception des Développement des

Gestion de projet / programme

Pr. Abderrahim Danine Master BDIO 6 Cours SID

Pr. Abderrahim Danine Master BDIO 7 Cours SID

Conception des Développement

Gestion de projet / programme

Pr. Abderrahim Danine Master BDIO 8 Cours SID

Pr. Abderrahim Danine Master BDIO 9 Cours SID

─ Typiquement supportés par un système opérationnel

─ Fournissent des indicateurs clés de performance (key performance indicator - KPI)

Pr. Abderrahim Danine Master BDIO 10 Cours SID

Pr. Abderrahim Danine Master BDIO 11 Cours SID

Pr. Abderrahim Danine Master BDIO 12 Cours SID

Pr. Abderrahim Danine Master BDIO 13 Cours SID

TotalSales Column Labels

Total ventes par année fiscale et catégorie de produit

Commandes par pays / région

Commandes par canal de ventes

Prévision des ventes X X X X X X X

Pr. Abderrahim Danine Master BDIO 17 Cours SID

Pr. Abderrahim Danine Master BDIO 18 Cours SID

Pr. Abderrahim Danine Master BDIO 19 Cours SID

Pr. Abderrahim Danine Master BDIO 20 Cours SID

⚫ À quoi correspond la modélisation dimensionnelle?

Pr. Abderrahim Danine Master BDIO 21 Cours SID

Pr. Abderrahim Danine Master BDIO 22 Cours SID

Pr. Abderrahim Danine Master BDIO 23 Cours SID

Pr. Abderrahim Danine Master BDIO 24 Cours SID

⚫ Stockent des mesures générées par les événements du processus;

⚫ Contiennent typiquement un très grand nombre de lignes:

Pr. Abderrahim Danine Master BDIO 25 Cours SID

⚫ Modélisent des relations de type plusieurs-à-plusieurs (table de jointure en relationnel)

Pr. Abderrahim Danine Master BDIO 26 Cours SID

Pr. Abderrahim Danine Master BDIO 27 Cours SID

⚫ Une mesure doit-elle toujours être une valeur numérique?

Pr. Abderrahim Danine Master BDIO 28 Cours SID

Pr. Abderrahim Danine Master BDIO 29 Cours SID

Pr. Abderrahim Danine Master BDIO 30 Cours SID

⚫ Comment peut-on différencier une mesure d’un attribut de dimension?

Pr. Abderrahim Danine Master BDIO 31 Cours SID

Pr. Abderrahim Danine Master BDIO 32 Cours SID

Pr. Abderrahim Danine Master BDIO 33 Cours SID

⚫ Doit être le plus fin possible (atomique) pour le processus d'affaires:

Pr. Abderrahim Danine Master BDIO 34 Cours SID

⚫ Que renferme une table de dimension?

Pr. Abderrahim Danine Master BDIO 35 Cours SID

─ De qualité (ex: aucune valeur manquante, obsolète, erronée, etc.);

─ Étiqueter les résultats (ex: champs descripteurs).

Pr. Abderrahim Danine Master BDIO 36 Cours SID

⚫ Définissent les chemins d'accès dans les données (drill-down paths);

⚫ Normalement dans une seule table de dimension.

Pr. Abderrahim Danine Master BDIO 37 Cours SID

⚫ Hiérarchie pour les dimensions suivantes?

Pr. Abderrahim Danine Master BDIO 38 Cours SID

Pr. Abderrahim Danine Master BDIO 39 Cours SID

Pr. Abderrahim Danine Master BDIO 40 Cours SID