QCM

Notion : La conception d’un Data Warehouse commence par le modèle analytique métier.
Explication : Avant de créer les tables, il faut identifier le processus métier étudié, définir précisément ce que représente une ligne de faits, puis déterminer les dimensions et les mesures nécessaires. Ces décisions se complètent : le processus fixe le sujet, la granularité fixe le niveau de détail, et les dimensions et mesures permettent l’analyse à ce niveau. Les clarifier évite des incohérences difficiles à corriger après la création des tables.
À retenir : Processus, granularité, dimensions et mesures doivent être cohérents avec les besoins analytiques.
Piège fréquent : Réduire la conception au choix d’un moteur fondé uniquement sur le volume actuel de données.

Notion : La granularité définit exactement ce que représente une ligne de la table de faits.
Explication : Avec une ligne par commande, les mesures appartiennent au niveau commande. Si une jointure ou une transformation les répète pour chaque produit, leur agrégation peut dupliquer le chiffre d’affaires ou d’autres montants. Les risques de répétition et de double comptage expliquent pourquoi la granularité doit être documentée et respectée dans les transformations. Ces réponses relient ainsi le problème à sa prévention.
À retenir : Ne pas mélanger sans précaution les niveaux commande et ligne de commande.
Piège fréquent : Croire qu’une clé primaire technique protège automatiquement les agrégations ; elle identifie les lignes, mais ne corrige pas leur signification analytique.

Notion : Le schéma en étoile organise les données autour d’une table de faits centrale.
Explication : Cette table contient les mesures et les clés reliant les faits aux dimensions. Les dimensions, généralement dénormalisées, sont directement reliées à la table centrale et apportent les axes d’analyse. Ces caractéristiques se complètent : la table de faits porte les valeurs analysées, les dimensions permettent de les contextualiser, et les relations directes contribuent à simplifier les requêtes analytiques.
À retenir : Une étoile associe un centre de faits à des dimensions directement accessibles.
Piège fréquent : Penser que toutes les dimensions doivent obligatoirement être normalisées en plusieurs niveaux ; cette exigence ne décrit pas le schéma en étoile.

Notion : Une dimension dégénérée est un identifiant ou attribut transactionnel conservé dans la table de faits, sans table de dimension associée.
Explication : Un numéro de commande peut être utile pour regrouper des faits ou explorer le détail d’une transaction. S’il ne possède pas d’attributs descriptifs nécessitant une dimension distincte, il peut rester directement dans les faits. Les réponses se complètent : elles précisent l’usage analytique, la raison de ne pas créer de table séparée et l’emplacement de l’identifiant.
À retenir : Une dimension dégénérée conserve un repère transactionnel utile sans dimension descriptive dédiée.
Piège fréquent : En déduire qu’elle remplace toutes les dimensions descriptives, alors que celles-ci répondent à d’autres besoins d’analyse.

Notion : Une dimension à évolution lente de type 2 conserve les versions successives d’une entité métier.
Explication : Lorsqu’un client change d’adresse, une nouvelle ligne représente sa nouvelle version, tandis que l’ancienne reste disponible. Chaque version possède une clé de substitution distincte. Des dates de validité, ou un mécanisme équivalent, permettent d’identifier la version applicable à une période donnée. Ces pratiques se complètent : elles assurent la conservation, l’identification et le repérage temporel des versions.
À retenir : Le type 2 historise les changements au lieu de remplacer les valeurs.
Piège fréquent : Écraser l’ancienne adresse détruit l’historique demandé.

Notion : Une clé de substitution est un identifiant généré par le Data Warehouse, souvent entier, distinct de la clé métier source.
Explication : Elle permet aux relations analytiques de ne pas dépendre directement des identifiants opérationnels. Si leur format change, cette séparation réduit les répercussions sur le modèle. Elle permet aussi d’identifier séparément plusieurs versions historiques d’une même entité métier. Ces avantages se complètent : stabilité des relations et gestion de l’historique.
À retenir : La clé de substitution identifie une ligne de dimension indépendamment des clés sources.
Piège fréquent : Un identifiant technique ne garantit pas la qualité des données source.

Notion : ETL et ELT distinguent l’ordre du chargement et de la transformation des données.
Explication : Dans un ETL, les données extraites sont généralement transformées avant leur chargement dans la cible. Dans un ELT, elles sont d’abord chargées, puis transformées dans la plateforme cible, en utilisant ses capacités de calcul. Le choix dépend donc de l’architecture et des capacités disponibles, et pas seulement du nom de l’approche.
À retenir : ETL signifie transformer avant de charger ; ELT signifie charger avant de transformer.
Piège fréquent : Transformer après le chargement ne signifie pas renoncer à valider les données.

Notion : Un chargement incrémental utilise un signal de changement pour sélectionner les données à traiter.
Explication : Si updated_at n’est pas actualisé correctement, des modifications peuvent rester invisibles au chargement. Un watermark, qui marque la progression du traitement, mal géré peut aussi provoquer des rechargements répétés. Une fenêtre de recouvrement permet de reprendre une période déjà traitée ; l’idempotence évite que cette reprise crée des doublons ou des incohérences. Ces protections se complètent, sans rendre fiable une colonne défectueuse.
À retenir : La fiabilité du delta dépend du signal et de la logique de reprise.
Piège fréquent : La présence de updated_at ne garantit pas l’exactitude du delta.

Notion : Un pipeline rejouable peut être relancé sans créer d’incohérences dans les données chargées.
Explication : L’idempotence signifie que répéter une opération ne modifie pas à nouveau le résultat déjà obtenu. Des clés ou identifiants fiables permettent de reconnaître les enregistrements déjà traités et de détecter les doublons. La journalisation de l’état et des erreurs aide à comprendre ce qui a réussi ou échoué. Ces mécanismes se complètent pour sécuriser les reprises.
À retenir : Rejouer exige de maîtriser les effets du traitement et de connaître son état.
Piège fréquent : Supprimer les contrôles fragilise les relances, même si cela paraît les accélérer.

Notion : Une donnée tardive arrive après le traitement de la période métier à laquelle elle appartient.
Explication : Une commande reçue après la clôture quotidienne peut nécessiter la correction des résultats de cette journée. Une fenêtre de rechargement couvre les périodes récentes susceptibles de recevoir des compléments. Le recalcul ou la correction de la partition concernée permet d’intégrer la commande. Tracer le retard et la correction rend cette intervention compréhensible. Ces mesures associent rattrapage, mise à jour et traçabilité.
À retenir : La clôture d’une période n’empêche pas une correction maîtrisée.
Piège fréquent : Ignorer définitivement la commande laisse les analyses incomplètes.