Chapitre 3 La normalisation du modèle relationnel Master 1, ESC 2011-2012  Chapitre 3 La normalisation du modèle relationnel

plan Les dépendances fonctionnelles Définitions, types, graphe Normalisation des relations objectifs, les 3 Formes normales , besoins, exemples

dépendance fonctionnelle (DF) Deux rubriques R1 et R2 sont dites en Dépendance Fonctionnelle si le fait de connaître la valeur de R1 permet de connaître une valeur et une seule de R2. R1R2. R1 et la source de la DF et R2 le but Ex: numéro client----- nom client matricule étudiant ---- âge, adresse, La question fondamentale à se poser est : "Connaissant une valeur de la source, peut-on connaître une valeur unique du but ?".

Dépendance fonctionnelle à partie gauche composée

Dépendance fonctionnelle élémentaire  

Dépendance fonctionnelle directe

Graphe de DF

Exemple de DF: graphe?

Graphe de l’exemple

La normalisation relationnelle L'objectif est de construire un schéma de base de données cohérent. Un mauvais schéma logique peut conduire à un certain nombre d'anomalies pendant la phase d'exploitation de la base de donnée. un modèle relationnel est normalisé, s’il respecte certaines contraintes appelées les formes normales. Les formes normales s’appuient sur les dépendances fonctionnelles entre attributs.

Objectifs de la normalisation élimination des redondances : Minimisation de l’espace de stockage Suppression des problèmes de mise à jour

Problème de la redondance ex. Soit la relation COMMANDE_PRODUIT. NumProd Quantité NumFour Adresse 101 300 901 place 1 mai 104 1000 902 emir aek, alger 112 78 904 avenue 1 nov 103 250 901 place 1 mai

les problèmes de mise à jour Anomalies de modification Si l’on souhaite mettre à jour l’adresse d’un fournisseur, il faut le faire pour tous les tuples concernés. Anomalies d’insertion : Pour ajouter un fournisseur nouveau, il faut obligatoirement fournir des valeurs pour NumProd et Quantité. Anomalies de suppression : ex. La suppression du produit 104 fait perdre toutes les informations concernant le fournisseur 902

La 1ére forme normale(1FN) Définition : Une relation est en 1FN si : Tous ses attributs sont élémentaires ; La relation possède une clé primaire. Il faut rappeler qu’un attribut est élémentaire lorsqu’il ne peut pas se décomposer. C’est à dire que l’attribut ne peut pas être un ensemble de plusieurs éléments.

La 1ére forme normale(1FN)

La 1ére forme normale(1FN)

La 2ème forme normale(2FN) Une relation est en 2FN si : Elle est en 1FN ; Chacun des attributs ne faisant pas partie de la clé primaire est en Dépendance Fonctionnelle élémentaire avec la clé primaire. Remarque : Une relation en 1FN avec un seul attribut comme clé primaire est automatiquement en 2FN. Cela signifie que le problème se pose uniquement pour les tables qui ont une clé primaire composée.   Rappel : un attribut est en dépendance fonctionnelle élémentaire avec la clé primaire lorsqu’il n’est en dépendance fonctionnelle avec aucune partie de la clé.

La 2ème forme normale(2FN)

La 3ème forme normale(3FN) Une relation est en 3FN si : Elle est en 2FN ; Chacun des attributs ne faisant pas partie de la clé primaire est en Dépendance Fonctionnelle élémentaire et directe avec la clé primaire et uniquement avec elle.   Rappel : un attribut est en dépendance fonctionnelle directe avec la clé primaire lorsque cette dépendance fonctionnelle n’est pas obtenue par transitivité.

La 3ème forme normale(3FN)

Modèle relationnel normalisé = relations avec Résumé Modèle relationnel normalisé = relations avec une clé, qui permet de distinguer chaque occurrence des attributs élémentaires (1FN) en dépendance de TOUTE la clé (2FN), et RIEN QUE de la clé (3FN)

Besoins en normalisation relationnelle La normalisation des relations est nécessaire pour éviter des problèmes de mises à jour et de redondances. Il suffit de se baser sur les Dépendances Fonctionnelles élémentaires et directes.

Besoin en normalisation

Besoin en normalisation

exemples FOURNISSEUR (Numfr, Nomfr, AdCPfr, Villefr, Telfr) LIGNE_PRODUIT (#Numfac, #Refproduit, Quantité, Datefac) PRODUITS (Refproduit, Designproduit, Numcateprod, Prixproduit) Normalisation de ces relations?

Exemple 1 FOURNISSEUR (Numfr, Nomfr, AdCPfr, Villefr, Telfr) : Cette relation n'est pas en première forme normale car l'attribut AdCPfr n'est pas élémentaire. Il contient deux informations : l'adresse et le code postal du fournisseur. FOURNISSEUR (Numfr, Nomfr, Adfr, CPfr, Telfr) : Cette relation est en première forme normale car tous les attributs sont élémentaires et en dépendance fonctionnelle de la clé primaire : la connaissance du numéro d'un fournisseur permet d'obtenir, sans risque d'erreur, son nom, son adresse, son code postal, sa ville et son numéro de téléphone.

Exemple 2 LIGNE_PRODUIT (#Numfac, #Refproduit, Quantité, Datefac) : Cette relation n'est pas en deuxième forme normale car l'attribut Datefac ne dépend pas de l'intégralité de la clé primaire (#Numfac, #Refproduit) mais que d'une partie de celle-ci (#Numfac). La connaissance du numéro de la facture permet d'obtenir sa date. LIGNE_PRODUIT (#Numfac, #Refproduit, Quantité) : Cette relation est en deuxième forme normale car tous les attributs dépendent de l'intégralité de la clé primaire. La quantité de produits facturés dépend du numéro de la facture et de la référence du produit. En l'absence d'une seule de ces valeurs, il n'est pas possible de connaître de manière sûre et certaine la quantité de produits facturés.

Exemple 3 PRODUITS (Refproduit, Designproduit, Numcateprod, Prixproduit) : Cette relation n'est pas en troisième forme normale si l'attribut Prixproduit dépend de la catégorie de produit. On devrait avoir : PRODUITS (Refproduit, Designproduit, #Numcateprod) et CATEGORIE_PRODUIT (Numcatproduit, Catproduit, Prixproduit). La relation PRODUIT est en troisième forme normale car tous les attributs dépendent exclusivement de la clé primaire