public:std-3:cm1:aspect_physique:2.2.5_normalisation_d_un_schema

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
public:std-3:cm1:aspect_physique:2.2.5_normalisation_d_un_schema [2016/09/05 10:18] – edaucepublic:std-3:cm1:aspect_physique:2.2.5_normalisation_d_un_schema [2017/02/28 20:01] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. 66.249.64.149
Ligne 1: Ligne 1:
 +====2.2.5 Normalisation d'un schéma====
  
 +**__Tables mal construites__**
 +
 +<note>
 +**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?
 +<note warning>
 +    * Couper la table en 2?
 +  <code>
 +  Fournisseurs (nom_f, adresse_f)
 +  Catalogue(composant, prix)
 +  </code>
 +--> Impossible de retrouver les prix pratiqués par les différents fournisseurs.
 +</note>
 +<note tip> 
 +  * Nouveau Schéma :
 +  <code>
 +  Fournisseurs (nom_f, adresse_f)
 +  Catalogue(nom_f, composant, prix)
 +  </code>
 +--> Il est possible de reconstruire la table initiale en effectuant une jointure entre ces 2 tables sur l’attribut ''nom_f''.
 +</note>
 +
 +</note>
 +
 +<note>
 +**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)
 +</note>
 +
 +**__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:
 +    * [[public:STD-3:CM1:Aspect logique:2.2.5 Normalisation d'un schéma:2ème forme normale (2FN)]]
 +    * [[public:STD-3:CM1:Aspect logique:2.2.5 Normalisation d'un schéma:Normalisation 2FN]]
 +    * [[public:std-3:cm1:aspect_logique:2.2.5_normalisation_d_un_schema:3eme_forme_normale_3fn]]
 +    * [[public:STD-3:CM1:Aspect logique:2.2.5 Normalisation d'un schéma:Normalisation 3FN]]
 +
 +__Previous__ : [[public:STD-3:CM1:Aspect logique:2.2.4 Clé d'une relation]]
 +__Up__ : 2.2 [[public:STD-3:CM1:Aspect logique]]
 +__Next__ : [[public:STD-3:CM1:Aspect logique:2.2.6 Exemple -- Création d’un schéma de table en SQL]]