Embed Size (px)
Citation preview
CHAPITRE 3
LA NORMALISATION DU MODÈLE RELATIONNEL
Master 1, ESC 2011-2012
plan
Les dépendances fonctionnellesDéfinitions, types, graphe
Normalisation des relations objectifs, les 3 Formes normales ,
besoins, exemples
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. R1R2. 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 (DF)
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 Adresse101 300 901 place 1
mai104 1000 902 emir
aek, alger112 78 904 avenue
1 nov103 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 suppressiondu 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)
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
