Chapitre 3 La normalisation du modèle relationnel

Présentation au sujet: "Chapitre 3 La normalisation du modèle relationnel"— Transcription de la présentation:

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

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

3 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 ?".

4 Dépendance fonctionnelle à partie gauche composée

5 Dépendance fonctionnelle élémentaire

6 Dépendance fonctionnelle directe

7 Graphe de DF

8 Exemple de DF: graphe?

9 Graphe de l’exemple

10 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.

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

12 Problème de la redondance
ex. Soit la relation COMMANDE_PRODUIT. NumProd Quantité NumFour Adresse place 1 mai emir aek, alger avenue 1 nov place 1 mai

13 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

14 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.

15 La 1ére forme normale(1FN)

16 La 1ére forme normale(1FN)

17 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é.

18 La 2ème forme normale(2FN)

19 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é.

20 La 3ème forme normale(3FN)

21 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)

22 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.

23 Besoin en normalisation

24 Besoin en normalisation

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

26 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.

27 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.

28 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