Lorsque vous travaillez avec des bases de données, il est courant de rencontrer des problèmes tels que des données redondantes et des mises à jour incohérentes. La deuxième forme normale est une étape de la normalisation des bases de données qui s’appuie sur la première forme normale (1NF) pour créer des tables plus propres et plus efficaces.
Comprendre la 2NF est essentiel pour toute personne travaillant dans la conception de bases de données ou la gestion des données, et elle pose les bases pour des formes de normalisation supérieures comme la troisième forme normale (3NF). Dans cet article, nous explorerons le fonctionnement de la 2NF et comment transformer les tables pour répondre aux exigences de la 2NF, avec des exemples pratiques. Nous parlerons également des avantages et inconvénients de la 2NF, et des cas d’utilisation pour lesquels elle convient le mieux.
Comprendre la Deuxième Forme Normale
La deuxième forme normale est une étape de normalisation des bases de données axée sur l’élimination des dépendances partielles. Elle a été introduite par Edgar F. Codd, le pionnier des bases de données relationnelles, dans le cadre de ses travaux sur la normalisation.
Avant qu’une table puisse être en 2NF, elle doit satisfaire aux règles de la première forme normale :
- Atomicité: Chaque cellule doit contenir une seule valeur (pas de groupes répétés ou de tableaux).
- Lignes uniques: La table doit avoir une clé primaire claire.
La 2NF va encore plus loin avec une règle supplémentaire: éliminer les dépendances partielles.
Une dépendance partielle se produit lorsqu’un attribut non-prime (colonne qui ne fait pas partie d’une clé candidate) dépend seulement d’une partie d’une clé composite au lieu de la clé entière. La règle de 2NF garantit que tous les attributs non-primes dépendent de l’ensemble de la clé primaire, et pas seulement d’une partie de celle-ci. Laisser des dépendances partielles dans une table signifie que des données redondantes peuvent s’immiscer dans la base de données, entraînant une inefficacité et des incohérences potentielles lors des mises à jour ou des suppressions.
La théorie seule peut être un peu sèche, alors examinons un exemple pratique.
Voici une table d’Inscription aux Cours des étudiants de Datacamp.
Student ID | Course ID | Course Name | Instructor Name |
---|---|---|---|
1001 | 201 | Les Fondamentaux du SQL | Ken Smith |
1002 | 202 | Introduction à Python | Merlin O’Donnell |
1001 | 202 | Introduction à Python | Merlin O’Donnell |
Ici, la clé primaire est le composite de ID Étudiant et ID Cours. Cependant, les attributs non primaires Nom du Cours et Frais de Cours dépendent uniquement de ID Cours, pas de l’ensemble de la clé. Cela viole la 2NF.
Étapes pour décomposer les tables afin d’atteindre la 2NF
Pour vous assurer qu’une table respecte les règles de la 2NF, vous devez :
- Identifier toutes les clés candidates : Déterminer les ensembles minimaux d’attributs qui identifient de manière unique les lignes dans la table. Ce sont vos clés candidates.
- Déterminer les dépendances fonctionnelles : Identifier toutes les dépendances fonctionnelles dans la table. En particulier, recherchez les dépendances où les attributs non premiers (ceux qui ne font pas partie d’une clé candidate) dépendent uniquement d’une partie d’une clé composite.
- Éliminer les dépendances partielles : Pour chaque dépendance partielle :
- Déplacez les attributs dépendants dans une nouvelle table avec la partie de la clé dont ils dépendent.
- Assurez-vous que la nouvelle table a une clé primaire unique.
- Répétez jusqu’à ce qu’il n’y ait plus de dépendances partielles : Confirmez que chaque attribut non-prime dans toutes les tables dépend entièrement de sa clé primaire respective.
Exemples de deuxième forme normale en pratique
Examinons maintenant deux exemples.
Exemple 1 : Table d’inscription aux cours
Auparavant, nous avons vu le tableau d’inscription au cours suivant :
Student ID | Course ID | Course Name | Instructor Name |
---|---|---|---|
1001 | 201 | Fondamentaux de SQL | Ken Smith |
1002 | 202 | Introduction à Python | Merlin O’Donnell |
1001 | 202 | Introduction à Python | Merlin O’Donnell |
Suivons les étapes que nous avons définies dans la section précédente.
1. Identifier notre clé candidate.
Dans ce cas, la clé candidate est une clé composite de ID étudiant et ID du cours. Cette combinaison unique identifie chaque ligne dans la table.
2. Déterminer nos dépendances fonctionnelles
Nom du cours et Nom de l’instructeur dépendent de ID du cours, pas de la clé composite complète (ID de l’étudiant, ID du cours). Il s’agit d’une dépendance partielle car ces attributs dépendent uniquement d’une partie de la clé composite.
3. Éliminer les dépendances partielles
Nous devons déplacer les attributs qui dépendent seulement d’une partie de la clé (Nom du cours et Nom de l’instructeur) vers une nouvelle table qui est uniquement basée sur ID du cours.
Après décomposition, nos nouvelles tables ressemblent à ceci :
Tableau d’inscription aux cours
Student ID | Course ID |
---|---|
1001 | 201 |
1002 | 202 |
1001 | 202 |
Tableau des détails du cours
Course ID | Course Name | Instructor Name |
---|---|---|
201 | Fondamentaux du SQL | Ken Smith |
202 | Introduction à Python | Merlin O’Donnell |
Si vous souhaitez mettre la main à la pâte et créer vos propres bases de données, jetez un œil à notre cours sur PostgresQL. Si vous êtes un peu plus avancé, vous pourriez essayer cette Introduction à la modélisation des données dans Snowflake, qui aborde des concepts tels que la modélisation entité-relation et dimensionnelle.
Exemple 2 : Table des commandes
Nous allons commencer par cette table des commandes. Essayez de suivre les étapes que nous avons décrites ci-dessus et décomposez cette table vous-même !
Order ID | Product ID | Order Date | Product Name | Supplier Name |
---|---|---|---|---|
1 | 201 | 2024-11-01 | Ordinateur portable | TechSupply |
1 | 202 | 2024-11-01 | Souris | TechSupply |
2 | 201 | 2024-11-02 | Ordinateur portable | TechSupply |
3 | 203 | 2024-11-03 | Clavier | KeyMasters |
1. Identifier notre clé candidate
Le numéro de commande et l’identifiant de produit forment une combinaison unique qui identifie chaque ligne, ce qui rend (numéro de commande, identifiant de produit) une clé candidate composite. Aucune colonne unique ne peut identifier les lignes car :
- ID de commande n’est pas unique, car plusieurs produits peuvent faire partie de la même commande.
- ID de produit n’est pas unique, car le même produit peut apparaître dans différentes commandes.
Cela signifie que (ID de commande, ID de produit) est également notre clé primaire.
2. Déterminer nos dépendances fonctionnelles
Date de commande dépend de ID de commande (pas de la clé primaire complète). Il s’agit d’une dépendance partielle.
Nom du produit et Nom du fournisseur dépendent de ID du produit (et non de la clé composite complète). Ce sont également des dépendances partielles.
3. Éliminer les dépendances partielles
Nous devons diviser la table en tables plus petites, chacune traitant d’une dépendance logique distincte.
Tout d’abord, nous allons créer une table pour les informations de commande, qui contient des informations spécifiques à ID de commande.
Table des commandes
Order ID | Order Date |
---|---|
1 | 2024-11-01 |
2 | 2024-11-02 |
3 | 2024-11-03 |
Ensuite, nous créons une table qui contient des informations spécifiques à ID de produit.
Table des commandes
Product ID | Product Name | Supplier Name |
---|---|---|
201 | Ordinateur portable | TechSupply |
202 | Souris | TechSupply |
203 | Clavier | KeyMasters |
La table originale est maintenant réduite à la clé composite et aux relations entre les commandes et les produits.
Order ID | Product ID |
---|---|
1 | 201 |
1 | 202 |
2 | 201 |
3 | 203 |
Maintenant, notre base de données est en 2NF car 1) toutes les dépendances partielles ont été éliminées, et 2) les attributs non-prime dépendent entièrement de leurs clés primaires respectives.
Quand mettre en œuvre la deuxième forme normale
Alors, pourquoi devriez-vous refactoriser votre base de données en 2NF ? Est-ce suffisant en soi ou devriez-vous aller un peu plus loin et viser la 3NF ?
Avantages et limitations de la deuxième forme normale
La deuxième forme normale offre plusieurs avantages, ce qui en fait une étape utile dans le processus de normalisation de la base de données :
- Intégrité des données améliorée : En éliminant les dépendances partielles, la 2NF minimise les anomalies d’insertion, de mise à jour et de suppression, conduisant à une base de données plus fiable.
- Réduction de la redondance : La 2NF diminue la répétition des données, optimisant l’utilisation de l’espace de stockage et simplifiant la maintenance des données.
- Structure de données améliorée : Elle prépare le terrain pour une normalisation plus poussée, comme la progression vers la troisième forme normale, en créant un design de base de données plus propre et plus efficace.
Mais cela comporte certaines limitations :
- Complexité accrue : Décomposer les tables pour répondre à la 2NF peut rendre le processus de conception plus complexe, en particulier lorsqu’il s’agit de clés composites et de dépendances.
- Joins supplémentaires : La division des tables peut nécessiter plus de joins dans les requêtes, ce qui peut impacter les performances dans les systèmes avec de grands ensembles de données ou des requêtes complexes – plus d’informations à ce sujet ci-dessous.
- Redondance résiduelle : Bien que la 2NF réduise les dépendances partielles, elle n’aborde pas les dépendances transitives, laissant une certaine redondance jusqu’à ce qu’elle soit traitée dans la 3NF.
Considérations de performance avec la deuxième forme normale
Décomposer les tables pour éliminer les dépendances partielles peut directement affecter les performances de la base de données. D’une part, atteindre la 2NF réduit la redondance des données et améliore la cohérence, entraînant moins d’anomalies lors des opérations d’insertion, de mise à jour ou de suppression. D’autre part, la normalisation peut augmenter le nombre de tables, ce qui signifie que des jointures supplémentaires sont nécessaires lors de la récupération des données connexes. Cela pourrait avoir un impact sur les performances des requêtes dans de grands ensembles de données.
Pour garantir que votre base de données normalisée reste performante, veillez à suivre ces bonnes pratiques :
- Indexation : Utilisez des index pour accélérer les jointures entre les tables décomposées.
- Optimisation des requêtes: Optimisez les requêtes pour minimiser le coût des joints supplémentaires.
- Approche hybride: Combinez la normalisation avec la dénormalisation dans les domaines où la performance est importante, tels que les tables de reporting.
- Suivi régulier: Évaluez continuellement les performances de votre base de données avec des outils de profilage pour détecter tout problème potentiel.
Est-ce que la 2NF n’est qu’une étape de transition pour atteindre la troisième forme normale?
Dans la plupart des cas, les concepteurs de bases de données s’efforcent d’atteindre la troisième forme normale en raison de sa capacité à réduire davantage la redondance et à améliorer l’intégrité globale des données. Cependant, atteindre la 3NF implique souvent un travail supplémentaire, tel que la création de plus de tables et de relations, ce qui peut introduire des complexités et des compromis de performances dans l’exécution des requêtes.
Il existe des cas où l’utilisation de la deuxième forme normale peut suffire en soi. Si la simplicité et une mise en œuvre rapide sont des priorités, comme dans les projets à petite échelle, les prototypes, ou les situations où la redondance des données est minimale, la 2NF peut suffire. Par exemple, dans les systèmes où tous les attributs dépendent déjà entièrement d’une clé primaire simple, atteindre la 2NF pourrait remplir l’objectif principal de réduire la dépendance partielle, sans nécessité de normalisation supplémentaire.
Aller au-delà de la deuxième forme normale : vers la troisième forme normale
Si vous souhaitez normaliser davantage votre base de données, vous pouvez continuer à refondre vos tables pour atteindre la troisième forme normale.
3NF s’appuie sur le 2NF en traitant les dépendances transitives – situations où les attributs non-clés dépendent d’autres attributs non-clés plutôt que de la clé primaire. Cette progression garantit que chaque attribut dépend directement de la clé primaire et de rien d’autre.
Par exemple, dans une table de suivi des inscriptions aux cours :
- 2NF: Garantit que des attributs tels que le nom du cours et le nom de l’étudiant dépendent entièrement de leurs clés primaires respectives (par exemple, ID de l’étudiant et ID du cours). Cela élimine les dépendances partielles, où les attributs non-clés ne reposent que sur une partie de la clé composite.
- 3NF: Assure que des attributs tels que les détails de l’instructeur ou les informations sur le département sont stockés dans des tables séparées, éliminant ainsi les dépendances transitives.
La 3NF est idéale pour des systèmes plus complexes où l’intégrité des données et l’efficacité sont primordiales, surtout à mesure que le volume de données augmente. Consultez notre Qu’est-ce que la troisième forme normale ? article si vous souhaitez en savoir plus sur la 3NF et sa forme plus restrictive, la BCNF.
Conclusion
La deuxième forme normale est une étape essentielle dans la normalisation des bases de données, comblant le fossé entre la 1NF et des formes supérieures comme la 3NF. En éliminant les dépendances partielles, la 2NF réduit la redondance et améliore la fiabilité de vos données. Bien qu’elle puisse ajouter une certaine complexité, les avantages d’une meilleure intégrité des données et d’une maintenance simplifiée en font une partie critique d’une conception de base de données efficace.
Si vous êtes prêt à approfondir vos compétences, explorez notre cours de Conception de bases de données pour approfondir votre compréhension des techniques de normalisation et de leurs applications pratiques. Vous pouvez également valider vos compétences en SQL et en gestion de bases de données et démontrer votre expertise aux employeurs potentiels avec notre Certification SQL Associate!
Enfin, je tiens à dire que si vous êtes un décideur dans une entreprise et que vous savez que vous avez du travail à faire pour créer des bases de données plus propres et plus efficaces, envisagez de faire une demande de démonstration pour DataCamp for Business. Nous pouvons vous aider à transformer les compétences de votre équipe afin que vous puissiez créer des systèmes de bases de données évolutifs qui stimulent l’efficacité et l’innovation de l’entreprise. Nous pouvons même créer des parcours d’apprentissage sur mesure et des pistes personnalisées.
Source:
https://www.datacamp.com/tutorial/second-normal-form