Vous êtes sur la page 1sur 205

I n f o r ma t i q u e

Synthse
de cours
exercices
corrigs
&
col l ection
Synt hex
Toutes les tapes de la cration dune base
de donnes, de lanalyse la ralisation
laide du langage SQL
Les mcanismes de prservation et de
scurisation des donnes
Des ressources sur www.pearson.fr :
chiers des donnes et textes des requtes
Nicolas Larrousse
Cration de
bases de donnes
Informatique
&
Cration de bases
de donnes
Nicolas Larrousse
CNRS
Avec la contribution de ric Innocenti
Universit de Corse Pasquale Paoli
collection
Synthex
Synthse
de cours
exercices
corrigs

Tous droits rservs
Composition sous FrameMaker : IDT
Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues l'article L. 122-5 2
et 3 a) du code de la proprit intellectuelle ne peut tre faite sans l'autorisation expresse de Pearson
Education France ou, le cas chant, sans le respect des modalits prvues l'article L. 122-10 dudit code.

ISBN : 978-2-7440-7386-1
ISSN : 1768-7616
2009 Pearson Education France
Sommaire
III Sommaire
Lauteur V
Le relecteur VII
Avant-propos IX
Chapitre 1 Introduction aux bases de donnes 1
1 Quest-ce quune base de donnes ? 2
2 volution des bases de donnes et de leur utilisation 4
3 Systmes de gestion de bases de donnes 13
4 tapes de la conception des bases de donnes 17
5 Mtiers des bases de donnes 19
6 Plan de louvrage 20
7 Prsentation de la BD exemple 20
Exercices 22
Chapitre 2 Analyse du monde rel 27
1 Dmarche danalyse 28
2 Modlisation par le modle entit-association 30
3 Remise en cause et volution du modle 35
4 Reprsentation avec UML 40
Exercices 44
Chapitre 3 Approche relationnelle 55
1 Concepts 56
2 Oprations du modle relationnel 60
3 Passage du modle conceptuel au relationnel 68
4 Normalisation 70
5 Logique du premier ordre et base de donnes 76
Exercices 82
Chapitre 4 SQL 95
1 Concepts du langage SQL 96
2 Oprations relationnelles avec SQL 97
3 Gestion de tables et de vues 110
4 Gestion des donnes 116
Exercices 120

IV Cration de bases de donnes
Chapitre 5 Du langage parl SQL 127
1 Prsentation de lactivit modliser 128
2 laboration du modle entit-association 129
3 Passage au modle relationnel 134
4 Interrogation de la base de donnes 141
Exercices 148
Chapitre 6 Prservation des donnes 157
1 Contrle daccs et sauvegarde 158
2 Limitations daccs au SGBD 161
3 Transactions 166
4 Triggers 173
Exercices 176
Annexe 183
Bibliographie 189
Index 191

Lauteur
V Avant-propos
Nicolas Larrousse est ingnieur au CNRS. Spcialis en informatique, il enseigne les bases
de donnes au niveau Master luniversit de Versailles Saint-Quentin-en-Yvelines et au
service de formation permanente de luniversit Pierre et Marie-Curie Jussieu. Il est
responsable dun atelier sur les outils informatiques pour le master de sciences cognitives de
lcole normale suprieure (Ulm). Il a mis en place une formation de type IUP (bac + 4) en
informatique luniversit dAntananarivo (Madagascar). Il a particip la conception et
la mise en uvre de nombreuses bases de donnes, essentiellement dans le domaine
documentaire lINIST (CNRS). Il est impliqu dans le programme des formations
TRANSFER de lAUF (Agence universitaire de la francophonie), o il soccupe plus
particulirement des formations rseaux et des certifications Linux.


Le relecteur
VII Le relecteur
ric Innocenti est matre de confrences en informatique luniversit de Corse Pasquale Paoli. Il
est responsable pdagogique des filires SRC (Services et Rseaux de Communication) et LPM
(Licence Professionnelle Multimdia). Il enseigne lalgorithmique, la programmation ainsi que
les systmes dinformation lInstitut universitaire de technologie. Son parcours professionnel la
conduit de la gestion informatique pour le compte de socits prives la recherche
universitaire o il travaille sur la modlisation et la simulation informatique des systmes
complexes. Il est galement auteur de progiciels de gestion et continue dexercer la fonction
danalyste consultant auprs dentreprises et dadministrations.


Avant-propos
IX Avant-propos
Objectifs de louvrage
Le but de cet ouvrage est de proposer une mthode ceux qui veulent concevoir un systme
dinformation robuste et volutif en vitant les cueils classiques aboutissant des donnes
inutilisables. En effet, une mauvaise conception de dpart conduit stocker des donnes
inutiles (redondance) et ainsi gnrer des incohrences. Par ailleurs, une structure de don-
nes inadapte peut provoquer des erreurs fondamentales dexpression dans linterrogation
de la base de donnes.
Il nest pas ais de prsenter dans un seul ouvrage toutes les facettes du monde des bases de
donnes de lenqute pralable la ralisation pratique en SQL et il a donc fallu oprer
certains choix pour ne conserver que lessentiel. La bibliographie propose permet dappro-
fondir les diffrents sujets prsents dans louvrage. La langue utilise est volontairement
peu technique pour rendre accessibles les concepts au public dbutant vis. Louvrage
sadresse des tudiants, de toutes les filires, qui dbutent dans ce domaine, mais aussi aux
professionnels qui veulent mettre en place une base de donnes, mme de taille modeste. En
effet, les problmes pratiques que pose la ralisation dune base de donnes se retrouvent
toutes les chelles, et ces aspects sont traits dans cet ouvrage au mme niveau que les
notions thoriques.
Organisation de louvrage
Le chapitre 1 est une introduction la notion de base de donnes et aux mtiers associs. Il
propose une mise en perspective de lvolution des bases de donnes, mais aussi de leur uti-
lisation (fouille de donnes, entrepts de donnes, etc.).
Les chapitres 2, 3 et 4 dcrivent les diffrentes tapes de la conception dune base de
donnes : la construction du modle conceptuel (entit-association dans cet ouvrage), le
passage au modle relationnel puis la ralisation avec le langage SQL.

X Cration de bases de donnes
Le chapitre 5 reprend les notions prsentes dans les chapitres prcdents en les appliquant
un exemple concret, ainsi trait de manire complte. Un regard critique sur la modlisation
effectue conduit la remise en cause et lvolution du modle.
Le chapitre 6 est consacr la prservation des donnes. En effet, une fois le processus de
cration ralis, on doit mettre en uvre des outils pour garantir la prennit des don-
nes. Aprs avoir nonc quelques conseils gnraux, on prsente ici les deux outils fonda-
mentaux que sont les transactions et les dclencheurs (triggers).
Notation
Les mots importants dune section sont mis en exergue par lutilisation de gras. Lorsque
lon fait rfrence des objets dfinis dans louvrage, par exemple une table, ils sont entre
guillemets simples (). Afin que la lecture soit facilite et les confusions vites, un mot
unique par chapitre a t choisi pour dsigner les synonymes que constituent les termes
attribut , champ et colonne . Le terme attribut est utilis dans le chapitre 2
pour le modle entit-association, le terme champ est utilis dans le chapitre 3 pour le
modle relationnel et le terme colonne est utilis dans le chapitre 4 consacr SQL. Les
noms des entits, des associations et de leurs attributs sont accentus dans le chapitre 2
alors que les noms des tables, des relations et de leurs champs ne sont pas accentus dans
les chapitres 3 et 4 car ils sont utiliss directement dans le code SQL ainsi que dans les
SGBD, qui ne les acceptent pas systmatiquement.
Les mots cls du langage SQL sont en majuscules pour les diffrencier facilement des par-
ties variables que sont les noms des colonnes et des tables qui sont en minuscules. Dans
la mesure du possible, les exemples en SQL sont indpendants du SGBD employ.
Ressources complmentaires
Les scripts prsents dans louvrage sont accessibles sur le site de Pearson Education
France (http://www.pearsoneducation.fr), diteur de louvrage. Vous y trouverez gale-
ment des jeux de donnes pour les bases de donnes que lon utilise ici ainsi que les scripts
de cration des diffrentes tables.
Remerciements
Je tiens remercier ric Innocenti pour son implication dans le projet. Je remercie parti-
culirement Christophe Lenne, chez Pearson Education France, notamment pour sa
patience.

Introduction aux
bases de donnes
1
Chapitre
1. Quest-ce quune base
de donnes ? ............................. 2
2. volution des bases de donnes
et de leur utilisation .................... 4
3. Systmes de gestion de bases
de donnes .............................. 13
4. tapes de la conception des bases
de donnes .............................. 17
5. Mtiers des bases de donnes 19
6. Plan de louvrage ..................... 20
7. Prsentation de la BD exemple ... 20
Exercices
1. Notion de base de donnes........ 22
2. Recherche dichotomique ............ 22
3. Langages dun SGBD................. 23
4. Modles de reprsentation ......... 23
5. Mtiers des bases de donnes .... 23
6. Utilisateurs dune base
de donnes .............................. 24
7. Vues externes ........................... 24
8. Base de donnes rparties ......... 25
9. XML ......................................... 25
10. Fouille de donnes et entrepts
de donnes .............................. 26
Au cours des dernires annes, les bases de donnes
ont connu un dveloppement considrable, au point
quelles jouent dsormais un rle dans chacune de
nos oprations quotidiennes du simple achat
effectu avec sa carte bancaire jusqu nos
dclarations de revenus.
Lobjectif de ce chapitre est de dfinir la notion de
base de donnes ainsi que les principaux concepts
qui sy rattachent. La mthodologie qui permet de les
concevoir, les applications informatiques associes
leur mise en uvre (SGBD) et les diffrents mtiers
des bases de donnes y sont prsents.

2 Cration de bases de donnes
1 Quest-ce quune base de donnes ?
Le nombre dinformations disponibles et les moyens de les diffuser sont en constante pro-
gression. La croissance du World Wide Web a encore accru ce dveloppement, en fournis-
sant laccs des bases de donnes trs diverses avec une interface commune. Celles-ci se
situent au cur de lactivit des entreprises, des administrations, de la recherche et de bon
nombre dactivits humaines dsormais lies linformatique.
Dans le domaine purement informatique, elles interviennent dornavant tous les
niveaux. Les dveloppeurs dapplications sappuient sur des bases de donnes externes
pour grer leurs donnes alors quauparavant elles taient intgres dans le programme.
Citons un autre exemple : la gestion des fichiers dans les nouveaux systmes dexploitation
(par exemple, Panther de chez Apple ou le futur Vista de Microsoft) volue vers de
vritables bases de donnes mises jour en permanence. Elles permettent de retrouver les
fichiers instantanment, par leur nom mais aussi par leur contenu, la manire dun
moteur de recherche.
Les bases de donnes reposent sur des thories solides et sont lorigine dune des plus
importantes disciplines de linformatique : lingnierie des systmes dinformation.
Cette section prsente une ide intuitive de ce quest une base de donnes, de son utilisa-
tion puis des lments de qualit qui lui sont associs.
1.1 NOTION DE BASE DE DONNES
Tout le monde a une ide naturelle de ce que peut tre une base de donnes : elle peut
revtir la forme dune liste de CD contenant le nom des artistes et les titres des morceaux
ou encore celle de fiches de recettes de cuisine.
On remarque quune caractristique des donnes contenues dans une base de donnes est
quelles doivent possder un lien entre elles. En effet, des donnes choisies au hasard ne
constituent certainement pas une base de donnes. Celle-ci est donc une reprsentation
partielle et (trs) simplifie du monde rel, que lon a obtenu par un processus de modli-
sation. En rsum, on dfinit une base de donnes comme lensemble des donnes stoc-
kes. Pour les manipuler, on utilise gnralement un logiciel spcialis appel SGBD
(Systme de Gestion de Bases de Donnes). Il y a parfois confusion, par abus de langage,
entre base de donnes et SGBD. On appelle aussi systme dinformation lensemble
compos par les bases de donnes, le SGBD utilis et les programmes associs. Plus for-
mellement, on appelle Base de Donnes (BD) un ensemble de fichiers informatiques ou
non structurs et organiss afin de stocker et de grer de linformation.
1.2 UTILISATION DUNE BASE DE DONNES
La cration dune base de donnes recle un but prcis : elle doit permettre de retrouver de
linformation par son contenu en se fondant sur des critres de recherche. On dsire, par
exemple, retrouver toutes les recettes qui ncessitent des ufs ou tous les CD qui contien-
nent un morceau donn.
La grande diffrence avec un programme crit dans un langage de programmation est
quune base de donnes doit pouvoir rpondre des questions pour lesquelles elle na pas
forcment t prvue la conception.
Une autre diffrence est que les donnes sont susceptibles dtre utilises par des applica-
tions diffrentes. Dans un programme classique, la structuration des donnes est dcrite

3 Introduction aux bases de donnes
Chapitre
directement dans le code, ce qui rend leur utilisation difficile par dautres programmes, en
particulier lorsque lon modifie cette structure. Ce que lon recherche en utilisant une base
de donnes est dassurer lindpendance entre le traitement et les donnes. Cest pourquoi,
il est ncessaire que lapplication obtienne des informations sur la structure des donnes
(nom, type, taille, etc.). Pour ce faire, on associe la base de donnes une description que
lon appelle mtadonne ou catalogue . Cette dernire dcrit la structure interne de
la base de donnes qui est spcifique au SGBD employ (voir figure 1.1). En plus de la
structure et du type des donnes, on stocke galement cet endroit les informations con-
cernant les rgles de cohrence des donnes abordes la section suivante.
Figure 1.1
Base de donnes
de CD et
mtadonne.
Lide gnrale est que lutilisateur ou lapplication utilisatrice des donnes ne doit pas tre
dpendante de leur reprsentation interne, ce qui constitue une abstraction des donnes.
Cest la raison pour laquelle on utilise une description des donnes sous la forme dun
modle pour permettre la restitution la plus efficace possible de linformation.
1.3 QUALIT DUNE BASE DE DONNES
Comme on la voqu prcdemment, lun des objectifs de cration dune base de donnes
est de pouvoir retrouver les donnes par leur contenu. Dans cette optique, il faut sassurer
que les donnes contenues dans la base sont de bonne qualit .
Comment dfinir la qualit des donnes ? De nombreux critres peuvent tre pris en
compte ; on peut citer parmi les principaux :
la cohrence des donnes contenues dans la base ;
labsence de redondance.
La cohrence des donnes est fondamentale ; elle ncessite une rflexion pralable sur la
normalisation du contenu des champs. On suppose quun champ contient la qualit dune
personne (par exemple, Monsieur, Madame, Mademoiselle). Si lon trouve dans ce champ
Mr la place de Monsieur, il est clair que les recherches sur ce champ par le contenu Mon-
sieur risquent dtre errones. Dans ce cas, les informations seraient moins nombreuses que
celles obtenues avec le contenu correct. On qualifie cet tat de fait de silence , qui signifie
que certains rsultats pertinents sont ignors lors dune interrogation.
Dans un autre cas, si lon saisit Mme pour Madame et Melle pour Mademoiselle, et
quil y ait eu par erreur plusieurs saisies de Mme alors quil sagissait dune demoiselle,
la recherche par le contenu Mme donne cette fois plus de rsultats quil ny a rellement
de dames. On qualifie cet tat de fait de bruit , qui signifie que certains rsultats non
1968
2005
1978
Anne
Dreyfus Chet Baker Two a day 3
Columbia Thelonious Monk Underground 2
Nocturne Olivier Temime Streetwise 1
Label Musicien Titre NumCD
Nombre entier
suprieur 1
Chane de caractres de taille 50
Nombre entier suprieur
1900 et infrieur
lanne en cours
Chane de caractres
de taille 30
Chane de caractres de taille 20

4 Cration de bases de donnes
pertinents sont retourns lors dune interrogation. La redondance est parfois plus dli-
cate identifier. Si lon considre le cas trs simple dun carnet dadresses qui contien-
drait en mme temps le code postal et le nom de la ville, elle est ici vidente.
On remarque que lon stocke plusieurs fois la mme association dinformation (par exem-
ple, Nancy et 54000), ce qui consomme de la place inutilement et peut devenir significatif
lorsque la base atteint quelques millions denregistrements.
De plus il existe des incohrences dans la saisie du nom de la ville Bordeaux. La recherche
par le nom Bordeaux ne donnera pas le mme rsultat que la recherche par le code
33000.
On verra plus loin que lapproche relationnelle procure des outils capables de dtecter et
damliorer considrablement ce genre de problmes de qualit des bases de donnes.
2 volution des bases de donnes et de leur
utilisation
Le dveloppement des bases de donnes stend sur une priode dune quarantaine
dannes. Cette section prsente tout dabord le contexte dans lequel elles se sont dvelop-
pes. On aborde ensuite les modles utiliss successivement pour les reprsenter. Enfin, la
dernire partie prsente une vue prospective des changements dans lutilisation des bases
de donnes.
2.1 CONTEXTE
partir des annes 1960, les ordinateurs voluent rapidement. Ils sont de plus en plus per-
formants mais aussi de plus en plus rpandus du fait de leur cot plus raisonnable. Leur
utilisation change galement ; on passe de la notion de calculateurs purs des machines
capables aussi de traiter de linformation. On parvient un niveau dabstraction suppl-
mentaire par rapport aux machines et on obtient en consquence une indpendance par
rapport larchitecture et surtout par rapport aux constructeurs.
La dcennie des annes 1970 est une priode faste pour la recherche et linnovation en
informatique dont les rsultats sont encore utiliss aujourdhui. On peut utiliser des lan-
gages de programmation de haut niveau, afin de guider, voire de faonner, la dmarche du
programmeur (Pascal), et lon envisage des systmes dexploitation indpendants de la
machine employe (Unix). Cest galement cette poque que lon pose les fondements
des techniques qui sont utilises dans les rseaux (TCP/IP), en particulier pour Internet.
Cest dans ce contexte favorable que E. F. Codd dfinit et dveloppe lapproche relation-
nelle en base de donnes.
Nom Tlphone Ville Code postal
Jaco 0668541087 Bordeaux 33000
Stanley 0654789254 Nancy 54000
Marcus 0658741263 Bordo 33000
Charles 0639517720 Nancy 54000
Steve 0659874120 Boredeaux 33000
Tableau 1.1
Exemple de
redondance de
linformation.

5 Introduction aux bases de donnes
Chapitre
Lobjectif principal est dloigner lutilisateur des dtails dimplmentation et de faciliter
ainsi lusage de linformatique. Un autre but est de rendre gnriques et rutilisables
les dveloppements informatiques, parfois devenus caducs en raison dun changement de
machine. Dans le domaine des bases de donnes, le dveloppement de larchitecture
trois niveaux constitue une premire tape importante. Les fonctionnalits des systmes
de bases de donnes sont spares en trois niveaux : niveau physique, niveau logique et
niveau externe.
2.2 MODLES
Les modles de donnes correspondent la manire de structurer linformation dans une
base de donnes. Ils reposent sur les principes et les thories issus du domaine de la
recherche en informatique et permettent de traduire la ralit de linformation vers une
reprsentation utilisable en informatique.
Modle hirarchique et modle rseau
Le traitement de linformation cette poque est encore trs li lorganisation des
fichiers sur une machine. Les modles conceptuels de donnes sont eux aussi trs proches
du systme de fichiers puisque lon manipule des graphes ou des arbres. Les nuds de ces
structures constituent les informations et les liens entre ces donnes les artes. ce
moment, on nest pas encore capable de sparer compltement le niveau logique du
niveau physique dun systme de bases de donnes (voir figure 1.2).
Le modle hirarchique propose une classification arborescente des donnes la
manire dune classification scientifique. Dans ce type de modle, chaque enregistrement
na quun seul possesseur ; par exemple, une commande na quun seul client. Cependant,
notamment cause de ce type de limitations, ce modle ne peut pas traduire toutes les
ralits de linformation dans les organisations.
Le modle rseau est une extension du modle prcdent : il permet des liaisons trans-
versales, utilise une structure de graphe et lve de nombreuses limitations du modle hi-
rarchique. Dans les deux cas, les enregistrements sont relis par des pointeurs : on stocke
ladresse de lenregistrement auquel il est li. Des SGBD de type hirarchique ou rseau
sont encore employs pour des raisons defficacit lorsque la structure des donnes sy
prte. On utilise cet effet des SGBD de conception ancienne, comme IMS (Bull) pour le
modle rseau ou IDMS (Computer Associate).
Figure 1.2
Modle
hirarchique.
Marque
Type
Couleur
Voiture
Personne
Nom
Prnom
NumINSEE
Logement
Numro
Rue
Ville
Type

6 Cration de bases de donnes
Modle relationnel
En 1970, E. F. Codd propose un nouveau modle relationnel dans un article rest
clbre : A Relational Model of Data for Large Shared Data Banks , CACM 13, n
o
6, June
1970. Il cherche crer un langage dinterrogation des bases de donnes plus proche du
langage naturel. Dans cette optique, il fonde sa recherche sur des concepts mathmatiques
rigoureux, tels que la thorie des ensembles et la logique du premier ordre. Le modle rela-
tionnel permet de modliser les informations contenues dans les bases de donnes en uti-
lisant des relations, cest--dire des ensembles dattributs (voir figure 1.3).
De lide de dpart la ralisation dun produit utilisable, le laps de temps est souvent de
lordre dune dcennie. La mise en uvre des ides de Codd se fait chez IBM dans le cadre
du projet de recherche System-R. Le premier produit commercial sera non pas le fait
dIBM, mais celui dHoneywell en 1976. Il sera suivi dun produit rellement abouti de
chez Relationnel Software en 1980 : Oracle, qui a connu le succs que lon sait. De son ct
IBM en tirera un produit qui deviendra DB2.
Toujours dans le cadre du projet de recherche System-R, E. F. Codd met au point, en
mme temps que le modle relationnel, un langage dinterrogation des donnes, SEQUEL,
qui deviendra ensuite SQL (Structured Query Language). La normalisation du langage
SQL ds 1986 par lANSI (institut de normalisation amricaine), puis par lISO (organisa-
tion internationale de normalisation), a assur pour une grande partie le succs du
modle relationnel auprs des entreprises. Fait rare dans le monde informatique, ce lan-
gage a t adopt par la quasi-totalit des diteurs commerciaux qui participent active-
ment son volution. SQL est devenu le standard de fait, mme si aucun diteur ne
respecte la lettre la norme. Dailleurs, partir de SQL 2, il existe une dfinition de quatre
niveaux de compatibilit avec la norme officielle. La normalisation de ce langage garantit
sa prennit, mme si son volution sen trouve ralentie. Les requtes crites pour un
SGBD fonctionnent en gnral sans trop de modifications avec un autre SGBD, ce qui per-
met denvisager des migrations moins douloureuses et de conserver une partie de linves-
tissement initial.
Figure 1.3
Modle
relationnel.
Modle objet
Dans le sillage du dveloppement des langages orients objet (C++, Java) dans les
annes 1980, le concept objet a t adapt aux bases de donnes. Plusieurs raisons, en
dehors des qualits reconnues de lapproche objet, ont conduit dfinir une extension
objet pour les bases de donnes (voir figure 1.4).
La premire est que le modle relationnel, dans sa simplicit, ne permet pas de modliser
facilement toutes les ralits. La deuxime est quun objet permet de reprsenter directe-
ment un lment du monde rel. Les structures dlments complexes se retrouvent sou-
vent disperses entre plusieurs tables dans lapproche relationnelle classique. De plus, le
concept objet est mieux adapt pour modliser des volumes de texte importants ou
dautres types de donnes multimdias (sons, images, vidos). Enfin, il est beaucoup
Basic Book Inc. D. Hofstadter Godel, Escher & Bach 6
Larousse P. Larousse Petit Larousse illustr 5
Eyrolles C. Delannoy Le langage C 4
First Interactive C. Baroudi Internet pour les nuls 3
Eyrolles G. Gardarin Les bases de donnes 2
MCGraw Hill J. M. Rifflet La programmation sous Unix 1
Editeur Auteur Titre Cote
Ouvrage (Cote, Titre, Auteur,Editeur)

7 Introduction aux bases de donnes
Chapitre
plus commode de manipuler directement des objets lorsque lon dveloppe avec un lan-
gage objet (comme C++ ou Java). Les bases de donnes, on le rappelle, sont dornavant
des briques constitutives des applications. Les bases de donnes orientes objet appor-
tent ainsi aux applications dveloppes en langage objet la persistance des objets
manipuls : ces derniers peuvent ainsi directement tre rutiliss par lapplication dori-
gine ou par dautres sans redfinition. Ces concepts ont t intgrs partir de la version 2
de la norme SQL.
Les produits commerciaux adapts ces concepts nont pas connu une diffusion suffisam-
ment importante. Le monde des bases de donnes volue assez lentement : la migration
dun systme dinformation vers lobjet reprsente pour une organisation un investisse-
ment considrable qui nest pas toujours justifi. La robustesse et la popularit de lappro-
che relationnelle, qui a mis presque vingt ans simposer, a galement frein le
dveloppement de lapproche objet pure dans les bases de donnes. Les donnes modli-
ses sous forme dobjets sont aussi plus complexes reprsenter du point de vue du SGBD
et lon rencontre encore trs souvent des problmes de performance.
Figure 1.4
Modle objet.
Modle relationnel-objet
Une demande dvolution du strict modle relationnel existe toutefois. En effet, la gestion
des donnes autres que du texte et des nombres comme des images, du son et des vidos
implique lvolution du modle relationnel. De mme, les champs dits multivalus ,
disposant de plusieurs valeurs telles quune liste de prnoms ou des coordonnes gogra-
phiques, ne peuvent pas tre modliss efficacement en utilisant ce type dapproche. Lide
est alors dintgrer de lobjet au modle relationnel existant plutt que dutiliser lappro-
che objet pure. Il convient de remarquer que ce type dvolution a dj t dvelopp dans
le cadre des langages de programmation. Le langage C++ est lvolution intgrant lappro-
che objet du langage C et non pas un langage objet pur comme peut ltre Smalltalk.
Cette extension, adopte par la plupart des SGBD, se nomme relationnel-objet et per-
met aux concepteurs des bases de donnes de disposer de types volus abstraits plus
simples concevoir et surtout plus commodes faire voluer. Elle offre en outre la possi-
Donnes
Mthodes
Objet
Encapsulation
Hritage
X1,Y1
X2,Y2
Dplacer()
Agrandir()
Fermer
Retourner

8 Cration de bases de donnes
bilit de modliser plus facilement la complexit des organisations (voir figure 1.5). Dans
cette optique, la norme SQL a logiquement t adapte. Dans sa version 3, elle prend en
compte lextension objet. Les types de donnes sont tendus et les oprations dencapsula-
tion et dhritage, typiques de lapproche objet, sont supportes. Cette solution a lavan-
tage doffrir un bon niveau de compatibilit avec lapproche prcdente trs rpandue et
deffectuer ainsi une migration plus aise.
Figure 1.5
Modle
relationnel-objet.
2.3 VOLUTION DE LUTILISATION DES BASES DE DONNES
Cette section prsente une description de nouvelles manires de stocker ou dutiliser les
bases de donnes. La diffrence par rapport la section prcdente est que lon ne remet
pas en cause le modle utilis pour dcrire les donnes sauf, dans une certaine mesure,
pour le cas de XML.
Base de donnes rparties
Le dploiement des rseaux ainsi que laugmentation de leur dbit ces dernires annes
ont conduit rpartir les donnes sur plusieurs sites gographiques, ce qui facilite la poli-
tique de dcentralisation des organisations. Ce type darchitecture masque la rpartition
de linformation tout en garantissant une gestion transparente aux utilisateurs, comme
sils disposaient dune seule base de donnes (voir figure 1.6). Les bases de donnes rpar-
ties assurent ainsi une plus grande fiabilit, de meilleures performances et facilitent
lvolution du systme dinformation.
La fiabilit et la scurit. On effectue une copie de scurit des donnes sur un site dis-
tant intervalles rguliers pour viter le dsastre de la perte de donnes due un incen-
die par exemple.
La disponibilit. On procde des rplications quasi permanentes des donnes dans le
but de rapprocher les utilisateurs des donnes dun point de vue de la topologie du
rseau. On amliore galement le temps de rponse en rpartissant la charge entre les
serveurs. Cette distribution est gre de manire intelligente par les systmes informa-
tiques, ce qui permet de rpartir linformation efficacement sur les diffrents sites, en
fonction des accs utilisateurs. Ces principes sont notamment utiliss par les moteurs
de recherche.
Les donnes sont rparties sur des sites spars. Le dispositif permet de masquer cet
aspect aux utilisateurs et de fonctionner comme si un seul serveur tait prsent sur un
seul site. Lvolution du systme est rendue totalement transparente pour les
utilisateurs : en cas notamment de changement de machine la suite dune panne, de
Romazava
La vie sans
mode demploi
2
Les ditions du
temps qui ne
passe pas
Le vide
1
Editeur Auteur Titre Cote
Charles Atamp
Dal Durand
Prnom Nom
Anne-Isabelle Paclaire
Romain Chteau
Jean-Marie Duporche
Alexis Brass
Prnom Nom

9 Introduction aux bases de donnes
Chapitre
modification de localisation, daugmentation de la taille de la base, dajouts dordina-
teurs sur le rseau afin daugmenter la capacit de stockage de la base de donnes.
Figure 1.6
Base de donnes
rparties.
Ces technologies possdent nanmoins des inconvnients. La scurit sur les rseaux
informatiques ncessite beaucoup plus de travail que dans le cas dun systme non rparti.
Les techniques de scurit mettre en uvre sont plus complexes et plus coteuses.
Extraction dinformations non explicitement stockes dans une base
de donnes
Il existe deux manires de crer de la nouvelle information partir de linformation
stocke explicitement dans une base de donnes. Soit on est capable dnoncer des rgles
prcises de constitution de linformation partir du sens mme des donnes, soit on uti-
lise des mthodes danalyse afin de trouver des corrlations sur un volume de donnes
important, ce qui permet ensuite den dduire des rgles.
La premire possibilit a t formalise et mise en uvre sous le nom de base de donnes
dductives, dans le but dutiliser des mthodes semblables celles pratiques pour la
dduction en intelligence artificielle. On dfinit un ensemble de rgles et on les applique
aux donnes de la base, laide dun programme que lon appelle un moteur
dinfrence . Les SGBD qualifis de dductifs utilisent cet effet un driv du langage
Prolog : Datalog.
Les relations de parent entre individus sont une bonne illustration de lutilisation des
bases de donnes dductives. Intuitivement, on peut apprhender le fonctionnement
gnral de ces SGBD dductifs en considrant lexemple suivant. On suppose que lon a
une base de donnes qui reprsente les relations pre-fils (voir figure 1.7). Une rgle
trs simple permet de dfinir un lien de parent anctre :
Si pre-fils(X,Y) et pre-fils(Y,Z), alors anctre(X,Z).
La seconde possibilit dobtenir linformation nouvelle partir de linformation existante
relve des mthodes dites de fouilles de donnes (ou data mining). Ce type dexploi-
tation des bases de donnes a connu un grand succs ces dernires annes, par lanalyse de
grands volumes de donnes afin didentifier des corrlations entre des valeurs de champs.
Par exemple, les personnes moustachues de plus de quarante ans habitant une maison
individuelle lisent plutt des revues de psychologie . Les techniques danalyses employes
sont une alchimie concocte partir de statistiques, de rseaux de neurones, de classifica-
tions et autres techniques employes en intelligence artificielle. Une fois ces rgles ta-
blies, on peut les utiliser au sein des bases de donnes dductives dcrites prcdemment.
Sige social
Filiale Est
Filiale Asie
Filiale Ocan indien
Copie sauvegarde
Copie sauvegarde
Copie sauvegarde
Interrogation
(rpartition)

10 Cration de bases de donnes
Figure 1.7
Base de donnes
dductives pre-
fils.
Linformation dcisionnelle ainsi extraite a de nombreux dbouchs : du ciblage marke-
ting la mdecine en passant par la prvision financire. Les mthodes saffinent et
deviennent rellement efficaces, ce qui a cependant donn lieu quelques escroqueries, les
entreprises spcialises dans le domaine refusant bien sr de donner les spcifications de
leurs mthodes danalyses, qui relevaient parfois de la divination, au motif de ne pas per-
dre leur avantage concurrentiel.
Entrepts de donnes (datawarehouse)
Les entrepts de donnes sont des bases de donnes rcapitulatives , constitues partir
de diffrentes sources de lentreprise (comptabilit, ventes, achats, service du person-
nel) pour disposer dun accs homogne lensemble des donnes. Les donnes disper-
ses ne peuvent pas tre exploites directement en tant quinformation dcisionnelle. En
effet, il nest pas possible danalyser efficacement dans le temps des indicateurs de gestion
par mtiers ou par individus. Les donnes sont alors rapatries et stockes dans un entre-
pt de donnes ou datawarehouse (voir figure 1.8).
Si linformation est disponible, on stocke les diffrentes valeurs dune donne, ce qui per-
met de conserver un historique dans le temps de certaines donnes : elles sont dites histo-
rises. Ce dernier aspect est dsign parfois aussi comme une base de donnes
temporelle, dans la mesure o le SGBD procure des outils danalyse adapts. Il est alors
possible deffectuer des analyses dcisionnelles qui combinent tous les paramtres de
lentreprise : cest lanalyse dcisionnelle multidimensionnelle. Les techniques prcden-
tes de fouille de donnes et de dduction peuvent tre utilises. Elles sont combines avec
dautres outils danalyse de lvolution dune donne partir de son historique pour en
extrapoler des tendances et ainsi faire des prvisions.
Lide des entrepts de donnes est plus quintressante, mais il est vident que sa mise en
uvre est dlicate tant dun point de vue du stockage de linformation (volume de don-
nes, htrognit des donnes traiter) que de lanalyse des donnes (comment ana-
lyser, quelle information stocker). En outre, il sagit le plus souvent du poste budgtaire
le plus onreux dans un projet dinformatique dcisionnelle.
Teanne Alize
Alize Merlin
Lastoul Tian
Merlin Tapeneau
Tian Hugo
Fils Pre

11 Introduction aux bases de donnes
Chapitre
Figure 1.8
Entrepts de
donnes.
XML
Le World Wide Web est la mise en uvre du concept dhypertexte par lutilisation de la
structure de communication fournie par Internet. Les fichiers disperss sur diffrentes
machines du rseau Internet peuvent ainsi tre associs. Son succs a provoqu un glisse-
ment de lide originale, qui consistait relier simplement des textes entre eux, vers la
notion dinterface universelle. On ne transmet plus seulement le contenu dun fichier sta-
tique, mais galement le rsultat de lexcution dun programme : le contenu devient donc
dynamique. Par extension, on imagine aisment que le mcanisme du Web peut gale-
ment transmettre le rsultat de linterrogation dune base de donnes.
Le concepteur du Web, T. B. Lee, sest appuy pour sa mise en uvre, outre la structure
technique existante dInternet, sur un langage de description de documents utilisant des
balises : le SGML (Standard Generalized Markup Language). Le dcoupage du document
par les balises est dcrit dans un document associ que chacun peut crer en fonction des
ses besoins : la DTD (Data Type Definition). Cette dernire, formule dans un langage
normalis, permettra des programmes spcialiss, les parsers , de vrifier si le docu-
ment est conforme la structure attendue et den extraire facilement le contenu. Le lan-
gage SGML est assez complexe manipuler, car il est trs gnral. Pour des besoins
spcifiques, on utilise des versions simplifies, telles que HTML ou XML.
T. B. Lee a donc dvelopp un langage de prsentation, HTML (Hyper Text Markup Lan-
guage), bas sur les notions dveloppes par SGML. Ce langage permet essentiellement de
spcifier des critres de prsentation (gras, soulign, couleur) et, bien sr, de dcrire les
liens entre les fichiers. Il ne comprend aucun lment de structuration des donnes du
texte contenu dans la page HTML. Les moteurs de recherche parcourent le Web et
indexent le contenu des pages par rapport des listes de mots cls combins dautres
mthodes (beaucoup) plus sophistiques. Cependant, ils ne peuvent diffrencier dans le
texte le titre dun rsum ou dune lgende associe une image. Lefficacit et la perti-
nence de lindexation en sont diminues dautant.
Pour remdier cela, le W3C (World Wide Web Consortium) a dfini un langage, qui est ga-
lement une simplification de SGML, permettant de dcrire la structure interne dun
document : XML (eXtended Markup Language). La structure dun document XML est repr-
sente sous la forme dun arbre tout comme celle dun document HTML. La description de
Entrept de
donnes
(datawarehouse)
Analyse
Consultation
Service
achats
Service
marketing
Service du
personnel
Production

12 Cration de bases de donnes
cette structure arborescente se trouve dans une DTD ou plus rcemment dans un schma
XML. Le schma est plus souple et permet demployer les mmes outils de traitement que
pour les fichiers XML. Le langage HTML possde videmment lui aussi une DTD, mais, la
diffrence de XML, elle est normalise par le W3C et ne peut tre modifie et adapte pour
ses besoins propres (voir figure 1.9).
Lobjectif terme est que les fichiers du World Wide Web soient dsormais dcrits en utili-
sant XML la place de HTML. La prsentation des donnes repose alors sur les feuilles
de styles (telles que eXtended Stylesheet Language) pour gnrer les formats de prsenta-
tion classiques (HTML, PDF, PostScript) partir du format XML. De cette manire, les
moteurs de recherche pourront extraire directement par exemple le rsum ou le titre
dun paragraphe dun fichier XML. Lindexation peut ainsi tre plus prcise ; un mot figu-
rant dans un titre tant plus important que le mme mot dans une note de bas de page.
Figure 1.9
Structure
arborescente XML.
Quel est le rapport avec les bases de donnes ? Comme on la vu prcdemment, une page
Web peut tre le rsultat dune requte provenant dun SGBD ; cest mme devenu le
moyen le plus courant dinterroger un SGBD. Dans cette optique, si le SGBD est capable
de gnrer directement du XML, cela facilite le processus. Cest dautant plus vrai que le
passage du modle relationnel un modle arborescent de type XML est parfois complexe
et quil est bien agrable que le SGBD sache le faire.
Le langage de description XML, par sa versatilit, simpose comme un format dchange
universel. Cest vident pour des fichiers gnrs par un traitement de texte : on spare
ainsi laspect structurel de laspect prsentation. On se donne galement la possibilit
douvrir le document indpendamment du logiciel utilis, ce qui garantit sa prennit. De
la mme manire, XML est utilis comme format dchange entre SGBD et dun SGBD
vers dautres logiciels (tableurs, traitements de texte).
Le langage XML est adopt petit petit par la plupart des diteurs et il est amen jouer
un rle croissant dans les changes de donnes. De plus en plus de SGBD sont capables de
produire des rsultats de requte en XML, dimporter du XML et acceptent mme de grer
les donnes directement dans ce format. Cette dernire possibilit implique que les SGBD
supportent des donnes moins bien structures : cette capacit constitue lune des volu-
tions futures des SGBD.
catalogue
<catalogue>
<article>
<nom> banane </nom>
<prix> 2 </prix>
<quantit> 1000 </quantit>
</article>
<article>
<nom> pige </nom>
<prix> 300 </prix>
<quantit> 35 </quantit>
</article>
<catalogue>
article
article
prix
quantit
nom
prix
quantit
nom
banane
2
1000
300
pige

13 Introduction aux bases de donnes
Chapitre
Contenu multimdia
Le multimdia sest fortement dvelopp depuis la fin des annes 1990. La demande tant
trs forte dans ce domaine, les diteurs de SGBD se doivent dintgrer de linformation
multimdia (image, son, vido) dans les bases de donnes. Les bases de donnes multi-
mdias posent de nouveaux problmes, en particulier pour effectuer des recherches sur les
contenus multimdias, ce qui est par nature difficile.
Une solution est deffectuer une indexation prliminaire manuelle laide de mots cls qui
permettent doprer par la suite des interrogations, mais cela semble illusoire de raliser ce
traitement pour des volumes importants de documents multimdias. Dans le cas con-
traire, il existe des mthodes de recherche sur des fichiers de type image par rapport des
schmas prdfinis. Cette possibilit reste pour linstant plutt du domaine de la recher-
che, mme si lon est dj (malheureusement) capable didentifier des visages par rapport
un modle dans certaines conditions.Dans le mme ordre dide, il est dj possible
dutiliser des techniques pour valuer le style de musique (classique, jazz, pop) dun
fichier en analysant son contenu. On est cependant assez loin de pouvoir identifier un
genre de film en se basant sur lanalyse des images.
Les bases de donnes multimdias constituent un sujet de recherche trs prometteur et
trs actif. Ces problmatiques relvent pour linstant plutt des proccupations des soci-
ts dveloppant les moteurs de recherche que des bases de donnes au sens strict. Cepen-
dant, le groupe de normalisation ISO/IEC prpare lvolution pour le multimdia de la
norme SQL-MM, qui est une volution pour le multimdia de la norme SQL.
3 Systmes de gestion de bases de donnes
On a beaucoup parl dans les sections prcdentes des SGBD. Un SGBD est un logiciel
complexe qui permet de grer et dutiliser les donnes que lon stocke en utilisant les
modles cits prcdemment. La premire partie de la section permet de comprendre le
mcanisme dabstraction partir duquel se fait le passage du simple fichier informatique
la gestion de linformation qui se fonde sur lutilisation dun SGBD. Une seconde partie
dtaille le modle en couches des SGBD ainsi que leurs fonctionnalits de base.
3.1 FICHIERS INFORMATIQUES
Un fichier peut tre vu (historiquement) comme un morceau de bande magntique. Les
mcanismes de gestion de fichiers des langages de programmation, comme le langage C,
fonctionnent encore avec cette mtaphore. Lorsquon utilise un fichier pour stocker de
linformation, il est ncessaire de prvoir un dcoupage de celui-ci par enregistrements,
souvent de taille fixe. Pour passer dun enregistrement lautre, il suffit alors davancer la
tte de lecture de la taille dun enregistrement (voir figure 1.10). Les donnes sont stoc-
kes dans lenregistrement par un dcoupage interne suivant la taille de chaque donne.
On utilise gnralement des structures de donnes (par exemple, en langage C) pour rcu-
prer directement chaque valeur de champ dans une variable. Dans une base de donnes,
on recherche les donnes par leur contenu. Pour retrouver lune dentre elles, il faut donc
parcourir tous les enregistrements un un (recherche squentielle), et en examiner le
contenu.

14 Cration de bases de donnes
Figure 1.10
Fichier
informatique.
Dans le cas dun accs squentiel, la recherche dun enregistrement en position n ncessite
daccder aux n1 enregistrements qui le prcdent. Si lon recherche larticle de rfrence
DR-NetCard10.102, contenu dans le fichier Article, il sera ncessaire de parcourir tous les
enregistrements, depuis le dbut du fichier jusqu larticle recherch. Pour retrouver une
information, il faut donc parcourir tous les enregistrements un un et en examiner le con-
tenu.
Une alternative au parcours squentiel est de construire des tables descriptives afin dacc-
lrer laccs aux donnes. Une premire table permet laccs direct un enregistrement
par une cl associe ladresse (pointeur) de lenregistrement. On rappelle que cest ce
mcanisme de pointeurs sur des enregistrements qui est modlis dans les modles
hirarchiques ou rseaux pour faire le lien entre des enregistrements. On constitue ainsi le
graphe qui permet de naviguer dans lensemble des enregistrements.
Une seconde table contient lordre relatif des enregistrements ordonns suivant les valeurs
dun champ : on appelle cette table un index (voir figure 1.11). Cette seconde table permet
demployer des mthodes de recherche par le contenu du champ index beaucoup plus
efficaces quune recherche squentielle. La recherche dichotomique bien connue est lune
dentre elles. Une fois lenregistrement identifi, on y accde directement grce la pre-
mire table. Les techniques de constitution des index constituent un sujet part entire
ainsi que les algorithmes de recherche qui leur sont associs.
Figure 1.11
Fichier et index.
On constate que la simple recherche dinformations recourt dj des algorithmes assez
sophistiqus et ncessite la construction et le maintien de structures annexes pour tre
efficace. De mme, la destruction denregistrements et lvolution de la structure de la
base sont galement des oprations lourdes mettre en uvre ; elles requirent souvent la
recopie complte des informations dans un nouveau fichier. Cette section nous permet de
comprendre pourquoi on utilise prfrentiellement des SGBD pour grer les donnes.
Toutes ces fonctionnalits et bien dautres que nous allons dtailler sont intgres dans le
logiciel.
Accs squentiel
Fichier
Index
Fichier

15 Introduction aux bases de donnes
Chapitre
3.2 FONCTIONNALITS DUN SGBD
De mme que lISO a dtermin un modle thorique en sept couches pour distinguer les
applications rseaux et leurs interactions, il existe dsormais un modle thorique en trois
couches (trois niveaux dabstraction) afin de concevoir et dorganiser les fonctionnalits
des SGBD. Ce modle est labor par la commission SPARC de lANSI : cest larchitec-
ture ANSI/SPARC (voir figure 1.12). Cette dernire, qui date de 1975, sinscrit dans les
concepts et thories de la premire gnration des bases de donnes, dont lobjectif est
davoir une indpendance entre les donnes et les traitements :
Niveau interne ou physique. Cest le niveau le plus bas . On dcrit les structures de
stockage de linformation, ce qui le rend trs dpendant du SGBD employ. Il se fonde
sur un modle de donnes physique.
Niveau conceptuel. Il correspond limplmentation du schma conceptuel de la
base de donnes, que lon ralise lors de la phase danalyse (voir Modle Conceptuel des
Donnes, Modle Logique des Donnes). Il est utilis pour dcrire les lments constitu-
tifs de la base de donnes et les contraintes qui leur sont associes. Il sagit dune cer-
taine faon de la documentation de la base de donnes.
Niveau externe. Le niveau externe sert dcrire les vues des utilisateurs, cest--dire le
schma de visualisation des donnes qui est diffrent pour chaque catgorie dutilisa-
teurs. Un schma externe permet de masquer la complexit de la base de donnes com-
plte en fonction des droits ou des besoins des utilisateurs. Cela facilite la lecture et la
scurit de linformation.
Figure 1.12
Niveaux ANSI/
SPARC.
Il sagit comme pour le modle rseau de lISO dun cadre de rflexion ; les SGBD ne res-
pectent pas la lettre le dcoupage propos. Ils se doivent cependant de possder les prin-
cipales caractristiques qui dcoulent de ce modle en couches :
Indpendance physique des donnes. Masquer la reprsentation interne des donnes
ainsi que les mthodes systme daccs aux utilisateurs.
Indpendance logique des donnes. Permettre la modification du schma conceptuel
des donnes sans remettre en cause les mcanismes de stockage et de manipulation
internes des donnes.
Intgrit des donnes. Faire en sorte que linformation rsultant des liens entre les
donnes soit cohrente.
Il peut apporter galement des fonctionnalits supplmentaires utilises dans le cadre de
bases de donnes rparties dcrites prcdemment :
Rplication des donnes. Copie automatise de sauvegarde.
Schma conceptuel
Niveau externe
Niveau interne
Modle physique
SGBD
Utilisateurs
Vues
Modle conceptuel

16 Cration de bases de donnes
Virtualisation des donnes. Masquage de la distribution gographique des donnes.
Haute disponibilit des donnes. Duplication de la base de donnes sur diffrents
sites pour diminuer la distance client/serveur et la charge des serveurs.
Le but principal de lutilisation dun SGBD est de masquer la reprsentation physique des
donnes et les mthodes daccs que lon vient de voir prcdemment. Cependant les
mcanismes de cration, dindexation et de recherche sous-jacents sont globalement les
mmes. videmment, pour des questions defficacit, les SGBD utilisent leur propre ges-
tion de fichiers et parfois mme contournent le systme de fichiers fourni avec le systme
dexploitation de la machine.
Un SGBD doit permettre galement la manipulation de la structure de la base de donnes,
comme lajout et la modification de champs, de manire transparente. Il conserve cet
effet une description de la structure de la base de donnes que lon appelle le
dictionnaire de donnes . Pour raliser ces oprations avec lindpendance souhaite
par rapport la reprsentation, le SGBD offre deux langages de haut niveau :
un Langage de Description de Donnes (LDD) qui permet dagir sur la structure de la
base de donnes (ajout, suppression et modification des tables) ;
un Langage de Manipulation de Donnes (LMD) qui permet dinterroger et de mettre
jour le contenu de la base de donnes.
Ces langages sont de type non procdural , cest--dire que lon sintresse leffet de
lopration (le quoi) et non pas la manire dont elle est ralise (le comment). On a pu
se rendre compte dans la section prcdente du niveau de complexit de certaines opra-
tions qui, grce ces langages, sont nonces simplement. Par exemple, la modification de
la taille dun champ peut tre nonce en une seule instruction avec le LDD. Il est courant
que les SGBD modernes implmentent ces langages de manipulation laide dobjets gra-
phiques.
Le SGBD doit galement assurer la protection des donnes en cas de problmes. Ceux-ci
peuvent tre la consquence dune manipulation malheureuse, mais galement dune
panne du systme qui survient par exemple la suite dune coupure de courant. Dans tous
les cas, le SGBD doit permettre de restaurer les donnes. Ces oprations sont gnrale-
ment ralises en utilisant des journaux qui enregistrent au fur et mesure les opra-
tions faites sur la base : cest le mcanisme de la journalisation. Ce journal est utilis pour
refaire, ou dfaire le cas chant, ces oprations.
En ce qui concerne les oprations de modification effectues sur la base de donnes, que
lon appelle des transactions, des proprits de mesure de la qualit de ces transactions
sont proposes sous le terme ACID :
Atomicit. Une transaction est atomique ; elle est excute entirement ou aban-
donne.
Cohrence. La transaction doit se faire dun tat cohrent de la base vers un autre tat
cohrent.
Isolement. Des transactions simultanes ne doivent pas interfrer entre elles.
Durabilit. La transaction a des effets permanents mme en cas de panne.
noter que tous les SGBD ne ralisent pas cette proprit ACID pour les transactions.
Les machines sont connectes au rseau ou sont simplement multi-utilisateurs : le SGBD
doit permettre de donner laccs aux bases de donnes plusieurs utilisateurs concurrem-
ment. Laccs concurrentiel implique des oprations algorithmiques complexes raliser,
puisquil faut par exemple empcher la modification dune valeur par un utilisateur alors
quelle est en lecture par un autre. Cela ncessite la gestion dune structure de description

17 Introduction aux bases de donnes
Chapitre
des utilisateurs comprenant les droits qui leur sont associs pour chaque lment (lecture,
modification) : les droits daccs aux donnes. Les mcanismes sont les mmes que
ceux qui sont mis en uvre dans les systmes dexploitation multi-utilisateurs.
4 tapes de la conception des bases de
donnes
On peut dcomposer le processus de conception dune base de donnes en plusieurs tapes :
lanalyse du systme du monde rel modliser ;
la mise en forme du modle pour lintgrer dans un SGBD ;
la cration effective dans le SGBD des structures et leur remplissage (voir figure 1.13).
4.1 ANALYSE DU MONDE REL
La premire tape de la dmarche de modlisation des donnes consiste effectuer lanalyse
de la situation du monde rel considrer. Cette action sapparente au travail effectu par
une entreprise de consulting. Cest une approche humaine qui se fonde en partie sur des
entretiens avec les personnels concerns et ressemble plutt une analyse du discours et de
lorganisation de lentreprise. Cest lors de cette phase danalyse que lon dtermine les objec-
tifs du systme dinformation concevoir et que lon identifie tous les lments prendre en
compte dans le systme ; ce sont les champs qui contiendront les donnes. Un ensemble de
champs peut constituer un objet du monde rel. Par exemple les champs nom,
prnom et adresse que lon regroupe constituent une personne .
Enfin, il faut identifier les liens modliser entre ces objets ainsi que les lments caract-
ristiques de ces liens. Par exemple une personne achte une voiture 10 000 euros. Ici les
deux objets lis sont personne et voiture , et le prix est le composant du lien. Cette
tape est dlicate et fondamentale, car elle conditionne laspect reprsentatif et la qualit
du modle du monde rel considr. Lors de cette phase, il convient galement dexprimer
les rgles qui dfinissent le domaine de validit du contenu des champs. Par exemple, le
prix dune voiture ne peut pas tre infrieur 500 euros ou suprieur 150 000 euros.
Cette modlisation du rel permet de proposer un schma conceptuel qui servira la des-
cription gnrale du systme dinformation. La notion de sens des donnes et surtout des
liens entre les entits ne sera rellement exprime que dans ce schma qui est plus proche
du monde rel. Ce schma est souvent ralis laide de la symbolique du modle entit-
association ou, plus couramment aujourdhui, exprim avec le langage UML (Unified
Modeling Language). Il existe diffrentes mthodes intgrant les concepts prsents ci-des-
sus. Lobjectif est de guider le travail danalyse et daider la ralisation dun modle de
donnes le plus juste possible. Parmi celles-ci, la mthode Merise a connu un certain suc-
cs dans le domaine en France.
4.2 PASSAGE AU SGBD
La reprsentation prcdente doit tre transforme pour la rendre acceptable par le SGBD,
quil soit relationnel, objet ou relationnel-objet. Souvent, cette tape modifie considra-
blement les objets du monde rel ainsi que les liens dfinis dans le schma prcdent. Cest
lors de cette phase que lon vrifie la qualit de la base de donnes en utilisant les critres

18 Cration de bases de donnes
vus prcdemment, comme llimination de la redondance. Le modle relationnel procure
cette fin des outils capables de tester la cohrence du systme et de le modifier le cas
chant : ce sont les formes normales , qui seront vues au chapitre 3.
Il est possible de constater des incohrences ce niveau de lanalyse, ce qui implique de
modifier le modle conceptuel de donnes dvelopp ltape prcdente. On obtient un
schma des donnes qui fournira aux utilisateurs les informations ncessaires pour effec-
tuer leurs requtes, par exemple la description des noms de tables, de champs et leurs
types. Par contre, on perd ce niveau linformation du sens des donnes et du lien
entre elles. Ce schma nest gure utilisable en pratique sans le prcdent. En effet, com-
ment savoir que les personnes achtent des voitures et non pas le vendeur si lon ne dis-
pose pas de linformation de liaison entre les objets du monde rel ? Cest galement lors
de cette phase que lon dfinit les vues du systme dinformation qui sont adaptes
chaque catgorie dutilisateurs.
4.3 CRATION ET UTILISATION DE LA BASE DE DONNES
Une fois le schma prcdent dfini, on utilise le SGBD pour passer la cration des tables
qui constituent la base de donnes. Puis, on insre videmment les valeurs dans les tables.
Le cas chant, on cre les vues dfinies ltape prcdente et par l mme les utilisateurs
concerns. Le systme est alors oprationnel. Toute cette tape se fait forcment en utili-
sant le SGBD, alors que les prcdentes taient plus thoriques. La cration des tables et
lutilisation de la base de donnes ncessiteront le langage SQL. Cependant, il existe de nos
jours de nombreux outils graphiques dans les SGBD qui masquent lutilisation du SQL.
Figure 1.13
tapes de la
conception dune
base de donnes.
Schma
relationnel
Base de
donnes
physique
Vue 1
Vue 2
SGDB
Monde rel
Analyse
LMD
LDD
Modle
entit-association
Transformation
Vue 3

19 Introduction aux bases de donnes
Chapitre
5 Mtiers des bases de donnes
Comme on peut le constater lorsque lon considre les diffrentes tapes de la conception
dune base de donnes, des acteurs aux comptences trs diverses interviennent dans ce
processus.
5.1 CONSULTANTS/ANALYSTES
Ils prennent en charge la premire tape qui consiste en lanalyse des activits et des flux
dinformation mis en jeu dans le monde rel modliser. Le profil de ces acteurs nest pas
toujours purement technique, puisque cette phase ncessite parfois beaucoup de dialogues
et de psychologie pour parvenir faire exprimer leurs besoins rels par les futurs utilisa-
teurs. La gageure est de parvenir faire exprimer correctement les besoins dinformatisa-
tion par les utilisateurs du systme dinformation, afin de proposer un modle conceptuel
de donnes le plus juste possible.
5.2 CONCEPTEURS DE LA BASE
Ce sont les personnes qui soccupent de traduire le modle prcdent en un modle logi-
que exploitable par le SGBD. Le concepteur est un spcialiste des bases de donnes qui
prpare les tables, les vues, les schmas daccs. Cest lui qui renseigne les utilisateurs et
programmeurs pour la dfinition des requtes. Il na pas, en principe, tre spcialis sur
un SGBD particulier, mais en pratique les lments quil manipule sont lis au SGBD qui
sera employ. Cest ordinairement lui qui cre les lments ncessaires la base de don-
nes (tables, vues) en collaboration avec ladministrateur de la base. Cest parfois la
mme personne qui est en charge de la partie analyse et de la conception, ce qui peut
induire une vision un peu trop oriente techniquement comme celle dun programmeur
qui crirait le cahier des charges dune application. Par contre, le concepteur peut aussi
tre administrateur du SGBD, ce qui ne pose pas de problmes particuliers dapproche.
5.3 ADMINISTRATEURS DE BASE DE DONNES (DBA, DATABASE ADMINISTRATOR)
Ladministrateur a la responsabilit du fonctionnement gnral du SGBD. Il cre les ressour-
ces (bases, comptes) la demande. Il donne les droits daccs et gre les personnes qui acc-
dent au systme. Il vrifie que les ressources sont suffisantes (taille du disque, puissance de la
machine), effectue les sauvegardes, vrifie les failles de scurit. Pour ces oprations, il est en
relation avec ladministrateur systme et rseau de la structure. Ce mtier est extrmement
li au SGBD employ. Il ny a pas vraiment de normalisation pour les oprations dadminis-
tration des SGBD qui sont spcifiques au SGBD et la version utiliss.
5.4 UTILISATEURS STANDARD ET PROGRAMMEURS DAPPLICATIONS
Ce sont eux qui utilisent le systme dinformation. Ils y ont accs grce aux vues dfinies par
le concepteur de la base. Ils utilisent les schmas dtermins aux deux premires tapes de la
conception. Ils nont pas besoin thoriquement dtre spcialiss sur le SGBD employ. En
pratique il est prfrable, surtout pour les dveloppeurs dapplications, davoir de bonnes
connaissances du fonctionnement du SGBD. Par exemple, pour optimiser les performances,
la manire dcrire les requtes peut tre assez diffrente suivant le SGBD employ.

20 Cration de bases de donnes
6 Plan de louvrage
Le plan de louvrage est dtermin par les diffrentes tapes de la conception dune BD.
Le deuxime chapitre traite de ltape danalyse du monde rel pour en concevoir un
modle descriptif. La modlisation est effectue classiquement par le modle entit-
association . On aborde galement la reprsentation du modle avec UML.
Le troisime chapitre est essentiellement consacr au modle relationnel et aux opra-
tions qui lui sont associes. On sintresse ensuite aux mthodes grce auxquelles il est
possible de passer du modle prcdent un ensemble de tables du modle relationnel.
Puis, on continue par ltape de normalisation qui permet de mettre en vidence les inco-
hrences du systme dinformation ainsi cr et de les rectifier. On prsente dans ce chapi-
tre les trois premires formes normales et celle de Boyce-Codd. Une autre approche de la
cration dune base de donnes partir de la relation universelle est aborde la fin du
chapitre.
Le quatrime chapitre prsente le langage SQL. Aprs avoir expos la syntaxe gnrale du
langage, il sattache la ralisation en SQL des oprations relationnelles vues prcdem-
ment. On aborde ensuite la correspondance entre les questions classiques des bases de
donnes en langage parl et leur reprsentation avec SQL. La dernire partie du chapitre
traite de la partie description de donnes de SQL, qui permet de crer et grer les tables
dans un SGBD.
Le cinquime chapitre constitue un exemple complet de ralisation dune base de don-
nes par la pratique. Cet exemple part de lnonc du monde rel en langage parl jusqu
la ralisation du systme dinformation, puis bien sr son utilisation. Ce chapitre reprend
les notions vues aux chapitres prcdents de manire pratique.
Le sixime chapitre aborde les mcanismes gnraux de prservation des donnes asso-
cis aux SGBD. On aborde la scurit des accs et les sauvegardes, mais aussi les outils qui
participent la scurisation des donnes comme les transactions ou les triggers .
7 Prsentation de la BD exemple
Une base de donnes extrmement simplifie est utilise rgulirement tout au long de
louvrage afin dillustrer les concepts dvelopps au fil de louvrage. Dautres bases de don-
nes plus complexes sont prsentes au fur et mesure des explications (voir figure 1.14).
Ce systme dinformation qui constitue ltude de cas basique modlise lactivit de vente
de voitures doccasion. Dans ce systme, deux entits du monde rel sont identifies : les
personnes et les voitures. Une voiture est caractrise par sa marque, son type, sa couleur.
Une personne est caractrise par son nom, son ge, sa ville, son sexe. Laction modlise
est la vente qui est caractrise par le prix de la vente et sa date. Une personne peut acheter
une plusieurs voitures. Une voiture peut tre vendue une seule fois ou jamais.

21 Introduction aux bases de donnes
Chapitre
Figure 1.14
Base de donnes
exemple.
Le modle entit-association et la reprsentation UML correspondant cette descrip-
tion seront crs au chapitre 2, Analyse du monde rel . Le modle relationnel sera cr
au chapitre 3, Approche relationnelle . La base de donnes rsultante sera utilise pour
les exemples du chapitre 4, SQL .
Rsum
Une base de donnes dsigne lensemble des donnes stockes. Pour manipuler ces don-
nes, on utilise un SGBD (Systme de Gestion de Bases de Donnes) qui est un logiciel com-
plexe. Lensemble compos par les donnes et le SGBD constitue un systme
dinformation. La conception dune base de donnes de la modlisation du monde rel
son implmentation dans le SGBD fait appel des techniques et des mthodes trs dif-
frentes pour chaque tape. Des mtiers spcifiques se sont donc dvelopps autour de ces
concepts et les mettent en uvre. Par exemple, lapproche du monde rel sapparente
lanalyse faite par un cabinet de consulting alors que limplmentation dans le SGBD et
son administration sont proches des mtiers informatiques.
Les SGBD ont volu paralllement aux concepts de modlisation des bases de donnes.
On est pass dune organisation comparable celle des fichiers informatiques (modles
hirarchiques ou rseaux) un modle plus abstrait : le modle relationnel. Ce modle est
toujours le plus utilis actuellement. Il est associ troitement SQL, un langage norma-
lis de description, de manipulation et dinterrogation de donnes. La modlisation objet,
adapte aux bases de donnes, na pas connu un dveloppement considrable, et ce, mal-
gr les avantages quelle procure par rapport au modle relationnel en particulier pour le
typage des donnes. Comme cest le cas dans le domaine de la programmation, une
approche mixte semble prendre de lampleur : le modle relationnel-objet. Il sagit
dapporter au modle relationnel les possibilits tendues de modlisation procures par
les objets sans remettre profondment en question lexistant.
Le dveloppement des rseaux apporte dautres manires dutiliser les bases de donnes,
comme la rpartition des donnes pour amliorer leur disponibilit et leur scurit.
Linterfaage avec le World Wide Web a introduit la prise en compte du langage XML
comme format dchange et de stockage par les SGBD. De nouvelles formes dinterroga-
tion, telles que la fouille de donnes (ou data mining) et les bases de donnes dducti-
ves, permettent dextrapoler de linformation non explicitement stocke dans les bases de
donnes. Ces approches ainsi que la prise en compte des donnes multimdias vont faire
voluer les modles de bases de donnes et les SGBD que lon utilise actuellement. Cela se
fera probablement sans remettre totalement en cause le modle relationnel, mais plutt en
le faisant voluer progressivement.
Type
Marque
Couleur
Nom
ge
Ville
Sexe
Vente

22 Cration de bases de donnes
Exercices
EXERCICE 1 NOTION DE BASE DE DONNES
On peut lister ces points essentiels qui les diffrencient :
Il nest pas ncessaire de connatre la mthode de stockage des informations sur le dis-
que pour manipuler les donnes avec une base de donnes.
Un fichier informatique simple nest pas conu pour effectuer une recherche dinfor-
mation par le contenu : pour retrouver le(s) enregistrement(s), on est oblig de par-
courir tout le fichier.
Les modifications de structure (ajout/suppression dun champ ou modification de sa
taille) ncessitent de recrer un autre fichier et dy recopier les donnes.
Une base de donnes contient en gnral plusieurs fichiers dont les enregistrements
sont relis entre eux.
EXERCICE 2 RECHERCHE DICHOTOMIQUE
Soit V la valeur recherche, Ti le tableau dindex de taille n. On suppose que la table
dindex contient les valeurs du champ indexes dans sa colonne 1 et les numros denre-
gistrement correspondants dans sa colonne 2.
Si le tableau est rduit un lment dont la valeur dans la premire colonne Ti[1,1] est dif-
frente de la valeur recherche alors la recherche est un chec sinon comparer llment du
milieu z du tableau Ti avec la valeur V
Si llment Ti[z,1] est gal la valeur, accder lenregistrement directement par son
numro Ti[z,2]
Si llment Ti[z,1] est infrieur la valeur recommencer avec la partie basse du tableau
(de 1 z-1)
Si llment Ti[z,1] est suprieur la valeur recommencer avec la partie basse du tableau
(de z+1 n)
Quelles sont les diffrences majeures entre un fichier informatique et une base de don-
nes gre par un SGBD ?
Donnez un algorithme intuitif simple de recherche dichotomique en utilisant une table
dindex et une table accs direct.

23 Introduction aux bases de donnes
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 3 LANGAGES DUN SGBD
Le langage de description de donnes sintresse la modification de structure dune table
dj cre ou la gestion des tables (cration/modification). Dans notre cas, on ne touche
pas la structure, on supprime des enregistrements, donc des donnes de la table. On ne
touche pas au dictionnaire de donnes. On utilisera par consquent le langage de manipu-
lation de donnes du SGBD. Pour augmenter la taille du champ, on modifie cette fois la
structure mme de la table, on utilise alors le langage de description de donnes.
EXERCICE 4 MODLES DE REPRSENTATION
Par nature, ce type de donnes est structur strictement de manire arborescente et cette
structure reste assez stable dans le temps. Il est donc tout fait possible dutiliser un simple
modle hirarchique. Un modle rseau ne sera pas utile en principe du fait de la structure
arborescente des donnes. On peut galement utiliser les modles relationnel ou objet,
mais il napporteront pas davantage dcisif dans ce cas (trs) particulier.
EXERCICE 5 MTIERS DES BASES DE DONNES
Dans une petite structure, cest souvent la mme personne qui ralise lensemble du pro-
cessus de construction dune base de donnes. Ce nest videmment pas la bonne
mthode, car la vision dun systme dinformation labor par un administrateur de base
de donnes est trs oriente par le SGBD quil emploiera. On peut facilement faire le
parallle avec le dveloppement de logiciels o un programmeur va avoir une approche
dforme par les proccupations lies au langage plutt que dadopter un point de vue sur
la structure gnrale de lapplication. Au minimum, la personne devra disposer des com-
ptences en conception de base de donnes et en administration du SGBD qui sera utilis.
On veut supprimer tous les enregistrements qui contiennent la valeur 666 dans le champ
catgorie. Utilise-t-on le langage de description de donnes ou le langage de manipulation
de donnes ? Que se passerait-il si lon voulait augmenter la taille du champ catgorie.
Vous devez reprsenter lorganisation de donnes correspondant une classification
scientifique despces doiseaux. Quel modle de donnes (hirarchique, rseau, relation-
nel, objet) choisiriez-vous ?
Est-il possible de faire raliser toutes les tapes de la conception dune base de donnes
par une mme personne ? Si oui, quelles sont alors ses comptences minimales ?

24 Cration de bases de donnes
EXERCICE 6 UTILISATEURS DUNE BASE DE DONNES
1. Un utilisateur final (par exemple un vendeur) muni des droits appropris peut interve-
nir sur le contenu des donnes.
2. Pour cette opration, cela dpend sil sagit dune convention ou si cela est entr au
niveau des contraintes du SGBD. Dans le premier cas, un utilisateur final peut sen
charger ; dans le second, il faut recourir au concepteur ou ladministrateur de base de
donnes.
3. Pas dambigut ici, car on touche la structure mme des donnes ; cela est du ressort
du concepteur ou de ladministrateur de base de donnes.
4. Il sagit du domaine du programmeur dapplication qui rcupre les donnes en utili-
sant le SGBD et qui les traite dans un programme pour leur donner leur forme finale.
5. Un utilisateur final (par exemple un vendeur ou la comptabilit) muni des droits
appropris peut intervenir sur le contenu des donnes.
EXERCICE 7 VUES EXTERNES
1. Les clients ne doivent avoir accs en lecture quaux informations concernant les voitu-
res en stock (non encore vendues).
2. Les vendeurs, sils grent galement le parc de voitures comme cest souvent le cas, peu-
vent avoir accs en lecture et en criture toutes les donnes (ventes, voitures, person-
nes).
3. Le service comptabilit peut avoir accs en lecture toutes les informations, mais ne
peut modifier les informations concernant les voitures ou les personnes du fichier
client.
On utilise pour cet exercice la base de donnes exemple de vente de voitures. On consi-
dre les oprations suivantes :
1. Ajouter une personne dans le fichier client.
2. Modifier les possibilits dajout dans le champ couleur .
3. Augmenter la taille du champ couleur.
4. Sortir le chiffre daffaires par marques pour le mois en cours afin de limporter dans
un tableur.
5. Enregistrer une vente.
Quels types dutilisateurs sont concerns par ces oprations ?
On utilise galement pour cet exercice la base de donnes exemple de vente de voitures.
On considre trois types dutilisateurs de la base :
1. les clients ;
2. les vendeurs ;
3. le service comptabilit.
Quelles sont les vues prvoir pour ces catgories dutilisateurs ?

25 Introduction aux bases de donnes
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 8 BASE DE DONNES RPARTIES
Cest une solution coteuse en ressources, en particulier pour la synchronisation de toutes
les mises jour, mais qui peut remplir deux fonctions :
1. De toute vidence, lide est que les diffrents sites de lentreprise accdent leur copie
locale des donnes. Cela permet dacclrer les accs et de rpartir la charge sur les ser-
veurs locaux de chaque site. Accessoirement, la circulation des requtes dinterrogation
et de mise jour peut tre limite au rseau local, ce qui renforce la scurit.
2. Il existe six copies des donnes sur des sites gographiquement spars. En cas de sinistre,
on peut repartir sans problmes avec une des copies de la base.
Avant de mettre en place un tel dispositif, on doit se poser la question de la mise jour des
donnes. Est-ce que les modifications se font uniquement sur la base matre , ce qui
semble plus raisonnable, ou peut-on les effectuer sur toutes les bases et consolider
ensuite ?
EXERCICE 9 XML
Par nature, les donnes contenues dans une base de donnes sont structures. Le langage
HTML a t conu pour dcrire la mise en forme dun texte sans considration de sa
structure interne. Donc, il nest pas adapt si lon dsire conserver la structuration des
donnes. Le langage XML a t prcisment cr pour dcrire la structure des donnes. Il
est toujours possible de passer ensuite du langage XML au langage HTML par une feuille
de style ; linverse nest pas possible.
XML permet de reprsenter des structures de donnes diffrentes sous forme arborescente ;
il est donc ncessaire de possder une description de la grammaire de la structure. Ce
document accompagnateur dun fichier XML est une DTD, comme pour les fichiers XML
classiques, ou plus commodment un schma XML. Un des avantages du schma est que
lon peut utiliser les mmes algorithmes de parcours que pour le fichier XML.
On dcide de recopier rgulirement une base de donnes complte sur chacun des six
sites de lentreprise. Quel est lintrt de cette solution ?
Pourquoi prfre-t-on utiliser XML plutt que HTML pour reprsenter les donnes pro-
venant dune base de donnes ? Les donnes XML sont dites autodescriptives . Quest-
ce que cela signifie et par quel(s) dispositif(s) est-ce ralis ?

26 Cration de bases de donnes
EXERCICE 10 FOUILLE DE DONNES ET ENTREPTS DE DONNES
Pour obtenir les lments ncessaires lanalyse, il nous faut intgrer les donnes de diff-
rents services de lentreprise.
Les donnes du fichier clientle sont gres par le service commercial (peut-tre avec
un tableur ou un traitement de texte pour faire des mailings) afin dobtenir le nom des
clients.
Les donnes du service comptabilit permettent dobtenir les journaux de ventes ; la
gestion est faite par exemple par une application de gestion spcifique connecte aux
caisses.
Les donnes du service achat sur les ngociations avec les fournisseurs peuvent tre
gres par exemple par une application dveloppe en interne. La marge provenant de
la ngociation avec les fournisseurs est fluctuante pour le mme article au cours du
temps en fonction du march, des personnes qui ngocient, etc. Il serait donc intres-
sant pour ces donnes de disposer des valeurs historises par priodes pour affiner
lanalyse par des tendances.
Pour intgrer ces donnes provenant de sources diffrentes dans votre entrept de don-
nes, vous utiliserez une (ou plusieurs) application(s) de type ETL (Extract, Transform and
Load) que lon appelle aussi datapumping .
Par des mthodes danalyse dassociations, on dcouvre quen utilisant votre systme
dinformation les clients dont le nom commence par M achtent le samedi plus de pro-
duits que les autres. Ils gnrent donc un chiffre daffaires plus important, mais ces pro-
duits sont marge faible et le bnfice est moins important que pour ceux dont le nom
commence par un Z. Quavez-vous intgr comme donnes dans votre entrept de don-
nes pour pouvoir effectuer cette opration en supposant que votre entreprise soit orga-
nise avec une structure de services classique ?

Analyse du monde
rel
27
Chapitre
1. Dmarche danalyse ................. 28
2. Modlisation par le modle
entit-association ...................... 30
3. Remise en cause et volution
du modle ............................... 35
4. Reprsentation avec UML .......... 40
Exercices
1. Identifiant dune entit ............... 44
2. Identification des entits
et des associations .................... 44
3. Questions associes
aux cardinalits ........................ 45
4. Description du monde rel
partir des cardinalits ............. 47
5. Association inutile ..................... 48
6. Association rflexive................... 49
7. Association ternaire .................. 49
8. De lnonc au modle
entit-association ...................... 51
9. Reprsentation avec UML .......... 52
10. Autre exemple le camping
lUliastru .................................. 53
Ce chapitre prsente la premire tape du processus
de modlisation du monde rel, qui consiste
recueillir les informations puis les transcrire sous
une forme conduisant un passage ais au modle
relationnel.
On utilise cette fin le modle entit-association,
dont les concepts et la mise en uvre sont prsents
dans ce chapitre. Cette dmarche de modlisation est
utilise depuis plus de vingt ans et prsente lintrt
de proposer une mthode danalyse simple et
efficace dans la majorit des cas.
Au cours des dernires annes, la reprsentation
utilisant le formalisme du modle entit-association
est progressivement remplace par le langage de
modlisation UML. Ce dernier apporte, en plus des
avantages de la normalisation, de la disponibilit
doutils graphiques logiciels ainsi que des possibilits
tendues de description. Les bases de la notation
UML sont abordes la fin de ce chapitre.

28 Cration de bases de donnes
1 Dmarche danalyse
1.1 APPROCHE DU MONDE REL
Comment apprhender et simplifier le monde rel, par nature complexe, pour raliser une
modlisation ?
Cette tche relve de comptences multiples du domaine dun cabinet de consulting. Il est
ncessaire didentifier les besoins des utilisateurs ainsi que les objectifs et les processus
dalimentation en donnes des systmes dinformation concevoir. Les bases de donnes
sont dornavant au cur de la plupart des applications, et leur structure doit correspon-
dre au mieux aux attentes de lorganisation.
Son laboration ncessite diffrentes tapes et se droule souvent en mme temps que le
processus danalyse du problme. Des allers-retours entre ces diffrentes tapes de la con-
ception sont souvent ncessaires la constitution du modle conceptuel de la base. On
qualifie alors ce processus ditratif. Il sagit de construire la structure de la base de don-
nes par raffinements successifs.
La premire phase de lanalyse du monde rel du problme est ralise par des entretiens,
gnralement codifis, avec les utilisateurs. On effectue une analyse du discours pour en
extraire linformation utile que lon resitue dans le contexte de lorganisation en gnral.
Lobjectif principal est de guider lanalyste, on utilise des mthodes danalyse et de con-
ception issues de ltude des flux dinformation de lentreprise. Parmi celles-ci, on peut
citer la mthode Merise dorigine franaise trs rpandue en France dans les annes
1980 ainsi que dautres issues de la recherche et du gnie logiciel, ou spcifiques des
grandes entreprises de consulting.
La prsentation de ces mthodes fort complexes dpasse largement le cadre de cet ouvrage.
Lobjectif de cette section est de donner quelques pistes pour approcher la ralit mod-
liser. Lexpression des besoins repose sur la formulation du problme laide de phrases
simples qui dcrivent la ralit modliser. Ces phrases se prsentent sous la forme
sujet-verbe-complment , avec une tournure active quand cela est possible. Le but est
dobtenir deux types de phrases :
Celles qui dcrivent les liens entre les objets du monde rel gnralement une action
ou une proprit. Exemple : Un lecteur emprunte un livre. Un livre a un auteur.
Celles qui caractrisent la manire dont sont relis ces objets. Exemple : Un lecteur est
considr comme lecteur sil a au moins dj emprunt un livre. Un livre peut tre
emprunt par plusieurs lecteurs. Il ny a pas de livres anonymes, un livre est crit par au
moins un auteur.
On doit ensuite prciser les donnes qui constituent les objets ainsi que celles qui caract-
risent les liens entre les objets.
Remarque
Le terme dobjet du monde rel employ ici nest pas pris au sens de la programmation objet. Il
sagit plutt de caractriser un regroupement logique de donnes. Un titre, un auteur, un diteur
constituent un livre. Un nom, un prnom, un numro de Scurit sociale constituent une personne.

29 Analyse du monde rel
Chapitre
1.2 MISE EN UVRE
Comment procder intuitivement pour obtenir ces phrases ?
Un bon point de dpart consiste faire linventaire des objets tangibles ou perus du
monde rel. Une fois ces objets identifis, on cherche exprimer le (ou les) lien(s) qui per-
met(tent) de les associer. Par exemple, si lon doit modliser une activit de location de
DVD, les objets que lon peut apprhender immdiatement sont les DVD et les clients. En
ce qui concerne les liens entre ces objets, on note quun client rserve un DVD ou quun
client loue un DVD, etc. Ensuite, il faut identifier les objets moins faciles percevoir
directement : les fournisseurs, les acteurs, les ralisateurs Enfin, une fois les objets iden-
tifis, on cherche qualifier les liens trouvs. Il faut tenir compte du fait que le lien est tou-
jours double sens. Par exemple, un client emprunte plusieurs DVD. Un DVD est
emprunt plusieurs fois ou nest jamais emprunt par un client.
Pour obtenir ce rsultat, quelles questions faut-il se poser et quelles questions doit-on
poser aux acteurs de lorganisation ?
Dcrivez lactivit globalement, en termes simples, sans entrer dans les dtails, pour
identifier les objets et leurs liens ventuels.
Indiquez quelles sont les procdures utilises dans lactivit pour caractriser les
liens entre les objets. Les procdures permettent dnoncer les contraintes qui seront
intgres ensuite dans la base de donnes.
On note que lon modlise souvent des actions qui reprsentent une activit, plus rare-
ment des lments statiques. Les actions reprsentent frquemment le lien entre les
objets : une personne emprunte un DVD, une voiture est achete par un client, etc.
1.3 NOTION DE TEMPS
Le temps est une notion importante, une base de donnes modlise des actions qui ont
lieu durant une priode de temps. Il faut toujours avoir lesprit cet aspect pour viter des
erreurs de conception. Une erreur classique est de confondre laspect simultan dune
action avec la possibilit de la ritrer durant la priode concerne. Lorsque lon spcifie
qu un livre peut tre emprunt plusieurs fois , il est vident quun livre ne peut tre
emprunt par deux personnes simultanment, mais plutt quil pourra tre emprunt
plusieurs reprises durant la priode modlise du fonctionnement de la bibliothque.
1.4 CAS PRATIQUE
Afin dillustrer les recommandations prcdentes, on considre la modlisation trs sch-
matique du fonctionnement dun htel. Quelle(s) phrase(s) simple(s) dcri(ven)t lacti-
vit de lhtel ?
On peut proposer en premire approche cette phrase : Un htel loue des chambres des
clients qui effectuent des rservations. Aprs avoir procd lanalyse de la phrase pour
en extraire les parties importantes, on peut la rcrire de la manire suivante :
Un client loue une chambre ; un client rserve une chambre.

30 Cration de bases de donnes
Les deux objets du monde rel la chambre et le client apparaissent clairement. On a
identifi ici un double lien entre ces deux objets, cas assez frquent.
Ensuite, on sintresse la caractrisation des liens : Une chambre peut navoir jamais
t loue ni rserve.
Un client est insr dans le systme dinformations partir du moment o il a effectu
soit une rservation soit une location.
Un client peut rserver ou louer plusieurs chambres.
Une chambre peut tre rserve ou loue plusieurs fois, mais pas pendant la mme
priode de temps.
On rappelle que lon considre toujours une modlisation associe une priode de temps
donne. Au dbut du processus, une chambre peut ne pas encore avoir t loue.
Enfin, on dcrit les donnes des objets et des liens.
Un client est caractris par son nom, son adresse et son numro de tlphone.
Une chambre est caractrise par son numro, un nombre de places, son tarif journalier
et la prsence ou non dun cabinet de toilettes.
Une location est caractrise par une date de dbut, un nombre de jours et les consom-
mations annexes (petits djeuners, tlphone).
Une rservation est caractrise par une date de dbut, un nombre de jours et le verse-
ment dune avance ventuelle.
2 Modlisation par le modle entit-association
Aprs ltape de recueil dinformations, on dispose dun ensemble de phrases simples qui
expriment les besoins dcrivant la ralit modliser : on doit alors en effectuer une repr-
sentation. Cette dernire est trs importante, car elle est la seule qui donnera une vue
densemble des donnes et des liens qui les caractrisent. Le modle obtenu cette tape
est en gnral nomm Modle Conceptuel des Donnes (MCD). En effet, on verra lors de
ltape du passage au modle relationnel, appel galement modle logique, que cette
information napparat plus. Les donnes stockes dans le SGBD seront presque inutiles si
lon ne dispose pas du modle conceptuel qui est lquivalent du schma technique dun
appareil ou du plan dun btiment.
Le formalisme le plus rpandu pour constituer ce schma est le modle entit-association
(ou entity-relationship en anglais). Il a t prsent lorigine par P. Chen en 1976 aux
tats-Unis quasi simultanment avec le modle de H. Tardieu en France, ce qui explique
les notations lgrement diffrentes en Europe et aux tats-Unis, en particulier au niveau
de la reprsentation des cardinalits. Le modle entit-association a t normalis lISO.
On verra dans la section suivante que lon peut utiliser galement le formalisme UML
pour la reprsentation.
Le formalisme entit-association , tout comme UML, utilise une reprsentation graphi-
que sous forme de diagrammes. Les entits sont les objets concrets ou abstraits du monde
rel voqus plus haut. Les associations reprsentent le lien entre ces entits. Comme on
la vu prcdemment, on peut identifier les entits et les associations en effectuant une
analyse du discours, cest--dire des phrases de type sujet-verbe-complment . Les
sujets et les complments sont les entits, et le verbe modlise lassociation.

31 Analyse du monde rel
Chapitre
2.1 ENTITS
Les entits sont composes de champs de donnes que lon nomme attributs. Un attribut,
ou un ensemble dattributs, doit tre choisi comme identifiant de lentit, avec pour
objectif didentifier une occurrence (ou reprsentant) de cette entit. La notion didenti-
fiant a les mmes proprits que la cl dans une relation qui sera introduite au chapitre 3.
On reprsente une entit par un rectangle qui contient le nom de lentit et ses attributs.
Lidentifiant est soulign ou prcd dun caractre # (voir figure 2.1).
Figure 2.1
Entits chambre,
attributs et
occurrences.
Le choix de lidentifiant nest pas toujours trivial. Il est parfois ncessaire dintroduire arti-
ficiellement un attribut supplmentaire afin de pouvoir disposer dun identifiant. Dans le
cas de lhtel, il faudrait intgrer un attribut pour identifier un client (voir figure 2.2),
dans la mesure o aucun des attributs issus de lanalyse ne permet didentifier de manire
unique un client. Classiquement, une identification sans ambigut reposera sur un
numro unique ; dans notre exemple, cest lattribut IDClient.
Les identifiants peuvent tre composs par la juxtaposition de diffrents attributs. Par
exemple, on peut identifier un client en juxtaposant les attributs nom+pr-
nom+date_naissance+ville_naissance. En effet, il est peu probable que deux homonymes
soient ns le mme jour dans la mme ville. Cependant, dans la pratique, il est recom-
mand, autant que faire se peut, de choisir un seul attribut comme identifiant. En effet, il
sera plus difficile de vrifier quun identifiant composite reste valide lorsque les donnes
voluent. Cest pourquoi, quand cela est possible, il est indispensable de choisir un identi-
fiant dont les contenus ne sont pas susceptibles dvoluer au fil du temps. On prfre iden-
tifier une personne par un numro de scurit sociale que par un numro de passeport qui
a une dure de validit limite.
Figure 2.2
Entit client.
Chambre
# IDChambre
NombrePlaces
Tarif

Entit chambre
Chambre
123
2
55

Chambre
13
4
75

Chambre
176
1
40

Occurrences chambre
Client
# IDClient
Nom
Adresse
NumTlphone


32 Cration de bases de donnes
2.2 ASSOCIATIONS
Les associations reprsentent les liens qui existent entre les entits. Elles sont composes le
cas chant dattributs, bien que cela ne soit pas indispensable. Par consquent, il nest pas
ncessaire de disposer dun identifiant pour une association. Lorsque les entits sont asso-
cies par deux, elles sont qualifies de binaires. Cependant, il est possible den associer
plus de deux ; les associations sont alors non plus binaires, mais n-aires. Le nombre
dentits associes sappelle le degr de lassociation.
On reprsente une association par un ovale qui contient le nom de lassociation et ses
attributs.
Figure 2.3
Entits client et
chambre relies
par lassociation
location.
Il peut galement y avoir plus dune association entre deux entits ; cest le cas de lexem-
ple de lhtel (voir figure 2.4). Les entits client et chambre sont relies par deux associa-
tions ayant des attributs diffrents : location et rservation.
Figure 2.4
Entits client et
chambre relies
par les
associations
location et
rservation.
Enfin, il est possible de relier par une association une entit elle-mme. Si lon prend
lexemple de la modlisation des liens de mariage entre personnes, on obtient une seule
entit personne qui est associe elle-mme par lassociation est_mari_ (voir
figure 2.5). Dans ce cas, on dit que lassociation est rflexive.
Chambre
# IDChambre
NombrePlaces
Tarif

Client
# IDClient
Nom
Adresse
NumTlphone

Location
DateDbut
NombreJours
Chambre
# IDChambre
NombrePlaces
Tarif

Client
# IDClient
Nom
Adresse
NumTlphone

Location
DateDbut
NombreJours
Rservation
DateDbut
NombreJours

33 Analyse du monde rel
Chapitre
Figure 2.5
Entit personne
relie par
lassociation
est_mari_.
2.3 CARDINALITS
Les cardinalits dcrivent les caractristiques de lassociation entre les entits. On utilise
deux nombres qui reprsentent les valeurs minimales et maximales pour caractriser
lassociation. Ces nombres modlisent le nombre doccurrences minimales et maximales
des entits impliques dans lassociation. Par exemple, comme illustre sur la figure ci-
aprs (voir figure 2.6) , une association binaire sera caractrise entirement par quatre
nombres. En effet, chaque entit participe de manire diffrente lassociation.
Figure 2.6
Cardinalits dune
association
binaire.
Les cardinalits peuvent prendre les valeurs suivantes :
De un un, note 1,1. Une brosse dents possde en thorie un (1) et un (1) seul pro-
pritaire.
De un plusieurs, note 1,n. Un livre a au moins un (1) auteur ; il peut en possder
plusieurs (n). On ne considre pas les ouvrages anonymes.
Optionnel, note 0,1. Une personne est clibataire (0) ou marie (lgalement) une
(1) autre personne au plus.
De zro plusieurs, note 0,n. Un appartement peut tre libre (0) ou habit ventuel-
lement par plusieurs habitants (n).
Dans lexemple de lhtel prcdent, lanalyse pralable permet de dduire les proprits
suivantes (voir figure 2.7) :
Un client loue au minimum une (1) chambre ; il peut en louer plusieurs (n). La cardi-
nalit est donc de 1,n.
Une chambre peut tre loue plusieurs fois (n) et elle peut ne pas tre occupe (0). La
cardinalit est donc de 0,n.
Client
# IDPersonne
Nom
Adresse
NumTlphone

Est mari
DateMariage
Chambre
# IDChambre
NombrePlaces
Tarif

Client
# IDClient
Nom
Adresse
NumTlphone

Location
DateDbut
NombreJours
1,n
0,n

34 Cration de bases de donnes
Figure 2.7
Entits client,
chambre et
association
location avec
cardinalit.
2.4 CAS DTUDE CASSE
On a prsent dans le chapitre dintroduction la base de donnes exemple casse , qui
dcrit lactivit de vente de voitures doccasion. Voici sa modlisation sous forme de
modle entit-association. On rappelle la description de ce systme.
Deux entits du monde rel sont identifies : les personnes et les voitures. Une voiture est
caractrise par sa marque, son type, sa couleur. Une personne est caractrise par son nom,
son ge, sa ville, son sexe. Laction modlise est la vente, caractrise par le prix de la vente et
sa date. Une personne peut acheter plusieurs voitures ou aucune. Une personne peut acheter
aucune ou plusieurs voitures. Une voiture peut tre vendue ou non.
Recherche des identifiants
Les deux entits voiture et clients ainsi que leurs attributs respectifs sont bien dfinis ; il
manque pour chacune de ces entits un identifiant capable de diffrencier les occurrences
(ou reprsentants) des entits voitures et des clients. Sur cet exemple simple, il est facile de
vrifier quaucun attribut ni ensemble dattributs ne permet de dfinir sans ambigut un
identifiant. Le processus de recherche dun identifiant partir des relations de dpendan-
ces entre les attributs, est dtaill au chapitre 3.
Recherche des cardinalits
Les cardinalits sont dduites des deux dernires phrases :
0,n. Pour une personne peut acheter plusieurs (n) voitures ou aucune (0) .
0,1. Pour une voiture peut tre vendue une seule fois (1) ou jamais (0) .
Remarque
Les cardinalits se notent diffremment dans le modle de Chen employ aux tats-Unis et dans
celui utilis en Europe. Dans le modle europen, on dispose les cardinalits du ct de lentit
concerne. La cardinalit 0,n dduite de une chambre peut tre loue plusieurs fois et elle peut
ne pas tre occupe se trouve du ct de lentit chambre. Cette notation prsente lavantage
dtre plus cohrente lors de lutilisation dassociations n-aires . Il ny a pas de changement
dans lemplacement des cardinalits des entits associes.
Chambre
# IDChambre
NombrePlaces
Tarif

Client
# IDClient
Nom
Adresse
NumTlphone

Location
DateDbut
NombreJours
1,n
0,n

35 Analyse du monde rel
Chapitre
Figure 2.8
Entits voiture et
client lies par
lassociation
vente avec
cardinalits.
3 Remise en cause et volution du modle
Cette section nonce quelques conseils pour amliorer et affiner le modle conceptuel
obtenu ltape prcdente.
3.1 QUALIT DES ATTRIBUTS
Dans cette sous-section, on aborde les qualits gnrales que doivent possder les attributs
des entits et des associations. Des rgles simples permettent de guider le choix des attributs.
Une premire rgle est de ne stocker que les attributs strictement ncessaires : la tendance
des utilisateurs est en gnral de prvoir le plus dattributs possible juste au cas o. Le
choix seffectue en tenant compte des fonctionnalits attendues du systme dinformation
par limination systmatique des donnes non utiles.
Une deuxime rgle consiste ne pas retenir les attributs qui peuvent tre dduits
dautres attributs. La dduction peut se faire soit par le calcul, soit par un lien smantique
entre plusieurs attributs :
Le chiffre daffaires peut tre calcul partir du prix de vente et de la quantit.
Une rfrence peut tre construite partir du nom du produit et du fournisseur.
Le but est de rduire la place occupe ainsi que les risques dincohrence.
Enfin, une dernire rgle concerne le nom des attributs qui doivent tre parlants . Il ne
faut pas hsiter utiliser des noms de grande taille si cela facilite la comprhension du rle
de lattribut dans lentit. Par exemple, il est prfrable dutiliser un attribut
Numro_Srie plutt quun attribut ns. Dans la mesure du possible, on essaie de donner
des noms dattributs spcifiques pour chacune des entits. Ces deux dernires prcautions
faciliteront la comprhension gnrale du modle et son utilisation future dans le SGBD.
3.2 RORGANISATION DES ENTITS
Dans cette sous-section, on remet en cause le dcoupage en entits produits par une pre-
mire approche. Le processus itratif de cette remise en cause peut conduire un redcou-
page des entits ou leur fusion.
On considre lexemple de la bibliothque de prt, que lon a dj utilis prcdemment. La
phrase caractristique dcrivant lactivit de la bibliothque est la suivante : Un lecteur
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
# NumVoit
Marque
Type
Couleur
Vente
DateVente
Prix
0,1
1,n

36 Cration de bases de donnes
emprunte un livre. On en dduit les deux entits lecteur et livre lies par lassociation
emprunte (voir figure 2.9).
Un lecteur est caractris classiquement par son nom, son prnom et son adresse.
Comme il ny a pas dattribut possdant les caractristiques dun identifiant pour
lentit lecteur, on ajoute un attribut identifiant. Cet attribut supplmentaire est le
numro de lecteur. noter que dans le monde rel, ce numro pourrait correspondre
par exemple un numro de carte de lecteur.
Un livre est caractris par son titre, son auteur, son numro ISBN, son diteur. Le
numro ISBN est ici un identifiant pour lentit puisquil est unique.
Lassociation emprunte a pour attribut la date demprunt.
Figure 2.9
Entits livre et
lecteur lies par
lassociation
emprunte (sans
cardinalits).
Cet exemple simple permet de se poser quelques questions qui vont conduire une ror-
ganisation du modle.
Que se passe-t-il si lon possde plusieurs exemplaires du mme
ouvrage ?
Le numro ISBN nest plus identifiant puisquil est le mme pour chacun des exemplaires.
Une solution consiste ajouter un numro supplmentaire unique pour chaque livre, qui
correspond la notion de cote dans une bibliothque. Ainsi, mme si lon a dix exemplai-
res dun ouvrage, il est possible de les diffrencier. Linconvnient de cette solution est que
lon rpte les informations communes aux diffrents ouvrages (titre, auteur) chaque
exemplaire. Lun des risques est de rpter incorrectement ces informations et daboutir
ainsi des incohrences.
La solution correcte dans ce cas est de sparer lentit livre en deux entits livre et
ouvrage (voir figure 2.10). Lactivit de la bibliothque est alors dcrite par deux phrases :
Un lecteur emprunte un exemplaire.
Un livre reprsente un exemplaire dun ouvrage.
Un livre est caractris par un numro (cote) identifiant et un ISBN. Un ouvrage est carac-
tris par un ISBN, qui est bien dans ce cas un identifiant, un titre, un auteur et un diteur.
Dans cet exemple, lobjet du modle conceptuel livre, utilis comme entit, est dcom-
pos en deux autres entits dont une est abstraite : louvrage. Louvrage est un regroupe-
ment dattributs qui na pas dexistence tangible dans le monde rel.
Lecteur
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Titre
Auteur
#ISBN
diteur
Livre

37 Analyse du monde rel
Chapitre
Figure 2.10
Entits livre,
ouvrage et
lecteur lies par
les associations
emprunte et est
un exemplaire
(sans
cardinalits).
Que se passe-t-il si louvrage possde plusieurs auteurs ?
Une solution simpliste est de prvoir un champ par auteur supplmentaire, cest--dire
dajouter des champs auteur2, auteur3, auteur4, etc. Cette solution pose de nombreux
problmes :
Si seulement dix livres sur un million possdent plusieurs auteurs, on rserve la place
pour les champs auteurs supplmentaires qui sera inutilise.
Si un livre possde un nombre dauteurs suprieur au nombre de champs prvus, on
ne rsout pas le problme.
Si lon considre quun auteur peut avoir crit plusieurs ouvrages, on rpte dans ce cas
les informations le concernant pour chacun de ses ouvrages. Cela constitue un cas
typique de redondance qui risque de provoquer des incohrences.
La solution correcte dans ce cas est de crer une entit supplmentaire pour ces attributs
qui sont smantiquement de mme type. On crera ici une entit auteur qui contiendra
un numro dauteur (identifiant), son nom et son prnom. Cette entit est relie lentit
ouvrage par lassociation a_crit (voir figure 2.11).
Figure 2.11
Entits livre,
ouvrage,
auteur et
lecteur lies par
les associations
emprunte,
a_crit et est un
exemplaire (sans
cardinalits).
Ouvrage
#Cote
ISBN
Lecteur
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Est un
exemplaire
Titre
Auteur
#ISBN
diteur
Livre
Ouvrage
#Cote
ISBN
Lecteur
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Titre
#ISBN
diteur
Livre
Est un
exemplaire
Auteur
# NumAuteur
Nom
Prnom
A crit

38 Cration de bases de donnes
Que se passe-t-il si un auteur emprunte un livre ?
Un auteur peut galement emprunter un livre et revtir par consquent le rle de lemprun-
teur. Dans ce cas, on rpte les informations le concernant dans lentit lecteur. De mme
que prcdemment, cela provoque de la redondance et peut gnrer des incohrences.
Comme les entits lecteur et auteur ont la mme structure (cest--dire des mmes
attributs), la solution consiste les fusionner en une entit unique personne. Cette opra-
tion conduit une association entre les entits personne et livre (emprunte) et les enti-
ts personne et ouvrage (a_crit) (voir figure 2.12).
Figure 2.12
Entits livre,
ouvrage,
personne lies
par les associations
emprunte,
a_crit et
est_un_exemplaire
(sans
cardinalits).
On a identifi dans cette sous-section plusieurs cas qui ncessitent de rorganiser les enti-
ts obtenues lors dune premire analyse :
Si lon repre lintrieur dune entit des attributs qui reprsentent un ensemble logi-
que (mis en valeur dans lexemple par un dfaut didentifiant pour un livre), on spare
ces attributs dans une entit supplmentaire.
Si des attributs dans une mme entit possdent une smantique identique (auteurs,
numros de tlphone multiples), on cre une entit supplmentaire pour sparer ces
attributs. Cette entit sera associe celle dont proviennent les attributs lorigine.
Si des entits ont la mme structure (et reprsentent le mme type dobjet), on les
fusionne et lon conserve les associations qui existaient avant la fusion.
On retrouvera ce processus de remise en question du modle un autre niveau, lors de
ltape de normalisation qui est aborde au chapitre 3.
3.3 LIMINATION ET FUSION DASSOCIATIONS
Dans cette sous-section, on sintresse la rorganisation dassociations qui nont pas de
raison dtre, par une fusion des associations ou par leur intgration dans les entits.
limination dassociations
On considre le cas dun acte dachat effectu sur Internet avec une carte bancaire. Une
facture est rgle par une carte. On peut distinguer les deux entits facture et carte .
Une facture est identifie par un numro de facture, et est constitue dun montant et
dune date. Une carte bancaire est identifie par son numro, son type (Visa, Master-
Card), sa date de validit et son propritaire. Les cardinalits entre les entits carte et
facture sont de type 1-1 (une facture est paye par une et une seule carte) et 1-n (une
Ouvrage
#Cote
ISBN
Personne
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Titre
#ISBN
diteur
Livre
Est un
exemplaire A crit

39 Analyse du monde rel
Chapitre
carte peut servir rgler plusieurs factures). On peut utiliser une Ecarte qui permet
damliorer la scurit de ces transactions. Une Ecarte est une carte virtuelle associe
une vritable carte bancaire, valable pour une seule transaction. Les cardinalits
deviennent alors de type 1-1 des deux cts : une Ecarte ne permet de rgler quune et
une seule facture (voir figure 2.13).
Figure 2.13
Entits carte et
facture lies par
lassociation
rgle avec ses
cardinalits.
Dans ce cas, lassociation rgle na plus lieu dtre puisquil sagit dune pure bijection :
une facture correspond une Ecarte et une seule, et une Ecarte correspond un produit et
un seul. On peut fusionner les deux entits carte et facture et liminer lassociation (voir
figure 2.14).
Figure 2.14
Entit facture_bis
fusionne.
Fusion dassociations
Suivant le mme principe, il est possible de fusionner plusieurs associations ayant le mme
rle smantique. Si lon considre la description de lactivit suivante, lie lexcution de
morceaux de jazz en quartet. Pour un morceau donn, le premier musicien joue la partie
de basse, le deuxime celle de batterie, le troisime celle de piano et le quatrime celle de
saxophone (voir figure 2.15).
Figure 2.15
Entits musicien
et morceau lies
par les
associations
basse, batterie,
piano et
saxophone.
Comme il sagit de la mme activit (un musicien interprte un morceau), on peut rempla-
cer toutes les associations par une association interprte. Lassociation interprte contien-
drait lattribut instrument pour ne pas perdre linformation de linstrument associ (voir
figure 2.16).
Carte
#NumCarte
Type
DateValidit
Propritaire
Facture
# NumFacture
Montant
DateFacture
Rgle
1,1
1,1
# NumFacture
Montant
DateFacture
NumCarte
Type
DateValidit
Propritaire
Musicien
#NumMusicien
Nom
Prnom
Morceau
# NumMorceau
Titre
Piano
0,n
0,n
Basse
0,n
0,n
0,n
Batterie
0,n
0,n
0,n
Saxophone

40 Cration de bases de donnes
Figure 2.16
Entits musicien
et morceau lies
par lassociation
interprte.
Dans cette section, on a essay de porter un regard critique sur le modle conceptuel
brut issu dune premire phase danalyse que lon a obtenue en utilisant les techniques
nonces dans les sections prcdentes. Cette tape fait partie intgrante du processus it-
ratif de constitution du modle par raffinements successifs. Le processus se poursuivra
un autre niveau par la normalisation des relations dduites de ce modle. Cette partie sera
traite au chapitre 3.
4 Reprsentation avec UML
Le langage UML (Unified Modeling Language) est un standard labor linitiative de
lOMG (Object Management Group). Il est donc spcifiquement destin la modlisation
objet. Comme son nom lindique, UML est le rsultat dun processus de fusion (unifica-
tion) de diffrentes mthodes existantes dans le domaine de la conception objet : Booch,
OMT, OOSE. Ces concepts reposent principalement sur les travaux de Grady Booch,
James Rumbaugh et Ivar Jacobson. Cest un langage indpendant de la plate-forme utilise
ainsi que des autres langages de plus bas niveau employs en programmation objet,
comme Java et C++. Il utilise une notation graphique et a connu trs rapidement le succs
dans le monde objet par la souplesse quil apporte en gestion de projets de dveloppement.
4.1 UML ET BASES DE DONNES
Quel est le rapport avec les bases de donnes ? UML a t adapt afin dtre utilis pour la
modlisation en bases de donnes : on recourt cet effet un profil spcifique (UML pro-
file for data modeling). Mme sil est prvu initialement uniquement pour la modlisation
objet, UML permet aussi de reprsenter un modle conceptuel utilisable pour crer des
bases de donnes relationnelles et relationnelles-objet. Les approches objet et relationnel-
les-objet en bases de donnes ont t introduites dans le premier chapitre et dpassent lar-
gement le cadre de cet ouvrage.
En outre, une motivation supplmentaire pour utiliser UML est de pouvoir disposer doutils
logiciels graphiques du march pour la description et lautomatisation du processus de pas-
sage au SGBD, allant jusqu la gnration de code SQL. UML offre des garanties de pren-
nit du fait de sa normalisation. Mme si UML napporte pas dvolutions majeures quant
aux mthodes existantes de modlisation en bases de donnes, il est de plus en plus large-
ment rpandu et permet dutiliser le mme formalisme et les mmes outils que les concep-
teurs dapplications logicielles.
Remarque
Il en serait diffremment pour des associations entre ces deux entits qui exprimeraient un autre
sens. Si lon considre lassociation compose ou arrange entre les entits musicien et mor-
ceau, il ne sagit pas de la mme activit que lassociation interprte : on ne fusionnera pas les
associations dans ce cas.
Musicien
#NumMusicien
Nom
Prnom
Morceau
# NumMorceau
Titre
Interprte
1,n
1,n
Instrument

41 Analyse du monde rel
Chapitre
4.2 REPRSENTATION DU MODLE CONCEPTUEL AVEC LES DIAGRAMMES
DE CLASSES UML
UML a t dvelopp lorigine pour la modlisation des concepts objet. La tendance
actuelle consiste utiliser une partie restreinte de ce puissant langage de modlisation,
afin de reprsenter le modle conceptuel des donnes. Dans sa version complte, UML
propose neuf types de diagrammes rpartis en deux catgories : les diagrammes de struc-
ture qui dcrivent la partie statique du modle ; les diagrammes de comportement qui
dcrivent la partie dynamique, cest--dire les traitements. On utilise les diagrammes de
classes qui font partie des diagrammes de structure pour reprsenter les lments du
modle conceptuel.
Classes
Dans ce type de reprsentation les entits sont interprtes comme des objets et sont
reprsentes par des classes. La description dune classe en UML comprend trois parties :
le nom de la classe ;
la description des attributs ;
les mthodes associes lobjet.
Cette section nutilise pas la notion de mthode spcifique lapproche objet. La descrip-
tion des attributs peut tre ralise de manire plus prcise. UML offre la possibilit de
dcrire ce niveau le domaine de lattribut :
jour : (lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche)
Une classe est reprsente graphiquement par un rectangle spar en trois zones corres-
pondant aux trois parties prcdentes (voir figure 2.17).
Figure 2.17
Entit voiture
reprsente par
une classe UML.
Associations et multiplicit
Les classes sont relies par des associations identifies par leur nom. Si lassociation pos-
sde elle-mme des attributs, ils sont intgrs dans une classe dassociation. Lexpression
des cardinalits est quasiment la mme en UML que pour le modle entit-association ;
elles sont appeles multiplicit. UML permet de dfinir plus prcisment les cardinalits
en utilisant les valeurs suivantes.
1. Obligatoire, un et un seul (peut scrire galement 1..1).
*. Non obligatoire (peut scrire galement 0..n).
Remarque
UML est un formalisme de reprsentation. Il nest associ aucune mthode particulire comme
peut ltre la mthode Merise qui associe une mthodologie et un langage de description.
Voiture
# NumVoit
Marque
Type
Couleur
Nom de la classe
Attributs
Mthodes

42 Cration de bases de donnes
0..1. Non obligatoire restreint 1.
1..*. Obligatoire.
2..4. Obligatoire restreint de 2 4.
Les associations sont matrialises par un trait entre les classes reprsentant les entits. Le
nom de lassociation est inscrit au-dessus du trait. Dans le cas o lassociation possde des
attributs, on utilise une classe dassociation sans nom qui contiendra les attributs. La
classe dassociation est relie par un trait pointill (voir figure 2.18).
Figure 2.18
Entits voiture et
client lies par
lassociation
vente
reprsentes par
une classe UML.
On peut dcrire plus finement lassociation en spcifiant un rle de lassociation pour
chacune des classes associes. Cest--dire que lon distingue, du point de vue de chacune
des classes impliques dans lassociation, la manire dont elle est associe une autre
classe par un terme spcifique : le rle. Comme les cardinalits sont diffrentes pour cha-
cune des classes impliques dans une association, on dispose alors dune description com-
plmentaire. La notion de rle est surtout utile lorsquune classe est associe elle-mme.
Par exemple, si lon considre les classes voiture et client (voir figure 2.19), du point de vue
de la classe voiture, la classe client a le rle dacheteur. Du point de vue de la classe client,
la classe voiture a le rle dune dpense. Ainsi, on note le nom du rle au mme emplace-
ment que celui de lassociation (au-dessus du trait), mais du ct de la classe concerne.
Figure 2.19
Classes voiture
et client lies par
lassociation
vente avec des
rles.
4.3 DU MODLE ENTIT-ASSOCIATION UML
La notation UML est utilise dans cette section pour reprsenter les entits et les associa-
tions issues de la dmarche danalyse primitive que lon a dcrite dans la premire sec-
Remarque
Attention, la position des cardinalits dans un diagramme de type UML est inverse par rapport
celle utilise dans un diagramme de type modle entit-association prsente dans ce chapitre.
En effet, UML utilise la notation employe aux tats-Unis, mal adapte la reprsentation dasso-
ciation de degr suprieur aux associations binaires.
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
# NumVoit
Marque
Type
Couleur
Vente
DateVente
Prix
0..1 1..*
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
# NumVoit
Marque
Type
Couleur
Acheteur
Dpense

43 Analyse du monde rel
Chapitre
tion. La correspondance qui est faite avec celle fonde sur le modle entit-association est
la suivante :
Une entit est reprsente par une classe.
Une association est reprsente par une association.
Une cardinalit est reprsente par une multiplicit.
ce niveau dutilisation, les avantages quapporte la notation UML napparaissent pas
clairement. Lintrt rside dans la possibilit dutiliser des outils logiciels. Ces derniers,
partir du schma du modle conceptuel exprim en UML, automatisent, ou plutt assis-
tent, le processus de passage au modle relationnel qui sera abord au chapitre 3.
Lide terme est de gnrer automatiquement le langage SQL ncessaire, comme cela se
fait en gnie logiciel o lon gnre le code du langage utilis. En revanche, lutilisation
dUML prendra tout son sens pour une modlisation plus complexe utilisant par exemple
le concept objet dhritage qui dpasse le cadre de cet ouvrage.
Rsum
Ce chapitre aborde lapproche de la modlisation, qui consiste dabord extraire les infor-
mations du monde rel puis en proposer une reprsentation formelle appele modle
conceptuel. Il nexiste pas rellement de dmarche scientifique pour raliser cette
tape. Elle est plutt constitue dun ensemble de techniques diverses qui permettent
dapprhender la complexit du monde rel modliser et de la simplifier.
Lanalyse du monde rel a pour but de pouvoir identifier les donnes qui interviennent
dans le domaine considr et de les regrouper dans des objets. Ltape suivante consiste
caractriser les liens qui les unissent. cette fin, on dcrit le systme modliser par des
phrases simples de type sujet-verbe-complment , que lon peut classer en deux gran-
des catgories :
celles qui dcrivent les objets du monde rel et les liens qui les unissent : le sujet et le
complment sont reprsents par des entits (classes) et le verbe est reprsent par une
association ;
celles qui dcrivent la manire dont sont relis ces objets : on en dduira les cardinalits
(ou multiplicits dans le cas dutilisation dUML) des associations.
Les entits sont constitues de champs de donnes que lon nomme attributs . Pour
identifier de manire unique les reprsentants dune entit, appels galement
instance , un attribut (ou un ensemble dattributs) est choisi : on lappelle
identifiant . Une fois les lments modliser identifis, leur reprsentation normalise
recourt diffrents langages. Les deux types de formalismes les plus courants employs
sont les suivants :
Le modle entit-association. Il a fait ses preuves ; sa notation est trs intuitive et il est
encore couramment utilis.
UML (Unified Modeling Language). Il reprsente (probablement) lavenir, car il est
soutenu par une communaut trs importante qui dpasse celle des bases de donnes.
Il offre lavantage dtre bien adapt la modlisation de donnes complexes qui nces-
sitent une approche objet.
Ni le modle entit-association, ni UML ne sont des mthodes danalyse ; il sagit dans les
deux cas de simples formalismes de reprsentation.

44 Cration de bases de donnes
Exercices
EXERCICE 1 IDENTIFIANT DUNE ENTIT
Si lentit dcrit des cinmas situs sur le territoire franais par exemple, le nom du cinma
nest pas significatif : le Rex existe dans bon nombre de villes. Il en est de mme pour le
nom de la salle : on peut imaginer sans peine que plusieurs cinmas possdent une salle
John Cassavettes .
Les autres attributs peuvent difficilement prtendre identifier une salle de cinma : le
nombre de places et la taille sont communs beaucoup de salles ainsi que la ville. Si lon
essaie la combinaison Nom du cinma & Nom de la salle, on court le risque que deux
cinmas Camo disposent de la mme salle Franois Truffaut .
Finalement, un identifiant possible serait la combinaison Nom du cinma & Nom de la
salle Ville du cinma. Il est peu probable en effet que la mme ville dispose de plusieurs
cinmas du mme nom encore que ce soit du domaine du possible. Dans ce cas, il est
prfrable de crer un champ identifiant de toutes pices qui identifiera la salle. Classique-
ment, on utilisera un chiffre identifiant que lon peut nommer Numero_salle.
EXERCICE 2 IDENTIFICATION DES ENTITS ET DES ASSOCIATIONS
Les lments qui simposent intuitivement sont les spectateurs et la pice joue. La phrase
qui reprsente le lien entre ces entits peut tre de la forme : les spectateurs achtent un
billet pour une pice .
On identifie deux entits spectateur et pice lies par lassociation achat.
Lentit spectateur contient les attributs nom, numro de tlphone. On cre un identi-
fiant numero_client puisque nom et numro de tlphone ne sont pas identifiants. On
On considre lentit ci-aprs, qui dcrit des salles de cinmas. Les attributs de cette entit
sont les suivants :
nom de la salle ;
nom du cinma ;
ville du cinma ;
nombre de places ;
taille de lcran.
Que proposez-vous comme identifiant pour cette entit ?
On veut modliser lactivit de vente de billets pour un thtre. Quelles phrases vont nous
permettre didentifier les entits et la manire dont elles sont associes ? Proposez les at-
tributs que vous utiliseriez pour dcrire ces entits et leurs associations ainsi que les iden-
tifiants de chaque entit. Que se passe-t-il si le prix du billet varie pour chaque sance et
en fonction de la place ?

45 Analyse du monde rel
E
x
e
r
c
i
c
e
s
Chapitre
pourrait ventuellement utiliser la combinaison des deux attributs comme identifiant, car
deux personnes de mme nom ont rarement le mme numro de tlphone, mais il est
prfrable de crer un identifiant dans ce cas.
Lentit pice comprend un titre, lauteur, le metteur en scne et le prix dune place (on
suppose que toutes les places sont au mme prix). De mme que pour lentit spectateur,
on a besoin de crer un identifiant pour la pice.
Lassociation a pour attributs la date et le numro de sige. Ces attributs sont en effet carac-
tristiques de laction dachat et non pas du spectateur ou de la pice (voir figure 2.20).
Figure 2.20
Entits
spectateur et
pice lies par
lassociation
achat (sans
cardinalits).
Si le prix des places varie pour chaque sance, il est non plus une caractristique de la
pice, mais de lachat. Lattribut prix devient un attribut de lassociation achat. Il ny a
jamais de solution unique en base de donnes. On aurait pu, par exemple, utiliser une
entit billet lie aux deux entits spectateur et pice.
EXERCICE 3 QUESTIONS ASSOCIES AUX CARDINALITS
Dans lexemple sur la bibliothque, prsent prcdemment dans ce chapitre, on est par-
venu au modle suivant la suite de la remise en cause du modle (voir figure 2.21) :
Les entits livre ouvrage sont lies par lassociation est_un_exemplaire
Les entits personne et livre sont lies par lassociation emprunte.
Les entits personne et livre sont lies par lassociation a_crit.
Figure 2.21
Entits livre,
ouvrage, personne
lies par les associa-
tions emprunte,
a_crit et
est_un_exemplaire
(sans cardinalits).
Spectateur
# Num
Nom
Tel
Pice
Achat
# NumPiece
Titre
Auteur
MetteurScene
Prix
DateAchat
NumSiege
Ouvrage
#Cote
ISBN
Personne
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Titre
#ISBN
diteur
Livre
Est un
exemplaire
A crit

46 Cration de bases de donnes
On doit dterminer pour chaque association les deux cardinalits minimales et maximales
associes aux deux entits lies, puisquil sagit dassociations binaires. Il y aura donc qua-
tre questions (se) poser par association. On pose ici les questions et on propose les
rponses ; dans la vie relle, ce sont les utilisateurs de la base de donnes qui apporteraient
les rponses (voir figure 2.22).
Association est_un_exemplaire
Pour dterminer les cardinalits du ct de lentit ouvrage :
Peut-on avoir une fiche douvrage sans disposer du livre lui-mme dans la
bibliothque ? Si cest le cas, la valeur minimale sera de 0, sinon elle sera 1. La valeur
1 est plus logique dans ce contexte, sauf si lon a rcupr le catalogue descriptif dun
diteur.
Une fiche douvrage peut-elle servir plusieurs livres ? Si cest le cas, la valeur maxi-
male sera de n ; sinon, elle sera de 1. Cest le but ici de regrouper les informations
douvrages communes plusieurs exemplaires. La cardinalit maximale choisie est de
n.
Pour dterminer les cardinalits du ct de lentit livre :
Peut-on avoir un livre sans avoir de fiche ouvrage ? Si cest le cas, la valeur minimale
sera de 0, ; sinon, elle sera de 1. Il parat clair que tout livre a une fiche ouvrage,
moins quil ne soit juste identifi dans la bibliothque mais pas encore catalogu.
Un livre peut-il avoir plusieurs fiches ouvrage ? Si cest le cas, la cardinalit maximale
sera de n ; sinon, elle sera de 1. On peut supposer quun livre na quune fiche
ouvrage.
Association emprunte
Pour dterminer les cardinalits du ct de lentit livre :
Un livre peut-il navoir jamais t emprunt ? Si cest le cas, la valeur minimale sera de
0 ; sinon elle sera de 1. On choisit 0 : un livre peut ne rencontrer aucun succs.
Un livre peut-il tre emprunt plusieurs fois ? Si cest le cas, la valeur maximale sera de
n ; sinon elle sera de 1. On rappelle quune base de donnes modlise une activit sur
une priode de temps. Un livre peut tre emprunt plusieurs fois mme si lon ne peut
pas le prter deux personnes simultanment. On choisit n.
Pour dterminer les cardinalits du ct de lentit personne :
Une personne peut-elle ne pas avoir emprunt de livre ? Si cest le cas, la valeur mini-
male sera de 0 ; sinon, elle sera de 1. Une personne ne sinscrit la bibliothque que
dans le but demprunter un livre ; elle en a donc au moins emprunt un. On choisit 1.
Une personne peut-elle emprunter plusieurs livres ? Si cest le cas, la cardinalit maxi-
male sera de n ; sinon, elle sera de 1. On choisit n : un lecteur nest pas limit
lemprunt dun seul livre.
Association a_crit
Pour dterminer les cardinalits du ct de lentit ouvrage :
Un ouvrage peut-il ne pas avoir dauteur ? Si cest le cas, la valeur minimale sera de 0 ;
sinon, elle sera de 1. On choisit 1 : on suppose quil ny a pas de livre anonyme.
Quelles questions faut-il poser aux utilisateurs de la base de donnes pour dterminer les
cardinalits des associations ? Proposez une rponse ces questions et dduisez-en les
cardinalits pour chaque entit.

47 Analyse du monde rel
E
x
e
r
c
i
c
e
s
Chapitre
Un ouvrage peut-il avoir plusieurs auteurs ? Si cest le cas, la valeur maximale sera de
n ; sinon, elle sera de1 : un livre peut avoir plusieurs auteurs ; ctait dailleurs la
motivation pour crer lentit auteur. On choisit donc n.
Pour dterminer les cardinalits du ct de lentit personne :
Une personne peut-elle ne pas avoir crit de livre ? Si cest le cas, la valeur minimale
sera de 0 ; sinon, elle sera de 1. On choisit 0 : une personne peut ne pas tre un
auteur.
Une personne peut-elle tre lauteur de plusieurs livres ? Si cest le cas, la cardinalit
maximale sera de n ; sinon, elle sera de1. On choisit n : un auteur peut crire plu-
sieurs livres.
Figure 2.22
Entits livre,
ouvrage,
personne lies
par les
associations
emprunte,
a_crit et
est_un_exemplaire
(avec
cardinalits).
EXERCICE 4 DESCRIPTION DU MONDE REL PARTIR DES CARDINALITS
On considre le schma entit-association, muni de ses cardinalits, qui dcrit une partie
de lorganisation de sminaires (voir figure 2.23).
Figure 2.23
Entits
sminaire,
thme,
intervenant
lies par les
associations
traite,
est_responsable
et intervient
(avec
cardinalits).
Ouvrage
#Cote
ISBN
Personne
# NumLecteur
Nom
Prnom
Adresse
Emprunte
DateEmprunt
Titre
#ISBN
diteur
Livre
Est un
exemplaire
A crit
0,n
1,n
1,1
0,n
1,n
1,n
Thme
# NumThme
Libell
Sminaire
# NumSminaire
DateSem
NbeJours
NbeInscrits
Prix
Traite
# NumInter
Nom
Prnom
Intervient
Anime
0,n
0,n
1,1
1,n
Est_responsable
Prime
0,n
1,1
Salaire
NbeHeures

48 Cration de bases de donnes
Un sminaire traite dun thme et dun seul (cardinalit 1-1). Un thme peut tre trait
par aucun sminaire ou par plusieurs (cardinalit 0-n).
Un sminaire a un intervenant au minimum (cardinalit 1-n). Un intervenant peut inter-
venir dans plusieurs sminaires ou aucun (cardinalit 0-n).
Un sminaire a toujours un responsable et un seul (cardinalit 1-1). Un intervenant peut
ntre responsable daucun sminaire ou ltre de plusieurs (cardinalit 0-n).
EXERCICE 5 ASSOCIATION INUTILE
On identifie aisment les entits parasite et hte comme les sujets ou les complments des
phrases de type sujet-verbe-complment qui dcrivent le systme. Les cardinalits
seront de type 1-1 de chaque ct : chaque hte est associ de manire unique un
parasite et inversement. Les associations de cardinalits 1-1 de chaque ct sont gnra-
lement inutiles : il est prfrable de les remplacer par une entit unique mme si lon perd
en lisibilit au niveau du schma. On fusionne les entits parasite et hte en une seule
entit cosystme (voir figure 2.24).
Figure 2.24
Entits parasite-
hte lies par
lassociation
utilise et fusion
en une entit
unique.
Quelle description pouvez-vous donner du lien entre les diffrentes entits partir des
cardinalits ?
On dcrit une (partie de la) ralit biologique dun systme parasite-hte de la manire
suivante :
Un parasite utilise un et un seul type dhte.
Un hte a un et un seul parasite.
Dcrivez les entits et les associations que vous identifiez partir de cette description et
dduisez-en les cardinalits associes. Que proposez-vous pour amliorer le schma ?
Parasite
# NumParasite
NomPara Hte
Utilise
1,1
1,1
# NumHte
NomHte
cosystme
# NumHte
NomHte
NumParasite
NomPara

49 Analyse du monde rel
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 6 ASSOCIATION RFLEXIVE
On pourrait diffrencier les humains/animaux des vgtaux et crer deux entits diffrentes.
Mais comme les humains mangent des animaux et des vgtaux et que les animaux mangent
galement dautres animaux et des vgtaux, il nest pas pertinent de les sparer pour
reprsenter ce type dinformation. On utilise une seule entit humain_animal_vgtal qui est
lie elle-mme par lassociation mange. Les cardinalits sont de type 0-n (voir figure 2.25) :
Un humain_animal_vgtal peut manger ou ne pas en manger un autre (un vgtal ne
mange pas ses congnres).
Un humain_animal_vgtal peut tre mang ou ne pas tre mang par un autre.
Figure 2.25
Entit
humain_animal
_vgtal lie par
lassociation
mange (avec
cardinalits).
EXERCICE 7 ASSOCIATION TERNAIRE
On doit dfinir une nouvelle entit vendeur. En effet, les informations du vendeur sont
indpendantes de celles des voitures ou des clients. On peut envisager le cas o lon ajoute
les informations du vendeur comme attributs de lassociation vente, mais un vendeur est
susceptible de raliser plus dune vente. On rpterait alors ces informations, identiques
pour le mme vendeur, avec les risques dincohrence classiques.
Lentit vendeur est lie lentit voiture mais galement lentit client. Ces liens sont
crs par lopration de vente :
Un vendeur vend une voiture.
Un vendeur vend un client.
On veut reprsenter les liens de nourriture entre des humains, des animaux et des vg-
taux. Lide, partir des schmas dalimentation modliss, est de pouvoir dduire des
chanes alimentaires de ce type : un homme mange un lapin qui mange des carottes .
partir de la base de donnes exemple de vente de voitures, on souhaite ajouter les in-
formations concernant le vendeur qui a ralis la vente. Proposez une (ou plusieurs) mo-
dification(s) du modle entit-association labor prcdemment. Ajoutez les nouvelles
cardinalits introduites par cette modification.
vgtal
# IdHAV
NomHAV
Mange
0,n
0,n

50 Cration de bases de donnes
Cette nouvelle entit sera lie aux deux autres par lassociation vente. On se trouve dans le
cas o lassociation sera donc non plus de type binaire, mais ternaire. Les cardinalits
associes aux entits voiture et client ne changent pas ; elles sont de type 0-n ( une
personne peut acheter plusieurs voitures ou aucune ; une voiture peut tre vendue une
seule fois ou jamais ).
Pour une association de type ternaire, on emploie plus ou moins implicitement des cardi-
nalits de type 0-n. Cela correspond du ct du vendeur une phrase un peu ambigu de
la forme : un vendeur peut vendre aucune ou plusieurs voitures aucun ou plusieurs
clients . Comme on utilise la notation europenne, on neffectue pas de changements du
ct des entits client et voiture (voir figure 2.26).
Figure 2.26
Entits voiture,
client et
vendeur lies
par les
associations
ternaire vente
(avec
cardinalits).
Les associations ternaires sont parfois dlicates utiliser et difficiles reprsenter en UML
sans contorsions. De plus, les cardinalits perdent de leur pertinence dans ce contexte. Il
est souvent prfrable de remplacer cette association par une entit que lon relie aux
autres par des associations binaires.
Figure 2.27
Entits voiture,
client, vendeur
et vente lies par
des associations
binaire aprs
transformation de
lassociation
ternaire vente en
entit (avec
cardinalits).
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
# NumVoit
Marque
Type
Couleur
0,1
0,n
Vente
DateVente
Prix
0,n
Vendeur
# NumVendeur
Nom
Tl
Voiture
# NumVoit
Marque
Type
Couleur
Vendeur
# NumVendeur
Nom
Tl
1,n
Vente
# NumVente
DateVente
Prix
1,n
1,1
1,1
0,1
1,1
Client
NumAch
Nom
ge
Ville
Sexe

51 Analyse du monde rel
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 8 DE LNONC AU MODLE ENTIT-ASSOCIATION
On peut extraire de lnonc des phrases cls qui permettent de caractriser les entits et
leurs associations :
Un client rserve un film.
Un client loue un film.
Une personne joue dans un film.
Une personne ralise un film.
Trois entits apparaissent : client, film et personnel. Les entits client et film sont
relies par deux associations : rservation et location. Les entits film et personnel
sont relies par deux entits joue et ralise (voir figure 2.28).
Le fait dutiliser la mme entit pour un ralisateur et pour un acteur (regroups dans
personnel) provient du fait quun acteur peut en mme temps tre ralisateur. Si lon
sparait les entits, il y aurait alors une duplication de linformation concernant cette cat-
gorie acteurs/ralisateurs. Le reste de lnonc permet de dcrire les attributs des entits et
des associations.
Entit client
On a peu dinformations sur cette entit, si ce nest que le client possde un compte qui
fera partie de ses attributs. Les autres attributs ont t choisis classiquement (nom, pr-
nom, adresse, tl., etc.). Il est ncessaire dutiliser un attribut pour lidentifiant : ici, Num-
Client.
Entit film
Lentit est mieux dcrite par son titre, son genre, son prix et le nombre de DVD dans la
pochette. Il est galement ncessaire dutiliser un attribut pour lidentifiant : ici, Num-
Film.
Entit personnel
Lentit ne comprend que les informations nom et prnom. Il est galement ncessaire de
crer un attribut pour lidentifiant : ici, NumPers.
Vous dsirez grer un club de prt de DVD. Les clients (adhrents du club) versent une
somme sur leur compte lors de leur adhsion. Ils peuvent rserver le film avant de le louer
et peuvent le garder une semaine au maximum. Le prix de location du film est forfaitaire
par jour emprunt. Il leur est possible de se faire livrer le film chez eux : cette opration
est facture forfaitairement en plus.
Le film est dcrit par son titre, le genre du film, le ralisateur et les trois acteurs princi-
paux. On prcise galement le nombre de DVD (il peut y en avoir plusieurs dans la
pochette : making of , autres versions, etc.) et leur prix dachat qui permettra de dbi-
ter le compte du client en cas de non-retour du film.
Vous voulez pouvoir annuler et mettre jour les rservations et grer les comptes des
adhrents (par exemple ne plus prter au-del dun certain seuil). Vous vous servirez
galement de cette base de donnes pour effectuer des bilans (tels que le chiffre daffai-
res en fin de mois), des relances (les films non rendus temps) et des statistiques
(film le plus emprunt, meilleur client).
Proposez un modle entit-association pour cette activit.

52 Cration de bases de donnes
Association rservation
Lassociation a pour attribut la date de rservation et le nombre de jours de rservation.
On a ajout un champ identifiant de la rservation NumRs. Il nest pas absolument
ncessaire dun point de vue du modle, une association na pas besoin dun attribut iden-
tifiant, mais il facilitera la gestion.
Association location
Lassociation a pour attribut la date et le nombre de jours de location. On a ajout un
champ identifiant de la location, NumLoc, pour les mmes raisons que prcdemment.
Lattribut livraison indique si la livraison a t effectue, afin le cas chant de la facturer.
Associations joue et ralise
Les deux associations nont pas dattributs.
Figure 2.28
Entits clients,
film, personnel
lies par les
associations
rservation,
location, joue et
ralise (sans
cardinalits).
EXERCICE 9 REPRSENTATION AVEC UML
Les entits sont reprsentes par des classes UML. Les associations sont reprsentes par
des associations UML. Les associations location et rservation qui possdent des attri-
buts seront munies dune classe UML sans nom qui permet dutiliser ces attributs. Les car-
dinalits sont dduites des phrases suivantes :
Location :
Un client loue aucun ou plusieurs films (0..n).
Un film est lou aucune ou plusieurs fois (0..n).
Rservation :
Un client rserve aucun ou plusieurs films (0..n).
partir du modle entit-association modlisant le club de location de DVD prcdent,
faites sa reprsentation en utilisant UML. Proposez des cardinalits pour les associations
en les justifiant.
Client
# NumClient
NomClient
PrnomClient
AdresseClient
TlClient
Compte
Film
# NumFilm
Titre
Genre
Prix
NbDVD
Rservation
# NumPers
NomPers
PrnomPers
Personnel
Joue
Ralise
Location
# NumRs
NbeJourRs
DateRs
# NumLoc
NbeJourLoc
DateLoc

53 Analyse du monde rel
E
x
e
r
c
i
c
e
s
Chapitre
Un film est rserv aucune ou plusieurs fois (0..n).
Joue :
Une personne joue dans aucun ou plusieurs films (0..n).
Un film a au moins un acteur (1..n).
Ralise :
Une personne ralise aucun ou plusieurs films (0..n).
Un film a un et un seul ralisateur (1..1).
Enfin, la notation des cardinalits est inverse par rapport au modle entit-association
(voir figure 2.29).
Figure 2.29
Reprsentation
UML des entits
clients, film,
personnel lies
par les
associations
reservation,
location, joue et
ralise (avec
cardinalits).
EXERCICE 10 AUTRE EXEMPLE LE CAMPING LULIASTRU
Voici les phrases cls dduites de lnonc qui permettent de caractriser les entits et les
cardinalits des associations du modle entit-association :
Les clients louent des sjours, ils peuvent en louer plusieurs (1..n).
Les sjours peuvent tre lous par un ou plusieurs clients (du moment que les priodes
de location ne se chevauchent pas) (0,n).
Le camping lUliastru (lolivier sauvage), situ dans lextrme sud de la France, propose
ses clients diffrents types de locations : des bungalows toile pour 350 /semaine, des
caravanes pour 440 /semaine, des tentes pour 45 /jour. Les diffrentes formules offrent
un quipement complet et appartiennent au camping. Il est galement possible de louer
un emplacement tourisme la journe pour 28 /personne. Lensemble de ces loca-
tions sadresse un maximum de quatre personnes. Proposez un modle entit-associa-
tion modlisant cette activit de gestion en fonction des lments de lnonc.
Client
# NumClient
NomClient
PrnomClient
AdresseClient
TlClient
Compte
Film
# NumFilm
Titre
Genre
Prix
NbDVD
Rservation
# NumPers
NomPers
PrnomPers
Personnel
Joue
Ralise
Location
# NumRs
NbeJourRs
DateRs
# NumLoc
NbeJourLoc
DateLoc
0..n
0..n
0..n
0..n
0..n
1..n
0..n
1..n

54 Cration de bases de donnes
On en dduit les entits Sjour et Client, ainsi que lassociation Louer. La premire dif-
ficult que lon rencontre est lie la notion de temps. En effet, dans quelle entit doit tre
stocke la notion de dure de la location ncessaire la gestion ventuelle des
disponibilits ? Daprs lnonc, la dure de la location est fonction du type de location
(bungalows toile : 7 jours, caravanes : 7 jours, tentes : 1 jour, emplacements tourisme : 1
jour). Le client ne peut donc pas choisir la dure minimum; cette dernire est dtermine
en fonction du type de location. Par consquent, il convient de stocker lattribut
duree_mini modlisant la dure de location minimum dans lentit location. Lunit
commune lensemble des locations pour la facturation est la journe ; les dures sexpri-
ment alors en nombre de jours.
La seconde difficult est lie la notion de personne. Comment intervient-elle dans le
schma conceptuel ? Tout dabord, remarquons que, daprs la premire phrase cl, un
client peut reprsenter plusieurs personnes car il peut louer plusieurs locations. Par cons-
quent, le moyen dintgrer efficacement la limite de quatre personnes et les quantits
ncessaires la facturation des diffrents types de location consiste en lajout de lattribut
quantit dans lassociation Louer. Le client du modle reprsente la personne physique
que lon facture.
Finalement, voici le MCD de cette activit de gestion :
Sjour(Type, Dure_mini, Prix_ttc)
Client(ID, Nom, Prnom, Adresse, Ville, CP, Tlphone)
Louer(quantit, date_dbut)
La date de dbut de location dpend la fois du client et de la location ; cest la raison pour
laquelle elle apparat dans lassociation Louer. La date de fin dune location est calcule
partir de la dure minimale et de la quantit loue en fonction de la date de dbut de
location ; cest la raison pour laquelle il est inutile de la stocker.

Approche
relationnelle
55
Chapitre
1. Concepts ................................. 56
2. Oprations du modle
relationnel ................................ 60
3. Passage du modle conceptuel
au relationnel ........................... 68
4. Normalisation .......................... 70
5. Logique du premier ordre
et base de donnes ................... 76
Exercices
1. Relation, degr, cardinalit ........ 82
2. Cl dune relation ..................... 82
3. Contraintes dintgrit ............... 83
4. Opration ensembliste .............. 83
5. Projection ................................ 84
6. Restriction ................................ 85
7. Jointure ................................... 85
8. Autre jointure ........................... 87
9. Calcul sur des agrgats ............. 88
10. Passage du modle
entit-association au relationnel ... 89
11. Passage du modle
entit-association
au relationnel II ........................ 90
12. Normalisation .......................... 91
13. Normalisation II ........................ 92
14. Normalisation III ....................... 93
Lapproche relationnelle prsente par E. F. Codd
possde un fondement mathmatique rigoureux qui
lui assure sa robustesse : le modle relationnel est de
loin le plus rpandu dans le monde des bases de
donnes.
Ce chapitre prsente le concept de relation
fondamental du modle relationnel, ainsi que les
oprations qui lui sont associes. Puis on aborde les
mthodes qui permettent de passer du modle
conceptuel vu au chapitre prcdent (entit-
association ou UML) un ensemble de relations. La
qualit des relations ainsi produites est contrle par
leur conformit aux trois premires formes normales.
Ce processus peut conduire une rorganisation des
relations sans perte dinformation. La manire de
rsoudre les incohrences laide de la forme
normale de Boyce-Codd est galement prsente.
Enfin, le lien entre les bases de donnes et la logique
du premier ordre est rapidement expos, afin de
dcrire la mthode dinterrogation de base de
donnes par QBE (Query By Example) qui en dcoule.

56 Cration de bases de donnes
1 Concepts
Cette section expose la notion de relation et la terminologie qui lui est associe. On pr-
sente ensuite les diffrents types de contraintes associes au contenu dune relation, ainsi
que la notion de cl dune relation.
1.1 MODLE RELATIONNEL
Le modle relationnel tire son nom de la notion de relation mathmatique entre des l-
ments. Chacun de ces lments peut prendre des valeurs dans un ensemble dfini.
On suppose que lon considre les appareils electromnagers dune cuisine. Ils peuvent
tre contenus dans lensemble des valeurs suivantes : rfrigrateur, cuisinire, hotte, robot,
lave-vaisselle. On considre par ailleurs un ensemble de couleurs qui peuvent tre conte-
nues dans lensemble des valeurs suivantes : rouge, bleu, vert, jaune, blanc, noir, rose, jaune.
Les combinaisons possibles entre les appareils et les couleurs sont au nombre de 40,
puisquil y a 5 appareils que lon peut associer 8 couleurs. Parmi toutes ces combinaisons
possibles, on effectue une slection qui reprsente par exemple la description dune (hor-
rible) cuisine dans le monde rel. Ces couples de valeurs choisis reprsentent les faits de la
vie relle.
(rfrigrateur, rouge)
(robot,mauve)
(cuisinire,jaune)
(lave-vaisselle,rouge)
Cet ensemble de couples de valeurs lies entre elles, que lon nomme tuples dans le
modle relationnel, reprsente la relation entre les lments appareil et couleur. Un
tuple est aussi dsign par les termes nuplets ou enregistrements . On dsigne ga-
lement les lments constitutifs de ces couples par les termes attributs ou champs .
On peut crire formellement la relation de la manire suivante : ma_cuisine(appareil,
couleur). Cette criture reprsente le schma relationnel de la relation ma_cuisine. Les
valeurs nonces prcdemment pour les champs reprsentent leurs domaines, cest--
dire les ensembles de toutes les valeurs possibles pour un champ.
Une relation est totalement dcrite par :
le schma relationnel ;
les domaines des diffrents champs ;
les tuples qui la constituent.
Le nombre de champs de la relation sappelle son degr de la relation. Ici, la relation
ma_cuisine est de degr 2. Le nombre de tuples se nomme la cardinalit de la relation. La
relation ma_cuisine est de cardinalit 4. Attention, il ne sagit pas de la mme cardinalit
que pour le modle entit-association vu prcdemment.
On reprsente une relation par une table, correspondant la notion de tableau. Les tuples
correspondent aux lignes et les colonnes aux champs de la relation. Voici sous forme de
table une reprsentation de lexemple prcdent (voir figure 3.1).
Dans le modle relationnel, la relation est llment fondamental. Toutes les oprations
sur une ou plusieurs relations retourneront une relation. Un ensemble de relations relies
entre elles par des liens smantiques constitue une base de donnes.

57 Approche relationnelle
Chapitre
1.2 NOTION DE CL DUNE RELATION ET DPENDANCE FONCTIONNELLE
Lorsque que lon utilise une base de donnes, il est ncessaire daccder un enregistre-
ment par le contenu dun ou de plusieurs champs. On nomme cl dune relation un
champ, ou un ensemble de champs, dune relation qui permet didentifier prcisment un
enregistrement. Une relation peut comprendre plusieurs cls possibles ; ce sont les cls
candidates. La cl choisie doit tre minimale, cest--dire quelle doit contenir le mini-
mum de champs. Cette cl minimale ainsi dfinie est appele la cl primaire de la relation.
Une cl doit toujours contenir une valeur et celle-ci doit tre unique pour chacun des
enregistrements de la relation.
La cl ne peut tre dduite simplement partir du contenu de la relation ; on ne peut pr-
juger du contenu futur des enregistrements. Si lon prend la relation ma_cuisine vue pr-
cdemment, le champ Appareil semble tre une cl puisquil contient une valeur unique
pour chacun des enregistrements. Cependant, il est tout fait possible que la cuisine con-
sidre comprenne un autre rfrigrateur de couleur bleue, auquel cas la valeur ne serait
plus unique et ne permettrait pas de retrouver lenregistrement. Dans ce cas de figure, la
combinaison Appareil Couleur pourrait sembler tre une cl, mais on ne peut en tre
certain compte tenu de lvolution des donnes.
Pour dsigner une cl primaire, il faut donc galement prendre en compte le sens des
donnes dans la vie relle. Les relations qui existent entre les diffrents champs dune rela-
tion vont tre importantes : on exprime ces relations laide de dpendances fonction-
nelles. Une dpendance fonctionnelle existe entre deux ensembles de champs si les valeurs
contenues dans lun des ensembles de champs permettent de dterminer les valeurs conte-
nues dans lautre ensemble.
Cette proprit se traduit en termes mathmatiques de la manire suivante :
Soit Cx un ensemble de champs (x1,x2,x3) et Cy un ensemble de champs (y1,y2,y3)
dune relation R(d1,d2,x1,x2,x3,u1,u2,u3,y1,y2,y3).
Supposons que lon considre des valeurs (x1_i, x2_i, x3_i) et (x1_j, x2_j, x3_j)
telles que lon ait R(d1_i,d2_i,x1_i,x2_i,x3_i,u1_i,u2_i,u3_i,y1_i,y2_i,y3_i) et
R(d1_j,d2_j,x1_j,x2_j,x3_j,u1_j,u2_j,u3_j,y1_j,y2_j,y3_j).
On dit que Cy dpend fonctionnellement de Cx lorsque pour tout i et j si (x1_i, x2_i,
x3_i) est gal (x1_j, x2_j, x3_j) alors (y1_i,y2_i,y3_i) est gal
(y1_j,y2_j,y3_j).
Les dpendances fonctionnelles expriment la relation de hirarchie qui existe entre les
champs.
On considre lexemple de table suivant (voir figure 3.2), qui correspond la relation Lec-
teur(Numero_carte, Nom, Age, Ville, Etablissement). Cet exemple modlise les lecteurs
dune bibliothque.
Appareil Couleur
Rfrigrateur Rouge
Robot Mauve
Cuisinire Jaune
Lave-vaisselle Rouge
Figure 3.1
Table
ma_cuisine.

58 Cration de bases de donnes
Si lon examine les donnes, on remarque quil ne peut y avoir de dpendances fonction-
nelles entre les couples de champs (Ville, Etablissement) et les champs (Nom, Age). Il
existe un enregistrement (Laurence, 34) pour lequel les valeurs des champs (Nom, Age)
correspondent deux valeurs diffrentes de (Ville, Etablissement).
En revanche, on sait que, dans la ralit, un tablissement est situ dans une ville et une
seule (on le suppose pour cet exemple). Cela signifie quil existe une relation de dpen-
dance entre les champs Etablissement et Ville. Le contenu des champs Ville et Etablis-
sement des enregistrements de notre relation se conforment cette relation de
dpendance. A une valeur donne de Etablissement correspond bien une valeur unique
de Ville.
La valeur du champ Numero_carte est unique pour chacune des personnes. On constate
que ses valeurs sont identifiantes pour tous les autres champs de la relation. Chaque
champ dpend fonctionnellement du champ Numero_carte. Ses valeurs sont uniques et
jamais vides : cest une cl candidate. Dans cet exemple, cest la seule cl possible car les
autres champs nont jamais de valeur unique. Le champ Numero_carte est choisi comme
cl primaire de la relation.
Les dpendances entre les champs reprsentent les liens entre les diffrents lments du
monde rel. On rappelle quelles ne peuvent tre dduites du contenu de la relation, mme
si cela peut constituer un point de dpart. Elles sont donc dtermines durant la phase
prcdente danalyse du monde rel. Il est possible en revanche de vrifier si les enregistre-
ments prsents dans la relation se conforment ces dpendances. La dtermination des
dpendances fonctionnelles entre les champs est fondamentale pour ltape de normalisa-
tion, traite la section Normalisation . Elles sont galement la base de la mthode
dite de la relation universelle , qui sera aborde dans la section Normalisation .
Numero
_carte
Nom Age Ville Etablissement
1 Henri 10 Paris Universit Sorbonne
2 Stanislas 34 Paris Universit Jussieu
3 Henriette 44 Lyon CHU Bron
4 Dominique 19 Nancy Universit Poincar
5 Isabelle 56 Nancy INPL
6 Olivier 51 Marseille Universit Saint Charles
7 Henri 98 Paris Universit Sorbonne
8 Jerome 23 Nancy INPL
9 Laurence 34 Bordeaux Universit Victor Segalen
10 Christian 41 Paris Ecole Normale Suprieure
11 Antoine 16 Marseille Universit Saint Charles
12 Laurence 34 Paris Universit Jussieu
Remarque
Tous les champs qui ne font pas partie dune cl candidate dune relation possdent des dpen-
dances fonctionnelles avec cette cl.
Figure 3.2
Relation Lecteur.

59 Approche relationnelle
Chapitre
1.3 COHRENCE DES DONNES ET CONTRAINTES DINTGRIT
Afin de garantir la cohrence des donnes pour lensemble des relations constitutives de la
base de donnes, on applique des restrictions sur le contenu des donnes que lon nomme
contraintes dintgrit. La vrification de la cohrence se situe plusieurs niveaux :
adapter le contenu des champs par rapport au sens des donnes dans le monde rel ;
prserver la cohrence du contenu de lensemble des relations qui sont lies ;
liminer les problmes dincohrence dus la redondance : en effet la duplication des
donnes rend dlicates la maintenance et lvolution de la relation.
Adapter le contenu des donnes
La cohrence par rapport au sens des donnes est lie la notion de domaine de valeurs du
champ dj aborde : on parle de contrainte de domaine ou cohrence smantique. Par
exemple, lge dune personne ne peut tre ngatif ou excder 120. On a prcdemment
dfini une contrainte dintgrit sur lensemble des champs qui constituent une cl
primaire : une cl ne peut contenir de valeur nulles et ses valeurs doivent tre uniques. On
procde la dfinition des contraintes lors de ltape danalyse du monde rel. Leur mise en
uvre effective interviendra au moment de la cration de la relation et sera ralise par le
SGBD.
Prserver la cohrence des donnes
On rappelle quune base de donnes est constitue par un ensemble de relations relies
entre elles. Les contenus des champs capables de lier ces relations doivent tre cohrents
entre eux pour pouvoir effectuer lopration de jointure. Si lon considre lexemple de la
base de donnes exemple casse, on ne doit pas permettre la saisie dune valeur identifiant
une voiture dans la relation vente qui nexiste pas dans la relation voiture. On fait dans
ce cas rfrence au contenu dune colonne dune autre relation, le champ NumVoit de la
relation voiture, pour contrler le contenu du champ NumVoit de la relation vente. Le
champ NumVoit est alors une cl trangre qui permet de raliser la notion dintgrit
rfrentielle. De mme que prcdemment, on dtermine ces rfrences lors de la phase
danalyse du monde rel et le SGBD permet de les raliser. On prfre appliquer en gnral
ces contraintes non pas lors de la cration des relations, mais plutt lorsque les donnes
ont dj t insres, en particulier dans les relations de rfrences. Cette prcaution vite
les problmes de rfrences impossibles rsoudre entre les relations, ce qui provoque
parfois lincapacit insrer des donnes.
liminer la redondance des donnes
Les incohrences provoques par la redondance dinformation reprsentent le principal
souci du concepteur dune base de donnes. En effet, lorsque les donnes sont dupliques,
aucun mcanisme ne peut garantir que le changement de la valeur dune donne est rper-
cut correctement sur les autres donnes. Dans lexemple ci-dessus (voir figure 3.2) dune
relation des lecteurs de bibliothque, on remarque la redondance dinformation qui existe
entre les champs Ville et Etablissement. Si le nom de ltablissement INPL change, il
faut mettre jour toutes les lignes qui contiennent son nom. La redondance est mise en
vidence par la dpendance fonctionnelle qui existe entre ces deux champs. Dans cet
exemple, dtecter la redondance est vident. Cependant, il sagit gnralement dincoh-
rences dlicates dceler lorsque le nombre de relations est lev ou encore si le sujet
modlis par la base de donnes nest pas familier. Les incohrences de ce type seront rso-
lues par la rorganisation des relations lors de la phase de normalisation.

60 Cration de bases de donnes
2 Oprations du modle relationnel
La manipulation des donnes dans le modle relationnel se fait laide doprations for-
melles reposant sur des concepts mathmatiques issus de la thorie des ensembles : cest
lalgbre relationnelle. Les oprations de lalgbre relationnelle portent sur une ou plu-
sieurs relations (ou tables). Le rsultat retourn par ces oprations est toujours une rela-
tion (ou table).
Cette section prsente une liste non exhaustive des diffrentes oprations de lalgbre rela-
tionnelle. Ces dernires peuvent tre regroupes en plusieurs catgories :
les oprations classiques issues de la thorie des ensembles (union, intersection,
diffrence) ;
les oprations plus spcifiques du monde relationnel (projection, slection, jointure)
qui constituent les oprations fondamentales de lalgbre relationnelle ;
les oprations de types calcul et agrgats qui ne constituent pas rellement des opra-
tions fondamentales (ni ensemblistes, ni relationnelles) mais qui sont le complment
indispensable des prcdentes.
2.1 OPRATIONS ENSEMBLISTES
Lalgbre relationnelle emprunte un certain nombre de concepts la thorie des ensem-
bles. lexception du produit cartsien, ces oprations ont la particularit de ne pouvoir
sutiliser que pour des relations qui ont exactement la mme structure ou des structures
compatibles. Elles sont toutes de type binaire, car elles sappliquent deux relations.
Union
Lopration dunion consiste en la mise en commun des enregistrements de chaque relation.
Les enregistrements identiques ne sont intgrs quune seule fois. Dans lexemple ci-aprs
(voir figures 3.3 et 3.4), le tuple dont la valeur du champ Numero_carte vaut 3 ne sera pas
dupliqu. Lunion est reprsente par le caractre . Cette opration sert typiquement
la consolidation de donnes de mme type provenant de diffrentes sources.
Lecteur_1(Numero_carte, Nom, Age, Ville, Etablissement)
Lecteur_2(Numero_carte, Nom, Age, Ville, Etablissement)
Numero_carte Nom Age Ville Etablissement
1 Henri 10 Paris
Universit
Sorbonne
2 Stanislas 34 Paris
Universit
Jussieu
3 Henriette 44 Lyon CHU Bron
Numero_carte Nom Age Ville Etablissement
3 Henriette 44 Lyon CHU Bron
4 Dominique 19 Nancy
Universit Poin-
car
5 Isabelle 56 Nancy INPL
Figure 3.3
Relations
Lecteur_1et
Lecteur_2.

61 Approche relationnelle
Chapitre
Lecteur_1 Lecteur_2
Diffrence
Lopration diffrence consiste dsigner les enregistrements qui appartiennent une relation
sans appartenir lautre. La diffrence est reprsente par le caractre (voir figure 3.5).
Attention, cette opration nest pas symtrique ; le rsultat de lopration Lecteur_1
Lecteur_2 est en gnral diffrent de Lecteur_2 Lecteur_1. Elle permet par exemple dlimi-
ner des enregistrements dune relation par rapport une liste.
Lecteur_1 Lecteur_2
Intersection
Lopration intersection peut se dduire de la prcdente ; elle dsigne les enregistrements
qui sont communs aux deux relations. Lintersection est reprsente par le caractre
(voir figure 3.6). Elle permet de trouver les lments communs deux relations.
Lecteur_1 Lecteur_2
Produit cartsien
Le produit cartsien permet la combinaison des enregistrements de deux relations sans
tenir aucun compte du contenu des donnes. Les relations nont donc pas besoin davoir la
mme structure. Le caractre reprsentant le produit cartsien est X .
Numero_carte Nom Age Ville Etablissement
1 Henri 10 Paris
Universit
Sorbonne
2 Stanislas 34 Paris
Universit
Jussieu
3 Henriette 44 Lyon CHU Bron
4 Dominique 19 Nancy
Universit
Poincar
5 Isabelle 56 Nancy INPL
Numero_carte Nom Age Ville Etablissement
1 Henri 10 Paris
Universit
Sorbonne
2 Stanislas 34 Paris
Universit
Jussieu
Numero_carte Nom Age Ville Etablissement
3 Henriette 44 Lyon CHU Bron
Figure 3.4
Union des
relations
Lecteur_1 et
Lecteur_2.
Figure 3.5
Diffrence des
relations
Lecteur_1 et
Lecteur_2.
Figure 3.6
Intersection des
relations
Lecteur_1 et
Lecteur_2.

62 Cration de bases de donnes
ma_cuisine(Appareil, Couleur)
musicien(Nom, Instrument)
Lexemple a t choisi de manire montrer que les relations ne ncessitent pas de rap-
ports entre elles pour faire un produit cartsien. Combiner des appareils de cuisine et des
musiciens na aucun sens dans la ralit (voir figures 3.7 et 3.8).
Le_resultat(Appareil, Couleur, Nom, Instrument) = ma_cuisine(Appareil, Couleur) X
musicien(Nom, Instrument)
2.2 OPRATIONS RELATIONNELLES
Projection
La projection consiste extraire certains champs de la relation, ce qui donne cette der-
nire un degr infrieur la relation de dpart. Voici la relation obtenue partir de la rela-
tion Lecteur en projetant les champs Nom et Ville (voir figure 3.9).
Lecteur_proj(Nom, Ville)
Appareil Couleur
Rfrigrateur rouge
Robot mauve
Cuisinire jaune
Nom Instrument
Jaco Pastorius
Basse
lectrique
Bill Evans Piano
Appareil Couleur Nom Instrument
rfrigrateur rouge Jaco Pastorius
Basse
lectrique
rfrigrateur rouge Bill Evans Piano
robot mauve Jaco Pastorius
Basse
lectrique
robot mauve Bill Evans Piano
cuisinire jaune Jaco Pastorius
Basse
lectrique
cuisinire jaune Bill Evans Piano
Nom Ville
Henri Paris
Stanislas Paris
Figure 3.7
Relations
ma_cuisine et
musicien.
Figure 3.8
Produit cartsien
des relations
ma_cuisine et
musicien.
Figure 3.9
Projection des
champs Nom et
Ville de la
relation Lecteur.

63 Approche relationnelle
Chapitre
Intuitivement, dans une reprsentation de type table, on conserve uniquement les colon-
nes sur lesquelles la projection est faite.
Slection ou restriction
La slection consiste extraire les enregistrements de la relation. On utilise des critres
pour caractriser les enregistrements slectionns. Voici la relation obtenue partir de la
relation Lecteur en slectionnant les enregistrements dont le contenu du champ Ville est
Marseille (voir figure 3.10). La structure de la relation rsultat est la mme que celle de la
relation de dpart.
Lecteur_sel(Numero_carte, Nom, Age, Ville, Etablissement)
Intuitivement, dans une reprsentation de type table, on conserve uniquement les lignes
rpondant au critre.
Jointure
La jointure est lopration fondamentale de lalgbre relationnelle qui permettra dexpri-
mer le sens du lien entre les relations dans le monde rel. La liaison entre les relations
seffectue par le contenu commun dun champ. Lopration de jointure peut tre vue
comme une slection des enregistrements obtenus par le produit cartsien des relations,
dont les contenus du champ sur lequel on effectue la jointure sont gaux. On lappelle
dans ce cas une quijointure. Les champs dont on compare les contenus sont nomms
champs de jointure.
On considre les deux relations Lecteur_bis(Numro_carte, Nom, Num_Etablissement)
et Etablissement(Num_Etablissement, Ville, Nom_Etablissement) dont le contenu suit
(voir figure 3.11).
Henriette Lyon
Dominique Nancy
Isabelle Nancy
Olivier Marseille
Henri Paris
Jerome Nancy
Laurence Bordeaux
Christian Paris
Antoine Marseille
Laurence Paris
Numero_carte Nom Age Ville Etablissement
6 Olivier 51 Marseille
Universit Saint
Charles
11 Antoine 16 Marseille
Universit Saint
Charles
Nom Ville
Figure 3.10
Slection sur la
relation Lecteur.

64 Cration de bases de donnes
Lecteur_bis(Numero_carte, Nom, Num_Etablissement)
Etablissement(Num Etablissement, Ville, Nom_Etablissement)
Mme si lon ne dispose pas du modle conceptuel associ, on constate que lon peut relier
ces deux relations par le champ Num_Etablissement. Les informations concernant lta-
blissement de la relation Lecteur_bis sont stockes dans la relation Etablissement dont la
cl est le champ Num_etablissement. Pour obtenir la liste des lecteurs ainsi que les infor-
mations concernant leur tablissement, on effectue une jointure entre ces relations sur le
champ Num_Etablissement (voir figure 3.12).
Lecteur_joint_Etablissement(Numero_carte, Nom, Num_Etablissement_1,
Num_Etablissement_2, Ville, Nom_Etablissement)
Le champ Num_Etablissement y figure deux fois car une occurrence vient de la relation
Lecteur et lautre de la relation Etablissement. Afin de ne conserver quune valeur du
champ Num_Etablissement, on utilise lopration de jointure naturelle (voir figure 3.13).
Lecteur_jointnat_Etablissement(Numero carte, Nom, Num_Etablissement, Ville,
Nom_Etablissement)
Numero_carte Nom Num_Etablissement
1 Henri 1
2 Stanislas 2
3 Henriette 1
Num_Etablissement Ville Nom_Etablissement
1 Paris Universit Jussieu
2 Lyon CHU Bron
3 Nancy Universit Poincar
4 Paris Universit Sorbonne
Numero
_carte
Nom
Num_Etablis-
sement_1
Num_Etablis-
sement_2
Ville
Nom
_Etablissement
1 Henri 1 1 Paris Universit Jussieu
2 Stanislas 2 2 Lyon CHU Bron
3 Henriette 1 1 Paris Universit Jussieu
Numero_carte Nom
Num
_Etablissement
Ville
Nom
_Etablissement
1 Henri 1 Paris
Universit
Jussieu
2 Stanislas 2 Lyon CHU Bron
3 Henriette 1 Paris
Universit
Jussieu
Figure 3.11
Relations
Lecteur_bis et
Etablissement.
Figure 3.12
Jointure des
relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.
Figure 3.13
Jointure naturelle
des relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.

65 Approche relationnelle
Chapitre
On peut considrer lopration de jointure comme une slection sur le produit cartsien
des deux relations. On ne conserve que les lignes dont le contenu du champ sur lequel
seffectue la jointure est gal. Les lignes grises sont celles qui sont slectionnes lors dune
jointure (voir figure 3.14).
Produit_cartesien_Etablissement(Numero_carte, Nom, Num_Etablissement_1,
Num_Etablissement_2, Ville, Nom_Etablissement)
On verra au chapitre consacr SQL que cest lune des manires dcrire une jointure.
Jointure externe
La jointure externe nest pas rellement une opration de base de lalgbre relationnelle.
Elle est cependant ncessaire pour pouvoir rpondre plus facilement des questions du
type Quels sont les tablissements qui nont pas de lecteurs ? Il sagit dune opration
de jointure tendue qui inclut dans le rsultat les lignes nayant pas de correspondance sur
le contenu du champ de jointure. Voici le rsultat de la jointure externe de la relation Eta-
blissement avec la relation Lecteur sur le champ Num_Etablissement (voir figure 3.15).
On met en correspondance les valeurs du champ Num_Etablissement de toutes les lignes
de la relation Etablissement avec celles de la relation Lecteur.
Numero
_carte
Nom
Num_Etablis-
sement_1
Num
_Etablissement
Ville
Num_Etablis-
sement_2
1 Henri 1 1 Paris
Universit
Jussieu
1 Henri 1 2 Lyon CHU Bron
1 Henri 1 3 Nancy
Universit Poin-
car
1 Henri 1 4 Paris
Universit
Sorbonne
2 Stanislas 2 1 Paris
Universit
Jussieu
2 Stanislas 2 2 Lyon CHU Bron
2 Stanislas 2 3 Nancy
Universit Poin-
car
2 Stanislas 2 4 Paris
Universit
Sorbonne
3 Henriette 1 1 Paris
Universit
Jussieu
3 Henriette 1 2 Lyon CHU Bron
3 Henriette 1 3 Nancy
Universit Poin-
car
3 Henriette 1 4 Paris
Universit
Sorbonne
Figure 3.14
Produit cartsien
des relations
Lecteur_bis et
Etablissement.

66 Cration de bases de donnes
Etablissement_jointext_ Lecteur(Num_Etablissement_1, Ville, Nom_Etablissement,
Numero_carte, Nom, Num_Etablissement_2)
Ici, les valeurs 3 et 4 du champ Num_Etablissement_1 provenant de la relation Etablisse-
ment nont pas de correspondance dans la relation Lecteur. Les lignes sont tout de mme
incluses dans le rsultat mais les champs provenant de la relation Lecteur prennent la
valeur NULL. Cette valeur signifie que le champ ne contient pas de valeur.
Pour rpondre la question Quels sont les tablissements qui nont pas de lecteurs ? , il
nous suffit de slectionner les lignes qui contiennent la valeur NULL, par exemple dans le
champ Numro_carte. Dans un second temps, on effectue une projection sur le champ
Nom_Etablissement (voir figure 3.16).
Etablissement_jointext_Lecteur_selproj(Nom_Etablissement)
La jointure externe nest pas une opration symtrique. Lopration inverse, cest--dire la
jointure externe de la relation Lecteur avec la relation Etablissement sur le champ
Num_Etablissement donne dans ce cas le mme rsultat quune jointure naturelle. En
effet, toutes les valeurs du champ Num_Etablissement de la relation Lecteur ont une
correspondance dans la relation Etablissement. Cest ce que lon souhaite puisque la rela-
tion Etablissement fait office de relation de rfrence pour le champ
Num_Etablissement de la relation Lecteur. Lopration de jointure externe peut tre uti-
lise pour dtecter ce type dincohrence.
2.3 CALCULS ET AGRGATS
Une rgle dans le domaine des bases de donnes est que tout ce qui peut se calculer ne doit
pas tre stock. On vite ainsi la perte de place et lincohrence qui peut en dcouler suite
au stockage dinformations redondantes. Les oprations de lalgbre relationnelle prsen-
tes dans les sections prcdentes ne permettent pas de crer de nouveau champ par calcul
partir du contenu dautres champs sans utiliser un langage de programmation. Des
Num_Etablis-
sement_1
Ville
Nom
_Etablissement
Numero
_carte
Nom
Num_Etablis-
sement_2
1 Paris
Universit Jus-
sieu
1 Henri 1
2 Lyon CHU Bron 2 Stanislas 2
3 Nancy
Universit Poin-
car
NULL NULL NULL
4 Paris
Universit Sor-
bonne
NULL NULL NULL
Nom
_Etablissement
Universit Poincar
Universit
Sorbonne
Figure 3.15
Jointure externe
des relations
Lecteur_bis et
tablissement
sur le champ
Num
_Etablissement.
Figure 3.16
Slection et
projection sur la
jointure externe
des relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.

67 Approche relationnelle
Chapitre
fonctions de calculs ont t dfinies afin de rpondre ce besoin. Elles seront dtailles au
chapitre sur SQL .
On considre la relation La_boutique(Num_facture, Article, Prix, Quantite) [voir figure 3.17].
La_boutique(Num_Facture, Article, Prix, Quantite)
On suppose que lon veut exemple trouver le total pour chaque facture en multipliant le
prix par la quantit. Il est alors possible dajouter un champ Total dont le contenu sera
calcul par lexpression Prix Quantit (voir figure 3.18).
La_boutique_total(Num_FactureArticle, Prix, Quantite, Total)
Il est galement possible deffectuer des oprations statistiques globales dun champ,
comme les calculs du nombre denregistrements, de moyenne, de maximum, de mini-
mum. On obtient dans ce cas une nouvelle relation rduite une ligne et une colonne qui
contient la valeur calcule. En effet, le rsultat dune opration sur une relation est tou-
jours une relation (voir figure 3.19).
La_boutique_moyenne(Moyenne_Prix)
De mme, les oprations de base de lalgbre relationnelle ne permettent pas de rpondre
des questions du type : Combien trouve-t-on de personnes par ville ? La solution
consiste alors regrouper les enregistrements qui contiennent les mmes valeurs dans le
champ Ville : ce regroupement sappelle un agrgat. On applique ensuite chaque sous-
relation ainsi constitue une opration statistique, dans notre cas lopration de comptage
(voir figure 3.20).
Lecteur_parville(Ville, Nombre)
Num_Facture Article Prix Quantite
101 Bananes 12 45
1034 Choux 5 129
2345 Riz 4 60
0987 Gazelle 15 48
Num_Facture Article Prix Quantite Total
101 Bananes 12 45 540
1034 Choux 5 129 645
2345 Riz 4 60 240
0987 Gazelle 15 48 720
Moyenne_Prix
9
Ville Nombre
Bordeaux 1
Lyon 1
Figure 3.17
Relation
La_boutique.
Figure 3.18
Relation
La_boutique
avec le champ
calcul Total.
Figure 3.19
Moyenne des prix
de la relation
La_boutique.
Figure 3.20
Agrgat par ville
de la relation
La_boutique.

68 Cration de bases de donnes
3 Passage du modle conceptuel au relationnel
On a expos au chapitre sur lanalyse du monde rel deux formalismes diffrents entit-
association et UML pour reprsenter le modle conceptuel obtenu. Il existe des rgles
simples pour passer de ces modles un ensemble de relations qui sera utilisable directe-
ment dans le SGBD. Cet ensemble de relations sappelle le schma relationnel et constitue
le modle logique des donnes. On prsente dans cette section les rgles de transition qui
permettent dexprimer le schma relationnel partir du modle conceptuel des donnes.
Pour illustrer ces rgles, on utilise la terminologie du modle entit-association, mais leur
expression est aisment adaptable au formalisme UML.
3.1 RGLES GNRALES
Deux grandes rgles gnrales sappliquent toujours, quel que soit le cas. Les exceptions
que lon aborde ensuite permettent simplement dobtenir un schma plus compact :
Une entit devient une relation compose des champs de lentit. La cl de cette rela-
tion est la mme que celle de lentit.
Une association devient une relation compose des deux cls des entits associes.
Lensemble de ces deux cls constitue celle de la relation. Lorsquelle en possde, les
champs de lassociation forment les champs non cls de cette nouvelle relation.
Figure 3.21
Modle entit-
association de la
base de donnes
casse.
partir du modle entit-association de la base de donnes casse labor au chapitre
prcdent (voir figure 3.21), on obtient trois relations en appliquant ces rgles. Les entits
voiture et personne deviennent les relations voiture(NumVoit, Marque, Type, Couleur)
et personne(NumAch, Nom, Age, Ville, Sexe). Lassociation se transforme en relation
vente(DateVent, Prix, NumAch, NumVoit).
Marseille 2
Nancy 3
Paris 5
Ville Nombre
Client
NumAch
Nom
Age
Ville
Sexe
Voiture
# NumVoit
Marque
Type
Couleur
Vente
DateVente
Prix
0,1
1,n

69 Approche relationnelle
Chapitre
3.2 CAS PARTICULIER DES ASSOCIATIONS AVEC UNE CARDINALIT DE TYPE 1-1
Considrons le cas du modle entit-association qui reprsente lactivit dorganisation de
sminaires dcrite trs succinctement de la manire suivante :
Un sminaire est anim par un ou plusieurs intervenants.
Un sminaire ne possde quun seul responsable.
Figure 3.22
Modle entit-
association de la
base de donnes
animation de
sminaire.
Deux associations existent entre les deux entits Sminaires et Intervenant : Anime et
Est_responsable. Les attributs utiliss pour les entits et les associations sont visibles sur
le modle entit-association (voir figure 3.22).
Si lon applique les rgles gnrales nonces ci-dessus, on obtient quatre relations :
Intervenant(NumInter, NomInter, TelInter)
Seminaire(NumSem, DateSem, Prix, NbeJour)
Anime(NumInter, NumSem, NbeHeure, SalaireHor)
Est_responsable(NumInter, NumSem, Prime)
Lune des cardinalits de lassociation Est_responsable est de type 1-1, car un sminaire
possde un responsable et un seul. De cette dernire proprit, on peut en dduire que la
cl de la relation Est_responsable nest pas minimale. En effet, pour la relation
Est_responsable lidentifiant du sminaire dtermine celui du responsable. En dautres
termes, on identifie une dpendance fonctionnelle entre les champs NumSem et
NumInter pour la relation Est_responsable. On choisit le champ NumSem comme cl
de la relation Est_responsable.
La relation Est_responsable devient ainsi Est_responsable(NumSem, NumInter, Prime).
Les relations Est_responsable et Seminaire ont alors la mme cl, et il est possible de les
regrouper. On obtient la relation Seminaire_Res(NumSem, DateSem, Prix, NbeJour, NumIn-
ter, Prime). Il sest produit une sorte de glissement des lments de lassociation
Est_responsable vers lentit Seminaire.
On peut en dduire une rgle complmentaire des rgles gnrales prcdentes :
Lorsque lassociation entre deux entits comprend une cardinalit de type 1-1, on ne
cre pas de relation pour lassociation. Les champs de lassociation seront intgrs la
Seminaire
# NumSeminaire
DateSem
NbeJours
Prix
# NumInter
NomInter
TelInter
Intervenant
Anime
0,n
1,n
Est responsable
Prime
0,n
1,1
Salaire
NbeHeures

70 Cration de bases de donnes
relation cre pour lentit qui est associe avec la cardinalit 1-1. La cl de cette rela-
tion est toujours celle de lentit.
4 Normalisation
Le modle relationnel procure des outils destins tester la qualit et la cohrence des
relations dans un schma relationnel cr ltape prcdente. Cette tape, appele
normalisation, permettra de vrifier certaines proprits des relations et le cas chant
de les transformer.
On aborde dans cette section les trois premires formes normales qui suffisent dans la plu-
part des cas et qui permettent une dcomposition du schma relationnel sans perte
dinformation. La forme normale de Boyce-Codd qui dtecte dautres incohrences, mais
propose une dcomposition avec perte dinformations de dpendance, est prsente la
fin de la section. Il existe dautres formes normales la quatrime et la cinquime , qui ne
sont pas prsentes dans cet ouvrage : ces dernires sont parfois difficiles apprhender et
les trois premires formes normales suffisent en gnral pour obtenir un schma relation-
nel de qualit.
La normalisation dun schma relationnel suggre une autre mthode pour obtenir un
ensemble de relations. On part dune relation unique qui contient tous les champs, que
lon appelle la relation universelle. laide des dcompositions proposes par la mise en
forme normale et du graphe des dpendances fonctionnelles des champs de cette relation,
on parvient par raffinements successifs un ensemble de relations normalises. Cette
mthode de la relation universelle est toutefois assez difficile manipuler ds que lon
dpasse une taille critique du nombre de champs.
4.1 PREMIRE FORME NORMALE
La premire forme normale sintresse au contenu des champs. Elle interdit la prsence,
appele multivaluation, de plusieurs valeurs dans un mme champ dune relation. En
effet, la notion de dpendance fonctionnelle entre les champs ne peut plus tre vrifie sils
possdent plusieurs valeurs. Elle sexprime de la manire suivante :
Tout champ contient une valeur atomique.
Comment passer en premire forme normale ?
La relation suivante nest pas en premire forme normale ; le champ Auteurs contient
plusieurs valeurs (voir figure 3.23).
Remarque
Lun des intrts dUML est de disposer de logiciels capables, partir dun modle conceptuel
exprim en UML, de dduire automatiquement les relations en utilisant les rgles nonces ici.
Dautres rgles apparatraient dans le cas de lutilisation des extensions objet que propose UML ;
cependant ces possibilits dpassent le cadre de cet ouvrage.

71 Approche relationnelle
Chapitre
Publication(NumPubli, Titre, Auteurs)
Une solution pour rsoudre ce problme est de dcomposer le champ Auteurs en
Auteur_1, Auteur_2, Auteur_3, Auteur_4, etc. Ainsi, la relation est bien en premire
forme normale. Lennui est que lon ne sait pas lavance le nombre dauteurs que peut
possder une publication, et le problme consiste donc savoir combien de champs ajouter.
La solution plus correcte, mais galement plus lourde mettre en uvre, est de dcompo-
ser cette relation en trois relations : Publication(NumPubli, Titre), Auteur(NumAuteur,
Nom, Prenom) et EstEcrite(NumPubli, NumAuteur). Ces trois relations sont la reprsen-
tation de la ralit une publication est crite par des auteurs . Elle se modlise par deux
entits Publication et Auteur relies par lassociation EstEcrite, comme on la vu au
chapitre 2, Analyse du monde rel .
On obtient alors le rsultat suivant (voir figure 3.24).
Publication(NumPubli, Titre)
Auteur(NumAuteur, Nom, Prenom)
NumPubli Titre Auteurs
13490
Le vin et
lavenir
Jean Lasso, Hubert De
la Tuque, Stanislas
Wilski
21322
Bire et
progrs social
Aristide Salem, Jean
Lasso, Salome Dupont
45333
Le champagne
et la France
Penelope Light,
Vanessa Martinez,
Salome Dupont
NumPubli Titre
13490
Le vin et
lavenir
21322
Bire et
progrs social
45333
Le champagne
et la France
NumAuteur Nom Prenom
1 Lasso Jean
2 De la Tuque Hubert
3 Wilski Stanislas
4 Salem Aristide
5 Dupont Salome
6 Light Penelope
7 Martinez Vanessa
Figure 3.23
Relation
Publication avec
un champ
multivalu.
Figure 3.24
Dcomposition de
la relation
Publication en
trois relations.

72 Cration de bases de donnes
EstEcrite(NumPubli, NumAuteur)
On doit alors effectuer des jointures sur les diffrentes relations afin de reconstituer
linformation dans son intgralit. Cette dcomposition en trois relations se fait sans perte
dinformation.
4.2 DEUXIME FORME NORMALE
Bien videmment, une relation doit dj se trouver en premire forme normale pour tre
en deuxime forme normale. Cette dernire recherche la redondance dinformation dans
une relation. Elle interdit les dpendances fonctionnelles possibles entre les champs qui
composent la cl et les autres champs. On peut lexprimer de la manire suivante :
La relation est en premire forme normale.
Tout champ qui nappartient pas la cl ne dpend pas dune partie de la cl.
Comment passer en deuxime forme normale ?
La solution consiste dcomposer la relation en deux relations. La nouvelle relation cre
a pour cl la partie de la cl dont dpendent les autres champs qui constituent ses champs.
On considre la relation Produit suivante (voir figure 3.25).
Produit(Article, Fournisseur, Adresse, Prix)
La cl est constitue des champs Article et Fournisseur. Or, il y a une relation de dpen-
dance entre le champ Fournisseur, qui est une partie de la cl, et le champ Adresse.
On dcompose alors la relation pour liminer la redondance ainsi cre. La nouvelle relation
NumPubli NumAuteur
13490 1
13490 2
13490 3
21322 4
21322 1
21322 5
45333 6
45333 7
45333 5
Article Fournisseur Adresse Prix
Marteau SOGENO Paris 5
Tournevis ARTIFACT Lille 10
Tournevis SOGENO Paris 23
Pince LEMEL Paris 34
Mtre ARTIFACT Lille 24
Figure 3.25
Relation Produit.

73 Approche relationnelle
Chapitre
aura pour cl la partie de la cl de la relation dorigine dont dpendent fonctionnellement les
autres champs. Dans cet exemple, il sagit du champ Fournisseur. Les autres champs dpen-
dants constituent le reste de la relation. Il sagit ici du champ Adresse.
On obtient alors le rsultat suivant (voir figure 3.26).
Produit(Article, Fournisseur, Prix)
Fournisseur(Fournisseur, Adresse)
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linforma-
tion. La dcomposition en deux relations se fait sans perte dinformation.
4.3 TROISIME FORME NORMALE
La troisime forme normale recherche galement la redondance dinformation dans une
relation. On cherche sil existe une dpendance entre deux champs qui ne font pas partie
dune cl. Si cest le cas, on se trouve dans la situation o un champ dpend dun autre
champ qui dpend lui mme dune cl. La cl considre peut tre primaire ou secondaire.
La troisime forme normale interdit donc les dpendances fonctionnelles dites
transitives entre les champs. Elle sexprime de la manire suivante :
La relation est en deuxime forme normale (donc en premire forme normale).
Tout champ nappartenant pas une cl ne dpend pas dun autre champ non cl.
Comment passer en troisime forme normale ?
La solution est galement de dcomposer la relation de dpart en deux relations. La nou-
velle relation cre a pour cl le champ dont dpendent les autres champs qui constituent
ainsi la dpendance transitive.
On considre la relation suivante (voir figure 3.27).
Article Fournisseur Prix
Marteau SOGENO 5
Tournevis ARTIFACT 10
Tournevis SOGENO 23
Pince LEMEL 34
Mtre ARTIFACT 24
Fournisseur Adresse
SOGENO Paris
ARTIFACT Lille
LEMEL Paris
Remarque
Si la cl dune relation est atomique, cest--dire compose dun seul champ, elle est naturelle-
ment en deuxime forme normale.
Figure 3.26
Dcomposition de
la relation
Produit pour
passer en
deuxime forme
normale.

74 Cration de bases de donnes
Baladeur(NumBal, Marque, Type, Couleur)
La cl de cette relation est un numro, NumBal, car il peut y avoir dans notre stock plu-
sieurs baladeurs de mme marque, de mme type et de mme couleur. Les marques dpo-
sent les noms des objets quelles fabriquent de faon les identifier sur le march. Il existe
donc une dpendance fonctionnelle entre le champ Type (qui nappartient pas la cl) et
le champ Marque (qui nappartient pas la cl). On dcompose la relation en en crant
une nouvelle qui a pour cl le champ dont dpendent les autres champs constituant la
dpendance transitive. Il sagit dans ce cas du champ Type. Les autres champs de la nou-
velle relation sont composs des champs qui en dpendent fonctionnellement : ici, le
champ Marque (voir figure 3.28).
Baladeur(NumBal, Type, Couleur)
Baladeur_type(Type, Marque)
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linfor-
mation dans son intgralit. La dcomposition en deux relations se fait sans perte
dinformation.
NumBal Marque Type Couleur
12 Apple Ipod Blanc
43 Creative Zen Noir
23 Apple Ipod Noir
29 Creative Zen Gris
34 Sony MZ-RH910 Rouge
NumBal Type Couleur
12 Ipod Blanc
43 Zen Noir
23 Ipod Noir
29 Zen Gris
34 MZ-RH910 Rouge
Type Marque
Ipod Apple
MZ-RH910 Sony
Zen Creative
Remarque
Les deuxime et troisime formes normales traitent des problmes diffrents. Lordre dans lequel
on les considre pour la normalisation, mise en deuxime forme puis en troisime forme normale,
est plutt li lhistorique qu une ncessit relle.
Figure 3.27
Relation
Baladeur.
Figure 3.28
Dcomposition de
la relation
Baladeur pour
passer en
troisime forme
normale.

75 Approche relationnelle
Chapitre
4.4 FORME NORMALE DE BOYCE-CODD
La forme normale de Boyce-Codd traite un cas un peu diffrent de ceux de la deuxime et
troisime forme normale. Il sagit du cas o une partie dune cl dpend dun champ.
Comme pour la troisime forme normale, la cl considre peut tre une cl primaire ou
secondaire. Une relation en troisime forme normale nest pas toujours en forme Boyce-
Codd , mais linverse est toujours vrai.
Tout champ appartenant une cl ne dpend pas dun autre champ non cl.
Comment passer en forme normale de Boyce-Codd ?
Lors de la dcomposition de la relation en deux relations, plusieurs choix sont envisagea-
bles compte tenu des liens de dpendances multiples entre les diffrents champs. On choi-
sit la dcomposition qui permet de reconstituer strictement linformation dorigine sans
gnrer de donnes supplmentaires. La perte dune dpendance fonctionnelle est fr-
quente lors de cette opration. La relation cre a pour cl la partie de celle-ci dont dpen-
dent les autres champs constituant la dpendance.
On considre la relation suivante (voir figure 3.29).
Dictaphone(Marque, Produit, Prix, Couleur)
La cl de cette relation est constitue par les champs Marque et Produit. En effet, un pro-
duit est fabriqu sous licence par la socit ImaginR et a donc le mme nom que celui pro-
pos par la socit Olympus. Il est alors ncessaire dutiliser les deux champs pour constituer
la cl. Pour se dmarquer les unes des autres, les socits utilisent des couleurs personnalises
destines identifier la marque : Philips, le blanc et lorange ; Olympus, le rouge et le noir ;
ImaginR, le gris. On a donc une relation de dpendance entre ces deux champs. La relation
est en troisime forme normale, mais elle nest pas en forme de Boyce-Codd.
Plusieurs dcompositions sont possibles : par exemple Dictaphone(Marque, Type, Prix) et
Marque_coul(Couleur, Marque). Mais cette dcomposition gnre des tuples non dsirs
au moment de la jointure. Quant la dcomposition Dictaphone(Type, Prix, Couleur) et
Marque_coul(Couleur, Marque), elle permet de reconstituer linformation de dpart par
une jointure sur le champ Couleur (voir figure 3.30).
Dictaphone(Produit, Prix, Couleur)
Marque Produit Prix Couleur
Philips LD 1024 49 Blanc
Olympus VN 1664 49 Noir
Philips LD 5647 H 59 Blanc
ImaginR VN 1664 69 Gris
Olympus VN 234 PC 79 Rouge
Produit Prix Couleur
LD 1024 49 Blanc
VN 1664 49 Noir
LD 5647 H 59 Blanc
Figure 3.29
Relation
Dictaphone.
Figure 3.30
Relation
Dictaphone
dcompose pour
passer en forme
de Boyce-Codd.

76 Cration de bases de donnes
Marque_coul(Couleur, Marque)
On a perdu la dpendance de Couleur par rapport Marque, Produit.
5 Logique du premier ordre et base de
donnes
Dans cette section, le fondement logique de lapproche relationnelle est brivement
abord pour prsenter une mthode dinterrogation : les QBE (Query By Example). La
logique du premier ordre a pour but de formaliser le raisonnement naturel en considrant
la dduction comme le rsultat dun calcul. Elle a fait lobjet de recherches intenses depuis
lAntiquit : Aristote, Frege et Gdel pour nen citer que quelques-uns sont parmi les plus
prestigieux stre penchs sur la question. Les principes de la logique du premier ordre,
dans une version restreinte que lon appelle le calcul des propositions, ont trouv de
nombreuses applications en informatique. Aprs quelques rappels sur le formalisme de la
logique, on aborde ses liens avec lapproche relationnelle en base de donnes et lon pr-
sente la mthode dinterrogation par QBE.
5.1 RAPPELS SUR LA LOGIQUE DU PREMIER ORDRE
Le formalisme de la logique du premier ordre permet dexprimer des phrases dans un lan-
gage non ambigu. Il offre la possibilit, par des rgles de drivation, ou rcritures, de
dduire dautres phrases. Llment fondamental de la logique du premier ordre est le pr-
dicat qui exprime le lien entre diffrents lments. La validit de ce prdicat est gnrale-
ment restreinte un ensemble de valeurs que lon nomme domaine du discours.
mange(x,y) sera par exemple vrai pour les valeurs du couple (x,y) suivantes
(homme,navet)
(lapin,carotte)
(homme,lapin).
On utilise classiquement des variables (x,y dans notre exemple) et des constantes dans les
expressions. Les prdicats peuvent tre associs par des connecteurs logiques : (et),
(ou), (non), (implique). Le domaine de discours des variables sexprime partir des
quantificateurs (quel que soit) et (il existe). Ce formalisme simple permet dexprimer
des proprits comme celle-ci : si x est mang par y ou y est mang par x, ils appartien-
nent tous deux la mme chane alimentaire .
VN 1664 69 Gris
VN 234 PC 79 Rouge
Couleur Marque
Blanc Philips
Noir Olympus
Gris ImaginR
Rouge Olympus
Produit Prix Couleur

77 Approche relationnelle
Chapitre
x y mange(x,y) mange(y,x) meme_chaine_alimentaire(x,y)
Cette formule peut se rcrire en utilisant des rgles de dduction dans le but daboutir
un ensemble de clauses plus aises vrifier : cest sur ce principe que fonctionne la
dmonstration automatique de thormes. La diffrence entre un (bon) mathmaticien et
un programme est videmment que le mathmaticien va choisir demble la srie de rgles
adapte pour parvenir plus rapidement au rsultat.
Voici une possibilit de rcriture de la formule prcdente.
a b donne a b
x y ((mange(x,y) mange(y,x)) (meme_chaine_alimentaire(x,y)))
(a b) donne a b
x y (mange(x,y) ? mange(y,x)) (meme_chaine_alimentaire(x,y)))
(a b) c donne (a c) (b c)
x y ((mange(x,y) meme_chaine_alimentaire(x,y)) ((mange(y,x)
meme_chaine_alimentaire(x,y)))
a b donne a b
x y ((mange(x,y) meme_chaine_alimentaire(x,y)) (mange(y,x)
meme_chaine_alimentaire(x,y))
x y signifie que y est dfini en fonction de x, on remplace y par F(x)
On obtient ainsi deux clauses relies par , on lappelle clause de Horn qui reprsente la
fin de la rcriture :
mange(x,F(x)) meme_chaine_alimentaire(x,F(x)))
mange(F(x),x) meme_chaine_alimentaire(x, F(x))
Dans notre cas, on peut sassurer assez facilement que ces deux implications sont toujours
vrifies pour le domaine du discours.
5.2 LIEN AVEC LES BASES DE DONNES
Le lien avec ce qui a t nonc prcdemment sur le modle de bases de donnes relation-
nelles est le suivant :
Le prdicat correspond la relation.
Le domaine du discours correspond au contenu de la relation.
Ce formalisme permet dexprimer les questions, naturellement ambigus du langage
parl, par une formule. Cette formule est rcrite en utilisant les rgles vues prcdem-
ment pour arriver un ensemble de clauses simples. On constitue ensuite des sous-ensem-
bles de tuples de la relation pour lesquels les clauses rcrites sont vrifies : ces tuples
reprsentent la rponse la question pose. Voici quelques exemples de questions expri-
mes en utilisant ce formalisme. On obtient ainsi des sortes de patrons de recherche
permettant de caractriser les tuples qui sont solutions.
Dans lexemple gnral (voir section 3.1), le schma de la relation voiture est voi-
ture(NumVoit, Marque, Type, Couleur) et le schma de la relation vente est vente(Date-
Vent, Prix, NumAch, NumVoit).
Lexpression afficher la liste des marques et des types de voitures , ou projection des
champs Marques et Types de la relation voiture, peut scrire sous la forme :
{ (m,t) | voiture(_,m,t,_) }
Cela signifie que les valeurs des champs Marque et Type des tuples de la relation voi-
ture sont reprsentes par les variables m et t. Le signe _ reprsente nimporte quelle
valeur des autres champs NumVoit et de Couleur.

78 Cration de bases de donnes
Lexpression afficher le type des voitures de couleur rouge , qui est une projection et
une slection sur la relation voiture, peut scrire sous la forme :
{ (t) | voiture(_,_,t,rouge) }
Cette fois, on utilise une constante, rouge, dans lexpression pour fixer la valeur dun
champ et la variable, t, pour les valeurs du champ recherches.
On peut exprimer lappartenance dun champ un ensemble par un critre. Lexpression
afficher les prix de vente suprieurs 10 000 , qui est une projection et une slection sur
la relation vente, peut scrire sous la forme :
{ (p) | vente(_,p,_,_) p > 10000 }
Enfin, la jointure entre deux relations est galement possible. Lexpression afficher le
type des voitures vendues et leur prix , qui met en jeu deux relations, peut scrire sous la
forme :
{ (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
Il suffit dutiliser la mme variable dans les deux relations : ici nv, pour le champ
NumVoit qui sert effectuer le lien. Le quantificateur permettra de ne slectionner
que les tuples dans les deux relations pour lesquels les valeurs de NumVoit sont identi-
ques, ce qui est exactement la dfinition dune jointure (quijointure).
Le formalisme de la logique du premier ordre permet dexprimer toutes les oprations
relationnelles vues prcdemment : cest normal puisquil sagit de la base de lapproche
relationnelle. On peut alors considrer un SGBD comme un outil de dmonstration de
thormes, tels que lon peut en rencontrer en intelligence artificielle, qui agirait sur un
ensemble trs restreint de rgles.
5.3 INTERROGATION PAR QBE (QUERY BY EXAMPLE)
Lors de la phase de dveloppement du prototype de SGBD bas sur lapproche relation-
nelle dans les laboratoires dIBM, un premier sous-produit a t conu : le langage dinter-
rogation SEQUEL, puis SQL. Une autre mthode dinterrogation a t dveloppe cette
occasion : les QBE (Query By Example). Lide est de disposer dun mode dinterrogation
dune base de donnes sans connatre de langage et en utilisant le formalisme vu la sec-
tion prcdente, prsent sous une forme graphique. Comme son nom lindique, on va
utiliser des exemples pour dfinir les questions. La relation est reprsente sous la forme
dun tableau :
La projection dun champ se fait en cochant la case correspondant au nom de la colonne
(voir figure 3.31).
Afficher la liste des marques et des types de voitures :
{ (m,t) | voiture(_,m,t,_) }
Les critres de slection se font par des valeurs exemples (voir figures 3.32 et 3.33).
NumVoit Marque Type Couleur
Figure 3.31
Projection du
champ Marque
dans un QBE.

79 Approche relationnelle
Chapitre
Afficher le type des voitures de couleur rouge :
{ (t) | voiture(_,_,t,rouge) }
Afficher les prix de vente suprieurs 10 000 :
{ (p) | vente(_,p,_,_) p > 10000 }
Les conditions situes sur la mme ligne sont relies par un et (voir figure 3.34).
Afficher les prix de vente suprieurs 10 000 et dont la date de vente a eu lieu aprs le
1
er
janvier 1997 :
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
Les conditions situes sur deux lignes diffrentes sont relies par un ou (voir
figure 3.35).
Afficher les prix de vente suprieurs 10 000 ou dont la date de vente a eu lieu aprs le
1
er
janvier 1997 :
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
La jointure entre deux relations se fait en utilisant une variable, exactement comme
dans une formule de la logique de premier ordre (voir figure 3.36).
Afficher le type des voitures vendues et leur prix :
{ (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
Cette mthode dinterrogation simple et efficace est encore propose par de nombreux SGBD.
NumVoit Marque Type Couleur Rouge
DateVent Prix NumAch NumVoit
> 10 000
DateVent Prix NumAch NumVoit
> 01/01/1997 > 10 000
DateVent Prix NumAch NumVoit
> 01/01/1997 > 10 000
NumVoit Marque Type Couleur
Nv
DateVent Prix NumAch NumVoit
Nv
Figure 3.33
Slection sur un
critre et
projection dans un
QBE.
Figure 3.34
Slection multicri-
tre obligatoire et
projection dans
un QBE.
Figure 3.35
Slection
multicritre
optionnel et
projection dans un
QBE.
Figure 3.32
Slection sur un
contenu et
projection dans un
QBE.
Figure 3.36
Jointure et
projection dans un
QBE.

80 Cration de bases de donnes
Rsum
Lapproche relationnelle modlise les faits de la vie relle par des tuples, qui sont des
ensembles de valeurs de diffrents champs (ou attributs) : (rfrigrateur, 2003, rouge) est
un tuple qui reprsente des valeurs des champs Objet, Anne, Couleur lies dans le
monde rel. Lensemble des tuples sappelle une relation. Il sagit du concept de base qui
sera manipul par lapproche relationnelle et peut tre reprsent sous la forme dune
table.
Pour identifier un tuple, on utilise le contenu dun ou de plusieurs champs que lon nom-
mera la cl dune relation. Cette dernire est tablie en utilisant le concept de dpendance
fonctionnelle entre les diffrents champs. La cl est constitue par le plus petit ensemble
de champs dont dpendent fonctionnellement les autres champs. Si plusieurs cls sont
possibles, on parle de cls candidates. La cl choisie sera nomme la cl primaire.
Les oprations de manipulation de ces relations peuvent tre regroupes en trois
catgories :
Les oprations du monde ensembliste. Produit cartsien, intersection, union et diff-
rence.
Les oprations spcifiques relationnelles. Projection, slection (ou restriction) et
jointure. On a prsent galement la jointure externe qui permet de rpondre des
questions spcifiques mme sil ne sagit pas dune opration de base du relationnel.
Les oprations et les fonctions de calcul. Elles ne constituent pas rellement des op-
rations du monde relationnel mais sont utiles pour effectuer des calculs sans recourir
un langage de programmation.
La cohrence des donnes contenues dans les relations est amliore par la dfinition de
contraintes que lon appliquera sur les relations au moment de leur cration. Ces con-
traintes expriment essentiellement les conditions dappartenance un ensemble que lon
nomme le domaine du champ. On peut dcrire cet ensemble de plusieurs manires :
Une liste exhaustive de valeurs, comme celles des jours de la semaine : lundi ,
mardi , etc.
Le respect de proprits, comme : lge doit tre compris entre 7 et 77 ans .
Lutilisation des valeurs dun champ comprises dans une autre relation de rfrence.
On parle de cl trangre.
La mise en uvre de ces contraintes est assure par le SGBD en utilisant le Langage de
Dfinition de Donnes (LDD). Aprs avoir prsent les concepts de relation (ou de table) et
les outils qui permettent de les manipuler, on a dcrit les rgles qui conduisent du modle
conceptuel prsent au chapitre prcdent un ensemble de relations constituant le
modle logique de la base de donnes. Les liaisons entre les relations, qui expriment les
liens de sens dans la ralit, seront tablies dynamiquement par lopration fondamentale
de lapproche relationnelle qui est la jointure.
On value ensuite la qualit de ces relations en vrifiant leur conformit par rapport des
proprits que lon appelle les formes normales. Ces proprits visent essentiellement
dtecter la redondance et la cohrence des donnes dans les relations. On a prsent dans
ce chapitre les quatre formes normales les plus courantes :
la premire forme normale qui interdit les champs multivalus ;
la deuxime forme normale qui dtecte une relation de dpendance entre une partie de
la cl et un champ ;

81 Approche relationnelle
Chapitre
la troisime forme normale qui dtecte une dpendance transitive entre une cl et
un champ, cest--dire quun champ non-cl dpend dun autre champ non-cl qui
dpend lui mme de la cl ;
la forme normale de Boyce-Codd qui dtecte la relation de dpendance entre un
champ non-cl et une partie dune cl ; cest une extension de la troisime forme nor-
male qui est plus restrictive.
La normalisation est une mthode de rorganisation qui consiste dcomposer une rela-
tion pour la rendre conforme aux formes normales. La recomposition des donnes se fait
alors par une opration de jointure qui peut se rvler coteuse en ressources. Cest pour
cette raison de performance que certaines relations sont parfois laisses en forme non nor-
malise. Les deux tapes prcdentes de passage du modle conceptuel au schma rela-
tionnel et de normalisation peuvent tre quasiment automatises. Enfin, on a abord les
bases du fondement logique de lapproche relationnelle. Lobjectif est de prsenter une
mthode dinterrogation intuitive et graphique dune base de donnes qui en dcoule : les
QBE ou interrogation par lexemple .

82 Cration de bases de donnes
Exercices
EXERCICE 1 RELATION, DEGR, CARDINALIT
Comme le produit cartsien est une combinaison de tous les tuples des deux relations, le
nombre de tuples sera le produit du nombre de tuples des deux relations. Tous les champs
sont intgrs dans le rsultat en une sorte de juxtaposition : le nombre de champs du pro-
duit cartsien est gal la somme du nombre de champs des deux relations. Enfin, le pro-
duit cartsien est une opration symtrique ; le rsultat sera le mme pour les deux
questions.
La relation Garage possde 3 tuples de 7 champs et la relation Film possde 15 tuples de 2
champs. Le rsultat est une relation qui possde 45 tuples et 9 champs. On peut galement
dire que le rsultat est une table qui possde 45 lignes et 9 colonnes.
EXERCICE 2 CL DUNE RELATION
Si lon considre simplement le contenu de la relation, il ny a pas de cl constitue par un
seul champ. Il semble que la combinaison de deux champs, Prix et Nombre est une cl
et que cest la seule qui contient deux champs.
On pourrait trouver des combinaisons avec trois champs qui fonctionnent : par exemple
Prix et Format et Couleur. Ce serait alors une cl candidate, mais on choisit celle qui est
la plus atomique possible. On peut sinterroger en revanche sur le bien-fond dune cl
constitue des deux champs Prix et Nombre si lon considre leur sens dans le monde
rel. Il semble vident que lon puisse avoir deux films diffrents avec le mme prix et le
mme nombre.
Comment choisir la cl dans ce cas ? On ne peut donc en gnral pas choisir une cl sans tenir
compte des dpendances fonctionnelles entre les champs. Mme si les donnes prsentes dans
On considre deux relations. La premire Garage est de degr 7 et de cardinalit 3. La se-
conde Film est de degr 2 et de cardinalit 15. Quels sont le degr et la cardinalit du pro-
duit cartsien de Garage par Film? Quels sont le degr et la cardinalit du produit
cartsien de Film par Garage ?
Quelle est la cl de cette relation (voir figure 3.37) ?
Film(Prix, Format, Type, Nombre)
Prix Format Type Nombre
12 4 :3 Couleur 3
4 16 :9 Noir/Blanc 1
12 16 :9 Couleur 1664
35 4 :3 Noir/Blanc 890
12 16 :9 Noir/Blanc 1
Figure 3.37
Relation Film.

83 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
la relation semblent confirmer quil sagit bien dune cl, il ny a pas ici de dpendance entre
les champs Prix et Nombre. Sauf si le commanditaire de la base de donnes vous affirme le
contraire pour son cas particulier. Sans faire une analyse exhaustive des dpendances entre
tous les champs, il semble quil ny a pas dans cette relation de bons candidats pour identi-
fier un tuple. Une solution est dajouter un champ spcifique ; cest ce que proposent la plu-
part des SGBD lorsque vous ne dfinissez pas de cl pour une relation.
EXERCICE 3 CONTRAINTES DINTGRIT
Pour les champs de type numrique comme Prix et Nombre, on peut proposer des limi-
tes dappartenance un intervalle. Le prix doit tre compris entre 0 et 1 000, et le nombre
entre 0 et 10 000.
Pour les champs de type caractre comme Format et Couleur, il semble que les valeurs
puissent tre incluses dans des ensembles numrs. Le format peut tre compris dans
lensemble (3 :4,16 :9) et la couleur dans lensemble (Couleur,Noir/Blanc) .
Le contenu du champ Numro_Film peut tre dfini par rapport au contenu du champ
correspondant dans la relation catalogue. Cela revient imposer la contrainte suivante :
on nentre pas de numro de films qui ne se trouveraient pas dans le catalogue. Dans tous
les cas, ces valeurs sont dterminer avec les usagers de la base de donnes.
EXERCICE 4 OPRATION ENSEMBLISTE
Pour raliser ces oprations, il faut que les relations possdent le mme schma. Linter-
section entre deux ensembles peut se concevoir de la manire suivante en utilisant lop-
On considre la relation Film(Prix, Format, Type, Nombre) de lexemple prcdent. Pro-
posez des contraintes dintgrit pour chaque champ. On suppose que lon ajoute un
champ Numro_Film qui correspond son identifiant dans une relation descriptive qui
est un catalogue de films. Que proposez-vous comme contrainte pour ce champ ?
Exprimez lintersection entre deux relations partir des oprations dunion et de diff-
rence. Donnez-en une illustration avec ses deux relations (voir figure 3.38).
ma_cuisine(Appareil, Couleur)
Appareil Couleur
Rfrigrateur rouge
Robot mauve
Cuisinire jaune
sa_cuisine(Appareil, Couleur)
Appareil Couleur
Rfrigrateur mauve
Cuisinire jaune
Hotte bleue
Figure 3.38
Relations
ma_cuisine et
sa_cuisine.

84 Cration de bases de donnes
rateur de diffrence : ma_cuisine sa_cuisine = ma_cuisine (ma_cuisine - sa_cuisine)
[voir figure 3.39].
ma_cuisine - sa_cuisine
ma_cuisine (ma_cuisine - sa_cuisine)
On obtient bien le rsultat de lintersection de ma_cuisine sa_cuisine. Vrifiez par la mme
mthode que sa_cuisine ma_cuisine peut scrire sa_cuisine (sa_cuisine - ma_cuisine) et
que lopration est symtrique bien que lopration de diffrence ne le soit pas.
EXERCICE 5 PROJECTION
Il sagit simplement dune projection sur les champs (voir figure 3.40).
Film_proj(Prix, Type)
Cette projection permet de mettre en vidence que Prix et Type nest pas une cl candi-
date, car il y a un doublon : le tuple (12, Noir/Blanc).
Appareil Couleur
Rfrigrateur rouge
Robot mauve
Appareil Couleur
Cuisinire jaune
Trouver le prix et le type de tous les films de la relation Film vue prcdemment. Peut-
on en dduire que Prix & Type est une cl candidate, cest--dire que toute combinai-
son des valeurs du prix et du type dun film permet didentifier un film?
Prix Type
12 Couleur
4 Noir/Blanc
12 Couleur
35 Noir/Blanc
12 Noir/Blanc
Figure 3.39
Opration sur les
relations
ma_cuisine et
sa_cuisine.
Figure 3.40
Projection de la
relation Film.

85 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 6 RESTRICTION
Il sagit de raliser une restriction sur les tuples dont le champ Type contient Noir/
Blanc ; on fait ensuite une projection sur le champ Prix (voir figure 3.41).
On obtient une relation de degr 1 et de cardinalit 2 (voir figure 3.42).
Film_NB(Prix)
On peut calculer le degr facilement, puisquil sagit du nombre de champs sur lesquels on
fera la projection. Pour la cardinalit qui reprsente le nombre de lignes du rsultat, on ne
peut la calculer lavance puisquelle va dpendre du contenu du champ Type des tuples
de la relation.
EXERCICE 7 JOINTURE
Donnez le prix des films de la base films en Noir/Blanc . Quels sont le degr et la car-
dinalit de la relation obtenue ? Est-il possible de calculer ces valeurs lavance, comme
on le fait pour un produit cartsien ?
Prix Format Type Nombre
12 4 :3 Couleur 3
4 16 :9 Noir/Blanc 1
12 16 :9 Couleur 1664
35 4 :3 Noir/Blanc 890
12 16 :9 Noir/Blanc 1
Prix
4
35
On considre ces deux relations prsentes dans un exercice prcdent (voir figures 3.43
et 3.44).
Film(Prix, Format, Type, Nombre, Numero_Film)
Prix Format Type Nombre Numero_Film
12 4/3 Couleur 3 2
4 16/9 Noir/Blanc 1 4
12 16/9 Couleur 1 664 50
35 4/3 Noir/Blanc 890 12
12 16/9 Noir/Blanc 1 12
Figure 3.41
Restriction et
projection de la
relation Film.
Figure 3.42
Rsultat de la
restriction et de la
projection de la
relation Film.
Figure 3.43
Relation Film.

86 Cration de bases de donnes
On fait une jointure entre les deux relations sur les champs Numero_Film (voir figure 3.45).
On projette sur les champs Titre et Format (voir figure 3.46).
Il nest pas incohrent dobtenir deux fois le mme titre avec deux formats diffrents. En
revanche, la contrainte dintgrit rfrentielle nest pas respecte, car on nobtient pas la
mme cardinalit que la relation de dpart lors de lopration de jointure. On aurait d
obtenir une cardinalit de 5. On constate sur cet exemple que le contenu 50 du champ
Numero_Film ne se trouve pas dans la relation Catalogue. Il manque donc un tuple dans
le rsultat.
Catalogue(Numero_Film, Titre)
Numero_Film Titre
2 Le train qui passe
4 A toi !
56 Les chats du Sngal
111 Le temps expliqu
12 Les impts faciles
Trouvez la liste des titres de films et leur format. Voyez-vous une incohrence dans le
rsultat ? Pouvez-vous lors de cette opration dtecter si la contrainte dintgrit rfren-
tielle suggre lexercice prcdent a t respecte ? Est-il possible de faire une jointure
entre ces deux relations sur le champ Prix de la relation Film avec le champ
Numero_film de la relation Catalogue ? Si oui, que signifie le rsultat ?
Prix Format Type Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12 4 :3 Couleur 3 2 2
Le train qui
passe
4 16 :9 Noir/Blanc 1 4 4 A toi !
35 4 :3 Noir/Blanc 890 12 12
Les impts
faciles
12 16 :9 Noir/Blanc 1 12 12
Les impts
faciles
Titre Format
Le train qui
passe
4 :3
A toi ! 16 :9
Les impts
faciles
4 :3
Les impts
faciles
16 :9
Figure 3.44
Relation
Catalogue.
Figure 3.45
Jointure des
relations Film et
Catalogue.
Figure 3.46
Projection sur la
jointure des
relations Film et
Catalogue.

87 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
La jointure sur les champs Prix et Numro_film est possible, car ils sont de mme type. Elle
sera donc effectue par le SGBD sans rejet. On obtient la relation suivante (voir figure 3.47).
Cette opration na aucune signification dans la ralit.
EXERCICE 8 AUTRE JOINTURE
On fait une jointure externe cette fois entre les relations sur les champs Numero_Film.
Attention, lopration nest pas symtrique, la jointure se fait partir de la relation Film
sur la relation Catalogue (voir figure 3.48)
Il suffit alors de faire une slection sur le contenu dun champ provenant de la relation
Catalogue dont le contenu est NULL, par exemple le champ Titre. On projette ensuite
sur le champ Numero_Film provenant de la relation Film. On obtient une relation une
ligne et une colonne (ou une relation de degr 1 et de cardinalit 1) [voir figure 3.49].
Prix Format Type Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12 4 :3 Couleur 3 2 12
Les impts
faciles
4 16 :9
Noir/
Blanc
1 4 4 A toi !
12 16 :9 Couleur 1664 50 12
Les impts
faciles
12 16 :9
Noir/
Blanc
1 12 12
Les impts
faciles
Comment trouver la(les) valeur(s) qui ne respectent pas lintgrit rfrentielle du
champ Numro_Film de la relation Film par rapport la relation Catalogue dans
lexemple prcdent ? Quels sont les films du catalogue qui ne sont pas utiliss dans la re-
lation Film ?
Prix Format Type Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12 4 :3 Couleur 3 2 2
Le train qui
passe
4 16 :9
Noir/
Blanc
1 4 4 A toi !
12 16 :9 Couleur 1664 50 NULL NULL
35 4 :3
Noir/
Blanc
890 12 12
Les impts
faciles
12 16 :9
Noir/
Blanc
1 12 12
Les impts
faciles
Figure 3.47
Jointure sans
objet des
relations Film et
Catalogue.
Figure 3.48
Jointure externe
des relations
Film et
Catalogue.

88 Cration de bases de donnes
Pour dtecter les films du catalogue non utiliss, on va cette fois faire une jointure externe
symtrique de la prcdente partir de la relation Catalogue sur la relation Film (voir
figure 3.49).
De mme que prcdemment, il suffit de faire une slection sur le contenu dun champ
provenant de la relation Film dont le contenu est NULL, par exemple le champ Prix. On
projette ensuite sur le champ Numero_Film provenant de la relation Film. On obtient
une relation deux lignes et une colonne (ou une relation de degr 1 et de cardinalit 2)
[voir figure 3.51].
Cet exercice permet de mettre en vidence lasymtrie de lopration de jointure externe et
son rle indispensable pour rpondre des questions de ce type. Cest pour cette raison
quelle a t introduite dans le langage SQL dans un second temps, mme si elle nen faisait
pas partie lorigine.
EXERCICE 9 CALCUL SUR DES AGRGATS
On va commencer par une opration qui consiste constituer autant de sous-relations que
lon trouve de valeurs diffrentes dans le champ Format de la relation Film . Ici, il y a deux
Numero
_Film
50
Numero
_Film
(Catalogue)
Titre Prix Format Type Nombre
Numero
_Film
(Film)
2
Le train qui
passe
12 4 :3 Couleur 3 2
4 A toi ! 4 16 :9
Noir/
Blanc
1 4
56
Les chats du
Sngal
NULL NUL NUL NUL NUL
111
Le temps
expliqu
NUL NUL NUL NUL NUL
12
Les impts
faciles
12 4 :3
Noir/
Blanc
890 12
Titre
Les chats du
Sngal
Le temps
expliqu
Quelle est la moyenne des prix pour les films par format ?
Figure 3.49
Slection et
projection de la
jointure externe
des relations
Film et
Catalogue.
Figure 3.50
Jointure externe
des relations
Catalogue et
Film.
Figure 3.51
Slection et
projection de la
jointure externe
des relations
Catalogue et
Film.

89 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
valeurs pour toute la relation 4 :3 et 16 :9. Lopration sappelle raliser des agrgats par
rapport au contenu dun champ . Ensuite, pour ces deux sous-relations, on calcule la
moyenne des valeurs du champ Prix. Dans la relation rsultat, on a le champ projet For-
mat et le champ calcul Moyenne (voir figure 3.52).
EXERCICE 10 PASSAGE DU MODLE ENTIT-ASSOCIATION AU RELATIONNEL
On applique les rgles classiques de passage vues prcdemment dans ce chapitre. Une
entit devient une relation compose des champs de lentit, ayant comme cl celle de
lentit.
Client (NumClient, Nom, Prenom, Adresse, Tel, Compte) ;
Films(NumFilm, Titre, Genre, Prix, NombreDVD) ;
Personnels(NumPers, Nom, Prenom).
Les associations deviennent des relations ayant comme champs ceux de lassociation et
comme cl celles des entits associes.
Locations(DateLoc, NbeJourLoc, Livraison, NumFilm, NumClient) ;
Reservations(DateRes, NbJourRes, NumFilm, NumClient) ;
Joue(NumPers, NumFilm) ;
Realise(NumPers, NumFilm).
Prix Format
29,5 4 :3
9,3333 16 :9
partir du modle entit-association modlisant une location de DVD, effectuez le pas-
sage au modle relationnel (voir figure 3.53).
Figure 3.53
Modle entit-
association de la
location de DVD.
Client
# NumClient
NomClient
PrenomClient
AdresseClient
TeleClient
Compte
Film
# NumFilm
Titre
Genre
Prix
NbDVD
Reservation
# NumPers
NomPers
PrenomPers
Personnel
Joue
Realise
Location
NbeJourRes
DateRes
NbeJourLoc
DateLoc
1,n
0,n
0,n
0,n
0,n
0,n
0,n
1,1
Figure 3.52
Agrgat sur la
relation Film.

90 Cration de bases de donnes
On remarque que lassociation Realise a une cardinalit de type 1-1 lors de son associa-
tion avec Films. Cela signifie dans le monde rel quun film a un et un seul ralisateur.
On est dans le cas o lassociation Realise est absorbe par la relation cre partir de
lentit associe, ici Film. On obtient la relation suivante :
Films(NumFilm, Titre, Genre, Prix, NombreDVD, NumPers) et la relation Realise
disparat.
On peut noter que les cls des relations cres partir des associations Locations et
Reservations supposent quun client ne rserve et ne loue pas le mme film deux fois.
Dans le cas contraire, on serait oblig dajouter un champ identifiant pour ces deux rela-
tions. L encore, on ne peut dcider cela qu lisssue de discussions avec les utilisateurs de
la base de donnes.
EXERCICE 11 PASSAGE DU MODLE ENTIT-ASSOCIATION AU RELATIONNEL II
Le fait que lassociation se fasse sur une mme entit ne pose pas de problmes
particuliers ; on applique les rgles classiques. On obtient deux relations :
Lentit personne devient une relation Personne(NumPersonne, Nom, Prenom,
Adresse, Tel).
Lassociation est_mari_ devient une relation Mariage(NumPersonne 1, NumPersonne 2,
DateMariage).
Les champs de lassociation de mme nom doivent tre renomms car ils ne peuvent avoir
le mme nom.
Les cardinalits 0-n de lassociation mariage ne signifient pas forcment que lon accepte la
polygamie, mais plutt que lon peut avoir t mari plusieurs fois des dates diffrentes.
ce sujet, la cl de la relation Mariage suppose quune personne ne se marie pas deux fois
avec la mme personne.
partir du modle entit-association modlisant le lien de mariage, effectuez le passage
au modle relationnel (voir figure 3.54).
Figure 3.54
Modle entit-
association du
mariage.
Client
# IDPersonne
Nom
Adresse
NumTlphone

Est mari
DateMariage
0,n
0,n

91 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 12 NORMALISATION
La relation nest pas en premire forme normale en raison des valeurs qui correspondent
bien des valeurs multiples contenues dans le champ Adresse_Mail. En revanche, il nest
pas sr que la valeur Employ, asserment de le champ Poste soit une valeur multiple.
Une virgule dans un champ ninduit pas ncessairement quil contient des valeurs
multiples : cest peut-tre un contenu normalis (un peu trange certes).
On remarque que cette relation na pas non plus de cl candidate srieuse, si lon tient
compte des dpendances fonctionnelles entre les champs. Or, seule la prsence dune cl
permettra de faire la dcomposition ncessaire la normalisation. On ajoute un champ
Ident_Personne qui en sera la cl et lon dcompose en trois relations comme on la vu
prcdemment.
Une autre solution moins lourde est dajouter un champ supplmentaire pour ladresse
mail en supposant que lon nen stockera toujours que deux. On effectue alors la rparti-
tion des valeurs entre les champs. Il faut tout de mme ajouter le champ Ident_Personne
pour que la relation possde une cl (voir figure 3.56).
Personne(Ident_Personne, Nom, Poste, Adresse_mail1, Adresse_mail2)
Cette relation est-elle en premire forme normale (voir figure 3.55) ?
Personne(Nom, Adresse_mail, Poste)
Nom Adresse_mail Poste
Andr
Dupont
adup@philips.com,
andre@dupond.fr
Directeur
Stanislas De
la Motte
sdlm@versailles.mairie.fr
Employ,
asserment
Elisabeth
Macroix
elsa@yago.to, mac@rien.fr Assistante
Ident
_Personne
Nom Poste Adresse_mail1 Adresse_mail2
1
Andr
Dupont
Directeur adup@philips.com andre@dupond.fr
2
Stanislas De
la Motte
Employ,
asserment
sdlm@ver-
sailles.mairie.fr
sdlm@ver-
sailles.mairie.fr
3
Elisabeth
Macroix
Assistante elsa@yago.to mac@rien.fr
Figure 3.56
Relation
Personne
modifie.
Figure 3.55
Relation
Personne.

92 Cration de bases de donnes
EXERCICE 13 NORMALISATION II
La relation est en premire forme normale.
Il ny a pas de cl candidate atomique pour cette relation.
Daprs lnonc, on dtermine que le couple de champs Numero_Film & Format est
une cl. Or, il y a une dpendance fonctionnelle entre le support et le format. On a donc
une dpendance entre un champ non cl et une partie de la cl ; la relation nest pas en
deuxime forme normale.
On dcompose la relation de la manire suivante (voir figure 3.58).
Film(Prix, Format, Type, Nombre, Numero Film)
FormatSup(Format, Support)
On considre la relation Film prcdente laquelle on a ajout le champ Support (voir
figure 3.57).
Film(Prix, Format, Couleur, Nombre, Numero_Film, Support)
Prix Format Type Nombre Numro_Film Support
12 4 :3 Couleur 3 2 VHS
4 16 :9 Noir/Blanc 1 4 DVD
12 16 :9 Couleur 1664 56 DVD
35 4 :3 Noir/Blanc 890 12 VHS
12 16 :9 Noir/Blanc 1 12 DVD
99 Inconnu Noir/Blanc 3 111 VHS
Aprs discussion avec les utilisateurs de la base de donnes, il ne peut y avoir deux fois le
mme film avec le mme format dans cette relation qui est un tat des stocks rcapitulatif.
ce sujet, les utilisateurs indiquent que les formats 16 :9 seront toujours sur support
DVD et les formats 4 :3 et Inconnu en support VHS.
La relation est-elle en deuxime forme normale ?
Prix Format Type Nombre Numero Film
12 4 :3 Couleur 3 2
4 16 :9 Noir/Blanc 1 4
12 16 :9 Couleur 1664 50
35 4 :3 Noir/Blanc 890 12
12 16 :9 Noir/Blanc 1 12
Format Support
4 :3 VHS
16 :9 DVD
Inconnu VHS
Figure 3.57
Relation Film
avec support.
Figure 3.58
Dcomposition de
la relation Film
avec support.

93 Approche relationnelle
E
x
e
r
c
i
c
e
s
Chapitre
Les relations sont en premire et en deuxime forme normale. On effectue une jointure
pour reconstituer linformation de dpart.
EXERCICE 14 NORMALISATION III
La relation est en premire forme normale, il ny a pas de champs multivalus.
La cl de cette relation est atomique. Cest le champ Numero_carte qui a sans doute t
ajout cet effet, sinon il ny avait pas vraiment de cls candidates. Si la cl est atomique,
alors on est sr que la relation est en deuxime forme normale : il ne peut y avoir de
dpendance entre un champ et une partie de la cl.
Il existe une dpendance fonctionnelle entre deux champs non cl Ville et Etablisse-
ment (voir discussion au dbut du chapitre). On est dans le cas dune dpendance de
type transitif . Le champ Ville dpend du champ Etablissement qui dpend de la
cl Numero_carte.
On dcompose la relation de la manire suivante (voir figures 3.60 et 3.61).
On considre la relation suivante que lon a dj tudie au dbut du chapitre (voir figure
3.59).
Lecteur(Numero carte, Nom, Age, Ville, Etablissement)
Numro carte Nom Age Ville Etablissement
1 Henri 10 Paris
Universit
Sorbonne
2 Stanislas 34 Paris Universit Jussieu
3 Henriette 44 Lyon CHU Bron
4 Dominique 19 Nancy
Universit
Poincar
5 Isabelle 56 Nancy INPL
6 Olivier 51 Marseille
Universit
Saint Charles
7 Henri 98 Paris
Universit
Sorbonne
8 Jerome 23 Nancy INPL
9 Laurence 34 Bordeaux
Universit
Victor Segalen
10 Christian 41 Paris
Ecole Normale
Suprieure
11 Antoine 16 Marseille
Universit
Saint Charles
12 Laurence 34 Paris Universit Jussieu
Est-elle en troisime forme normale ?
Figure 3.59
Relation Lecteur .

94 Cration de bases de donnes
Lecteur(Numero_carte, Nom, Age, Etablissement)
Attention, la dcomposition suppose que le nom de ltablissement est unique quelle que
soit la ville. En effet, le champ Etablissement est la cl de la deuxime relation. Cest ce
qui a permis dtablir la relation de dpendance fonctionnelle. Cela ne peut tre garanti
sans discussion avec les utilisateurs de la base de donnes. Si ce ntait pas le cas, il faudrait
utiliser un identifiant unique pour chaque tablissement, qui se trouverait alors dans les
deux relations et servirait faire la jointure.
Etablissement_Ville(Etablissement, Ville)
Les deux relations sont en troisime forme normale. On effectue une jointure pour
reconstituer linformation de dpart.
Numero carte Nom Age Etablissement
1 Henri 10 Universit Sorbonne
2 Stanislas 34 Universit Jussieu
3 Henriette 44 CHU Bron
4 Dominique 19 Universit Poincar
5 Isabelle 56 INPL
6 Olivier 51 Universit Saint Charles
7 Henri 98 Universit Sorbonne
8 Jerome 23 INPL
9 Laurence 34
Universit Victor
Segalen
10 Christian 41
Ecole Normale
Suprieure
11 Antoine 16 Universit Saint Charles
12 Laurence 34 Universit Jussieu
Etablissement Ville
Universit Sorbonne Paris
Universit Jussieu Paris
CHU Bron Lyon
Universit Poincar Nancy
INPL Nancy
Universit Saint Charles Marseille
Universit Victor
Segalen
Bordeaux
cole Normale
Suprieure
Paris
Figure 3.60
Relation Lecteur
dcompose I.
Figure 3.61
Relation Lecteur
dcompose II.

SQL
95
Chapitre
1. Concepts du langage SQL ........ 96
2. Oprations relationnelles
avec SQL ................................. 97
3. Gestion de tables et de vues .... 110
4. Gestion des donnes .............. 116
Exercices
1. Projection simple .................... 120
2. Projection avec une colonne
calcule ................................. 120
3. Projection/restriction avec
un oprateur statistique ........... 120
4. Agrgat ................................. 121
5. Question ngative .................. 121
6. Produit cartsien ..................... 121
7. Jointure simple ....................... 122
8. Requte SQL trange .............. 122
9. Autre question ngative
jointure externe .................... 122
10. Slection sur un agrgat
dune jointure ......................... 123
11. Slection par rapport au rsultat
dun calcul statistique .............. 124
12. Cration dune table ............... 124
13. Insertion de donnes dans
une table ............................... 125
14. Modification des donnes
dune table ............................ 125
15. Requte combine .................. 125
Le langage SQL est lun des lments qui ont
contribu au dveloppement et au succs de
lapproche relationnelle dans le monde des bases de
donnes. En effet, la normalisation internationale du
langage garantit la prennit et la stabilit des
donnes ainsi que des dveloppements qui leur sont
associs, indpendamment du SGBD et du langage
utiliss.
Ce chapitre aborde les concepts et la syntaxe du
langage SQL, et prsente les trois grandes familles
doprations que le langage permet dexprimer :
Linterrogation et la recherche dans les tables.
La gestion de tables et de vues munies des
contraintes associes. Ces instructions concernent
la table et sa structure et constituent la partie LDD
(Langage de Description des Donnes) de SQL.
La manipulation de donnes. Ces instructions
concernent les donnes contenues dans la table et
constituent la partie LMD (Langage de
Manipulation des Donnes) de SQL.

96 Cration de bases de donnes
1 Concepts du langage SQL
Le langage SQL est essentiellement un sous-produit issu des travaux du groupe de tra-
vail System-R. Il sagissait de la ralisation pratique des concepts de lapproche relation-
nelle chez IBM. Cest une volution du langage SEQUEL, lui-mme driv du langage de
recherche SQUARE.
Le langage est normalis par lISO depuis 1987. La deuxime version du langage, SQL2, a
t adopte en 1992. Les exemples de cet ouvrage sont bass, dans la mesure du possible,
sur cette norme. La troisime version du langage, SQL3, normalise en 1999, ajoute essen-
tiellement les fonctionnalits lies lutilisation de lapproche objet.
La quasi-totalit des SGBD disposent dune interface SQL mme si aucun ne couvre
lensemble de la norme. La norme SQL prvoit trois niveaux de conformit : le niveau
dentre, le niveau intermdiaire et le niveau complet. Les SGBD respectent en gnral le
premier niveau et adoptent certains lments des autres niveaux. La normalisation du lan-
gage garantit la portabilit gnrale des applications dun SGBD un autre, mme sil sub-
siste des diffrences entre les approches des diffrents diteurs. En effet, compte tenu du
temps ncessaire au processus de modification de la norme, certains diteurs la devancent
parfois et intgrent des fonctionnalits qui leur semblent essentielles ou susceptibles de
leur donner un avantage concurrentiel.
Le langage SQL manipule lobjet fondamental de lapproche relationnelle : la relation
reprsente par une table vue au chapitre 3. SQL est un langage dit non procdural ou
dclaratif , cest--dire que lon ne dcrit pas la manire deffectuer les oprations pas
pas : cest le SGBD qui choisit la mthode utilise pour y parvenir. Cest ce qui explique
que des concours de rapidit de rsolution de requte soient organiss chaque anne pour
tester les diffrentes stratgies des diteurs. Par consquent, il ne dispose pas dinstruc-
tions de structuration, telles que des boucles. Pour effectuer ce type doprations, on uti-
lise un langage de programmation classique , comme les langages C, php, Java et bien
dautres. Les instructions SQL sont alors intgres dans le langage via une interface spci-
fique. Les rsultats de la requte SQL sont alors stocks dans des structures de donnes
propres au langage employ (par exemple un tableau) afin de pouvoir les manipuler. Cest
typiquement ce procd qui est employ pour construire une interface daccs une base
de donnes par le Web.
Le langage de programmation qui intgre le langage SQL est alors appel langage hte
(voir figure 4.1). De petites diffrences de syntaxe peuvent apparatre entre une requte
SQL exprime interactivement et la version intgre dans un langage de programma-
tion. Enfin, il existe une extension procdurale de SQL qui ajoute les fonctions, proc-
dures et mthodes SQL mais qui ne sera pas traite dans le cadre de cet ouvrage.
Remarque
Un ensemble dinstructions SQL se nomme une requte. Une requte SQL se termine toujours par
le caractre ; .

97 SQL
Chapitre
Figure 4.1
Interface entre
SQL et les
langages de
programmation.
1.1 ORGANISATION DU CHAPITRE
Linterrogation dune ou de plusieurs tables est aborde dans la section Oprations rela-
tionnelles avec SQL . Toutes les requtes de ce type retournent comme rsultat une table
qui peut tre sauvegarde sous forme de table temporaire. Cette table intermdiaire est
utilise pour effectuer dautres requtes.
La cration, la modification et la destruction dune table sont abordes dans la section
Gestion de tables et de vues . Lexpression des contrles de cohrence (contraintes
dintgrit) que lon souhaite appliquer une table est traite logiquement dans cette sec-
tion. La manipulation (insertion, modification et suppression) des donnes dune table est
aborde dans la section Gestion des donnes . La partie de SQL qui est consacre la
gestion des autorisations sera aborde plus loin au chapitre 6.
Cet ouvrage ne traite pas de lintgralit de la norme SQL ; ce nest pas son objectif. Pour
en savoir plus, vous pouvez vous reporter louvrage dit dans la mme collection (F.
Brouard et C. Soutou, Syntex SQL).
2 Oprations relationnelles avec SQL
Cette section prsente lexpression en SQL des oprations de lalgbre relationnelle vues
prcdemment : projection, slection, agrgats, produits cartsiens et jointures. Une des-
cription prcise de ces oprations se trouve au chapitre 3. Les exemples simples qui pr-
sentent les oprations relationnelles utilisent la base de donnes casse (voir figure 4.2).
Remarque
Par convention, dans tous les exemples qui suivent, les instructions SQL sont indiques en majus-
cules afin de les diffrencier des noms de tables et de champs. Les interprteurs SQL ne diffren-
cient pas les majuscules des minuscules en ce qui concerne les instructions. En revanche, cela
dpend du systme dexploitation utilis ; le nom des champs ou des tables doit en gnral tre
crit de manire exacte.
Programme en
langage hte
Bibliothque
fonctions SQL
SGBD
+
code SQL

98 Cration de bases de donnes
Figure 4.2
Base de donnes
casse.
2.1 PROJECTION (SELECT)
Lopration de projection consiste slectionner la (les) colonne(s) que lon veut voir figu-
rer dans la table rsultat . On spcifie la liste des colonnes inclure dans cette table der-
rire linstruction SELECT en les sparant par des virgules. Si lon dsire afficher toutes les
colonnes, on les dsigne par le caractre * .
SELECT Nom, Ville
FROM personne ;
Nom Ville
Nestor Paris
Irma Lille
Henri Paris
Josette Lyon
Jacques Bordeaux
Bleue Floride Renault 6
Rose Alpine A310 Renault 5
Blanche 403 Peugeot 4
Blanche GT Opel 3
Noire SM Citroen 2
Rouge 404 Peugeot 1
Type Type Marque NumVoit
2 5 45 000 2000-04-02
1 4 30 000 1998-06-14
4 2 70 000 1996-03-30
1 1 10 000 1985-12-03
NumAch NumVoit Prix DateVente
M
F
M
F
M
Sexe
Bordeaux 50 Jacques 5
Lyon 34 Josette 4
Paris 45 Henri 3
Lille 20 Irma 2
Paris 96 Nestor 1
Ville Age Nom NumAch
Vente
Voiture
Personne
Projection sur les
colonnes Nom et
Ville de la table
Personne.

99 SQL
Chapitre
SELECT *
FROM personne ;
Les colonnes de la table rsultat peuvent tre renommes par le mot cl AS.
SELECT Ville AS City
FROM personne ;
Valeurs distinctes dune colonne
Une colonne Salutations ne devrait contenir que les valeurs normalises Madame ,
Monsieur , Mademoiselle . Laffichage des valeurs distinctes permet de lister les dif-
frentes valeurs prises par la colonne pour reprer dventuelles incohrences comme la
prsence dune valeur Mr. , M. , etc. Afin dliminer les doublons ventuels des
valeurs dune colonne de la table rsultat , on fait prcder le nom de la colonne par le
mot cl DISTINCT.
SELECT DISTINCT Marque
FROM voiture ;
Utilisation dexpressions pour crer une colonne
On rappelle quun grand principe en base de donnes est que lon ne stocke pas dans une
table ce qui peut tre calcul. On vite ainsi loccupation de place inutile ainsi que les pro-
blmes dincohrence provoqus par la mise jour des donnes.
Par exemple, si lon dispose dune colonne prix et dune colonne quantit, on ne stocke
pas la colonne chiffre daffaire on calcule ses valeurs partir des colonnes prcdentes
(chiffre daffaires = prix quantit). Cette manire de procder sera plus coteuse en
NumAch Nom Age Ville Sexe
1 Nestor 96 Paris M
2 Irma 20 Lille F
3 Henri 45 Paris M
4 Josette 34 Lyon F
5 Jacques 50 Bordeaux M
City
Paris
Lille
Paris
Lyon
Bordeaux
Marque
Peugeot
Citroen
Opel
Renault
Projection sur tous
les champs de la
table Personne.
Projection sur les
valeurs distinctes
du champ Marque
de la table
voiture.

100 Cration de bases de donnes
calcul et pourra ventuellement affecter les performances du systme. Les valeurs des
colonnes (colonnes) de la table rsultat peuvent tre constitues par des expressions
construites avec les oprateurs suivants (voir tableau 4.1).
SELECT Prix, DateVente, (Prix / 6.5596) AS Prix_Euros
FROM vente ;
SQL dispose de nombreuses autres fonctions intgres, parfois dpendantes du SGBD uti-
lis, qui permettent par exemple le traitement des colonnes de types caractres, date
SELECT UPPER(Nom) AS NomMajuscule
FROM personne ;
SELECT MONTH(DateVente) AS Mois
FROM vente ;
Utilisation de fonctions statistiques sur toutes les valeurs dune table
SQL ne possde pas dinstruction de structuration et ne permet donc pas de raliser
des boucles. Il possde des fonctions simples de traitement des donnes dune colonne ; les
calculs plus complexes seront raliss laide dun langage de programmation comme on
+ Addition
- Soustraction
* Multiplication
/ Division
% Modulo
Prix DateVente Prix_Euros
10 000 1985-12-03 1 524.483 200
70 000 1996-03-30 10 671.382 401
30 000 1998-06-14 4 573.449 601
45 000 2000-04-02 6 860.174 401
NomMajuscule
NESTOR
IRMA
HENRI
JOSETTE
JACQUES
Mois
12
3
6
4
Tableau 4.1
Oprateurs
dexpressions de
SQL.
Cration dune
colonne
Prix_Euros dans la
table vente
contenant le prix de
vente en euros.
Transformation
dune colonne
Nom de la table
Personne en
majuscules.
Extraction du mois
de la colonne
'DateVente' de la
table 'Vente'.

101 SQL
Chapitre
la indiqu prcdemment. Les colonnes (colonnes) de la table rsultat peuvent tre
constitues de rsultats de fonctions statistiques intgres SQL. Voici une liste (non
exhaustive) des oprateurs statistiques de SQL (voir tableau 4.2) :
SELECT AVG(Prix) AS Prix_Moyen
FROM vente ;
SELECT COUNT(*) AS Nombre_Personne
FROM personne ;
Dans le cas de la fonction COUNT, on ne spcifie pas la colonne sur laquelle sapplique la
fonction puisquil sagit de la table entire.
2.2 SLECTION OU RESTRICTION (WHERE)
Lopration de slection (ou restriction) consiste indiquer un ou plusieurs critres pour
choisir les lignes inclure dans la table rsultat . Ces critres utilisent videmment le
contenu des valeurs des colonnes. Le critre de slection est indiqu la suite du mot cl
WHERE. Il est constitu dexpressions de conditions composes laide doprateurs de
comparaison et combines laide de connecteurs logiques.
Voici la liste des oprateurs de comparaison classiques permettant de constituer les expres-
sions en SQL (voir tableau 4.3), la liste des oprateurs de comparaison spcifiques SQL
(voir tableau 4.4), et la liste des oprateurs et connecteurs logiques (voir tableau 4.5).
COUNT Comptage du nombre dlments (lignes) de la table
MAX Maximum des lments dune colonne
MIN Minimum des lments dune colonne
AVG Moyenne des lments dune colonne
SUM Somme des lments dune colonne
Remarque
Les fonctions statistiques sappliquent lensemble des donnes dune colonne (sauf pour la fonc-
tion COUNT qui sapplique aux lignes de la table entire). Pour toutes ces oprations, la table
rsultat contiendra une seule ligne et souvent une seule colonne.
Prix_Moyen
38 750.000 0
Nombre_Personne
5
= gal
<> Diffrent
< Infrieur
Tableau 4.2
Oprateurs
statistiques de SQL.
Calcul de la
moyenne des prix
de vente pour la
table vente.
Calcul du nombre
de personnes (le
nombre de lignes
en ralit) de la
table personne.
Tableau 4.3
Oprateurs de
comparaison de
SQL.

102 Cration de bases de donnes
SELECT *
FROM vente
WHERE Prix > 50 000 ;
SELECT *
FROM voiture
WHERE Couleur IN ("Blanc","Rouge") ;
SELECT *
FROM personne
WHERE Age BETWEEN 40 AND 60;
SELECT *
FROM voiture
WHERE Couleur="Blanche" OR Marque="Peugeot" ;
> Suprieur
<= Infrieur ou gal
>= Suprieur ou gal
DateVente Prix NumVoit NumAch
1996-03-30 70 000 2 4
BETWEEN <valeur> AND <valeur> Appartient un intervalle
IN <liste de valeurs> Appartient un ensemble de valeurs
IS NULL Teste si la colonne nest pas renseigne
LIKE Compare des chanes de caractres
NumVoit Marque Type Couleur
1 Peugeot 404 Rouge
NumAch Nom Age Ville Sexe
3 Henri 45 Paris M
5 Jacques 50 Bordeaux M
AND Et : les deux conditions sont vraies simultanment
OR Ou : lune des deux conditions est vraie
NOT Inversion de la condition
NumVoit Marque Type Couleur
1 Peugeot 404 Rouge
3 Opel GT Blanche
4 Peugeot 403 Blanche
Tableau 4.4
Oprateurs de
comparaison
spcifiques SQL
permettant de
constituer des
expressions.
Extraction des
voitures blanches
ou rouges.
Extraction des
personnes dont
lge est compris
en 40 et 60.
Extraction des
enregistrements de
la table vente dont
le prix est suprieur
50 000.
Tableau 4.5
Oprateurs et
connecteurs
logiques de SQL
permettant de
constituer des
expressions.
Extraction des
voitures de couleur
Blanche ou de
marque
Peugeot .

103 SQL
Chapitre
SELECT *
FROM personne
WHERE NOT (Ville=Paris);
2.3 AGRGATS OU GROUPAGE (GROUP BY)
Les oprations d agrgation ou de groupage regroupent les lignes dune table par
valeurs contenues dans une colonne. On applique gnralement des oprations de type
statistique sur les sous-tables ainsi cres. Pour raliser cette opration avec SQL, on
utilise le mot cl GROUP BY suivi du nom de la colonne sur laquelle seffectue lagrgat.
SELECT Marque
FROM voiture
GROUP BY Marque ;
On obtient dans ce cas le mme rsultat que si lon avait utilis le mot cl DISTINCT vu
prcdemment. Lutilisation courante de cette opration est dappliquer en une seule ins-
truction les fonctions statistiques dj abordes aux diffrents sous-ensembles dune table
ainsi constitus.
SELECT Marque, COUNT(*) AS Compte
FROM voiture
GROUP BY Marque ;
SELECT Ville, AVG(ge) AS Moyenne_Age
FROM personne
GROUP BY Ville ;
NumAch Nom Age Ville Sexe
2 Irma 20 Lille F
4 Josette 34 Lyon F
5 Jacques 50 Bordeaux M
Marque
Citroen
Opel
Peugeot
Renault
Marque Compte
Citroen 1
Opel 1
Peugeot 2
Renault 2
Ville Moyenne_Age
Bordeaux 50.0000
Extraction des
personnes
nhabitant pas
Paris.
Affichage des
diffrentes
marques de
voitures de la table
voiture.
Calcul du nombre
de voitures des
diffrentes
marques de la
table voiture.
Calcul de la
moyenne dge par
ville partir de la
table personne.

104 Cration de bases de donnes
Restriction sur le rsultat
Le rsultat de lopration de groupage peut lui-mme tre filtr : cest--dire que lon
effectue une slection des lignes par rapport au contenu des colonnes obtenues dans la
table rsultat prcdente. En pratique, on filtre sur le rsultat des oprations statisti-
ques appliques aux sous-ensembles dfinis par le groupage.
On reprend lexemple prcdent qui a permis de calculer le nombre de voitures par mar-
ques. On suppose que lon limine du rsultat les marques dont on possde moins de deux
voitures en considrant que ces marques ne sont pas reprsentatives du parc.
SELECT Marque, COUNT(*) AS Compte
FROM voiture
GROUP BY Marque
HAVING Compte > 1;
Supposons que lon veuille liminer les voitures rouges de notre calcul.
SELECT Marque, COUNT(*) AS Compte
FROM voiture
WHERE NOT (Couleur=Rouge)
GROUP BY Marque;
2.4 REQUTES SUR PLUSIEURS TABLES
Lorsque lon utilise plusieurs tables dans une requte SQL, il peut exister une ambigut
dans les expressions sur les noms de colonnes. En effet, deux tables peuvent avoir une
colonne de nom identique. Pour cette raison, on prfixera le nom de la colonne par le nom
Lille 20.0000
Lyon 34.0000
Paris 70.5000
Marque Compte
Peugeot 2
Renault 2
Remarque
Le mot cl HAVING permet deffectuer une slection sur le rsultat de lopration de groupage. Le
mot cl WHERE opre une slection sur les lments (lignes) de la table avant lopration de grou-
page..
Marque Compte
Citroen 1
Opel 1
Peugeot 1
Renault 2
Ville Moyenne_Age
Calcul du nombre
de voitures par
marque de la table
voiture dont le
nombre est
suprieur 1.
Calcul du nombre
de voitures par
marque de la table
voiture dont la
couleur est
Rouge .

105 SQL
Chapitre
de la table. Pour des questions de lisibilit, il est prfrable de le faire systmatiquement
pour toutes les requtes mme si ce nest pas absolument ncessaire.
SELECT voiture.Marque, voiture.Couleur
FROM voiture ;
Cette notation peut devenir rapidement fastidieuse si le nombre de tables est lev et si
leurs noms sont longs. Dans ce cas, on dsigne la table par un alias plus commode, qui
peut tre rduit une simple lettre, plutt que par son nom complet. Lalias est indiqu
simplement la suite du nom de la table ou laide du mot cl AS qui est optionnel.
SELECT Vo.Marque, Vo.Couleur
FROM voiture AS Vo;
Produit cartsien
Le produit cartsien est la combinaison de toutes les lignes dune table avec toutes les lignes
dune autre table sans tenir aucun compte du sens associ aux donnes. Cest une op-
ration qui na gure dintrt en pratique. En SQL, cette opration scrit simplement.
SELECT *
FROM personne, voiture ;
Marque Couleur
Peugeot Rouge
Citroen Noire
Opel Blanche
Peugeot Blanche
Renault Rose
Renault Bleue
Marque Couleur
Peugeot Rouge
Citroen Noire
Opel Blanche
Peugeot Blanche
Renault Rose
Renault Bleue
NumAch Nom Age Ville Sexe
Num
Voit
Marque Type Couleur
1 Nestor 96 Paris M 1 Peugeot 404 Rouge
2 Irma 20 Lille F 1 Peugeot 404 Rouge
3 Henri 45 Paris M 1 Peugeot 404 Rouge
4 Josette 34 Lyon F 1 Peugeot 404 Rouge
5 Jacques 50 Bordeaux M 1 Peugeot 404 Rouge
1 Nestor 96 Paris M 2 Citroen SM Noire
Qualification des
attributs par leur
table
dappartenance.
Qualification
simplifie des
attributs par leur
table
dappartenance.
Produit cartsien.

106 Cration de bases de donnes
Le nombre de lignes de la table rsultat est gal au produit du nombre de lignes des
deux tables. Les colonnes sont celles des deux tables simplement juxtaposes.
Jointure interne (INNER JOIN)
Il sagit de lopration de base de lalgbre relationnelle. Elle permet de lier deux tables
entre elles en introduisant un critre de sens des donnes issu du monde rel par oppo-
sition lopration prcdente. Elle peut sexprimer de plusieurs manires en SQL. La pre-
mire est semblable la restriction du produit cartsien prcdent, mais dans ce cas la
requte nest gnralement pas traite de manire optimale par le SGBD.
2 Irma 20 Lille F 2 Citroen SM Noire
3 Henri 45 Paris M 2 Citroen SM Noire
4 Josette 34 Lyon F 2 Citroen SM Noire
5 Jacques 50 Bordeaux M 2 Citroen SM Noire
1 Nestor 96 Paris M 3 Opel GT Blanche
2 Irma 20 Lille F 3 Opel GT Blanche
3 Henri 45 Paris M 3 Opel GT Blanche
4 Josette 34 Lyon F 3 Opel GT Blanche
5 Jacques 50 Bordeaux M 3 Opel GT Blanche
1 Nestor 96 Paris M 4 Peugeot 403 Blanche
2 Irma 20 Lille F 4 Peugeot 403 Blanche
3 Henri 45 Paris M 4 Peugeot 403 Blanche
4 Josette 34 Lyon F 4 Peugeot 403 Blanche
5 Jacques 50 Bordeaux M 4 Peugeot 403 Blanche
1 Nestor 96 Paris M 5 Renault
AlpineA
310
Rose
2 Irma 20 Lille F 5 Renault
AlpineA
310
Rose
3 Henri 45 Paris M 5 Renault
AlpineA
310
Rose
4 Josette 34 Lyon F 5 Renault
AlpineA
310
Rose
5 Jacques 50 Bordeaux M 5 Renault
AlpineA
310
Rose
1 Nestor 96 Paris M 6 Renault Floride Bleue
2 Irma 20 Lille F 6 Renault Floride Bleue
3 Henri 45 Paris M 6 Renault Floride Bleue
4 Josette 34 Lyon F 6 Renault Floride Bleue
5 Jacques 50 Bordeaux M 6 Renault Floride Bleue
NumAch Nom Age Ville Sexe
Num
Voit
Marque Type Couleur

107 SQL
Chapitre
SELECT voiture.Marque, voiture.Couleur, vente.Prix
FROM voiture, vente
WHERE voiture.NumVoit=vente.NumVoit ;
Une autre manire dexprimer la jointure interne passe par un oprateur de jointure sp-
cifique JOIN. Il faut bien sr spcifier la colonne sur laquelle seffectue la jointure.
SELECT voiture.Marque, voiture.Couleur, vente.Prix
FROM vente JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
Le traitement de la requte est dans ce cas optimis par le SGBD. Cest important, car
lopration de jointure est complexe raliser pour un SGBD et est coteuse en temps et
en ressources. Le nombre de lignes de la table rsultat est gal cette fois au nombre de
lignes contenues dans les deux tables pour lesquelles le critre dgalit des colonnes est
respect. Il est bien sr possible deffectuer la jointure sur plus de deux tables : on indique
alors les diffrents critres de jointure entre les tables.
SELECT vo.Marque, vo.Couleur, ve.Prix, pe.Nom, pe.Age
FROM voiture AS vo, vente AS ve, personne AS pe
WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
ou
SELECT vo.Marque, vo.Couleur, ve.Prix, pe.Nom, pe.Age
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit)
AND (pe.NumAch=ve. NumAch);
Dans ce cas, il est indispensable de prciser le nom de la table pour chaque colonne dans la
mesure o les tables ont des noms de colonnes en commun ; de plus, il peut tre intres-
sant de les dsigner par des alias pour une simple commodit dcriture.
Marque Couleur Prix
Peugeot Rouge 10 000
Citroen Noire 70 000
Peugeot Blanche 30 000
Renault Rose 45 000
Marque Couleur Prix Nom Age
Peugeot Rouge 10 000 Nestor 96
Citroen Noire 70 000 Josette 34
Peugeot Blanche 30 000 Nestor 96
Renault Rose 45 000 Irma 20
Remarque
Lopration de jointure prcdente est dite galement interne ; le mot cl INNER devant
JOIN est, pour la plupart des SGBD, implicite et donc optionnel, mais il faudrait crire en
toute rigueur :
SELECT voiture.Marque, voiture.Couleur, vente.Prix
FROM vente INNER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
Construction de la
jointure des tables
voiture et vente
sur le critre
dgalit de la
colonne NumVoit.
Construction de la
jointure des tables
voiture,
personne et
vente sur les
critres dgalit
des colonnes
NumaAch et
NumVoit.

108 Cration de bases de donnes
Jointure externe (OUTER JOIN)
Lopration de jointure interne ne permet pas de rpondre des questions du type :
Quelles sont les voitures qui nont pas t vendues ? . cette fin, il nous faut utiliser un
oprateur capable dinclure dans le rsultat les lignes de la table voiture qui nont pas de
correspondance dans la table vente (par rapport aux valeurs de la colonne NumVoit)
sans quil sagisse dun produit cartsien : cette opration spcifique se nomme la jointure
externe.
Loprateur SQL de jointure externe sexprime par le mot cl OUTER JOIN. Cette opra-
tion nest pas symtrique : soit on inclut toutes les lignes dune table, soit toutes celles de
lautre. On prcise cela laide des mots cls LEFT et RIGHT ou en inversant simplement
lordre des tables dans lexpression de linstruction de jointure.
Dans la requte qui suit, toutes les lignes de la table voiture seront affiches, y compris
celles pour lesquelles la colonne NumVoit na pas de correspondance dans vente : les
colonnes issues de vente ne pourront alors tre mises en correspondance et auront la
valeur NULL.
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;
Si lon opre la requte en inversant lordre des tables, ou en employant le mot cl RIGHT,
on obtient la mme rponse que pour la requte dqui-jointure ci-dessus. Cela signifie
quil ny a pas de lignes dans vente dont le contenu de la colonne NumVoit ne possde
pas de correspondance dans la colonne NumVoit de la table voiture. Ce rsultat est pr-
visible puisquune voiture doit exister dans la table voiture pour pouvoir faire lobjet
dune vente. On dispose alors dun moyen de contrler la cohrence des donnes entre les
tables : dans notre cas, on pourra ainsi vrifier quil ny a pas de valeur didentifiant de voi-
ture dans la table vente (contenu de la colonne NumVoit de la table vente) qui ne se
trouve pas dans la table voiture (contenu de la colonne NumVoit de la table voiture).
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
FROM vente LEFT OUTER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
NumVoit NumVoit Marque Couleur Prix
1 1 Peugeot Rouge 10 000
2 2 Citroen Noire 70 000
3 NULL Opel Blanche NULL
4 4 Peugeot Blanche 30 000
5 5 Renault Rose 45 000
6 NULL Renault Bleue NULL
NumVoit NumVoit Marque Couleur Prix
1 1 Peugeot Rouge 10 000
2 2 Citroen Noire 70 000
4 4 Peugeot Blanche 30 000
5 5 Renault Rose 45 000
Construction de la
jointure externe des
tables voiture et
vente sur les
critres dgalit de
la colonne
NumVoit.
Construction de la
jointure externe
inverse des tables
voiture et vente
sur les critres
dgalit de la
colonne NumVoit.

109 SQL
Chapitre
ou
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
FROM voiture RIGTH OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;
Il faut terminer la requte et rpondre la question de dpart : Quelles sont les voitures
qui nont pas t vendues ? Pour ce faire, il suffit de slectionner les lignes dont lune des
colonnes issues de la table vente na pas pu tre mise en correspondance avec une ligne de
la table voiture : le contenu de cette colonne sera vide, ce qui signifie que lon peut le tes-
ter avec le mot cl NULL. Par exemple, on teste le contenu de la colonne Prix issue de la
table vente.
SELECT voiture.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit
WHERE vente.Prix IS NULL;
2.5 TRI DU RSULTAT DUNE REQUTE
On utilise le mot cl ORDER BY pour spcifier la (les) colonne(s) sur laquelle (lesquelles)
on souhaite trier le rsultat.
SELECT Marque, Type
FROM voiture
ORDER BY Marque ;
Il est possible de prciser lordre de tri par les mots cls ASC (croissant par dfaut) ou
DESC (dcroissant).
SELECT Prix, DateVente
FROM vente
ORDER BY Prix DESC ;
NumVoit Marque Couleur Prix
3 Opel Blanche NULL
6 Renault Bleue NULL
Marque Type
Citroen SM
Opel GT
Peugeot 404
Peugeot 403
Renault
Alpine
A310
Renault Floride
Prix DateVente
70 000 1996-03-30
45 000 2000-04-02
30 000 1998-06-14
10 000 1985-12-03
Slection des lignes
de la table
prcdente.
Tri par Marque de
la table voiture.
Tri par Marque de
la table voiture en
ordre dcroissant.

110 Cration de bases de donnes
On peut indiquer plusieurs critres de tri, qui sont lus et traits de gauche droite (ici, on
trie dabord par villes puis par ges).
SELECT Nom, Age, Ville
FROM personne
ORDER BY Ville, Age ;
3 Gestion de tables et de vues
3.1 TABLES
Le langage SQL comprend une partie manipulation de donnes (LMD) pour grer les
tables, qui est prsente dans cette section. Les oprations de cration, de suppression et de
modification des tables mettent jour le dictionnaire de donnes du SGBD. On rappelle
que le dictionnaire de donnes est une structure propre au SGBD qui contient la descrip-
tion des objets du SGBD (base de donnes, tables, colonnes, droits, etc.).
Cration
La cration dune table est une opration importante quil faut entreprendre avec soin.
Cest lors de cette tape que lon dfinit le type de donnes, la cl, les index ventuels et
quil convient dimposer des contraintes de validation garantissant la bonne qualit des
informations entres dans la table. La forme gnrale de linstruction de cration de table
est la suivante :
CREATE TABLE <Nom de la table> ( liste des colonnes avec leur type spar par ,) ;
CREATE TABLE voiture (
NumVoit INT,
Marque CHAR(40),
Type CHAR(30),
Couleur CHAR(20)
) ;
Nom Age Ville
Jacques 50 Bordeaux
Irma 20 Lille
Josette 34 Lyon
Henri 45 Paris
Nestor 96 Paris
Remarque
Pour pouvoir grer une table, il faut au pralable disposer des droits sur la base de donnes qui la
contient : ces aspects sont abords au chapitre 6.
Remarque
Le nom de la table ou dune colonne ne doit pas dpasser 128 caractres. Il commence par une
lettre, contient des chiffres, des lettres et le caractre _ . Attention de mme ne pas utiliser un
mot cl SQL.
Tri par Ville et par
Age de la table
personne.

111 SQL
Chapitre
Les tables peuvent tre cres de manire temporaire : elles seront donc effaces la fin de
la session de lutilisateur laide du mot cl TEMPORARY.
CREATE TEMPORARY TABLE temporaire (
Identifiant INT,
Jour DATE,
Valide BOOLEAN
) ;
Les tables peuvent tre issues directement du rsultat dune requte en utilisant le mot cl
AS : cest particulirement commode pour pouvoir disposer de rsultats intermdiaires en
fin de vrification, lors dune srie de manipulations sur une table.
CREATE TEMPORARY TABLE resultat
AS
(SELECT Vo.Marque, Vo.Couleur
FROM voiture AS Vo);
Type de donnes Le type de donnes est choisi essentiellement en fonction des opra-
tions qui sont effectues sur la colonne. Le choix du type permet galement de mettre en
place un premier niveau de restriction sur le contenu des donnes : une colonne de type
numrique ne pourra pas contenir de caractres. Des restrictions plus fines seront dfinies
la section Contraintes dintgrit .
Voici une liste (non exhaustive) des types de donnes SQL (voir tableaux 4.6, 4.7, 4.8 et
4.9).
INT Entier standard (32 bits)
SMALLINT Entier petit (16 bits)
REAL Rel (taille spcifique au SGBD)
FLOAT(n) Rel (reprsent sur n bits)
CHAR(n) Chane de caractres de longueur n
(codage ASCII 1 octet)
VARCHAR(n) Chane de caractres de longueur maximale n
(codage ASCII 1 octet)
NCHAR(b) Chane de caractres de longueur n
(codage Unicode sur 2 octets)
NVAR-
CHAR(b)
Chane de caractres de longueur maximale n
(codage Unicode sur 2 octets)
DATE Date
TIME[(n)]
Heure, n (optionnel) est le nombre de dcimales
reprsentant la fraction de secondes
BOOLEAN Boolen
BLOB
Binary Large Object : permet de stocker tout type
binaire (photo, fichier traitement de texte)
Cration de la table
voiture.
Tableau 4.6
Types de donnes
numriques de
SQL.
Tableau 4.7
Types de donnes
chanes de
caractres de SQL.
Tableau 4.8
Types de donnes
date de SQL.
Tableau 4.9
Types de donnes
binaires de SQL.

112 Cration de bases de donnes
Suppression
La commande DROP TABLE permet de supprimer une table.
DROP TABLE voiture
Si la table est rfrence dans une autre table (par exemple, contrainte dintgrit rfren-
tielle), le SGBD refuse en gnral de la supprimer : il utilise loption RESTRICT par
dfaut. Si lon dsire tout de mme la supprimer ainsi que tous les objets qui lui sont lis,
il faut alors utiliser loption CASCADE. Dans lexemple, si la table vente utilise la table
voiture comme table de rfrence pour le contenu de la colonne NumVoit, on ne peut
supprimer la table voiture avant davoir supprim la table vente.
DROP TABLE voiture CASCADE
Modification
La commande ALTER TABLE permet de modifier la structure de la table, cest--dire
dajouter, de supprimer ou modifier des colonnes.
ALTER TABLE voiture
ADD COLUMN enplus INT ;
SELECT * FROM voiture ;
ALTER TABLE voiture
DROP COLUMN Couleur;
SELECT * FROM voiture ;
NumVoit Marque Type Couleur enplus
1 Peugeot 404 Rouge NULL
2 Citroen SM Noire NULL
3 Opel GT Blanche NULL
4 Peugeot 403 Blanche NULL
5 Renault Alpine A310 Rose NULL
6 Renault Floride Bleue NULL
NumVoit Marque Type enplus
1 Peugeot 404 NULL
2 Citroen SM NULL
3 Opel GT NULL
4 Peugeot 403 NULL
5 Renault Alpine A310 NULL
6 Renault Floride NULL
Ajout dune
colonne de nom
enplus de type
INT la table
voiture (ADD
COLUMN).
Suppression de la
colonne de nom
Couleur de la
table voiture
(DROP COLUMN).
Affichage de la
table voiture
modifie.
Affichage de la
table voiture
modifie.

113 SQL
Chapitre
La commande ALTER permet de modifier galement les contraintes associes aux colon-
nes. Cette partie est traite la section suivante, Contraintes dintgrit . Le mot cl
COLUMN est optionnel.
Voici la suite dinstructions permettant la modification du nom de la colonne de nom
Couleur de la table voiture en Teinte en changeant son type. Linstruction UPDATE
sera dtaille la section Gestion des donnes .
ALTER TABLE voiture
ADD COLUMN Teinte CHAR(60);
SELECT * FROM voiture ;
UPDATE voiture
SET Teinte=Couleur ;
SELECT * FROM voiture ;
ALTER TABLE voiture
DROP COLUMN Couleur;
Remarque
Il nest pas possible de modifier directement le nom dune colonne ou son type. Il faut pour cela
crire une srie doprations, en utilisant par exemple des colonnes temporaires.
NumVoit Marque Type Couleur Teinte
1 Peugeot 404 Rouge NULL
2 Citroen SM Noire NULL
3 Opel GT Blanche NULL
4 Peugeot 403 Blanche NULL
5 Renault
Alpine
A310
Rose NULL
6 Renault Floride Bleue NULL
NumVoit Marque Type Couleur Teinte
1 Peugeot 404 Rouge Rouge
2 Citroen SM Noire Noire
3 Opel GT Blanche Blanche
4 Peugeot 403 Blanche Blanche
5 Renault
Alpine
A310
Rose Rose
6 Renault Floride Bleue Bleue
Recopie des
donnes de
Couleur dans
Teinte.
Ajout de la colonne
Teinte.
Affichage de la
table voiture
modifie.
Affichage de la
table voiture
modifie.
Suppression de la
colonne Couleur.

114 Cration de bases de donnes
SELECT * FROM voiture ;
3.2 CONTRAINTES DINTGRIT
Lors de ltape de conceptualisation, on a dfini la notion de domaine , qui dcrira
lensemble des valeurs que peut prendre un attribut. Au niveau de SQL, une premire
approche du domaine est tablie par le choix du type de la colonne, mais cela nest pas
assez restrictif en gnral.
SQL vous permet de dfinir des conditions de validit plus fines lors de la cration de la
table, que lon nomme contraintes dintgrit. Cest le SGBD qui applique ces conditions
au moment de linsertion, de la modification ou mme de la suppression de donnes dans
le cas ou ces dernires sont lies dautres tables. Cette tape est parfois fastidieuse, mais
elle garantit la cohrence des donnes et vite de se retrouver avec des bases de donnes,
conceptuellement correctes, mais inutilisables faute de donnes valides.
On peut distinguer diffrents types de contraintes sur les colonnes :
les proprits gnrales comme lunicit ;
les restrictions dappartenance un ensemble ;
les dpendances entre plusieurs colonnes.
Proprits gnrales
La valeur de la colonne doit tre renseigne absolument (NOT NULL).
La valeur doit tre unique compare toutes les valeurs de la colonne de la table (UNI-
QUE).
Lorsque les deux conditions prcdentes sont runies, la colonne peut servir identifier
un enregistrement et constitue donc une cl candidate . On rappelle quil ne peut y
avoir quune seule cl que lon dsignera en SQL par le mot cl PRIMARY KEY. Ici, on
indique que la colonne NumAch est choisie comme cl de la table (donc implicitement
unique et non nulle) et que la colonne Nom doit toujours tre renseigne.
CREATE TABLE personne (
NumAch INT PRIMARY KEY,
Nom CHAR(20) NOT NULL,
Age INT
) ;
Si aucune mention nest prcise comme pour la colonne Age, elle peut tre renseigne ou
non. Attention, une colonne non renseigne (cest--dire qui contient la valeur NULL
pour SQL) signifie quelle ne contient aucune donne, et non pas, par exemple, quelle
NumVoit Marque Type Teinte
1 Peugeot 404 Rouge
2 Citroen SM Noire
3 Opel GT Blanche
4 Peugeot 403 Blanche
5 Renault
Alpine
A310
Rose
6 Renault Floride Bleue
Affichage de la
table voiture
modifie.

115 SQL
Chapitre
contient 0 pour une colonne de type entier ou un espace pour une colonne de type
caractre .
Si la cl est constitue de plusieurs colonnes (elle est dite composite) ; on indique la liste
des colonnes constitutives de la cl la suite du mot cl PRIMARY KEY.
CREATE TABLE vente (
DateVente DATE,
PRIX INT,
NumAch INT,
NumVoit INT,
PRIMARY KEY (NumAch, NumVoit)
) ;
Condition dappartenance un ensemble
Il sagit de dcrire le domaine dans lequel la colonne pourra prendre ses valeurs. Un
ensemble peut tre dcrit :
En donnant la liste de tous ses lments constitutifs (IN). Lensemble des jours de la
semaine ne peut tre exprim que de cette manire : lundi , mardi , etc. On vrifie
que la colonne couleur ne peut prendre que des valeurs normalises : Rouge
Vert ou Bleu.
CREATE TABLE voiture(
NumVoit INT PRIMARY KEY,
Marque CHAR(30) NOT NULL,
Type CHAR(20),
Couleur CHAR(40),
CHECK Couleur in (Rouge,Vert,Bleu)
Par une expression (>, < , BETWEEN). Par exemple, le prix doit tre suprieur 1 000.
On vrifie que lge est compris entre 1 et 80.
CREATE TABLE personne
(NumAch INT PRIMARY KEY,
Nom CHAR(20) NOT NULL,
Ville CHAR(40),
AGE INT NOT NULL,
CHECK (Age BETWEEN 1 AND 80)
);
Par une rfrence aux valeurs dune colonne dune autre table (REFERENCES). Les
colonnes doivent tre de mme type et lon ne peut plus dtruire par dfaut une table
qui apparat comme rfrence. On vrifie que les valeurs identifiantes des personnes
NumAch et des voitures NumVoit de la table vente existent bien dans les tables de
rfrence personne et voiture.
CREATE TABLE vente (
DateAch DATE,
PRIX INT,
NumAch INT NOT NULL REFERENCES personne(NumAch),
NumVoit INT NOT NULL REFERENCES voiture(NumVoit),
PRIMARY KEY (NumAch, NumVoit)
) ;
Condition sur plusieurs colonnes (contrainte de table)
Lorsque lon dsire exprimer des contraintes plus labores impliquant plusieurs colon-
nes, on peut dfinir une contrainte de table en utilisant le mot cl CONSTRAINT. On
vrifie que la colonne Age et la colonne Ville doivent tre renseignes ou vides en mme
temps.

116 Cration de bases de donnes
CREATE TABLE personne
(NumAch INT PRIMARY KEY,
Nom CHAR(20) NOT NULL,
Ville CHAR(40),
AGE INT,
CONSTRAINT la_contrainte CHECK ( (Age IS NOT NULL AND Ville IS NOT NULL) OR (Age
IS NULL AND Ville IS NULL) )
;
3.3 VUES (CREATE VIEW)
Une vue est le rsultat dune requte que lon peut manipuler de la mme faon quune
table. On peut considrer une vue comme une table dynamique dont le contenu est recal-
cul chaque utilisation. On utilise les vues pour des raisons de commodit il nest pas
ncessaire que certains utilisateurs voient le modle complet qui est parfois complexe ou
encore de scurit/confidentialit en restreignant laccs certaines donnes. Dans cette
optique, les vues viennent en complment de la gestion des droits daccs, qui est traite
au chapitre 6.
CREATE VIEW personne_bis (NumAch, Nom, Age)
AS
SELECT NumAch, Nom, Age
FROM personne ;
Les vues permettent galement de mettre jour les tables, condition que les rgles dint-
grit de(s) table(s) utilises pour construire la vue soient respectes : en pratique, seules les
vues concernant une seule table peuvent effectuer des mises jour.
4 Gestion des donnes
Les commandes SQL qui sont prsentes dans cette section concernent non plus la gestion
de la structure des tables, mais celle des contenus. On dispose classiquement de trois
oprations : linsertion, la suppression et la mise jour, pour grer les donnes dune table.
Linsertion se fait enregistrement par enregistrement, mais cela peut se rvler fastidieux.
Cependant, linsertion de donnes est possible galement partir de la lecture dun fichier
externe dont le format est accept par le SGBD. Ces instructions dpendent donc du
SGBD utilis.
Les oprations de suppression et de modification des donnes se font partir de critres
de slection des enregistrements (lignes) modifier ou supprimer. Par exemple, on peut
dcider de supprimer toutes les personnes qui habitent Paris. Autre exemple : on actualise
le prix en euros de lensemble des ventes qui ont eu lieu aprs la date du passage leuro.
Ces critres sexpriment de la mme manire que pour les oprations de slection vues
prcdemment. Il est galement possible dutiliser le rsultat dune requte pour dtermi-
ner lensemble des valeurs dune colonne afin deffectuer cette slection.
4.1 INSERTION (INSERT INTO)
Linsertion denregistrements dans une table peut se raliser de plusieurs manires :
enregistrement par enregistrement (INSERT INTO) ;
en insrant la rponse une requte SQL (INSERT INTO).

117 SQL
Chapitre
La commande pour insrer des donnes est de la forme gnrale suivante :
INSERT INTO <nom de la table> [ liste des colonnes ] VALUES <liste des valeurs>
Insertion dun enregistrement dans la table voiture
INSERT INTO voiture
(NumVoit, Marque, Couleur)
VALUES (10,Triumph,Bleue) ;
SELECT * FROM voiture ;
Si certaines colonnes sont omises, elles prendront la valeur NULL.
Si la liste des colonnes est omise, on considre quil sagit de la liste de celles prises dans
lordre dfini lors de la cration de la table.
Insertion denregistrement(s) partir du rsultat dune requte
La table dans laquelle on insre les donnes doit avoir le mme nombre de colonnes que la
table rsultat de la requte (et le mme type).
INSERT INTO voiture
SELECT NumVoit, Marque, Type, Couleur
FROM voiturebis
WHERE NumVoit>10;
4.2 SUPPRESSION (DELETE FROM)
Lopration de suppression permet de supprimer un ensemble denregistrements (lignes)
que lon identifiera avec une expression identique aux conditions de slection vues prc-
demment.
DELETE FROM voiture
WHERE Couleur=Rouge ;
NumVoit Marque Type Couleur
1 Peugeot 404 Rouge
2 Citroen SM Noire
3 Opel GT Blanche
4 Peugeot 403 Blanche
5 Renault
Alpine
A310
Rose
6 Renault Floride Bleue
10 Triumph NULL Bleue
Remarque
Pour tre insres, les valeurs des colonnes doivent respecter les contraintes dintgrit associes
la table.
Affichage de la
table voiture
modifie.

118 Cration de bases de donnes
SELECT * FROM voiture ;
Attention, si lon ne spcifie aucune condition, tous les enregistrements sont supprims.
DELETE FROM personne ;
4.3 MODIFICATION (UPDATE)
Pour cette opration, il faut prciser :
la (les) colonne(s) concerne(s) ;
la (les) nouvelle(s) valeur(s) ;
les enregistrements pour lesquels on modifiera ces valeurs.
De mme que prcdemment, on identifiera les enregistrements concerns par une
expression de slection. La valeur modifie peut tre statique ou calcule partir des
valeurs dautres colonnes.
UPDATE personne
SET Ville=Paris-Centre
WHERE Ville=Paris ;
SELECT * FROM personne ;
NumVoit Marque Type Couleur
2 Citroen SM Noire
3 Opel GT Blanche
4 Peugeot 403 Blanche
5 Renault
Alpine
A310
Rose
6 Renault Floride Bleue
NumAch Nom Age Ville Sexe
1 Nestor 96 Paris-Centre M
2 Irma 20 Lille F
3 Henri 45 Paris-Centre M
4 Josette 34 Lyon F
5 Jacques 50 Bordeaux M
Affichage de la
table voiture
modifie.
Modification du
nom dune ville
dans la table
personne.
Affichage de la
table personne
modifie.

119 SQL
Chapitre
Rsum
Voici une synthse des commandes SQL prsentes dans ce chapitre. Le langage SQL
permet :
La gestion de tables et de vues munies des contraintes associes (LDD, Langage de Des-
cription des Donnes). Ces instructions concernent la table et sa structure.
cration CREATE TABLE/VIEW <nom de la table>
destruction DROP TABLE/VIEW <nom de la table>
modification ALTER TABLE/VIEW <nom de la table>
La manipulation de donnes (LMD, Langage de Manipulation des Donnes). Ces ins-
tructions concernent les donnes contenues dans les tables.
insertion INSERT INTO <nom de la table> (<liste de colonnes> <liste de valeurs>)
modification UPDATE <nom de la table> SET <colonne=valeur> WHERE <critre>
destruction DELETE FROM <nom de la table> WHERE <critre>
Linterrogation et la recherche dans les tables.
SELECT <liste de colonnes>
FROM <nom de la table>
WHERE <critre>
Figure 4.3
Synthse des
commandes SQL.
Le langage SQL se rvle beaucoup plus complet que la partie qui est prsente dans ce
chapitre. Le choix effectu parmi les commandes permet de rpondre aux questions les
plus courantes en base de donnes.
SELECT <liste de champs>
FROM <liste de tables>
WHERE <liste de critres>
ORDER BY <liste de champs>
GROUP BY <liste de champs> HAVING <liste de critres>
CREATE TABLE <Table>
( <liste de champs + Type> )
DROP TABLE <Table>
ALTER TABLE <Table>
( <liste de champs + Type> )
INSERT INTO <Table>
( <liste de champs> )( <liste de valeurs> )
DELETE FROM <Table>
WHERE <liste de critres>
UPDATE <Table> SET < champ=valeur >
WHERE <liste de critres>
AS, DISTINCT
+, , *, /, %
AVG, MAX, MIN
SUM, COUNT
=, <, >, LIKE
IS NULL, IN, BETWEEN
OR, AND, NOT
ASC, DESC
J OIN
(LEFT/RIGHT) J OIN
ON

120 Cration de bases de donnes
Exercices
EXERCICE 1 PROJECTION SIMPLE
Il sagit dune projection simple sur la colonne Ville de la table personne laide du mot
cl DISTINCT.
SELECT DISTINCT Ville
FROM personne
ORDER BY Ville DESC ;
EXERCICE 2 PROJECTION AVEC UNE COLONNE CALCULE
Solution
Il sagit dutiliser la fois une fonction statistique et une colonne calcule partir de la
colonne Prix de la table vente.
SELECT SUM(Prix*1.2) AS CA_TTC
FROM vente ;
EXERCICE 3 PROJECTION/RESTRICTION AVEC UN OPRATEUR STATISTIQUE
Toutes les informations ncessaires se trouvent dans la table personne.
Pour rsoudre cet exercice, on peut raisonner en deux temps :
Extraire de la table personne les enregistrements dont la colonne Ville contient
Paris (slection).
SELECT *
FROM Personne
WHERE Ville=Paris ;
Calculer laide dune fonction statistique la moyenne de la colonne Age pour ses
enregistrements (projection).
SELECT AVG(Age)
FROM Personne
WHERE Ville=Paris ;
Trouvez les diffrentes villes dans lesquelles habitent les personnes. Ordonnez le rsultat
par ordre dcroissant.
Affichez le chiffre daffaires, cest--dire la somme des prix de vente, toutes taxes (20 %)
en considrant que la table contient les prix hors taxes. Renommez la colonne Rsultat
en CA_TTC .
Trouvez lge moyen des personnes habitant Paris dans la base de donnes casse.

121 SQL
E
x
e
r
c
i
c
e
s
Chapitre
Pour complter cet exercice, il serait plus lgant de renommer la colonne ainsi calcule,
par exemple en Moyenne_Paris :
SELECT AVG(Age) AS Moyenne_Paris
FROM Personne
WHERE Ville=Paris ;
EXERCICE 4 AGRGAT
Toutes les informations ncessaires existent dans la table voiture.
De mme que pour lexercice prcdent, il est intressant de raisonner en deux temps :
Grouper les donnes par marques de voitures (agrgat).
SELECT Marque
FROM Voiture
GROUP BY Marque;
Calculer laide dune fonction statistique le nombre de lignes par marque.
SELECT Marque, COUNT(*) AS Nombre
FROM Voiture
GROUP BY Marque;
EXERCICE 5 QUESTION NGATIVE
Toutes les informations ncessaires sont prsentes dans la table personne.
Le problme est toujours dexprimer une condition ngative, ici la non-appartenance un
ensemble. Dans ce cas, cest assez simple puisque toutes les valeurs de la colonnes Ville
sont renseignes. Ce serait plus difficile si certains enregistrements possdaient une
colonne Ville vide (valeur NULL) : il faudrait logiquement les exclure du rsultat. Il est
prudent dinclure dans la rponse, en phase de vrification, la colonne sur laquelle on
exprime un critre (ici, la colonne Ville). Il est en effet assez facile de faire une erreur dans
lexpression dun critre.
SELECT Age, Ville
FROM personne
WHERE NOT (Ville=Paris) ;
EXERCICE 6 PRODUIT CARTSIEN
Trouvez le nombre de voitures par marques dans la base de donnes casse.
Trouvez lge des personnes qui nhabitent pas Paris.
crivez lexpression du produit cartsien de la table voiture et de la table personne.
Combien de lignes et de colonnes possde la table rsultat ? Est-ce une opration
symtrique (dans laquelle on retrouve le mme rsultat en inversant lordre des tables).

122 Cration de bases de donnes
Il ny a aucun critre de projection, ni de slection ; toutes les colonnes et les lignes des
deux tables participent donc au produit cartsien. On obtient 30 lignes (6 5) et 9 colon-
nes (5 + 4).
SELECT *
FROM personne, voiture;
Lopration est videmment symtrique. En revanche, si les donnes sont les mmes, elles
ne se trouveront pas dans le mme ordre.
EXERCICE 7 JOINTURE SIMPLE
Linformation se trouve dans les tables voiture et personne. Mais pour relier
smantiquement ces deux tables, on a besoin de la table vente. Il faut donc faire une
qui-jointure entre ces trois tables.
SELECT vo.Marque, pe.Nom
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit)
AND (pe.NumAch=ve. NumAch);
On aurait pu galement crire :
SELECT vo.Marque, pe.Nom
FROM voiture AS vo, vente AS ve, personne AS pe
WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
Le rsultat est-il identique ? Pourquoi ?
EXERCICE 8 REQUTE SQL TRANGE
Cest pratiquement la mme requte que pour lexercice prcdent, mais le lien entre les
tables a t ralis sur des colonnes diffrentes. La syntaxe est correcte et le type des colon-
nes sur lesquelles a t faite la jointure est compatible ; SQL retournera donc une table
rsultat . Le fait que ce rsultat na aucun sens du point de vue du monde rel ne peut
tre dduit du schma des relations. Pour ce faire, il faut consulter le modle conceptuel
qui lui a servi de base.
EXERCICE 9 AUTRE QUESTION NGATIVE JOINTURE EXTERNE
Cest une question ngative , comme celle de lexercice 4.5, mais qui met en jeu deux
tables. Il sagit de trouver, en comparant les valeurs de la colonne NumVoit comprises
Donnez les noms des personnes et la marque des voitures quelles ont achetes.
Que donnerait cette requte ?
SELECT vo.Marque, pe.Nom
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve. NumAch)
AND (pe.NumAch=ve. NumVoit);
Obtient-elle une rponse ou provoque-t-elle un message derreur ?
Quelles sont les villes o habitent les personnes qui nont pas achet de voiture ?

123 SQL
E
x
e
r
c
i
c
e
s
Chapitre
dans les tables vente et voiture , celles qui sont dans voiture et pas dans vente .
cet effet, on utilise une opration, qui nest pas proprement parler une opration de
lalgbre relationnelle, qui sappelle la jointure externe qui permet dafficher les enregistre-
ments qui nont pas de correspondance dans lautre table.
L encore, le raisonnement peut se dcomposer en deux tapes :
Construction de la jointure externe des deux tables : lajout des colonnes NumAch des
deux tables dans la rponse sert simplement vrifier notre requte.
SELECT personne.Ville, personne.NumAch, vente.NumAch
FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch
;
Slection dans cette table rsultat des lments nayant pas de correspondance dans
vente et qui ont donc une valeur NULL pour la colonne NumAch.
SELECT personne.Ville
FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch
WHERE vente.NumAch IS NULL;
noter que la question demandait dtablir la liste des villes. Si le contenu de la base de
donnes tait plus important, la mme ville pourrait apparatre plusieurs fois dans la
rponse. Pour viter ce cas de figure, on prcise que lon veut la liste des diffrentes occur-
rences de ville par le mot cl DISTINCT.
SELECT DISTINCT personne.Ville
FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch
WHERE vente.NumAch IS NULL;
EXERCICE 10 SLECTION SUR UN AGRGAT DUNE JOINTURE
Les informations permettant de rpondre cette question se trouvent dans deux tables
vente et voiture. Il nous faut donc effectuer une jointure sur la colonne NumVoit pour
lier ces deux tables.
SELECT vo.Marque, ve.Prix
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
;
Ensuite, on utilise lopration dagrgation pour effectuer un regroupement par Marque
et calculer pour chaque sous-ensemble la moyenne des prix de vente.
SELECT vo.Marque, AVG(ve.Prix)
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
GROUP BY vo.Marque
;
Enfin, on limine du rsultat du calcul prcdent les marques dont la moyenne des prix est
infrieure 40 000 en ne gardant que les lignes dont la moyenne est suprieure ou gale
40 000.
SELECT vo.Marque, AVG(ve.Prix) AS Moyenne
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
GROUP BY vo.Marque
HAVING Moyenne >= 40000
;
Calculez la moyenne des prix de vente par marques en ne considrant que les marques
dont cette moyenne est suprieure 40 000.

124 Cration de bases de donnes
On peut utiliser lalias du nom de la colonne calcule (ici Moyenne ) pour effectuer la
slection. Attention, on ne peut pas utiliser le mot cl WHERE ici, car il sagit dune
slection sur le rsultat du calcul et non pas a priori avant le calcul. On utiliserait
WHERE pour rpondre une question du type : Calculez la moyenne des prix de
vente par marques en ne considrant pour ce calcul que les prix suprieurs 40 000.
SELECT vo.Marque, AVG(ve.Prix) AS Moyenne
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
WHERE ve.Prix >= 40000
GROUP BY vo.Marque;
Avec le jeu de donnes restreint dont on dispose, on remarque que le rsultat est identique,
mais cest videmment un hasard.
EXERCICE 11 SLECTION PAR RAPPORT AU RSULTAT DUN CALCUL STATISTIQUE
Ici, on doit comparer les valeurs de la table vente par rapport une opration qui a t
ralise sur toutes les valeurs de la table. Cest une question simple en apparence, mais
parfois difficile traiter car tous les SGBD nacceptent pas les requtes imbriques.
Comme toujours, on peut dcomposer le raisonnement en plusieurs tapes :
Calculer la moyenne des prix.
SELECT AVG(vente.Prix) AS Moyenne_Prix
FROM vente
;
Comparer les prix.
SELECT ve1.Prix
FROM vente AS ve1
WHERE ve1.Prix > (SELECT AVG(ve2.Prix) FROM vente AS ve2);
EXERCICE 12 CRATION DUNE TABLE
CREATE TABLE personne
(NumAch INT PRIMARY KEY,
Nom CHAR(30) NOT NULL,
Age INT,
Ville CHAR(40),
Sexe CHAR(1),
CHECK (Age BETWEEN 16 AND 100),
CHECK Sexe IN (H,F)
);
Affichez les prix qui sont suprieurs la moyenne.
Crez la table personne avec les colonnes suivantes :
NumAch. De type entier, cl de la relation.
Nom. De type caractre, de taille 30, ne doit pas tre vide.
Age. De type entier, compris entre 16 et 100.
Ville. De type caractre, de taille 40.
Sexe. De type caractre, de taille 1, doit contenir H ou F .

125 SQL
E
x
e
r
c
i
c
e
s
Chapitre
EXERCICE 13 INSERTION DE DONNES DANS UNE TABLE
On ninsre par toutes les valeurs des colonnes ; donc, il faut prciser la liste des colonnes
pour lesquelles une valeur est prsente dans lordre que lon choisit.
INSERT INTO personne
(NumAch, Ville, Nom)
VALUES (100,Paris,Essai) ;
Lenregistrement est valide ; aucune colonne ne contredit les contraintes dfinies
prcdemment : la cl NumAch est unique, le nom est renseign, les colonnes Age et
Sexe ne sont pas renseignes, mais ne sont pas obligatoires.
EXERCICE 14 MODIFICATION DES DONNES DUNE TABLE
Les informations modifier se trouvent simplement dans la table vente bien que la ques-
tion voque les voitures . Il ny a pas de critre dans ce cas puisque lon modifie toute la
table.
UPDATE vente
SET Prix=Prix*1.1 ;
EXERCICE 15 REQUTE COMBINE
La question parat simple, mais elle doit tre bien analyse. On doit considrer deux cat-
gories de personnes : celles qui ont achet des voitures mais pas de voitures rouges ; celles
qui nont achet aucune voiture. Pour obtenir la liste des personnes qui nont achet
aucune voiture, on utilise une requte de type jointure externe. Les informations se trou-
vent dans les deux tables personne et vente .
SELECT personne.Nom
FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch
WHERE vente.NumAch IS NULL;
Pour obtenir la liste des personnes qui ont achet une voiture, mais pas rouge, on utilise
une requte de type slection sur une quijointure. Les informations se trouvent dans les
deux tables personne et voiture, que lon doit relier par la table vente.
SELECT pe.Nom
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit)
AND (pe.NumAch=ve. NumAch)
WHERE vo.Couleur != Rouge;
Insrez les valeurs suivantes dans la table prcdemment cre.
NumAch : 100
Nom: Essai
Ville : Paris
Lenregistrement est-il valid ? (Satisfait-il aux contraintes dintgrit ?)
Modifiez le prix de vente (+10 %) des voitures.
Quelles sont les personnes qui nont pas achet de voitures rouges ?


Du langage
parl SQL
127
Chapitre
1. Prsentation de lactivit
modliser ............................ 128
2. laboration du modle
entit-association .................... 129
3. Passage au modle relationnel .. 134
4. Interrogation de la base
de donnes ............................ 141
Exercices
1. Reprsentation UML ................ 148
2. Calculs par expression SQL ..... 148
3. Code SQL et signification ........ 149
4. Agrgats et slection ............... 150
5. Requtes combines ............... 151
6. Simple slection ou
jointure externe ? .................... 152
7. Mise jour de la base ............ 153
8. volution de la base
de donnes ............................ 154
9. Autre exemple complet ............ 154
Ce chapitre prsente un exemple complet de
ralisation dune base de donnes, tape par tape.
On part de lnonc dans la vie relle jusqu
linterrogation de la base laide du langage SQL.
Cet exemple permet de rcapituler les concepts
prsents dans les chapitres prcdents, savoir :
lanalyse du monde rel et la cration du modle
entit-association ;
le passage au modle relationnel ;
la cration des tables en SQL par lintgration des
contraintes de contenu ;
linterrogation de la base de donnes par des
requtes SQL.
On aborde galement ici les diffrents aspects
dordre pratique qui se posent chaque tape de la
ralisation dune base de donnes.

128 Cration de bases de donnes
1 Prsentation de lactivit modliser
On veut modliser la gestion dune entreprise de fabrication et de livraison de pizzas
domicile : la socit RaPizz. Il sagit dune socit en franchise qui utilise des formats et des
compositions de pizzas normaliss partir dun ensemble dingrdients dtermins. En
dautres termes, le client na pas la libert de composer lui-mme une pizza personnalise ;
il doit choisir dans le catalogue propos.
Produits
Les produits vendus sont des pizzas. Une pizza est caractrise par son nom, les ingr-
dients qui la composent et son prix de base. Pour chaque pizza, il existe trois tailles :
naine , humaine et ogresse . La naine est 1/3 moins chre que le prix de base,
cest--dire la taille humaine , et l ogresse est 1/3 plus chre.
Mode de distribution
Les pizzas sont livres par des livreurs qui circulent en voiture ou moto et qui nont pas
de vhicules attitrs. La base de donnes doit galement permettre le suivi de lactivit des
livreurs et des vhicules quils utilisent.
Modalits de vente
Le mode de vente est du type prpay : pralablement toute commande, les clients doi-
vent sabonner au service et approvisionner leur compte. On vrifie le solde du compte
avant de prparer et de livrer la commande.
Il existe deux systmes de bonification :
Une pizza gratuite est offerte au bout de 10 pizzas achetes.
Toute pizza livre en plus de trente minutes est gratuite.
Objectifs du systme
Le but de cette base de donnes est de grer lactivit quotidienne de vente et de livraison
de pizzas :
vrification du solde du compte et facturation aux clients ;
suivi du chiffre daffaires ;
refus dhonorer les commandes pour lesquelles le solde du compte client est
insuffisant ;
non-facturation des pizzas gratuites (retard ou fidlit).
On veut galement effectuer des statistiques diverses sur lactivit :
identification du meilleur client ;
identification du plus mauvais livreur (nombre de retards dans la livraison) et du
vhicule utilis ;
identification de la pizza la plus ou la moins demande ;
identification de lingrdient favori

129 Du langage parl SQL
Chapitre
2 laboration du modle entit-association
Lors de cette tape, on dtermine les lments qui permettront de constituer les futures
tables de la base de donnes. Pour laborer ce modle, on procde en deux temps :
construction du graphe des entits relies par les associations ;
qualification des associations par leurs cardinalits.
Ce schma est trs important, car il reprsente en somme la documentation de la future
base de donnes. Lensemble de tables obtenues la suite de lopration de passage au
schma relationnel est gnralement peu lisible et donne peu dindications sur les liens
entre les diffrents lments. En effet, il est quasi impossible de dterminer quelles tables
peuvent tre jointes, du point de vue du sens des donnes dans la ralit, sans disposer du
schma entit-association associ.
2.1 IDENTIFICATION DES ENTITS ET DES ASSOCIATIONS
La premire tape consiste reprer les diffrentes entits que lon doit considrer. Pour ce
faire, il nous faut trouver les phrases simples qui identifient lactivit par rapport
lnonc. Paralllement, on peut chercher quels objets concrets du monde rel semblent
impliqus dans le systme. Puis, pour chaque entit, on doit dterminer une cl parmi les
attributs. Enfin, on caractrise les liens entre les entits par des associations.
Entits et attributs
On rappelle quil ne sagit pas vraiment dun processus scientifique bas sur des rgles pr-
cises. Une certaine part dintuition est ncessaire, dautant plus quil nexiste pas une solu-
tion unique dans la majorit des cas.
On peut remarquer quelques mots cls dans la description gnrale : pizza, ingrdient,
client, livreur, vhicule. Ces descripteurs reprsentent des objets familiers du monde
rel. En revanche, les mot cls taille, prix, compte, retard, nom et autres sont claire-
ment plus des qualifiants que des objets. Ce qui relie tous ces objets pour constituer la
reprsentation de lactivit est la notion de commande. Cette dernire est lun des seuls
objets abstraits, compare aux autres objets concrets du monde rel, comme peut ltre un
vhicule par exemple.
partir de ces constatations, voici une proposition de quelques phrases extraites ou
dduites de la description gnrale qui permettent deffectuer une premire synthse de
lactivit :
Une pizza est constitue de plusieurs ingrdients.
Un client passe une commande.
Une commande est livre par un et un seul livreur.
Une commande est livre par un et un seul vhicule.
Remarque
Afin de simplifier le problme, on considre que lopration de base modliser dans cette acti-
vit est la vente dune unique pizza. La notion de commande qui peut contenir plusieurs pizzas
nest pas prise en compte. On pourra faire voluer le systme plus tard si besoin est pour intgrer
cet aspect. Il est en effet plus simple de raisonner en termes de ventes unitaires, que lon peut
agrger ensuite, plutt que dattaquer directement sur des commandes multiples.

130 Cration de bases de donnes
On en dduit lexistence des entits suivantes :
commande ;
client ;
pizza ;
livreur ;
vhicule ;
ingrdient.
On peut se poser la question de savoir si un ingrdient est une entit part entire ou un
simple attribut dune pizza. Lentreprise considre est une franchise ou tout est trs nor-
malis, et lon peut imaginer que la liste des ingrdients lest aussi. Un mme ingrdient
entre certainement dans la composition de plusieurs pizzas. Il est donc prfrable de spa-
rer les ingrdients des pizzas ; lassociation entre les deux entits est reprsente par la
phrase : Une pizza est constitue dingrdients. Notons propos des ingrdients que le
systme ne doit grer que les aspects commande et livraison ; lon ne sintresse pas ici la
gestion des stocks dingrdients.
Il manque dans la description un nombre important de donnes qui vont constituer cer-
taines entits, en particulier les entits vhicule ou client. Le cas est frquent lors de la
ralisation du processus ; il est alors ncessaire de poser de nouvelles questions pour com-
bler ces lacunes. On imagine qu la suite dun dialogue avec les diffrents acteurs de
lentreprise, on obtient les renseignements suivants :
Un client est caractris par son nom et son adresse.
Un livreur est caractris par son nom et son numro de tlphone.
Un vhicule est caractris par sa marque, son type et son numro dimmatriculation.
Ces informations complmentaires permettent de dterminer quelques attributs des enti-
ts ainsi constitues. Les autres attributs des entits se trouvent dans lnonc : par exem-
ple une pizza est caractrise par son nom et par son prix ou un ingrdient est
caractris par son nom. Laffectation dun attribut une entit nest pas toujours vi-
dente. On va crer un attribut compte qui contiendra les informations de solvabilit du
client puisque lon fonctionne en mode prpay. Il faut se poser la question : est-ce une
proprit caractristique du client ? La rponse dans notre cas est aise et lattribut sera
affect lentit client.
Mais comment prendre en compte la taille de la pizza ? Sagit-t-il dune proprit caract-
ristique de lentit pizza ou la taille est-elle associe la commande ou mme au
client ? Pour rpondre cette question, on doit considrer le moment ainsi que lendroit
o intervient la notion de taille et dterminer son utilit. La taille sert uniquement pon-
drer le prix de base de la pizza : elle nest donc pas associe la pizza, dont le prix est fixe ;
elle ne constitue pas non plus on sen doutait un peu une caractristique dun client.
On pourrait, la limite, la considrer comme telle si lon disposait dune information du
type : les grandes tailles sont uniquement commandes par des hommes, les tailles nor-
males par des femmes et les petites tailles par des enfants de sexe indiffrenci . Comme
ce nest pas le cas, on associe logiquement la taille lentit commande.
Ce type de rflexion doit tre engag galement pour modliser les possibilits de bonifi-
cation qui peuvent tre obtenues soit en raison dun retard de livraison soit par une capi-
talisation sous forme de points de fidlit. Par un raisonnement semblable, on dtermine
que le retard est associ la commande alors que la fidlisation est associe au client. Si
lon rcapitule, on obtient les entits munies de leurs attributs suivants :
commande (DateCom, Taille, Retard) ;

131 Du langage parl SQL
Chapitre
client (NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (NomLivreur, Tlphone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NomIngrdient).
Choix de la cl
Les attributs tant identifis, on doit maintenant choisir une cl pour chaque entit. Si lon
prend lentit client, il est clair quaucun attribut ne peut convenir pour constituer une
cl. De mme, lassociation de plusieurs attributs NomClient-Adresse, NomClient-
Compte, Compte-PointsRaPizz et autres ne permet pas de crer une cl. On ajoute alors
classiquement un attribut identifiant qui sert de cl : ce peut tre un simple nombre ou un
mlange de lettres et de nombres (alphanumriques) plus commode mmoriser.
En utilisant ces mmes arguments, on est amen ajouter des attributs numriques
comme cls pour les entits livreur et commande.
Pour lentit pizza, on peut supposer que le nom de la pizza est significatif et quil peut
donc servir de cl. En effet, le catalogue de pizzas propos est restreint et codifi par le fait
quil sagisse dune entreprise de type franchis . Il ny a pas dintrt pour le franchi-
seur, dun simple point de vue commercial, donner deux fois le mme nom une pizza.
En pratique, mme si le nom est unique, on pourrait dcider de ne pas lutiliser car le con-
tenu est un peu long. Lentit vhicule dispose dun champ identifiant : son numro
dimmatriculation qui est par dfinition unique. Enfin, en ce qui concerne les ingrdients,
il peut tre moins vident que le nom seul de lingrdient suffise lidentifier. Il est prf-
rable de lui ajouter un numro.
On obtient les entits suivantes munies de leurs attributs :
commande (NumCommande, DateCom, Taille, Retard) ;
client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (CodeLivreur, NomLivreur, Tlphone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NumIngre, NomIngrdient).
Associations et attributs
On peut, partir des phrases qui ont permis de reprer les entits, en dduire les associa-
tions suivantes :
Livre entre Livreur et Commande ;
Transporte entre Vhicule et Commande ;
Passe entre Client et Commande ;
Constitue entre Pizza et Commande ;
Compose entre Pizza et Ingrdient.
Il reste dterminer les attributs ventuels des associations. Dans notre cas, le choix duti-
liser une entit commande fait que lon regroupe naturellement dans cette entit les attri-
buts qui auraient pu se retrouver sur les associations.
ventuellement, une date de commande pourrait tre un attribut de lassociation Passe si
elle tait diffrente de la date de la commande. On peut cependant imaginer que ce genre

132 Cration de bases de donnes
dentreprise ne prend pas les commandes lavance : on commande une pizza lorsque lon
a faim. On se trouve donc dans le cas un peu particulier o aucune des associations ne
possde dattribut (voir figure 5.1).
Figure 5.1
Modle entit-
association
Livraisons de
pizzas sans
cardinalits.
2.2 DTERMINATION DES CARDINALITS
On se pose ensuite des questions sur la nature des liens entre les entits capables de dter-
miner les cardinalits qui seront utilises pour le passage au modle relationnel. On doit
trouver deux cardinalits, maximales et minimales, par entit associe, ce qui correspond
deux questions doubles par association. Il sagit dune tape dinventaire un peu fasti-
dieuse, mais elle est indispensable et permet de poser un autre regard sur le modle.
Association Compose
Ingrdient : un ingrdient peut-il ne jamais tre utilis dans la composition dune pizza et
peut-il tre utilis plusieurs fois ? On suppose que si un ingrdient est au catalogue, cest
quil est utilis au moins une fois (1) et quil peut entrer dans la composition de plusieurs
(n) pizzas. Les cardinalits associes sont de type 1-n.
Pizza : une pizza peut-elle navoir aucun ingrdient et peut-elle en avoir plusieurs ? On
suppose quune pizza est constitue dau moins un (1) ingrdient et quelle peut en avoir
plusieurs (n). Les cardinalits associes sont de type 1-n.
Association Passe
Client : un client peut-il navoir jamais pass de commandes et peut-il en avoir pass
plusieurs ? Il peut y avoir une priode pendant laquelle le client a approvisionn son
compte mais na pas encore pass (0) de commande et il est videmment encourag en
passer plusieurs (n). Les cardinalits associes sont de type 0-n.
Commande : une commande peut-elle avoir t passe par aucun client ou par plusieurs ?
Une commande donne est passe par un (1) et un (1) seul client. Les cardinalits asso-
cies sont de type 1-1.
Commande
Livreur
Pizza
Vhicule
Ingrdient
Client
# NumCommande
DateCom
Taille
Retard
# NumClient
NomClient
Adresse
Compte
PointsRapizz
# NomPizza
Prix
# CodeLivreur
NomLivreur
Tlphone
# NumIngre
NomIngre
# NumImmat
Marque
Type
Livre
Transporte
Passe
Constitue
Compose

133 Du langage parl SQL
Chapitre
Association Livre
Livreur : un livreur peut-il navoir jamais livr de pizzas et peut-il en avoir livr plusieurs ?
Un livreur a au moins effectu une (1) livraison, sinon il nest pas considr comme tel.
On peut imaginer que lon ne rentre les informations associes un livreur qu partir du
moment o il a rellement effectu une livraison. Il est suppos faire plusieurs (n) livrai-
sons. Les cardinalits associes sont de type 1-n.
Commande : une commande peut-elle avoir t livre par plusieurs livreurs ou par
aucun ? Une commande est livre par un (1) et un (1) seul livreur. Les cardinalits asso-
cies sont de type 1-1.
Association Transporte
Vhicule : un vhicule peut-il navoir jamais livr de pizzas et peut-il en avoir livr plusieurs ?
Dans ce cas, la situation nest pas tout fait la mme que pour les livreurs. On peut imaginer
que les informations concernant un vhicule pourraient tre insres dans la base de don-
nes sans que le vhicule nait encore effectu une livraison (0). Si ctait le cas, on aurait des
cardinalits de type 0-n. On choisit ici des cardinalits associes de type 1-n. Dans les deux
cas, un vhicule est suppos tre utilis pour livrer plusieurs (n) commandes.
Commande : une commande peut-elle avoir t livre par plusieurs vhicules ou par
aucun ? Une commande est livre par un (1) et un (1) seul vhicule. Les cardinalits asso-
cies sont de type 1-1. On obtient le modle entit-association suivant (voir figure 5.2) :
Figure 5.2
Modle entit-
association
Livraisons de
pizzas avec
cardinalits.
Cependant, si cela est possible, on prfre cependant viter les associations autres que binai-
res, plus complexes transformer en relations. De plus, le modle UML ne propose pas de
solution trs cohrente pour reprsenter les associations ternaires ou de plus haut degr.
Remarque
Toutes les associations qui lient lentit commande sont de cardinalit 1-1. On aurait pu
ainsi considrer lentit commande comme une association qui serait alors quaternaire.
Commande
Livreur
Pizza
Vhicule
Ingrdient
Client
# NumCommande
DateCom
Taille
Retard
# NumClient
NomClient
Adresse
Compte
PointsRapizz
# NomPizza
Prix
# CodeLivreur
NomLivreur
Tlphone
# NumIngre
NomIngre
# NumImmat
Marque
Type
Livre
Transporte
Passe
Constitue
Compose
1,n
1,n
0,n 1,1
1,1
1,1
1,1
1,n
1,n
0,n

134 Cration de bases de donnes
3 Passage au modle relationnel
Cette section reprsente le travail prliminaire effectu en vue du passage lutilisation
dun SGBD. Elle comprend plusieurs parties :
la transformation du modle entit-association en modle relationnel laide des
rgles nonces prcdemment ;
la vrification de la conformit des relations cres par rapport la dfinition des for-
mes normales du modle relationnel ;
la discussion sur le type des donnes adopter pour chaque champ ainsi que sur les
contraintes dintgrits dfinir ;
la cration des tables en SQL.
3.1 TRANSFORMATION DU MODLE ENTIT-ASSOCIATION
Les deux rgles gnrales de passage du modle entit-association vers le modle relation-
nel sont les suivantes :
Une entit donne une relation de mme cl que lentit qui contient les mmes attri-
buts que lentit.
Une association donne une relation dont la cl est compose des deux cls des entits
associes et des attributs de lassociation.
Application de la rgle gnrale
On obtient les relations suivantes partir des entits :
commande (NumCommande, DateCom, Taille, Retard) ;
client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (CodeLivreur, NomLivreur, Telephone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NumIngre, NomIngredient).
En appliquant la rgle gnrale, on obtient les relations suivantes partir des associations :
livre (CodeLivreur, NumCommande) ;
transporte (NumImmat, NumCommande) ;
passe (NumClient, NumCommande) ;
constitue (NomPizza, NumCommande) ;
compose (NumIngre, NomPizza).
Cas particuliers des associations de cardinalit 1-1
Un cas particulier existe lorsque lune des cardinalits dune association est de type 1-1.
La relation reprsentant lassociation disparat et fusionne avec la relation reprsentant
lentit associe avec la cardinalit 1-1. On peut dire quil y a aspiration de lassocia-
tion par lentit.
Dans cet exemple, de nombreuses associations sont de type 1-1 par rapport lentit
commande , comme lassociation livre . Lapplication de cette rgle produit une sim-

135 Du langage parl SQL
Chapitre
plification du nombre de relations au dtriment de la lisibilit gnrale. On perd ainsi une
partie de linformation sur le lien entre ces entits.
Ce processus peut tre expliqu de la manire suivante. La cl de lassociation livre est
compose des attributs CodeLivreur & NumCommande. Du fait de la cardinalit 1-1,
on peut en dduire qu un numro de commande correspond un et un seul code du
livreur. La cl peut alors tre simplifie et rduite lattribut NumCommande. On
obtient la relation :
livre (NumCommande, CodeLivreur)
Les deux relations commande et livre possdent alors la mme cl ; on peut les fusion-
ner. On obtient la relation commande augmente suivante :
commande (NumCommande, DateCom, Taille, Retard, CodeLivreur).
Les associations transporte , passe et constitue sont de cardinalit 1-1 par
rapport lentit commande . On peut aussi fusionner ces relations avec la relation
commande . On obtient :
commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat,
NumClient, NomPizza).
Voici la liste des relations ainsi constitues :
client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (CodeLivreur, NomLivreur, Telephone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NumIngre, NomIngredient) ;
commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat,
NumClient, NomPizza) ;
compose (NumIngre, NomPizza).
3.2 VRIFICATION DE LA CONFORMIT AUX FORMES NORMALES
On doit vrifier que lensemble de relations cres ltape prcdente est bien en confor-
mit avec les formes normales. On peut se limiter en gnral aux trois premires formes
normales. En effet, celle de Boyce-Codd provoque frquemment un certain niveau de
perte dinformations (voir chapitre 3 pour plus de prcisions).
Premire forme normale
A priori, aucune des relations ne dispose de champs plusieurs valeurs (multivalus) :
chaque champ possde une valeur atomique . Cependant, on pourrait sinterroger par
exemple sur le contenu du champ NomClient dans la relation client ainsi que sur le
champ NomLivreur de la relation livreur. Sils contiennent le nom et le prnom de la
personne, il est prfrable de les sparer systmatiquement en deux champs : NomClient
et PrenomClient, NomLivreur et PrenomLivreur. De mme, il faut considrer le con-
tenu du champ Adresse de la relation client : pour des raisons de simplification et de lisi-
bilit de lexemple, on na pas dcoup ladresse en ses diffrents composants classiques :
numro, type de voie, nom de la voie, ville, code postal et pays.
Toutes les relations sont en premire forme normale si lon tient compte des remarques
sur le contenu de champs du prcdent paragraphe.

136 Cration de bases de donnes
Deuxime forme normale
La recherche de non-conformit la deuxime forme normale na de sens que si la cl est
compose de multiples champs. Dans notre cas, la seule relation qui possde une cl
composite est la relation compose. De plus, cette relation ne contient aucun attribut
qui ne fasse pas partie de la cl. La relation est en deuxime forme normale. Toutes les rela-
tions sont en deuxime forme normale.
Troisime forme normale
En revanche, la troisime forme normale concerne les liens qui peuvent exister entre des
champs qui ne font pas partie de la cl dune relation. Si lon considre la relation client,
les champs ne faisant pas partie de la cl sont les suivants : NomClient, Adresse,
Compte, PointsRaPizz. Il est clair que le solde du compte ne permet de dterminer ni le
nom du client, ni son adresse, ni son nombre de points de fidlit. Ce dernier et le nom
dune personne ne permettent pas non plus didentifier le contenu des autres champs. La
question pourrait ventuellement se poser pour le champ Adresse, susceptible dans cer-
tains cas dtablir le nom du client si lon suppose que deux clients nhabitent pas la
mme adresse.
Par le mme type de raisonnement sur la relation vehicule, on peut tre amen identi-
fier une relation de dpendance entre le type qui est unique pour un vhicule. Si lon sup-
pose que les constructeurs dposent le nom du type de leur vhicule, il permet de
dterminer sans ambigut le nom de la marque. Ce dernier pouvant tre identique pour
deux vhicules on vite ainsi la redondance provoque par sa rptition. En toute rigueur,
on serait conduit dans ce cas dcomposer la relation vhicule en deux relations :
vhicule (NumImmat, Type) ;
constructeur (Type, Marque).
On remarque immdiatement la complexit introduite par cette dcomposition en regard
du gain apport pour viter une redondance modeste, surtout si le nombre de vhicules
est relativement faible. Aprs analyse, on ne trouve de relations de dpendance entre
aucun des champs de la relation commande qui ne font pas partie de la cl, cest--dire
les champs DateCom, Taille, Retard, CodeLivreur, NumImmat, NumClient et Nom-
Pizza. Sil y avait de trs mauvais livreurs qui livrent systmatiquement en retard et
dautres qui ne livrent jamais en retard, il pourrait exister une relation de dpendance
entre les champs CodeLivreur et Retard, mais cela est peu probable dans la ralit.
On pourrait trouver une relation de dpendance entre les champs de cette relation en for-
ant un peu le raisonnement pour la relation Livreur. En effet, si lon suppose que le tl-
phone est un numro de portable personnel et quil est associ un livreur donn, alors le
numro de tlphone permet de dterminer le nom du livreur et son code client. Le
champ devient une cl candidate. On pourrait peut-tre supprimer la cl constitue par le
code client pour viter la redondance entre ce code que lon a fabriqu et le numro de
tlphone. Il ne sagit plus dans ce cas que dun problme de conformit la troisime
forme normale puisque le champ cl est concern. Dans la pratique, un critre pour la
slection entre plusieurs cls est de choisir le champ dont le contenu est le plus stable dans
le temps. Un numro de tlphone peut changer ; on lui prfrera donc le numro de
code.
Toutes les relations ne sont pas strictement en troisime forme normale, mais on consi-
dre les redondances rsiduelles comme acceptables.

137 Du langage parl SQL
Chapitre
3.3 TYPES DE DONNES ET CONTRAINTES
Cette section permet de dterminer quels contrles doivent tre appliqus sur le contenu
des champs afin den garantir la cohrence. Les contraintes sont mises en uvre par le
SGBD employ et sont exprimes dans les instructions de cration des tables. Ces con-
traintes expriment lappartenance un ensemble. Un ensemble en SQL peut tre dcrit de
quatre manires :
le typage gnral dun point de vue des types prdfinis de SQL (par exemple, entier,
rel, caractre, date) ;
une numration des diffrentes valeurs possibles (par exemple, do , r , mi ,
fa , sol ) ;
lexpression dun intervalle dans lequel les valeurs sont contenues (par exemple, com-
pris entre 10 et 30) ;
la rfrence aux valeurs dun champ dune autre table (par exemple, contenu du
champ code_postal de la table communes).
Seule la description du type est obligatoire pour crer un champ, les autres contraintes
tant videmment optionnelles. Les champs dont les valeurs doivent tre absolument ren-
seignes sont indiqus spcifiquement en langage SQL par le mot cl NOT NULL .
Type(s) des donnes
La dfinition du type des donnes a pour but de faire une premire restriction sur les
valeurs que peut prendre un champ et surtout de spcifier les oprations et fonctions quil
sera possible de lui appliquer. Lutilisation du type date pour le champ DateCom permet-
tra dutiliser des fonctions dextractions du mois, du jour de la semaine ainsi que dautres
oprations spcifiques aux donnes de type date pour ce champ. Le champ Telephone de
la table livreur ne contiendra que des valeurs de type numrique, mais on neffectuera
jamais doprations de calculs sur ce champ : une moyenne des numros de tlphone na
gure de sens. En revanche, lextraction dun prfixe, comme par exemple les deux pre-
miers chiffres dun numro peut tre utile. On emploie alors un champ de type chane de
caractres sur lequel il est possible demployer des fonctions dextraction de chane.
Les champs de type numrique sont presque tous de type entier, sauf le champ Compte
de la table client et le champ Prix de la table Pizza qui sont de type rel. La taille des
champs de type chane de caractres est un compromis trouver entre loccupation de
place inutile et la taille maximale suppose des valeurs que peuvent contenir ce champ.
Table client
NumClient : code simple de type entier
NomClient : chane de caractres ( renseigner obligatoirement)
Adresse : chane de caractres
Compte : solde de type rel
Remarque
En pratique, on neffectue pas toujours cette tape de manire stricte compte tenu de la com-
plexit que produit la dcomposition par le processus de normalisation. Il est parfois prfrable
de conserver un peu de redondance pour limiter le nombre de tables et prserver ainsi lefficacit
du systme.

138 Cration de bases de donnes
PointsRaPizz : nombre de points de type entier
Table pizza
NomPizza : chane de caractres
Prix : solde de type rel ( renseigner obligatoirement)
Table livreur
CodeLivreur : code simple de type entier
NomLivreur : chane de caractres ( renseigner obligatoirement)
Telephone : chane de caractres ( renseigner obligatoirement)
Table vehicule
NumImmat : chane de caractres
Marque : chane de caractres ( renseigner obligatoirement)
Type : chane de caractres ( renseigner obligatoirement)
Table ingredient
NumIngre : code simple de type entier
NomIngrdient : chane de caractres ( renseigner obligatoirement)
Table commande
NumCommande : code simple de type entier
DateCom: type date ( renseigner obligatoirement)
Taille : chane de caractres ( renseigner obligatoirement)
Retard : chane de caractres ( renseigner obligatoirement)
CodeLivreur : code simple de type entier
NumImmat : chane de caractres
NumClient : chane de caractres
NomPizza : chane de caractres
Table compose
NumIngre : code simple de type entier
NomPizza : chane de caractres ( renseigner obligatoirement)
Contraintes dintgrit
Les contraintes permettent de dcrire de manire plus prcise les ensembles auxquels
appartiennent les champs.
Intervalle. Le champ Prix de la table pizza peut tre limit lintervalle 1 .. 30. On
pourrait dfinir un intervalle de validit pour les dates de commande (champ DateCom
de la table commande), par exemple la date de commande doit tre suprieure ou gale
la date du jour.
numration. Le champ Retard de la table commande doit contenir les valeurs O ou
N. Le champ Taille de la table commande doit contenir les valeurs naine ,
humaine ou ogresse . Comme il sagit dune franchise o les contenus sont norma-

139 Du langage parl SQL
Chapitre
liss, on peut imaginer que lensemble des noms de pizzas est connu (par exemple, quatre
saisons, margherita). Le champ NomPizza apparat dans plusieurs tables, mais la con-
trainte de type numration porterait uniquement sur le champ NomPizza de la table
pizza. Les autres champs NomPizza sont plutt soumis des contraintes de rfrences
comme on va le voir dans la partie consacre aux rfrences.
Rfrence au contenu dune table. Les champs cls qui proviennent des associations
transformes en relations font rfrence au contenu des relations qui proviennent des
entits. Pour la relation compose, le champ NumIngre fait rfrence au contenu du
champ NumIngre de la table ingrdient et le champ NomPizza au contenu du champ
NomPizza de la table pizza.
En pratique, ici, la plupart des champs fusionns de la relation commande font aussi
rfrence des champs dautres relations.
CodeLivreur de la relation commande. Rfrence au champ CodeLivreur de la rela-
tion livreur.
NumImmat de la relation commande. Rfrence au champ NumImmat de la rela-
tion vehicule.
NumClient de la relation commande. Rfrence au champ NumClient de la relation
client.
NomPizza de la relation commande. Rfrence au champ NomPizza de la relation
pizza.
3.4 CRATION DES TABLES
La cration des tables se fait partir de la dfinition des relations effectues prcdem-
ment. On spcifie le nom des champs, leur type, les contraintes dintgrit et la dfinition
des cls. On peut choisir galement ce moment les champs sur lesquels on souhaite crer
des index. Ces derniers amliorent la recherche par le contenu, mais pnalisent les mises
jour puisquil faut modifier les tables dindex. En gnral, mme si lon est susceptible
deffectuer des recherches sur tous les champs, on ne cre pas dindex pour chacun dentre
eux afin de ne pas pnaliser les performances, mme si lon est susceptible deffectuer des
recherches sur tous les champs. Cela pourrait tre cependant envisageable si le contenu de
la base est trs statique et que lon souhaite favoriser les performances de recherche. Les
index peuvent tre crs sparment.
En pratique, on cre systmatiquement un index sur les cls des relations, ne serait-ce que
pour amliorer les oprations de jointure. Certains SGBD prennent dailleurs linitiative
de crer lindex sur la cl mme si lon ne le spcifie pas explicitement.
Table client
CREATE TABLE client (
NumClient INT PRIMARY KEY,
NomClient VARCHAR(20) NOT NULL,
Adresse VARCHAR(150) ,
Compte REAL,
PointsRaPizz INT
);
Table pizza
CREATE TABLE pizza(
NomPizza CHAR(30) PRIMARY KEY,
Prix CHAR(30) NOT NULL,

140 Cration de bases de donnes
CHECK (Prix BETWEEN 1 AND 30)
);
Table ingredient
CREATE TABLE ingredient(
NumIngre INT PRIMARY KEY ,
NomIngre CHAR(30) NOT NULL
);
Table vehicule
CREATE TABLE vehicule(
NumImmat CHAR(30) PRIMARY KEY,
Marque CHAR(30) NOT NULL,
Type CHAR(30) NOT NULL
);
Table livreur
CREATE TABLE livreur (
CodeLivreur INT PRIMARY KEY,
NomLivreur CHAR(30) NOT NULL,
TeleLivreur CHAR(30) NOT NULL
);
Table compose
CREATE TABLE compose (
NomPizza CHAR(30) REFERENCES pizza(NomPizza),
NumIngre INT REFERENCES ingredient(NumIngre),
PRIMARY KEY (NomPizza, NumIngre)
);
Table commande
CREATE TABLE commande (
NumCommande INT PRIMARY KEY,
DateCom DATE,
Taille CHAR(30) NOT NULL,
Retard CHAR(1) NOT NULL,
NumClient INT REFERENCES client(NumClient),
NomPizza CHAR(30) REFERENCES pizza(NomPizza),
CodeLivreur INT REFERENCES livreur(CodeLivreur),
NumImmat CHAR(30) REFERENCES vehicule(NumImmat),
CHECK Taille in (Ogresse,Humaine,Naine),
CHECK Retard in (O,N)
);
Exemple de cration dun index appel Index_NumCommande sur le champ Num-
Commande de la table commande dans lordre ascendant. Linstruction de cration dun
index nest pas toujours normalise et la syntaxe peut diffrer suivant les SGBD.
CREATE INDEX Index_NumCommande ON commande (NumCommande ASC) ;
La cration des tables ne peut pas se faire dans nimporte quel ordre. Il faut dabord crer
les tables auxquelles ont fait rfrence, puis seulement ensuite les autres tables.
En dautres termes, on ne pourra crer la table commande quaprs avoir cr les tables
client, pizza, livreur et vehicule.
La destruction des tables se fait logiquement dans lordre inverse : on ne peut dtruire une
table qui est rfrence par une autre table.
Cest le SGBD qui ralise ces vrifications.

141 Du langage parl SQL
Chapitre
4 Interrogation de la base de donnes
Cette section aborde la manire de passer dune question en langage parl la requte SQL
conduisant au rsultat. Lensemble des questions nest videmment pas exhaustif ; on a
effectu un choix qui permet de mettre en valeur certains points jugs intressants. On
utilise galement ces questions pour porter un regard sur les reprsentations choisies et
vrifier quelles sont bien adaptes. Le sujet de loptimisation des requtes en fonction du
SGBD choisi nest pas trait, car il dpasse largement le cadre de cet ouvrage.
4.1 MENU
On veut extraire les donnes qui servent imprimer la carte, ce qui signifie que lon veut
disposer du nom de chaque pizza, de son prix et des ingredients qui la composent. Pour ce
faire, on commence par identifier les tables o se trouvent les champs que lon veut
projeter :
Le nom de la pizza est dans la table pizza.
Le prix de la pizza est dans la table pizza.
Les noms des ingrdients se trouve dans la table ingredient.
Le lien entre ces deux tables est matrialis par le modle entit-association : il sagit de
lassociation compose. Cette dernire est devenue la relation compose. On effectue donc
une double jointure entre les trois tables pizza, ingredient et compose. Les tables pizza
et compose seront jointes sur le champ NomPizza et les tables ingredient et compose
seront jointes sur le champ NumIngre.
Il y a deux manires dcrire une jointure. Une jointure peut tre La premire consiste
lapprhender comme une slection sur un produit cartsien. Lcriture est plus pdagogi-
que, mais totalement inefficace du point de vue du SGBD qui doit effectuer le produit car-
tsien puis slectionner les lignes.
SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix
FROM pizza, ingredient, compose
WHERE pizza.NomPizza = compose.NomPizza
AND ingredient.NumIngre = compose.Numingre;
La seconde, plus efficace, est dutiliser linstruction de jointure JOIN.
SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix
FROM pizza JOIN ingredient JOIN compose
ON (pizza.NomPizza = compose.NomPizza
AND ingredient.NumIngre = compose.Numingre);
On se trouve dans le cas trs classique de deux entits lies par une association, qui don-
nent trois tables (pizza et ingredient lies par compose). Il sera ncessaire dutiliser un
langage de programmation pour obtenir un affichage lgant du nom de la pizza, de son
prix et des ingrdients qui la composent. En effet, pour chaque nom de pizza, on obtien-
dra autant de lignes que dingrdients.
4.2 FICHE DE LIVRAISON
On veut imprimer une fiche de livraison qui mentionne le nom du livreur, le type du vhi-
cule utilis, le nom du client, la date de la commande, le retard ventuel, le nom et le prix
de base de la pizza. Par le mme raisonnement que prcdemment, on identifie les tables
commande, client, pizza, livreur et vehicule pour les champs projeter :

142 Cration de bases de donnes
client, pour le nom du client ;
pizza, pour le nom et le prix de la pizza ;
livreur, pour le nom du livreur ;
vehicule, pour le type du vhicule ;
commande, pour le retard, le numro de commande et surtout pour tablir le lien
entre toutes les tables.
SELECT C.NumCommande, CI.NomClient, P.NomPizza, P.Prix, LI.NomLivreur, V.Type,
C.Retard
FROM commande C JOIN livreur LI JOIN pizza P JOIN client CI JOIN vehicule V
ON (C.CodeLivreur=LI.CodeLivreur AND P.NomPizza=C.NomPizza AND
C.NumClient=CI.NumClient AND C.NumImmat=V.NumImmat)
ORDER BY C.NumCommande
;
La table pivot est ici la table commande qui assure la jointure avec toutes les autres tables.
Cela confirme lintuition que lentit commande aurait pu tre considre comme une
association n-aire.
Sur une requte aussi simple, on remarque que le travail du SGBD est assez lourd puisquil
doit effectuer la jointure de cinq tables. Cest la raison pour laquelle on prfre parfois uti-
liser des relations, et donc des tables, avec une certaine redondance afin damliorer les
performances : lopration de jointure est coteuse. Une stratgie couramment employe
consiste grer en interne une base de donnes sans redondance et gnrer une table
redondante qui servira faire les requtes. On dispose ainsi dune garantie de cohrence et
des performances prserves. Les bases de donnes en ligne accessibles par le Web sur les-
quelles on effectue beaucoup de requtes fonctionnent de cette manire. On rserve bien
sr cette mthode aux bases de donnes dont le contenu est assez stable : lopration de re-
gnration de bases chaque changement est coteuse.
4.3 QUELS SONT LES VHICULES NAYANT JAMAIS SERVI ?
Si lon se reporte aux cardinalits du modle entit-association, le cas ne doit pas exister.
On a choisi une cardinalit de type 1-n, ce qui signifie quun vhicule a livr au moins une
commande et quil a pu en livrer plusieurs. Cette requte va permettre de vrifier quil ny
a pas dincohrence ce niveau. On espre que le rsultat sera vide.
On a besoin pour rpondre aux questions du type quels sont les qui nont pas
dutiliser une extension des oprations de jointure : la jointure externe. Celle-ci permet
dinclure dans le rsultat dune jointure les enregistrements qui nont pas de valeur corres-
pondante dans lautre table. Les valeurs des champs de cette autre table sont alors logique-
ment vides. Il suffit de slectionner ces lignes vides pour obtenir la rponse la question.
Cest une opration non symtrique ; on part de la table vehicule que lon va joindre.
SELECT vehicule.NumImmat, vehicule.Marque, vehicule.Type
FROM vehicule LEFT OUTER JOIN commande
ON vehicule.NumImmat = commande.NumImmat
WHERE commande.NumImmat IS NULL;
Cette requte est typique des requtes de vrification que ladministrateur dune base doit
effectuer pour procder certaines vrifications de cohrence. Cela est surtout vrai lors-
que la base de donnes na pas t conue en intgrant les contraintes dintgrit indispen-
sables.

143 Du langage parl SQL
Chapitre
4.4 QUELS CLIENTS COMMANDENT PLUS QUE LA MOYENNE ?
Bien que la question dorigine exprime en langage parl soit simple, ce genre de requte
doit tre aborde avec prudence. La meilleure approche consiste sparer les tapes de
ralisation de la requte ; cette dernire peut tre dissocie en trois tapes :
On calcule ce que commande chaque client.
On calcule la moyenne des commandes.
On cherche les clients qui ont command plus que la moyenne.
chaque tape, on cre une table temporaire qui nous permet de rutiliser le rsultat de la
requte pour les autres tapes. Les tables temporaires disparaissent la fin de la session
SQL.
Calcul du nombre de commandes par client
On utilise la notion dagrgat pour effectuer une opration statistique sur des regroupe-
ments denregistrements de la table. La prsence du mot par dans la question oriente
assez naturellement vers un regroupement et donc vers lutilisation dun agrgat.
CREATE TEMPORARY TABLE requete1
SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande
FROM client JOIN commande ON client.NumClient=commande.NumClient
GROUP BY commande.NumClient;
Calcul de la moyenne des commandes
On doit calculer la moyenne du nombre de commandes par client ; on utilise cet effet
une opration statistique classique sur le champ de la table nombre de commande cre
par la requte prcdente.
CREATE TEMPORARY TABLE requete2
SELECT AVG(NombreCommande) AS MoyenneCommande
FROM requete1;
Extraction des clients ayant command plus que la moyenne
Enfin, on utilise la valeur de la moyenne obtenue par la seconde requte dans lexpression
du critre de slection des enregistrements sur la table obtenue par la premire requte.
Un petit artifice est employ ici. Comme la table provenant de la seconde requte ne con-
tient quun champ, on effectue un produit cartsien entre ces deux tables sans modifier le
nombre de lignes du rsultat. Le but est de pouvoir disposer de la valeur du champ de la
moyenne des commandes pour le comparer au compte du nombre de commandes.
SELECT requete1.NumClient, requete1.NomClient
FROM requete1, requete2
WHERE requete1.NombreCommande > requete2.MoyenneCommande;
On peut crire ces diffrentes requtes dans une seule en utilisant les sous-requtes (ou
requtes imbriques). Cependant, il est prudent daccomplir dabord les tapes prcden-
tes. En dcomposant, il est possible de vrifier les rsultats chaque tape et dviter ainsi
un certain nombre derreurs.
SELECT A.NumClient, A.NomClient
FROM
(SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande
FROM client JOIN commande ON client.NumClient=commande.NumClient
GROUP BY commande.NumClient) A
WHERE R1.NombreCommande >
(SELECT AVG(B.NombreCommande)

144 Cration de bases de donnes
FROM (SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande
FROM client JOIN commande ON client.NumClient=commande.NumClient
GROUP BY commande.NumClient) B
)
;
Il sagit exactement des mmes requtes que celles obtenues lors des tapes prcdentes.
Attention, tous les SGBD ne permettent pas dimbriquer les requtes.
4.5 CALCUL DU PRIX DUNE COMMANDE
On dsire calculer le prix dune commande dans le but dtablir ensuite le rcapitulatif du
chiffre daffaires mensuel, par exemple par client, et de faon gnrale dautres calculs. Le
prix dune commande est fonction de la taille de la pizza commande, qui pondre le prix
de base de la pizza ; on peut lextraire de la table pizza.
Difficults lies la reprsentation choisie
On saperoit lors de cette opration que la reprsentation sous forme textuelle ( naine ,
humaine , ogresse ) de la taille dune pizza nest pas adapte pour le calcul. En effet,
on est incapable de calculer son prix directement en SQL partir des informations conte-
nues dans la table.
Il ny a pas dindication dans la base de donnes du mode de calcul du prix de la pizza, ce
qui signifie que lon doit faire un test de ce type : si taille vaut ogresse , alors prix = prix
(1 + 1/3). Le plus simple est alors de passer par un langage de programmation pour
associer la taille au coefficient qui permet de calculer le prix. Ce nest pas le but recherch ;
la base de donnes doit tre autonome et il sagit dune information importante que lon
doit pouvoir retrouver dans la base et qui doit donc y tre stocke.
Modification de la base de donnes
On propose une modification de la base de donnes pour intgrer cette notion. Une pre-
mire solution simple serait de remplacer le libell de la taille par le coefficient qui permet
de calculer le prix. On remplace naine par 2/3 , humaine par 1 et ogresse
par 4/3 . On doit changer le type du champ Taille sans perdre le contenu. Le plus sim-
ple est de recrer un champ Taille_Prix et de faire une mise jour. Les commandes qui
modifient le contenu sont les suivantes :
Ajout du champ Taille_prix
ALTER TABLE commande
ADD COLUMN Taille_Prix Float;
Cration du contenu du champ en fonction du contenu de Taille
UPDATE commande
SET Taille_Prix=2/3
WHERE Taille=naine ;
UPDATE commande
SET Taille_Prix=1
WHERE Taille=humaine ;
UPDATE commande
SET Taille_Prix=4/3
WHERE Taille=ogresse ;
Destruction du champ Taille
ALTER TABLE commande
DROP COLUMN Taille;
On peut alors calculer le prix dune commande directement.

145 Du langage parl SQL
Chapitre
SELECT commande.NumCommande, pizza.Prix*commande.Taille_Prix AS Prix_Commande
FROM commande JOIN pizza ON
commande.NomPizza=pizza.NomPizza;
Rflexion sur la modification apporte et amlioration de la solution
Si le mode de calcul change, par exemple si lon dcide quune pizza naine cote 3/4 du
prix normal, il faut alors modifier le(s) coefficient(s) pour toutes les commandes.
On perd galement la mention du libell, plus commode manipuler et probablement
indispensable pour imprimer les factures. On aurait pu conserver le champ Taille avec le
libell pour ne pas perdre cette information, il suffit de ne pas effacer la colonne Taille
(dernire commande de la liste prcdente). On se trouve alors dans la situation o il
existe une dpendance fonctionnelle entre les champs Taille et Taille_Prix. En effet,
une taille correspond un unique prix : la relation commande nest plus en troisime
forme normale et lon a cr de la redondance.
Pour rgler ce problme, il suffit de dcomposer la relation commande en crant une
nouvelle relation tarification qui dcrira le coefficient en fonction du libell.
Cration de la table tarification
CREATE TABLE tarification(
Taille CHAR(30) PRIMARY KEY,
Coefficient FLOAT NOT NULL
);
Insertion des donnes dans la table tarification
INSERT INTO tarification
(Taille, Coefficient)
VALUES (naine, 2/3) ;
INSERT INTO tarification
(Taille, Coefficient)
VALUES (humaine, 1) ;
INSERT INTO tarification
(Taille, Coefficient)
VALUES (ogresse, 4/3) ;
On obtient alors les instructions SQL suivantes pour calculer le prix dune commande. Il
est ncessaire de faire une jointure entre les trois tables commande, pizza (pour le prix)
et tarification (pour le coefficient).
SELECT commande.NumCommande, pizza.Prix*tarification.Coefficient AS Prix_Commande
FROM commande JOIN pizza JOIN tarification ON
commande.NomPizza=pizza.NomPizza
AND commande.Taille=tarification.Taille;
Implications des modifications apportes au modle entit-
association
Quelles sont les rpercussions de cette modification sur le modle entit-association uti-
lis jusqu prsent ? Par un processus inverse, on doit retrouver logiquement le mme
ensemble de relations. La phrase qui reprsente lassociation entre les entits est la
suivante : Une commande utilise la tarification . La nouvelle relation introduite pro-
vient dune nouvelle entit associe lentit commande :
Lattribut Taille ne se trouve plus dans lentit commande.
La nouvelle entit Tarification contient les attributs Taille et Coefficient, lattribut
Taille est la cl de cette entit.
Lentit tarification est associe lentit commande par une association que lon
peut nommer utilise.

146 Cration de bases de donnes
Cardinalits de lassociation utilise.
La pizza de la commande a une et une seule taille : la cardinalit est de type 1-1.
Une tarification peut navoir jamais t utilise pour une commande et plusieurs com-
mandes diffrentes peuvent avoir la mme tarification : la cardinalit est de type 0-n
(voir figure 5.3).
Figure 5.3
Modle entit-
association
Livraisons de
pizzas avec
cardinalits.
On dcompose lassociation emploie et lentit tarification :
Lentit tarification devient une relation dont la cl est Taille
Lassociation a une cardinalit 1-1, il sagit du cas particulier voqu prcdemment,
la relation produite par lassociation est aspire par la relation cre par lentit
associe avec la cardinalit 1-1, cest--dire commande. La fusion produit le dplace-
ment de lattribut Taille vers la relation commande.
Finalement, la relation commande reste inchange mme si lentit dont elle est issue a
t modifie au niveau du modle entit-association. On a introduit une nouvelle relation
tarification comme cela a t fait de manire intuitive prcdemment. On obtient
lensemble de relations suivant :
client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (CodeLivreur, NomLivreur, Tlphone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NumIngre, NomIngrdient) ;
commande (NumCommande, DateCom, Taille, Retard, CodeLivreur, NumImmat,
NumClient, NomPizza) ;
compose (NumIngre, NomPizza) ;
tarification(Taille, Coefficient).
Commande
Livreur
Pizza
Vhicule
Ingrdient
Client
# NumCommande
DateCom
Retard
# NumClient
NomClient
Adresse
Compte
PointsRapizz
# NomPizza
Prix
# CodeLivreur
NomLivreur
Tlphone
# NumIngre
NomIngre
# NumImmat
Marque
Type
Livre
Transporte
Passe
Compose
1,n
1,n
0,n
1,1
1,1
1,1
1,1
1,n
1,n
0,n
Tarification
#Taille
Coefficient
Utilise
1,1
0,n Constitue

147 Du langage parl SQL
Chapitre
pilogue
Cet exemple illustre comment le modle entit-association peut tre remis en cause par
ncessit. Le problme de reprsentation de dpart a provoqu une modification du
modle par une dmarche inverse de celle utilise prcdemment : on a remis en cause le
modle entit-association partir de lensemble des relations. En revanche, il ne faut pas
oublier de modifier le modle entit-association pour quil soit cohrent avec lensemble
des tables employes dans le SGBD. Les tables sont inutilisables sans modle descriptif. On
peut le constater avec ce systme relativement simple qui possde dj huit tables. Les
allers-retours entre les diffrents niveaux de modles sont frquents dans la vie dune
base de donnes.
Rsum
Ce chapitre dtaille lensemble des tapes ncessaires la ralisation dune base de don-
nes, mme les plus fastidieuses. La grande difficult est de passer dun nonc en langage
parl, qui fait gnralement suite un entretien avec les commanditaires et les utilisateurs,
un systme utilisable en pratique et efficace. Le flot dinformations recueilli doit tre
ordonn et structur. Lexemple choisi est peu complexe, mais il permet daborder quel-
ques questions essentielles. On saperoit cette occasion que lensemble des tables utili-
ses dans le SGBD devient rapidement illisible si lon ne possde pas un schma descriptif
(modle entit-association ou UML) correct.
La partie Interrogation illustre les catgories dutilisations et dinterrogations classi-
ques dune base de donnes. Lide est de donner des indications afin didentifier le type de
requte SQL utiliser en fonction de la question exprime en langage courant. La dmar-
che suggre est de toujours dcomposer les questions en sous-questions plus simples
rsoudre puis de procder par tapes. Un des exemples aborde ensuite le cas o, au cours
de lutilisation de la base de donnes, il est impossible de trouver la solution en raison
dune reprsentation inadquate. Il est alors ncessaire de remettre en cause le modle
utilis :
Soit on modifie le contenu des tables et lon rpercute les modifications sur le modle
descriptif utilis.
Soit on modifie le modle descriptif et lon ritre les tapes de passage au modle rela-
tionnel.
La seconde mthode est la solution la plus juste dun point de vue thorique. Mais, en pra-
tique, on utilise une combinaison des deux approches pour obtenir le rsultat. Il est essen-
tiel de comprendre quil ny a pas de solution unique en base de donnes. Le modle est
frquemment adapt et aucune reprsentation nest fige. De mme que la ralit peut tre
envisage diffremment suivant les personnes, il existe souvent plusieurs visions valides.
Remarque
Les requtes retournent toujours un rsultat. Cependant, on ne peut tre sr que ce dernier repr-
sente la rponse exacte la question pose. Il est ncessaire de systmatiquement vrifier le rsul-
tat sur un jeu de donnes rduit. De mme quen programmation, on ne peut prouver quun
programme ralise correctement ce quon lui demande dans tous les cas de figure ; il est difficile
dtablir quune requte fournit la rponse adquate lorsque le nombre denregistrements devient
lev.

148 Cration de bases de donnes
Exercices
EXERCICE 1 REPRSENTATION UML
On part du modle entit-association final, celui auquel on a ajout lentit
tarification . La partie dUML qui est utilise est le diagramme de classe ; celui-ci com-
prend le nom de la classe, la description des attributs et les mthodes associes la classe.
Dans ce cas, on nutilise pas la partie objet et donc il ny a pas de mthodes associes aux
classes. Une entit est reprsente par un diagramme de classe. Avec UML, il est possible
dintgrer les notions de contraintes dintgrit au niveau du schma. On peut par exem-
ple spcifier que lattribut retard de lentit commande ne pourra prendre comme
valeurs que O et N . Les associations utilises dans ce message nont pas dattributs.
Une diffrence majeure est que les cardinalits seront positionnes de manire inverse
par rapport au modle entit-association (voir figure 5.4).
Figure 5.4
Modle UML
Livraisons de
pizzas avec
cardinalits.
EXERCICE 2 CALCULS PAR EXPRESSION SQL
Pour calculer le nombre de pizzas livres en retard, il faut se souvenir dun point impor-
tant que lon a fix comme axiome lors de llaboration du modle : une pizza est asso-
cie une commande et une seule. Une commande ne contient quune seule pizza. Cest
important : si ce ntait pas le cas, la requte serait beaucoup plus complexe.
Reprsentez le modle entit-association en utilisant le formalisme UML.
Combien de pizzas ont-elles t livres en retard ? Quelle est la perte occasionne par ces
retards ?
Commande
Livreur
Pizza
Vhicule
Ingrdient
Client
# NumCommande
DateCom
Retard
# NumClient
NomClient
Adresse
Compte
PointsRapizz
# NomPizza
Prix
# CodeLivreur
NomLivreur
Tlphone
# NumIngre
NomIngre
# NumImmat
Marque
Type
Livre
Transporte
Passe
Compose
1..1 1..n
Tarification
#Taille
Coefficient
Utilise
1..1 0..n
1..1
1..n
0..n
0..n
1..1
1..1
1..n
1..n
Constitue

149 Du langage parl SQL
E
x
e
r
c
i
c
e
s
Chapitre
Le type de question qui inclut le mot combien suggre que lon va effectuer un comp-
tage sur la table. Il nous suffit de compter le nombre denregistrements dont le champ
retard est positionn Oui . On a vu lors de la dfinition de la table commande que le
contenu du champ retard a t normalis et restreint par une contrainte dintgrit aux
valeurs N et O . Ces rflexions conduisent la simple requte suivante :
SELECT COUNT(*) AS NombreRetard
FROM commande
WHERE retard=O;
On compte le nombre de lignes de la table commande dont le champ commande est gal
O . On ne spcifie pas de nom de champ dans la fonction COUNT de SQL, car il
sagit dun calcul indpendant dun champ donn.
Pour connatre la perte occasionne, on calcule la somme du prix de chaque commande.
Le modle a t modifi pour pouvoir calculer directement cette information. On a besoin
du prix de base de la pizza qui se trouve dans la table pizza et du coefficient qui se trouve
dans la table tarification. On effectue une jointure sur ces trois tables.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard
FROM commande JOIN pizza JOIN tarification
ON commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille
WHERE commande.retard=O;
La fonction SQL SUM a besoin du contenu prcis du champ concern par le calcul. Ici, il
sagit dune expression constitue partir du prix et du coefficient. Il est prfrable de pr-
fixer les noms de champ par le nom de la table do ils proviennent pour viter les ambi-
guts et faciliter la lecture ultrieure de la requte. Les ambiguts sont signales par le
SGBD qui refuse dexcuter la requte.
On aurait pu crire les jointures en utilisant classiquement un produit cartsien et une
slection. Dans ce cas, les expressions qui servent la jointure sont mlanges celles qui
servent faire la slection dans la clause WHERE. De plus, la requte est effectue de
manire beaucoup moins efficace par le SGBD ; cela est nettement perceptible lorsque lon
dispose de tables de taille importante.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard
FROM commande, pizza, tarification
WHERE commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille
AND commande.retard=O;
Les deux tables rsultat sont des tables qui possdent une seule ligne et une seule
colonne. On peut utiliser ces valeurs par exemple pour faire une comparaison (voir lun
des exercices suivants) en les associant par un produit cartsien la table sur laquelle on
veut effectuer la comparaison.
EXERCICE 3 CODE SQL ET SIGNIFICATION
Cette requte SQL donne-t-elle un rsultat ? Si oui, que signifie-t-il ?
SELECT client.NomClient, livreur.NomLivreur
FROM livreur JOIN client
ON livreur.CodeLivreur=client.NumClient ;
Imaginez quel type de question a voulu rpondre la personne qui a fait cette requte.

150 Cration de bases de donnes
La requte retourne un rsultat, car la syntaxe est correcte et le type des champs sur les-
quels on a effectu la jointure sont de type compatible et contiennent des valeurs commu-
nes. Bien videmment, le rsultat na aucun sens dun point de vue la ralit. Le schma
entit-association montre que les liens entre les tables client et livreur passent par la
table commande et les associations livre et passe. Il sagit du cas typique qui illustre le
fait quune requte donne toujours un rsultat, mme sil na aucun sens.
En aucun cas, cette requte ne permettrait deffectuer des recherches de corrlation entre
le livreur et le client. Si lon cherche afficher le nom du client et le nom du livreur corres-
pondant par commande, on doit utiliser la table commande mme si lon ne projette
aucun champ de la table commande. Pour faciliter la lecture et reprer dventuelles cor-
rlations, on ordonne par noms de clients.
SELECT client.NomClient, livreur.NomLivreur
FROM livreur JOIN commande JOIN client
ON livreur.CodeLivreur=commande.CodeLivreur
AND client.NumClient= commande.NumClient
ORDER BY client.NomClient;
Pour savoir quels clients sont toujours livrs par le mme livreur, la dmarche serait plus
complexe.
EXERCICE 4 AGRGATS ET SLECTION
La mthode conseille dans ce chapitre est daborder la question en dcomposant le pro-
blme. Pour calculer le chiffre daffaires, il faut dabord regrouper les commandes par
pizza et ensuite effectuer le calcul. La notion de regroupement suggre lemploi des agr-
gats. Le nom de la pizza est directement accessible dans la table commande. Pour vrifier
combien de commandes ont t passes par pizza, on les compte.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande
FROM commande
GROUP BY commande.NomPizza;
Pour calculer le prix, on a besoin du prix de base qui se trouve dans la table pizza et du
coefficient qui se trouve dans la table tarification.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarifica-
tion.coefficient) AS TotalCommande
FROM commande JOIN pizza JOIN tarification
ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza
GROUP BY commande.NomPizza
ORDER BY TotalCommande;
On trie le rsultat en utilisant le champ calcul TotalCommande. Lopration de tri se fait
donc aprs les oprations de jointures, dagrgation et de calculs. Il est possible de raliser
une slection sur le rsultat final de cette opration en ne considrant que les pizzas dont
le chiffre daffaires dpasse le nombre 200 . On nemploie pas dans ce cas le mot cl
WHERE qui sert raliser les slections sur une table standard. On utilise le mot
cl HAVING qui fait une slection sur le rsultat des calculs sur les agrgats. Cette slec-
tion se fait, de mme que le tri, la fin de lopration sur la table rsultat finale.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarifica-
tion.coefficient) AS TotalCommande
Donnez le chiffre daffaires par pizza vendue. On ne tient pas compte ce niveau des piz-
zas gratuites obtenues grce aux points de fidlit ou en raison dun retard de livraison.

151 Du langage parl SQL
E
x
e
r
c
i
c
e
s
Chapitre
FROM commande JOIN pizza JOIN tarification
ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza
GROUP BY commande.NomPizza
HAVING TotalCommande > 200
ORDER BY TotalCommande;
En revanche, si lon avait voulu liminer du rsultat les pizzas dont le prix de vente nest
pas assez lev considrant que cela fausse le rsultat, le mode de slection ne serait pas le
mme. Il faudrait raliser une slection sur lensemble de dpart avant deffectuer les agr-
gats et les calculs ; dans ce cas, on utiliserait le mot cl WHERE.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarifica-
tion.coefficient) AS TotalCommande
FROM commande JOIN pizza JOIN tarification
ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza
WHERE pizza.prix > 10
GROUP BY commande.NomPizza
ORDER BY TotalCommande;
Dans le premier cas, la slection est faite a fortiori ; dans le second, a priori.
EXERCICE 5 REQUTES COMBINES
On dcompose le problme :
calcul du nombre de retards par livreur ;
calcul du maximum de ces retards ;
slection du nom du livreur qui a le maximum de retard.
Calcul du nombre de retards par livreur. Le mot par suggre comme prcdem-
ment lemploi dagrgats sur lesquels on utilise la fonction de comptage.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
Calcul du maximum de ces retards. On utilise la fonction SQL MAX sur le contenu de
la table prcdente.
CREATE TEMPORARY TABLE requete2
SELECT MAX(NombreRetard)AS MaxRetard
FROM requete1
;
Slection du nom du livreur qui a le maximum de retard. Il est demand dafficher le
nom du livreur, disponible uniquement dans la table livreur. On fait classiquement une
jointure pour le rcuprer. On doit galement disposer de la valeur du maximum de retard
que lon trouve dans la table temporaire requete2. On lassocie lopration sur les deux
autres tables par un produit cartsien. Cela ne change pas le nombre de lignes du rsultat
car la table requete2 na quune ligne.
Il sagit dun cas o lon effectue dans la mme requte un produit cartsien et une jointure.
Quel est le nom du livreur qui a le plus de retard ?

152 Cration de bases de donnes
SELECT livreur.NomLivreur
FROM requete1 JOIN livreur ON livreur.CodeLivreur=requete1.CodeLivreur, requete2
WHERE requete1.NombreRetard=requete2.MaxRetard
;
Avec un peu dexprience, on saperoit quil sagit dune requte semblable celle que lon
prsente dans le chapitre pour connatre les clients qui commandent plus que la moyenne.
EXERCICE 6 SIMPLE SLECTION OU JOINTURE EXTERNE ?
La tournure de phrase qui na jamais semble suggrer lemploi dune jointure externe,
comme ctait dj le cas dans le chapitre o on a dtermin les vhicules nayant jamais
servi. Cependant, cette jointure externe sert dterminer les entits non associes dans
une jointure. Ici, on peut obtenir linformation du retard directement dans la table com-
mande. Si lon considre les rsultats de lexercice prcdent, on a calcul le nombre de
retards par livreur par la requte suivante.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
Un livreur naura jamais t en retard si le nombre de retards ainsi calcul est gal zro.
SELECT requete1.CodeLivreur
FROM requete1
WHERE requete1. NombreRetard=0
;
On cherche le nom du livreur et non pas son code. Il y a deux manires de procder :
Soit on fait une jointure sur la table livreur pour la premire requte de manire
inclure le nom du livreur dans la table rsultat.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, livreur.NomLivreur, COUNT(*) AS NombreRetard
FROM commande JOIN livreur
ON commande.CodeLivreur=livreur.CodeLivreur
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
SELECT requete1.NomLivreur
FROM requete1
WHERE requete1. NombreRetard=0
;
Soit on fait la jointure lors de la seconde requte.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
SELECT livreur.NomLivreur
FROM requete1 JOIN livreur ON requete1.CodeLivreur=livreur.CodeLivreur
WHERE requete1. NombreRetard=0
;
Quel est le nom du livreur qui nest jamais en retard ?

153 Du langage parl SQL
E
x
e
r
c
i
c
e
s
Chapitre
Il est possible de regrouper ces deux requtes en une seule. La stratgie de regroupement
dpendra du SGBD employ.
Le cas serait diffrent si lon cherchait identifier les noms des livreurs qui nont jamais
effectu de livraison.
Laction de livraison est reprsente par lassociation livre dans le modle entit-associa-
tion. Cette association, puisque de cardinalit 1-1, a disparu en tant que table et a t
intgre dans la relation commande issue de lentit commande.
En rsum, linformation nest disponible que par une jointure entre les tables com-
mande et livreur. Lide ici est de trouver les codes des livreurs prsents dans la table
livreur mais pas dans la table commande. Daprs notre dfinition du modle entit-
association, ce ne devrait pas tre possible puisque la cardinalit du point de vue (du ct)
de lentit livreur est de type 1-n : un livreur a au moins livr une pizza et est susceptible
den livrer plusieurs. On emploie alors une jointure externe qui nous permet dinclure
dans le rsultat les lignes nayant pas de correspondance dans la table commande.
SELECT *
FROM livreur LEFT JOIN commande
ON livreur.CodeLivreur=commande.CodeLivreur
;
Pour slectionner ceux qui nauraient pas effectu de livraison, on choisit une ligne dont
un champ issu de la table commande est vide (a une valeur nulle en SQL). On projette
sur le champ NomLivreur de la table commande qui tait linformation demande.
SELECT livreur.NomLivreur
FROM livreur LEFT JOIN commande
ON livreur.CodeLivreur=commande.CodeLivreur
WHERE commande.CodeLivreur IS NULL
;
EXERCICE 7 MISE JOUR DE LA BASE
On calcule le prix de la commande comme on la vu prcdemment. La commande est
identifie par son numro de commande, ici 60. On aura galement besoin du numro de
client pour faire la mise jour.
CREATE TEMPORARY TABLE requete1
SELECT commande.NumClient, pizza.Prix*tarification.Coefficient AS Prix_Commande
FROM commande JOIN pizza JOIN tarification ON
commande.NomPizza=pizza.NomPizza
AND commande.Taille=tarification.Taille
WHERE NumCommande=60 ;
La requte de mise jour serait la suivante, on rcupre les champs prix de la commande
de la premire requte pour effectuer la mise jour du solde du compte du client dans la
table client.
UPDATE client,requete1
SET Compte=Compte-requete1.Prix_Commande
WHERE client.NumClient=requete1.NumClient ;
On veut mettre jour le solde du compte dun client aprs chaque commande. Pour ce fai-
re, il est ncessaire de recourir un langage de programmation ou des notions qui dpas-
sent le cadre de cet ouvrage ; on sintresse simplement aux diffrentes requtes prvoir
pour raliser cette opration. Pour linstant, on considrera que lon cre la requte de mise
jour sans se proccuper des aspects de solde (ngatif ou positif) du compte.

154 Cration de bases de donnes
Il est prvu de pouvoir lancer dans un SGBD une requte au moment o lon effectue une
opration : on appelle cela des triggers ou procdures stockes. Typiquement, il faudrait
lancer cette requte chaque fois que lon cre une commande.
EXERCICE 8 VOLUTION DE LA BASE DE DONNES
Pour traiter ce genre de cas, on doit se rappeler que lon ne stocke jamais une donne qui
peut tre calcule. Par consquent, on ne stocke pas les prix hors taxes et toutes taxes de
chaque pizza. On suppose que le prix stock dans la table pizza est le prix hors taxes. Si le
taux est fixe, on peut lutiliser pour les calculs de prix toutes taxes. On affiche le contenu de
lexpression qui permet de calculer le prix toutes taxes.
SELECT NomPizza, Prix*(1+19.6) AS Prix_Ttc
FROM pizza ;
Si le taux nest pas fixe, il faut linclure dans le systme dinformation ; on cre une table
taxe avec une ligne et une colonne, qui contiendra uniquement le taux.
CREATE TABLE taxes (
Taux FLOAT
);
INSERT INTO taxes
(Taux) VALUES (19.6) ;
On rcupre la valeur du taux comme on la fait prcdemment, en faisant un produit car-
tsien avec la table taxes.
SELECT NomPizza, Prix*(1+Taux) AS Prix_Ttc
FROM pizza, taxes ;
Dans ce second cas, il faudrait pour tre complet ajouter lentit taxes au modle entit-
association. Elle ne serait lie aucune entit par une association.
EXERCICE 9 AUTRE EXEMPLE COMPLET
On veut pouvoir calculer les prix des pizzas hors taxes et toutes taxes. Que faut-il modifier
dans la base de donnes selon que le taux est considr comme fixe ou susceptible de
varier ?
Xavier S. possde deux tablissements hteliers dans le Limousin : Le Saint-Bob
Saint-Robert et Le Saint-Sgur Sgur-le-Chteau. Il dsire automatiser la gestion des
rservations. Les chambres proposes dans les deux tablissements sont de trois types :
simples (50 /jour), doubles (65 /jour) et royales (150 /jour). Dans chacun des deux
htels, les chambres sont numrotes en fonction de ltage : les chambres en rez-de-
chausse portent les numros 001, 002; les chambres du premier tage portent les nu-
mros 100, 101 ainsi de suite. Les rservations sont centralises Saint-Robert au 0800
800 800 et un employ est charg de rpondre au tlphone pour les deux tablissements.
Lorsquun client rserve une chambre, sil nest pas rfrenc, on lui demande son nom,
son prnom, son numro de tlphone ainsi que son adresse.

155 Du langage parl SQL
E
x
e
r
c
i
c
e
s
Chapitre
Les numros de chambres ne peuvent pas constituer un identifiant de lentit Chambre,
dans la mesure o les deux htels possdent des chambres ayant le mme identifiant. En
consquence, il convient dajouter un identifiant unique supplmentaire lentit Cham-
bre. La priode de rservation modlise laide dune date de dbut et dune date de fin
dpend fonctionnellement de la chambre et du client. Le nombre de jour sera dduit
partir de ces donnes laide dun traitement informatique afin de procder la factura-
tion du sjour. Le type de chambre dterminant le prix de la chambre, une entit suppl-
mentaire Type doit tre cre.
1. Modle conceptuel
Htel(ID_Hotel, Nom_hotel, CP, Ville)
Chambre(ID_Chambre, Num_chambre)
Type(ID_Type, Libelle, Prix)
Reserver(Date_debut, Date_Fin) entre Client et Chambre (1,n 0,n)
Composer() entre Chambre et Hotel (1,1 1,n)
Correspondre() entre Chambre et Type (1,1 0,n)
2. Modle relationnel
Hotel(ID_Hotel, Nom_hotel, CP, Ville)
Chambre(ID_Chambre, Num_chambre, ID_hotel, ID_Type)
Type(ID_Type, Libelle, Prix)
Reserver(Code_client, ID_Chambre, Date_debut, Date_fin,)
Client(Code_client, Nom_client, Prenom_client, Num_tel, Adresse, CP, Ville)
3. Code SQL de cration des tables
CREATE TABLE HOTEL
ID_HOTEL INT PRIMARY KEY,
NOM_HOTEL VARCHAR(20) NOT NULL,
CP VARCHAR(5) NOT NULL,
VILLE VARCHAR(50) NOT NULL
) ;
CREATE TABLE CHAMBRE(
ID_CHAMBRE INT PRIMARY KEY,
NUM_CHAMBRE INT NOT NULL,
ID_HOTEL INT REFERENCES HOTEL(ID_HOTEL),
ID_TYPE INT NOT NULL REFERENCES TYPE(ID_TYPE)
) ;
CREATE TABLE TYPE(
ID_TYPE INT PRIMARY KEY,
LIBELLE VARCHAR(50) NOT NULL,
PRIX FLOAT(10,2),
CHECK LIBELLE IN (SIMPLE,DOUBLE,ROYALE)
) ;
1. Ralisez le modle conceptuel des donnes, spcifiez les cardinalits.
2. Dduisez-en le modle entit-association correspondant.
3. Crez les tables correspondantes (commande SQL create table), en spcifiant les
cls uniques. Indiquez les contraintes dintgrit pour ces tables.
4. Donnez la requte permettant de lister les rservations effectues en 2006.

156 Cration de bases de donnes
CREATE TABLE RESERVER(
CODE_CLIENT VARCHAR(9) NOT NULL REFERENCES CLIENT(CODE_CLIENT,
ID_CHAMBRE INT NOT NULL REFERENCES CHAMBRE(ID_CHAMBRE),
DATE_DEBUT DATE, DATE_FIN DATE
) ;
CREATE TABLE CLIENT(
CODE_CLIENT VARCHAR(9) PRIMARY KEY,
NOM_CLIENT VARCHAR(50) NOT NULL,
PRENOM_CLIENT VARCHAR(50) NOT NULL,
NUM_TEL VARCHAR(10) NOT NULL,
ADRESSE VARCHAR(250),
CP VARCHAR(5),
VILLE VARCHAR(50) NOT NULL
) ;
4. Code SQL permettant de lister les rservations de 2006
SELECT *
FROM `RESERVER`
WHERE `DATE_DEBUT` >= '01/01/2006 ' AND `DATE_FIN` <= '31/12/2006'
;

Prservation
des donnes
157
Chapitre
1. Contrle daccs et
sauvegarde ............................ 158
2. Limitations daccs au SGBD ... 161
3. Transactions ........................... 166
4. Triggers ................................ 173
Exercices
1. Scurit de base ..................... 176
2. Disponibilit des donnes ........ 176
3. Niveaux dutilisation dune base
de donnes ............................ 177
4. Gestion des droits ................... 178
5. Vues ...................................... 179
6. Transactions ........................... 181
7. Trigger ................................... 182
Ce chapitre traite de la scurit des donnes qui est
une notion fondamentale des bases de donnes. En
effet, le pire pour une base de donnes est la perte
ou la modification de donnes. Des problmes
srieux peuvent tre provoqus de manire
intentionnelle ou accidentelle, mais le rsultat
obtenu est le mme.
Lactivit des organisations repose sur les donnes :
il convient par consquent de les protger, mais
galement den assurer la disponibilit permanente.
On distinguera plusieurs niveaux de granularit
quant aux recommandations gnrales concernant la
scurit des donnes :
la protection de laccs la machine dun point de
vue physique ou rseau, les aspects de dure de
vie du systme ainsi que la politique de
sauvegarde ;
la politique de restriction daccs aux donnes du
SGBD par des comptes et lutilisation des vues ;
la capacit des outils du SGBD protger les
oprations sur les donnes, les restaurer et
revenir en arrire, comme pour les transactions.
On introduit en fin de chapitre un outil
complmentaire : le trigger . Les triggers (ou
dclencheurs) sont utiliss pour forcer une bonne
gestion du contenu des donnes lors des oprations
dinsertion, de mise jour ou de suppression de
donnes.

158 Cration de bases de donnes
1 Contrle daccs et sauvegarde
Toute rflexion autour de la scurit doit se concevoir de manire globale en utilisant en
premier lieu le bon sens : il est inutile dinstaller une porte blinde inviolable sur une palis-
sade en bois. Les recommandations qui sont nonces dans cette section sont applicables
tous les systmes informatiques, en particulier ceux qui sont connects un rseau ou
situs dans un milieu qualifi d hostile .
On dcrit ici plusieurs types de proccupations :
laccs physique la machine ;
laccs distant la machine travers le rseau ;
les aspects de prennit de lensemble machine, systme dexploitation et SGBD ;
les sauvegardes, la redondance des donnes et leur accessibilit.
1.1 ACCS PHYSIQUE LA MACHINE
Cette mesure de scurit informatique lmentaire est trs souvent nglige. Procurer un
accs physique la machine permet en gnral de contourner toutes les protections lies
au systme dexploitation ou au SGBD que lon aborde dans ce chapitre. Il suffit de
dmarrer une machine avec un autre systme dexploitation prsent sur un CD ou une cl
USB par exemple pour obtenir un accs au disque et ainsi aux donnes associes au SGBD.
La premire prcaution prvoir consiste protger le BIOS (Basic Input Output System)
ou lquivalent de la machine pour lempcher de dmarrer sur un autre disque que celui
qui contient le bon systme dexploitation.
Le fait de pouvoir accder directement la machine permet galement une personne
anime de mauvaises intentions dempcher laccs aux donnes en dtruisant physique-
ment le disque sur lequel se trouvaient les fichiers ou mme la machine.
Par consquent, la ou les machines qui contiennent le SGBD et les fichiers de donnes doi-
vent se trouver dans des pices dont laccs est, au minimum, contrl. Dans le mme
ordre dide, lalimentation lectrique ne doit pas tre accessible. On a tous entendu ou
vcu une histoire de machines ou dlments rseaux dbranchs par erreur pour effectuer
le mnage, sans parler de la malveillance. Comme on peut le constater, les prcautions
concernant laccs physique la machine ne sont pas toujours dordre purement
technique ; elles relvent souvent du simple bon sens commun.
1.2 ACCS LA MACHINE PAR LE RSEAU
Laccs la machine par le rseau est devenu une porte dentre privilgie pour les per-
sonnes malintentionnes, car rares sont les serveurs qui ne sont pas connects
aujourdhui. On distingue ainsi principalement deux aspects de problmes de scurit :
les attaques internes qui proviennent de personnes ayant accs la machine par un
compte standard associ un mot de passe correct ;
les attaques externes qui se font en profitant dune faille du systme dexploitation
ou dune des applications installes sur la machine.
Dans les deux cas, on peut tre confront un problme de destruction de donnes par
simple effacement de fichiers de donnes. Cette opration deffacement sera rendue plus
ou moins facile suivant les systmes employs. Dans le premier cas, il est en principe

159 Prservation des donnes
Chapitre
impossible quun simple utilisateur efface les fichiers des autres, mais certains systmes
sont plus permables que dautres. Dans le second cas, si lon peut devenir administra-
teur sur la machine concerne du point de vue du systme dexploitation, tout est possible.
Sil sagit dun cas de malveillance, les dgts peuvent tre considrables.
Les protections dans ce domaine ne dpendent pas spcifiquement de ladministrateur du
SGBD, mais aussi de ladministrateur systme et rseau de lenvironnement dans lequel se
trouve la machine qui hberge le SGBD. Le systme et les applications prsentes sur la
machine doivent tre maintenus et mis jour rgulirement pour viter les problmes.
Ladministrateur systme doit galement tenir jour les comptes utilisateurs qui poss-
dent les droits daccs la machine et vrifier la qualit des mots de passe associs. Classi-
quement, une intrusion se fait en utilisant un compte oubli , cr par exemple pour un
besoin ponctuel, dont le mot de passe est assez simple pour tre devin. Le SGBD lui-
mme est une application parmi les autres ; il peut prsenter des failles et doit faire partie
du programme des mises jour critiques. Cette tche est gnralement effectue par
ladministrateur du SGBD, qui doit galement tenir jour les comptes dutilisateurs spci-
fiques du SGBD disposant de droits daccs la machine.
En rsum, le systme sur lequel est hberge la base de donnes doit faire lobjet dun
suivi permanent tous les niveaux. Il nest pas raisonnable dinstaller un SGBD sur une
machine dont le systme ne peut tre mis jour ou dont les mises jour sont disponibles
trop tardivement. Toute application prsente sur la machine peut recler des failles et tre
le maillon faible de lensemble. Les informations de vulnrabilit et les correctifs sont
fournis par les diteurs de ces applications. Dans notre cas, on doit porter une attention
particulire une application importante : le SGBD. La ractivit des diteurs constitue un
critre dcisif pour choisir un systme et un SGBD. Dun point de vue humain, la qualit
de ladministration du systme et du rseau sur lequel se trouve la machine peut tre ga-
lement un lment du choix.
1.3 PRENNIT DU SYSTME
Une base de donnes se conoit gnralement pour de nombreuses annes dutilisation. Il
est donc essentiel, avant de choisir une machine, son systme dexploitation ainsi que le
logiciel de SGBD, de prendre en considration leurs prennits respectives. Le choix peut
alors se porter sur des ensembles moins performants mais que lon considre comme plus
viables en termes de dure de vie.
Voici quelques points considrer :
Le suivi de la machine elle-mme. Par exemple, la dure de la garantie matrielle, la
possibilit de retrouver les pices etc.
La dure de vie du systme dexploitation. Un systme qui nest plus mis jour par
son diteur et qui prsente des trous importants de scurit se rvle un trs mauvais
choix. La plupart des diteurs continuent assurer une maintenance minimale pour
les anciens systmes, mais ce nest pas systmatique.
Lvolutivit du SGBD. Un SGBD propritaire qui noffre pas les changes de donnes
avec dautres logiciels handicape la migration vers un autre SGBD. De mme que pour
les points prcdents, un SGBD qui prsente des failles importantes de scurit daccs
ou de fonctionnement et qui nest plus mis jour par lditeur constitue un problme
potentiel quaucune autre prcaution ne saurait combler.
Cette projection dans lavenir nest pas toujours vidente compte tenu du nombre de para-
mtres prendre en compte. Il est difficile de prdire quun constructeur ou un diteur ne

160 Cration de bases de donnes
disparatra pas dans les annes venir. Il est important denvisager ds la conception
lventualit dune migration vers un autre SGBD, ventuellement hberg par un autre
systme.
1.4 SAUVEGARDE, REDONDANCE ET ACCESSIBILIT DES DONNES
Sauvegarde des donnes
Des copies de sauvegarde des donnes contenues dans la base, mais aussi des mtadon-
nes (dictionnaire de donnes) du SGBD, doivent tre ralises rgulirement. Outre les
problmes de malveillance, un incendie ou une inondation peuvent rduire nant des
annes de travail. Dans la mesure du possible, les sauvegardes ne doivent pas tre stockes
dans le mme endroit que la machine. Lidal tant de disposer dune armoire de stockage
adapte qui soit ignifuge et situe dans un endroit labri des inondations. Si ce stockage
se trouve dans un lieu diffrent, cest encore mieux.
Compte tenu du volume des donnes utilis actuellement, la sauvegarde peut poser des
problmes de taille de support physique de stockage. cet effet, on utilise frquemment
des robots de sauvegarde spcialiss, manipulant des bandes que lon peut regrouper pour
former un espace de stockage suffisant. Les disques regroups dans un dispositif auto-
nome (type RAID) sont galement trs employs pour les sauvegardes en raison de leur
prix relativement abordable. Ils apportent de plus une certaine scurit lie des mcanis-
mes de redondance, qui leur assure un fonctionnement sans pertes de donnes en cas de
panne de lun des disques.
Redondance des donnes
Un procd plus efficace et plus sr consiste disposer de copies de la base en plusieurs
endroits gographiquement distincts. La plupart des SGBD sont capables deffectuer des
mises jour sur des copies de la base de donnes situes sur dautres machines via le
rseau. La frquence de ces mises jour va dpendre de celle de modification des donnes.
Cette mthode permet de plus damliorer la disponibilit des donnes :
Si lun des serveurs est inaccessible, un autre peut prendre le relais.
Il est possible ainsi de rpartir la charge sur plusieurs serveurs.
On obtient une redondance de machines et donc des donnes. Cela peut sembler para-
doxal dans la mesure o une grande partie de louvrage est consacre la suppression de
la redondance, mais le concept mis en uvre ici est diffrent. Les donnes sont simple-
ment dupliques pour se prmunir contre leur perte et augmenter leur disponibilit. Ce
dispositif est complexe grer dun point de vue du rseau et ncessite de disposer de plu-
sieurs hbergements gographiquement distants (voir figure 6.1).

161 Prservation des donnes
Chapitre
Figure 6.1
Redondance et
rpartition de
charge.
2 Limitations daccs au SGBD
Aprs avoir rsolu les problmes gnraux daccs la machine, abords dans la section
prcdente, il convient de restreindre laccs au SGBD. Ces restrictions concernent les
autorisations accordes ou non sur les diffrents lments que contient le SGBD, mais
aussi permettent de contrler laccs gnral au SGBD.
Ces oprations de gestion sont effectues typiquement par ladministrateur de la base de
donnes, qui dfinira des identifiants et leur affectera des droits, de manire totalement
indpendante du systme dexploitation. Ces informations seront stockes dans le dic-
tionnaire de donnes du SGBD. Il est possible daccder au SGBD, ventuellement dis-
tance, sans possder de compte sur la machine qui lhberge. Ladministrateur du SGBD
doit donc grer avec le plus grand soin ces identifiants, afin quils deviennent pas un
moyen de pntrer dans le systme dexploitation en cas de faille dans le SGBD.
2.1 SQL ET LA GESTION DES UTILISATEURS
Les instructions qui permettent daffecter les droits sont dfinies dans la norme SQL.
Comme pour les autres lments de la norme, les diteurs ne les ont pas toujours intgres
totalement dans leurs produits. linverse, ils ont souvent ajout des instructions qui ne
figurent pas dans la norme pour grer ces droits. Classiquement, pour protger une res-
source, on commence par en interdire laccs tous. Puis on dcrit ceux qui sont autoriss
lutiliser (utilisateurs). On associe ensuite chaque utilisateur un identifiant (mot de
passe) pour viter les emprunts didentit.
Dans le principe, SQL ne considre pas rellement la notion dutilisateur pour le SGBD tel
quon le conoit au sens dun systme dexploitation. On peut envisager lutilisation de
plusieurs identifiants associs au mme nom: cela correspondrait grossirement la pos-
sibilit dutiliser des mots de passe spcifiques selon la ressource. Il sagit donc dune logi-
que diffrente de celle qui consiste associer strictement un mot de passe un compte
et lui procurer des droits sur les ressources. La norme SQL considre que cest lobjet
Base originale
Hbergement 3
Recopie des donnes
Rpartition
&
redondance
Recopie des donnes
Recopie des donnes
Hbergement 3 Hbergement 2

162 Cration de bases de donnes
protger qui est au centre du processus : les droits dutilisation de cet objet sont ensuite
affects des couples de types (nom, identifiant).
Le SGBD stocke les informations suivantes pour chaque objet quil contient :
Le type de droit. Slection, cration, destruction
Lobjet sur lequel sappliquent les droits. Une base de donnes, une table, une vue
Le nom de lutilisateur.
Lidentifiant, au sens du mot de passe.
Le donneur des droits.
Compte tenu de la remarque prcdente, les diteurs intgrent souvent la notion plus clas-
sique dutilisateur dans un SGBD. Ce dernier permet en gnral de distribuer des autori-
sations un ensemble dutilisateurs qui constituent ainsi un groupe. Les tches de gestion
en sont facilites, mais les groupes, qui reprsentent lorganisation de lentreprise, sont
parfois complexes grer. Laffectation de droits une hirarchie de groupes et sous-grou-
pes peut relever du casse-tte.
Afin de rsoudre ce problme, on dispose dun autre modle de distribution des droits : le
rle. Celui-ci dsigne un assortiment de droits que lon dsire affecter un objet du
SGBD. Cest une vue inverse o les utilisateurs prennent le(s) rle(s) dont ils ont besoin
pour pouvoir travailler sur les objets du SGBD qui les concernent. Linstruction pour crer
un rle est la suivante :
CREATE ROLE consultation_seulement ;
Laffectation des droits un rle et la distribution de rles des utilisateurs sont prsentes
la section suivante. La gestion des rles, mme sils font partie de la norme SQL, nest pas
propose par tous les SGBD. Il en est de mme pour les groupes dutilisateurs ou tout sim-
plement de la notion dutilisateur qui nexiste pas toujours dans le SGBD.
En rsum, il ny a pas de rgle gnrale de gestion des autorisations de connexion au
SGBD. Linitiative en est laisse lditeur du SGBD. Cet aspect peut provoquer des soucis
lors de la migration vers un autre SGBD.
Remarque
En pratique, la plupart des SGBD intgrent une instruction pour crer un utilisateur et lui
associer un identifiant qui reste unique. Mme si elle nest pas dfinie rellement dans la
norme SQL, elle est frquemment de la forme :
CREATE USER <type de droit> IDENTIFIED BY <identifiant> ;
Cette instruction met jour le dictionnaire de donnes du SGBD. Ce dernier utilise les infor-
mations de lutilisateur pour authentifier la connexion au SGBD. L encore, le mode de con-
nexion dpend du SGBD utilis. Par extension, celui-ci fournira en gnral une instruction du
type DROP USER pour dtruire lutilisateur cr par la prcdente commande.
Comme les informations du dictionnaire de donnes sont le plus souvent stockes dans des
bases de donnes, on peut galement les manipuler avec des instructions SQL classiques de
types INSERT et DELETE. La spcificit de linstruction CREATE USER est de possder une ins-
truction de cryptage du mot de passe.

163 Prservation des donnes
Chapitre
2.2 SQL ET LA GESTION DES DROITS
Une fois que lutilisateur est connect au systme, il convient de grer son accs aux don-
nes. Une pratique courante pour les SGBD est que tout nouvel objet cr une base de
donnes par exemple est par dfaut inaccessible tous. Les droits sont distribus ensuite
des utilisateurs, des groupes ou des rles. Il existe ensuite une hirarchie entre les diff-
rents objets du SGBD : une table est comprise dans une base de donnes ; un champ est
compris dans une table, etc. Afin de simplifier la gestion, la plupart des SGBD permettent
laffectation de droits un objet associ tous les sous-objets qui constituent une branche
de la hirarchie.
Droits sur les objets du SGBD
Avec SQL, il est possible de spcifier des droits essentiellement sur les oprations de mani-
pulation de tables (ou de vues considres comme des tables) suivantes :
interrogation (SELECT) ;
insertion (INSERT) ;
mise jour (UPDATE) ;
destruction (DELETE) ;
rfrence une table (REFERENCE).
Les bnficiaires des droits sont les utilisateurs, les groupes ou les rles. Les droits sont
accords par ladministrateur du SGBD. Cependant, il est possible de transfrer la facult
de redistribuer ces droits un autre utilisateur avec loption WITH GRANT OPTION.
Linstruction GRANT permet de raliser lassociation des droits et du bnficiaire. Sa
forme gnrale est la suivante :
GRANT <type de droit>
ON <objet>
TO <nom utilisateur>
Voici un exemple dutilisation de GRANT.
Ladministrateur cre un utilisateur pastorius avec lidentifiant fender .
CREATE USER pastorius IDENTIFIED BY fender ;
Il lui donne tous les droits sur la base de donnes pastorius_base quil vient de crer.
Loption ALL PRIVILEGES sert transmettre lensemble des droits dont dispose le
donneur : en loccurrence, ladministrateur dispose de tous les droits sur tous les objets. Le
fait de prciser pastorius_base.* signifie tous les sous-objets prsents et venir contenus
dans la base de donnes pastorius_base
CREATE DATABASE pastorius_base;
GRANT ALL PRIVILEGES ON pastorius_base.* TO pastorius ;
Lutilisateur pastorius cre la table jaco dans la base de donnes pastorius_base et
donne laccs de type SELECT lutilisateur nhop pralablement cr.
USE pastorius_base;
CREATE TABLE jaco (NumMorceau INT PRIMARY KEY, Titre CHAR(50) ) ;
GRANT SELECT ON jaco TO nhop ;
On obtient un message derreur : lutilisateur pastorius na pas le droit de retransmettre
ses droits un autre utilisateur. Ladministrateur aurait d entrer la commande suivante :
GRANT ALL PRIVILEGES ON pastorius_base.* TO pastorius WITH GRANT OPTION ;
Cette fois, la commande de transmission de droits peut tre faite par lutilisateur pastorius

164 Cration de bases de donnes
GRANT SELECT ON jaco TO nhop ;
Lutilisateur nhop a le droit deffectuer toutes les oprations de consultation de la table
jaco de la base de donnes pastorius_base, il peut par exemple excuter la squence
suivante :
USE pastorius_base;
SELECT * FROM jaco;
Lorsque lon veut donner un droit tous les utilisateurs du SGBD, on utilise le mot cl
PUBLIC comme nom dutilisateur.
GRANT SELECT ON jaco TO PUBLIC;
Lensemble des utilisateurs peut alors interroger la table jaco de la base de donne
pastorius_base .On peut affiner ces permissions en ne les accordant que pour certains
champs de la table. On spcifie alors pour le type de droit le ou les champs sur lesquels ils
sappliquent.
GRANT UPDATE Adresse ON jaco TO nhop ;
Lutilisateur nhop a le droit de mettre jour le champ Adresse de la table jaco. Ce droit
peut lui avoir t accord par lutilisateur pastorius ou par ladministrateur du systme. Si
lon ne spcifie pas le champ comme on la fait prcdemment, le SGBD considre que le
droit concerne tous les champs de la table.
Droits associs aux rles
Linstruction GRANT permet galement de donner un rle un utilisateur ou un
ensemble dutilisateurs et sutilise alors de la manire suivante :
GRANT <rle>
TO <liste des noms dutilisateur spars par des virgules>
Voici un exemple dutilisation de GRANT avec les rles. On considre les rles suivants
sur la table jaco :
consultation : interrogation ;
utilisation : mise jour et insertion ;
gestion : destruction.
On cre les rles et on met jour les droits ncessaires.
CREATE ROLE consultation;
CREATE ROLE utilisation;
CREATE ROLE gestion;
GRANT SELECT ON jaco TO consultation;
GRANT UPDATE, INSERT ON jaco TO utilisation;
GRANT DELETE ON jaco TO gestion;
On affecte les rles aux utilisateurs.
GRANT consultation TO pastorius, nhop, miller ;
GRANT utilisation TO pastorius, miller ;
GRANT gestion TO pastorius;
Les utilisateurs qui ont plusieurs rles disposent des droits de tous les rles auxquels ils
appartiennent. Ainsi, lutilisateur miller possde les droits suivants sur la table :
INSERT, UPDATE, SELECT . Pour retirer les droits accords par linstruction GRANT,
on utilise linstruction REVOKE. Elle est de la forme suivante :
REVOKE <type de droit>
ON <objet>
FROM <nom utilisateur>

165 Prservation des donnes
Chapitre
Pour retirer les droits de lutilisateur nhop sur la table jaco, on procde comme suit :
REVOKE SELECT
ON jaco
FROM nhop ;
Les droits donns par plusieurs utilisateurs sont cumulatifs. Cela signifie que tous les
droits accords doivent tre retirs pour quun utilisateur ne puisse plus effectuer les op-
rations. Ce graphe de permissions nest pas toujours simple grer et devient rapide-
ment de taille exponentielle. Par consquent, les administrateurs des SGBD ont tendance
accorder parcimonieusement les possibilits de redistribuer des droits.
Pour aider ladministrateur, un bon SGBD procure une option de linstruction de destruc-
tion dun utilisateur, capable de dtruire galement tous les objets quil a crs. Linstruc-
tion DROP USER, non normalise par SQL comme on la vu prcdemment, sutilise avec
loption CASCADE pour dtruire les tables, les vues et autres que lutilisateur a crs.
2.3 UTILISATION DES VUES
La gestion des droits dans le SGBD, prsents la section prcdente, peut constituer un
vritable casse-tte lorsque le nombre dutilisateurs et dobjets augmente. En effet, les
droits sur les tables et surtout sur les champs peuvent tre dfinis par linstruction
GRANT, mais il devient vite fastidieux et particulirement difficile de les modifier. Un des
aspects de cette difficult est le manque de lisibilit de lensemble des permissions.
La notion de rle permet de factoriser , ou rassembler, un ensemble de droits sur un ou
plusieurs objets. Une approche complmentaire consiste dfinir plus finement les objets
sur lesquels on affecte les droits en se servant simplement des vues SQL. Celles-ci permet-
tent de cacher certaines donnes laide de critres de slection prcis, ce qui est
impossible raliser dune autre manire. De plus, les vues permettent de masquer aux
utilisateurs la complexit de la structure des donnes, leur fournissant ainsi une interface
plus commode avec la base de donnes.
Le mcanisme de cration des vues a t abord rapidement au chapitre 4. Les donnes ne
sont pas stockes et sont recalcules chaque utilisation de la vue. Une vue est le rsultat
dune instruction SQL SELECT: les possibilits de dfinition sont donc trs tendues
puisquil sagit du cur mme du fonctionnement de SQL. Enfin, il est galement possible
de mettre jour les donnes contenues dans les vues sous certaines conditions. Les per-
missions sur les vues sont ensuite accordes par les instructions de type GRANT utilises
prcdemment. Voici quelques exemples de vues qui recourent la base de donnes exem-
ple casse.
Vue utilisant une jointure simple
Le service marketing veut vrifier sil ny a pas de corrlations entre la couleur des vhicu-
les vendus et la ville dans laquelle rsident les clients qui les achtent. Il est inutile de four-
nir ce service la procdure pour obtenir ces informations qui ncessite de lier les trois
tables voiture, vente et client. On cre une vue qui contient uniquement la projection de
ces deux informations et qui slectionne les voitures vendues.
Remarque
Seul lutilisateur qui lui a donn ces droits peut les lui retirer. Dans notre cas, la commande prc-
dente doit tre lance par lutilisateur pastorius.

166 Cration de bases de donnes
CREATE VIEW couleur_ville (Couleur, Ville)
AS SELECT voiture.couleur, client.ville
FROM voiture JOIN vente JOIN client ON voiture.NumVoit=vente.Numvoit
AND client.NumAch = vente.Numach ;
On donne les droits de visualiser ces informations aux personnes du service marketing qui
sont les utilisateurs nhop et miller.
GRANT SELECT ON couleur_ville TO nhop, miller ;
Vue utilisant une jointure plus labore
On souhaite que tous les utilisateurs puissent consulter le catalogue des voitures non
encore vendues. Cette liste de voitures est accessible par une requte plus complexe que la
prcdente, de type jointure externe. Il sagit dun cas dutilisation dune vue, trs pratique
pour les utilisateurs qui nont pas connatre les notions avances de jointure externe.
CREATE VIEW catalogue (NumVoit, Marque, Type, Couleur)
AS SELECT voiture.NumVoit, voiture.Marque, voiture.Type, voiture.Couleur
FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.Numvoit
WHERE vente.Numvoit IS NULL;
On donne la permission lutilisateur PUBLIC, cest--dire tous les utilisateurs.
GRANT SELECT ON catalogue TO PUBLIC;
Vue avec possibilit de mise jour
Le service comptabilit doit pouvoir accder aux informations de vente et de clientle afin
de facturer et calculer le chiffre daffaires. En outre, ce service a besoin de mettre jour le
prix de vente.
CREATE VIEW journal_compta (Date_de_vente, Prix_de_vente, Nom_client, Ville_client)
AS SELECT vente.DateVent, vente.Prix, client.Nom, client.Ville
FROM vente JOIN client ON vente.NumAch=client.NumAch
WITH CHECK OPTION ;
Loption CHECK OPTION permet les mises jour des donnes au travers de la vue.
On donne les droits un rle que les utilisateurs pastorius et miller vont utiliser.
CREATE ROLE comptabilite ;
GRANT SELECT ON journal_compta TO comptabilite;
GRANT UPDATE Prix_de_vente ON journal_compta TO comptabilite;
On donne le rle comptabilit aux utilisateurs pastorius et miller.
GRANT comptabilite TO pastorius, miller
Lutilisation des vues permet de dfinir des objets dynamiques puisquune vue est le rsul-
tat dune requte et nest jamais stocke. Les vues sutilisent en complment du systme
gnral de droits prsent la section prcdente. Il sagit de la bonne solution pour viter
la complexit de description des permissions sur la totalit des champs. Comme pour le
reste de la norme SQL, tous les SGBD ne proposent pas les vues.
3 Transactions
Cette section prsente plusieurs outils procurs par les SGBD pour protger les oprations
effectues sur les donnes. Les incidents lis aux donnes dans un SGBD proviennent
essentiellement de laccs concurrent ces dernires par plusieurs utilisateurs. Ces pro-
blmes sont habituellement rsolus par les mcanismes associs aux transactions prsen-
tes dans cette section. Celles-ci permettent galement de rsoudre les pertes dues aux

167 Prservation des donnes
Chapitre
erreurs de manipulation ou celles lies aux erreurs dans le traitement des donnes, par
exemple en cas de panne matrielle.
3.1 ACCS CONCURRENT AUX DONNES
La section prcdente aborde la dfinition des accs et des permissions sur les diffrents
objets grs par le SGBD. Implicitement, cela signifie que plusieurs utilisateurs ou applica-
tions peuvent accder aux donnes en mme temps. De surcrot, la plupart des machines
sont connectes un rseau, ce qui augmente encore le nombre potentiel dutilisateurs
simultans.
Lecture(s) trange(s)
Laccs multiple en lecture ne pose pas habituellement de problmes, mais que se passe-t-
il lorsquun ou plusieurs utilisateurs dcident de modifier les mmes donnes au mme
moment ? On considre la squence dinstructions suivante applique la base de don-
nes casse . On suppose que tous les utilisateurs disposent de tous les droits sur tous les
objets (tables et champs) de cette base de donnes :
Lutilisateur pastorius consulte la liste des voitures non vendues.
Lutilisateur nhop enregistre la vente dune voiture.
Lutilisateur pastorius relance la mme requte et trouve un rsultat diffrent.
Lutilisateur nhop invalide la vente de cette voiture.
Lutilisateur pastorius pensant stre tromp relance la mme requte qui aboutit au
rsultat initial.
Pour trois excutions de la mme requte, lutilisateur pastorius va obtenir des rsultats
diffrents. On peut considrer la mme squence excute dans un ordre diffrent.
Lutilisateur pastorius consulte la liste des voitures non vendues.
Lutilisateur pastorius relance la requte et trouve le mme rsultat.
Lutilisateur nhop enregistre la vente dune voiture.
Lutilisateur nhop invalide la vente de cette voiture.
Lutilisateur pastorius relance la requte prcdente et retrouve le mme rsultat.
Comment dcider de lordre dans lequel excuter les instructions ? En pratique, le SGBD
ne dispose pas dlments de comparaison qui lui permettraient dordonner la srie dins-
tructions afin que cela passe inaperu comme dans la deuxime srie. On pourrait utiliser
ici le terme de lecture fantme pour qualifier les problmes rencontrs : une donne
apparat puis disparat.
Incohrence de rsultats
On peut imaginer une autre srie dinstructions qui ralisent des modifications de don-
nes effectues par diffrents utilisateurs. En raison de laugmentation des frais de struc-
ture, le service comptable a dcid dune augmentation gnrale du prix de vente de 5 %.
Afin que cette dernire passe inaperue et dans le cadre dune campagne de communica-
tion, le service marketing offre 100 euros de ristourne sur tout le catalogue pendant un
mois. Lutilisateur pastorius appartient au service comptable et lutilisateur nhop au ser-
vice marketing. Les vrifications sont effectues par lutilisateur miller de la direction
(voir figure 6.2).
Lutilisateur pastorius consulte le prix de vente de la voiture X.

168 Cration de bases de donnes
Lutilisateur nhop effectue la modification de promotion sans vrifier le prix de vente
(Prix_vente = Prix_vente 100).
Lutilisateur pastorius effectue la modification daugmentation (Prix_vente =
Prix_vente 1,05).
Lutilisateur miller vrifie le rsultat de lopration de modification du prix de vente et
constate une diffrence avec le rsultat attendu : le prix est gal (Prix_vente 100) 1,05,
alors quil sattendait un prix gal (Prix_vente 1,05) 100.
Figure 6.2
Droulement de
la squence
dinstructions de
mise jour du
prix de vente.
On obtient alors une incohrence due la squence de modification des donnes. Les
oprations effectues sur le champ Prix ne sont en effet pas commutatives. L encore, le
SGBD ne dispose pas dlments lui permettant dordonner correctement les oprations.
En revanche, pour certains prix de vente, la mise jour pourra tre correcte.
Il existe bien dautres types dincohrences qui peuvent tre provoques par laccs con-
current aux donnes. On peut citer le cas des anomalies de lecture : Deux lectures suc-
cessives ne donnent pas le mme rsultat. Cela survient lorsque la modification dune
donne est effectue par un processus concurrent entre deux lectures successives. Le
SGBD traite naturellement les requtes de manire squentielle, dans lordre de leur arri-
ve. Si lon augmente le nombre dutilisateurs, ce type de problmes peut videmment se
multiplier.
Verrous
On a donc besoin de disposer dun mcanisme qui garantisse une certaine exclusivit
sur les donnes lors des oprations de mise jour. Un tel mcanisme existe depuis long-
temps en informatique pour rsoudre ce problme : il sagit des verrous. Lide est simple :
on bloque une ressource pour effectuer les oprations et on la libre ds que les oprations
sont effectues. Cette mthode semble rsoudre le problme ; elle prsente cependant
quelques piges et doit tre utilise avec prudence. En effet, on peut rapidement parvenir
une situation de blocage que lon nomme treinte fatale (deadlock en anglais) ou parfois
Pastorius : consultation du prix de vente 9 700
Prix de vente
Nhop : promotion et modification du prix
de vente (Prix = Prix 100)
9 600
Prix de vente
Pastorius : augmentation du prix de vente
10 185
Prix de vente
Miller : vrification du prix de vente
10 185
Prix de vente
10 085
Prix de vente
attendu
constat

169 Prservation des donnes
Chapitre
interblocage. Pour illustrer cette situation, on suppose que deux vendeurs veulent mettre
jour la base de donnes casse :
Lutilisateur pastorius veut insrer une vente de voiture dans la table vente et cons-
tate cette occasion une erreur sur la couleur dans la table voiture quil veut modifier.
Lutilisateur miller veut insrer la fois une nouvelle voiture dans la table voiture et
la mention de sa vente dans la table vente.
La squence dinstruction peut tre la suivante :
Lutilisateur pastorius pose un verrou sur la table vente.
Lutilisateur miller pose un verrou sur la table voiture.
Lutilisateur pastorius a termin la mise jour de vente et veut raliser celle de voi-
ture mais la table voiture est verrouille par miller.
Lutilisateur miller a termin la mise jour de voiture et veut procder celle de
vente mais la table vente est verrouille par pastorius.
On parvient une situation o les deux utilisateurs attendent que lautre libre la res-
source pour continuer. videmment, cest une attente infinie qui se profile pour chacun.
Dautres phnomnes de blocage peuvent survenir dans lutilisation des verrous. On parle
parfois dans ce cas de famine. Voici un exemple illustrant cette possibilit.
Lutilisation classique des verrous pour protger laccs une ressource est la suivante
(algorithme des lecteurs-rdacteurs ) :
Tous les lecteurs peuvent lire en mme temps.
Si un rdacteur veut crire, aucun lecteur ne doit plus utiliser la donne.
Si un rdacteur est en train dcrire, aucun lecteur ne peut lire la donne et aucun autre
rdacteur ne peut y accder (accs exclusif).
Sil existe un grand nombre de lecteurs qui se succdent en lecture sur la donne, lattente
pour un rdacteur qui voudrait la modifier peut alors devenir quasi infinie.
Laisser la gestion des verrous un utilisateur est donc dlicat et peut conduire des bloca-
ges du systme. Les SGBD performants disposent doutils capables de dtecter et rsoudre
ces phnomnes, voire de les prvenir le cas chant. Les algorithmes utiliss cet effet
dpassent le cadre de cet ouvrage.
3.2 MCANISME DES TRANSACTIONS
Pour rsoudre les problmes daccs concurrents vus prcdemment, les SGBD proposent
aux utilisateurs un outil que lon nomme une transaction. Lide est de considrer un
ensemble dinstructions comme une seule instruction. Lensemble dinstructions est dit
unitaire ou atomique.
Proprits des transactions
La notion datomicit peut tre dcrite en ces termes :
Soit le SGBD est capable dexcuter toutes les instructions qui composent une transac-
tion et il effectue les mises jour provoques par ces instructions.
Soit il ny parvient pas et il remet la base de donnes dans ltat cohrent prcdent le
dbut de lexcution des instructions de la transaction.

170 Cration de bases de donnes
Les proprits que doivent vrifier les transactions sont rsumes par le terme ACID:
Atomicit. Une transaction est atomique : elle est excute entirement ou abandonne.
Cohrence. La transaction doit se faire dun tat cohrent de la base vers un autre tat
cohrent.
Isolement. Des transactions simultanes ne doivent pas interfrer entre elles.
Durabilit. La transaction a des effets permanents mme en cas de panne.
Les qualits des transactions sont un argument de vente pour un SGBD. Il est en effet
complexe de trouver un compromis entre la scurit et les performances. Bien quil
sagisse dun mcanisme prouv qui existe depuis fort longtemps, les transactions ainsi
que les techniques de gestion des accs concurrentiels restent des sujets de recherches
importants dans les laboratoires. Les transactions font partie de la norme SQL.
Ralisation des transactions dans les SGBD
Pour mettre en uvre les transactions, le SGBD doit offrir lexclusivit daccs aux don-
nes ainsi que la possibilit dannuler des modifications effectues. Afin de garantir laccs
exclusif aux donnes, le SGBD utilise les verrous vus prcdemment. Ces mcanismes sont
associs des algorithmes de protection sophistiqus afin de prvenir les problmes des
mthodes de verrouillage.
La possibilit de revenir en arrire repose sur lutilisation dun journal de transactions.
Pour ce faire, le SGBD garde une trace de toutes les requtes de la transaction et des don-
nes qui sont modifies par ces instructions. Ce mcanisme est identique celui qui est
utilis pour les systmes de fichiers modernes dans les systmes dexploitation. Puisque la
plupart des critures se font en mmoire pour gagner du temps, le systme de fichiers nest
pas forcment cohrent en cas de panne de courant qui entrane la perte de toutes les
informations se trouvant en mmoire. On conserve donc un journal de lensemble des lec-
tures et critures afin de pouvoir reconstituer un systme cohrent. En utilisant ce journal,
partir dun tat courant du systme, on est capable de rexcuter les instructions qui
nont pu ltre effectivement ou on revient en arrire si ce nest pas possible.
La description faite ci-dessus est videmment simpliste par rapport la ralit plus com-
plexe des SGBD. Les mthodes de verrouillage implmentes dans ces derniers sont bien
plus labores que celles prsentes ici. Il en est de mme pour les mcanismes de journa-
lisation qui disposent de plusieurs niveaux.
Diffrents niveaux de transaction
La norme SQL fixe plusieurs degrs de qualit pour les transactions : on parle de niveaux
disolation. Cest--dire quune transaction pourra tre rendue plus ou moins permable
aux autres transactions. Les niveaux standard sont les suivants :
Remarque
Les transactions permettent de rsoudre les problmes lis aux accs concurrentiels, mais gale-
ment de traiter le cas de la reprise en cas de panne. Le SGBD est ainsi capable de remettre la
base de donnes dans ltat cohrent o elle se trouvait avant le dbut de la transaction qui a
chou pour cause de panne. Les transactions sont galement employes pour annuler des
erreurs de traitement ventuelles. En effet, grce ce mcanisme, on peut revenir ltat initial
dans lequel se trouvait la base de donnes avant le dbut de la srie de mauvaise(s) manipula-
tion(s) sur la base de donnes. Il sagit certainement de lutilisation principale des transactions.

171 Prservation des donnes
Chapitre
0, READ UNCOMMITED. Lecture de donnes non valides en cours de transaction
(niveau le plus bas).
1, READ COMMITED. Modification des donnes possible en cours de transaction.
2, REPEATABLE READ. Insertion de nouveaux enregistrements possible en cours de
transaction.
3, SERIALIZABLE. Toutes les transactions sont traites en srie (niveau le plus sr).
Pourquoi prvoir plusieurs niveaux, puisque le but est dobtenir une scurit maximale ?
La scurit a un cot en matire de performances et, dans certains contextes, il nest pas
ncessaire de demander au SGBD de traiter une requte avec le niveau maximal dexclusi-
vit. Il est clair que, pour une simple opration de lecture, le niveau 1 qui garantit limpos-
sibilit de lire des donnes non valides peut tre suffisant.
Syntaxe SQL des transactions
Linstruction pour dbuter une transaction est START TRANSACTION. La transaction
prendra fin par lune des instructions suivantes :
COMMIT. Les instructions effectues depuis START TRANSACTION sont valides.
ROLLBACK. Les instructions effectues depuis START TRANSACTION sont annu-
les.
Voici un exemple dinsertion et de mise jour dans la base de donnes casse que lon
annule ensuite :
#Dmarrage de la transaction
START TRANSACTION ;
#Insertion dun tuple dans la table client
INSERT INTO client VALUES (6,'Laetitia',34,'Paris','F');
#Mise jour des donnes de prix (augmentation de 5 %)
UPDATE vente SET Prix=Prix*1.05 ;
#Annulation des modifications faites depuis START TRANSACTION
ROLLBACK ;
Voici un exemple de destruction dans la table client de la base de donnes casse que lon
valide ensuite :
#Dmarrage de la transaction
START TRANSACTION ;
#Destruction des tuples dont le champ Ville vaut Paris dans la table client
DELETE FROM client WHERE Ville=Paris;
#Validation des modifications faites depuis START TRANSACTION
COMMIT ;
On peut choisir le niveau disolation au moment o lon dmarre la transaction. Dans
lexemple suivant, on fixe le niveau maximal de scurit.
START TRANSACTION
ISOLATION LEVEL SERIALIZABLE ;

Remarque
Les SGBD ne fonctionnent pas par dfaut au mme niveau disolation. Il est prudent de vrifier
dans la documentation quel niveau se trouve par dfaut le SGBD que lon utilise. En effet, cer-
tains SGBD trs rpandus fonctionnent par dfaut au niveau 1 ! Ce peut tre suffisant pour certai-
nes applications, encore faut-il en tre bien conscient. Le choix du niveau est motiv par des
arguments plus commerciaux que techniques : le SGBD est plus rapide en utilisant un niveau
moins lev.

172 Cration de bases de donnes
Points de retour dans les transactions
Les instructions contenues dans une transaction sont considres par le SGBD comme
unitaires , cest--dire quelles sont excutes dun seul bloc ou ne sont pas excutes. Lins-
truction ROLLBACK annule toutes les instructions effectues depuis linstruction START
TRANSACTION. Cependant, il est possible de diviser cet ensemble dinstructions en sous-
ensembles par la dfinition de points de retour utiliss par linstruction ROLLBACK. Au
lieu dannuler les instructions excutes depuis START TRANSACTION, on revient ltat
de la base de donnes depuis le point dfini par linstruction SAVEPOINT (voir figure 6.3).
#Dmarrage de la transaction
START TRANSACTION ;
#Insertion dun tuple dans la table client
INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F');
# Dfinition dun point de retour que lon nomme UN
SAVEPOINT UN
#Mise jour des donnes de prix (augmentation de 5 %)
UPDATE vente SET Prix=Prix*1.05 ;
#Destruction des tuples dont le champ Ville vaut Paris dans la table client
DELETE FROM client WHERE Ville=Paris;
#Annulation des modifications faites depuis le point UN
ROLLBACK TO UN ;
Une diffrence essentielle par rapport linstruction ROLLBACK vue prcdemment est
que, dans ce cas, la transaction nest pas termine. Un autre ROLLBACK reviendrait
ltat de la base de donnes avant lexcution de linstruction START TRANSACTION.
Figure 6.3
Point de retour
dans une
transaction.
Le mcanisme des points de retour est trs utile pour prvenir les cas de mauvaise mani-
pulation de donnes. On combine ainsi la possibilit deffectuer les modifications dans
une seule transaction avec celle de ne pas annuler toutes les modifications. Certaines
dentre elles prennent en effet un temps considrable.
Remarque
La plupart des SGBD considrent que chaque instruction SQL est en soi une transaction qui est
automatiquement valide (mode AUTO COMMIT). Certains fonctionnent en crant une nouvelle
transaction lors de chaque connexion au SGBD, ce qui permet dannuler le cas chant toutes les
oprations effectues depuis la connexion. Dans le doute, il est donc prfrable de spcifier expli-
citement le dbut de toute transaction par une instruction START TRANSACTION.
START TRANSACTION ;
INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F');
SAVEPOINT UN
UPDATE vente SET Prix=Prix*1.05 ;
DELETE FROM client WHERE Ville=Paris;
ROLLBACK TO UN ;

ROLLBACK

173 Prservation des donnes
Chapitre
Le systme des transactions gres par le SGBD est un outil indispensable pour prendre en
compte les problmes cits prcdemment : la concurrence daccs, les erreurs et les repri-
ses aprs les pannes. Comme on la vu dans cette section, la ralisation des transactions fait
appel des compromis entre la rapidit et la scurit. Tous les SGBD neffectuent pas les
mmes choix et prsentent des degrs diffrents de fiabilit. Les cas dinterblocage peuvent
tre frquents dans certains SGBD pourtant trs utiliss. Dautres, galement fort rpan-
dus, ne proposent mme pas les transactions sur leurs tables en standard .
4 Triggers
Les triggers ou dclencheurs ont un objectif diffrent des outils tels que les transactions.
Ils servent excuter des contrles complmentaires personnaliss au moment des opra-
tions dajout, de suppression et mise jour des donnes. Ils sont utiles galement pour
effectuer un formatage spcifique des donnes. Pratiquement, un trigger est un ensemble
dinstructions SQL, dfinies par lutilisateur, qui seront dclenches lors dune action
dajout, de suppression ou de mise jour de donnes. Il sapplique donc un objet de type
table. On peut choisir dexcuter un trigger avant ou aprs une instruction de mise jour.
Les donnes manipules par le trigger sont stockes dans des tables temporaires que lon
dsigne dans le code du trigger par les termes :
NEW valeurs, aprs lexcution de lopration de mise jour ;
OLD valeurs, avant lexcution de lopration de mise jour.
4.1 SYNTAXE GNRALE POUR CRER ET DTRUIRE UN TRIGGER
Linstruction, normalise par la norme SQL, est de la forme gnrale suivante :
CREATE TRIGGER Nom du trigger
Moment o le trigger est excut
Opration concerne
ON Nom de la table
FOR EACH ROW(ou STATEMENT)
BEGIN
Instructions
END
Le moment peut prendre les valeurs BEFORE ou AFTER.
Les oprations concernes sont INSERT, UPDATE et DELETE.
La diffrence entre ROW et STATEMENT est que lon excute les instructions pour
chaque ligne ou pour toute la table.
Pour dtruire un trigger, on utilise linstruction DROP et on spcifie le nom du trigger que
lon veut dtruire.
DROP TRIGGER conversion
Comme toujours, la syntaxe peut tre lgrement diffrente suivant le SGBD employ.

174 Cration de bases de donnes
4.2 EXEMPLES DUTILISATION DUN TRIGGER
Contrle de la forme du contenu des champs
Pour le formatage, on veut imposer que les noms dune ville dans la table client soient
transforms en majuscules avant dtre insrs. On fait rfrence ici la nouvelle table
NEW que lon modifie avant linsertion.
CREATE TRIGGER ville_majuscule BEFORE INSERT ON client FOR EACH ROW
BEGIN
SET NEW.Ville=UPPER(NEW.Ville) ;
END
Modification automatique du contenu dun champ
Les triggers permettent, par exemple, de complter le mcanisme dintgrit rfrentielle par
des contrles plus fins et la dfinition des actions associes ces derniers. On considre lexem-
ple de la base de donnes casse. Si le prix de vente est suprieur 40 000 lors dune insertion de
donnes dans la table vente, on suppose que la personne a saisi par erreur le prix en francs et
non pas en euros. On effectue automatiquement la conversion des francs en euros. L encore,
on modifie les donnes de la table NEW qui contient celles que lon va insrer.
CREATE TRIGGER conversion BEFORE INSERT ON vente FOR EACH ROW
BEGIN
IF New.Prix> 40000
THEN SET
NEW.Prix=NEW.Prix/6.5596 ;
END IF;
END
Mise jour dautres tables
On peut galement provoquer la mise jour dautres tables laide dun trigger. Si lon
ajoute un champ compte la table client qui reprsente ltat du solde de son compte vis-
-vis de lentreprise, on veut pouvoir mettre jour automatiquement le champ compte de
lacheteur lors de linsertion dune opration de vente. cette occasion, on soustrait le prix
de vente de la voiture du montant du compte du client. Cest la seule manire de raliser
cette opration de modification dune autre table lors dune simple insertion.
# Ajout dun champ compte la table client
ALTER TABLE client ADD COLUMN compte INT ;
# Cration du trigger
CREATE TRIGGER compte BEFORE INSERT ON vente FOR EACH ROW
BEGIN
UPDATE client
SET client.Compte=client.Compte-NEW.Prix
WHERE client.NumAch=New.NumAch ;
END
# Ajout dune vente dans la table vente
INSERT INTO vente VALUES (6, '2005-03-01',50000,2,5)
Le compte du client de numro NumAch gal 2 sera automatiquement diminu de la
somme de 50000.
Un trigger apporte de la souplesse et de la personnalisation dans la dfinition des con-
traintes que lon associe aux tables. Pour ce faire, il dclenche lexcution dun morceau de
code spcifique associ un vnement de mise jour de la table. Il est parfois possible de
raliser les oprations dune autre de manire plus complexe. Du point de vue de la scu-
rit des donnes, le code associ au trigger sexcute sur le serveur sans interaction avec le
client. On rduit ainsi les risques derreur lis aux changes entre le client et le serveur.

175 Prservation des donnes
Chapitre
Rsum
Ce chapitre expose les diffrentes dispositions que lon doit prendre afin de prvenir lalt-
ration ou la perte des donnes. On a prsent tout dabord les prcautions de premier
niveau quil ne faut pas ngliger. Elles concernent essentiellement lenvironnement dans
lequel se trouve le SGBD : la machine munie de son systme dexploitation, les locaux
informatiques et enfin le rseau sur lequel elle est connecte. Un autre point important
concerne la sauvegarde et la duplication des donnes, de faon garantir laccessibilit
ces dernires mme en cas de sinistre.
Une fois lenvironnement du SGBD scuris, on a abord les permissions et les restrictions
qui sont gres directement par le SGBD. Il sagit de la partie prise en charge par ladmi-
nistrateur du SGBD qui dfinit les droits sur les diffrents objets de la base de donnes.
Cette gestion devient rapidement complexe : on utilise en complment les vues SQL pour
dcrire plus finement les objets sur lesquels on distribue les droits.
Les prcautions prcdentes mises en uvre, on se trouve confront au problme de
laccs concurrent aux donnes. La solution consiste en lutilisation de verrous. Leur
mcanisme est trs dlicat grer et lon prfre laisser ce soin au SGBD. Ce dernier pro-
cure de surcrot un mcanisme de journalisation des instructions capable de remettre
la base de donnes dans ltat cohrent prcdant la squence dinstructions. Cette combi-
naison des mcanismes daccs exclusif associs la journalisation se nomme les transac-
tions. Enfin, les triggers (ou dclencheurs en franais) sont trs utiles pour complter la
panoplie doutils qui assurent le contrle des donnes dune base de donnes.

176 Cration de bases de donnes
Exercices
EXERCICE 1 SCURIT DE BASE
La dcision doit reposer sur la prise en considration de plusieurs points ; la liste ci-des-
sous nest pas exhaustive.
Aspects techniques. Lune des premires proccupations doit tre dauditer le type de
machine ainsi que le systme dexploitation sur lequel sera hberg le SGBD. Dautre part,
les SGBD sont gourmands en ressources de calcul et de stockage et il faut donc sassurer
que lon disposera du ncessaire dans ces domaines.
On peut supposer que la machine sera connecte un rseau quil faut auditer galement.
De quel type de connexion dispose lhbergeur, quels matriels de protection contre les
intrusions utilise-t-il ? Le minimum est de disposer dun dispositif de filtrage pour se pro-
tger des intrusions lies au rseau. Un plus est de disposer de deux fournisseurs daccs,
lun prenant le relais en cas de faille de lautre.
Enfin, quel matriel de sauvegarde peut-on utiliser, et de quelle taille de stockage dispose-
t-on ? Une sauvegarde quotidienne est indispensable pour une base de donnes standard,
cest--dire sur laquelle les mises jours sont raisonnablement frquentes. En cas de mises
jour intensives, on peut prvoir de conserver plusieurs versions de la base sauvegarde.
Aspects humains. Les machines et les rseaux aussi performants soient-ils sont grs
avant tout par des tres humains. Il est donc essentiel de savoir combien de personnes
assurent cette mission, et de quelle faon ; didentifier la politique de scurit gnrale :
accs physique aux machines, protection contre les intrusions rseau et le suivi des inci-
dents, mise jour des machines, gestion des comptes
EXERCICE 2 DISPONIBILIT DES DONNES
La haute disponibilit ncessite que laccs aux donnes soit dune part permanent et
dautre part performant. Afin de garantir que les donnes soient disponibles en perma-
nence, on doit effectuer des copies intervalles rguliers des donnes qui proviennent
dune base de donnes primaire vers des bases de sauvegarde secondaires . En cas de
panne du primaire, on peut basculer rapidement vers lun des secondaires. Lidal est de
disposer de plusieurs secondaires dans des lieux gographiquement loigns, situs sur des
rseaux (informatiques) diffrents.
Disposer en outre dun accs performant suppose que lon utilise galement les secondai-
res pour faire de la rpartition de charge. Le systme de rpartition choisi doit tenir
Quelles sont les vrifications de base indispensables avant de faire hberger un SGBD ser-
veur de bases de donnes par une structure ?
Quel type darchitecture permet de garantir en mme temps la haute disponibilit des
donnes et de disposer de sauvegarde ? Quels sont les inconvnients de ce systme ?

177 Prservation des donnes
E
x
e
r
c
i
c
e
s
Chapitre
compte de la proximit , au sens informatique, du serveur par rapport au client qui
effectue la requte. Cette proximit peut tre calcule en termes de distance combien
de nuds du rseau sont traverss ? mais galement en termes de charge des branches du
rseau. Il existe des outils capables de tenir jour en permanence ce genre dinformations,
mais ils sont assez complexes grer. Lors du choix de la machine vers laquelle on va redi-
riger la demande, on doit prendre en considration galement sa charge et donc son apti-
tude rpondre rapidement.
Les inconvnients dune solution complte de ce type sont vidents. Les applications de
rpartition de charge sur un rseau standard sont dj complexes grer ; on imagine bien
quelles le sont dautant plus lorsque lon passe une chelle suprieure. Un autre incon-
vnient est la difficult de maintenir des copies des donnes jour par rapport la base
primaire. Si les mises jour sont trs frquentes, il devient difficile de disposer des mmes
donnes sur tous les secondaires.
Une autre solution plus facile grer pour rpartir naturellement la charge entre les
serveurs consiste rpartir les donnes entre ces serveurs. Ainsi, cette opration se fait par
larchitecture mme de la base de donnes qui est dite rpartie . En revanche, cette solu-
tion ne rsout pas le problme de la recopie des donnes. Si lun des serveurs tombe en
panne, il nexiste pas, contrairement au systme prcdent, de mcanisme automatique
pour le remplacer. On peut envisager des variantes qui panachent les deux systmes : par
exemple, on peut mettre en place un serveur matre qui recopie une partie des donnes sur
les secondaires. Cette problmatique gnrale est illustre par les grands moteurs de
recherche, ou encore les serveurs de vido qui utilisent plusieurs milliers de serveurs
rpartis sur le rseau Internet.
EXERCICE 3 NIVEAUX DUTILISATION DUNE BASE DE DONNES
La notion dutilisateur ne reprsente pas forcment une personne physique ; il sagit le
plus souvent dapplications qui disposent ou non de droits sur certaines donnes. En pre-
mire approche, on peut distinguer trois grandes catgories dutilisateurs de la base de
donnes.
Les clients peuvent consulter les informations les concernant ainsi que le catalogue des
pizzas disponibles avec leur prix et leur composition.
Lactivit courante, qui par consquent va gnrer les mises jour les plus frquentes,
est la commande de pizzas. Les utilisateurs concerns sont les employs qui mettent
jour les donnes de la table commande, mais galement celles de la table client pour
crer de nouveaux clients le cas chant. Ils ont accs en lecture toutes les donnes des
autres tables.
Enfin, les gestionnaires de lactivit doivent pouvoir mettre jour toutes les informa-
tions de gestion : en particulier, celles sur les pizzas, les clients, les livreurs et les voitures
utilises. En revanche, on peut considrer quils nont pas besoin de modifier les infor-
mations concernant les commandes, mais quils doivent pouvoir y accder en lecture.
Lors de la conception dune base de donnes, on doit envisager ds le dbut les diffrentes
catgories dutilisateurs qui vont lutiliser. On considre lexemple complet livraison de
pizzas trait au chapitre 5, Du langage parl SQL . Quels niveaux dutilisation des
donnes doit-on prvoir ? On se limite aux grandes catgories.

178 Cration de bases de donnes
On rsume dans un tableau (voir tableau 6.1) les droits par catgories sur les tables (par
criture , on entend mise jour, insertion et destruction).
Figure 6.1 : Synthse des droits par catgories de la base de donnes pizza
EXERCICE 4 GESTION DES DROITS
Si le SGBD le supporte, la solution la plus lgante est dutiliser les rles. On cre un rle
par catgorie et on lui affecte les permissions. Il suffira ensuite de donner ce rle aux utili-
sateurs ou aux applications concernes. Dans cet exemple, on a surtout cherch mettre
en vidence tous les droits distribuer. Il existe des notations plus concises.
Cration du rle client et distribution des droits. CREATE ROLE client;
GRANT SELECT ON pizza TO client;
GRANT SELECT ON compose TO client;
GRANT SELECT ON ingrdient TO client;
GRANT SELECT ON tarification TO client ;
GRANT SELECT ON client TO client;
Cration du rle employe et distribution des droits. CREATE ROLE employe;
GRANT SELECT ON pizza TO employe ;
GRANT SELECT ON compose TO employe ;
GRANT SELECT ON ingrdient TO employe ;
GRANT SELECT ON tarification TO employe ;
GRANT SELECT ON vehicule TO employe ;
GRANT SELECT ON livreur TO employe ;
GRANT SELECT ON client TO employe ;
GRANT UPDATE ON client TO employe;
GRANT DELETE ON client TO employe;
GRANT INSERT ON client TO employe;
GRANT SELECT ON commande TO employe ;
GRANT UPDATE ON commande TO employe;
GRANT DELETE ON commande TO employe;
GRANT INSERT ON commande TO employe;
Cration du rle gestionnaire et distribution des droits. CREATE ROLE gestionnaire;
GRANT SELECT ON commande TO gestionnaire ;
GRANT SELECT ON client TO gestionnaire;
GRANT UPDATE ON client TO gestionnaire;
GRANT DELETE ON client TO gestionnaire;
GRANT INSERT ON client TO gestionnaire;
GRANT SELECT ON livreur TO gestionnaire;
GRANT UPDATE ON livreur TO gestionnaire;
commande pizza compose ingredient tarification client livreur vehicule
Client X Lecture Lecture Lecture Lecture Lecture X X
Employ
Lecture/
criture
Lecture Lecture Lecture Lecture Lecture Lecture Lecture
Gestion-
naire
Lecture
Lecture/
criture
Lecture/
criture
Lecture/
criture
Lecture/
criture
Lecture/
criture
Lecture/
criture
Lecture/
criture
Comment reprsenter pratiquement les catgories identifies lexercice prcdent dans
un SGBD ? crivez les instructions permettant de le faire.

179 Prservation des donnes
E
x
e
r
c
i
c
e
s
Chapitre
GRANT DELETE ON livreur TO gestionnaire;
GRANT INSERT ON livreur TO gestionnaire;
GRANT SELECT ON vehicule TO gestionnaire;
GRANT UPDATE ON vehicule TO gestionnaire;
GRANT DELETE ON vehicule TO gestionnaire;
GRANT INSERT ON vehicule TO gestionnaire;
GRANT SELECT ON tarification TO gestionnaire;
GRANT UPDATE ON tarification TO gestionnaire;
GRANT DELETE ON tarification TO gestionnaire;
GRANT INSERT ON tarification TO gestionnaire;
GRANT SELECT ON ingrdient TO gestionnaire;
GRANT UPDATE ON ingrdient TO gestionnaire;
GRANT DELETE ON ingrdient TO gestionnaire;
GRANT INSERT ON ingrdient TO gestionnaire;
GRANT SELECT ON compose TO gestionnaire;
GRANT UPDATE ON compose TO gestionnaire;
GRANT DELETE ON compose TO gestionnaire;
GRANT INSERT ON compose TO gestionnaire;
GRANT SELECT ON pizza TO gestionnaire;
GRANT UPDATE ON pizza TO gestionnaire;
GRANT DELETE ON pizza TO gestionnaire;
GRANT INSERT ON pizza TO gestionnaire;
On distribue les rles des utilisateurs :
swallow et clarke sont des clients.
GRANT clientTO swallow, clarke;
gomez et pattitucci sont des employs.
GRANT employe TO gomez, pattitucci;
pastorius est un gestionnaire.
GRANT gestionnaire TO pastorius;
EXERCICE 5 VUES
On remarque que les informations dont ces utilisateurs ont besoin ne sont pas directe-
ment disponibles dans une table ni mme dans un champ particulier. Il sagit de rsultats
de calculs sur lensemble de la base de donnes. Le moyen le plus simple pour grer ces
besoins est de crer des vues pour chaque catgorie dutilisateurs, auxquels on distribuera
les permissions sur ces vues. Il est videmment possible de crer des rles dutilisateurs
comme dans lexercice prcdent, ce qui est plus lgant mais nest pas support par tous
les SGBD.
De nouveaux utilisateurs aux besoins plus spcifiques vont utiliser la base de donnes de
livraison de pizzas vue au chapitre 5, Du langage parl SQL .
Le service comptabilit doit rmunrer les livreurs : il a besoin de connatre le nom-
bre de commandes livres par chacun deux.
Le service du personnel effectue un suivi des livreurs : il a besoin de connatre le
nombre de retards de chacun, mais galement le nombre de commandes livres.
Un laboratoire de recherche en sociologie effectue des tudes sur la clientle, spci-
fiquement sur la relation entre les ingrdients des pizzas achetes et ladresse des
clients.
Ces utilisateurs ne doivent accder quaux champs dont ils ont strictement besoin.

180 Cration de bases de donnes
Service comptabilit. Le besoin est uniquement davoir accs aux nombres de com-
mandes livres pour chaque livreur. Il sagit du rsultat dun calcul classique sur un agr-
gat. On affiche uniquement les informations du livreur (code et nom) et le rsultat du
calcul.
SELECT L.CodeLivreur, L.NomLivreur, COUNT(*) AS Nombre_Livraison
FROM commande C JOIN livreur L ON C.CodeLivreur=L.CodeLivreur
GROUP BY C.CodeLivreur
ORDER BY L.NomLivreur;
On cre une vue partir de cette requte :
CREATE VIEW commande_livreur AS
SELECT L.CodeLivreur, L.NomLivreur, COUNT(*) AS Nombre_Livraison
FROM commande C JOIN livreur L ON C.CodeLivreur=L.CodeLivreur
GROUP BY C.CodeLivreur
ORDER BY L.NomLivreur;
On distribue les droits de lecture lutilisateur comptabilit
GRANT SELECT ON commande_livreur TO comptabilite;
Service du personnel. Par un raisonnement identique, on obtiendrait la requte qui
permet de calculer le nombre de retards cumuls par livreur.
CREATE VIEW retard_livreur AS
SELECT L.CodeLivreur, L.NomLivreur, COUNT(*) AS Nombre_Retard
FROM commande C JOIN livreur L ON C.CodeLivreur=L.CodeLivreur
WHERE C.Retard=O
GROUP BY C.CodeLivreur
ORDER BY L.NomLivreur;
On distribue les droits de lecture lutilisateur personnel.
GRANT SELECT ON retard_livreur TO personnel;
Le service du personnel a besoin galement dutiliser la prcdente vue :
GRANT SELECT ON commande_livreur TO personnel;
Pour tre complet, on pourrait crer une vue rcapitulative qui permette de visualiser les
commandes livres et les retards dans une seule table. Ce nest pas le moyen le plus simple,
mais cela rend le processus plus lisible.
CREATE VIEW retard_commande_livreur AS
SELECT R.CodeLivreur, R.NomLivreur, C.Nombre_Livraison, R.Nombre_Retard
FROM retard_livreur R JOIN commande_livreur C ON R.CodeLivreur = C.CodeLivreur
ORDER BY R.NomLivreur;
On distribue les droits de lecture sur cette vue lutilisateur personnel:
GRANT SELECT ON retard_commande_livreur TO personnel;
Laboratoire de sociologie. Le laboratoire de recherche doit pouvoir accder au contenu
de deux champs sans calcul ni mise en forme. En revanche, on ne donne pas la possibilit
ces utilisateurs extrieurs de connatre la structure interne des donnes et davoir accs
dautres champs. On cre une vue qui est le rsultat de la jointure entre les tables com-
mande, client, pizza, compose, ingredient.
CREATE VIEW adresse_ingredient AS
SELECT CL.Adresse, I.NomIngre
FROM commande C JOIN client CL JOIN pizza P JOIN compose CO JOIN ingredient I
ON C.NumClient=CL.NumClient AND C.NomPizza=P.NomPizza
AND P.NomPizza = CO.NomPizza AND CO.NumIngre=I.NumIngre
;

181 Prservation des donnes
E
x
e
r
c
i
c
e
s
Chapitre
On distribue les droits de lecture sur cette vue lutilisateur sociologue.
GRANT SELECT ON adresse_ingredient TO sociologue;
On se trouve dans les cas typiques dutilisation de vues pour dfinir des objets qui nexis-
tent pas ltat naturel dans la base de donnes. La distribution des droits en est
dautant simplifie. De plus, lensemble est volutif ; on peut sans difficults ajouter un
champ dans ces vues sans avoir besoin de changer lensemble des droits sur les tables, les
champs, etc.
EXERCICE 6 TRANSACTIONS
On utilise videmment le mcanisme des transactions en dfinissant des points de retour
pour pouvoir annuler les effets des modifications des coefficients et des prix. On aban-
donne toutes les modifications, y compris celles des prix la fin de la transaction.
#Dmarrage de la transaction
START TRANSACTION ;
# Dfinition dun point de retour que lon nomme PRIX
SAVEPOINT PRIX ;
#Augmentation des prix des pizzas de 10 %
UPDATE pizza SET Prix=Prix*1.1;
On a dfini ici un point de retour PRIX qui permet de revenir ltat de la base avant la
modification de prix.
# Dfinition dun point de retour que lon nomme COEFF_NAINE
SAVEPOINT COEFF_NAINE ;
#Modification des coefficients de la taille nainedans la table tarification
UPDATE tarification SET Coefficient=0.5 WHERE Taille=naine ;
# Dfinition dun point de retour que lon nomme COEFF_OGRE
SAVEPOINT COEFF_OGRE ;
#Modification des coefficients de la taille ogressedans la table tarification
UPDATE tarification SET Coefficient=1.5 WHERE Taille=ogresse ;
On a dfini ici deux points de retour COEFF_NAINE et COEFF_OGRE qui permettent
de revenir ltat de la base avant les modifications des coefficients.
Pour revenir ltat de la base avant modification de tous les coefficients, on retourne au
point COEFF_NAINE.
#Annulation des modifications faites depuis le point COEFF_NAINE
ROLLBACK TO COEFF_NAINE;
La transaction ne se termine pas lorsque lon fait un ROLLBACK vers un point de retour. On
peut donc essayer dautres coefficients, sans oublier de redfinir de nouveaux points de retour.
# Dfinition dun point de retour que lon nomme COEFF_NAINE2
SAVEPOINT COEFF_NAINE2 ;
#Modification des coefficients de la taille nainedans la table tarification
UPDATE tarification SET Coefficient=0.5 WHERE Taille=naine ;
On dsire effectuer une simulation de mise jour de la base de donnes livraison de
pizzas . Lide est de procder une augmentation gnrale de 10 % du prix des pizzas,
tout en vitant de faire fuir les clients. On essaie de jouer sur les coefficients affects aux
diffrentes tailles de pizzas (naine, humaine, ogresse) et sur les prix de base. Lobjectif est
de mesurer les effets de ces modifications sur le compte des clients. On modifie dans un
premier temps les prix ; ensuite, les coefficients en se donnant la possibilit de revenir en
arrire pour tester diffrentes combinaisons de coefficients et de prix. Une fois les essais
termins, on abandonne toutes les modifications : ce ntait quune simulation.

182 Cration de bases de donnes
Et ainsi de suite. Puis, on abandonne lensemble des modifications par linstruction
ROLLBACK qui termine la transaction et remet la base dans ltat de dpart.
EXERCICE 7 TRIGGER
On utilise un trigger (dclencheur) pour mettre jour automatiquement la table com-
pose lors dune destruction dans la table pizza.
CREATE TRIGGER maj_compose BEFORE DELETE ON pizza FOR EACH ROW
BEGIN
DELETE FROM compose
WHERE NomPizza=OLD.NomPizza ;
END
On remarque dune part que, par rapport aux triggers dfinis dans le chapitre, on fait
appel aux valeurs de la table OLD . En effet, lors dune instruction DELETE, le SGBD
ne gre pas de table NEW dans la mesure o il nexiste pas de nouvelles valeurs ; dans
ce cas, la table OLD fera rfrence aux valeurs supprimes de la table pizza.
Dautre part, on effectue lopration de destruction dans la table compose avant celle de
pizza laide du terme BEFORE . Ici, elle aurait peut-tre pu intervenir galement
aprs, sauf sil existe une contrainte dintgrit de rfrence de la table compose par rap-
port la table pizza : un entre du champ NomPizza dans compose ne peut exister que
si elle existe dans la table pizza.
Le trigger permet alors dautomatiser les instructions quil aurait t fastidieux deffectuer
la main lors de la destruction dune entre dans la table pizza.
On dsire effectuer des mises jour proprement dans la base de donnes livraison
de pizzas . Lorsque lon dtruit une pizza dans la table pizza, on veut que les entres de
la table compose correspondant cette pizza disparaissent automatiquement. Ainsi, la
table composene contiendra aucune entre orpheline .

183 Codages de caractres et bases de donnes
Annexe
Codages de caractres
et bases de donnes
Du code Morse au code ASCII : un rapide
historique du codage des caractres
Historiquement, la transmission dinformation distance se faisait de manire visuelle. La
marine transmettait des messages entre les bateaux par des fanions qui reprsentaient
chacun une lettre de lalphabet. Le tlgraphe de Chappe reposait sur le mme principe :
une position des bras figurait une lettre. Il disposait en outre dun mcanisme de cryptage
ainsi que de codes spciaux qui accompagnaient le message (par exemple, urgent , en
attente , etc.). Avec linvention de llectricit est arriv le tlgraphe lectrique qui utili-
sait un fil par lettre de lalphabet (donc, 26 en tout).
Samuel Morse invente en 1840 un codage qui passe un seul fil pour la transmission. Il
sagit du premier codage moderne international qui inclut les chiffres, les lettres et cer-
tains caractres accentus. Il possde galement des caractres de contrle utiliss pour la
transmission du message (par exemple, rptez ). Ce codage universel permet de trans-
mettre des informations en utilisant une source lumineuse, sonore ou lectrique.
Le tlex apparat vers 1920 ; il se sert dun codage sur 5 positions invent par le Franais
Baudot. Les messages envoys par tlex sont dabord saisis sur un ruban perfor et lenvoi
ainsi que la rception sont automatiss. Cest le mme type de code qui a servi stocker de
linformation sur les cartes perfores 80 colonnes. Ces dernires reprsentent le premier
stockage dinformation avec un code qui prfigure ce qui est utilis actuellement. Le
codage 5 positions permet 32 possibilits (2
5
). Cette capacit est quasiment double
(diminue de caractres de contrle) par lemploi de deux tables. On indique par un
caractre spcifique la table dans laquelle on se situe. Le codage comprend les lettres, les
chiffres et quelques caractres de ponctuation. noter que, dans les caractres de con-
trle, on trouve un code pour ramener le chariot de limprimante en dbut de ligne (CR,
Carriage Return) et un caractre pour passer la ligne suivante (LF, Line Feed).
Les annes 1940 voient apparatre les ordinateurs qui recourent au dpart aux cartes per-
fores puis dautres systmes de stockage. Chaque constructeur dfinit son systme de
codage ; il arrive parfois que plusieurs systmes cohabitent chez le mme constructeur.
IBM dfinit le codage BCD qui servira de base EBCDIC plus tard et utilise 6 positions.
Dans les annes 1960, les constructeurs se sont regroups pour dfinir une norme com-
mune qui sera publie au final par lorganisme de normalisation ASS (American Standard
Association) sous le nom de code ASCII (American Standard Code for Information Inter-
change). Le code ASCII possde 7 positions, ce qui permet de stocker 128 (2
7
) caractres.
Les 32 premiers caractres sont des caractres de contrle, un hritage du transfert de
donnes par ruban perfor. Le reste du code contient des caractres majuscules et minus-
cules, les chiffres et des caractres divers (? @ $ , etc.). De nombreuses variantes nationales
existent en particulier pour le signe montaire qui diffre suivant les pays ( $ , pour les
USA, , pour la Grande-Bretagne, etc.). En dpit de ces spcificits, lusage du codage

184 Cration de bases de donnes
de caractre ASCII est encore trs rpandu, car il suffit bon nombre dapplications con-
dition que lon crive sans lettres accentues. Si lon a besoin de caractres diacritiques ou
dautres caractres ne se trouvant pas dans la table de codage ASCII, on peut les reprsen-
ter par une suite spcifique de caractres ASCII comme on le fait en HTML. Par exemple
se reprsente par la suite &eacute; .
Tables ISO-8859 et codages propritaires
Le systme de codage des caractres absents de la table ASCII vue plus haut nest gure
commode. Afin quil soit possible de reprsenter dautres langues, le codage ASCII a t
tendu. Le nombre de caractres disponibles a augment en passant un codage 8 posi-
tions, ce qui donne 256 (2
8
) possibilits. Les constructeurs ont propos leurs propres
extensions de ASCII. Par exemple, IBM avec EBCDIC et DEC avec la norme
VT200 .
Enfin, lISO (Organisation internationale de normalisation) a dfini une normalisation de
lextension ASCII pour les langues europennes. Lennui est que lon ne peut reprsenter
tous les caractres utiliss dans les langues latines, puisque leur nombre est limit 256.
Plusieurs tables ont donc t dfinies, le critre choisi pour regrouper les jeux de caractres
est fond sur la proximit gographique et commerciale. On dispose de 16 tables qui
seront nommes ISO-8859-n, n pouvant varier de 1 15. Lavantage est que les 128 pre-
miers caractres sont identiques ceux de lASCII. La compatibilit avec lexistant est
donc assure.
La table dfinie pour lEurope occidentale est la table ISO-8859-1, nomme galement
Latin1 , laquelle il manque videmment quelques caractres pour tre exhaustive. On
peut citer labsence du fameux franais ou du signe . Pour pallier ces manques,
une version modifie de Latin1 a t dfinie : Latin9 ou ISO8859-15. Elle est toute-
fois peu rpandue, probablement en raison du temps important qua ncessit sa dfini-
tion. La norme ISO-8859 dispose de tables pour le codage dautres langues comme le grec
(ISO-8859-7), le cyrillique (ISO-8859-5), etc. Les langues extrmes-orientales utilisent
beaucoup plus de 256 caractres et codent les caractres sur plus de 8 positions. Une ver-
sion allge du Japonais peut toutefois tre code par une extension de ASCII sur 8
positions : JIS X.
Dans un souci de simplification, les constructeurs ont conu des extensions de ces nor-
mes. En ce qui concerne lEurope occidentale, on peut citer lextension de ISO-8859-1,
ralise par Microsoft (Windows-1252), qui remplace certains caractres de contrle de la
table Latin1 pour y stocker les caractres manquants cits plus haut. Apple utilisait un
codage spcifique, MacRoman , incompatible avec les autres.
Remarque
Un point, qui peut se rvler pnible lusage, concerne les caractres de fin de ligne. On a
vu que le codage, hrit du temps o lon utilisait des machines mcaniques pour transmet-
tre les caractres, propose deux caractres distincts pour changer de ligne : le retour chariot
(CR) et le passage la ligne (LF).
Il nest plus techniquement utile aujourdhui de spcifier ces deux caractres pour indiquer
une fin de ligne. Cependant, la plupart des protocoles rseaux (par exemple HTTP) ainsi que
le monde DOS/Windows ont conserv la combinaison CR-LF pour passer la ligne. Les
familles UNIX utilisent le seul caractre LF et Apple le caractre CR. Il est donc ncessaire
deffectuer des transformations pour passer dun type de fichier lautre.

185 Codages de caractres et bases de donnes
Annexe
Unicode
Aujourdhui, on envoie des mails et lon schange des fichiers dun bout lautre du monde
et lon aimerait pouvoir les exprimer avec les caractres corrects. Le franais scrit avec des
caractres diacritiques : la lecture dun texte sans accents est dsagrable et peut mme nuire
la comprhension. La section prcdente donne une ide de la confusion qui rgne pour le
codage des caractres malgr les efforts de normalisation. De plus, on ne peut deviner
(cest--dire dtecter automatiquement) en ouvrant un fichier sil est cod en ISO-8859-l ou
en MacRoman et il est impossible dutiliser des tables de langues diffrentes au sein dun
mme fichier. Pour rsoudre ces problmes, un groupement de constructeurs et dditeurs
de logiciels (Adobe, Xerox, Apple, IBM, MicroSoft, etc.) ont fond le consortium Unicode
au dbut des annes 1990. Unicode est un standard dfini par un consortium priv, mais
aprs quelques errements la norme ISO-10646 a repris lensemble du standard.
Lide est de disposer dun systme de codage de tous les caractres du monde ou plus
exactement de pouvoir coder la reprsentation de ces caractres. Unicode spare la notion
de caractre de sa reprsentation que lon appelle un glyphe . Ainsi, les notions
daspect, de police ou de taille du caractre nexistent pas dans le codage Unicode ; ces
informations sont reportes au niveau de lapplication. Le standard fournit tout de mme
un exemple de reprsentation (glyphe) du caractre titre informatif. En revanche, on
inclut des informations complmentaires, comme la direction dans laquelle il faut lire les
caractres ou des proprits alphabtiques qui seront importantes pour les bases de don-
nes. En ce qui concerne plus particulirement les caractres diacritiques, la rgle gnrale
est de donner la possibilit de construire le caractre plutt que de le stocker : un
sera construit en utilisant le code e combin au code ` . Cependant, pour des raisons
pratiques de compatibilit, Unicode a repris intgralement les codages existants tels que
ISO-8859-1 : dans ce cas, on stocke galement le caractre .
La plupart des langues vivantes peuvent scrire dsormais avec Unicode (plus ou moins 100
000 caractres sont actuellement dfinis), mme si certains choix ont fait lobjet de fortes cri-
tiques. Les symboles mathmatiques, musicaux ou autres font galement partie du code. Le
processus se poursuit avec les langues mortes, comme le codage des hiroglyphes gyptiens.
Techniquement, Unicode utilise un codage sur 21 positions. Le codage est divis en 17
tables de 65 536 (2
16
) caractres que lon appelle des plans. Lun des intrts de ce dcou-
page est que par exemple le premier plan suffit coder la plupart des langues vivantes. De
surcrot, le tout dbut de ce premier plan reprend exactement la norme ISO-8851-1. De
cette manire, on nest pas oblig dutiliser la place des 21 positions pour coder les carac-
tres Unicode. Il suffit de trouver un codage astucieux qui indique que lon utilise le pre-
mier plan ou mme le dbut du premier plan, et alors 8 positions suffisent. Avec des
caractres plus exotiques , le codage utilise alors 16 positions et ainsi du suite. Cet
aspect offre beaucoup de souplesse et assure galement la compatibilit avec lexistant
ASCII et ISO-8859.
Les machines et les logiciels utilisent traditionnellement, et cest l lhritage des codages
prcdents, comme unit de base loctet qui contient 8 positions. Les diffrentes manires de
coder les caractres Unicode seront donc des multiples doctets. Essentiellement, on trouve :
UTF-8 : il sagit dun encodage gnial sur 8 bits concoct en une journe (une nuit ?)
par K. Thompson. Lide est que tout ce qui est en ASCII est cod sur un octet ; ce qui
est cod avec des diacritiques conformes la norme ISO-8859 est cod sur deux octets
et ainsi de suite. Cette manire de coder permet de conserver la compatibilit totale
avec le codage ASCII ainsi que de continuer utiliser les logiciels et matriels conus
lorigine pour lire des octets.

186 Cration de bases de donnes
UTF-16 : on reprsente Unicode sur deux octets. Cest plus conomique en termes de
place si lon utilise frquemment des langues extrme-orientales (UTF-8 utilise 3
octets dans ce cas). Le problme est de savoir de ces deux octets lequel est le premier
(dit de poids fort ). En effet, deux architectures diffrentes de machines coexistent
toujours, car cette information est code au niveau matriel. Ces dernires sont dsi-
gnes par les termes Little Endian et Big Endian . Il existe donc une version UTF-
16LE et une version UTF-16BE. Pour la petite histoire, les termes Big Endian et
Little Endian proviennent du livre Les Voyages de Gulliver, o lauteur dcrit des
peuplades qui mangent les ufs par le petit bout , opposes celles qui les mangent
par le grand bout .
Il existe dautres reprsentations du codage Unicode : UTF-32 sur 32 positions, UTF-7 sur
7 positions, etc. UTF-8 est logiquement le codage le plus frquemment utilis actuelle-
ment, car il est celui qui consomme le moins de place (si lon utilise des caractres ASCII
ou europens) et qui ncessite le moins de changements structurels aux niveaux logiciel et
matriel. noter que, dans tous les cas, on pourra reconnatre informatiquement le type
de codage qui est utilis. Unicode nest pas parfait, puisquil a intgr les systmes de
codage hrits des systmes prcdents (presque depuis le code Morse). En revanche, les
langues qui ne possdaient aucun codage prliminaire disposent dun codage lgant et
cohrent. Unicode est actuellement support par la plupart des systmes dexploitation,
mais la transformation de tous les textes et bases de donnes existants prendra du temps :
Ken Whistler (directeur technique du consortium Unicode) prvoit environ 10 ans pour la
transition.
Figure A.1
Les diffrents
codages de
caractres.
Morse
Baudot (5 positions)
BCD- IBM (6 positions)
ASCII (7 positions)
ISO 8859(8 positions)
ISO-8859-1 (Latin1)
ISO-8859-15 (Latin9)
ISO-8859-7 (Grec)
UNICODE -ISO-10646
(21 positions)
MacRoman (8 positions)
Windows-1251 (8 positions)
JIS X Japonais (8 positions)
UTF 8(octets)
UTF 16(doubles octets)
UTF-7, UTF-32, UCS-2 .
Plan Multilingue Base
Autres plans

187 Codages de caractres et bases de donnes
Annexe
Codage dans une base de donnes et ordre de tri
Les bases de donnes contiennent des donnes textuelles. On peut donc trouver dans une
base de donnes tous les codages de caractres prsents plus haut du simple ASCII
Unicode.
Comment choisir le codage de caractre employer au moment de
la conception de la base de donnes ?
Une des premires proccupations est de choisir le codage de caractre qui conviendra aux
donnes entres. Si lon utilise les tables de la norme ISO-8859, il faut dcider laquelle est
convenable en fonction du contenu futur. Le problme ne se pose videmment pas sil ne
se trouve aucun diacritique dans les donnes. Une autre question est de savoir ce que les
utilisateurs feront des donnes extraites de la base. Par exemple, sont-ils capables dutiliser
un format de type Unicode ou ont-ils recours exclusivement Windows-1252 ? De mme,
disposent-ils de logiciels clients capables dinterroger directement la base de donnes
en Unicode ou en IS0-8859-15 par exemple ? Un dernier critre de choix pourrait tre la
place occupe. Dans le cas du choix dUnicode, si lon emploie des langues latines, UTF-8
est plus intressant que UTF-16. Dans le cas de langues asiatiques, UTF-16 est plus appro-
pri. Le plus conomique est sans doute la norme ISO-8859, mais cela est valable condi-
tion que la table utilise soit suffisamment complte pour les donnes considres. Un bon
compromis est la norme Unicode code en UTF-8, qui permet de reprsenter tous les
caractres tout en tant conome en place.
Ordre de tri et collation
Le codage de caractre consiste associer un code une lettre. Par exemple on affecte le
code 1 la lettre a , le code 2 la lettre b , et ainsi de suite. Pour trier, il suffit alors de
mettre les lettres dans lordre des codes. Que se passe-t-il si, dans notre code, la lettre a
est code en majuscules et en minuscules ? Si la lettre A a le code 30 dans notre codage,
le tri par ordre croissant des numros va se faire dabord par lettres minuscules puis par
lettres majuscules. De mme, si notre codage affecte le numro 50 la lettre accentue
, elle va se retrouver la suite des majuscules et non pas au mme niveau que la lettre
a . Afin de pouvoir effectuer le tri correctement, il faut disposer dune table de corres-
pondance qui indique que les codes 1, 30 et 50 de notre codage doivent se trouver au
mme niveau dans le rsultat du tri. On appelle cette table de correspondance la
collation ; elle sera en gnral diffrente suivant la langue employe.
Choix du jeu de caractres et de la collation avec SQL
On doit donc effectuer au moment de la cration de la table le choix du codage de caract-
res employer ainsi que la collation lui appliquer.
Le choix du jeu de caractres se fait par le mot cl CHARACTER SET suivi du nom du jeu de
caractres.
Nom_client CHAR(20) CHARACTER SET Unicode ;
On peut dfinir un jeu de caractres spcifique pour chaque champ. Il existe des noms de
jeux de caractres prdfinis dans la norme SQL : Unicode, ASCII_FULL, LATIN1 etc. Les
SGBD proposent en gnral des jeux de caractres complmentaires. Il est possible en SQL
dindiquer lutilisation dun jeu de caractres prdfini avec le mot cl NATIONAL CHARACTER.
En pratique, dans les SGBD actuels, le jeu de caractres employ dans ce cas est le plus
souvent UTF-8.

188 Cration de bases de donnes
Nom_client NATIONAL CHARACTER(20) ;
La collation utiliser est spcifie par le mot cl COLLATE suivi du nom de la collation uti-
liser.
Nom_client CHAR(20) CHARACTER SET Unicode COLLATE LATIN1;
Les SGBD proposent de nombreuses collations en dehors de celles prdfinies dans la
norme SQL. Les jeux de caractres et les collations peuvent tre dfinis plus gnralement
au niveau des tables, des bases de donnes et du SGBD lui-mme. Un jeu de caractres
ainsi quune collation par dfaut sont utiliss dans le SGBD ; il est intressant den vrifier
le contenu avant dutiliser le SGBD si lon ne les spcifie pas explicitement.

189 Bibliographie
Bibliographie
G. Gardarin, Bases de donnes, Eyrolles, 2001 (ISBN : 2-212-09283-0).
R. Elmasri et S. Navathe, Conception et Architecture des bases de donnes, Pearson Educa-
tion, 2004 (ISBN : 2-7440-7055-6).
C. Delobel, C. Lcluse et P. Richard, Bases de donnes et Systmes relationnels, Dunod.
N. Boudjlida, Bases de donnes et Systmes dinformations. Le Modle relationnel : langages,
systmes et mthodes, Dunod, 1999.
C. J. Date, Introduction aux bases de donnes, Vuibert, 2004 (ISBN 2-7117-8640-4).
T. Connoly et C. Begg, Systmes de bases de donnes, Eyrolles (ISBN 2-89377-267-6).
F. Brouard et Ch. Soutou, Synthex SQL, Pearson Education, 2005 (ISBN : 2-7440-7095-5).
B. Charroux, A. Osmani et Y. Thierry-Mieg, Synthex UML2, Pearson Education, 2005
(ISBN : 2-7440-7124-2).
Ch. Soutou, De UML SQL, Eyrolles, 2002 (ISBN : 2-212-11098-7).
H. Tardieu, A. Rochfeld et R. Colleti, La Mthode MERISE, Eyrolles, 2000.
D. Nanci et B. Espinasse, Ingnierie des systmes dinformation : Merise deuxime gnra-
tion, Vuibert, 2001 (ISBN 2-7117-8674-9).
P. Andr et A. Vailly, Conception des systmes dinformation, panorama des mthodes et des
techniques, Technosup, Ellipse, 2001 (ISBN 2-7298-0479-X).
E.F. Codd, A Relational Model of Data for Large Shared Data Banks, 1970.


191 Index
Index
A
Accs concurrent 167
ACID 16, 170
Administrateur 19, 161
Algbre relationnelle 60
ANSI/SPARC 15
Association 17, 30, 32, 38, 41, 68
Attributs 6, 31, 35
B
Bases de donnes 8, 9, 10, 19
dductives 9, 10
volution 4
mtiers 19
modles 5
rparties 8, 9
C
Cardinalits 30, 33, 34, 43, 56, 69
Champs 3, 31, 56
Cl 14, 56, 57, 58, 59, 114
candidate 57, 58, 114
composite 115
trangre 59
primaire 57
Cohrence 3, 16, 59
Collation 187
Contraintes dintgrit 59, 114
D
Data mining 9
Datawarehouse 10, 11
Dcomposition 70, 72, 73, 74
Degr 32, 56
Dpendance fonctionnelle 57, 70, 72,
73
Disponibilit 8, 16, 160
Domaine 17, 41, 56, 59
DTD 11, 12
E
Entits 31
Entrepts de donnes 10, 11
F
Fichier informatique 13, 14
Forme normale 70, 72, 73, 75, 135, 136
Boyce-Codd 75
deuxime 72, 136
premire 70, 135
troisime 73, 136
Fouilles de donnes 9
Fusion 38, 39
H
HTML 11
I
Identifiant 31
Incohrences 4, 18, 35, 36, 37, 38, 59,
167
Index 14, 110, 140
J
Jeu de caractres
ASCII 183
ISO-8859-n 184
Base de donnes book Page 191 Lundi, 5 juin 2006 3:33 15
192 Cration de bases de donnes
MacRoman 184
unicode 185
UTF-16 186
UTF-32 186
UTF-8 185
Windows-1252 184
Jointure 64, 65
externe 65
naturelle 64
Journalisation 16, 170
L
Langage hte 96
LDD 16, 80, 95
LMD 16, 95
Logique du premier ordre 76
M
Mtadonne 3, 160
Modle 5, 6, 7, 8, 30, 56, 68
entit-association 30
hirarchique 5
logique 68
objet 6, 7
relationnel 6, 56
relationnel-objet 7, 8
rseau 5
Multivaluation 70
N
Niveau 5, 15
conceptuel 15
externe 5, 15
interne 15
logique 5
physique 5, 15
O
Objet 7, 28, 29
Oprations
agrgat 67, 103
diffrence 61
quijointure 63
intersection 61, 83
jointure 63
jointure externe 108
jointure interne 106
produit cartsien 61, 105
projection 62, 98
restriction 63
slection 63, 101
union 60
Q
QBE 76, 78
R
Redondance 3, 4, 37, 38, 59, 72, 73, 136, 160
Relation 56
Rle 42, 162, 164
S
Sauvegarde 15, 160
SGBD 13
SQL
- 100
% 100
* 100
+ 100
/ 100
< 101
<= 102
<> 101
= 101
> 101
>= 102
ALTER TABLE 112
AND 102
AVG 101
BETWEEN 102
CHECK 115
COMMIT 171
CONSTRAINT 116
COUNT 101
CREATE INDEX 140
CREATE ROLE 166
CREATE TABLE 110
CREATE TEMPORARY TABLE 111
CREATE TRIGGER 173
CREATE VIEW 116
DELETE FROM 117
DISTINCT 99
DROP TABLE 112
DROP TRIGGER 173
GRANT 166
GROUP BY 103
HAVING 104
IN 102
INNER JOIN 106
INSERT INTO 116
IS NULL 102
LIKE 102
MAX 101
Base de donnes book Page 192 Lundi, 5 juin 2006 3:33 15
193 Index
MIN 101
NOT 102
OR 102
ORDER BY 109
OUTER JOIN 108
PRIMARY KEY 114
ROLLBACK 171
SAVEPOINT 172
SELECT 98
START TRANSACTION 171
SUM 101
UPDATE 118
WHERE 101
T
Tables 110
Transactions 169
Tri 109
Triggers 173
Type SQL
BLOB 111
BOOLEAN 111
CHAR 111
DATE 111
FLOAT 111
INT 111
NCHAR 111
NVARCHAR 111
REAL 111
SMALLINT 111
TIME 111
VARCHAR 111
U
UML 17, 30, 40, 41, 42
V
Verrouillage 170
Verrous 168
Vues 116, 165
W
World Wide Web 2, 11
X
XML 11, 12
Base de donnes book Page 193 Lundi, 5 juin 2006 3:33 15
Pearson Education France
47 bis, rue des Vinaigriers
75010 Paris
Tl. : 01 72 74 90 00
Fax : 01 42 05 22 17
www.pearson.fr
ISBN : 978-2-7440-7386-1
I n f o r ma t i q u e
Synthse
de cours
exercices
corrigs
&
La collection Synthex informatique propose de (re)-dcouvrir les
fondements thoriques et les applications pratiques des principales
disciplines de science informatique. partir dune synthse de cours
rigoureuse et dexercices aux corrigs dtaills, le lecteur, tudiant
ou professionnel, est conduit au cur de la discipline, et acquiert une
comprhension rapide et un raisonnement solide.
Lauteur :
Nicolas Larrousse est ingnieur au
CNRS. Spcialis en informatique,
il enseigne les bases de donnes
luniversit de Versailles Saint-Quentin-
en-Yvelines et au service de formation
permanente de luniversit Pierre et
Marie Curie Jussieu.
Le relecteur :
ric Innocenti est matre de confren-
ces en informatique luniversit de
Corse. Il est responsable pdago-
gique des lires SRC (Services et
Rseaux de Communication) et LPM
(Licence Professionnelle Multimdia). Il
enseigne lalgorithmique, la program-
mation et les systmes dinformation.
Cet ouvrage propose une dmarche progressive ceux qui veulent concevoir
un systme dinformation robuste et volutif en vitant les cueils classiques qui
conduisent rendre les donnes inutilisables. Toutes les tapes de la ralisation
dune base de donnes, de lanalyse pralable au choix du codage des carac-
tres, sont tudies et illustres par des exemples.
Le livre prsente plus particulirement la modlisation du monde rel au moyen
du modle entit-association, le passage au modle relationnel et la mise en
uvre du systme ainsi conu laide du langage SQL. Une tude de cas
rcapitulative permet ensuite dappliquer les notions prsentes dans les cha-
pitres prcdents. Le dernier chapitre traite de la scurisation des donnes,
notament au moyen des transactions et des triggers.
Les exercices, qui occupent la moiti du livre, sont intgralement corrigs an
que le lecteur mette progressivement en uvre ses connaissances. Par ailleurs,
les donnes et les scripts SQL utiliss tant pour les exemples que pour les exerci-
ces sont disponibles ladresse www.pearsoneducation.fr.
Le livre sadresse aux tudiants de premier et de second cycles (IUT, BTS, univer-
sits et coles dingnieurs) qui dbutent lapprentissage des bases de donnes.
Il sera galement utile aux professionnels qui veulent mettre en place une base
de donnes, mme de taille modeste.
Cration
de bases
de donnes
Dans la mme collection :
Algorithmique, Applications en C,
Jean-Michel Lry
Algorithmique en C++, Jean-Michel Lry
Algorithmique en Java 5,
Jean-Michel Lry
Architecture de lordinateur,
Emmanuel Lazard
Java 5, Robert Chevallier
LateX, Jean-Cme Charpentier,
Denis Bitouz
Le langage C, Jean-Michel Lry
Le langage C++, Marius Vasiliu
Linux, Jean-Michel Lry
Mathmatiques discrtes appliques
linformatique, Rod Haggarty
SQL, Frdric Brouard, Christian Soutou
Systmes dexploitation, Bart Lamiroy,
Laurent Najman, Hugues Talbot
Rseaux, Dominique Seret, Danile
Dromard
UML 2, Benot Charroux, Aomar
Osmani et Yann Thierry-Mieg

Vous aimerez peut-être aussi