Cours Informatique décisionnelle

Chapitre 4: Modélisation d’un Data

warehouse

1
Références 2

• S. Chafki, C. Desrosiers, Cours « Entrepôts de données et intelligence

d’affaires », Ecole de Technologie Supérieur, Université Québec CANADA
• Leila KJIRI, « Cours Data Warehoure », Ecole Ensias RABAT
• EL FAR Mohamed, « Cours Data Warehoure », Faculté des sciences Dhar
El Mahraz
Extract, Transform and Load (ETL) 3
Modélisation relationnelle 4

Diagrammes Entités-Relations (E/R)

• permettent aux concepteurs de représenter visuellement la structure
et le contexte de la base de données

• représentent des:
• Entités (nom, attributs, clé primaire)

• Relations entre les entités (base des jointures utilisées entre les
tables)

• Cardinalités des relations (un à un, un à plusieurs, plusieurs à

plusieurs, zéro à un)
Modélisation relationnelle 5
Modélisation relationnelle 6

Normalisation: ensemble de règles de conception de bases de données

relationnelles. Elle apporte les avantages suivants:
• élimination des doublons d’informations dans les tables
• gestion efficace des modifications apportées aux structures de tables

Les Formes Normales (FN)

• Première Forme Normale (1 FN): les tables sont bidimensionnelles, une
seule valeur par cellule de données
• Deuxième Forme Normale (2 FN): les colonnes (attributs) non-clé doivent
dépendre intégralement de la clé primaire
• Troisième Forme Normale (3 FN): les attributs ne dépendent pas des autres
attributs présents dans cette table, ni dans aucune autre
Modélisation relationnelle 7

Initial 1 FN 2 FN 3 FN

Commande Commande Commande

Achats Clé-BC Clé-BC Clé-BC
Date-BC Date-BC Date-BC
Clé-BC
Clé-Fourn. Clé-Fourn. Clé-Fourn.(CE)
Date-BC
Clé-Fourn. Nom-Fourn. Nom-Fourn.
Nom-Fourn. Fournisseur
Clé-Pièce Clé-Fourn.
QT-Pièce BC-Pièce Nom-Fourn.
BC-Pièce
Desc-Pièce
Clé-BC(CE) BC-Pièce
Clé-BC (CE) Clé-Pièce(CE)
Clé-Pièce Clé-BC(CE)
QT-Pièce
QT-Pièce Clé-Pièce(CE)
Desc-Pièce QT-Pièce
Pièce
Clé-Pièce Pièce
Desc-Pièce Clé-Pièce
Desc-Pièce
Modélisation d’un datawarehouse 8

Les techniques classiques doivent-elles être

• conservées telles quelles?

• adaptées au contexte décisionnel?

• totalement repensées?
Modélisation d’un datawarehouse 9

Adaptation du modèle relationnel

Adaptation 1:
• Extension du formalisme classique de représentation des données E/R
• Modélisation des données agrégées
• Stockage des règles de gestion
• Stockage des règles de calcul
• Gestion des données historiées

• Optimisation des requêtes fréquentes

• Prédéfinition physique d’ensembles de données
Modélisation d’un datawarehouse 10

Adaptation du modèle relationnel

Adaptation 2:
• Dénormalisation du modèle
• Aucune technique formelle de normalisation
• Approche pragmatique: analyse précise des besoins des utilisateurs
• Précalcul de certains agrégats
Résultat adaptation
• Chaque table est associée à un sujet d’intérêt
• Le modèle présente un certain nombre d’informations agrégées
• Modèle moins complexe plus simple que le normalisé
• Nombre de tables diminue mais volume des tables augmente
• Sémantique plus forte mais complétude moins bonne
Modélisation multidimensionnelle 11

Modélisation

• Relationnelle • Multidimensionnelle

• Tables • Dimensions
Différentes formes
• Relations de stockage des • Mesures
données • Cubes
• Jointures
• Hiérarchies
Modèle en étoile 12

• Pour faciliter l'extraction et l'analyse des données, un data warehouse

organise les données en structures physiques aisément exploitables
appelées schémas en étoile.
• Un schéma en étoile se caractérise par une table de faits centrale
entourée de plusieurs tables de dimension:
Une table de faits contient des mesures qui décrivent des
événements propres à l'entreprise. Elle peut également contenir des
données agrégées.
Les pointes de l'étoile représentent les tables dimensionnelles et
servent à décrire les informations liées à un processus d'entreprise
précis et à donner un contexte aux données numériques
Modèle en étoile 13

 Tables de faits
• Correspondent normalement à un seul événement d'affaires
 Ex: achat d’un produit par un client, envoi du produit au client,
commande de matériaux auprès d’un fournisseur, etc.
• Contiennent deux types de colonnes:
 Des métriques associées à l’événement d’affaire: Ex: total des ventes,
nombre d’items commandés, etc.
 Des clés étrangères vers les tables de dimension: Ex: ID du client qui
fait la commande, ID du produit commandé, etc.
• Contiennent typiquement un très grand nombre de lignes:
 Jusqu'à plusieurs millions de lignes;
 Souvent plus de 90% des données du modèle.
Modèle en étoile 14

 Exemple de fait : quantité vendue, chiffre d’affaire, coût, nombre de clients, nombre
d’appels
 Fait additif: quantité vendue, chiffre d’affaire, coût
 Fait semi additif:
• niveau de stock, niveau de solde (valeurs instantanées)
• nombre de transactions de clients (excepté sur la dimension produit)
Exemple : le nombre de clients et la dimension Produit
Soient deux faits (même magasin, même jour)
(Papier essuie tout, 20 clients) et (Mouchoir, 30 clients)
La somme du nombre de clients sur la dimension Produit n’a
pas de signification car un client peut avoir acheté des
mouchoirs et du papier
 Fait non additif: un attribut ratio, marge brute = 1 - Coût/CA
Modèle en étoile 15
Modèle en étoile 16

Composants de la table des faits:

 Mesures
• Une mesure est une colonne numérique, quantitative, de la table de
faits. Les mesures représentent généralement les valeurs analysées.
• Dans l'illustration précédente, les mesures de la table Faits-Ventes sont
Quantité-Ventes (quantités vendues) et Montant-Ventes (montant
ventes). Ces mesures englobent l'ensemble des dimensions.
Modèle en étoile 17

Composants de la table des faits:

 Clés étrangères
• Une clé étrangère est la représentation de la clé principale d'une
dimension dans une table de faits. L'association de ces clés correspond
généralement à l'identificateur unique de chaque enregistrement de la
table de faits.
• Dans l’exemple, les clés étrangères sont représentées par les champs ID-
Client (clé client), ID-Produit (clé produit), Id-Période (clé période), Id-
Employé (clé employé), ID-Transporteur (clé transporteur).
Modèle en étoile 18

Une table de dimension

• décrit des entités d'entreprise,
• contient des attributs qui fournissent un contexte pour les
données numériques.
Dim-Client Dim-Période
ID-Client ID-Période
Nom-Client Date
Prénom-Client Jour
Num-Compte Mois
Adresse1 Année
Ville Semestre
Région Période-Fiscale
Modèle en étoile 19

Une table de dimension

• La conception des tables de dimension vise à ce que les
informations présentées soient exploitables, descriptives et
faciles à explorer, afin que les besoins analytiques de l'utilisateur
de l'entreprise soient satisfaits.
Modèle en étoile 20

Une table de dimension

 Modification dans une dimension
• Changement de description des membres dans les dimensions
• un client peut changer d’adresse, se marier, ...
• un produit peut changer de noms, de formulations
• Choix entre 3 solutions
• écrasement de l’ancienne valeur
• versionnement
• valeur d’origine / valeur courante
Modèle en étoile 21

Une table de dimension

Versionnement
• clé étendue d’un numéro de version
• partitionnement automatique de l’historique
Valeur d’origine / valeur courante
l’ancienne valeur n’est utile que pendant un certain temps pour étudier les
effets d’une transition.
Modèle en étoile 22

Une table de dimension: Hiérarchies

• 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 ) jour ) heure;
 Produit: famille ) catégorie ) marque ) produit;
 Lieu: pays ) région ) province ) ville ) code postal.
• Multiples
Modèle en étoile 23

Une table de dimension

Dimension temporelle :
• Avoir un grain trop fin dans la dimension temporelle (ex: temps du jour)
peut causer l'explosion du nombre de rangées:
 Ex: 31,000,000 secondes différentes dans une année.
• Solution : mettre le temps du jour 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.
Modèle en étoile 24

Clés primaires et étrangères

Table de faits:
• Clé primaire composée, formée d'un sous-ensemble des clés étrangères vers
les tables de dimension: Ex: (idDateTransaction, idClient, idProduit).
• Les clés étrangères ne devraient jamais être nulles: utiliser plutôt une valeur
spéciale dans la table de dimension;
 Ex: une ligne "Aucun spécial" dans la dimension RabaisSpécial si le client
n'a eu droit à aucun rabais lors d'une transaction)
Table de dimension:
• Clé primaire artificielle (surrogate key), pour des raisons de performance.
Modèle en flocon 25

• Il présente des données hiérarchisées;

• Dans chaque dimension, vous pouvez organiser les données en une ou
plusieurs hiérarchies;
• La création de hiérarchies de données permet aux utilisateurs de
visualiser les données sous forme détaillée et résumée;
• Il provient de la normalisation des tables de dimension.
Dim-Produit
Dim-Catégorie
Dim-SousCatégorie
Dim-Produit ID-Catégorie
ID-Produit ID-SousCatégorie Nom-Catégorie
Nom-Produit Nom-SousCatégorie
Prix Responsable
ID-SousCatégorie ID-Catégorie
Modèle en flocon 26

• Variante du modèle en étoile;

• Les tables de dimension sont normalisées;
• Réduction de la redondance mais exécution parfois plus lente des
requêtes (jointure de tables);
• Modèle mixte: seules certaines tables sont normalisées
Modèle en Flocon 27
Modèle en Flocon 28

• 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.
Stratégie d'indexation 29

 Index bitmap (index binaire)

• Populaire dans les produits OLAP
 Microsoft SQL server, Sysbase IQ, Oracle ‰
• Un vecteur de bits pour chaque valeur d’attribut;
• Opération bit à bit pour l’exécution de requêtes
 Comparaison
 Jointure
 Agrégation
 Plus compact que les B+ arbres (compression)
Stratégie d'indexation 30

P‰rincipe de l’index bitmap

• Soit un attribut A, prenant n valeurs possibles [v 1, …,v n] (domaine)
• ‰
Création d’un index bitmap sur l’attribut A: ‰
 On crée n tableaux de bit, un pour chaque valeur vi;
 ‰ Le tableau contient un bit pour chaque tuple t;
 L‰e bit d’un tuple t est à 1 si: t.A = vi, à 0 sinon ;
Stratégie d'indexation 31

Exemple bitmap join index: