Les anomalies d’analyse finissent toujours par remonter aux données sous-jacentes. Les profils clients en doublon, les chiffres de revenus qui divergent d’un rapport à l’autre et les tableaux de bord qui se contredisent ne découlent pas de problèmes de visualisation ou de requêtes ; ce sont des failles de schéma, et la normalisation des données est la méthode employée par les équipes pour les corriger à la source.

Nous examinerons ci-dessous le fonctionnement des normalisation des données, la structure d’un schéma normalisé en pratique et la manière dont ces compromis impactent concrètement les équipes d’analyse et de warehouse.

Points clés

• La normalisation des données structure une base de données relationnelle afin que chaque information ne réside qu’à un seul et unique endroit, éliminant ainsi les doublons et les valeurs contradictoires.

• Les équipes d’analyse appliquent la normalisation au sein d’un pipeline en concevant d’abord des tables d’entités centrales normalisées, puis en superposant une couche de reporting dénormalisée.

• Un prestataire de paiement moderne peut synchroniser les données de paiement directement dans le warehouse d’une entreprise. Les schémas normalisés disposent ainsi d’une source de données complète et actualisée pour se construire, sans avoir à faire transiter des données financières sensibles par des connecteurs tiers.

Qu’est-ce que la normalisation des données ?

La normalisation des données est le processus consistant à organiser une base de données relationnelle de manière à ce que chaque information ne réside qu’à un seul et unique endroit. Pour ce faire, les données sont réparties dans plusieurs tables liées entre elles par des clés, plutôt que de répéter les mêmes valeurs sur plusieurs lignes.

L’objectif recherché est la cohérence. À mesure que le volume de données augmente, cette rigueur structurelle est précisément ce qui différencie un entrepôt de données fiable d’un système que vous devez constamment auditer.

Pourquoi la normalisation des données est-elle essentielle pour l’exactitude des analyses et la gouvernance ?

Des données non normalisées peuvent générer des catégories de problèmes qui s’amplifient à mesure que le volume de données augmente.

Chacun des points suivants représente une faille structurelle du schéma lui-même :

• Les anomalies de mise à jour : Elles surviennent lorsqu’un même fait est stocké sur plusieurs lignes. Si le nom d’un abonnement est directement sauvegardé sur chaque ligne de facture, renommer cet abonnement impose de mettre à jour des milliers d’enregistrements ; le moindre oubli crée alors une divergence. Dans un schéma normalisé, le nom de l’abonnement réside dans une table de plans de souscription, et la facture contient simplement un plan_id.

• Les anomalies d’insertion : Elles se produisent lorsqu’il est impossible d’enregistrer une information sans en enregistrer une autre totalement distincte. Dans une table plate qui stocke à la fois les données clients et les données de commandes, vous ne pouvez pas ajouter de nouveau client tant que celui-ci n’a pas passé commande. La table devient alors inutilisable dès que l’équipe commerciale souhaite intégrer des prospects dans le warehouse.

• Les anomalies de suppression : Elles se produisent lorsque la suppression d’un enregistrement spécifique entraîne involontairement la perte de données importantes et indépendantes. Supprimez la dernière commande d’un client dans une table plate, et vous perdrez également ses coordonnées de contact, car celles-ci ne disposaient pas de leur propre espace de stockage.

Quelles sont les principales formes normales ?

Les formes normales constituent une suite de règles de plus en plus strictes régissant la structure des données.

Les équipes qui mettent en œuvre la normalisation des données doivent maîtriser ces règles jusqu’à la troisième forme normale (3NF) incluse pour prendre les bonnes décisions d’architecture. Une base de données est généralement qualifiée de « normalisée » lorsqu’elle respecte les critères de la norme 3NF.

• Première Forme Normale (1NF) : Elle exige que chaque colonne contienne des valeurs atomiques, c’est-à-dire sans listes, sans chaînes de caractères séparées par des virgules et sans tableaux encapsulés dans un seul champ. Une colonne de produits affichant « chemise, pantalon, veste » ne respecte pas la norme 1NF. En revanche, trois lignes distinctes associant chacune un product_id à un product_name s’y conforment parfaitement.

• Deuxième Forme Normale (2NF) : Elle s’appuie sur la 1NF et impose que chaque colonne non clé dépende de la totalité de la clé primaire, et non d’une partie seulement. Si une table de lignes de commande utilise « (order_id, product_id) » comme clé mais stocke également la ville du client, laquelle dépend uniquement de « order_id », il s’agit d’une dépendance partielle et donc d’une violation de la norme 2NF. La ville du client doit être rattachée à la table des commandes.

• Troisième Forme Normale (3NF) : Elle élimine les dépendances transitives, c’est-à-dire les colonnes non clés qui dépendent d’autres colonnes non clés plutôt que de la clé elle-même. Si une table de commandes stocke à la fois le zip_code et la ville, et que la ville est déterminée par le code postal et non par la commande, ces champs doivent être déplacés dans une table géographique distincte.

• Forme Normale de Boyce-Codd (BCNF) : Il s’agit d’une version plus stricte de la norme 3NF qui gère les cas particuliers impliquant des clés candidates imbriquées ou chevauchantes. Pour les schémas destinés à l’analyse de données, atteindre la norme 3NF est amplement suffisant.

Comment la normalisation des données fonctionne-t-elle en pratique ?

Le moyen le plus clair de comprendre ce que fait réellement la normalisation est de partir d’une table défaillante pour la corriger. Voici l’exemple d’une table de commandes non normalisée, suivi d’une explication de sa transformation après normalisation.

Tableau des commandes non normalisé

Cette table présente immédiatement trois problèmes. L’adresse e-mail d’Ana apparaît deux fois : si vous la modifiez sur une seule ligne, vous créez un conflit de données. Le nom et la catégorie du produit se répètent à chaque ligne de commande, ce qui signifie que la modification d’une catégorie nécessiterait de corriger chaque commande historique qui la contient. Enfin, il est impossible d’ajouter un nouveau client ou un nouveau produit sans y associer obligatoirement une commande.

Après normalisation, vous obtenez trois tables distinctes :

• Customers : customer_id, name, email
  
• Products : product_id, name, category
  
• Orders : order_id, customer_id, product_id, qty, unit_price
  

L’adresse e-mail d’Ana n’existe plus qu’à un seul endroit. La catégorie du casque audio également. Les commandes font référence à ces deux entités par leurs identifiants (ID). Une instruction SELECT avec deux jointures en langage SQL comprenant deux jointures permet de combiner les données de ces multiples tables sur la base de critères communs : un coût technique minime et permanent pour un schéma de base de données qui n’accumule pas d’erreurs à mesure qu’il monte en charge.

Quels sont les compromis courants de la normalisation des données ?

Bien qu’elle présente des avantages majeurs, la normalisation peut également engendrer des coûts réels pour les équipes.

Ces compromis s’articulent autour de trois axes principaux :

• La complexité des requêtes : Chaque relation que vous normalisez dans sa propre table se traduira par une jointure à écrire plus tard. Un rapport qui aurait pu être lu directement depuis une table unique et plate nécessite désormais trois jointures, et cette charge cognitive finit par peser sur une équipe d’analystes travaillant directement en SQL.

• L’effort de modélisation initial : Concevoir un schéma normalisé exige de bien comprendre le domaine métier pour identifier correctement les entités, leurs attributs et les relations qui les unissent. Soumises à la pression des délais de livraison, les équipes font souvent l’impasse sur cette étape pour bâtir des structures plates, plus simples à court terme mais très coûteuses par la suite.

• La performance de lecture : Sur de très grandes tables, les jointures s’avèrent plus lentes que les balayages de tables. Les data warehouses modernes (comme BigQuery, Snowflake ou Redshift) disposent certes d’optimiseurs de requêtes qui gèrent relativement bien les jointures, mais les structures dénormalisées l’emportent souvent en matière de vitesse brute d’exécution lorsqu’il s’agit d’effectuer des analyses sur des milliards de lignes.

Comment les équipes d’analyse et de warehouse appliquent-elles la normalisation dans leurs flux de travail ?

En pratique, les équipes d’analyse déploient la normalisation par strates tout au long d’un pipeline de données. Chaque niveau de structure répond à des objectifs et à des exigences spécifiques : l’intégrité des données est traitée au niveau de la couche centrale normalisée, tandis que la performance des requêtes et le confort de travail des analystes sont gérés au niveau de la couche de reporting.

Voici comment ceci se produit :

• La couche de préparation : Les données brutes y sont importées quasiment en l’état depuis la source. Très peu ou pas de transformations n’ont lieu à ce stade. L’objectif est simplement d’intégrer les données dans le warehouse de manière intacte et interrogeable, sans chercher à les modéliser.

• La couche centrale normalisée : Des outils de transformation génèrent des tables d’entités normalisées à partir de la couche de préparation, une table pour les clients, une pour les abonnements et une pour les transactions. Ces tables respectent globalement la norme 3NF et font office de source unique de vérité pour tous les modèles situés en aval.

• La couche de rapports : Par-dessus la couche centrale normalisée, les équipes conçoivent de grandes tables dénormalisées, optimisées pour la vitesse d’exécution et la simplicité d’utilisation dans les outils de Business Intelligence (BI) tels que Tableau ou Looker. Un modèle de tableau de bord des revenus peut ainsi combiner cinq tables normalisées en une seule grande table de faits que l’outil de BI interroge directement.

Comment Stripe garantit des données plus propres et plus fiables pour la normalisation en aval

La qualité de tout schéma normalisé dépend entièrement de la qualité et de l’exhaustivité des données qui l’alimentent. Des enregistrements de transactions obsolètes ou incomplets peuvent créer des écarts de rapprochement qu’aucune conception de schéma, aussi minutieuse soit-elle, ne pourra corriger.

Voici ce qu’un prestataire de paiement peut apporter :

• La synchronisation : Stripe Data Pipeline transfère les données Stripe (par exemple, les paiements, les clients, les abonnements, les remboursements, les litiges, les versements) directement vers un warehouse ou un espace de stockage cloud, sans connecteur tiers intermédiaire et sans limites d’appels de l’API.

• L’exhaustivité : Stripe garantit l’exhaustivité des données en synchronisant l’intégralité de vos données Stripe, vos rapports financiers prédéfinis et vos ensembles de données sélectionnés.

• La sécurité : Lorsque les équipes acheminent les données Stripe via des connecteurs tiers d’extraction, de transformation et de chargement (ETL), elles envoient des données financières sensibles dans l’infrastructure d’un fournisseur supplémentaire. Data Pipeline gère le transport de manière directe, ce qui supprime cet intermédiaire et retire un prestataire de votre liste d’évaluation de la sécurité des données.

Data Pipeline ne remplace pas une plateforme ETL complète. Si vous combinez les données Stripe avec celles d’une douzaine d’autres sources, vous aurez toujours besoin d’outils de transformation. Cependant, cette solution est spécifiquement conçue pour synchroniser vos données Stripe de manière plus efficace qu’un connecteur tiers, garantissant ainsi un transfert fiable, sécurisé et précis de vos données financières.