Conception des

Bases de Données

1
 Chapitre 6

Le modèle Relationnel

2
Historique (1/2)
 Le père des bases de données relationnelles
est Edgar Frank Codd.
 Chercheur chez IBM à la fin des année 1960, il
étudiait de nouvelles méthodes pour gérer de
grandes quantités de données car les modèles
et les logiciels de l’époque ne le satisfaisait
pas.
 Il était persuadé qu’il pourrait utiliser la théorie
des ensembles pour résoudre des difficultés
telles que la redondance des données,
l’intégrité des données ou l’indépendance de la
structure de la base de données avec sa mise
en œuvre physique.
3
Historique (2/2)
 En 1970, il publia un article où il proposait de
stocker des données hétérogènes dans des
tables, permettant d’établir des relations entre
elles.
 De nos jours, ce modèle est extrêmement
répandu, mais en 1970, cette idée était
considérée comme une curiosité intellectuelle.
On doutait que les tables puissent être jamais
gérées de manière efficace par un ordinateur.
 Depuis les années 80, cette technologie a mûri
et a été adoptée par l’industrie.
 En 1987, le langage SQL, qui étend l’algèbre
relationnelle, a été standardisé. 4
Introduction (1/2)
 Dans ce modèle, 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. 5
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 et la logique des prédicats
d’ordre1
6
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
7
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.
8
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 compose d’un
ensemble de colonnes désignées par un nom
d’attribut.
 Dans chaque colonne on trouve des valeurs d’un
certain domaine (chaînes de caractères, nombres,
…).
 Enfin on constate que chaque ligne (ou tuple)
correspond à une occurrence d’une entité.
 Un schéma relationnel est constitué d’un
ensemble de schémas de relations qui décrivent,
à l’aide des élements présentés informellement ci-
dessus (domaines, attributs, noms de relation) le
contenu d’une relation. 9
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).
10
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. 11
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)
12
Définitions (6/9)
 Degré
 Le degré d’une relation est son nombre
d’attributs.
 Occurrence ou n-uplets ou tuples
 Une occurrence, ou n-uplets, ou tuples, est
un élément de l’ensemble figuré par une
relation. Autrement dit, une occurrence est
une ligne du tableau qui représente la relation.
 Cardinalité
 La cardinalité d’une relation est son nombre
d’occurrences 13
Définitions (7/9)
 Clé candidate
 Une clé candidate d’une relation est un
ensemble minimal des attributs de la relation
dont les valeurs identifient à 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.

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

15
Définitions (9/9)
 Clé primaire
 La clé primaire d’une relation est une de ses
clés candidates. Pour signaler la clé
primaire, ses attributs sont généralement
soulignés.
 Clé étrangère
 Une clé étrangère dans une relation est
formée d’un ou plusieurs attributs qui
constituent une clé primaire dans une autre
relation.
16
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.
17
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.
18
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 à
partir d’un schéma Entité/Association et
d’appliquer certaines règles de
transformation. 19
Anomalies de mise à jour (1/4)
Soit la relation
FOURNISSEUR (NomFournisseur, AdresseFournisseur, Produits, Prix)

NomFournisseur AdresseFournisseur Produit Prix

Lebras 10, Rue des Gras- Clermont Chaise 20
Table 35
Dupont 86, Rue de la République - Bureau 60
Moulins
Lajoie 26, Rue des Dômes - Vichy Lit 50

Dupont 39, Rue des Buttes - Moulins Lampe 18

Table de chevet 25 20
Anomalies de mise à jour (2/4)

 1er 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

21
Anomalies de mise à jour (3/4)

 3ème problème
 Une relation (table) correspondant à ce
schéma pourra éventuellement contenir
plusieurs produits pour un même
fournisseur.
 Dans ce cas, il faudra faire face à un certain
nombre de problèmes :
 l'adresse du fournisseur sera dupliquée dans
chaque n-uplet  redondance
22
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 modification
 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
23
Dépendances fonctionnelles (1/9)

 Pour remédier aux différentes anomalies

rencontrées, il est nécessaire de procéder à
une normalisation du modèle relationnel
permettant ainsi de :
 éliminer les redondances
 diminuer la taille de la base de donnée sur le disque
 diminuer les risques d’incohérence
 éviter une mise à jour multiple des mêmes données
 Mais avant de normaliser, il faut étudier la
notion de dépendances fonctionnelles. 24 24
Dépendances fonctionnelles (2/9)

 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.
25
Dépendances fonctionnelles (3/9)

 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
faire correspondre qu’une seule valeur au
plus de la propriété B.
 Deux attributs sont en dépendance
fonctionnelle si la connaissance d’une valeur
de A détermine une et une seule valeur de
b. on dit que a détermine B ou encore que B
dépend fonctionnellement de A et on note
A B
26
Dépendances fonctionnelles (4/9)

 Autrement dit, si on connaît la valeur de A, on

peut en déduire une seule valeur de B.
 Mais la réciproque n’est pas vrai (si on connaît
B, on ne peut pas en déduire A).
 Exemple : 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. 27
Dépendances fonctionnelles (5/9)

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

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.

28
Dépendances fonctionnelles (6/9)

 Exemple : Considérons une commande qui comporte

plusieurs produits
Num_Commande, Ref_Produit quantité commandée
 Si on n’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 respectifs) pour en déduire la quantité
commandée.

29
Dépendances fonctionnelles (7/9)

 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.
30
Dépendances fonctionnelles (8/9)

 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é :
Si Y X Alors XY
 Augmentation :
Si XY et si W est un ensemble quelconque
d’attributs, alors X,W  Y,W

31
Dépendances fonctionnelles (9/9)

 Transitivité
Si XY et YZ Alors XZ
 Pseudo-transitivité
Si XY et Y,WZ Alors X,WZ
 Union
Si XY et XZ Alors XY,Z
 Décomposition
Si XY,Z Alors XY et XZ

32
Graphe des DF (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.

33
Graphe des DF (2/4)

 Exemple
 Des articles, identifiés par un code et ayant
une description, sont achetés chez un seul
fournisseur par article. Le fournisseur est
connu par son numéro et son nom
 Les DF sont les suivantes :
Code articleDescription article
Num fournisseur  Nom fournisseur
Code article  Num fournisseur
34
Graphe des DF (3/4)

 Le graphe correspondant

Code Article
Num Fournisseur

Description Article Nom Fournisseur

35
Normalisation (1/13)

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
36
Normalisation (2/13)

 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)
37
Normalisation (3/13)

 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é. Autrement dit,
aucun des attributs ne dépend que d’une partie
de la clé.

Remarque La 2FN n'est à vérifier que pour les

relations ayant une clé composée. Une relation en 1FN
n'ayant qu'un seul attribut clé est toujours en 2FN
38
Normalisation (4/13)
 Exemple
 LIGNE_COMMANDE(#Num_cde, #RéférenceProd,
DésignationProd, Quantité)
 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° 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.

39
Normalisation (5/13)

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

40
Normalisation (6/13)

 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
41
Normalisation (7/13)

 Si l’une des 3 règles n’est pas vérifiée, cela

indique une erreur dans le modèle relationnel
qu’il faut alors modifier pour que les 3 règles
soient vérifiées pour toutes les relations.
 On vérifie 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érifier la 2FN. Et si
la 2FN n’est pas vérifiée, inutile de vérifier la
3FN.
42
Normalisation (8/13)

 Modèle 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)

43
Normalisation (9/13)
 Forme Normale de Boyce-Codd
 Dans les définitions précédentes, les
dépendances transitives cachées (pouvant
causer des anomalies de mise à jour) n’ont
pas été prises en compte.
 Elles peuvent se manifester par
l’intermédiaire de clés candidates qui
pourraient demeurer dans une relation.
 La forme normale de Boyce-Codd doit donc
prendre en considération toutes les clés de
la relation (au sens large).
44
Normalisation (10/13)

 Une relation est en BCNF ssi les seules

DF élémentaires sont celles dans
lesquelles il n’ y a pas d’autre
déterminant que la clé primaire.
 Une relation en BCNF est aussi en 3ème
Forme Normale et elle aboutit, en
général, à une perte de dépendances.

45
Normalisation (11/13)

 Exemple
 Soit la relation suivante :
Entretiens (candidat,dateExamen, heure, jury, salle)
 Avec les dépendances suivantes:
 candidat, dateExamen heure, jury, salle
 jury ,dateExamen, heure candidat
 jury ,dateExamen  salle

46
Normalisation (12/13)

 Cette relation contient des dépendances

transitives partielles et nécessite d’être
transformée en deux relations en FNBC
pour éviter les anomalies de mise à jour.
Entretiens (candidat,dateExamen, heure, jury)
Planning (jury,dateExamen, salle)
 La seconde DF est ainsi perdue.

47
Normalisation (13/13)

 La normalisation permet donc de :

 Construire des tables sans redondance
 Vérifier la bonne conception des tables
issues de la modélisation conceptuelle
 Restructurer une base existante

48
Exercice 1
 Pour les relations suivantes :

 Identifier les redondances éventuelles ainsi que les anomalies

 Déterminer la clé
 Déterminer la forme normale
 Proposer une décomposition en BCNF si possible sans perte
d'information ni perte de dépendances fonctionnelles, sinon,
justifier.

 Description des pièces employées dans un atelier

de montage.
Pièce(numPièce, prix, TVA, libellé, catégorie)

DF1 : numPièce prix, TVA, libellé, catégorie

DF2 : catégorie TVA 49
Exercice 2

 Liste d'employés travaillant sur des projets d'un

laboratoire
Employé(numEmployé, numLaboratoire,
numProjet, nomEmployé, nomProjet, adresse)
DF1 : numEmployé, numLaboratoire numProjet
DF2 : numEmployé nomEmployé, adresse
DF3 : numProjet  nomProjet

50
Règles de passage
Modèle E/AModèle 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 51