1NF est la forme normale la plus élémentaire : chaque cellule d'un tableau ne doit contenir qu'un seul élément d'information et il ne peut y avoir de lignes en double.
2NF et 3NF ont pour but de dépendre de la clé primaire. Rappelons qu'une clé primaire peut être constituée de plusieurs colonnes. Comme Chris l'a dit dans sa réponse :
Les données dépendent de la clé [1NF], de toute la clé [2NF] et de rien d'autre que la clé [3NF] (alors aidez-moi Codd ).
2NF
Supposons que vous disposiez d'une table contenant les cours suivis au cours d'un semestre donné et que vous ayez les données suivantes :
|-----Primary Key----| uh oh |
V
CourseID | SemesterID | #Places | Course Name |
------------------------------------------------|
IT101 | 2009-1 | 100 | Programming |
IT101 | 2009-2 | 100 | Programming |
IT102 | 2009-1 | 200 | Databases |
IT102 | 2010-1 | 150 | Databases |
IT103 | 2009-2 | 120 | Web Design |
C'est pas dans 2NF parce que la quatrième colonne ne s'appuie pas sur l'indice de confiance. tout le site mais seulement une partie de celle-ci. Le nom du cours dépend de l'ID du cours, mais n'a rien à voir avec le semestre au cours duquel il a été suivi. Ainsi, comme vous pouvez le constater, nous avons des informations en double - plusieurs lignes nous indiquant que IT101 est un cours de programmation, et IT102 un cours de bases de données. Nous corrigeons donc ce problème en déplaçant le nom du cours dans une autre table, où CourseID est la clé ENTIÈRE.
Primary Key |
CourseID | Course Name |
---------------------------|
IT101 | Programming |
IT102 | Databases |
IT103 | Web Design |
Pas de redondance !
3NF
Bon, disons que nous ajoutons également le nom de l'enseignant du cours, ainsi que certains détails le concernant, dans le SGBDR :
|-----Primary Key----| uh oh |
V
Course | Semester | #Places | TeacherID | TeacherName |
---------------------------------------------------------------|
IT101 | 2009-1 | 100 | 332 | Mr Jones |
IT101 | 2009-2 | 100 | 332 | Mr Jones |
IT102 | 2009-1 | 200 | 495 | Mr Bentley |
IT102 | 2010-1 | 150 | 332 | Mr Jones |
IT103 | 2009-2 | 120 | 242 | Mrs Smith |
Maintenant, nous espérons qu'il est évident que TeacherName dépend de TeacherID - donc ceci est pas dans 3NF . Pour résoudre ce problème, nous faisons à peu près la même chose que dans 2NF : nous retirons le champ TeacherName de cette table et nous le plaçons dans sa propre table, dont la clé est TeacherID.
Primary Key |
TeacherID | TeacherName |
---------------------------|
332 | Mr Jones |
495 | Mr Bentley |
242 | Mrs Smith |
Pas de redondance !
Une chose importante à retenir est que si quelque chose n'est pas en 1NF, il n'est pas non plus en 2NF ou 3NF. Ainsi, chaque forme normale supplémentaire nécessite tout que les formes normales inférieures avaient, plus quelques conditions supplémentaires, qui doivent todo se réaliser.