test

1. Plan du Cours de BD & SGBD
• Chapitre 1 : Introduction
• Chapitre 2 : Conception de bases de Données
• Chapitre 3: Le modèle entité-relation
• Chapitre 5 : Le modèle relationnel
• Chapitre 6 : Algèbre relationnelle et SQL
Marielle Delhom 1

2. Chapitre 5 :
Le Modèle
Relationnel
2

3. I. Introduction (1)
• Le modèle relationnel a été introduit par E.F. CODD, à la
fin des années 1970, qui travaillait dans le centre de
recherche d’IBM San-José.
• Facile à appréhender, même pour un non spécialiste, il
repose sur de solides bases théoriques qui permettent
notamment de définir de façon formelle les langages de
manipulation associés.
• Il a ensuite été complété en 1976 par DATE et en 1982 par
CODD
Marielle Delhom 3

4. I. Introduction (2)
• La première volonté du modèle relationnel fut d’être un
modèle ensembliste simple.
• Il propose de percevoir les données (objets et associations
du monde réel) sous une forme simple de tables (ou
relations)
Exemple
Marielle Delhom 4
2014101 Susini Jean 20
2014202 Gambini Marie 19
2013256 Martin Paul 18
2012100 Battesti Armand 19

5. I. Introduction (3)
• Depuis les années 70, le modèle relationnel a fait l'objet de
très nombreuses recherches qui ont débouché sur la
réalisation et la commercialisation de SGBDs relationnels.
• C'est le modèle le plus utilisé par les SGBDs actuellement
disponibles sur le marché.
Marielle Delhom 5

6. I. Introduction (4)
• Principaux objectifs du modèle relationnel
• Permettre un haut degré d’indépendance Données - Programmes d’application.
• Fournir une base solide pour traiter les problèmes de cohérence et de
redondance de données.
• Permettre le développement de LMD (Langage de Manipulation de Données)
non-procéduraux basés sur des théories solides.
Marielle Delhom 6

7. I. Introduction (5)
• Principaux objectifs du modèle relationnel (suite)
• Etre un modèle ensembliste permettant de modéliser et de
manipuler des données complexes.
C’est un objectif important car il a permis d’intégrer de nouveaux
concepts (exemple : les objets).
• Devenir un standard pour la description et la manipulation de
bases de données.
Cet objectif a été réalisé en particulier grâce à IBM (langage SQL).
Marielle Delhom 7

8. II Concepts de base
II.1 Domaine
II.2 Relation
II.3 Attribut
II.4 Tuple (ou enregistrements)
II.5 Clé d'une relation
II.6 Schéma d'une relation
II.7 Base de données relationnelle
II. 8 Résumé
Marielle Delhom 8

9. II.1 Domaine (1)
• Définition : Ensemble de valeurs caractérisé par un nom.
Exemple :
• Domaine des entiers : Entier = {0, ±1, ±2, ±3,....}
• Domaine des booléens : Logique = {0, 1}
• Salaire = 1000…100000 (€) - Intervalle
• Domaine des couleurs : Couleur = { vert, rouge,
blanc}
Marielle Delhom 9

10. II.1 Domaine (2)
• Le produit cartésien d’un ensemble de domaines D1,
D2,..., Dn, que l’on note D1 x D2 x....x Dn est l’ensemble
des n_uplets ou tuples (V1, V2, ..., Vn) tel que Vi  Di.
Ex : le produit cartésien Couleur x Logique
avec Couleur = {vert, rouge, blanc} et Logique = {0,
1}
donne les 6 tuples suivants :
Marielle Delhom 10
vert 0
vert 1
rouge 0
rouge 1
blanc 0
blanc 1

11. II.1 Domaine (3)
Exemple 1 :
le produit cartésien Couleur x Logique
avec Couleur = {vert, rouge, blanc}
Logique = {0, 1}
donne les 6 tuples suivants :
Marielle Delhom 11
vert 0
vert 1
rouge 0
rouge 1
blanc 0
blanc 1

12. II.2 Relation (1)
• Définition : Sous-ensemble du produit cartésien d’une liste de domaines caractérisé par un nom.
Exemple : La relation Vin est construite à partir des domaines
Couleur_vins = {rosé, blanc, rouge} et
Cru = {Bordeaux, Bourgogne, Alsace},
.
Marielle Delhom 12
Vin Couleur_vins Cru
rosé Bourgogne
rosé Alsace
blanc Bourgogne
rouge Bordeaux
rouge Bourgogne
rouge Alsace

13. II.2 Relation (2)
• La relation est le concept central du modèle relationnel
• Plus simplement, une relation est un tableau à deux dimensions
• Une ligne est un n-uplet ou tuple ou enregistrement
• Nom associé à chaque colonne afin de la repérer
indépendamment de l'ordre = attribut
• Associé à un un domaine
Marielle Delhom 13

14. II.3 Attribut
• Définition : Colonne d’une relation caractérisée par un
nom.
• Les attributs prennent leurs valeurs dans les domaines,
plusieurs attributs peuvent être définis sur le même
domaine.
Marielle Delhom 14
Vin Couleur_vins Cru
rosé Bourgogne
rosé Alsace
blanc Bourgogne
rouge Bordeaux
rouge Bourgogne
rouge Alsace
Couleur_vins et Cru sont
deux attributs de la
relation Vin

15. II.4 Tuple
• Définition : Ligne d’une relation correspondant à un
enregistrement (assignation de valeurs à chacun des
attributs d’une relation).
Marielle Delhom 15
Vin Couleur_vins Cru
rosé Bourgogne
rosé Alsace
blanc Bourgogne
rouge Bordeaux
rouge Bourgogne
rouge Alsace
Tuples ou N_uplets

16. II.5 Clé d’une relation
• Définition
Une clé est un groupe d'attributs minimum qui détermine
un n-uplet unique dans une relation (à tout instant)
• Contrainte d'intégrité
Toute relation doit posséder une clé renseignée (sans valeur
inconnue)
Marielle Delhom 16

17. II.6 Schéma d'une relation (1)
• Définition : Le schéma d'une relation décrit :
- Son nom
- La liste des attributs qu'elle comporte et des domaines associés
- La liste des attributs composant la clé (la clé est soulignée)
Notation : R(A1:D1, A2:D2,...., An:Dn)
avec : R : Nom de la relation
Ai : Attributs
Di : Domaine
Exemple :
Voiture (Num_véhic : entier, Marque : caract(10), Type : caract (4), Puiss : entier)
Client (NumClient : Entier, Nom : Carac(20), Prénom : Carac(15))
Vin (NV : entier, Cru : Caract (10), Millésime : entier, Degré : réel)
Marielle Delhom 17

18. II.6 Schéma d'une relation (2)
• Le schéma d’une relation représente son intention, c’est à dire
les attributs communs et invariants des tuples qu’elle va contenir
au cours du temps.
• Une table représente une extension d’une relation, c’est à dire
une vue des tuples qu’elle contient à un instant donné.
• Le degré ou arité d’une relation : nombre d’attributs de la
relation.
• La cardinalité d’une relation : nombre de tuples.
Marielle Delhom 18

19. II.6 Schéma d'une relation (3)
Donc :
Le schéma d’une relation représente son intention,
la table avec tous les tuples représente une extension de la relation.
L’intention est le résultat de la description des données
L’extension fait suite à des manipulations des données et représente l’état de la
base
Marielle Delhom 19

20. II.7 Base de données relationnelle
• Définition : base de données dont le schéma est un
ensemble de schémas de relations et dont les occurrences
sont des tuples de ces relations.
Marielle Delhom 20

21. II.8 Résumé (1)
• Les objets et associations du monde réel sont représentés
par un concept unique : la relation.
• Les relations sont des tableaux à deux dimensions appelés
aussi tables.
Chaque ligne (Tuple)
de la Relation correspond
à une occurrence
Etudiant NumEtud Nom Prénom Age
123 Dupont Jean 19
231 Susini Martin 21
121 Castelli Julie 21
134 Castelli Adrien 18
Nom de la
Relation ou de
la Table
Les entêtes des colonnes constituent les attributs
de la relation (l'identifiant est souligné)

22. II.8 Résumé (2)
• Un Domaine est un ensemble de valeurs que peut prendre un attribut (domaine de
définition de l'attribut)
Exemple : DnumEtud : entiers compris entre 0 et 9999
Dnom : chaîne de caractères de longueur max 20
Dprénom : chaîne de caractères de longueur max 15
Dâge : entiers compris entre 14 et 99
• Une relation est définie par :
• son nom
• la liste des couples (nom d'attribut : domaine)
• son identifiant
• sa définition (phrase en français)
Marielle Delhom 22

23. II.8 Résumé (3)
• Les trois premières informations (nom de la relation, liste des
couples (nom d'attribut : domaine) et l'identifiant) constituent
le schéma de la relation ou l'intention de la relation.
• L'ensemble des tuples d'une table constitue l'extension de la
relation
Exemple : Schéma de la relation Etudiant
Etudiant (NumEtud : DnumEtud, Nom : Dnom, Prénom : Dprénom, Age : Dâge)
Marielle Delhom 23

24. II.8 Résumé (4)
• On appelle Schéma d'une base de données
relationnelle l'ensemble des schémas de ses relations
• On appelle base de données relationnelle, les extensions
de toutes ses relations
Marielle Delhom 24

25. III Conception de Schémas Relationnels
III.1 Généralités
III.2 Décomposition
Marielle Delhom 25

26. III.1 Généralités (1)
• La première étape de la conception de bases de données
relationnelles est de concevoir les schémas relationnels
• Les schémas relationnels vont modéliser le monde réel que
l’on veut décrire => on obtient ainsi les entités et
associations du monde réel
Marielle Delhom 26

27. III.1 Généralités (2)
• Objectif : Obtenir un bon schéma
• Des relations problématiques peuvent apparaître si l’on a
mal conçu les relations.
Marielle Delhom 27

28. III.1 Généralités (3)
Exemple – Magasin de Jouets:
Marielle Delhom 28
no-bon date-bon ref-art libellé-art qté-art code-
famille
libellé-
famille
10 20/04/2014 SDF0875 Poupée
Barbie
200 JF jouets filles
10 20/04/2014 RMD7543 Monopoly 250 JS jeu de
société
18 25/04/2014 RMD7543 Monopoly 20 JS jeu de
société
... ... ... ... ... ... ...

29. III.1 Généralités (4)
Donc :
Une relation mal conçue peut faire apparaître des données
redondantes et des incohérences potentielles
On a donc intérêt à éviter ce type d’anomalie pour faciliter la
manipulation des relations
Marielle Delhom 29

30. III.2 Décomposition (1)
L’approche par décomposition permet de concevoir des
schémas relationnels
• A partir d’une relation composée de tous les attributs, que l’on
appelle relation universelle, on la décompose en sous-
relations qui ne comportent pas d’ anomalies.
• Ce processus va permettre de dégager les entités et
associations du monde réel et va être réalisé par un
algorithme de décomposition à partir d’une bonne
compréhension des propriétés sémantiques (sens des mots)
des données.
Marielle Delhom 30

31. III.2 Décomposition (2)
• Processus de décomposition :
Marielle Delhom 31
N°Etud
CodeDiplome
PrénomEtud
AdresseEtud
VilleEtud
CPEtud
LibelléDiplome
NomEtud
AgeEtud
Algorithme
De
Décomposition
Semantique
des données
Etudiant(N°Etud, NomEtud, PrenomEtud, AgeEtud, CPEtud, VilleEtd)
Diplôme(CodeDiplome, LibelléDiplome)

32. III.2 Décomposition (3)
La décomposition utilise deux opérations élémentaires :
- la projection
- la jointure
Marielle Delhom 32

33. III.2 Décomposition (4)
La Projection
• Opération qui consiste à supprimer les attributs d’une relation et à
éliminer les tuples en double qui risquent d’apparaître dans la nouvelle
relation obtenue.
• Définition : la projection de la relation R de schéma R(A1, A2, ...,
An) sur les attributs A1, A2, ..., Ap est une relation R’ de schéma
R’(A1, A2, ..., Ap) obtenue par élimination des valeurs des attributs de
R n’appartenant pas à R’ et par la suppression des tuples en double.
• Notation : A1, A2,..., Ap
Marielle Delhom 33

34. III.2 Décomposition (5)
• Exemple 1 : (relation Mag)
Marielle Delhom 34
 ref-art, libellé-art (Mag) Ref-art Libellé-art
SDF0875 Poupée Barbie
RMD7543 Monopoly
no-bon date-bon ref-art libellé-art qté-art code-
famille
libellé-
famille
10 20/04/2014 SDF0875 Poupée
Barbie
200 JF jouets filles
10 20/04/2014 RMD7543 Monopoly 250 JS jeu de
société
18 25/04/2014 RMD7543 Monopoly 20 JS jeu de
société
... ... ... ... ... ... ...

35. III.2 Décomposition (6)
• Exemple 2 :
Marielle Delhom 35
Etudiant Numéro Nom Année d’étude Diplôme
801 Pierre 1 Bac
825 Marie 3 Licence
956 Jean 1 Bac
 Année d’étude, Diplôme (Etudiant) Année d’étude Diplôme
1 Bac
3 Licence

36. III.2 Décomposition (7)
La Jointure
• La jointure naturelle (ou simplement jointure) est
l’opération inverse de la projection.
• Cette opération consiste à connecter deux relations qui
contiennent respectivement deux mêmes rubriques ou deux
mêmes ensembles de rubriques.
Marielle Delhom 36

37. III.2 Décomposition (8)
• La jointure de deux relations R et S de schémas respectifs
R(A1, A2, ..., An) et S(B1, B2, ..., Bp)
est une relation T ayant pour attribut l’union des attributs de R et
de S, soit {A1, A2, ..., An} U { B1, B2, ..., Bp} et pour tuples tous
ceux obtenus par concaténation de tuples de R et S ayant mêmes
valeurs pour les attributs de même nom.
On obtient ainsi :  A1, A2, ..., An (T) = R
 B1, B2, ..., Bp (T) = S
Marielle Delhom 37

38. III.2 Décomposition (9)
• La jointure naturelle de deux relations est notée R
S
 Opération commutative (RS = S R)
 Opération associative (((R S)V) = (R (SV))
Marielle Delhom 38

39. III.3 Décomposition (10)
• Exemple 1 :
39
R Marque Couleur S Couleur Puissance
Renault rouge rouge 6
Peugeot verte verte 9
Citroen bleue bleue 2
Renault verte bleue 5
verte 6
T = R  S Marque Couleur Puissance
Renault rouge 6
Peugeot verte 9
Peugeot verte 6
Citroen bleue 2
Citroen bleue 5
Renault verte 9
Renault verte 6

40. III.3 Décomposition (11)
• Exemple 2 :
Marielle Delhom 40
Etudiant Numéro Nom CodeDipl Diplomes CodeDipl NomDipl
2014010 Chiari S2I S2I Master S2I
2014315 Susini L1ST L1ST Licence1 S&T
2013818 Castelli L1ST L1ST Licence1 S&T
L2ST Licence2 S&T
Etudiant 
Diplome
Numéro Nom CodeDipl NomDipl
2014010 Chiari S2I Master S2I
2014315 Susini L1ST Licence1 S&T
2013818 Castelli L1ST Licence1 S&T

41. III.2 Décomposition (12)
Décomposition d’une relation
• C’est le remplacement d’une relation R(A1, A2, ..., An) par
une collection de relations R1, R2,..., Rm obtenues par des
projections de R et telles que la relation résultat des jointures
R1R2 R3.... Rn ait même schéma que R.
• Lors d’une décomposition, le schéma de la relation R(A1,
A2, ..., An) est remplacé par une collection de schémas dont
l’union des attributs est (A1, A2, ..., An).
Marielle Delhom 41

42. III.2 Décomposition (13)
Remarques :
• Il n’existe pas qu’une seule manière de décomposer les
relations
• Toutes les relations ne sont pas décomposables
Marielle Delhom 42

43. III.2 Décomposition (14)
Voiture Nv Marque Type Puissance Couleur
872 RH 2A Renault Clio 6 Bleue
975 AB 2B Renault Clio 6 Rouge
R1 Nv Type Couleur
872 RH 2A Clio Bleue
975 AB 2B Clio Rouge
R2 Type Marque Puissance
Clio Renault 6
A1 Nv Type
872 RH 2A Clio
975 AB 2B Clio
A2 Type Puissance Couleur
Clio 6 Bleue
Clio 6 Rouge
A3 Type Marque
Clio Renault

44. III.2 Décomposition (15)
• Si on admet qu’à un type de véhicule sont associées une seule
marque et une seule puissance, la décomposition 1 est meilleure.
• La décomposition 1 permet de retrouver toutes les informations
par jointure alors que la décomposition 2 ne permet pas de
retrouver la couleur d’un véhicule
•  la jointure A1 A2 A3 est différente de la relation initiale
Voiture.
Marielle Delhom 44

45. III.2 Décomposition (15)
Décomposition sans perte
• Décomposition d’une relation R en R1, R2, ..., Rn telle que
pour toute extension de R, on ait : R = R1 R2... Rn.
• La conception d’une base de données relationnelle peut être
vue comme une décomposition de la relation universelle,
composée de tous les attributs, en sous-relations ne souffrant
pas d’anomalies et réalisée de manière à obtenir une
décomposition sans perte.
Marielle Delhom 45

46. IV Dépendances fonctionnelles
IV.1 Définitions
IV.2 Propriétés des DF
IV.3 DF élémentaires
IV.4 DF élémentaires directes
IV.5 DF canoniques
IV.6 Graphe des DF
IV.7 Fermeture transitive et couverture minimale
Marielle Delhom 46

47. IV.1 Définitions (1)
• La notion de dépendance fonctionnelle (dépendance entre
données) fut introduite par CODD afin de caractériser des
relations qui peuvent être décomposées sans perte
d’informations.
Marielle Delhom 47

48. IV.1 Définitions (2)
Définition :
• Un attribut (ou groupe d’attributs) Y dépend fonctionnellement
d’un attribut (ou groupe d’attributs) X, si étant donné une valeur
de X, il lui correspond une valeur unique de Y et ceci quel que
soit l’instant considéré.
• On dit aussi que X détermine Y ou Y est fonctionnellement
dépendant de X et on note X  Y.
• X est appelée la Source et Y le But.
Marielle Delhom 48

49. IV.1 Définitions (3)
Exemple 1 :
N°Etudiant  Nom_Etudiant
• La connaissance de N°Etudiant détermine une et une seule valeur de
Nom_Etudiant
• Autrement dit, si on connaît le N°Etudiant, on doit pouvoir connaître son
nom et celui-ci sera unique
• Réciproque fausse : le nom de l'étudiant ne permet pas de déterminer son
numéro
Nom_Etudiant  N°Etudiant (faux)
Marielle Delhom 49

50. IV.1 Définitions (4)
Exemple 2 :
• La dépendance fonctionnelle peut porter sur la concaténation de plusieurs attributs
Ex : N°Bon_de_Commande,Ref  Quantité_Commandée
• Ref seule ne suffit pas à déterminer la quantité commandée
• N°Bon_de_Commande ne suffit à déterminer la quantité commandée
• La connaissance du numéro de bon ET de la référence détermine celle de la quantité
commandée
Marielle Delhom 50

51. IV.2 Propriétés des Dépendances Fonctionnelles (1)
• Les DF obéissent à 3 règles (Axiomes d’Amstrong).
Réflexivité : Si Y  X  X  Y
Tout ensemble détermine lui-même ou une partie de lui-même.
Augmentation : X  Y  X, Z  Y, Z
Si X détermine Y, les deux ensemble d’attributs peuvent être enrichis par un
troisième.
Transitivité : X  Y et Y  Z  X  Z
Ex : N°_Véhicule  Type et Type  Puissance
 N°_Véhicule  Puissance
Marielle Delhom 51

52. IV.2 Propriétés des Dépendances Fonctionnelles (2)
• Autres règles se déduisant de ces axiomes :
Pseudo-transitivité X  Y et W, Y  Z  W, X  Z
Union X  Y et X  Z  X  Y, Z
Décomposition X  Y et Z  Y  X  Z
Marielle Delhom 52

53. IV.3 Dépendances Fonctionnelles élémentaires (1)
• Dépendance fonctionnelle de la forme X  Y , où Y est un
attribut unique non inclus dans X et où il n’existe pas X’ 
X tel que X’  Y.
(X est l'ensemble minimum d'attributs déterminant Y)
• Autrement dit, on dit qu’il y a dépendance fonctionnelle
élémentaire entre les attributs X et Y si aucune partie de X
ne détermine Y.
Marielle Delhom 53

54. IV.3 Dépendances Fonctionnelles élémentaires (3)
Exemple 1 :
Code_Client, Nom_Client  Adresse_Client
Ce n’est pas une DF élémentaire puisque la connaissance de Code_Client suffit à
déterminer l’adresse.
Code_Client  Adresse_Client est une DF élémentaire.
Exemple 2 :
N°Bon_de_Commande, Ref  Quantité_Commandée
est une DF élémentaire.
Marielle Delhom 54

55. IV.4 Dépendances Fonctionnelles élémentaires
directes (1)
On dit que l’attribut Y dépend fonctionnellement de X par
une dépendance fonctionnelle élémentaire directe si cette
dépendance est élémentaire et s’il n’existe pas de propriété
Z telle que : X  Z et Z  Y.
On élimine toute transitivité
Marielle Delhom 55

56. IV.4 Dépendances Fonctionnelles élémentaires
directes (2)
Exemple :
N°Prof  Code_Matière
Code_Matière  Nom_Matière
N°Prof  Nom_Matière
Les deux premières DF sont directes mais la troisième ne l’est pas en
raison de la transitivité.
N°Prof  Code_Matière  Nom_Matière
Marielle Delhom 56

57. IV.5 Dépendances Fonctionnelles canoniques
• Une dépendance fonctionnelle est dite Canonique si sa partie droite
se réduit à un seul attribut.
Exemple :
La DF N°Facture  N°Représentant est canonique
La DF N°Facture  N°Représentant, Nom_Représentant n ’est pas
canonique
Marielle Delhom 57

58. IV.6 Graphe des Dépendances Fonctionnelles (1)
Soit un ensemble de DF élémentaires.
Dans le cas où tous les attributs gauches sont uniques, il est
possible de réaliser le graphe des dépendances
fonctionnelles.
Marielle Delhom 58

59. IV.6 Graphe des Dépendances Fonctionnelles (2)
Exemple :
Soit l’ensemble des DF entre les attributs de la relation
voiture.
F = {NV  Type; Type  Marque, Type  Puissance;
NV  Couleur}
Marielle Delhom 59
NV
Couleur
Type
Marque
Puissance

60. IV.6 Graphe des Dépendances Fonctionnelles (3)
• Dans le cas où une partie gauche d’une dépendance
fonctionnelle comporte plus d’un attribut, il faut introduire
des arcs représentant une association de plusieurs sommets
vers un sommet.
Exemples :
60
Type Marque
Puissance
N°Cde N°Produit
Quantité

61. IV.7 Fermeture transitive et Couverture minimale (1)
• A partir d’un ensemble des DF élémentaires, par transitivité, on
peut composer d’autres DF.
• On aboutit ainsi à la notion de fermeture transitive d’un ensemble
F de DF élémentaires.
Fermeture Transitive :
Ensemble des DF élémentaires considérées, enrichi de toutes les
DF élémentaires déduites à l ’aides des axiomes d ’Amstrong (DF
déductibles et non déductibles).
Marielle Delhom 61

62. IV.7 Fermeture transitive et Couverture minimale (2)
Exemple :
F = {NV  Type; Type  Marque, Type  Puissance; NV
 Couleur}
Fermeture transitive : F+
= F  {NV  Marque; NV 
Puissance}
Graphe correspondant à F+
:
Marielle Delhom 62
NV
Couleur
Type
Marque
Puissance

63. IV.7 Fermeture transitive et Couverture minimale (3)
• Equivalence de deux ensembles de DF : deux tels
ensembles sont équivalents s’ils ont la même fermeture
transitive.
• Par la suite, il est intéressant de déterminer un sous-
ensemble minimum de dépendances fonctionnelles
permettant de générer toutes les autres.
Marielle Delhom 63

64. IV.7 Fermeture transitive et Couverture minimale (4)
• Couverture minimale :
Ensemble F de DF élémentaires associé à un ensemble
d’attributs vérifiant les propriétés suivantes :
• Aucune dépendance dans F n’est redondante ; c’est à dire que pour
toute dépendance fonctionnelle f de F, F-f n’est pas équivalent à F
• Toute dépendance élémentaire des attributs est dans la fermeture
transitive de F (notée F+
) .
Marielle Delhom 64

65. IV.7 Fermeture transitive et Couverture minimale (5)
• Tout ensemble de DF a une couverture minimale
Exemple :
F = {NV  Type; Type  Marque, Type  Puissance; NV 
Couleur}
F est une couverture minimale pour l’ensemble des dépendances
fonctionnelles de Voiture
Marielle Delhom 65

66. V Normalisation
V.1 Clé d’une relation
V.2 Normalisation
Marielle Delhom 66

67. V.1 Clé d’une relation (1)
• L’ensemble minimum d’attributs d’une relation pouvant
déterminer tous les autres est appelé Clé.
• La clé détermine un n-uplet de façon unique.
Exemple :
Elève(Num_elv, Nom_elv, Pren_elv, Adres_elv,,DatNais_elv, Uv)
Marielle Delhom 67

68. V.1 Clé d’une relation (2)
• Définition : Clé d’une relation
Sous-ensemble X des attributs d’une relation R(A1, A2, A3, ...,
An) tel que :
1) X  A1, A2, ..., An
2) Il n’existe pas de sous-ensemble Y  X tel que
Y  A1, A2, ..., An (DF élémentaire)
• Il peut y avoir plusieurs clefs pour une même relation ; on en
choisi en général une comme clé primaire. On parle parfois de
clé candidate pour désigner une clé quelconque.
Marielle Delhom 68

69. V.2 Normalisation (1)
• BUT : Eliminer les redondances et incohérences
• La normalisation constitue un ensemble de règles introduites
dans le modèle relationnel dès son origine
• Le concept de forme normale d’une relation a été introduit par
CODD en proposant une classification en trois formes
normales.
• Cette classification repose sur la notion de dépendance
fonctionnelle. Marielle Delhom 69

70. V.2 Normalisation (2)
• A l’exception de la 1ère FN, les autres formes normales permettent de caractériser le
degré de redondance et d’incohérence des relations.
Plus le degré de normalisation est élevé, moins il y a de redondances et moins il y a de
risque d’anomalies lors la manipulation des relations.
• La normalisation est une technique qui permet une décomposition successive
70
1FN 2FN 3FN BCFN
Relation non normalisée

71. V.2 Normalisation (Resumé)
• Normaliser une base, c'est imposer des règles de
construction à sa structure afin de respecter la cohérence
des données et éviter toute redondance d'informations.
• Il existe cinq formes normales mais, en pratique, on estime
qu'une base est normalisée qd arrivé à FN3si elle respecte
les trois premières formes.
Marielle Delhom 71

72. V.2 Normalisation (3)
Première forme normale (1FN)
Une relation est en première forme normale si :
• elle possède une clé
• contient une valeur atomique (non multiple, non composée).
Exemple :
Personne(Num, Nom, Prénom, Adresse) n’est pas en 1FN car
l’adresse est composite et correspond à la concatenation de
Code_postal et Ville.
Personne(Num, Nom, Prénom, Code_postal, Ville) est en 1FN.
Marielle Delhom 72

73. V.2 Normalisation (4)
Deuxième forme normale (2FN)
Une relation R est en 2FN si :
 R est en 1FN
 Tout attribut n’appartenant pas à une clé ne dépend pas d’une
partie de cette clé (tout attribut doit dépendre fonctionnellement
de la totalité de la clé) – DF Elementaire
Autrement dit il faut éviter la configuration suivante :
Marielle Delhom 73
R(A, B, C, D, E)

74. V.2 Normalisation (5)
Exemple 1:
Soit une relation qui est en 1FN mais qui n'est pas en 2FN :
Fournisseur(NF,NomProduit,Adr,CP, Ville, Tel, Prix)
On a les DF suivantes :
NF  Adr,CP, Ville, Tel et (NF,NomProduit)  Prix
Problèmes :
• s'il existe 50 produits pour un fournisseur, on va répéter 50 fois les informations concernant
le fournisseur
• si un fournisseur change de numéro de téléphone, il faut faire cette mise à jour sur les 50
tuples
• ...
Marielle Delhom 74

75. V.2 Normalisation (6)
Solution : on décompose la relation Fournisseur en 2
relations qui sont en 2FN:
Fournisseur(NF,NomProduit,Adr,CP, Ville, Tel, Prix)
Fournisseur(NF, Adr,CP, Ville, Tel)
Catalogue(NF, NomProduit, Prix)
Marielle Delhom 75

76. V.2 Normalisation (7)
Exemple 2 :
La relation Ligne_Cde (N°Cde, Ref, Désignation, Qté) n’est pas en 2FN car :
la clé est la concaténation de N°Cde et Ref mais on a la DF :
Ref  Désignation
Solution : on décompose la relation Ligne_Cde en 2 relations qui sont en 2FN :
Ligne_Cde(N°Cde, Ref, Qté)
Produit(Ref, Désignation)
Marielle Delhom 76

77. V.2 Normalisation (8)
Troisième forme normale (3FN)
Une relation R est en 3FN si :
 R est en 2FN
 Tout attribut n’appartenant pas à une clé ne dépend pas d’un
attribut non clé
Autrement dit il faut éviter la configuration suivante :
Marielle Delhom 77
R(A, B, C, D, E)

78. V.2 Normalisation (9)
La 3FN est importante car toute relation a au moins une
décomposition en 3FN telle que :
• la décomposition préserve les DF
• la décomposition est sans perte
Marielle Delhom 78

79. V.2 Normalisation (10)
Exemple : Voiture(Nv, Marque, Type, Puissance, Couleur)
On admet deux types de décompositions :
D1 : qui préserve les DF:
R1 (Nv, Type, Couleur)
R2(Type, marque, Puissance)
D2 : qui ne préserve pas les DF car il manque la DF : Nv  Couleur
R’1 (Nv, Type)
R’2(Type, Puissance, Couleur)
R’3(Type, Marque)
Marielle Delhom 79

80. V.2 Normalisation (11)
Forme normale de Boyce-Codd (FNBC)
• Une relation R est en FNBC si
 elle est en 3FN
 les seules DF élémentaires sont celles dans lesquelles une clé
détermine un attribut
• Autrement dit il faut éviter la configuration suivante :
Marielle Delhom 80
R(A, B, C, D, E)

81. V.2 Normalisation (12)
Exemple : Vins(Crus, Pays, Région)
 la clé est Crus + Pays
 on a les DF suivantes Région  Pays
Crus, Pays  Région
Cette relation est en 3FN (aucun attribut non clé ne dépend
d’une partie de la clé ou d’un attribut non clé) par contre
elle n’est pas en FNBC (problèmes de redondances).
Marielle Delhom 81

82. V.2 Normalisation (13)
Une décomposition en FNBC ne préserve en général pas les DF.
Exemple : Vins est décomposé en 2 relations qui sont en FNBC :
Crus(Crus, Région)
Région(Région, Pays)
La DF Crus,Pays  Région est perdue, mais il est possible de
recomposer la relation initiale par jointure des deux relations sur
l’attribut Région.
Marielle Delhom 82

83. VI Méthode de conception de schémas relationnels
Démarche :
1 - Recenser les attributs
2 - Recenser les Dépendances Fonctionnelles
3 - Rechercher la Couverture Minimale
4 - Concevoir le MCD
5 - Concevoir le Schémas relationnel de la base de données
Marielle Delhom 83

84. VI.1 Recenser les attributs
• Pour recenser les attributs, il n'y a pas à priori de méthode
 Essayer de recenser à partir des différents documents existants les
informations utilisées
 De nouvelles informations peuvent apparaître
Marielle Delhom 84

85. VI.2 Recenser les DF
• Pour recenser les DF, il n'y a pas non plus de méthode
formelle
Marielle Delhom 85

86. VI.3 Recherche de la Couverture Minimale
• Rechercher la couverture minimale correspondante
Marielle Delhom 86

87. Exemple (1)
Soit R = {N°commande, Date_Commande, N°client,
adresse_livraison, raison_sociale, N°représentant,
Nom_représentant, date_du_jour, quantité_commandée,
référence_produit, désignation, quantité_en_stock, nb_cl
(nombre de client visités par un représentant un jour donné)}
Contraintes :
- Dans une commande, plusieurs produits peuvent être
commandés.
- Un client n’est visité que par un seul représentant.
Marielle Delhom 87

88. Exemple (2)
DF1 : N°commande  date_commande
N°commande  N°client
N°commande  adresse_livraison
N°commande  raison_sociale
N°commande  N°représentant
N°client  raison_sociale
N°client  adresse_livraison
N°client  N°représentant
N°représentant  nom_représentant
référence  désignation
référence  quantité_en_stock
N°client  nom_représentant
N°commande, référence  quantité_commandée
Date_du_jour, N°représentant  nb_cl
Marielle Delhom 88

89. Exemple (3)
Couverture Minimale :
N°commande  date_commande
N°commande  N°client
N°client  raison_sociale
N°client  adresse_livraison
N°client  N°représentant
N°représentant  nom_représentant
référence  désignation
référence  quantité_en_stock
N°commande,référencequantité_commandée (DF2)
date_du_jour, N°représentant  nb_cl (DF3)
Marielle Delhom 89

90. Exemple (4)
Marielle Delhom 90
N°Commande
date_commande N°Client
référence
quantité_en_
stock
désignation
raison_sociale
N°représentant
adresse_livraison
nom_représentant
date_du_jour
nb_cl
quantité_commandée

91. Rappel de la Démarche
Démarche :
1 - Recenser les attributs
2 - Recenser les Dépendances Fonctionnelles
3 - Rechercher la Couverture Minimale
4 - Concevoir le MCD
5 - Concevoir le Schémas relationnel de la base de données
Marielle Delhom 91

92. VI.4 Conception du MCD (1)
A partir de la couverture minimale, on va construire le MCD.
4 Etapes :
1. Définition de l’ensemble des identifiants
2. Recherche des entités
3. Recherche des relations
4. Recherche des propriétés
Marielle Delhom 92

93. VI.4 Conception du MCD (2)
Etape 1 : Définition de l’ensemble des identifiants
• L’ensemble des attributs sources des dépendances fonctionnelles, A,
constitue l’ensemble des identifiants.
Exemple (suite) :
A = {N°commande, N°client, N°représentant, référence, date_du_jour}
Remarque : si deux attributs apparaissent toujours ensemble dans des
sources de dépendances fonctionnelles, ils constituent un seul élément.
Marielle Delhom 93

94. VI.4 Conception du MCD (3)
Etape 2 : Recherche des entités
• A tout élément de A correspond une entité dont cet élément est
identifiant (chaque nœud du graphe).
Exemple (suite) :
A = {N°commande, N°client, N°représentant, référence, date_du_jour}
94
Commande Client Représentant Produit
Date

95. VI.4 Conception du MCD (4)
Etape 3 : Recherche des relations
Cas1 : A toute source d’une DF constituée d’un moins deux éléments de A
correspond une relation (clé à attributs multiples).
Les éléments de A identifient les entités intervenant dans la relation. La
dimension de la relation est égale au nombre d’éléments pris dans A.
Exemple (suite) : relations
- ligne_com Entités (collection) : commande, produit
Dimension : 2
- Visite Entités (collection) : date, représentant
Dimension : 2
Marielle Delhom 95

96. VI.4 Conception du MCD (5)
Cas 2 : A tout élément de A, but d’une relation, correspond une
relation de dimension 2 (clé étrangère).
Exemple (suite) : relations
- Com_Cli (entités : commande, client)
- Cli_Rep (entités : client, représentant)
Cardinalités :
• Cas 1 : les cardinalités sont fonction du domaine d’étude
• Cas 2 : au moins une cardinalité est égale à 0,1 ou 1,1.
Marielle
Delhom
9
6

97. VI.4 Conception du MCD (6)
Etape 4 : Recherche des propriétés
• A tout attribut n’appartenant pas à A correspond une
propriété.
• Ces attributs sont obligatoirement but de DF, leur
affectation est évidente.
Marielle Delhom 97

98. VI.4 Conception du MCD (7)
Marielle Delhom 98
Client
N°Client
raison_sociale
adresse_livrais
Commande
N°Commande
Date_Cde
Com_cli
0,N 1,1
Produit
Référence
désignation
qté_en_stock
ligne_com
qté_commandéee
1,N
0,N
Représentant
Cli_rep
1,1
1,N
N°représentant
Nom_représentant
qté_en_stock
Date
Visite
1,N
0,N
Date_du_jour
nb_cli

99. Rappel de la Démarche
Démarche :
1 - Recenser les attributs
2 - Recenser les Dépendances Fonctionnelles
3 - Rechercher la Couverture Minimale
4 - Concevoir le MCD
5 - Concevoir le Schémas relationnel de la base de données
Marielle Delhom 99

100. VI .5 Conception du schéma relationnel de
la BD (1)
• A partir du MCD, on va maintenant définir le
schéma relationnel de la base de données.
Marielle Delhom 100

101. Règles concernant les entités :
• Chaque entité se transforme en une table (ou relation)
• L’identifiant se transforme en clé primaire de la table
• Les propriétés de l’entité deviennent des attributs de la table
Marielle Delhom 101

102. Règles concernant les relations (1) :
Cas 1 : Relation binaire et cardinalités de type (x,1) - (x,N)
• C’est le cas d’une relation de type "père-fils" (père x,N / fils x,1), dans ce cas :
à l’identifiant de l’entité père devient une propriété de la table fils, cette propriété est
appelée clé étrangère (ou clé externe)
à les propriétés de la relation deviennent des propriétés de la table fils
Donc dans le cas général :
- Relation_A(IdentA, PropriétéA, #IdentB, Pro_rel)
- Relation_B(IdentB, PropriétéB)
Marielle Delhom 102
Entité A
IdentA
PropriétéA
Entité B
IdentB
PropriétéB
Rel
Pro_rel
x, 1 x, N

103. Règles concernant les relations (2) :
Exemple :
On obtient 2 tables :
Client (N°Client, Nom)
Commande(N°Cde, Date_Cde, #N°Client)
Marielle Delhom 103
Commande
N°Cde
Date-Cde
Client
N°Client
Nom
passe
1, 1 1, N

104. Règles concernant les relations (3) :
Cas 2 : Relation binaire et cardinalités de type (x,N) - (x,N)
La relation devient une table, l'identifiant de la relation devient la clé primaire de la table.
Donc, on obtient 3 tables :
- Relation_A(IdentA, PropriétéA)
- Relation_B(IdentB, PropriétéB)
- Relation_R(#IdentA, #IdentB, Pro_rel)
Marielle Delhom 104
Entité A
IdentA
PropriétéA
Entité B
IdentB
PropriétéB
Rel
Pro_rel
x,N x, N

105. Règles concernant les relations (4) :
Exemple :
On obtient 3 tables :
Fournisseur (N°Fourn, Nom)
Produit(N°Produit, Désignation)
Fournir(#N°Fourn, #N°Produit, Prix)
Marielle
Delhom
10
5
Fournisseur
N°Fourn
Nom
Produit
N°Produit
Désignation
Fournir
Prix
1,N 1, N

106. Règles concernant les relations (5) :
Cas 3 : Relation ternaire et cardinalités de type (x,1) - (x,N) - (x,N)
On obtient 3 tables :
- Relation_A(IdentA, PropriétéA)
- Relation_B(IdentB, PropriétéB)
- Relation_C(IdentC, PropriétéC, Pro_rel, #IdentA, #IdentB)
Marielle Delhom 106
Entité A
IdentA
PropriétéA
Entité B
IdentB
PropriétéB
Rel
Pro_rel
x,N x, N
Entité C
IdentC
PropriétéC
x, 1

107. Règles concernant les relations (6) :
Cas 4 : Relation ternaire et cardinalités de type (x,N) - (x,N) - (x,N)
4 tables : - Relation_A(IdentA, PropriétéA)
- Relation_B(IdentB, PropriétéB)
- Relation_C(IdentC, PropriétéC)
- Relation_R(#IdentC, #IdentA, #IdentB, Pro_rel)
Marielle Delhom 107
Entité A
IdentA
PropriétéA
Entité B
IdentB
PropriétéB
Rel
Pro_rel
x,N x, N
Entité C
IdentC
PropriétéC
x, N

108. Remarque : autre méthode
• Les sources des DF sont les clés de chaque relation du
schéma relationnel de la BD
Marielle
Delhom
10
8
N°Commande
date_
commande
N°Client
référence
quantité_en_
stock
désignation
raison_sociale
N°représentant
adresse_livraison
nom_représentant
date_du_jour
nb_cl
quantité_commandée

109. Remarque : autre methode
On définit ensuite les attributs de chaque relation (6)
Marielle Delhom 109
N°Commande
date_
commande
N°Client
référence
quantité_en_
stock
désignation
raison_sociale
N°représentant
adresse_livraison
nom_représentant
date_du_jour
nb_cl
quantité_commandée