public:std-3:cm1:aspect_logique: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
Prochaine révision		 Révision précédente
public:std-3:cm1:aspect_logique:2.2.5_normalisation_d_un_schema [2016/09/05 10:58] – edaucepublic:std-3:cm1:aspect_logique:2.2.5_normalisation_d_un_schema [2016/09/06 14:32] (Version actuelle) – edauce
Ligne 1: Ligne 1:
 +====2.2.5 Normalisation d'un schéma====
 +__**Tables mal construites**__
 +<note>
 +** 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?
 +<note warning>
 +$$\textbf{Fournisseurs} (\text{nom_f, adresse_f})$$
 +$$\textbf{Catalogue}(\text{composant, prix})$$
 +</note>
 +--> Impossible de retrouver les prix pratiqués par les différents fournisseurs.
 +
 +
 +  * Nouveau Schéma :
 +<note tip> 
 +$$\textbf{Fournisseurs} (\text{nom_f, adresse_f})$$
 +$$\textbf{Catalogue}(\text{nom_f, composant, prix})$$
 +</note>
 +--> Il est possible de reconstruire la table initiale en effectuant une jointure entre ces 2 tables sur l’attribut ''nom_f''.
 +
 +
 +</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//:
 +  * Voir:
 +    * [[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 schéma:3ème 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]]