Projt BI

MTI820 −
Entrepôts de données et intelligence d’affaires
Modélisation dimensionnelle
Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 1

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

application de des applications Maintenance
BI de 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.

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

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ésente les données comme des faits et des dimensions;
– Les dimensions ne 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
utilisateur 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).

Exemple de schéma en étoile (manufacturier)
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'à plusieurs milliards 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)
???
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;
– Ex: montant de vente, quantité commandée, etc.
• Mesures semi-additives:
– Peuvent être agrégées selon certaines dimensions
seulement;
– Ex: 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;
– Ex: 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;
– Ex: 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;
– Ex: 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:
• Ex: (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;
• Ex: 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:
– Ex: 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):
– Ex: 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);
– Ex: 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'identifier la même entité dans deux
tables même si les tables ont des colonnes diffé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;
• Ex: 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
Faits : PrédictionVentes
couleur
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:
– Ex: 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)
???
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:
– Ex: 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:
– Ex: 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: Avoir deux colonnes dans la table de dimension
correspondant à l'ancienne et la nouvelle valeur.
– Hybride: On combine les Types 2 et 3.

Question
• Quels sont les avantages / limitations des 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:
– Ex: 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:
– Ex: 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);
– Ex: 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:
– Ex: 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 dimensions et 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:
– Ex: 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;
• Ex: 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*
– Matrice en bus de données:
Représentant
Appel service
d'utilisation
Canal de
Ligne tél.
de vente
Employé
Produit
Client
vente
Processus /
Date
Relai
Plan
Dimension
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
...
*: Tiré du livre The Data Warehouse Toolkit 2ème édition

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

• Modèle préliminaire:
Dim : Client
noClient (PK naturelle) Faits : Facturation Dim : Facture
nomClient noFacture (FK) noFacture (PK naturelle)
ville noClient (FK) dateFacturation
province noVendeur (FK) noLigne (FK)
codePostal codePlan (FK)
datePremierService nbAppels Dim : LigneTél
... totalMinutes noLigne (PK naturelle)
minutesLongueDistance codeRégional
Dim: ReprésentantVente dateActivation
minutesSoir
noVendeur (PK naturelle)
minutesWeekend
nomVendeur Dim : PlanUtilisation
fraisService
idDépartement (FK) codePlan(PK naturelle)
fraisServiceCumulatifs
abbréviationPlan
Dim: Département fraisLongueDistance
minutesSemaine
idDépartement (PK) taxes
minutesSoir
directeur total
minutesWeekend
...
...
• 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 (ex:
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.

• Nouveau modèle: Dim : DateFacturation
idDateFacture (PK)
Faits : Facturation
Dim : Client dateFacture
idDateFacture (FK)
idClient (PK) mois
idLigne (FK)
noClient année
idClient (FK)
nomClient ...
idVendeur (FK)
ville
idPlan (FK) Dim : LigneTél
province
noFacture (DD) idLigne (PK)
codePostal
nbAppels noLigne
datePremierService
totalMinutes codeRégional
... Dim : PlanUtilisation
minutesLongueDistance dateActivation
idPlan (PK)
Dim: ReprésentantVente minutesSoir
codePlan
idVendeur (PK) minutesWeekend
abbréviationPlan
noVendeur fraisService
descriptionPlan
nomVendeur fraisLongueDistance
minutesSemaine
idDépartement taxes
minutesSoir
nomDépartement total
minutesWeekend
directeurDépartement
...

Projt BI

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Projt BI

Загружено:

Авторское право:

Доступные форматы

MTI820 −

Entrepôts de données et intelligence d’affaires

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 1

Conception des Développement

Gestion de projet / programme

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 2

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 3

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 4

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 5

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 7

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 8

• Stockent des mesures générées par les événements du

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

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 9

• Modélisent des relations de type plusieurs-à-plusieurs

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 10

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 11

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 12

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 13

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 14

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 15

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 16

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 17

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 18

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 19

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 20

• Normalement dans une seule table de dimension.

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 22

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 23

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 24

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 25

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 26

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 27

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 28

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 29

• Mettre toutes ces valeurs même si la plupart peuvent

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 31

• Solution 1: mettre le temps du jour (time of day) dans une

• Solution 2: mettre le temps du jour comme un fait et garder le

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 32

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 33

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 34

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 35

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 36

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 37

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;

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 38

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;

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'

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 40

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 41

Dimension: Client Dim: GroupeDémographique

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 42

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 43