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 Boyce­Codd ; les autres FN[1] ne sont que des extensions peu utilisée

Première forme normale (1FN)

Une relation est en 1FN[1] si tout attribut contient une valeur atomique (non divisible).

ExempleExemple 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)

Exemple 1FN

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.

ExempleExemple 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)

Exemple 2FN
Solution exemple 2FN

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é.

ExempleExemple1 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 3FN
Solution exemple 3FN

ExempleExemple2 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é)

ExempleExemple BCNF

Voici un exemple de la forme Boyce Codd

Exemple de la forme Boyce Codd
Solution de l'exemple de la forme de 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,

ExempleExemple 4FN

Le tableau suivant indique quels produits ont été commandés par client et à quel code postal ils doivent être livrés.

Exemple 4FN

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

Solution exemple 4FN

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.

ExempleExemple de normalisation

Voici une table non normalisée

Table non normalisée

Table normalisée avec 1FN

Table normalisée avec 1FN

Table normalisée avec 2FN

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".

Normalisation de l'exmple

Exercices : Série de TD 05

Voici une série d'exercices concernant la normalisation des relations.