Les problèmes d'analytique remontent finalement aux données sous-jacentes. Les enregistrements de clients en double, les chiffres de revenus qui ne correspondent pas d'un rapport à l'autre et les tableaux de bord qui se contredisent ne sont pas des problèmes de visualisation ou de requête ; ce sont des problèmes de schéma, et la normalisation des données est la façon dont les équipes les résolvent à la source.

Ci-dessous, nous verrons comment fonctionne la normalisation des données, à quoi ressemble un schéma normalisé en pratique et où les véritables compromis apparaissent pour les équipes d'analytique et d'entrepôt.

Points clés

• La normalisation des données structure une base de données relationnelle de sorte que chaque élément d'information se trouve à un seul endroit. Cela élimine les valeurs en double et conflictuelles.

• Les équipes d'analytique peuvent appliquer la normalisation sur l'ensemble d'un pipeline en construisant d'abord des tables d'entités centrales normalisées, puis en superposant la production de rapports dénormalisée par-dessus.

• Un prestataire de services de paiement moderne peut synchroniser les données de paiement directement dans l'entrepôt d'une entreprise. Cela fournit aux schémas normalisés une source complète et récente sur laquelle s'appuyer sans avoir besoin d'effectuer l'acheminement de données financières sensibles par l'intermédiaire de connecteurs tiers.

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

La normalisation des données est le processus d'organisation d'une base de données relationnelle de sorte que chaque élément d'information se trouve à un seul endroit. Vous faites cela en divisant les données en tables liées et en les associant au moyen de clés plutôt que de répéter les mêmes valeurs sur plusieurs lignes.

Le but est la cohérence. À mesure que le volume de données augmente, cette discipline structurelle est ce qui sépare un entrepôt auquel vous pouvez faire confiance d'un entrepôt que vous auditez constamment.

Pourquoi la normalisation des données est-elle importante pour l'exactitude et la gouvernance de l'analytique?

Les données non normalisées peuvent créer des catégories de problèmes qui s'aggravent à mesure que vos données augmentent.

Chacun des éléments suivants est un défaut structurel dans le schéma lui-même :

• Anomalies de mise à jour : Celles-ci se produisent lorsque le même fait apparaît dans plusieurs lignes. Si le nom d'une offre d'abonnement est sauvegardé directement sur chaque ligne de facture, renommer l'offre signifie mettre à jour des milliers d'enregistrements, et en manquer ne serait-ce qu'un seul crée une divergence. Dans un schéma normalisé, le nom de l'offre réside dans une table plans ; la facture ne contient qu'un plan_id.

• Anomalies d'insertion : Celles-ci se produisent lorsque vous ne pouvez pas enregistrer quelque chose sans enregistrer autre chose de non lié. Dans une table plate qui stocke ensemble les données de clients et de commandes, vous ne pouvez pas ajouter un nouveau client tant qu'il n'a pas passé de commande, ce qui signifie que la table devient défectueuse dès que votre équipe de vente commence à charger des prospects dans l'entrepôt.

• Anomalies de suppression : Celles-ci se produisent lorsque la suppression d'un enregistrement spécifique supprime involontairement des données importantes et non liées. Supprimez la dernière commande pour un client dans une table plate, et vous avez également perdu ses coordonnées, car elles n'avaient aucun emplacement indépendant.

Quelles sont les principales formes normales?

Les formes normales sont une séquence de règles de plus en plus strictes sur la façon dont les données doivent être structurées.

Les équipes utilisant la normalisation des données doivent comprendre les formes jusqu'à et y compris la troisième forme normale (3FN) pour prendre de bonnes décisions de schéma. Une base de données est souvent décrite comme « normalisée » si elle respecte la 3FN.

• Première forme normale (1FN) : Celle-ci exige que chaque colonne contienne des valeurs atomiques – aucune liste, aucune chaîne séparée par des virgules et aucun tableau regroupé dans un seul champ. Une colonne de produits contenant « chemise, pantalon, veste » échoue à la 1FN. Trois lignes avec un product_id et un product_name réussissent à la respecter.

• Deuxième forme normale (2FN) : Celle-ci s'appuie sur la 1FN en exigeant que chaque colonne non clé dépende de l'ensemble de la clé primaire, et non pas seulement d'une partie. Si une table d'articles de ligne utilise « (order_id, product_id) » comme clé, mais qu'elle stocke également la ville du client, ce qui ne dépend que de order_id, il s'agit d'une dépendance partielle et d'une violation de la 2FN. La ville du client appartient à la table de commandes.

• Troisième forme normale (3FN) : Celle-ci élimine les dépendances transitives, ce qui signifie des 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 zip_code et city, et que la ville est déterminée par le code postal plutôt que par la commande, ces champs appartiennent à une table de géographie distincte.

• Forme normale de Boyce-Codd (FNBC) : Il s'agit d'une version plus stricte de la 3FN qui gère les cas particuliers impliquant des clés candidates qui se chevauchent. Pour les schémas d'analytique, atteindre la 3FN est suffisant.

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

La façon la plus claire de voir ce que fait réellement la normalisation est de commencer avec une table défectueuse et de la corriger. Voici un exemple de table de commandes non normalisée et une explication de ce qui lui arrive après la normalisation.

Table de commandes non normalisée

Il y a trois problèmes immédiats avec cette table. Le courriel d'Ana apparaît deux fois : si vous le mettez à jour dans une ligne, vous créez un conflit. Le nom du produit et la catégorie se répètent sur chaque ligne de commande, de sorte que modifier une catégorie signifie toucher à chaque commande historique qui l'incluait. De plus, il n'y a aucun moyen d'ajouter un nouveau client ou produit sans y joindre une commande.

Après la normalisation, vous auriez trois tables :

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

Le courriel d'Ana n'existe qu'une seule fois. La catégorie du casque n'existe qu'une seule fois. Les commandes font référence aux deux par ID. Une instruction SELECT à deux jointures de type Structured Query Language (requête SQL) peut combiner des données provenant de multiples tables établies sur des conditions communes : un coût faible et permanent pour un schéma qui n'accumule pas d'erreurs lorsqu'il évolue.

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

Bien qu'elle présente des avantages importants, la normalisation peut également introduire des coûts réels pour les équipes.

Les compromis se divisent en trois catégories :

• Complexité des requêtes : Chaque relation que vous normalisez dans sa propre table est une jointure que vous écrirez plus tard. Un rapport que vous pouviez lire à partir d'une seule table plate nécessite maintenant trois jointures, et la charge cognitive s'accumule au sein d'une équipe d'analystes travaillant directement en SQL.

• Effort de modélisation initial : La conception d'un schéma normalisé nécessite de comprendre le domaine suffisamment bien pour identifier les entités, leurs attributs et les relations entre eux. Les équipes subissant des pressions pour livrer sautent souvent cette étape afin de construire des structures plates qui semblent plus faciles sur le moment, mais qui deviennent coûteuses par la suite.

• Performance de lecture : Sur les très grandes tables, les jointures sont plus lentes que les balayages. Les entrepôts de données modernes (par exemple, BigQuery, Snowflake, Redshift) disposent d'optimiseurs de requêtes qui gèrent raisonnablement bien les jointures, mais les structures dénormalisées l'emportent souvent sur la vitesse de requête brute pour les charges de travail analytiques portant sur des milliards de lignes.

Comment les équipes d'analytique et d'entrepôt appliquent-elles la normalisation des données dans les flux de travail?

En pratique, les équipes d'analytique appliquent la normalisation par couches sur l'ensemble d'un pipeline. Différents niveaux de structure servent des objectifs et des préoccupations distincts : l'intégrité des données est gérée au niveau de la couche centrale normalisée, tandis que la performance des requêtes et l'ergonomie des analystes sont gérées au niveau de la couche de production de rapports.

Voici comment cela se passe :

• Couche de préparation : Les données brutes arrivent ici presque telles quelles à partir de la source. Peu ou pas de transformation ne se produit à ce stade. L'objectif est simplement d'obtenir des données intactes et interrogeables dans l'entrepôt, et non de les modéliser.

• Couche centrale normalisée : Les outils de transformation produisent des tables d'entités normalisées à partir de la couche de préparation – une pour les clients, une pour les abonnements et une pour les transactions. Celles-ci se situent approximativement à la 3FN et servent de source de vérité pour tout modèle en aval.

• Couche de production de rapports : Au-dessus du cœur normalisé, les équipes construisent de larges tables dénormalisées conçues pour la vitesse et la facilité d'utilisation dans un outil d'intelligence d'entreprise (BI) tel que Tableau ou Looker. Un modèle de tableau de bord des revenus pourrait joindre cinq tables normalisées en une seule grande table de faits que l'outil de BI lit directement.

Comment Stripe favorise 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 dossiers de transaction obsolètes ou incomplets peuvent créer des écarts de rapprochement qu'aucune conception de schéma, même rigoureuse, ne peut corriger.

Voici ce qu'un prestataire de services de paiement peut offrir :

• Synchronisation : Stripe Data Pipeline déplace les données Stripe (p. ex., paiements, clients, abonnements, remboursements, litiges et virements) directement vers un entrepôt ou une destination de stockage infonuagique, sans connecteur tiers intermédiaire ni limites de débit de l'interface de programmation d'application (API).

• Exhaustivité : Stripe garantit l'exhaustivité des données en synchronisant toutes les données Stripe, les rapports financiers préétablis et les ensembles de données organisés.

• Sécurité : Lorsque les équipes redirigent les données Stripe au moyen de connecteurs tiers d'extraction, de transformation et de chargement (ETL), elles envoient des données financières sensibles dans l'infrastructure d'un autre fournisseur. Data Pipeline gère directement le transport, ce qui supprime cet intermédiaire et élimine un fournisseur de votre liste de vérification de la sécurité des données.

Data Pipeline ne remplace pas une plateforme ETL complète. Si vous combinez des données Stripe avec des données provenant d'une douzaine d'autres sources, vous avez toujours besoin d'outils de transformation. Toutefois, cette solution est conçue spécifiquement pour synchroniser vos données Stripe de manière plus efficace qu'un connecteur tiers, ce qui garantit une synchronisation fiable, sécuritaire et précise de vos données financières.