Normalisation

Première forme normale (1NF)

Une relation (ou un schéma de relation) dans une base de données donnée est en “première forme normale”, si le domaine de tous les “attributs” de cette relation est atomique. Un domaine est atomique si tous les éléments de ce domaine sont considérés comme des unités indivisibles. Supposons qu’une relation employee, a l’attribut name, alors la relation n’est pas dans la première forme normale, car les éléments du domaine de nom de l'attribut peuvent être divisés en first name et last name .

En un mot, si une relation a [attributs composites] [1], alors elle n’est pas en première forme normale. Supposons que nous ayons la relation suivante :

EmpId prénom nom de famille salaire poste
Deptx-101 Jean forgeron 12000 intermédiaire
Dépt-201 Caroline Williams 18900 gestionnaire

Le EmpId de la première ligne peut être divisé en : Deptx (qui est utilisé pour identifier le service) et 101, est un numéro unique attribué au sein de l’organisation. Clairement, le domaine de l’attribut “EmpId” n’est pas atomique et donc notre relation n’est pas en “première forme normale”.

Inconvénients rencontrés :

  1. Lorsque de tels identifiants d’employé sont utilisés, le département d’un employé peut être trouvé en écrivant du code qui décompose la structure de EmpId en Deptx et 101, ce qui nécessite une programmation supplémentaire. De plus, les informations sont encodées dans le programme plutôt que dans la base de données.
  2. Supposons qu’un employé particulier doive changer de service, l’attribut “EmpId” devra être mis à jour partout où il est utilisé.

Nous pouvons faire en sorte que notre relation satisfasse la “première forme normale”, en la divisant en deux relations suivantes :

Relation 1

EmpId prénom nom de famille département
101 Jean forgeron Deptx
201 Caroline Williams Département

Relation 2

EmpId salaire poste
101 12000 intermédiaire
201 18900 gestionnaire

Maintenant, si nous devons changer de département, nous devons le faire une seule fois dans la relation 1, aussi déterminer le département est plus facile maintenant.

[1] : http://ion.uwinnipeg.ca/~rmcfadye/2914/hypergraph/composite.html

Deuxième forme normale (2NF)

Pour normaliser la base de données dans le deuxième formulaire, il ne doit y avoir aucune dépendance partielle d’une colonne sur la clé primaire.

Considérons l’exemple suivant :

identifiant nom date sujet
1 marque 1-1-1981 Physique
2 Jack 2-2-1982 Mathématiques
2 Jack 2-2-1982 Biologie
3 Jean 3-3-1983 Mathématiques

Cette table est considérée comme ayant une clé primaire composite (id et subject), mais les colonnes *name et dob ne dépendent que de id, pas de subject, elles dépendent donc partiellement de clé primaire. En conséquence, nous pouvons voir la redondance des informations dans le tableau. Pour normaliser la base de données dans le deuxième formulaire, nous devons diviser cette table en deux tables comme ceci :

Tableau des étudiants

identifiant nom date
1 marque 1-1-1981
2 Jack 2-2-1982
3 Jean 3-3-1983

Tableau des sujets

étudiant_id sujet
1 Physique
2 Mathématiques
2 Biologie
3 Mathématiques

La colonne student_id de la table Subjects est une clé étrangère qui fait référence à la clé primaire id de la table Students.