Licence MI2E 2007-2008

Bases de Données : exercices corrigés

Maude Manouvrier

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

conformément aux articles L111-1 et L122-4 du code de la propriété 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
SEANCE−CODE CLIENT
ClientID ASSISTE_A SEANCE−CODE
0:N 1:M
Nom SEANCEID ClientID
1..* ASSISTE_A *
Prénom NombreFautes DATE Nom SEANCEID
Adresse 1:1 HEURE Prénom 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
CD−ROM

0:8 CdRomID CD−ROM

Editeur *
EXAMEN_CODE CdRomID
EXAMEN_CODE Editeur
6:6
PassageCodeID
Date PassageCodeID SérieID
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
Réponse Numéro SérieID Intitulé
NiveauDifficulté Réponse SérieID
Thème NiveauDifficulté 1
Thème
POSITION_QUESTION

Numéro

MODELISATION ENTITE − ASSOCIATION MODELISATION UML

Figure 1: Modélisation E/A et UML de la base de données d'une l'auto-école.

Une auto-école souhaite construire une base de données pour gérer les examens théoriques du
code de la route de ses élèves. Chaque élève est identié par un numéro unique et est caractérisé par
un nom, un prénom, une adresse et une date de naissance. Chaque élève assiste à plusieurs séances
de code (autant qu'il le souhaite). Chaque séance est caractérisée par une date et une heure. A
chaque séance de code, le directeur de l'auto-école choisit une série de questions sur un CD-ROM.
Chaque CD-ROM est identié par un numéro et est caractérisé par un nom d'éditeur. Chaque
CD-ROM est composé de 6 séries, numérotées de 1 à 6. Chaque série est composée de 40 questions.
Chaque question est identiée par un intitulé et est caractérisée par une réponse, un niveau de
diculté et un thème. Une même question peut apparaître dans plusieurs séries avec un numéro
d'ordre pour chaque série ; par exemple une même question peut apparaître comme question N◦ 2
dans la série 5 du CD-ROM 15 et comme question N◦ 12 dans la série 3 du CD-ROM 4. Une même
série peut être projetée plusieurs fois à des séances diérentes. Lorsqu'un élève assiste à une séance,
il obtient le nombre de fautes (une note sur 40) qu'il a fait pour la série passée pendant la séance.

2
Lorsqu'un élève a obtenu, au cours des quatre dernières séances auxquelles il a assistées, un nombre
de fautes inférieur ou égal à 5, le directeur de l'auto-école l'autorise à passer l'examen théorique du
code de la route à une date donnée (un seul examen pour une date donnée). L'auto-école ne peut
présenter que 8 élèves maximum à chaque date d'examen. Les élèves ayant obtenu plus de 5 fautes
à l'examen sont recalés et doivent assister de nouveau à des séances de code avant de pouvoir se
représenter à l'examen.
La base de données doit permettre de répondre à des requêtes telles que "Quel est le nombre moyen
de fautes pour la série 5 du CD-ROM 14?", "Quels élèves peuvent se présenter au prochain examen
du code de la route ?", "Quels élèves ont échoué au moins une fois à l'examen ?" etc.

La gure 1 présente la modélisation Entité/Association (format Merise) et la modélisation UML

de l'énoncé. Les explications ne sont données que pour le schéma E/A mais peuvent être adaptées
au schéma UML. Pour une compréhension de la diérence entre une modélisation E/A ou UML et
le passage au relationnel, vous pouvez vous reporter à l'ouvrage [4]. Les schémas de modélisation
ci-avant sont sémantiquement clairs. Néanmoins, quels points nécessitent d'être précisés.

• L'ensemble d'entités est un ensemble d'entités faibles de , au format Merise

(ou une association qualiée en UML). En eet, ce choix de modélisation a été fait pour
représenter le fait que le numéro d'une série est relatif au CD-ROM auquel la série appartient.

• Les cardinalités de l'association entre les ensembles d'entités et sont - ,

car une série appartient à un unique CD-ROM et un CR-ROM contient exactement 6 séries
de questions. Le principe est le même pour les cardinalités de l'association entre et
: une série contient exactement 40 questions (cardinalité 40 : 40). En revanche,
une même question peut apparaître dans plusieurs séries avec un numéro d'ordre diérent à
chaque fois, d'où la cardinalité 1 : N et l'attribut qui caractérise l'assocation .

• L'attribut est un attribut de l'association entre les ensembles d'entités

et et de l'association entre les ensembles d'entités et . En
eet, cet attribut caractérise l'association et non pas un client, une séance de code ou encore
un examen de code. Il caractérise le lien entre deux entités de ces ensembles.

Déduisez le schéma relationnel de la base de données correspondante.

Vous préciserez les clés primaires des relations en les soulignant ainsi que les clés étrangères en
les signalant par un # et en précisant à quoi elles font référence.
Dans votre schéma relationnel, chaque relation doit être spéciée de la manière 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'entités
(classes) ou des associations du schéma de modélisation de la question 1.

Correction de l'exercice 1
Le modèle relationnel déduit de la modélisation ci-dessus est le suivant. Les clés primaires sont
soulignées. Les clés étrangères sont précédées d'un '#'. Pour un rappel de ces notions, vous
pouvez vous référer aux pages 56 à 60 de [2]. Le passage d'un schéma de modélisation à un modèle
relationnel est rappelé aux pages 120 à 143 de [4].

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe) .

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe)
.

3
 Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe)
.

Cette relation est issue du passage au relationnel de l'ensemble d'entités (classes) .

En modélisation E/A, l'ensemble d'entités étant un ensemble d'entités faibles de
, la clé primaire de la relation est composée de l'identicateur de la série et de
l'identicateur du CD-ROM auquel la série appartient.

Cette relation est déduite du passage au relationnel de l'association . Le cou-

ple d'attributs fait référence à la clé primaire de la relation .
L'attribut fait référence à la clé primaire de la relation . Il ne faut
pas oublier l'attribut qui caractérise l'association .

Cette relation est issue du passage au relationnel de l'ensemble d'entités (classes) .

Le couple d'attributs est une clé étrangère qui fait référence à la clé primaire
de la relation . Ce couple d'attributs a été ajouté lors du passage au relationel de
l'association , une seule série (d'un CR-ROM donné) étant diusée pen-
dant une séance de code (cardinalité ).

Cette relation est issue du passage au relationnel de l'association . Les attributs

et sont des clés étrangères qui font respectivement références aux clés
primaires des relations et . En eet, un client peut assister à plusieurs séances
et, lors d'une séance, il y a plusieurs clients. Il ne faut pas oublier l'attribut
qui caractérise l'association .

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe)
.

Cette relation est déduite du passage au relationnel de l'association .

Les attributs et font référence aux clés primaires des relations
et .

Exercice 2
Enoncé de l'exercice
On souhaite construire une base de données gérant des revues et les articles de ces revues. Une
revue est caractérisée par un nom et une périodicité. Chaque revue parait sous la forme de numéros,
chaque numéro étant identié par un nombre relatif à la revue et à l'année en cours (ex. le numéro
N◦ 12 de en 2003 est diérent du numéro N◦ 12 de en 2004). Un
numéro est également caractérisé par un nombre de pages. Chaque numéro contient des articles
écrits par un ou plusieurs auteurs. Un auteur est caractérisé par un nom, un prénom, ainsi qu'un
email. Chaque article possède un titre et un contenu. Un même article peut apparaître dans
plusieurs plusieurs numéros d'une même revue ou de diérentes revues. Lorsqu'un article apparaît
dans un numéro d'une revue, il a une page de début et une page de n. Un article peut faire
référence à d'autres articles, en précisant le numéro et la revue dans lesquels l'article référencé a
été publié.

4
 Revue
Auteur Revue
Nom Auteur
ID
Périodicité Nom
Nom ID
1:N Périodicité
Prénom Nom
NuméroID
Email Prénom
1 Email
1:N
1..*

comporte
comporte
écrit

écrit
1:1
1:M 0:M
Numéro 1..*
est publié Article 1..*
dans Numéro Article
1:N 1:M
ID Titre
PageDébut ID 1..* est publié dans 1..*
Année Contenu 0:N fait référence Titre
PageFin
NbPages à Année Contenu
NbPages
*

référence à
Modélisation Entité / Association Publication
*
PageDébut
fait
PageFin

Modélisation UML

Figure 2: Modélisation E/A et UML d'une base de données gérant des revues.

La base de données doit permettre de répondre à des requêtes telles que "Combien de numéros
de sont parus en 2004 ?", "Quels sont les titres des articles parus dans au moins
deux revues diérentes ?", "Quels sont les auteurs ayant publiés dans le numéro 3 de la revue
en 2004 ?" etc.

La gure 2 présente la modélisation Entité/Association (format Merise) et la modélisation UML

de l'énoncé. Les explications ne sont données que pour le schéma E/A mais peuvent être adaptées
au schéma UML. Pour une compréhension de la diérence entre une modélisation E/A ou UML et
le passage au relationnel, vous pouvez vous reporter à l'ouvrage [4]. Les schémas de modélisation
ci-avant sont sémantiquement clairs. Néanmoins, quels points nécessitent d'être précisés.

• L'ensemble d'entités est un ensemble d'entités faibles de au format Merise

(ou une association qualiée en UML). En eet, ce choix de modélisation a été fait pour
représenter le fait que l'identicateur d'un numéro est relatif à la revue à laquelle le numéro
appartient. Un numéro d'une revue donnée étant identié par un nombre et une année, ces
deux attributs ( et ) sont soulignés.

• Les cardinalités de l'association entre les ensembles d'entités et sont - ,

car un article peut apparaître dans plusieurs numéros et un numéro contient plusieurs articles.
Le principe est le même pour les cardinalités de l'association entre et .

• Les attributs et caractérisent l'association entre et (un

numéro étant relatif à une revue, il est inutile de faire une association avec ). En eet,
la page de début et la page de n peuvent varier, pour un même article, lorsqu'il paraît dans
plusieurs numéros diérents.

• Un article peut faire référence à un autre article. Le numéro et la revue dans lesquels l'article
référencé apparaît doivent être précisés dans l'article référençant. Par exemple, l'article in-
titulé "Correction d'exercices en bases de données" peut faire référence à l'article "Concepts
généraux en BD relationnelle" du numéro 12 de l'année 2004 de la revue "Informatique mag-
azine". A cet eet, les ensembles d'entités et ont été regroupés au sein d'un
agrégat au format Merise (ou d'une classe-association en UML). Cet agrégat (ou cette classe-
association) représente l'article référencé, c'est-à-dire l'article et le numéro de la revue où il
a été publié (il est inutile d'ajouter la revue à l'agrégat puisque est un ensemble
d'entités faibles de ). Cet agrégrat (ou cette classe-association) est associée à ,

5
 c'est-à-dire à l'article référençant, dont on ne précise pas le numéro et la revue. Les cardi-
nalités ont pour borne inférieure 0 car un article peut ne référencer aucun autre article et un
article peut ne jamais être référencé. Pour plus de détails sur l'agrégation, vous pouvez vous
référer à la page 37 de l'ouvrage [2] ou aux pages 55-56 de [3].

Déduisez le schéma relationnel de la base de données correspondante.

Vous préciserez les clés primaires des relations en les soulignant ainsi que les clés étrangères en les
signalant par un # et en précisant à quoi elles font référence.
Dans votre schéma relationnel, chaque relation doit être spéciée de la manière 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'entités
(classes) ou des associations du schéma de modélisation de la question 1.

Correction de l'exercice 2
Le modèle relationnel déduit de la modélisation ci-dessus est le suivant. Les clés primaires sont
soulignées. Les clés étrangères sont précédées d'un '#'. Pour un rappel de ces notions, vous
pouvez vous référer aux pages 56 à 60 de [2]. Le passage d'un schéma de modélisation à un modèle
relationnel est rappelé aux pages 120 à 143 de [4].

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe) .

Cette relation est issue du passage au relationnel de l'ensemble d'entités (classes) , qui
est un ensemble d'entités faibles (ou une association qualiée) de . La clé primaire de la
relation est donc composée du couple ( ) qui identie un numéro pour une
revue donnée et de l'attribut , clé étrangère faisant référence à la clé primaire de
la relation (c'est-à-dire faisant référence à la revue à laquelle le numéro est relatif).

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe) .

Cette relation est déduite du passage au relationnel de l'ensemble d'entités (ou classe) .

Cette relation est déduite du passage au relationnel de l'association entre et .

En eet, un article peut être écrit par plusieurs auteurs et un auteur peut écrire plusieurs
articles. L'attribut est une clé étrangère qui fait référence à la clé primaire de la
relation . L'attribut est une clé étrangère qui fait référence à la clé primaire
de la relation .

Cette relation est déduite du passage au relationnel de l'association entre et .

La clé primaire de la relation est composée du titre de l'article publié (identié par )
et du numéro dans lequel l'article apparaît (identié par le triplet
). L'attribut est une clé étrangère qui fait référence à la clé primaire
de la relation . Les attributs ( ) forment une
clé étrangère qui fait référence à la clé primaire de la relation . Il faut bien noter,
ici, qu'une clé étrangère fait toujours référence à la clé primaire d'une autre relation. Or,
dans cet exemple, la clé primaire de la relation est composée de trois attributs qui
doivent également apparaître dans toutes clés étrangères y faisant référence. Il ne faut pas

6
non plus oublier d'ajouter dans la relation les attributs et qui
caractérise l'association .

Cette relation est déduite du passage au relationnel de l'association entre l'ensemble d'entités
(ou la classe) et l'agrégat (ou la classe-association) regroupant et . Les
noms des attributs sont particulièrement longs pour que la sémantique soit claire. L'attribut
est une clé étrangère qui fait référence à la clé primaire de la rela-
tion . Cet attribut représente le titre de l'article référençant (contenant une référence
à un article publié dans un numéro). L'attribut est une clé étrangère
qui fait référence à la clé primaire de la relation . Cet attribut représente le titre de
l'article référençé. Les attributs (
) forment une clé étrangère qui fait référence à la clé primaire
de la relation . Ils représentent le numéro de la revue dans lequel a été publié l'article
référencé.

7
Langage d'interrogation

Exercice 3
Enoncé de l'exercice
On suppose qu'une bibliothèque gère une base de données dont le schéma est le suivant (les clés
primaires des relations sont soulignées) :

Exprimer, lorsque cela est possible, les requêtes suivantes en algèbre 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 (empruntés au moins une fois) ?

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

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

Correction de l'exercice 3
Dans cet exercice, le schéma relationnel est particulièrement simple, an que l'expression des re-
quêtes soit facile à exprimer. Il s'agit néanmoins de requêtes complexes. Vous pouvez vous entraîner
à exprimer ces requêtes en améliorant le schéma, c'est-à-dire en ajoutant deux relations
et et précisant les clés étrangères dans les relations et faisant référence à une
personne et à un livre.

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

En algèbre relationnelle : ΠP ersonne (σLivre=0 Recueil...0 (Emprunt))

L'algèbre relationnelle est un langage composé d'opérations ensemblistes. Il permet d'indiquer

comment le résultat de la requête est calculé en termes d'opérations ensemblistes sur des en-
sembles de nuplets (les relations). Dans cette requête par exemple, le résultat est calculé
en parcourant tous les nuplets de la relation , en y sélectionnant les nuplets dont
l'attribut a pour valeur et en prenant uniquement les valeurs de l'attribut
(i.e. en projetant sur l'attribut ).

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

Le calcul relationnel décrit, sous forme logique, le résultat de la requête (sans préciser com-
ment on le calcule). Le résultat de la requête 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 algèbre relationnelle : ΠP ersonne (Emprunt) − ΠP ersonne (Retard)

La résultat de la requête est calculé en prenant toutes les valeurs de l'attribut

dans la relation et en éliminant les valeurs de ce même attribut apparaissant égale-
ment dans la relation . Il s'agit d'une diérence entre deux ensembles.

En calcul relationnel :

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

Le résultat de la requête 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 même valeur pour l'attribut P ersonne (donc telles qu'il n'existe
pas de retards associés à ces personnes).

En SQL, deux manières possibles, par simple traduction en SQL de la requête 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 nécessaire que lorsqu'il y a ambiguïté au niveau des
noms d'attributs (cf. requête de gauche).

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

En algèbre relationnelle : ΠP ersonne,Livre (Emprunt) ÷ ΠLivre (Emprunt)

Le résultat de cette requête est calculé en utilisant l'opérateur de division. Pour une bonne
compréhension de la division, vous pouvez vous reporter à la page 99 de [2].
La sous-requête ΠLivre (Emprunt) correspond à la liste des livres empruntés. Le résultat de la
sous-requête ΠP ersonne,Livre (Emprunt) contient tous les couples
). Le résultat de la division sera donc la liste des person-
nes associées, dans le résultat de ΠP ersonne,Livre (Emprunt), à chacun des livres apparaissant
dans le résultat de la requête Π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 résultat de la requête 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 manière 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 résultat de la requête 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 manière négative :

{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 requête 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é empruntés par tout le monde (i.e. tous les em-
prunteurs) ?

En algèbre relationnelle : ΠP ersonne,Livre (Emprunt) ÷ ΠP ersonne (Emprunt)

Le résultat de cette requête est calculé en utilisant également l'opérateur de division.

La sous-requête ΠP ersonne (Emprunt) correspond à la liste des emprunteurs. Le résultat de la
sous-requête ΠP ersonne,Livre (Emprunt) contient tous les couples
). Le résultat de la
division sera donc la liste des livres associés, dans le résultat de ΠP ersonne,Livre (Emprunt), à
chacun des emprunteurs apparaissant dans le résultat de la requête Π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 résultat de la requête 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 manière 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 résultat de la requête 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 manière négative :
{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 requête 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
empruntés ?

En algèbre relationnelle : Il n'est pas possible d'exprimer cette requête par une division.
La requête est donc décomposée en deux sous-requêtes. La requête, 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 requête ci-dessous enlève de la liste des personnes qui empruntent des livres (sous-requête
de gauche) la liste des personnes ayant rendu au moins un livre sans retard (requête R1 ). Cela
correspond à comment calculer le résultat de la requête 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 résultat de la requête 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 résultat de la requête 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 manière négative :

{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 requête 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 gère
une base de données dont le schéma relationnel est le suivant :

Les attributs soulignés sont les attributs appartenant à la clé primaire. Ils sont de type entier.
L'attribut de la relation est une clé étrangère qui fait référence à l'attribut de
même nom de la relation . L'attribut de la relation est une clé étrangère
qui fait référence à l'attribut de même nom de la relation . L'attribut de la
relation est une clé étrangère qui fait référence à l'attribut de même nom de la relation
. L'attribut de la relation est une clé étrangère qui fait référence à l'attribut
de même nom de la relation .

Exprimez, lorsque cela est possible, les requêtes suivantes en algèbre 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 réalisé de concert à la Cygale ?

4. Quels sont les chanteurs ayant réalisé 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 algèbre relationnelle : ΠDate [Concert o

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

12
 Cette requête comporte deux jointures naturelles. La première jointure, entre les relations
et , associe les nuplets de , correspondant aux spectacles du chanteur
`Corneille' (puisqu'il y a une sélection avant), avec les nuplets de la relation ayant la
même valeur pour l'attribut . La jointure se fait naturellement sur l'attribut de
même nom, . La deuxième jointure associe les nuplets résultats de la première
jointure (donc les concerts des spectacles de 'Corneille') avec le nuplets correspondant à la
salle du 'Zenith' (résultat de la requête de sélection σN om=0 Zenith0 (Salle)). La jointure se fait
naturellement sur l'attribut commun . La projection nale se fait sur l'attribut .

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 requête retourne les dates des concerts pour lesquels il existe un spectacle de 'Corneille'
associé à la salle du 'Zenith'. Le résultat de la requête contient donc les valeurs de l'attribut
Date des nuplets t de la relation Concert tels qu'il existe un nuplet u dans , cor-
respondant à un spectacle de 'Corneille' (c'est-à-dire dont l'attribut a pour valeur
'Corneille'), avec la même valeur pour l'attribut que le nuplet t et tels qu'il
existe aussi un nuplet v dans la relation , correspondant à la salle du 'Zenith' (dont
l'attribut a pour valeur 'Zenith'), avec la même valeur pour l'attribut que celle
de l'attribut du nuplet u.

En SQL, par traduction immédiate de la requête 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 algèbre relationnelle : Cette requête ne peut pas s'écrire en algèbre relationnelle non éten-
due. Il faut un opérateur maximum. Pour plus de détails sur l'algèbre relationnelle étendue,
vous pouvez vous reporter aux pages 103 à 111 de [3] ou aux pages 221 à 230 de [1].

En algèbre relationnelle étendue1 , la requête s'exprime par:

ΠN om (σ(Capacite>=CapaciteM ax) ΠSalle_ID,CapacitM ax [Salle×(ΠM AX(Capacite)−→CapaciteM ax) (Salle))])

La requête ΠSalle_ID,CapacitM ax [Salle×(ΠM AX(Capacite)−→CapaciteM ax) (Salle))] retourne une

relation temporaire de deux colonnes, la pemière contenant les valeurs de l'attribut
de la relation et la deuxième colonne contenant une seule valeur (repétée pour toutes
les valeurs de ) correspondant à la valeur maximale de l'attribut (calculée
par la fonction d'agrégation et renommée en ). L'opérateur utilisé est le
produit cartésien (×). Pour obtenir le nom des salles avec la plus grande capacité, il sut
donc de joindre à cette relation temporaire à la relation et de sélectionner les nuplets
ayant une valeur de superieure ou égale à celle de l'attribut .

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

Cette requête retourne les valeurs de l'attribut des nuplets t de la relation pour
1 L'algèbre relationnelle étendue n'est pas au programme de l'examen.

13
 lesquels il n'existe pas de nuplets u dans avec une valeur de l'attribut supérieure
ou égale.

En SQL:

Il est possible de traduire directement la requête exprimée 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'opérateur d'agrégation M AX , comme pour la requête

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 réalisé de concert à la Cygale ?

En algèbre relationnelle : ΠChanteur (Spectacle)−ΠChanteur [Spectacle o

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

La requête Π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 résultat de la requête 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 requête retourne les valeurs de l'attribut des nuplets t de la relation

tels qu'il ne soit pas possible de trouver un spectacle de ce même chanteur à la 'Cygale'
(i.e. de trouver un nuplet u dans avec la même valeur pour l'attribut et
un nuplet v dans avec 'Cygale' comme valeur de l'attribut et avec la même valeur
que u.Salle_ID pour l'attribut ).

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 requête 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 réalisé au moins un concert dans toutes les salles
?

En algèbre relationnelle : ΠChanteur,Salle_ID (Spectacle o

n Salle) ÷ ΠSalle_ID (Salle)

La requête ΠSalle_ID (Salle) retourne tous les identicateurs de salle.

La requête ΠChanteur,Salle_ID (Spectacle o n Salle) retourne une relation associant à chaque
chanteur l'identicateur de la salle dans laquelle il a réalisé au moins un spectacle.
La division va donc retourner les chanteurs associés 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 requête retourne les valeurs de l'attribut des nuplets t de la relation

tels que pour quel que soit un nuplet, s'il s'agit d'une salle (donc un nuplet u pris dans
), alors il existe un spectacle de ce chanteur dans cette salle (donc il existe un nuplet v
dans 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 requête retourne les valeurs de l'attribut des nuplets t de la relation

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 ), soit (implicitement il s'agit d'un nuplet u de et) il existe un spectacle
de ce chanteur dans cette salle (donc il existe un nuplet v dans correspondant à ce
chanteur, avec v.Chanteur = t.Chanteur, et à cette salle, avec u.Salle_ID = v.Salle_ID).

D'où dit de manière négative :

{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 algèbre relationnelle : Cette requête étant complexe et ne peut pas s'exprimer à l'aide
d'une division. Il est plus simple de l'écrire en la décomposant. Une première sous-requête
R1 va permettre de déterminer les billets invendus :

R1 = ΠBillet_ID (Billet) − ΠBillet_ID (V ente)

La requête 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 (pour obtenir la valeur de l'attribut
associé au billet) puis avec (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 associée au résultat
de la requête 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 requête retourne les valeurs des attributs et des nuplets t de la rela-

tion tels que pour tous les billets de ce concert (donc pour tous les nuplets u dans
tels que u.Concert_ID = t.Concert_ID), il existe une vente de ce billet (donc il existe
un nuplet v dans correspondant à ce billet, i.e. tel que v.Billet_ID = u.Billet_ID).

D'où dit de manière négative :

{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
Dépendances fonctionnelles et
normalisation

Exercice 5
Enoncé de l'exercice
Soit un schéma de bases de données contenant les relation suivantes :

avec
FBureau = { N umBureau → N umT elephone, T aille; N umT elephone → N umBureau; }
avec FOccupant = { N umBureau → P ersonneID }
avec FM ateriel = { N umP C → N umBureau }

1. Les contraintes ci-dessous sont-elles vériées par ce schéma de bases de données? Si la réponse
est positive, expliquez pourquoi. Si la réponse est négative, indiquez quelle(s) dépendance(s)
fonctionnelle(s) il faut ajouter/supprimer ou modier pour que la contrainte soit vériée.

(a) "Un bureau peut contenir plusieurs postes téléphoniques."

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

2. A partir des familles de dépendances fonctionnelles initiales données dans l'énoncé, indiquez
quelles sont les clés minimales possibles de chaque relation.

Correction de l'exercice 5
1. Vérication des contraintes exprimées par des dépendances fonctionnelles :

(a)
Cette contrainte n'est pas vériée car FBureau contient la dépendance fonctionnelle
N umBureau → N umT elephone donc à un bureau est associé un et un seul numéro de
téléphone. Pour que la contrainte soit vériée, il faudrait supprimer cette dépendances
fonctionnelle.
(b)
Cette contrainte est vériée car FOccupant contient la dépendance fonctionnelle N umBureau →
P ersonneID, donc à un numéro de bureau est associée une et une seule personne.
(c)
Cette contrainte n'est pas vériée 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 vériée, il faudrait ajouter la dépendance fonctionnelle N umBureau → N umP C .

17
 2. Détermination des clés minimales des relations :

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

La relation Bureau a donc deux clés minimales possibles : N umBureau et N umT elephone.

En eet, à partir de l'attribut N umBureau il est possible de déduire les deux autres attributs
de la relation (par la première dépendance fonctionnelle). Par l'attribut N umT elephone, il est
possible de déduire N umBureau (2ème dépendance fonctionnelle) et donc l'attribut T aille
(par la première dépendance 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 détails sur les dépendances fonctionnelles, vous pouvez vous reporter aux pages
422 à 430 de [2].

Exercice 6
Enoncé de l'exercice
Soit R une relation dont le schéma est le suivant :
.

1. Exprimer, à l'aide de dépendances fonctionnelles, les contraintes suivantes que doivent vérier
les instances de la relation R :

(a) "On peut déduire le nom et le prénom d'un utilisateur à partir de son identicateur."

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

(c) "Une adresse email est associée à un et un seul identicateur d'utilisateur."

Attention : un utilisateur peut avoir plusieurs adresses de mails.

(d) "Une adresse email est associée à un et un seul serveur de mails."

2. Indiquer, à partir de la famille de dépendances fonctionnelles, issue de la question 1, quelles

sont les clés mimimales de R.

3. Indiquer, à partir de la famille de dépendances 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 dépendances fonctionnelles :

(a)
Cette contrainte s'exprime par la dépendance fonctionnelle :
−→
En eet, à un identicateur d'utilisateur est associé un et un seul nom et un et un seul
prénom.

(b)

Cette contrainte s'exprime par la dépendance fonctionnelle :

−→
En eet pour un couple ( ) est associé un et
un seul login et un et un seul mot de passe.

(c)

Cette contrainte s'exprime par la dépendance fonctionnelle :

−→
En eet, à une adresse mail est associée un et un seul identicateur d'utilisateur.

(d)
Cette contrainte s'exprime par la dépendance fonctionnelle :
−→
En eet, à une adresse mail est associée un et un seul serveur de mails.

2. Identication des clés minimales de la relation R

La famille de dépendances fonctionnelles associées à R est :

F ={ −→ −→ ;
−→ −→ }

L'attribut ne peut être déduit d'aucun autre attribut, il doit donc appartenir
à tous les clés minimales possibles de la relation. A partir de l'attribut on
peut déduire l'identicateur de l'Utilisateur est donc, par transitivité, le nom et le prénom
de l'utilisateur : −→ −→ . A partir de ce même
attribut, on peut en déduire aussi le nom du serveur de mail et donc avec l'identicateur
d'utilisateur, le login et le mot de passe de l'utilisateur :
−→ −→
D'où : [AdresseEmail]+ = {
}=R

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

3. Déduction de la forme normale du schéma de la relation R

Les deux dernières dépendances fonctionnelles sont de la forme −→ ,

et vérient donc les propriétés de la forme normale BCNF. En revanche, les deux premières
dépendances fonctionnelles sont transitives puisqu'elles ne sont composées que d'attributs
n'appartenant pas à une clé. Par conséquent, le schéma de la relation R est en deuxième
forme normale.

19
Pour plus de détails sur les formes normales, vous pouvez vous référer 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, ,

Prentice Hall, 2002

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

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

[3] A. Silberschatz, H.F. Korth et S. Sudarshan, , 4th Edition,

McGraw-Hill, 2002, ISBN: 0-07-228363-7

[4] C. Soutou, , Eyrolles, 2002, ISBN: 2-212-

11098-7

21