Data Warehouse Course Notes

Caractéristiques des Dimensions

Clé de la Table de Dimension

La clé primaire d'une table de dimension dans un entrepôt de données identifie de manière unique chaque enregistrement et est cruciale pour la liaison à la table de faits.

Types de Clés:

• Clé Naturelle: Existe dans les données opérationnelles (ex: code produit, numéro de client).

  • Problème: Sujet aux changements dans le système source en raison de:

    • Problèmes d'intégrité des données.

    • Changements dans les politiques de gestion des identifiants.

    • Corrections d'erreurs.

    • Fusions ou acquisitions.

    • Migrations ou mises à jour du système.

    • Réutilisation des identifiants.

• Clé Artificielle (Clé de Substitution): Spécifiquement générée pour la table de dimension (souvent un entier auto-incrémenté).

  • Avantages:

    • Utilisée comme clé primaire (PK) dans la table de dimension.

    • La clé naturelle est conservée uniquement pour référence.

    • Ne change pas même si la clé naturelle change dans la source.

    • Assure la stabilité et gère l'évolution des données.

Exemple:

CREATE TABLE Dimension_Produit (
    Produit_ID INT PRIMARY KEY AUTO_INCREMENT, -- Clé artificielle (PK)
    Code_Produit VARCHAR(20) UNIQUE, -- Clé naturelle (mais pas PK)
    Nom_Produit VARCHAR(100),
    Catégorie VARCHAR(50),
    Marque VARCHAR(50)
);

L'exemple de table inclut Produit_ID comme clé artificielle primaire et Code_Produit comme clé naturelle.

Types de Dimensions

Il existe plusieurs types de dimensions:

• Dimensions Conformées

• Dimensions Dégénérées

• Dimensions Poubelle

• Dimensions de Rôle

• Dimensions Hiérarchiques

• Dimensions Causales

• Dimensions Temporelles

Dimensions Conformées

Une dimension partagée entre plusieurs tables de faits, assurant la cohérence des analyses à travers différents ensembles de données.

Exemples:

• Une dimension Temps (Année, Mois, Jour, Trimestre) utilisée à la fois pour les ventes et les achats.

• Une dimension Client partagée entre les cubes de ventes et de service après-vente.

Dimensions Dégénérées

Dimensions sans table dédiée, stockées directement dans la table de faits, souvent comme un identifiant de transaction unique.

• Le numéro de commande dans une table de faits de ventes est une dimension dégénérée, identifiant une transaction sans avoir besoin d'une table de dimension séparée.

Exemple:

Le numéro de commande dans une table de faits de ventes.

Dimensions Poubelle

Dimensions regroupant plusieurs attributs indépendants sans relations fortes, empêchant une explosion de colonnes dans la table de faits.

Exemple:

Une table de faits de ventes avec des attributs de méthode de paiement (carte, espèces, PayPal) et de statut de livraison (en attente, expédié, livré, annulé).

Dimensions de Rôle

La même dimension utilisée pour plusieurs rôles dans un cube de données.

Exemple:

Une dimension Temps utilisée pour la date de commande, la date de livraison et la date de paiement dans une table de faits de commande. Au lieu de créer plusieurs tables de dimension Temps, la même table est utilisée avec différents alias en fonction du contexte.

Dimensions Hiérarchiques

Dimensions contenant plusieurs niveaux d'agrégation pour analyser les données à différentes granularités.

Exemples:

• Dimension Géographique: Pays → Région → Ville → Magasin

• Dimension Produit: Catégorie → Sous-catégorie → Produit

Ces hiérarchies permettent des analyses multi-niveaux (ex: ventes par pays, puis par région, puis par ville).

Dimensions Causales

Dimensions qui expliquent la cause ou le facteur influençant un fait, permettant l'analyse de pourquoi un fait s'est produit, et pas seulement les conditions dans lesquelles il s'est produit.

Exemples:

• Dans l'analyse des défaillances d'équipement, une dimension causale pourrait être la cause de la défaillance: surcharge, court-circuit, défaut de fabrication, erreur humaine, etc.

• Fait: Nombre de défaillances

• Dimension Causale: Explique pourquoi la défaillance s'est produite.

• Dans le secteur médical, une dimension causale peut représenter la cause de l'hospitalisation: infection, accident, maladie chronique, etc.

Utile pour passer d'une analyse descriptive à une analyse explicative ou prédictive.

Dimensions Temporelles

Les dimensions temporelles jouent un rôle structurant dans tous les entrepôts de données, utilisées pour analyser les faits dans le temps (jour, semaine, mois, trimestre, année, etc.).

• Presque toujours présentes dans les modèles de prise de décision.

• Une granularité fine peut entraîner une explosion du volume de données.

• Il y a $31,536,000$ secondes dans une année (365 jours × 24 heures × 60 minutes × 60 secondes).

  • Une ligne pour chaque seconde de l'année se traduit par $31,536,000$ lignes.

  • Si la dimension temporelle est définie avec une précision trop élevée, comme la seconde, la table de dimension contiendra un nombre énorme de lignes et sera difficile à gérer. Cela rend la table de dimension trop lourde, difficile à gérer et à interroger.

Solutions:

• Diviser la dimension Temps en deux dimensions distinctes:

  • Dimension 1: Date (Année → Mois → Semaine → Jour) - 365 lignes

  • Dimension 2: Heure de la Journée (Heure → Minute → Seconde) - $86,400$ lignes ($24 \, \text{h} \times 60 \, \text{min} \times 60 \, \text{s}$)

• Conserver une seule dimension Date et stocker l'heure dans la table de faits.

  • La dimension Temps contient uniquement des informations relatives à la date (jour, mois, année, etc.), avec environ 365 lignes.

  • Ajouter une colonne "heure de la journée" dans la table de faits, contenant une valeur de temps précise (heure:minute:seconde) sans utiliser de dimension dédiée.

  • Total: $365 + 86,400 \approx 87,000$ lignes

Cette solution est plus flexible et légère, car elle évite de créer une dimension très volumineuse.

Historisation des Données

Pour gérer l'évolution des données, les dimensions sont classifiées en fonction de leur fréquence de changement. Un entrepôt de données repose sur deux éléments clés:

• Les faits, qui changent rarement, représentent des données mesurables (ex: note d'un étudiant, publication d'un enseignant).

• Les dimensions, qui fournissent le contexte de ces faits (ex: étudiant, enseignant, matière).

• Les dimensions évoluent plus fréquemment (ex: changement de grade d'un enseignant, modification de l'adresse d'un étudiant).

Types de Dimensions Basés sur le Changement

• Dimensions à Changement Lent (SCD)

• Dimensions à Changement Rapide (RCD)

Dimensions à Changement Lent (SCD)

Gérer les changements progressifs des valeurs d'attributs au fil du temps.

SCD Type 1 (Écraser l'Ancienne Valeur)

Remplacer l'ancienne valeur par la nouvelle sans conserver l'historique.

Exemple:

Grade d'un Enseignant

• En 2022: Assistant

• En 2024: Maître Assistant

• En 2026: Maître de Conférences

SCD Type 2 (Changements Historiques)

Chaque changement crée une nouvelle ligne avec une date de début et une date de fin pour conserver l'historique.

Exemple:

Grade d'un Enseignant

Chaque fois qu'il y a un changement, une nouvelle entrée est créée avec Date Début et Date Fin pour suivre l'historique.

SCD Type 3 (Ajouter une Colonne pour l'Ancienne Valeur)

Ajouter une nouvelle colonne pour stocker l'ancienne valeur.

Exemple:

Grade d'un Enseignant

Une colonne stocke le grade 'actuel' tandis qu'une autre stocke le grade 'précédent'.

Dimensions à Changement Rapide (RCD)

Ces dimensions changent très fréquemment, posant un problème de gestion de l'historique. Stocker tous les changements peut surcharger inutilement le système. Si tous ces changements sont stockés dans la dimension principale (ex: dimension Client), la table devient très grande, difficile à gérer et à maintenir, surtout si le SCD Type 2 est utilisé pour chaque changement.

Exemples:

• Une dimension Client avec un attribut de score de fidélité qui change très souvent (ex: après chaque achat).

• Une dimension Utilisateur avec un attribut d'adresse IP qui peut changer 10 fois par jour.

• Une dimension Client avec un attribut de préférence (couleur préférée, type de produit préféré, etc.).

Solution: Mini-Dimensions

Déplacer ces attributs dans une mini-dimension pour optimiser la gestion des changements.

• La mini-dimension est une petite table de dimension séparée contenant uniquement les attributs très volatils ou à changement rapide, empêchant la dimension principale de gonfler.

• Référencer les attributs volatils via un lien vers la mini-dimension directement dans la table de faits.

Structure de la Table de Faits:

• ID Fait

• ID temps

• ID produit

• ID client

• Mesure 1

• Mesure 2

• Attributs Volatils

La table de faits contient deux clés étrangères:

• Une vers la dimension Client

• Une vers la mini-dimension Comportement

Justification de la liaison de la mini-dimension à la table de faits

Garder les données relativement stables dans la dimension principale et les données très volatiles dans une mini-dimension liée aux faits. La mini-dimension contient des attributs à changement rapide qui peuvent changer fréquemment d'un événement à l'autre.

Lier la mini-dimension directement à la dimension principale (ex: Client) nécessiterait de créer une nouvelle ligne dans la dimension principale pour chaque changement de ces attributs, avec une nouvelle clé artificielle. Cela annule le but de la mini-dimension, qui est d'éviter de dupliquer les données stables (nom, adresse, sexe, etc.).

En liant la mini-dimension directement à la table de faits, une dimension principale stable est maintenue, et l'état des attributs volatils est capturé au moment de chaque événement, sans impacter la dimension principale.

Approches de Conception d'un Entrepôt de Données

La conception d'un entrepôt de données (DW) peut être réalisée selon plusieurs approches, chacune ayant ses avantages et ses inconvénients en fonction des besoins de l'organisation, du budget, du temps disponible, etc.

Principalement, deux approches de conception d'entrepôt de données se distinguent:

1. Approche Bottom-Up (Ralph Kimball)

2. Approche Top-Down (Bill Inmon)

Approche Top-Down

Commencer par construire un entrepôt de données centralisé (DW global) et ensuite dériver des data marts spécifiques à chaque domaine.

Étapes:

• Concevoir un modèle global d'entreprise.

• Intégrer les données dans le DW.

• Créer des data marts dérivés.

Avantages:

• Vision globale et cohérente.

• Meilleure qualité des données à long terme.

Limitations:

• Longue implémentation du projet.

• Coût initial élevé.

Approche Bottom-Up

Prioriser la création de data marts indépendants, conçus rapidement pour répondre à des besoins spécifiques, puis progressivement intégrés dans un entrepôt de données global.

Étapes:

• Définir les besoins décisionnels d'un domaine.

• Concevoir un data mart.

• Intégrer les data marts dans un DW fédéré.

Avantages:

• Déploiement plus rapide.

• Coûts initiaux réduits.

Limitations:

• Risque d'incohérence entre les data marts.

• Moins adapté à une vision globale de l'entreprise dès le départ.

Architectures d'Entrepôt de Données

La mise en place d'un entrepôt de données représente un réel défi. Il existe plusieurs façons de concevoir un entrepôt. La littérature identifie cinq principaux types d'architectures.

• Data Marts Indépendants

• Architecture en Bus de Data Marts

• Architecture Hub-and-Spoke

• Entrepôt de Données Centralisé

• Architecture Fédérée

Le choix de l'architecture appropriée dépend d'une combinaison de plusieurs critères:

• Les objectifs

• Le profil des utilisateurs finaux

• Le volume de données à traiter

• Le temps à mettre en œuvre

• Les ressources disponibles, etc.

Data Marts Indépendants

Un data mart peut être considéré comme une sous-partie d'un DW, conçu pour répondre à un besoin fonctionnel spécifique. Ce type d'architecture consiste à regrouper plusieurs data marts.

Ces magasins sont développés de manière autonome, chacun pouvant s'appuyer sur des sources de données distinctes et indépendantes.

Avantages:

• Architecture simple et peu coûteuse.

• Implémentation rapide.

• Fortement orientée sujet

• Adaptation aux besoins spécifiques.

Inconvénients:

• Redondances et incohérences de données.

• Impossible analyse inter-fonctionnelle.

Architecture en Bus de Data Marts

Cette architecture est proposée par R. Kimball, également appelée approche Bottom-Up. Elle propose de construire des data marts mais en utilisant des dimensions conformées. Conception fortement orientée sujet, mais pour certaines données, les magasins utiliseront des dimensions communes (temporelles et géographiques par exemple).

Avantages:

• Fortement orientée sujet.

• Intégration de données cohérentes grâce aux dimensions conformées.

• Architecture incrémentale: Possibilité d'ajouter des magasins au besoin.

Inconvénients:

• Chaque nouveau magasin doit être adapté aux tables de dimension et de faits existantes.

• Faibles performances d'analyse inter-fonctionnelle.

Architecture Hub-and-Spoke

L'architecture hub-and-spoke est proposée par B. Inmon, également appelée approche Top-Down. Elle consiste en un hub central qui stocke et gère les données partagées, tandis que les spokes sont des data marts spécialisés qui s'appuient sur le hub pour accéder aux données nécessaires.

Avantages:

• Intégration centralisée des données.

• Cohérence des données dans tous les Data Marts.

• Flexibilité: De nouveaux Data Marts peuvent être ajoutés.

Inconvénients:

• Temps d'implémentation plus long.

• Coût de gestion élevé et complexité.

Architecture Centralisée

L'architecture centralisée est similaire au modèle Hub and Spoke, mais sans data marts. Toutes les données, détaillées et résumées, sont stockées directement dans l'entrepôt central.

Avantages:

• Vue globale et cohérente des données de toute l'organisation.

• Performances optimales (meilleure qualité des données, gouvernance des données facile).

Inconvénients:

• Rigidité: L'ajout de nouvelles sources ou la modification du modèle est plus complexe.

Architecture Fédérée

L'architecture fédérée est utilisée lorsque plusieurs entrepôts de données existent déjà (ex: fusion d'entreprises). Plutôt que de créer un nouvel entrepôt centralisé, un entrepôt virtuel est mis en place qui fournit une vue unifiée des entrepôts existants.

Les données restent dans les systèmes sources, et une couche middleware permet d'interroger ces sources sans déplacer les données.

Avantages:

• Implémentation rapide et économique.

• Utilisation des systèmes existants sans modifications majeures.

• Peu de ressources matérielles requises.

Inconvénients:

• Requêtes lentes (accès en temps réel à des sources hétérogènes).

• Faible contrôle sur la qualité des données

• Intégration complexe à gérer

• Performances analytiques limitées

Comparaison des Architectures