Comment la normalisation corrige-t-elle les trois types d'anomalies de mise à jour?

Question

J'ai lu "Systèmes de base de données: une approche pratique de la conception, de la mise en œuvre et de la gestion" par Connolly et Begg afin de comprendre la normalisation de la base de données (chapitre 14). Je comprends maintenant mieux les trois formulaires de normalisation de base de données:

Première forme normale (1NF)
Deuxième forme normale (2NF)
Troisième forme normale (3NF)

Je comprends également les trois anomalies de mise à jour:

Anomalie d'insertion
Anomalie de suppression
Anomalie de mise à jour/modification

Ce que j'ai du mal à comprendre maintenant, c'est comment lier les deux ensemble. Par exemple, laquelle des différentes formes aide à corriger l'anomalie d'insertion? De même pour les autres anomalies. Je voudrais idéalement connaître la relation de cartographie entre les deux groupes et pourquoi ces formes corrigent certaines anomalies.

C'est ma première question ici et j'ai cherché sur Google et ce site pour essayer de trouver une réponse en premier, mais en vain.

Je vous remercie.

BradC · Accepted Answer

1NF est simplement "ne conservez pas trop de données dans une seule colonne", donc je pense que 2NF et 3NF sont le principal correctif pour les 3 anomalies de base de données, car 2NF et 3NF impliquent de séparer les éléments dans leurs propres tables:

Anomalie d'insertion : Si vous avez une grande table enrollment qui inclut à la fois des données "classe" et "étudiant" (aucune d'elles n'existe ailleurs ), vous ne pouvez pas entrer dans un nouveau cours (vide) sans au moins un étudiant correspondant (car le tableau est un enregistrement de vos inscriptions). Donc, appliquez 2NF et créez des tables distinctes pour classes, students, et créez votre lien de table enrollment d'origine avec ClassID et StudentID. Vous pouvez maintenant entrer de nouvelles classes sans élèves et de nouveaux élèves sans classes.
Anomalie de suppression : comme ci-dessus, si chaque ligne de votre table enrollment d'origine contient tous les détails de l'étudiant et tous les détails de la classe dans laquelle ils sont inscrits, puis supprimer le dernier étudiant inscrit pour une classe supprime le dernier bit d'informations sur cette classe. La solution est la même, appliquez 2NF pour créer des tableaux séparés, afin que les étudiants puissent être inscrits ou désinscrits sans perdre les informations de la classe.
Anomalie de mise à jour : comme ci-dessus, en utilisant la méthode à table unique, la mise à jour des informations (par exemple, le numéro de la salle) pour une classe avec plusieurs étudiants inscrits peut conduire à une situation où certaines lignes ont été de nouvelles informations et d'autres lignes ont les anciennes. L'application de 2NF comme ci-dessus est à nouveau la solution, de sorte que les données de classe sont modifiées en un seul endroit (la table classes).

Notez que 1NF joue toujours le rôle certains dans votre processus, car cela signifie que vous ne pouvez pas essayer de résoudre le problème en entassant une liste entière d'étudiants inscrits dans un seul champ, ou ajoutez student1, student2, student3 champs ou quelque chose comme ça.

Nous pourrions trouver des exemples similaires où le facteur en jeu est 3NF au lieu de 2NF: si chaque "étudiant" a un conseiller pédagogique (et certains conseillers sont affectés à plusieurs étudiants), cela pourrait ne pas faire partie de la clé de notre table des étudiants , mais il s'agit d'un "attribut dépendant" et pourrait entraîner certains des mêmes problèmes que ci-dessus. Le conseiller pédagogique pourrait donc être divisé en son propre tableau.

Quelques ressources que j'ai trouvées utiles:

vidya · Answer

Je vais vous donner l'exemple que j'ai appris. 1Nf consiste à séparer les groupes répétitifs en différentes tables et tous ses attributs doivent être atomiques.

Supposons que nous ayons une table qui contient les attributs suivants. Purchase_order_No, Purchase_date, Emp_code, Supplier_Name, Supplier_No, Part_No Part_description, Part_Quantity

1NF: Ici, dans un seul bon de commande, nous pouvons avoir plusieurs pièces commandées, donc les mêmes données associées seront répétées. nous pouvons donc séparer part_no, part_description, part_quantity et faire de part_no, Purchase_order_no comme clé primaire. mais nous aurons des anomalies ici ..
1. insérer une anomalie: il y a maintenant 2 tables. nous ne pouvons pas insérer de pièce non achetée.
2. supprimer une anomalie: s'il y a eu un seul achat pour une pièce en particulier et si cette commande a été supprimée, nous n'aurons pas cette pièce dans notre tableau.
3. mettre à jour l'anomalie: pour changer la description d'une certaine pièce, nous devons la mettre à jour dans tous les endroits où elle a été achetée.
2NF: pour qu'une table soit en seconde forme, tous ses attributs doivent être totalement dépendants de sa clé primaire. Par exemple, pour connaître la quantité de pièces, nous devons connaître le numéro de pièce et le bon de commande. mais pour la description de la pièce, la pièce no est juste suffisante, nous les séparons donc en tableaux. le nom du fournisseur ne d
1. insérer une anomalie: si nous devions insérer un fournisseur qui n'a pas de commande, ce n'est pas possible.
2. supprimer l'anomalie: si nous supprimons la dernière commande unique d'un fournisseur, les données du fournisseur seront également perdues.
3. mise à jour d'anomalie: pour mettre à jour un fournisseur, il faut mettre à jour dans chaque bon de commande du fournisseur.
3Nf: pour qu'une table soit en 3NF, il ne doit pas y avoir d'attribut dépendant également d'un autre attribut non clé. ici, nous avons le nom du fournisseur qui dépend également de sup-no, nous les mettons donc dans une table différente. où sup_no est la clé primaire.

maintenant les tableaux ne peuvent plus être décomposés mais les anomalies peuvent continuer d'exister. nous ne pouvons pas former des tableaux de données parfaitement normalisés. j'espère que cela vous éclaircit.