2.2.5 Normalisation d'un schéma
Tables mal construites
Exemple : fournisseurs de composants électroniques:
$$\textbf{Fournisseur}(\underline{\text{nom_f, composant}}, \text{adresse_f, 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?
$$\textbf{Fournisseurs} (\text{nom_f, adresse_f})$$
$$\textbf{Catalogue}(\text{composant, prix})$$
–> Impossible de retrouver les prix pratiqués par les différents fournisseurs.
- Nouveau Schéma :
$$\textbf{Fournisseurs} (\text{nom_f, adresse_f})$$
$$\textbf{Catalogue}(\text{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:
- Voir:
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