Techniques de normalisation des données : exploration et décryptage

Les données incohérentes, redondantes ou mal structurées font perdre un temps précieux aux équipes et génèrent des analyses peu fiables. La normalisation des données est la discipline qui élimine ces problèmes en amont, avant qu’ils n’atteignent un rapport, un modèle ou une expérience client.

Cet article aborde les points suivants :

• Qu’est-ce que la normalisation des données ?
• Quelles sont les principales techniques de normalisation des données ?
• Pourquoi la normalisation des données est-elle essentielle à la qualité des données ?
• Comment la normalisation des données s’intègre-t-elle dans un pipeline de données global ?
• Comment choisir l’approche de normalisation adaptée à votre organisation ?

La normalisation des données est le processus qui consiste à organiser les données de façon cohérente, sans redondance et structurées pour prendre en charge des requêtes et des analyses fiables. Un exemple concret illustre son importance : si un système enregistre le pays d’un client sous US, un autre sous United States, et un troisième sous USA, aucune jointure entre ces systèmes ne produira de résultats corrects tant que les valeurs n’auront pas été normalisées selon un standard unique. Ce type d’incohérence n’est pas un cas limite. C’est l’état par défaut de toute organisation qui collecte des données provenant de plusieurs sources.

Deux disciplines distinctes font appel au terme normalisation des données, et toutes deux sont essentielles pour les équipes data.

• La normalisation de base de données relationnelle structure les tables pour éliminer les données dupliquées et imposer des dépendances logiques. Elle intéresse toute personne qui conçoit ou maintient un schéma de base de données, et s’appuie sur un ensemble de règles progressives appelées formes normales.
• La normalisation numérique redimensionne les valeurs numériques dans une plage ou une distribution commune. Elle s’adresse à toute personne qui crée des modèles de machine learning ou alimente des algorithmes sensibles à l’échelle, comme le clustering ou la régression.

Dans un environnement de données d’entreprise, la normalisation ne se limite pas à une tâche ponctuelle de conception de base de données. C’est une préoccupation continue qui traverse l’ingestion, la transformation et l’activation des données, et qui engage chaque équipe qui produit ou consomme de la donnée. Les ingénieurs et ingénieures de données conçoivent des schémas normalisés. Les analystes marketing s’appuient sur des données normalisées pour obtenir des comptages de segments précis. Les data scientists appliquent la normalisation numérique avant l’entraînement des modèles. Ce concept est présent à chaque couche d’un data stack moderne, ce qui fait de la maîtrise des techniques de normalisation dans ces deux disciplines un atout incontournable pour toute personne qui travaille avec des données clients ou opérationnelles.

Voici les principales techniques de normalisation des données :

Normalisation relationnelle : formes normales

Les techniques de normalisation relationnelle s’organisent en étapes progressives appelées formes normales. Chaque forme repose sur la précédente et corrige un défaut structurel bien précis.

• La première forme normale (1FN) exige que chaque colonne ne contienne que des valeurs atomiques et indivisibles, et que chaque ligne soit unique. Par exemple, une colonne Numéros de téléphone regroupant plusieurs valeurs séparées par des virgules enfreint la 1FN. La solution consiste à répartir ces valeurs dans des lignes distinctes ou dans une table associée.
• La deuxième forme normale (2FN) exige que chaque colonne non clé dépende de l’intégralité de la clé primaire, et non d’une seule partie. Cela élimine les dépendances partielles qui génèrent des anomalies de mise à jour dans les tables à clés composites. Un cas classique est celui d’une table de lignes de commande où la description du produit ne dépend que de l’identifiant produit, et non de la clé composite complète formée par l’identifiant de commande et l’identifiant produit. Déplacer la description du produit dans une table produits distincte résout cette violation.
• La troisième forme normale (3FN) exige qu’aucune colonne non clé ne dépende d’une autre colonne non clé, éliminant ainsi les dépendances transitives. Si une table client stocke à la fois un code postal et un nom de ville, et que la ville peut être déduite du code postal, la mise à jour du nom de la ville sans modifier le code postal laisse les données dans un état contradictoire. Isoler la correspondance code postal-ville dans sa propre table supprime ce risque.
• La forme normale de Boyce-Codd (BCNF) est une variante plus stricte de la 3FN, utilisée lorsqu’une table comporte plusieurs clés candidates qui se chevauchent. Elle est moins souvent nécessaire, mais permet de traiter des cas particuliers que la 3FN ne couvre pas.

Normalisation numérique : méthodes de mise à l’échelle

Les techniques de normalisation numérique redimensionnent les variables numériques afin que les différences d’amplitude ne faussent pas les résultats des modèles.

• La mise à l’échelle min-max compresse l’ensemble des valeurs dans une plage fixe, généralement de zéro à un. Elle fonctionne bien lorsque la distribution de la variable est connue et bornée, comme l’âge dans une population définie. En revanche, une seule valeur aberrante extrême peut comprimer les autres valeurs dans une bande très étroite, réduisant ainsi le pouvoir discriminant de la variable.
• La standardisation par score Z transforme les valeurs de façon à ce que la variable présente une moyenne nulle et un écart-type de un. Elle est préférable lorsque les données contiennent des valeurs aberrantes ou lorsque l’algorithme suppose une distribution normale, comme dans le cas de la régression logistique ou de l’analyse en composantes principales. En contrepartie, les valeurs obtenues ne sont plus exprimées dans les unités d’origine, ce qui peut rendre les résultats plus difficiles à interpréter pour les parties prenantes métier.
• La mise à l’échelle logarithmique applique une transformation logarithmique pour compresser de larges plages de valeurs. Elle est particulièrement utile pour les données de revenus ou de vues de pages couvrant plusieurs ordres de grandeur. Elle ne peut pas être appliquée directement à des valeurs nulles ou négatives sans ajustement préalable, par exemple en ajoutant une constante avant la transformation.
• L’écrêtage définit une limite supérieure ou inférieure stricte et plafonne les valeurs qui la dépassent, empêchant ainsi les valeurs aberrantes extrêmes de fausser un modèle sans supprimer entièrement la ligne concernée. Le risque est d’éliminer un signal pertinent si le seuil est fixé de manière trop agressive.

Guide de sélection des techniques

Les données relationnelles non normalisées génèrent trois catégories d’anomalies qui altèrent silencieusement les enregistrements.

• Anomalie de mise à jour. Le même fait est stocké dans plusieurs lignes. Modifier l’adresse e-mail d’un client dans une seule ligne sans répercuter la modification sur les autres place la base de données dans un état contradictoire. Une équipe marketing qui extrait des listes d’e-mails depuis cette table enverra des messages à des adresses obsolètes, et la logique de déduplication traitera le même client comme deux personnes distinctes.
• Anomalie d’insertion. L’ajout d’un nouvel enregistrement nécessite des données qui ne devraient pas logiquement être requises. Par exemple, un schéma qui stocke les informations sur les produits uniquement dans les lignes de commande rend impossible l’ajout d’un nouveau produit tant qu’aucune vente n’existe, retardant ainsi les mises à jour du catalogue.
• Anomalie de suppression. La suppression d’une ligne entraîne involontairement la perte d’informations sans rapport stockées dans cette même ligne. Supprimer la dernière commande d’un client peut également effacer ses coordonnées si les deux sont stockées dans une seule et même table.

Chacune de ces anomalies engendre des erreurs de reporting en aval difficiles à relier à leur cause structurelle : les données paraissent plausibles au niveau de la ligne, même lorsqu’elles se contredisent au niveau de la table.

Dans les pipelines de machine learning, les variables numériques non normalisées causent une catégorie de problèmes bien distincte. Les algorithmes basés sur la distance — comme les k plus proches voisins — et les optimiseurs par descente de gradient accordent une influence bien plus grande à une variable dont les valeurs se chiffrent en milliers qu’à une variable dont les valeurs oscillent entre zéro et un, même si toutes deux ont le même pouvoir prédictif. Le coût métier est alors un modèle qui performe bien sur les données d’entraînement, mais se dégrade en production, car c’est l’échelle de la variable, et non son signal, qui pilote les prédictions.

Le nettoyage des données et la validation des données sont deux disciplines complémentaires qui s’exercent en parallèle de la normalisation. Le nettoyage supprime ou corrige les enregistrements inexacts. La validation s’assure que les données entrantes respectent les formats et les contraintes attendus avant d’entrer dans un pipeline. La normalisation, quant à elle, suppose que les données sont déjà propres et valides. L’appliquer à des données non fiables produit un désordre structuré plutôt qu’un jeu de données exploitable. Les équipes qui font l’impasse sur les techniques de nettoyage des données avant de normaliser ne découvrent souvent le problème que lorsque les rapports en aval affichent des valeurs impossibles dans des colonnes parfaitement formatées.

Les organisations qui gèrent des données client sur plusieurs canaux sont confrontées à une version amplifiée de ce problème. Lorsque les attributs d’un client proviennent d’un outil de gestion de la relation client, d’une plateforme e-commerce, d’une application mobile et d’un système de support, chaque source emploie généralement des noms de champs, des formats de valeurs et des types de données différents. Sans normalisation au niveau de la couche d’ingestion, les profils clients unifiés deviennent peu fiables, générant des doublons, des segments manqués et des erreurs de personnalisation.

La normalisation s’intègre à l’étape de transformation des données d’un pipeline ETL (extraction-transformation-chargement) ou ELT (extraction-chargement-transformation) standard, après l’ingestion des données brutes et avant leur écriture dans un système de destination à des fins d’analyse ou d’activation. L’ordre des opérations est déterminant. Les tâches de transformation des données, telles que la conversion de format et le mapping de champs, précèdent généralement la normalisation, tandis que l’enrichissement des données — l’ajout d’attributs tiers ou de signaux dérivés — lui succède. L’enrichissement est d’autant plus fiable qu’il s’applique à une base propre et cohérente.

La standardisation des données est une étape étroitement liée à la normalisation, mais bien distincte. Elle consiste à aligner les valeurs sur un vocabulaire ou un format commun — par exemple, convertir tous les formats de date en ISO 8601 — ou à associer les noms de pays aux codes ISO 3166. La normalisation, quant à elle, va plus loin : elle restructure l’organisation des données entre les tables ou remet à l’échelle les valeurs numériques. Confondre les deux amène les équipes à appliquer le mauvais correctif — standardiser les formats de champs quand le vrai problème est un schéma mal structuré, ou normaliser une table quand le problème de fond est un encodage incohérent des valeurs. Avant d’arrêter la conception d’un pipeline, il est essentiel de bien maîtriser la différence entre normalisation et standardisation des données.

En pratique, la frontière entre ces étapes de pipeline reste poreuse. Les équipes données les plus matures intègrent la normalisation dans un programme de qualité des données en continu, plutôt que d’en faire une décision de conception de schéma arrêtée une fois pour toutes au démarrage d’un projet. Chaque nouvelle source de données ajoutée à une plateforme soulève de nouvelles décisions de normalisation : comment mapper ses champs sur le schéma existant, comment gérer les conflits de valeurs, et si les variables numériques doivent être remises à l’échelle avant leur utilisation en aval.

La modélisation des données fournit le plan structurel dans lequel s’inscrit la normalisation. Un modèle de données bien conçu définit les entités existantes, leurs relations et la forme normale appropriée pour chaque table. Ces techniques de modélisation déterminent l’ampleur des travaux de normalisation requis ainsi que la complexité de la couche de requêtes qui en découle. Les équipes qui font l’impasse sur l’étape de modélisation se retrouvent souvent à re-normaliser les tables à plusieurs reprises au fil des nouvelles exigences — raison pour laquelle l’écriture vers un système de destination pour l’analyse ou l’activation exige une planification amont rigoureuse.

Normalisation relationnelle et normalisation numérique ne s’excluent pas mutuellement. La grande majorité des environnements de données d’entreprise requiert les deux. L’enjeu est de déterminer quelle technique appliquer, à quel endroit et jusqu’à quel niveau de profondeur.

Si votre priorité est la conception du schéma de base de données pour un système transactionnel, tel qu’un outil de gestion de la relation client, une plateforme de gestion des commandes ou un entrepôt de données clients, privilégiez la normalisation relationnelle jusqu’à la 3NF. Cela réduit les coûts de stockage, prévient les anomalies de mise à jour et facilite la maintenance du schéma au fil de l’évolution des exigences. Si les performances des requêtes se dégradent en raison de la complexité des jointures, envisagez une dénormalisation sélective des tables à lecture intensive plutôt que d’abandonner la base normalisée.

Si la préparation de données pour des modèles de machine learning ou des analyses statistiques est votre priorité principale, concentrez-vous sur la normalisation numérique. Optez pour la mise à l’échelle min-max lorsque les caractéristiques ont une plage connue et bornée et que l’algorithme ne présuppose pas de distribution spécifique. Choisissez la standardisation par score Z lorsque les caractéristiques peuvent contenir des valeurs aberrantes ou que l’algorithme s’attend à une entrée de moyenne nulle. Appliquez une mise à l’échelle logarithmique à toute caractéristique présentant une distribution fortement asymétrique à droite avant d’évaluer d’autres options.

Si votre organisation gère des données client provenant de plusieurs systèmes sources, un scénario courant dans la grande distribution, les services financiers et les médias numériques, le défi de normalisation porte principalement sur l’alignement des schémas et la cohérence des valeurs entre les sources. C’est là qu’une plateforme de données client imposant un modèle de données commun à l’ingestion prend tout son intérêt opérationnel. Adobe Experience Platform répond à ce cas d’usage en appliquant un cadre de schémas standardisé — le Modèle de données d’expérience (XDM) — qui normalise les données entrantes provenant de sources disparates dans un profil client unifié. Cela réduit le travail de normalisation manuel qui incomberait sinon aux équipes d’ingénierie des données. Les équipes qui évaluent des plateformes d’entreprise doivent déterminer si la plateforme applique la normalisation des schémas à l’ingestion ou la reporte aux consommateurs en aval.

Avant d’arrêter une stratégie de normalisation, parcourez cette liste de contrôle pratique :

1. Identifiez les principaux consommateurs des données. Les outils de reporting, les modèles de machine learning (ML) et les systèmes d’activation présentent chacun des seuils de tolérance différents en matière de complexité des jointures et de sensibilité à l’échelle.
2. Examinez les schémas existants pour détecter les trois types d’anomalies — mise à jour, insertion et suppression — avant de concevoir une stratégie de normalisation. Les anomalies identifiées indiqueront quelle forme normale est nécessaire.
3. Analysez le profil des variables numériques en termes de forme de distribution et de densité des valeurs aberrantes avant de sélectionner une technique de mise à l’échelle.
4. Vérifiez que les étapes de nettoyage et de validation des données sont bien en place en amont. La normalisation n’est pleinement efficace que sur des données propres : les problèmes de qualité sous-jacents doivent être traités au préalable.
5. Tenez compte des exigences réglementaires et de confidentialité. Des techniques d’anonymisation des données peuvent s’avérer nécessaires avant ou en parallèle de la normalisation, notamment lorsque des données client provenant de plusieurs sources sont consolidées dans un profil unifié.

Qu’il s’agisse de normaliser des schémas relationnels, de remettre à l’échelle des variables numériques ou d’unifier les données client issues de dizaines de systèmes sources, la bonne plateforme transforme des mois d’ingénierie de données manuelle en un processus gouverné et reproductible. Découvrez comment Adobe Experience Platform applique la normalisation au niveau des schémas via le Modèle de données d’expérience pour créer des profils clients unifiés à l’échelle de l’entreprise sur Adobe Experience Platform.