Académique Documents
Professionnel Documents
Culture Documents
Creation de Bases de Donnees PDF
Creation de Bases de Donnees PDF
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
collection
Synthex
Nicolas Larrousse
Informatique
&
Synthse exercices
de cours 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
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 V
Le relecteur VII
Avant-propos IX
Chapitre 1 Introduction aux bases de donnes 1
1 Quest-ce quune base de donnes ? 2
2 volution des bases de donnes et de leur utilisation 4
3 Systmes de gestion de bases de donnes 13
4 tapes de la conception des bases de donnes 17
5 Mtiers des bases de donnes 19
6 Plan de louvrage 20
7 Prsentation de la BD exemple 20
Exercices 22
Chapitre 2 Analyse du monde rel 27
1 Dmarche danalyse 28
2 Modlisation par le modle entit-association 30
3 Remise en cause et volution du modle 35
4 Reprsentation avec UML 40
Exercices 44
Chapitre 3 Approche relationnelle 55
1 Concepts 56
2 Oprations du modle relationnel 60
3 Passage du modle conceptuel au relationnel 68
4 Normalisation 70
5 Logique du premier ordre et base de donnes 76
Exercices 82
Chapitre 4 SQL 95
1 Concepts du langage SQL 96
2 Oprations relationnelles avec SQL 97
3 Gestion de tables et de vues 110
4 Gestion des donnes 116
Exercices 120
Sommaire III
Chapitre 5 Du langage parl SQL 127
1 Prsentation de lactivit modliser 128
2 laboration du modle entit-association 129
3 Passage au modle relationnel 134
4 Interrogation de la base de donnes 141
Exercices 148
Chapitre 6 Prservation des donnes 157
1 Contrle daccs et sauvegarde 158
2 Limitations daccs au SGBD 161
3 Transactions 166
4 Triggers 173
Exercices 176
Annexe 183
Bibliographie 189
Index 191
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 don-
nes inadapte peut provoquer des erreurs fondamentales dexpression dans linterrogation
de la base de donnes.
Il nest pas ais de prsenter dans un seul ouvrage toutes les facettes du monde des bases de
donnes de lenqute pralable la ralisation pratique en SQL et il a donc fallu oprer
certains choix pour ne conserver que lessentiel. La bibliographie propose permet dappro-
fondir les diffrents sujets prsents dans louvrage. La langue utilise est volontairement
peu technique pour rendre accessibles les concepts au public dbutant vis. Louvrage
sadresse des tudiants, de toutes les filires, qui dbutent dans ce domaine, mais aussi aux
professionnels qui veulent mettre en place une base de donnes, mme de taille modeste. En
effet, les problmes pratiques que pose la ralisation dune base de donnes se retrouvent
toutes les chelles, et ces aspects sont traits dans cet ouvrage au mme niveau que les
notions thoriques.
Organisation de louvrage
Le chapitre 1 est une introduction la notion de base de donnes et aux mtiers associs. Il
propose une mise en perspective de lvolution des bases de donnes, mais aussi de leur uti-
lisation (fouille de donnes, entrepts de donnes, etc.).
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 don-
nes. Aprs avoir nonc quelques conseils gnraux, on prsente ici les deux outils fonda-
mentaux que sont les transactions et les dclencheurs (triggers).
Notation
Les mots importants dune section sont mis en exergue par lutilisation de gras. Lorsque
lon fait rfrence des objets dfinis dans louvrage, par exemple une table, ils sont entre
guillemets simples (). Afin que la lecture soit facilite et les confusions vites, un mot
unique par chapitre a t choisi pour dsigner les synonymes que constituent les termes
attribut , champ et colonne . Le terme attribut est utilis dans le chapitre 2
pour le modle entit-association, le terme champ est utilis dans le chapitre 3 pour le
modle relationnel et le terme colonne est utilis dans le chapitre 4 consacr SQL. Les
noms des entits, des associations et de leurs attributs sont accentus dans le chapitre 2
alors que les noms des tables, des relations et de leurs champs ne sont pas accentus dans
les chapitres 3 et 4 car ils sont utiliss directement dans le code SQL ainsi que dans les
SGBD, qui ne les acceptent pas systmatiquement.
Les mots cls du langage SQL sont en majuscules pour les diffrencier facilement des par-
ties variables que sont les noms des colonnes et des tables qui sont en minuscules. Dans
la mesure du possible, les exemples en SQL sont indpendants du SGBD employ.
Ressources complmentaires
Les scripts prsents dans louvrage sont accessibles sur le site de Pearson Education
France (http://www.pearsoneducation.fr), diteur de louvrage. Vous y trouverez gale-
ment des jeux de donnes pour les bases de donnes que lon utilise ici ainsi que les scripts
de cration des diffrentes tables.
Remerciements
Je tiens remercier ric Innocenti pour son implication dans le projet. Je remercie parti-
culirement Christophe Lenne, chez Pearson Education France, notamment pour sa
patience.
Introduction aux
bases de donnes
1. Quest-ce quune base Au cours des dernires annes, les bases de donnes
de donnes ? .............................2
ont connu un dveloppement considrable, au point
2. volution des bases de donnes
et de leur utilisation ....................4 quelles jouent dsormais un rle dans chacune de
3. Systmes de gestion de bases
de donnes ..............................13 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
qui sy rattachent. La mthodologie qui permet de les
2. Recherche dichotomique ............22
3. Langages dun SGBD.................23 concevoir, les applications informatiques associes
4. Modles de reprsentation .........23
leur mise en uvre (SGBD) et les diffrents mtiers
5. Mtiers des bases de donnes ....23
6. Utilisateurs dune base des bases de donnes y sont prsents.
de donnes ..............................24
7. Vues externes ...........................24
8. Base de donnes rparties .........25
9. XML .........................................25
10. Fouille de donnes et entrepts
de donnes ..............................26
1
1 Quest-ce quune base de donnes ?
Le nombre dinformations disponibles et les moyens de les diffuser sont en constante pro-
gression. La croissance du World Wide Web a encore accru ce dveloppement, en fournis-
sant laccs des bases de donnes trs diverses avec une interface commune. Celles-ci se
situent au cur de lactivit des entreprises, des administrations, de la recherche et de bon
nombre dactivits humaines dsormais lies linformatique.
Dans le domaine purement informatique, elles interviennent dornavant tous les
niveaux. Les dveloppeurs dapplications sappuient sur des bases de donnes externes
pour grer leurs donnes alors quauparavant elles taient intgres dans le programme.
Citons un autre exemple : la gestion des fichiers dans les nouveaux systmes dexploitation
(par exemple, Panther de chez Apple ou le futur Vista de Microsoft) volue vers de
vritables bases de donnes mises jour en permanence. Elles permettent de retrouver les
fichiers instantanment, par leur nom mais aussi par leur contenu, la manire dun
moteur de recherche.
Les bases de donnes reposent sur des thories solides et sont lorigine dune des plus
importantes disciplines de linformatique : lingnierie des systmes dinformation.
Cette section prsente une ide intuitive de ce quest une base de donnes, de son utilisa-
tion puis des lments de qualit qui lui sont associs.
Tout le monde a une ide naturelle de ce que peut tre une base de donnes : elle peut
revtir la forme dune liste de CD contenant le nom des artistes et les titres des morceaux
ou encore celle de fiches de recettes de cuisine.
On remarque quune caractristique des donnes contenues dans une base de donnes est
quelles doivent possder un lien entre elles. En effet, des donnes choisies au hasard ne
constituent certainement pas une base de donnes. Celle-ci est donc une reprsentation
partielle et (trs) simplifie du monde rel, que lon a obtenu par un processus de modli-
sation. En rsum, on dfinit une base de donnes comme lensemble des donnes stoc-
kes. Pour les manipuler, on utilise gnralement un logiciel spcialis appel SGBD
(Systme de Gestion de Bases de Donnes). Il y a parfois confusion, par abus de langage,
entre base de donnes et SGBD. On appelle aussi systme dinformation lensemble
compos par les bases de donnes, le SGBD utilis et les programmes associs. Plus for-
mellement, on appelle Base de Donnes (BD) un ensemble de fichiers informatiques ou
non structurs et organiss afin de stocker et de grer de linformation.
La cration dune base de donnes recle un but prcis : elle doit permettre de retrouver de
linformation par son contenu en se fondant sur des critres de recherche. On dsire, par
exemple, retrouver toutes les recettes qui ncessitent des ufs ou tous les CD qui contien-
nent un morceau donn.
La grande diffrence avec un programme crit dans un langage de programmation est
quune base de donnes doit pouvoir rpondre des questions pour lesquelles elle na pas
forcment t prvue la conception.
Une autre diffrence est que les donnes sont susceptibles dtre utilises par des applica-
tions diffrentes. Dans un programme classique, la structuration des donnes est dcrite
il est ncessaire que lapplication obtienne des informations sur la structure des donnes
(nom, type, taille, etc.). Pour ce faire, on associe la base de donnes une description que
lon appelle mtadonne ou catalogue . Cette dernire dcrit la structure interne de
la base de donnes qui est spcifique au SGBD employ (voir figure 1.1). En plus de la
structure et du type des donnes, on stocke galement cet endroit les informations con-
cernant les rgles de cohrence des donnes abordes la section suivante.
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.
Comme on la voqu prcdemment, lun des objectifs de cration dune base de donnes
est de pouvoir retrouver les donnes par leur contenu. Dans cette optique, il faut sassurer
que les donnes contenues dans la base sont de bonne qualit .
Comment dfinir la qualit des donnes ? De nombreux critres peuvent tre pris en
compte ; on peut citer parmi les principaux :
la cohrence des donnes contenues dans la base ;
labsence de redondance.
La cohrence des donnes est fondamentale ; elle ncessite une rflexion pralable sur la
normalisation du contenu des champs. On suppose quun champ contient la qualit dune
personne (par exemple, Monsieur, Madame, Mademoiselle). Si lon trouve dans ce champ
Mr la place de Monsieur, il est clair que les recherches sur ce champ par le contenu Mon-
sieur risquent dtre errones. Dans ce cas, les informations seraient moins nombreuses que
celles obtenues avec le contenu correct. On qualifie cet tat de fait de silence , qui signifie
que certains rsultats pertinents sont ignors lors dune interrogation.
Dans un autre cas, si lon saisit Mme pour Madame et Melle pour Mademoiselle, et
quil y ait eu par erreur plusieurs saisies de Mme alors quil sagissait dune demoiselle,
la recherche par le contenu Mme donne cette fois plus de rsultats quil ny a rellement
de dames. On qualifie cet tat de fait de bruit , qui signifie que certains rsultats non
On remarque que lon stocke plusieurs fois la mme association dinformation (par exem-
ple, Nancy et 54000), ce qui consomme de la place inutilement et peut devenir significatif
lorsque la base atteint quelques millions denregistrements.
De plus il existe des incohrences dans la saisie du nom de la ville Bordeaux. La recherche
par le nom Bordeaux ne donnera pas le mme rsultat que la recherche par le code
33000.
On verra plus loin que lapproche relationnelle procure des outils capables de dtecter et
damliorer considrablement ce genre de problmes de qualit des bases de donnes.
2.1 CONTEXTE
partir des annes 1960, les ordinateurs voluent rapidement. Ils sont de plus en plus per-
formants mais aussi de plus en plus rpandus du fait de leur cot plus raisonnable. Leur
utilisation change galement ; on passe de la notion de calculateurs purs des machines
capables aussi de traiter de linformation. On parvient un niveau dabstraction suppl-
mentaire par rapport aux machines et on obtient en consquence une indpendance par
rapport larchitecture et surtout par rapport aux constructeurs.
La dcennie des annes 1970 est une priode faste pour la recherche et linnovation en
informatique dont les rsultats sont encore utiliss aujourdhui. On peut utiliser des lan-
gages de programmation de haut niveau, afin de guider, voire de faonner, la dmarche du
programmeur (Pascal), et lon envisage des systmes dexploitation indpendants de la
machine employe (Unix). Cest galement cette poque que lon pose les fondements
des techniques qui sont utilises dans les rseaux (TCP/IP), en particulier pour Internet.
Cest dans ce contexte favorable que E. F. Codd dfinit et dveloppe lapproche relation-
nelle en base de donnes.
2.2 MODLES
Figure 1.2
Modle Personne
hirarchique.
Nom
Prnom
NumINSEE
Voiture
Logement
Marque
Type
Numro
Couleur
Rue
Ville
Type
Modle objet
Dans le sillage du dveloppement des langages orients objet (C++, Java) dans les
annes 1980, le concept objet a t adapt aux bases de donnes. Plusieurs raisons, en
dehors des qualits reconnues de lapproche objet, ont conduit dfinir une extension
objet pour les bases de donnes (voir figure 1.4).
La premire est que le modle relationnel, dans sa simplicit, ne permet pas de modliser
facilement toutes les ralits. La deuxime est quun objet permet de reprsenter directe-
ment un lment du monde rel. Les structures dlments complexes se retrouvent sou-
vent disperses entre plusieurs tables dans lapproche relationnelle classique. De plus, le
concept objet est mieux adapt pour modliser des volumes de texte importants ou
dautres types de donnes multimdias (sons, images, vidos). Enfin, il est beaucoup
tent ainsi aux applications dveloppes en langage objet la persistance des objets
manipuls : ces derniers peuvent ainsi directement tre rutiliss par lapplication dori-
gine ou par dautres sans redfinition. Ces concepts ont t intgrs partir de la version 2
de la norme SQL.
Les produits commerciaux adapts ces concepts nont pas connu une diffusion suffisam-
ment importante. Le monde des bases de donnes volue assez lentement : la migration
dun systme dinformation vers lobjet reprsente pour une organisation un investisse-
ment considrable qui nest pas toujours justifi. La robustesse et la popularit de lappro-
che relationnelle, qui a mis presque vingt ans simposer, a galement frein le
dveloppement de lapproche objet pure dans les bases de donnes. Les donnes modli-
ses sous forme dobjets sont aussi plus complexes reprsenter du point de vue du SGBD
et lon rencontre encore trs souvent des problmes de performance.
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 gogra-
phiques, ne peuvent pas tre modliss efficacement en utilisant ce type dapproche. Lide
est alors dintgrer de lobjet au modle relationnel existant plutt que dutiliser lappro-
che objet pure. Il convient de remarquer que ce type dvolution a dj t dvelopp dans
le cadre des langages de programmation. Le langage C++ est lvolution intgrant lappro-
che objet du langage C et non pas un langage objet pur comme peut ltre Smalltalk.
Cette extension, adopte par la plupart des SGBD, se nomme relationnel-objet et per-
met aux concepteurs des bases de donnes de disposer de types volus abstraits plus
simples concevoir et surtout plus commodes faire voluer. Elle offre en outre la possi-
Duporche Jean-Marie
Chteau Romain
Paclaire Anne-Isabelle
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.
Figure 1.6
Filiale Est
Base de donnes Copie sauvegarde
rparties.
Sige social
Copie sauvegarde
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.
Tian Lastoul
Merlin Alize
Alize Teanne
Service
achats
Analyse
Entrept de
donnes
(datawarehouse)
Service
marketing
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 glisse-
ment de lide originale, qui consistait relier simplement des textes entre eux, vers la
notion dinterface universelle. On ne transmet plus seulement le contenu dun fichier sta-
tique, mais galement le rsultat de lexcution dun programme : le contenu devient donc
dynamique. Par extension, on imagine aisment que le mcanisme du Web peut gale-
ment transmettre le rsultat de linterrogation dune base de donnes.
Le concepteur du Web, T. B. Lee, sest appuy pour sa mise en uvre, outre la structure
technique existante dInternet, sur un langage de description de documents utilisant des
balises : le SGML (Standard Generalized Markup Language). Le dcoupage du document
par les balises est dcrit dans un document associ que chacun peut crer en fonction des
ses besoins : la DTD (Data Type Definition). Cette dernire, formule dans un langage
normalis, permettra des programmes spcialiss, les parsers , de vrifier si le docu-
ment est conforme la structure attendue et den extraire facilement le contenu. Le lan-
gage SGML est assez complexe manipuler, car il est trs gnral. Pour des besoins
spcifiques, on utilise des versions simplifies, telles que HTML ou XML.
T. B. Lee a donc dvelopp un langage de prsentation, HTML (Hyper Text Markup Lan-
guage), bas sur les notions dveloppes par SGML. Ce langage permet essentiellement de
spcifier des critres de prsentation (gras, soulign, couleur) et, bien sr, de dcrire les
liens entre les fichiers. Il ne comprend aucun lment de structuration des donnes du
texte contenu dans la page HTML. Les moteurs de recherche parcourent le Web et
indexent le contenu des pages par rapport des listes de mots cls combins dautres
mthodes (beaucoup) plus sophistiques. Cependant, ils ne peuvent diffrencier dans le
texte le titre dun rsum ou dune lgende associe une image. Lefficacit et la perti-
nence de lindexation en sont diminues dautant.
Pour remdier cela, le W3C (World Wide Web Consortium) a dfini un langage, qui est ga-
lement une simplification de SGML, permettant de dcrire la structure interne dun
document : XML (eXtended Markup Language). La structure dun document XML est repr-
sente sous la forme dun arbre tout comme celle dun document HTML. La description de
<catalogue> prix
nom
1000
prix
quantit
2 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 volu-
tions futures des SGBD.
trs forte dans ce domaine, les diteurs de SGBD se doivent dintgrer de linformation
multimdia (image, son, vido) dans les bases de donnes. Les bases de donnes multi-
mdias posent de nouveaux problmes, en particulier pour effectuer des recherches sur les
contenus multimdias, ce qui est par nature difficile.
Une solution est deffectuer une indexation prliminaire manuelle laide de mots cls qui
permettent doprer par la suite des interrogations, mais cela semble illusoire de raliser ce
traitement pour des volumes importants de documents multimdias. Dans le cas con-
traire, il existe des mthodes de recherche sur des fichiers de type image par rapport des
schmas prdfinis. Cette possibilit reste pour linstant plutt du domaine de la recher-
che, mme si lon est dj (malheureusement) capable didentifier des visages par rapport
un modle dans certaines conditions.Dans le mme ordre dide, il est dj possible
dutiliser des techniques pour valuer le style de musique (classique, jazz, pop) dun
fichier en analysant son contenu. On est cependant assez loin de pouvoir identifier un
genre de film en se basant sur lanalyse des images.
Les bases de donnes multimdias constituent un sujet de recherche trs prometteur et
trs actif. Ces problmatiques relvent pour linstant plutt des proccupations des soci-
ts dveloppant les moteurs de recherche que des bases de donnes au sens strict. Cepen-
dant, le groupe de normalisation ISO/IEC prpare lvolution pour le multimdia de la
norme SQL-MM, qui est une volution pour le multimdia de la norme SQL.
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 con-
tenu.
Une alternative au parcours squentiel est de construire des tables descriptives afin dacc-
lrer laccs aux donnes. Une premire table permet laccs direct un enregistrement
par une cl associe ladresse (pointeur) de lenregistrement. On rappelle que cest ce
mcanisme de pointeurs sur des enregistrements qui est modlis dans les modles
hirarchiques ou rseaux pour faire le lien entre des enregistrements. On constitue ainsi le
graphe qui permet de naviguer dans lensemble des enregistrements.
Une seconde table contient lordre relatif des enregistrements ordonns suivant les valeurs
dun champ : on appelle cette table un index (voir figure 1.11). Cette seconde table permet
demployer des mthodes de recherche par le contenu du champ index beaucoup plus
efficaces quune recherche squentielle. La recherche dichotomique bien connue est lune
dentre elles. Une fois lenregistrement identifi, on y accde directement grce la pre-
mire table. Les techniques de constitution des index constituent un sujet part entire
ainsi que les algorithmes de recherche qui leur sont associs.
Fichier et index.
Index
De mme que lISO a dtermin un modle thorique en sept couches pour distinguer les
applications rseaux et leurs interactions, il existe dsormais un modle thorique en trois
couches (trois niveaux dabstraction) afin de concevoir et dorganiser les fonctionnalits
des SGBD. Ce modle est labor par la commission SPARC de lANSI : cest larchitec-
ture ANSI/SPARC (voir figure 1.12). Cette dernire, qui date de 1975, sinscrit dans les
concepts et thories de la premire gnration des bases de donnes, dont lobjectif est
davoir une indpendance entre les donnes et les traitements :
Niveau interne ou physique. Cest le niveau le plus bas . On dcrit les structures de
stockage de linformation, ce qui le rend trs dpendant du SGBD employ. Il se fonde
sur un modle de donnes physique.
Niveau conceptuel. Il correspond limplmentation du schma conceptuel de la
base de donnes, que lon ralise lors de la phase danalyse (voir Modle Conceptuel des
Donnes, Modle Logique des Donnes). Il est utilis pour dcrire les lments constitu-
tifs de la base de donnes et les contraintes qui leur sont associes. Il sagit dune cer-
taine faon de la documentation de la base de donnes.
Niveau externe. Le niveau externe sert dcrire les vues des utilisateurs, cest--dire le
schma de visualisation des donnes qui est diffrent pour chaque catgorie dutilisa-
teurs. Un schma externe permet de masquer la complexit de la base de donnes com-
plte en fonction des droits ou des besoins des utilisateurs. Cela facilite la lecture et la
scurit de linformation.
Figure 1.12
Utilisateurs
Niveaux ANSI/ Niveau externe
SPARC. Vues
Il sagit comme pour le modle rseau de lISO dun cadre de rflexion ; les SGBD ne res-
pectent pas la lettre le dcoupage propos. Ils se doivent cependant de possder les prin-
cipales caractristiques qui dcoulent de ce modle en couches :
Indpendance physique des donnes. Masquer la reprsentation interne des donnes
ainsi que les mthodes systme daccs aux utilisateurs.
Indpendance logique des donnes. Permettre la modification du schma conceptuel
des donnes sans remettre en cause les mcanismes de stockage et de manipulation
internes des donnes.
Intgrit des donnes. Faire en sorte que linformation rsultant des liens entre les
donnes soit cohrente.
Il peut apporter galement des fonctionnalits supplmentaires utilises dans le cadre de
bases de donnes rparties dcrites prcdemment :
Rplication des donnes. Copie automatise de sauvegarde.
La reprsentation prcdente doit tre transforme pour la rendre acceptable par le SGBD,
quil soit relationnel, objet ou relationnel-objet. Souvent, cette tape modifie considra-
blement les objets du monde rel ainsi que les liens dfinis dans le schma prcdent. Cest
lors de cette phase que lon vrifie la qualit de la base de donnes en utilisant les critres
Une fois le schma prcdent dfini, on utilise le SGBD pour passer la cration des tables
qui constituent la base de donnes. Puis, on insre videmment les valeurs dans les tables.
Le cas chant, on cre les vues dfinies ltape prcdente et par l mme les utilisateurs
concerns. Le systme est alors oprationnel. Toute cette tape se fait forcment en utili-
sant le SGBD, alors que les prcdentes taient plus thoriques. La cration des tables et
lutilisation de la base de donnes ncessiteront le langage SQL. Cependant, il existe de nos
jours de nombreux outils graphiques dans les SGBD qui masquent lutilisation du SQL.
Figure 1.13
tapes de la Monde rel
conception dune
base de donnes.
Analyse
Modle
entit-association
Vue 1
Transformation
LMD
Schma SGDB
Vue 2 LDD
relationnel
Base de
donnes
Vue 3 physique
Comme on peut le constater lorsque lon considre les diffrentes tapes de la conception
dune base de donnes, des acteurs aux comptences trs diverses interviennent dans ce
processus.
5.1 CONSULTANTS/ANALYSTES
Ils prennent en charge la premire tape qui consiste en lanalyse des activits et des flux
dinformation mis en jeu dans le monde rel modliser. Le profil de ces acteurs nest pas
toujours purement technique, puisque cette phase ncessite parfois beaucoup de dialogues
et de psychologie pour parvenir faire exprimer leurs besoins rels par les futurs utilisa-
teurs. La gageure est de parvenir faire exprimer correctement les besoins dinformatisa-
tion par les utilisateurs du systme dinformation, afin de proposer un modle conceptuel
de donnes le plus juste possible.
Ce sont les personnes qui soccupent de traduire le modle prcdent en un modle logi-
que exploitable par le SGBD. Le concepteur est un spcialiste des bases de donnes qui
prpare les tables, les vues, les schmas daccs. Cest lui qui renseigne les utilisateurs et
programmeurs pour la dfinition des requtes. Il na pas, en principe, tre spcialis sur
un SGBD particulier, mais en pratique les lments quil manipule sont lis au SGBD qui
sera employ. Cest ordinairement lui qui cre les lments ncessaires la base de don-
nes (tables, vues) en collaboration avec ladministrateur de la base. Cest parfois la
mme personne qui est en charge de la partie analyse et de la conception, ce qui peut
induire une vision un peu trop oriente techniquement comme celle dun programmeur
qui crirait le cahier des charges dune application. Par contre, le concepteur peut aussi
tre administrateur du SGBD, ce qui ne pose pas de problmes particuliers dapproche.
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.
7 Prsentation de la BD exemple
Une base de donnes extrmement simplifie est utilise rgulirement tout au long de
louvrage afin dillustrer les concepts dvelopps au fil de louvrage. Dautres bases de don-
nes plus complexes sont prsentes au fur et mesure des explications (voir figure 1.14).
Ce systme dinformation qui constitue ltude de cas basique modlise lactivit de vente
de voitures doccasion. Dans ce systme, deux entits du monde rel sont identifies : les
personnes et les voitures. Une voiture est caractrise par sa marque, son type, sa couleur.
Une personne est caractrise par son nom, son ge, sa ville, son sexe. Laction modlise
est la vente qui est caractrise par le prix de la vente et sa date. Une personne peut acheter
une plusieurs voitures. Une voiture peut tre vendue une seule fois ou jamais.
Vente
ge
Type Couleur
Ville
Sexe
Rsum
Une base de donnes dsigne lensemble des donnes stockes. Pour manipuler ces don-
nes, on utilise un SGBD (Systme de Gestion de Bases de Donnes) qui est un logiciel com-
plexe. Lensemble compos par les donnes et le SGBD constitue un systme
dinformation. La conception dune base de donnes de la modlisation du monde rel
son implmentation dans le SGBD fait appel des techniques et des mthodes trs dif-
frentes pour chaque tape. Des mtiers spcifiques se sont donc dvelopps autour de ces
concepts et les mettent en uvre. Par exemple, lapproche du monde rel sapparente
lanalyse faite par un cabinet de consulting alors que limplmentation dans le SGBD et
son administration sont proches des mtiers informatiques.
Les SGBD ont volu paralllement aux concepts de modlisation des bases de donnes.
On est pass dune organisation comparable celle des fichiers informatiques (modles
hirarchiques ou rseaux) un modle plus abstrait : le modle relationnel. Ce modle est
toujours le plus utilis actuellement. Il est associ troitement SQL, un langage norma-
lis de description, de manipulation et dinterrogation de donnes. La modlisation objet,
adapte aux bases de donnes, na pas connu un dveloppement considrable, et ce, mal-
gr les avantages quelle procure par rapport au modle relationnel en particulier pour le
typage des donnes. Comme cest le cas dans le domaine de la programmation, une
approche mixte semble prendre de lampleur : le modle relationnel-objet. Il sagit
dapporter au modle relationnel les possibilits tendues de modlisation procures par
les objets sans remettre profondment en question lexistant.
Le dveloppement des rseaux apporte dautres manires dutiliser les bases de donnes,
comme la rpartition des donnes pour amliorer leur disponibilit et leur scurit.
Linterfaage avec le World Wide Web a introduit la prise en compte du langage XML
comme format dchange et de stockage par les SGBD. De nouvelles formes dinterroga-
tion, telles que la fouille de donnes (ou data mining) et les bases de donnes dducti-
ves, permettent dextrapoler de linformation non explicitement stocke dans les bases de
donnes. Ces approches ainsi que la prise en compte des donnes multimdias vont faire
voluer les modles de bases de donnes et les SGBD que lon utilise actuellement. Cela se
fera probablement sans remettre totalement en cause le modle relationnel, mais plutt en
le faisant voluer progressivement.
Quelles sont les diffrences majeures entre un fichier informatique et une base de don-
nes gre par un 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.
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.
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 pro-
cessus de construction dune base de donnes. Ce nest videmment pas la bonne
mthode, car la vision dun systme dinformation labor par un administrateur de base
de donnes est trs oriente par le SGBD quil emploiera. On peut facilement faire le
parallle avec le dveloppement de logiciels o un programmeur va avoir une approche
dforme par les proccupations lies au langage plutt que dadopter un point de vue sur
la structure gnrale de lapplication. Au minimum, la personne devra disposer des com-
ptences en conception de base de donnes et en administration du SGBD qui sera utilis.
Exercices
On utilise pour cet exercice la base de donnes exemple de vente de voitures. On consi-
dre les oprations suivantes :
1. Ajouter une personne dans le fichier client.
2. Modifier les possibilits dajout dans le champ couleur .
3. Augmenter la taille du champ couleur.
4. Sortir le chiffre daffaires par marques pour le mois en cours afin de limporter dans
un tableur.
5. Enregistrer une vente.
Quels types dutilisateurs sont concerns par ces oprations ?
1. Un utilisateur final (par exemple un vendeur) muni des droits appropris peut interve-
nir sur le contenu des donnes.
2. Pour cette opration, cela dpend sil sagit dune convention ou si cela est entr au
niveau des contraintes du SGBD. Dans le premier cas, un utilisateur final peut sen
charger ; dans le second, il faut recourir au concepteur ou ladministrateur de base de
donnes.
3. Pas dambigut ici, car on touche la structure mme des donnes ; cela est du ressort
du concepteur ou de ladministrateur de base de donnes.
4. Il sagit du domaine du programmeur dapplication qui rcupre les donnes en utili-
sant le SGBD et qui les traite dans un programme pour leur donner leur forme finale.
5. Un utilisateur final (par exemple un vendeur ou la comptabilit) muni des droits
appropris peut intervenir sur le contenu des donnes.
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 voitu-
res en stock (non encore vendues).
2. Les vendeurs, sils grent galement le parc de voitures comme cest souvent le cas, peu-
vent avoir accs en lecture et en criture toutes les donnes (ventes, voitures, person-
nes).
3. Le service comptabilit peut avoir accs en lecture toutes les informations, mais ne
peut modifier les informations concernant les voitures ou les personnes du fichier
client.
On dcide de recopier rgulirement une base de donnes complte sur chacun des six
sites de lentreprise. Quel est lintrt de cette solution ?
EXERCICE 9 XML
Pourquoi prfre-t-on utiliser XML plutt que HTML pour reprsenter les donnes pro-
venant dune base de donnes ? Les donnes XML sont dites autodescriptives . Quest-
ce que cela signifie et par quel(s) dispositif(s) est-ce ralis ?
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
Par des mthodes danalyse dassociations, on dcouvre quen utilisant votre systme
dinformation les clients dont le nom commence par M achtent le samedi plus de pro-
duits que les autres. Ils gnrent donc un chiffre daffaires plus important, mais ces pro-
duits sont marge faible et le bnfice est moins important que pour ceux dont le nom
commence par un Z. Quavez-vous intgr comme donnes dans votre entrept de don-
nes pour pouvoir effectuer cette opration en supposant que votre entreprise soit orga-
nise avec une structure de services classique ?
Pour obtenir les lments ncessaires lanalyse, il nous faut intgrer les donnes de diff-
rents services de lentreprise.
Les donnes du fichier clientle sont gres par le service commercial (peut-tre avec
un tableur ou un traitement de texte pour faire des mailings) afin dobtenir le nom des
clients.
Les donnes du service comptabilit permettent dobtenir les journaux de ventes ; la
gestion est faite par exemple par une application de gestion spcifique connecte aux
caisses.
Les donnes du service achat sur les ngociations avec les fournisseurs peuvent tre
gres par exemple par une application dveloppe en interne. La marge provenant de
la ngociation avec les fournisseurs est fluctuante pour le mme article au cours du
temps en fonction du march, des personnes qui ngocient, etc. Il serait donc intres-
sant pour ces donnes de disposer des valeurs historises par priodes pour affiner
lanalyse par des tendances.
Pour intgrer ces donnes provenant de sources diffrentes dans votre entrept de don-
nes, vous utiliserez une (ou plusieurs) application(s) de type ETL (Extract, Transform and
Load) que lon appelle aussi datapumping .
Analyse du monde
rel
1. Dmarche danalyse .................28 Ce chapitre prsente la premire tape du processus
2. Modlisation par le modle de modlisation du monde rel, qui consiste
entit-association ......................30
3. Remise en cause et volution
recueillir les informations puis les transcrire sous
du modle ...............................35 une forme conduisant un passage ais au modle
4. Reprsentation avec UML ..........40
relationnel.
Exercices
1. Identifiant dune entit ...............44
On utilise cette fin le modle entit-association,
2. Identification des entits dont les concepts et la mise en uvre sont prsents
et des associations ....................44
dans ce chapitre. Cette dmarche de modlisation est
3. Questions associes
aux cardinalits ........................45 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
utilisant le formalisme du modle entit-association
8. De lnonc au modle
entit-association ......................51 est progressivement remplace par le langage de
9. Reprsentation avec UML ..........52
modlisation UML. Ce dernier apporte, en plus des
10. Autre exemple le camping
lUliastru ..................................53 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
1 Dmarche danalyse
1.1 APPROCHE DU MONDE REL
Comment apprhender et simplifier le monde rel, par nature complexe, pour raliser une
modlisation ?
Cette tche relve de comptences multiples du domaine dun cabinet de consulting. Il est
ncessaire didentifier les besoins des utilisateurs ainsi que les objectifs et les processus
dalimentation en donnes des systmes dinformation concevoir. Les bases de donnes
sont dornavant au cur de la plupart des applications, et leur structure doit correspon-
dre au mieux aux attentes de lorganisation.
Son laboration ncessite diffrentes tapes et se droule souvent en mme temps que le
processus danalyse du problme. Des allers-retours entre ces diffrentes tapes de la con-
ception sont souvent ncessaires la constitution du modle conceptuel de la base. On
qualifie alors ce processus ditratif. Il sagit de construire la structure de la base de don-
nes par raffinements successifs.
La premire phase de lanalyse du monde rel du problme est ralise par des entretiens,
gnralement codifis, avec les utilisateurs. On effectue une analyse du discours pour en
extraire linformation utile que lon resitue dans le contexte de lorganisation en gnral.
Lobjectif principal est de guider lanalyste, on utilise des mthodes danalyse et de con-
ception issues de ltude des flux dinformation de lentreprise. Parmi celles-ci, on peut
citer la mthode Merise dorigine franaise trs rpandue en France dans les annes
1980 ainsi que dautres issues de la recherche et du gnie logiciel, ou spcifiques des
grandes entreprises de consulting.
La prsentation de ces mthodes fort complexes dpasse largement le cadre de cet ouvrage.
Lobjectif de cette section est de donner quelques pistes pour approcher la ralit mod-
liser. Lexpression des besoins repose sur la formulation du problme laide de phrases
simples qui dcrivent la ralit modliser. Ces phrases se prsentent sous la forme
sujet-verbe-complment , avec une tournure active quand cela est possible. Le but est
dobtenir deux types de phrases :
Celles qui dcrivent les liens entre les objets du monde rel gnralement une action
ou une proprit. Exemple : Un lecteur emprunte un livre. Un livre a un auteur.
Celles qui caractrisent la manire dont sont relis ces objets. Exemple : Un lecteur est
considr comme lecteur sil a au moins dj emprunt un livre. Un livre peut tre
emprunt par plusieurs lecteurs. Il ny a pas de livres anonymes, un livre est crit par au
moins un auteur.
On doit ensuite prciser les donnes qui constituent les objets ainsi que celles qui caract-
risent les liens entre les objets.
Remarque
Le terme dobjet du monde rel employ ici nest pas pris au sens de la programmation objet. Il
sagit plutt de caractriser un regroupement logique de donnes. Un titre, un auteur, un diteur
constituent un livre. Un nom, un prnom, un numro de Scurit sociale constituent une personne.
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.
Les entits sont composes de champs de donnes que lon nomme attributs. Un attribut,
ou un ensemble dattributs, doit tre choisi comme identifiant de lentit, avec pour
objectif didentifier une occurrence (ou reprsentant) de cette entit. La notion didenti-
fiant a les mmes proprits que la cl dans une relation qui sera introduite au chapitre 3.
On reprsente une entit par un rectangle qui contient le nom de lentit et ses attributs.
Lidentifiant est soulign ou prcd dun caractre # (voir figure 2.1).
Le choix de lidentifiant nest pas toujours trivial. Il est parfois ncessaire dintroduire arti-
ficiellement un attribut supplmentaire afin de pouvoir disposer dun identifiant. Dans le
cas de lhtel, il faudrait intgrer un attribut pour identifier un client (voir figure 2.2),
dans la mesure o aucun des attributs issus de lanalyse ne permet didentifier de manire
unique un client. Classiquement, une identification sans ambigut reposera sur un
numro unique ; dans notre exemple, cest lattribut IDClient.
Les identifiants peuvent tre composs par la juxtaposition de diffrents attributs. Par
exemple, on peut identifier un client en juxtaposant les attributs nom+pr-
nom+date_naissance+ville_naissance. En effet, il est peu probable que deux homonymes
soient ns le mme jour dans la mme ville. Cependant, dans la pratique, il est recom-
mand, autant que faire se peut, de choisir un seul attribut comme identifiant. En effet, il
sera plus difficile de vrifier quun identifiant composite reste valide lorsque les donnes
voluent. Cest pourquoi, quand cela est possible, il est indispensable de choisir un identi-
fiant dont les contenus ne sont pas susceptibles dvoluer au fil du temps. On prfre iden-
tifier une personne par un numro de scurit sociale que par un numro de passeport qui
a une dure de validit limite.
Figure 2.2
Client
Entit client.
# IDClient
Nom
Adresse
NumTlphone
Les associations reprsentent les liens qui existent entre les entits. Elles sont composes le
cas chant dattributs, bien que cela ne soit pas indispensable. Par consquent, il nest pas
ncessaire de disposer dun identifiant pour une association. Lorsque les entits sont asso-
cies par deux, elles sont qualifies de binaires. Cependant, il est possible den associer
plus de deux ; les associations sont alors non plus binaires, mais n-aires. Le nombre
dentits associes sappelle le degr de lassociation.
On reprsente une association par un ovale qui contient le nom de lassociation et ses
attributs.
Figure 2.3
Chambre
Entits client et
chambre relies # IDChambre
NombrePlaces
par lassociation Tarif
location. Client
Location
# IDClient
DateDbut Nom
NombreJours Adresse
NumTlphone
Il peut galement y avoir plus dune association entre deux entits ; cest le cas de lexem-
ple de lhtel (voir figure 2.4). Les entits client et chambre sont relies par deux associa-
tions ayant des attributs diffrents : location et rservation.
Figure 2.4
Chambre
Entits client et
chambre relies # IDChambre
NombrePlaces
par les Tarif
associations Client
location et Location
rservation. DateDbut
# IDClient
Nom
NombreJours 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.
# IDPersonne
2
Chapitre
Nom
lassociation Adresse
est_mari_. 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 ci-
aprs (voir figure 2.6) , une association binaire sera caractrise entirement par quatre
nombres. En effet, chaque entit participe de manire diffrente lassociation.
Figure 2.6
Chambre
Cardinalits dune
association # IDChambre
NombrePlaces
binaire. Tarif
0,n Client
Location
# IDClient
DateDbut 1,n Nom
NombreJours 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.
NumAch
2
Chapitre
Nom
lassociation ge
vente avec Ville 1,n Vente Voiture
cardinalits. Sexe
DateVente # NumVoit
Prix 0,1 Marque
Type
Couleur
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.
Dans cette sous-section, on remet en cause le dcoupage en entits produits par une pre-
mire approche. Le processus itratif de cette remise en cause peut conduire un redcou-
page des entits ou leur fusion.
On considre lexemple de la bibliothque de prt, que lon a dj utilis prcdemment. La
phrase caractristique dcrivant lactivit de la bibliothque est la suivante : Un lecteur
Figure 2.9
Livre
Entits livre et
lecteur lies par Titre
Auteur
lassociation #ISBN
emprunte (sans diteur Lecteur
Emprunte
cardinalits).
DateEmprunt # NumLecteur
Nom
Prnom
Adresse
Cet exemple simple permet de se poser quelques questions qui vont conduire une ror-
ganisation du modle.
#Cote
2
Chapitre
Est un
exemplaire
Livre
Titre
Auteur
#ISBN
diteur
Figure 2.11
Ouvrage
Entits livre,
ouvrage, Lecteur
#Cote Emprunte
auteur et ISBN
# NumLecteur
DateEmprunt
lecteur lies par Nom
les associations Prnom
emprunte, Adresse
a_crit et est un
exemplaire (sans
cardinalits).
Est un
exemplaire
Livre
Auteur
Titre # NumAuteur
#ISBN A crit Nom
diteur Prnom
Figure 2.12
Ouvrage
Entits livre,
ouvrage, Personne
#Cote Emprunte
personne lies ISBN
# NumLecteur
DateEmprunt
par les associations Nom
emprunte, Prnom
a_crit et Adresse
est_un_exemplaire
(sans
cardinalits).
Est un
exemplaire A crit
Livre
Titre
#ISBN
diteur
On a identifi dans cette sous-section plusieurs cas qui ncessitent de rorganiser les enti-
ts obtenues lors dune premire analyse :
Si lon repre lintrieur dune entit des attributs qui reprsentent un ensemble logi-
que (mis en valeur dans lexemple par un dfaut didentifiant pour un livre), on spare
ces attributs dans une entit supplmentaire.
Si des attributs dans une mme entit possdent une smantique identique (auteurs,
numros de tlphone multiples), on cre une entit supplmentaire pour sparer ces
attributs. Cette entit sera associe celle dont proviennent les attributs lorigine.
Si des entits ont la mme structure (et reprsentent le mme type dobjet), on les
fusionne et lon conserve les associations qui existaient avant la fusion.
On retrouvera ce processus de remise en question du modle un autre niveau, lors de
ltape de normalisation qui est aborde au chapitre 3.
limination dassociations
On considre le cas dun acte dachat effectu sur Internet avec une carte bancaire. Une
facture est rgle par une carte. On peut distinguer les deux entits facture et carte .
Une facture est identifie par un numro de facture, et est constitue dun montant et
dune date. Une carte bancaire est identifie par son numro, son type (Visa, Master-
Card), sa date de validit et son propritaire. Les cardinalits entre les entits carte et
facture sont de type 1-1 (une facture est paye par une et une seule carte) et 1-n (une
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
Carte
Entits carte et
Facture
facture lies par #NumCarte 1,1
lassociation Type
Rgle # NumFacture
rgle avec ses DateValidit
Montant
Propritaire
cardinalits. DateFacture
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).
0,n
0,n
Saxophone
Comme il sagit de la mme activit (un musicien interprte un morceau), on peut rempla-
cer toutes les associations par une association interprte. Lassociation interprte contien-
drait lattribut instrument pour ne pas perdre linformation de linstrument associ (voir
figure 2.16).
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 mor-
ceau, 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 it-
ratif de constitution du modle par raffinements successifs. Le processus se poursuivra
un autre niveau par la normalisation des relations dduites de ce modle. Cette partie sera
traite au chapitre 3.
Quel est le rapport avec les bases de donnes ? UML a t adapt afin dtre utilis pour la
modlisation en bases de donnes : on recourt cet effet un profil spcifique (UML pro-
file for data modeling). Mme sil est prvu initialement uniquement pour la modlisation
objet, UML permet aussi de reprsenter un modle conceptuel utilisable pour crer des
bases de donnes relationnelles et relationnelles-objet. Les approches objet et relationnel-
les-objet en bases de donnes ont t introduites dans le premier chapitre et dpassent lar-
gement le cadre de cet ouvrage.
En outre, une motivation supplmentaire pour utiliser UML est de pouvoir disposer doutils
logiciels graphiques du march pour la description et lautomatisation du processus de pas-
sage au SGBD, allant jusqu la gnration de code SQL. UML offre des garanties de pren-
nit du fait de sa normalisation. Mme si UML napporte pas dvolutions majeures quant
aux mthodes existantes de modlisation en bases de donnes, il est de plus en plus large-
ment rpandu et permet dutiliser le mme formalisme et les mmes outils que les concep-
teurs dapplications logicielles.
peut ltre la mthode Merise qui associe une mthodologie et un langage de description.
Classes
Dans ce type de reprsentation les entits sont interprtes comme des objets et sont
reprsentes par des classes. La description dune classe en UML comprend trois parties :
le nom de la classe ;
la description des attributs ;
les mthodes associes lobjet.
Cette section nutilise pas la notion de mthode spcifique lapproche objet. La descrip-
tion des attributs peut tre ralise de manire plus prcise. UML offre la possibilit de
dcrire ce niveau le domaine de lattribut :
jour : (lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche)
Une classe est reprsente graphiquement par un rectangle spar en trois zones corres-
pondant aux trois parties prcdentes (voir figure 2.17).
Figure 2.17
Voiture Nom de la classe
Entit voiture
reprsente par # NumVoit
Marque
une classe UML. Type Attributs
Couleur
Mthodes
Associations et multiplicit
Les classes sont relies par des associations identifies par leur nom. Si lassociation pos-
sde elle-mme des attributs, ils sont intgrs dans une classe dassociation. Lexpression
des cardinalits est quasiment la mme en UML que pour le modle entit-association ;
elles sont appeles multiplicit. UML permet de dfinir plus prcisment les cardinalits
en utilisant les valeurs suivantes.
1. Obligatoire, un et un seul (peut scrire galement 1..1).
*. Non obligatoire (peut scrire galement 0..n).
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 dasso-
ciation de degr suprieur aux associations binaires.
La notation UML est utilise dans cette section pour reprsenter les entits et les associa-
tions issues de la dmarche danalyse primitive que lon a dcrite dans la premire sec-
Rsum
Ce chapitre aborde lapproche de la modlisation, qui consiste dabord extraire les infor-
mations du monde rel puis en proposer une reprsentation formelle appele modle
conceptuel. Il nexiste pas rellement de dmarche scientifique pour raliser cette
tape. Elle est plutt constitue dun ensemble de techniques diverses qui permettent
dapprhender la complexit du monde rel modliser et de la simplifier.
Lanalyse du monde rel a pour but de pouvoir identifier les donnes qui interviennent
dans le domaine considr et de les regrouper dans des objets. Ltape suivante consiste
caractriser les liens qui les unissent. cette fin, on dcrit le systme modliser par des
phrases simples de type sujet-verbe-complment , que lon peut classer en deux gran-
des catgories :
celles qui dcrivent les objets du monde rel et les liens qui les unissent : le sujet et le
complment sont reprsents par des entits (classes) et le verbe est reprsent par une
association ;
celles qui dcrivent la manire dont sont relis ces objets : on en dduira les cardinalits
(ou multiplicits dans le cas dutilisation dUML) des associations.
Les entits sont constitues de champs de donnes que lon nomme attributs . Pour
identifier de manire unique les reprsentants dune entit, appels galement
instance , un attribut (ou un ensemble dattributs) est choisi : on lappelle
identifiant . Une fois les lments modliser identifis, leur reprsentation normalise
recourt diffrents langages. Les deux types de formalismes les plus courants employs
sont les suivants :
Le modle entit-association. Il a fait ses preuves ; sa notation est trs intuitive et il est
encore couramment utilis.
UML (Unified Modeling Language). Il reprsente (probablement) lavenir, car il est
soutenu par une communaut trs importante qui dpasse celle des bases de donnes.
Il offre lavantage dtre bien adapt la modlisation de donnes complexes qui nces-
sitent une approche objet.
Ni le modle entit-association, ni UML ne sont des mthodes danalyse ; il sagit dans les
deux cas de simples formalismes de reprsentation.
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. Classique-
ment, on utilisera un chiffre identifiant que lon peut nommer Numero_salle.
On veut modliser lactivit de vente de billets pour un thtre. Quelles phrases vont nous
permettre didentifier les entits et la manire dont elles sont associes ? Proposez les at-
tributs que vous utiliseriez pour dcrire ces entits et leurs associations ainsi que les iden-
tifiants de chaque entit. Que se passe-t-il si le prix du billet varie pour chaque sance et
en fonction de la place ?
Les lments qui simposent intuitivement sont les spectateurs et la pice joue. La phrase
qui reprsente le lien entre ces entits peut tre de la forme : les spectateurs achtent un
billet pour une pice .
On identifie deux entits spectateur et pice lies par lassociation achat.
Lentit spectateur contient les attributs nom, numro de tlphone. On cre un identi-
fiant numero_client puisque nom et numro de tlphone ne sont pas identifiants. On
Lentit pice comprend un titre, lauteur, le metteur en scne et le prix dune place (on
suppose que toutes les places sont au mme prix). De mme que pour lentit spectateur,
on a besoin de crer un identifiant pour la pice.
Lassociation a pour attributs la date et le numro de sige. Ces attributs sont en effet carac-
tristiques de laction dachat et non pas du spectateur ou de la pice (voir figure 2.20).
Figure 2.20
Spectateur
Entits
spectateur et # Num
pice lies par
lassociation Nom
Achat Pice
achat (sans
cardinalits). Tel DateAchat
# NumPiece
NumSiege
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.
Dans lexemple sur la bibliothque, prsent prcdemment dans ce chapitre, on est par-
venu au modle suivant la suite de la remise en cause du modle (voir figure 2.21) :
Les entits livre ouvrage sont lies par lassociation est_un_exemplaire
Les entits personne et livre sont lies par lassociation emprunte.
Les entits personne et livre sont lies par lassociation a_crit.
Figure 2.21
Entits livre,
ouvrage, personne Ouvrage
lies par les associa- Personne
tions emprunte, #Cote Emprunte
ISBN
a_crit et DateEmprunt # NumLecteur
est_un_exemplaire Nom
Prnom
(sans cardinalits). Adresse
Est un
Exercices
exemplaire A crit
Livre
Titre
#ISBN
diteur
On doit dterminer pour chaque association les deux cardinalits minimales et maximales
associes aux deux entits lies, puisquil sagit dassociations binaires. Il y aura donc qua-
tre questions (se) poser par association. On pose ici les questions et on propose les
rponses ; dans la vie relle, ce sont les utilisateurs de la base de donnes qui apporteraient
les rponses (voir figure 2.22).
Association est_un_exemplaire
Pour dterminer les cardinalits du ct de lentit ouvrage :
Peut-on avoir une fiche douvrage sans disposer du livre lui-mme dans la
bibliothque ? Si cest le cas, la valeur minimale sera de 0, sinon elle sera 1. La valeur
1 est plus logique dans ce contexte, sauf si lon a rcupr le catalogue descriptif dun
diteur.
Une fiche douvrage peut-elle servir plusieurs livres ? Si cest le cas, la valeur maxi-
male sera de n ; sinon, elle sera de 1. Cest le but ici de regrouper les informations
douvrages communes plusieurs exemplaires. La cardinalit maximale choisie est de
n.
Pour dterminer les cardinalits du ct de lentit livre :
Peut-on avoir un livre sans avoir de fiche ouvrage ? Si cest le cas, la valeur minimale
sera de 0, ; sinon, elle sera de 1. Il parat clair que tout livre a une fiche ouvrage,
moins quil ne soit juste identifi dans la bibliothque mais pas encore catalogu.
Un livre peut-il avoir plusieurs fiches ouvrage ? Si cest le cas, la cardinalit maximale
sera de n ; sinon, elle sera de 1. On peut supposer quun livre na quune fiche
ouvrage.
Association emprunte
Pour dterminer les cardinalits du ct de lentit livre :
Un livre peut-il navoir jamais t emprunt ? Si cest le cas, la valeur minimale sera de
0 ; sinon elle sera de 1. On choisit 0 : un livre peut ne rencontrer aucun succs.
Un livre peut-il tre emprunt plusieurs fois ? Si cest le cas, la valeur maximale sera de
n ; sinon elle sera de 1. On rappelle quune base de donnes modlise une activit sur
une priode de temps. Un livre peut tre emprunt plusieurs fois mme si lon ne peut
pas le prter deux personnes simultanment. On choisit n.
Pour dterminer les cardinalits du ct de lentit personne :
Une personne peut-elle ne pas avoir emprunt de livre ? Si cest le cas, la valeur mini-
male sera de 0 ; sinon, elle sera de 1. Une personne ne sinscrit la bibliothque que
dans le but demprunter un livre ; elle en a donc au moins emprunt un. On choisit 1.
Une personne peut-elle emprunter plusieurs livres ? Si cest le cas, la cardinalit maxi-
male sera de n ; sinon, elle sera de 1. On choisit n : un lecteur nest pas limit
lemprunt dun seul livre.
Association a_crit
Pour dterminer les cardinalits du ct de lentit ouvrage :
Un ouvrage peut-il ne pas avoir dauteur ? Si cest le cas, la valeur minimale sera de 0 ;
sinon, elle sera de 1. On choisit 1 : on suppose quil ny a pas de livre anonyme.
Figure 2.22
Ouvrage
Entits livre,
0,n Personne
ouvrage, #Cote Emprunte
personne lies ISBN
# NumLecteur
DateEmprunt
par les 1,n Nom
associations Prnom
emprunte, Adresse
1,n
a_crit et 0,n
est_un_exemplaire
(avec
Est un
cardinalits).
exemplaire A crit
Livre
Titre
1,1
#ISBN
diteur 1,n
On considre le schma entit-association, muni de ses cardinalits, qui dcrit une partie
de lorganisation de sminaires (voir figure 2.23).
Figure 2.23
Entits Th me
sminaire,
thme, # NumThme
0,n Sminaire
intervenant Libell
Traite
lies par les 1,1 # NumSminaire
associations DateSem
traite, 1,n NbeJours
est_responsable NbeInscrits
1,1
et intervient Prix
Anime
(avec
cardinalits). Salaire
NbeHeures
Exercices
Intervient
0,n Est_responsable
# NumInter Prime
Nom
Prnom 0,n
Un sminaire traite dun thme et dun seul (cardinalit 1-1). Un thme peut tre trait
par aucun sminaire ou par plusieurs (cardinalit 0-n).
Un sminaire a un intervenant au minimum (cardinalit 1-n). Un intervenant peut inter-
venir dans plusieurs sminaires ou aucun (cardinalit 0-n).
Un sminaire a toujours un responsable et un seul (cardinalit 1-1). Un intervenant peut
ntre responsable daucun sminaire ou ltre de plusieurs (cardinalit 0-n).
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 gnra-
lement inutiles : il est prfrable de les remplacer par une entit unique mme si lon perd
en lisibilit au niveau du schma. On fusionne les entits parasite et hte en une seule
entit cosystme (voir figure 2.24).
Figure 2.24
Parasite
Entits parasite-
hte lies par # NumParasite 1,1
lassociation
utilise et fusion NomPara
Utilise Hte
en une entit
unique. # NumHte
1,1
NomHte
cosystme
# NumHte
NomHte
NumParasite
NomPara
On veut reprsenter les liens de nourriture entre des humains, des animaux et des vg-
taux. Lide, partir des schmas dalimentation modliss, est de pouvoir dduire des
chanes alimentaires de ce type : un homme mange un lapin qui mange des carottes .
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 0,n
humain_animal
_vgtal lie par
# IdHAV
lassociation
mange (avec NomHAV
cardinalits). Mange
0,n
partir de la base de donnes exemple de vente de voitures, on souhaite ajouter les in-
formations concernant le vendeur qui a ralis la vente. Proposez une (ou plusieurs) mo-
dification(s) du modle entit-association labor prcdemment. Ajoutez les nouvelles
cardinalits introduites par cette modification.
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.
Exercices
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.
Figure 2.26
Client
Entits voiture,
client et NumAch
Nom
vendeur lies ge
par les Ville 0,n Vente Voiture
associations Sexe
DateVente # NumVoit
ternaire vente Prix Marque
0,1
(avec Type
cardinalits). Couleur
0,n
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
Client
Entits voiture,
client, vendeur NumAch
Nom 1,n
et vente lies par ge
des associations Ville Voiture
binaire aprs Sexe Vente
transformation de 1,1 # NumVoit
lassociation # NumVente 1,1 0,1 Marque
DateVente Type
ternaire vente en Prix Couleur
entit (avec
cardinalits).
1,1
Vendeur
# NumVendeur
Nom
1,n
Tl
Vous dsirez grer un club de prt de DVD. Les clients (adhrents du club) versent une
somme sur leur compte lors de leur adhsion. Ils peuvent rserver le film avant de le louer
et peuvent le garder une semaine au maximum. Le prix de location du film est forfaitaire
par jour emprunt. Il leur est possible de se faire livrer le film chez eux : cette opration
est facture forfaitairement en plus.
Le film est dcrit par son titre, le genre du film, le ralisateur et les trois acteurs princi-
paux. On prcise galement le nombre de DVD (il peut y en avoir plusieurs dans la
pochette : making of , autres versions, etc.) et leur prix dachat qui permettra de dbi-
ter le compte du client en cas de non-retour du film.
Vous voulez pouvoir annuler et mettre jour les rservations et grer les comptes des
adhrents (par exemple ne plus prter au-del dun certain seuil). Vous vous servirez
galement de cette base de donnes pour effectuer des bilans (tels que le chiffre daffai-
res en fin de mois), des relances (les films non rendus temps) et des statistiques
(film le plus emprunt, meilleur client).
Proposez un modle entit-association pour cette activit.
On peut extraire de lnonc des phrases cls qui permettent de caractriser les entits et
leurs associations :
Un client rserve un film.
Un client loue un film.
Une personne joue dans un film.
Une personne ralise un film.
Trois entits apparaissent : client, film et personnel. Les entits client et film sont
relies par deux associations : rservation et location. Les entits film et personnel
sont relies par deux entits joue et ralise (voir figure 2.28).
Le fait dutiliser la mme entit pour un ralisateur et pour un acteur (regroups dans
personnel) provient du fait quun acteur peut en mme temps tre ralisateur. Si lon
sparait les entits, il y aurait alors une duplication de linformation concernant cette cat-
gorie acteurs/ralisateurs. Le reste de lnonc permet de dcrire les attributs des entits et
des associations.
Entit client
On a peu dinformations sur cette entit, si ce nest que le client possde un compte qui
fera partie de ses attributs. Les autres attributs ont t choisis classiquement (nom, pr-
nom, adresse, tl., etc.). Il est ncessaire dutiliser un attribut pour lidentifiant : ici, Num-
Client.
Entit film
Lentit est mieux dcrite par son titre, son genre, son prix et le nombre de DVD dans la
Exercices
pochette. Il est galement ncessaire dutiliser un attribut pour lidentifiant : ici, Num-
Film.
Entit personnel
Lentit ne comprend que les informations nom et prnom. Il est galement ncessaire de
crer un attribut pour lidentifiant : ici, NumPers.
Figure 2.28
Location
Entits clients, # NumLoc
film, personnel NbeJourLoc
lies par les Client DateLoc
associations
Film
rservation, # NumClient
location, joue et NomClient
PrnomClient
ralise (sans AdresseClient
Rservation # NumFilm
cardinalits). TlClient # NumRs
Titre
Genre
Compte NbeJourRs
Prix
DateRs
NbDVD
Joue
Personnel
Ralise
# NumPers
NomPers
PrnomPers
Les entits sont reprsentes par des classes UML. Les associations sont reprsentes par
des associations UML. Les associations location et rservation qui possdent des attri-
buts seront munies dune classe UML sans nom qui permet dutiliser ces attributs. Les car-
dinalits sont dduites des phrases suivantes :
Location :
Un client loue aucun ou plusieurs films (0..n).
Un film est lou aucune ou plusieurs fois (0..n).
Rservation :
Un client rserve aucun ou plusieurs films (0..n).
1..n Joue
Personnel
Ralise
# NumPers
NomPers 1..n
PrnomPers
Le camping lUliastru (lolivier sauvage), situ dans lextrme sud de la France, propose
ses clients diffrents types de locations : des bungalows toile pour 350 /semaine, des
caravanes pour 440 /semaine, des tentes pour 45 /jour. Les diffrentes formules offrent
un quipement complet et appartiennent au camping. Il est galement possible de louer
un emplacement tourisme la journe pour 28 /personne. Lensemble de ces loca-
tions sadresse un maximum de quatre personnes. Proposez un modle entit-associa-
tion modlisant cette activit de gestion en fonction des lments de lnonc.
Voici les phrases cls dduites de lnonc qui permettent de caractriser les entits et les
cardinalits des associations du modle entit-association :
Exercices
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).
Approche
relationnelle
1. Concepts .................................56 Lapproche relationnelle prsente par E. F. Codd
2. Oprations du modle possde un fondement mathmatique rigoureux qui
relationnel ................................60
lui assure sa robustesse : le modle relationnel est de
3. Passage du modle conceptuel
au relationnel ...........................68 loin le plus rpandu dans le monde des bases de
4. Normalisation ..........................70 donnes.
5. Logique du premier ordre Ce chapitre prsente le concept de relation
et base de donnes ...................76
fondamental du modle relationnel, ainsi que les
Exercices
1. Relation, degr, cardinalit ........82
oprations qui lui sont associes. Puis on aborde les
2. Cl dune relation .....................82 mthodes qui permettent de passer du modle
3. Contraintes dintgrit ...............83 conceptuel vu au chapitre prcdent (entit-
4. Opration ensembliste ..............83 association ou UML) un ensemble de relations. La
5. Projection ................................84
qualit des relations ainsi produites est contrle par
6. Restriction ................................85
leur conformit aux trois premires formes normales.
7. Jointure ...................................85
8. Autre jointure ...........................87 Ce processus peut conduire une rorganisation des
9. Calcul sur des agrgats .............88 relations sans perte dinformation. La manire de
10. Passage du modle rsoudre les incohrences laide de la forme
entit-association au relationnel ...89
normale de Boyce-Codd est galement prsente.
11. Passage du modle
entit-association Enfin, le lien entre les bases de donnes et la logique
au relationnel II ........................90
du premier ordre est rapidement expos, afin de
12. Normalisation ..........................91
13. Normalisation II ........................92
dcrire la mthode dinterrogation de base de
14. Normalisation III .......................93 donnes par QBE (Query By Example) qui en dcoule.
55
1 Concepts
Cette section expose la notion de relation et la terminologie qui lui est associe. On pr-
sente ensuite les diffrents types de contraintes associes au contenu dune relation, ainsi
que la notion de cl dune relation.
Le modle relationnel tire son nom de la notion de relation mathmatique entre des l-
ments. Chacun de ces lments peut prendre des valeurs dans un ensemble dfini.
On suppose que lon considre les appareils electromnagers dune cuisine. Ils peuvent
tre contenus dans lensemble des valeurs suivantes : rfrigrateur, cuisinire, hotte, robot,
lave-vaisselle. On considre par ailleurs un ensemble de couleurs qui peuvent tre conte-
nues dans lensemble des valeurs suivantes : rouge, bleu, vert, jaune, blanc, noir, rose, jaune.
Les combinaisons possibles entre les appareils et les couleurs sont au nombre de 40,
puisquil y a 5 appareils que lon peut associer 8 couleurs. Parmi toutes ces combinaisons
possibles, on effectue une slection qui reprsente par exemple la description dune (hor-
rible) cuisine dans le monde rel. Ces couples de valeurs choisis reprsentent les faits de la
vie relle.
(rfrigrateur, rouge)
(robot,mauve)
(cuisinire,jaune)
(lave-vaisselle,rouge)
Cet ensemble de couples de valeurs lies entre elles, que lon nomme tuples dans le
modle relationnel, reprsente la relation entre les lments appareil et couleur. Un
tuple est aussi dsign par les termes nuplets ou enregistrements . On dsigne ga-
lement les lments constitutifs de ces couples par les termes attributs ou champs .
On peut crire formellement la relation de la manire suivante : ma_cuisine(appareil,
couleur). Cette criture reprsente le schma relationnel de la relation ma_cuisine. Les
valeurs nonces prcdemment pour les champs reprsentent leurs domaines, cest--
dire les ensembles de toutes les valeurs possibles pour un champ.
Une relation est totalement dcrite par :
le schma relationnel ;
les domaines des diffrents champs ;
les tuples qui la constituent.
Le nombre de champs de la relation sappelle son degr de la relation. Ici, la relation
ma_cuisine est de degr 2. Le nombre de tuples se nomme la cardinalit de la relation. La
relation ma_cuisine est de cardinalit 4. Attention, il ne sagit pas de la mme cardinalit
que pour le modle entit-association vu prcdemment.
On reprsente une relation par une table, correspondant la notion de tableau. Les tuples
correspondent aux lignes et les colonnes aux champs de la relation. Voici sous forme de
table une reprsentation de lexemple prcdent (voir figure 3.1).
Dans le modle relationnel, la relation est llment fondamental. Toutes les oprations
sur une ou plusieurs relations retourneront une relation. Un ensemble de relations relies
entre elles par des liens smantiques constitue une base de donnes.
Robot Mauve
Cuisinire Jaune
Lave-vaisselle Rouge
Lorsque que lon utilise une base de donnes, il est ncessaire daccder un enregistre-
ment par le contenu dun ou de plusieurs champs. On nomme cl dune relation un
champ, ou un ensemble de champs, dune relation qui permet didentifier prcisment un
enregistrement. Une relation peut comprendre plusieurs cls possibles ; ce sont les cls
candidates. La cl choisie doit tre minimale, cest--dire quelle doit contenir le mini-
mum de champs. Cette cl minimale ainsi dfinie est appele la cl primaire de la relation.
Une cl doit toujours contenir une valeur et celle-ci doit tre unique pour chacun des
enregistrements de la relation.
La cl ne peut tre dduite simplement partir du contenu de la relation ; on ne peut pr-
juger du contenu futur des enregistrements. Si lon prend la relation ma_cuisine vue pr-
cdemment, le champ Appareil semble tre une cl puisquil contient une valeur unique
pour chacun des enregistrements. Cependant, il est tout fait possible que la cuisine con-
sidre comprenne un autre rfrigrateur de couleur bleue, auquel cas la valeur ne serait
plus unique et ne permettrait pas de retrouver lenregistrement. Dans ce cas de figure, la
combinaison Appareil Couleur pourrait sembler tre une cl, mais on ne peut en tre
certain compte tenu de lvolution des donnes.
Pour dsigner une cl primaire, il faut donc galement prendre en compte le sens des
donnes dans la vie relle. Les relations qui existent entre les diffrents champs dune rela-
tion vont tre importantes : on exprime ces relations laide de dpendances fonction-
nelles. Une dpendance fonctionnelle existe entre deux ensembles de champs si les valeurs
contenues dans lun des ensembles de champs permettent de dterminer les valeurs conte-
nues dans lautre ensemble.
Cette proprit se traduit en termes mathmatiques de la manire suivante :
Soit Cx un ensemble de champs (x1,x2,x3) et Cy un ensemble de champs (y1,y2,y3)
dune relation R(d1,d2,x1,x2,x3,u1,u2,u3,y1,y2,y3).
Supposons que lon considre des valeurs (x1_i, x2_i, x3_i) et (x1_j, x2_j, x3_j)
telles que lon ait R(d1_i,d2_i,x1_i,x2_i,x3_i,u1_i,u2_i,u3_i,y1_i,y2_i,y3_i) et
R(d1_j,d2_j,x1_j,x2_j,x3_j,u1_j,u2_j,u3_j,y1_j,y2_j,y3_j).
On dit que Cy dpend fonctionnellement de Cx lorsque pour tout i et j si (x1_i, x2_i,
x3_i) est gal (x1_j, x2_j, x3_j) alors (y1_i,y2_i,y3_i) est gal
(y1_j,y2_j,y3_j).
Les dpendances fonctionnelles expriment la relation de hirarchie qui existe entre les
champs.
On considre lexemple de table suivant (voir figure 3.2), qui correspond la relation Lec-
teur(Numero_carte, Nom, Age, Ville, Etablissement). Cet exemple modlise les lecteurs
dune bibliothque.
Approche relationnelle 57
Figure 3.2 Numero
Nom Age Ville Etablissement
Relation Lecteur. _carte
1 Henri 10 Paris Universit Sorbonne
2 Stanislas 34 Paris Universit Jussieu
3 Henriette 44 Lyon CHU Bron
4 Dominique 19 Nancy Universit Poincar
5 Isabelle 56 Nancy INPL
6 Olivier 51 Marseille Universit Saint Charles
7 Henri 98 Paris Universit Sorbonne
8 Jerome 23 Nancy INPL
9 Laurence 34 Bordeaux Universit Victor Segalen
10 Christian 41 Paris Ecole Normale Suprieure
11 Antoine 16 Marseille Universit Saint Charles
12 Laurence 34 Paris Universit Jussieu
Si lon examine les donnes, on remarque quil ne peut y avoir de dpendances fonction-
nelles entre les couples de champs (Ville, Etablissement) et les champs (Nom, Age). Il
existe un enregistrement (Laurence, 34) pour lequel les valeurs des champs (Nom, Age)
correspondent deux valeurs diffrentes de (Ville, Etablissement).
En revanche, on sait que, dans la ralit, un tablissement est situ dans une ville et une
seule (on le suppose pour cet exemple). Cela signifie quil existe une relation de dpen-
dance entre les champs Etablissement et Ville. Le contenu des champs Ville et Etablis-
sement des enregistrements de notre relation se conforment cette relation de
dpendance. A une valeur donne de Etablissement correspond bien une valeur unique
de Ville.
La valeur du champ Numero_carte est unique pour chacune des personnes. On constate
que ses valeurs sont identifiantes pour tous les autres champs de la relation. Chaque
champ dpend fonctionnellement du champ Numero_carte. Ses valeurs sont uniques et
jamais vides : cest une cl candidate. Dans cet exemple, cest la seule cl possible car les
autres champs nont jamais de valeur unique. Le champ Numero_carte est choisi comme
cl primaire de la relation.
Remarque
Tous les champs qui ne font pas partie dune cl candidate dune relation possdent des dpen-
dances 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 enregistre-
ments prsents dans la relation se conforment ces dpendances. La dtermination des
dpendances fonctionnelles entre les champs est fondamentale pour ltape de normalisa-
tion, traite la section Normalisation . Elles sont galement la base de la mthode
dite de la relation universelle , qui sera aborde dans la section Normalisation .
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.
Approche relationnelle 59
2 Oprations du modle relationnel
La manipulation des donnes dans le modle relationnel se fait laide doprations for-
melles reposant sur des concepts mathmatiques issus de la thorie des ensembles : cest
lalgbre relationnelle. Les oprations de lalgbre relationnelle portent sur une ou plu-
sieurs relations (ou tables). Le rsultat retourn par ces oprations est toujours une rela-
tion (ou table).
Cette section prsente une liste non exhaustive des diffrentes oprations de lalgbre rela-
tionnelle. Ces dernires peuvent tre regroupes en plusieurs catgories :
les oprations classiques issues de la thorie des ensembles (union, intersection,
diffrence) ;
les oprations plus spcifiques du monde relationnel (projection, slection, jointure)
qui constituent les oprations fondamentales de lalgbre relationnelle ;
les oprations de types calcul et agrgats qui ne constituent pas rellement des opra-
tions fondamentales (ni ensemblistes, ni relationnelles) mais qui sont le complment
indispensable des prcdentes.
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 Lecteur_1(Numero_carte, Nom, Age, Ville, Etablissement)
Relations
Numero_carte Nom Age Ville Etablissement
Lecteur_1et
Lecteur_2. Universit
1 Henri 10 Paris
Sorbonne
Universit
2 Stanislas 34 Paris
Jussieu
3 Henriette 44 Lyon CHU Bron
relations
Lecteur_1 et
Lecteur_2. Universit
1 Henri 10 Paris
Sorbonne
Universit
2 Stanislas 34 Paris
Jussieu
3 Henriette 44 Lyon CHU Bron
Universit
4 Dominique 19 Nancy
Poincar
5 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 dlimi-
ner des enregistrements dune relation par rapport une liste.
Figure 3.5 Lecteur_1 Lecteur_2
Diffrence des
relations Numero_carte Nom Age Ville Etablissement
Lecteur_1 et
Lecteur_2. Universit
1 Henri 10 Paris
Sorbonne
Universit
2 Stanislas 34 Paris
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 Lecteur_1 Lecteur_2
Intersection des
relations Numero_carte Nom Age Ville Etablissement
Lecteur_1 et
Lecteur_2. 3 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 .
Approche relationnelle 61
Figure 3.7 ma_cuisine(Appareil, Couleur)
Relations
ma_cuisine et Appareil Couleur
musicien.
Rfrigrateur rouge
Robot mauve
Cuisinire jaune
musicien(Nom, Instrument)
Nom Instrument
Basse
Jaco Pastorius
lectrique
Bill Evans Piano
Lexemple a t choisi de manire montrer que les relations ne ncessitent pas de rap-
ports entre elles pour faire un produit cartsien. Combiner des appareils de cuisine et des
musiciens na aucun sens dans la ralit (voir figures 3.7 et 3.8).
Figure 3.8 Le_resultat(Appareil, Couleur, Nom, Instrument) = ma_cuisine(Appareil, Couleur) X
Produit cartsien
musicien(Nom, Instrument)
des relations
ma_cuisine et Appareil Couleur Nom Instrument
musicien.
Basse
rfrigrateur rouge Jaco Pastorius
lectrique
rfrigrateur rouge Bill Evans Piano
Basse
robot mauve Jaco Pastorius
lectrique
robot mauve Bill Evans Piano
Basse
cuisinire jaune Jaco Pastorius
lectrique
cuisinire jaune Bill Evans Piano
Projection
La projection consiste extraire certains champs de la relation, ce qui donne cette der-
nire un degr infrieur la relation de dpart. Voici la relation obtenue partir de la rela-
tion Lecteur en projetant les champs Nom et Ville (voir figure 3.9).
Figure 3.9 Lecteur_proj(Nom, Ville)
Projection des
champs Nom et Nom Ville
Ville de la
relation Lecteur. Henri Paris
Stanislas Paris
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 colon-
nes sur lesquelles la projection est faite.
Slection ou restriction
La slection consiste extraire les enregistrements de la relation. On utilise des critres
pour caractriser les enregistrements slectionns. Voici la relation obtenue partir de la
relation Lecteur en slectionnant les enregistrements dont le contenu du champ Ville est
Marseille (voir figure 3.10). La structure de la relation rsultat est la mme que celle de la
relation de dpart.
Figure 3.10 Lecteur_sel(Numero_carte, Nom, Age, Ville, Etablissement)
Slection sur la
relation Lecteur. Numero_carte Nom Age Ville Etablissement
Universit Saint
6 Olivier 51 Marseille
Charles
Universit Saint
11 Antoine 16 Marseille
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 dexpri-
mer le sens du lien entre les relations dans le monde rel. La liaison entre les relations
seffectue par le contenu commun dun champ. Lopration de jointure peut tre vue
comme une slection des enregistrements obtenus par le produit cartsien des relations,
dont les contenus du champ sur lequel on effectue la jointure sont gaux. On lappelle
dans ce cas une quijointure. Les champs dont on compare les contenus sont nomms
champs de jointure.
On considre les deux relations Lecteur_bis(Numro_carte, Nom, Num_Etablissement)
et Etablissement(Num_Etablissement, Ville, Nom_Etablissement) dont le contenu suit
(voir figure 3.11).
Approche relationnelle 63
Figure 3.11 Lecteur_bis(Numero_carte, Nom, Num_Etablissement)
Relations
Lecteur_bis et Numero_carte Nom Num_Etablissement
Etablissement.
1 Henri 1
2 Stanislas 2
3 Henriette 1
Mme si lon ne dispose pas du modle conceptuel associ, on constate que lon peut relier
ces deux relations par le champ Num_Etablissement. Les informations concernant lta-
blissement de la relation Lecteur_bis sont stockes dans la relation Etablissement dont la
cl est le champ Num_etablissement. Pour obtenir la liste des lecteurs ainsi que les infor-
mations concernant leur tablissement, on effectue une jointure entre ces relations sur le
champ Num_Etablissement (voir figure 3.12).
Figure 3.12 Lecteur_joint_Etablissement(Numero_carte, Nom, Num_Etablissement_1,
Num_Etablissement_2, Ville, Nom_Etablissement)
Jointure des
relations
Lecteur_bis et Numero Num_Etablis- Num_Etablis- Nom
Etablissement Nom Ville
_carte sement_1 sement_2 _Etablissement
sur le champ
Num 1 Henri 1 1 Paris Universit Jussieu
_Etablissement.
2 Stanislas 2 2 Lyon CHU Bron
3 Henriette 1 1 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 Lecteur_jointnat_Etablissement(Numero carte, Nom, Num_Etablissement, Ville,
Nom_Etablissement)
Jointure naturelle
des relations
Lecteur_bis et Num Nom
Etablissement Numero_carte Nom Ville
_Etablissement _Etablissement
sur le champ
Num Universit
_Etablissement. 1 Henri 1 Paris
Jussieu
2 Stanislas 2 Lyon CHU Bron
Universit
3 Henriette 1 Paris
Jussieu
On verra au chapitre consacr SQL que cest lune des manires dcrire une jointure.
Jointure externe
La jointure externe nest pas rellement une opration de base de lalgbre relationnelle.
Elle est cependant ncessaire pour pouvoir rpondre plus facilement des questions du
type Quels sont les tablissements qui nont pas de lecteurs ? Il sagit dune opration
de jointure tendue qui inclut dans le rsultat les lignes nayant pas de correspondance sur
le contenu du champ de jointure. Voici le rsultat de la jointure externe de la relation Eta-
blissement avec la relation Lecteur sur le champ Num_Etablissement (voir figure 3.15).
On met en correspondance les valeurs du champ Num_Etablissement de toutes les lignes
de la relation Etablissement avec celles de la relation Lecteur.
Approche relationnelle 65
Figure 3.15 Etablissement_jointext_ Lecteur(Num_Etablissement_1, Ville, Nom_Etablissement,
Jointure externe
Numero_carte, Nom, Num_Etablissement_2)
des relations
Lecteur_bis et Num_Etablis- Nom Numero Num_Etablis-
tablissement Ville Nom
sement_1 _Etablissement _carte sement_2
sur le champ
Num Universit Jus-
_Etablissement. 1 Paris 1 Henri 1
sieu
2 Lyon CHU Bron 2 Stanislas 2
Universit Poin-
3 Nancy NULL NULL NULL
car
Universit Sor-
4 Paris NULL NULL NULL
bonne
Une rgle dans le domaine des bases de donnes est que tout ce qui peut se calculer ne doit
pas tre stock. On vite ainsi la perte de place et lincohrence qui peut en dcouler suite
au stockage dinformations redondantes. Les oprations de lalgbre relationnelle prsen-
tes dans les sections prcdentes ne permettent pas de crer de nouveau champ par calcul
partir du contenu dautres champs sans utiliser un langage de programmation. Des
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 La_boutique_total(Num_FactureArticle, Prix, Quantite, Total)
Relation
La_boutique Num_Facture Article Prix Quantite Total
avec le champ
calcul Total. 101 Bananes 12 45 540
1034 Choux 5 129 645
2345 Riz 4 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 mini-
mum. On obtient dans ce cas une nouvelle relation rduite une ligne et une colonne qui
contient la valeur calcule. En effet, le rsultat dune opration sur une relation est tou-
jours une relation (voir figure 3.19).
Figure 3.19 La_boutique_moyenne(Moyenne_Prix)
Moyenne des prix
de la relation Moyenne_Prix
La_boutique.
9
Approche relationnelle 67
Ville Nombre
Marseille 2
Nancy 3
Paris 5
Deux grandes rgles gnrales sappliquent toujours, quel que soit le cas. Les exceptions
que lon aborde ensuite permettent simplement dobtenir un schma plus compact :
Une entit devient une relation compose des champs de lentit. La cl de cette rela-
tion est la mme que celle de lentit.
Une association devient une relation compose des deux cls des entits associes.
Lensemble de ces deux cls constitue celle de la relation. Lorsquelle en possde, les
champs de lassociation forment les champs non cls de cette nouvelle relation.
Figure 3.21
Modle entit- Client
association de la NumAch
base de donnes Nom
casse. Age
Ville 1,n Vente Voiture
Sexe
DateVente # NumVoit
Prix 0,1 Marque
Type
Couleur
Figure 3.22
Seminaire
Modle entit-
association de la
base de donnes # NumSeminaire
DateSem
animation de 1,n NbeJours
sminaire. Prix
1,1
Anime
Salaire
NbeHeures
Intervenant
0,n Est responsable
# NumInter Prime
NomInter
TelInter 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, NumIn-
ter, Prime). Il sest produit une sorte de glissement des lments de lassociation
Est_responsable vers lentit Seminaire.
On peut en dduire une rgle complmentaire des rgles gnrales prcdentes :
Lorsque lassociation entre deux entits comprend une cardinalit de type 1-1, on ne
cre pas de relation pour lassociation. Les champs de lassociation seront intgrs la
Approche relationnelle 69
relation cre pour lentit qui est associe avec la cardinalit 1-1. La cl de cette rela-
tion 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.
4 Normalisation
Le modle relationnel procure des outils destins tester la qualit et la cohrence des
relations dans un schma relationnel cr ltape prcdente. Cette tape, appele
normalisation, permettra de vrifier certaines proprits des relations et le cas chant
de les transformer.
On aborde dans cette section les trois premires formes normales qui suffisent dans la plu-
part des cas et qui permettent une dcomposition du schma relationnel sans perte
dinformation. La forme normale de Boyce-Codd qui dtecte dautres incohrences, mais
propose une dcomposition avec perte dinformations de dpendance, est prsente la
fin de la section. Il existe dautres formes normales la quatrime et la cinquime , qui ne
sont pas prsentes dans cet ouvrage : ces dernires sont parfois difficiles apprhender et
les trois premires formes normales suffisent en gnral pour obtenir un schma relation-
nel de qualit.
La normalisation dun schma relationnel suggre une autre mthode pour obtenir un
ensemble de relations. On part dune relation unique qui contient tous les champs, que
lon appelle la relation universelle. laide des dcompositions proposes par la mise en
forme normale et du graphe des dpendances fonctionnelles des champs de cette relation,
on parvient par raffinements successifs un ensemble de relations normalises. Cette
mthode de la relation universelle est toutefois assez difficile manipuler ds que lon
dpasse une taille critique du nombre de champs.
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.
un champ
multivalu. Jean Lasso, Hubert De
Le vin et
13490 la Tuque, Stanislas
lavenir
Wilski
Bire et Aristide Salem, Jean
21322
progrs social Lasso, Salome Dupont
Penelope Light,
Le champagne
45333 Vanessa Martinez,
et la France
Salome Dupont
Approche relationnelle 71
EstEcrite(NumPubli, NumAuteur)
NumPubli NumAuteur
13490 1
13490 2
13490 3
21322 4
21322 1
21322 5
45333 6
45333 7
45333 5
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.
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.
La cl est constitue des champs Article et Fournisseur. Or, il y a une relation de dpen-
dance entre le champ Fournisseur, qui est une partie de la cl, et le champ Adresse.
On dcompose alors la relation pour liminer la redondance ainsi cre. La nouvelle relation
Fournisseur(Fournisseur, Adresse)
Fournisseur Adresse
SOGENO Paris
ARTIFACT Lille
LEMEL Paris
Comme prcdemment, il est ncessaire de faire une jointure pour reconstituer linforma-
tion. 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 naturelle-
ment en deuxime forme normale.
Approche relationnelle 73
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 plu-
sieurs baladeurs de mme marque, de mme type et de mme couleur. Les marques dpo-
sent les noms des objets quelles fabriquent de faon les identifier sur le march. Il existe
donc une dpendance fonctionnelle entre le champ Type (qui nappartient pas la cl) et
le champ Marque (qui nappartient pas la cl). On dcompose la relation en en crant
une nouvelle qui a pour cl le champ dont dpendent les autres champs constituant la
dpendance transitive. Il sagit dans ce cas du champ Type. Les autres champs de la nou-
velle relation sont composs des champs qui en dpendent fonctionnellement : ici, le
champ Marque (voir figure 3.28).
Figure 3.28 Baladeur(NumBal, Type, Couleur)
Dcomposition de
la relation NumBal Type Couleur
Baladeur pour
passer en 12 Ipod Blanc
troisime forme 43 Zen Noir
normale.
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 linfor-
mation 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.
La cl de cette relation est constitue par les champs Marque et Produit. En effet, un pro-
duit est fabriqu sous licence par la socit ImaginR et a donc le mme nom que celui pro-
pos par la socit Olympus. Il est alors ncessaire dutiliser les deux champs pour constituer
la cl. Pour se dmarquer les unes des autres, les socits utilisent des couleurs personnalises
destines identifier la marque : Philips, le blanc et lorange ; Olympus, le rouge et le noir ;
ImaginR, le gris. On a donc une relation de dpendance entre ces deux champs. La relation
est en troisime forme normale, mais elle nest pas en forme de Boyce-Codd.
Plusieurs dcompositions sont possibles : par exemple Dictaphone(Marque, Type, Prix) et
Marque_coul(Couleur, Marque). Mais cette dcomposition gnre des tuples non dsirs
au moment de la jointure. Quant la dcomposition Dictaphone(Type, Prix, Couleur) et
Marque_coul(Couleur, Marque), elle permet de reconstituer linformation de dpart par
une jointure sur le champ Couleur (voir figure 3.30).
Figure 3.30 Dictaphone(Produit, Prix, Couleur)
Relation
Dictaphone Produit Prix Couleur
dcompose pour
passer en forme LD 1024 49 Blanc
de Boyce-Codd. VN 1664 49 Noir
LD 5647 H 59 Blanc
Approche relationnelle 75
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
Le formalisme de la logique du premier ordre permet dexprimer des phrases dans un lan-
gage non ambigu. Il offre la possibilit, par des rgles de drivation, ou rcritures, de
dduire dautres phrases. Llment fondamental de la logique du premier ordre est le pr-
dicat qui exprime le lien entre diffrents lments. La validit de ce prdicat est gnrale-
ment restreinte un ensemble de valeurs que lon nomme domaine du discours.
mange(x,y) sera par exemple vrai pour les valeurs du couple (x,y) suivantes
(homme,navet)
(lapin,carotte)
(homme,lapin).
On utilise classiquement des variables (x,y dans notre exemple) et des constantes dans les
expressions. Les prdicats peuvent tre associs par des connecteurs logiques : (et),
(ou), (non), (implique). Le domaine de discours des variables sexprime partir des
quantificateurs (quel que soit) et (il existe). Ce formalisme simple permet dexprimer
des proprits comme celle-ci : si x est mang par y ou y est mang par x, ils appartien-
nent tous deux la mme chane alimentaire .
Cette formule peut se rcrire en utilisant des rgles de dduction dans le but daboutir
3
Chapitre
un ensemble de clauses plus aises vrifier : cest sur ce principe que fonctionne la
dmonstration automatique de thormes. La diffrence entre un (bon) mathmaticien et
un programme est videmment que le mathmaticien va choisir demble la srie de rgles
adapte pour parvenir plus rapidement au rsultat.
Voici une possibilit de rcriture de la formule prcdente.
a b donne a b
x y ((mange(x,y) mange(y,x)) (meme_chaine_alimentaire(x,y)))
(a b) donne a b
x y (mange(x,y) ? mange(y,x)) (meme_chaine_alimentaire(x,y)))
(a b) c donne (a c) (b c)
x y ((mange(x,y) meme_chaine_alimentaire(x,y)) ((mange(y,x)
meme_chaine_alimentaire(x,y)))
a b donne a b
x y ((mange(x,y) meme_chaine_alimentaire(x,y)) (mange(y,x)
meme_chaine_alimentaire(x,y))
x y signifie que y est dfini en fonction de x, on remplace y par F(x)
On obtient ainsi deux clauses relies par , on lappelle clause de Horn qui reprsente la
fin de la rcriture :
mange(x,F(x)) meme_chaine_alimentaire(x,F(x)))
mange(F(x),x) meme_chaine_alimentaire(x, F(x))
Dans notre cas, on peut sassurer assez facilement que ces deux implications sont toujours
vrifies pour le domaine du discours.
Le lien avec ce qui a t nonc prcdemment sur le modle de bases de donnes relation-
nelles est le suivant :
Le prdicat correspond la relation.
Le domaine du discours correspond au contenu de la relation.
Ce formalisme permet dexprimer les questions, naturellement ambigus du langage
parl, par une formule. Cette formule est rcrite en utilisant les rgles vues prcdem-
ment pour arriver un ensemble de clauses simples. On constitue ensuite des sous-ensem-
bles de tuples de la relation pour lesquels les clauses rcrites sont vrifies : ces tuples
reprsentent la rponse la question pose. Voici quelques exemples de questions expri-
mes en utilisant ce formalisme. On obtient ainsi des sortes de patrons de recherche
permettant de caractriser les tuples qui sont solutions.
Dans lexemple gnral (voir section 3.1), le schma de la relation voiture est voi-
ture(NumVoit, Marque, Type, Couleur) et le schma de la relation vente est vente(Date-
Vent, Prix, NumAch, NumVoit).
Lexpression afficher la liste des marques et des types de voitures , ou projection des
champs Marques et Types de la relation voiture, peut scrire sous la forme :
{ (m,t) | voiture(_,m,t,_) }
Cela signifie que les valeurs des champs Marque et Type des tuples de la relation voi-
ture sont reprsentes par les variables m et t. Le signe _ reprsente nimporte quelle
valeur des autres champs NumVoit et de Couleur.
Approche relationnelle 77
Lexpression afficher le type des voitures de couleur rouge , qui est une projection et
une slection sur la relation voiture, peut scrire sous la forme :
{ (t) | voiture(_,_,t,rouge) }
Cette fois, on utilise une constante, rouge, dans lexpression pour fixer la valeur dun
champ et la variable, t, pour les valeurs du champ recherches.
On peut exprimer lappartenance dun champ un ensemble par un critre. Lexpression
afficher les prix de vente suprieurs 10 000 , qui est une projection et une slection sur
la relation vente, peut scrire sous la forme :
{ (p) | vente(_,p,_,_) p > 10000 }
Enfin, la jointure entre deux relations est galement possible. Lexpression afficher le
type des voitures vendues et leur prix , qui met en jeu deux relations, peut scrire sous la
forme :
{ (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
Il suffit dutiliser la mme variable dans les deux relations : ici nv, pour le champ
NumVoit qui sert effectuer le lien. Le quantificateur permettra de ne slectionner
que les tuples dans les deux relations pour lesquels les valeurs de NumVoit sont identi-
ques, ce qui est exactement la dfinition dune jointure (quijointure).
Le formalisme de la logique du premier ordre permet dexprimer toutes les oprations
relationnelles vues prcdemment : cest normal puisquil sagit de la base de lapproche
relationnelle. On peut alors considrer un SGBD comme un outil de dmonstration de
thormes, tels que lon peut en rencontrer en intelligence artificielle, qui agirait sur un
ensemble trs restreint de rgles.
Les critres de slection se font par des valeurs exemples (voir figures 3.32 et 3.33).
projection dans un
QBE.
NumVoit Marque Type Couleur Rouge
> 10 000
Les conditions situes sur la mme ligne sont relies par un et (voir figure 3.34).
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 :
tre obligatoire et
projection dans { (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
un QBE.
DateVent Prix NumAch NumVoit
Les conditions situes sur deux lignes diffrentes sont relies par un ou (voir
figure 3.35).
Figure 3.35 Afficher les prix de vente suprieurs 10 000 ou dont la date de vente a eu lieu aprs le
Slection 1er janvier 1997 :
multicritre { (p) | vente(d,p,_,_) (p > 10000 d > 01/01/1997)}
optionnel et
projection dans un
QBE. DateVent Prix NumAch NumVoit
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).
Figure 3.36 Afficher le type des voitures vendues et leur prix :
Jointure et { (t,p) | nv voiture(nv,_,t,_) vente(_,p,_ ,nv)}
projection dans un
QBE.
NumVoit Marque Type Couleur
Nv
Nv
Cette mthode dinterrogation simple et efficace est encore propose par de nombreux SGBD.
Approche relationnelle 79
Rsum
Lapproche relationnelle modlise les faits de la vie relle par des tuples, qui sont des
ensembles de valeurs de diffrents champs (ou attributs) : (rfrigrateur, 2003, rouge) est
un tuple qui reprsente des valeurs des champs Objet, Anne, Couleur lies dans le
monde rel. Lensemble des tuples sappelle une relation. Il sagit du concept de base qui
sera manipul par lapproche relationnelle et peut tre reprsent sous la forme dune
table.
Pour identifier un tuple, on utilise le contenu dun ou de plusieurs champs que lon nom-
mera la cl dune relation. Cette dernire est tablie en utilisant le concept de dpendance
fonctionnelle entre les diffrents champs. La cl est constitue par le plus petit ensemble
de champs dont dpendent fonctionnellement les autres champs. Si plusieurs cls sont
possibles, on parle de cls candidates. La cl choisie sera nomme la cl primaire.
Les oprations de manipulation de ces relations peuvent tre regroupes en trois
catgories :
Les oprations du monde ensembliste. Produit cartsien, intersection, union et diff-
rence.
Les oprations spcifiques relationnelles. Projection, slection (ou restriction) et
jointure. On a prsent galement la jointure externe qui permet de rpondre des
questions spcifiques mme sil ne sagit pas dune opration de base du relationnel.
Les oprations et les fonctions de calcul. Elles ne constituent pas rellement des op-
rations du monde relationnel mais sont utiles pour effectuer des calculs sans recourir
un langage de programmation.
La cohrence des donnes contenues dans les relations est amliore par la dfinition de
contraintes que lon appliquera sur les relations au moment de leur cration. Ces con-
traintes expriment essentiellement les conditions dappartenance un ensemble que lon
nomme le domaine du champ. On peut dcrire cet ensemble de plusieurs manires :
Une liste exhaustive de valeurs, comme celles des jours de la semaine : lundi ,
mardi , etc.
Le respect de proprits, comme : lge doit tre compris entre 7 et 77 ans .
Lutilisation des valeurs dun champ comprises dans une autre relation de rfrence.
On parle de cl trangre.
La mise en uvre de ces contraintes est assure par le SGBD en utilisant le Langage de
Dfinition de Donnes (LDD). Aprs avoir prsent les concepts de relation (ou de table) et
les outils qui permettent de les manipuler, on a dcrit les rgles qui conduisent du modle
conceptuel prsent au chapitre prcdent un ensemble de relations constituant le
modle logique de la base de donnes. Les liaisons entre les relations, qui expriment les
liens de sens dans la ralit, seront tablies dynamiquement par lopration fondamentale
de lapproche relationnelle qui est la jointure.
On value ensuite la qualit de ces relations en vrifiant leur conformit par rapport des
proprits que lon appelle les formes normales. Ces proprits visent essentiellement
dtecter la redondance et la cohrence des donnes dans les relations. On a prsent dans
ce chapitre les quatre formes normales les plus courantes :
la premire forme normale qui interdit les champs multivalus ;
la deuxime forme normale qui dtecte une relation de dpendance entre une partie de
la cl et un champ ;
Approche relationnelle 81
Exercices
EXERCICE 1 RELATION, DEGR, CARDINALIT
Comme le produit cartsien est une combinaison de tous les tuples des deux relations, le
nombre de tuples sera le produit du nombre de tuples des deux relations. Tous les champs
sont intgrs dans le rsultat en une sorte de juxtaposition : le nombre de champs du pro-
duit cartsien est gal la somme du nombre de champs des deux relations. Enfin, le pro-
duit cartsien est une opration symtrique ; le rsultat sera le mme pour les deux
questions.
La relation Garage possde 3 tuples de 7 champs et la relation Film possde 15 tuples de 2
champs. Le rsultat est une relation qui possde 45 tuples et 9 champs. On peut galement
dire que le rsultat est une table qui possde 45 lignes et 9 colonnes.
tous les champs, il semble quil ny a pas dans cette relation de bons candidats pour identi-
fier un tuple. Une solution est dajouter un champ spcifique ; cest ce que proposent la plu-
part des SGBD lorsque vous ne dfinissez pas de cl pour une relation.
Pour les champs de type numrique comme Prix et Nombre, on peut proposer des limi-
tes dappartenance un intervalle. Le prix doit tre compris entre 0 et 1 000, et le nombre
entre 0 et 10 000.
Pour les champs de type caractre comme Format et Couleur, il semble que les valeurs
puissent tre incluses dans des ensembles numrs. Le format peut tre compris dans
lensemble (3 :4,16 :9) et la couleur dans lensemble (Couleur,Noir/Blanc) .
Le contenu du champ Numro_Film peut tre dfini par rapport au contenu du champ
correspondant dans la relation catalogue. Cela revient imposer la contrainte suivante :
on nentre pas de numro de films qui ne se trouveraient pas dans le catalogue. Dans tous
les cas, ces valeurs sont dterminer avec les usagers de la base de donnes.
Exprimez lintersection entre deux relations partir des oprations dunion et de diff-
rence. Donnez-en une illustration avec ses deux relations (voir figure 3.38).
Figure 3.38 ma_cuisine(Appareil, Couleur)
Relations Appareil Couleur
ma_cuisine et
sa_cuisine. Rfrigrateur rouge
Robot mauve
Cuisinire jaune
sa_cuisine(Appareil, Couleur)
Appareil Couleur
Rfrigrateur mauve
Exercices
Cuisinire jaune
Hotte bleue
Pour raliser ces oprations, il faut que les relations possdent le mme schma. Linter-
section entre deux ensembles peut se concevoir de la manire suivante en utilisant lop-
Approche relationnelle 83
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 Appareil Couleur
ma_cuisine et
sa_cuisine. Rfrigrateur rouge
Robot mauve
Appareil Couleur
Cuisinire jaune
EXERCICE 5 PROJECTION
Trouver le prix et le type de tous les films de la relation Film vue prcdemment. Peut-
on en dduire que Prix & Type est une cl candidate, cest--dire que toute combinai-
son des valeurs du prix et du type dun film permet didentifier un film ?
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
4 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 candi-
date, car il y a un doublon : le tuple (12, Noir/Blanc).
Donnez le prix des films de la base films en Noir/Blanc . Quels sont le degr et la car-
dinalit de la relation obtenue ? Est-il possible de calculer ces valeurs lavance, comme
on le fait pour un produit cartsien ?
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
Prix Format Type Nombre
Restriction et
projection de la 12 4 :3 Couleur 3
relation Film. 4 16 :9 Noir/Blanc 1
12 16 :9 Couleur 1664
35 4 :3 Noir/Blanc 890
12 16 :9 Noir/Blanc 1
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).
Figure 3.43 Film(Prix, Format, Type, Nombre, Numero_Film)
Relation Film.
Prix Format Type Nombre Numero_Film
12 4/3 Couleur 3 2
4 16/9 Noir/Blanc 1 4
12 16/9 Couleur 1 664 50
Exercices
Approche relationnelle 85
Catalogue(Numero_Film, Titre)
Figure 3.44 Numero_Film Titre
Relation
Catalogue.
2 Le train qui passe
4 A toi !
56 Les chats du Sngal
111 Le temps expliqu
12 Les impts faciles
Trouvez la liste des titres de films et leur format. Voyez-vous une incohrence dans le
rsultat ? Pouvez-vous lors de cette opration dtecter si la contrainte dintgrit rfren-
tielle suggre lexercice prcdent a t respecte ? Est-il possible de faire une jointure
entre ces deux relations sur le champ Prix de la relation Film avec le champ
Numero_film de la relation Catalogue ? Si oui, que signifie le rsultat ?
On fait une jointure entre les deux relations sur les champs Numero_Film (voir figure 3.45).
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.
On fait une jointure externe cette fois entre les relations sur les champs Numero_Film.
Attention, lopration nest pas symtrique, la jointure se fait partir de la relation Film
sur la relation Catalogue (voir figure 3.48)
Il suffit alors de faire une slection sur le contenu dun champ provenant de la relation
Catalogue dont le contenu est NULL, par exemple le champ Titre. On projette ensuite
sur le champ Numero_Film provenant de la relation Film. On obtient une relation une
ligne et une colonne (ou une relation de degr 1 et de cardinalit 1) [voir figure 3.49].
Approche relationnelle 87
Figure 3.49
Numero
Slection et _Film
projection de la
jointure externe 50
des relations
Film et Pour dtecter les films du catalogue non utiliss, on va cette fois faire une jointure externe
Catalogue.
symtrique de la prcdente partir de la relation Catalogue sur la relation Film (voir
figure 3.49).
Figure 3.50
Numero Numero
Jointure externe _Film Titre Prix Format Type Nombre _Film
des relations (Catalogue) (Film)
Catalogue et
Film. Le train qui
2 12 4 :3 Couleur 3 2
passe
Noir/
4 A toi ! 4 16 :9 1 4
Blanc
Les chats du
56 NULL NUL NUL NUL NUL
Sngal
Le temps
111 NUL NUL NUL NUL NUL
expliqu
Les impts Noir/
12 12 4 :3 890 12
faciles Blanc
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 Les chats du
jointure externe Sngal
des relations Le temps
Catalogue et
Film. expliqu
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
0,n Film
# NumClient
NomClient 0,n
PrenomClient 0,n
Reservation # NumFilm
AdresseClient
Titre
TeleClient NbeJourRes
1,n Genre
Compte DateRes
Prix
NbDVD
1,1
Joue
Personnel
0,n
Realise
# NumPers
NomPers
PrenomPers 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
Exercices
Approche relationnelle 89
On remarque que lassociation Realise a une cardinalit de type 1-1 lors de son associa-
tion avec Films. Cela signifie dans le monde rel quun film a un et un seul ralisateur.
On est dans le cas o lassociation Realise est absorbe par la relation cre partir de
lentit associe, ici Film. On obtient la relation suivante :
Films(NumFilm, Titre, Genre, Prix, NombreDVD, NumPers) et la relation Realise
disparat.
On peut noter que les cls des relations cres partir des associations Locations et
Reservations supposent quun client ne rserve et ne loue pas le mme film deux fois.
Dans le cas contraire, on serait oblig dajouter un champ identifiant pour ces deux rela-
tions. L encore, on ne peut dcider cela qu lisssue de discussions avec les utilisateurs de
la base de donnes.
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.
La relation nest pas en premire forme normale en raison des valeurs qui correspondent
bien des valeurs multiples contenues dans le champ Adresse_Mail. En revanche, il nest
pas sr que la valeur Employ, asserment de le champ Poste soit une valeur multiple.
Une virgule dans un champ ninduit pas ncessairement quil contient des valeurs
multiples : cest peut-tre un contenu normalis (un peu trange certes).
On remarque que cette relation na pas non plus de cl candidate srieuse, si lon tient
compte des dpendances fonctionnelles entre les champs. Or, seule la prsence dune cl
permettra de faire la dcomposition ncessaire la normalisation. On ajoute un champ
Ident_Personne qui en sera la cl et lon dcompose en trois relations comme on la vu
prcdemment.
Une autre solution moins lourde est dajouter un champ supplmentaire pour ladresse
mail en supposant que lon nen stockera toujours que deux. On effectue alors la rparti-
tion des valeurs entre les champs. Il faut tout de mme ajouter le champ Ident_Personne
pour que la relation possde une cl (voir figure 3.56).
Personne(Ident_Personne, Nom, Poste, Adresse_mail1, Adresse_mail2)
Figure 3.56
Ident
Nom Poste Adresse_mail1 Adresse_mail2
Relation _Personne
Personne
modifie. Andr
1 Directeur adup@philips.com andre@dupond.fr
Dupont
Stanislas De Employ, sdlm@ver- sdlm@ver-
2
la Motte asserment sailles.mairie.fr sailles.mairie.fr
Elisabeth
3 Assistante elsa@yago.to mac@rien.fr
Macroix
Exercices
Approche relationnelle 91
EXERCICE 13 NORMALISATION II
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 ?
FormatSup(Format, Support)
Format Support
4 :3 VHS
16 :9 DVD
Inconnu VHS
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
Relation Lecteur .
Universit
1 Henri 10 Paris
Sorbonne
2 Stanislas 34 Paris Universit Jussieu
3 Henriette 44 Lyon CHU Bron
Universit
4 Dominique 19 Nancy
Poincar
5 Isabelle 56 Nancy INPL
Universit
6 Olivier 51 Marseille
Saint Charles
Universit
7 Henri 98 Paris
Sorbonne
8 Jerome 23 Nancy INPL
Universit
9 Laurence 34 Bordeaux
Victor Segalen
Ecole Normale
10 Christian 41 Paris
Suprieure
Universit
11 Antoine 16 Marseille
Saint Charles
12 Laurence 34 Paris Universit Jussieu
Approche relationnelle 93
Figure 3.60 Lecteur(Numero_carte, Nom, Age, Etablissement)
Relation Lecteur
dcompose I. Numero carte Nom Age Etablissement
1 Henri 10 Universit Sorbonne
2 Stanislas 34 Universit Jussieu
3 Henriette 44 CHU Bron
4 Dominique 19 Universit Poincar
5 Isabelle 56 INPL
6 Olivier 51 Universit Saint Charles
7 Henri 98 Universit Sorbonne
8 Jerome 23 INPL
Universit Victor
9 Laurence 34
Segalen
Ecole Normale
10 Christian 41
Suprieure
11 Antoine 16 Universit Saint Charles
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
Universit Saint Charles Marseille
Universit Victor
Bordeaux
Segalen
cole Normale
Paris
Suprieure
Les deux relations sont en troisime forme normale. On effectue une jointure pour
reconstituer linformation de dpart.
SQL
1. Concepts du langage SQL ........96 Le langage SQL est lun des lments qui ont
2. Oprations relationnelles contribu au dveloppement et au succs de
avec SQL .................................97
lapproche relationnelle dans le monde des bases de
3. Gestion de tables et de vues ....110
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
associs, indpendamment du SGBD et du langage
calcule .................................120
3. Projection/restriction avec utiliss.
un oprateur statistique ...........120
Ce chapitre aborde les concepts et la syntaxe du
4. Agrgat .................................121
langage SQL, et prsente les trois grandes familles
5. Question ngative ..................121
6. Produit cartsien .....................121 doprations que le langage permet dexprimer :
7. Jointure simple .......................122 Linterrogation et la recherche dans les tables.
8. Requte SQL trange ..............122
La gestion de tables et de vues munies des
9. Autre question ngative
jointure externe ....................122
contraintes associes. Ces instructions concernent
10. Slection sur un agrgat
la table et sa structure et constituent la partie LDD
dune jointure .........................123 (Langage de Description des Donnes) de SQL.
11. Slection par rapport au rsultat La manipulation de donnes. Ces instructions
dun calcul statistique ..............124
concernent les donnes contenues dans la table et
12. Cration dune table ...............124
constituent la partie LMD (Langage de
13. Insertion de donnes dans
Manipulation des Donnes) de SQL.
une table ...............................125
14. Modification des donnes
dune table ............................125
15. Requte combine ..................125
95
1 Concepts du langage SQL
Le langage SQL est essentiellement un sous-produit issu des travaux du groupe de tra-
vail System-R. Il sagissait de la ralisation pratique des concepts de lapproche relation-
nelle chez IBM. Cest une volution du langage SEQUEL, lui-mme driv du langage de
recherche SQUARE.
Le langage est normalis par lISO depuis 1987. La deuxime version du langage, SQL2, a
t adopte en 1992. Les exemples de cet ouvrage sont bass, dans la mesure du possible,
sur cette norme. La troisime version du langage, SQL3, normalise en 1999, ajoute essen-
tiellement les fonctionnalits lies lutilisation de lapproche objet.
La quasi-totalit des SGBD disposent dune interface SQL mme si aucun ne couvre
lensemble de la norme. La norme SQL prvoit trois niveaux de conformit : le niveau
dentre, le niveau intermdiaire et le niveau complet. Les SGBD respectent en gnral le
premier niveau et adoptent certains lments des autres niveaux. La normalisation du lan-
gage garantit la portabilit gnrale des applications dun SGBD un autre, mme sil sub-
siste des diffrences entre les approches des diffrents diteurs. En effet, compte tenu du
temps ncessaire au processus de modification de la norme, certains diteurs la devancent
parfois et intgrent des fonctionnalits qui leur semblent essentielles ou susceptibles de
leur donner un avantage concurrentiel.
Le langage SQL manipule lobjet fondamental de lapproche relationnelle : la relation
reprsente par une table vue au chapitre 3. SQL est un langage dit non procdural ou
dclaratif , cest--dire que lon ne dcrit pas la manire deffectuer les oprations pas
pas : cest le SGBD qui choisit la mthode utilise pour y parvenir. Cest ce qui explique
que des concours de rapidit de rsolution de requte soient organiss chaque anne pour
tester les diffrentes stratgies des diteurs. Par consquent, il ne dispose pas dinstruc-
tions de structuration, telles que des boucles. Pour effectuer ce type doprations, on uti-
lise un langage de programmation classique , comme les langages C, php, Java et bien
dautres. Les instructions SQL sont alors intgres dans le langage via une interface spci-
fique. Les rsultats de la requte SQL sont alors stocks dans des structures de donnes
propres au langage employ (par exemple un tableau) afin de pouvoir les manipuler. Cest
typiquement ce procd qui est employ pour construire une interface daccs une base
de donnes par le Web.
Le langage de programmation qui intgre le langage SQL est alors appel langage hte
(voir figure 4.1). De petites diffrences de syntaxe peuvent apparatre entre une requte
SQL exprime interactivement et la version intgre dans un langage de programma-
tion. Enfin, il existe une extension procdurale de SQL qui ajoute les fonctions, proc-
dures et mthodes SQL mais qui ne sera pas traite dans le cadre de cet ouvrage.
Remarque
Un ensemble dinstructions SQL se nomme une requte. Une requte SQL se termine toujours par
le caractre ; .
Bibliothque
fonctions SQL
SGBD
Linterrogation dune ou de plusieurs tables est aborde dans la section Oprations rela-
tionnelles avec SQL . Toutes les requtes de ce type retournent comme rsultat une table
qui peut tre sauvegarde sous forme de table temporaire. Cette table intermdiaire est
utilise pour effectuer dautres requtes.
La cration, la modification et la destruction dune table sont abordes dans la section
Gestion de tables et de vues . Lexpression des contrles de cohrence (contraintes
dintgrit) que lon souhaite appliquer une table est traite logiquement dans cette sec-
tion. La manipulation (insertion, modification et suppression) des donnes dune table est
aborde dans la section Gestion des donnes . La partie de SQL qui est consacre la
gestion des autorisations sera aborde plus loin au chapitre 6.
Cet ouvrage ne traite pas de lintgralit de la norme SQL ; ce nest pas son objectif. Pour
en savoir plus, vous pouvez vous reporter louvrage dit dans la mme collection (F.
Brouard et C. Soutou, Syntex SQL).
Remarque
Par convention, dans tous les exemples qui suivent, les instructions SQL sont indiques en majus-
cules afin de les diffrencier des noms de tables et de champs. Les interprteurs SQL ne diffren-
cient pas les majuscules des minuscules en ce qui concerne les instructions. En revanche, cela
dpend du systme dexploitation utilis ; le nom des champs ou des tables doit en gnral tre
crit de manire exacte.
SQL 97
Figure 4.2 Voiture
Base de donnes NumVoit Marque Type Type
casse.
1 Peugeot 404 Rouge
2 Citroen SM Noire
3 Opel GT Blanche
Personne
1 Nestor 96 Paris M
2 Irma 20 Lille F
3 Henri 45 Paris M
4 Josette 34 Lyon F
5 Jacques 50 Bordeaux M
Vente
DateVente Prix NumVoit NumAch
1985-12-03 10 000 1 1
1996-03-30 70 000 2 4
1998-06-14 30 000 4 1
2000-04-02 45 000 5 2
Lopration de projection consiste slectionner la (les) colonne(s) que lon veut voir figu-
rer dans la table rsultat . On spcifie la liste des colonnes inclure dans cette table der-
rire linstruction SELECT en les sparant par des virgules. Si lon dsire afficher toutes les
colonnes, on les dsigne par le caractre * .
Projection sur les SELECT Nom, Ville
colonnes Nom et FROM personne ;
Ville de la table
Personne.
Nom Ville
Nestor Paris
Irma Lille
Henri Paris
Josette Lyon
Jacques 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
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
+ Addition
Oprateurs
dexpressions de - Soustraction
SQL. * Multiplication
/ Division
% Modulo
SQL dispose de nombreuses autres fonctions intgres, parfois dpendantes du SGBD uti-
lis, qui permettent par exemple le traitement des colonnes de types caractres, date
Transformation SELECT UPPER(Nom) AS NomMajuscule
dune colonne FROM personne ;
Nom de la table
Personne en
majuscules.
NomMajuscule
NESTOR
IRMA
HENRI
JOSETTE
JACQUES
Remarque
Les fonctions statistiques sappliquent lensemble des donnes dune colonne (sauf pour la fonc-
tion COUNT qui sapplique aux lignes de la table entire). Pour toutes ces oprations, la table
rsultat contiendra une seule ligne et souvent une seule colonne.
Dans le cas de la fonction COUNT, on ne spcifie pas la colonne sur laquelle sapplique la
fonction puisquil sagit de la table entire.
SQL 101
> Suprieur
<= Infrieur ou gal
>= Suprieur ou gal
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 SELECT Marque
diffrentes FROM voiture
marques de GROUP BY Marque ;
voitures de la table
voiture.
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 ins-
truction les fonctions statistiques dj abordes aux diffrents sous-ensembles dune table
ainsi constitus.
Calcul du nombre SELECT Marque, COUNT(*) AS Compte
de voitures des FROM voiture
diffrentes GROUP BY Marque ;
marques de la
table voiture.
Marque Compte
Citroen 1
Opel 1
Peugeot 2
Renault 2
SQL 103
Ville Moyenne_Age
Lille 20.0000
Lyon 34.0000
Paris 70.5000
Remarque
Le mot cl HAVING permet deffectuer une slection sur le rsultat de lopration de groupage. Le
mot cl WHERE opre une slection sur les lments (lignes) de la table avant lopration de grou-
page..
Supposons que lon veuille liminer les voitures rouges de notre calcul.
Calcul du nombre SELECT Marque, COUNT(*) AS Compte
de voitures par FROM voiture
marque de la table WHERE NOT (Couleur=Rouge)
voiture dont la GROUP BY Marque;
couleur est
Rouge .
Marque Compte
Citroen 1
Opel 1
Peugeot 1
Renault 2
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
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 SELECT Vo.Marque, Vo.Couleur
simplifie des FROM voiture AS Vo;
attributs par leur
table
dappartenance. 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 op-
ration qui na gure dintrt en pratique. En SQL, cette opration scrit simplement.
Produit cartsien. SELECT *
FROM personne, voiture ;
Num
NumAch Nom Age Ville Sexe Marque Type Couleur
Voit
1 Nestor 96 Paris M 1 Peugeot 404 Rouge
2 Irma 20 Lille F 1 Peugeot 404 Rouge
3 Henri 45 Paris M 1 Peugeot 404 Rouge
4 Josette 34 Lyon F 1 Peugeot 404 Rouge
5 Jacques 50 Bordeaux M 1 Peugeot 404 Rouge
1 Nestor 96 Paris M 2 Citroen SM Noire
SQL 105
Num
NumAch Nom Age Ville Sexe Marque Type Couleur
Voit
2 Irma 20 Lille F 2 Citroen SM Noire
3 Henri 45 Paris M 2 Citroen SM Noire
4 Josette 34 Lyon F 2 Citroen SM Noire
5 Jacques 50 Bordeaux M 2 Citroen SM Noire
1 Nestor 96 Paris M 3 Opel GT Blanche
2 Irma 20 Lille F 3 Opel GT Blanche
3 Henri 45 Paris M 3 Opel GT Blanche
4 Josette 34 Lyon F 3 Opel GT Blanche
5 Jacques 50 Bordeaux M 3 Opel GT Blanche
1 Nestor 96 Paris M 4 Peugeot 403 Blanche
2 Irma 20 Lille F 4 Peugeot 403 Blanche
3 Henri 45 Paris M 4 Peugeot 403 Blanche
4 Josette 34 Lyon F 4 Peugeot 403 Blanche
5 Jacques 50 Bordeaux M 4 Peugeot 403 Blanche
AlpineA
1 Nestor 96 Paris M 5 Renault Rose
310
AlpineA
2 Irma 20 Lille F 5 Renault Rose
310
AlpineA
3 Henri 45 Paris M 5 Renault Rose
310
AlpineA
4 Josette 34 Lyon F 5 Renault Rose
310
AlpineA
5 Jacques 50 Bordeaux M 5 Renault Rose
310
1 Nestor 96 Paris M 6 Renault Floride Bleue
2 Irma 20 Lille F 6 Renault Floride Bleue
3 Henri 45 Paris M 6 Renault Floride Bleue
4 Josette 34 Lyon F 6 Renault Floride Bleue
5 Jacques 50 Bordeaux M 6 Renault Floride Bleue
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.
sur le critre
dgalit de la
colonne 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 sp-
cifique JOIN. Il faut bien sr spcifier la colonne sur laquelle seffectue la jointure.
SELECT voiture.Marque, voiture.Couleur, vente.Prix
FROM vente JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
Le traitement de la requte est dans ce cas optimis par le SGBD. Cest important, car
lopration de jointure est complexe raliser pour un SGBD et est coteuse en temps et
en ressources. Le nombre de lignes de la table rsultat est gal cette fois au nombre de
lignes contenues dans les deux tables pour lesquelles le critre dgalit des colonnes est
respect. Il est bien sr possible deffectuer la jointure sur plus de deux tables : on indique
alors les diffrents critres de jointure entre les tables.
Construction de la SELECT vo.Marque, vo.Couleur, ve.Prix, pe.Nom, pe.Age
jointure des tables FROM voiture AS vo, vente AS ve, personne AS pe
voiture, WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
personne et
vente sur les
critres dgalit
Marque Couleur Prix Nom Age
des colonnes Peugeot Rouge 10 000 Nestor 96
NumaAch et
NumVoit. 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 intres-
sant 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 :
SELECT voiture.Marque, voiture.Couleur, vente.Prix
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 opra-
tion nest pas symtrique : soit on inclut toutes les lignes dune table, soit toutes celles de
lautre. On prcise cela laide des mots cls LEFT et RIGHT ou en inversant simplement
lordre des tables dans lexpression de linstruction de jointure.
Dans la requte qui suit, toutes les lignes de la table voiture seront affiches, y compris
celles pour lesquelles la colonne NumVoit na pas de correspondance dans vente : les
colonnes issues de vente ne pourront alors tre mises en correspondance et auront la
valeur NULL.
Construction de la SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
jointure externe des FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit ;
tables voiture et
vente sur les
critres dgalit de NumVoit NumVoit Marque Couleur Prix
la colonne 1 1 Peugeot Rouge 10 000
NumVoit.
2 2 Citroen Noire 70 000
3 NULL Opel Blanche NULL
4 4 Peugeot Blanche 30 000
5 5 Renault Rose 45 000
6 NULL Renault Bleue NULL
Si lon opre la requte en inversant lordre des tables, ou en employant le mot cl RIGHT,
on obtient la mme rponse que pour la requte dqui-jointure ci-dessus. Cela signifie
quil ny a pas de lignes dans vente dont le contenu de la colonne NumVoit ne possde
pas de correspondance dans la colonne NumVoit de la table voiture. Ce rsultat est pr-
visible puisquune voiture doit exister dans la table voiture pour pouvoir faire lobjet
dune vente. On dispose alors dun moyen de contrler la cohrence des donnes entre les
tables : dans notre cas, on pourra ainsi vrifier quil ny a pas de valeur didentifiant de voi-
ture dans la table vente (contenu de la colonne NumVoit de la table vente) qui ne se
trouve pas dans la table voiture (contenu de la colonne NumVoit de la table voiture).
Construction de la SELECT voiture.NumVoit, vente.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
jointure externe FROM vente LEFT OUTER JOIN voiture ON voiture.NumVoit=vente.NumVoit ;
inverse des tables
voiture et vente
sur les critres
NumVoit NumVoit Marque Couleur Prix
dgalit de la 1 1 Peugeot Rouge 10 000
colonne NumVoit.
2 2 Citroen Noire 70 000
4 4 Peugeot Blanche 30 000
5 5 Renault Rose 45 000
Il faut terminer la requte et rpondre la question de dpart : Quelles sont les voitures
qui nont pas t vendues ? Pour ce faire, il suffit de slectionner les lignes dont lune des
colonnes issues de la table vente na pas pu tre mise en correspondance avec une ligne de
la table voiture : le contenu de cette colonne sera vide, ce qui signifie que lon peut le tes-
ter avec le mot cl NULL. Par exemple, on teste le contenu de la colonne Prix issue de la
table vente.
Slection des lignes SELECT voiture.NumVoit, voiture.Marque, voiture.Couleur, vente.Prix
de la table FROM voiture LEFT OUTER JOIN vente ON voiture.NumVoit=vente.NumVoit
prcdente. WHERE vente.Prix IS NULL;
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 SELECT Marque, Type
la table voiture. FROM voiture
ORDER BY Marque ;
Marque Type
Citroen SM
Opel GT
Peugeot 404
Peugeot 403
Alpine
Renault
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 SELECT Prix, DateVente
la table voiture en FROM vente
ordre dcroissant. 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 SELECT Nom, Age, Ville
Age de la table FROM personne
personne. ORDER BY Ville, Age ;
Le langage SQL comprend une partie manipulation de donnes (LMD) pour grer les
tables, qui est prsente dans cette section. Les oprations de cration, de suppression et de
modification des tables mettent jour le dictionnaire de donnes du SGBD. On rappelle
que le dictionnaire de donnes est une structure propre au SGBD qui contient la descrip-
tion des objets du SGBD (base de donnes, tables, colonnes, droits, etc.).
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.
Les tables peuvent tre cres de manire temporaire : elles seront donc effaces la fin de
Type de donnes Le type de donnes est choisi essentiellement en fonction des opra-
tions qui sont effectues sur la colonne. Le choix du type permet galement de mettre en
place un premier niveau de restriction sur le contenu des donnes : une colonne de type
numrique ne pourra pas contenir de caractres. Des restrictions plus fines seront dfinies
la section Contraintes dintgrit .
Voici une liste (non exhaustive) des types de donnes SQL (voir tableaux 4.6, 4.7, 4.8 et
4.9).
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 rfren-
tielle), le SGBD refuse en gnral de la supprimer : il utilise loption RESTRICT par
dfaut. Si lon dsire tout de mme la supprimer ainsi que tous les objets qui lui sont lis,
il faut alors utiliser loption CASCADE. Dans lexemple, si la table vente utilise la table
voiture comme table de rfrence pour le contenu de la colonne NumVoit, on ne peut
supprimer la table voiture avant davoir supprim la table vente.
DROP TABLE voiture CASCADE
Modification
La commande ALTER TABLE permet de modifier la structure de la table, cest--dire
dajouter, de supprimer ou modifier des colonnes.
Ajout dune ALTER TABLE voiture
colonne de nom ADD COLUMN enplus INT ;
enplus de type
INT la table
voiture (ADD
COLUMN).
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.
SQL 113
Affichage de la SELECT * FROM voiture ;
table voiture
modifie.
NumVoit Marque Type Teinte
1 Peugeot 404 Rouge
2 Citroen SM Noire
3 Opel GT Blanche
4 Peugeot 403 Blanche
Alpine
5 Renault Rose
A310
6 Renault Floride Bleue
Proprits gnrales
La valeur de la colonne doit tre renseigne absolument (NOT NULL).
La valeur doit tre unique compare toutes les valeurs de la colonne de la table (UNI-
QUE).
Lorsque les deux conditions prcdentes sont runies, la colonne peut servir identifier
un enregistrement et constitue donc une cl candidate . On rappelle quil ne peut y
avoir quune seule cl que lon dsignera en SQL par le mot cl PRIMARY KEY. Ici, on
indique que la colonne NumAch est choisie comme cl de la table (donc implicitement
unique et non nulle) et que la colonne Nom doit toujours tre renseigne.
CREATE TABLE personne (
NumAch INT PRIMARY KEY,
Nom CHAR(20) NOT NULL,
Age INT
) ;
Si aucune mention nest prcise comme pour la colonne Age, elle peut tre renseigne ou
non. Attention, une colonne non renseigne (cest--dire qui contient la valeur NULL
pour SQL) signifie quelle ne contient aucune donne, et non pas, par exemple, quelle
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)
) ;
SQL 115
CREATE TABLE personne
(NumAch INT PRIMARY KEY,
Nom CHAR(20) NOT NULL,
Ville CHAR(40),
AGE INT,
CONSTRAINT la_contrainte CHECK ( (Age IS NOT NULL AND Ville IS NOT NULL) OR (Age
IS NULL AND Ville IS NULL) )
;
Une vue est le rsultat dune requte que lon peut manipuler de la mme faon quune
table. On peut considrer une vue comme une table dynamique dont le contenu est recal-
cul chaque utilisation. On utilise les vues pour des raisons de commodit il nest pas
ncessaire que certains utilisateurs voient le modle complet qui est parfois complexe ou
encore de scurit/confidentialit en restreignant laccs certaines donnes. Dans cette
optique, les vues viennent en complment de la gestion des droits daccs, qui est traite
au chapitre 6.
CREATE VIEW personne_bis (NumAch, Nom, Age)
AS
SELECT NumAch, Nom, Age
FROM personne ;
Les vues permettent galement de mettre jour les tables, condition que les rgles dint-
grit de(s) table(s) utilises pour construire la vue soient respectes : en pratique, seules les
vues concernant une seule table peuvent effectuer des mises jour.
Remarque
Pour tre insres, les valeurs des colonnes doivent respecter les contraintes dintgrit associes
la table.
SQL 117
Affichage de la SELECT * FROM voiture ;
table voiture
modifie.
NumVoit Marque Type Couleur
2 Citroen SM Noire
3 Opel GT Blanche
4 Peugeot 403 Blanche
Alpine
5 Renault Rose
A310
6 Renault Floride Bleue
Attention, si lon ne spcifie aucune condition, tous les enregistrements sont supprims.
DELETE FROM personne ;
permet :
La gestion de tables et de vues munies des contraintes associes (LDD, Langage de Des-
cription des Donnes). Ces instructions concernent la table et sa structure.
cration CREATE TABLE/VIEW <nom de la table>
destruction DROP TABLE/VIEW <nom de la table>
modification ALTER TABLE/VIEW <nom de la table>
La manipulation de donnes (LMD, Langage de Manipulation des Donnes). Ces ins-
tructions concernent les donnes contenues dans les tables.
insertion INSERT INTO <nom de la table> (<liste de colonnes> <liste de valeurs>)
modification UPDATE <nom de la table> SET <colonne=valeur> WHERE <critre>
destruction DELETE FROM <nom de la table> WHERE <critre>
Linterrogation et la recherche dans les tables.
SELECT <liste de colonnes>
FROM <nom de la table>
WHERE <critre>
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 ;
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 ;
Trouvez lge moyen des personnes habitant Paris dans la base de donnes casse.
FROM Personne
WHERE Ville=Paris ;
EXERCICE 4 AGRGAT
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 colon-
nes (5 + 4).
SELECT *
FROM personne, voiture;
Lopration est videmment symtrique. En revanche, si les donnes sont les mmes, elles
ne se trouveront pas dans le mme ordre.
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
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit)
AND (pe.NumAch=ve. NumAch);
On aurait pu galement crire :
SELECT vo.Marque, pe.Nom
FROM voiture AS vo, vente AS ve, personne AS pe
WHERE (vo.NumVoit=ve.NumVoit) AND (pe.NumAch=ve. NumAch);
Le rsultat est-il identique ? Pourquoi ?
Cest pratiquement la mme requte que pour lexercice prcdent, mais le lien entre les
tables a t ralis sur des colonnes diffrentes. La syntaxe est correcte et le type des colon-
nes sur lesquelles a t faite la jointure est compatible ; SQL retournera donc une table
rsultat . Le fait que ce rsultat na aucun sens du point de vue du monde rel ne peut
tre dduit du schma des relations. Pour ce faire, il faut consulter le modle conceptuel
qui lui a servi de base.
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
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)
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
GROUP BY vo.Marque
;
Enfin, on limine du rsultat du calcul prcdent les marques dont la moyenne des prix est
infrieure 40 000 en ne gardant que les lignes dont la moyenne est suprieure ou gale
40 000.
Exercices
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
FROM voiture AS vo JOIN vente AS ve ON vo.NumVoit=ve.NumVoit
WHERE ve.Prix >= 40000
GROUP BY vo.Marque;
Avec le jeu de donnes restreint dont on dispose, on remarque que le rsultat est identique,
mais cest videmment un hasard.
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);
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.
Les informations modifier se trouvent simplement dans la table vente bien que la ques-
tion voque les voitures . Il ny a pas de critre dans ce cas puisque lon modifie toute la
table.
UPDATE vente
SET Prix=Prix*1.1 ;
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 cat-
gories de personnes : celles qui ont achet des voitures mais pas de voitures rouges ; celles
qui nont achet aucune voiture. Pour obtenir la liste des personnes qui nont achet
aucune voiture, on utilise une requte de type jointure externe. Les informations se trou-
vent dans les deux tables personne et vente .
SELECT personne.Nom
FROM personne LEFT OUTER JOIN vente ON personne.NumAch=vente.NumAch
WHERE vente.NumAch IS NULL;
Pour obtenir la liste des personnes qui ont achet une voiture, mais pas rouge, on utilise
Exercices
une requte de type slection sur une quijointure. Les informations se trouvent dans les
deux tables personne et voiture, que lon doit relier par la table vente.
SELECT pe.Nom
FROM voiture AS vo JOIN vente AS ve JOIN personne AS pe ON (vo.NumVoit=ve.NumVoit)
AND (pe.NumAch=ve. NumAch)
WHERE vo.Couleur != Rouge;
SQL 125
Chapitre
Du langage
parl SQL
1. Prsentation de lactivit Ce chapitre prsente un exemple complet de
modliser ............................128 ralisation dune base de donnes, tape par tape.
2. laboration du modle
entit-association ....................129 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 Cet exemple permet de rcapituler les concepts
de donnes ............................141
prsents dans les chapitres prcdents, savoir :
Exercices
1. Reprsentation UML ................148 lanalyse du monde rel et la cration du modle
2. Calculs par expression SQL .....148 entit-association ;
3. Code SQL et signification ........149 le passage au modle relationnel ;
4. Agrgats et slection ...............150
la cration des tables en SQL par lintgration des
5. Requtes combines ...............151
contraintes de contenu ;
6. Simple slection ou
jointure externe ? ....................152 linterrogation de la base de donnes par des
7. Mise jour de la base ............153 requtes SQL.
8. volution de la base
de donnes ............................154
On aborde galement ici les diffrents aspects
9. Autre exemple complet ............154 dordre pratique qui se posent chaque tape de la
ralisation dune base de donnes.
127
1 Prsentation de lactivit modliser
On veut modliser la gestion dune entreprise de fabrication et de livraison de pizzas
domicile : la socit RaPizz. Il sagit dune socit en franchise qui utilise des formats et des
compositions de pizzas normaliss partir dun ensemble dingrdients dtermins. En
dautres termes, le client na pas la libert de composer lui-mme une pizza personnalise ;
il doit choisir dans le catalogue propos.
Produits
Les produits vendus sont des pizzas. Une pizza est caractrise par son nom, les ingr-
dients qui la composent et son prix de base. Pour chaque pizza, il existe trois tailles :
naine , humaine et ogresse . La naine est 1/3 moins chre que le prix de base,
cest--dire la taille humaine , et l ogresse est 1/3 plus chre.
Mode de distribution
Les pizzas sont livres par des livreurs qui circulent en voiture ou moto et qui nont pas
de vhicules attitrs. La base de donnes doit galement permettre le suivi de lactivit des
livreurs et des vhicules quils utilisent.
Modalits de vente
Le mode de vente est du type prpay : pralablement toute commande, les clients doi-
vent sabonner au service et approvisionner leur compte. On vrifie le solde du compte
avant de prparer et de livrer la commande.
Il existe deux systmes de bonification :
Une pizza gratuite est offerte au bout de 10 pizzas achetes.
Toute pizza livre en plus de trente minutes est gratuite.
Objectifs du systme
Le but de cette base de donnes est de grer lactivit quotidienne de vente et de livraison
de pizzas :
vrification du solde du compte et facturation aux clients ;
suivi du chiffre daffaires ;
refus dhonorer les commandes pour lesquelles le solde du compte client est
insuffisant ;
non-facturation des pizzas gratuites (retard ou fidlit).
On veut galement effectuer des statistiques diverses sur lactivit :
identification du meilleur client ;
identification du plus mauvais livreur (nombre de retards dans la livraison) et du
vhicule utilis ;
identification de la pizza la plus ou la moins demande ;
identification de lingrdient favori
vit est la vente dune unique pizza. La notion de commande qui peut contenir plusieurs pizzas
nest pas prise en compte. On pourra faire voluer le systme plus tard si besoin est pour intgrer
cet aspect. Il est en effet plus simple de raisonner en termes de ventes unitaires, que lon peut
agrger ensuite, plutt que dattaquer directement sur des commandes multiples.
La premire tape consiste reprer les diffrentes entits que lon doit considrer. Pour ce
faire, il nous faut trouver les phrases simples qui identifient lactivit par rapport
lnonc. Paralllement, on peut chercher quels objets concrets du monde rel semblent
impliqus dans le systme. Puis, pour chaque entit, on doit dterminer une cl parmi les
attributs. Enfin, on caractrise les liens entre les entits par des associations.
Entits et attributs
On rappelle quil ne sagit pas vraiment dun processus scientifique bas sur des rgles pr-
cises. Une certaine part dintuition est ncessaire, dautant plus quil nexiste pas une solu-
tion unique dans la majorit des cas.
On peut remarquer quelques mots cls dans la description gnrale : pizza, ingrdient,
client, livreur, vhicule. Ces descripteurs reprsentent des objets familiers du monde
rel. En revanche, les mot cls taille, prix, compte, retard, nom et autres sont claire-
ment plus des qualifiants que des objets. Ce qui relie tous ces objets pour constituer la
reprsentation de lactivit est la notion de commande. Cette dernire est lun des seuls
objets abstraits, compare aux autres objets concrets du monde rel, comme peut ltre un
vhicule par exemple.
partir de ces constatations, voici une proposition de quelques phrases extraites ou
dduites de la description gnrale qui permettent deffectuer une premire synthse de
lactivit :
Une pizza est constitue de plusieurs ingrdients.
Un client passe une commande.
Une commande est livre par un et un seul livreur.
Une commande est livre par un et un seul vhicule.
Choix de la cl
Les attributs tant identifis, on doit maintenant choisir une cl pour chaque entit. Si lon
prend lentit client, il est clair quaucun attribut ne peut convenir pour constituer une
cl. De mme, lassociation de plusieurs attributs NomClient-Adresse, NomClient-
Compte, Compte-PointsRaPizz et autres ne permet pas de crer une cl. On ajoute alors
classiquement un attribut identifiant qui sert de cl : ce peut tre un simple nombre ou un
mlange de lettres et de nombres (alphanumriques) plus commode mmoriser.
En utilisant ces mmes arguments, on est amen ajouter des attributs numriques
comme cls pour les entits livreur et commande.
Pour lentit pizza, on peut supposer que le nom de la pizza est significatif et quil peut
donc servir de cl. En effet, le catalogue de pizzas propos est restreint et codifi par le fait
quil sagisse dune entreprise de type franchis . Il ny a pas dintrt pour le franchi-
seur, dun simple point de vue commercial, donner deux fois le mme nom une pizza.
En pratique, mme si le nom est unique, on pourrait dcider de ne pas lutiliser car le con-
tenu est un peu long. Lentit vhicule dispose dun champ identifiant : son numro
dimmatriculation qui est par dfinition unique. Enfin, en ce qui concerne les ingrdients,
il peut tre moins vident que le nom seul de lingrdient suffise lidentifier. Il est prf-
rable de lui ajouter un numro.
On obtient les entits suivantes munies de leurs attributs :
commande (NumCommande, DateCom, Taille, Retard) ;
client (NumClient, NomClient, Adresse, Compte, PointsRaPizz) ;
pizza (NomPizza, Prix) ;
livreur (CodeLivreur, NomLivreur, Tlphone) ;
vhicule (NumImmat, Marque, Type) ;
ingrdient (NumIngre, NomIngrdient).
Associations et attributs
On peut, partir des phrases qui ont permis de reprer les entits, en dduire les associa-
tions suivantes :
Livre entre Livreur et Commande ;
Transporte entre Vhicule et Commande ;
Passe entre Client et Commande ;
Constitue entre Pizza et Commande ;
Compose entre Pizza et Ingrdient.
Il reste dterminer les attributs ventuels des associations. Dans notre cas, le choix duti-
liser une entit commande fait que lon regroupe naturellement dans cette entit les attri-
buts qui auraient pu se retrouver sur les associations.
ventuellement, une date de commande pourrait tre un attribut de lassociation Passe si
elle tait diffrente de la date de la commande. On peut cependant imaginer que ce genre
Figure 5.1
Commande Passe Client
Modle entit- Livre
Livreur # NumCommande
association # NumClient
Livraisons de # CodeLivreur DateCom
NomClient
NomLivreur Taille
pizzas sans Adresse
Tlphone Retard
cardinalits. Compte
PointsRapizz
Transporte
Constitue
Vhicule Ingrdient
Pizza
# NumImmat Compose
Marque # NumIngre # NomPizza
Type NomIngre Prix
On se pose ensuite des questions sur la nature des liens entre les entits capables de dter-
miner les cardinalits qui seront utilises pour le passage au modle relationnel. On doit
trouver deux cardinalits, maximales et minimales, par entit associe, ce qui correspond
deux questions doubles par association. Il sagit dune tape dinventaire un peu fasti-
dieuse, mais elle est indispensable et permet de poser un autre regard sur le modle.
Association Compose
Ingrdient : un ingrdient peut-il ne jamais tre utilis dans la composition dune pizza et
peut-il tre utilis plusieurs fois ? On suppose que si un ingrdient est au catalogue, cest
quil est utilis au moins une fois (1) et quil peut entrer dans la composition de plusieurs
(n) pizzas. Les cardinalits associes sont de type 1-n.
Pizza : une pizza peut-elle navoir aucun ingrdient et peut-elle en avoir plusieurs ? On
suppose quune pizza est constitue dau moins un (1) ingrdient et quelle peut en avoir
plusieurs (n). Les cardinalits associes sont de type 1-n.
Association Passe
Client : un client peut-il navoir jamais pass de commandes et peut-il en avoir pass
plusieurs ? Il peut y avoir une priode pendant laquelle le client a approvisionn son
compte mais na pas encore pass (0) de commande et il est videmment encourag en
passer plusieurs (n). Les cardinalits associes sont de type 0-n.
Commande : une commande peut-elle avoir t passe par aucun client ou par plusieurs ?
Une commande donne est passe par un (1) et un (1) seul client. Les cardinalits asso-
cies sont de type 1-1.
Un livreur a au moins effectu une (1) livraison, sinon il nest pas considr comme tel.
On peut imaginer que lon ne rentre les informations associes un livreur qu partir du
moment o il a rellement effectu une livraison. Il est suppos faire plusieurs (n) livrai-
sons. Les cardinalits associes sont de type 1-n.
Commande : une commande peut-elle avoir t livre par plusieurs livreurs ou par
aucun ? Une commande est livre par un (1) et un (1) seul livreur. Les cardinalits asso-
cies sont de type 1-1.
Association Transporte
Vhicule : un vhicule peut-il navoir jamais livr de pizzas et peut-il en avoir livr plusieurs ?
Dans ce cas, la situation nest pas tout fait la mme que pour les livreurs. On peut imaginer
que les informations concernant un vhicule pourraient tre insres dans la base de don-
nes sans que le vhicule nait encore effectu une livraison (0). Si ctait le cas, on aurait des
cardinalits de type 0-n. On choisit ici des cardinalits associes de type 1-n. Dans les deux
cas, un vhicule est suppos tre utilis pour livrer plusieurs (n) commandes.
Commande : une commande peut-elle avoir t livre par plusieurs vhicules ou par
aucun ? Une commande est livre par un (1) et un (1) seul vhicule. Les cardinalits asso-
cies sont de type 1-1. On obtient le modle entit-association suivant (voir figure 5.2) :
1,n
0,n
Vhicule Ingrdient
1,n
Pizza
# NumImmat Compose
Marque # NumIngre # NomPizza
NomIngre 1,n Prix
Type
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 binai-
res, plus complexes transformer en relations. De plus, le modle UML ne propose pas de
solution trs cohrente pour reprsenter les associations ternaires ou de plus haut degr.
Les deux rgles gnrales de passage du modle entit-association vers le modle relation-
nel sont les suivantes :
Une entit donne une relation de mme cl que lentit qui contient les mmes attri-
buts que lentit.
Une association donne une relation dont la cl est compose des deux cls des entits
associes et des attributs de lassociation.
On doit vrifier que lensemble de relations cres ltape prcdente est bien en confor-
mit avec les formes normales. On peut se limiter en gnral aux trois premires formes
normales. En effet, celle de Boyce-Codd provoque frquemment un certain niveau de
perte dinformations (voir chapitre 3 pour plus de prcisions).
plexit que produit la dcomposition par le processus de normalisation. Il est parfois prfrable
de conserver un peu de redondance pour limiter le nombre de tables et prserver ainsi lefficacit
du systme.
Cette section permet de dterminer quels contrles doivent tre appliqus sur le contenu
des champs afin den garantir la cohrence. Les contraintes sont mises en uvre par le
SGBD employ et sont exprimes dans les instructions de cration des tables. Ces con-
traintes expriment lappartenance un ensemble. Un ensemble en SQL peut tre dcrit de
quatre manires :
le typage gnral dun point de vue des types prdfinis de SQL (par exemple, entier,
rel, caractre, date) ;
une numration des diffrentes valeurs possibles (par exemple, do , r , mi ,
fa , sol ) ;
lexpression dun intervalle dans lequel les valeurs sont contenues (par exemple, com-
pris entre 10 et 30) ;
la rfrence aux valeurs dun champ dune autre table (par exemple, contenu du
champ code_postal de la table communes).
Seule la description du type est obligatoire pour crer un champ, les autres contraintes
tant videmment optionnelles. Les champs dont les valeurs doivent tre absolument ren-
seignes sont indiqus spcifiquement en langage SQL par le mot cl NOT NULL .
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.
pizza. Les autres champs NomPizza sont plutt soumis des contraintes de rfrences
comme on va le voir dans la partie consacre aux rfrences.
Rfrence au contenu dune table. Les champs cls qui proviennent des associations
transformes en relations font rfrence au contenu des relations qui proviennent des
entits. Pour la relation compose, le champ NumIngre fait rfrence au contenu du
champ NumIngre de la table ingrdient et le champ NomPizza au contenu du champ
NomPizza de la table pizza.
En pratique, ici, la plupart des champs fusionns de la relation commande font aussi
rfrence des champs dautres relations.
CodeLivreur de la relation commande. Rfrence au champ CodeLivreur de la rela-
tion livreur.
NumImmat de la relation commande. Rfrence au champ NumImmat de la rela-
tion vehicule.
NumClient de la relation commande. Rfrence au champ NumClient de la relation
client.
NomPizza de la relation commande. Rfrence au champ NomPizza de la relation
pizza.
La cration des tables se fait partir de la dfinition des relations effectues prcdem-
ment. On spcifie le nom des champs, leur type, les contraintes dintgrit et la dfinition
des cls. On peut choisir galement ce moment les champs sur lesquels on souhaite crer
des index. Ces derniers amliorent la recherche par le contenu, mais pnalisent les mises
jour puisquil faut modifier les tables dindex. En gnral, mme si lon est susceptible
deffectuer des recherches sur tous les champs, on ne cre pas dindex pour chacun dentre
eux afin de ne pas pnaliser les performances, mme si lon est susceptible deffectuer des
recherches sur tous les champs. Cela pourrait tre cependant envisageable si le contenu de
la base est trs statique et que lon souhaite favoriser les performances de recherche. Les
index peuvent tre crs sparment.
En pratique, on cre systmatiquement un index sur les cls des relations, ne serait-ce que
pour amliorer les oprations de jointure. Certains SGBD prennent dailleurs linitiative
de crer lindex sur la cl mme si lon ne le spcifie pas explicitement.
Table client
CREATE TABLE client (
NumClient INT PRIMARY KEY,
NomClient VARCHAR(20) NOT NULL,
Adresse VARCHAR(150) ,
Compte REAL,
PointsRaPizz INT
);
Table pizza
CREATE TABLE pizza(
NomPizza CHAR(30) PRIMARY KEY,
Prix CHAR(30) NOT NULL,
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.
Cette section aborde la manire de passer dune question en langage parl la requte SQL
conduisant au rsultat. Lensemble des questions nest videmment pas exhaustif ; on a
effectu un choix qui permet de mettre en valeur certains points jugs intressants. On
utilise galement ces questions pour porter un regard sur les reprsentations choisies et
vrifier quelles sont bien adaptes. Le sujet de loptimisation des requtes en fonction du
SGBD choisi nest pas trait, car il dpasse largement le cadre de cet ouvrage.
4.1 MENU
On veut extraire les donnes qui servent imprimer la carte, ce qui signifie que lon veut
disposer du nom de chaque pizza, de son prix et des ingredients qui la composent. Pour ce
faire, on commence par identifier les tables o se trouvent les champs que lon veut
projeter :
Le nom de la pizza est dans la table pizza.
Le prix de la pizza est dans la table pizza.
Les noms des ingrdients se trouve dans la table ingredient.
Le lien entre ces deux tables est matrialis par le modle entit-association : il sagit de
lassociation compose. Cette dernire est devenue la relation compose. On effectue donc
une double jointure entre les trois tables pizza, ingredient et compose. Les tables pizza
et compose seront jointes sur le champ NomPizza et les tables ingredient et compose
seront jointes sur le champ NumIngre.
Il y a deux manires dcrire une jointure. Une jointure peut tre La premire consiste
lapprhender comme une slection sur un produit cartsien. Lcriture est plus pdagogi-
que, mais totalement inefficace du point de vue du SGBD qui doit effectuer le produit car-
tsien puis slectionner les lignes.
SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix
FROM pizza, ingredient, compose
WHERE pizza.NomPizza = compose.NomPizza
AND ingredient.NumIngre = compose.Numingre;
La seconde, plus efficace, est dutiliser linstruction de jointure JOIN.
SELECT pizza.NomPizza, ingredient.NomIngre, pizza.Prix
FROM pizza JOIN ingredient JOIN compose
ON (pizza.NomPizza = compose.NomPizza
AND ingredient.NumIngre = compose.Numingre);
On se trouve dans le cas trs classique de deux entits lies par une association, qui don-
nent trois tables (pizza et ingredient lies par compose). Il sera ncessaire dutiliser un
langage de programmation pour obtenir un affichage lgant du nom de la pizza, de son
prix et des ingrdients qui la composent. En effet, pour chaque nom de pizza, on obtien-
dra autant de lignes que dingrdients.
On veut imprimer une fiche de livraison qui mentionne le nom du livreur, le type du vhi-
cule utilis, le nom du client, la date de la commande, le retard ventuel, le nom et le prix
de base de la pizza. Par le mme raisonnement que prcdemment, on identifie les tables
commande, client, pizza, livreur et vehicule pour les champs projeter :
La table pivot est ici la table commande qui assure la jointure avec toutes les autres tables.
Cela confirme lintuition que lentit commande aurait pu tre considre comme une
association n-aire.
Sur une requte aussi simple, on remarque que le travail du SGBD est assez lourd puisquil
doit effectuer la jointure de cinq tables. Cest la raison pour laquelle on prfre parfois uti-
liser des relations, et donc des tables, avec une certaine redondance afin damliorer les
performances : lopration de jointure est coteuse. Une stratgie couramment employe
consiste grer en interne une base de donnes sans redondance et gnrer une table
redondante qui servira faire les requtes. On dispose ainsi dune garantie de cohrence et
des performances prserves. Les bases de donnes en ligne accessibles par le Web sur les-
quelles on effectue beaucoup de requtes fonctionnent de cette manire. On rserve bien
sr cette mthode aux bases de donnes dont le contenu est assez stable : lopration de re-
gnration de bases chaque changement est coteuse.
Si lon se reporte aux cardinalits du modle entit-association, le cas ne doit pas exister.
On a choisi une cardinalit de type 1-n, ce qui signifie quun vhicule a livr au moins une
commande et quil a pu en livrer plusieurs. Cette requte va permettre de vrifier quil ny
a pas dincohrence ce niveau. On espre que le rsultat sera vide.
On a besoin pour rpondre aux questions du type quels sont les qui nont pas
dutiliser une extension des oprations de jointure : la jointure externe. Celle-ci permet
dinclure dans le rsultat dune jointure les enregistrements qui nont pas de valeur corres-
pondante dans lautre table. Les valeurs des champs de cette autre table sont alors logique-
ment vides. Il suffit de slectionner ces lignes vides pour obtenir la rponse la question.
Cest une opration non symtrique ; on part de la table vehicule que lon va joindre.
SELECT vehicule.NumImmat, vehicule.Marque, vehicule.Type
FROM vehicule LEFT OUTER JOIN commande
ON vehicule.NumImmat = commande.NumImmat
WHERE commande.NumImmat IS NULL;
Cette requte est typique des requtes de vrification que ladministrateur dune base doit
effectuer pour procder certaines vrifications de cohrence. Cela est surtout vrai lors-
que la base de donnes na pas t conue en intgrant les contraintes dintgrit indispen-
sables.
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.
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.
Figure 5.3
1,1 Commande 0,n
Modle entit- 1,n
1,1
Passe Client
association Livreur
Livre # NumCommande
Livraisons de DateCom
1,1 # NumClient
pizzas avec # CodeLivreur 1,1 Retard NomClient
cardinalits. NomLivreur Adresse
1,1
Tlphone Compte
Utilise PointsRapizz
Transporte
0,n Constitue
1,n Tarification
0,n
#Taille
Vhicule Coefficient
Pizza
# NumImmat
Marque # NomPizza
1,n Prix
Type Ingrdient
Compose
# NumIngre
NomIngre 1,n
Remarque
Les requtes retournent toujours un rsultat. Cependant, on ne peut tre sr que ce dernier repr-
sente la rponse exacte la question pose. Il est ncessaire de systmatiquement vrifier le rsul-
tat sur un jeu de donnes rduit. De mme quen programmation, on ne peut prouver quun
programme ralise correctement ce quon lui demande dans tous les cas de figure ; il est difficile
dtablir quune requte fournit la rponse adquate lorsque le nombre denregistrements devient
lev.
Rsum
Ce chapitre dtaille lensemble des tapes ncessaires la ralisation dune base de don-
nes, mme les plus fastidieuses. La grande difficult est de passer dun nonc en langage
parl, qui fait gnralement suite un entretien avec les commanditaires et les utilisateurs,
un systme utilisable en pratique et efficace. Le flot dinformations recueilli doit tre
ordonn et structur. Lexemple choisi est peu complexe, mais il permet daborder quel-
ques questions essentielles. On saperoit cette occasion que lensemble des tables utili-
ses dans le SGBD devient rapidement illisible si lon ne possde pas un schma descriptif
(modle entit-association ou UML) correct.
La partie Interrogation illustre les catgories dutilisations et dinterrogations classi-
ques dune base de donnes. Lide est de donner des indications afin didentifier le type de
requte SQL utiliser en fonction de la question exprime en langage courant. La dmar-
che suggre est de toujours dcomposer les questions en sous-questions plus simples
rsoudre puis de procder par tapes. Un des exemples aborde ensuite le cas o, au cours
de lutilisation de la base de donnes, il est impossible de trouver la solution en raison
dune reprsentation inadquate. Il est alors ncessaire de remettre en cause le modle
utilis :
Soit on modifie le contenu des tables et lon rpercute les modifications sur le modle
descriptif utilis.
Soit on modifie le modle descriptif et lon ritre les tapes de passage au modle rela-
tionnel.
La seconde mthode est la solution la plus juste dun point de vue thorique. Mais, en pra-
tique, on utilise une combinaison des deux approches pour obtenir le rsultat. Il est essen-
tiel de comprendre quil ny a pas de solution unique en base de donnes. Le modle est
frquemment adapt et aucune reprsentation nest fige. De mme que la ralit peut tre
envisage diffremment suivant les personnes, il existe souvent plusieurs visions valides.
Utilise
Transporte Constitue
1..1
Tarification
1..1
#Taille 1..1
Vhicule Coefficient
Pizza
# NumImmat
Marque 1..n # NomPizza
Type Ingrdient Prix
Compose
# NumIngre 1..n
NomIngre
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 impor-
tant que lon a fix comme axiome lors de llaboration du modle : une pizza est asso-
cie une commande et une seule. Une commande ne contient quune seule pizza. Cest
important : si ce ntait pas le cas, la requte serait beaucoup plus complexe.
contenu du champ retard a t normalis et restreint par une contrainte dintgrit aux
valeurs N et O . Ces rflexions conduisent la simple requte suivante :
SELECT COUNT(*) AS NombreRetard
FROM commande
WHERE retard=O;
On compte le nombre de lignes de la table commande dont le champ commande est gal
O . On ne spcifie pas de nom de champ dans la fonction COUNT de SQL, car il
sagit dun calcul indpendant dun champ donn.
Pour connatre la perte occasionne, on calcule la somme du prix de chaque commande.
Le modle a t modifi pour pouvoir calculer directement cette information. On a besoin
du prix de base de la pizza qui se trouve dans la table pizza et du coefficient qui se trouve
dans la table tarification. On effectue une jointure sur ces trois tables.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard
FROM commande JOIN pizza JOIN tarification
ON commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille
WHERE commande.retard=O;
La fonction SQL SUM a besoin du contenu prcis du champ concern par le calcul. Ici, il
sagit dune expression constitue partir du prix et du coefficient. Il est prfrable de pr-
fixer les noms de champ par le nom de la table do ils proviennent pour viter les ambi-
guts et faciliter la lecture ultrieure de la requte. Les ambiguts sont signales par le
SGBD qui refuse dexcuter la requte.
On aurait pu crire les jointures en utilisant classiquement un produit cartsien et une
slection. Dans ce cas, les expressions qui servent la jointure sont mlanges celles qui
servent faire la slection dans la clause WHERE. De plus, la requte est effectue de
manire beaucoup moins efficace par le SGBD ; cela est nettement perceptible lorsque lon
dispose de tables de taille importante.
SELECT SUM(pizza.prix*tarification.coefficient) AS PerteRetard
FROM commande, pizza, tarification
WHERE commande.NomPizza=pizza.NomPizza AND commande.Taille=tarification.Taille
AND commande.retard=O;
Les deux tables rsultat sont des tables qui possdent une seule ligne et une seule
colonne. On peut utiliser ces valeurs par exemple pour faire une comparaison (voir lun
des exercices suivants) en les associant par un produit cartsien la table sur laquelle on
veut effectuer la comparaison.
Imaginez quel type de question a voulu rpondre la personne qui a fait cette requte.
Donnez le chiffre daffaires par pizza vendue. On ne tient pas compte ce niveau des piz-
zas gratuites obtenues grce aux points de fidlit ou en raison dun retard de livraison.
ORDER BY TotalCommande;
En revanche, si lon avait voulu liminer du rsultat les pizzas dont le prix de vente nest
pas assez lev considrant que cela fausse le rsultat, le mode de slection ne serait pas le
mme. Il faudrait raliser une slection sur lensemble de dpart avant deffectuer les agr-
gats et les calculs ; dans ce cas, on utiliserait le mot cl WHERE.
SELECT commande.NomPizza, COUNT(*) AS NombreCommande, SUM(pizza.prix*tarifica-
tion.coefficient) AS TotalCommande
FROM commande JOIN pizza JOIN tarification
ON commande.Taille=tarification.Taille AND commande.NomPizza=pizza.NomPizza
WHERE pizza.prix > 10
GROUP BY commande.NomPizza
ORDER BY TotalCommande;
Dans le premier cas, la slection est faite a fortiori ; dans le second, a priori.
On dcompose le problme :
calcul du nombre de retards par livreur ;
calcul du maximum de ces retards ;
slection du nom du livreur qui a le maximum de retard.
Calcul du nombre de retards par livreur. Le mot par suggre comme prcdem-
ment lemploi dagrgats sur lesquels on utilise la fonction de comptage.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
Calcul du maximum de ces retards. On utilise la fonction SQL MAX sur le contenu de
la table prcdente.
CREATE TEMPORARY TABLE requete2
SELECT MAX(NombreRetard)AS MaxRetard
FROM requete1
;
La tournure de phrase qui na jamais semble suggrer lemploi dune jointure externe,
comme ctait dj le cas dans le chapitre o on a dtermin les vhicules nayant jamais
servi. Cependant, cette jointure externe sert dterminer les entits non associes dans
une jointure. Ici, on peut obtenir linformation du retard directement dans la table com-
mande. Si lon considre les rsultats de lexercice prcdent, on a calcul le nombre de
retards par livreur par la requte suivante.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
Un livreur naura jamais t en retard si le nombre de retards ainsi calcul est gal zro.
SELECT requete1.CodeLivreur
FROM requete1
WHERE requete1. NombreRetard=0
;
On cherche le nom du livreur et non pas son code. Il y a deux manires de procder :
Soit on fait une jointure sur la table livreur pour la premire requte de manire
inclure le nom du livreur dans la table rsultat.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, livreur.NomLivreur, COUNT(*) AS NombreRetard
FROM commande JOIN livreur
ON commande.CodeLivreur=livreur.CodeLivreur
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
SELECT requete1.NomLivreur
FROM requete1
WHERE requete1. NombreRetard=0
;
Soit on fait la jointure lors de la seconde requte.
CREATE TEMPORARY TABLE requete1
SELECT commande.CodeLivreur, COUNT(*) AS NombreRetard
FROM commande
GROUP BY commande.CodeLivreur
ORDER BY NombreRetard
;
SELECT livreur.NomLivreur
FROM requete1 JOIN livreur ON requete1.CodeLivreur=livreur.CodeLivreur
WHERE requete1. NombreRetard=0
;
Le cas serait diffrent si lon cherchait identifier les noms des livreurs qui nont jamais
effectu de livraison.
Laction de livraison est reprsente par lassociation livre dans le modle entit-associa-
tion. Cette association, puisque de cardinalit 1-1, a disparu en tant que table et a t
intgre dans la relation commande issue de lentit commande.
En rsum, linformation nest disponible que par une jointure entre les tables com-
mande et livreur. Lide ici est de trouver les codes des livreurs prsents dans la table
livreur mais pas dans la table commande. Daprs notre dfinition du modle entit-
association, ce ne devrait pas tre possible puisque la cardinalit du point de vue (du ct)
de lentit livreur est de type 1-n : un livreur a au moins livr une pizza et est susceptible
den livrer plusieurs. On emploie alors une jointure externe qui nous permet dinclure
dans le rsultat les lignes nayant pas de correspondance dans la table commande.
SELECT *
FROM livreur LEFT JOIN commande
ON livreur.CodeLivreur=commande.CodeLivreur
;
Pour slectionner ceux qui nauraient pas effectu de livraison, on choisit une ligne dont
un champ issu de la table commande est vide (a une valeur nulle en SQL). On projette
sur le champ NomLivreur de la table commande qui tait linformation demande.
SELECT livreur.NomLivreur
FROM livreur LEFT JOIN commande
ON livreur.CodeLivreur=commande.CodeLivreur
WHERE commande.CodeLivreur IS NULL
;
On veut mettre jour le solde du compte dun client aprs chaque commande. Pour ce fai-
re, il est ncessaire de recourir un langage de programmation ou des notions qui dpas-
sent le cadre de cet ouvrage ; on sintresse simplement aux diffrentes requtes prvoir
pour raliser cette opration. Pour linstant, on considrera que lon cre la requte de mise
jour sans se proccuper des aspects de solde (ngatif ou positif) du compte.
La requte de mise jour serait la suivante, on rcupre les champs prix de la commande
de la premire requte pour effectuer la mise jour du solde du compte du client dans la
table client.
UPDATE client,requete1
SET Compte=Compte-requete1.Prix_Commande
WHERE client.NumClient=requete1.NumClient ;
On veut 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 car-
tsien avec la table taxes.
SELECT NomPizza, Prix*(1+Taux) AS Prix_Ttc
FROM pizza, taxes ;
Dans ce second cas, il faudrait pour tre complet ajouter lentit taxes au modle entit-
association. Elle ne serait lie aucune entit par une association.
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.
Prservation
des donnes
1. Contrle daccs et Ce chapitre traite de la scurit des donnes qui est
sauvegarde ............................158 une notion fondamentale des bases de donnes. En
2. Limitations daccs au SGBD ...161 effet, le pire pour une base de donnes est la perte
3. Transactions ...........................166
ou la modification de donnes. Des problmes
srieux peuvent tre provoqus de manire
4. Triggers ................................173
intentionnelle ou accidentelle, mais le rsultat
Exercices obtenu est le mme.
1. Scurit de base .....................176 Lactivit des organisations repose sur les donnes :
2. Disponibilit des donnes ........176 il convient par consquent de les protger, mais
3. Niveaux dutilisation dune base galement den assurer la disponibilit permanente.
de donnes ............................177 On distinguera plusieurs niveaux de granularit
4. Gestion des droits ...................178 quant aux recommandations gnrales concernant la
scurit des donnes :
5. Vues ......................................179
la protection de laccs la machine dun point de
6. Transactions ...........................181
vue physique ou rseau, les aspects de dure de
7. Trigger ...................................182 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
1 Contrle daccs et sauvegarde
Toute rflexion autour de la scurit doit se concevoir de manire globale en utilisant en
premier lieu le bon sens : il est inutile dinstaller une porte blinde inviolable sur une palis-
sade en bois. Les recommandations qui sont nonces dans cette section sont applicables
tous les systmes informatiques, en particulier ceux qui sont connects un rseau ou
situs dans un milieu qualifi d hostile .
On dcrit ici plusieurs types de proccupations :
laccs physique la machine ;
laccs distant la machine travers le rseau ;
les aspects de prennit de lensemble machine, systme dexploitation et SGBD ;
les sauvegardes, la redondance des donnes et leur accessibilit.
Cette mesure de scurit informatique lmentaire est trs souvent nglige. Procurer un
accs physique la machine permet en gnral de contourner toutes les protections lies
au systme dexploitation ou au SGBD que lon aborde dans ce chapitre. Il suffit de
dmarrer une machine avec un autre systme dexploitation prsent sur un CD ou une cl
USB par exemple pour obtenir un accs au disque et ainsi aux donnes associes au SGBD.
La premire prcaution prvoir consiste protger le BIOS (Basic Input Output System)
ou lquivalent de la machine pour lempcher de dmarrer sur un autre disque que celui
qui contient le bon systme dexploitation.
Le fait de pouvoir accder directement la machine permet galement une personne
anime de mauvaises intentions dempcher laccs aux donnes en dtruisant physique-
ment le disque sur lequel se trouvaient les fichiers ou mme la machine.
Par consquent, la ou les machines qui contiennent le SGBD et les fichiers de donnes doi-
vent se trouver dans des pices dont laccs est, au minimum, contrl. Dans le mme
ordre dide, lalimentation lectrique ne doit pas tre accessible. On a tous entendu ou
vcu une histoire de machines ou dlments rseaux dbranchs par erreur pour effectuer
le mnage, sans parler de la malveillance. Comme on peut le constater, les prcautions
concernant laccs physique la machine ne sont pas toujours dordre purement
technique ; elles relvent souvent du simple bon sens commun.
Laccs la machine par le rseau est devenu une porte dentre privilgie pour les per-
sonnes malintentionnes, car rares sont les serveurs qui ne sont pas connects
aujourdhui. On distingue ainsi principalement deux aspects de problmes de scurit :
les attaques internes qui proviennent de personnes ayant accs la machine par un
compte standard associ un mot de passe correct ;
les attaques externes qui se font en profitant dune faille du systme dexploitation
ou dune des applications installes sur la machine.
Dans les deux cas, on peut tre confront un problme de destruction de donnes par
simple effacement de fichiers de donnes. Cette opration deffacement sera rendue plus
ou moins facile suivant les systmes employs. Dans le premier cas, il est en principe
Sil sagit dun cas de malveillance, les dgts peuvent tre considrables.
Les protections dans ce domaine ne dpendent pas spcifiquement de ladministrateur du
SGBD, mais aussi de ladministrateur systme et rseau de lenvironnement dans lequel se
trouve la machine qui hberge le SGBD. Le systme et les applications prsentes sur la
machine doivent tre maintenus et mis jour rgulirement pour viter les problmes.
Ladministrateur systme doit galement tenir jour les comptes utilisateurs qui poss-
dent les droits daccs la machine et vrifier la qualit des mots de passe associs. Classi-
quement, une intrusion se fait en utilisant un compte oubli , cr par exemple pour un
besoin ponctuel, dont le mot de passe est assez simple pour tre devin. Le SGBD lui-
mme est une application parmi les autres ; il peut prsenter des failles et doit faire partie
du programme des mises jour critiques. Cette tche est gnralement effectue par
ladministrateur du SGBD, qui doit galement tenir jour les comptes dutilisateurs spci-
fiques du SGBD disposant de droits daccs la machine.
En rsum, le systme sur lequel est hberge la base de donnes doit faire lobjet dun
suivi permanent tous les niveaux. Il nest pas raisonnable dinstaller un SGBD sur une
machine dont le systme ne peut tre mis jour ou dont les mises jour sont disponibles
trop tardivement. Toute application prsente sur la machine peut recler des failles et tre
le maillon faible de lensemble. Les informations de vulnrabilit et les correctifs sont
fournis par les diteurs de ces applications. Dans notre cas, on doit porter une attention
particulire une application importante : le SGBD. La ractivit des diteurs constitue un
critre dcisif pour choisir un systme et un SGBD. Dun point de vue humain, la qualit
de ladministration du systme et du rseau sur lequel se trouve la machine peut tre ga-
lement un lment du choix.
redondance
charge.
Hbergement 3 Hbergement 2
Hbergement 3
Les instructions qui permettent daffecter les droits sont dfinies dans la norme SQL.
Comme pour les autres lments de la norme, les diteurs ne les ont pas toujours intgres
totalement dans leurs produits. linverse, ils ont souvent ajout des instructions qui ne
figurent pas dans la norme pour grer ces droits. Classiquement, pour protger une res-
source, on commence par en interdire laccs tous. Puis on dcrit ceux qui sont autoriss
lutiliser (utilisateurs). On associe ensuite chaque utilisateur un identifiant (mot de
passe) pour viter les emprunts didentit.
Dans le principe, SQL ne considre pas rellement la notion dutilisateur pour le SGBD tel
quon le conoit au sens dun systme dexploitation. On peut envisager lutilisation de
plusieurs identifiants associs au mme nom : cela correspondrait grossirement la pos-
sibilit dutiliser des mots de passe spcifiques selon la ressource. Il sagit donc dune logi-
que diffrente de celle qui consiste associer strictement un mot de passe un compte
et lui procurer des droits sur les ressources. La norme SQL considre que cest lobjet
Remarque
En pratique, la plupart des SGBD intgrent une instruction pour crer un utilisateur et lui
associer un identifiant qui reste unique. Mme si elle nest pas dfinie rellement dans la
norme SQL, elle est frquemment de la forme :
CREATE USER <type de droit> IDENTIFIED BY <identifiant> ;
Cette instruction met jour le dictionnaire de donnes du SGBD. Ce dernier utilise les infor-
mations de lutilisateur pour authentifier la connexion au SGBD. L encore, le mode de con-
nexion dpend du SGBD utilis. Par extension, celui-ci fournira en gnral une instruction du
type DROP USER pour dtruire lutilisateur cr par la prcdente commande.
Comme les informations du dictionnaire de donnes sont le plus souvent stockes dans des
bases de donnes, on peut galement les manipuler avec des instructions SQL classiques de
types INSERT et DELETE. La spcificit de linstruction CREATE USER est de possder une ins-
truction de cryptage du mot de passe.
Compte tenu de la remarque prcdente, les diteurs intgrent souvent la notion plus clas-
sique dutilisateur dans un SGBD. Ce dernier permet en gnral de distribuer des autori-
sations un ensemble dutilisateurs qui constituent ainsi un groupe. Les tches de gestion
en sont facilites, mais les groupes, qui reprsentent lorganisation de lentreprise, sont
parfois complexes grer. Laffectation de droits une hirarchie de groupes et sous-grou-
pes peut relever du casse-tte.
Afin de rsoudre ce problme, on dispose dun autre modle de distribution des droits : le
rle. Celui-ci dsigne un assortiment de droits que lon dsire affecter un objet du
SGBD. Cest une vue inverse o les utilisateurs prennent le(s) rle(s) dont ils ont besoin
pour pouvoir travailler sur les objets du SGBD qui les concernent. Linstruction pour crer
un rle est la suivante :
CREATE ROLE consultation_seulement ;
Laffectation des droits un rle et la distribution de rles des utilisateurs sont prsentes
la section suivante. La gestion des rles, mme sils font partie de la norme SQL, nest pas
propose par tous les SGBD. Il en est de mme pour les groupes dutilisateurs ou tout sim-
plement de la notion dutilisateur qui nexiste pas toujours dans le SGBD.
En rsum, il ny a pas de rgle gnrale de gestion des autorisations de connexion au
SGBD. Linitiative en est laisse lditeur du SGBD. Cet aspect peut provoquer des soucis
lors de la migration vers un autre SGBD.
Une fois que lutilisateur est connect au systme, il convient de grer son accs aux don-
nes. Une pratique courante pour les SGBD est que tout nouvel objet cr une base de
donnes par exemple est par dfaut inaccessible tous. Les droits sont distribus ensuite
des utilisateurs, des groupes ou des rles. Il existe ensuite une hirarchie entre les diff-
rents objets du SGBD : une table est comprise dans une base de donnes ; un champ est
compris dans une table, etc. Afin de simplifier la gestion, la plupart des SGBD permettent
laffectation de droits un objet associ tous les sous-objets qui constituent une branche
de la hirarchie.
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
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.
FROM nhop ;
Remarque
Seul lutilisateur qui lui a donn ces droits peut les lui retirer. Dans notre cas, la commande prc-
dente doit tre lance par lutilisateur pastorius.
Les droits donns par plusieurs utilisateurs sont cumulatifs. Cela signifie que tous les
droits accords doivent tre retirs pour quun utilisateur ne puisse plus effectuer les op-
rations. Ce graphe de permissions nest pas toujours simple grer et devient rapide-
ment de taille exponentielle. Par consquent, les administrateurs des SGBD ont tendance
accorder parcimonieusement les possibilits de redistribuer des droits.
Pour aider ladministrateur, un bon SGBD procure une option de linstruction de destruc-
tion dun utilisateur, capable de dtruire galement tous les objets quil a crs. Linstruc-
tion DROP USER, non normalise par SQL comme on la vu prcdemment, sutilise avec
loption CASCADE pour dtruire les tables, les vues et autres que lutilisateur a crs.
La gestion des droits dans le SGBD, prsents la section prcdente, peut constituer un
vritable casse-tte lorsque le nombre dutilisateurs et dobjets augmente. En effet, les
droits sur les tables et surtout sur les champs peuvent tre dfinis par linstruction
GRANT, mais il devient vite fastidieux et particulirement difficile de les modifier. Un des
aspects de cette difficult est le manque de lisibilit de lensemble des permissions.
La notion de rle permet de factoriser , ou rassembler, un ensemble de droits sur un ou
plusieurs objets. Une approche complmentaire consiste dfinir plus finement les objets
sur lesquels on affecte les droits en se servant simplement des vues SQL. Celles-ci permet-
tent de cacher certaines donnes laide de critres de slection prcis, ce qui est
impossible raliser dune autre manire. De plus, les vues permettent de masquer aux
utilisateurs la complexit de la structure des donnes, leur fournissant ainsi une interface
plus commode avec la base de donnes.
Le mcanisme de cration des vues a t abord rapidement au chapitre 4. Les donnes ne
sont pas stockes et sont recalcules chaque utilisation de la vue. Une vue est le rsultat
dune instruction SQL SELECT : les possibilits de dfinition sont donc trs tendues
puisquil sagit du cur mme du fonctionnement de SQL. Enfin, il est galement possible
de mettre jour les donnes contenues dans les vues sous certaines conditions. Les per-
missions sur les vues sont ensuite accordes par les instructions de type GRANT utilises
prcdemment. Voici quelques exemples de vues qui recourent la base de donnes exem-
ple casse.
Lutilisation des vues permet de dfinir des objets dynamiques puisquune vue est le rsul-
tat dune requte et nest jamais stocke. Les vues sutilisent en complment du systme
gnral de droits prsent la section prcdente. Il sagit de la bonne solution pour viter
la complexit de description des permissions sur la totalit des champs. Comme pour le
reste de la norme SQL, tous les SGBD ne proposent pas les vues.
3 Transactions
Cette section prsente plusieurs outils procurs par les SGBD pour protger les oprations
effectues sur les donnes. Les incidents lis aux donnes dans un SGBD proviennent
essentiellement de laccs concurrent ces dernires par plusieurs utilisateurs. Ces pro-
blmes sont habituellement rsolus par les mcanismes associs aux transactions prsen-
tes dans cette section. Celles-ci permettent galement de rsoudre les pertes dues aux
La section prcdente aborde la dfinition des accs et des permissions sur les diffrents
objets grs par le SGBD. Implicitement, cela signifie que plusieurs utilisateurs ou applica-
tions peuvent accder aux donnes en mme temps. De surcrot, la plupart des machines
sont connectes un rseau, ce qui augmente encore le nombre potentiel dutilisateurs
simultans.
Lecture(s) trange(s)
Laccs multiple en lecture ne pose pas habituellement de problmes, mais que se passe-t-
il lorsquun ou plusieurs utilisateurs dcident de modifier les mmes donnes au mme
moment ? On considre la squence dinstructions suivante applique la base de don-
nes casse . On suppose que tous les utilisateurs disposent de tous les droits sur tous les
objets (tables et champs) de cette base de donnes :
Lutilisateur pastorius consulte la liste des voitures non vendues.
Lutilisateur nhop enregistre la vente dune voiture.
Lutilisateur pastorius relance la mme requte et trouve un rsultat diffrent.
Lutilisateur nhop invalide la vente de cette voiture.
Lutilisateur pastorius pensant stre tromp relance la mme requte qui aboutit au
rsultat initial.
Pour trois excutions de la mme requte, lutilisateur pastorius va obtenir des rsultats
diffrents. On peut considrer la mme squence excute dans un ordre diffrent.
Lutilisateur pastorius consulte la liste des voitures non vendues.
Lutilisateur pastorius relance la requte et trouve le mme rsultat.
Lutilisateur nhop enregistre la vente dune voiture.
Lutilisateur nhop invalide la vente de cette voiture.
Lutilisateur pastorius relance la requte prcdente et retrouve le mme rsultat.
Comment dcider de lordre dans lequel excuter les instructions ? En pratique, le SGBD
ne dispose pas dlments de comparaison qui lui permettraient dordonner la srie dins-
tructions afin que cela passe inaperu comme dans la deuxime srie. On pourrait utiliser
ici le terme de lecture fantme pour qualifier les problmes rencontrs : une donne
apparat puis disparat.
Incohrence de rsultats
On peut imaginer une autre srie dinstructions qui ralisent des modifications de don-
nes effectues par diffrents utilisateurs. En raison de laugmentation des frais de struc-
ture, le service comptable a dcid dune augmentation gnrale du prix de vente de 5 %.
Afin que cette dernire passe inaperue et dans le cadre dune campagne de communica-
tion, le service marketing offre 100 euros de ristourne sur tout le catalogue pendant un
mois. Lutilisateur pastorius appartient au service comptable et lutilisateur nhop au ser-
vice marketing. Les vrifications sont effectues par lutilisateur miller de la direction
(voir figure 6.2).
Lutilisateur pastorius consulte le prix de vente de la voiture X.
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 con-
current aux donnes. On peut citer le cas des anomalies de lecture : Deux lectures suc-
cessives ne donnent pas le mme rsultat. Cela survient lorsque la modification dune
donne est effectue par un processus concurrent entre deux lectures successives. Le
SGBD traite naturellement les requtes de manire squentielle, dans lordre de leur arri-
ve. Si lon augmente le nombre dutilisateurs, ce type de problmes peut videmment se
multiplier.
Verrous
On a donc besoin de disposer dun mcanisme qui garantisse une certaine exclusivit
sur les donnes lors des oprations de mise jour. Un tel mcanisme existe depuis long-
temps en informatique pour rsoudre ce problme : il sagit des verrous. Lide est simple :
on bloque une ressource pour effectuer les oprations et on la libre ds que les oprations
sont effectues. Cette mthode semble rsoudre le problme ; elle prsente cependant
quelques piges et doit tre utilise avec prudence. En effet, on peut rapidement parvenir
une situation de blocage que lon nomme treinte fatale (deadlock en anglais) ou parfois
Lutilisateur pastorius veut insrer une vente de voiture dans la table vente et cons-
tate cette occasion une erreur sur la couleur dans la table voiture quil veut modifier.
Lutilisateur miller veut insrer la fois une nouvelle voiture dans la table voiture et
la mention de sa vente dans la table vente.
La squence dinstruction peut tre la suivante :
Lutilisateur pastorius pose un verrou sur la table vente.
Lutilisateur miller pose un verrou sur la table voiture.
Lutilisateur pastorius a termin la mise jour de vente et veut raliser celle de voi-
ture mais la table voiture est verrouille par miller.
Lutilisateur miller a termin la mise jour de voiture et veut procder celle de
vente mais la table vente est verrouille par pastorius.
On parvient une situation o les deux utilisateurs attendent que lautre libre la res-
source pour continuer. videmment, cest une attente infinie qui se profile pour chacun.
Dautres phnomnes de blocage peuvent survenir dans lutilisation des verrous. On parle
parfois dans ce cas de famine. Voici un exemple illustrant cette possibilit.
Lutilisation classique des verrous pour protger laccs une ressource est la suivante
(algorithme des lecteurs-rdacteurs ) :
Tous les lecteurs peuvent lire en mme temps.
Si un rdacteur veut crire, aucun lecteur ne doit plus utiliser la donne.
Si un rdacteur est en train dcrire, aucun lecteur ne peut lire la donne et aucun autre
rdacteur ne peut y accder (accs exclusif).
Sil existe un grand nombre de lecteurs qui se succdent en lecture sur la donne, lattente
pour un rdacteur qui voudrait la modifier peut alors devenir quasi infinie.
Laisser la gestion des verrous un utilisateur est donc dlicat et peut conduire des bloca-
ges du systme. Les SGBD performants disposent doutils capables de dtecter et rsoudre
ces phnomnes, voire de les prvenir le cas chant. Les algorithmes utiliss cet effet
dpassent le cadre de cet ouvrage.
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.
Remarque
Les transactions permettent de rsoudre les problmes lis aux accs concurrentiels, mais gale-
ment de traiter le cas de la reprise en cas de panne. Le SGBD est ainsi capable de remettre la
base de donnes dans ltat cohrent o elle se trouvait avant le dbut de la transaction qui a
chou pour cause de panne. Les transactions sont galement employes pour annuler des
erreurs de traitement ventuelles. En effet, grce ce mcanisme, on peut revenir ltat initial
dans lequel se trouvait la base de donnes avant le dbut de la srie de mauvaise(s) manipula-
tion(s) sur la base de donnes. Il sagit certainement de lutilisation principale des transactions.
Remarque
Les SGBD ne fonctionnent pas par dfaut au mme niveau disolation. Il est prudent de vrifier
dans la documentation quel niveau se trouve par dfaut le SGBD que lon utilise. En effet, cer-
tains SGBD trs rpandus fonctionnent par dfaut au niveau 1 ! Ce peut tre suffisant pour certai-
nes applications, encore faut-il en tre bien conscient. Le choix du niveau est motiv par des
arguments plus commerciaux que techniques : le SGBD est plus rapide en utilisant un niveau
moins lev.
Point de retour
dans une INSERT INTO client VALUES (8,'Annabelle',29,'Paris','F');
transaction.
SAVEPOINT UN
ROLLBACK TO UN ;
ROLLBACK
Le mcanisme des points de retour est trs utile pour prvenir les cas de mauvaise mani-
pulation de donnes. On combine ainsi la possibilit deffectuer les modifications dans
une seule transaction avec celle de ne pas annuler toutes les modifications. Certaines
dentre elles prennent en effet un temps considrable.
Remarque
La plupart des SGBD considrent que chaque instruction SQL est en soi une transaction qui est
automatiquement valide (mode AUTO COMMIT). Certains fonctionnent en crant une nouvelle
transaction lors de chaque connexion au SGBD, ce qui permet dannuler le cas chant toutes les
oprations effectues depuis la connexion. Dans le doute, il est donc prfrable de spcifier expli-
citement le dbut de toute transaction par une instruction START TRANSACTION.
appel des compromis entre la rapidit et la scurit. Tous les SGBD neffectuent pas les
mmes choix et prsentent des degrs diffrents de fiabilit. Les cas dinterblocage peuvent
tre frquents dans certains SGBD pourtant trs utiliss. Dautres, galement fort rpan-
dus, ne proposent mme pas les transactions sur leurs tables en standard .
4 Triggers
Les triggers ou dclencheurs ont un objectif diffrent des outils tels que les transactions.
Ils servent excuter des contrles complmentaires personnaliss au moment des opra-
tions dajout, de suppression et mise jour des donnes. Ils sont utiles galement pour
effectuer un formatage spcifique des donnes. Pratiquement, un trigger est un ensemble
dinstructions SQL, dfinies par lutilisateur, qui seront dclenches lors dune action
dajout, de suppression ou de mise jour de donnes. Il sapplique donc un objet de type
table. On peut choisir dexcuter un trigger avant ou aprs une instruction de mise jour.
Les donnes manipules par le trigger sont stockes dans des tables temporaires que lon
dsigne dans le code du trigger par les termes :
NEW valeurs, aprs lexcution de lopration de mise jour ;
OLD valeurs, avant lexcution de lopration de mise jour.
Comme toujours, la syntaxe peut tre lgrement diffrente suivant le SGBD employ.
ration ou la perte des donnes. On a prsent tout dabord les prcautions de premier
niveau quil ne faut pas ngliger. Elles concernent essentiellement lenvironnement dans
lequel se trouve le SGBD : la machine munie de son systme dexploitation, les locaux
informatiques et enfin le rseau sur lequel elle est connecte. Un autre point important
concerne la sauvegarde et la duplication des donnes, de faon garantir laccessibilit
ces dernires mme en cas de sinistre.
Une fois lenvironnement du SGBD scuris, on a abord les permissions et les restrictions
qui sont gres directement par le SGBD. Il sagit de la partie prise en charge par ladmi-
nistrateur du SGBD qui dfinit les droits sur les diffrents objets de la base de donnes.
Cette gestion devient rapidement complexe : on utilise en complment les vues SQL pour
dcrire plus finement les objets sur lesquels on distribue les droits.
Les prcautions prcdentes mises en uvre, on se trouve confront au problme de
laccs concurrent aux donnes. La solution consiste en lutilisation de verrous. Leur
mcanisme est trs dlicat grer et lon prfre laisser ce soin au SGBD. Ce dernier pro-
cure de surcrot un mcanisme de journalisation des instructions capable de remettre
la base de donnes dans ltat cohrent prcdant la squence dinstructions. Cette combi-
naison des mcanismes daccs exclusif associs la journalisation se nomme les transac-
tions. Enfin, les triggers (ou dclencheurs en franais) sont trs utiles pour complter la
panoplie doutils qui assurent le contrle des donnes dune base de donnes.
Quelles sont les vrifications de base indispensables avant de faire hberger un SGBD ser-
veur de bases de donnes par une structure ?
La dcision doit reposer sur la prise en considration de plusieurs points ; la liste ci-des-
sous nest pas exhaustive.
Aspects techniques. Lune des premires proccupations doit tre dauditer le type de
machine ainsi que le systme dexploitation sur lequel sera hberg le SGBD. Dautre part,
les SGBD sont gourmands en ressources de calcul et de stockage et il faut donc sassurer
que lon disposera du ncessaire dans ces domaines.
On peut supposer que la machine sera connecte un rseau quil faut auditer galement.
De quel type de connexion dispose lhbergeur, quels matriels de protection contre les
intrusions utilise-t-il ? Le minimum est de disposer dun dispositif de filtrage pour se pro-
tger des intrusions lies au rseau. Un plus est de disposer de deux fournisseurs daccs,
lun prenant le relais en cas de faille de lautre.
Enfin, quel matriel de sauvegarde peut-on utiliser, et de quelle taille de stockage dispose-
t-on ? Une sauvegarde quotidienne est indispensable pour une base de donnes standard,
cest--dire sur laquelle les mises jours sont raisonnablement frquentes. En cas de mises
jour intensives, on peut prvoir de conserver plusieurs versions de la base sauvegarde.
Aspects humains. Les machines et les rseaux aussi performants soient-ils sont grs
avant tout par des tres humains. Il est donc essentiel de savoir combien de personnes
assurent cette mission, et de quelle faon ; didentifier la politique de scurit gnrale :
accs physique aux machines, protection contre les intrusions rseau et le suivi des inci-
dents, mise jour des machines, gestion des comptes
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 perma-
nence, on doit effectuer des copies intervalles rguliers des donnes qui proviennent
dune base de donnes primaire vers des bases de sauvegarde secondaires . En cas de
panne du primaire, on peut basculer rapidement vers lun des secondaires. Lidal est de
disposer de plusieurs secondaires dans des lieux gographiquement loigns, situs sur des
rseaux (informatiques) diffrents.
Disposer en outre dun accs performant suppose que lon utilise galement les secondai-
res pour faire de la rpartition de charge. Le systme de rpartition choisi doit tenir
rseau. Il existe des outils capables de tenir jour en permanence ce genre dinformations,
mais ils sont assez complexes grer. Lors du choix de la machine vers laquelle on va redi-
riger la demande, on doit prendre en considration galement sa charge et donc son apti-
tude rpondre rapidement.
Les inconvnients dune solution complte de ce type sont vidents. Les applications de
rpartition de charge sur un rseau standard sont dj complexes grer ; on imagine bien
quelles le sont dautant plus lorsque lon passe une chelle suprieure. Un autre incon-
vnient est la difficult de maintenir des copies des donnes jour par rapport la base
primaire. Si les mises jour sont trs frquentes, il devient difficile de disposer des mmes
donnes sur tous les secondaires.
Une autre solution plus facile grer pour rpartir naturellement la charge entre les
serveurs consiste rpartir les donnes entre ces serveurs. Ainsi, cette opration se fait par
larchitecture mme de la base de donnes qui est dite rpartie . En revanche, cette solu-
tion ne rsout pas le problme de la recopie des donnes. Si lun des serveurs tombe en
panne, il nexiste pas, contrairement au systme prcdent, de mcanisme automatique
pour le remplacer. On peut envisager des variantes qui panachent les deux systmes : par
exemple, on peut mettre en place un serveur matre qui recopie une partie des donnes sur
les secondaires. Cette problmatique gnrale est illustre par les grands moteurs de
recherche, ou encore les serveurs de vido qui utilisent plusieurs milliers de serveurs
rpartis sur le rseau Internet.
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.
Enfin, les gestionnaires de lactivit doivent pouvoir mettre jour toutes les informa-
tions de gestion : en particulier, celles sur les pizzas, les clients, les livreurs et les voitures
utilises. En revanche, on peut considrer quils nont pas besoin de modifier les infor-
mations concernant les commandes, mais quils doivent pouvoir y accder en lecture.
Si le SGBD le supporte, la solution la plus lgante est dutiliser les rles. On cre un rle
par catgorie et on lui affecte les permissions. Il suffira ensuite de donner ce rle aux utili-
sateurs ou aux applications concernes. Dans cet exemple, on a surtout cherch mettre
en vidence tous les droits distribuer. Il existe des notations plus concises.
EXERCICE 5 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 nom-
bre de commandes livres par chacun deux.
Le service du personnel effectue un suivi des livreurs : il a besoin de connatre le
nombre de retards de chacun, mais galement le nombre de commandes livres.
Un laboratoire de recherche en sociologie effectue des tudes sur la clientle, spci-
fiquement sur la relation entre les ingrdients des pizzas achetes et ladresse des
clients.
Ces utilisateurs ne doivent accder quaux champs dont ils ont strictement besoin.
On remarque que les informations dont ces utilisateurs ont besoin ne sont pas directe-
ment disponibles dans une table ni mme dans un champ particulier. Il sagit de rsultats
de calculs sur lensemble de la base de donnes. Le moyen le plus simple pour grer ces
Exercices
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.
On se trouve dans les cas typiques dutilisation de vues pour dfinir des objets qui nexis-
tent pas ltat naturel dans la base de donnes. La distribution des droits en est
dautant simplifie. De plus, lensemble est volutif ; on peut sans difficults ajouter un
champ dans ces vues sans avoir besoin de changer lensemble des droits sur les tables, les
champs, etc.
EXERCICE 6 TRANSACTIONS
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 ;
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 .
et bases de donnes
Du code Morse au code ASCII : un rapide
historique du codage des caractres
Historiquement, la transmission dinformation distance se faisait de manire visuelle. La
marine transmettait des messages entre les bateaux par des fanions qui reprsentaient
chacun une lettre de lalphabet. Le tlgraphe de Chappe reposait sur le mme principe :
une position des bras figurait une lettre. Il disposait en outre dun mcanisme de cryptage
ainsi que de codes spciaux qui accompagnaient le message (par exemple, urgent , en
attente , etc.). Avec linvention de llectricit est arriv le tlgraphe lectrique qui utili-
sait un fil par lettre de lalphabet (donc, 26 en tout).
Samuel Morse invente en 1840 un codage qui passe un seul fil pour la transmission. Il
sagit du premier codage moderne international qui inclut les chiffres, les lettres et cer-
tains caractres accentus. Il possde galement des caractres de contrle utiliss pour la
transmission du message (par exemple, rptez ). Ce codage universel permet de trans-
mettre des informations en utilisant une source lumineuse, sonore ou lectrique.
Le tlex apparat vers 1920 ; il se sert dun codage sur 5 positions invent par le Franais
Baudot. Les messages envoys par tlex sont dabord saisis sur un ruban perfor et lenvoi
ainsi que la rception sont automatiss. Cest le mme type de code qui a servi stocker de
linformation sur les cartes perfores 80 colonnes. Ces dernires reprsentent le premier
stockage dinformation avec un code qui prfigure ce qui est utilis actuellement. Le
codage 5 positions permet 32 possibilits (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 con-
trle, on trouve un code pour ramener le chariot de limprimante en dbut de ligne (CR,
Carriage Return) et un caractre pour passer la ligne suivante (LF, Line Feed).
Les annes 1940 voient apparatre les ordinateurs qui recourent au dpart aux cartes per-
fores puis dautres systmes de stockage. Chaque constructeur dfinit son systme de
codage ; il arrive parfois que plusieurs systmes cohabitent chez le mme constructeur.
IBM dfinit le codage BCD qui servira de base EBCDIC plus tard et utilise 6 positions.
Dans les annes 1960, les constructeurs se sont regroups pour dfinir une norme com-
mune qui sera publie au final par lorganisme de normalisation ASS (American Standard
Association) sous le nom de code ASCII (American Standard Code for Information Inter-
change). Le code ASCII possde 7 positions, ce qui permet de stocker 128 (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 minus-
cules, les chiffres et des caractres divers (? @ $ , etc.). De nombreuses variantes nationales
existent en particulier pour le signe montaire qui diffre suivant les pays ( $ , pour les
USA, , pour la Grande-Bretagne, etc.). En dpit de ces spcificits, lusage du codage
Remarque
Un point, qui peut se rvler pnible lusage, concerne les caractres de fin de ligne. On a
vu que le codage, hrit du temps o lon utilisait des machines mcaniques pour transmet-
tre les caractres, propose deux caractres distincts pour changer de ligne : le retour chariot
(CR) et le passage la ligne (LF).
Il nest plus techniquement utile aujourdhui de spcifier ces deux caractres pour indiquer
une fin de ligne. Cependant, la plupart des protocoles rseaux (par exemple HTTP) ainsi que
le monde DOS/Windows ont conserv la combinaison CR-LF pour passer la ligne. Les
familles UNIX utilisent le seul caractre LF et Apple le caractre CR. Il est donc ncessaire
deffectuer des transformations pour passer dun type de fichier lautre.
Aujourdhui, on envoie des mails et lon schange des fichiers dun bout lautre du monde
et lon aimerait pouvoir les exprimer avec les caractres corrects. Le franais scrit avec des
caractres diacritiques : la lecture dun texte sans accents est dsagrable et peut mme nuire
la comprhension. La section prcdente donne une ide de la confusion qui rgne pour le
codage des caractres malgr les efforts de normalisation. De plus, on ne peut deviner
(cest--dire dtecter automatiquement) en ouvrant un fichier sil est cod en ISO-8859-l ou
en MacRoman et il est impossible dutiliser des tables de langues diffrentes au sein dun
mme fichier. Pour rsoudre ces problmes, un groupement de constructeurs et dditeurs
de logiciels (Adobe, Xerox, Apple, IBM, MicroSoft, etc.) ont fond le consortium Unicode
au dbut des annes 1990. Unicode est un standard dfini par un consortium priv, mais
aprs quelques errements la norme ISO-10646 a repris lensemble du standard.
Lide est de disposer dun systme de codage de tous les caractres du monde ou plus
exactement de pouvoir coder la reprsentation de ces caractres. Unicode spare la notion
de caractre de sa reprsentation que lon appelle un glyphe . Ainsi, les notions
daspect, de police ou de taille du caractre nexistent pas dans le codage Unicode ; ces
informations sont reportes au niveau de lapplication. Le standard fournit tout de mme
un exemple de reprsentation (glyphe) du caractre titre informatif. En revanche, on
inclut des informations complmentaires, comme la direction dans laquelle il faut lire les
caractres ou des proprits alphabtiques qui seront importantes pour les bases de don-
nes. En ce qui concerne plus particulirement les caractres diacritiques, la rgle gnrale
est de donner la possibilit de construire le caractre plutt que de le stocker : un
sera construit en utilisant le code e combin au code ` . Cependant, pour des raisons
pratiques de compatibilit, Unicode a repris intgralement les codages existants tels que
ISO-8859-1 : dans ce cas, on stocke galement le caractre .
La plupart des langues vivantes peuvent scrire dsormais avec Unicode (plus ou moins 100
000 caractres sont actuellement dfinis), mme si certains choix ont fait lobjet de fortes cri-
tiques. Les symboles mathmatiques, musicaux ou autres font galement partie du code. Le
processus se poursuit avec les langues mortes, comme le codage des hiroglyphes gyptiens.
Techniquement, Unicode utilise un codage sur 21 positions. Le codage est divis en 17
tables de 65 536 (216) caractres que lon appelle des plans. Lun des intrts de ce dcou-
page est que par exemple le premier plan suffit coder la plupart des langues vivantes. De
surcrot, le tout dbut de ce premier plan reprend exactement la norme ISO-8851-1. De
cette manire, on nest pas oblig dutiliser la place des 21 positions pour coder les carac-
tres Unicode. Il suffit de trouver un codage astucieux qui indique que lon utilise le pre-
mier plan ou mme le dbut du premier plan, et alors 8 positions suffisent. Avec des
caractres plus exotiques , le codage utilise alors 16 positions et ainsi du suite. Cet
aspect offre beaucoup de souplesse et assure galement la compatibilit avec lexistant
ASCII et ISO-8859.
Les machines et les logiciels utilisent traditionnellement, et cest l lhritage des codages
prcdents, comme unit de base loctet qui contient 8 positions. Les diffrentes manires de
coder les caractres Unicode seront donc des multiples doctets. Essentiellement, on trouve :
UTF-8 : il sagit dun encodage gnial sur 8 bits concoct en une journe (une nuit ?)
par K. Thompson. Lide est que tout ce qui est en ASCII est cod sur un octet ; ce qui
est cod avec des diacritiques conformes la norme ISO-8859 est cod sur deux octets
et ainsi de suite. Cette manire de coder permet de conserver la compatibilit totale
avec le codage ASCII ainsi que de continuer utiliser les logiciels et matriels conus
lorigine pour lire des octets.
Figure A.1
Morse Autres plans
Les diffrents
Plan Multilingue Base
codages de
caractres.
Baudot (5 positions)
UNICODE -ISO-10646
(21 positions)
ISO-8859-15 (Latin9)
ISO-8859-7 (Grec)
ASCII (7 positions)
Windows-1251 (8 positions)
MacRoman (8 positions)
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.
Bibliographie 189
Base de donnes book Page 191 Lundi, 5 juin 2006 3:33 15
Index
Index 191
Base de donnes book Page 192 Lundi, 5 juin 2006 3:33 15
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
Synthse Cration
de cours
&
exercices
de bases
corrigs de donnes
Lauteur : Cet ouvrage propose une dmarche progressive ceux qui veulent concevoir
Nicolas Larrousse est ingnieur au un systme dinformation robuste et volutif en vitant les cueils classiques qui
CNRS. Spcialis en informatique,
il enseigne les bases de donnes conduisent rendre les donnes inutilisables. Toutes les tapes de la ralisation
luniversit de Versailles Saint-Quentin-
dune base de donnes, de lanalyse pralable au choix du codage des carac-
en-Yvelines et au service de formation
permanente de luniversit Pierre et tres, sont tudies et illustres par des exemples.
Marie Curie Jussieu.
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 confren- uvre du systme ainsi conu laide du langage SQL. Une tude de cas
ces en informatique luniversit de
Corse. Il est responsable pdago- rcapitulative permet ensuite dappliquer les notions prsentes dans les cha-
gique des filires SRC (Services et pitres prcdents. Le dernier chapitre traite de la scurisation des donnes,
Rseaux de Communication) et LPM
(Licence Professionnelle Multimdia). Il notament au moyen des transactions et des triggers.
enseigne lalgorithmique, la program- Les exercices, qui occupent la moiti du livre, sont intgralement corrigs afin
mation et les systmes dinformation.
que le lecteur mette progressivement en uvre ses connaissances. Par ailleurs,
Dans la mme collection : les donnes et les scripts SQL utiliss tant pour les exemples que pour les exerci-
Algorithmique, Applications en C,
ces sont disponibles ladresse www.pearsoneducation.fr.
Jean-Michel Lry Le livre sadresse aux tudiants de premier et de second cycles (IUT, BTS, univer-
Algorithmique en C++, Jean-Michel Lry
Algorithmique en Java 5,
sits et coles dingnieurs) qui dbutent lapprentissage des bases de donnes.
Jean-Michel Lry Il sera galement utile aux professionnels qui veulent mettre en place une base
Architecture de lordinateur,
Emmanuel Lazard de donnes, mme de taille modeste.
Java 5, Robert Chevallier
LateX, Jean-Cme Charpentier,
Denis Bitouz
Le langage C, Jean-Michel Lry
La collection Synthex informatique propose de (re)-dcouvrir les
Le langage C++, Marius Vasiliu
Linux, Jean-Michel Lry fondements thoriques et les applications pratiques des principales
Mathmatiques discrtes appliques disciplines de science informatique. partir dune synthse de cours
linformatique, Rod Haggarty rigoureuse et dexercices aux corrigs dtaills, le lecteur, tudiant
SQL, Frdric Brouard, Christian Soutou
ou professionnel, est conduit au cur de la discipline, et acquiert une
Systmes dexploitation, Bart Lamiroy,
Laurent Najman, Hugues Talbot comprhension rapide et un raisonnement solide.
Rseaux, Dominique Seret, Danile
Dromard
UML 2, Benot Charroux, Aomar
Osmani et Yann Thierry-Mieg