CBD SQL 1827hdbnn

Cours de bases de donnes - Modles
et langages
Version 1.0
Philippe Rigaux
16 November 2015
Table des matires
1 Introduction 3
2 Conception dune base de donnes 5

2.1 Schma dune base de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Le modle E/A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Le modle relationnel 25
3.1 Dfinition dun schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Passage dun schma E/A un schma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Dfinition dun schma SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Lalgbre relationnelle 41
4.1 Les oprateurs de lalgbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Expression de requtes avec lalgbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 SQL 51
5.1 Principes de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Recherche avec SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Jointures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Agrgats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Mises jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.6 Les vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Indices and tables 77
i
ii
Cours de bases de donnes - Modles et langages, Version 1.0
Contents : Le document que vous commencez lire fait partie de lensemble des supports dapprentissage proposs
sur le site http ://www.bdpedia.fr. Il fait partie du cours consacr aux bases de donnes relationnelles, divis en deux
parties :
La version en ligne du support Modles et langages est accessible http ://sql.bdpedia.fr, la version imprimable
(PDF) est disponible http ://sql.bdpedia.fr/files/cbd-sql.pdf.
La version en ligne du support Aspects systme est accessible http ://sys.bdpedia.fr, la version imprimable (PDF)
est disponible http ://sys.bdpedia.fr/files/cbd-sys.pdf.
Deux autres cours, aux contenus proches, sont galement disponibles :
Un cours sur les bases de donnes documentaires et distribues http ://b3d.bdpedia.fr.
Un cours sur les applications avec bases de donnes http ://orm.bdpedia.fr
Reportez-vous http ://www.bdpedia.fr pour plus dexplications.
Important : Ce cours de Philippe Rigaux est mis disposition selon les termes de la licence Creative Com-
mons Attribution - Pas dUtilisation Commerciale - Partage dans les Mmes Conditions 4.0 International. Cf.
http ://creativecommons.org/licenses/by-nc-sa/4.0/.
Table des matires 1

2 Table des matires

CHAPITRE 1
Introduction
Ce support de cours sadresse aux tudiants en premier cyle (IUT) ou second cycle universitaire (Licence, Master) et
formations apparentes. Il propose un ensemble de chapitres consacrs aux principes et la mise en uvre de bases de
donnes relationnelles, ainsi qu la pratique des Systmes de Gestion de Bases de Donnes (SGBD). Il couvre plus
particulirement les modles et langages des bases de donnes. Cette partie couvre tout dabord la conception et la
dfinition dun schma relationnel correct et complet, comprenant des tables, des contraintes, des vues, etc. Elle dcrit
ensuite lalgbre relationnelle et SQL, ainsi que lintgration de SQL avec un langage de programmation comme le C.
Une seconde partie, consacre aux aspects systmes prsente les techniques internes utilises par les SGBD relation-
nels pour stocker efficacement les donnes et valuer des requtes. Elle couvre la reprsentation physique, lindexation,
loptimisation et comprend galement une introduction aux problmes de concurrence daccs, dont la connaissance
est ncessaire aux dveloppeurs dapplications bases sur des SGBD. Cette seconde partie est disponible sparment
sur le site le site http ://sys.bdpedia.fr.
La premire partie est accessible aux tudiants suivant un cours dintroduction aux bases de donnes et ne demande
que peu de pr-requis. La second partie est plus avance et ncessite de bonnes bases en structures de donnes et
algorithmique.
Le premier chapitre est une (rapide) prsentation de tous les thmes prsents en dtails dans ce cours. On peut le lire
comme une mise en perspective gnrale de lensemble du document.
3
4 Chapitre 1. Introduction
CHAPITRE 2
Conception dune base de donnes
Ce chapitre est consacr la dmarche de conception dune base relationnelle. Elle se droule en gnral selon un
processus de conception comportant plusieurs tapes. Nous nous concentrons dans ce chapitre sur la modlisation,
et sur la reprsentation de cette modlisation avec une notation trs rpandue, dite entit / association. Au pralable,
nous allons discuter de lobjectif final, qui est dobtenir un schma de la base de donnes conforme au besoin et ne
prsentant par danomalie.
2.1 Schma dune base de donnes
Le schma dune base relationnelle est constitu dun ensemble de schmas de tables. Le schma dune table son
tour consiste pour lessentiel en un nom (de table) et un ensemble de noms dattributs.
La conception dun schma relationnel ne prsente pas de difficult technique. On constate en pratique quelle de-
mande une certaine exprience, notamment parce que les conseils dusage, assez abstraits, deviennent beaucoup plus
clairs quand on sest tromp une ou deux fois et quon a constat les consquences de ses erreurs. Le schma de
donnes constitue en effet les fondations dune application Le schma nest jamais fig : il voluera avec lapplica-
tion. Mais la partie existante dun schma est toujours difficile remettre en cause sans entraner une rcriture non
ngligeable.
Dans ce qui suit, nous illustrons, partir dexemples, les obstacles viter dans la conception dun schma, lobjectif
atteindre et les mthodes disponibles.
2.1.1 Qualit dun schma relationnel
Voici un exemple de schma, avec une notation trs simplifie, que nous allons utiliser pour discuter de la notion
centrale de bon et mauvais schma. On veut crer une base de donnes reprsentant des films, avec des informa-
tions comme le titre, lanne, le metteur en scne, etc. On part dun schma rassemblant ces informations (MES est
lacronyme de Metteur en Scne) :
Film(titre, annee, prenomMes, nomMES, anneeNaiss)
Un tel schma permet de reprsenter les donnes de manire complte, en en vitant autant que possible les anomalies ?
Regardons un exemple de contenu de la table dcrite par ce schma.
5
titre anne nomMES prnomMES anneNais

Alien 1979 Scott Ridley 1943
Vertigo 1958 Hitchcock Alfred 1899
Psychose 1960 Hitchcock Alfred 1899
Kagemusha 1980 Kurosawa Akira 1910
Volte-face 1997 Woo John 1946
Pulp Fiction 1995 Tarantino Quentin 1963
Titanic 1997 Cameron James 1954
Sacrifice 1986 Tarkovski Andrei 1932
Mme pour une information aussi simple, il est facile dnumrer tout un ensemble de problmes potentiels. Tous ou
presque dcoulent dun grave dfaut de la table ci-dessus : il est possible de reprsenter la mme information plusieurs
fois, ou, pour employer un mot que nous retrouverons souvent, il y a redondance de linformation.
Anomalies lors dune insertion
Rien nempche de reprsenter plusieurs fois le mme film. Pire : il est possible dinsrer plusieurs fois le film Vertigo
en le dcrivant chaque fois de manire diffrente, par exemple en lui attribuant une fois comme ralisateur Alfred
Hitchcock, puis une autre fois John Woo, etc.
La bonne question consiste dailleurs se demander ce qui distingue deux films lun de lautre, et quel moment on
peut dire que la mme information a t rpte. Peut-il y avoir deux films diffrents avec le mme titre par exemple ?
Si la rponse est non ( ?), alors on devrait pouvoir assurer quil ny a pas deux lignes dans la table avec la mme valeur
pour lattribut titre. Si la rponse est oui (ce qui semble raisonnable), il reste dterminer quel est lensemble des
attributs qui permet de caractriser de manire unique un film ou, dfaut, de crer un tel identifiant artificiellement.
Cest une notion centrale sur laquelle nous revenons de manire approfondie.
Anomalies lors dune modification
La redondance dinformation entrane galement des anomalies de mise jour. Supposons que lon modifie lanne de
naissance de Hitchcock pour la ligne Vertigo et pas pour la ligne Psychose. On se retrouve alors avec des informations
incohrentes. Les mmes questions que prcdemment se posent dailleurs. Jusqu quel point peut-on dire quil ny
a quun seul ralisateur nomm Hitchcock, et quil ne doit donc y avoir quune seule anne de naissance pour un
ralisateur de ce nom ?
Anomalies lors dune destruction
On ne peut pas supprimer un film sans supprimer du mme coup son metteur en scne. Si on souhaite, par exemple,
ne plus voir le film Titanic figurer dans la base de donnes, on va effacer du mme coup les informations sur James
Cameron.
2.1.2 Schmas normaliss
Que dduire de ce qui prcde ? Tout dabord quil existe des schmas avec de bonnes proprits, et dautres qui
souffrent de dfauts de conception. Ensuite, que nous avons besoin daller plus loin quune simple numration dat-
tributs et noncer des contraintes et des rgles qui nous indiquent plus prcisment les liens qui caractrisent les
donnes.
Le modle relationnel nous propose un outil prcieux pour rpondre ces questions : la normalisation. Un schma
normalis prsente des caractristiques formelles quil est possible dvaluer. La normalisation nous garantit labsence
de dfaut (et notamment de redondance) tout en prservant lintgralit de linformation reprsente.
La thorie du modle relationnel a dvelopp une construction mathmatique solide pour qualifier les proprits dun
schma dune part, et dcomposer un schma dnormalis en schma normalis dautre part. Le second aspect sappuie
malheureusement sur une dmarche peu utilisable en pratique pour des raisons sur lesquelles nous reviendront plus
loin. Le premier en revanche donne un clairage trs prcis sur ce quest un bon schma relationnel. Il est intressant
de consacrer quelques instants (voire un peu plus si vous voulez vous donner tous les moyens dviter des ennuis
ultrieurs) la dfinition des schmas normaliss.
6 Chapitre 2. Conception dune base de donnes

2.1.3 La notion de dpendance fonctionnelle
Le principal concept est celui de dpendance fonctionnelle, qui fournit une construction de base pour laborer les
contraintes dont nous avons besoin pour caractriser nos donnes et leurs liens. Il snonce comme suit. Prenons un
schma de relation R, S un sous-ensemble dattributs de R, et A un attribut quelconque de R.
Dfinition : dpendance fonctionnelle

On dit que A dpend fonctionnellement de S (ce que lon note ) quand, pour toute paire (1 , 2 ) de lignes de R,
lgalit de 1 et de 2 sur S implique lgalit sur A.
Informellement, on peut raisonner ainsi : Si je connais S, alors je connais A. Par, exemple, si je prends lensemble
des attributs suivants :
(nom, prenom, noSS, dateNaissance, adresse, email)
je peux chercher les dpendances fonctionnelles et trouver celles-ci :

, , , ,
, , , ,
Jai donc reconnu que la connaisance dun email dtermine la connaissance des autres attributs, et de mme pour le
numro de scurit sociale. On peut avoir des dpendances fonctionnelles o la partie gauche comprend plusieurs
attributs. Par exemple, pour les attributs suivants :
noEtudiant, noCours, annee, note
on trouvera la dpendance fonctionnelle suivante :

, ,
La connaissance dun tudiant, dun cours et dune anne dtermine la note obtenue.
Les dpendances fonctionnelles fournissent un outil pour analyser la qualit dun schma relationnel. Prenons le cas
dun systme permettant dvaluer des manuscrits soumis un diteur. Voici deux schmas possibles pour reprsenter
les rapports dvaluation dun manuscrit (on va supposer quil existe un seul expert par manuscrit).
Schma 1
Manuscrit (id_manuscrit, titre, id_expert, nom, adresse, commentaire)}
Schma 2
Manuscrit (id_manuscrit, titre, id_expert, commentaire)
Expert (id_expert, nom, adresse)
Il est trs instructif de rflchir ces deux schmas, leurs diffrences et leurs avantages et inconvnients respectifs.
Si lon raisonne en termes de dpendance fonctionnelle (que nous noterons DF partir de maintenant), on constate que
dans le schma de la relation Expert(id_expert, adresse), il existe une dpendance fonctionnelle entre id_expert et
adresse. En dautre termes, si on trouve dans la base deux lignes avec lidentifiant dexpert 128, ladresse pour ces
deux lignes doit tre la mme. Une DF nonce donc une contrainte sur le contenu de la base de donnes : la prservation
des DFs garantit labsence dincohrence (le mme expert, mais deux adresses diffrentes et donc contradictoires).
La question suivante est bien sr : pourquoi devrait-on reprsenter plusieurs fois la mme information et simposer la
charge de vrifier la cohrence ? L encore, en nous appuyant sur les dpendances fonctionnelles, nous allons pouvoir
dfinir la notion essentielle de cl qui nous permettra dviter les redondances.
Dfinition : cl
Une cl (dune relation R) est un sous-ensemble minimal C des attributs tel que tout attribut de R dpend fonctionnel-
lement de C.
Lattribut id_expert est une cl de la relation Expert dans le schma 2. Dans le schma 1, lattribut
id_manuscrit est une cl de Manuscrit. Notez que tout attribut de la relation dpend aussi de la paire
2.1. Schma dune base de donnes 7

(id_manuscrit, id_expert), sans que cette paire soit une cl puisquelle nest pas minimale (il existe un
sous-ensemble strict qui est lui-mme cl).
Et maintenant nous pouvons dfinir ce quest un schma de relation normalis.
Dfinition : schma normalis

Un schma de relation R est normalis quand, dans toute dpendance fonctionnelle sur les attributs de R, S est
une cl.
Considrons nouveau notre schma 1 :

Manuscrit (id_manuscrit, id_expert, nom, commentaire, adresse_expert)
Il nest pas normalis car il existe une dpendance fonctionelle id_expert nom, adresse_expert, alors
que lattribut id_expert nest pas une cl. Il existe une version intuitive de cette constatation abstraite : la table
Manuscrit contient des informations qui ne sont pas directement lies la notion de manuscrit. La prsence din-
formations indirectes est une source de redondance et donc danomalies.
Lessentiel de ce quil faut comprendre est nonc (certes de manire trs condense) dans ce qui prcde. On veut
obtenir des relations normalises car il et facile de montrer que la dnormalisation entrane toutes sortes danomalies
au moment o la base est mise jour. De plus, si R est une relation de cl C, deux lignes de R ayant les mme
valeurs pour C auront par dfinition les mmes valeurs pour les autres attributs et seront donc parfaitement identiques.
Il est donc inutile (et nuisible) dautoriser cette situation : on fera en sorte que la valeur dune cl soit unique pour
lensemble des lignes dune relation. En rsum on veut des schmas de relation normaliss et dots dune cl unique
bien identifie. Cette combinaison interdit toute redondance.
Note : Les thoriciens qui ont tudi ces notions ont dfini plusieurs formes de normalisation. Celle prsente ici est
dite troisime forme normale (3FN).
2.1.4 La dcomposition dun schma
Etant donn un schma et ses dpendances fonctionnelles, nous savons dterminer sil est normalis. Peut-on aller
plus loin et produire automatiquement un schma normalis partir de lensemble des attributs et de leurs contraintes
(les DFs) ? En principe oui, en pratique pas vraiment.
Regardons dabord le principe avec un exemple illustrant la normalisation dun schma relationnel par un processus
de dcomposition progressif. On veut reprsenter lorganisation dun ensemble dimmeubles locatifs en appartements,
et dcrire les informations relatives aux propritaires des immeubles et aux occupants de chaque appartement. Voici
un premier schma de relation :
Appart(id_appart, surface, id_immeuble, nb_etages, date_construction)
La cl est id_appart. Cette relation est-elle normalise ? Non, car lidentifiant de limmeuble dtermine fonc-
tionnellement le nombre dtages et la date de construction. On a donc une dpendance _
_, _ dont la partie gauche nest pas la cl id_appart. En pratique, une telle relation
dupliquerait le nombre dtages et la date de construction autant de fois quil y a dappartements dans un immeuble.
Le bon schma en loccurrence serait la dcomposition en deux relations :
Appart(id_appart, surface, id_immeuble)
Immeuble (id_immeuble, nb_etages, date_construction)
Supposons quun immeuble puisse tre dtenu par plusieurs propritaires, et considrons la seconde relation suivante, :
Proprietaire(id_appart, id_personne, quote_part)

Est-elle normalise ? Oui car lunique dpendance fonctionnelle est
_, _ _
Un peu de rflexion suffit se convaincre que ni lappartement, ni le propritaire ne dterminent eux seuls la
quote-part. Seule lassociation des deux permet de donner un sens cette information, et la cl est donc le couple
(id_appart, id_personne). Maintenant considrons lajout du nom et du prnom du propritaire dans la
relation.
Proprietaire(id_appart, id_personne, prenom, nom, quote_part)
La dpendance fonctionnelle _ , indique que cette relation nest pas normalise. Le bon
schma est :
Personne(id_personne, prenom, nom)
Si, en revanche, on dcide quil ne peut y avoir quun propritaire pour un appartement et inversement, la quote-
part devient inutile, une nouvelle dpendance fonctionnelle _ _ apparat, et la relation avant
dcomposition est bien normalise, avec pour cl id_personne.
Voyons pour finir le cas des occupants dun appartement, avec la relation suivante.
Occupant(id_personne, nom, prenom, id_appart, surface)
On mlange clairement des informations sur les personnes, et dautres sur les appartements. Plus prcisment, la cl
est le couple (id_personne, id_appart), mais on a les dpendances suivantes :
_ ,
_
Un premier rflexe pourrait tre de dcomposer en deux relations Personne(id_personne, prnom, nom)
et Appart (id_appart, surface). Toutes deux sont normalises, mais on perd alors une information impor-
tante, et mme essentielle : le fait que telle personne occupe tel appartement. Il faut donc imprativement conserver
une relation correspondant la cl initiale :Occupant (id_personne, id_appart). Do le schma final :
Immeuble (id_immeuble, nb_etages, date_construction)
Personne (id_personne, prenom, nom)
Appart (id_appart, surface)
Occupant (id_personne, id_appart)
Ce schma, obtenu par dcompositions successives, prsente la double proprit

de ne pas avoir perdu dinformation par rapport la version initiale ;
de ne contenir que des relations normalises.
Important : Labsence de perte dinformation est une notion qui est survole ici mais qui est de fait essentielle. Une
dcomposition est sans perte dinformation sil est possible, par des oprations, de reconstruire la relation initiale,
avant dcomposition. Ces oprations, et notamment la jointure, seront prsents dans les chapitres suivants.
Cet exemple est une dmonstration dune approche quasiment algorithmique pour obtenir un schma normalis partir
dun ensemble dattributs initial. Cette approche est malheureusement inutilisable en pratique cause dune difficult
que nous avons cache : les dpendances fonctionnelles prsentes dans notre schma ont t artificiellement cres par
ajout didentifiants pour les immeubles, les occupants et les appartements. En pratique, de tels identifiants nexistent
pas si on na pas au pralable dtermin les entits prsentes dans le schma : Immeuble, Occupant, et Appartement.
En dautres termes, lexemple qui prcde sappuie sur une forme de tricherie : on a normalis un schma dans lequel
on avait guid lavance la dcomposition.
2.1. Schma dune base de donnes 9

2.1.5 Une approche pratique
Reprenons notre table des films pour nous confronter une situation raliste. Rappelons les quelques attributs consi-
drs.
(titre, annee, prenomMes, nomMES, anneeNaiss)
La triste ralit est quon ne trouve aucune dpendance fonctionnelle dans cet ensemble dattribut. Le titre dun film
ne dtermine rien puisquil y a videmment des films diffrents avec le mme titre, Eventuellement, la paire (titre,
anne) pourrait dterminer de manire univoque un film, mais un peu de rflexion suffit se convaincre quil est trs
possible de trouver deux films diffrents avec le mme titre la mme anne. Et ainsi de suite : le nom du ralisateur
ou mme la paire (prnom, nom) sont des candidats trs fragiles pour dfinir des dpendances fonctionnelles. En fait,
on constate quil est trs rare en pratique de trouver des DFs naturelles sur lesquelles on peut solidement sappuyer
pour dfinir un schma.
Il nous faut donc une dmarche diffrente consistant crer artificiellement des DFs parmi les ensembles dattributs. La
connaissance des identifiants dappartement, dimmeuble et de personne dans notre exemple prcdent correspondait
une telle cration artificielle : tous les attributs de, respectivement, Immeuble, Appartement et Personne dpendent
fonctionnellement, par construction, de leurs identifiants respectifs, ajouts au schma.
Comment trouve-t-on ces identifiants ? Par une dmarche essentiellement diffrente de celle partant de bas en haut,
consistant prendre un tas dattributs et les regrouper en relations. Au contraire, on part de groupes dattributs
appartenant une mme entit, laquelle on ajoute un attribut-identifiant. La dmarche consiste :
dterminer les entits (immeuble, personne, appartement, ou film et ralisateur) pertinents pour lapplication ;
dfinir une mthode didentification de chaque entit ; en pratique on recourt la dfinition dun identifiant artificiel
(il na aucun rle descriptif) qui permet dune part de sassurer quune mme entit est reprsente une seule fois,
dautre part de rfrencer une entit par son identifiant.
prserver le lien entre les entits sans introduire de redondance, par un mcanisme de rfrence bas sur la cl.
Voici une illustration informelle de la mthode, que nous reprendrons ensuite de manire plus dtaile avec la notation
Entit/association.
Commenons par les deux premires tapes. On va dabord distinguer la table des films et la table des ralisateurs.
Ensuite, on va ajouter chaque table un attribut spcial, lidentifiant, dsign par id.
Important : Le choix de lidentifiant est un sujet dlicat. On peut arguer en effet que lidentifiant devrait tre recherch
dans les attributs existant, au lieu den crer un artificiellement. Pour des raisons qui tiennent la raret/fragilit des
DFs naturelles, la cration de lidentifiant artificiel est la seule rellement applicable et satisfaisante dans tous les
cas.
On obtient le rsultat suivant.

id titre anne
1 Alien 1979
2 Vertigo 1958
3 Psychose 1960
4 Kagemusha 1980
5 Volte-face 1997
6 Pulp Fiction 1995
7 Titanic 1997
8 Sacrifice 1986
La table des films.

id titre anne
101 Scott Ridley 1943
102 Hitchcock Alfred 1899
103 Kurosawa Akira 1910
104 Woo John 1946
105 Tarantino Quentin 1963
106 Cameron James 1954
107 Tarkovski Andrei 1932
La table des ralisateurs
Premier progrs : il ny a maintenant plus de redondance dans la base de donnes. Le ralisateur Hitchcock, par
exemple, napparat plus quune seule fois, ce qui limine les anomalies de mise jour voques prcdemment.
Important : On peut noter que, par construction, les schmas obtenus sont normaliss.
Il reste reprsenter le lien entre les films et les metteurs en scne, sans introduire de redondance. Maintenant que
nous avons dfini les identifiants, il existe un moyen simple pour indiquer quel est le metteur en scne qui a ralis
un film : associer lidentifiant du metteur en scne au film. Lidentifiant sert alors de rfrence lentit. On ajoute un
attribut idRalisateur dans la table Film, et on obtient la reprsentation suivante.
id titre anne idRalisateur
1 Alien 1979 101
2 Vertigo 1958 102
3 Psychose 1960 102
4 Kagemusha 1980 103
5 Volte-face 1997 104
6 Pulp Fiction 1995 105
7 Titanic 1997 106
8 Sacrifice 1986 107
Cette reprsentation est correcte. La redondance est rduite au minimum puisque seule lidentifiant du metteur en
scne a t dplac dans une autre table. Pour peu quon sassure que cet identifiant ne change jamais, cette redondance
ninduit aucun effet ngatif. On peut vrifier que les anomalies que nous avons cites ont disparu.
Dune part, il ny a plus de redondance des attributs descriptifs, donc toute mise jour affecte lunique occurrence de la
donne modifier. Dautre part, on peut dtruire un film sans affecter les informations sur le ralisateur. Ce gain dans
la qualit du schma na pas pour contrepartie une perte dinformation. Il est en effet facile de voir que linformation
initiale (autrement dit, avant la dcomposition en deux tables) peut tre reconstitue intgralement. En prenant un
film, on obtient lidentifiant de son metteur en scne, et cette identifiant permet de trouver lunique ligne dans la
table des ralisateurs qui contient toutes les informations sur ce metteur en scne. Ce processus de reconstruction
de linformation, disperse dans plusieurs tables, peut sexprimer avec les oprations relationnelles, et notamment la
jointure.
Il reste appliquer une mthode systmatique visant aboutir au rsultat ci-dessus, et ce mme dans des cas beaucoup
plus complexes. Cela tant, aucune mthode ne produit automatiquement un rsultat correct, puisquelle repose sur un
processus danalyse et didentification des entits dont rien ne peut garantir la validit. On ne peut jamais se dispenser
de rflchir et de comprendre les donnes que lon veut modliser. Il faut, toujours, reprer les entits et leur attribuer
un identifiant, et grer correctement les rfrences (ou associations) entre ces entits. Entits, associations, sont les
concepts essentiels. Do le modle prsent dans ce qui suit.
2.2 Le modle E/A
Le modle Entit/Association (E/A) propose essentiellement une notation pour soutenir la dmarche de conception
de schma prsente prcdemment. La notation E/A a pour caractristiques dtre simple et suffisamment puissante
2.2. Le modle E/A 11

pour modliser des structures relationnelles. De plus, elle repose sur une reprsentation graphique qui facilite consi-
drablement sa comprhension.
Le modle E/A souffre galement de nombreuses insuffisances : la principale est de ne proposer que des structures. Il
nexiste pas dopration permettant de manipuler les donnes, et pas (ou peu) de moyen dexprimer des contraintes.
Un autre inconvnient du modle E/A est de mener certaines ambiguits pour des schmas complexes.
2.2.1 Le schma de la base Films
La prsentation qui suit est dlibrement axe sur lutilit du modle E/A dans le cadre de la conception dune base
de donnes. Ajoutons quil ne sagit pas directement de concevoir un schma E/A (voir un cours sur les systmes
dinformation), mais dtre capable de le comprendre et de linterprter. Nous reprenons lexemple dune base de
donnes dcrivant des films, avec leur metteur en scne et leurs acteurs, ainsi que les cinmas o passent ces films.
Nous supposerons galement que cette base de donnes est accessible sur le Web et que des internautes peuvent noter
les films quils ont vus.
La mthode permet de distinguer les entits qui constituent la base de donnes, et les associations entre ces entits. Un
schma E/A dcrit lapplication vise, cest--dire une abstraction dun domaine dtude, pertinente relativement aux
objectifs viss. Rappelons quune abstraction consiste choisir certains aspects de la ralit perue (et donc liminer
les autres). Cette slection se fait en fonction de certains besoins, qui doivent tre prcisment dfinis, et rlve dune
dmarche danalyse qui nest pas aborde ici.
F IGURE 2.1 Le schma E/A des films
Par exemple, pour notre base de donnes Films, on na pas besoin de stocker dans la base de donnes lintgralit des
informations relatives un internaute, ou un film. Seules comptent celles qui sont importantes pour lapplication.
Voici le schma dcrivant cete base de donnes Films (figure :ref :ea-films). Sans entrer dans les dtails pour linstant,
on distingue
des entits, reprsentes par des rectangles, ici Film, Artiste, Internaute et Pays ;
des associations entre entits reprsentes par des liens entre ces rectangles. Ici on a reprsent par exemple le fait
quun artiste joue dans des films, quun internaute note des films, etc.

Chaque entit est caractrise par un ensemble dattributs, parmi lesquels un ou plusieurs forment lidentifiant unique
(en gras). Il est essentiel de dire ce qui caractrise de manire unique une entit, de manire viter la redondance
dinformation. Comme nous lavons prconis prcdemment, un attribut non-descriptif a t ajout chaque entit,
indpendamment des attributs descriptifs. Nous lavons appel id pour Film et Artiste, code pour le pays. Le nom
de lattribut-identifiant est peu important, mme si la convention id est trs rpandue.
Seule exception : les internautes sont identifis par un de leurs attributs descriptifs, leur adresse de courrier lectro-
nique. Mme sil sagit en apparence dun choix raisonnable (unicit de lemail pour identifier une personne), ce cas
nous permettra dillustrer les problmes qui peuvent quand mme se poser.
Les associations sont caractrises par des cardinalits. La notation 0..* sur le lien Ralise, du ct de lentit Film,
signifie quun artiste peut raliser plusieurs films, ou aucun. La notation 0..1 du ct Artiste signifie en revanche quun
film ne peut tre ralis que par au plus un artiste. En revanche dans lassociation Donne une note, un internaute peut
noter plusieurs films, et un film peut tre not par plusieurs internautes, ce qui justifie la prsence de 0..* aux deux
extrmits de lassociation.
Le choix des cardinalits est essentiel. Ce choix est aussi parfois discutable, et constitue donc lun des aspects les plus
dlicats de la modlisation. Reprenons lexemple de lassociation Ralise. En indiquant quun film est ralis par un
seul metteur en scne, on sinterdit les pas si rares situations o un film est ralis par plusieurs personnes. Il ne
sera donc pas possible de reprsenter dans la base de donnes une telle situation. Tout est ici question de choix et
de compromis : est-on prt en loccurrence accepter une structure plus complexe (avec 0..* de chaque ct) pour
lassociation Ralise, pour prendre en compte un nombre minime de cas ?
Les cardinalits sont notes par deux chiffres. Le chiffre de droite est la cardinalit maximale, qui vaut en gnral
1 ou . Le chiffre de gauche est la cardinalit minimale. Par exemple la notation 0..1 entre *Artiste et Film indique
quon sautorise ne pas connatre le metteur en scne dun film. Attention : cela ne signifie pas que ce metteur en
scne nexiste pas. Une base de donnes, telle quelle est dcrite par un schma E/A, ne prtend pas donner une vision
exhaustive de la ralit. On ne doit surtout pas chercher tout reprsenter, mais sassurer de la prise en compte des
besoins de lapplication.
La notation 1..1 entre Film et Pays indique au contraire que lon doit toujours connatre le pays producteur dun film.
On devra donc interdire le stockage dans la base dun film sans son pays.
Les cardinalits minimales sont moins importantes que les cardinalits maximales, car elles ont un impact limit
sur la structure de la base de donnes et peuvent plus facilement tre remises en cause aprs coup. Il faut bien tre
conscient de plus quelles ne reprsentent quun choix de conception, souvent discutable. Dans la notation UML que
nous prsentons ici, il existe des notations abrges qui donnent des valeurs implicites aux cardinalits minimales :
La notation * est quivalente 0..* ;
la notation 1 est quivalente 1..1 .
Outre les proprits dj voques (simplicit, clart de lecture), videntes sur ce schma, on peut noter aussi que la
modlisation conceptuelle est totalement indpendante de tout choix dimplantation. Le schma de la figure Le schma
E/A des films (page 12) ne spcifie aucun systme en particulier. Il nest pas non plus question de type ou de structure
de donnes, dalgorithme, de langage, etc. En principe, il sagit donc de la partie la plus stable dune application. Le
fait de se dbarrasser ce stade de la plupart des considrations techniques permet de se concentrer sur lessentiel :
que veut-on stocker dans la base ?
Une des principales difficults dans le maniement des schmas E/A est que la qualit du rsultat ne peut svaluer que
par rapport une demande qui est difficilement formalisable. Il est donc souvent difficile de mesurer (en fonction de
quels critres et quelle mtrique ?) ladquation du rsultat au besoin. Peut-on affirmer par exemple que :
toutes les informations ncessaires sont reprsentes ?
quun film ne sera jamais ralis par plus dun artiste ?
Il faut faire des choix, en connaissance de cause, en sachant toutefois quil est toujours possible de faire voluer une
base de donnes, quand cette volution nimplique pas de restructuration trop importante. Pour reprendre les exemples
ci-dessus, il est facile dajouter des informations pour dcrire un film ou un internaute ; il serait beaucoup plus difficile
de modifier la base pour quun film passe de un, et un seul, ralisateur, plusieurs. Quant changer lidentifiant de
la table Internaute, cest une des volutions les plus complexes raliser. Les cardinalits et le choix des cls font
vraiment partie des des aspects dcisifs des choix de conception.

2.2.2 Entits, attributs et identifiants
Il est difficile de donner une dfinition trs prcise des entits. Les points essentiels sont rsums ci-dessous.
Dfinition : Entits
On dsigne par entit toute unit dinformation identifiable et pertinente pour lapplication.
La notion dunit dinformation correspond au fait quune entit ne peut pas se dcomposer sans perte de sens. Comme
nous lavons vu prcdemment, lidentit est primordiale. Cest elle qui permet de distinguer les entits les unes des
autres, et donc de dire quune information est redondante ou quelle ne lest pas. Il est indispensable de prvoir un
moyen technique pour pouvoir effectuer cette distinction entre entits au niveau de la base de donnes : on parle
didentifiant ou (dans un contexte de base de donnes) de cl. Reportez-vous au dbut du chapitre pour une dfinition
prcise de cette notion.
La pertinence est galement importante : on ne doit prendre en compte que les informations ncessaires pour satisfaire
les besoins. Par exemple :
le film Impitoyable ;
lacteur Clint Eastwood ;
sont des entits pour la base Films.
La premire tape dune conception consiste identifier les entits utiles. On peut souvent le faire en considrant
quelques cas particuliers. La deuxime est de regrouper les entits en ensembles : en gnral on ne sintresse pas un
individu particulier mais des groupes. Par exemple il est clair que les films et les acteurs constituent des ensembles
distincts dentits. Quen est-il de lensemble des ralisateurs et de lensemble des acteurs ? Doit-on les distinguer ou
les assembler ? Il est certainement prfrable de les assembler, puisque des acteurs peuvent aussi tre ralisateurs.
Attributs
Les entits sont caractrises par des attributs (ou proprits) : le titre (du film), le nom (de lacteur), sa date de
naissance, ladresse, etc. Le choix des attributs relve de la mme dmarche dabstraction qui a dict la slection des
entits : il nest pas ncssaire de donner exhaustivement tous les attributs dune entit. On ne garde que ceux utiles
pour lapplication.
Un attribut est dsign par un nom et prend sa valeur dans un domaine comme les entiers, les chanes de caractres, les
dates, etc. On peut considrer un nom datribut comme une fonction dfinie sur un ensemble dentits et prenant
ses valeurs dans un domaine pour une entit .
Selon cette dfinition un attribut prend une valeur et une seule. On dit que les attributs sont atomiques. Il sagit
dune restriction importante puisquon sinterdit, par exemple, de dfinir un attribut tlphones dune entit Personne,
prenant pour valeur les numros de tlphone dune personne. Cette restricion est lun des inconvnients du modle
relationnel, qui mne la multiplication des tables par le mcanisme de normalisation drit en dbut de chapitre. Pour
notre exemple, il faudrait par exemple dfinir une table ddie aux numros de tlphone et associe aux personnes.
Note : Certaines mthodes admettent lintroduction de constructions plus complexes :

les attributs multivalus sont constitus dun ensemble de valeurs prises dans un mme domaine ; une telle construc-
tion permet de rsoudre le problme des numros de tlphones multiples ;
les attributs composs sont constitus par agrgation dautres atributs ; un attribut adresse peut par exemple tre
dcrit comme lagrgation dun code postal, dun numro de rue, dun nom de rue et dun nom de ville.
Cette modlisation dans le modle conceptuel (E/A) doit pouvoir tre transpose dans la base de donnes. Certains
systmes relationnels (PostgreSQL par exemple) autorisent des attributs complexes. Une autre solution est de recourir
dautres modles, semi-structurs ou objets.
Nous nous en tiendrons pour linstant aux attributs atomiques qui, au moins dans le contexte dune modlisation
oriente vers un SGBD relationnel, sont suffisants.

2.2.3 Types dentits
Il est maintenant possible de dcrire un peu plus prcisment les entits par leur type.
Dfinition : Type dentit

Le type dune entit est compos des lments suivants :
son nom ;
la liste de ses attributs avec, optionnellement le domaine o lattribut prend ses valeurs : les entiers, les chanes
de caractres ;
lindication du (ou des) attribut(s) permettant didentifier lentit : ils constituent la cl.
On dit quune entit e est une instance de son type E. Enfin, un ensemble dentits {1 , 2 , . . . }, instances dun
mme type est une extension de .
Rappelons maintenant la notion de cl, pratiquement identique celle nonce pour les shmas relationnels.
Dfinition : cl
Soit un type dentit et lensemble des attributs de . Une cl de est un sous-ensemble minimal de permettant
didentifier de manire unique une entit parmi nimporte quelle extension de .
Prenons quelques exemples pour illustrer cette dfinition. Un internaute est caractris par plusieurs attributs : son
email, son nom, son prnom, la rgion o il habite. Ladresse mail constitue une cl naturelle puisquon ne trouve pas,
en principe, deux internautes ayant la mme adresse lectronique. En revanche lidentification par le nom seul parat
impossible puisquon constituerait facilement un ensemble contenant deux internautes avec le mme nom. On pourrait
penser utiliser la paire (nom,prnom), mais il faut utiliser avec modration lutilisation didentifiants composs
de plusieurs attributs. Quoique possible, elle peut poser des problmes de performance et complique les manipulations
par SQL.
Il est possible davoir plusieurs cls candidates pour un mme ensemble dentits. Dans ce cas on en choisit une comme
cl principale (ou primaire), et les autres comme cls secondaires. Le choix de la cl (primaire) est dterminant pour
la qualit du schma de la base de donnes. Les caractristiques dune bonne cl primaire sont les suivantes :
elle dsigne sans ambiguit une et une seule entit dans toute extension ;
sa valeur est connue pour toute entit ;
on ne doit jamais avoir besoin de la modifier ;
enfin, pour des raisons de performance, sa taille de stockage doit tre la plus petite possible.
Il est trs difficile de trouver un ensemble dattributs satisfaisant ces proprits parmi les attributs descriptifs dune
entit. Considrons lexemple des films. Le choix du titre pour identifier un film serait incorrect puisquon aura affaire
un jour ou lautre deux films ayant le mme titre. Mme en combinant le titre avec un autre attribut (par exemple
lanne), il est difficile de garantir lunicit.
Le choix de ladresse lectronique (email) pour un internaute semble respecter ces conditions, du moins la premire
(unicit). Mais peut-on vraiment garantir que lemail sera connu au moment de la cration de lentit ? De plus, il
semble clair que cette adresse peut changer, ce qui va poser de gros problmes puisque la cl, comme nous le verrons,
sert rfrencer une entit. Changer lidentifiant de lentit implique donc de changer aussi toutes les rfrences. La
conclusion simpose : ce choix didentifiant est un mauvais choix, il posera terme des problmes pratiques.
Insistons : la seule solution saine et gnrique consiste crer un identifiant artificiel, indpendant de tout autre
attribut. On peut ainsi ajouter dans le type dentit Film un attribut id, corespondant un numro squentiel qui sera
incrment au fur et mesure des insertions. Ce choix est de fait le meilleur, ds lors quun attribut ne respecte pas les
conditions ci-dessus (autrement dit, toujours). Il satisfait ces conditions : on peut toujours lui attribuer une valeur, il ne
sera jamais ncessaire de la modifier, et elle a une reprsentation compacte.
On reprsente graphiquement un type dentit comme sur la figure Reprsentation des types dentit (page 16) qui
donne lexemple des types Internaute et Film. Lattribut (ou les attributs sil y en a plusieurs) formant la cl sont en
gras.

F IGURE 2.2 Reprsentation des types dentit
Il est important de bien distinguer types dentits et entits. La distinction est la mme quentre entre type et valeur
dans un langage de programmation, ou schma et *base dans un SGBD, comme nous le verrons.
2.2.4 Associations binaires
La reprsentation (et le stockage) dentits indpendantes les unes des autres est de peu dutilit. On va maintenant
dcrire les relations (ou associations) entre des ensembles dentits.
Dfinition : association
Une association binaire entre les ensembles dentits 1 et 1 est un ensemble de couples (1 , 2 ), avec 1 1 et
2 2 .
Cest la notion classique, ensembliste, de relation. On emploie plutt le terme dassociation pour viter toute confusion
avec le modle relationnel. Une bonne manire dinterprter une association entre des ensembles dentits est de faire
un petit graphe o on prend quelques exemples, les plus gnraux possibles.
F IGURE 2.3 Association entre deux ensembles
Prenons lexemple de lassociation reprsentant le fait quun ralisateur met en scne des films. Sur le graphe de la
figure Association entre deux ensembles (page 16) on remarque que :
certains ralisateurs mettent en scne plusieurs films ;
inversement, un film est mis en scne par au plus un ralisateur.
La recherche des situations les plus gnrales possibles vise sassurer que les deux caractristiques ci-dessus sont
vraies dans tout les cas. Bien entendu on peut trouver x % des cas o un film a plusieurs ralisateurs, mais la question
se pose alors : doit-on modifier la structure de notre base, pour x % des cas. Ici, on a dcid que non. Encore une fois
on ne cherche pas reprsenter la ralit dans toute sa complexit, mais seulement la partie de cette ralit que lon
veut stocker dans la base de donnes.
Ces caractristiques sont essentielles dans la description dune association entre des ensembles dentits.
Dfinition : cardinalits
Soit une association (1 , 2 ) entre deux types dentits. La cardinalit de lassociation pour , {1, 2}, est une
paire [, ] telle que :

Le symbole max (cardinalit maximale) dsigne le nombre maximal de fois o une une entit peut intervenir dans
lassociation.
En gnral, ce nombre est 1 (au plus une fois) ou (plusieurs fois, nombre indetermin), not par le symbole *.
Le symbole min (cardinalit minimale) dsigne le nombre minimal de fois o une une entit peut intervenir dans
lassociation.
En gnral, ce nombre est 1 (au moins une fois) ou 0.
Les cardinalits maximales sont plus importantes que les cardinalits minimales ou, plus prcisment, elles savrent
beaucoup plus difficiles remettre en cause une fois que le schma de la base est constitu. On dcrit donc souvent
une association de manire abrge en omettant les cardinalits minimales. La notation * en UML, est labrviation
de 0..*, et 1 est labrviation de 1..1. On caractrise galement une association de manire concise en donnant les
cardinalits maximales aux deux extrmits, par exemple 1 :* (association de un plusieurs) ou * :* (association de
plusieurs plusieurs).
Les cardinalits minimales sont parfois dsignes par le terme contraintes de participation. La valeur 0 indique quune
entit peut ne pas participer lassociation, et la valeur 1 quelle doit y participer.
Insistons sur le point suivant : les cardinalits nexpriment pas une vrit absolue, mais des choix de conception. Elles
ne peuvent tre dclars valides que relativement un besoin. Plus ce besoin sera exprim prcisment, et plus il sera
possible dappcier la qualit du modle.
Il existe plusieurs manires de noter une association entre types dentits. Nous utilisons ici la notation de la mthode
UML. En France, on utilise aussi couramment de moins en moins... la notation de la mthode MERISE que nous
ne prsenterons pas ici.
F IGURE 2.4 Reprsentation de lassociation
Dans la notation UML, on indique les cardinalits aux deux extrmits dun lien dassociation entre deux types den-
tits et . Les cardinalits pour sont places lextrmit du lien allant de et les cardinalits pour
sont lextrmit du lien allant de .
Pour lassociation entre Ralisateur et Film, cela donne lassociation de la figure Reprsentation de lassociation
(page 17). Cette association se lit Un ralisateur ralise zro, un ou plusieurs films, mais on pourrait tout aussi bien
utiliser la forme passive avec comme intitul de lassociation Est ralis par et une lecture Un film est ralis par au
plus un ralisateur. Le seul critre privilgier dans ce choix des termes est la clart de la reprsentation.
Prenons maintenant lexemple de lassociation (Acteur, Film) reprsentant le fait quun acteur joue dans un film. Un
graphe bas sur quelques exemples est donn dans la figure Association (Acteur,Film) (page 18). On constate tout
dabord quun acteur peut jouer dans plusieurs films, et que dans un film on trouve plusieurs acteurs. Mieux : Clint
Eastwood, qui apparaissait dj en tant que metteur en scne, est maintenant galement acteur, et dans le mme film.
Cette dernire constatation mne la conclusion quil vaut mieux regrouper les acteurs et les ralisateurs dans un
mme ensemble, dsign par le terme plus gnral Artiste. On obtient le schma de la figure Association entre
Artiste et Film (page 18), avec les deux associations reprsentant les deux types de lien possible entre un artiste et un
film : il peut jouer dans le film, ou le raliser. Ce ou nest pas exclusif : Eastwood joue dans Impitoyable, quil a
aussi ralis.

F IGURE 2.5 Association (Acteur,Film)
F IGURE 2.6 Association entre Artiste et Film
Dans le cas dassociations avec des cardinalits multiples de chaque ct, on peut avoir des attributs qui ne peuvent
tre affects qu lassociation elle-mme. Par exemple lassociation Joue a pour attribut le rle tenu par lacteur dans
le film (figure Association entre Artiste et Film (page 18)).
Rappelons quun attribut ne peut prendre quune et une seule valeur. Clairement, on ne peut associer rle ni Acteur
puisquil a autant de valeurs possibles quil y a de films dans lesquels cet acteur a jou, ni Film, la rciproque tant
vraie galement. Seules les associations ayant des cardinalits multiples de chaque ct peuvent porter des attributs.
Quelle est la cl dune association ? Si lon sen tient la dfinition, une association est un ensemble de couples, et il ne
peut donc y avoir deux fois le mme couple (parce quon ne trouve pas deux fois le mme lment dans un ensemble).
On a donc :
Dfinition : Cl dune association

La cl dune association (binaire) entre un type dentit 1 et un type dentit 2 est la paire constitue de la cl 1 de
1 et de la cl 2 de 2 .
En pratique cette contrainte est souvent trop contraignante car on souhaite autoriser deux entits tre lies plus dune
fois dans une association. Imaginons par exemple quun internaute soit amen noter plusieurs reprises un film, et
que lon souhaite conserver lhistorique de ces notations successives. Avec une association binaire entre Internaute et
Film, cest impossible : on ne peut dfinir quun seul lien entre un film donn et un internaute donn.
Le problme est quil nexiste pas de moyen pour distinguer des liens multiples entre deux mmes entits. Le seul
moyen pour effectuer une telle distinction est dintroduire une entit discriminante, par exemple la date de la notation.
On obtient alors une association ternaire dans laquelle on a ajout un type dentit Date (figure Ajout dune entit Date
pour conserver lhistorique des notations (page 19)).
Un lien de cette association runit donc une entit Film, une entit Internaute et une entit Date. On peut identifier un
tel lien par un triplet (id, email, date) constitu par les cls des trois entits constituant le lien.
Comme le montre la figure Graphe dune association ternaire (page 19), il devient alors possible, pour un mme
internaute, de noter plusieurs fois le mme film, pourvu que ce ne soit pas la mme date. Rciproquement un
internaute peut noter des films diffrents le mme jour, et un mme film peut tre not plusieurs fois la mme date,
condition que ce ne soit pas par le mme internaute.

F IGURE 2.7 Ajout dune entit Date pour conserver lhistorique des notations
F IGURE 2.8 Graphe dune association ternaire

Mme si cette solution est correcte, elle prsente linconvnient dintroduire une entit assez artificielle, Date, qui
porte peu dinformation et vient alourdir le schma. En pratique on sautorise une notation abrge en ajoutant un
attribut date dans lassociation, et en le soulignant pour indiquer quil fait partie de la cl, en plus du couple des cls
des entits (voir figure Notation abrge dune association avec un type dentit Date (page 20)).
F IGURE 2.9 Notation abrge dune association avec un type dentit Date
Nous reviendrons plus longuement sur les associations ternaires par la suite.
2.2.5 Entits faibles
Jusqu prsent nous avons considr le cas dentits indpendantes les unes des autres. Chaque entit, disposant de
son propre identifiant, pouvait tre considre isolment. Il existe des cas o une entit ne peut exister quen troite
association avec une autre, et est identifie relativement cette autre entit. On parle alors dentit faible.
Prenons lexemple dun cinma, et de ses salles. On peut considrer chaque salle comme une entit, dote dattributs
comme la capacit, lquipement en son Dolby, ou autre. Il est diffcilement imaginable de reprsenter une salle sans
quelle soit rattache son cinma. Cest en effet au niveau du cinma que lon va trouver quelques informations
gnrales comme ladresse de la salle.
Il est possible de reprsenter le lien en un cinma et ses salles par une association classique, comme le montre la figure
Modlisations possibles du lien Cinma-Salle (page 21).a. La cardinalit 1..1 force la participation dune salle un
lien dassociation avec un et un seul cinma. Cette reprsentation est correcte, mais prsente un inconvnient : on doit
crer un identifiant artificiel id pour le type dentit Salle, et numroter toutes les salles, indpendamment du cinma
auquel elles sont rattaches.
On peut considrer quil est beaucoup plus naturel de numroter les salles par un numro interne chaque cinma. La
cl didentification dune salle est alors constitue de deux parties :
la cl de Cinma, qui indique dans quel cinma se trouve la salle ;
le numro de la salle au sein du cinma.
En dautres termes, lentit Salle ne dispose pas dune identification absolue, mais dune identification relative une
autre entit. Bien entendu cela force la salle a toujours tre associe un et un seul cinma.
La reprsentation graphique des entits faibles avec UML est illustre dans la figure Modlisations possibles du lien
Cinma-Salle (page 21).b. La salle est associe au cinma avec une association qualifie par lattribut no qui sert
de discriminant pour distinguer les salles au sein dun mme cinma. Noter que la cardinalit du ct Cinma est
implicitement 1..1.
Lintroduction dentits faibles est un subtilit qui permet de capturer une caractristique intressante du modle. Elle
nest pas une ncessit absolue puisquon peut trs bien utiliser une association classique. La principale diffrence
est que, dans le cas dune entit faible, on obtient une identification compose qui peut tre plus pratique grer, et
peut galement rendre plus faciles certaines requtes. On touche ici la libert de choix qui est laisse, sur bien des
aspects, un modeleur de base de donnes, et qui ncessite de sappuyer sur une exprience robuste pour apprcier
les consquences de telle ou telle dcision.

F IGURE 2.10 Modlisations possibles du lien Cinma-Salle
La prsence dun type dentit faible associ un type dentit implique galement des contraintes fortes sur les
crations, modifications et destructions des instances de car on doit toujours sassurer que la contrainte est valide.
Concrtement, en prenant lexemple de Salle et de Cinma, on doit mettre en place les mcanismes suivants :
quand on insre une salle dans la base, on doit toujours lassocier un cinma ;
quand un cinma est dtruit, on doit aussi dtruire toutes ses salles ;
quand on modifie la cl dun cinma, il faut rpercuter la modification sur toutes ses salles.
Rflchissez bien ces mcanismes pour apprcier le sucrot de contraintes apport par des variantes des associations.
Parmi les impacts qui en dcoulent, et pour respecter les rgles de destruction/cration nonces, on doit mettre en
place une stratgie. Nous verrons que les SGBD relationnels nous permettent de spcifier de telles stratgies.
2.2.6 Associations gnralises
On peut envisager des associations entre plus de deux entits, mais elles sont plus difficiles comprendre, et sur-
tout la signification des cardinalits devient beaucoup plus ambigue. La dfinition dune association -aire est une
gnralisation de celle des associations binaires.
Dfinition : associations n-aires

Une association n-aire entre n types dentits 1 , 2 , . . . est un ensemble de n-uplets (1 , 2 , . . . , ) o chaque
appartient .
Il nexiste pas en principe pas de limite sur le degr dune association. En pratique on ne va jamais au-del dune
association entre trois entits qui est dj assez difficile interprter.
Nous allons prendre lexemple dune association permettant de reprsenter la projection de certains films dans des
salles certains horaires. Il sagit dune association ternaire entre les types dentits Film, Salle et Horaire (figure
Association ternaire reprsentant les sances (page 22)). Chaque instance de cette association lie un film, un horaire
et une salle. La figure Graphe dune association ternaire (page 22) montre quelques-unes de ces instances.
Bien que, jusqu prsent, une association ternaire puisse tre considre comme une gnralisation directe des asso-
ciations binaires, en ralit de nouveaux problmes sont soulevs.
Tout dabord les cardinalits sont, implicitement, 0..*. Il nest pas possible de dire quune entit ne participe quune
fois lassociation. Il est vrai que, dune part la situation se prsente rarement, dautre part cette limitation est due
la notation UML qui place les cardinalits lextrmit oppose dune entit.

F IGURE 2.11 Association ternaire reprsentant les sances
F IGURE 2.12 Graphe dune association ternaire

Plus problmatique en revanche est la dtermination de la cl. Quest-ce qui identifie un lien entre trois entits ? En
principe, la cl est le triplet constitu des cls respectives de la salle, du film et de lhoraire constituant le lien. On
aurait donc le -uplet [nomCinma, noSalle, idFilm, idHoraire]. Une telle cl est assez volumineuse, ce qui risque de
poser des problmes de performance. De plus elle ne permet pas dimposer certaines contraintes comme, par exemple,
le fait que dans une salle, pour un horaire donn, il ny a quun seul film. Comme le montre la figure Graphe dune
association ternaire (page 22), il est tout fait possible de crer deux liens distincts qui sappuient sur le mme horaire
et la mme salle.
Ajouter une telle contrainte, cest signifier que la cl de lassociation est en fait constitu de [nomCinma, noSalle,
idHoraire]. Cest donc un sous-ensemble de la concatnation des cls, ce qui semble rompre avec la dfinition donne
prcdemment. On peut videmment compliquer les choses en ajoutant une deuxime contrainte similaire, comme
connaissant le cinma, le film et lhoraire, je connais la salle. Il faut ajouter une deuxime cl [idFilm,idHoraire]. Il
nest donc plus possible de dduire automatiquement la cl comme on le faisait dans le cas des associations binaires.
Plusieurs cls deviennent possibles : on parle de cl candidates.
Les associations de degr suprieur deux sont difficiles manipuler et interprter. Il est toujours possible de
remplacer cette association par un type dentit. Pour cela on suit la rgle suivante :
Rgle
Soit une association entre les types dentit {1 , 2 , . . . , }. La transformation de en type dentit seffectue
en trois tapes :
On attribue un identifiant autonome .
On cre une association de type 1 :n entre et chacun des La contrainte minimale, du ct de A, est toujours
1.
Lassociation prcdente peut tre transforme en un type dentit Sance. On lui attribue un identifiant idSance,
et des associations 1..* avec Film, Horaire et Salle. Voir figure Lassociation Sance transforme en entit (page 23).
F IGURE 2.13 Lassociation Sance transforme en entit
2.2.7 Bilan
Le modle Entit/Association est simple et pratique.

Il ny a que 3 concepts : entits, associations et attributs.
Il est appropri une reprsentation graphique intuitive, mme sil existe beaucoup de conventions.
Il permet de modliser rapidement des structures pas trop complexes.

Il prsente malheureusement plusieurs limitations, qui dcoulent du fait que beaucoup de choix de conceptions plus
ou moins quivalents peuvent dcouler dune mme spcification, et que la spcification elle-mme est dans la plupart
du cas informelle et sujette interprtation.
Un autre inconvnient du modle E/A reste sa pauvret : il est difficile dexprimer des contraintes dintgrit, des
structures complexes. Beaucoup dextensions ont t proposes, mais la conception de schma reste en partie matire
de bon sens et dexprience. On essaie en gnral :
de se ramener des associations entre 2 entits : au-del, on a probablement intrt a transformer lassociation en
entit ;
dviter toute redondance : une information doit se trouver en un seul endroit ;
enfin et surtout de privilgier la simplicit et la lisibilit, notamment en ne reprsentant que ce qui est strictement
ncessaire.
La mise au point dun modle engage fortement la suite dun projet de dveloppement de base de donnes. Elle doit
sappuyer sur des personnes exprimentes, sur lcoute des prescripteurs, et sur un processus par itration qui identifie
les ambiguits et cherche les rsoudre en prcisant le besoin correspondant. Dans le cadre des bases de donnes, le
modle E/A est utilis dans la phase de conception. Il permet de spcifier la structure des informations qui vont tre
contenues dans la base et doffrir une reprsentation abstraite indpendante du modle logique qui sera choisi ensuite.
Signalons pour finir que les SGBD fournissent des outils de modlisation troitement associs la production et la
maintenance de la base. Cest le cas par exemple de MySQLWorkbench que vous pouvez librement rcuprer et tester
(https ://www.mysql.fr/products/workbench/).

CHAPITRE 3
Le modle relationnel
Un modle de donnes dfinit un mode de reprsentation des donnes selon trois composantes :
Des structures.
Des contraintes.
Des oprations.
Les deux premires relvent du Langage de Dfinition de Donnes (LDD) dans un Systme de Gestion de Bases
de Donnes (SGBD). Le LDD est utilis pour dcrire le schma dune base de donnes. La troisime composante
(oprations) est la base du Langage de Manipulation de Donnes (LMD) dont le reprsentant le plus clbre est SQL.
Dans le contexte des bases de donnes, la principale qualit dun modle de donnes est dtre indpendant de la
reprsentation physique. Cette indpendance permet de sparer totalement les tches respectives des administrateurs
de la base, chargs de loptimisation de ses performances, et des dveloppeurs dapplication ou utilisateurs finaux qui
nont pas se soucier de la manire dont le systme satisfait leurs demandes.
Le modle relationnel offre une totale indpendance entre les reprsentations logique et physique. Ce chapitre prsente
la partie du modle relative la dfinition et la cration des tables.
3.1 Dfinition dun schma relationnel
Un des grands avantages du modle relationnel est sa trs grande simplicit. Il nexiste en effet quune seule structure,
la relation. Une relation peut simplement tre reprsente sous forme de table (les deux termes seront employs comme
des synonymes). Une table a un nom (Film) et se compose dun ensemble de colonnes dsignes par un nom dattribut.
Dans chaque colonne on trouve des valeurs dun certain domaine (chanes de caractres, nombres). Enfin chaque ligne
(ou nuplet) correspond une entit (ici des films).
id titre anne genre
1 Alien 1979 Science-Fiction
2 Vertigo 1958 Suspense
3 Psychose 1960 Suspense
4 Kagemusha 1980 Drame
5 Volte-face 1997 Policier
6 Pulp Fiction 1995 Policier
7 Titanic 1997 Drame
8 Sacrifice 1986 Drame
Un schma relationnel est constitu dun ensemble de schmas de relations qui dcrivent, laide des lements pr-
sents informellement ci-dessus (domaines, attributs, noms de relation) le contenu dune relation. Le schma de cette
table est donc :
Film (titre: string, anne: number, genre : string)
25
Il existe un langage de dfinition pour crer une relation dans un SGBDR, mais nous nous contenterons pour linstant
de cette description simplifie. Voici maintenant quelques prcisions sur la terminologie introduite ci-dessus.
Domaines
Un domaine de valeurs est un ensemble dinstances dun type lmentaire. Exemple : les entiers, les rels, les chanes
de caractres, etc. La notion de type lmentaire soppose celle de type structur : il nest pas possble en relationnel
de placer dans une cellule un graphe, une liste, un enregistrement. En dautres termes le systme de types est fig et
fourni par le systme.
Note : Cest une limitation que lon a cherch lever par lextension des systmes de nouveaux types. Ces SGBD
extensibles ne sont pas prsents ici.
Attributs
Les attributs nomment les colonnes dune relation. Il servent la fois indiquer le contenu de cette colonne, et la
rfrencer quand on effectue des oprations. Un attribut est toujours associ un domaine. Un mme nom dun attribut
peut apparatre dans plusieurs schmas distincts.
Schma de relation
Un schma est simplement un nom suivi de la liste des attributs, chaque attribut tant associ un type. La syntaxe est
donc :
(1 : 1 , 2 : 2 , . . . , : )
o les sont les noms dattributs et les les types.

On peut trouver dans un schma de relation plusieurs fois le mme type, mais une seule fois un mme nom dattribut.
Le type peut tre omis en phase de dfinition. Il est daileurs reltivement facile de changer le type dun attribut sur une
base existante.
Instance dune relation
Une instance dune relation R, ou simplement relation se dfinit mathmatiquement comme un sous-ensemble fini
du produit cartsien des domaines des attributs de . Rappelons que le produit cartsien 1 . . . entre des
domaines 1 , . . . , est lensemble de tous les nuplets (1 , . . . , ), .
Un des fondements du modle relationnel est la thorie des ensembles et la notion de relation dans le modle corres-
pond strictement au concept mathmatique dans cette thorie. Une (instance de) relation se reprsente sous forme de
table, et on emploie le plus souvent ces deux termes comme des synonymes.
La dfinition dune table comme un ensemble (au sens mathmatique) a quelques consquences importantes :
lordre des lignes est indiffrent car il ny a pas dordre dans un ensemble ; consquence pratique : le rsultat dune
requte applique une table ne dpend pas de lordre des lignes dans la table ;
on ne peut pas trouver deux fois la mme ligne car il ny a pas de doublons dans un ensemble ;
il ny a pas de cellule vide dans la table, donc toutes les valeurs de tous les attributs sont toujours connues.
Dans la pratique les choses sont un peu diffrentes pour les doublons et les cellules vides, comme nous le verrons plus
loin.
Cl dune table
Une cl dune table est un sous-ensemble des attributs qui permet didentifier chaque ligne de manire unique (cf.
le chapitre Conception dune base de donnes (page 5)). Comme on a vu que deux lignes sont toujours diffrentes,
lensemble de tous les attributs est lui-mme une cl mais il est indispensable de trouver au moins un sous-ensemble
satisfaisant la condition. Le choix de la cl, qui seffectue au moment de la conception, est trs important pour la
qualit du schma. Choisir didentifier un film par son titre comme nous lavons envisag dans lexemple prcdent
nest pas un trs bon choix. Reportez-vous sur ce sujet dans le chapitre Conception dune base de donnes (page 5)
consacr la modlisation.
nuplets
26 Chapitre 3. Le modle relationnel

Un nuplet dune relation (1 , . . . , ) est une liste de n valeurs (1 , . . . , ) o chaque est la valeur dun attribut
de type . Exemple :
(Cyrano, 1992, Rappeneau)
Un nuplet est reprsent par une ligne dans une relation sous forme de table. En principe, on connat les valeurs de
tous les attributs du nuplet.
Note : La terminologie nuplet vient directement de celle utilise en thorie des ensembles. En pratique, on utilisera
couramment le terme ligne, et parfois tuple qui nest pas reconnu par lAcadmie.
Base de donnes
Une (instance de) base de donnes est un ensemble fini (dinstances) de relations. Le schma de la base est lensemble
des schmas des relations de cette base.
La cration dun schma de base de donnes est simple une fois que lon a dtermin toutes les tables qui constituent la
base. En revanche le choix de ces tables est un problme difficile car il dtermine en grande partie les caractristiques
et qualits de la base : performances, exactitude, exhaustivit, disponibilit des informations, etc. En pratique, on
dfinit le schma laide dun modle de donnes conceptuel, puis on le transcrit en schma relationnel. La technique
la plus rpandue consiste partir dun schma Entit/Association. La section suivante donne les rgles du processus
de transformation, en sappuyant sur lexemple du schma E/A, de la figure Le schma E/A des films (page 27), discut
dans le chapitre Conception dune base de donnes (page 5).
F IGURE 3.1 Le schma E/A des films
3.2 Passage dun schma E/A un schma relationnel
On passe donc dun modle disposant de deux structures (entits et associations) un modle disposant dune seule
(tables). Logiquement, entits et associations seront donc toutes deux transformes en tables. La subtilit rside en fait
dans la ncessit de prserver les liens existant explicitement dans un schma E/A et qui semblent manquer dans le
3.2. Passage dun schma E/A un schma relationnel 27

modle relationnel. Dans ce dernier cas on utilise en fait un mcanisme de rfrence par valeur bas sur les cls des
tables.
3.2.1 Types dentits
Le schma dune table est constitu du nom de la table, suivi de la liste des attributs. Alors, pour chaque type dentit
du schma E/A, on obtient le schma dune table :
La table a le mme nom que lentit.
Chaque proprit du type dentit, y compris lidentifiant, devient un attribut de la table.
Lidentition est la cl de la table.
partir du schma E/A de la figure Le schma E/A des films (page 27), on obtient les schmas de table suivants. La
cl primaire est en gras.
Film (idFilm, titre, anne, genre, rsum)
Artiste (idArtiste, nom, prnom, anneNaissance)
Internaute (email, nom, prnom, rgion)
Pays (code, nom, langue)
Chaque entit sera donc reprsente par une ligne (nuplet) dans la table. On peut remarquer que lon a perdu pour
linstant tout lien entre les tables.
3.2.2 Associations de un plusieurs
Soit une association de un plusieurs (l sagit ici des cardinalits maximales). Le passage au modle relationnel suit
les rgles suivantes :
On cre les tables et correspondant respectivement aux entits et , appliquant la premire rgle.
Lidentifiant de devient un attribut de .
Lide est quune ligne (entit) de rfrence la ligne (entit) de qui lui est associe laide dun attribut qui
contient la valeur de la cl de . Cet attribut est la cl trangre de dans .
Voici le schma obtenu pour reprsenter lassociation entre les types dentit Film, Artiste et Pays. Les cls trangres
sont en italiques.
Film (idFilm, titre, anne, genre, rsum, idArtiste, codePays)
Pays (code, nom, langue)
Comment nommer la cl trangre ? Ici nous avons adopt une convention simple en concatnant id et le nom de la
table rfrence. On peut souvent faire mieux. Par exemple, dans le schma de la table Film, le rle prcis tenu par
lartiste rfrenc dans lassociation nest pas induit par le nom idArtiste. Lartiste dans Film a un rle de metteur
en scne, mais il pourrait tout aussi bien sagir du dcorateur ou de laccessoiriste : rien dans le nom de lattribut ne le
prcise
On peut donner un nom plus explicite lattribut. Il nest pas du tout obligatoire en fait que les attributs constituant
une cl trangre aient le mme nom que ceux de le cl primaire auxquels ils se rfrent. Voici le schma de la table
Film, dans lequel la cl trangre pour le metteur en scne est nomme idRalisateur.
Film (idFilm, titre, anne, genre, rsum, idRalisateur)
Les tables ci-dessous montrent un exemple de la reprsentation des associations entre Film et Artiste dune part, Film
et Pays dautre part (on a omis le rsum du film). Noter que lon ne peut avoir quun artiste dont lid est 102 dans la
table Artiste, puisque lattribut idArtiste ne peut prendre quune valeur. Cela correspond la contrainte, identifie
pendant la conception et modlise dans le schma E/A de la figure Le schma E/A des films (page 27), quun film na
quun seul ralisateur.
En revanche rien nempche cet artiste 102 de figurer plusieurs fois dans la colonne idRalisateur de la table
Film puisquil ny a aucune contrainte dunicit sur cet attribut. On a donc bien lquivalent de lassociation un
plusieurs labore dans le schma E/A.

id nom prnom anne

101 Scott Ridley 1943
102 Hitchcock Alfred 1899
103 Kurosawa Akira 1910
104 Woo John 1946
105 Tarantino Quentin 1963
106 Cameron James 1954
107 Tarkovski Andrei 1932
Et voici la table des films. Remarquez que chaque valeur de la colonne idRalisateur est lidentifiant dun artiste.
id titre anne genre idRalisateur codePays
1 Alien 1979 Science-Fiction 101 USA
2 Vertigo 1958 Suspense 102 USA
3 Psychose 1960 Suspense 102 USA
4 Kagemusha 1980 Drame 103 JP
5 Volte-face 1997 Policier 104 USA
6 Pulp Fiction 1995 Policier 105 USA
7 Titanic 1997 Drame 106 USA
8 Sacrifice 1986 Drame 107 FR
Note : les valeurs des cls primaires et trangres sont compltement indpendantes lune de lautre. Nous avons
identifi les films en partant de 1 et les artistes en partant de 101 pour des raisons de clart, mais en pratique rien
nempche de trouver une ligne comme :
(63, Gravity, 2014, SF, 63, USA)
Il ny a pas dambiguit : le premier 63 est lidentifiant du film, le second est lidentifiant du ralisateur.
Et voici, pour complter, la table des pays.

code nom langue
USA Etats Unis anglais
FR France franais
JP Japon japonais
3.2.3 Associations avec type dentit faible
Une entit faible est toujours identifie par rapport une autre entit. Cest le cas par exemple de lassociation entre
Cinma et Salle (voir chapitre Conception dune base de donnes (page 5)). Cette association est de type un
plusieurs car lentit faible (une salle) est lie une seule autre entit (un cinma) alors que, en revanche, un cinma
peut tre li plusieurs salles.
Le passage un schma relationnel est donc identique celui dune association 1-n classique. On utilise un mcanisme
de cl trangre pour rfrencer lentit forte dans lentit faible. La seule nuance est que la cl trangre est une partie
de lidentifiant de lentit faible.
Regardons notre exemple pour bien comprendre. Voici le schma obtenu pour reprsenter lassociation entre les types
dentit Cinma et Salle.
Cinma (id, nom, numro, rue, ville)
Salle (idCinma, no, capacit)
On note que lidentifiant dune salle est constitu de lidentifiant du cinma et dun numro complmentaire permettant
de distinguer les salles au sein dun mme cinma. Mais lidentifiant du cinma dans Salle est aussi une cl trangre
rfrenant une ligne de la table Cinma. En dautres termes, la cl trangre est une partie de la cl primaire.
Cette modlisation simplifie lattribution de lidentifiant une nouvelle entit Salle puisquil suffit de reprendre liden-
tifiant du compos (le cinma) et de numroter les composants (les salles) relativement au compos. Il ne sagit pas
dune diffrence vraiment fondamentale avec les associations 1-n mais elle peut clarifier le schma.

3.2.4 Associations binaires de plusieurs plusieurs
Soit une association binaire n-n entre et . La transformation en un schma relationnel se fait de la manire suivante :
On cre les tables * et * correspondant respectivement aux entits et .
On cre une table pour lassociation. La cl de * et la cl de * deviennent des cls trangres de .
La cl de cette table est la concatnation des cls des tables et .
Les proprits de lassociation deviennent des attributs de .
Toujours partir du schma des films, on obtient la table Rle reprsentant lassociation entre les films et les acteurs.
Par application des rgles, on obtient :
Film (idFilm, titre, anne, genre, rsum, idRalisateur, codePays)
Role (idFilm, idActeur, nomRle)
De mme, on obtient une table Notation pour reprsenter lassociation entre un internaute et les films quil a nots.
Internaute (email, nom, prnom, rgion)
Notation (email, idFilm, note)
Pour bien comprendre le mcanisme de representation des entits et associations grce aux cls primaires et trangres,
examinons les tables suivantes montrant un exemple de reprsentation de Rle. On peut constater le mcanisme de
rfrence unique obtenu grce aux cls des tables. Chaque rle correspond un unique acteur et un unique film.
De plus on ne peut pas trouver deux fois la mme paire (idFilm, idActeur) dans cette table (cest un choix
de conception qui dcoule du schma E/A sur lequel nous nous basons). En revanche un mme acteur peut figurer
plusieurs fois (mais pas associ au mme film), ainsi quun mme film (mais pas associ au mme acteur).
Voici tout dabord la table des films.
id titre anne genre idRalisateur codePays
20 Impitoyable 1992 Western 130 USA
21 Ennemi dtat 1998 Action 132 USA
Puis la table des artistes.
id nom prnom anne
130 Eastwood Clint 1930
131 Hackman Gene 1930
132 Scott Tony 1930
133 Smith Will 1968
En voici enfin la table des rles, qui consiste ensentiellement en identifiants tablissant des liens avec les deux tables
prcdentes. vous de les dcrypter pour comprendre comment toute linformation est reprsente, et conforme aux
choix de conception issus du schma E/A. Que peut-on dire de lartiste 130 par exemple ? Peut-on savoir dans quels
films joue Gene Hackman ? Qui a mis en scne Impitoyable ?
idFilm idArtiste nomRle
20 130 William Munny
20 131 Little Bill
21 131 Bril
21 133 Robert Dean
On peut donc remarquer que chaque partie de la cl de la table Rle est elle-mme une cl trangre qui fait rfrence
une ligne dans une autre table :
lattribut idFilm fait rfrence une ligne de la table Film (un film) ;
lattribut idActeur fait rfrence une ligne de la table Artiste (un acteur) ;
Le mme principe de rfrencement et didentification des tables sapplique la table Notation. Il faut bien noter
que, par choix de conception, on a interdit quun internaute puisse noter plusieurs fois le mme film, de mme quun
acteur ne peut pas jouer plusieurs fois dans un mme film. Ces contraintes ne constituent pas des limitations, mais des
dcisions prises au moment de la conception sur ce qui est autoris, et sur ce qui ne lest pas.

Le processus de conception dtaill ci-dessus permet de dcomposer toutes les informations dune base de donnes
en plusieurs tables dont chacune stocke un des ensembles dentits. Les liens sont dfinis par un mcanisme de rf-
rencement bas sur les cls primaires et les cls trangres. Ce mcanisme est la fois simple et puissant, et bien le
comprendre est ncessaire pour matriser la construction de bases de donnes qui ne demanderont par de rorganisation
ncessairement douloureuse par la suite.
3.2.5 Associations ternaires
Dans le cas dassociations impliquant plus de deux entits, on atteint une des limites du modle Entit/Association en
matire de spcification de contraintes. En premire approche, on peut appliquer la rgle nonce prcdemment pour
les associations binaires et la gnraliser. On obtiendrait alors, pour lassociation Sance :
Cinma (idCinma, nomCinma, numro, rue, ville)
Salle (idCinma, no, capacit)
Horaire (idHoraire, heureDbut, heureFin)
Sance (idFilm, idCinma, noSalle, idHoraire, tarif)
La table Sance a pour cl la concatnation des identifiants de chacune des entits composantes, ce qui donne une
cl dune taille assez importante, avec 4 attributs. La contrainte dunicit portant sur lensemble des attributs, on
saperoit que rien ninterdit quune mme salle prsente deux films diffrents au mme horaire. Si on souhaite viter
cette situation, la cl devient (idCinma, noSalle, idHoraire), et on ne respecte plus la rgle de passage du schma
E/A vers le schma relationnel.
En dautres termes, en cas dassociation entre plus de 2 entits, la cl de la table reprsentant lassociation est un
sous-ensemble de la concatnation des cls. Il faut se poser soigneusement la question de la (ou des) cl(s) au moment
de la cration de la table car elle(s) ne peu(ven)t plus tre dduite(s) du schma E/A. On parle parfois de cl candidate.
On peut trouver plus de deux cls candidates : cest le cas par exemple si on souhaite quun mme cinma ne prsente
pas deux fois le mme film dans des salles diffrentes.
Ce type de contrainte est exprimable dans un schma relationnel (voir, plus loi, la clause unique). Les exemples qui
prcdent montrent que lassociation de plus de deux entits introduit une libert dinterprtation et de reprsentation
des donnes qui peut se faire au dpend de leur cohrence. Il est en fait trs recommand de ne reprsenter dans le
schma E/A que des associations binaires, ce qui peut se faire dans le cas qui prcde en transformant lassociation
ternaire en une entit Sance dote de son propre identifiant. La plupart des modles de donnes intgrs comme outils
de conception aux SGBD ne permettent que des associations binaires.
3.2.6 Retour sur le choix des identifiants
Il est maintenant largement admis que la cl dune table doit tre un identifiant neutre contenant un entier auto-
incrment chaque insertion. En effet :
La valeur de la cl doit tre connue au moment de linsertion.
Chaque valeur de lidentifiant doit caractriser de manire unique une occurrence, ; le titre pour la table Film ou le
nom pour la table Acteur ne sont clairement pas des bons choix.
Si on utilise un ensemble de proprits comme identifiant, la rfrence une entit devient trs lourde ; par exemple,
la cl de Cinma pourrat tre (nom, rue, ville).
Lidentifiant sert de rfrence externe et ne doit donc jamais tre modifi (il faudrait rpercuter les mises jour sur
les valeurs des cls trangres, ce qui est trs compliqu garantir).
Il savre, sauf cas particulier, impossible de trouver une proprit dans une entit qui satisfait toutes ces conditions.
Si on a une table Personne, par exemple, on peut mener la discussion suivante :
Le numro de scurit sociale ? Oui, il identifie uniquement une personne ; est-ce quil ne change jamais ? Cest
moins clair : que se passe-t-il si on a fait une erreur la saisie par exemple. Est-il toujours connu au moment de
linsertion de lentit ? L, il semble trs aventureux de rpondre oui : quid des trangers, des mineurs, de cas o
le no SS est temporairement inconnu ? Ce nest certainement pas un bon choix.

Ladresse lectronique (email) ? Oui cest un identifiant unique, mais est-ce quil ne peut pas passer dune personne
une autre ? En tout il est clair que les personnes changent demail, ce qui rompt une des conditions ci-dessus.
En conclusion, la seule mthode dont on peut tre sr quelle ne prsente pas de risque est lajout dun attribut id, de
type entier, dans lequel on place une valeur unique gnre par le programme dinsertion.
Ce choix ne rgle pas le risque de redondance (la mme entit prsente plusieurs fois) et mme, dune certaine manire,
la maximalise. En effet, puisque lidentifiant est gnr, une insertion rpte dune mme entit engendre de nouveaux
identifiants sans provoquer de rejet. La redondance doit tre gre, mais indpendamment du choix de lidentifiant,
par des contraintes dunicit qui sont exprimables dans le langage de cration des tables.
3.3 Dfinition dun schma SQL
Cette section prsente le langage de dfinition de donnes (LDD) qui permet de spcifier le schma dune base de
donnes relationnelle. Ce langage correspond une partie de la norme SQL (structured query language), lautre partie
tant relative la manipulation des donnes (LMD).
La dfinition dun schma comprend essentiellement deux parties : dune part la description des tables et de leur
contenu, dautre part les contraintes qui portent sur les donnes de la base. La spcification des contraintes est souvent
place au second plan bien quelle soit en fait trs importante : elle permet dassurer, au niveau de la base, des
contrles sur lintgrit des donns qui simposent toutes les applications accdant cette base. Un dernier aspect
de la dfinition dun schma, rapidement survol ici, est la description de la reprsentation dite physique, celle qui
dcrit lorganisation des donnes. Il est toujours possible de rorganiser une base, et on peut donc tout fait adopter
initialement lorganisation choisie par dfaut pour le systme.
3.3.1 Types SQL
La norme SQL ANSI propose un ensemble de types dont les principaux sont donns dans le tableau ci-dessous. Ce
tableau prsente galement la taille, en octets, des instances de chaque type, cette taille ntant ici qu titre indicatif
car elle peut varier selon les systmes.
Type Description Taille
integer Type des entiers relatifs 4 octets
smallint idem 2 octets
bigint idem 8 octets
float Flottants simple prcision 4 octets
double Flottants double prcision 8 octets
real Flottant simple ou double 8 octets
numeric (M, D) Numrique avec prcision fixe. M octets
decimal(M, D) Idem. M octets
char(M) Chanes de longueur fixe M octets
varchar*(M*) Chanes de longueur variable L+1 avec
bit varying Chanes doctets Longueur de la chane.
date Date (jour, mois, an) env. 4 octets
time Horaire (heure, minutes, secondes) env. 4 octets
datetime Date et heure 8 octets
year Anne 2 octets
Types numriques exacts
La norme SQL ANSI distingue deux catgories dattributs numriques : les numriques exacts, et les numriques flot-
tants. Les types de la premire catgorie (essentiellement integer et decimal) permettent de spcifier la prcision
souhaite pour un attribut numrique, et donc de reprsenter une valeur exacte. Les numriques flottants correspondent
aux types couramment utiliss en programmation (float, double) et ne reprsentent une valeur quavec une prci-
sion limite.

Le type integer permet de stocker des entiers, sur 4 octets en gnral. Il existe deux variantes du type integer :
smallint et bigint. Ces types diffrent par la taille utilise pour le stockage : voir le tableau des types SQL.
Le type decimal(M, D) correspond un numrique de taille maximale M, avec un nombre de dcimales fix D.
numeric est un synonyme de decimal. Ces types sont surtout utiles pour manipuler des valeurs dont la prcision
est connue, comme les valeurs montaires. Afin de prserver cette prcision, les instances de ces types sont stockes
comme des chanes de caractres.
Types numriques flottants
Ces types sappuient sur la reprsentation des numriques flottants propre la machine, en simple ou double prcision.
Leur utilisation est donc analogue celle que lon peut en faire dans un langage de programmation comme le C.
Le type float correspond aux flottants en simple prcision.
Le type double precision correspond aux flottants en double prcision ; le raccourci double est accept.
Caractres et chanes de caractres
Les deux types principaux de la norme ANSI sont char et varchar. Ces deux types permettent de stocker des
chanes de caractres dune taille maximale fixe par le paramtre M. Les syntaxes sont identiques. Pour le premier,
char(M), et varchar(M) pour le second. La diffrence essentielle est quune valeur char a une taille fixe, et se
trouve donc complte avec des blancs si sa taille est infrieure M. En revanche une valeur varchar a une taille
variable et est tronque aprs le dernier caractre non blanc.
Quand on veut stocker des chanes de caractres longues (des textes, voire des livres), dont la taille dpasse, typique-
ment, 255 caractres, le type varchar ne suffit plus. La norme SQL propose un type bit varying qui correspond
de trs longues chanes de caractres. Souvent les systmes proposent des variantes de ce type sous le nom text ou
blob (pour Binary Long Object).
Dates
Un attribut de type date stocke les informations jour, mois et anne (sur 4 chiffres). La reprsentation interne nest
pas spcifie par la norme. Tous les systmes proposent de nombreuses oprations de conversion (non normalises)
qui permettent dobtenir un format daffichage quelconque.
Un attribut de type time reprsente un horaire avec une prcision la seconde. Le type datetime permet de
combiner une date et un horaire.
3.3.2 Cration des tables
Dune manire gnrale, les objects du schma sont crs avec create, modifis avec alter et dtruits avec drop,
alors que les donnes, instances du schma sont cres, modifies et dtruites avec, respectivement, insert, update
et delete.
Voici un premier exemple avec la commande de cration de la table Internaute.
create table Internaute (email varchar (40) not null,
nom varchar (30) not null ,
prenom varchar (30) not null,
region varchar (30),
primary key (email));
La syntaxe se comprend aisment. La seule difficult est de choisir correctement le type de chaque attribut.
Conventions : noms des tables, des attributs, mots-cl SQL

On dispose, comme dans un langage de programmation, dune certaine libert. La seule recommandation est dtre
cohrent pour des raisons de lisibilit. Dune manire gnrale, SQL nest pas sensible la casse. Quelques proposi-
tions :
Le nom des tables devrait commencer par une majuscule, le nom des attributs par une minuscule ;
3.3. Dfinition dun schma SQL 33

quand un nom dattribut est constitu de plusieurs mots, on peut soit les sparer par des caractres _, soit employer
la convention CamelCase : minuscule au premier mot, majuscule aux suivants. Exemple : mot_de_passe ou
motDePasse.
Majuscule ou minuscule pour les mots-cl SQL ? Quand on inclut une commande SQL dans un langage de pro-
grammation, il est sans doute plus lisible dutiliser des majuscules pour les mots-cl.
Les accents et caractres diacritiques sont-ils accepts ? En principe oui, cela dpend des systmes. Mais en pratique
le codage au-del de lASCII est toujours susceptible de soulever des problmes (par exemple pour interroger une base
dont le schma contient des lettres accentues, avec un clavier QWERTY). Il vaut sans doute mieux malheureusement
lviter.
Le not null dans la cration de table Internaute indique que lattribut correspondant doit toujours avoir une valeur.
Il sagit dune diffrence importante entre la pratique et la thorie : on admet que certains attributs peuvent ne pas
avoir de valeur, ce qui est trs diffrent dune chane vide ou de 0. Quand on parle de valeur null en SQL, il sagit
en fait dune absence de valeur. En consquence :
on ne peut pas faire dopration incluant un null ;
on ne peut pas faire de comparaison avec un null.
Labsence de valeur a des consquences parfois droutantes. Il est prfrable dajouter la contrainte not null quand
cest pertinent : cela renforce la qualit de la base et facilite le travail des applications par la suite. Loption suivante
permet ainsi de garantir que tout internaute a un mot de passe.
motDePasse varchar(60) not null
Le SGBD rejettera alors toute tentative dinsrer une ligne dans Internaute sans donner de mot de passe.
Important : La cl primaire doit toujours tre dclare not null.
Une autre manire de forcer un attribut toujours prendre une valeur est de spcifier une valeur par dfaut avec
loption default.
create table Cinema (id integer not null,
nom varchar (30) not null ,
adresse varchar(255) default Inconnue
primary key (id));
Quand on insrera une ligne dans la table Cinma sans indiquer dadresse, le systme affectera automatiquement la
valeur Inconnue cet attribut. En gnral on utilise comme valeur par dfaut une constante, sauf pour quelques
variables fournies par le systme (par exemple sysdate pour indiquer la date courante).
3.3.3 Contraintes
La cration dune table telle quon la vue prcdemment est extrmement sommaire car elle nindique que le contenu
de la table sans spcifier les contraintes que doit respecter ce contenu. Or il y a toujours des contraintes et il est
indispensable de les inclure dans le schma pour assurer (dans la mesure du possible) lintgrit de la base.
Voici les rgles (ou contraintes dintgrit) que lon peut demander au systme de garantir :
La valeur dun attribut doit tre unique au sein de la table.
Un attribut doit toujours avoir une valeur. Cest la contrainte not null vue prcdemment.
Un attribut (ou un ensemble dattributs) constitue(nt) la cl de la table.
Un attribut dans une table est lie la cl primaire dune autre table (intgrit rfrentielle).
Enfin toute rgle sappliquant la valeur dun attribut (min et max par exemple).
Les contraintes sur les cls doivent tre systmatiquement spcifies. La dernire (clause check) sappuie en grande
partie sur la connaissance du langage dinterrogation de SQL et sera vue ultrieurement.

Cls dune table
Une cl est un attribut (ou un ensemble dattributs) qui identifie(nt) de manire unique un nuplet dune table. Il peut
y avoir plusieurs cls mais lune dentre elles doit tre choisie comme cl primaire. Ce choix est important : la cl
primaire est la cl utilise pour rfrencer une ligne et une seule partir dautres tables. Il est donc trs dlicat de
la remettre en cause aprs coup. En revanche les cls secondaires peuvent tre cres ou supprimes beaucoup plus
facilement.
La cl primaire est spcifie avec loption primary key.
create table Pays (code varchar(4) not null,
nom varchar (30) default Inconnu not null,
langue varchar (30) not null,
primary key (code));
Il doit toujours y avoir une cl primaire dans une table afin de pouvoir dsigner une ligne de manire univoque. Une
cl peut tre constitue de plusieurs attributs :
create table Notation (idFilm integer not null,
email varchar (40) not null,
note integer not null,
primary key (idFilm, email));
Tous les attributs figurant dans une cl doivent tre dclars not null. Cela na pas vraiment de sens en effet
didentifier des lignes par des valeurs absentes.
Comme nous lavons dj expliqu plusieurs reprises, la mthode recommande pour grer la cl primaire est duti-
liser un attribut id, sans aucune signification particulire autre que celle de contenir la valeur unique identifiant une
ligne. Voici un exemple typique :
create table Artiste (id integer not null,
nom varchar (30) not null,
anneeNaiss integer,
primary key (id))
La valeur de cet identifiant peut mme est automatiquement engendre chaque insertion, ce qui soulage davoir
implanter un mcanisme de gnration didentifiant. La mthode varie dun systme lautre, et repose de manire
gnrale sur la notion de squence. Voici la syntaxe MySQL pour indiquer quune cl est auto-incrmente.
create table Artiste (id integer not null auto increment,

...,
primary key (id))
Lutilisation dun identifiant artificiel napporte rien pour le contrle des redondances. Il est possible dinsrer des
centaines de lignes dans la table Artiste ci-dessus ayant toutes exactement les mmes valeurs, et ne diffrant que par
la cl.
Les contraintes empchant la redondance (et plus gnralement assurant la cohrence dune base) sont spcifies
indpendamment de la cl par la clause unique. On peut par exemple indiquer que deux artistes distincts ne peuvent
avoir les mmes nom et prnom.
create table Artiste (idArtiste integer not null auto increment,

nom varchar (30) not null,
anneeNaiss integer,
primary key (idArtiste),
unique (nom, prenom))

Il est facile de supprimer cette contrainte (dite de cl secondaire) par la suite. Ce serait beaucoup plus difficile si on
avait utilis la paire (nom, prenom) comme cl primaire puisquelle serait alors utilise pour rfrencer un artiste
dans dautres tables.
La clause unique ne sapplique pas aux valeurs null.
3.3.4 Cls trangres
SQL permet dindiquer quelles sont les cls trangres dans une table, autrement dit, quels sont les attributs qui font
rfrence une ligne dans une autre table. On peut spcifier les cls trangres avec loption foreign key.
create table Film (idFilm integer not null,
titre varchar (50) not null,
annee integer not null,
idRealisateur integer not null,
genre varchar (20) not null,
resume varchar(255),
codePays varchar (4),
primary key (idFilm),
foreign key (idRealisateur) references Artiste,
foreign key (codePays) references Pays);
La commande
indique que idRealisateur rfrence la cl primaire de la table Artiste. Le SGBD vrifiera alors, pour toute
modification pouvant affecter le lien entre les deux tables, que la valeur de idRealisateur correspond bien une
ligne de Artiste. Ces modifications sont :
linsertion dans Film avec une valeur inconnue pour idRealisateur ;
la destruction dun artiste ;
la modification de id dans Artiste ou de idRealisateur dans Film.
En dautres termes on a la garantie que le lien entre Film et Artiste est toujours valide. Cette contrainte est importante
pour sassurer quil ny a pas de fausse rfrence dans la base, par exemple quun film ne fait pas rfrence un
artiste qui nexiste pas. Il est beaucoup plus confortable dcrire une application par la suite quand on sait que les
informations sont bien l o elles doivent tre.
Il faut noter que lattribut codePays nest pas dclar not null, ce qui signifie que lon sautorise ne pas connatre
le pays de production dun film. Quand un attribut est null, la contrainte dintgrit rfrentielle ne sapplique pas.
En revanche, on impose de connatre le ralisateur dun film. Cest une contrainte forte, qui dun ct amliore la
richesse et la cohrence de la base, mais de lautre empche toute insertion, mme provisoire, dun film dont le
metteur en scne est inconnu. Ces deux situations correspondent respectivement aux associations 0..* et 1..* dans la
modlisation entit/association.
Note : On peut facilement passer un attribut de not null null. Linverse nest pas vrai sil existe dj des
valeurs null dans la base.
Que se passe-t-il quand la violation dune contrainte dintgrit est dtecte par le systme ? Par dfaut, la mise jour
est rejete, mais il est possible de demander la rpercussion de cette mise jour de manire ce que la contrainte soit
respecte. Les vnements que lon peut rpercuter sont la modification ou la destruction de la ligne rfrence, et on
les dsigne par on update et on delete respectivement. La rpercussion elle-mme consiste soit mettre la cl
trangre null (option set null), soit appliquer la mme opration aux lignes de lentit composante (option
cascade).
Voici comment on indique que la destruction dun pays dclenche la mise null de la cl trangre codePays pour
tous les films de ce pays.


annee integer not null,
idRealisateur integer not null,
genre varchar (20) not null,
foreign key (codePays) references Pays
on delete set null)
Dans le cas dune entit faible, on dcide en gnral de dtruire le composant quand on dtruit le compos. Par
exemple, quand on dtruit un cinma, on veut galement dtruire les salles ; quand on modifie la cl dun cinma, on
veut rpercuter la modification sur ses salles. Dans ce cas cest loption cascade qui simpose.
create table Salle (idCinema integer not null,
no integer not null,
capacite integer not null,
primary key (idCinema, noSalle),
foreign key (idCinema) references Cinema
on delete cascade,
on update cascade)
Lattribut idCinema fait partie de la cl et ne peut donc pas tre null. On ne pourrait donc pas spcifier ici on
delete set null.
La spcification des actions on delete et on update simplifie la gestion de la base par la suite : on na plus par
exemple se soucier de dtruire les salles quand on dtruit un cinma.
3.3.5 La clause check
La clause check exprime des contraintes portant soit sur un attribut, soit sur une ligne. La condition elle-mme
peut tre toute expression suivant la clause where dans une requte SQL. Les contraintes les plus courantes sont
celles consistant restreindre un attribut un ensemble de valeurs, comme expliqu ci-dessous. On peut trouver des
contraintes arbitrairement complexes, faisant rfrence dautres tables. Nous reviendrons sur cet aspect aprs avoir
tudi le langage dinterrogation SQL.
Voici un exemple simple qui restreint les valeurs possibles des attributs annee et genre dans la table Film.
annee integer not null
check (annee between 1890 and 2063) not null,
idRealisateur integer,
genre varchar (20) not null
check (genre in (Histoire,Western,Drame)),
foreign key (idRealisateur) references Artiste
on delete set null,
foreign key (codePays) references Pays)
Au moment dune insertion dans la table Film, ou dune modification de lattribut annee ou genre, le SGBD vrifie
que la valeur insre dans genre appartient lensemble numr dfini par la clause check.

Une autre manire de dfinir, dans la base, lensemble des valeurs autorises pour un attribut en dautres termes,
une codification impose consiste placer ces valeurs dans une table et la lier lattribut par une contrainte de cl
trangre. Cest ce que nous pouvons faire par exemple pour la table Pays.
create table Pays (code varchar(4) not null,
nom varchar (30) default Inconnu not null,
langue varchar (30) not null,
primary key (code));
insert into Pays (code, nom, langue) values (FR, France, Franais);
insert into Pays (code, nom, langue) values (USA, Etats Unis, Anglais);
insert into Pays (code, nom, langue) values (IT, Italie, Italien);
insert into Pays (code, nom, langue) values (GB, Royaume-Uni, Anglais);
insert into Pays (code, nom, langue) values (DE, Allemagne, Allemand);
insert into Pays (code, nom, langue) values (JP, Japon, Japonais);
Si on ne fait pas de vrification automatique, soit avec check, soit avec la commande foreign key, il faut faire
cette vrification dans lapplication, ce qui est plus lourd grer.
3.3.6 Modification du schma
La cration dun schma nest quune premire tape dans la vie dune base de donnes. On est toujours amen par
la suite crer de nouvelles tables, ajouter des attributs ou en modifier la dfinition. La forme gnrale de la
commande permettant de modifier une table est :
alter table <nomTable> <action> <description>
o action peut tre principalement add, modify, drop ou rename et description est la commande de
modification associe action. La modification dune table peut poser des problmes si elle est incompatible avec
le contenu existant. Par exemple passer un attribut not null implique que cet attribut a dj des valeurs pour
toutes les lignes de la table.
Modification des attributs
Voici quelques exemples dajout et de modification dattributs. On peut ajouter un attribut region la table Inter-
naute avec la commande :
alter table Internaute add region varchar(10)
Sil existe dj des donnes dans la table, la valeur sera null ou la valeur par dfaut. La taille
de regiontant certainement insuffisante, on peut lagrandir avec modify, et
la dclarer not null par la mme occasion :
alter table Internaute modify region varchar(30) not null
Il est galement possible de diminuer la taille dune colonne, avec le risque dune perte dinformation pour les donnes
existantes. On peut mme changer son type, pour passer par exemple de varchar integer, avec un rsultat
imprvisible.
La commande alter table permet dajouter une valeur par dfaut.
alter table Internaute add region set default PACA
Enfin, on peut dtruire un attribut avec drop.

alter table Internaute drop region

3.3.7 Cration dindex
Pour complter le schma dune table, on peut dfinir des index. Un index offre un chemin daccs aux lignes dune
table qui est considrablement plus rapide que le balayage de cette table du moins quand le nombre de lignes est trs
lev. Les SGBD crent systmatiquement un index sur la cl primaire de chaque table. Il y a deux raisons cela ;
lindex permet de vrifier rapidement, au moment dune insertion, que la cl nexiste pas dj ;
beaucoup de requtes SQL, notamment celles qui impliquent plusieurs tables (jointure), se basent sur les cls des
tables pour reconstruire les liens. Lindex peut alors tre utilis pour amliorer les temps de rponse.
Un index est galement cr pour chaque clause unique utilise dans la cration de la table. On peut de plus crer
dautres index, sur un ou plusieurs attributs, si lapplication utilise des critres de recherche autres que les cls primaire
ou secondaires.
La commande pour crer un index est la suivante :
create [unique] index <nomIndex> on <nomTable> (<attribut1> [, ...])
Loption unique indique quon ne peut pas trouver deux fois la mme cl dans lindex. La commande ci-dessous
cre un index de nom idxNom sur les attributs nom et prenomde la table *Artiste*. Cet index a
donc une fonction quivalente la clause unique dj utilise dans la cration de la table.
create unique index idxNom on Artiste (nom, prenom)
On peut crer un index, cette fois non unique, sur lattribut genre de la table Film.
create index idxGenre on Film (genre)
Cet index permettra dexcuter trs rapidement des requtes SQL ayant comme critre de recherche le genre dun film.
select * from Film where genre = Western
Cela dit il ne faut pas crer des index tort et travers, car ils ont un impact ngatif sur les commandes dinsertion et
de destruction. chaque fois, il faut en effet mettre jour tous les index portant sur la table, ce qui reprsente un cot
certain.
Pour en savoir plus sur les index, et en gnral sur la gestion de lorganisation des donnes, je vous renvoie la seconde
partie du cours disponible http ://sys.bdpedia.fr.


CHAPITRE 4
Lalgbre relationnelle
Le premier langage tudi dans ce cours est lalgbre relationnelle. Elle consiste en un ensemble doprations qui
permettent de manipuler des relations, considres comme des ensembles de nuplets : on peut ainsi faire lunion ou la
diffrence de deux relations, slectionner une partie de la relation, effectuer des produits cartsiens ou des projections,
etc.
Une proprit fondamentale de chaque opration est quelle prend une ou deux relations en entre, et produit une
relation en sortie. Cette proprit (dite de clture) permet de composer des oprations : on peut appliquer une slection
au rsultat dun produit cartsien, puis une projection au rsultat de la slection et ainsi de suite. En fait on peut
construire des expressions algbriques arbitrairement complexes qui permettent deffectuer des manipulations sur un
grand nombre de relations laide dun petit nombre doprations de base.
Une requte est une expression algbrique qui sapplique un ensemble de relations (la base de donnes) et produit
une relation finale (le rsultat de la requte). On peut voir lalgbre relationnelle comme un langage de programmation
trs simple qui permet dexprimer des requtes sur une base de donnes relationnelle. Les requtes du langage SQL
peuvent se transposer en expressions algbriques, ce qui nous donnera un moyen dinterprter leur signification dune
part, et de comprendre comment les excuter dautre part.
Dans tout ce chapitre on va prendre lexemple de la (petite) base de donnes dun organisme de voyage. Cet organisme
propose des sjours (sportifs, culturels, etc) se droulant dans des stations de vacances. Chaque station propose un
ensemble dactivits (ski, voile, tourisme). Enfin on maintient une liste des clients et des sjours auxquels ils ont
particip avec leurs semaines de dbut et de fin.
Voici le schma de la base. Les cls primaires sont en gras, les cls trangres en italiques.
Station (id, nom, capacit, lieu, rgion, tarif)
Activit (idStation, libell, prix)
Client (id, nom, prnom, ville, rgion, solde)
Sjour (id, idClient, idStation, dbut, fin, nbPlaces)
La table Station
Voici le contenu de la table Station. La cl est un code synthtisant le nom de la station.
id nom capacit lieu rgion tarif
va Venusa 350 Guadeloupe Antilles 1200
fa Farniente 200 Seychelles Ocan Indien 1500
sa Santalba 150 Martinique Antilles 2000
pa Passac 400 Alpes Europe 1000
La table Activit
Cette table contient les activits proposes par les stations. La cl est la paire consitue de (idStation,
libell).
41
idStation libell prix

va Voile 150
va Plonge 120
fa Plonge 130
pa Ski 200
pa Piscine 20
La table des clients
Les clients sont identifis par un numro squentiel incrment de 10 en 10.
id nom prnom ville rgion solde
10 Fogg Phileas Londres Europe 12465
20 Pascal Blaise Paris Europe 6763
30 Kerouac Jack New York Amrique 9812
La table des sjours
Les sjours sont identifis par un numro squentiel incrment par units. Le dbut et la fin sont des numros de
semaine dans lanne.
id idClient idStation dbut fin nbPlaces
1 10 Passac 20 20 2
2 30 Santalba 21 21 5
3 20 Santalba 21 22 4
4 30 Passac 2 3 3
5 30 Venusa 19 23 3
6 20 Venusa 23 23 6
7 30 Farniente 22 24 5
8 10 Farniente 23 25 3
Nous allons dcouvrir comme appliquer des oprations de lalgbre aux relations de cette base, afin de construire une
nouvelle relation. Exprimer une requte, cest simplement construire une expression combinant plusieurs oprations
afin dobtenir une relation reprsentant le rsultat cherch.
4.1 Les oprateurs de lalgbre
Lalgbre se compose dun ensemble doprateurs, parmi lesquels 5 sont ncessaires et suffisants et permettent de
dfinir les autres par composition. Ce sont :
La slection, dnote ;
La projection, dnote ;
Le produit cartsien, dnot ;
Lunion, ;
La diffrence, .
Les deux premiers sont des oprateurs unaires (ils prennent en entre une seule relation) et les autres sont des opra-
teurs binaires. partir de ces oprateurs il est possible den dfinir dautres, et notamment la jointure, o
n, qui est la
composition dun produit cartsien et dune slection.
Ces oprateurs sont maintenant prsents tour tour.
4.1.1 La slection,
La slection () sapplique une relation, , et extrait de cette relation les nuplets qui satisfont un critre de
slection, . Ce critre peut tre :
La comparaison entre un attribut de la relation, , et une constante . Cette comparaison scrit , o appar-
tient {=, <, >, , }.
42 Chapitre 4. Lalgbre relationnelle

La comparaison entre deux attributs 1 et 2 , qui scrit 1 2 avec les mmes oprateurs de comparaison que
prcdemment.
Premier exemple : exprimer la requte qui donne toutes les stations aux Antilles.
= ()
On obtient donc le rsultat :

id nom capacit lieu rgion tarif
va Venusa 350 Guadeloupe Antilles 1200
sa Santalba 150 Martinique Antilles 2000
La slection a pour effet de supprimer des lignes, mais chaque ligne garde lensemble de ses attributs.
4.1.2 La projection,
La projection 1 ,2 ,..., () sapplique une relation , et construit une relation contenant toutes les lignes de ,
dans lesquelles seuls les attributs 1 , 2 , . . . sont conservs. Donc, contrairement la slection, on ne supprime
pas des lignes mais des colonnes. Par exemple : on veut le nom des stations, et leur rgion.
, ()
On obtient le rsultat suivant, aprs suppression des colonnes capacit, lieu et tarif} :
nom rgion
Venusa Antilles
Farniente Ocan Indien
Santalba Antilles
Passac Europe
On pourrait sattendre ce que le nombre de lignes dans le rsultat soit le mme que dans la relation initiale. Cest
presque le cas, avec cependant une petite subtilit. Comme le rsultat est une relation, il ne peut pas y avoir deux lignes
identiques (il ny a pas deux fois le mme lment dans un ensemble). Il peut arriver quaprs une projection, deux
lignes qui taient distinctes initialement se retrouvent identiques, justement parce ce que lattribut qui permettait de
les distinguer a t supprim. Dans ce cas on ne conserve quune seule des deux (ou plus) lignes identiques.
Exemple : on souhaite connatre toutes les rgions o il y a des stations. On exprime cette requte par :
()
et on obtient :
rgion
Antilles
Ocan Indien
Europe
La ligne Antilles tait prsente deux fois dans la relation Station, et napparat plus quen un seul exemplaire dans le
rsultat.
4.1.3 Le produit cartsien,
Le premier oprateur binaire, et le plus utilis, est le produit cartsien, . Le produit cartsien entre deux relations
et se note , et permet de crer une nouvelle relation o chaque nuplet de est associ chaque nuplet de .
Voici deux relations, la premire, , contient
A B
a b
x y
4.1. Les oprateurs de lalgbre 43

et la seconde, , contient :
C D
c d
u v
x y
Et voici le rsultat de :
A B C D
a b c d
a b u v
a b x y
x y c d
x y u v
x y x y
Le nombre de lignes dans le rsultat est exactement || || (|| dnote le nombre de lignes dans la relation ).
En lui-mme, le produit cartsien ne prsente pas un grand intrt puisquil associe aveuglment chaque ligne de
chaque ligne de . Il ne prend vraiment son sens quassoci lopration de slection, ce qui permet dexprimer des
jointures, opration fondamentale qui sera dtaille plus loin.
4.1.4 Renommage
Quand les schmas des relations et sont compltement distincts, il ny a pas dambiguit sur la provenance des
colonnes dans le rsultat. Par exemple on sait que les valeurs de la colonne dans viennent de la relation . Il
peut arriver (il arrive de fait trs souvent) que les deux relations aient des attributs qui ont le mme nom. On doit alors
se donner les moyens de distinguer lorigine des colonnes dans la table rsultat en donnant un nom distinct chaque
attribut.
Voici par exemple une table qui a les mmes noms dattributs que .
A B
m n
o p
Le schma du rsultat du produit cartsien a pour schma (, , , ) et prsente donc des ambiguits, avec
les colonnes et B en double.
La premire solution pour lever lambiguit est dadopter une convention par laquelle chaque attribut est prfix par
le nom de la table do il provient. Le rsultat de devient alors :
R.A R.B T.A T.B
a b m n
a b n p
x y m n
x y n p
Cette convention pose quelques problmes quand on cre des expressions complexes. Il existe une seconde possibilit,
plus rigoureuse, pour rsoudre les conflits de noms : le renommage. Il sagit dun oprateur particulier, dnot , qui
permet de renommer un ou plusieurs attributs dune relation. Lexpression , ( ) permet ainsi de renommer
en et en dans la relation T. Le produit cartsien
, ( )
ne prsente alors plus dambiguits. Le renommage est une solution trs gnrale, mais asez lourde utiliser

Il est tout fait possible de faire le produit cartsien dune relation avec elle-mme. Dans ce cas le renommage o
lutilisation dun prfixe distinctif est impratif. Voici par exemple le rsultat de , dans lequel on prfixe par 1
et 2 respectivement les attributs venant de chacune des oprandes.
R1.A R1.B R1.A R2.B
a b a b
a b x y
x y a b
x y x y
4.1.5 Lunion,
Il existe deux autres oprateurs binaires, qui sont la fois plus simples et moins frquemment utiliss.
Le premier est lunion. Lexpression cre une relation comprenant tous les nuplets existant dans lune ou lautre
des relations et . Il existe une condition imprative : les deux relations doivent avoir le mme schma, cest--dire
mme nombre dattributs, mmes noms et mmes types.
Lunion des relations (, ) et (, ) donnes en exemple ci-dessus est donc interdite (on ne saurait pas comment
nommer les attributs dans le rsultat). En revanche, en posant = , (), il devient possible de calculer
, avec le rsultat suivant :
A B
a b
x y
c d
u v
Comme pour la projection, il faut penser viter les doublons. Donc le nuplet (x,y) qui existe la fois dans et
dans ne figure quune seule fois dans le rsultat.
4.1.6 La diffrence,
Comme lunion, la diffrence sapplique deux relations qui ont le mme schma. Lexpression a alors pour
rsultat tous les nuplets de qui ne sont pas dans .
Voici la diffrence de et , les deux relations tant dfinies comme prcdemment.
A B
a b
La diffrence est le seul oprateur qui permet dexprimer des requtes comportant une ngation (on veut rejeter
quelque chose, on ne veut pas des lignes ayant telle proprit). Il sagit dune fonctionnalit importante et difficile
manier : elle sera dtaille plus loin.
4.1.7 Jointure, o
n
Toutes les requtes exprimables avec lalgbre relationnelle peuvent se construire avec les 5 oprateurs prsents
ci-dessus. En principe, on pourrait donc sen contenter. En pratique, il existe dautres oprations, trs couramment
utilises, qui peuvent se contruire par composition des oprations de base. La plus importante est la jointure.
Afin de comprendre lintrt de cet oprateur, regardons le produit cartsien Station Activit.
4.1. Les oprateurs de lalgbre 45

id nom capacit lieu rgion tarif idStation libell prix

va Venusa 350 Guadeloupe Antilles 1200 va Voile 150
va Venusa 350 Guadeloupe Antilles 1200 va Plonge 120
va Venusa 350 Guadeloupe Antilles 1200 fa Plonge 130
va Venusa 350 Guadeloupe Antilles 1200 pa Ski 200
va Venusa 350 Guadeloupe Antilles 1200 pa Piscine 20
fa Farniente 200 Seychelles Ocan Indien 1500 va Voile 150
fa Farniente 200 Seychelles Ocan Indien 1500 va Plonge 120
fa Farniente 200 Seychelles Ocan Indien 1500 fa Plonge 130
fa Farniente 200 Seychelles Ocan Indien 1500 pa Ski 200
fa Farniente 200 Seychelles Ocan Indien 1500 pa Piscine 20
sa Santalba 150 Martinique Antilles 2000 va Voile 150
sa Santalba 150 Martinique Antilles 2000 va Plonge 120
sa Santalba 150 Martinique Antilles 2000 fa Plonge 130
sa Santalba 150 Martinique Antilles 2000 pa Ski 200
sa Santalba 150 Martinique Antilles 2000 pa Piscine 20
pa Passac 400 Alpes Europe 1000 va Voile 150
pa Passac 400 Alpes Europe 1000 va Plonge 120
pa Passac 400 Alpes Europe 1000 fa Plonge 130
pa Passac 400 Alpes Europe 1000 pa Ski 200
pa Passac 400 Alpes Europe 1000 pa Piscine 20
Le rsultat comprend manifestement un grand nombre de lignes qui ne nous intressent pas. Cela ne prsente pas
beaucoup de sens de rapprocher des informations sur Santalba, aux Antilles et sur lactivit de ski Passac.
Si, en revanche, on considre le produit cartsien comme un rsultat intermdiaire, on voit quil permet de se ramener
au cas on on effectue, par une simple slection, des rapprochements de lignes distinctes. Sur notre exemple, en consi-
drant la table ci-dessus comme une table de la base, on rapproche les informations gnrales sur une station et la liste
des activits de cette station.
La slection qui effectue une rapprochement pertinent est la suivante :
= (Station Activit)
Prenez bien le temps de mditer cette opration de slection : nous ne voulons conserver que les lignes de Station
Activit pour lesquelles lidentifiant de la station (provenant de Station) est identique celui provenant de Activit. En
regardant le produit cartsien ci-dessous, vous devriez pouvoir vous convaincre que cela revient conserver les lignes
qui ont un sens : chacune contient des informations sur une station et sur une activit dans cette mme station. Si vous
saisissez cette logique, vous avez fait un grand pas dans la connaissance des bases relationelles : consacrez-y le temps
de rflexion ncessaire.
On obtient le rsultat ci-dessous.
id nom capacit lieu rgion tarif idStation libell prix
va Venusa 350 Guadeloupe Antilles 1200 va Voile 150
va Venusa 350 Guadeloupe Antilles 1200 va Plonge 120
fa Farniente 200 Seychelles Ocan Indien 1500 fa Plonge 130
pa Passac 400 Alpes Europe 1000 pa Ski 200
pa Passac 400 Alpes Europe 1000 pa Piscine 20
On a donc effectu une composition de deux oprations (un produit cartsien, une slection) afin de rapprocher des
informations rparties dans plusieurs tables, mais ayant des liens entre elles (toutes les informations dans un nuplet du
rsultat sont relatives une seule station). Cette opration est une jointure, que lon peut directement, et simplement,
noter :
Station o
nid=idStation Activit
La jointure consiste donc rapprocher les lignes de deux relations pour lesquelles les valeurs dun (ou plusieurs)
attributs sont identiques. De fait, dans la plupart des cas, ces attributs communs sont (1) la cl primaire de lune des

relations et (2) la cl trangre dans lautre relation. Dans lexemple ci-dessus, cest le cas pour id (cl primaire de Sta-
tion) et idStation (cl trangre dans Activit). La jointure permet alors de reconstruire lassociation conceptuelle
entre Station et Activit.
Note : La station Santalba, qui ne propose pas dactivit, napparat pas dans le rsultat de la jointure. Cest normal
et conforme la dfinition que nous avons donne, mais peut parfois apparatre comme une contrainte. Nous verrons
que SQL propose une variante, la jointure externe, qui permet de la contourner.
La notation de la jointure, o n , est un racourci pour ( ). Le critre de rapprochement, , peut tre

nimporte quelle opration de comparaison liant un attribut de un attribut de . En pratique, on emploie peu les =
ou < qui sont difficiles interprter, et on effectue des galits.
Note : Si on nexprime pas de critre de rapprochement, la jointure est quivalente un produit cartsien.
Il faut tre attentif aux ambiguits dans le nommage des attributs qui peut survenir dans la jointure au mme titre que
dans le produit cartsien. Les solutions employer sont les mmes : on prfixe par le nom de la relation ou par un
synonyme clair, ou bien on renomme des attributs avant deffectuer la jointure.
4.2 Expression de requtes avec lalgbre
Cette section est consacre lexpression de requtes algbriques complexes impliquant plusieurs oprateurs. On
utilise la composition des oprations, rendue possible par le fait que tout oprateur produit en sortie une relation sur
laquelle on peut appliquer nouveau des oprateurs.
4.2.1 Slection gnralise
Regardons dabord comment on peut gnraliser les critres de slection de loprateur . Jusqu prsent on a vu
comment slectionner des lignes satisfaisant un critre de slection, par exemple : les stations aux Antilles. Mainte-
nant supposons que lon veuille retrouver les stations qui sont aux Antilles et dont la capacit est suprieure 200. On
peut exprimer cette requte par une composition :
>200 (= ())
Ce qui revient pouvoir exprimer une slection avec une conjonction de critres. La requte prcdente est donc
quivalente celle ci-dessous, o le dnote le et.
>200= ()
La composition de plusieurs slections revient exprimer une conjonction de critres de recherche. De mme la
composition de la slection et de lunion permet dexprimer la disjonction. Voici la requte qui recherche les stations
qui sont aux Antilles, ou dont la capacit est suprieure 200.
>200 () = ()
Ce qui permet de sautoriser la syntaxe suivante, o le dnote le ou.
>200 = ()
Enfin la diffrence permet dexprimer la ngation et dliminer des lignes. Par exemple, voici la requte qui slec-
tionne les stations dont la capacit est suprieure 200 mais qui ne sont pas aux Antilles.
>200 () = ()
4.2. Expression de requtes avec lalgbre 47

Cette requte est quivalente une slection o on sautorise loprateur = :
>200= ()
Important : Attention avec les requtes comprenant une ngation, dont linterprtation est parfois subtile. Dune
manire gnrale, lutilisation du = nest pas quivalente lutilisation de la diffrence. Voir la prochaine section.
En rsum, les oprateurs dunion et de diffrence permettent de dfinir une slection o le critre est une
expression boolenne quelconque. Attention cependant : si toute slection avec un ou peut sexprimer par une union,
linverse nest pas vrai (exercice).
4.2.2 Requtes conjonctives
Les requtes dites conjonctives constituent lessentiel des requtes courantes. Intuitivement, il sagit de toutes les
recherches qui sexpriment avec des et, par opposition celles qui impliquent des ou ou des not. Dans lalgbre,
ces requtes sont toutes celles qui peuvent scrire avec seulement trois oprateurs : , , (et donc, indirectement,
n).
o
Les plus simples sont celles o on nutilise que et . En voici quelques exemples.
Nom des stations aux Antilles :
(= ())
Id des stations o lon pratique la voile.
(= ())
Nom et prnom des clients europens
, (= ())
Des requtes lgrement plus complexes - et extrmement utiles - sont celles qui impliquent la jointure. On doit
utiliser la jointure ds que les attributs ncessaires pour valuer une requte sont rparties dans au moins deux tables.
Ces attributs ncessaires peuvent tre :
Soit des attributs qui figurent dans le rsultat ;
Soit des attributs sur lesquels on exprime un critre de slection.
Considrons par exemple la requte suivante : Donner le nom et la rgion des stations o lon pratique la voile.
Une analyse trs simple suffit pour constater que lon a besoin des attributs rgion et nom qui apparassent dans la
relation Station, et de libell qui apparat dans Activit.
Donc il faut faire une jointure, de manire rapprocher les lignes de Station et de Activit. Il reste donc dterminer
le (ou les) attribut(s) sur lesquels se fait ce rapprochement. Ici, comme dans la plupart des cas, la jointure permet de
recalculer lassociation entre les relations Station et Activit. Elle seffectue donc par appariement de la cl primaire
dune part (dans Station), de la cl trangre dautre part.
, ( o
n= = (Activit))
En pratique, la grande majorit des oprations de jointure seffectue sur des attributs qui sont cl primaire dans une
relation, et cl secondaire dans lautre. Il ne sagit pas dune rgle absolue, mais elle rsulte du fait que la jointure
permet le plus souvent de reconstituer le lien entre des informations qui sont naturellement associes (comme une
station et ses activits, ou une station et ses clients), mais qui ont t rparties dans plusieurs relations au moment de la
modlisation logique de la base. Cette reconstitution sappuie sur le mcanisme de cl trangre qui a t tudi dans
le chapitre consacr la conception.
Voici quelques autres exemples qui illustrent cet tat de fait :
Nom des clients qui sont alls Passac :
( o n= = (Sjour))
Quelles rgions a visit le client 30 :
(=30 () o n= ())

Nom des clients qui ont eu loccasion de faire de la voile :

( on= ( o n= = ()))
La dernire requte comprend deux jointures, portant chaque fois sur des cls primaires et/ou trangres. Encore
une fois ce sont les cls qui dfinissent les liens entre les relations, et elle servent donc naturellement de support
lexpression des requtes.
Voici maintenant un exemple qui montre que cette rgle nest pas systmatique. On veut exprimer la requte qui
recherche les noms des clients qui sont partis en vacances dans leur rgion, ainsi que le nom de cette rgion.
Ici on a besoin des informations rparties dans les relations Station, Sjour et Client. Voici lexpression algbrique :
,. ( o
n== ( o
n= ))
Les jointures avec la table Sjour se font sur les couples (cl primaire, cl trangre), mais on a en plus un critre de
rapprochement relatif lattribut rgion de Client et de Station.
Note : Dans la projection finale, on utilise la notation client.region pour viter toute ambiguit.
4.2.3 Requtes avec et
Pour finir, voici quelques exemples de requtes impliquant les deux oprateurs et . Leur utilisation est moins
frquente, mais elle peut savrer absolument ncessaire puisque ni lun ni lautre ne peuvent sexprimer laide
des trois oprateurs conjonctifs tudis prcdemment. En particulier, la diffrence permet dexprimer toutes les
requtes o figure une ngation : on veut slectionner des donnes qui ne satisfont pas telle proprit, ou tous les
untels sauf les x et les y, etc.
Illlustration concrte sur la base de donnes avec la requte suivante : quelles sont les identifiants des stations qui ne
proposent pas de voile ?
() (= ())
Comme le suggre cet exemple, la dmarche gnrale pour construire une requte du type Tous les qui ne satisfont
pas la proprit est la suivante :
Construire une premire requte qui slectionne tous les .
Construire une deuxime requte : : qui satisfont :math :p.
Finalement, faire .
Les requtes et peuvent bien entendu tre arbitrairement complexes et mettre en oeuvre des jointures, des slec-
tions, etc. La seule contrainte est que le rsultat de et de comprenne le mme nombre dattributs.
Important : Attention ne pas considrer que lutilisation du comparateur = est quivalent la diffrence. La requte
suivante par exemple ne donne pas les stations qui ne proposent pas de voile
( = ())
Pas convaincu(e) ? Rflchissez un peu plus, faites le calcul concret. Cest lun de piges viter.
Voici quelques exemples complmentaires qui illustrent ce principe.

Rgions o il y a des clients, mais pas de station.
() ()
Identifiant des stations qui nont pas reu de client amricain.
() ( o
n= = ())
Id des clients qui ne sont pas alls aux Antilles.
() (= () o
n= )
La dernire requte construit lensemble des idClient pour les clients qui ne sont pas alls aux Antilles. Pour
obtenir le nom de ces clients, il suffit dajouter une jointure (exercice).
4.2. Expression de requtes avec lalgbre 49

4.2.4 Complment dun ensemble
La diffrence peut tre employe pour calculer le complment dun ensemble. Prenons lexemple suivant : on veut les
ids des clients et les stations o ils ne sont pas alls. En dautres termes, parmi toutes les associations Client/Station
possibles, on veut justement celles qui ne sont pas reprsentes dans la base !
Cest un des rares cas o le produit cartsien seul est utile : il permet justement de constituer toutes les associations
possibles. Il reste ensuite en soustraire celles qui sont dans la base avec loprateur .
( () ()) , ()
4.2.5 Quantification universelle
Enfin la diffrence est ncessaire pour les requtes qui font appel la quantification universelle : celles o lon de-
mande par exemple quune proprit soit toujours vraie. A priori, on ne voit pas pourquoi la diffrence peut tre utile
dans de tels cas. Cela rsulte simplement de lquivalence suivante : une proprit est vraie pour tous les lments
dun ensemble si et seulement si il nexiste pas un lment de cet ensemble pour lequel la proprit est fausse. La
quantification universelle sexprime par une double ngation.
En pratique, on se ramne toujours la seconde forme pour exprimer des requtes. Prenons un exemple : quelles sont
les stations dont toutes les activits ont un prix suprieur 100 ? On lexprime galement par quelles sont stations
pour lesquelles il nexiste pas dactivit avec un prix infrieur 100. Ce qui donne lexpression suivante :
() (<100 ())
Pour finir, voici une des requtes les plus complexes, la division. Lnonc (en franais) est simple, mais lexpression
algbrique ne lest pas du tout. Lexemple est le suivant : on veut les ids des clients qui sont alls dans toutes les
stations.
Traduit avec (double) ngation, cela donne : les ids des clients tels quil nexiste pas de station o ils ne soient pas
alls. Ce qui donne lexpression algbrique suivante :
() (( () ()) , ())
On rutilise lexpression donnant les clients et les stations o ils ne sont pas alls (voir plus haut) :
() ()) , ()
On obtient un ensemble . Il reste prendre tous les clients, sauf ceux qui sont dans .
()
Ce type de requte est rare (heureusement) mais illustre la capacit de lalgbre exprimer par de simples manipula-
tions ensemblistes des oprations complexes.

CHAPITRE 5
SQL
Le langage SQL est loutil standard pour effectuer des recherches ou mises jour dans une base de donnes relation-
nelle. Ce chapitre est consacr la partie Langage de Manipulation de Donnes (LMD) complmentaire de la partie
Langage de Dfinition de Donnes (LDD) prsente prcdemment.
SQL est un langage relativement facile dans la mesure o il ne permet que des oprations assez limites : manipuler
plusieurs tables en entre (celles de la base) pour obtenir une table en sortie (le rsultat). La seule vritable difficult
rside dans linterprtation des requtes complexes qui font parfois appel des logiques sophistiques. Par ailleurs
la multiplicit des variantes syntaxiques offre de nombreuses manires dexprimer la mme interrogation ce qui peut
parfois troubler. Nous avons donc choisi dinsister sur la signification des oprations SQL et sur la dmarche de
conception dune requte.
Nous utilisons le schma de la base Immeuble du chapitre prcdent et linstance de base donne ci-dessous. Ce
schma et cette base sont fournis respectivement dans les scripts SchemaImmeuble.sql et BaseImmeuble.sql sur notre
site si vous souhaitez effectuer rellement les requtes proposes paralllement votre lecture.
La table Immeuble
Voici le contenu de la table Immeuble.
id nom adresse
1 Koudalou 3 Rue Blanche
2 Barabas 2 Alle Nikos
La table Appart
Voici le contenu de la table Appart.
id no surface tage id_immeuble
100 1 150 14 1
101 34 50 15 1
102 51 200 2 1
103 52 50 5 1
201 1 250 1 2
202 2 250 2 2
La table Personne
Voici le contenu de la table Personne.
id prnom nom profession id_appart
1 Ross Informaticien 202
2 Alice Black Cadre 103
3 Rachel Verte Stagiaire 100
4 William Dupont Acteur 102
5 Doug Ramut Rentier 201
51
La table Possede
Voici le contenu de la table Possede.
id_personne id_appart quote_part
1 100 33
5 100 67
1 101 100
5 102 100
1 202 100
5 201 100
2 103 100
5.1 Principes de SQL
Nous commenons par un abrg dinterprtation des requtes SQL qui va nous guider pendant tout ce chapitre. Il
existe quelques principes gnraux qui sappliquent quelle que soit la complexit de la requte et auxquels il est trs
utile de pouvoir se ramener en prsence dun cas complexe.
5.1.1 Forme de base et interprtation
La recherche seffectue avec la commande select dont la forme de base est :

select liste_expressions
from source
[where liste_conditions]
Lordre des trois clauses select from et where est trompeur pour la signification dune requte. En fait lintepr-
tation seffectue toujours de la manire suivante :
la clause from dfinit lespace de recherche en fonction dun ensemble de sources de donnes : cet espace a toujours
conceptuellement la forme dune table relationnelle que nous appellerons Tfrom ;
la clause where exprime un ensemble de conditions sur les lignes de la table Tfrom : seules les lignes pour lesquelles
ces conditions sont satisfaites sont conserves ;
enfin la clause select consiste en une liste dexpressions appliques chaque ligne de Tfrom ayant pass le filtre
du where.
Nous vous conseillons de revenir toujours la dfinition ci-dessus quand vous avez un problme avec vos requtes
SQL. Elle permet de rendre compte uniformment de leur signification de la requte la plus simple la plus complexe.
Le sens de lecture from where select facilite la conception et linterprtation. Voyons tout de suite concrtement
comme elle sapplique une requte trs simple.
select nom adresse from Immeuble where id=1
Cette requte renvoie le rsultat suivant.

nom adresse
Koudalou 3 Rue Blanche
Lespace de recherche est ici constitu dune seule table de la base Immeuble. Il sagit du cas le plus simple et le plus
courant. On value ensuite pour toutes les lignes de cette table les conditions exprimes dans le where : seules les
lignes (une seule en loccurrence) pour lesquelles lattribut id vaut 1 satisfont cette condition. Finalement on extrait
de cette ligne les valeurs des attributs nom et adresse.
52 Chapitre 5. SQL
5.1.2 Lespace de recherche : clause from
Lespace de recherche est dfini dans la clause from par une table ou une combinaison de plusieurs tables. Par table
il ne faut pas ici comprendre forcment une des tables de la base courante mme si cest le cas le plus souvent
rencontr. SQL est beaucoup gnral que cela : une table dans un from peut galement tre rsultat dune autre
requte. On parlera de table base et de table calcule pour distinguer ces deux cas. Ce peut galement tre une table
stocke dans une autre base ou une table calcule partir de tables bases dans plusieurs bases ou une combinaison de
tout cela.
La premire requte effectue ci-dessus ramne les immeubles dont lid vaut 1. Il naura pas chapp au lecteur attentif
que le rsultat est lui-mme une table calcule. Pourquoi ne pourrait-on pas interroger cette table calcule comme une
autre ? Cest possible en SQL comme le montre lexemple suivant :
select *
from (select nom adresse from Immeuble where id=1) as Koudalou
On a donc plac une requte SQL dans le from o elle dfinit un espace de recherche constitu de son propre rsultat.
Le mot-cl as permet de donner un nom temporaire au rsultat. En dautres termes Koudalou est le nom de la table
calcule sur laquelle seffectue la requte. Cette table temporaire nexiste que pendant lexcution.
On peut aller un peu plus loin et donner dfinivement un nom cette requte qui slectionne limmeuble. En SQL
cela sappelle une vue. On cre une vue dans un schma avec la commande create view (les vues sont traites en
dtail plus loin). Par exemple :
create view Koudalou as

select nom adresse from Immeuble where id=1
Une fois cre une vue peut tre utilise comme espace de recherche exactement comme une table base. Le fait que
son contenu soit calcul reste transparent pour lutilisateur.
select nom adresse from Koudalou
nom adresse
Koudalou 3 Rue Blanche
Encore une fois, linterprtation du from est indpendante de lorigine des tables : tables bases, tables calcules, et
vues.
Note : On peut galement interroger les tables ou vues dune autre base pourvu que lutilisateur connect ait les droits
suffisants. Dans ce cas on prfixe le nom de la table par le nom de la base.
Venons-en maintenant au cas o le from est dfini par plusieurs tables. Dans un tel cas les contenus des tables sont
toujours combines de manire dfinir une table virtuelle (le Tfrom voqu prcdemment) qui tient lieu despace de
recherche par la suite. La combinaison la plus simple de deux tables A et B, obtenue en sparant les noms des tables
par une virgule, consiste effectuer toutes les associations possibles dune ligne de A et dune ligne de B. Voici par
exemple ce que cela donne pour les tables Immeuble et Appart.
select * from Immeuble, Appart
Laffichage ci-dessus nous montre quel est lespace de recherche Tfrom considr quand on place ces deux tables dans
un from.
5.1. Principes de SQL 53

id nom adresse id surface etage id_immeuble no

1 Koudalou 3 Rue Blanche 100 150 14 1 1
2 Barabas 2 Alle Nikos 100 150 14 1 1
La virgule est en fait un synonyme de cross join, terme qui indique que lon effectue un produit cartsien (cross
product) des deux tables vues comme des ensembles. Reportez-vous au chapitre Lalgbre relationnelle (page 41)
pour des explications dtailles. La requte donnant le mme rsultat est donc :
select * from Immeuble cross join Appart
Dautre types de combinaisons plus restrictives et souvent plus utiles sont les jointures. Regardons nouveau le rsultat
prcdent. Le fait dassocier chaque ligne de Immeuble chaque ligne de Appart nous donne des rsultats peu utiles
priori. La seconde ligne associe par exemple le Barabas un appartement du Koudalou. On ne voit pas quelle
application peut trouver intrt un tel regroupement. En revanche, associer un appartement limmeuble o il se
situe est trs utile (ne serait-ce que pour trouver son adresse).
Un peu de rflexion suffit pour se convaincre que les lignes intressantes dans le rsultat du produit cartsien sont celles
pour lesquelles lattribut id provenant de la table Immeuble est gal lattribut id_immeuble provenant de Appart.
Un tel produit cartsien restreint est une jointure dans la terminologie du modle relationnel. Une combinaison de
deux tables par jointure doit indiquer quelles sont les conditions dassociation de deux lignes. En SQL on lexprime
avec la syntaxe suivante :
table1 join table2 on (conditions)
Donc on peut effectuer la jointure dans la clause from. On obtient un espace de recherche constitu des paires de
lignes pour lesquelles la condition de jointure est vraie.
select *
from Immeuble join Appart on (Immeuble.id=Appart.id_immeuble)

id nom adresse id surface etage id_immeuble no
Les jointures seront revues plus loin. Comment souvent en SQL il existe plusieurs moyens de les exprimer, la plus
utilise consistant effectuer un produit cartsien (virgules dans le from) suivi de conditions de jointures exprimes
dans le where.
Ce quil faut retenir : le from consiste dfinir un espace de recherche qui est constitu par combinaison dune ou
plusieurs tables bases ou calcules provenant du mme schma ou dun autre schma. Quel que soit le cas cet espace
est lui-mme une table (calcule) dont on va chercher extraire une ou plusieurs lignes (par le where) puis une ou
plusieurs colonnes (par le select).
54 Chapitre 5. SQL
Beaucoup de difficults dinterprtation proviennent dune mauvaise comprhension de lespace dans lequel on
cherche les donnes. La premire tape pour les rsoudre consiste se poser correctement la question : que signi-
fie le from de ma requte.
5.1.3 Les conditions : la clause where
La clause where permet dexprimer des conditions portant sur les lignes de la table dfinie par la clause from. Ces
conditions prennent la forme classique de tests combins par les connecteurs boolens classiques and, or et not. Les
rgles de priorit sont exprimes par des parenthses. Voici quelques exemples simples de requtes avec leur rsultat.
select * from Appart where surface > 50
id surface etage id_immeuble no

100 150 14 1 1
102 200 2 1 51
201 250 1 2 1
202 250 2 2 2
select * from Appart
where surface > 50
and etage > 3

100 150 14 1 1
where (surface > 50 and etage > 3)
or id_immeuble=2

100 150 14 1 1
201 250 1 2 1
202 250 2 2 2
Il est galement possible dexprimer des conditions sur des tables calcules par dautre requtes SQL incluses dans la
clause where et habituellement dsignes par le terme de requtes imbriques. On pourra par exemple demander la
liste des personnes dont lappartement fait partie de la table calcule des appartements situs au-dessus du troisime
tage.
select * from Personne
where id_appart in (select id from Appart where etage < 3)
id prenom nom profession id_appart

1 null Ross Informaticien 202
Avec les requtes imbriques on entre dans le monde incertain des requtes qui semblent claires mais finissent par ne
plus ltre du tout. La difficult vient souvent du fait quil faut raisonner simultanment sur plusieurs requtes qui, de
plus, sont souvent interdpendantes (les donnes slectionnes dans lune servent de paramtre lautre). Il est trs
souvent possible dviter les requtes imbriques comme nous lexpliquons dans ce chapitre.
5.1.4 Les expressions : la clause select
Finalement, une fois obtenues les lignes du from qui satisfont le where on cre partir de ces lignes le rsultat
final avec les expressions du select. Le terme expression dsigne ici, comme dans tout langage, une construction
5.1. Principes de SQL 55

syntaxique qui prend une ou plusieurs valeurs en entre et produit une valeur en sortie. Dans sa forme la plus simple,
une expression est simplement un nom dattribut ou une constante comme dans lexemple suivant.
select surface etage 18 as Euros/m2
from Appart
surface etage Euros/m2

150 14 18
50 15 18
200 2 18
50 5 18
250 1 18
250 2 18
Les attributs surface et etage proviennent de Appart alors que 18 est une constante qui sera rpte autant de
fois quil y a de lignes dans le rsultat. De plus, on peut donner un nom cette colonne avec la commande as. Voici
un second exemple qui montre une expression plus complexe. Lutilisateur (certainement un agent immobilier avis
et connaissant bien SQL) calcule le loyer dun appartement en fonction dune savante formule qui fait intervenir la
surface et ltage.
select no, surface, etage,
(surface * 18) * (1 (0.03 * etage)) as loyer
from Appart
no surface etage loyer

1 150 14 3834.00
34 50 15 1305.00
51 200 2 3816.00
52 50 5 1035.00
1 250 1 4635.00
2 250 2 4770.00
SQL fournit de trs nombreux oprateurs et fonctions de toute sorte qui sont clairement numres dans la documen-
tation de chaque systme. Elles sont particulirement utiles pour des types de donnes un peu dlicat manipuler
comme les dates.
Une extension rarement utilise consiste effectuer des tests sur la valeur des attributs lintrieur de la clause
select avec lexpression case dont la syntaxe est :
case
when test then expression
[when ...]
else expression
end
Ces tests peuvent tre utiliss par exemple pour effectuer un dcodage des valeurs quand celles-ci sont difficiles
interprter ou quand on souhaite leur donner une signification drive. La requte ci-dessous classe les appartements
en trois catgories selon la surface.
select no etage surface
case when surface <= 50 then Petit
when surface > 50 and surface <= 100 then Moyen
else Grand
end as categorie
from Appart
56 Chapitre 5. SQL
no etage surface catgorie

1 14 150 Grand
34 15 50 Petit
51 2 200 Grand
52 5 50 Petit
65 12 70 Moyen
65 12 70 Moyen
1 1 250 Grand
2 2 250 Grand
Voici donc tout ce quil faut savoir sur linterprtation des requtes SQL exprimes plat, sans requte imbrique.
Nous reprenons maintenant la prsentation du langage en apportant des prcisions sur chaque partie.
5.2 Recherche avec SQL
La recherche la plus simple consiste rcuprer le contenu complet dune table. On nutilise pas la clause where et
le * dsigne tous les attributs.
select * from Immeuble
id nom adresse
2 Barabas 2 Alle Nikos
5.2.1 Construction dexpressions
Si on indique explicitement les attributs au lieu dutiliser *, leur nombre dtermine le nombre de colonnes de la table
calcule. Le nom de chaque attribut dans cette table est par dfaut lexpression du select mais on peut indiquer
explicitement ce nom avec as. Voici un exemple qui illustre galement une fonction assez utile, la concatnation de
chanes.
select prenom || nom as Prenom et nom

from Personne
Prenom et nom
null
Alice Black
Rachel Verte
William Dupont
Doug Ramut
Le rsultat montre que lune des valeurs est null. Le null en SQL correspond labsence de valeur. Logiquement
toute opration applique un null renvoie un null en sortie puisquon ne peut calculer aucun rsultat partir
dune valeur inconnue. Ici cest le prnom de lune des personnes qui manque. La concatnation du prnom avec le
nom est une opration qui propage cette valeur null.
5.2.2 La clause where
Les conditions de la clause where suivent en gnral la syntaxe expr1 [not] expr2, o expr1 et expr2
sont deux expressions construites partir de noms dattributs de constantes et des fonctions et est lun des oprateurs
de comparaison classique < > <= >= !=.
5.2. Recherche avec SQL 57

Les conditions se combinent avec les connecteurs boolens and or et not. SQL propose galement un prdicat in
qui teste lappartenance dune valeur un ensemble. Il sagit (du moins tant quon nutilise pas les requtes imbriques)
dune facilit dcriture pour remplacer le or. La requte
select *
from Personne
where profession=Acteur
or profession=Rentier
scrit de manire quivalente avec un in comme suit :

select *
from Personne
where profession in (Acteur, Rentier)

Pour les chanes de caractres, SQL propose loprateur de comparaison like, avec deux caractres de substitution :
le % remplace nimporte quelle sous-chane ;
le _ remplace nimporte quel caractre.
Lexpression _ou%ou est donc interprte par le like comme toute chane commenant par un caractre suivi de
ou suivi de nimporte quelle chane suivie une nouvelle fois de ou.
select *
from Immeuble
where nom like _ou%ou
id nom adresse
5.2.3 Valeurs nulles
Il est impossible de dterminer quoi que ce soit partir dune valeur null. Nous avons vu que toute opration
applique un null renvoie null. Dans le cas des comparaisons, la prsence dun null renvoie un rsultat qui
nest ni true ni false mais unknown, une valeur boolenne intermdiaire. Reprenons nouveau la table Personne
avec un des prnoms null. La requte suivante devrait ramener toutes les lignes.
select *
from Personne
where prenom like %
Mais la prsence dun null empche linclusion de la ligne correspondante dans le rsultat.
Cependant la condition like na pas t value false comme le montre la requte suivante.
select *
from Personne
where prenom not like %
58 Chapitre 5. SQL
On obtient un rsultat vide, ce qui montre bien que le like appliqu un null ne renvoie pas false (car sinon on
aurait not false = true). Cest dailleurs tout fait normal puisquil ny a aucune raison de dire quune absence
de valeur ressemble nimporte quelle chane.
Les tables de vrit de la logique trivalue de SQL sont dfinies de la manire suivante. Tout dabord on affecte une
valeur aux trois constantes logiques :
true vaut 1
false vaut 0
unknown vaut 0.5
Les connecteurs boolens sinterprtent alors ainsi :
val1 and val2 = max(val1 val2)
val1 or val2 = min(val1 val2)
not val1 = 1 - val1.
On peut vrifier notamment que not unknown vaut toujours unknown. Ces dfinitions sont claires et cohrentes.
Cela tant il faut mieux prvenir de mauvaises surprises avec les valeurs null, soit en les interdisant la cration
de la table avec les options not null ou default, soit en utilisant le test is null (ou son complment is not
null). La requte ci-dessous ramne toutes les lignes de la table, mme en prsence de null.
select *
from Personne
where prenom like %
or prenom is null

1 null Ross Informaticien 202
Attention le test valeur = null na pas de sens. On ne peut pas tre gal une absence de valeur.
5.2.4 Tri et limination de doublons
SQL renvoie les lignes du rsultat sans se soucier de la prsence de doublons. Si on cherche par exemple les surfaces
des appartements avec
select surface
from Appart
on obtient le rsultat suivant.

surface
150
50
200
50
250
250
On a autant de fois une valeur quil y a de lignes dans le rsultat intermdiaire aprs excution des clauses from et
where. En gnral, on ne souhaite pas conserver ces lignes identiques dont la rptition napporte aucune information.
Le mot-cl distinct plac juste aprs le select permet dliminer ces doublons.
select distinct surface

from Appart
5.2. Recherche avec SQL 59

surface
150
50
200
250
Le distinct est viter quand cest possible car llimination des doublons peut entraner des calculs coteux. Il
faut commencer par calculer entirement le rsultat, puis le trier ou construire une table de hachage, et enfin utiliser
la structure temporaire obtenue pour trouver les doublons et les liminer. Si le rsultat est de petite taille cela ne pose
pas de problme. Sinon, on risque de constater une grande diffrence de temps de rponse entre une requte sans
distinct et la mme avec distinct.
On peut demander explicitement le tri du rsultat sur une ou plusieurs expressions avec la clause order by qui
vient toujours la fin dune requte select. La requte suivante trie les appartements par surface puis, pour ceux de
surface identique, par ltage.
select *
from Appart
order by surface etage

103 50 5 1 52
101 50 15 1 34
100 150 14 1 1
102 200 2 1 51
201 250 1 2 1
202 250 2 2 2
Par dfaut, le tri est en ordre ascendant. On peut inverser lordre de tri dun attribut avec le mot-cl desc .
select *
from Appart
order by surface desc, etage desc

202 250 2 2 2
201 250 1 2 1
102 200 2 1 51
100 150 14 1 1
101 50 15 1 34
103 50 5 1 52
Bien entendu, on peut trier sur des expressions au lieu de trier sur de simples noms dattribut.
5.3 Jointures
La jointure est une opration indisoensable ds que lon souhaite combiner des donnes rparties dans plusieurs tables.
la base de la jointure, on trouve le produit cartsien qui consiste trouver toutes les associations possibles dune
ligne de la premire table avec une ligne de la seconde. La jointure consiste restreindre le rsultat du produit cartsien
en ne conservant que les associations qui sont intressantes pour la requte.
Il existe beaucoup de manires diffrentes dexprimer les jointures en SQL. Pour les dbutants, il est recommand de
se limiter la forme de base donne ci-dessous qui est plus facile interprter et se gnralise un nombre de tables
quelconques.
60 Chapitre 5. SQL
5.3.1 Syntaxe classique
La mthode la plus courante consiste effectuer un produit cartsien dans le from puis liminer les lignes inutiles
avec le where
Important : Attention, nous parlons ici de la manire dont on conoit la requte pas de lvaluation par le systme
qui essaiera en gnral dviter le calcul complet du produit cartsien.
Prenons lexemple dune requte cherchant la surface et ltage de lappartement de M. William Dupont. On doit
associer deux tables. La premire est une table calcule contenant les informations sur William Dupont. On lobtient
par la requte suivante.
select *
from Personne
where prenom=William
and nom=Dupont

La seconde table est lensemble des appartements. Lassociation des deux tables par un produit cartsien consiste
simplement les placer toutes les deux dans le from.
select p.id, nom, prenom, id_appart, a.id, surface, etage
from Personne as p, Appart as a
where prenom=William and nom=Dupont
Ce qui donne le rsultat suivant :

id nom prenom id_appart id surface etage
4 Dupont William 102 100 150 14
Une premire difficult rsoudre quand on utilise plusieurs tables est la possibilit davoir des attributs de mme
nom dans lunion des schmas, ce qui soulve des ambiguits dans les clauses where et select. On rsout cette
ambiguit en prfixant les attributs par le nom des tables dont ils proviennent. Ici, on a mme simplifi lcriture en
donnant des alias aux nom des tables avec le mot-cl as. La table Personne et la table Appart sont donc respectivement
rfrences par p et a.
Notez que la leve de lambiguit en prfixant par le nom ou lalias de la table nest ncessaire que pour les attributs
qui apparaissent en double soit ici id qui peut dsigner lidentifiant de la personne ou celui de lappartement.
On na plac aucun critre de filtrage pour lassociation des lignes provenant des deux tables. William Dupont est
donc associ toutes les lignes de la table Appart. La jointure consiste ajouter une condition complmentaire dans le
where exprimant le fait que lappartement auquel on sintresse (dsign par sa cl a.id) est celui o habite William
Dupont (dsign par la cl trangre id_appart). Le rsultat de la requte prcdente montre bien que la seule ligne
qui nous intresse est celle o ces deux attributs ont la mme valeur. Do la requte donnant le bon rsultat :
select p.id, p.nom, p.prenom, p.id_appart, a.id, a.surface, a.etage
from Personne as p Appart as a
and nom=Dupont
and a.id = p.id_appart
5.3. Jointures 61
id nom prenom id_appart id surface etage

Comme dans la trs grande majorit des cas la jointure consiste exprimer une galit entre la cl primaire de lune
des tables et la cl trangre correspondante de lautre. Un peu de rflexion permet de raliser que lon recre ainsi le
lien dfini au niveau du modle entitassociation. Mais SQL est plus puissant que cette reconstitution puisquon peut
exprimer des conditions de jointure sur nimporte quel attribut et pas seulement sur ceux qui sont des cls.
Imaginons que lon veuille trouver les appartements dun mme immeuble qui ont la mme surface. On veut associer
une ligne de Appart une autre ligne de Appart avec les conditions suivantes :
elles sont dans le mme immeuble (attribut id_immeuble) ;
elles ont la mme valeur pour lattribut surface ;
elles correspondent des appartements distincts (attributs id).
La requte exprimant ces conditions est donc :
select a1.id, a1.surface, a1.etage, a2.id, a2.surface, a2.etage
from Appart a1 Appart a2
where a1.id != a2.id
and a1.surface = a2.surface
and a1.id_immeuble = a2.id_immeuble
Ce qui donne le rsultat suivant :

id surface etage id surface etage
101 50 15 103 50 5
103 50 5 101 50 15
201 250 1 202 250 2
202 250 2 201 250 1
On peut noter que dans le rsultat la mme paire apparat deux fois avec des ordres inverss. On peut liminer cette
redondance en remplaant a1.id != a2.id par a1.id < a2.id.
Les alias a1 et a2 jouent le rle de curseurs qui rfrencent, un moment donn, deux lignes de la table Appart.
Ces deux lignes sont associes et incluses dans le rsultat si la condition du where est satisfaite.
Voici quelques exemples complmentaires de jointures impliquant parfois plus de deux tables exprimes par produit
cartsien, puis restriction avec where.
Qui habite un appartement de plus de 200 m2 ?
select prenom, nom, profession
from Personne, Appart
where id_appart = Appart.id
and surface >= 200
Attention lever lambiguit sur les noms dattributs quand ils peuvent provenir de
deux tables (cest le cas ici pour id).
Qui habite le Barabas ?
select prenom, p.nom, no, surface, etage
from Personne as p, Appart as a, Immeuble as i
where p.id_appart=a.id
and a.id_immeuble=i.id
and i.nom=Barabas
Qui habite un appartement quil possde et avec quelle quote-part ?
62 Chapitre 5. SQL
select prenom, nom, quote_part

from Personne as p, Possede as p2, Appart as a
where p.id=p2.id_personne /* p est propritaire */
and p2.id_appart=a.id /* de lappartement a */
and p.id_appart=a.id /* et il y habite */
De quel(s) appartement(s) Alice Black est-elle propritaire et dans quel immeuble ?
Voici la requte sur les quatre tables avec des commentaires inclus montrant les jointures.
select i.nom, no, etage, surface
from Personne as p, Appart as a, Immeuble as i, Possede as p2
where p.id=p2.id_personne /* Jointure PersonnePossede */
and p2.id_appart = a.id /* Jointure PossedeAppart */
and a.id_immeuble= i.id /* Jointure AppartImmeuble */
and p.nom=Black and p.prenom=Alice
Attention lever lambiguit sur les noms dattributs quand ils peuvent provenir de deux tables (cest
le cas ici pour id).
La jointure classique plat o toutes les tables sont places dans le from et associes par produit cartsien est une
manire tout fait recommandable de procder surtout pour les dbutants SQL. Elle permet de se ramener toujours la
mme mthode dinterprtation et consolide la comprhension des principes dinterrogation dune base relationnelle.
Toutes ces jointures peuvent sexprimer avec dautres syntaxes : tables calcules dans le from oprateur de jointure
dans le from ou (pas toujours) requtes imbriques. lexception notable des jointures externes et des requtes
imbriques avec ngation, elles napportent aucune expressivit supplmentaire. Toutes ces variantes constituent des
moyens plus ou moins commodes dexprimer diffremment la jointure.
5.3.2 Tables calcules dans le from
La possibilit de placer des requtes dans le from est prise en compte depuis peu de temps par les SGBD relationnels.
Cette option napporte rien en terme dexpressivit mais elle peut (question de got) parfois tre considre comme
plus claire ou plus proche du raisonnement intuitif. Elle ne sert que dans les cas o il existe un critre de slection sur
une table. En revanche les conditions de jointure restent dans le where.
Nous reprenons quelques exemples de requtes que nous avons dj rsolues avec des jointures plat.
Quel est lappartement o habite M. William Dupont ?
select no, surface, etage
from Appart, (select id_appart from Personne
and nom=Dupont) as Dupont
where id=id_appart
no surface etage
51 200 2
Un (lger) avantage est de supprimer dans la table calcule les attributs qui soulvent des ambiguits (par exemple
lid de la personne qui ne sert rien par la suite). Il faut toujours donner un alias avec le mot-cl as la table
calcule.
from Personne as p, (select id from Appart where surface>=200) as a
Dernier exemple montrant la possibilit deffectuer une jointure pour obtenir la table calcule.
5.3. Jointures 63
select prenom, nom, no, surface, etage

from Personne p, (select Appart.id, no, surface, etage
from Appart, Immeuble
where id_immeuble=Immeuble.id
and nom=Barabas) as a
5.3.3 Oprateurs de jointure
La virgule sparant deux tables dans un from exprime un produit cartsien : toutes les combinaisons de lignes sont
considres puis soumises aux conditions du where. Comme nous lavons vu il sagit dun moyen deffectuer la
jointure. Mais SQL propose galement des oprateurs de jointure dans le from avec la syntaxe suivante : table1
oprateur table2 [condition]
Les oprateurs disponibles sont :
cross join le produit cartsien synonyme de la virgule ;
join la jointure accompagne de conditions ;
straight join jointure forant lordre daccs aux tables (dconseill : mieux vaut laisser faire le systme) ;
left [outer] join et right [outer] join : jointures externes ;
natural [left,right [outer]] join : jointure naturelle.
Le seul oprateur qui nest pas redondant avec des syntaxes prsentes prcdemment est la jointure externe (outer).
On peut bon droit considrer que cette multiplication de variantes syntaxiques ne fait que compliquer le langage.
Nous prsentons dans ce qui suit les oprateurs join et outer join. La jointure naturelle est une variante possible
quand la cl primaire et la cl trangre ont le mme nom.
Loprateur join permet dexprimer directement dans le from les conditions de jointure. Il est trs proche dans sa
conception des jointures plat tudies prcdemment. Quelques exemples reprenant des requtes dj exprimes
suffiront pour comprendre le mcanisme.
Quel est lappartement o habite M. William Dupont ?
select no, surface, etage
from Personne join Appart on (Personne.id_appart=Appart.id)
Il suffit de comparer avec la version combinant produit cartsien et where pour se rendre compte que la diffrence
est minime. On peut tout fait considrer que la version avec join est plus claire.
from Personne as p join Appart as a
on (id_appart=a.id and surface>=200)
Cet exemple illustre un dtournement de la condition de jointure. On y a inclus une condition de slection (la
surface suprieure 200). La requte est correcte mais il est possible que la mthode dvaluation ne soit pas
optimale.
Il faut souligner (nous y reviendrons) que ces variantes alternatives reprsentent un dfi pour le module charg
doptimiser lvaluation des requtes. Un avantage potentiel des jointures plat o tout est exprim dans le where
est quelles offrent une forme canonique partir de laquelle un optimiseur peut travailler avec un maximum de
libert.
On peut composer deux oprateurs de jointure comme le montre ce dernier exemple.
select prenom, p.nom, no, surface, etage
from Personne p join (Appart a join Immeuble i
on id_immeuble=i.id)
on (id_appart=a.id)
where i.nom=Barabas
64 Chapitre 5. SQL
Contrairement aux jointures exprimes avec join, les jointures externes ne peuvent pas sexprimer avec un where.
Quest-ce quune jointure externe ? Effectuons la requte qui affiche tous les appartements avec leur occupant.
select id_immeuble, no, etage, surface, nom, prenom
from Appart as a join Personne as p on (p.id_appart=a.id)
Voici ce que lon obtient :

id_immeuble no etage surface nom prenom
2 2 2 250 Ross null
1 52 5 50 Black Alice
1 1 14 150 Verte Rachel
1 51 2 200 Dupont William
2 1 1 250 Ramut Doug
Il manque un appartement le 34 du Koudalou. En effet cet appartement na pas doccupant. Il ny a donc aucune
possibilit que la condition de jointure soit satisfaite.
La jointure externe permet dviter cette limination parfois indsirable. On considre alors une hirarchie entre les
deux tables. La premire table (en gnral celle de gauche) est dite directrice et toutes ses lignes, mme celle qui ne
trouvent pas de correspondant dans la table de droite, seront prises en compte. Les lignes de la table de droite sont en
revanche optionnelle.
Si pour une ligne de la table de gauche on trouve une ligne satisfaisant le critre de jointure dans la table de droite,
alors la jointure seffectue normalement. Sinon, les attributs provenant de la table de droite sont affichs null. Voici
la jointure externe entre Appart et Personne. Le mot-cl outer est optionnel.
select id_immeuble, no etage, surface, nom, prenom
from Appart as a left outer join Personne as p on (p.id_appart=a.id)
id_immeuble no etage surface nom prenom

1 1 14 150 Verte Rachel
1 34 15 50 null null
1 51 2 200 Dupont William
1 52 5 50 Black Alice
2 1 1 250 Ramut Doug
2 2 2 250 Ross null
Notez les deux attributs prenom et nom null pour lappartement 34.
Il existe un right outer join qui prend la table de droite comme table directrice. On peut combiner la jointure
externe avec des jointures normales des slections des tris etc. Voici la requte qui affiche le nom de limmeuble en
plus des informations prcdentes et trie par numro dimmeuble et numro dappartement.
select i.nom, no, etage, surface, p.nom, prenom
from Immeuble as i
join
(Appart as a left outer join Personne as p
on (p.id_appart=a.id))
on (i.id=a.id_immeuble)
order by i.id, a.no
5.3.4 Oprations ensemblistes
La norme SQL ANSI comprend des oprations qui considrent les tables comme des ensembles et effectuent des
intersections des unions ou des diffrences avec les mots-cl union, intersect ou except. Chaque oprateur
sapplique deux tables de schma identique (mme nombre dattributs mmes noms mmes types).
5.3. Jointures 65
Lunion est un oprateur peu utilis car il est difficile de trouver des cas o son application est justifie. Voici un
exemple montrant le calcul de lunion des noms dimmeuble et des noms de personne.
select nom from Immeuble
union
select nom from Personne
Le except exprime la diffrence entre deux ensembles. Il est avantageusement remplac par lutilisation des requtes
imbriques et des not in et not exists prsents ci-dessous.
5.3.5 Requtes imbriques
Les requtes peuvent tre imbriques les unes dans les autres de deux manires :
dans la clause from : la requte est place entre parenthses et son rsultat est vu comme une table ;
dans la clause where avec loprateur in qui permet de tester lappartenance de la valeur dun attribut un
ensemble calcul par une requte.
Reprenons lexemple de la requte trouvant la surface et ltage de lappartement de M. Dupont. On peut lexprimer
avec une requte imbrique de deux manires :
select surface, etage
from Appart (select id_appart
from Personne
where prenom=William and nom=Dupont) as ri
where Appart.id = ri.id_appart
select surface, etage from Appart

where id in (select id_appart
from Personne
where prenom=William and nom=Dupont)
Le mot-cl in exprime la condition dappartenance de lidentifiant de lappartement lensemble didentifiants consti-

tu avec la requte imbrique. Il doit y avoir correspondance entre le nombre et le type des attributs auxquels sapplique
la comparaison par in. Lexemple suivant montre une comparaison entre des paires dattributs (ici on cherche des in-
formations sur les propritaires).
select prenom, nom, surface, etage
from Appart as a join Personne as p on (a.id=p.id_appart)
where (p.id p.id_appart)
in (select id_personne id_appart from Possede)
prenom nom surface etage

null Ross 250 2
Alice Black 50 5
Doug Ramut 250 1
Il est bien entendu assez direct de rcrire la requte ci-dessus comme une jointure classique. Parfois lexpression avec
requte imbrique peut savrer plus naturelle. Supposons que lon cherche les immeubles dans lesquels on trouve un
appartement de 50 m2. Voici lexpression avec requte imbrique.
select *
from Immeuble
where id in (select id_immeuble from Appart where surface=50)
id nom adresse
La requte directement rcrite en jointure donne le rsultat suivant :
66 Chapitre 5. SQL
select i.* from Immeuble as i join Appart as a

on (i.id=a.id_immeuble)
where surface=50
id nom adresse
On obtient deux fois le mme immeuble puisquil peut tre associ deux appartements diffrents de 50 m2. Il
suffit dajouter un distinct aprs le select pour rgler le problme, mais on peut considrer que dans ce cas la
requte imbrique est plus approprie. Attention cependant : il nest pas possible dobtenir dans le rsultat des attributs
appartenant aux tables des requtes imbriques.
Le principe gnral des requtes imbriques est dexprimer des conditions sur des tables calcules par des requtes.
Ces conditions sont les suivantes :
exists R : renvoie true si R nest pas vide false sinon.
t in R o est une ligne dont le type (le nombre et le type des attributs) est celui de R : renvoie true si t appartient
R false sinon.
v cmp any R o cmp est un comparateur SQL (< > = etc.) : renvoie true si la comparaison avec au moins une
des lignes de la table R renvoie true.
v cmp all R o cmp est un comparateur SQL (< > = etc.) : renvoie true si la comparaison avec toutes les lignes
de la table R renvoie true.
De plus toutes ces expressions peuvent tre prfixes par not pour obtenir la ngation. La richesse des expressions
possibles permet deffectuer une mme interrogation en choisissant parmi plusieurs syntaxes possibles. En gnral,
tout ce qui nest pas bas sur une ngation not in ou not exists peut sexprimer sans requte imbrique.
Le cas du all correspond une ngation puisque si une proprit est toujours vraie il nexiste pas de cas o elle est
fausse. La requte ci-dessous applique le all pour chercher ltage le plus lev de limmeuble 1.
where id_immeuble=1
and etage >= all (select etage from Appart where id_immeuble=1)
Le all exprime une comparaison qui vaut pour toutes les lignes ramenes par la requte imbrique. Attention aux
valeurs null dans ce genre de situation : toute comparaison avec une de ces valeurs renvoie UNKNOWN et cela peut
entraner lchec du all. Il nexiste pas dexpression avec jointure qui puisse exprimer ce genre de condition.
5.3.6 Requtes correles
Les exemples de requtes imbriques donns prcdemment pouvaient tre valus indpendamment de la requte
principale, ce qui permet au systme (sil le juge ncessaire) dexcuter la requte en deux phases. La clause exists
fournit encore un nouveau moyen dexprimer les requtes vues prcdemment en basant la sous-requte sur une ou
plusieurs valeurs issues de la requte principale. On parle alors de requtes correles.
Voici encore une fois la recherche de lappartement de M. William Dupont exprime avec exists :
where exists (select * from Personne
and Personne.id_appart=Appart.id)
On obtient donc une nouvelle technique dexpression qui permet daborder le critre de recherche sous une troisime
perspective : on conserve un appartement si, pour cet appartement, loccupant sappelle William Dupont. Il sagit
assez visiblement dune jointure mais entre deux tables situes dans des requtes (ou plutt des blocs) distinctes. La
condition de jointure est appele corrlation do le nom de ce type de technique.
5.3. Jointures 67
Toutes les jointures peuvent dexprimer avec exists ou in. Voici quelques exemples reprenant des requtes dj
vues prcdemment.
Avec in :
select prenom nom profession
from Personne
where id_appart in (select id from Appart where surface >= 200)
Avec exists :
select prenom nom profession
from Personne p
where exists (select * from Appart a
where a.id=p.id_appart
and surface >= 200)
Avec in :
select prenom p.nom no surface etage
and a.id_immeuble in
(select id from Immeuble
where nom=Barabas)
Avec exists :
select prenom p.nom no surface etage
and exists (select * from Immeuble i
where i.id=a.id_immeuble
and i.nom=Barabas)
Important : dans une sous-requte associe la clause exists peu importe les attributs du select puisque la
condition se rsume : cette requte ramne-t-elle au moins une ligne ou non ? On peut donc systmatiquement
utiliser select *.
Enfin rien nempche dutiliser plusieurs niveaux dimbrication au prix dune forte dgradation de la lisibilit. Voici
la requte De quel(s) appartement(s) Alice Black est-elle propritaire et dans quel immeuble ? crite avec plusieurs
niveaux.
select i.nom no etage surface
from Immeuble as i Appart as a
where a.id_immeuble= i.id
and a.id in
(select id_appart from Possede
where id_personne in
(select id from Personne
where nom=Black
and prenom=Alice))
En rsum une jointure entre les tables R et S de la forme :

select R.*
from R S
where R.a = S.b
68 Chapitre 5. SQL
peut scrire de manire quivalente avec une requte imbrique :
select [distinct] *
from R
where R.a in (select S.b from S)
ou bien encore sous forme de requte corrle :
select [distinct] *
from R
where exists (select S.b from S where S.b = R.a)
Le choix de la forme est matire de got ou de lisibilit, ces deux critres relevant de considrations essentiellement
subjectives.
5.3.7 Requtes avec ngation
Les requtes imbriques sont en revanche irremplaables pour exprimer des ngations. On utilise alors not in ou
(de manire quivalente) not exists. Voici un premier exemple avec la requte : donner les appartements sans
occupant.
where id not in (select id_appart from Personne)

101 50 15 1 34
La ngation est aussi un moyen dexprimer des requtes courantes comme celle recherchant lappartement le plus lev
de son immeuble. En SQL, on utilisera typiquement une sous-requte pour prendre ltage maximal dun immeuble,
et on utilisera cet tage pour slectionner un ou plusieurs appartements, le tout avec une requte correle pour ne
comparer que des appartements situs dans le mme immeuble.
select *
from Appart as a1
where etage = (select max(etage) from Appart as a2
where a1.id_immeuble=a2.id_immeuble)

101 50 15 1 34
202 250 2 2 2
Il existe en fait beaucoup de manires dexprimer la mme chose. Tout dabord cette requte peut en fait sexprimer
sans la fonction max() avec la ngation : si a est lappartement le plus lev, cest quil nexiste pas dtage plus elev
que a. On utilise alors habituellement une requte dite corrle dans laquelle la sous-requte est base sur une ou
plusieurs valeurs issues des tables de la requte principale.
select *
from Appart as a1
where not exists (select * from Appart as a2
where a2.etage > a1.etage
and a1.id_immeuble = a2.id_immeuble)
Autre manire dexprimer la mme chose : si ltage est le plus lev, tous les autres sont situs un tage infrieur. On
peut utiliser le mot-cl all qui indique que la comparaison est vraie avec tous les lments de lensemble constitu
par la sous-requte.
5.3. Jointures 69
select *
from Appart as a1
where etage >= all (select etage from Appart as a2
where a1.id_immeuble=a2.id_immeuble)
Dernier exemple de ngation : quels sont les personnes qui ne possdent aucun appartement mme partiellement ? Les
deux formulations ci-dessous sont quivalentes, lune sappuyant sur not in, et lautre sur not exists.
select *
from Personne
where id not in (select id_personne from Possede)
select *
from Personne as p1
where not exists (select * from Possede as p2
where p1.id=p2.id_personne)
5.4 Agrgats
Les requtes agrgat en SQL consistent effectuer des regroupements de lignes en fonction des valeurs dune ou
plusieurs expressions. Ce regroupement est spcifi par la clause group by. On obtient une structure qui nest pas
une table relationnelle puisquil sagit dun ensemble de groupes de lignes. On doit ensuite ramener cette structure
une table en appliquant des fonctions de groupes qui dterminent des valeurs agrges calcules pour chaque groupe.
Enfin il est possible dexprimer des conditions sur les valeurs agrges pour ne conserver quun ou plusieurs des
groupes constitus. Ces conditions portent sur des groupes de lignes et ne peuvent donc tre obtenues avec where.
On utilise alors la clause having.
Les agrgats seffectuent toujours sur le rsultat dune requte classique select - from. On peut donc les voir
comme une extension de SQL consistant partitionner un rsultat en groupes selon certains critres, puis exprimer
des conditions sur ces groupes, et enfin appliquer des fonctions dagrgation.
Il existe un groupe par dfaut : cest la table toute entire. Sans mme utiliser group by, on peut appliquer les
fonctions dagrgation au contenu entier de la table comme le montre lexemple suivant.
select count(*), count(prenom), count(nom)
from Personne
Ce qui donne :
count(*) count(prenom) count(nom)
5 4 5
On obtient 5 pour le nombre de lignes, 4 pour le nombre de prnoms, et 5 pour le nombre de noms. En effet, lattribut
prenom est null pour la premire personne et nest en consquence pas pris en compte par la fonction dagrgation.
Pour compter toutes les lignes, on doit utiliser count(*) ou un attribut dclar comme not null. On peut aussi
compter le nombre de valeurs distinctes dans un groupe avec count(distinct <expression>).
5.4.1 La clause group by
Le rle du group by est de partitionner une table (calcule ou base) en fonction dun critre (un attribut ou plus
gnralement une expression sur des attributs). Pour bien analyser ce qui se passe pendant une requte avec group
by on peut dcomposer lexcution dune requte en deux tapes. Prenons lexemple de celle permettant de vrifier
que la somme des quote-part des propritaires est bien gale 100 pour tous les appartements.
70 Chapitre 5. SQL
select id_appart sum(quote_part)

from Possede
group by id_appart
id_appart sum(quote_part)
100 100
101 100
102 100
103 100
201 100
202 100
Dans une premire tape le systme va constituer les groupes. On peut les reprsenter avec un tableau comprenant,
pour chaque ligne, dune part la (ou les) valeur(s) du (ou des) attribut(s) de partitionnement (ici id_appart), dautre
part lensemble de lignes dans lesquelles on trouve cette valeur. Ces lignes imbriques sont spares par des points-
virgule dans la reprsentation ci-dessous.
id_appart Groupe count
100 (id_personne=1 quote_part=33 ; id_personne=5 quote_part=67) 2
101 (id_personne=1 quote_part=100) 1
Le groupe associ lappartement 100 est constitu de deux copropritaires. Le tableau ci-dessus nest donc pas une
table relationnelle dans laquelle chaque cellule ne peut contenir quune seule valeur.
Pour se ramener une table relationnelle, on transforme durant la deuxime tape chaque groupe de lignes en une
valeur par application dune fonction dagrgation. La fonction count() compte le nombre de lignes dans chaque
groupe, max() donne la valeur maximale dun attribut parmi lensemble des lignes du groupe, etc. La liste des
fonctions dagrgation est donne ci-dessous :
count(expression), Compte le nombre de lignes pour lesquelles expression est not null.
avg(expression), Calcule la moyenne de expression.
min(expression), Calcule la valeur minimale de expression.
max(expression), Calcule la valeur maximale de expression.
sum(expression), Calcule la somme de expression.
std(expression), Calcule lcart-type de expression.
Dans la norme SQL lutilisation de fonctions dagrgation pour les attributs qui napparaissent pas dans le group by
est obligatoire. Une requte comme :
select id, surface, max(etage)
from Appart
group by surface
srea rejete parce que le groupe associ une mme surface contient deux appartements diffrents (et donc deux
valeurs diffrentes pour id), et quil ny a pas de raison dafficher lun plutt que lautre.
5.4.2 La clause having
Finalement, on peut faire porter des conditions sur les groupes, ou plus prcisment sur le rsultat de fonctions dagr-
gation appliques des groupes avec la clause having. La clause where ne peut exprimer des conditions que sur les
lignes prises une une. Par exemple, on peut slectionner les appartements pour lesquels on connat au moins deux
copropritaires.
5.4. Agrgats 71
select id_appart, count(*)

from Possede
group by id_appart
having count(*) >= 2
On voit que la condition porte ici sur une proprit de lensemble des lignes du groupe et pas de chaque ligne prise
individuellement. La clause having est donc toujours exprime sur le rsultat de fonctions dagrgation.
Pour conclure, voici une requte slectionnant la surface possde par chaque copropritaire pour limmeuble 1. La
surface possde est la somme des surfaces dappartements possds par un propritaire, pondres par leur quote-part.
On regroupe par propritaire et on trie sur la surface possde.
select prenom nom,
sum(quote_part * surface / 100) as Surface possde
from (Personne as p1 join Possede as p2 on (p1.id=p2.id_personne) )
join Appart as a on (a.id=p2.id_appart)
where id_immeuble = 1
group by p1.id
order by sum(quote_part * surface / 100)

prnom nom Surface possde
Alice Black 50.00000
null Ross 125.00000
Doug Ramut 275.00000
5.5 Mises jour
Les commandes de mise jour (insertion, destruction, modification) sont considrablement plus simples que les inter-
rogations.
5.5.1 Insertion
Linsertion seffectue avec la commande insert, avec trois variantes. Dans la premire on indique la liste des valeurs
insrer sans donner explicitement le nom des attributs. Le systme suppose alors quil y a autant de valeurs que
dattributs, et que lordre des valeurs correspond celui des attributs dans la table. On peut indiquer null pour les
valeurs inconnues.
insert into Immeuble

values (1 Koudalou 3 Rue Blanche)
Si on veut insrer dans une partie seulement des attributs, il faut donner la liste explicitement.
insert into Immeuble (id nom adresse)

values (1 Koudalou 3 Rue Blanche)
Il est dailleurs prfrable de toujours donner la liste des attributs. La description dune table peut changer par ajout
dattribut, et lordre insert qui marchait un jour ne marchera plus le lendemain.
Enfin avec la troisime forme de insert il est possible dinsrer dans une table le rsultat dune requte. Dans ce
cas la partie values est remplace par la requte elle-mme. Voici un exemple avec une nouvelle table Barabas dans
laquelle on insre uniquement les informations sur limmeuble Barabas.
72 Chapitre 5. SQL
create table Barabas (id int not null,

nom varchar(100) not null,
adresse varchar(200),
primary key (id)
)
insert into Barabas

select * from Immeuble where nom=Barabas
5.5.2 Destruction
La destruction seffectue avec la clause delete dont la syntaxe est :

delete from table
where condition
table tant bien entendu le nom de la table, et condition toute condition ou liste de conditions valide pour une
clause where. En dautres termes, si on effectue avant la destruction la requte
select * from table
where condition
on obtient lensemble des lignes qui seront dtruites par delete. Procder de cette manire est un des moyens de
sassurer que lon va bien dtruire ce que lon souhaite.
5.5.3 Modification
La modification seffectue avec la clause update. La syntaxe est proche de celle du delete :
update table set A1=v1, A2=v2, ... An=vn
where condition
Comme prcdemment table est la table, les Ai sont les attributs les vi les nouvelles valeurs, et condition est
toute condition valide pour la clause where.
5.6 Les vues
Une requte SQL produit toujours une table. Cela suggre la possibilit dajouter au schma des tables calcules, qui
ne sont rien dautre que le rsultat de requtes stockes. De telles tables sont nommes des vues dans la terminologie
relationnelle. On peut interroger des vues comme des tables stockes et, dans certaines limites, faire des mises jour
des tables stockes au travers de vues.
Une vue ninduit aucun stockage puisquelle nexiste pas physiquement. Elle permet dobtenir une reprsentation
diffrente des tables sur lesquelles elle est base avec deux grands avantages :
on peut faciliter linterrogation de la base en fournissant sous forme de vues des requtes prdfinies ;
on peut masquer certaines informations en crant des vues et en forant par des droits daccs lutilisateur passer
par ces vues pour accder la base.
Les vues constituent donc un moyen complmentaire de contribuer la scurit (par restriction daccs) et la facilit
dutilisation (en offrant une schma virtuel simplifi).
5.6. Les vues 73

5.6.1 Cration et interrogation dune vue
Une vue est en tout point comparable une table : en particulier on peut linterroger par SQL. La grande diffrence
est quune vue est le rsultat dune requte avec la caractristique essentielle que ce rsultat est rvalu chaque fois
que lon accde la vue. En dautres termes une vue est dynamique : elle donne une reprsentation fidle de la base
au moment de lvaluation de la requte.
Une vue est essentiellement une requte laquelle on a donn un nom. La syntaxe de cration dune vue est trs
simple :
create view nomvue ([listeattributs])

as requete
[with check option]
Nous avons dj vu au dbut de ce chapitre vlexemple dune vue sur la table Immeuble montrant uniquement le
Koudalou. En voici une nouvelle version plus complte avec le nombre dappartements.
create Koudalou as
select nom, adresse, count(*) as nb_apparts
from Immeuble as i join Appart as a on (i.id=a.id_immeuble)
where i.id=1
group by i.id, nom, adresse
La destruction dune vue a videmment beaucoup moins de consquences que pour une table puisquon supprime
uniquement la dfinition de la vue pas son contenu.
On interroge la vue comme nimporte quelle table.
select * from Koudalou
nom adresse nb_apparts

Koudalou 3 Rue Blanche 4
La vue fait maintenant partie du schma. On ne peut dailleurs videmment pas crer une vue avec le mme nom quune
table (ou vue) existante. La dfinition dune vue peut consister en un requte SQL aussi complexe que ncessaire, avec
jointures, regroupements, tris.
Allons un peu plus loin en dfinissant sous forme de vues un accs aux informations de notre base Immeuble, mais
restreint uniquement tout ce qui concerne limmeuble Koudalou. On va en profiter pour offrir dans ces vues un accs
plus facile linformation. La vue sur les appartements, par exemple, va contenir contrairement la table Appart le
nom et ladresse de limmeuble et le nom de son occupant.
create or replace view AppartKoudalou as

select no, surface, etage, i.nom as immeuble, adresse,
p.prenom || p.nom as occupant
from (Immeuble as i join Appart as a on (i.id=a.id_immeuble))
join Personne as p on (a.id=p.id_appart)
where i.id=1
On voit bien sur cet exemple que lun des intrts des vues est de donner une reprsentation dnormalise de la
base en regroupant des informations par des jointures. Le contenu tant virtuel, il ny a ici aucun inconvnient voir
la redondance du nom de limmeuble et de son adresse. Le bnfice, en revanche, est la possibilit dobtenir trs
simplement toutes les informations utiles.
select * from AppartKoudalou
no surface etage immeuble adresse occupant

52 50 5 Koudalou 3 Rue Blanche Alice Black
1 150 14 Koudalou 3 Rue Blanche Rachel Verte
51 200 2 Koudalou 3 Rue Blanche William Dupont
74 Chapitre 5. SQL
Le nom des attributs de la vue est celui des expressions de la requte associe. On peut galement donner ces noms
aprs le create view condition quil y ait correspondance univoque entre un nom et une expression du select.
On peut ensuite donner des droits en lecture sur cette vue pour que cette information limite soit disponible tous.
grant select on Immeuble.Koudalou Immeuble.AppartKoudalou to adminKoudalou
Pour peu que cet utilisateur nait aucun droit de lecture sur les tables de la base Immeuble, on obtient un moyen simple
de masquer et restructurer linformation.
5.6.2 Mise jour dune vue
Lide de modifier une vue peut sembler trange puisquune vue na pas de contenu. En fait il sagit bien entendu de
modifier la table qui sert de support la vue. Il existe de svres restrictions sur les droits dinsrer ou de mettre jour
des tables au travers des vues. Un exemple suffit pour comprendre le problme. Imaginons que lon souhaite insrer
une ligne dans la vue AppartKoudalou.
insert into AppartKoudalou (no, surface, etage, immeuble, adresse, occupant)

values (1, 12, 4, Globe, 2 Avenue Leclerc, Palamde)
Le systme rejettera cette requte (par exemple, pour MySQL, avec le message Can not modify more than
one base table through a join view Immeuble.AppartKoudalou). Cet ordre sadresse une
vue issue de trois tables. Il ny a clairement pas assez dinformation pour alimenter ces tables de manire cohrente
et linsertion nest pas possible (de mme que toute mise jour). De telles vues sont dites non modifiables. Les
rgles dfinissant les vues modifiables sont assez strictes et difficiles rsumer simplement dautant quelles varient
selon lopration (update, delete, ou insert). En premire approximation on peut retenir les points suivants qui
donnent lieu quelques exceptions sur lesquelles nous reviendrons ensuite.
la vue doit tre base sur une seule table ; toute colonne non rfrence dans la vue doit pouvoir tre mise null
ou disposer dune valeur par dfaut ;
on ne peut pas mettre jour un attribut qui rsulte dun calcul ou dune opration.
On ne peut donc pas insrer ou modifier la vue Koudalou cause de la jointure et de lattribut calcul. La requte
suivante serait rejete.
insert into Koudalou (nom, adresse)

values (Globe, 2 Avenue Leclerc)
En revanche une vue portant sur une seule table avec un select * est modifiable.
create view PossedeAlice

as select * from Possede
where id_personne=2
insert into PossedeAlice values (2 100 20)

insert into PossedeAlice values (3 100 20)
Maintenant, si on fait :
select * from PossedeAlice
On obtient :
id_personne id_appart quote_part
2 100 20
2 103 100
Linsertion prcdente illustre une petite subtilit : on peut insrer dans une vue sans tre en mesure de voir la ligne
insre au travers de la vue par la suite ! On a en effet insr dans la vue le propritaire 3 qui est ensuite filtr quand
on interroge la vue.
5.6. Les vues 75

SQL propose loption with check option qui permet de garantir que toute ligne insre dans la vue satisfait les
critres de slection de la vue.
create view PossedeAlice

as select * from Possede
where id_personne=2
with check option
SQL permet galement la modification de vues dfinies par des jointures. Les restrictions sont essentielement les
mme que pour les vues mono-tabulaires : on ne peut insrer que dans une des tables (il faut donc prciser la liste des
attributs) et tous les attributs not null doivent avoir une valeur. Voici un exemple de vue modifiable base sur une
jointure.
create or replace view ToutKoudalou

as select i.id as id_imm, nom, adresse, a.*
from Immeuble as i join Appart as a on (i.id=a.id_immeuble)
where i.id=1
with check option
Il est alors possible dinsrer condition dindiquer des attributs dune seule des deux tables. La commande ci-dessous
ajoute un nouvel appartement au Koudalou.
insert into ToutKoudalou (id, surface, etage, id_immeuble, no)

values (104, 70, 12, 1, 65)
En conclusion, lintrt principal des vues est de permettre une restructuration du schma en vue dinterroger et/ou de
protger des donnes. Lutilisation de vues pour des mises jour devrait rester marginale.
76 Chapitre 5. SQL
CHAPITRE 6
Indices and tables
genindex
modindex
search
77

CBD SQL 1827hdbnn

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CBD SQL 1827hdbnn

Încărcat de

Drepturi de autor:

Formate disponibile

Cours de bases de donnes - Modles

2 Conception dune base de donnes 5

6 Indices and tables 77

Table des matires 1

2 Table des matires

Conception dune base de donnes

2.1 Schma dune base de donnes

2.1.1 Qualit dun schma relationnel

titre anne nomMES prnomMES anneNais

2.1.2 Schmas normaliss

6 Chapitre 2. Conception dune base de donnes

2.1.3 La notion de dpendance fonctionnelle

Dfinition : dpendance fonctionnelle

je peux chercher les dpendances fonctionnelles et trouver celles-ci :

on trouvera la dpendance fonctionnelle suivante :

2.1. Schma dune base de donnes 7

Dfinition : schma normalis

Considrons nouveau notre schma 1 :

2.1.4 La dcomposition dun schma

8 Chapitre 2. Conception dune base de donnes

Est-elle normalise ? Oui car lunique dpendance fonctionnelle est

Ce schma, obtenu par dcompositions successives, prsente la double proprit

2.1. Schma dune base de donnes 9

2.1.5 Une approche pratique

On obtient le rsultat suivant.

10 Chapitre 2. Conception dune base de donnes

2.2 Le modle E/A

2.2. Le modle E/A 11

2.2.1 Le schma de la base Films

F IGURE 2.1 Le schma E/A des films

12 Chapitre 2. Conception dune base de donnes

2.2. Le modle E/A 13

2.2.2 Entits, attributs et identifiants

Note : Certaines mthodes admettent lintroduction de constructions plus complexes :

14 Chapitre 2. Conception dune base de donnes

2.2.3 Types dentits

Dfinition : Type dentit

2.2. Le modle E/A 15

F IGURE 2.2 Reprsentation des types dentit

2.2.4 Associations binaires

F IGURE 2.3 Association entre deux ensembles

16 Chapitre 2. Conception dune base de donnes

F IGURE 2.4 Reprsentation de lassociation

2.2. Le modle E/A 17

F IGURE 2.5 Association (Acteur,Film)

F IGURE 2.6 Association entre Artiste et Film

Dfinition : Cl dune association

18 Chapitre 2. Conception dune base de donnes

F IGURE 2.8 Graphe dune association ternaire

2.2. Le modle E/A 19

2.2.5 Entits faibles

20 Chapitre 2. Conception dune base de donnes

F IGURE 2.10 Modlisations possibles du lien Cinma-Salle

2.2.6 Associations gnralises

Dfinition : associations n-aires

2.2. Le modle E/A 21

F IGURE 2.11 Association ternaire reprsentant les sances

F IGURE 2.12 Graphe dune association ternaire

22 Chapitre 2. Conception dune base de donnes

F IGURE 2.13 Lassociation Sance transforme en entit

Le modle Entit/Association est simple et pratique.

2.2. Le modle E/A 23

24 Chapitre 2. Conception dune base de donnes