2.2.5 Normalisation d'un schéma
Tables mal construites
Exemple de table mal construite (fournisseurs de composants électroniques):
Fournisseur(nom_f, adresse_f,composant, prix)
- Problèmes :
- Redondance : l’adresse des fournisseurs est répétée plusieurs fois
- Inconsistance : mauvaise mise à jour ⇒ adresses différentes pour un même fournisseur.
- Problème Insertion : on ne peut pas insérer dans la table un fournisseur qui ne fournit rien
- Problème suppression : si un fournisseur ne fournit plus rien, on perd son adresse
- Solution?
- Couper la table en 2?
Fournisseurs (nom_f, adresse_f) Catalogue(composant, prix)
–> Impossible de retrouver les prix pratiqués par les différents fournisseurs.
- Nouveau Schéma :
Fournisseurs (nom_f, adresse_f) Catalogue(nom_f, composant, prix)
–> Il est possible de reconstruire la table initiale en effectuant une jointure entre ces 2 tables sur l’attribut nom_f.
Exercice : Les tables suivantes sont-elles bien ou mal construites?
Enseignement(id_enseignant, nom_enseignant, matière, id_élève, nom_élève)
Arrêt (num_train, horaire, nom_gare, ville)
Facture(id_client, article, date, montant)
Les Formes normales
- Restreignent les dépendances admises dans un schéma relationnel
- Permettent d’éviter la duplication de l’information au sein des relations
- Définissent une méthode de décomposition d’un schéma relationnel redondant en plusieurs schémas liés entre eux:
Previous : 2.2.4 Clé d'une relation Up : 2.2 Aspect logique Next : 2.2.6 Exemple -- Création d’un schéma de table en SQL