Création de Bases de Données

Informatique
Synthse
de cours
&
exercices
corrigs
Cration de
bases de donnes
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 :
fichiers des donnes et textes des requtes
collection
Synthex
Nicolas Larrousse
Informatique
Synthse
de cours
&
exercices
corrigs
Cration de bases
de donnes
Nicolas Larrousse
CNRS
Avec la contribution de ric Innocenti
Universit de Corse Pasquale Paoli
collection
Synthex
ISBN : 978-2-7440-7386-1
ISSN : 1768-7616
2009 Pearson Education France

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.
Sommaire
Lauteur
Le relecteur
VII
Avant-propos
IX
Chapitre 1 Introduction aux bases de donnes

1 Quest-ce quune base de donnes ?
2 volution des bases de donnes et de leur utilisation
3 Systmes de gestion de bases de donnes
4 tapes de la conception des bases de donnes
5 Mtiers des bases de donnes
6 Plan de louvrage
7 Prsentation de la BD exemple
Exercices
1
2
4
13
17
19
20
20
22
Chapitre 2 Analyse du monde rel

1 Dmarche danalyse
2 Modlisation par le modle entit-association
3 Remise en cause et volution du modle
4 Reprsentation avec UML
Exercices
27
28
30
35
40
44
Chapitre 3 Approche relationnelle

1 Concepts
2 Oprations du modle relationnel
3 Passage du modle conceptuel au relationnel
4 Normalisation
55
56
60
68
70
Logique du premier ordre et base de donnes
Exercices
Chapitre 4 SQL
1 Concepts du langage SQL
2 Oprations relationnelles avec SQL
3 Gestion de tables et de vues
4 Gestion des donnes
Exercices
76
82
95
96
97
110
116
120
Sommaire III
IV
Chapitre 5 Du langage parl SQL

1 Prsentation de lactivit modliser
2 laboration du modle entit-association
3 Passage au modle relationnel
4 Interrogation de la base de donnes
Exercices
127
128
129
134
141
148
Chapitre 6 Prservation des donnes

1 Contrle daccs et sauvegarde
2 Limitations daccs au SGBD
3 Transactions
4 Triggers
Exercices
157
158
161
166
173
176
Annexe
183
Bibliographie
189
Index
191
Cration de bases de donnes
Lauteur
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.
Avant-propos V
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.
Le relecteur VII
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 donnes 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 dapprofondir 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 utilisation (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.
Avant-propos IX
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 donnes. Aprs avoir nonc quelques conseils gnraux, on prsente ici les deux outils fondamentaux 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 parties 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 galement 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 particulirement Christophe Lenne, chez Pearson Education France, notamment pour sa
patience.
Chapitre
Introduction aux
bases de donnes
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
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
4. tapes de la conception des bases

de donnes ..............................17
effectu avec sa carte bancaire jusqu nos
5. Mtiers des bases de donnes 19
dclarations de revenus.
6. Plan de louvrage .....................20

7. Prsentation de la BD exemple ...20
Lobjectif de ce chapitre est de dfinir la notion de
Exercices
base de donnes ainsi que les principaux concepts
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
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.
7. Vues externes ...........................24

8. Base de donnes rparties .........25
9. XML .........................................25
10. Fouille de donnes et entrepts
de donnes ..............................26
Quest-ce quune base de donnes ?

Le nombre dinformations disponibles et les moyens de les diffuser sont en constante progression. La croissance du World Wide Web a encore accru ce dveloppement, en fournissant 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 utilisation 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 modlisation. En rsum, on dfinit une base de donnes comme lensemble des donnes stockes. 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 formellement, 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 contiennent 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 applications diffrentes. Dans un programme classique, la structuration des donnes est dcrite
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 concernant les rgles de cohrence des donnes abordes la section suivante.
Figure 1.1
Base de donnes
de CD et
mtadonne.
NumCD
Nombre entier suprieur

1900 et infrieur
lanne en cours
Chane de caractres
de taille 30
Nombre entier
suprieur 1
Titre
Musicien
Label
Anne
Streetwise
Olivier Temime
Nocturne
1978
Underground
Thelonious Monk
Columbia
2005
Two a day
Chet Baker
Dreyfus
1968
Chane de caractres de taille 50
Chane de caractres de taille 20
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 Monsieur 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
Introduction aux bases de donnes 3
pertinents sont retourns lors dune interrogation. La redondance est parfois plus dlicate identifier. Si lon considre le cas trs simple dun carnet dadresses qui contiendrait en mme temps le code postal et le nom de la ville, elle est ici vidente.
Tableau 1.1
Exemple de
redondance de
linformation.
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
On remarque que lon stocke plusieurs fois la mme association dinformation (par exemple, 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.
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 dveloppes. 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 performants 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 supplmentaire 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 langages 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 relationnelle en base 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 transversales, utilise une structure de graphe et lve de nombreuses limitations du modle hirarchique. 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.
Personne
Nom
Prnom
NumINSEE
Voiture
Logement
Marque
Type
Couleur
Numro
Rue
Ville
Type
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, no 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 relationnel permet de modliser les informations contenues dans les bases de donnes en utilisant 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 (organisation internationale de normalisation), a assur pour une grande partie le succs du
modle relationnel auprs des entreprises. Fait rare dans le monde informatique, ce langage a t adopt par la quasi-totalit des diteurs commerciaux qui participent activement 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 permet denvisager des migrations moins douloureuses et de conserver une partie de linvestissement initial.
Figure 1.3
Ouvrage (Cote, Titre, Auteur,Editeur)
Modle
relationnel.
Cote
Titre
Auteur
Editeur
La programmation sous Unix
J. M. Rifflet
MC Graw Hill
Les bases de donnes
G. Gardarin
Eyrolles
Internet pour les nuls
C. Baroudi
First Interactive
Le langage C
C. Delannoy
Eyrolles
Petit Larousse illustr
P. Larousse
Larousse
Godel, Escher & Bach
D. Hofstadter
Basic Book Inc.
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 directement un lment du monde rel. Les structures dlments complexes se retrouvent souvent 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
Chapitre
plus commode de manipuler directement des objets lorsque lon dveloppe avec un langage 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 apportent ainsi aux applications dveloppes en langage objet la persistance des objets
manipuls : ces derniers peuvent ainsi directement tre rutiliss par lapplication dorigine 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 suffisamment importante. Le monde des bases de donnes volue assez lentement : la migration
dun systme dinformation vers lobjet reprsente pour une organisation un investissement considrable qui nest pas toujours justifi. La robustesse et la popularit de lapproche relationnelle, qui a mis presque vingt ans simposer, a galement frein le
dveloppement de lapproche objet pure dans les bases de donnes. Les donnes modlises 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.
Encapsulation
Objet
Mthodes
Donnes
Hritage
Dplacer()
X1,Y1
X2,Y2
Fermer
Agrandir()
Retourner
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 gographiques, ne peuvent pas tre modliss efficacement en utilisant ce type dapproche. Lide
est alors dintgrer de lobjet au modle relationnel existant plutt que dutiliser lapproche 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 lapproche 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 permet 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-
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 dencapsulation et dhritage, typiques de lapproche objet, sont supportes. Cette solution a lavantage doffrir un bon niveau de compatibilit avec lapproche prcdente trs rpandue et
deffectuer ainsi une migration plus aise.
Figure 1.5
Cote
Modle
relationnel-objet.
Titre
Le vide
La vie sans
mode demploi
Auteur
Nom
Prnom
Durand
Dal
Atamp
Charles
Editeur
Les ditions du
temps qui ne
passe pas
Romazava
Nom
Prnom
Brass
Alexis
Duporche
Jean-Marie
Chteau
Romain
Paclaire
Anne-Isabelle
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 politique 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 rparties 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 distant intervalles rguliers pour viter le dsastre de la perte de donnes due un incendie 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 informatiques, 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
Chapitre
modification de localisation, daugmentation de la taille de la base, dajouts dordinateurs sur le rseau afin daugmenter la capacit de stockage de la base de donnes.
Figure 1.6
Base de donnes
rparties.
Filiale Est
Copie sauvegarde
Sige social
Copie sauvegarde
Copie sauvegarde
Filiale Ocan indien
Filiale Asie
Interrogation
(rpartition)
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 utilise 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 dexploitation 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 classifications et autres techniques employes en intelligence artificielle. Une fois ces rgles tablies, on peut les utiliser au sein des bases de donnes dductives dcrites prcdemment.
Figure 1.7
Base de donnes
dductives prefils.
Pre
Fils
Hugo
Tian
Tapeneau
Merlin
Tian
Lastoul
Merlin
Alize
Alize
Teanne
Linformation dcisionnelle ainsi extraite a de nombreux dbouchs : du ciblage marketing 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 perdre 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 personnel) pour disposer dun accs homogne lensemble des donnes. Les donnes disperses 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 entrept de donnes ou datawarehouse (voir figure 1.8).
Si linformation est disponible, on stocke les diffrentes valeurs dune donne, ce qui permet de conserver un historique dans le temps de certaines donnes : elles sont dites historises. 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 prcdentes 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 donnes, htrognit des donnes traiter) que de lanalyse des donnes (comment analyser, quelle information stocker). En outre, il sagit le plus souvent du poste budgtaire
le plus onreux dans un projet dinformatique dcisionnelle.
10
Chapitre
Figure 1.8
Entrepts de
donnes.
Production
Service
achats
Analyse
Entrept de
donnes
Service
marketing
(datawarehouse)
Consultation
Service du
personnel
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 glissement 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 statique, mais galement le rsultat de lexcution dun programme : le contenu devient donc
dynamique. Par extension, on imagine aisment que le mcanisme du Web peut galement 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 document est conforme la structure attendue et den extraire facilement le contenu. Le langage 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 Language), 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 pertinence de lindexation en sont diminues dautant.
Pour remdier cela, le W3C (World Wide Web Consortium) a dfini un langage, qui est galement une simplification de SGML, permettant de dcrire la structure interne dun
document : XML (eXtended Markup Language). La structure dun document XML est reprsente sous la forme dun arbre tout comme celle dun document HTML. La description de
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 utilisant 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 prsentation 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 figurant dans un titre tant plus important que le mme mot dans une note de bas de page.
Figure 1.9
Structure
arborescente XML.
<catalogue>
catalogue
<article>
<nom> banane </nom>
<prix>
</prix>
<quantit>
1000
</quantit>
</article>
article
<article>
article
<nom>
<prix>
pige
300
<quantit>
</nom>
</prix>
35
</quantit>
quantit
</article>
prix
<catalogue>
nom
1000
prix
2
quantit
nom
banane
pige
300
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 volutions futures des SGBD.
12
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 multimdias 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 contraire, 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 recherche, 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 socits dveloppant les moteurs de recherche que des bases de donnes au sens strict. Cependant, 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.
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 stockes 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 rcuprer 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.
Figure 1.10
Fichier
Fichier
informatique.
Accs squentiel
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 contenu.
Une alternative au parcours squentiel est de construire des tables descriptives afin dacclrer 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 premire 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
Fichier et index.
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.
14
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 larchitecture 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 constitutifs de la base de donnes et les contraintes qui leur sont associes. Il sagit dune certaine 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 dutilisateurs. Un schma externe permet de masquer la complexit de la base de donnes complte en fonction des droits ou des besoins des utilisateurs. Cela facilite la lecture et la
scurit de linformation.
Figure 1.12
Utilisateurs
Niveaux ANSI/
SPARC.
Niveau externe
Schma conceptuel
Niveau interne
Vues
Modle conceptuel
Modle physique
SGBD
Il sagit comme pour le modle rseau de lISO dun cadre de rflexion ; les SGBD ne respectent pas la lettre le dcoupage propos. Ils se doivent cependant de possder les principales 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.
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 gestion 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 oprations 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 graphiques.
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 gnralement ralises en utilisant des journaux qui enregistrent au fur et mesure les oprations 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 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.
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 concurremment. 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
16
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.
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 objectifs 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 caractristiques 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 description 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 entitassociation ou, plus couramment aujourdhui, exprim avec le langage UML (Unified
Modeling Language). Il existe diffrentes mthodes intgrant les concepts prsents ci-dessus. 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 succs 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 considrablement 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
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 effectuer 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, comment savoir que les personnes achtent des voitures et non pas le vendeur si lon ne dispose 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 utilisant 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.
Monde rel
Analyse
Modle
entit-association
Vue 1
Transformation
Schma
Vue 2
Vue 3
18
relationnel
LMD
SGDB
LDD
Base de
donnes
physique
Chapitre
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 utilisateurs. La gageure est de parvenir faire exprimer correctement les besoins dinformatisation 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 logique 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 donnes (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 ressources (bases, comptes) la demande. Il donne les droits daccs et gre les personnes qui accdent 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 dadministration 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.
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 entitassociation . On aborde galement la reprsentation du modle avec UML.
Le troisime chapitre est essentiellement consacr au modle relationnel et aux oprations 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 incohrences du systme dinformation ainsi cr et de les rectifier. On prsente dans ce chapitre 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 prcdemment. 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 donnes 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 associs 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 .
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 donnes 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.
20
Chapitre
Figure 1.14
Base de donnes
exemple.
Nom
Marque
Vente
Type
ge
Couleur
Ville
Sexe
Le modle entit-association et la reprsentation UML correspondant cette description 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 donnes, on utilise un SGBD (Systme de Gestion de Bases de Donnes) qui est un logiciel complexe. 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 diffrentes 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 normalis de description, de manipulation et dinterrogation de donnes. La modlisation objet,
adapte aux bases de donnes, na pas connu un dveloppement considrable, et ce, malgr 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 dinterrogation, telles que la fouille de donnes (ou data mining) et les bases de donnes dductives, 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.
Exercices
EXERCICE 1
NOTION DE BASE DE DONNES

Quelles sont les diffrences majeures entre un fichier informatique et une base de donnes gre par un SGBD ?
On peut lister ces points essentiels qui les diffrencient :
EXERCICE 2
Il nest pas ncessaire de connatre la mthode de stockage des informations sur le disque pour manipuler les donnes avec une base de donnes.
Un fichier informatique simple nest pas conu pour effectuer une recherche dinformation par le contenu : pour retrouver le(s) enregistrement(s), on est oblig de parcourir 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.
RECHERCHE DICHOTOMIQUE
Donnez un algorithme intuitif simple de recherche dichotomique en utilisant une table
dindex et une table accs direct.
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 denregistrement correspondants dans sa colonne 2.
Si le tableau est rduit un lment dont la valeur dans la premire colonne Ti[1,1] est diffrente 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)
22
Chapitre
EXERCICE 3
LANGAGES DUN
SGBD
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.
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 manipulation 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
Vous devez reprsenter lorganisation de donnes correspondant une classification
scientifique despces doiseaux. Quel modle de donnes (hirarchique, rseau, relationnel, objet) choisiriez-vous ?
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.
MTIERS DES BASES DE DONNES

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 ?
Dans une petite structure, cest souvent la mme personne qui ralise lensemble du processus 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 comptences en conception de base de donnes et en administration du SGBD qui sera utilis.
Exercices
EXERCICE 5
EXERCICE 6
UTILISATEURS DUNE BASE DE DONNES

On utilise pour cet exercice la base de donnes exemple de vente de voitures. On considre les oprations suivantes :
1.
2.
3.
4.
Ajouter une personne dans le fichier client.

Modifier les possibilits dajout dans le champ couleur .
Augmenter la taille du champ couleur.
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 ?
1. Un utilisateur final (par exemple un vendeur) muni des droits appropris peut intervenir 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 utilisant 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
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 ?
1. Les clients ne doivent avoir accs en lecture quaux informations concernant les voitures en stock (non encore vendues).
2. Les vendeurs, sils grent galement le parc de voitures comme cest souvent le cas, peuvent avoir accs en lecture et en criture toutes les donnes (ventes, voitures, personnes).
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.
24
Chapitre
EXERCICE 8
BASE DE DONNES RPARTIES

On dcide de recopier rgulirement une base de donnes complte sur chacun des six
sites de lentreprise. Quel est lintrt de cette solution ?
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 serveurs 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 ?
XML
Pourquoi prfre-t-on utiliser XML plutt que HTML pour reprsenter les donnes provenant dune base de donnes ? Les donnes XML sont dites autodescriptives . Questce que cela signifie et par quel(s) dispositif(s) est-ce ralis ?
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.
Exercices
EXERCICE 9
EXERCICE 10
FOUILLE DE DONNES ET ENTREPTS DE DONNES

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 produits que les autres. Ils gnrent donc un chiffre daffaires plus important, mais ces produits 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 donnes pour pouvoir effectuer cette opration en supposant que votre entreprise soit organise avec une structure de services classique ?
Pour obtenir les lments ncessaires lanalyse, il nous faut intgrer les donnes de diffrents 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 intressant 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 donnes, vous utiliserez une (ou plusieurs) application(s) de type ETL (Extract, Transform and
Load) que lon appelle aussi datapumping .
26
Chapitre
Analyse du monde
rel
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
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
4. Description du monde rel

partir des cardinalits .............47
de proposer une mthode danalyse simple et
5. Association inutile .....................48
efficace dans la majorit des cas.
6. Association rflexive...................49
Au cours des dernires annes, la reprsentation
7. Association ternaire ..................49

8. De lnonc au modle
entit-association ......................51
9. Reprsentation avec UML ..........52
10. Autre exemple le camping
lUliastru ..................................53
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.
27
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 correspondre 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 conception 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 donnes 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 conception 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 modliser. 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 caractrisent 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.
28
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 permet(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 identifis, on cherche qualifier les liens trouvs. Il faut tenir compte du fait que le lien est toujours 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 rarement 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 schmatique du fonctionnement dun htel. Quelle(s) phrase(s) simple(s) dcri(ven)t lactivit 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.
Analyse du monde rel 29
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 consommations annexes (petits djeuners, tlphone).
Une rservation est caractrise par une date de dbut, un nombre de jours et le versement dune avance ventuelle.
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 reprsentation. 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 graphique 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.
30
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 didentifiant 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.
Occurrences chambre
Entit chambre
Chambre
Chambre
13
# IDChambre
NombrePlaces
75
Tarif
Chambre
Chambre
176
1
123
2
40
55
Le choix de lidentifiant nest pas toujours trivial. Il est parfois ncessaire dintroduire artificiellement 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+prnom+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 recommand, 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 identifiant dont les contenus ne sont pas susceptibles dvoluer au fil du temps. On prfre identifier 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.
Client
# IDClient
Nom
Adresse
NumTlphone
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 associes 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.
Chambre
# IDChambre
NombrePlaces
Tarif
Client
Location
DateDbut
NombreJours
# IDClient
Nom
Adresse
NumTlphone
Il peut galement y avoir plus dune association entre deux entits ; cest le cas de lexemple de lhtel (voir figure 2.4). Les entits client et chambre sont relies par deux associations ayant des attributs diffrents : location et rservation.
Figure 2.4
Entits client et
chambre relies
par les
associations
location et
rservation.
Chambre
# IDChambre
NombrePlaces
Tarif
Client
Location
DateDbut
NombreJours
# IDClient
Nom
Adresse
NumTlphone
Rservation
DateDbut
NombreJours
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.
32
Chapitre
Figure 2.5
Client
Entit personne
relie par
lassociation
est_mari_.
# IDPersonne
Nom
Adresse
NumTlphone
Est mari
DateMariage
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 ciaprs (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
Chambre
Cardinalits dune
association
binaire.
# IDChambre
NombrePlaces
Tarif
Client
0,n
Location
DateDbut
NombreJours
1,n
# IDClient
Nom
Adresse
NumTlphone
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 propritaire.
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 ventuellement 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 cardinalit 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.
Figure 2.7
Chambre
Entits client,
chambre et
association
location avec
cardinalit.
# IDChambre
NombrePlaces
Tarif
Client
0,n
Location
DateDbut
NombreJours
1,n
# IDClient
Nom
Adresse
NumTlphone
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.
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 dpendances entre les attributs, est dtaill au chapitre 3.
Recherche des cardinalits

Les cardinalits sont dduites des deux dernires phrases :
34
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) .
Chapitre
Figure 2.8
Entits voiture et
client lies par
lassociation
vente avec
cardinalits.
Client
NumAch
Nom
ge
Ville
Sexe
1,n
Voiture
Vente
DateVente
Prix
0,1
# NumVoit
Marque
Type
Couleur
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 premire approche. Le processus itratif de cette remise en cause peut conduire un redcoupage 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
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).
Livre
Titre
Auteur
#ISBN
diteur
Emprunte
DateEmprunt
Lecteur
# NumLecteur
Nom
Prnom
Adresse
Cet exemple simple permet de se poser quelques questions qui vont conduire une rorganisation 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 exemplaires 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 caractris 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 dcompos en deux autres entits dont une est abstraite : louvrage. Louvrage est un regroupement dattributs qui na pas dexistence tangible dans le monde rel.
36
Chapitre
Figure 2.10
Ouvrage
Entits livre,
ouvrage et
lecteur lies par
les associations
emprunte et est
un exemplaire
(sans
cardinalits).
#Cote
ISBN
Lecteur
Emprunte
DateEmprunt
# NumLecteur
Nom
Prnom
Adresse
Est un
exemplaire
Livre
Titre
Auteur
#ISBN
diteur
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
Emprunte
# NumLecteur
Nom
Prnom
Adresse
DateEmprunt
Est un
exemplaire
Livre
Titre
#ISBN
diteur
Auteur
A crit
# NumAuteur
Nom
Prnom
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 lemprunteur. 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 opration conduit une association entre les entits personne et livre (emprunte) et les entits 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).
Ouvrage
#Cote
ISBN
Personne
Emprunte
# NumLecteur
Nom
Prnom
Adresse
DateEmprunt
Est un
exemplaire
Livre
A crit
Titre
#ISBN
diteur
On a identifi dans cette sous-section plusieurs cas qui ncessitent de rorganiser les entits obtenues lors dune premire analyse :
Si lon repre lintrieur dune entit des attributs qui reprsentent un ensemble logique (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, MasterCard), 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
38
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.
Carte
#NumCarte
Type
DateValidit
Propritaire
Facture
1,1
# NumFacture
Montant
DateFacture
Rgle
1,1
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.
# NumFacture
Montant
DateFacture
NumCarte
Type
DateValidit
Propritaire
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.
0,n
Musicien
#NumMusicien
Nom
Prnom
Batterie
0,n
Piano
0,n
Morceau
0,n
# NumMorceau
Titre
0,n
0,n
0,n
Basse
0,n
Saxophone
Comme il sagit de la mme activit (un musicien interprte un morceau), on peut remplacer toutes les associations par une association interprte. Lassociation interprte contiendrait lattribut instrument pour ne pas perdre linformation de linstrument associ (voir
figure 2.16).
Figure 2.16
Entits musicien
et morceau lies
par lassociation
interprte.
Musicien
#NumMusicien
Nom
Prnom
Morceau
1,n
Interprte
# NumMorceau
Titre
Instrument
1,n
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 morceau, il ne sagit pas de la mme activit que lassociation interprte : on ne fusionnera pas les
associations dans ce cas.
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 itratif 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.
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 (unification) 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 profile 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 relationnelles-objet en bases de donnes ont t introduites dans le premier chapitre et dpassent largement 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 passage au SGBD, allant jusqu la gnration de code SQL. UML offre des garanties de prennit 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 largement rpandu et permet dutiliser le mme formalisme et les mmes outils que les concepteurs dapplications logicielles.
40
Chapitre
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.
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 structure 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 description 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 correspondant aux trois parties prcdentes (voir figure 2.17).
Figure 2.17
Voiture
Entit voiture
reprsente par
une classe UML.
# NumVoit
Marque
Type
Couleur
Nom de la classe
Attributs
Mthodes
Associations et multiplicit
Les classes sont relies par des associations identifies par leur nom. Si lassociation possde 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).
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.
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
1..*
0..1
# NumVoit
Marque
Type
Couleur
Vente
DateVente
Prix
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 dassociation de degr suprieur aux associations binaires.
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 chacune des classes impliques dans une association, on dispose alors dune description complmentaire. 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 emplacement 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.
Client
NumAch
Nom
ge
Ville
Sexe
Voiture
Acheteur
Dpense
# NumVoit
Marque
Type
Couleur
4.3 DU MODLE ENTIT-ASSOCIATION UML

La notation UML est utilise dans cette section pour reprsenter les entits et les associations issues de la dmarche danalyse primitive que lon a dcrite dans la premire sec-
42
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 assistent, 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 informations 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 grandes 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 ncessitent 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.
Exercices
EXERCICE 1
IDENTIFIANT DUNE ENTIT

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 ?

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. Classiquement, on utilisera un chiffre identifiant que lon peut nommer Numero_salle.
EXERCICE 2
IDENTIFICATION DES ENTITS ET DES ASSOCIATIONS

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 attributs que vous utiliseriez pour dcrire ces entits et leurs associations ainsi que les identifiants de chaque entit. Que se passe-t-il si le prix du billet varie pour chaque sance et
en fonction de la place ?
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 identifiant numero_client puisque nom et numro de tlphone ne sont pas identifiants. On
44
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 caractristiques de laction dachat et non pas du spectateur ou de la pice (voir figure 2.20).
Figure 2.20
Spectateur
Entits
spectateur et
pice lies par
lassociation
achat (sans
cardinalits).
# Num
Achat
Nom
Pice
DateAchat
NumSiege
Tel
# NumPiece
Titre
Auteur
MetteurScene
Prix
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 parvenu 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
Ouvrage
#Cote
ISBN
Personne
Emprunte
# NumLecteur
Nom
Prnom
Adresse
DateEmprunt
Est un
exemplaire
Livre
Titre
#ISBN
diteur
A crit
Exercices
Entits livre,
ouvrage, personne
lies par les associations emprunte,
a_crit et
est_un_exemplaire
(sans cardinalits).
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.
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 quatre 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 maximale 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 minimale 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 maximale 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 :
46
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.
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 :
Figure 2.22
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 plusieurs livres.
Ouvrage
Entits livre,
ouvrage,
personne lies
par les
associations
emprunte,
a_crit et
est_un_exemplaire
(avec
cardinalits).
0,n
#Cote
ISBN
DateEmprunt
1,n
1,n
# NumLecteur
Nom
Prnom
Adresse
0,n
Est un
exemplaire
A crit
Livre
1,1
EXERCICE 4
Personne
Emprunte
Titre
#ISBN
diteur
1,n
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
Th me
# NumThme
Libell
0,n
Sminaire
Traite
1,1
1,n
1,1
# NumSminaire
DateSem
NbeJours
NbeInscrits
Prix
Anime
Salaire
NbeHeures
Intervient
0,n
# NumInter
Nom
Prnom
Est_responsable
Prime
0,n
Exercices
Entits
sminaire,
thme,
intervenant
lies par les
associations
traite,
est_responsable
et intervient
(avec
cardinalits).
Quelle description pouvez-vous donner du lien entre les diffrentes entits partir des
cardinalits ?
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 intervenir 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 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 ?
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 gnralement 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 parasitehte lies par
lassociation
utilise et fusion
en une entit
unique.
Parasite
# NumParasite
1,1
Utilise
NomPara
Hte
1,1
# NumHte
NomHte
cosystme
# NumHte
NomHte
NumParasite
NomPara
48
Chapitre
EXERCICE 6
ASSOCIATION RFLEXIVE
On veut reprsenter les liens de nourriture entre des humains, des animaux et des vgtaux. 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 .
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
vgtal
Entit
humain_animal
_vgtal lie par
lassociation
mange (avec
cardinalits).
0,n
# IdHAV
NomHAV
Mange
0,n
ASSOCIATION TERNAIRE
partir de la base de donnes exemple de vente de voitures, on souhaite ajouter les informations concernant le vendeur qui a ralis la vente. Proposez une (ou plusieurs) modification(s) du modle entit-association labor prcdemment. Ajoutez les nouvelles
cardinalits introduites par cette modification.
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.
Exercices
EXERCICE 7
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 cardinalits 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).
Client
NumAch
Nom
ge
Ville
Sexe
0,n
Voiture
Vente
DateVente
Prix
0,1
0,n
# NumVoit
Marque
Type
Couleur
Vendeur
# NumVendeur
Nom
Tl
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
1,n
Voiture
Vente
1,1
# NumVente
DateVente
Prix
1,1
Vendeur
# NumVendeur
Nom
1,n
Tl
50
1,1
0,1
# NumVoit
Marque
Type
Couleur
Chapitre
DE LNONC AU MODLE ENTIT-ASSOCIATION

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 principaux. 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 dbiter 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 daffaires 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.
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 catgorie 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, prnom, adresse, tl., etc.). Il est ncessaire dutiliser un attribut pour lidentifiant : ici, NumClient.
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, NumFilm.
Entit personnel
Lentit ne comprend que les informations nom et prnom. Il est galement ncessaire de
crer un attribut pour lidentifiant : ici, NumPers.
Exercices
EXERCICE 8
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 identifiant, 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
Location
Entits clients,
film, personnel
lies par les
associations
rservation,
location, joue et
ralise (sans
cardinalits).
# NumLoc
NbeJourLoc
DateLoc
Client
Film
# NumClient
NomClient
PrnomClient
AdresseClient
TlClient
Compte
Rservation
# NumFilm
Titre
Genre
Prix
NbDVD
# NumRs
NbeJourRs
DateRs
Joue
Personnel
# NumPers
NomPers
PrnomPers
EXERCICE 9
REPRSENTATION AVEC
Ralise
UML
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.
Les entits sont reprsentes par des classes UML. Les associations sont reprsentes par
des associations UML. Les associations location et rservation qui possdent des attributs seront munies dune classe UML sans nom qui permet dutiliser ces attributs. Les cardinalits 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 :
52
Un client rserve aucun ou plusieurs films (0..n).
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
0..n
Client
Reprsentation
UML des entits
clients, film,
personnel lies
par les
associations
reservation,
location, joue et
ralise (avec
cardinalits).
0..n
# NumClient
NomClient
PrnomClient
AdresseClient
TlClient
Compte
# NumFilm
Titre
Genre
Prix
NbDVD
# NumLoc
NbeJourLoc
DateLoc
0..n
0..n
Rservation
0..n
0..n
# NumRs
NbeJourRs
DateRs
Personnel
# NumPers
NomPers
PrnomPers
AUTRE EXEMPLE
1..n
Joue
Ralise
1..n
LE CAMPING LULIASTRU
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 locations sadresse un maximum de quatre personnes. Proposez un modle entit-association modlisant cette activit de gestion en fonction des lments de lnonc.
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).
Exercices
EXERCICE 10
Film
Location
On en dduit les entits Sjour et Client, ainsi que lassociation Louer. La premire difficult 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 sexpriment 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 consquent, 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.
54
Chapitre
Approche
relationnelle
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 (entitassociation 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.
55
Concepts
Cette section expose la notion de relation et la terminologie qui lui est associe. On prsente 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 lments. 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 contenues 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 (horrible) 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 galement 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.
56
Chapitre
Figure 3.1
Table
ma_cuisine.
Appareil
Couleur
Rfrigrateur
Rouge
Robot
Mauve
Cuisinire
Jaune
Lave-vaisselle
Rouge
1.2 NOTION DE CL DUNE RELATION ET DPENDANCE FONCTIONNELLE

Lorsque que lon utilise une base de donnes, il est ncessaire daccder un enregistrement 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 minimum 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 prjuger du contenu futur des enregistrements. Si lon prend la relation ma_cuisine vue prcdemment, 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 considre 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 relation vont tre importantes : on exprime ces relations laide de dpendances fonctionnelles. Une dpendance fonctionnelle existe entre deux ensembles de champs si les valeurs
contenues dans lun des ensembles de champs permettent de dterminer les valeurs contenues 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 Lecteur(Numero_carte, Nom, Age, Ville, Etablissement). Cet exemple modlise les lecteurs
dune bibliothque.
Approche relationnelle 57
Figure 3.2
Relation Lecteur.
Numero
_carte
Nom
Age
Ville
Etablissement
Henri
10
Paris
Universit Sorbonne
Stanislas
34
Paris
Universit Jussieu
Henriette
44
Lyon
CHU Bron
Dominique
19
Nancy
Universit Poincar
Isabelle
56
Nancy
INPL
Olivier
51
Marseille
Universit Saint Charles
Henri
98
Paris
Universit Sorbonne
Jerome
23
Nancy
INPL
Laurence
34
Bordeaux
Universit Victor Segalen
10
Christian
41
Paris
Ecole Normale Suprieure
11
Antoine
16
Marseille
12
Laurence
34
Paris
Universit Jussieu
Si lon examine les donnes, on remarque quil ne peut y avoir de dpendances fonctionnelles 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 dpendance entre les champs Etablissement et Ville. Le contenu des champs Ville et Etablissement 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.
Remarque
Tous les champs qui ne font pas partie dune cl candidate dune relation possdent des dpendances fonctionnelles avec cette cl.
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 enregistrements prsents dans la relation se conforment ces dpendances. La dtermination des
dpendances fonctionnelles entre les champs est fondamentale pour ltape de normalisation, traite la section Normalisation . Elles sont galement la base de la mthode
dite de la relation universelle , qui sera aborde dans la section Normalisation .
58
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 rpercut 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 dincohrences 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 rsolues par la rorganisation des relations lors de la phase de normalisation.
Oprations du modle relationnel

La manipulation des donnes dans le modle relationnel se fait laide doprations formelles reposant sur des concepts mathmatiques issus de la thorie des ensembles : cest
lalgbre relationnelle. Les oprations de lalgbre relationnelle portent sur une ou plusieurs relations (ou tables). Le rsultat retourn par ces oprations est toujours une relation (ou table).
Cette section prsente une liste non exhaustive des diffrentes oprations de lalgbre relationnelle. 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 oprations 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 ensembles. 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.
Figure 3.3
Relations
Lecteur_1et
Lecteur_2.
Lecteur_1(Numero_carte, Nom, Age, Ville, Etablissement)

Numero_carte
Nom
Age
Ville
Etablissement
Henri
10
Paris
Universit
Sorbonne
Stanislas
34
Paris
Universit
Jussieu
Henriette
44
Lyon
CHU Bron
Lecteur_2(Numero_carte, Nom, Age, Ville, Etablissement)
60
Numero_carte
Nom
Age
Ville
Etablissement
Henriette
44
Lyon
CHU Bron
Dominique
19
Nancy
Universit Poincar
Isabelle
56
Nancy
INPL
Chapitre
Figure 3.4
Union des
relations
Lecteur_1 et
Lecteur_2.
Lecteur_1 Lecteur_2
Numero_carte
Nom
Age
Ville
Etablissement
Henri
10
Paris
Universit
Sorbonne
Stanislas
34
Paris
Universit
Jussieu
Henriette
44
Lyon
CHU Bron
Dominique
19
Nancy
Universit
Poincar
Isabelle
56
Nancy
INPL
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 dliminer des enregistrements dune relation par rapport une liste.
Figure 3.5
Diffrence des
relations
Lecteur_1 et
Lecteur_2.
Lecteur_1 Lecteur_2
Numero_carte
Nom
Age
Ville
Etablissement
Henri
10
Paris
Universit
Sorbonne
Stanislas
34
Paris
Universit
Jussieu
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.
Figure 3.6
Intersection des
relations
Lecteur_1 et
Lecteur_2.
Lecteur_1 Lecteur_2
Numero_carte
Nom
Age
Ville
Etablissement
Henriette
44
Lyon
CHU Bron
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 .
Figure 3.7
ma_cuisine(Appareil, Couleur)
Relations
ma_cuisine et
musicien.
Appareil
Couleur
Rfrigrateur
rouge
Robot
mauve
Cuisinire
jaune
Nom
Instrument
Jaco Pastorius
Basse
lectrique
Bill Evans
Piano
musicien(Nom, Instrument)
Lexemple a t choisi de manire montrer que les relations ne ncessitent pas de rapports 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).
Figure 3.8
Le_resultat(Appareil, Couleur, Nom, Instrument) = ma_cuisine(Appareil, Couleur) X

musicien(Nom, Instrument)
Produit cartsien
des relations
ma_cuisine et
musicien.
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
2.2 OPRATIONS RELATIONNELLES

Projection
La projection consiste extraire certains champs de la relation, ce qui donne cette dernire un degr infrieur la relation de dpart. Voici la relation obtenue partir de la relation Lecteur en projetant les champs Nom et Ville (voir figure 3.9).
Figure 3.9
Lecteur_proj(Nom, Ville)
Projection des
champs Nom et
Ville de la
relation Lecteur.
62
Nom
Ville
Henri
Paris
Stanislas
Paris
Chapitre
Nom
Ville
Henriette
Lyon
Dominique
Nancy
Isabelle
Nancy
Olivier
Marseille
Henri
Paris
Jerome
Nancy
Laurence
Bordeaux
Christian
Paris
Antoine
Marseille
Laurence
Paris
Intuitivement, dans une reprsentation de type table, on conserve uniquement les colonnes 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.
Figure 3.10
Slection sur la
relation Lecteur.
Lecteur_sel(Numero_carte, Nom, Age, Ville, Etablissement)

Numero_carte
Nom
Age
Ville
Etablissement
Olivier
51
Marseille
Universit Saint
Charles
11
Antoine
16
Marseille
Universit Saint
Charles
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 dexprimer 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).
Figure 3.11
Lecteur_bis(Numero_carte, Nom, Num_Etablissement)
Relations
Lecteur_bis et
Etablissement.
Numero_carte
Nom
Num_Etablissement
Henri
Stanislas
Henriette
Etablissement(Num Etablissement, Ville, Nom_Etablissement)

Num_Etablissement
Ville
Nom_Etablissement
Paris
Universit Jussieu
Lyon
CHU Bron
Nancy
Universit Poincar
Paris
Universit Sorbonne
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 ltablissement 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 informations concernant leur tablissement, on effectue une jointure entre ces relations sur le
champ Num_Etablissement (voir figure 3.12).
Figure 3.12
Jointure des
relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.
Lecteur_joint_Etablissement(Numero_carte, Nom, Num_Etablissement_1,

Num_Etablissement_2, Ville, Nom_Etablissement)
Numero
_carte
Nom
Num_Etablissement_1
Num_Etablissement_2
Ville
Nom
_Etablissement
Henri
Paris
Universit Jussieu
Stanislas
Lyon
CHU Bron
Henriette
Paris
Universit Jussieu
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).
Figure 3.13
Jointure naturelle
des relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.
64
Lecteur_jointnat_Etablissement(Numero carte, Nom, Num_Etablissement, Ville,

Nom_Etablissement)
Numero_carte
Nom
Num
_Etablissement
Ville
Nom
_Etablissement
Henri
Paris
Universit
Jussieu
Stanislas
Lyon
CHU Bron
Henriette
Paris
Universit
Jussieu
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).
Figure 3.14
Produit cartsien
des relations
Lecteur_bis et
Etablissement.
Produit_cartesien_Etablissement(Numero_carte, Nom, Num_Etablissement_1,

Num_Etablissement_2, Ville, Nom_Etablissement)
Numero
_carte
Nom
Num_Etablissement_1
Num
_Etablissement
Ville
Num_Etablissement_2
Henri
Paris
Universit
Jussieu
Henri
Lyon
CHU Bron
Henri
Nancy
Universit Poincar
Henri
Paris
Universit
Sorbonne
Stanislas
Paris
Universit
Jussieu
Stanislas
Lyon
CHU Bron
Stanislas
Nancy
Universit Poincar
Stanislas
Paris
Universit
Sorbonne
Henriette
Paris
Universit
Jussieu
Henriette
Lyon
CHU Bron
Henriette
Nancy
Universit Poincar
Henriette
Paris
Universit
Sorbonne
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 Etablissement 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.
Figure 3.15
Etablissement_jointext_ Lecteur(Num_Etablissement_1, Ville, Nom_Etablissement,

Numero_carte,
Nom, Num_Etablissement_2)
Jointure externe
des relations
Lecteur_bis et
tablissement
sur le champ
Num
_Etablissement.
Num_Etablissement_1
Ville
Nom
_Etablissement
Numero
_carte
Nom
Num_Etablissement_2
Paris
Universit Jussieu
Henri
Lyon
CHU Bron
Stanislas
Nancy
Universit Poincar
NULL
NULL
NULL
Paris
Universit Sorbonne
NULL
NULL
NULL
Ici, les valeurs 3 et 4 du champ Num_Etablissement_1 provenant de la relation Etablissement 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).
Figure 3.16
Etablissement_jointext_Lecteur_selproj(Nom_Etablissement)
Slection et
projection sur la
jointure externe
des relations
Lecteur_bis et
Etablissement
sur le champ
Num
_Etablissement.
Nom
_Etablissement
Universit Poincar
Universit
Sorbonne
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 relation Etablissement fait office de relation de rfrence pour le champ
Num_Etablissement de la relation Lecteur. Lopration de jointure externe peut tre utilise 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 prsentes 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
66
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].
Figure 3.17
Relation
La_boutique.
La_boutique(Num_Facture, Article, Prix, Quantite)

Num_Facture
Article
Prix
Quantite
101
Bananes
12
45
1034
Choux
129
2345
Riz
60
0987
Gazelle
15
48
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).
Figure 3.18
Relation
La_boutique
avec le champ
calcul Total.
La_boutique_total(Num_FactureArticle, Prix, Quantite, Total)

Num_Facture
Article
Prix
Quantite
Total
101
Bananes
12
45
540
1034
Choux
129
645
2345
Riz
60
240
0987
Gazelle
15
48
720
Il est galement possible deffectuer des oprations statistiques globales dun champ,
comme les calculs du nombre denregistrements, de moyenne, de maximum, de minimum. 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 toujours une relation (voir figure 3.19).
Figure 3.19
La_boutique_moyenne(Moyenne_Prix)
Moyenne des prix

de la relation
La_boutique.
Moyenne_Prix
9
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 sousrelation ainsi constitue une opration statistique, dans notre cas lopration de comptage
(voir figure 3.20).
Figure 3.20
Agrgat par ville
de la relation
La_boutique.
Lecteur_parville(Ville, Nombre)
Ville
Nombre
Bordeaux
Lyon
Ville
Nombre
Marseille
Nancy
Paris
Passage du modle conceptuel au relationnel

On a expos au chapitre sur lanalyse du monde rel deux formalismes diffrents entitassociation 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 directement 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 relation 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 entitassociation de la
base de donnes
casse.
Client
NumAch
Nom
Age
Ville
Sexe
1,n
Voiture
Vente
DateVente
Prix
0,1
# NumVoit
Marque
Type
Couleur
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).
68
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
Seminaire
base de donnes
animation de
sminaire.
# NumSeminaire
DateSem
NbeJours
Prix
1,n
1,1
Anime
Salaire
NbeHeures
Intervenant
0,n
# NumInter
NomInter
TelInter
Est responsable
Prime
0,n
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, NumInter, 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
relation cre pour lentit qui est associe avec la cardinalit 1-1. La cl de cette relation est toujours celle de lentit.
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.
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 plupart 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 relationnel 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).
70
Chapitre
Figure 3.23
Relation
Publication avec
un champ
multivalu.
Publication(NumPubli, Titre, Auteurs)

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
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 dcomposer cette relation en trois relations : Publication(NumPubli, Titre), Auteur(NumAuteur,
Nom, Prenom) et EstEcrite(NumPubli, NumAuteur). Ces trois relations sont la reprsentation 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).
Figure 3.24
Dcomposition de
la relation
Publication en
trois relations.
Publication(NumPubli, Titre)
NumPubli
Titre
13490
Le vin et
lavenir
21322
Bire et
progrs social
45333
Le champagne
et la France
Auteur(NumAuteur, Nom, Prenom)

NumAuteur
Nom
Prenom
Lasso
Jean
De la Tuque
Hubert
Wilski
Stanislas
Salem
Aristide
Dupont
Salome
Light
Penelope
Martinez
Vanessa
EstEcrite(NumPubli, NumAuteur)
NumPubli
NumAuteur
13490
13490
13490
21322
21322
21322
45333
45333
45333
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).
Figure 3.25
Produit(Article, Fournisseur, Adresse, Prix)
Relation Produit.
Article
Fournisseur
Adresse
Prix
Marteau
SOGENO
Paris
Tournevis
ARTIFACT
Lille
10
Tournevis
SOGENO
Paris
23
Pince
LEMEL
Paris
34
Mtre
ARTIFACT
Lille
24
La cl est constitue des champs Article et Fournisseur. Or, il y a une relation de dpendance 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
72
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 dpendants constituent le reste de la relation. Il sagit ici du champ Adresse.
On obtient alors le rsultat suivant (voir figure 3.26).
Figure 3.26
Produit(Article, Fournisseur, Prix)
Dcomposition de
la relation
Produit pour
passer en
deuxime forme
normale.
Article
Fournisseur
Prix
Marteau
SOGENO
Tournevis
ARTIFACT
10
Tournevis
SOGENO
23
Pince
LEMEL
34
Mtre
ARTIFACT
24
Fournisseur(Fournisseur, Adresse)
Fournisseur
Adresse
SOGENO
Paris
ARTIFACT
Lille
LEMEL
Paris
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linformation. La dcomposition en deux relations se fait sans perte dinformation.
Remarque
Si la cl dune relation est atomique, cest--dire compose dun seul champ, elle est naturellement en deuxime forme normale.
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 nouvelle 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).
Figure 3.27
Baladeur(NumBal, Marque, Type, Couleur)
Relation
Baladeur.
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
La cl de cette relation est un numro, NumBal, car il peut y avoir dans notre stock plusieurs baladeurs de mme marque, de mme type et de mme couleur. Les marques dposent 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 nouvelle relation sont composs des champs qui en dpendent fonctionnellement : ici, le
champ Marque (voir figure 3.28).
Figure 3.28
Baladeur(NumBal, Type, Couleur)
Dcomposition de
la relation
Baladeur pour
passer en
troisime forme
normale.
NumBal
Type
Couleur
12
Ipod
Blanc
43
Zen
Noir
23
Ipod
Noir
29
Zen
Gris
34
MZ-RH910
Rouge
Baladeur_type(Type, Marque)
Type
Marque
Ipod
Apple
MZ-RH910
Sony
Zen
Creative
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linformation dans son intgralit. La dcomposition en deux relations se fait sans perte
dinformation.
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.
74
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 BoyceCodd , 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 envisageables compte tenu des liens de dpendances multiples entre les diffrents champs. On choisit la dcomposition qui permet de reconstituer strictement linformation dorigine sans
gnrer de donnes supplmentaires. La perte dune dpendance fonctionnelle est frquente lors de cette opration. La relation cre a pour cl la partie de celle-ci dont dpendent les autres champs constituant la dpendance.
On considre la relation suivante (voir figure 3.29).
Figure 3.29
Relation
Dictaphone.
Dictaphone(Marque, 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
La cl de cette relation est constitue par les champs Marque et Produit. En effet, un produit est fabriqu sous licence par la socit ImaginR et a donc le mme nom que celui propos 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).
Figure 3.30
Relation
Dictaphone
dcompose pour
passer en forme
de Boyce-Codd.
Dictaphone(Produit, Prix, Couleur)

Produit
Prix
Couleur
LD 1024
49
Blanc
VN 1664
49
Noir
LD 5647 H
59
Blanc
Produit
Prix
Couleur
VN 1664
69
Gris
VN 234 PC
79
Rouge
Marque_coul(Couleur, Marque)
Couleur
Marque
Blanc
Philips
Noir
Olympus
Gris
ImaginR
Rouge
Olympus
On a perdu la dpendance de Couleur par rapport Marque, Produit.
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 prsente 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 langage 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 prdicat qui exprime le lien entre diffrents lments. La validit de ce prdicat est gnralement 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 appartiennent tous deux la mme chane alimentaire .
76
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))
meme_chaine_alimentaire(x,y)))
a b donne a b
x y ((mange(x,y)
meme_chaine_alimentaire(x,y))
meme_chaine_alimentaire(x,y))
((mange(y,x)
(mange(y,x)
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 relationnelles 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 prcdemment pour arriver un ensemble de clauses simples. On constitue ensuite des sous-ensembles 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 exprimes 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 voiture(NumVoit, Marque, Type, Couleur) et le schma de la relation vente est vente(DateVent, 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 voiture sont reprsentes par les variables m et t. Le signe _ reprsente nimporte quelle
valeur des autres champs NumVoit et de Couleur.
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 identiques, 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 relationnelle dans les laboratoires dIBM, un premier sous-produit a t conu : le langage dinterrogation 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 section 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).
Figure 3.31
Afficher la liste des marques et des types de voitures :

{ (m,t) | voiture(_,m,t,_) }
Projection du
champ Marque
dans un QBE.
NumVoit
78
Marque
Type
Couleur
Les critres de slection se font par des valeurs exemples (voir figures 3.32 et 3.33).
Chapitre
Figure 3.32
Afficher le type des voitures de couleur rouge :

{ (t) | voiture(_,_,t,rouge) }
Slection sur un
contenu et
projection dans un
QBE.
Figure 3.33
NumVoit
Marque
Type
Couleur Rouge
Afficher les prix de vente suprieurs 10 000 :

{ (p) | vente(_,p,_,_) p > 10000 }
Slection sur un
critre et
projection dans un
QBE.
DateVent
Prix
NumAch
NumVoit
> 10 000
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
Slection multicri- 1er janvier 1997 :
Figure 3.34
tre obligatoire et
projection dans
un QBE.
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
DateVent
> 01/01/1997
Prix
NumAch
NumVoit
> 10 000
Figure 3.35
Slection
multicritre
optionnel et
projection dans un
QBE.
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
1er janvier 1997 :
{ (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
DateVent
> 01/01/1997
Prix
NumAch
NumVoit
> 10 000
Figure 3.36
Jointure et
projection dans un
QBE.
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)}
NumVoit
Marque
Type
Couleur
Prix
NumAch
NumVoit
Nv
DateVent
Nv
Cette mthode dinterrogation simple et efficace est encore propose par de nombreux SGBD.
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 nommera 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 diffrence.
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 oprations 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 contraintes 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 :
80
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 ;
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 normale qui est plus restrictive.
La normalisation est une mthode de rorganisation qui consiste dcomposer une relation 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 normalise. Les deux tapes prcdentes de passage du modle conceptuel au schma relationnel 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 .
Exercices
EXERCICE 1
RELATION, DEGR, CARDINALIT

On considre deux relations. La premire Garage est de degr 7 et de cardinalit 3. La seconde Film est de degr 2 et de cardinalit 15. Quels sont le degr et la cardinalit du produit cartsien de Garage par Film ? Quels sont le degr et la cardinalit du produit
cartsien de Film par Garage ?
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 produit cartsien est gal la somme du nombre de champs des deux relations. Enfin, le produit 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
Quelle est la cl de cette relation (voir figure 3.37) ?
Film(Prix, Format, Type, Nombre)
Figure 3.37
Relation Film.
Prix
Format
Type
Nombre
12
4 :3
Couleur
16 :9
Noir/Blanc
12
16 :9
Couleur
1664
35
4 :3
Noir/Blanc
890
12
16 :9
Noir/Blanc
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
82
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 identifier un tuple. Une solution est dajouter un champ spcifique ; cest ce que proposent la plupart des SGBD lorsque vous ne dfinissez pas de cl pour une relation.
EXERCICE 3
CONTRAINTES DINTGRIT
On considre la relation Film(Prix, Format, Type, Nombre) de lexemple prcdent. Proposez 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 ?
Pour les champs de type numrique comme Prix et Nombre, on peut proposer des limites 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
Exprimez lintersection entre deux relations partir des oprations dunion et de diffrence. Donnez-en une illustration avec ses deux relations (voir figure 3.38).
ma_cuisine(Appareil, Couleur)
Relations
ma_cuisine et
sa_cuisine.
Appareil
Couleur
Rfrigrateur
rouge
Robot
mauve
Cuisinire
jaune
Appareil
Couleur
Rfrigrateur
mauve
Cuisinire
jaune
Hotte
bleue
sa_cuisine(Appareil, Couleur)
Pour raliser ces oprations, il faut que les relations possdent le mme schma. Lintersection entre deux ensembles peut se concevoir de la manire suivante en utilisant lop-
Exercices
Figure 3.38
rateur de diffrence : ma_cuisine sa_cuisine = ma_cuisine (ma_cuisine - sa_cuisine)

[voir figure 3.39].
Figure 3.39
ma_cuisine - sa_cuisine
Opration sur les

relations
ma_cuisine et
sa_cuisine.
Appareil
Couleur
Rfrigrateur
rouge
Robot
mauve
ma_cuisine (ma_cuisine - sa_cuisine)

Appareil
Couleur
Cuisinire
jaune
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
Trouver le prix et le type de tous les films de la relation Film vue prcdemment. Peuton en dduire que Prix & Type est une cl candidate, cest--dire que toute combinaison des valeurs du prix et du type dun film permet didentifier un film ?
Il sagit simplement dune projection sur les champs (voir figure 3.40).
Figure 3.40
Film_proj(Prix, Type)
Projection de la
relation Film.
Prix
Type
12
Couleur
Noir/Blanc
12
Couleur
35
Noir/Blanc
12
Noir/Blanc
Cette projection permet de mettre en vidence que Prix et Type nest pas une cl candidate, car il y a un doublon : le tuple (12, Noir/Blanc).
84
Chapitre
EXERCICE 6
RESTRICTION
Donnez le prix des films de la base films en Noir/Blanc . Quels sont le degr et la cardinalit de la relation obtenue ? Est-il possible de calculer ces valeurs lavance, comme
on le fait pour un produit cartsien ?
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).
Figure 3.41
Restriction et
projection de la
relation Film.
Prix
Format
Type
Nombre
12
4 :3
Couleur
16 :9
Noir/Blanc
12
16 :9
Couleur
1664
35
4 :3
Noir/Blanc
890
12
16 :9
Noir/Blanc
On obtient une relation de degr 1 et de cardinalit 2 (voir figure 3.42).

Figure 3.42
Film_NB(Prix)
Rsultat de la
restriction et de la
projection de la
relation Film.
Prix
4
35
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
On considre ces deux relations prsentes dans un exercice prcdent (voir figures 3.43
et 3.44).
Relation Film.
Film(Prix, Format, Type, Nombre, Numero_Film)

Prix
Format
Type
Nombre
Numero_Film
12
4/3
Couleur
16/9
Noir/Blanc
12
16/9
Couleur
1 664
50
35
4/3
Noir/Blanc
890
12
12
16/9
Noir/Blanc
12
Exercices
Figure 3.43
Catalogue(Numero_Film, Titre)
Figure 3.44
Relation
Catalogue.
Numero_Film
Titre
Le train qui passe
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 rfrentielle 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 ?
On fait une jointure entre les deux relations sur les champs Numero_Film (voir figure 3.45).
Figure 3.45
Jointure des
relations Film et
Catalogue.
Prix
Format
Type
Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12
4 :3
Couleur
Le train qui
passe
16 :9
Noir/Blanc
A toi !
35
4 :3
Noir/Blanc
890
12
12
Les impts
faciles
12
16 :9
Noir/Blanc
12
12
Les impts
faciles
On projette sur les champs Titre et Format (voir figure 3.46).

Figure 3.46
Projection sur la
jointure des
relations Film et
Catalogue.
Titre
Format
Le train qui
passe
4 :3
A toi !
16 :9
Les impts
faciles
4 :3
Les impts
faciles
16 :9
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.
86
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).
Figure 3.47
Jointure sans
objet des
relations Film et
Catalogue.
Prix
Format
Type
Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12
4 :3
Couleur
12
Les impts
faciles
16 :9
Noir/
Blanc
A toi !
12
16 :9
Couleur
1664
50
12
Les impts
faciles
12
16 :9
Noir/
Blanc
12
12
Les impts
faciles
Cette opration na aucune signification dans la ralit.
EXERCICE 8
AUTRE JOINTURE
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 relation Film ?
Figure 3.48
Jointure externe
des relations
Film et
Catalogue.
Prix
Format
Type
Nombre
Numero
_Film
(Films)
Numero
_Film
(Catalogue)
Titre
12
4 :3
Couleur
Le train qui
passe
16 :9
Noir/
Blanc
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
12
12
Les impts
faciles
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].
Exercices
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)
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.
Numero
_Film
50
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).
Numero
_Film
(Catalogue)
Titre
Prix
Format
Type
Nombre
Numero
_Film
(Film)
Le train qui
passe
12
4 :3
Couleur
A toi !
16 :9
Noir/
Blanc
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
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].
Figure 3.51
Titre
Slection et
projection de la
jointure externe
des relations
Catalogue et
Film.
Les chats du
Sngal
Le temps
expliqu
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

Quelle est la moyenne des prix pour les films par format ?
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
88
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 Format et le champ calcul Moyenne (voir figure 3.52).
Figure 3.52
Prix
Format
29,5
4 :3
9,3333
16 :9
Agrgat sur la
relation Film.
EXERCICE 10
PASSAGE DU MODLE ENTIT-ASSOCIATION AU RELATIONNEL

partir du modle entit-association modlisant une location de DVD, effectuez le passage au modle relationnel (voir figure 3.53).
Figure 3.53
Location
NbeJourLoc
DateLoc
0,n
Client
# NumClient
NomClient
PrenomClient
AdresseClient
TeleClient
Compte
0,n
Film
0,n
Reservation
NbeJourRes
DateRes
0,n
1,n
1,1
# NumFilm
Titre
Genre
Prix
NbDVD
Joue
Personnel
0,n
# NumPers
NomPers
PrenomPers
Realise
0,n
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).
Exercices
location de DVD.
On remarque que lassociation Realise a une cardinalit de type 1-1 lors de son association 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 relations. 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
partir du modle entit-association modlisant le lien de mariage, effectuez le passage

au modle relationnel (voir figure 3.54).
Figure 3.54
Modle entitassociation du
mariage.
Client
# IDPersonne
Nom
Adresse
NumTlphone
0,n
Est mari
DateMariage
0,n
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.
90
Chapitre
EXERCICE 12
NORMALISATION
Cette relation est-elle en premire forme normale (voir figure 3.55) ?
Personne(Nom, Adresse_mail, Poste)
Figure 3.55
Relation
Personne.
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
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 rpartition 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)
Relation
Personne
modifie.
Ident
_Personne
Nom
Poste
Adresse_mail1
Adresse_mail2
Andr
Dupont
Directeur
adup@philips.com
andre@dupond.fr
Stanislas De
la Motte
Employ,
asserment
Elisabeth
Macroix
Assistante
elsa@yago.to
mac@rien.fr
Exercices
Figure 3.56
EXERCICE 13
NORMALISATION
II
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)
Figure 3.57
Prix
Format
Type
Nombre
Numro_Film
Support
Relation Film
avec support.
12
4 :3
Couleur
VHS
16 :9
Noir/Blanc
DVD
12
16 :9
Couleur
1664
56
DVD
35
4 :3
Noir/Blanc
890
12
VHS
12
16 :9
Noir/Blanc
12
DVD
99
Inconnu
Noir/Blanc
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 ?
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)
Figure 3.58
Dcomposition de
la relation Film
avec support.
Prix
Format
Type
Nombre
Numero Film
12
4 :3
Couleur
16 :9
Noir/Blanc
12
16 :9
Couleur
1664
50
35
4 :3
Noir/Blanc
890
12
12
16 :9
Noir/Blanc
12
FormatSup(Format, Support)
92
Format
Support
4 :3
VHS
16 :9
DVD
Inconnu
VHS
Chapitre
Les relations sont en premire et en deuxime forme normale. On effectue une jointure
pour reconstituer linformation de dpart.
EXERCICE 14
NORMALISATION
III
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)
Figure 3.59
Numro carte
Nom
Age
Ville
Etablissement
Henri
10
Paris
Universit
Sorbonne
Stanislas
34
Paris
Universit Jussieu
Henriette
44
Lyon
CHU Bron
Dominique
19
Nancy
Universit
Poincar
Isabelle
56
Nancy
INPL
Olivier
51
Marseille
Universit
Saint Charles
Henri
98
Paris
Universit
Sorbonne
Jerome
23
Nancy
INPL
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
Relation Lecteur .
Est-elle en troisime forme normale ?

La relation est en premire forme normale, il ny a pas de champs multivalus.
Il existe une dpendance fonctionnelle entre deux champs non cl Ville et Etablissement (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).
Exercices
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.
Figure 3.60
Relation Lecteur
dcompose I.
Lecteur(Numero_carte, Nom, Age, Etablissement)

Numero carte
Nom
Age
Etablissement
Henri
10
Universit Sorbonne
Stanislas
34
Universit Jussieu
Henriette
44
CHU Bron
Dominique
19
Universit Poincar
Isabelle
56
INPL
Olivier
51
Henri
98
Universit Sorbonne
Jerome
23
INPL
Laurence
34
Universit Victor
Segalen
10
Christian
41
Ecole Normale
Suprieure
11
Antoine
16
12
Laurence
34
Universit Jussieu
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.
Figure 3.61
Etablissement_Ville(Etablissement, Ville)
Relation Lecteur
dcompose II.
Etablissement
Ville
Universit Sorbonne
Paris
Universit Jussieu
Paris
CHU Bron
Lyon
Universit Poincar
Nancy
INPL
Nancy
Marseille
Universit Victor
Segalen
Bordeaux
cole Normale
Suprieure
Paris
Les deux relations sont en troisime forme normale. On effectue une jointure pour
reconstituer linformation de dpart.
94
Chapitre
SQL
1. Concepts du langage SQL ........96

2. Oprations relationnelles
avec SQL .................................97
3. Gestion de tables et de vues ....110
Le langage SQL est lun des lments qui ont

contribu au dveloppement et au succs de
lapproche relationnelle dans le monde des bases de
4. Gestion des donnes ..............116
donnes. En effet, la normalisation internationale du
Exercices
langage garantit la prennit et la stabilit des
1. Projection simple ....................120
donnes ainsi que des dveloppements qui leur sont
2. Projection avec une colonne

calcule .................................120
associs, indpendamment du SGBD et du langage
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
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.
14. Modification des donnes

dune table ............................125
15. Requte combine ..................125
95
Concepts du langage SQL

Le langage SQL est essentiellement un sous-produit issu des travaux du groupe de travail System-R. Il sagissait de la ralisation pratique des concepts de lapproche relationnelle 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 essentiellement 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 langage garantit la portabilit gnrale des applications dun SGBD un autre, mme sil subsiste 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 dinstructions de structuration, telles que des boucles. Pour effectuer ce type doprations, on utilise 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 spcifique. 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 programmation. Enfin, il existe une extension procdurale de SQL qui ajoute les fonctions, procdures 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 ; .
96
Chapitre
Figure 4.1
Programme en
Interface entre
SQL et les
langages de
programmation.
langage hte
+
code SQL
Bibliothque
fonctions SQL
SGBD
1.1 ORGANISATION DU CHAPITRE

Linterrogation dune ou de plusieurs tables est aborde dans la section Oprations relationnelles 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 section. 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).
Remarque
Par convention, dans tous les exemples qui suivent, les instructions SQL sont indiques en majuscules afin de les diffrencier des noms de tables et de champs. Les interprteurs SQL ne diffrencient 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.
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 description prcise de ces oprations se trouve au chapitre 3. Les exemples simples qui prsentent les oprations relationnelles utilisent la base de donnes casse (voir figure 4.2).
SQL 97
Figure 4.2
Voiture
Base de donnes
casse.
NumVoit
Marque
Type
Type
Peugeot
404
Rouge
Citroen
SM
Noire
Opel
GT
Blanche
Peugeot
403
Blanche
Renault
Alpine A310
Rose
Renault
Floride
Bleue
Personne
NumAch
Nom
Age
Ville
Sexe
Nestor
96
Paris
Irma
20
Lille
Henri
45
Paris
Josette
34
Lyon
Jacques
50
Bordeaux
Vente
DateVente
Prix
1985-12-03
10 000
NumVoit
1
NumAch
1
1996-03-30
70 000
1998-06-14
30 000
2000-04-02
45 000
2.1 PROJECTION (SELECT)

Lopration de projection consiste slectionner la (les) colonne(s) que lon veut voir figurer dans la table rsultat . On spcifie la liste des colonnes inclure dans cette table derrire linstruction SELECT en les sparant par des virgules. Si lon dsire afficher toutes les
colonnes, on les dsigne par le caractre * .
Projection sur les
colonnes Nom et
Ville de la table
Personne.
98
SELECT Nom, Ville

FROM personne ;
Nom
Ville
Nestor
Paris
Irma
Lille
Henri
Paris
Josette
Lyon
Jacques
Bordeaux
Chapitre
Projection sur tous
les champs de la
table Personne.
SELECT *
FROM personne ;
NumAch
Nom
Age
Ville
Sexe
Nestor
96
Paris
Irma
20
Lille
Henri
45
Paris
Josette
34
Lyon
Jacques
50
Bordeaux
Les colonnes de la table rsultat peuvent tre renommes par le mot cl AS.
SELECT Ville AS City
FROM personne ;
City
Paris
Lille
Paris
Lyon
Bordeaux
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 diffrentes 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.
Projection sur les
valeurs distinctes
du champ Marque
de la table
voiture.
SELECT DISTINCT Marque

FROM voiture ;
Marque
Peugeot
Citroen
Opel
Renault
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 problmes 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
SQL 99
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).
Tableau 4.1
Oprateurs
dexpressions de
SQL.
Cration dune
colonne
Prix_Euros dans la
table vente
contenant le prix de
vente en euros.
Addition
Soustraction
Multiplication
Division
Modulo
SELECT Prix, DateVente, (Prix / 6.5596) AS Prix_Euros

FROM vente ;
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
SQL dispose de nombreuses autres fonctions intgres, parfois dpendantes du SGBD utilis, qui permettent par exemple le traitement des colonnes de types caractres, date
Transformation
dune colonne
Nom de la table
Personne en
majuscules.
SELECT UPPER(Nom) AS NomMajuscule

FROM personne ;
NomMajuscule
NESTOR
IRMA
HENRI
JOSETTE
JACQUES
Extraction du mois
de la colonne
'DateVente' de la
table 'Vente'.
SELECT MONTH(DateVente) AS Mois

FROM vente ;
Mois
12
3
6
4
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
100
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) :
Tableau 4.2
COUNT
Oprateurs
statistiques de SQL.
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 fonction 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.
Calcul de la
moyenne des prix
de vente pour la
table vente.
SELECT AVG(Prix) AS Prix_Moyen

FROM vente ;
Prix_Moyen
38 750.000 0
Calcul du nombre
de personnes (le
nombre de lignes
en ralit) de la
table personne.
SELECT COUNT(*) AS Nombre_Personne

FROM personne ;
Nombre_Personne
5
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 expressions 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).
Tableau 4.3
Oprateurs de
comparaison de
SQL.
gal
<>
Diffrent
<
Infrieur
SQL 101
Extraction des
enregistrements de
la table vente dont
le prix est suprieur
50 000.
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.
Tableau 4.5
Oprateurs et
connecteurs
logiques de SQL
permettant de
constituer des
expressions.
Extraction des
voitures de couleur
Blanche ou de
marque
Peugeot .
102
>
Suprieur
<=
Infrieur ou gal
>=
Suprieur ou gal
SELECT *
FROM vente
WHERE Prix > 50 000 ;
DateVente
Prix
NumVoit
NumAch
1996-03-30
70 000
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
SELECT *
FROM voiture
WHERE Couleur IN ("Blanc","Rouge") ;
NumVoit
Marque
Type
Couleur
Peugeot
404
Rouge
SELECT *
FROM personne
WHERE Age BETWEEN 40 AND 60;
NumAch
Nom
Age
Ville
Sexe
Henri
45
Paris
Jacques
50
Bordeaux
AND
Et : les deux conditions sont vraies simultanment
OR
Ou : lune des deux conditions est vraie
NOT
Inversion de la condition
SELECT *
FROM voiture
WHERE Couleur="Blanche" OR Marque="Peugeot" ;
NumVoit
Marque
Type
Couleur
Peugeot
404
Rouge
Opel
GT
Blanche
Peugeot
403
Blanche
Chapitre
Extraction des
personnes
nhabitant pas
Paris.
SELECT *
FROM personne
WHERE NOT (Ville=Paris);
NumAch
Nom
Age
Ville
Sexe
Irma
20
Lille
Josette
34
Lyon
Jacques
50
Bordeaux
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.
Affichage des
diffrentes
marques de
voitures de la table
voiture.
SELECT Marque
FROM voiture
GROUP BY Marque ;
Marque
Citroen
Opel
Peugeot
Renault
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 instruction les fonctions statistiques dj abordes aux diffrents sous-ensembles dune table
ainsi constitus.
Calcul du nombre
de voitures des
diffrentes
marques de la
table voiture.
Calcul de la
moyenne dge par
ville partir de la
table personne.
SELECT Marque, COUNT(*) AS Compte

FROM voiture
GROUP BY Marque ;
Marque
Compte
Citroen
Opel
Peugeot
Renault
SELECT Ville, AVG(ge) AS Moyenne_Age

FROM personne
GROUP BY Ville ;
Ville
Moyenne_Age
Bordeaux
50.0000
SQL 103
Ville
Moyenne_Age
Lille
20.0000
Lyon
34.0000
Paris
70.5000
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 statistiques appliques aux sous-ensembles dfinis par le groupage.
On reprend lexemple prcdent qui a permis de calculer le nombre de voitures par marques. 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.
Calcul du nombre
de voitures par
marque de la table
voiture dont le
nombre est
suprieur 1.

FROM voiture
GROUP BY Marque
HAVING Compte > 1;
Marque
Compte
Peugeot
Renault
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 groupage..
Supposons que lon veuille liminer les voitures rouges de notre calcul.
Calcul du nombre
de voitures par
marque de la table
voiture dont la
couleur est
Rouge .

FROM voiture
WHERE NOT (Couleur=Rouge)
GROUP BY Marque;
Marque
Compte
Citroen
Opel
Peugeot
Renault
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
104
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.
Qualification des
attributs par leur
table
dappartenance.
SELECT voiture.Marque, voiture.Couleur

FROM voiture ;
Marque
Couleur
Peugeot
Rouge
Citroen
Noire
Opel
Blanche
Peugeot
Blanche
Renault
Rose
Renault
Bleue
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.
Qualification
simplifie des
attributs par leur
table
dappartenance.
SELECT Vo.Marque, Vo.Couleur

FROM voiture AS Vo;
Marque
Couleur
Peugeot
Rouge
Citroen
Noire
Opel
Blanche
Peugeot
Blanche
Renault
Rose
Renault
Bleue
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 opration qui na gure dintrt en pratique. En SQL, cette opration scrit simplement.
Produit cartsien.
SELECT *
FROM personne, voiture ;
NumAch
Nom
Age
Ville
Sexe
Num
Voit
Marque
Type
Couleur
Nestor
96
Paris
Peugeot
404
Rouge
Irma
20
Lille
Peugeot
404
Rouge
Henri
45
Paris
Peugeot
404
Rouge
Josette
34
Lyon
Peugeot
404
Rouge
Jacques
50
Bordeaux
Peugeot
404
Rouge
Nestor
96
Paris
Citroen
SM
Noire
SQL 105
NumAch
Nom
Age
Ville
Sexe
Num
Voit
Marque
Type
Couleur
Irma
20
Lille
Citroen
SM
Noire
Henri
45
Paris
Citroen
SM
Noire
Josette
34
Lyon
Citroen
SM
Noire
Jacques
50
Bordeaux
Citroen
SM
Noire
Nestor
96
Paris
Opel
GT
Blanche
Irma
20
Lille
Opel
GT
Blanche
Henri
45
Paris
Opel
GT
Blanche
Josette
34
Lyon
Opel
GT
Blanche
Jacques
50
Bordeaux
Opel
GT
Blanche
Nestor
96
Paris
Peugeot
403
Blanche
Irma
20
Lille
Peugeot
403
Blanche
Henri
45
Paris
Peugeot
403
Blanche
Josette
34
Lyon
Peugeot
403
Blanche
Jacques
50
Bordeaux
Peugeot
403
Blanche
Nestor
96
Paris
Renault
AlpineA
310
Rose
Irma
20
Lille
Renault
AlpineA
310
Rose
Henri
45
Paris
Renault
AlpineA
310
Rose
Josette
34
Lyon
Renault
AlpineA
310
Rose
Jacques
50
Bordeaux
Renault
AlpineA
310
Rose
Nestor
96
Paris
Renault
Floride
Bleue
Irma
20
Lille
Renault
Floride
Bleue
Henri
45
Paris
Renault
Floride
Bleue
Josette
34
Lyon
Renault
Floride
Bleue
Jacques
50
Bordeaux
Renault
Floride
Bleue
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 opposition lopration prcdente. Elle peut sexprimer de plusieurs manires en SQL. La premire est semblable la restriction du produit cartsien prcdent, mais dans ce cas la
requte nest gnralement pas traite de manire optimale par le SGBD.
106
Chapitre
Construction de la
jointure des tables
voiture et vente
sur le critre
dgalit de la
colonne NumVoit.
SELECT voiture.Marque, voiture.Couleur, vente.Prix

FROM voiture, vente
WHERE voiture.NumVoit=vente.NumVoit ;
Marque
Couleur
Prix
Peugeot
Rouge
10 000
Citroen
Noire
70 000
Peugeot
Blanche
30 000
Renault
Rose
45 000
Une autre manire dexprimer la jointure interne passe par un oprateur de jointure spcifique JOIN. Il faut bien sr spcifier la colonne sur laquelle seffectue la jointure.
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.
Construction de la
jointure des tables
voiture,
personne et
vente sur les
critres dgalit
des colonnes
NumaAch et
NumVoit.
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);
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
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 intressant de les dsigner par des alias pour une simple commodit dcriture.
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 :
FROM vente INNER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
SQL 107
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 opration 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.
Construction de la
jointure externe des
tables voiture et
vente sur les
critres dgalit de
la colonne
NumVoit.
SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix

FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;
NumVoit
NumVoit
Marque
Couleur
Prix
Peugeot
Rouge
10 000
Citroen
Noire
70 000
NULL
Opel
Blanche
NULL
Peugeot
Blanche
30 000
Renault
Rose
45 000
NULL
Renault
Bleue
NULL
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 prvisible 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 voiture 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).
Construction de la
jointure externe
inverse des tables
voiture et vente
sur les critres
dgalit de la
colonne NumVoit.
108

FROM vente LEFT OUTER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
NumVoit
NumVoit
Marque
Couleur
Prix
Peugeot
Rouge
10 000
Citroen
Noire
70 000
Peugeot
Blanche
30 000
Renault
Rose
45 000
Chapitre
ou
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 tester avec le mot cl NULL. Par exemple, on teste le contenu de la colonne Prix issue de la
table vente.
Slection des lignes
de la table
prcdente.
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;
NumVoit
Marque
Couleur
Prix
Opel
Blanche
NULL
Renault
Bleue
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.
Tri par Marque de
la table voiture.
SELECT Marque, Type

FROM voiture
ORDER BY Marque ;
Marque
Type
Citroen
SM
Opel
GT
Peugeot
404
Peugeot
403
Renault
Alpine
A310
Renault
Floride
Il est possible de prciser lordre de tri par les mots cls ASC (croissant par dfaut) ou
DESC (dcroissant).
Tri par Marque de
la table voiture en
ordre dcroissant.
SELECT Prix, DateVente

FROM vente
ORDER BY Prix DESC ;
Prix
DateVente
70 000
1996-03-30
45 000
2000-04-02
30 000
1998-06-14
10 000
1985-12-03
SQL 109
On peut indiquer plusieurs critres de tri, qui sont lus et traits de gauche droite (ici, on
trie dabord par villes puis par ges).
Tri par Ville et par
Age de la table
personne.
SELECT Nom, Age, Ville

FROM personne
ORDER BY Ville, Age ;
Nom
Age
Ville
Jacques
50
Bordeaux
Irma
20
Lille
Josette
34
Lyon
Henri
45
Paris
Nestor
96
Paris
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 description des objets du SGBD (base de donnes, tables, colonnes, droits, etc.).
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.
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 ,) ;
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.
CREATE TABLE voiture (
NumVoit INT,
Marque CHAR(40),
Type CHAR(30),
Couleur CHAR(20)
) ;
110
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.
Cration de la table
voiture.
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 oprations 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).
Tableau 4.6
Types de donnes
numriques de
SQL.
INT
Entier standard (32 bits)
SMALLINT
Entier petit (16 bits)
REAL
Rel (taille spcifique au SGBD)
FLOAT(n)
Rel (reprsent sur n bits)
Tableau 4.7
CHAR(n)
Types de donnes
chanes de
caractres de SQL.
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)
NVARCHAR(b)
Chane de caractres de longueur maximale n

(codage Unicode sur 2 octets)
Tableau 4.8
BOOLEAN
Boolen
Types de donnes
date de SQL.
BLOB
Tableau 4.9
DATE
Date
Types de donnes
binaires de SQL.
TIME[(n)]
Heure, n (optionnel) est le nombre de dcimales

reprsentant la fraction de secondes
Binary Large Object : permet de stocker tout type

binaire (photo, fichier traitement de texte)
SQL 111
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 rfrentielle), 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.
112
Ajout dune
colonne de nom
enplus de type
INT la table
voiture (ADD
COLUMN).
ALTER TABLE voiture

ADD COLUMN enplus INT ;
Affichage de la
table voiture
modifie.
SELECT * FROM voiture ;
NumVoit
Marque
Type
Couleur
enplus
Peugeot
404
Rouge
NULL
Citroen
SM
Noire
NULL
Opel
GT
Blanche
NULL
Peugeot
403
Blanche
NULL
Renault
Alpine A310
Rose
NULL
Renault
Floride
Bleue
NULL
Suppression de la
colonne de nom
Couleur de la
table voiture
(DROP COLUMN).
ALTER TABLE voiture

DROP COLUMN Couleur;
Affichage de la
table voiture
modifie.
NumVoit
Marque
Type
enplus
Peugeot
404
NULL
Citroen
SM
NULL
Opel
GT
NULL
Peugeot
403
NULL
Renault
Alpine A310
NULL
Renault
Floride
NULL
Chapitre
La commande ALTER permet de modifier galement les contraintes associes aux colonnes. Cette partie est traite la section suivante, Contraintes dintgrit . Le mot cl
COLUMN est optionnel.
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.
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 .
Ajout de la colonne
Teinte.
ALTER TABLE voiture

ADD COLUMN Teinte CHAR(60);
Affichage de la
table voiture
modifie.
NumVoit
Marque
Type
Couleur
Teinte
Peugeot
404
Rouge
NULL
Citroen
SM
Noire
NULL
Opel
GT
Blanche
NULL
Peugeot
403
Blanche
NULL
Renault
Alpine
A310
Rose
NULL
Renault
Floride
Bleue
NULL
NumVoit
Marque
Type
Couleur
Teinte
Peugeot
404
Rouge
Rouge
Citroen
SM
Noire
Noire
Opel
GT
Blanche
Blanche
Peugeot
403
Blanche
Blanche
Renault
Alpine
A310
Rose
Rose
Renault
Floride
Bleue
Bleue
Recopie des
donnes de
Couleur dans
Teinte.
UPDATE voiture
SET Teinte=Couleur ;
Affichage de la
table voiture
modifie.
Suppression de la
colonne Couleur.
ALTER TABLE voiture

DROP COLUMN Couleur;
SQL 113
Affichage de la
table voiture
modifie.
NumVoit
Marque
Type
Teinte
Peugeot
404
Rouge
Citroen
SM
Noire
Opel
GT
Blanche
Peugeot
403
Blanche
Renault
Alpine
A310
Rose
Renault
Floride
Bleue
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 (UNIQUE).
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
114
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,
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 colonnes, 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.
SQL 115

Ville CHAR(40),
AGE INT,
CONSTRAINT la_contrainte CHECK ( (Age IS NOT NULL AND Ville IS NOT NULL) OR
IS NULL AND Ville IS NULL) )
;
(Age
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 recalcul 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 dintgrit 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.
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 dterminer 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 :
116
enregistrement par enregistrement (INSERT INTO) ;

en insrant la rponse une requte SQL (INSERT INTO).
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) ;
Affichage de la
table voiture
modifie.
NumVoit
Marque
Type
Couleur
Peugeot
404
Rouge
Citroen
SM
Noire
Opel
GT
Blanche
Peugeot
403
Blanche
Renault
Alpine
A310
Rose
Renault
Floride
Bleue
10
Triumph
NULL
Bleue
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;
Remarque
Pour tre insres, les valeurs des colonnes doivent respecter les contraintes dintgrit associes
la table.
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 prcdemment.
DELETE FROM voiture
WHERE Couleur=Rouge ;
SQL 117
Affichage de la
table voiture
modifie.
NumVoit
Marque
Type
Couleur
Citroen
SM
Noire
Opel
GT
Blanche
Peugeot
403
Blanche
Renault
Alpine
A310
Rose
Renault
Floride
Bleue
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.
118
Modification du
nom dune ville
dans la table
personne.
UPDATE personne
SET Ville=Paris-Centre
WHERE Ville=Paris ;
Affichage de la
table personne
modifie.
SELECT * FROM personne ;
NumAch
Nom
Age
Ville
Sexe
Nestor
96
Paris-Centre
Irma
20
Lille
Henri
45
Paris-Centre
Josette
34
Lyon
Jacques
50
Bordeaux
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 Description 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 instructions 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.
JOIN
AS, DISTINCT
(LEFT/RIGHT) JOIN
+, , *, /, %
AVG, MAX, MIN
SELECT
FROM
ON
<liste de champs>
<liste de tables>
=, <, >, LIKE

IS NULL, IN, BETWEEN
SUM, COUNT
OR, AND, NOT
WHERE
<liste de critres>
ASC, DESC
ORDER BY <liste de champs>
GROUP BY <liste de champs> HAVING <liste de critres>
INSERT INTO
CREATE TABLE
<Table>
( <liste de champs + Type> )

DROP TABLE
<Table>
ALTER TABLE
<Table>
( <liste de champs + Type> )
<Table>
( <liste de champs> )( <liste de valeurs> )

DELETE FROM
<Table>
WHERE <liste de critres>

UPDATE <Table> SET < champ=valeur >
WHERE <liste de critres>
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.
SQL 119
Exercices
EXERCICE 1
PROJECTION SIMPLE
Trouvez les diffrentes villes dans lesquelles habitent les personnes. Ordonnez le rsultat
par ordre dcroissant.
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

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

Trouvez lge moyen des personnes habitant Paris dans la base de donnes casse.
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 ;
120
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
Trouvez le nombre de voitures par marques dans la base de donnes casse.
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
Trouvez lge des personnes qui nhabitent pas Paris.
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) ;
PRODUIT CARTSIEN
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).
Exercices
EXERCICE 6
SQL 121
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 colonnes (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
Donnez les noms des personnes et la marque des voitures quelles ont achetes.
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
AND (pe.NumAch=ve. NumAch);
On aurait pu galement crire :

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
Que donnerait cette requte ?

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 ?

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 colonnes 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
Quelles sont les villes o habitent les personnes qui nont pas achet de voiture ?
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
122
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 enregistrements 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
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 occurrences de ville par le mot cl DISTINCT.
SELECT DISTINCT personne.Ville
SLECTION SUR UN AGRGAT DUNE JOINTURE

Calculez la moyenne des prix de vente par marques en ne considrant que les marques
dont cette moyenne est suprieure 40 000.
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)
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
GROUP BY vo.Marque
HAVING Moyenne >= 40000
;
Exercices
EXERCICE 10
SQL 123
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
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

Affichez les prix qui sont suprieurs la moyenne.
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

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 .

Age INT,
Ville CHAR(40),
Sexe CHAR(1),
CHECK (Age BETWEEN 16 AND 100),
CHECK Sexe IN (H,F)
);
124
Chapitre
EXERCICE 13
INSERTION DE DONNES DANS UNE TABLE

Insrez les valeurs suivantes dans la table prcdemment cre.
NumAch : 100
Nom : Essai
Ville : Paris
Lenregistrement est-il valid ? (Satisfait-il aux contraintes dintgrit ?)
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

Modifiez le prix de vente (+10 %) des voitures.
Les informations modifier se trouvent simplement dans la table vente bien que la question 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 ;
REQUTE COMBINE
Quelles sont les personnes qui nont pas achet de voitures rouges ?
La question parat simple, mais elle doit tre bien analyse. On doit considrer deux catgories 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 trouvent dans les deux tables personne et vente .
SELECT personne.Nom
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
AND (pe.NumAch=ve. NumAch)
WHERE vo.Couleur != Rouge;
Exercices
EXERCICE 15
SQL 125
Chapitre
Du langage
parl SQL
1. Prsentation de lactivit
modliser ............................128
2. laboration du modle
entit-association ....................129
Ce chapitre prsente un exemple complet de

ralisation dune base de donnes, tape par tape.
On part de lnonc dans la vie relle jusqu
3. Passage au modle relationnel ..134
linterrogation de la base laide du langage SQL.
4. Interrogation de la base
de donnes ............................141
Cet exemple permet de rcapituler les concepts
Exercices
prsents dans les chapitres prcdents, savoir :
7. Mise jour de la base ............153
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.
8. volution de la base
de donnes ............................154
On aborde galement ici les diffrents aspects
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
9. Autre exemple complet ............154
dordre pratique qui se posent chaque tape de la

ralisation dune base de donnes.
127
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 ingrdients 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 doivent 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 :
128
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
Chapitre
Remarque
Afin de simplifier le problme, on considre que lopration de base modliser dans cette activit 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.
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 prcises. Une certaine part dintuition est ncessaire, dautant plus quil nexiste pas une solution 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 clairement 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.
Du langage parl SQL 129
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 normalis, 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 sparer 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 certaines 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 combler 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 entits ainsi constitues. Les autres attributs des entits se trouvent dans lnonc : par exemple 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 vidente. 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 caractristique 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 pondrer 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 normales 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 bonification qui peuvent tre obtenues soit en raison dun retard de livraison soit par une capitalisation 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 :
130
commande (DateCom, Taille, Retard) ;
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, NomClientCompte, 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 franchiseur, 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 contenu 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 prfrable 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) ;
livreur (CodeLivreur, NomLivreur, Tlphone) ;
ingrdient (NumIngre, NomIngrdient).
Associations et attributs
On peut, partir des phrases qui ont permis de reprer les entits, en dduire les associations 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 dutiliser une entit commande fait que lon regroupe naturellement dans cette entit les attributs 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
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 entitassociation
Livraisons de
pizzas sans
cardinalits.
Commande
Livreur
Passe
Client
Livre
# NumCommande
DateCom
Taille
Retard
# CodeLivreur
NomLivreur
Tlphone
# NumClient
NomClient
Adresse
Compte
PointsRapizz
Transporte
Constitue
Vhicule
# NumImmat
Marque
Type
Ingrdient
# NumIngre
NomIngre
Pizza
Compose
# NomPizza
Prix
2.2 DTERMINATION DES CARDINALITS

On se pose ensuite des questions sur la nature des liens entre les entits capables de dterminer 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 fastidieuse, 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 associes sont de type 1-1.
132
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) livraisons. 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 associes 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 donnes 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 associes sont de type 1-1. On obtient le modle entit-association suivant (voir figure 5.2) :
Figure 5.2
Livraisons de
pizzas avec
cardinalits.
1,1
1,n
1,1
Commande
Passe
0,n
Client
Livre
Livreur
1,1
# CodeLivreur
NomLivreur
Tlphone
# NumCommande
DateCom
Taille
Retard
# NumClient
NomClient
Adresse
Compte
PointsRapizz
1,1
Transporte
Constitue
1,n
0,n
Vhicule
Ingrdient
Pizza
1,n
# NumImmat
Marque
Type
# NumIngre
NomIngre
Compose
1,n
# NomPizza
Prix
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.
Cependant, si cela est possible, on prfre cependant viter les associations autres que binaires, 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.
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 formes 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 relationnel sont les suivantes :
Une entit donne une relation de mme cl que lentit qui contient les mmes attributs 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) ;
livreur (CodeLivreur, NomLivreur, Telephone) ;
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 lassociation 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-
134
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 fusionner. 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 :

livreur (CodeLivreur, NomLivreur, Telephone) ;
ingrdient (NumIngre, NomIngredient) ;
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 conformit 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 contenu du champ Adresse de la relation client : pour des raisons de simplification et de lisibilit 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.
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 relations 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 certains 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 identifier une relation de dpendance entre le type qui est unique pour un vhicule. Si lon suppose 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 NomPizza. 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 forant un peu le raisonnement pour la relation Livreur. En effet, si lon suppose que le tlphone 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 considre les redondances rsiduelles comme acceptables.
136
Chapitre
Remarque
En pratique, on neffectue pas toujours cette tape de manire stricte compte tenu de la complexit 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.
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 contraintes 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, compris 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 renseignes 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 permettra 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 premiers 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
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-
138
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 contrainte 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 relation livreur.

NumImmat de la relation commande. Rfrence au champ NumImmat de la relation 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 prcdemment. 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,
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 NumCommande 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.
140
Chapitre
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 pdagogique, mais totalement inefficace du point de vue du SGBD qui doit effectuer le produit cartsien 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 donnent 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 obtiendra 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 vhicule 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 :
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 utiliser 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 lesquelles 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 regnration 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 correspondante dans lautre table. Les valeurs des champs de cette autre table sont alors logiquement 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 lorsque la base de donnes na pas t conue en intgrant les contraintes dintgrit indispensables.
142
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 regroupements 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.
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 contient 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 prcdentes. 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
GROUP BY commande.NumClient) A
WHERE R1.NombreCommande >
(SELECT AVG(B.NombreCommande)
FROM (SELECT commande.NumClient, NomClient, COUNT(*) AS NombreCommande

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 contenues 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 premire 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 simple 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.
144
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) ;
VALUES (humaine, 1) ;
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 entitassociation

Quelles sont les rpercussions de cette modification sur le modle entit-association utilis 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 provient 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.
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 commandes diffrentes peuvent avoir la mme tarification : la cardinalit est de type 0-n
(voir figure 5.3).
Figure 5.3
1,1
Livraisons de
pizzas avec
cardinalits.
Commande
1,1
1,n
Livre
Livreur
# CodeLivreur
NomLivreur
Tlphone
1,1
# NumCommande
DateCom
Retard
0,n
Passe
Client
# NumClient
NomClient
Adresse
Compte
PointsRapizz
1,1
1,1
Utilise
Transporte
0,n
1,n
Constitue
Tarification
0,n
Vhicule
# NumImmat
Marque
Type
#Taille
Coefficient
Pizza
1,n
Ingrdient
# NomPizza
Prix
Compose
# NumIngre
NomIngre
1,n
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 dplacement 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 :
146

livreur (CodeLivreur, NomLivreur, Tlphone) ;
ingrdient (NumIngre, NomIngrdient) ;
NumClient, NomPizza) ;
compose (NumIngre, NomPizza) ;
tarification(Taille, Coefficient).
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.
Remarque
Les requtes retournent toujours un rsultat. Cependant, on ne peut tre sr que ce dernier reprsente la rponse exacte la question pose. Il est ncessaire de systmatiquement vrifier le rsultat 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.
Rsum
Ce chapitre dtaille lensemble des tapes ncessaires la ralisation dune base de donnes, 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 quelques questions essentielles. On saperoit cette occasion que lensemble des tables utilises 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 classiques 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 dmarche 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 relationnel.
La seconde mthode est la solution la plus juste dun point de vue thorique. Mais, en pratique, on utilise une combinaison des deux approches pour obtenir le rsultat. Il est essentiel 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.
Exercices
EXERCICE 1
REPRSENTATION
UML
Reprsentez le modle entit-association en utilisant le formalisme 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 comprend 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 exemple 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.
Livreur
Livre
1..1
# CodeLivreur
NomLivreur
Tlphone
Client
Passe
Commande
1..n
1..n
0..n
# NumCommande
DateCom
Retard
1..1
0..n
# NumClient
NomClient
Adresse
Compte
PointsRapizz
0..n
Utilise
Transporte
Constitue
1..1
Tarification
1..1
# NumImmat
Marque
Type
1..1
#Taille
Coefficient
Vhicule
Pizza
1..n
Ingrdient
# NomPizza
Prix
Compose
# NumIngre
NomIngre
EXERCICE 2
CALCULS PAR EXPRESSION
1..n
SQL
Combien de pizzas ont-elles t livres en retard ? Quelle est la perte occasionne par ces
retards ?
Pour calculer le nombre de pizzas livres en retard, il faut se souvenir dun point important que lon a fix comme axiome lors de llaboration du modle : une pizza est associe 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.
148
Chapitre
Le type de question qui inclut le mot combien suggre que lon va effectuer un comptage 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 prfixer les noms de champ par le nom de la table do ils proviennent pour viter les ambiguts 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.
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.
Exercices
EXERCICE 3
La requte retourne un rsultat, car la syntaxe est correcte et le type des champs sur lesquels on a effectu la jointure sont de type compatible et contiennent des valeurs communes. 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 correspondant 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 corrlations, 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
Donnez le chiffre daffaires par pizza vendue. On ne tient pas compte ce niveau des pizzas gratuites obtenues grce aux points de fidlit ou en raison dun retard de livraison.
La mthode conseille dans ce chapitre est daborder la question en dcomposant le problme. 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 agrgats. 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*tarification.coefficient) AS TotalCommande
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 slection se fait, de mme que le tri, la fin de lopration sur la table rsultat finale.
SELECT commande.NomPizza, COUNT(*)
tion.coefficient) AS TotalCommande
150
AS
NombreCommande,
SUM(pizza.prix*tarifica-
Chapitre
HAVING TotalCommande > 200
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 agrgats et les calculs ; dans ce cas, on utiliserait le mot cl WHERE.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarification.coefficient) AS TotalCommande
WHERE pizza.prix > 10
Dans le premier cas, la slection est faite a fortiori ; dans le second, a priori.
REQUTES COMBINES
Quel est le nom du livreur qui a le plus de retard ?
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 prcdemment lemploi dagrgats sur lesquels on utilise la fonction de comptage.
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.
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.
Exercices
EXERCICE 5
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
Quel est le nom du livreur qui nest jamais en retard ?

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 commande. Si lon considre les rsultats de lexercice prcdent, on a calcul le nombre de
retards par livreur par la requte suivante.
FROM commande
;
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.
SELECT commande.CodeLivreur, livreur.NomLivreur, COUNT(*) AS NombreRetard
FROM commande JOIN livreur
ON commande.CodeLivreur=livreur.CodeLivreur
SELECT requete1.NomLivreur
FROM requete1
;
Soit on fait la jointure lors de la seconde requte.

FROM commande
;
FROM requete1 JOIN livreur ON requete1.CodeLivreur=livreur.CodeLivreur
;
152
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-association. 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 commande 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 entitassociation, 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
;
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.
FROM livreur LEFT JOIN commande
WHERE commande.CodeLivreur IS NULL
;
MISE JOUR DE LA BASE

On veut mettre jour le solde du compte dun client aprs chaque commande. Pour ce faire, il est ncessaire de recourir un langage de programmation ou des notions qui dpassent 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.
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.
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 ;
Exercices
EXERCICE 7
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

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 ?
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 cartsien 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 entitassociation. Elle ne serait lie aucune entit par une association.
EXERCICE 9
AUTRE EXEMPLE COMPLET

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-dechausse portent les numros 001, 002 ; les chambres du premier tage portent les numros 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.
154
Chapitre
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.
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 Chambre. 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 facturation du sjour. Le type de chambre dterminant le prix de la chambre, une entit supplmentaire 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 TYPE(

ID_TYPE INT PRIMARY KEY,
LIBELLE VARCHAR(50) NOT NULL,
PRIX FLOAT(10,2),
CHECK LIBELLE IN (SIMPLE,DOUBLE,ROYALE)
) ;
Exercices
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 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'
;
156
Chapitre
Prservation
des donnes
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.
157
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 palissade 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 physiquement 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 doivent 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 personnes 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
158
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 administrateur 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 possdent les droits daccs la machine et vrifier la qualit des mots de passe associs. Classiquement, 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 luimme 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 spcifiques 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 galement 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 paramtres prendre en compte. Il est difficile de prdire quun constructeur ou un diteur ne
Prservation des donnes 159
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 mtadonnes (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 autonome (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 mcanismes 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 paradoxal 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 simplement 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 plusieurs hbergements gographiquement distants (voir figure 6.1).
160
Chapitre
Figure 6.1
Rpartition
Redondance et
rpartition de
charge.
&
redondance
Hbergement 3
Hbergement 2
Hbergement 3
Recopie des donnes

Recopie des donnes
Recopie des donnes

Base originale
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 dictionnaire de donnes du SGBD. Il est possible daccder au SGBD, ventuellement distance, 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 ressource, 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 possibilit dutiliser des mots de passe spcifiques selon la ressource. Il sagit donc dune logique 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
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.
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 informations de lutilisateur pour authentifier la connexion au SGBD. L encore, le mode de connexion 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 instruction de cryptage du mot de passe.
Compte tenu de la remarque prcdente, les diteurs intgrent souvent la notion plus classique dutilisateur dans un SGBD. Ce dernier permet en gnral de distribuer des autorisations 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-groupes 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 simplement 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.
162
Chapitre
2.2 SQL ET LA GESTION DES DROITS

Une fois que lutilisateur est connect au systme, il convient de grer son accs aux donnes. 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 diffrents 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 manipulation 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
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>
164
Chapitre
Pour retirer les droits de lutilisateur nhop sur la table jaco, on procde comme suit :
REVOKE SELECT
ON jaco
FROM nhop ;
Remarque
Seul lutilisateur qui lui a donn ces droits peut les lui retirer. Dans notre cas, la commande prcdente doit tre lance par lutilisateur pastorius.
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 oprations. Ce graphe de permissions nest pas toujours simple grer et devient rapidement 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 destruction dun utilisateur, capable de dtruire galement tous les objets quil a crs. Linstruction 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 permettent 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 permissions 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 exemple casse.
Vue utilisant une jointure simple

Le service marketing veut vrifier sil ny a pas de corrlations entre la couleur des vhicules vendus et la ville dans laquelle rsident les clients qui les achtent. Il est inutile de fournir 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.
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 rsultat 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.
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 problmes sont habituellement rsolus par les mcanismes associs aux transactions prsentes dans cette section. Celles-ci permettent galement de rsoudre les pertes dues aux
166
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 applications 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-til lorsquun ou plusieurs utilisateurs dcident de modifier les mmes donnes au mme
moment ? On considre la squence dinstructions suivante applique la base de donnes 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 dinstructions 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 donnes effectues par diffrents utilisateurs. En raison de laugmentation des frais de structure, 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 communication, 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 service 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.
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
Prix de vente
Droulement de
la squence
dinstructions de
mise jour du
prix de vente.
Pastorius : consultation du prix de vente
9 700
Nhop : promotion et modification du prix

de vente (Prix = Prix
100)
Prix de vente
Pastorius : augmentation du prix de vente
Prix de vente
9 600
10 185
constat
Miller : vrification du prix de vente
Prix de vente
10 185
attendu
Prix de vente
10 085
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 concurrent aux donnes. On peut citer le cas des anomalies de lecture : Deux lectures successives 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 arrive. 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 longtemps 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
168
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 constate 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 voiture 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 ressource 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 blocages 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 transaction 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.
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.
Remarque
Les transactions permettent de rsoudre les problmes lis aux accs concurrentiels, mais galement 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) manipulation(s) sur la base de donnes. Il sagit certainement de lutilisation principale des transactions.
Ralisation des transactions dans les SGBD

Pour mettre en uvre les transactions, le SGBD doit offrir lexclusivit daccs aux donnes 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 donnes 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 lectures 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 complexe 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 journalisation 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 :
170
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 dexclusivit. Il est clair que, pour une simple opration de lecture, le niveau 1 qui garantit limpossibilit de lire des donnes non valides peut tre suffisant.
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, certains SGBD trs rpandus fonctionnent par dfaut au niveau 1 ! Ce peut tre suffisant pour certaines 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.
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 annules.
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 :
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 ;
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. Linstruction ROLLBACK annule toutes les instructions effectues depuis linstruction START
TRANSACTION. Cependant, il est possible de diviser cet ensemble dinstructions en sousensembles 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).
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 %)
#Destruction des tuples dont le champ Ville vaut Paris dans la table client
#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
START TRANSACTION ;
Point de retour
dans une
transaction.
INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F');
SAVEPOINT UN
ROLLBACK TO UN ;
ROLLBACK
Le mcanisme des points de retour est trs utile pour prvenir les cas de mauvaise manipulation 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 explicitement le dbut de toute transaction par une instruction START TRANSACTION.
172
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 reprises 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 rpandus, ne proposent mme pas les transactions sur leurs tables en standard .
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 oprations 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.
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 lexemple 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 contraintes 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 scurit 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.
174
Chapitre
Rsum
Ce chapitre expose les diffrentes dispositions que lon doit prendre afin de prvenir laltration 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 ladministrateur 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 procure de surcrot un mcanisme de journalisation des instructions capable de remettre
la base de donnes dans ltat cohrent prcdant la squence dinstructions. Cette combinaison des mcanismes daccs exclusif associs la journalisation se nomme les transactions. 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.
Exercices
EXERCICE 1
SCURIT DE BASE
Quelles sont les vrifications de base indispensables avant de faire hberger un SGBD serveur de bases de donnes par une structure ?
La dcision doit reposer sur la prise en considration de plusieurs points ; la liste ci-dessous 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 protger 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 disposet-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 incidents, mise jour des machines, gestion des comptes
EXERCICE 2
DISPONIBILIT DES DONNES

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 ?
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 permanence, 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 secondaires pour faire de la rpartition de charge. Le systme de rpartition choisi doit tenir
176
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 rediriger la demande, on doit prendre en considration galement sa charge et donc son aptitude 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 inconvnient 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 solution 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.
NIVEAUX DUTILISATION DUNE BASE DE DONNES

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.
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 premire 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 informations 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 informations concernant les commandes, mais quils doivent pouvoir y accder en lecture.
Exercices
EXERCICE 3
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
commande
pizza
compose
Client
Lecture
Lecture
Lecture
Employ
Lecture/
criture
Lecture
Lecture
Gestionnaire
Lecture
Lecture/
criture
Lecture/
criture
EXERCICE 4
ingredient tarification
client
livreur
vehicule
Lecture
Lecture
Lecture
Lecture
Lecture
Lecture
Lecture
Lecture/
criture
Lecture/
criture
Lecture/ Lecture/ Lecture/

criture criture criture
GESTION DES DROITS

Comment reprsenter pratiquement les catgories identifies lexercice prcdent dans
un SGBD ? crivez les instructions permettant de le faire.
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 utilisateurs 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
GRANT
GRANT
GRANT
GRANT
SELECT
SELECT
SELECT
SELECT
SELECT
ON
ON
ON
ON
ON
pizza TO client;
compose TO client;
ingrdient TO client;
tarification TO client ;
client TO client;
Cration du rle employe et distribution des droits. CREATE ROLE employe;

GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
SELECT
SELECT
SELECT
SELECT
SELECT
SELECT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
pizza TO employe ;
compose TO employe ;
ingrdient TO employe ;
tarification TO employe ;
vehicule TO employe ;
livreur TO employe ;
client TO employe ;
client TO employe;
client TO employe;
client TO employe;
commande TO employe ;
commande TO employe;
Cration du rle gestionnaire et distribution des droits. CREATE ROLE gestionnaire;

GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
178
SELECT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
ON
ON
ON
ON
ON
ON
ON
commande TO gestionnaire ;
client TO gestionnaire;
livreur TO gestionnaire;
Chapitre
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
GRANT
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
SELECT
UPDATE
DELETE
INSERT
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
vehicule TO gestionnaire;
tarification TO gestionnaire;
ingrdient TO gestionnaire;
compose TO gestionnaire;
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;
VUES
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 nombre 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, spcifiquement 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.
On remarque que les informations dont ces utilisateurs ont besoin ne sont pas directement 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.
Exercices
EXERCICE 5
Service comptabilit. Le besoin est uniquement davoir accs aux nombres de commandes livres pour chaque livreur. Il sagit du rsultat dun calcul classique sur un agrgat. 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
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
WHERE C.Retard=O
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 commande, 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
;
180
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 nexistent 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.
TRANSACTIONS
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.
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 abandonne toutes les modifications, y compris celles des prix la fin 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 ;
Exercices
EXERCICE 6
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 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 .
On utilise un trigger (dclencheur) pour mettre jour automatiquement la table compose 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 rapport 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.
182
A
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 utilisait 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 certains caractres accentus. Il possde galement des caractres de contrle utiliss pour la
transmission du message (par exemple, rptez ). Ce codage universel permet de transmettre 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 (25). 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 contrle, 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 perfores 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 commune qui sera publie au final par lorganisme de normalisation ASS (American Standard
Association) sous le nom de code ASCII (American Standard Code for Information Interchange). Le code ASCII possde 7 positions, ce qui permet de stocker 128 (27) 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 minuscules, 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
Codages de caractres et bases de donnes 183
de caractre ASCII est encore trs rpandu, car il suffit bon nombre dapplications condition 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 reprsenter par une suite spcifique de caractres ASCII comme on le fait en HTML. Par exemple
se reprsente par la suite é .
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 positions, ce qui donne 256 (28) 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 premiers 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 toutefois peu rpandue, probablement en raison du temps important qua ncessit sa dfinition. 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 version 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 normes. 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 transmettre 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.
184
A
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 donnes. 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 critiques. 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 (216) caractres que lon appelle des plans. Lun des intrts de ce dcoupage 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 caractres Unicode. Il suffit de trouver un codage astucieux qui indique que lon utilise le premier 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.
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 dsignes par les termes Little Endian et Big Endian . Il existe donc une version UTF16LE 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 actuellement, 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.
Autres plans
Morse
Plan Multilingue Base
Baudot (5 positions)
UNICODE -ISO-10646
(21 positions)
ISO 8859 (8 positions)

BCD- IBM (6 positions)
UTF 8 (octets)
UTF 16 (doubles octets)
ISO-8859-1 (Latin1)
UTF-7, UTF-32, UCS-2.
ISO-8859-15 (Latin9)
ASCII (7 positions)
ISO-8859-7 (Grec)
Windows-1251 (8 positions)
JIS X Japonais (8 positions)
MacRoman (8 positions)
186
A
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 appropri. Le plus conomique est sans doute la norme ISO-8859, mais cela est valable condition 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 correspondance 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 caractres 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.
Nom_client NATIONAL CHARACTER(20) ;
La collation utiliser est spcifie par le mot cl COLLATE suivi du nom de la collation utiliser.
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.
188
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 Education, 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 gnration, 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.
Bibliographie 189
Base de donnes book Page 191 Lundi, 5 juin 2006 3:33 15
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
Index 191
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
Redondance 3, 4, 37, 38, 59, 72, 73, 136, 160

Relation 56
Rle 42, 162, 164
Langage hte 96
LDD 16, 80, 95
LMD 16, 95
Logique du premier ordre 76
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
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
192 Cration de bases de donnes
union 60
Q
QBE 76, 78
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
Index
193
Informatique
Cration
&
de
bases
exercices
corrigs de donnes
Synthse
de cours
Lauteur :
Cet ouvrage propose une dmarche progressive ceux qui veulent concevoir
Nicolas Larrousse est ingnieur au

CNRS. Spcialis en informatique,
il enseigne les bases de donnes
luniversit de Versailles Saint-Quentinen-Yvelines et au service de formation
permanente de luniversit Pierre et
Marie Curie Jussieu.
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 caractres, 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
Le relecteur :
ric Innocenti est matre de confrences en informatique luniversit de
Corse. Il est responsable pdagogique des filires SRC (Services et
Rseaux de Communication) et LPM
(Licence Professionnelle Multimdia). Il
enseigne lalgorithmique, la programmation et les systmes dinformation.
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
uvre du systme ainsi conu laide du langage SQL. Une tude de cas
rcapitulative permet ensuite dappliquer les notions prsentes dans les chapitres 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 afin
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 exercices sont disponibles ladresse www.pearsoneducation.fr.
Le livre sadresse aux tudiants de premier et de second cycles (IUT, BTS, universits 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.
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.
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

Création de Bases de Données

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Création de Bases de Données

Transféré par

Droits d'auteur :

Formats disponibles

Informatique

2009 Pearson Education France

Composition sous FrameMaker : IDT

Chapitre 1 Introduction aux bases de donnes

Chapitre 2 Analyse du monde rel

Chapitre 3 Approche relationnelle

Logique du premier ordre et base de donnes

Chapitre 5 Du langage parl SQL

Chapitre 6 Prservation des donnes

Cration de bases de donnes

Cration de bases de donnes

Au cours des dernires annes, les bases de donnes

4. tapes de la conception des bases

effectu avec sa carte bancaire jusqu nos

5. Mtiers des bases de donnes 19

6. Plan de louvrage .....................20

Lobjectif de ce chapitre est de dfinir la notion de

base de donnes ainsi que les principaux concepts

1. Notion de base de donnes........22

qui sy rattachent. La mthodologie qui permet de les

7. Vues externes ...........................24

Quest-ce quune base de donnes ?

1.1 NOTION DE BASE DE DONNES

1.2 UTILISATION DUNE BASE DE DONNES

Cration de bases de donnes

Nombre entier suprieur

Chane de caractres de taille 50

Chane de caractres de taille 20

1.3 QUALIT DUNE BASE DE DONNES

Introduction aux bases de donnes 3

volution des bases de donnes et de leur

Cration de bases de donnes

Modle hirarchique et modle rseau

Introduction aux bases de donnes 5

Ouvrage (Cote, Titre, Auteur,Editeur)

La programmation sous Unix

Les bases de donnes

Internet pour les nuls

Petit Larousse illustr

Godel, Escher & Bach

Basic Book Inc.

Cration de bases de donnes

Introduction aux bases de donnes 7

2.3 VOLUTION DE LUTILISATION DES BASES DE DONNES

Base de donnes rparties

Cration de bases de donnes

Filiale Ocan indien

Extraction dinformations non explicitement stockes dans une base

Introduction aux bases de donnes 9

Entrepts de donnes (datawarehouse)

Cration de bases de donnes

Introduction aux bases de donnes 11

Cration de bases de donnes

Systmes de gestion de bases de donnes

3.1 FICHIERS INFORMATIQUES

Introduction aux bases de donnes 13

On constate que la simple recherche dinformations recourt dj des algorithmes assez

Cration de bases de donnes

3.2 FONCTIONNALITS DUN SGBD

Rplication des donnes. Copie automatise de sauvegarde.

Introduction aux bases de donnes 15

Virtualisation des donnes. Masquage de la distribution gographique des donnes.

Un SGBD doit permettre galement la manipulation de la structure de la base de donnes,

un Langage de Description de Donnes (LDD) qui permet dagir sur la structure de la