Conception des Bases de Données

Chapitre 3- Le Modèle Relationnel

II1 h e l a . b o u ke f @e ns i - u m a . t n

2023/2024 1
Plan du chapitre

• Introduction

• Objectifs

• Définitions

• Propriétés d’une BD Relationnelle

• Anomalies de mise à jour

• Dépendances fonctionnelles et Normalisation

• Règles de Passage Modèle EA → Modèle Relationnel

2
Introduction (1/2)

• Dans le modèle relationnel, les données sont représentées par

des tables, sans préjuger de la façon dont les informations
sont stockées dans la machine.

• Les tables constituent donc la structure logique du modèle

relationnel.

• Au niveau physique, le système est libre d’utiliser n’importe

quelle technique de stockage dès lors qu’il est possible de
relier ces structures à des tables au niveau logique.

• Les tables ne représentent donc qu’une abstraction de

l’enregistrement physique des données en mémoire. 3
Introduction (2/2)

• Le succès du modèle relationnel auprès des chercheurs,

concepteurs et utilisateurs est dû à la puissance et à la
simplicité de ses concepts.

• Contrairement à certains autres modèles, il repose sur des

bases théoriques solides, notamment la théorie des ensembles

4
Objectifs

Les objectifs du modèle relationnel sont :

• Proposer des schémas de données faciles à utiliser

• Améliorer l’indépendance logique et physique

• Mettre à la disposition des utilisateurs des langages de haut niveau

• Optimiser les accès à la base de données

• Améliorer l’intégrité et la confidentialité

• Fournir une approche méthodologique dans la construction des

schémas
5
Définitions (1/9)

De façon informelle, on peut définir le modèle relationnel de

la manière suivante :
• Les données sont organisées sous forme de tables à deux
dimensions, encore appelées relations, dont les lignes sont
appelées n-uplet ou tuple
• Les données sont manipulées par des opérateurs de l’algèbre
relationnelle
• L’état cohérent de la base est défini par un ensemble de
contraintes d’intégrité.
• Au modèle relationnel est associée, la théorie de la normalisation
des relations qui permet de se débarrasser des incohérences au
moment de la conception d’une base de données relationnelle.
6
Définitions (2/9)

Schéma Relationnel
• Une relation peut simplement être représentée sous forme de table

• Une relation a donc un nom et se com pose d’un ensem ble de colonnes
désignées par un nom d’attri but .

• Dans chaque colonne on t rouve des valeurs d’un cer tain domai ne (chaînes de
caractères, nombres, …).

• Enf in on constate que chaque lig ne (ou tupl e ) correspond à une occurrence
d’une entité .

• Un schéma rel ati onnel est consti tué d’un ensembl e de schémas de
rel ati ons qui décrivent, à l’aide des élements pr ésentés inf orm ellement ci-
dessus (domaines, attribut s, noms de relation) le contenu d’une relation . 7
Définitions (3/9)

Attribut
• Un attribut est un identificateur (un nom) décrivant une information
stockée dans une base.
• Exemples d’attribut : l’âge d’une personne, le nom d’une personne, le
numéro de sécurité sociale

Domaine
• Le domaine d’un attribut est l’ensemble, fini ou infini, de ses
valeurs possibles.
• Par exemple, l’attribut numéro de sécurité sociale a pour domaine
l’ensemble des combinaisons de quinze chiffres et nom a pour
domaine l’ensemble des combinaisons de lettres (appelée chaîne
de caractères). 8
Définitions (4/9)

Relation
• Une relation est un sous-ensemble du produit cartésien de n
domaines d’attributs (n > 0).
• Une relation est représentée sous la forme d’un tableau à deux
dimensions dans lequel les n attributs correspondent aux titres
des n colonnes.
Schéma de relation
• Un schéma de relation précise le nom de la relation ainsi que
la liste des attributs avec leurs domaines.

9
Définitions (5/9)

Exemple de relation et son schéma

N° Sécu Nom Prénom
354338532195874 Durand Caroline
345353545435811 Dubois Jacques
173354684513546 Dupont Lisa
973564213535435 Dubois Rose-Marie
relation de schéma
Personne(N° sécu : Entier, Nom : Chaîne, Prénom : Chaîne) 10
Définitions (6/9)

Degré
• Le degré d’une relation est son nombre d’attribut s .

Occurrence ou n-uplets ou tuples

• Une occurrence, ou n-uplets, ou tu ples, est un élément de l’ensem ble f ig uré

par une relation . Autrem ent dit, une occurrence est une ligne du tableau qui
représente la relation .

Cardinalité

• La cardinalité d’une relation est son nombre d’occurrences

11
Définitions (7/9)

Clé candidate
• Une clé candidate d’une relation est un ensemble minimal des
attributs de la relation dont les valeurs identif ient à coup sûr une
occurrence.

• La valeur d’une clé candidate est donc distincte pour tous les tuples
de la relation.

• La notion de clé candidate est essentielle dans le modèle relationnel.

12
Définitions (8/9)

• Toute relation a au moins une clé candidate et peut en avoir

plusieurs.

• Ainsi, il ne peut jamais y avoir deux tuples identiques au sein

d’une relation.

• Les clés candidates d’une relation n’ont pas forcément le

même nombre d’attributs.

• Une clé candidate peut être formée d’un attribut arbitraire,

utilisé à cette seule fin.

13
Définitions (9/9)

Clé primaire

• La clé prim aire d’une relation e st un e de ses clés candidate s. Pour

signaler la clé primaire, ses attributs sont généralement soulignés .

Clé étrangère

• Une clé étrangère dans une relation est f orm ée d’un ou plusieurs
attributs qui constituent une clé primaire dans une autre relation .

14
Propriétés d’une BD Relationnelle (1/3)

• Une base de données relationnelle est un ensemble fini de

relations.

• Le schéma de la base est l’ensemble des schémas des relations

de cette base.

• La création d’un schéma de BDR est simple une fois que l’on a
déterminé toutes les relations qui constituent la base.

15
Propriétés d’une BD Relationnelle (2/3)

• En revanche le choix de ces relations est un problème difficile car il

détermine en grande partie les caractéristiques, qualités de la base :
performances, exactitude, exhaustivité, disponibilité des informations,
etc.

• Un des aspects importants de la théorie des bases de données

relationnelles consiste précisément à définir ce qu’est un bon schéma
et propose des outils formels pour y parvenir.

16
Propriétés d’une BD Relationnelle (3/3)

• En pratique, on procède d’une manière moins rigoureuse mais plus

accessible, en concevant le schéma à l’aide d’un modèle de données
conceptuel , puis en transcrivant le schéma conceptuel obtenu en
schéma relationnel.

• La technique la plus répandue consiste à par tir d’un schéma

Entité/Association et d’appliquer certaines règles de
transformation.

17
Anomalies de Mise à Jour (1/4)

Soit la relation

FOURNISSEUR (NomFournisseur, AdresseFournisseur, Produits, Prix)

NomFournisseur AdresseFournisseur Produit Prix

Lascaux 10, Rue des Gras- Clermont Chaise 20

Table 35
Dupont 86, Rue de la République - Bureau 60
Moulins
Martin 26, Rue des Dômes - Vichy Lit 50

Dupont 39, Rue des Buttes - Moulins Lampe 18

18
Table de chevet 25
Anomalies de Mise à Jour (2/4)

• 1 er problème
Il n’y a pas de clé primaire : on ne sait pas si les deux
Dupont sont différents ou pas (si c’est le même Dupont, il
y a une des deux adresses qui est fausse)

• 2 ème problème
L’adresse n’est pas décomposée. Si on veut par exemple
rechercher tous les fournisseurs qui habitent la même ville,
ça ne va pas être possible

19
Anomalies de Mise à Jour (3/4)

• 3ème problème
Une relation (table ) correspondant à ce schéma pourra évent uellem ent
contenir plusieurs produits pour un même fournisseur.

Dans ce cas, il faudra faire face à un cer tain nombre de problèm es :

– l ' a d r ess e d u f o u r n i ss eur s e r a d u p l i q u ée d a n s c h a q u e n - u p l e t → r e d o nd an c e

20
Anomalies de Mise à Jour (4/4)

• Si on insère un nouveau produit pour un fournisseur déjà référencé,

il faudra vérifier que l'adresse est identique
→ Anomalie d’Insertion
• Si on souhaite modifier l'adresse d'un fournisseur, il faudra
rechercher et mettre à jour tous les n-uplets correspondant à ce
fournisseur
→ Anomalie de modif ication
• Si on veut supprimer un fournisseur, il faudra retrouver et supprimer
tous les n-uplets correspondant à ce fournisseur (pour différents
produits) dans la table.
→ Anomalie de suppression

21
Dépendances Fonctionnelles
&
Normalisation

22
Introduction

• La théorie de la normalisation est une théorie destinée à concevoir un

bon schéma d’une base de données sans redondance d’information et
sans risques d'anomalie de mise à jour.

• Elle a été introduite dès l'origine dans le modèle relationnel.

• La théorie de la normalisation est fondée sur deux concepts principaux :

– Les dépend ances fonctionnell es q ui traduisen t d e s contraintes sur le s

données .

– Les formes normal es qui déf inissent des relations bien conçues .

• La mise en œuvre de la normalisation est fondée sur la décomposition

progressive des relations jusqu'à obtenir des relations normalisées
23
Les dépendances fonctionnelles (1/21)

• La construction du modèle relationnel repose presque entièrement sur

le concept de dépendance fonctionnelle.

• C’est ce concept qui permet de passer d’un ensemble de propriétés

non structuré à un modèle formé d’entités et d’associations puis au
modèle relationnel correspondant.

24
Les dépendances fonctionnelles (2/21)

Définition
• On dit que b est en dépendance fonctionnelle (DF) de a si à une valeur
quelconque de la propriété a, on ne peut f aire correspondre q u’une seul e valeur
au plus de la propriété b.

• Deux at tributs sont en d épendance f onctionnelle si la connaissance d’une valeur

de a déterm ine une et un e seule valeur de b. on dit que a détermine b ou encore
que b dépend fonctionnellem ent de a et on note a → b

• Autrement di t, si on connaît la valeur de a, on peut e n déduire une seule val eur

de b.

• Mais la réciproque n’est pas vrai (si on connaît b, on ne peut pas en déduire a).
25
Les dépendances fonctionnelles (3/21)

Exemple1 : Num client →Nom client

• Il existe une DF entre Num client et Nom client, car si on

connaît une valeur de la propriété Num client (ex : 4553), il ne
peut lui correspondre qu’une seule valeur de la propriété nom
(ex : Duval).
• La réciproque est fausse : Nom client → Num client n’est pas
une DF
• Si l’on connaît la valeur de la propriété Nom client, on ne peut
pas en déduire la propriété Num client, car il peut y avoir des
homonymes.

26
 Les dépendances fonctionnelles (4/21)

• Soit la relation suivante: Achat (Client, Produit, Prix)

• Chaque ligne (c,p,x) spécifie que le client c a acheté le produit p au prix x

• Prix du produit dépend du produit et pas d’autres attributs

• Existence d’ une dépendance fonctionnelle (DF) de produit vers prix

27
Les dépendances fonctionnelles (5/21)

Dans cet Exemple:

• Produit → Prix
• Produit détermine (fonctionnellement) Prix mais pas le
contraire
• Prix dépend (fonctionnellement) de Produit
• Produit est le déterminant et Prix est le déterminé de la
dépendance fonctionnelle.
28
Les dépendances fonctionnelles (6/21)

• Les attributs d’une dépendance fonctionnelle

(déterminant, déterminé) peuvent comprendre plus d’un
attribut.
• X→Y : X et Y peuvent être des attributs composés
(ensemble d'attributs)
• Exemple: soit une relation R( A, B, C, D), on peut
trouver des dépendances telles que:
✓ B,C → D ou
✓ B → C,D

29
Les dépendances fonctionnelles (7/21)

Exemple3 : Considérons une commande qui comporte plusieurs

produits
Num_Commande, Ref_Produit →quantité commandée

• Si on a seulement le numéro de la commande, on ne peut pas en

déduire la quantité commandée, car il faut aussi savoir de quel
produit.

• De même, on ne peut pas savoir la quantité commandée d’un

produit si on ne sait pas de quelle commande. Il faut bien
connaître à la fois la commande et le produit (leurs identifiants
30
respectifs) pour en déduire la quantité commandée.
Les dépendances fonctionnelles (8/21)

Soit la relation suivante:

COMMANDE (Ncli, Nom, Adresse, Ncom, Date, Npro, Qte, Prix-u)
Une ligne (a,b,c,d,e,f,g,h) de cette relation indique: Le client n ° a de
nom b et d’adresse c a passé la commande numéro d, à la date e,
spécifiant le produit n°f en quantité g et au prix unitaire h.
NCOM→NCLI ;

NCLI → NOM;

N C L I → A D RE SSE ;

N C O M → D ATE ;

N C O M , NPRO → QTE ;

N PRO → PRIX - U 31
Les dépendances fonctionnelles (9/21)

Comment trouver les DF ?

• Une DF est déf inie sur l'intension du schéma .

• Une DF traduit une cer taine perception de la réalité .

• La seule m aniè re de déterm iner une DF est donc de regarder

soigneusem ent ce que signif ient les attributs et de trouver les
contraintes qui les lient dans le monde réel.

32
Les dépendances fonctionnelles (10/21)

Exemple
Personne(NSS, Nom, Prénom, Marque, Type, Puiss, Date, Prix)
On peut poser les exemples de DF suivants :
NSS→Nom
NSS→Prénom
Type→Marque
Type→Puiss
(NSS, Type,Marque, Date)→Prix
etc. 33
Les dépendances fonctionnelles (11/21)

• Les DF font partie du schéma d'une BD, en conséquence, elles

doivent être déclarées par les administrateurs de la BD et être
contrôlées par le SGBD.

• De plus l'identification des DF est la base indispensable pour

déterminer dans quelle forme normale est une relation et
comment en diminuer la redondance.

34
Les dépendances fonctionnelles (12/21)

Remarque1 :Toutes les propriétés d’une entité

dépendent fonctionnellement de l’identifiant.
DF à partir de propriétés concaténées (partie gauche
composée de plusieurs attributs)

• Il peut exister des dépendances fonctionnelles à partir

de propriétés concaténées, c'est -à-dire qui forment un
tout indissociable, comme si elles étaient soudées.
35
Les dépendances fonctionnelles (13/21)

Les dépendances fonctionnelles dont la source est formée de plusieurs

propriétés doivent être élémentaires.

Exemple :

Num Commande, Num Client →date commande

n’est pas une DF élémentaire car on n’a pas besoin du numéro de

client pour connaître la date de commande, il suffit de connaître le
numéro de la commande. La propriété Num Client ne sert à rien dans
cette DF.

36
Les dépendances fonctionnelles (14/21)

Propriétés des dépendances fonctionnelles

Soient X,Y,Z des attributs, on dit que Y dépend fonctionnellement de X,

s’il existe une DF de X vers Y et on note X→Y

– Réflexivité

✓ Tout groupe d'attributs se détermine lui même et détermine chacun

de ses attributs (ou sous groupe de ses attributs).

✓ Soient X et Y des attributs :

XY→XY et XY→X et XY→Y

37
Les dépendances fonctionnelles (15/21)

– Augmentation
✓ Si un attribut X détermine un attribut Y, alors tout groupe composé de X,
enrichi avec d'autres attributs, détermine un groupe composé de Y et
enrichi des mêmes autres attributs.
✓ Soient X, Y et Z des attributs :
Si X → Y et si Z est un ensemble quelconque d’attributs, alors X,Z → Y,Z
– Transitivité
✓ Si un attribut X détermine un attribut Y et que cet attribut Y détermine un
autre attribut Z, alors X détermine Z.
✓ Soient X, Y et Z des attributs :
38
X→Y et Y→Z ⇒ X→Z
Les dépendances fonctionnelles (16/21)

– La pseudo-transitivité

✓ Si un attribut X détermine un autre attribut Y, et que Y appartient à un

groupe G qui détermine un troisième attribut Z, alors le groupe G'
obtenu en substituant Y par X dans G détermine également Z.

Soient, W, X, Y et Z des attributs :

X→Y et WY→Z ⇒ WX→Z

✓ Cette propriété est déduite de l'augmentation et de la transitivité :

X→Y et WY→Z ⇒ WX→WY et WY→Z ⇒ WX→Z

39
Les dépendances fonctionnelles (17/21)

– L’union
✓ Si un attribut détermine plusieurs autres attributs, alors il détermine tout
groupe composé de ces attributs.

✓ Soient X, Y et Z des attributs :

X→Y et X→Z ⇒ X→YZ

– La décomposition
✓ Si un attribut détermine un groupe d'attribut, alors il détermine chacun
des attributs de ce groupe pris individuellement.

✓ Soient X, Y et Z des attributs :

X→YZ ⇒ X→Z et X→Y 40

Les dépendances fonctionnelles (18/21)

Notion de Dépendance fonctionnelle élémentaire

Soit G un groupe d'attributs et A un attribut, une DF G→A est

élémentaire si :

• A n'est pas incluse dans G et s'il n'existe pas d'attribut A' de G

qui détermine A

• AB→C est élémentaire si ni A, ni B pris individuellement ne

déterminent C.

NumCde, RefProd→Qté
41
Les dépendances fonctionnelles (19/21)

DF non élémentaires
• AB→A n'est pas élémentaire car A est incluse dans AB.

• AB→CB n'est pas élémentaire car CB n'est pas un attribut, mais

un groupe d'attributs.

• N°SS,Nom→ Prénom n'est pas élémentaire.

42
Les dépendances fonctionnelles (20/21)

Notion de Fermeture Transitive

On appelle fermeture transitive F+ d'un ensemble F de DFE , l'ensemble
de toutes les DFE qui peuvent être composées par transitivité à partir des
DFE de F.

Exemple

Soit l'ensemble F = {A→B, B→C, B→D, A→E}.

La fermeture transitive de F est F+ =

{ A→B, B→C, B→D, A→E, A→C, A→D }

43
Les dépendances fonctionnelles (21/21)

Notion de couverture minimale

• La couver ture minimale d’un ensemble de DFE est un sous-ensemble
minimum de DFE permettant de générer toutes les autres DFE.
• Tout ensemble de DFE (et donc tout ensemble de DF) admet au moins
une couverture minimale (et en pratique souvent plusieurs).

Exemple
L'ensemble F = {A→B, A→C, B→C, C→B}
admet les deux couvertures minimales :
CM1 = {A→C, B→C, C→B}
et CM2 = {A→B, B→C, C→B} 44
Graphe des dépendances (1/4)

• Une fois les dépendances fonctionnelles établies, on peut

construire le graphe correspondant .

• Ce graphe fait apparaître les dépendances fonctionnelles entre

les données.

• Une DF relie deux données lorsque la connaissance de l’une

détermine l’autre.

• La dépendance n’est pas réversible.

45
Graphe des dépendances (2/4)

Exemple
• Des ar ticles, identif iés par un code et ayant une de scription, sont
achetés chez un seul f ournisseur par ar ticle . Le f ournisseur est connu
par son numéro et son nom
• Les DF sont les suivantes :

✓ Code ar ticle→Des cript ion ar ticle

✓ Num fournisseur → Nom fournisseur

✓ Code ar ticle → Num fournisseur

46
Graphe des dépendances (3/4)

• Le graphe correspondant

Code Article
Num Fournisseur

Description Article Nom Fournisseur

47
Graphe des dépendances (4/4)

Exercice

Soit le sché ma E/A suivant, déterminer le dif férentes dépendances

fonctionnelles et générer le graphe correspondant

[M:N]
(0,n) (0,n)
Fournisseur Vendre Article

Num Fou Code Art

Nom Fou Prix Desc Art
Adr Fou Poids Art
48
Qté Art
Normalisation (1/7)

Afin d’être opérationnelle, une BD Relationnelle

doit respecter certaines règles de normalisation.
1 ère Forme Normale
Une relation est normalisée en première forme normale si :
1. Elle possède une clé identifiant de manière unique et
stable chaque ligne
2. Chaque attribut est monovalué (ne peut avoir qu’une
seule valeur par ligne)
3. Aucun attribut n’est décomposable en plusieurs attributs
significatifs

49
Normalisation (2/7)

Exemples
PERSONNE (NOM, PRENOMS)
• Mise en 1FN :
PERSONNE (NOM, PRENOM1, PRENOM2)
PERSONNE (NOM, PRENOM, ADRESSE)
• Mise en 1FN :
PERSONNE (NOM, PRENOM, N °RUE, RUE, CODEPOSTAL, VILLE)

50
Normalisation (3/7)

2 ème Forme Normale

Une relation R est en 2 ème forme normale si et seulement si :

1. Elle est en 1FN

2. Tout attribut non clé est totalement dépendant de toute la clé

(dépendance fonctionnelle elémentaire). Autrement dit, aucun des
attributs ne dépend que d’une partie de la clé.

Remarque

La 2 FN n'est à vérif ier que pour le s relations ayant une clé c om posée . Une
relation en 1FN n'ayant qu'un seul attribut clé est toujours en 2FN
51
Normalisation (4/7)

Exemple
LIGNE_COMMANDE(#Num_cde, #RéférenceProd,DésignationProd, Qté)

Cette relation est en première forme normale (existence d’une clé valide et
aucun attribut n’est décomposable)

MAIS elle n’est pas en 2 ème forme normale car on a DésignationProd ne

dépend pas de toute la clé mais seulement de RéférenceProd

RéférenceProd→ DésignationProd

pour connaître l’attribut désignationProd, on n’a pas besoin de connaître le

numéro de commande.
52
Normalisation (5/7)

3 ème Forme Normale

Une relation est en 3 ème forme normale si et seulement si :
1. Elle est en 2° forme normale
2. Et tout attribut doit dépendre directement de la clé, c'est -à-dire
qu’aucun attribut ne doit dépendre de la clé par transitivité.

Autrement dit , aucun attribut ne doit dépendre d’un autre attribut non clé.

53
Normalisation (6/7)

Exemple :
CLIENT(Num_client, Nom_client, code_categ, nom_categ)
Cette relation n’est pas en 3FN car :
num_client→nom_categ n’est pas une dépendance directe.

En effet, on a aussi :
num_client →code_categ→ nom_categ

54
Normalisation (7/7)

• Si l’une des 3 règles n’est pas vérif iée, cela indique une erreur dans le
modèle relationnel qu’il faut alors modif ier pour que les 3 règles soient
vérif iées pour toutes les relations.

• On vérif ie les règles dans l’ordre. Si la première forme normale n’est pas
respectée, ce n’est pas nécessaire de vérif ier la 2FN. Et si la 2FN n’est pas
vérif iée, inutile de vérif ier la 3FN.

Modèle normalisé = relations avec une clé:

• q u i p e r met d e d i s t i n g u e r ch a q u e o ccu r r e n ce d e s a t t r i b u t s é l é men t a ires ( 1 F N )

• e n d é p en d a n ce d e TO U TE l a cl é ( 2 F N )

• e t R I E N Q U E d e l a cl é ( 3 F N )
55
Règles de Passage E/A→Relationnel

• Règle 1 : Entité
✓ Chaque entité donne une table
✓ Sa clé primaire est la clé de la table
• Règle 2 : association de type 1-N ou 1-1
✓ La clé primaire de l'entité côté N est ajoutée du côté
1 où elle devient clé étrangère
• Règle 3: association de type N-M
✓ Création d'une nouvelle table dont la clé est
l'ensemble des clés primaires des entités concernées
✓ Tout attribut de l'association devient attribut de la
nouvelle table
56