QCM

Notion : La qualité d’une table de faits doit être vérifiée au-delà de la réussite technique du chargement.
Explication : Comparer les volumes aide à repérer des écarts avec la source ou l’historique attendu. Contrôler l’unicité selon la granularité détecte les doublons. Vérifier les clés étrangères révèle les faits sans dimension correspondante. Réconcilier les montants agrégés avec une référence fiable contrôle la cohérence des mesures. Ces vérifications se complètent : aucune ne couvre seule tous les défauts possibles.
À retenir : Contrôler à la fois la présence, l’unicité, les relations et les valeurs.
Piège fréquent : Un job terminé sans erreur peut avoir chargé des données incorrectes.

Notion : Une dimension Date conforme fournit un référentiel temporel commun à plusieurs tables de faits.
Explication : Centraliser les attributs calendaires permet aux processus métier d’utiliser les mêmes définitions des semaines, mois, trimestres ou exercices fiscaux. Les analyses reposent ainsi sur des périodes cohérentes, ce qui facilite leur comparaison et les jointures temporelles. Le partage de la dimension et la richesse de ses attributs se complètent pour rendre les analyses transversales cohérentes.
À retenir : Un calendrier partagé donne un sens commun aux regroupements temporels.
Piège fréquent : Imposer un calendrier incompatible à chaque table de faits compromet la comparabilité des résultats.

Notion : L’additivité détermine sur quelles dimensions une mesure peut être sommée correctement.
Explication : Le chiffre d’affaires est généralement additif selon les dimensions appropriées. Un stock est souvent semi-additif : il peut se sommer sur certaines dimensions, mais additionner ses valeurs successives dans le temps ne donne pas un stock pertinent. Un taux de conversion est non additif et doit généralement être recalculé à partir de ses composantes. Ces distinctions permettent de choisir l’agrégation adaptée à chaque mesure.
À retenir : Avant de sommer, identifier la nature de la mesure et les dimensions concernées.
Piège fréquent : Additionner directement des pourcentages produit généralement un résultat trompeur.

Notion : Optimiser une requête analytique consiste notamment à limiter les données lues et à adapter leur accès au moteur.
Explication : Un partitionnement cohérent avec les filtres fréquents, comme la date, peut réduire les partitions parcourues. Sélectionner uniquement les colonnes nécessaires limite aussi le volume traité. Index, clustering et statistiques doivent être adaptés au moteur et aux usages. Ces pistes se complètent et s’évaluent à partir des plans d’exécution ; des agrégats peuvent être envisagés si nécessaire.
À retenir : Optimiser selon les requêtes réelles et les capacités de la plateforme.
Piège fréquent : Ajouter des index sans analyser leur utilité ni leurs coûts d’écriture.

Notion : La gouvernance et la traçabilité rendent les données compréhensibles, contrôlées et attribuables à des responsables.
Explication : Le lineage retrace le parcours des données, depuis les sources jusqu'au modèle analytique, en explicitant les transformations. Le catalogue permet de retrouver les données, tandis que le glossaire clarifie leurs définitions. Les responsables et les règles d'accès précisent qui répond de leur gestion et qui peut les consulter. Ces pratiques se complètent : elles couvrent l'origine, le sens et les conditions d'utilisation.
À retenir : Gouverner, c'est documenter, définir et encadrer l'usage des données.
Piège fréquent : Une sauvegarde protège contre la perte, mais ne suffit pas à expliquer les données ni à organiser leur gouvernance.

Notion : Kimball et Inmon sont deux approches distinctes d'architecture d'entrepôt de données.
Explication : Kimball privilégie généralement des modèles dimensionnels orientés processus métier. L'intégration de plusieurs data marts repose notamment sur des dimensions conformes, qui assurent des définitions cohérentes. Inmon met traditionnellement l'accent sur un entrepôt central d'entreprise normalisé, à partir duquel sont construits les data marts. Les caractéristiques de Kimball se complètent donc : organisation dimensionnelle et intégration par des dimensions partagées.
À retenir : Kimball privilégie le dimensionnel intégré ; Inmon privilégie un socle central normalisé.
Piège fréquent : Leur objectif analytique commun ne signifie pas qu'ils désignent exactement la même architecture.

Notion : Data Vault sépare les clés métier, les relations et les attributs historisés.
Explication : Les hubs représentent principalement les clés métier. Les links décrivent les associations entre hubs. Les satellites portent les attributs descriptifs et leur historique. Ces trois composants se complètent : ils distinguent l'identification d'un objet métier, ses relations et l'évolution de ses caractéristiques. Cette séparation met l'accent sur l'évolutivité et la traçabilité du modèle.
À retenir : Hub = clé métier ; link = relation ; satellite = attributs et historique.
Piège fréquent : Une structure Data Vault ne supprime pas le besoin de modèles de présentation adaptés aux analyses des utilisateurs.

Notion : Une table de faits sans mesures numériques, ou factless fact table, représente des événements ou des associations.
Explication : Un appel au support constitue un événement analysable, même lorsqu'il ne génère aucune vente. Une ligne peut enregistrer son occurrence et contenir les clés des dimensions pertinentes. Le comptage des lignes permet alors de compter les événements, tandis que les dimensions permettent d'étudier leurs combinaisons. L'absence de mesure stockée n'empêche donc pas l'analyse.
À retenir : Un fait peut exprimer « cela s'est produit », sans montant ni prix.
Piège fréquent : Exiger une mesure financière ferait écarter des événements utiles, comme les appels sans vente.

Notion : Une dimension à rôles multiples réutilise une même dimension avec plusieurs significations métier.
Explication : La date de commande et la date de livraison peuvent référencer la même dimension Date. Elles utilisent les mêmes définitions calendaires, mais répondent à des questions différentes. Des rôles explicitement nommés dans le modèle, les vues ou les alias permettent de distinguer ces usages. Réutilisation et clarification sémantique se complètent : on conserve un calendrier cohérent sans confondre les événements.
À retenir : Une dimension commune peut jouer plusieurs rôles clairement identifiés.
Piège fréquent : Il n'est pas nécessaire de créer deux calendriers différents ; ignorer les rôles peut en revanche produire des analyses ambiguës.

Notion : Une dimension tardive correspond à des données dimensionnelles disponibles après les faits qui les référencent.
Explication : Lorsqu'une transaction précède les informations du client, une clé inconnue ou une ligne temporaire documentée permet de conserver le fait. À l'arrivée des données, les faits ou la dimension sont corrigés selon la stratégie retenue. Une procédure de rattrapage, accompagnée de contrôles et d'une traçabilité des corrections, complète ce traitement provisoire.
À retenir : Conserver, identifier le manque, puis régulariser de manière contrôlée.
Piège fréquent : Supprimer la transaction masque le problème au lieu de le résoudre et retire un événement réel des analyses.