Télécharger - Les Masters de l`ESC Alger

Report
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
 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é
 101
 104
 112
 103
300
1000
78
250
NumFour
901
902
904
901
Adresse
place 1 mai
emir aek, alger
avenue 1 nov
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)
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

similar documents