Normalisation d'une relation
Introduction
Pour être parfaites, les relations doivent respecter certaines règles. Cet ensemble de règles se nomme : les Formes Normales FN[1].
Cette théorie a été élaborée par Codd en 1970. Son objectif est d'éviter les anomalies dans les bases de données relationnelles :
Problèmes de mise à jour.
Suppression des redondances d'informations.
Simplification de certaines contraintes d'intégrité.
Il existe 5 FN[1] principales. Plus le niveau de normalisation est élevé, plus le modèle est exempte de redondances.
Pour parfaire une base de données relationnelle, il est nécessaire de connaître les trois premières FN[1] et la forme normale dite BoyceCodd ; les autres FN[1] ne sont que des extensions peu utilisée
Première forme normale (1FN)
Exemple : Exemple 1FN
Clients (NumCli, Nom, Prénom, Adresse, Téléphone)
Cette relation n'est pas en première forme normale, car Adresse n'est pas atomique.
Cette représentation si elle était mise en pratique générerait un accès aux données plus lent. Le simple fait de vouloir extraire les habitants d'une ville précise devra mettre en œuvre des procédures d'extraction de sous chaînes sans fournir de garantie quant au résultat retourné.
Voici une représentation 1FN[1] correcte :
Clients (NumCli, Nom, Prénom, Adresse, CodeP, Ville, Téléphone)
Deuxième forme normale (2FN)
Une relation est en 2FN Si :
Elle est en 1FN.
tous les attributs non clés sont complètement dépendants de la clé primaire.
Exemple : Exemple 2FN
Commande (Numcli, CodeArticle, Date, Qté commandée, Désignation)
Cette relation est elle en 1FN ? Oui.
Est elle en deuxième forme normale ? Non, car la propriété Désignation ne dépend pas intégralement de la clé (Numcli, CodeArticle, Date).
Voici comment corriger :
Commandes(Numcli, CodeArticle, Date, Qté commandée)
Articles(CodeArticle, Désignation)


Troisième forme normale (3FN)
Une relation est en 3FN Si :
Elle est en 2FN.
Tout attribut n'appartenant pas à une clé ne dépend pas d'un autre attribut non clé.
Exemple : Exemple1 3FN
Véhicule (NV, Type, Marque, Puissance, Couleur) cette relation n'est pas en 3FN car :
L'attribut non clé Type → Marque et Type → Puissance.
Cette relation peut être décomposée en deux relations
Véhicule (NV, Type, Couleur)
Modèle (Type, Marque, Puissance)


Exemple : Exemple2 3FN
La relation Commande(NuméroCommande, #CodeClient, Nom client, #RefArticle)
Est elle en première forme normale ?
Oui
Est elle en deuxième forme normale ?
Oui
Est elle en troisième forme normale ?
Non !
En effet Nom client dépend d'une propriété non clé : CodeClient
Voici comment corriger :
Commande(NuméroCommande, #CodeClient, #RefArticle)
Clients(CodeClient, Nom client)
Forme normale de Boyce-Codd (BCNF)
Boyce et Codd ont introduit une forme normale qui porte leur nom (Boyce Codd Normal Form/BCNF) :
Une relation est en forme normale de Boyce-Codd Si :
1 - Elle est en 3FN.
2 - les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé détermine un attribut. (Aucun attribut faisant partie de la clé dépend d'un attribut ne faisant pas partie de la clé)
Exemple : Exemple BCNF
Voici un exemple de la forme Boyce Codd


Quatrième forme normale (4FN)
Une relation est en quatrième forme normale si et seulement si :
Elle est en BCNF.
Lorsqu'il existe une dépendance multivaluée élémentaire, celle ci est unique.
Une dépendance à valeurs multiples existe toujours si deux attributs non liés dépendent du même attribut,
Exemple : Exemple 4FN
Le tableau suivant indique quels produits ont été commandés par client et à quel code postal ils doivent être livrés.

Par exemple, le client portant le numéro de client 234 a commandé les articles 1-0023-D et 2-0023-D qui doivent être livrés à son adresse au code postal 12345. Pour le client 567, les articles 1-0023-D, 3-0023-D, 4-0023-D, 4-0023-D et 5-0023-D seront livrés sous le code postal 56789.
l'attribut numéro de produit et l'attribut code postal dépendent tous deux de l'attribut numéro client, mais ne sont pas liés l'un à l'autre.
L'inconvénient d'une telle conception de base de données est que chaque fois qu'un nouveau produit est ajouté à l'enregistrement du client, le code postal doit également être ajouté, ce qui entraîne des données redondantes.
Ces redondances peuvent être éliminées en convertissant le tableau en 4FN. Pour ce faire, vous devez diviser la table

Cinquième forme normale (5FN)
Cette forme normale n'étant quasiment jamais utilisée, en voici juste la définition :
Une relation est en cinquième forme normale si et seulement si :
Elle est en quatrième forme normale.
Le tableau ne peut pas être divisé davantage sans perdre des informations.
La cinquième forme normale est une généralisation de la quatrième forme normale qui nécessite de prendre en compte les dépendances de jointure induites par la connaissance des clés d'une relation.
la jointure est l'opération permettant d'associer plusieurs tables ou vues de la base par le biais d'un lien logique de données entre les différentes tables ou vues
Remarque :
Ces formes normales évitent principalement la redondance d'information, elles sont plus précises.
En pratique la 3FN est suffisante. En effet, les autres formes sont coûteuses pour le système, ainsi une trop forte normalisation diminue fortement les performances
Quelques exemples
Voici un exemple illustrant les différentes formes normales.
Exemple : Exemple de normalisation
Voici une table non normalisée

Table normalisée avec 1FN
Table normalisée avec 2FN

Table normalisée avec 3FN
Dans le tableau "Facture", le nom et le prénom, l'adresse, la ville, l'état et le code postal dépendent non seulement de la clé primaire (le numéro de facture), mais aussi du numéro du client.
Dans le tableau "Poste de facture", les attributs produits et prix dépendent non seulement de la clé primaire, dérivée du numéro de facture et du numéro de poste de facture, mais aussi du numéro de produit. Cette condition spécifique viole également la troisième forme normale.

Pour supprimer toutes les dépendances entre les attributs non clés, les attributs pertinents ont été déplacés dans des tables séparées, reliées entre elles par des clés étrangères. Il en résulte les quatre tableaux normalisés : "Facture", "Client", "Poste de Facture" et "Produit".

Exercices : Série de TD 05
Voici une série d'exercices concernant la normalisation des relations.