Licence MI2E 2007-2008

Bases de Donnes : exercices corrigs

Maude Manouvrier

La reproduction de ce document par tout moyen que ce soit est interdite

conformment aux articles L111-1 et L122-4 du code de la proprit intellectuelle

Attention, ce document peut comporter des erreurs, utiliser donc en

connaissance de cause!!

1
Passage au relationnel

Exercice 1
Enonc de l'exercice

CLIENT
SEANCECODE CLIENT
ClientID ASSISTE_A SEANCECODE
0:N 1:M
Nom SEANCEID ClientID
1..* ASSISTE_A *
Prnom NombreFautes DATE Nom SEANCEID
Adresse 1:1 HEURE Prnom DATE
DateNaissance Adresse HEURE
DateNaissance
0:N *
EST_AUTORISE_A_PASSER

0..8 RESULTAT_SEANCE

EST_AUTORISE EST_DIFFUSE NombreFautes

PENDANT
A PASSER

NombreFautes RESULTAT_EXAM

EST_DIFFUSE_PENDANT
NombreFautes
CDROM

0:8 CdRomID CDROM

Editeur *
EXAMEN_CODE CdRomID
EXAMEN_CODE Editeur
6:6
PassageCodeID
Date PassageCodeID SrieID
Heure Date
LieuExamen EST_COMPOSE_DE Heure
LieuExamen 1

COMPOSE
EST

DE
QUESTION 0:N 1:1
QUESTION
QuestionID CONTIENT 40:40 SERIE 6
1:N
Intitul QuestionID 40 CONTIENT 1..* SERIE
Rponse Numro SrieID Intitul
NiveauDifficult Rponse SrieID
Thme NiveauDifficult 1
Thme
POSITION_QUESTION

Numro

MODELISATION ENTITE ASSOCIATION MODELISATION UML

Figure 1: Modlisation E/A et UML de la base de donnes d'une l'auto-cole.

Une auto-cole souhaite construire une base de donnes pour grer les examens thoriques du
code de la route de ses lves. Chaque lve est identi par un numro unique et est caractris par
un nom, un prnom, une adresse et une date de naissance. Chaque lve assiste plusieurs sances
de code (autant qu'il le souhaite). Chaque sance est caractrise par une date et une heure. A
chaque sance de code, le directeur de l'auto-cole choisit une srie de questions sur un CD-ROM.
Chaque CD-ROM est identi par un numro et est caractris par un nom d'diteur. Chaque
CD-ROM est compos de 6 sries, numrotes de 1 6. Chaque srie est compose de 40 questions.
Chaque question est identie par un intitul et est caractrise par une rponse, un niveau de
dicult et un thme. Une mme question peut apparatre dans plusieurs sries avec un numro
d'ordre pour chaque srie ; par exemple une mme question peut apparatre comme question N 2
dans la srie 5 du CD-ROM 15 et comme question N 12 dans la srie 3 du CD-ROM 4. Une mme
srie peut tre projete plusieurs fois des sances direntes. Lorsqu'un lve assiste une sance,
il obtient le nombre de fautes (une note sur 40) qu'il a fait pour la srie passe pendant la sance.

2
Lorsqu'un lve a obtenu, au cours des quatre dernires sances auxquelles il a assistes, un nombre
de fautes infrieur ou gal 5, le directeur de l'auto-cole l'autorise passer l'examen thorique du
code de la route une date donne (un seul examen pour une date donne). L'auto-cole ne peut
prsenter que 8 lves maximum chaque date d'examen. Les lves ayant obtenu plus de 5 fautes
l'examen sont recals et doivent assister de nouveau des sances de code avant de pouvoir se
reprsenter l'examen.
La base de donnes doit permettre de rpondre des requtes telles que "Quel est le nombre moyen
de fautes pour la srie 5 du CD-ROM 14?", "Quels lves peuvent se prsenter au prochain examen
du code de la route ?", "Quels lves ont chou au moins une fois l'examen ?" etc.

La gure 1 prsente la modlisation Entit/Association (format Merise) et la modlisation UML

de l'nonc. Les explications ne sont donnes que pour le schma E/A mais peuvent tre adaptes
au schma UML. Pour une comprhension de la dirence entre une modlisation E/A ou UML et
le passage au relationnel, vous pouvez vous reporter l'ouvrage [4]. Les schmas de modlisation
ci-avant sont smantiquement clairs. Nanmoins, quels points ncessitent d'tre prciss.

L'ensemble d'entits Serie est un ensemble d'entits faibles de CD-ROM, au format Merise
(ou une association qualie en UML). En eet, ce choix de modlisation a t fait pour
reprsenter le fait que le numro d'une srie est relatif au CD-ROM auquel la srie appartient.

Les cardinalits de l'association entre les ensembles d'entits Serie et CD-ROM sont 1:1-6:6,
car une srie appartient un unique CD-ROM et un CR-ROM contient exactement 6 sries
de questions. Le principe est le mme pour les cardinalits de l'association entre Serie et
Question : une srie contient exactement 40 questions (cardinalit 40 : 40). En revanche,
une mme question peut apparatre dans plusieurs sries avec un numro d'ordre dirent
chaque fois, d'o la cardinalit 1 : N et l'attribut Numro qui caractrise l'assocation contient.

L'attribut NombreFautes est un attribut de l'association entre les ensembles d'entits Client
et Examen_Code et de l'association entre les ensembles d'entits Client et Seance_Code. En
eet, cet attribut caractrise l'association et non pas un client, une sance de code ou encore
un examen de code. Il caractrise le lien entre deux entits de ces ensembles.

Dduisez le schma relationnel de la base de donnes correspondante.

Vous prciserez les cls primaires des relations en les soulignant ainsi que les cls trangres en
les signalant par un # et en prcisant quoi elles font rfrence.
Dans votre schma relationnel, chaque relation doit tre spcie de la manire suivante :
N om(att1 ,...,attn ) o N om est le nom de la relation et att1 , ..., attn sont des noms d'attributs.
Le nom de la relation doit obligatoirement avoir un lien avec les noms des ensembles d'entits
(classes) ou des associations du schma de modlisation de la question 1.
Vous donnerez des explications claires et concises du passage au relationnel. Vous prciserez no-
tamment pourquoi et comment vous crez ou modiez certaines relations (1 ligne maximum par
relation).

Correction de l'exercice 1
Le modle relationnel dduit de la modlisation ci-dessus est le suivant. Les cls primaires sont
soulignes. Les cls trangres sont prcdes d'un '#'. Pour un rappel de ces notions, vous
pouvez vous rfrer aux pages 56 60 de [2]. Le passage d'un schma de modlisation un modle
relationnel est rappel aux pages 120 143 de [4].

Client(ClientID, Nom, Prnom, Adresse, DateNaissance)

Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Client.

CD-ROM(CdRomID, Editeur)
Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) CD-
ROM.

3
 Question(QuestionID, Intitul, Rponse, NiveauDicult, Thme)
Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Ques-
tion.

Serie(SerieID, #CdRomID)
Cette relation est issue du passage au relationnel de l'ensemble d'entits (classes) Serie.
En modlisation E/A, l'ensemble d'entits Serie tant un ensemble d'entits faibles de CR-
ROM, la cl primaire de la relation Serie est compose de l'identicateur de la srie et de
l'identicateur du CD-ROM auquel la srie appartient.

ContenuSerie(#QuestionID, SerieID, #CdRomID, Numro)

Cette relation est dduite du passage au relationnel de l'association Contient. Le cou-
ple d'attributs #CdRomID,#SerieID fait rfrence la cl primaire de la relation Serie.
L'attribut #QuestionID fait rfrence la cl primaire de la relation Question. Il ne faut
pas oublier l'attribut Numro qui caractrise l'association contient. Seance_Code(SeanceID,
Date, Heure, #CdRomID,#SerieID)
Cette relation est issue du passage au relationnel de l'ensemble d'entits (classes) Seance_Code.
Le couple d'attributs #CdRomID est une cl trangre qui fait rfrence la cl primaire
de la relation Serie. Ce couple d'attributs a t ajout lors du passage au relationel de
l'association est_diuse_pendant, une seule srie (d'un CR-ROM donn) tant diuse pen-
dant une sance de code (cardinalit 1:1).

Participation(#ClientID, #SeanceID, NombreFautes)

Cette relation est issue du passage au relationnel de l'association assiste_. Les attributs
#ClientID et #SeanceID sont des cls trangres qui font respectivement rfrences aux cls
primaires des relations Client et Seance. En eet, un client peut assister plusieurs sances
et, lors d'une sance, il y a plusieurs clients. Il ne faut pas oublier l'attribut NombreFautes
qui caractrise l'association assiste_.

Examen_Code(PassageCodeID, Date, Heure, LieuExamen)

Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Exa-
men_Code.

PassageCode(#PassageCodeID, #ClientID, NombreFautes)

Cette relation est dduite du passage au relationnel de l'association est_autoris__passer.
Les attributs #PassageCodeID et #ClientID font rfrence aux cls primaires des relations
Examen-Code et Client.

Exercice 2
Enonc de l'exercice
On souhaite construire une base de donnes grant des revues et les articles de ces revues. Une
revue est caractrise par un nom et une priodicit. Chaque revue parait sous la forme de numros,
chaque numro tant identi par un nombre relatif la revue et l'anne en cours (ex. le numro
N 12 de Linux Magazine en 2003 est dirent du numro N 12 de Linux Magazine en 2004). Un
numro est galement caractris par un nombre de pages. Chaque numro contient des articles
crits par un ou plusieurs auteurs. Un auteur est caractris par un nom, un prnom, ainsi qu'un
email. Chaque article possde un titre et un contenu. Un mme article peut apparatre dans
plusieurs plusieurs numros d'une mme revue ou de direntes revues. Lorsqu'un article apparat
dans un numro d'une revue, il a une page de dbut et une page de n. Un article peut faire
rfrence d'autres articles, en prcisant le numro et la revue dans lesquels l'article rfrenc a
t publi.

4
 Revue
Auteur Revue
Nom Auteur
ID
Priodicit Nom
Nom ID
1:N Priodicit
Prnom Nom
NumroID
Email Prnom
1 Email
1:N
1..*

comporte
comporte
crit

crit
1:1
1:M 0:M
Numro 1..*
est publi Article 1..*
dans Numro Article
1:N 1:M
ID Titre
PageDbut ID 1..* est publi dans 1..*
Anne Contenu 0:N fait rfrence Titre
PageFin
NbPages Anne Contenu
NbPages
*

rfrence
Modlisation Entit / Association Publication
*
PageDbut
fait
PageFin

Modlisation UML

Figure 2: Modlisation E/A et UML d'une base de donnes grant des revues.

La base de donnes doit permettre de rpondre des requtes telles que "Combien de numros
de Linux Magazine sont parus en 2004 ?", "Quels sont les titres des articles parus dans au moins
deux revues direntes ?", "Quels sont les auteurs ayant publis dans le numro 3 de la revue
L'Histoire en 2004 ?" etc.

La gure 2 prsente la modlisation Entit/Association (format Merise) et la modlisation UML

de l'nonc. Les explications ne sont donnes que pour le schma E/A mais peuvent tre adaptes
au schma UML. Pour une comprhension de la dirence entre une modlisation E/A ou UML et
le passage au relationnel, vous pouvez vous reporter l'ouvrage [4]. Les schmas de modlisation
ci-avant sont smantiquement clairs. Nanmoins, quels points ncessitent d'tre prciss.

L'ensemble d'entits Numro est un ensemble d'entits faibles de Revue au format Merise
(ou une association qualie en UML). En eet, ce choix de modlisation a t fait pour
reprsenter le fait que l'identicateur d'un numro est relatif la revue laquelle le numro
appartient. Un numro d'une revue donne tant identi par un nombre et une anne, ces
deux attributs (ID et Anne) sont souligns.

Les cardinalits de l'association entre les ensembles d'entits Numro et Article sont 1:N-1:M,
car un article peut apparatre dans plusieurs numros et un numro contient plusieurs articles.
Le principe est le mme pour les cardinalits de l'association entre Auteur et Article.

Les attributs PageDbut et PageFin caractrisent l'association entre Article et Numro (un
numro tant relatif une revue, il est inutile de faire une association avec Revue). En eet,
la page de dbut et la page de n peuvent varier, pour un mme article, lorsqu'il parat dans
plusieurs numros dirents.

Un article peut faire rfrence un autre article. Le numro et la revue dans lesquels l'article
rfrenc apparat doivent tre prciss dans l'article rfrenant. Par exemple, l'article in-
titul "Correction d'exercices en bases de donnes" peut faire rfrence l'article "Concepts
gnraux en BD relationnelle" du numro 12 de l'anne 2004 de la revue "Informatique mag-
azine". A cet eet, les ensembles d'entits Numro et Article ont t regroups au sein d'un
agrgat au format Merise (ou d'une classe-association en UML). Cet agrgat (ou cette classe-
association) reprsente l'article rfrenc, c'est--dire l'article et le numro de la revue o il
a t publi (il est inutile d'ajouter la revue l'agrgat puisque Numro est un ensemble
d'entits faibles de Revue). Cet agrgrat (ou cette classe-association) est associe Article,

5
 c'est--dire l'article rfrenant, dont on ne prcise pas le numro et la revue. Les cardi-
nalits ont pour borne infrieure 0 car un article peut ne rfrencer aucun autre article et un
article peut ne jamais tre rfrenc. Pour plus de dtails sur l'agrgation, vous pouvez vous
rfrer la page 37 de l'ouvrage [2] ou aux pages 55-56 de [3].

Dduisez le schma relationnel de la base de donnes correspondante.

Vous prciserez les cls primaires des relations en les soulignant ainsi que les cls trangres en les
signalant par un # et en prcisant quoi elles font rfrence.
Dans votre schma relationnel, chaque relation doit tre spcie de la manire suivante :
RN om (att1 ,...,attn ) o RN om est le nom de la relation et att1 , ..., attn sont des noms d'attributs.
Le nom de la relation doit obligatoirement avoir un lien avec les noms des ensembles d'entits
(classes) ou des associations du schma de modlisation de la question 1.
Vous donnerez des explications claires et concises du passage au relationnel. Vous prciserez no-
tamment pourquoi et comment vous crez ou modiez certaines relations (1 ligne maximum par
relation).

Correction de l'exercice 2
Le modle relationnel dduit de la modlisation ci-dessus est le suivant. Les cls primaires sont
soulignes. Les cls trangres sont prcdes d'un '#'. Pour un rappel de ces notions, vous
pouvez vous rfrer aux pages 56 60 de [2]. Le passage d'un schma de modlisation un modle
relationnel est rappel aux pages 120 143 de [4].

Revue(Nom, Priodicit)
Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Revue.

Numro(ID, Anne, #NomRevue, NbPages)

Cette relation est issue du passage au relationnel de l'ensemble d'entits (classes) Numro, qui
est un ensemble d'entits faibles (ou une association qualie) de Revue. La cl primaire de la
relation Numro est donc compose du couple (ID, Anne) qui identie un numro pour une
revue donne et de l'attribut #NomRevue, cl trangre faisant rfrence la cl primaire de
la relation Revue (c'est--dire faisant rfrence la revue laquelle le numro est relatif).

Auteur(ID, Nom, Prnom, Email)

Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Auteur.

Article(Titre, Contenu)
Cette relation est dduite du passage au relationnel de l'ensemble d'entits (ou classe) Article.

Ecriture(#Titre, #IDAuteur)
Cette relation est dduite du passage au relationnel de l'association entre Article et Auteur.
En eet, un article peut tre crit par plusieurs auteurs et un auteur peut crire plusieurs
articles. L'attribut #Titre est une cl trangre qui fait rfrence la cl primaire de la
relation Titre. L'attribut #IDAuteur est une cl trangre qui fait rfrence la cl primaire
de la relation Auteur.

Publication(#Titre, #NomRevue, #IDNumro, #AnneNumro, PageDbut, PageFin)

Cette relation est dduite du passage au relationnel de l'association entre Article et Numros.
La cl primaire de la relation est compose du titre de l'article publi (identi par #Titre)
et du numro dans lequel l'article apparat (identi par le triplet #NomRevue, #IDNumro,
#AnneNumro). L'attribut #Titre est une cl trangre qui fait rfrence la cl primaire
de la relation Titre. Les attributs (#NomRevue, #IDNumro, #AnneNumro) forment une
cl trangre qui fait rfrence la cl primaire de la relation Numro. Il faut bien noter,
ici, qu'une cl trangre fait toujours rfrence la cl primaire d'une autre relation. Or,
dans cet exemple, la cl primaire de la relation Numro est compose de trois attributs qui
doivent galement apparatre dans toutes cls trangres y faisant rfrence. Il ne faut pas

6
non plus oublier d'ajouter dans la relation Publication les attributs PageDbut et PageFin qui
caractrise l'association est_publi_dans.

Rfrence(#TitreArticleRfrenant, #TitreArticleRfrenc, #NomRevueArticleRfrenc,

#IDNumroArticleRfrenc, #AnneNumroArticleRfrenc)
Cette relation est dduite du passage au relationnel de l'association entre l'ensemble d'entits
(ou la classe) Article et l'agrgat (ou la classe-association) regroupant Numro et Article. Les
noms des attributs sont particulirement longs pour que la smantique soit claire. L'attribut
#TitreArticleRfrenant est une cl trangre qui fait rfrence la cl primaire de la rela-
tion Article. Cet attribut reprsente le titre de l'article rfrenant (contenant une rfrence
un article publi dans un numro). L'attribut #TitreArticleRfrenc est une cl trangre
qui fait rfrence la cl primaire de la relation Article. Cet attribut reprsente le titre de
l'article rfren. Les attributs (#NomRevueArticleRfrenc, #IDNumroArticleRfrenc,
#AnneNumroArticleRfrenc) forment une cl trangre qui fait rfrence la cl primaire
de la relation Numro. Ils reprsentent le numro de la revue dans lequel a t publi l'article
rfrenc.

7
Langage d'interrogation

Exercice 3
Enonc de l'exercice
On suppose qu'une bibliothque gre une base de donnes dont le schma est le suivant (les cls
primaires des relations sont soulignes) :

Emprunt(Personne, Livre, DateEmprunt, DateRetourPrevue, DateRetourEective)

Retard(Personne, Livre, DateEmprunt, PenalitRetard)

Exprimer, lorsque cela est possible, les requtes suivantes en algbre relationnelle, en calcul variable nuplet
et en SQL.

1. Quelles sont les personnes ayant emprunt le livre "Recueil Examens BD" ?

2. Quelles sont les personnes n'ayant jamais rendu de livre en retard ?

3. Quelles sont les personnes ayant emprunt tous les livres (emprunts au moins une fois) ?

4. Quels sont les livres ayant t emprunts par tout le monde (i.e. tous les emprunteurs) ?

5. Quelles sont les personnes ayant toujours rendu en retard les livres qu'elles ont emprunts ?

Correction de l'exercice 3
Dans cet exercice, le schma relationnel est particulirement simple, an que l'expression des re-
qutes soit facile exprimer. Il s'agit nanmoins de requtes complexes. Vous pouvez vous entraner
exprimer ces requtes en amliorant le schma, c'est--dire en ajoutant deux relations Personne
et Livre et prcisant les cls trangres dans les relations Emprunt et Retard faisant rfrence une
personne et un livre.

1. Quelles sont les personnes ayant emprunt le livre "Recueil Examens BD" ?

En algbre relationnelle : P ersonne (Livre=0 Recueil...0 (Emprunt))

L'algbre relationnelle est un langage compos d'oprations ensemblistes. Il permet d'indiquer

comment le rsultat de la requte est calcul en termes d'oprations ensemblistes sur des en-
sembles de nuplets (les relations). Dans cette requte par exemple, le rsultat est calcul
en parcourant tous les nuplets de la relation Emprunt, en y slectionnant les nuplets dont
l'attribut Livre a pour valeur 'Recueil...' et en prenant uniquement les valeurs de l'attribut
Personne (i.e. en projetant sur l'attribut Personne).

En calcul relationnel : {t.P ersonne | Emprunt(t) (u.Livre =0 Recueil...0 ) }

Le calcul relationnel dcrit, sous forme logique, le rsultat de la requte (sans prciser com-
ment on le calcule). Le rsultat de la requte contient les valeurs de l'attribut P ersonne des
nuplets t de la relation Emprunt tels que l'attribut Livre corresponde 'Recueil Examens

8
 BD'.

En SQL:

SELECT Personne
FROM Emprunt WHERE Livre = 'Recueil...'

Il aurait galement t possible de remplacer la clause WHERE par WHERE Livre LIKE 'Recueil%'
indiquant que l'on recherche les emprunteurs des ouvrages dont le titre commence par 'Re-
cueil'.

2. Quelles sont les personnes n'ayant jamais rendu de livre en retard ?

En algbre relationnelle : P ersonne (Emprunt) P ersonne (Retard)

La rsultat de la requte est calcul en prenant toutes les valeurs de l'attribut Personne
dans la relation Emprunt et en liminant les valeurs de ce mme attribut apparaissant gale-
ment dans la relation Retard. Il s'agit d'une dirence entre deux ensembles.

En calcul relationnel :

{t.P ersonne | Emprunt(t) [ u Retard(u) (u.P ersonne = t.P ersonne) )]}

Le rsultat de la requte contient les valeurs de l'attribut P ersonne des nuplets t de la

relation Emprunt (donc des personnes empruntant) tels qu'il n'existe pas de nuplets u dans
la relation Retard avec la mme valeur pour l'attribut P ersonne (donc telles qu'il n'existe
pas de retards associs ces personnes).

En SQL, deux manires possibles, par simple traduction en SQL de la requte en calcul
relationnel (le calcul relationnel tant l'origine de la syntaxe de SQL) :

SELECT t.Personne FROM Emprunt t SELECT Personne FROM Emprunt

WHERE NOT EXISTS (SELECT * FROM Retard u WHERE Personne NOT IN
WHERE u.Personne=t.Personne (SELECT Personne FROM Retard)
)

Les variables nuplet (ex. t et u) ne sont ncessaire que lorsqu'il y a ambigut au niveau des
noms d'attributs (cf. requte de gauche).

3. Quelles sont les personnes ayant emprunt tous les livres (emprunts au moins
une fois) ?

En algbre relationnelle : P ersonne,Livre (Emprunt) Livre (Emprunt)

Le rsultat de cette requte est calcul en utilisant l'oprateur de division. Pour une bonne
comprhension de la division, vous pouvez vous reporter la page 99 de [2].
La sous-requte Livre (Emprunt) correspond la liste des livres emprunts. Le rsultat de la
sous-requte P ersonne,Livre (Emprunt) contient tous les couples (Personne, Livre emprunt
au moins une fois par cette personne). Le rsultat de la division sera donc la liste des person-
nes associes, dans le rsultat de P ersonne,Livre (Emprunt), chacun des livres apparaissant
dans le rsultat de la requte Livre (Emprunt).

9
 En calcul relationnel :

{t.P ersonne | Emprunt(t) [ u (Emprunt(u)) = ( v Emprunt(v) (v.P ersonne =

t.P ersonne) (u.Livre = v.Livre) )]}
Le rsultat de la requte contient les valeurs de l'attribut P ersonne des nuplets t de la relation
Emprunt tels que quel que soit un nuplet s'il s'agit d'un livre emprunt (donc d'un nuplet
u dans Emprunt) alors on trouve un nuplet v dans Emprunt associant cette personne ce
livre (c'est--dire v.P ersonne = t.P ersonne et u.Livre = v.Livre).

On peut galement l'crire de la manire suivante :

{t.P ersonne | Emprunt(t) [ u (Emprunt(u)) ( v Emprunt(v) (v.P ersonne =
t.P ersonne) (u.Livre = v.Livre) )]}

Ce qui signie que le rsultat de la requte contient les valeurs de l'attribut P ersonne des
nuplets t de la relation Emprunt tels que quel que soit un nuplet u soit c'est n'est pas un
nuplet de Emprunt soit (implicitement c'est un nuplet de Emprunt et) on trouve un nuplet
v dans Emprunt associant cette personne ce livre (c'est--dire v.P ersonne = t.P ersonne
et u.Livre = v.Livre).

D'o dit de manire ngative :

{t.P ersonne | Emprunt(t) [ u Emprunt(u) ( v Emprunt(v)(v.P ersonne = t.P ersonne)
(u.Livre = v.Livre) )]}

En SQL, simple traduction de la requte en calcul relationnel :

SELECT t.Personne
FROM Emprunt t
WHERE NOT EXISTS ( SELECT *
FROM Emprunt u WHERE NOT EXISTS ( SELECT *
FROM Emprunt v
WHERE v.Personne=t.Personne
AND v.Livre=u.Livre
)
)

4. Quels sont les livres ayant t emprunts par tout le monde (i.e. tous les em-
prunteurs) ?

En algbre relationnelle : P ersonne,Livre (Emprunt) P ersonne (Emprunt)

Le rsultat de cette requte est calcul en utilisant galement l'oprateur de division.

La sous-requte P ersonne (Emprunt) correspond la liste des emprunteurs. Le rsultat de la
sous-requte P ersonne,Livre (Emprunt) contient tous les couples (Personne ayant emprunt
au moins une fois, Livre emprunt au moins une fois par cette personne). Le rsultat de la
division sera donc la liste des livres associs, dans le rsultat de P ersonne,Livre (Emprunt),
chacun des emprunteurs apparaissant dans le rsultat de la requte P ersonne (Emprunt).

En calcul relationnel :

{t.Livre | Emprunt(t) [ u (Emprunt(u)) = ( v Emprunt(v) (u.Livre = t.Livre)

(v.P ersonne = u.P ersonne) )]}

Le rsultat de la requte contient les valeurs de l'attribut Livre des nuplets t de la rela-
tion Emprunt tels que quel que soit un nuplet s'il s'agit d'un emprunteur (donc d'un nuplet u
dans Emprunt) alors on trouve un nuplet v dans Emprunt associant ce livre cet emprunteur

10
 (c'est--dire u.Livre = t.Livre et v.P ersonne = u.P ersonne ).

On peut galement l'crire de la manire suivante :

{t.Livre | Emprunt(t) [ u (Emprunt(u)) ( v Emprunt(v) (u.Livre = t.Livre)
(v.P ersonne = u.P ersonne) )]}

Ce qui signie que le rsultat de la requte contient les valeurs de l'attribut Livre des nu-
plets t de la relation Emprunt tels que quel que soit un nuplet soit il ne s'agit pas d'un
nuplet u dans Emprunt soit (il s'agit d'un d'un nuplet u dans Emprunt et) il existe un nu-
plet v dans Emprunt associant ce livre cet emprunteur (c'est--dire u.Livre = t.Livre et
v.P ersonne = u.P ersonne ). D'o dit de manire ngative :
{t.Livre | Emprunt(t) [ u Emprunt(u) ( v Emprunt(v) (u.Livre = t.Livre)
(v.P ersonne = u.P ersonne) )]}

En SQL, simple traduction de la requte en calcul relationnel :

SELECT t.Livre FROM Emprunt t

WHERE NOT EXISTS ( SELECT * FROM Emprunt u
WHERE NOT EXISTS ( SELECT * FROM Emprunt v
WHERE u.Livre=t.Livre AND v.Personne=u.Personne
)
)

5. Quelles sont les personnes ayant toujours rendu en retard les livres qu'elles ont
emprunts ?

En algbre relationnelle : Il n'est pas possible d'exprimer cette requte par une division.
La requte est donc dcompose en deux sous-requtes. La requte, R1 , ci-dessous, retourne
la liste des personnes ayant emprunt au moins un livre sans le rendre en retard.

R1 = P ersonne [P ersonne,Livre,DateEmprunt (Emprunt) P ersonne,Livre,DateEmprunt (Retard)]

La requte ci-dessous enlve de la liste des personnes qui empruntent des livres (sous-requte
de gauche) la liste des personnes ayant rendu au moins un livre sans retard (requte R1 ). Cela
correspond comment calculer le rsultat de la requte que l'on recherche.

P ersonne (Emprunt) R1

En calcul relationnel :

{t.P ersonne | Emprunt(t) [ u [Emprunt(u) (u.P ersonne = t.P ersonne)] = ( v

Retard(v) (v.P ersonne = u.P ersonne) (u.Livre = v.Livre) )]}

Le rsultat de la requte contient les valeurs de l'attribut P ersonne des nuplets t de la relation
Emprunt tels que quel que soit un nuplet s'il s'agit d'un livre emprunt par cette personne
(donc d'un nuplet u dans Emprunt tel que u.P ersonne = t.P ersonne) alors on trouve un nu-
plet v dans Retard associant cette personne ce livre (c'est--dire v.P ersonne = u.P ersonne
et u.Livre = v.Livre).

On peut galement cire :

{t.P ersonne | Emprunt(t) [ u [Emprunt(u) (u.P ersonne = t.P ersonne)] ( v
Retard(v) (v.P ersonne = u.P ersonne) (u.Livre = v.Livre) )]}

Le rsultat de la requte contient les valeurs de l'attribut P ersonne des nuplets t de la

relation Emprunt tels que quel que soit un nuplet soit il ne s'agit pas d'un livre emprunt
par cette personne (donc d'un nuplet u dans Emprunt tel que u.P ersonne = t.P ersonne)

11
 soit on trouve un nuplet v dans Retard associant cette personne ce livre (c'est--dire
v.P ersonne = u.P ersonne et u.Livre = v.Livre).

D'o dit de manire ngative :

{t.P ersonne | Emprunt(t) [ u Emprunt(u)(u.P ersonne = t.personne) ( v Retard(v)
(v.P ersonne = u.P ersonne) (u.Livre = v.Livre) )]}

En SQL, l encore , simple traduction de la requte en calcul relationnel:

SELECT t.Personne
FROM Emprunt t
WHERE NOT EXISTS (SELECT * FROM Emprunt u WHERE u.Personne=t.Personne
AND NOT EXISTS (SELECT * FROM Retard v WHERE v.Personne=u.Personne
AND v.Livre=u.Livre )
)

Exercice 4
Enonc de l'exercice
Un organisme de gestion de spectacles, de salles de concert et de vente de billets de spectacles gre
une base de donnes dont le schma relationnel est le suivant :

Spectacle(Spectacle_ID, Titre, DateDb, Dure, Salle_ID, Chanteur)

Concert (Concert_ID, Date, Heure, Spectacle_ID)
Salle (Salle_ID, Nom, Adresse, Capacit)
Billet (Billet_ID, Concert_ID, Num_Place, Catgorie, Prix)
Vente (Vente_ID, Date_Vente, Billet_ID, MoyenPaiement)

Les attributs souligns sont les attributs appartenant la cl primaire. Ils sont de type entier.
L'attribut Salle_ID de la relation Spectacle est une cl trangre qui fait rfrence l'attribut de
mme nom de la relation Salle. L'attribut Spectacle_ID de la relation Concert est une cl trangre
qui fait rfrence l'attribut de mme nom de la relation Spectacle. L'attribut Concert_ID de la
relation Billet est une cl trangre qui fait rfrence l'attribut de mme nom de la relation Con-
cert. L'attribut Billet_ID de la relation Vente est une cl trangre qui fait rfrence l'attribut
de mme nom de la relation Billet.

Exprimez, lorsque cela est possible, les requtes suivantes en algbre relationnelle,
en calcul relationnel variable nuplet et en SQL.
1. Quelles sont les dates du concert de Corneille au Zenith ?

2. Quels sont les noms des salles ayant la plus grande capacit ?

3. Quels sont les chanteurs n'ayant jamais ralis de concert la Cygale ?

4. Quels sont les chanteurs ayant ralis au moins un concert dans toutes les salles ?

5. Quels sont les dates et les identicateurs des concerts pour lesquels il ne reste aucun billet
invendu ?

Correction de l'exercice 4
1. Quelles sont les dates du concert de Corneille au Zenith ?

En algbre relationnelle : Date [Concert o

n Chanteur=0 Corneille0 (Spectacle) o
n N om=0 Zenith0 (Salle)]

12
 Cette requte comporte deux jointures naturelles. La premire jointure, entre les relations
Concert et Spectacle, associe les nuplets de Spectacle, correspondant aux spectacles du chanteur
`Corneille' (puisqu'il y a une slection avant), avec les nuplets de la relation Concert ayant la
mme valeur pour l'attribut Spectacle_ID. La jointure se fait naturellement sur l'attribut de
mme nom, Spectacle_ID. La deuxime jointure associe les nuplets rsultats de la premire
jointure (donc les concerts des spectacles de 'Corneille') avec le nuplets correspondant la
salle du 'Zenith' (rsultat de la requte de slection N om=0 Zenith0 (Salle)). La jointure se fait
naturellement sur l'attribut commun Salle_ID. La projection nale se fait sur l'attribut Date.

En calcul relationnel :

{t.Date | Concert(t) [ u, v Spectacle(u) Salle(v) (u.Spectacle_ID = t.Spectacle_ID)

(u.Chanteur =0 Corneille0 ) (v.N om =0 Zenith0 ) (u.Salle_ID = v.Salle_ID) ] }

La requte retourne les dates des concerts pour lesquels il existe un spectacle de 'Corneille'
associ la salle du 'Zenith'. Le rsultat de la requte contient donc les valeurs de l'attribut
Date des nuplets t de la relation Concert tels qu'il existe un nuplet u dans Spectacle, cor-
respondant un spectacle de 'Corneille' (c'est--dire dont l'attribut Chanteur a pour valeur
'Corneille'), avec la mme valeur pour l'attribut Spectacle_ID que le nuplet t et tels qu'il
existe aussi un nuplet v dans la relation Salle, correspondant la salle du 'Zenith' (dont
l'attribut Nom a pour valeur 'Zenith'), avec la mme valeur pour l'attribut Salle_ID que celle
de l'attribut Salle_ID du nuplet u.

En SQL, par traduction immdiate de la requte en calcul variable nuplet :

SELECT Date
FROM Concert t, Spectacle u, Salle v
WHERE t.Spectacle_ID = u.Spectacle_ID
AND u.Chanteur = 'Corneille'
AND u.Salle_ID = v.Salle_ID
AND v.Nom = 'Zenith'

2. Quels sont les noms des salles ayant la plus grande capacit ?

En algbre relationnelle : Cette requte ne peut pas s'crire en algbre relationnelle non ten-
due. Il faut un oprateur maximum. Pour plus de dtails sur l'algbre relationnelle tendue,
vous pouvez vous reporter aux pages 103 111 de [3] ou aux pages 221 230 de [1].

En algbre relationnelle tendue1 , la requte s'exprime par:

N om ((Capacite>=CapaciteM ax) Salle_ID,CapacitM ax [Salle(M AX(Capacite)CapaciteM ax) (Salle))])

La requte Salle_ID,CapacitM ax [Salle(M AX(Capacite)CapaciteM ax) (Salle))] retourne une

relation temporaire de deux colonnes, la pemire contenant les valeurs de l'attribut Salle_ID
de la relation Salle et la deuxime colonne contenant une seule valeur (repte pour toutes
les valeurs de Salle_ID) correspondant la valeur maximale de l'attribut Capacit (calcule
par la fonction d'agrgation MAX et renomme en CapaciteMAX). L'oprateur utilis est le
produit cartsien (). Pour obtenir le nom des salles avec la plus grande capacit, il sut
donc de joindre cette relation temporaire la relation Salle et de slectionner les nuplets
ayant une valeur de Capacit superieure ou gale celle de l'attribut CapaciteMax.

En calcul relationnel :
{t.N om | Salle(t) [ u Salle(u) (u.Capacite >= t.Capacite) ] }

Cette requte retourne les valeurs de l'attribut Nom des nuplets t de la relation Salle pour
1 L'algbre relationnelle tendue n'est pas au programme de l'examen.

13
 lesquels il n'existe pas de nuplets u dans Salle avec une valeur de l'attribut Capacit suprieure
ou gale.

En SQL:

Il est possible de traduire directement la requte exprime en calcul relationnel, comme ci-
dessous.

SELECT Nom
FROM Salle t
WHERE NOT EXISTS (SELECT *
FROM Salle u
WHERE u.Capacit >= t. Capacit)

Il est galement possible d'utiliser l'oprateur d'agrgation M AX , comme pour la requte

suivante.

SELECT Nom
FROM Salle
WHERE Capacit >= ( SELECT (MAX(Capacit)
FROM Salle
)

Il est galement possible d'utiliser le mot-cl ALL :

SELECT Nom
FROM Salle
WHERE Capacit >= ALL ( SELECT Capacit
FROM Salle
)

3. Quels sont les chanteurs n'ayant jamais ralis de concert la Cygale ?

En algbre relationnelle : Chanteur (Spectacle)Chanteur [Spectacle o

n (N om=0 Cygale0 ) (Salle)]

La requte Chanteur [Spectacle o

n (N om=0 Cygale0 ) (Salle)] retourne les chanteurs ayant chant
au moins une fois dans la salle de la 'Cygale'. Le rsultat de la requte fnale est obtenu en
supprimant ces chanteurs de la liste de tous les chanteurs.

En calcul relationnel :

{t.Chanteur | Spectacle(t) [ u, v Spectacle(u) Salle(v) (v.N om =0 Cygale0 )

(u.Chanteur = t.Chanteur) (u.Salle_ID = v.Salle_ID) ] }

La requte retourne les valeurs de l'attribut Chanteur des nuplets t de la relation Specta-
cle tels qu'il ne soit pas possible de trouver un spectacle de ce mme chanteur la 'Cygale'
(i.e. de trouver un nuplet u dans Spectacle avec la mme valeur pour l'attribut Chanteur et
un nuplet v dans Salle avec 'Cygale' comme valeur de l'attribut Nom et avec la mme valeur
que u.Salle_ID pour l'attribut Salle_ID).

En SQL:

SELECT Chanteur
FROM Spectacle
WHERE Chanteur NOT IN (SELECT Chanteur

14
 FROM Spectacle u, Salle v
WHERE u.Salle_ID=v.Salle_ID
AND v.Nom='Cygale'
)

Cette requte peut aussi s'exprimer avec un NOT EXISTS en utilisant une variable nuplet t
dans le premier F ROM , par une simple traduction du calcul relationnel :

SELECT Chanteur
FROM Spectacle t
WHERE Chanteur NOT EXISTS ( SELECT *
FROM Spectacle u, Salle v
WHERE u.Salle_ID=v.Salle_ID
AND v.Nom='Cygale'
AND t.CHanteur=u.Chanteur
)

4. Quels sont les chanteurs ayant ralis au moins un concert dans toutes les salles
?

En algbre relationnelle : Chanteur,Salle_ID (Spectacle o

n Salle) Salle_ID (Salle)

La requte Salle_ID (Salle) retourne tous les identicateurs de salle.

La requte Chanteur,Salle_ID (Spectacle o n Salle) retourne une relation associant chaque
chanteur l'identicateur de la salle dans laquelle il a ralis au moins un spectacle.
La division va donc retourner les chanteurs associs au moins une fois toutes les salles de la
base.

En calcul relationnel :
{t.Chanteur | Spectacle(t) [ u (Salle(u)) = ( v Spectacle(v) (v.Chanteur = t.Chanteur)
(u.Salle_ID = v.Salle_ID) ) ] }

La requte retourne les valeurs de l'attribut Chanteur des nuplets t de la relation Specta-
cle tels que pour quel que soit un nuplet, s'il s'agit d'une salle (donc un nuplet u pris dans
Salle), alors il existe un spectacle de ce chanteur dans cette salle (donc il existe un nuplet v
dans Spectacle correspondant ce chanteur, avec v.Chanteur = t.Chanteur, et cette salle,
avec u.Salle_ID = v.Salle_ID).

On peut galement crire :

{t.Chanteur | Spectacle(t) [ u (Salle(u)) ( v Spectacle(v) (v.Chanteur = t.Chanteur)
(u.Salle_ID = v.Salle_ID) ) ] }

La requte retourne les valeurs de l'attribut Chanteur des nuplets t de la relation Spectacle
tels que pour quel que soit un nuplet, soit il ne s'agit pas d'une salle (donc il ne s'agit pas d'un
nuplet u de Salle), soit (implicitement il s'agit d'un nuplet u de Salle et) il existe un spectacle
de ce chanteur dans cette salle (donc il existe un nuplet v dans Spectacle correspondant ce
chanteur, avec v.Chanteur = t.Chanteur, et cette salle, avec u.Salle_ID = v.Salle_ID).

D'o dit de manire ngative :

{t.Chanteur | Spectacle(t) [ u Salle(u) ( v Spectacle(v) (v.Chanteur = t.Chanteur)

(u.Salle_ID = v.Salle_ID) ) ] }

En SQL:

SELECT Chanteur FROM Spectacle t WHERE NOT EXISTS

15
 ( SELECT * FROM Salle u WHERE NOT EXISTS
( SELECT * FROM Spectacle v
WHERE v.Chanteur = t. Chanteur AND u.Salle_ID = v.Salle_ID
)
)

5. Quels sont les dates et les identicateurs des concerts pour lesquels il ne reste
aucun billet invendu ?

En algbre relationnelle : Cette requte tant complexe et ne peut pas s'exprimer l'aide
d'une division. Il est plus simple de l'crire en la dcomposant. Une premire sous-requte
R1 va permettre de dterminer les billets invendus :

R1 = Billet_ID (Billet) Billet_ID (V ente)

La requte R1 supprime de la liste des billets (Billet_ID (Billet)), ceux qui ont t vendus
(Billet_ID (V ente)). Pour obtenir les concerts auxquels appartiennent ces billets invendus, il
faut faire une jointure avec la relation Billet (pour obtenir la valeur de l'attribut Concert_ID
associ au billet) puis avec Concert (pour obtenir la date du concert associ), soit :

R2 = Date,Concert_ID (Concert o n [Billet_ID (Billet) Billet_ID (V ente)])

n Billet o
| {z }
R1

Au nal, on supprime la liste des identicateurs de concerts et de leur date associe au rsultat
de la requte R2 , soit :
R2
z }| {
Date,Concert_ID (Concert)Date,Concert_ID (Concert o
n Billet o
n [Billet_ID (Billet) Billet_ID (V ente)])
| {z }
R1

En calcul relationnel :

{t.Concert_ID, t.Date | Concert(t) [ u Billet(u) (u.Concert_ID = t.Concert_ID) (

v V ente(v) (v.Billet_ID = u.Billet_ID) ) ] }

La requte retourne les valeurs des attributs Concert_ID et Date des nuplets t de la rela-
tion Concert tels que pour tous les billets de ce concert (donc pour tous les nuplets u dans
Billet tels que u.Concert_ID = t.Concert_ID), il existe une vente de ce billet (donc il existe
un nuplet v dans Vente correspondant ce billet, i.e. tel que v.Billet_ID = u.Billet_ID).

D'o dit de manire ngative :

{t.Concert_ID, t.Date | Concert(t) [ u Billet(u) (u.Concert_ID = t.Concert_ID)
( v V ente(v) (v.Billet_ID = u.Billet_ID) ) ] }

En SQL:

SELECT Concert_ID, Date

FROM Concert t
WHERE NOT EXISTS (SELECT * FROM Billet u
WHERE u.Concert_ID=t.Concert_ID
AND NOT EXISTS (SELECT * FROM Vente v
WHERE u.Billet_ID = v.Billet_ID
)
)

16
Dpendances fonctionnelles et
normalisation

Exercice 5
Enonc de l'exercice
Soit un schma de bases de donnes contenant les relation suivantes :

Bureau(NumBureau, NumTelephone, Taille) avec

FBureau = { N umBureau N umT elephone, T aille; N umT elephone N umBureau; }
Occupant(NumBureau, PersonneID) avec FOccupant = { N umBureau P ersonneID }
Materiel(NumBureau, NumPC) avec FM ateriel = { N umP C N umBureau }

1. Les contraintes ci-dessous sont-elles vries par ce schma de bases de donnes? Si la rponse
est positive, expliquez pourquoi. Si la rponse est ngative, indiquez quelle(s) dpendance(s)
fonctionnelle(s) il faut ajouter/supprimer ou modier pour que la contrainte soit vrie.

(a) "Un bureau peut contenir plusieurs postes tlphoniques."

(b) "Il y a une et une seule personne par bureau."
(c) "Un bureau contient un seul ordinateur."

2. A partir des familles de dpendances fonctionnelles initiales donnes dans l'nonc, indiquez
quelles sont les cls minimales possibles de chaque relation.

Correction de l'exercice 5
1. Vrication des contraintes exprimes par des dpendances fonctionnelles :

(a) "Un bureau peut contenir plusieurs postes tlphoniques"

Cette contrainte n'est pas vrie car FBureau contient la dpendance fonctionnelle
N umBureau N umT elephone donc un bureau est associ un et un seul numro de
tlphone. Pour que la contrainte soit vrie, il faudrait supprimer cette dpendances
fonctionnelle.
(b) "Il y a une et une seule personne par Bureau."
Cette contrainte est vrie car FOccupant contient la dpendance fonctionnelle N umBureau
P ersonneID, donc un numro de bureau est associe une et une seule personne.
(c) "Un bureau contient un seul ordinateur."
Cette contrainte n'est pas vrie car il y a juste l'information qu'un ordinateur est dans
un seul bureau (N umP C N umBureau) mais pas l'inverse. Pour que la contrainte
soit vrie, il faudrait ajouter la dpendance fonctionnelle N umBureau N umP C .

17
 2. Dtermination des cls minimales des relations :

FBureau = { N umBureau N umT elephone, T aille; N umT elephone N umBureau; }

La relation Bureau a donc deux cls minimales possibles : N umBureau et N umT elephone.

En eet, partir de l'attribut N umBureau il est possible de dduire les deux autres attributs
de la relation (par la premire dpendance fonctionnelle). Par l'attribut N umT elephone, il est
possible de dduire N umBureau (2me dpendance fonctionnelle) et donc l'attribut T aille
(par la premire dpendance fonctionnelle). On a donc :
[N umBureau]+ = {N umBureau, N umT elephone, T aille} car N umBureau N umT elephone, T aille.
et [N umT elephone]+ = {N umT elephone, N umBureau, T aille}, car N umT elephone N umBureau
et donc par transitivit avec N umBureau T aille, on obtient N umT elephone T aille.

FOccupant = { N umBureau P ersonneID }

La relation Occupant a donc une seule cl minimale possible : N umBureau.

FM ateriel = { N umP C N umBureau }

La relation M ateriel a donc une seule cl minimale possible : N umP C .

Pour plus de dtails sur les dpendances fonctionnelles, vous pouvez vous reporter aux pages
422 430 de [2].

Exercice 6
Enonc de l'exercice
Soit R une relation dont le schma est le suivant :
R(UtilisateurID, Nom, Prnom, AdresseEmail, Login, Passwd, ServeurMail).

1. Exprimer, l'aide de dpendances fonctionnelles, les contraintes suivantes que doivent vrier
les instances de la relation R :

(a) "On peut dduire le nom et le prnom d'un utilisateur partir de son identicateur."

(b) "Un utilisateur (identi par son identicateur) possde un seul login et un seul password
par serveur de mails."

(c) "Une adresse email est associe un et un seul identicateur d'utilisateur."

Attention : un utilisateur peut avoir plusieurs adresses de mails.

(d) "Une adresse email est associe un et un seul serveur de mails."

2. Indiquer, partir de la famille de dpendances fonctionnelles, issue de la question 1, quelles

sont les cls mimimales de R.

3. Indiquer, partir de la famille de dpendances fonctionnelles, issue de la question 1, en quelle

forme normale est la relation R.

18
Correction de l'exercice 6
1. Expression de contraintes par des dpendances fonctionnelles :

(a) "On peut dduire le nom et le prnom d'un utilisateur partir de son identicateur."
Cette contrainte s'exprime par la dpendance fonctionnelle :
UtilisateurID Nom, Prnom
En eet, un identicateur d'utilisateur est associ un et un seul nom et un et un seul
prnom.

(b) "Un utilisateur (identi par son identicateur) possde un seul login et un seul password
par serveur de mails."
Cette contrainte s'exprime par la dpendance fonctionnelle :
UtilisateurID, ServeurMail Login, Passwd
En eet pour un couple (identicateur d'utilisateur, serveur de mail) est associ un et
un seul login et un et un seul mot de passe.

(c) "Une adresse email est associe un et un seul identicateur d'utilisateur."

Attention : un utilisateur peut avoir plusieurs adresses de mails.
Cette contrainte s'exprime par la dpendance fonctionnelle :
AdresseEmail UtilisateurID
En eet, une adresse mail est associe un et un seul identicateur d'utilisateur.

(d) "Une adresse email est associe un et un seul serveur de mails."

Cette contrainte s'exprime par la dpendance fonctionnelle :
AdresseEmail ServeurMail
En eet, une adresse mail est associe un et un seul serveur de mails.

2. Identication des cls minimales de la relation R

La famille de dpendances fonctionnelles associes R est :

F = { UtilisateurID Nom, Prnom; UtilisateurID, ServeurMail Login, Passwd;

AdresseEmail UtilisateurID; AdresseEmail ServeurMail }

L'attribut AdresseEmail ne peut tre dduit d'aucun autre attribut, il doit donc appartenir
tous les cls minimales possibles de la relation. A partir de l'attribut AdresseEmail on
peut dduire l'identicateur de l'Utilisateur est donc, par transitivit, le nom et le prnom
de l'utilisateur : AdresseEmail UtilisateurID Nom, Prnom. A partir de ce mme
attribut, on peut en dduire aussi le nom du serveur de mail et donc avec l'identicateur
d'utilisateur, le login et le mot de passe de l'utilisateur :
AdresseEmail UtilisateurID, ServeurMail Login, Passwd
D'o : [AdresseEmail]+ = { AdresseEmail, UtilisateurID, Nom, Prnom, ServeurMail, Lo-
gin, Passwd } = R

La relation R a donc une seule cl minimale possible : AdresseEmail.

3. Dduction de la forme normale du schma de la relation R

Les deux dernires dpendances fonctionnelles sont de la forme cl primaire autre attribut,
et vrient donc les proprits de la forme normale BCNF. En revanche, les deux premires
dpendances fonctionnelles sont transitives puisqu'elles ne sont composes que d'attributs
n'appartenant pas une cl. Par consquent, le schma de la relation R est en deuxime
forme normale.

19
Pour plus de dtails sur les formes normales, vous pouvez vous rfrer aux pages 100 117
de l'ouvrage [1], au chapitre 15 de l'ouvrage [2] ou au chapitre 7 de l'ouvrage [3].

20
Bibliography

[1] H. Garcia-Molina, J.D. Ulmann et J. Widow, Database Systems - The Complete Book,
Prentice Hall, 2002

[2] R. Ramakrishnan et J. Gehrke, Database Management Systems, Second Edition; McGraw-

Hill, 2000, ISBN: 0-07-232206-3

[3] A. Silberschatz, H.F. Korth et S. Sudarshan, Database System Concepts, 4th Edition,
McGraw-Hill, 2002, ISBN: 0-07-228363-7

[4] C. Soutou, De UML SQL - Conception de bases de donnes, Eyrolles, 2002, ISBN: 2-212-
11098-7

21