La normalisation des bases de données est un processus utilisé dans la conception de bases de données pour organiser les données de manière efficace. Elle peut aider à réduire la redondance des données (données en double) et à améliorer leur intégrité (exactitude et cohérence des données). C'est comme organiser un classeur mal rangé : au lieu d'avoir les mêmes informations à plusieurs endroits, vous placez chaque élément d'information à un seul endroit, puis vous utilisez un système de croisement des données pour les relier.
Une base de données est tout simplement une collection organisée de données, généralement stockées électroniquement dans un système informatique. Considérez-le comme un classeur numérique. Au lieu de dossiers papier et de tiroirs, vous utilisez des tableaux structurés (ou d'autres méthodes d'organisation des données) qui vous permettent de stocker, de gérer et de récupérer des informations rapidement et efficacement.
Les entreprises modernes utilisent des bases de données pour suivre tout ce qui les concerne, des commandes des clients aux niveaux d'inventaire, en passant par les informations des comptes utilisateur et les transactions financières. Nombre d'entre elles choisissent d'exécuter leurs bases de données dans le cloud.
Une base de données relationnelle organise les données dans une ou plusieurs tables comprenant des colonnes et des lignes. Elle est dite "relationnelle", car elle établit des relations spécifiques et prédéfinies entre ces tables. L'idée principale est de diviser les informations complexes en éléments plus petits et plus faciles à gérer, ce qui évite de stocker plusieurs fois les mêmes informations.
Prenons un exemple : une base de données simple pour une boutique en ligne. Vous auriez alors une table pour les clients (nom, adresse, numéro de téléphone) et une autre pour les commandes (date, total). Lorsqu'un client passe une commande, vous n'avez pas besoin de copier l'intégralité de son adresse dans la table "Commandes". Il vous suffit d'utiliser son ID client unique pour associer la commande à ses coordonnées complètes.
Si le client déménage et change d'adresse, il vous suffit de la modifier à un seul endroit : dans la table "Clients". Si vous l'aviez copié dans 100 enregistrements de commandes, il vous faudrait la modifier 100 fois, ce qui risquerait de générer des données désordonnées et incohérentes. Ce problème, qui consiste à devoir mettre à jour des informations à de nombreux endroits, est appelé anomalie de données.
Cependant, il est logique de copier le prix d'un produit dans l'enregistrement de commande au moment de l'achat. Pourquoi ? Parce que le prix du produit peut changer à l'avenir dans votre table "Produits" principale, mais l'enregistrement de la commande doit refléter le prix réellement payé par le client à la date de la transaction. Dans ce cas, copier et figer les données (ou créer un instantané) est le bon choix de conception.
La normalisation est le processus systématique de conception des tables relationnelles et des relations entre elles afin d'éliminer ces incohérences et d'économiser de l'espace de stockage. Les "formes normales" (1NF, 2NF, 3NF, etc.) sont une série de règles prescriptives. Elles permettent de résoudre les problèmes de redondance des données et les anomalies qu'elle engendre, en fournissant une méthode claire pour organiser les données de manière efficace et fiable en fonction des besoins de votre application.
La normalisation est un guide par étapes permettant de structurer vos tables, où chaque étape (ou "forme") s'appuie sur la précédente. Pour se présenter sous la troisième forme normale (3NF), une table doit passer les tests des formes 1NF et 2NF. La plupart des bases de données opérationnelles sont conçues pour respecter au moins la forme standard 3NF, car elle offre un bon équilibre entre intégrité et performances des données.
La règle 1NF consiste à s'assurer que vos tables sont correctement structurées dès le départ, comme si vous configuriez une feuille de calcul propre.
Règle : chaque colonne doit avoir un nom unique, et chaque cellule ne doit contenir qu'une seule valeur indivisible.
Problème résolu : vous ne pouvez pas insérer une liste d'éléments dans une seule cellule. Par exemple, dans une table "Commandes", vous ne pouvez pas lister "Lait, œufs, pain" dans une cellule de la colonne "Produits commandés". Chaque produit doit figurer sur une ligne distincte, ce qui permet de rechercher et de gérer les données.
La règle 2NF ne s'applique que si votre table utilise une clé composite, c'est-à-dire une clé primaire composée d'au moins deux colonnes combinées (comme un ID de commande et un ID produit). Une clé primaire est une colonne ou un ensemble de colonnes dont les valeurs identifient de manière unique chaque ligne d'une table. Une colonne non-clé est une colonne qui ne fait pas partie de la clé primaire.
Règle : une table doit déjà être sous la forme 1NF, et toutes les colonnes non-clés doivent dépendre de la clé composite entière, et non d'une partie seulement.
Problème résolu : vous ne devez stocker les données qu'à l'endroit où elles ont leur place. Si vous avez une table dont la clé est (ID de commande, ID produit), une colonne comme "Prix du produit" ne doit pas y figurer, car le prix ne dépend que de l'ID produit, et non de l'ID de commande. La solution consiste à déplacer "ID produit" et "Prix du produit" dans une table "Produits" distincte, où "ID produit" est la clé primaire unique. Cela évite de répéter inutilement le prix du produit pour chaque commande qui le contient.
La règle 3NF est la plus courante pour la conception de bases de données. Elle consiste à supprimer les relations indirectes entre les points de données.
Règle : une table doit être sous la forme 2NF, et les colonnes non-clés doivent dépendre uniquement de la clé primaire, et non d'une autre colonne non-clé.
Problème résolu : éviter que des données non-clés déterminent la valeur d'autres données non-clés. Prenons l'exemple d'une table "Employés" qui stocke un ID de bureau (colonne non-clé) et l'emplacement du bureau (autre colonne non-clé). L'emplacement du bureau est déterminé par l'ID du bureau, et non par l'ID de l'employé (la clé primaire de la table). Ce lien indirect est une dépendance transitive. Pour résoudre ce problème, vous créez une table "Bureaux" contenant uniquement l'ID du bureau et l'emplacement du bureau, puis vous liez les deux tables à l'aide de l'ID de bureau. Ainsi, si l'adresse du bureau change, vous n'aurez à la modifier qu'à un seul endroit.
Fonctionnalité | Normalization | Dénormalisation |
Objectif principal | Réduire la redondance, améliorer l'intégrité des données | Améliorer les performances de lecture |
Exemples de cas d'utilisation | Bases de données transactionnelles (mises à jour fréquentes) | Bases de données analytiques et entrepôts de données (lectures fréquentes) ; données ne devant pas être modifiées après leur création (par exemple, un instantané de contrat ou de facture). |
Résultat | Plus de tables, moins de duplication des données | Moins de tables, duplication intentionnelle des données |
Fonctionnalité
Normalization
Dénormalisation
Objectif principal
Réduire la redondance, améliorer l'intégrité des données
Améliorer les performances de lecture
Exemples de cas d'utilisation
Bases de données transactionnelles (mises à jour fréquentes)
Bases de données analytiques et entrepôts de données (lectures fréquentes) ; données ne devant pas être modifiées après leur création (par exemple, un instantané de contrat ou de facture).
Résultat
Plus de tables, moins de duplication des données
Moins de tables, duplication intentionnelle des données
La dénormalisation consiste à ajouter intentionnellement des données redondantes à une base de données, souvent dans le but d'améliorer les performances des requêtes à des fins de reporting ou d'analyse. C'est un compromis : vous sacrifiez une partie de l'intégrité et augmentez l'espace de stockage pour accélérer la récupération des données. Toutefois, dans certains cas, comme pour un contrat juridique, vous pouvez souhaiter cette redondance intentionnelle afin de créer un instantané des données indépendant des futures modifications. Cela garantit que les conditions, les noms et les prix enregistrés au moment de la signature du contrat restent fixes et disponibles de façon permanente, même si les données client ou produit principales sont modifiées ultérieurement.
La normalisation rend les bases de données relationnelles (comme Cloud SQL ou Spanner) plus efficaces, fiables et faciles à gérer en utilisant des "formes normales" pour structurer les données et éviter les problèmes courants.
Réduire la redondance des données
Stockez chaque élément de données, comme l'adresse d'un client, à un seul endroit pour économiser de l'espace de stockage et gagner en efficacité.
Éliminer les anomalies de données
Éviter les incohérences qui peuvent survenir avec des données redondantes, telles que des anomalies d'insertion, de suppression ou de mise à jour
Améliorer l'intégrité des données
Assurez-vous que les données sont exactes et cohérentes dans toute la base de données en garantissant que chaque élément de données est correct et stocké à un seul emplacement.
Si vous privilégiez les performances ultra-élevées, l'évolutivité massive ou un schéma flexible, vous pouvez opter pour une base de données non relationnelle (NoSQL) comme Bigtable ou Firestore. Les bases de données NoSQL sont conçues selon des principes différents qui incluent intentionnellement la redondance des données pour optimiser la rapidité de lecture et la disponibilité.
Google Cloud propose une gamme de services qui prennent en charge la normalisation des bases de données et en tirent parti.




Profitez de 300 $ de crédits gratuits et de plus de 20 produits Always Free pour commencer à créer des applications sur Google Cloud.