Uml Vers MLD

0e U|L SQL 1
Editions systmes et information

CONCEPTION & REALISATION

DES BASES DE DONNEES :

De UML SQL

Jacques Guyot
2 Modeliser et realiser une BD
0e U|L SQL J
Copyright 2002 Lditions systmes et information

Tous droits de traduction, dàdaptation et de reproduction par procede reserves pour tous les
pays

ISB : 2 -940105-12-x

aitiov. .,.teve. et ivforvatiov
P,a Citte. atqvet
2:, cbeviv ae ta catiforvie
Cb1222 1e.eva

Co,rigbt 200 aitiov. .,.teve. et ivforvatiov :

aitiov vtervet


0e U|L SQL 5

A Amelie, Mal, Noe, Alina et Thibault

0e U|L SQL 7
1able des matires

NDTATIDNS ............................................................................................................................ 15
1. INTPD0UCTIDN A LA hD0ELISATIDN ................................................................... 17
L'NFDF|ATDN AU CDUF L'ENTFEPFSE ................................................................................... 17
0U STFUCTUFE AU NDN STFUCTUFE .......................................................................................... 18
UNE 7SDN 0E L'E7DLUTDN 0E L'NFDF|ATQUE ....................................................................... 20
QUD, CD||ENT, QU : ........................................................................................................... 21
|D0ELE .................................................................................................................................. 23
PDUFQUD |D0ELSEF : ........................................................................................................... 24
U|L UN PEU 0'HSTDFE ........................................................................................................ 25
0EJA 0ES EXEFCCES ................................................................................................................ 26
2. DJETS ET CLASSES ................................................................................................. 29
C'EST QUD UN D8JET .............................................................................................................. 29
CLASSE ................................................................................................................................... 30
PDUFQUD LES D8JETS :........................................................................................................... 30
0ACFA||E 0E CLASSES EN U|L .............................................................................................. 31
0ACFA||E 0'D8JETS .............................................................................................................. 33
LENS ENTFE LES D8JETS .......................................................................................................... 33
ASSDCATDNS ......................................................................................................................... 34
CAF0NALTE 0ES ASSDCATDNS ................................................................................................ 35
Ccs 1..1, 1 ....................................................................................................................... 36
Ccs 0..1 ........................................................................................................................... 37
Ccs , 0.. ........................................................................................................................ 38
Ccs 1.. ............................................................................................................................ 38
ASSDCATDN 8NAFE, TEFNAFE, . ......................................................................................... 39
CLASSE 0'ASSDCATDN ............................................................................................................ 41
CDNTFANTES .......................................................................................................................... 43
ACFECATDN ET CD|PDSTDN .................................................................................................. 46
CENEFALSATDN ..................................................................................................................... 50
0]]rence entre ynrclscton et composton .................................................. 50
EXE|PLES 0E CENEFALSATDN .................................................................................................. 51
LA CENEFALSATDN EST CLASSFANTE ....................................................................................... 52
PFNCPE 0E SU8STTUTDN 0E LSKD7 ....................................................................................... 53
FACTDFSEF LE CD0E ............................................................................................................... 54
HEFTACE |ULTPLE ................................................................................................................ 55
CD7AFANCE ........................................................................................................................... 56
3. LES CAS 0'UTILISATIDN ........................................................................................... 59
D8JECTFS 0U |D0ELE ............................................................................................................. 59
PFDCESSUS 0E SPECFCATDN 0ES 8ESDNS ................................................................................ 60
PFDCESSUS 0E 0E7ELDPPE|ENT ................................................................................................ 61
STEFEDTYPES 0ES CAS 0'UTLSATDN ........................................................................................ 62
CAS CD|PAFES AUX CLASSES ..................................................................................................... 64
FECD||AN0ATDNS ................................................................................................................. 66
EXE|PLE : LE FESTAUFANT ....................................................................................................... 70
EXTENSDN PDUF LES PFDCESSUS .............................................................................................. 71
EN SA7DF PLUS SUF U|L ........................................................................................................ 72
LES ELE|ENTS 0'U|L ............................................................................................................... 73
U|L : UN SYSTE|E DU7EFT ..................................................................................................... 75
EXEFCCE ................................................................................................................................ 75
4. SDPTIP 0E LA CDNFUSIDN ...................................................................................... 77
EXEFCCES ............................................................................................................................... 77
Exercce sur RECETTE ................................................................................................... 77
Exercce sur TT
J
............................................................................................................ 77
Enonc de TT
J
................................................................................................................ 77
Correcton RECETTE ...................................................................................................... 79
Correcton TT
J
............................................................................................................... 80
5. ENCDPE UNE INTPD0UCTIDN ................................................................................. 81
0ES FCHEFS AUX FELATDNS .................................................................................................... 82
PFD8LE|ATQUE 0ES 8ASES 0E 0DNNEES .................................................................................... 85
SQL LANCACE 0ES 8ASES 0E 0DNNEES FELATDNNELLES ........................................................... 89
TFDS 0SCDUFS ...................................................................................................................... 90
6. ASE 0U hD0ELE PELATIDNNEL ........................................................................... 93
0D|ANES ............................................................................................................................... 93
CDNSTTUANTS ........................................................................................................................ 95
FAPPELS SUF LA LDCQUE 0ES PFDPDSTDNS ............................................................................. 96
FAPPELS SUF LA LDCQUE 0ES PFE0CATS ................................................................................... 97
ENSE|8LES, PFDPDSTDNS ET PFE0CATS .................................................................................. 99
FETDUF A LA 0EFNTDN 0E FELATDN .................................................................................... 100
EXEFCCES ............................................................................................................................. 104
Questons sur TT
J
........................................................................................................ 104
Rponses sur TT
J
......................................................................................................... 104
7. hD0ELISATIDN ET 0EFINITIDN 0ES 0DNNEES ................................................. 107
0ACFA||ES SYNTAXQUES ..................................................................................................... 107
LANCACE 0E 0ESCFPTDN 0E |D0ELSATDN ............................................................................ 107
LANCACE 0E 0ESCFPTDN 0ES 0DNNEES (SQL)........................................................................ 111
EXEFCCES ............................................................................................................................. 114
8. 0ES CLASSES AUX PELATIDNS .............................................................................. 115
CHAQUE CLASSE 0E7ENT UNE FELATDN .................................................................................. 115
QUE FAFE A7EC LES |THD0ES : ............................................................................................ 116
Mmorser les cttrbuts cclculs .............................................................................. 116
0tlser des vues .......................................................................................................... 117
0tlser les mthodes de mse c ]our ...................................................................... 117
TFA0UFE LES ASSDCATDNS ................................................................................................... 118
0n des mcxmum est ycl c un ................................................................................. 118
Les deux mcxmum sont plus yrcnd que un ........................................................... 120
ASSDCATDN ATTF8UEE ........................................................................................................ 122
ACFCATDN ET CD|PDSTDN ................................................................................................ 123
CNFALSATDN ................................................................................................................... 124
0e U|L SQL 9
Tout dcns un ................................................................................................................. 124
Chccun c sc plcce ........................................................................................................ 125
EXEFCCES ............................................................................................................................. 128
Questons sur TT
J
........................................................................................................ 128
Rponses sur TT
J
......................................................................................................... 129
. ALCEPE PELATIDNNELLE .................................................................................... 134
DPEFATDNS ALCE8FQUES ..................................................................................................... 134
Lunon ........................................................................................................................... 135
Lc d]]rence ................................................................................................................ 135
Lc pro]ecton ................................................................................................................ 136
Le produt ..................................................................................................................... 137
Lc slecton .................................................................................................................. 138
JDNTUFES ............................................................................................................................ 138
Lc ]onture (lc thtc]onture) ............................................................................. 139
\crctons sur lc ]onture .......................................................................................... 139
Equ]onture ................................................................................................................ 140
1onture ncturelle ....................................................................................................... 140
Sem]onture ............................................................................................................... 140
1onture externe ......................................................................................................... 141
EXPFESSDN ALCE8FQUE ........................................................................................................ 141
LANCACE ALCE8FQUE, UN LANCACE 0'NTEFFDCATDN ............................................................ 142
EXEFCCES ............................................................................................................................. 146
Questons sur TT
J
........................................................................................................ 146
Rponses sur TT
J
......................................................................................................... 146
10. INTEPPDCATIDN EN SL ....................................................................................... 148
0U LANCACE ALCE8FQUE A SQL ............................................................................................ 148
SYNTAXE 0ES FEQUETES SQL .................................................................................................. 152
Lc pro]ecton ................................................................................................................ 154
Expresson ..................................................................................................................... 155
Les relctons du produt ccrtsen ........................................................................... 156
Condton ...................................................................................................................... 157
Sousrequtes ............................................................................................................... 163
Reyroupements ............................................................................................................ 165
Ensembles ..................................................................................................................... 167
Arborescences .............................................................................................................. 167
Trer ............................................................................................................................... 169
|D0ELE 0E LA |ACHNE SQL .................................................................................................. 170
EXPFESSDN CFAPHQUE 0'UNE FEQUETE ................................................................................. 171
EXEFCCES ............................................................................................................................. 172
Questons sur TT
J
........................................................................................................ 172
Rponses sur TT
J
......................................................................................................... 175
11. hD0IFICATIDN 0ES 0DNNEES .............................................................................. 181
PF|T7ES 0E |D0FCATDN .................................................................................................. 185
Crcton ........................................................................................................................ 185
Suppresson ................................................................................................................... 186
Mse c ]our .................................................................................................................... 187
TFANSACTDN ........................................................................................................................ 187
LANCACE 0E |ANPULATDN 0E 0DNNEES EN SQL ..................................................................... 189
NTEFFACES UTLSATEUFS ...................................................................................................... 193
EXEFCCES ............................................................................................................................. 194
Questons sur TT
J
........................................................................................................ 194
Rponses sur TT
J
......................................................................................................... 194
12. LES PECLES 0'INTECPITE ..................................................................................... 195
0EFNTDNS ET PFDPFETES ................................................................................................... 196
LA CDNSSTANCE 0'UNE TFANSACTDN ...................................................................................... 197
PDFTEE 0E LA FECLE 0'NTECFTE ........................................................................................... 198
7.4. LES FECLES 0'NTECFTE EN SQL................................................................................. 203
EXEFCCE .................................................................................. ERREUR ! SIGNET NON DEFINI.
Questons sur TT
J
.................................................................. Erreur ! Signet non dfini.
Rponses sur TTJ ................................................................... Erreur ! Signet non dfini.
13. 0EPEN0ANCES FDNCTIDNNELLES ....................................................................... 211
FEF|ETUFE ET CDNSEQUENCE LDCQUE 0E F ........................................................................... 213
UN SYSTE|E 0E 0E0UCTDN .................................................................................................... 214
\cldt du systme de dducton ............................................................................ 215
Extenson du systme de dducton ........................................................................ 216
Forme ccnonque de F et scturcton de X .............................................................. 217
Compltude du systme de dducton .................................................................... 218
Equvclence, couverture et rredondcnce de F ..................................................... 219
ALCDFTH|E LE AU 0F .......................................................................................................... 221
Tester lquvclence de F et 6 scns cclculer les ]ermetures .............................. 221
Cclculer lc bcse complte de F ................................................................................ 222
Cclculer une bcse rredondcnte de F ...................................................................... 223
EXEFCCES ............................................................................................................................. 223
Questons sur TT
J
........................................................................................................ 223
Rponses sur TT
J
......................................................................................................... 224
14. CLES ........................................................................................................................... 227
ALCDFTH|E 0E FECHEFCHE 0E CLES ....................................................................................... 228
ATTF8UTS PUTS ET SDUFCE .................................................................................................. 229
Proposton: sur les cls, puts et sources .............................................................. 229
0nct de lc cl dcns les yrcphes de d] ccyclques ............................................. 230
Heurstques pour lc recherche des cls ................................................................. 231
0ECD|PDSTDN 0'UNE FELATDN ............................................................................................ 233
EXEFCCES ............................................................................................................................. 233
Questons sur les cls ................................................................................................. 233
Questons sur TT
J
........................................................................................................ 234
Rponses sur les cls .................................................................................................. 235
Rponses sur TT
J
......................................................................................................... 235
15. 0ECDhPDSITIDN 0'UNE PELATIDN ..................................................................... 237
CDNSEF7ATDN 0E L'NFDF|ATDN .......................................................................................... 238
0e U|L SQL 11
Proprt de lc dcomposton ................................................................................. 239
0ECD|PDSTDN TDTALE ........................................................................................................ 240
Tester s une dcomposton est totcle .................................................................. 240
PFESEF7ATDN 0ES 0F ............................................................................................................ 244
Tester lc prservcton des d] ................................................................................... 245
lncluson des d] dcns les R ....................................................................................... 247
EL|NATDN 0ES AND|ALES 0E |SE A JDUF ........................................................................... 247
1er ]orme normcle 1NF .............................................................................................. 248
2eme ]orme normcle 2NF .......................................................................................... 250
Jeme ]orme normcle JNF .......................................................................................... 251
Forme normcle 8oyceCodd (8CFN) ......................................................................... 252
Lc JFN une relcxcton de lc 8CFN ............................................................................ 253
16. VUES .......................................................................................................................... 255
7UES EN SQL ........................................................................................................................ 256
|ULTPLEF LES FEPFESENTATDNS LDCQUES ........................................................................... 258
Crer des vues contextuelles ................................................................................... 258
lnter]ccer un schmc .................................................................................................. 259
Crer des dpendcnces cclcules ............................................................................. 259
0dure de ln]ormcton ............................................................................................ 261
EXEFCCES ............................................................................................................................. 263
Le ]eu des tros ds ..................................................................................................... 263
Produt scclcre et le produt mctrcel ................................................................. 264
Sur TTJ .......................................................................................................................... 265
Rponses ....................................................................................................................... 265
17. DPTIhISATIDN ET PEPFDPhANCE ....................................................................... 269
DPT|SATDN 0ES FEQUETES SQL .......................................................................................... 270
Rcrture de lc requte SQL ................................................................................... 272
Chemns dcccs ........................................................................................................... 274
Chox de lc mthode de ]onture ............................................................................. 277
UNE PEFCEPTDN HDLSTQUE 0E LA CDNCEPTDN ..................................................................... 279
SPECALSEF LES 7UES PDUF UN ACCES PFNCPAL ..................................................................... 283
0ENDF|ALSATDN ................................................................................................................. 285
18. INVEST ....................................................................................................................... 289
ENDNCE ................................................................................................................................ 289
0D|ANE 0ES CDNSTTUANTS .................................................................................................. 290
SE|ANTQUE.......................................................................................................................... 291
0ACFA||E 0ES CLASSES ........................................................................................................ 292
FELATDNS ............................................................................................................................ 292
0EPEN0ANCES FDNCTDNNELLES .............................................................................................. 293
TA8LES TYPE ......................................................................................................................... 293
SUF LA |D0ELSATDN ............................................................................................................ 294
FEQUETES ............................................................................................................................. 294
FECLES 0'NTECFTE............................................................................................................... 295
1. SECUP ........................................................................................................................ 297
ENDNCE ................................................................................................................................ 297
SCHE|A 0ES FELATDNS .......................................................................................................... 299
0ACFA||E 0ES CAS 0'UTLSATDN ........................................................................................ 300
0ACFA||E 0ES CLASSES ........................................................................................................ 301
SE|ANTQUE.......................................................................................................................... 301
TA8LE TYPE ........................................................................................................................... 302
SUF LA |D0ELSATDN ............................................................................................................ 303
FEQUETES ............................................................................................................................. 303
FECLES 0'NTECFTE............................................................................................................... 304
20. ULTIhA ...................................................................................................................... 305
ENDNCE ................................................................................................................................ 305
FELATDNS ............................................................................................................................ 307
0ACFA||E 0ES CLASSES ........................................................................................................ 308
SE|ANTQUE.......................................................................................................................... 308
TA8LES TYPE ......................................................................................................................... 309
SUF LA |D0ELSATDN ............................................................................................................ 309
FEQUETES ............................................................................................................................. 310
FECLES 0'NTECFTE............................................................................................................... 310
21. ICShAC .................................................................................................................... 313
0ACFA||E 0ES CLASSES ........................................................................................................ 316
FELATDNS ............................................................................................................................ 318
SE|ANTQUE.......................................................................................................................... 319
TA8LES TYPE ......................................................................................................................... 319
SUF LA |D0ELSATDN ............................................................................................................ 320
FEQUETES ............................................................................................................................. 321
FECLES 0'NTECFTE .............................................................................................................. 321
22. 0UF ............................................................................................................................ 323
FELATDNS ............................................................................................................................ 325
0ACFA||E 0ES CLASSES ........................................................................................................ 326
SE|ANTQUE.......................................................................................................................... 327
TA8LES TYPE ......................................................................................................................... 328
SUF LA |D0ELSATDN ............................................................................................................ 329
FEQUETES ............................................................................................................................. 329
FECLES 0'NTECFTE .............................................................................................................. 330
23. FAhE .......................................................................................................................... 331
ENDNCE ................................................................................................................................ 331
0ACFA||E 0E CLASSES ......................................................................................................... 333
FELATDNS ............................................................................................................................ 333
0e U|L SQL 1J
SE|ANTQUE.......................................................................................................................... 334
SUF LA |D0ELSATDN ............................................................................................................ 335
FEPDN0FE EN SQL AUX QUESTDNS SU7ANTES: ....................................................................... 336
7UES .................................................................................................................................... 336
FECLES 0'NTECFTE .............................................................................................................. 336
24. ELECTA ...................................................................................................................... 337
0ACFA||E 0E CLASSES ......................................................................................................... 338
FELATDNS ............................................................................................................................ 338
SUF LA |D0ELSATDN ............................................................................................................ 339
25. CDNFEP ..................................................................................................................... 341
ENDNCE ................................................................................................................................ 341
QUESTDNS ........................................................................................................................... 342
26. 3,2 LE hATIN ......................................................................................................... 343
ENDNCE ................................................................................................................................ 343
0ACFA||E 0ES CLASSES ........................................................................................................ 348
27. Ch LICTH ............................................................................................................... 349
FELATDNS ............................................................................................................................ 350
SE|ANTQUE.......................................................................................................................... 351
QUESTDNS 0E |D0ELSATDN ................................................................................................. 352
FEPDN0FE EN SQL ................................................................................................................ 353
28. hETCE ....................................................................................................................... 355
0ACFA||E 0ES CLASSES ........................................................................................................ 360
FELATDNS ............................................................................................................................ 361
QUESTDNS ........................................................................................................................... 361
2. ETU0E 0E CAS : A C 0 ........................................................................................ 365
0ACFA||E 0ES CLASSES ........................................................................................................ 369
30. PLANS, PLANS, PATAPLAN ................................................................................... 371
31. ILIDCPAPHIE ........................................................................................................ 375
32. IN0EX ......................................................................................................................... 379

0e U|L SQL 15
Notations

F prdIcat d'une relatIon F
F
+
ensemble de constItuants de F
appartIent
est Inclus dans
unIon
IntersectIon
dIffrence
ensemble vIde
et logIque
ou logIque InclusIf
ngatIon
pour tout
Il exIste
quIvalence
produIt cartsIen
tel que (dans un ensemble)
[] un ensemble
squence de produIt
F,S,T, ... des relatIons
r,s,t des nuplets
A,8,C, ... des constItuants
X,Y,Z, ... des ensembles de constItuant
F(A,8,C,0) Une cl de la relatIon est IndIque par un soulIgnement

0e U|L SQL 17
J. Introduction la modelisation
"Les images ne sont pas faites pour la lumire. Tout rve le
sait et chaque nuit le prouve" Vie secrte - Pascal
Quignard
L'information au cour l'entreprise
L'actIvIt des entreprIses est actuellement entIerement centre sur
l'InformatIon. Les systemes les plus connus et les plus vIsIbles sont les
systemes de base des entreprIses quI soustendent l'ensemble des actIvIts
opratIonnelles de l'entreprIse (Legacy system en anglaIs). ParmI ces
applIcatIons, nous trouvons tradItIonnellement la comptabIlIt gnrale, la
gestIon dea fournIsseurs, la gestIon des stocks, la gestIon des ventes et des
clIents et souvent une applIcatIon centre sur le mtIer de l'entreprIse. Pour
une rgIe, Il s'agIra d'une gestIon d'Immeuble, pour un cabInet de gestIon de
fortune, on trouvera une gestIon de portefeuIlle. Ces systemes opratIonnels
sont caractrIss par l'aspect protocole de saIsIe des InformatIons. Par
exemple, Il exIste gnralement une seule manIere de saIsIr une crIture
comptable et l'ensemble des rapports assocIs la comptabIlIt sont
gnralement prdtermIns.
Les besoIns en InformatIon ont rapIdement dpass le cadre opratIonnel
pour atteIndre celuI du dcIsIonnel. 0ans ce cadre, le gestIonnaIre doIt
prendre des dcIsIons sur la base des donnes opratIonnelles. Ses outIls
sont ceux de l'analyse de donnes, de l'aIde la dcIsIon, les donnes sont
agrges par prIodes, par domaInes. Ces besoIns sont actuellement
regroups sous le terme d'entrepots de donnes (0atawarehouse en anglaIs),
d'analyse d'espace ndImensIons ou de cubes de donnes.
La dernIere exploItatIon possIble des donnes est celle effectue par les
outIls de 0ata|InIng quI partIr des donnes opratIonnelles tentent de
dcouvrIr des regles ou des loIs caches dans l'InformatIon. Ces outIls sont
surtout utIlIss dans les tudes de march pour dcouvrIr le comportement
du consommateur.
L'InformatIon d'une entreprIse n'est pas unIquement contenue dans des
donnes structures, elle est aussI prsente dans les documents manIpuls
par l'entreprIse. Pour celles quI tendent vers le zro papIer, elles utIlIsent
des systemes de gestIon lectronIque des documents (CE0) quI sont des
bases de donnes de documents. Les documents sont gnralement scanns
l'entre du systeme d'InformatIon. Les documents sont ensuIte analyss par
un outIl de reconnaIssance de caracteres, ce quI permet ultrIeurement
d'accder au contenu de ces documents, sInon on en a unIquement une
Image. Ces CE0 possedent gnralement de systeme d'IndexatIon du
contenu, des IndexatIons par mots cls, par auteurs, par date quI
permettent de retrouver le document.
La gestIon de la cIrculatIon des documents et la synchronIsatIon des actIvIts
sont gres avec des technIques de gestIon de flux (Workflow en anglaIs).
CecI permet d'automatIser l'admInIstratIon du suIvI des documents. Les
documents sont assocIs des tats et des regles de gestIon sont tablIes sur
ces tats pour autorIser les traItements approprIs.
Un pas supplmentaIre est franchI avec les collectIcIels. 0ans le cas
prcdent, les documents cIrculaIent d'un acteur l'autre. cI, Il s'agIt
d'organIser la synchronIsatIon des acteurs avec des outIls de communIcatIon
et des outIls permettant d'laborer plusIeurs, sImultanment, des
documents. A nouveau, des bases de donnes contenant les messages et les
partIcIpatIons des acteurs sont mIses en uvre. Les mcanIsmes d'IndexatIon
sur les contenus, les auteurs, les destInataIres, les versIons, etc. facIlItent
les recherches.
Et fInalement l'utIlIsatIon de serveurs WE8 en ntranet ou nternet complete
la mIse en rseau de l'InformatIon. L'InformatIon de l'entreprIse est vue
comme un document hypertextuel. Les bases de donnes sont encore le
moyen le plus fIable et le plus sImple pour grer les lIens d'hypertexte entre
les dIffrents documents.
Ce bref survol des dIffrentes technIques d'utIlIsatIon de l'InformatIon dans
l'entreprIse, nous montre que les bases de donnes sont au centre de la
gestIon des InformatIons.
Du structure au non structure
Comme nous l'avons vu, l'InformatIon peut prendre plusIeurs formes. 0ans
les bases de donnes, elle est fortement structure. Par contre dans un
serveur Web, elle est nonstructure.

structure
(0 )
non-structure
(WE)
modlIsable Indexable
domaIne lImIt
(nbr de catgorIes petIt)
domaIne IllImIt
(nbr de catgorIes grand)
protocole connu
(cycle de vIe des objets)
pas de protocole explIcIt

Le structur est gnralement le rsultat d'une modlIsatIon d'un domaIne
lImIt. Le domaIne tant lImIt, les catgorIes d'objets l'IntrIeur de celuI
cI sont peu nombreuses, Il est donc possIble de modlIser l'ensemble. 0e plus
0e U|L SQL 19
le protocole du cycle de vIe des objets est connu (c'est dIre quand les
objets apparaIssent, se modIfIent et dIsparaIssent du champ d'applIcatIon).
Les bases de donnes contenant les applIcatIons de base de l'entreprIse sont
un cas typIque d'InformatIon structure.
Le nonstructur est caractrIs par un domaIne aux frontIeres plus floues.
Les catgorIes d'objets devIennent alors plus nombreuses et moIns
dIscernables par une forme rgulIere. Le domaIne n'est plus modlIsable,
maIs gnralement Indexable. l n'y a pas de protocole explIcIte du cycle de
vIe des objets.
Structur SemI-structur non-structur
modlIsable syntaxe smantIque
auteur
tItre
dIteur
nbr pages
ChapItre
partIe
paragraphe
phrase
Sens
Concept
des
CommentaIres

l exIste une contInuIt d'tats de l'InformatIon du structur au non
structur. Un objet peut avoIr plusIeurs facettes InformatIonnelles ayant
dIffrents nIveaux de structuratIon. Par exemple un lIvre pourra tre vu
comme:
Un objet structur appartenant la base de donnes d'un lIbraIre ou la
modlIsatIon aura unIquement retenu son auteur, son tItre, son
dIteur, le nombre de pages, etc. ;
Le mme lIvre peut tre dcrIt en X|L avec une structure de
chapItres, partIes, paragraphes, phrases, etc. cI on a affaIre un
document dont la forme est structure ;
EnfIn ce lIvre peut faIre l'objet d'une crItIque sur Internet, ses
adorateurs et ses dtracteurs peuvent crer des pages en HT|L qu'Ils
lIeront au reste du Web par des lIens hypertextuels.

InformatIon
structure 0ataWare
House
Legacy
System

nonstructure WE8 WorkFlow
non
structur
structur processus

FIgure 11 : Systemes en fonctIon de leur structuratIon
Les processus aussI sont plus ou moIns structurables. 0ans la FIgure 11, on
constate que tous les cas de fIgure sont possIbles. Les applIcatIons de base
de l'entreprIse sont fortement structures dans les donnes et dans les
processus. Par contre, quand un gestIonnaIre explore, compare, analyse un
entrepot de donnes, son chemInement n'est pas connu, nI structur.
A l'Inverse, dans une gestIon de documents, les donnes peuvent tre
faIblement structures et les traItements completement contraInts par les
regles de gestIon.
La modlIsatIon d'un systeme d'InformatIon explIcIte quand cela est possIble:
la structure des donnes, la structure des traItements et les regles de
gestIon. Ces troIs axes de descrIptIon sont la base de la modlIsatIon.
Donnees

systeme
a
decrire

Traitements Regles

FIgure 12 : Axes de descrIptIon du systeme d'InformatIon
Une vision de l'evolution de l'informatique
Nous donnons dans le tableau quI suIt quelques poInts de repere sur
l'volutIon de l'InformatIque. Au fond, seule la tendance nous Intresse. Les
traItements sont de plus en plus dIstrIbus. Les InformatIons manIpules sont
de plus en plus standardIses et modlIses. L'archItecture appelle plus
d'InterconnexIons, plus de mobIlIt dans les donnes et les applIcatIons
changes.
Les axes de l'archItecture d'un systeme d'InformatIon sont donc en suIvant
ces tendances:
Les donnes et les regles de gestIon sont toutes gres par une base
de donnes ;
Les traItements sont spcIfIs dans un code supportant la mobIlIt,
c'est dIre pouvant s'excuter sur des plateformes dIffrentes et sous
des systemes d'exploItatIon dIffrents ;
Les Interfaces doIvent tre de nature hypertextuelle.
Les applIcatIons ClIent/serveur, Intranet/Internet utIlIsant un mlange de
Web, de code Java et de base de donnes possedent tous les IngrdIents
dcrIts cIdessus.

CPU 0DNNEES APCHI- TECHND-
0e U|L SQL 21
TECTUPE LDCIE
60 ordInateur
central
fIchIers centralIs bande, carte
perfore, centre
de traItement
70 mInI
dpartemen
tal
80
hIrarchIques
rseaux
toIle termInal, dIsque
amovIble
80 ordInateur
personnel
80
relatIonnelles
PoInt
rseau Interne
dIsquette, cable
coaxIal
90 ordInateur
rseaux
80
Dbjets/relatIon
rseau global

C0rom, modem
00 Dbjets
IntellIgent
0ocuments

|obIlIt, Ecran plat, tl
phone portable

8ase de donnes

systeme

dcrIre

nterface
Hypertextuelle Code mobIle

FIgure 1J : Axes de l'archItecture du systeme d'InformatIon
Quoi, Comment, Qui ?
Nous venons de voIr que nous pouvIons nous Interroger sur comment dcrIre
l'InformatIon, sur le choIx des technologIes mettre en uvre pour la grer.
|aIs d'autres questIons gravItent autour de l'InformatIon :
Sur la confIdentIalIt : quI peut accder l'InformatIon, quels sont les
droIts offerts chacun, combIen me coute son dvoIlement :
Sur la fIabIlIt : Pendant combIen de temps puIsje vIvre sans cette
InformatIon, combIen me coute sa perte :
Sur son atteIgnabIlIt : comment la retrouver, quels sont les Index quI
la rfrence :
Sur son utIlIsatIon : quI l'utIlIse, dans quel processus estelle utIlIse :
Sur son cycle de vIe, quand estelle cre, supprIme, modIfIe dans le
champ d'applIcatIon :
Sur ses assocIatIons : quelles autres InformatIons estelle lIe, de
quelles InformatIons dpendelle :
Sur son Importance pour l'entreprIse ;
Sur les servIces possIbles : la valeur ajoute ces servIces grce
cette InformatIon ;
Sur les opratIons possIbles.
En examInant ces questIons, on peut constater que plusIeurs poInts de vue
sont prendre en compte. Cet aspect polymorphe de l'InformatIon s'tend
aussI sa reprsentatIon. 0ans la premIer cours apres J0 mInutes, je
demande aux tudIants de modlIser le groupe d'tudIants qu'Ils
reprsentent. Et les rsultats se rpartIssent gnralement en plusIeurs
styles.
Dn trouve le style classIfIcatIon.
Facult

SES ScIences Autre

LIcence S |Ineure LIcence CertIfIcat AudIteur

tudIants

1ere 2eme Jeme 4
eme

F H F H F H F H

FIgure 14 : l'arbre comme choIx de classIfIcatIon
Le style botes et fleches:

ETU0ANT No EtudIant

ND|:
PFEND|:
ACE:
A0FESSE:
FACULTE:

Anne en Cours

HoraIre des cours

FIgure 15 : la bote comme choIx de rangement

0e U|L SQL 2J
Le style texte et lIste:
Par rapport au cours :
horaIre du cours
semestrIel, annuel
Nbr d'heures de cours
quels genres d'exas (crIt,
oral)
Nbr de partIcIpants
nom du prof
prrequIs
Par rapport I'tudIant :
nom
prnom
ge
quelle lIcence suIvIe
quelle anne d'tude

Sur la base des rsultats de ce petIt exercIce, on peut constater que:
Sans objectIf, chacun a suIvI des objectIfs propres, chacun a suIvI sa
propre InspIratIon ;
Le domaIne n'est pas cIos par une frontIre: l'absence d'objectIf ne
dlImIte pas le S spcIfIer ;
La forme est moIIe: chacun a reprsent le S selon son InspIratIon
sans donner un sens prcIs aux symboles utIlIss ou aux structures ;
CommunIcabIe: toutes ces formes sont facIlement communIcables
maIs sans rIgueur dans la forme, Il est dIffIcIle d'tre prcIs.
Modle
Pour nous un modele est une abstractIon de la ralIt sur laquelle on peut
oprer. C'est une abstractIon, car nous devons fIltrer, slectIonner une
partIe de la ralIt pour laborer le modele. Pour ce quI a t retenu, se
pose la questIon de comment le reprsenter : Ce choIx de la reprsentatIon
est dIrectement lI l'aspect opratoIre de la modlIsatIon. Comment
manIpuler le modele : Comment Interroger le modele : Comment Interprter
les rponses dans la ralIt : En effet, Il va y avoIr un retour du modele dans
la ralIt. Nous faIsons le dtour par le modele pour nous aIder prendre
une dcIsIon dans la ralIt. Tous les modeles ne sont pas adapts tout.
Chacun est spcIalIs dans une facette partIculIere de la reprsentatIon de
la ralIt. Dn doIt donc vrIfIer les hypotheses d'utIlIsatIon du modele et
connatre les lImItes de valIdIt du modele.
L'utIlIsatIon d'un modele correspond toujours un dplacement du
questIonnement. ExamInons l'exemple de la FIgure 16 : dans le rel, Il
exIste saturne. 0ans la ralIt, ce quI est peru par nous et quI dpend de
nos sens et de nos moyens d'InvestIgatIon, nous percevons saturne comme
une masse sphrIque avec un anneau. SI notre questIonnement est : quel est
le volume de saturne : Nous cherchons le modele le plus adquat, nous
faIsons des hypotheses sImplIfIcatrIces. Par exemple, nous dcIdons de
consIdrer saturne comme une sphere parfaIte et de ne pas tenIr compte de
son anneau. La questIon devIent alors une questIon du domaIne de la
gomtrIe : quel est le volume de la sphere : Nous utIlIsons la formule
adquate avec une estImatIon du rayon de saturne. En retour, nous obtenons
un chIffre que nous Interprtons dans la ralIt.
FeformulatIon en rponse
termes du modele du modele
modele vol=4/J*F
J

capturer un petIt nombre de parametre + hypothese sImplIfIcatrIce

questIons choIx du modele InterprtatIon

ralIt + =saturne

peru par l'homme

rel

FIgure 16 : de la ralIt au modele.
Le processus de modlIsatIon peut tre carIcatur par les tapes suIvantes :
Dn a dans un premIer temps des questIons sur la ralIt, maIs cellecI
ne se laIsse pas Interroger ;
Dn modlIse donc la partIe quI doIt tre Interroge ;
Dn InItIalIse le modele avec les valeurs provenant de la ralIt ;
Dn reformule la questIon InItIale dans les termes du modele ;
Dn value la questIon dans le modele ;
Dn valIde la rponse donne par le modele ;
Dn Interprete la rponse dans la ralIt InItIale.
Pourquoi modeliser ?
Avant de termIner cette IntroductIon la modlIsatIon, on peut se demander
pourquoI modlIser le systeme d'InformatIon. Pour nous, la modlIsatIon du
systeme d'InformatIon dtermIne un espace possIble pour l'artIculatIon de
deux dIscours. L'un est le dIscours du gestIonnaIre en termes de
responsabIlIt, de ressources humaInes, de document, de hIrarchIes d'unIt
d'organIsatIon, de mthodes de management, de couts, de valeur ajoute,
de servIce, etc.. L'autre dIscours est celuI de l'InformatIcIen en termes de
technologIes, de base de donnes, de systeme exploItatIon, de rseaux, de
mgahertz, gIgabytes, etc.. La modlIsatIon permet de s'abstraIre des deux
types de dIscours et de se consacrer plus pragmatIquement sur les objectIfs
0e U|L SQL 25
et les besoIns de l'entreprIse et de ses acteurs. Le concepteur produIra un
systeme en poursuIvant les objectIfs suIvants:
|InImIser la complexIt ;
|axImIser l'volutIvIt ;
AutorIser l'ImplmentabIlIt ;
Augmenter la Fobustesse.
Ces objectIfs seront dans le reste de l'ouvrage, une lIgne de conduIte lors
des choIx oblIgs de la conceptIon.
Comme nous l'avons vu prcdemment pour modlIser, Il est Important de
fIxer la notatIon dans laquelle nous allons exprImer. Nous avons faIt le choIx
de travaIller avec la notatIon U|L (0n]ed Modelny Lcnyucye). U|L est
destIn la modlIsatIon objet et couvre toutes les phases d'un projet. Pour
nous Il permettra de spcIfIer les objets prIncIpaux des systemes
d'InformatIon, savoIr les donnes, les traItements et les regles de gestIon.
UML - un peu d'histoire
U|L est un exemple de russIte par l'allIance. Au dbut des annes 90, la
recherche est orIente vers le monde des objets et les chercheurs en gnIe
logIcIel produIsent des mthodes pour le paradIgme objet. 0eux acteurs
C. 8ooch et J. Fumbaugh sont en concurrence avec leur modele 8ooch91 et
D|T1. La deuxIeme versIon de leur modele complete les manques de la
premIere versIon et ajoute des fonctIonnalIts. |aIs les modeles 8ooch9J et
D|T2 sont conceptuellement pratIquement IdentIques. C. 8ooch et
J. Fumbaugh dcIdent d'allIer leur comptence plutot que de se perdre dans
une querelle strIle. En octobre 1994, J. Fumbaugh entre dans la socIt
FatIonal (www.ratIonal.com) de C. 8ooch. En octobre 1995, Il publIe une
premIere versIon U| 0.8 (UnIfIed |ethod) runIssant leurs travaux. En juIllet
1996, sous l'Influence de var Jacobson et de sa mthodologIe DDSE, la
premIere versIon de U|L 0.9 parat. En janvIer 1997, la versIon U|L 1.0 est
propose l'D|C (Dbject |odellIng Croup www.omg.org) afIn de la
standardIse. Cette standardIsatIon est parraIne par 0IgItal EquIpment,
HewlettPackard, |Icrosoft, Dracle, Texas nstruments Software, UnIsys,
etc. En novembre 1997, la versIon 1.1 est standardIse par l'D|C. Sur le sIte
de l'D|C, on peut suIvre les dveloppements et les rvIsIons du standard.
Les acteurs prIncIpaux de U|L sont:
Crady 8ooch : mthodologIe, 8ooch91,8ooch9J ;
JIm Fumbaugh: mthodologIe, D|T1, D|T2 ;
var Jacobson: mthodologIe, DDSE .
|aIs on y trouve aussI les travaux de:
Harel: Statechart (automate formel) ;
|eyer: pr et postcondItIon ;
Shlaer et |ellor: cycle de vIe d'objets .
En deux ans, la plupart des grandes socIts de logIcIel ont adopt U|L dans
leurs outIls. Comme on le verra, U|L n'Impose une mthode maIs une
notatIon.
Les prIncIpaux objectIfs d'U|L sont:
0e modlIser des systemes complets et complexes, U|L ne se lImIte
pas seulement au langage de programmatIon objet ;
0e coupler les concepts avec les artefacts excutables. l assIste donc
le dveloppement depuIs la conceptIon jusqu'au dploIement ;
0e grer la complexIt des systemes. En utIlIsant, la possIbIlIt de
raffInement successIf, Il est possIble d'utIlIser U|L aussI bIen pour
concevoIr un dIstrIbuteur de boIsson ou qu'une navette spatIale ;
0'tre un modele adapt aux humaIns et aux machInes. Chaque
concept possede toujours les deux reprsentatIons, l'une externe
graphIque et lIsIble par une personne, l'autre formelle et manIpulable
par un programme ou un outIl ;
0'tre un systeme ouvert. U|L n'est qu'une notatIon, Il ne dfInIt pas
la mthode, nI les outIls. l reste extensIble d'autres concepts.
AvoIr une unIt de notatIon durant tout le cycle de vIe du dveloppement
constItue un atout majeur en faveur d'U|L. En effet, peu de mthodes
couvrent completement le cycle de vIe du dveloppement. Et la rupture ou
le changement de modele cre un rIsque de perte smantIque dans la
contInuIt du dveloppement.
U|L c'est sIx modeles:
|odele des cIasses : exprImer la structure statIque des objets ;
|odele des cas d'utIIIsatIon : exprImer les besoIns des utIlIsateurs ;
|odele des tats : exprImer la structure dynamIque des objets ;
|odele des InteractIons : entre les acteurs et le systeme, entre les
objets ;
|odele de raIIsatIon : exprImer le regroupement et les unIts
logIques de ralIsatIon ;
|odele de dpIoIement : exprImer la rpartItIon physIque des
lments du systeme.
0ans les deux chapItres suIvants, nous allons examIner les deux premIers
modeles.
Dej des exercices
Chercher des modeles et vrIfIer qu'Ils sont bIen des abstractIons munIes
d'opratIons :
en physIque
en conomIe
en socIologIe
en psychologIe
0e U|L SQL 27
etc.
Fpondre aux poInts suIvants:
A quelles InterrogatIons rpondentIls :
Quelles sont les hypotheses d'utIlIsatIon :
Comment reformuler sa questIon :
Comment paramtrer la modlIsatIon :
Comment Interprter la rponse :

0e U|L SQL 29
2. Objets et classes
Tous les systmes y passaient, adoucis d'une certitude
de triomphe facile, d'un baiser universel qui terminerait le
malentendu des classes Germinal E. Zola
0ans ce chapItre, nous prsentons les concepts d'objet et de classe aInsI que
les notatIons U|L quI leur sont assocIs.
C'est quoi un objet
C'est une entIt contenant des:
0onnes : les donnes nous Informent sur l'tat de l'objet.
Procdures : les procdures nous Informent sur le comportement de l'objet.
L'tat de l'objet est gnralement conserv dans des varIables et le
comportement de l'objet est spcIfI dans des mthodes, des petIts
programmes assocIs l'objet.
variables
m thodes

FIgure 21 : Un objet.
Prenons par exemple l'objet rectcnyle r1, son tat est dfInI par les deux
varIables largeur et hauteur valant respectIvement 5 et 8. l est possIble de
le manIpuler pour luI demander sa surface, son prImetre ou bIen de
modIfIer son tat en luI demandant de s'agrandIr.
Chaque objet a une IdentIt (DId) quI permet de le reprer. Les objets
communIquent entre eux en changeant des messages. La rceptIon d'un
message par un objet dclenche l'excutIon de la mthode Invoque avec
les parametres donns.
Par exemple:
r1.sur]cce() retournera la valeur 40
r1.cyrcndr(5) modIfIera l'tat de r1 (largeur=25 et hauteur=40)
Les objets ne restent pas longtemps Isols : Ils se rassemblent en collectIon,
de ces collectIons se dgagent une structure commune, de l'artIsannat, on
passe au stade IndustrIel.

Largeur=5
Largeur=5
Hauteur=8
surface
primtre
agrandir

FIgure 22 : r1 un rectangle, son tat et son comportement.
Classe
Une classe est un moule pour fabrIquer des objets
0e mme structure ;
0e mme comportement ;
FgIt par les mmes regles.
Largeur=5
Largeur=
Hauteur= surface
p rim tre
agrandir
NEW
Largeur=5
Largeur=5
Hauteur=8 surface
p rim tre
agrandir
Largeur=5
Largeur=4
Hauteur=4 surface
p rim tre
agrandir
new Rectangle(5,8) new Rectangle(4,4)

FIgure 2J : La classe Fectangle et deux Instances.
La classe Fectangle, est le moule permettant de fabrIquer des objets
rectangles ayant tous une largeur, une hauteur et ragIssant de la mme
manIere aux messages prImetre, surface et agrandIr. La cratIon d'un objet
rectangle par la classe Fectangle s'obtIent en Invoquant la mthode new sur
la classe ellemme. Dn parle alors d'InstancIatIon d'objet partIr de la
classe. Un objet est une Instance d'une classe
Pourquoi les objets ?
La programmatIon objet a rencontr un large succes aupres des
dveloppeurs durant ces dernIeres annes, d'abord avec Smalltalk, ensuIte
0e U|L SQL J1
avec C++ et dernIerement avec Java. La programmatIon objet possede des
bonnes proprIts gnIe logIcIel.
La premIere est de runIr les donnes et traItements. Le comportement est
dfInI dans la classe. Les changements d'tats d'un objet devraIent tre
unIquement le faIt des mthodes de cet objet. La comprhensIon d'un objet
peut donc s'effectuer dans le contexte de la classe. 0ans la programmatIon
classIque, la sparatIon des donnes et des traItements ne permet pas
d'avoIr cette certItude sur la modIfIcatIon des varIables.
Les objets changent des messages entre eux et cela devraIt tre le seul
mode de communIcatIon ( Il ne doIt pas y avoIr d'InteractIon dIrecte sur une
varIable d'tat d'un objet depuIs une mthode extrIeure cet objet). SI tel
est le cas, alors le comportement d'un systeme se dcrIt comme la
collaboratIon d'un ensemble d'objets, orIente vers un objectIf.
L'encapsulatIon est le mcanIsme quI permet de cacher comment sont
ralIses les mthodes et de rendre prIv l'acces aux varIables d'tats de
l'objet. Ce mcanIsme permet de dlImIter claIrement la spcIfIcatIon d'un
servIce et de son ImplmentatIon. Cela permet de rendre plus volutIf le
systeme, la modIfIcatIon de l'ImplmentatIon d'une mthode n'ayant pas
d'effet secondaIre sI la spcIfIcatIon est respecte.
L'hrItage est l'autre mcanIsme majeur de la programmatIon objet. l
permet d'affIner le comportement d'une classe, de factorIser le code et
d'tre un vecteur de rutIlIsatIon. Plus gnralement, le polymorphIsme
permet un objet de s'habIller avec plusIeurs types de comportements
dIffrents.
L'ensemble de ces caractrIstIques a assur le succes du paradIgme objet.
0ans la suIte de cet ouvrage, nous aborderont les proprIts conceptuelles
structurantes suIvantes:
Les classes ;
Les attrIbuts ;
Les mthodes ;
Les assocIatIons ;
Les relatIons d'hrItage.
Nous ne commenterons pas les caractrIstIques propres la programmatIon
objet comme la vIsIbIlIt des attrIbuts, des mthodes, les types de classe
(Interface, abstraIte, .).
Diagramme de classes en UML
La notatIon U|L (FIgure 24) dessIne le concept de classe dans un rectangle,
le nom de la classe apparassent dans la partIe suprIeure. Le compartIment
suIvant contIent la lIste des attrIbuts de la classe et le dernIer compartIment
la lIste des mthodes.

FIgure 24 : dsIgnatIon des classes en U|L.
La FIgure 25 montre les classes Rectcnyles, 0sques et Trcnyles.

FIgure 25 : exemples de classes en U|L.

Nom classiIicateur
stereotype~~
proprietes

Nom de la relation
relationnel~~
FN3ieme

FIgure 26 : les strotypes.
Les classes appartIennent l'ensemble des classIfIcateurs de la descrIptIon
statIque. l exIste d'autres types de classIfIcateurs, par exemple :
type de donnes>> : un descrIpteur assocI un ensemble de
valeurs, un domaIne ;
nter]cce>> : le nom d'un ensemble d'opratIons quI dfInIssent un
comportement ;
soussystme>> : un package quI est traIt d'une manIere unItaIre
avec une spcIfIcatIon et une ImplmentatIon ;
utltcre>> : une classe ne comportant que des opratIons (pas
d'Instance).
Chaque classIfIcateur dfInIt un strotype et peut se reprsenter comme
IndIqu dans la FIgure 26.
Classe
Attributs : type
Methodes()
Attributs : type
Methodes()
Klass
Triangles Rectangles
largeur : real
hauteur : real
perimetre()
surIace()
agrandir()
diagonal()
Disques
diametre : real
perimetre()
surIace()
agrandir()
diametre : real
perimetre()
surIace()
agrandir()
largeur : real
hauteur : real
perimetre()
surIace()
agrandir()
diagonal()
0e U|L SQL JJ
l est aussI possIble de crer des nouveaux strotypes, par exemple, on peut
crer le classIfIcateur relcton assocI au strotype relctonnel>>, une
classe ne comportant que des attrIbuts (pas d'opratIon).
Diagramme d'objets
La notatIon U|L, pour dsIgner les objets rutIlIse la forme rectangulaIre.
L'IdentIt de l'objet est dfInIe en deux partIes, la premIere est le nom de
l'Instance, la deuxIeme le nom de la classe. 0ans le deuxIeme
compartIment, Il est possIble de spcIfIer l'tat de l'objet en assocIant des
valeurs aux attrIbuts. La FIgure 27 montre troIs cas d'IdentIfIcatIon des
objets :
lnstcnce : le cas d'un objet dont la classe n'est pas connue ;
lnstcnce :Klcss, le cas d'un objet dont la classe est connue ;
:Klcss, un objet anonyme d'une certaIne classe.

FIgure 27 : les dIffrentes appellatIons des objets.

FIgure 28 : exemples d'objets
La FIgure 28 montre troIs objets :
Un rectangle r1 avec les tats prIs par ses attrIbuts ;
Un trIangle anonyme ;
Un objet d1 dont la classe n'est pas spcIfIe.
Liens entre les objets
Les objets ont des IIens entre eux. 0ans l'exemple suIvant, les lIens entre les
objets dfInIssent la smantIque quI lIe les objets. ls dcrIvent comment
InteragIssent statIquement les objets. Dn pourra dIre que le cours est donn
par un professeur, dans une tranche horaIre, dans une salle. La salle est
quIpe avec des tables, derrIere une table se trouvent deux chaIses sur
lesquelles sont assIs |arIe et No.
Instance:
attributvaleur
Instance1:Klass :Klass
attributvaleur
r1:Rectangles
largeur5
hauteur8
:Triangles d1:
diametre13
epaisseur1.3
largeur5
hauteur8
diametre13
epaisseur1.3
Les classes ont des assocIatIons entre elles. Les lIens sont des Instances des
assocIatIons.

FIgure 29 : les objets sont lIs entre eux
Associations
Une assocIatIon dcrIt la connexIon entre plusIeurs classes. Les classes sont
Indpendantes les unes des autres, dans le sens ou l'exIstence d'une
Instance de ces classes ne dpend pas d'une autre. L'assocIatIon dtermIne
un couplage faIble entre classes.
Les assocIatIons dtermInent les InteractIons entre les classes. Le nom de
l'assocIatIon spcIfIe cette InteractIon. Pour tre plus prcIs, on peut
recourIr aux roles. 0ans la FIgure 210, on peut lIre :
Classe est assocIe Klass ;
Les cours sont suIvIs par des tudIants ;
Les tudIants suIvent des cours ;
Les personnes sont les employs d'une entreprIse dans une relatIon de
travaIl ;
Les entreprIses sont les employeurs des personnes dans une relatIon de
travaIl.
chaise1:Equipements
chaise2:Equipements
Noe:Etudiants Marie:Etudiants
table:Equipements
U408:Salles
10h-12h:
J.Guyot:
Introduction a la modelisation:Cours
0e U|L SQL J5

Classe Klass
Etudiants Cours
associer a
est suivi par
suit ~
Personnes Entreprises
travail
employe employeur

FIgure 210 : exemples d'assocIatIon
Entre deux classes, Il peut exIster plusIeurs assocIatIons possIbles, on parle
aussI de roles multIples. Les personnes peuvent entretenIr des lIens
dIffrents avec les vIlles. Elles peuvent y natre, travaIller ou les habIter.

Personnes Villes
habiter
travailler
natre

FIgure 211 : exemple d'assocIatIons multIples.

Personnes Ordinateurs
posseder
allumer
utiliser
eteindre

FIgure 212 : les mthodes ne sont pas des assocIatIons.
Les assocIatIons doIvent dcrIre une relatIon stable entre les classes. Par
consquent, les lIens entre les objets doIvent exIster en dehors de
l'excutIon d'une mthode. 0ans la FIgure 212, cllumer, tendre, rpcrer
sont des mthodes. Seul possder tablIt un lIen stable entre Personnes et
Drdncteurs
Cardinalite des associations
Les assocIatIons sont contraIntes par leur cardInalIt. Dn peut Imposer que
tout objet de A est assocI par r un nombre mInImaI d'objets de 8 et au
plus un nombre maxImum d'objets de 8. Dn IndIquera cette contraInte en
fIxant un Intervalle mIn..max proxImIt de 8.

FIgure 21J : dnotatIons de la cardInalIt d'une assocIatIon.
La modlIsatIon de la FIgure 214 dnote qu'un tudIant peut suIvre
plusIeurs cours (0..n). Un cours doIt avoIr au moIns 6 et au plus J0 tudIants.

FIgure 214 : exemples de cardInalIt
Nous allons examIner plus prcIsment certaIns cas partIculIers.
Cas J..J, J
Tout objet de A est assocI exactement 1 objet de 8 (1 dnote 1..1)

FIgure 215 : cardInalIt 1 = 1..1
Nous avons par exemple, en acceptant ces gnralIts :
Un tre humaIn agIt avec une seule personnalIt ;
Un croyant est fIdele une seule relIgIon ;
Un enfant est n d'une seule mere ;
Un vIlle est ratache un seul canton.
Classe A Classe B
associer
min..max
Etudiants Cours
suivre
6..30 0..n
Classe A Classe B
associer
1
0e U|L SQL J7

Personalits EtreHumains
Religions Croyants
Mres Enfants
Villes Cantons
agit avec
* 1
Iidele a
* 1
ne de
* 1
rattache a
* 1

FIgure 216 : exemple de cardInalIt 1
Cas 0..J
Tout objet de A est assocI au plus 1 objet de 8

FIgure 217 : cardInalIt 0..1, l'optIon

FIgure 218 : exemple de cardInalIt 0..1.
Nous avons par exemple, en acceptant ces gnralIts :
Un Immeuble est entretenu au plus par un concIerge ;
Une personne possede au plus un permIs de conduIre ;
Classe A Classe B
associer
0..1
Concierges Immeubles
PermisDeConduire Personnes
Pays Villes
Hommes Femmes
entretenu par
0..1 *
possede
1 0..1
capital
1 0..1
marie a
0..1 0..1
Une vIlle peut tre la capItale d'un seul pays, un pays possede une et
une seule capItale ;
Un homme est marI au plus une femme et rcIproquement.
Ce dernIer cas est Intressant, on conoIt aIsment qu'Il est possIble que
l'on ne dIstIngue pas les hommes des femmes, nous aurrIons donc une classe
personnes. L'assocIatIon mcr c devIent une assocIatIon entre Personnes et
se dessIne de la faon suIvante.

FIgure 219 : assocIatIon entre mme classes
Les deux modlIsatIons ne sont pas tout faIt quIvalentes la premIere ne
marIe que des hommes des femmes, la deuxIeme marIe des personnes
des personnes sans dIstInctIon de sexe. SI l'on veut retrouver, la mme
contraInte, Il sera ncessaIre d'ajouter une regle d'IntgrIt (par exemple,
demander que le sexe des conjoInts soIt dIffrent)
Cas *, 0..*
Tout objet de A est assocI plusIeurs objets de 8. L'toIle dnote un
nombre arbItraIre.

FIgure 220 : cardInalIt * = 0..n
Cas J..*
Tout objet de A est assocI au moIns 1 objet de 8, ventuellement plus.
Nous avons donc les exemples possIbles suIvants :
Un auteur doIt avoIr crIt au moIns un lIvre. Un lIvre peut tre crIt
par plusIeurs auteurs et ventuellement ne pas avoIr d'auteur connu ;
Un homme peut possder plusIeurs natIonalIts ( ou zro pour les
apatrIdes). Une natIonnalIt peut tre reprsente par plusIeurs
personnes.
Personnes
marie a
conjoint
conjointe
0..1
0..1
Classe A Classe B
associer
*
0e U|L SQL J9
Un pays peut possder plusIeurs monuments. Un monument se sItue
dans un et un seul pays.

FIgure 221 : cardInalIt 1..*

FIgure 222 : exemple de cardInalIt multIple.
Association binaire, ternaire, .
Dn dfInIt I'arIt de l'assocIatIon comme tant le nombre de classes
partIcIpant l'assocIatIon. Pour le moment, nous n'avons examIn que des
assocIatIons bInaIres.

FIgure 22J : assocIatIon bInaIre
|aIs rIen n'empche de modlIser la naIssance d'un IndIvIdu en assocIant
d'autres concepts cet vnement. 0ans le cas suIvant, l'assocIatIon est
ternaIre. La naIssance est l'assocIatIon quI lIe une personne, une vIlle et un
Classe A Classe B
associer
1..n
Auteurs Livres
Hommes Nationalits
Monuments Pays
Personnes
* 1..*
* *
* 1
ami de
*
*
Personnes Villes
natre a
* 1
sIgne du zodIaque. Les cardInalIts doIvent tre examInes, en fIxant deux
objets et en regardant combIen d'objets ce couple peut tre assocI.
0ans notre exemple, nous avons :
Une personne et une vIlle ne peuvent tre assocIes qu' un sIgne ;
Une personne et un sIgne ne peuvent tre assocIs qu' une vIlle ;
Un sIgne et une vIlle peuvent tre assocIs plusIeurs personnes.

FIgure 224 : assocIatIon ternaIre
Dn dIra d'une assocIatIon qu'elle est naIre sI sa cardInalIt dpasse troIs. Le
cas suIvant montre une assocIatIon d'arIt 5, la naIssance est l'assocIatIon
quI lIe une personne, une vIlle et un sIgne du zodIaque chInoIs, deux sIgnes
du zodIaque avec deux roles dIstIncts, l'un de sIgne prIncIpal, l'autre
d'ascendant.

FIgure 225 : assocIatIon multIple
0'une manIere gnrale, on vItera, les assocIatIons naIre. En effet, elle
cache souvent un concept quI peut tre lev au rang de classe. Notre
exemple comprend alors une classe Thme cstrcl quI est assocIe par des
assocIatIons bInaIres aux classes prcdentes.
Personnes Villes
Zodiaques
* 1
1
Personnes Villes
Zodiaques
ZodiaquesChinois
*
1
ascendant
1
1
signe
1
0e U|L SQL 41

FIgure 226 : retour aux assocIatIons bInaIres !
Classe d'association
Jusqu' prsent, nous avons eu le soucI de modlIser unIquement le faIt
qu'un objet d'une classe soIt assocI un autre d'une autre classe. ParfoIs,
nous dsIrons ajouter des InformatIons concernant cette assocIatIon. Ces
InformatIons seront reprsentes par une classe d'assocIatIon quI sera
dIrectement attache l'assocIatIon ( avec un type de traIt brIs). CecI va
permettre de mmorIser des InformatIons dans le lIen.
0ans l'assocIatIon Trcvcller c, entre Personnes et \lles, Il nous est possIble
d'ajouter des InformatIons prcIsant la prIode de travaIl avec les attrIbuts
depus et ]usquc. Dn remarquera qu'Il est aInsI possIble qu'une personne soIt
assocIe deux foIs une mme vIlle pour des prIodes dIffrentes.

FIgure 227 : exemple de classe d'assocIatIon.
Dn reprsentera ces InformatIons supplmentaIres, en les rattachant sur le
lIen dIrectement. Nous avons, dans l'exemple suIvant que Mcre travaIlle
Pcrs depuIs le 1.1.2000 jusqu' une date IndtermIne.
Villes Personnes
Zodiaques
ZodiaquesChinois
Thme astral
signe
1 1
*
* 1
1
*
1
ascendant 1
*
Travailler
depuis : date
jusqua : date
Personnes Villes
depuis : date
jusqua : date
* *
ParfoIs la classe d'assocIatIon doIt perdre ce statut car elle contIent des
concepts quI demandent tre explIcIts. Nous allons examIner un exemple
Illustrant ce besoIn d'explIcItatIon.

Personnes::Marie: Villes::Paris:
Travailler a::.:
depuis1.1.2000
jusqua...
depuis1.1.2000
jusqua...

FIgure 228 : exemple d'Instance de classe d'assocIatIon.
0ans la FIgure 229, le concepteur a choIsI de reprsenter Auteurs, LIvres et
l'assocIatIon Ecrt Pcr quI les lIe. l a ajout les attrIbuts EdIteur et date de
parutIon cette assocIatIon.
Cette modlIsatIon est errone, car les attrIbuts EdIteur et ParutIon, ne
concernent pas l'assocIatIon, maIs le LIvre. l est donc envIsageable
d'ajouter ces attrIbuts LIvres. |aIs cette nouvelle modlIsatIon a pour
InconvnIent de ne pas pouvoIr tenIr compte qu'un lIvre peut avoIr plusIeurs
dItIons.

Auteurs Livres
Ecrit par
Editeur : string
Parution : date
Editeur : string
Parution : date
* *
}

FIgure 229 : l'assocIatIon ne suffIt pas.
cI IntervIent le contexte de la modlIsatIon. En effet, un partIculIer a
rarement plusIeurs versIons du mme lIvre. Par contre ce faIt est courant
pour un lIbraIre. Le concept d'dIteur doIt donc tre prIs pleInement en
consIdratIon. Nous ajoutons donc une classe Edteurs et une assocIatIon
Edton quI contIendra les attrIbuts No lS8N et dcte de pcruton.
La modlIsatIon de la FIgure 2J0, permet effectIvement d'assocIer plusIeurs
dItIons un mme lIvre. |aIs en faIsant glIsser le contexte, on s'apperoIt
qu'une uvre lIttraIre peut tre assemble dans une dItIon sous dIverses
formes. Une nouvelle d'un auteur peut tre publIe seule dans une
0e U|L SQL 4J
anthologIe consacre un theme ou dans un receuIl de nouvelles de cet
auteur.

FIgure 2J0 : suIte de l'exemple
Pour modlIser cecI, Il est IndIspensable de sparer l'uvre de son mode de
publIcatIon. 0ans la modlIsatIon quI suIt, nous avons remplac la notIon
d'dItIon par celle de publIcatIon. l est mme alors possIble de modlIser la
notIon de codItIon ou chaque dIteur partIcIpe un certaIn taux aux rIsques
et aux bnfIces.

FIgure 2J1 : fIn de l'exemple.
Contraintes
Les cardInalIts sont un cas partIculIer des contraIntes. Pour exprImer une
contraInte, on utIlIsera le strotype de contraInte (note avec des
accolades) que l'on attachera aux objets devant valIder la contraInte. Les
Auteurs Livres
Edition
No ISBN : string
Parution : date
No ISBN : string
Parution : date
* *
Editeurs
*
*
Auteurs
Idauteur : integer
Nom : string
Prenom : string
Publication
No ISBN : string
Parution : date
No ISBN : string
Parution : date
Idauteur : integer
Nom : string
Prenom : string
Editeurs
Raison Sociale : string
Adresse : string
Raison Sociale : string
Adresse : string
* *
Taux
Participation : integer
Oeuvres
Titre : string
Langue : string
Titre : string
Langue : string
Participation : integer
ecrit par
* *
rassemble
*
*
contraIntes peuvent tre places sur n'Importe quel objet de la
modlIsatIon.
0ans la FIgure 2J2, on montre un exemple de contraInte et une note quI
sont attachs la classe Trcnyles. Nous allons commenter quelques
exemples de contraIntes.

FIgure 2J2 : dnotatIon des contraIntes.
Les tIrages de Loto sont assocIs un nombre fIxe de boules, sIx dans notre
cas et ces assocIatIons sont ordonnes. Lors de la traductIon de cette
modlIsatIon, Il faudra ajouter une InformatIon pour tenIr compte de cet
ordre.

FIgure 2JJ : contraInte sur l'ordre des lIens.
0ans l'exemple quI suIt, les employs sont assocIs un vol. La regle nonce
que chaque vol doIt comporter un pIlote et deux copIlotes. CecI est
reprsent par les cardInalIts. 8Ien entendu, le pIlote doIt tre dIstInct des
copIlotes. l faut une contraInte externe pour l'exprImer. Une contraInte
peut aussI tre exprIme dans une note (par exemple, celle concernant les
vols InternatIonaux)
La contraInte quI est cIdessous exprIme que les confrencIers reprsentant
une communIcatIon doIvent tre choIsIs parmI les auteurs de cette
communIcatIon.
Triangles
a : real
b : real
c : real
a : real
b : real
c : real
abc}
Les
methodes
doivent tre
eIIicace car
plus d'un
million d'
instances
sont
prevues
Tirages Loto Boules
*
6
ordonne}
0e U|L SQL 45

Vols Employs
pilote
1
*
copilote
2
*
diIIerent}
contexte
Ne sont pris
en compte que
les vols
internationaux}

FIgure 2J4 : contraInte entre roles.

FIgure 2J5 : contraInte entre roles.
Le cas suIvant exprIme qu'un contrIbuable est soIt une personne physIque
soIt une personne morale.
Dn peut contraIndre l'assocIatIon tre parcourue que dans un sens. Le sens
de navIgatIon est IndIqu par une fleche. Ce type d'InformatIon est
Important dans la programmatIon objet car les assocIatIons sont souvent
Implmentes avec des poInteurs et, comme l'IndIque le nom, Il ne se
parcourt que dans un sens. Pour qu'une assocIatIon soIt bIdIrectIonnelle, Il
faut Implmenter le chemIn Inverse.
Personnes Communications
auteurs
* *
conIerencier
*
*
sous-
ensemble}

FIgure 2J6 : contraInte entre assocIatIons
Cette notIon de navIgatIon n'a pas d'Importance dans le cas d'une
ImplmentatIon avec un systeme de gestIon de base de donnes
relatIonnelle car les assocIatIons sont reprsentes par des valeurs et non
pas par des poInteurs.

FIgure 2J7 : contraInte de navIgabIlIt.
Pour dfInIr plus formellement les contraIntes, Il est possIble d'utIlIser DCL
(Dbject ConstraInt Language). DCL permet de dfInIr des contraIntes, des
requtes, des expressIons boolennes et des expressIons de navIgatIon. Les
expressIons permettent de manIpuler les attrIbuts des classes, de former des
ensembles, de contraIndre ces dernIers possder certaInes proprIts. Pour
plus de dtaIl, nous renvoyons le lecteur la documentatIon de D|C
[D|C99] quI consacre un chapItre entIer DCL ou l'ouvrage [WAF99]
Agregation et composition
L'agrgatIon dfInIt une assocIatIon non symtrIque, dans le sens que les
classes assocIes ne sont plus completement Indpendantes. Nous avons des
phrases du genre suIvant pour marquer cette dIssymtrIe :
A est form de 8 ;
A prexIste 8 ;
8 n'exIste pas sans A ;
A contIent 8 (ensemblIste).

0'autres dpendances moIns structurelles peuvent exIster telles que :
Les attrIbuts d'une classe sont dpendants de l'autre ;
Contribuables
Personnes Physiques Personnes Morales
0..1
1
0..1
1
ou
exclusiI}
Espions Hommes
a l'identite de
* *
0e U|L SQL 47
Les actIons d'une classe sont dpendantes de l'autre.
L'agrgatIon est spcIfIe par un petIt losange du cot de la classe quI joue
le role de matre dans l'assocIatIon.

FIgure 2J8 : dnotatIon de l'agrgatIon.
7oIcI quelques exemple d'agrgatIon : Une recette de cuIsIne est labore
avec des IngrdIents. Un polygone est constItu d'une suIte de poInts sur le
plan. Un portefeuIlle de tItres est un ensemble de placement.

FIgure 2J9 : exemples d'agrgatIon.
SI un objet de 8 n'est lI qu' un objet de A alors l'agrgatIon est une
composItIon. La cardInalIt l'assocIatIon est de 1 pour les objets de 8. La
composItIon se dIstIngue graphIquement par un losange remplI. Les objets de
8 sont entIerement dpendant de ceux de A.

FIgure 240 : dnotatIon de la composItIon.
En reprenant l'exemple, Dn peut constater qu'un polygone est compos d'un
ensemble de poInts. En utIlIsant l'agrgatIon pour modlIser la mme
sItuatIon, les poInts du plan peuvent tre partags. 0ans la composItIon, Il
n'y a pas de partage : sI deux polygones partagent un sommet, Il exIste deux
poInts dIffrents quI ont des valeurs IdentIques comme coordonnes.
A B
contient
* *
Recettes Ingrdients
Polygones Points
Portefeuilles Placements
* *
* *
* *
A B
compose de
1 *

Polygones Points
1 3..*
ordonnes}

FIgure 241 : exemple de composItIon
Le choIx d'une modlIsatIon dpend essentIellement des opratIons
effectuer sur les polygones :
La composItIon favorIse les dplacements Indpendants des polygones, les
homothtIes de chaque objet. Elle sera adquate pour la rprsentatIon d'un
systeme de logIcIel de dessIn.
L'agrgatIon favorIse le travaIl sur les poInts. En effet, modIfIer la posItIon
d'un poInt entranera la modIfIcatIon de tous les polygones quI le partagent.
Elle sera choIsIe pour la modlIsatIon de treIllIs, comme dans l'exemple,
montrant la modlIsatIon d'un hlIcoptere en fIl de fer .

FIgure 242 : Applet d'anImatIon J0 fIl de fer de Sun

FIgure 24J : exemple classIque des clIents et des commandes.
L'exemple cIdessus est celuI de la commande d'un clIent, une commande
est compose d'une entte et d'un ensemble de lIgnes de commande,
Clients Commandes
Lignes
Articles
Entte
1
1
1
*
1 *
*
1
0e U|L SQL 49
chaque lIgne de commande est assocIe un artIcle. Une commande est
assocIe un clIent.
0ans la programmatIon objet, le faIt de reconnatre une composItIon peut
modIfIer la nature mme de la modlIsatIon : on peut transformer une
composItIon en un type et attrIbuer ce type un attrIbut. 0Ire qu'une
personne est assocIe un domcle par un lIen de composItIon ou spcIfIer
qu'un attrIbut domcle de la personne est du type Adresse est quIvalent.
Dn doIt toutefoIs remarquer que dans le cas ou l'ImplmentatIon se fera
dans une base de donnes relatIonnelle, Il n'est pas possIble d'assocIer des
types complexes un attrIbut. Une telle modlIsatIon relatIonnelle ne seraIt
pas en premIere forme normale 1NF (voIr chapItre sur la dcomposIon). 0ans
notre cas, nous prfrerons toujours explIcIter les assocIatIons.

FIgure 244 : composItIon ou type :

Fentres
Enttes Ascenceurs Panneaux
Libells Boutons
Icnes Comportements
2 1
1
*
4
*
1
1 1

FIgure 245 : Exemple des fentres.
Comme dernIer exemple, nous prenons celuI d'une fentre affIcher sur un
cran d'ordInateur. Une fentre est compose d'une entte, de deux
ascenseurs et d'un panneau. Une entte est compose d'un lIbell et de
Personnes
Nom : string
Prenom : string
Adresses
Domicile
1 * Nom : string
Prenom : string
Personnes'
Nom : string
Prenom : string
Domicile : Adresse
Nom : string
Prenom : string
Domicile : Adresse
quatre boutons. Un bouton est assocI une Icone et un comportement. Dn
remarquera que l'agrgatIon et la composItIon permettent de construIre des
hIrarchIes quI spcIfIent par raffInements successIfs les dtaIls du systeme
modlIser.

Generalisation
Le dernIer concept de la modlIsatIon des classes est celuI de la
gnralIsatIon. L'objectIf de ce concept est de permettre de partager entre
les classes des attrIbuts et des mthodes. Les raffInements successIfs de la
modlIsatIon ne concernent plus les dtaIls structurels d'un objet form par
d'autres objets (le cas de composItIon) maIs un mme objet dont le
comportement se spcIalIse selon la spcIfIcatIon de son Instance. Dn parle
aussI de relatIon d'hrItage. CraphIquement, la sous classe est relIe par
une fleche creuse la classe prIncIpale. Un objet sera une Instance d'une
seule classe. l s'agIt donc d'explIcIter une structure entre les classes.

Gnral
Spcialisation

FIgure 246 : reprsentatIon de la gnralIsatIon.

A'
B'
A
B
A est un B
(tre)
A a des B
(avoir)

FIgure 247 : dIffrence entre gnralIsatIon et composItIon.
Difference entre generalisation et composition ?
0ans le cas de la composItIon, Il exIste des Instances de A' et de 8', les
Instances de A' sont composes par des Instances de 8'. 0ans le cas de la
gnralIsatIon, Il exIste des Instances de A et de 8, maIs leurs Instances ne
sont pas lIes. Les Instances de 8 hrItent du mme comportement que les
Instances de A.
0e U|L SQL 51
Lxemples de generalisation
llustrons ce nouveau concept avec des exemples :
0ans la FIgure 248, on trouve deux spcIalIsatIons de 8ossons, celles Scns
Alcool et celles Alcoolses. Les boIssons Scns Alcool sontelles mmes
spcIalIses en Ecux mnrcles et 1us de Frut. Pour les Alcoolses, on
trouve les \ns et les 8res. l est Intressant de voIr qu'Il exIste des
Instances dans chacune de ces classes, les classes les plus spcIalIses
hrItent de tous les attrIbuts et de toutes les mthodes de leurs anctres.

FIgure 248 : spcIalIsatIon des boIssons
Nous avons donc les Instances suIvantes pour les spcIalIsatIons de boIsson :
o1 : 8oIsson (Nom=lIxIr) ;
o2 : Sans Alcool (Nom=CocaCola, Synthese=ouI) ;
oJ : AlcoolIses (Nom=WhIsky, 0egr Alcool= 45) ;
o4 : Eaux mInrales (Nom=EvIan, Synthese=non, source=EvIan) ;
o5 : Jus de fruIt (Nom=Pommos, Synthese=non, FruIt=pomme,
teneur=15) ;
o6 : 7Ins (Nom=Chteau |argaux, 0egr Alcool= 1J,
FgIon=8ordeaux) ;
o7 : 8Ieres (Nom=|ort SubIte, 0egr Alcool= 5, 8rasseur=
Keermaeker).
La FIgure 249 Illustre la dIffrence entre l'agrgatIon et la composItIon :
l'eau est une boIsson, maIs elle contIent des sels mInraux.
Boissons
Nom : string
Eaux minrales
Source : string
Bires
Brasseur : string
1us de Fruit
Fruit : string
Teneur : integer
Vins
Regions : string
Sans Alcool
Synthese : boolean
Alcoolises
Degre Alcool : integer
Source : string Fruit : string
Teneur : integer
Regions : string Brasseur : string
Degre Alcool : integer Synthese : boolean
Nom : string

FIgure 249 : utIlIsatIon de la composItIon
L'vIan est une eau mInrale, maIs aussI une boIsson sans alcool et
fInalement une boIsson. L'vIan content du NaCl (sel).

Etres vivants
Animaux Vgtaux
Vertbr Invertbrs
Mammifres Rptiles Oiseaux

FIgure 250 : l'hrItage est classIfIant.
La generalisation est classifiante
L'hrItage tablIt un ordre classIfIant entre les dIffrentes sousclasses. Ce
type de classIfIcatIon est bIen connu dans le domaIne de la bIologIe.
A nouveau, l'appartenance d'un IndIvIdu une classe le faIt hrIter de tous
les attrIbuts et de toutes les mthodes des classes parentes (aussI nommes
superclasses).
Cette facette de l'hrItage peut en complIquer son utIlIsatIon. ExamInons la
FIgure 251 : nous avons sparer les surfaces planes en polygones et en
ellIpses, les polygones en rectangles et en trIangles. |aIs peuton vraIment
dIre que :
Eaux
Source : string
Sel Minraux
NomSel : string
Formule : string
composition
quantite : real
* *
Source : string
NomSel : string
Formule : string
quantite : real
0e U|L SQL 5J
un carr est un rectangle :
un cercle est une ellIpse :
Peuton parler de la largeur et de la hauteur d'un carr :

FIgure 251 : l'hrItage n'est pas toujours sImple.
Principe de substitution de Liskov
Le prIncIpe de substItutIon de LIskov [LS94] s'nonce aInsI SI :A est un :8
alors Il doIt tre possIble de substItuer un objet de la classe la plus
gnrale (8) un objet d'une de ses sousclasses (A) sans modIfIer le
comportement du systeme (un programme)
magInons qu'Il exIste une mthode mculer() dans la classe Chcts de la
FIgure 252. Une Instance mnou : de la classe Scmos devIent apres
substItutIon une Instance mnou : de la classe Chcts et doIt donc pouvoIr
mIauler.
Fevenons nos rectangles et nos carrs. Dn peut ImagIner que l'on dcIde
que les carrs sont des rectangles. Pour masquer, le faIt que le carr n'aIt
qu'un cot sIgnIfIcatIf, on ajoute une nouvelle mthode quI crera les carrs
en InItIalIsant la largeur et la hauteur avec la valeur du parametre cot. La
mthode 0oubler() ne faIt plus la dIstInctIon entre la hauteur et la largeur.
La mthode CetCot() permet de retrouver le cot. Cette ImplmentatIon
pour dsavantage d'utIlIser deux varIables pour stocker une seule valeur.
|aIs admettons que nous n'ayons pas de probleme d'espace mmoIre.
Surfaces planes
Polygones
Rectangles
Carrs
Triangles
Ellipses
Disques

Chats
Siamois De gouttire

Rectangles
largeur : real
hauteur : real
DoublerLargeur()
New Rectangle(In largeur:real ,In hauteur:real)
Carrs
GetCote()
Doubler()
New Carre(In cote:real)
largeur : real
hauteur : real
DoublerLargeur()
New Rectangle(In largeur:real ,In hauteur:real)
GetCote()
Doubler()
New Carre(In cote:real)

FIgure 252 : IllustratIon du prIncIpe de substItutIon de LIskov
Le prIncIpe de substItutIon estIl respect : magInons le carr
c :(largeur=8,hauteur=8). SI on le consIdere comme un rectangle, Il est
possIble de luI demander de doubler sa largeur 0oublerLcryeur().
EffectIvement, Il peut se comporter comme un rectangle, maIs se faIsant, Il
perd sa nature de carr. En effet apres l'excutIon de la mthode nous avons
pour c :(largeur=16,hauteur=8).
Cnralement toute spcIalIsatIon quI opere par restrIctIon, ne respecte pas
le prIncIpe de substItutIon de LIskov.
Nous allons voIr que la gnralIsatIon n'est pas toujours utIlIse comme un
outIl conceptuellement structurant, maIs qu'Il peut tre utIlIs par les
dveloppeurs dans les cas suIvants:
Pour propager et partager du code ;
Comme mcanIsme de versIon ;
Comme mcanIsme de rutIlIsatIon.
Iactoriser le code
Prenons le cas d'une tude quI a dj t faIte pour l'tude des trajectoIres
des planetes. Un peu plus tard, Il est demand d'tendre cette tude aux
satellItes. Le programmeur avIs constatera qu'Il possede dj une mthode
pour le calcul en faIsant de Sctellte ; une sousclasse de Plcntes, Il rsout
probablement son probleme.
Cependant, mme sI la trajectoIre des satellItes peut se calculer comme
celle d'une planete, la lune n'est pas une planete.
0e U|L SQL 55

FIgure 25J : hrIter des mthodes
Une telle utIlIsatIon de la gnralIsatIon s'carte d'une modlIsatIon
conceptuelle.
Heritage Multiple
L'hrItage multIple dcrIt le cas ou une classe hrIte son comportement
partIr de plusIeurs classes. Le cas le plus sImple est celuI ou ces classes ne
partagent pas la mme arborescence. 0ans la FIgure 254, les objets de la
classe Plcntes se comportent comme des corps clestes dont on peut
tablIr la trajectoIre, et comme des spheres dont on peut fIxer le dIametre
et dont Il est possIble de calculer le volume. Dn remarquera que l'on a
rsolu le probleme d'hrItage entre Plcntes et Sctelltes en Isolant la
mthode CclculTrc]ectore() dans une classe plus abstraIte.

FIgure 254 : hrItage multIple.
Un cas plus complexe est celuI ou les superclasses partagent la mme
arborescence. 0ans la FIgure 255, les objets de la classe NectarInes se
comportent comme des pches et des prunes. Souvent, l'hrItage n'est pas
complet et Il faut prcIser ce que l'on hrIte de l'un et de l'autre, et ce que
Plantes
Calcul Trajectoire() Calcul Trajectoire()
Satellites
Corps clestes
Calcul Trajectoire()
Satellites Plantes Comtes
Sphres
Volume()
Diametre : real
Volume()
Diametre : real
Calcul Trajectoire()
l'on masque. |taphorIquement, pour les nectarInes on veut l'arome de la
pche et la texture de la peau des prunes.

FIgure 255 : complexIt de l'hrItage multIple.
Covariance
La covarIance permet d'Intgrer plusIeurs crIteres Indpendants dans une
mme arborescence. l s'agIt de classIfIer avec deux crIteres, par exemple.
L'emploI d'un tableau est plus adquat que celuI d'un arbre ! Jouons le jeu
et classIfIons les vhIcules avec un crItere du mIlIeu et un crItere sur la
propulsIon.

FIgure 256 : covarIance une vIsIon possIble
Nous obtenons deux vIsIons possIbles :
FIgure 256, IcI la classIfIcatIon s'effectue d'abord par le mIlIeu et
ensuIte par la propulsIon ;
FIgure 257, la classIfIcatIon s'effectue d'abord par la propulsIon et
ensuIte par le mIlIeu.
Fruits
Pches Prunes
Nectarines
Vhicules
Ariens Nautiques Terrestres
A moteur Sans moteur A moteur' Sans moteur' A moteur'' Sans moteur''
0e U|L SQL 57

Dn constate que l'utIlIsatIon de la gnralIsatIon pour traIter la covarIance
n'est pas adquate. Le nombre de sousclasses au dernIer nIveau peut
devenIr grand. l est gal au produIt du nombre de crIteres chaque nIveau.

FIgure 257 : covarIance une autre vIsIon possIble
Dn prfrera utIlIser l'hrItage multIple telle que dans la FIgure 258. Le
nombre de classes est la somme du nombre de crIteres chaque nIveau.

FIgure 258 : utIlIser l'hrItage multIple :
L'hrItage multIple est complexe utIlIser. Les concepteurs du langage Java
ont prfr l'abandonner au profIt du concept d'Interface. Par exemple, les
classes Ncutques et A moteur devIennent des Interfaces. Dn dIra alors que
la classe Hors bord Implmente les Interfaces Ncutques et A moteur. l
n'exIste donc que des Instances de Hors bord et quI se comporte comme des
vhIcules nautIques et moteur. Pour une dIscussIon plus approfondIe sur ce
sujet voIr [8DN99].
Vhicules
Ariens Nautiques Terrestres
A moteur Sans moteur
Ariens' Nautiques' Terrestres'
Vhicules
Ariens Nautiques Terrestres A moteur Sans moteur
Hors bord Vlos
La FIgure 259 reprend la mme modlIsatIon en utIlIsant le concept
d'Interface. Dn remarquera l'utIlIsatIon sImultane de l'Icone Interface et
de la bote standard. La dpendance d'ImplmentatIon est reprsente par
un traIt dIscontInu.

FIgure 259 : utIlIser l'hrItage multIple :
Les exemples sont souvent purement acadmIques. 0ans la pratIque, la
modlIsatIon de la FIgure 260 en termes de donnes sera souvent largement
suffIsante.

FIgure 260 : parfoIs les choses ne sont pas sI complIques.
interIace~~
Vhicules
Vitesse : real
Ariens
interIace~~
Nautiques
Tirant d'eau : real
Terrestres
interIace~~
A moteur
Puissance : real
Sans moteur
Vitesse : real
Tirant d'eau : real Puissance : real
Hors bord
le hors bord est une
realisation d'un
vehicule nautique a
moteur
Vhicules
Genre : string
Milieu : string
Motorise : boolean
0e U|L SQL 59
3. Les cas d'utilisation
Faire la diffrence entre connaissance et opinions
constitue dj un degr dvolution avanc Le quatrime
royaume-Luis Ansa
Les cas d'utIlIsatIon sont un modele d'U|L ; Ils ont t formalIss par var
Jacobson. Les cas d'utIlIsatIon sont en amont de la conceptIon des systemes
InformatIss. var Jacobson montre dans [JAC92] qu'Ils sont un concept du
gnIe logIcIel. Les cas d'utIlIsatIon donnent une vIsIon des servIces rendus
par le systeme sans entrer dans les dtaIls de leur ralIsatIon. 0es scnarIos
spcIfIent les InteractIons entre les composants du systeme et les acteurs
dclenchent les cas d'utIlIsatIon. l est possIble de repenser ce nIveau les
actIvIts et var Jacobson dcrIt dans [JAC94] comment les cas d'utIlIsatIon
sont adapts au 8PF (8usIness Process FeengIneerIng). Les cas d'utIlIsatIon
sont aussI un lment de la rutIlIsatIon logIcIelle. [JAC97].
Le modele des cas d'utIlIsatIon va spcIfIer le comportement d'un systme
(ou d'une partIe d'un systeme, voIre d'une classe) tel qu'Il apparat un
utIlIsateur extrIeur ce systeme. Les servIces rendus par ce systeme vont
tre IdentIfIs et appels ccs d'utlscton. Les cas d'utIlIsatIon dfInIssent
une transactIon entre le systeme et un ccteur, souvent un utIlIsateur IdalIs
dans un role partIculIer.
Objectifs du modle
La spcIfIcatIon d'un systeme (InformatIs) est un probleme IntrInsequement
complexe, car gnralement la connaIssance des besoIns du systeme
ralIser et la connaIssance des moyens de la ralIsatIon du systeme ne sont
pas dans une mme unIt cognItIve (personne). Cette sparatIon rend
dIffIcIle la communIcatIon. Ces dIffIcults sont quotIdIennes entre ceux quI
exprIment les besoIns du systeme ralIser (les utIlIsateurs) et ceux quI
connaIssent les technologIes pour concrtIser le systeme (les InformatIcIens).
L'objectIf des cas d'utIlIsatIon est de crer un traIt d'unIon cognItIf : Les
utIlIsateurs sont la source d'InformatIon et les crateurs de ce modele. ls
ont la charge de :
0termIner Ies besoIns : seuls les utIlIsateurs sont capables de faIre
ce travaIl, Ils ont des connaIssances profondes du domaIne, Ils savent
ce quI est ncessaIre, Ils connaIssent les raIsons et l'utIlIt des
procdures qu'Ils emploIent.
Comprendre Ies besoIns : en travaIllant la dtermInatIon des
besoIns, on va sImultanment travaIller sur la raIson d'tre de ces
dernIers dans le systeme et l'on aboutIt gnralement un systeme
dont les fonctIonnalIts sont ncessaIres et suffIsantes.
0IImIter Ie systme : fInalement le rsultat sera de fIxer une
frontIere entre l'IntrIeur et l'extrIeur du systeme : ce que fera le
systeme, ce l'on peut attendre du systeme.
Intgrer Ies vues utIIIsateurs : des que le systeme atteInt une
certaIne taIlle, les utIlIsateurs ne possedent qu'une vue partIelle de
l'ensemble. La modlIsatIon des cas d'utIlIsatIon est le lIeu ou ces
connaIssances partIelles peuvent (et doIvent) s'Intgrer.
Dn peut rsumer le modele des cas d'utIlIsatIon par la fIche sIgnaltIque
suIvante :
QuI partIcIpe : Les utIlIsateurs ;
Comment : En langage naturel et avec un formalIsme sImple ;
QuoI : Ce que doIt ralIser le systeme ;
Pour quI : Les InformatIcIens (ventuellement un 8PF du systeme).
Processus de specification des besoins
Commentons la FIgure J1 : Cnralement, travers d'un schma dIrecteur,
l'organIsatIon se fIxe des objectIfs atteIndre en termes de qualIt et de
quantIt. Ces objectIfs sont communIqus aux dIverses structures et
utIlIsateurs de l'organIsatIon. Ces objectIfs demandent la collaboratIon de
plusIeurs dpartements pour tre atteInts.
0ans le cadre de la ralIsatIon d'un systeme d'InformatIon, les responsables
des dIffrents dpartements reoIvent le mandat d'laborer la spcIfIcatIon
d'un systeme d'InformatIon remplIssant les objectIfs de la dIrectIon. Ces
responsables vont dcrIre le systeme ralIser au moyen des cas
d'utIlIsatIon. Ces cas d'utIlIsatIon feront gnralement l'objet d'une
descrIptIon sous forme d'un scnarIo, d'un dIagramme de squence ou de
collaboratIon. Les cas d'utIlIsatIon sont dclenchs par des acteurs externes
au systeme et ne sont donc pas concerns par le dcoupage Interne de
l'organIsatIon. CecI va favorIser l'IntgratIon des vues des dIffrents
responsables.
Le processus de spcIfIcatIon va tre rItr afIn de raffIner les cas, de
prsenter un nIveau de dtaIl suffIsant pour que l'on puIsse effectIvement
ralIser un systeme.
Parallelement, sur la modlIsatIon des cas d'utIlIsatIon, Il est possIble de
revoIr les procdures de gestIon (8usIness process FeegIneerIng ou 8PF).
0e U|L SQL 61

A 8
C
Systeme
aclue|
Schma dIrecteur
StratgIe entreprIse
A
8
C
A 8 C
|AFKET PFD0 FE0
DbjectIfs atteIndre
Cas d'utIlIsatIon
0fInItIon
0Iag
Squence
scnarIo
usIness
PeengIneerIng
Intgrent Ies
vIsIons
SpcIfIent Ies
besoIns
ItratIon
->prcIser
->dIImIter
->raffIner

FIgure J1 : processus de spcIfIcatIon des besoIns.
Processus de developpement
Les dveloppeurs du systeme vont recevoIr comme mIssIon de ralIser un
systeme quI peut s'utIlIser comme dcrIt dans les cas d'utIlIsatIon. l s'agIra
alors de modlIser le systeme avec des classes, des dIagrammes d'tats
transItIons, de dcouper la complexIt du systeme en modules (packages),
de dcrIre le dploIement du systeme dans ces dIffrents composants.
Les cas d'utIlIsatIon vont tre la rfrence durant tout le processus de
dveloppement. l s'agIt de ne pas Inventer ou IntroduIre des comportements
ImagIns par les InformatIcIens.
La procdure de test sera sImple car Il suffIra de suIvre les scnarIos des cas
d'utIlIsatIon et de controler que le systeme peut s'utIlIser comme Il taIt
prvu.
Prcdemment, nous avIons voqu que nous cherchIons satIsfaIre les
crIteres de complexIt, d'volutIvIt, d'ImplmentabIlIt et de robustesse.
Nous cherchons aussI dImInuer la complexIt du systeme, en permettant
aux utIlIsateurs de spcIfIer le systeme. Nous le rendons plus concret car les
utIlIsateurs sont plus centrs sur l'actIon que sur les abstractIons. Au dpart,
les descrIptIons peuvent paratre embrouIlles, maIs au fur et mesure des
ItratIons, les objectIfs de ces actIons vont se dgager. En terme
d'volutIvIt, les cas d'utIlIsatIon sont bIen adapts et sont recommands
pour les 8PF. L'ImplmentabIlIt n'est pas garantIe, maIs elle sera conue
par les besoIns exprIms et gnralement elle est le rsultat d'une
descrIptIon d'une actIon qu'excute dj un utIlIsateur.

Cas d'utIlIsatIon
0fInItIon
0Iag.
squence
scnarIo
classe
InteractIo
n
tat transItIon
ralIsatIon
dployement
Ie systme dveIopper
Ie systme utIIIser
utIIIser
comme
dans Ies cas
0veIoppement
ItratIon
->prcIser
->dIImIter
->raffIner

FIgure J2 : processus de spcIfIcatIon des besoIns.
Stereotypes des cas d'utilisation
Les cas d'utIlIsatIon sont dfInIs avec un formalIsme sImple (Ils doIvent tre
facIlement apprIs par les utIlIsateurs). l exIste troIs concepts :
Le systeme : l s'agIt du systeme dont on doIt spcIfIer le
comportement ; Il tablIt la frontIere entre les acteurs externes au
systeme et les cas d'utIlIsatIon Interne au systeme ;
L'acteur : c'est l'IdalIsatIon d'un utIlIsateur, d'un processus ou d'un
autre systeme entrant en InteractIon avec le systeme dfInIr ;
Le cas d'utIlIsatIon : c'est une actIon consIstante qu'un acteur peut
dclencher en vue d'obtenIr un servIce du systeme. L'excutIon du cas
d'utIlIsatIon est peru comme une transactIon longue. Le cas
d'utIlIsatIon est gnralement dcrIt en dtaIl par un scnarIo.
0e U|L SQL 6J

Acteur

Cas d'utilisation

systeme

FIgure JJ : strotypes des dIagrammes de cas d'utIlIsatIon.
l exIste les relatIons suIvantes entre les concepts des cas d'utIlIsatIon :
Un acteur dclenche un cas d'utIlIsatIon ;
Une personne physIque peut tre assocIe plusIeurs acteurs (roles) ;
PlusIeurs personnes physIques peuvent tre assocIes un acteur (role
gnrIque) ;
Les cas entretIennent des relatIons entre eux. Un cas peut tendre le
comportement d'un autre cas. Un cas peut Inclure l'excutIon d'un
autre cas ;
Les systemes peuvent utIlIser d'autres systemes.

systeme
A
cas1
systeme ext
cas X
cas2
cas3
B
C
extend~~
cas X
include~~

FIgure J4 : nteractIon entre les concepts.
Pour chaque acteur, on donnera une descrIptIon (texte de quelque lIgnes) de
son role gnrIque. Dn dIstInguera :
Les acteurs prncpcux : Ceux quI utIlIsent les servIces du systeme (les
clIents) ;
Les acteurs secondcres: Ceux quI supportent ou maIntIennent le
systeme (par exemple, le postIer, l'employ de banque).
Dn dIstInguera aussI les composants matrIels Internes et externes au
systeme :
Composants Internes : 0es dIsposItIfs matrIels Internes au systeme,
quI sont ddIs l'accomplIssement des actIvIts du systeme (un
ordInateur, une caIsse enregIstreuse, .) ;
Composants externes : 0es dIsposItIfs matrIels externes au systeme,
quI supportent l'accomplIssement des actIvIts du systeme (un
tlcopIeur, une photocopIeuse, un sIte Web, .).
L'accomplIssement d'une actIvIt ncessIte parfoIs l'utIlIsatIon d'un autre
systeme (par exemple, un systeme de paIement par carte)

Entreprise A
Clients Fournisseurs
Acheter Vendre
Produire
include~~
include~~
Visa
paiement paiement
include~~

FIgure J5 : Exemple de dIagramme de cas d'utIlIsatIon.
Dn remarquera que, formellement, le cas Produre n'est pas une ncessIt
de l'entreprIse A. Lors d'une restructuratIon de l'entreprIse, on peut dcIder
de soustraIter la productIon l'extrIeur du systeme (un nouvel acteur
soustraItant). Cette modIfIcatIon ne seraIt pas normalement perceptIble par
le clIent. En effet, le cas vendre demande l'exIstence d'un produIt vendre,
Il ne se proccupe pas de son mode de productIon.
Cas compares aux classes
l nous parat Intressant de comparer les concepts des cas d'utIlIsatIon et
ceux des classes.
Un cas d'utIlIsatIon est le moule de toutes les InteractIons entre l'acteur et
le systeme. Un acteur est celuI quI dclenche l'excutIon du cas d'utIlIsatIon
et quI InteragIt avec ce dernIer.
En termes de classe, chaque cas est donc une classe ayant une mthode quI
correspond au scnarIo dcrIt pour le cas d'utIlIsatIon. L'acteur est une
classe ayant la possIbIlIt d'Invoquer les scnarIos des cas d'utIlIsatIon, de
plus Il possede des InformatIons et des mthodes luI permettant de rpondre
aux sollIcItatIons des scnarIos.

En termes de cas En terme de classe
Cas d'utIIIsatIon : c'est le moule de
toutes les InteractIons entre l'acteur
et le systeme
Classe (scnarIo)
Acteur : dclenche le cas et InteragIt
avec le cas
Classe (acteur)
0cIenchement d'un cas (par un
acteur)
Dbjet (Instance du scnarIo)
0e U|L SQL 65
InteractIons avec le systeme (de
l'acteur)
ExcutIon du scnarIo (messages
changs)
ExamInons le cas de la FIgure J6. Le clent peut dclencher le cas ccheter
auquel est assocI un scncro. En termes de classes, cecI correspond une
classe Clent quI peut Invoquer une mthode ccheter() de la classe
ccsAcheter. Dn remarquera que la mthode ccheter() peut Invoquer des
mthodes de Clent, par exemple pour luI demander son numro de carte de
crdIt.

acreler
C||erl
scnario
C||erl
cas Acreler
dclenche()
....
visa()
acheter()
...
en termes
de classe

FIgure J6 : comparaIson entre la modlIsatIon des classes et des cas.
En termes d'objets, la trace de l'excutIon prcdente laIssera peuttre les
objets de la FIgure J7. Lors de la modlIsatIon des donnes, le scnarIo
d'achat produIra des donnes de la commande.

J. GUYOT:
Script achat:
13/11/2003
CD Bach:
en termes
dobjets

FIgure J7 : Exemple d'objet restant apres l'excutIon du scnarIo.
CecI nous amene mIeux dfInIr les relatIons entre nos concepts. 0ans la
FIgure J8, on dIra que l'acteur A dclenche le cas1. |aIs aussI que A cre
une Instance du scnarIo cas1. Un cas d'utIlIsatIon doIt tre peru comme
une transactIon, c'estdIre que son scnarIo doIt tre droul entIerement
jusqu' une des termInaIsons possIbles.

A
Cas 1

FIgure J8 : relatIon de communIcatIon.
Un cas peut Inclure un autre cas dans son excutIon. 0ans la FIgure J9, une
Instance du cas 1 peut comporter une Instance du cas 2. CecI, nous permet
de dcomposer des cas en souspartIe pour vIter de les rendre trop
complexe ou de partager le scnarIo d'un cas dans plusIeurs autres cas.

FIgure J9 : relatIon d'InclusIon.

Un cas peut tendre le comportement d'un autre cas, on dIra qu'Il le
spcIalIse. 0ans la FIgure J10, une Instance du cas 1 tend le comportement
du cas 2. Comme dans la gnralIsatIon, le cas 1 hrIte des comportements
du cas2.

FIgure J10 : relatIon d'extensIon.
0ans l'exemple de la FIgure J11, nous avons mIs en vIdence les dIffrentes
relatIons. Dn peut lIre sur le dIagramme que :
Un clIent dclenche le cas acheter ;
Le cas acheter peut Inclure une vrIfIcatIon d'IdentIt et une demande
d'expdItIon de catalogue ;
Le cas acheter est tendu en fonctIon de l'Interface utIlIs par le
clIent (tlphone, nternet, mInItel) ;
Le clIent avec tlphone est une extensIon du clIent (cette relatIon
n'est pas explIcIte sur le dIagramme).
Recommandations
Un cas d'utIlIsatIon doIt procurer une valeur ajoute l'acteur quI le
dclenche. SI ce n'est pas le cas, pourquoI dIable, l'acteur dclencheraItIl
une actIvIt sans obtenIr quelque chose en retour :
cas 1 cas 2
include~~
cas 1 cas 2
extend~~
0e U|L SQL 67
Dn lImItera le nombre d'acteurs dclenchant un cas un (en crant des roles
gnrIques sI ncessaIre).

FIgure J11 : Exemple d'objet restant apres l'excutIon du scnarIo.
Dn lImItera le nombre de cas d'utIlIsatIon d'un systeme J0 (lImIte propose
par . Jacobson). Ce nombre peut sembler petIt, maIs Il semble suffIsant
mme pour dcrIre une multInatIonale. SInon on fera usage des relatIons
d'InclusIon et d'extensIon pour rendre plus gnrIque les cas prImaIres.

FIgure J12 : 0Iagramme en radar des crIteres de choIx.
0ans le cas ou l'acteur changeraIt des InformatIons avec le systeme, on
dfInIra ce qu'Il en faIt (crer, sauvegarder, lIre, dcIder, mettre jour, .,
par exemple mot de passe). Dn dcrIra aussI comment on
synchronIse l'acteur et le systeme, c'estdIre comment :
L'acteur Informe le systeme (par exemple, un changement d'adresse) ;
Le systeme Informe l'acteur (par exemple, une lImIte de crdIt).
L'Intrt de la spcIfIcatIon des cas est aussI de pouvoIr prsenter le
systeme sous dIffrents poInts de vue :
achat par correspondance
Client
avec telephone avec internet avec minitel
acheter
expedier catalogue
veriIier identite
interIace minitel interIace telephonique interIace internet
include~~
include~~
extend~~
extend~~ extend~~
par rapport
aux objectifs
intrt pour
l'acteur
levier enjeux (ROI)
par rapport
l'activit
de l'entreprise
risque
dpendance
SI actuel
Par acteur, tous les cas qu'Il dclenche ;
Par cas, tous les acteurs concerns ;
Par causalIt, enchanements de squence d'actIons.
0ans le cas d'une refonte gnrale du systeme d'InformatIon, les cas
peuvent tre utIles pour fIxer les prIorIts de mIse en uvre. Dn peut
retenIr sIx crIteres de choIx et tablIr un dIagramme en radar pour
reprsenter chaque cas en fonctIon de leur Importance (FIgure J12)

Les crIteres retenus sont :
L'Intrt pour l'acteur ;
L'Importance et l'Intrt par rapport aux objectIfs fIxs par
l'entreprIse ;
Le levIer du retour sur InvestIssement ;
Le rIsque (de ne pas le faIre, de modIfIer le cas, .) ;
Les enjeux par rapport l'actIvIt de l'entreprIse ;
La dpendance avec le systeme d'InformatIon actuel (quelles seront
les Interfaces entre le nouveau et l'ancIen)
7oIcI quelques regles pour les scnarIos :
Le scnarIo dcrIt I'actIvIt : Dn dfInIt QuoI est faIt , on ne
prcIse pas le comment , Par exemple : la tlphonIste vrIfIe
l'IdentIt du clIent, on ne dIt pas comment ;
Pester sImpIe : les scnarIos doIvent rester sImples, pas trop long.
Pour vIter la complexIt, dcomposer avec les relatIons utIlIse
et tend ;
AutonomIe : pas de mlange partIel entre les cas (en dehors des
relatIons utIlIse et tend)
StyIe dIrect ImpratIf : ne pas laIsser d'ambIgut, pas
d'approxImatIon, pas de flou dans les textes de descrIptIon. ElImIner
les tres, assez, beaucoup, peu , souvent, en gnral,
exceptIonnellement, . car Il cache quelque chose de non spcIfI.
Le cas est une transactIon Iongue : Il a un dbut, une fIn et on
droule entIerement le scnarIo.
Le cas dIImIte Ia frontIre du systme : ce quI est attendu du
systeme par les acteurs et les InformatIons externes possdes par les
acteurs, ce quI est Interne au systeme, comment Il rend les servIces et
donne les InformatIons Internes mmorIses par le systeme.
utIIIser des Itrateurs IInguIstIques : dans la descrIptIon des
scnarIos, on peut utIlIser les constructIons suIvantes :

0e U|L SQL 69
tant que condton faIre :
...

rpter n foIs :
...

SI condton:
Alors .
SInon .

ChoIx :
Cas 1, condton : ..
Cas 2, condton : ..
Cas J, condton : ..

Ne pas oublIer que c'est une actIvIt des UTLSATEUFS ! Les cas ne sont pas
parfaIts du premIer coup : Il faut rItrer, raffIner, lImIner les flous et les
ambIguts. Pendant le processus de spcIfIcatIon, l'utIlIsateur exprIme et
dcouvre ses besoIns et ses processus de travaIl, des choses dont Il n'est pas
toujours conscIent. L'InformatIcIen peut assIster l'utIlIsateur dans la mIse en
forme du cas. l peut le forcer rester gnrIque (abstractIon), vrIfIer
que cette gnrIcIt couvre les cas concrets et les exemples mIs
dIsposItIon. Dn veIllera aussI rester quIlIbr dans le nIveau de prcIsIon,
c'estdIre de ne pas entrer dans certaIns dtaIls alors que l'on taIt pas
tres prcIs prcdemment. L'utIlIsateur doIt tre expert de son domaIne.
0ans les modlIsatIons Importantes, Il sera ncessaIre de recourIr plusIeurs
utIlIsateurs. Dn aIdera l'utIlIsateur rester dans le QUD, en reformulant
Comment Il faIt en Ce qu'Il faIt .
0ans les processus ItratIfs, Il y a toujours la questIon Quand peuton
s'arrter : . Nous proposons de remplIr les crIteres d'arrt suIvants :
Complet (par rapport aux besoIns) ;
ComprhensIble (pour les dveloppeurs) ;
Couvrant (explore toutes les alternatIves des scnarIos) ;
ntgral ( du poInt de vue des utIlIsateurs).

FIgure J1J : Processus de spcIfIcatIon des cas d'utIlIsatIon.
Lxemple : le restaurant
Prenons le restaurant comme systeme. Les acteurs gravItant autour de ce
systeme sont les clIents et les fournIsseurs. Les clIents se font servIr un repas
et les fournIsseurs vendent des IngrdIents.

Restaurant
Clients
Fournisseurs
Servir un repas Acheter les ingredients

FIgure J14 : Le restaurant.
ScnarIo de servIr un repas :
1. Le clIent entre, laIsse son manteau au vestIaIre.
2. Le clIent est accueIllI par le chef de rang, quI apres examen du
plan de la salle, le place.
J. Le serveur donne la carte au clIent.
4. Le clIent examIne la carte et commande ses plats au serveur
aInsI que les boIssons.
5. Le serveur transmet la commande au cuIsInIer.
6. Le cuIsInIer prpare les plats avec les produIts de base.
7. Les plats prpars sont apports par le serveur.
8. Les boIssons sont prpares et apportes par le serveur.
9. Le clIent mange et boIt.
10. Le clIent demande l'addItIon, le chef de rang la prpare.
11. Le serveur apporte l'addItIon et encaIsse le montant.
besoins
acteurs
utilisateurs
exprime
et dcouvre
cas 1

version -1
version -2
version
raffinement
du scnario
reste en adquation
aux besoins
valider
les rgles
0e U|L SQL 71
12. Le charg du vestIaIre redonne son manteau au clIent.
1J. Le clIent quItte le restaurant.
En examInant le dIagramme de la FIgure J14, on peroIt l'absence de lIens
entre les actIvIts des fournIsseurs et celles des clIents. 0ans la fIgure
suIvante, nous avons corrIg cecI en ajoutant deux cas :
C'est le cas Prparer les menus quI produIra la carte des menus et
quI dclenchera la commandes d'IngrdIents ;
Prparer les repas quI est dclencher chaque occurrence de repas.
Dn constate que la prparatIon des menus rgule le fonctIonnement du
systeme. En effet, la carte des menus doIt correspondre aux IngrdIents
achets. Cette carte est celle quI sera propose aux clIents. La prparatIon
d'un plats concernera donc un plat de la carte et Il se fera avec les
IngrdIents commands.

Restaurant
Clients
Fournisseurs
Servir un repas
Vendre les ingredients Preparer les plats
Preparer les menus
carte
des
menus
include~~
include~~
ingredients

FIgure J15 : Le restaurant : plus de dtaIl
Lxtension pour les processus
Pour spcIfIer certaIns processus, Il est parfoIs plus pratIque de reprsenter
graphIquement le flux. CecI est possIble avec les strotypes suIvant :

Acteur (clIent)

Interface (mIse au vestIaIre, prIse de
commande)

EntIt (carte, plat, boIsson, addItIon)

ContrIeur (prparatIon des plats,
prparatIon de l'addItIon
L'acteur est un agent externe au systeme. l InteragIt avec le systeme
travers les Interfaces. Les entIts sont produItes et consommes par les
Interfaces et les controleurs. Les entIts sont des objets statIques physIques
ou abstraIts. Les controleurs sont processus quI transforment les entIts. En
rsum :
Interface : AffIcher, demander, collecter
EntIt : nformatIon, matIere
ContrIeur :Transformer, controler

commande
note
mange
service plats
prparation
ingrdients
commande
apporte
commande
Client
Client

FIgure J16 : correctIon partIel du scnarIo du restaurant
Ln savoir plus sur UML
Nous avons vu les deux premIers modeles d'U|L, et nous compltons notre
prsentatIon d'U|L par un survol des autres.
U|L c'est sIx modeles:
|odele des cas d'utIIIsatIon : exprImer les besoIns des utIlIsateurs ;
|odele des cIasses : exprImer la structure statIque des objets ;
|odele des tats : exprImer la structure dynamIque des objets ;
|odele des InteractIons : exprImer les InteractIons entre les acteurs
et le systeme, entre les objets ;
|odele de raIIsatIon : exprImer le regroupement et les unIts
logIques de ralIsatIon ;
|odele de dpIoIement : exprImer la rpartItIon physIque des
lments du systeme.
Un modele est la descrIptIon complete depuIs un poInt de vue partIculIer
(celuI des objets, des InteractIons, etc.). Pour exprImer un modele, on
utIlIse des dIagrammes :
0e U|L SQL 7J
Espace |odele projeter sur Espace
0Iagramme

spcIfIer par

FIgure J17 : relatIons entre dIagrammes et modeles en U|L

0Iag.
|odeles
Cas
d'utIlIs
atIon

objet
s
Colla
bora
tIon
squ
ence
s
Clas
ses
tat
trans
ItIon
ActIv
Its
Compo
sants
dploI
ement
Cas d'utIlIsatIon
InteractIon
classes
tat transItIon
ralIsatIon
dploIement

U|L propose 9 types de dIagrammes :
de cas d'utIIIsatIon : Acteurs, actIvItservIce rendu par le systeme ;
de cIasses : structure statIque, classe, assocIatIon, mthode,
hrItage ;
d'objets : exemples d'objet, Instance, valeur, lIen ;
de squences : ordonner messages entre acteurs / objets ;
de coIIaboratIon : changer messages entre acteurs / objets ;
d'tats-transItIons : modIfIcatIon des tats (classe/objet) par les
messages ;
d'actIvIt : structuratIon des actIons (alternatIve, squence,
paralllIsme, .) ;
de composants : regroupement module, package ;
de dpIoIement : dcrIre les objets physIques .
Un modele peut tre projet sur plusIeurs dIagrammes. Par exemple, le
modele des cas d'utIlIsatIon s'exprIme avec un dIagramme partIculIer quI luI
est propre, maIs on peut aussI utIlIser un dIagramme de squence pour
clarIfIer les InteractIons entre les acteurs.
les elements d'UML
Les lments sont les atomes de base des modeles. Une modlIsatIon est un
ensemble d'lments regroups dans un paquetage. Un paquetage peut
contenIr d'autres paquetages. La complexIt est donc gre par un systeme
d'arborescence de paquetage. Un lment a deux reprsentatIons, l'une
destIne sa modlIsatIon et l'autre sa vIsualIsatIon.

Objets
physiq
Cas dùtilisation
Objets Collaborations
Sequences
Classes
Etat - transition
realisation
activites
Deployement
Realise par
Chronologie
scenario
Entre
dans
Realise par
SpeciIie le
comportement
SpeciIie
methode
Syncho
regroupement
repartition
lien
transIormation
Etat
mess
Structuration
action
association
Msg - objet
Entre cas
scenario

FIgure J18 :relatIons entre dIagrammes

visuel
modele
e5
e4
e3
e2
e1
P1
P3 P2
Modele x

FIgure J19 :Un modele est un arbre de paquetages.
Tous les lments d'U|L ont la forme de la FIgure J20. C'est dIre que
chaque lment un nom (par exemple ArtIcle), chaque lment est assocI
un strotype (par exemple classe), chaque lment peut avoIr une lIste
d'attrIbuts (par exemple nombre d'objets = 1000) chaque lment peut tre
assocI avec d'autres lments (par exemple ArtIcle peut tre en relatIon
avec la classe LIgne0eCommande). Chaque lment peut avoIr une note (un
0e U|L SQL 75
commentaIre sur l'objet) et fInalement une expressIon en DCL (Dbject
ConstraInt Language) peut tre assocIe l'lment.
Cette constructIon systmatIque des lments dans U|L en faIt un systeme
ouvert. l est donc possIble de crer de nouveaux strotypes.

FelatIon
(dpendance)

Note

Strotype

Elment

ContraInte
(DCL)

LIste d'attrIbuts

Nom

FIgure J20 : Structure de base d'un lment
UML : un systme ouvert
U|L s'Impose comme un standard de l'InformatIque et de la communIcatIon.
U|L est avant tout une notatIon et non une mthode. l ne dIcte donc pas le
processus d'laboratIon de la modlIsatIon. l est donc ouvert aux socIts de
servIce, dIteurs de logIcIel, mthodologues quI peuvent y ajouter une
valeur propre. Plus gnralement, on peut ajouter sImplement des
strotypes, maIs Il est aussI envIsageable d'ajouter des nouveaux types de
dIagrammes ou mme des modeles.
La descrIptIon du systeme d'InformatIon d'une entreprIse peut tre
mmorIse dans un dIctIonnaIre structur avec U|L. Et autour de ce
dIctIonnaIre, on trouvera les dIffrents outIls : de modlIsatIon graphIque,
de conduIte de projets, de gnratIon automatIque de code, etc.
Lxercice
1) 0crIre completement le flux des processus du restaurant.
2) Prendre un autre type de lIeu de vente de nourrIture tel que :
la caftrIa de l'unIversIt ;
un |ac 0onalds ;
un Kebab.
0crIre le cas d'utIlIsatIon prendre un repas , le flux des processus et
montrer le reenyneerny du processus en termes d'conomIe par rapport au
scnarIo classIque du restaurant. (0ans ces tudes de cas, une pIle de
plateau, une poubelle peuvent tre des Interfaces au systeme !)
0e U|L SQL 77
4. Sortir de la confusion
|odlIser, c'est accepter de prendre le rIsque de montrer en tant que
dbutant une certaIne confusIon. l n'est pas aussI vIdent qu'Il n'y parat de
dcIder sI quelque chose est une classe, un attrIbut, une mthode ou une
assocIatIon. PIre, dans un contexte on choIsIra un attrIbut et dans l'autre
une classe. A prIorI, Il n'y a pas de modlIsatIon fausse, Il y a seulement des
modlIsatIons quI ne refletent pas la ralIt. La seule faon de sortIr de la
confusIon c'est de modlIser, de prendre un crayon, une feuIlle et
d'accepter les regles d'un jeu quI consIste reprsenter la ralIt dans des
botes relIes par des lIgnes.
Lxercices
La compagnIe TT
J
est le champ d'applIcatIon quI nous servIra de fIl
conducteur pour les exercIces. 0ans certaIns cas, nous ajouterons des
exercIces spcIfIques. 0ans les annexes, vous trouverez d'autres champs
d'applIcatIon, dont certaIns avec des corrIgs.
Prendre les domaInes suIvants et dcrIre les classes et les assocIatIons:
C0|usIque
K77Ido
Composant (d'une voIture)
UnIversIt
8IblIotheque
Agence de voyage
.
Avant de commencer, nous allons faIre un mInIcas d'utIlIsatIon pour fIxer un
contexte de modlIsatIon!
Lxercice sur RLCL11L

FaIre le dIagramme de classes d'un systeme quI devraIt permettre de
mmorIser les IngrdIents ncessaIres une recette de cuIsIne.
Lxercice sur 11
3
FaIre le dIagramme de classes de TT
J
.
Lnonce de 11
3

La compagnIe de transport TT
J
(Tout Transport, Tout Type, Tout Temps) a
choIsI de se dIversIfIer. Son domaIne d'actIvIt prIncIpal est lI aux taxIs et
aux transports de groupes. Cette dIversIfIcatIon rcente a entran des
problemes de gestIon et la dIrectIon a comprIs que les dIffIcults taIent en
partIe IncrImInables l'obsolescence de son systeme d'InformatIon. La
dcIsIon d'InformatIser a t prIse. Le P0C de la compagnIe, sur les conseIls
d'un amI, a dcId de procder une modlIsatIon du champ d'applIcatIon
avant d'acheter les ordInateurs personnels que luI rclament les
gestIonnaIres de la compagnIe (proverbe du routIer: Ne pas mettre la
charrue avant les bufs).
Le champ d'applIcatIon couvert par les ImpratIfs de la gestIon de cette
compagnIe de transport concerne le parc des vhIcules, son entretIen,
l'admInIstratIon des chauffeurs et de leur emploI du temps, la gestIon des
appels des clIents la centrale tlphonIque.
Le texte quI suIt est une descrIptIon du champ d'applIcatIon tel qu'Il
apparat la suIte d'une runIon avec les dIffrents cadres de la dIrectIon
(les mots en style gras sont les constItuants quI sont retenus dans la
modlIsatIon).
Compte rendu de la runIon:
Pour le chef mcanIcIen, un vhIcule est IdentIfI par un numro de chssIs
noChassIs. Chaque vhIcule possede un numro de plaque noPIaque aInsI
qu'une date de mIse en servIce mIseEnServIce. Le parc de vhIcules est
dIvIs en plusIeurs types. Un type est connu par le modele modIe, par
exemple: |ercedes J00. Un vhIcule ne peut bIen entendu appartenIr qu'
un seul modele. La descrIptIon d'un modele permet de connatre le nombre
de personnes pouvant prendre place dans les vhIcules nbPIaces de ce
modele; le type de carburant typeCarburant consomm; la catgorIe de
permIs catgorIe que doIt possder le chauffeur; le type de bote vItesses
automatIque et le poIds du modele poIds.
Un des objectIfs de ce systeme d'InformatIon est de surveIller la
consommatIon journalIere en carburant des vhIcules. AInsI une
augmentatIon de cette consommatIon sera le sIgne que le moteur ncessIte
un rglage. A chaque foIs que le chauffeur faIt le pleIn, Il remplIt une fIche
IndIquant le numro de plaque, la date noJour, le nombre de kIlometres
rouls depuIs le dernIer pleIn kIIometrage, la quantIt IItres et le type de
carburant mIs dans le rservoIr.
L'quIpe des mcanIcIens s'occupe de l'entretIen. Ce quI est mmorIs sur
l'entretIen des vhIcules est donn par une descrIptIon descrIptIon assocIe
une date et un numro de chassIs.
Le responsable de la planIfIcatIon a besoIn des InformatIons suIvantes pour
tablIr l'emploI du temps de ces chauffeurs. l dIspose jusqu' maIntenant
de fIches sur les chauffeurs ou l'on trouve le numro du chauffeur
noChauffeur, son nom nom, son prnom prnom, son adresse adresse. La
fIche contIent aussI un emplacement ou sont notes les catgorIes de permIs
que possede le chauffeur.
0e U|L SQL 79
L'emploI du temps des chauffeurs et des vhIcules est dfInI sur un grand
tableau quI occupe une paroI entIere de son bureau. Les numros des chssIs
des vhIcules se trouvent sur les enttes de lIgne. Les enttes de colonne
sont des dates subdIvIses en troIs tranches horaIre trancheHoraIre. Un seul
numro de chauffeur est InscrIt dans une case du tableau.
Le responsable de planIfIcatIon doIt faIre attentIon ce que les modeles
conduIts par les chauffeurs soIent compatIbles avec les permIs qu'Ils
possedent.
Pour grer les appels tlphonIques, le central tlphonIque est quIp d'un
systeme quI permet aux chauffeurs de donner leur posItIon en IndIquant la
zone noZone dans laquelle Ils sont Inoccups avec un vhIcule. Lorsqu'un
clIent demande un taxI, Il suffIt de luI assIgner un vhIcule dans sa zone de
prIse en charge. SI aucun taxI ne se trouve dans la zone, Il faut trouver le
plus proche vhIcule. AfIn d'effectuer cette recherche d'une manIere
optImale, Il exIste des tabelles, quI, pour chaque heure de la journe heure,
IndIque le temps de parcours tempsParcours d'une zone zone0e une autre
zoneA. Dn encode aInsI le varIatIon de fluIdIt du trafIc dans la vIlle au
cours de la journe.
La compagnIe TT
J
est rpartIe dans la vIlle en statIons ou sont gars les
vhIcules. Une statIon possede un numro de statIon noStatIon. La statIon se
trouve dans une zone. Un vhIcule est assocI une seule statIon. Un
chauffeur est aussI assIgn une et une seule statIon. C'est cette statIon
qu'Il vIent prendre et rendre son vhIcule.
Correction RLCL11L

FIgure 41 : 0Iagramme de classes (recettes et IngrdIents)

Recettes
nom : string
nombrePers : integer
diIIiculte : integer
prix : integer
NbrDeCalorie()
preparation : string
Ingrdients
nom : string
uniteDeMesure : string
nbreDeCalorie : integer
Compose
qte : integer
nom : string
nombrePers : integer
diIIiculte : integer
prix : integer
NbrDeCalorie()
nom : string
uniteDeMesure : string
nbreDeCalorie : integer
qte : integer
elaborer avec
1..* *
preparation : string
Correction 11
3

FIgure 42 : |odlIsatIon des classes de TTJ

Chauffeurs
noChauIIeur : integer
nom : string
prenom : string
adresse : string
Permis
categorie : string
Types
modele : string
nbPlaces : integer
automatique : boolean
poids : integer
TypeCarburants
TypeCarburant : string TypeCarburant : string
modele : string
nbPlaces : integer
automatique : boolean
poids : integer
categorie : string
noChauIIeur : integer
*
Planning
noJour : integer
trancheHoraire : string
1
necessite
possede
1
Vhicules
miseEnService : date
noChassis : integer
noPlaque : integer
Distances
tempsParcours : integer
heure : integer
miseEnService : date
noChassis : integer
noPlaque : integer
tempsParcours : integer
se trouve
1
Entretiens
noJour : integer
description : string
noJour : integer
description : string
*
1
eIIectue
Carburants
noJour : integer
kilometrage : integer
litre : integer
noJour : integer
kilometrage : integer
litre : integer
* 1
1
*
1
deIinit
consomme
avec
*
plein du
heure : integer
de
*
1
utilise
*
Stations
noStation : integer
Zones
noZone : integer
noStation : integer
gare dans
*
1
*
noZone : integer
1
a
1
*
1
*
1
assigne a
*
*
*
1
*
nom : string
prenom : string
adresse : string
noJour : integer
trancheHoraire : string
horaire
*
0e U|L SQL 81
S. Lncore une introduction
"le pluralisme des thories et des conceptions
mtaphysiques n'est pas seulement important pour la
mthodologie, c'est aussi un lment essentiel dans une
perspective humaniste." (Paul Feyerabend - Contre la
mthode)
0ans la premIere partIe, nous avons vu comment spcIfIer un systeme. l
exIste plusIeurs possIbIlIt pour Implmenter le systeme. Nous nous
restreIgnons IcI au cas ou les InformatIons devraIent tre mmorIses dans
une base de donnes. Les bases de donnes relatIonnelles sont au centre des
systemes d'InformatIon modernes. La standardIsatIon du langage SQL en 1987
et la mIse en rseaux des postes de travaIl mettent dIsposItIon de tous les
donnes de l'entreprIse, pour tre analyses, mIses en page, mdIatIses.
Les tableurs et des outIls graphIques offrent des facIlIts de connexIons aux
bases de donnes travers D08C (Dpen 0ata 8ase ConnectIvty). Les sItes
Web sur nternet sont gnralement construIts autour de bases de donnes.
Pour effectuer ce passage du fIchIer la relatIon, du programme la
requte, deux lments sont IndIspensables: les concepts de base du modele
relatIonnel et sa mIse en applIcatIon avec le langage SQL.
Une modlIsatIon relatIonnelle est la concrtIsatIon d'une modlIsatIon de
classe. Le modele des classes est un outIl pour la conceptIon. Le modele
relatIonnel est un outIl pour la ralIsatIon du systeme. La thorIe prsente
est la cl de lecture de cette modlIsatIon, elle permet d'en valuer les
adquatIons et les lImItes.
SQL est le langage de gestIon de bases de donnes relatIonnelles, Il permet
l'InterrogatIon et la manIpulatIon de ces donnes. Son unIversalIt permet
d'accder aux systemes de gestIon de bases de donnes (SC80) de la plupart
des constructeurs, de l'ordInateur central d'une multInatIonale au portable
d'un reprsentant.
Seule la comprhensIon du modele relatIonnel est garante d'une
InterprtatIon smantIque correcte des donnes mmorIses dans un SC80.
|algr que la plupart des SC80 propose des Interfaces graphIques pour
l'InterrogatIon, la connaIssance syntaxIque de SQL est ncessaIre pour une
exploItatIon effIcace du SC80. cI, toutes les regles du langage SQL sont
reprsentes par des dIagrammes syntaxIques, une forme graphIque de
spcIfIcatIon des langages.
Cette partIe de l'ouvrage est labor autour des troIs problmatIques
prIncIpales du modele relatIonnel: l'InterrogatIon comment Interroger une
modlIsatIon pour avoIr une rponse fIdele au champ d'applIcatIon; les
modIfIcatIons comment modIfIer le contenu de la base pour contInuer
reflter la ralIt modlIse; les regles d'IntgrIt comment Intgrer dans
la modlIsatIon les contraIntes de gestIon perues dans la ralIt. Ces
problmatIques sont abordes sparment, puIs sImultanment, dans le
cadre des formes normales.
FInalement, nous abordons le theme concernant l'optImIsatIon des requtes,
la scurIt des donnes et un exemple InformatIque de reprsentatIon
physIque des relatIons.
0es exemples dIvers Illustrent la thorIe et la pratIque de SQL. Une tude de
cas corrIge, prsente comme exercIce, accompagne le lecteur, la fIn des
chapItres.
Des fichiers aux relations
La premIere applIcatIon d'un traItement automatIs de l'InformatIon est celle
du recensement amrIcaIn de 1890 [CDL72], Herman HollerIth met au poInt
une machIne lectromcanIque capable de trIer et de compter des cartes en
fonctIon des trous quI y sont prsents. 0j la standardIsatIon est prsente,
la carte est au format du bIllet d'un dollar (la fabrIcatIon des cartes est donc
assure). 288 trous peuvent tre effectus. Lors du recensement, les crIteres
retenus sont traduIts avec des trous sur la zone rserve de la carte
correspondant ce crItere pour un IndIvIdu. Chaque crItere demandera un
mIllIard de trous, pour dcrIre les 6J'000'000 d'habItants. |aIs pour la
premIere foIs, Il est possIble de rpondre des questIons telles que:
Le nombre d'enfants ns ;
Le nombre d'enfants vIvants ;
Le nombre de famIlles parlant l'anglaIs.
La mthode et les machInes de HollerIth furent un succes. Dn y retrouve les
IngrdIents d'une base de donnes actuelle, les entIts, les proprIts
pertInentes retenIr, les modeles physIques, les requtes.
Pendant un demIsIecle la technIque du traItement des cartes perfores (la
mcanographIe) sera l'Instrument domInant du traItement de l'InformatIon.
0urant cette prIode, l'ordInateur sera exclusIvement un outIl de calcul. En
1950, dans The federal computIng machIne program, [FEE50] |Ima Fees
parle d'une utIlIsatIon possIble d'un ordInateur ayant pour spcIfIcIt
d'accepter un grand nombre de donnes en entre, d'effectuer peu
d'opratIons et de produIre une grande quantIt de rsultats. C'est le dbut
d'une ere ou l'ordInateur n'est plus un outIl destIn aux scIentIfIques et aux
mIlItaIres maIs comme un outIl pouvant tre utIlIs dans la gestIon de
l'InformatIon. L'UN7AC (1951) sera la machIne cIvIle type de gestIon,
quIpe d'ImprImantes haut dbIt et supportant jusqu' dIx lecteurs de
bandes magntIques. 0urant la mme dcennIe, on trouve la 8Z|AC, conue
par FCA, quIpe de 200 lecteurs de bandes quI prfIgure ce que sera une
0e U|L SQL 8J
grande base de donnes (pour un expos complet lIre une hIstoIre de
l'InformatIque de P. 8reton [8FE90]).
Parallelement au dveloppement des machInes, nous avons celuI des
langages InformatIques. Avec le langage FLDW|ATC (1955) de la compagnIe
UnIvac, nat le premIer langage destIn l'InformatIque de gestIon. Ce
langage demandaIt dj une descrIptIon spare des donnes et des
InstructIons. Ce concept fut ensuIte reprIs lors de la dfInItIon du langage
CD8DL (1960).
La cratIon d'applIcatIons programmes en CD8DL utIlIsant des fIchIers de
donnes mettra en vIdence deux dIffIcults dues la structure physIque des
donnes quI doIt tre ncessaIrement connue par le programmeur lors de
l'crIture du programme. La premIere dIffIcult rsIdaIt dans le rapport de
dpendance entre la reprsentatIon de l'InformatIon et le support physIque
des InformatIons (les bandes, les tambours et ensuIte les dIsques). CellecI
rendaIt dIffIcIle le transport des donnes d'une InstallatIon une autre. La
deuxIeme dIffIcult taIt due la redondance des fIchIers ayant des
structures dIffrentes maIs des InformatIons communes, ce quI empchaIt
toute centralIsatIon et partage des InformatIons. Chaque applIcatIon
possdaIt ses propres fIchIers et ses propres programmes. Les
IncompatIbIlIts de structure lImItaIent la concertatIon, le partage des
donnes et le travaIl en quIpe quI sont ncessaIres pour ralIser les
dIffrentes applIcatIons travaIllant sur les donnes communes une
entreprIse.
Ces faIts furent dtermInants dans la recherche de concepts favorIsant
l'Indpendance des traItements par rapport aux donnes. Les bases de
donnes apportent une solutIon ces problemes en proposant un langage de
descrIptIon des donnes et un langage de manIpulatIon des donnes; les
programmes peuvent tre alors crIts Indpendamment de la structure
physIque des donnes. TroIs modeles furent largement utIlIss:
Le modele hIrarchIque ;
Le modele rseau ;
Le modele relatIonnel.
0ans un fIchIer (1950..), les donnes d'un mme objet sont dfInIes par un
enregIstrement physIque, l'ensemble des enregIstrements physIques
constItue le fIchIer. La descrIptIon de l'enregIstrement est ImplIcIte et elle
est code dans les programmes quI utIlIsent le fIchIer. SI l'on modIfIe la
structure du fIchIer, on est donc oblIg de modIfIer les programmes. Les
systemes de base de donnes contournent cet InconvnIent majeur en
rendant expIIcIte Ia structure des donnes, rendant aInsI Indpendants les
programmes de la reprsentatIon physIque. Les SC80 possedent donc tous
une descrIptIon explIcIte de la structure de donne, maIs Il exIste plusIeurs
faons de dcrIre les lIens exIstant entre les objets du champ d'applIcatIon;
on parle alors de modele de donnes.

FIgure 51 : Exemple avec le modele hIrarchIque
0ans le modele hIrarchIque (1965...),les lIens exIstant entre les objets sont
strIctement arborescents. Un dpartement contIent des employs; un
employ travaIlle dans des projets; un hIstorIque des salaIres correspond
un employ.
0ans l'exemple, on remarquera que sI une feuIlle de l'arbre doIt tre utIlIse
dans une autre arborescence Il faudra la duplIquer. Par exemple, pour
trouver tous les employs d'un projet, Il faut soIt parcourIr toutes les feuIlles
de l'arbre ou bIen crer une autre arborescence dont la racIne est PFDJET.
0ans le premIer cas, la recherche est longe car exhaustIve et squentIelle.
0ans le second, la seconde arborescence cre des redondances d'InformatIon
quI seront couteuses en programmatIon. |S est l'exemple typIque de SC80
hIrarchIque.
Le modele rseau (1965..) est une extensIon du modele prcdent, les lIens
entre objets peuvent exIster sans restrIctIon.
Pour retrouver une donne dans une telle modlIsatIon, Il faut connatre le
chemIn d'acces (les lIens), cecI rend encore les programmes dpendants de
la structure de donnes. Le noeud E|PPFDJET permet de trouver les projets
d'un employ et les employs d'un projet. CecI reprsente une amlIoratIon
car cela supprIme la redondance.

DEPARTEMENT
NODPT, NOMDPT
EMPLOYE
NOEMP, NOMEMP, DATE-EMB
PROJET
NOPJ, NOMPJ,RESP-PJ
ANNEE, SAL
SALAIRE
EMP-PROJET
NOPJ, NOEMP, DUREE

FIgure 52 : Exemple avec le modele rseau
Cependant s'Il n'exIste pas le chemIn (lIen) entre deux noeuds, nous
retombons dans le parcours squentIel exhaustIf. Par exemple, pour la
questIon quel est le salaIre moyen des chefs de projets Il manque le lIen
entre les chefs de projets et les employs Les logIcIels 0|S, TDTAL, |08S
taIent des SC80 de ce type.
DEPARTEMENT
NODPT, NOMDPT
EMPLOYE
NOEMP, NOMEMP, DATE-EMB
PROJET
NOPJ, NOMPJ,RESP-PJ ANNEE, SAL
SALAIRE
0e U|L SQL 85
Le modele relatIonnel (1970..) est bas sur la notIon de relatIon. Une
relatIon est un ensemble de nuplets (n est fIxe) quI correspondent chacun
une proprIt de l'objet dcrIre.

DEPARTEMENT
NODPT NOMDPT
PROJET
NOPJ NOMPJ RESP-PJ NODEPT
EMPLOYE
NOEMP NOMEMP DATE-EMB
N
NODPT
EMP-PROJET
NOPJ NOEMP DUREE

FIgure 5J : Exemple avec le modele relatIonnel
0EPAFTE|ENT, PFDJET, E|PLDYE, E|PPFDJET sont des relatIons. Les lIgnes
dessInes en poIntIll sont les lIens smantIques entre les relatIons, maIs IcI
Il n'est plus ncessaIre de dcrIre explIcItement les lIens, les chemIns d'acces
sont Indpendants de la modlIsatIon.
Dn trouvera un hIstorIque complet des modeles hIrarchIques et rseaux
dans [FFY76] et dans le lIvre de C. 0elobel et |. AdIba [0EL82], un exemple
est traIt dans les troIs modeles.
L'hIstoIre des bases de donnes est essentIellement une hIstoIre de
l'Indpendance des donnes et des traItements, elle se poursuIt
actuellement avec celle des bases dIstrIbues ou le demandeur d'InformatIon
se trouve devant une base de donnes vIrtuelle dont la localIsatIon physIque
(processeurs) est dIstrIbue sur un rseau.
Problematique des bases de donnees
Une base de donnes est un ensemble structur de donnes enregIstres sur
des supports accessIbles par l'ordInateur pour satIsfaIre sImultanment
plusIeurs utIlIsateurs de faon slectIve et en un temps opportun [0EL82]
Cette dfInItIon artIcule les dIffrents lments que nous allons traIter:
Les donnes de la 80 reprsentent des faIts, des actIvIts ou des
vnements de l'entreprIse. La 80 doIt tre consIdre comme la mmoIre
de l'entreprIse. 0e ce faIt, le contenu de la 80 doIt tre:
pertInent (donnes utIles) ;
fIable (donnes cohrentes et justes dans le sens de vraI par rapport
au champ d'applIcatIon) ;
utIlIsable (accessIble aux traItements).
Les objets mmorIss dans la 80 possedent des proprIts communes,
permettant aInsI de les regrouper par type d'objet. La structure de la 80 est
le plcn quI permettra d'Interprter les donnes stockes. La gestIon de la
base de donnes se faIt par rapport cette structure.
La base de donnes peut comporter quelques mIllIers de caracteres pour une
petIte base sur mIcroordInateur, donc elle peut tre stocke sur dIsquette
ou bIen elle est constItue de plusIeurs mIllIards de caracteres et elle doIt
tre stocke sur des unIts de dIsques d'un ordInateur. |algr les dIffrences
de taIlles, les technIques et les concepts utIlIss sont sImIlaIres. La base de
donnes est Indpendante de son support.
Les donnes mmorIses sont appeles tre utIlIses par dIffrents
servIces de l'entreprIse, avec des utIIIsateurs appartenant prIncIpalement
troIs catgorIes:
Les InformatIcIens; grant la 80, concevant les nouvelles applIcatIons ;
Les utIlIsateurs cverts; sachant faIre des requtes d'InterrogatIon pour
leurs propres besoIns quI ne sont pas spcIfIables (les gestIonnaIres) ;
Les utIlIsateurs nc]s; dont la tche est entIerement spcIfIable
(rptItIve), saIsIe de l'InformatIon .
La 80 est surtout utIlIse en InterrogatIon, le langage d'InterrogatIon est
donc un lment essentIel du systeme, Il doIt tre:
facIle apprendre (pour les utIlIsateurs avertIs) ;
masquer la structure physIque de la base de donnes (ndex,
parametres, ...) ;
avoIr une smantIque claIre (comprendre le sens de la questIon et de
la rponse).
Par temps opportun, on entend que sI l'InformatIon exIste dans la 80, alors
on peut l'obtenIr dans un dlaI raIsonnable (court sI l'on travaIlle de manIere
InteractIve (guIchet de banque) ou temps (pour prendre une dcIsIon).
Les objectIfs de I'organIsatIon
L'utIlIsatIon des bases de donnes peut aussI se consIdrer sous l'angle
organIsatIonnel. La conceptIon d'une applIcatIon 80 est une opratIon
demandant des ressources fInancIeres (achat des ordInateurs, logIcIel de
gestIon de 80, ...) aInsI que des ressources humaInes (concepteur,
programmeur, opratrIces de saIsIe, ...), Il est donc Important que
l'organIsatIon examIne les avantages qu'elle doIt en retIrer. Les arguments
suIvants peuvent motIver l'organIsatIon:
sImplIfIer une tche de l'entreprIse ;
augmenter la qualIt d'un servIce ;
permettre une meIlleure prIse de dcIsIon ;
rentabIlIser les ressources matrIelles et humaInes.
En rsum, la 80 doIt conserver les donnes stratgIques de l'entreprIse pour
que l'on puIsse les utIlIser d'une manIere optImale. Les objectIfs de
l'entreprIse peuvent s'chelonner en plusIeurs tapes ou bIen voluer dans le
0e U|L SQL 87
temps, d'ou l'Importance d'une conceptIon et d'un systeme de gestIon de
base de donnes (SC80) autorIsant les volutIons et les modIfIcatIons.
Les objectIfs de l'organIsatIon dlImItent un champ d'appIIcatIon dans la
ralIt dont la 80 est le reflet. L'tablIssement d'un schma dIrecteur
[HDU88] ou les cas d'utIlIsatIon [JAC94] permettent de cerner les objectIfs
et le champ d'applIcatIon. Ses lments fInaux sont:
les traItements effectuer ;
les requtes d'InterrogatIon excuter ;
les donnes ncessaIres mmorIser ;
les regles d'IntgrIt respecter.
0ans l'exemple HDTEL, quI nous accompagnera dans cet ouvrage, plusIeurs
domaInes d'applIcatIon sont possIbles et Interdpendants. La dtermInatIon
de l'appartenance d'un objet un domaIne se faIt en examInant les objectIfs
fIxs par l'organIsatIon.

FIgure 54 : 0omaInes de notre exemple Hotel
Les traItements de l'applIcatIon sont dfInIs par toutes les modIfIcatIons
envIsages sur les donnes de la 80. TroIs types d'actIons prImItIves sont
possIbles:
La cratIon; un objet nouveau apparat dans la ralIt et celuIcI est
dans le champ d'applIcatIon, donc Il doIt tre enregIstr dans la base
de donnes (un nouveau clIent) ;
La mIse jour; un objet dj enregIstr dans la 80 se modIfIe et cecI
doIt tre report dans la 80 (changement dans la quantIt stocke d'un
artIcle) ;
La destructIon; un objet enregIstr dans la 80 sort du champ
d'applIcatIon et doIt donc tre lImIn de la 80 (changement d'anne
comptable, un salarI quItte l'entreprIse).
Les traItements permettent de modIfIer la 80 pour tenIr compte des
changements Intervenant dans la ralIt du champ d'applIcatIon.
Pour les InterrogatIons, Il s'agIt d'IdentIfIer les besoIns de chaque utIlIsateur
devant accder la 80, en se posant les questIons suIvantes:
Quelles sont les InformatIons de la 80 ncessaIres l'accomplIssement
de la tche de cet utIlIsateur (le magasInIer, la rceptIonnIste de
l'hotel):
SERVICE
ETAGE
COMPTA
BILITTE
RESERVATION
CUISINE
PERSONNEL
MENU,QUANTITE, ...
Quelle est la frquence de ces questIons, le temps de rponse exIg:
Le couple (100 req/jour, 15 secondes) sera examIn dIffremment de
celuI (1 req/moIs, dans la matIne).
QuI peut examIner et modIfIer les InformatIons: Ce poInt concerne le
degr de confIdentIalIt et de scurIt de chaque InformatIon.

FIgure 55 : |odIfIcatIon par rapport la frontIere du champ d'applIcatIon
Les donnes mmorIser dans la 80 sont celles dfInIes par le champ
d'applIcatIon. Les traItements les crent, les mettent jour et les
dtruIsent. Les requtes d'InterrogatIon les utIlIsent en lecture pour
rpondre aux utIlIsateurs. Nous avons vu que c'est dans le cadre de la
dfInItIon du champ d'applIcatIon que la slectIon des donnes s'effectue. Le
choIx des proprIts enregIstrer dans la 80 doIt tre ncessaIre et
suffIsant pour excuter les traItements et rpondre aux requtes
d'InterrogatIon:
ncessaIre: court terme, pour tre aussI effIcace que le systeme
remplac et moyen terme, pour rpondre de nouvelles questIons
(que l'on vIte de se poser car dans un systeme manuel, elles sont trop
onreuses).
suffIsant: pour vIter de mmorIser des InformatIons quI seront peu ou
pas utIlIses.
Pour une personne, nous pouvons la dfInIr par exemple: nom, prnom,
taIlle, professIon, adresse, numro de tlphone, revenu, poIds,
appartenance polItIque, sports pratIqus, tat cIvIl, nombre d'enfants, .....
Chacune de ces proprIts a un sens dans un contexte bIen dfInI, par contre
elles sont InutIles dans un autre.
Chaque InformatIon (compte en caracteres) a un prIx calcul avec les couts
suIvants:
cout de saIsIe (opratrIce, poste de saIsIe)
cout de stockage (dIsques, bandes d'archIvage)
cout de manIpulatIon (taIlle ordInateur ...)
"ralit"
champ
d'application
destruction
cration
mise jour
0e U|L SQL 89
Les rgIes d'IntgrIt refletent les reglements de l'organIsatIon, le bon sens
de la ralIt. Dn peut les exprImer:
sur Ies donnes; le faIt que la 80 respecte les regles d'IntgrIt
permet d'assurer une certaIne cohrence des donnes, donc assure aux
utIlIsateurs des InformatIons de qualIt (Une chambre n'est rserve
qu'une foIs, les quantIts du stock sont posItIves, les clIents ont plus
de 18 ans, ...).
sur Ies traItements; IcI Il s'agIt d'exprImer l'ordre dans lequel doIvent
s'effectuer les modIfIcatIons de la 80.
Nous pouvons constater que les prIncIpaux lments cIts sont
Interdpendants. 0e plus, dans une approche classIque [8DE76], chaque
lment doIt traverser plusIeurs tapes dans le processus de conceptIon:
Analyse des besoIns: par rapport aux objectIfs de l'organIsatIon
SpcIfIcatIon: une descrIptIon prcIse de chaque lment
ConceptIon nformatIque: une descrIptIon de l'ensemble du systeme en
termes InformatIques
Codage: chaque lment est cod dans le langage supportant la
gestIon de la 80
Test
|aIntenance
Pour assIster l'quIpe de conceptIon, Il exIste des mthodologIes et des outIls
InformatIques. CeuxcI permettent de guIder la conceptIon, de construIre
des prototypes et mme de gnrer le code. Leur utIlIsatIon est dlIcate et
elles demandent que le concepteur soIt conscIent des Impasses et de leurs
lImItes. Cependant elles peuvent assurer un role de communIcatIon au seIn
d'une quIpe.
SQL - Langage des bases de donnees relationnelles
SQL est l'acronyme de Structured Query Langage. A l'orIgIne, Il n'taIt
destIn qu' l'InterrogatIon des bases de donnes, maIs Il fut tendu la
spcIfIcatIon des donnes, des prImItIves de modIfIcatIon et la spcIfIcatIon
des regles d'IntgrIt d'une base de donnes.
HIstorIquement, c'est l'artIcle de E.F. Codd [CD070] du laboratoIre de 8|
San Jose quI fonda le modele relatIonnel en y exposant, la sImplIcIt de la
reprsentatIon de la relatIon, une forme normale pour dcomposer une
relatIon afIn d'vIter des redondances, et les prIncIpaux oprateurs de
l'algebre relatIonnelle.
PlusIeurs classes de langages furent explores dans les annes quI suIvIrent,
dans les unIversIts et les laboratoIres prIvs. En 1974, 0.0. ChamberlIn
proposa une dfInItIon d'un langage nomm SEQUEL quI fut Implant chez
8| dans un projet nomm SEQUELXF|. l fut tendu dans un projet plus
vaste touchant l'ensemble de l'archItecture d'un SC80, le System F (1977).
Ce systeme fut jusqu' la fIn des annes 70 une plateforme
d'exprImentatIon pour 8|. Pendant la mme prIode pour des raIsons
lgales SEQUEL/2 fut renomm SQL.
Le dbut des annes 80, verra l'apparItIon de plusIeurs SC80 relatIonnels
dfInIs autour de SQL (DFACLE de Dracle nc., SQL/0S et 082 d'8|, NCFES
de FelatIonal Technology nc., SY8ASE de Sybase nc., ...) et aInsI SQL
devIent une norme de faIt, maIs chaque SC80 possede un dIalecte de SQL
avec ses propres partIcularIts.
A partIr de 1982, l'InstItut natIonal amrIcaIn de normalIsatIon (ANS) sera en
charge de dfInIr une norme quI sera fInalIse en 1986, la mme versIon est
accepte par l'organIsatIon InternatIonale des standards (SD9075) en 1987.
Une extensIon portant sur les regles d'IntgrIt est dIte par l'SD en 1989.
En 1992, une nouvelle versIon du standard est dIte par l'SD, SQL2. En
1999, une versIon SQL99 correspond la versIon la plus plus rcente.
Les exemples de cet ouvrage sont crIts avec le SQL du SC80 DFACLE. 0ans
sa dernIere versIon, Dracle est conforme la norme SD de 1989. Nous avons
rarement utIlIs les extensIons la norme.
1rois discours
Les bases de donnes relatIonnelles prennent racIne dans troIs unIvers
dIstIncts. La notIon de relatIon est tablIe formellement dans les
mathmatIques. Le modele relatIonnel est un outIl permettant la
reprsentatIon des objets du champ d'applIcatIon. Et les systemes de gestIon
de bases de donnes relatIonnelles sont des logIcIels utIlIsant les
technologIes de l'InformatIque. Nous avons troIs mondes et par consquent
troIs dIscours. l convIent donc d'tre partIculIerement attentIf pour vIter la
confusIon entre le formel, le modele et la technIque.
Chaque monde se dveloppe son propre rythme; les notIons
mathmatIques pouvant tre consIdres comme stables, les proprIts
fondamentales de la modlIsatIon relatIonnelle voluent lentement et les
technologIes de l'InformatIque se succedent les unes aux autres rapIdement
autour du langage SQL standardIs. La matrIse de ces dIscours est le passage
oblIg pour comprendre l'volutIon des systemes de gestIon de bases de
donnes relatIonnelles, ces dernIers tendent, dans leurs versIons successIves,
d'Incorporer les acquIs du formel et les proprIts de la modlIsatIon
relatIonnelle. Ce soucI de lIer ces troIs dIscours se fera dans le sens du
concret et restera dIrectement lI aux technologIes de l'InformatIque.
Nous allons Illustrer ces propos par un exemple (ne faItes pas attentIon aux
notatIons, elles seront completement dfInIes ultrIeurement). 0ans le
champ d'applIcatIon consIdr, Il s'agIt de dfInIr la dIstance vol d'oIseau
entre deux vIlles.
La relatIon mathmatIque se rduIt au prdIcat suIvant:
0Istance(x,y,z)=z est la dIstance entre x et y
ou z N, x,y 7Ille
0e U|L SQL 91
La modlIsatIon relatIonnelle enrIchIt la reprsentatIon par rapport au
champ d'applIcatIon, en lImItant la source des InformatIons l'atlas et en
prcIsant l'unIt de mesure. Dn cherche aussI explIcIter les lIens exIstants
entre les InformatIons lmentaIres. Dn peut dIre par exemple que
0Ist_en_Km dpend fonctIonnellement de 0part et d'ArrIve.
0Istance(0part,ArrIve,0Ist_en_Km)
0omaIne(0part)= Nom_de_7Ille_de_mon_Atlas
0omaIne(ArrIve)= Nom_de_7Ille_de_mon_Atlas
0omaIne(0Ist_en_Km)= NumrIque entIer [0..20'000]
0Istance(0part,ArrIve,0Ist_en_Km)=0Ist_en_Km est la dIstance
en Km entre la vIlle de 0part et la vIlle d'ArrIve
L'ordre de cratIon de la table dans un systeme de gestIon de base de
donnes relatIonnelles ne se proccupe que des questIons de reprsentatIon
InformatIque et de la valIdatIon sur l'Intervalle de la dIstance. Les
dpendances fonctIonnelles dfInIssent alors la cl de la relatIon.
CREATE TABLE Distance(
Depart char(12) not null,
Arrivee char(12) not null,
Dist_en_Km number(5)
Check (Dist_en_Km between 0 AND 20000),
primary key (Depart, Arrivee))
Pour reprsenter quelques donnes, Il est possIble d'utIlIser la notIon de
table: 0Istance
0part ArrIve 0Ist [kmj
Ceneve ParIs 420
ParIs PkIn 8220
PkIn 7ancouver 8510
... ... ...
En mathmatIque, on parle d'ensembles et de prdIcats; dans la
modlIsatIon, on s'exprIme avec des relatIons, des constItuants, des
domaInes et des dpendances fonctIonnelles. 0ans la technologIe
InformatIque, les termes sont ceux de tables, colonnes, caracteres,
nombres, cls de table. Cette cascade de transformatIons, nous faIt passer
des abstractIons pures des mathmatIques une concrtIsatIon sous forme
d'un systeme InformatIque. PoursuIvons notre exemple avec une proprIt:
La dIstance parcourIr entre l'arrIve et le dpart est IdentIque celle du
dpart l'arrIve.

En mathmatIque, on parlera de commutatIvIt que l'on notera:
x ,y 0Istance(x,y,z) 0Istance(y,x,z)
0ans la modlIsatIon, cette commutatIvIt sera perue comme une regle
d'IntgrIt que devront valIder les donnes:
rI1) r 0Istance, r' 0Istance
sI (r.ArrIve=r'.0part)(r.0part=r'.ArrIve)
alors r.0Ist_en_Km=r'.0Ist_en_Km
L'ImplantatIon InformatIque de cette regle peut tre envIsage de
dIffrentes manIeres; Il faudra maIntenIr automatIquement la dIstance des
couples aller et retour chaque modIfIcatIon de la dIstance ou bIen
n'enregIstrer que la moItI de la table et permettre l'utIlIsateur une
InterrogatIon sur la totalIt.
Notre parcours suIvra un ItInraIre entre la thorIe, les concepts et la mIse
en oeuvre, explIcItant les lIens autant que possIble. CecI permettra au
lecteur de se rendre relatIvement Indpendant des futures volutIons des
technologIes de l'InformatIon quI ne toucheront pas son capItal de
connaIssances conceptuelles.

0e U|L SQL 9J
6. Base du modle relationnel
"2.18 Ce que chaque tableau, de quelque forme que ce soit
doit avoir de commun avec la ralit, pour absolument
pouvoir la reprsenter - justement ou faussement - c'est la
forme logique, c'est dire la forme de la ralit" (Ludwig
Wittegenstein - Tractatus logico-philosophicus)
L'objectIf de ce chapItre est d'lucIder la dfInItIon de la relatIon (donne en
termes mathmatIques). Nous n'IntroduIrons que les notIons mathmatIques
ncessaIres la comprhensIon cette dernIere.
0fInItIon:
Une relcton ncre R est dfInIe sur le produIt cartsIen des domaInes
de n constItuants formant l'ensemble F
+

et d'un prdIcat not F
dont les varIables lIbres correspondent aux constItuants de F
+
et
prennent leurs valeur dans les domaInes de ces constItuants.
Cette dfInItIon est lIe aux ensembles, aux proposItIons logIques et aux
prdIcats logIques dont nous allons revoIr les dfInItIons fondamentales.
EnsuIte, au fur et mesure, nous dIssquerons la dfInItIon de la relatIon.
Les ouvrages de rfrence pour ce chapItre sont [CHE74] et [HDT89].
Domaines
Un domaIne dsIgne un ensemble de valeurs. l est sImIlaIre la notIon de
type que l'on trouve dans les langages de programmatIon. Ces valeurs seront
prIses par les donnes de notre champ d'applIcatIon.
0fInItIon:
Un domcne est un ensemble 0 non vIde,fInI ou dnombrable
1

Dn dIra que a est une vcleur de 0 sI a 0
Exemples de domaIne :
0omaIne_des_couleurs = [vert, jaune, bleu, rouge]
0omaIne_des_nombres_entIers = [1,2,J,....,n,...]
0omaIne_des_tats_des_portes =[ouvertes, fermes]
0omaIne_des_pays =[SuIsse, France, Panama, ...]
0omaIne_des_tats_logIques = [vraI, faux]

1
Un ensemble est dnombrabre sI l'on peut compter l'aIde des entIers naturels N. Notons
que F les nombres rels ne sont pas dnombrables, maIs leur reprsentatIon dans les
ordInateurs tant fInIe, Ils devIennent dnombrables. Dn pourra donc les utIlIser comme
domaIne!
0omaIne_des_tItres_de_lIvre = [comprendre la logIque moderne,what
Is the name of thIs book, Le parfum,...]
0omaIne_des_types_de_plante = [arbre, fleur, cacte, ...]
0omaIne_des_fleurs = [rose, camlIa, marguerIte, ...]
0omaIne_des_produIts = [parfum, maquIllage, creme solaIre, ...]
0omaIne_des_dates = [1avrIl1992, 24dec2000, ....)
Les domaInes sont entIerement dpendants du champ d'applIcatIon dans
lequel on travaIlle. L'effort de modlIsatIon commence par une laboratIon
complete des domaInes. 0ans [LED88], on trouve une typologIe des
domaInes. A chaque type de domaIne est assocI les opratIons quI sont
autorIses. Nous donnons cette typologIe dans la FIgure 61, sous forme d'un
arbre ou chaque noeud hrIte des opratIons du noeud prcdant.
Le type texte dfInIt les domaInes ou aucune opratIon n'est possIble, Il
s'agIt donc d'un domaIne purement InformatIf. Le domaIne des adresses peut
tre consIdr comme appartenant au type texte. l sera dIffIcIle de
rpondre surement la questIon combIen de personnes habItent une
avenue. En effet, le texte tant totalement lIbre, la saIsIe aura permIs des
abrvIatIons et aussI des erreurs. Le lIbell d'une crIture comptable est
aussI du type texte, sa valeur nous permet de comprendre l'objet de
l'crIture maIs ne peut pas tre utIlIse pour connatre la somme des
factures payes aux fournIsseurs. Chaque foIs que l'on assocIe ce type un
domaIne, on renonce utIlIser ce domaIne pour des opratIons de slectIon.
Le type mot dfInIt les domaInes ou les opratIons d'galIt ou d'IngalIt
sont possIbles. Les domaInes des noms, des prnoms des personnes sont
assocIs ce type. l s'agIt donc de domaInes ou Il exIste un crItere quI
permet d'tablIr sI une valeur appartIent ou non ce domaIne. Pour
rpondre la questIon sur les paIements d'un fournIsseur, on peut assocIer
chaque crIture comptable un genre d'crIture quI prendra ses valeurs dans
0omaIne_des_genres =[ Payement_FournIsseur, FraIs_gnraux, ...]. Pour
passer du type texte au type mot, Il faut donc explIcIter l'InformatIon
contenue ImplIcItement dans le type texte.
Le type mot ordonn est un type mot sur lequel une relatIon d'ordre est
dfInIe. SI les valeurs sont reprsentes avec des caracteres, Il exIste par
dfaut un ordre lexIcographIque quI permettra un trI de l'InformatIon (ou de
chercher les valeurs plus petItes, plus grandes, avant, apres, ...). Pour
certaIns types mot cet ordre doIt tre donn explIcItement; par exemple
pour ordonner le 0omaIne_des_couleurs, on pourra choIsIr la longueur d'onde
assocIe chacune.
0e U|L SQL 95

texte
mot(=, )
boolen (et,ou,non, ...)
mot ordonn (<,>)
date horaire
numrique (+,-,*,/)
entier(div,mod,..) flottant(sqrt,...)

FIgure 61: HrItage des opratIons dans la typologIe des domaInes.
Le type numrque autorIse les opratIons arIthmtIques de l'addItIon, de la
soustractIon, de la dIvIsIon et de la multIplIcatIon. l se dIvIse en deux sous
types: les entIers et les rels, chacun possdant ses opratIons propres. Le
type dcte et horcre sont des domaInes propres la gestIon. Le type boolen
est un type sur lequel sont dfInIs les opratIons logIques (et, ou, non, ...).
Le choIx du type de domaIne est essentIel car Il dtermIne les opratIons de
comparaIson et de manIpulatIon des donnes quI seront assocIes ce type.
Ce choIx se faIt au moment de la modlIsatIon, car au moment de la mIse en
oeuvre InformatIque, les SC80 assocIent tous ces types deux catgorIes:
les chanes de caracteres et les nombres. Dn aura donc recours d'autres
mcanIsmes pour assurer la valIdIt des donnes par rapport leurs
domaInes.
Constituants
Un consttucnt est un ensemble de donnes ayant une proprIt et un
comportement homogene dans le champ d'applIcatIon. La sIgnIfIcatIon des
donnes rsIde dans l'appartenance cette classe. La donne FDSE sera
Interprte comme un prnom sI elle est une valeur du constItuant PFEND|,
comme une espece de fleur sI elle est une valeur du constItuant FLEUF,
comme une couleur sI elle est une valeur du constItuant CDULEUF.
Le constItuant est assocI un IdentIfIcateur (PFEND|, ND|, FLEUF,
CDULEUF, 0ATE_ECFTUFE, 0ATE_NASSANCE).
Le constItuant est assocI un et un seul domaIne quI dfInIt les valeurs que
peut prendre cette proprIt.
La fonctIon dom assocIe un constItuant son domaIne
C : ensemble des constItuants
0 : ensemble des domaInes
dom : C 0
dom(C)=0
Dn a par exemple:
dom(0ATE_NASSANCE) = 0omaIne_du_calendrIer.
Pour Interprter une valeur, Il est IndIspensable de connatre son
constItuant, sa valeur seule ne suffIt pas. Le 14novembre1980, estce une
date de naIssance ou une date d'crIture comptable : Le constItuant donne
son sens la valeur, le domaIne tablIt les valeurs autorIses. l seraIt
possIble de modIfIer tous les domaInes d'une modlIsatIon, par exemple, en
les traduIsant dans une autre langue, sans affecter l'InterprtatIon donne
par les constItuants. Les proprIts d'une modlIsatIon seront tablIes
ultrIeurement par les lIens smantIques exIstant entre les constItuants.
Rappels sur la logique des propositions
0ans [HDT89], on peut lIre: la logIque ne consIdere comme proposItIons que
des phrases susceptIbles d'tre vraIes ou fausses; cecI carte d'emble
toutes les formes (modales) de la prIere, de l'InterrogatIon, du
commandement, du souhaIt ... Seules, en prIncIpe, sont recevable les
proposItIons dcIaratIves, descrIptIves, empIrIques, c'estdIre, d'une
faon gnrale, les proposItIons quI dIsent queIque chose au sujet de Ia
raIIt et dont l'affIrmatIon est, au moIns thorIquement, vrIfIable
2
.
(p) Un domaIne est un ensemble est une proposItIon vraIe
(q) Les autruches volent est une proposItIon fausse
(r) 7ous lIsez cette phrase est une proposItIon vraIe
(s) ParIs est dans l'hmIsphere sud est une proposItIon fausse
La proposton smple, habItuellement note par les lettres p, q, r, s ... ne
se proccupe pas de l'analyse du contenu de la phrase, sa totalIt est
value vraI ou faux.
La proposton compose est forme de proposItIons sImples connectes par
des oprateurs logIques (et ventuellement des parentheses pour oter les
ambIguts). Les oprateurs couramment utIlIss sont:
La con]oncton (et logIque note ): p q sera value vraI sI p est vraI et
sI q est vraI.
La ds]oncton (ou logIque InclusIf note ) p q sera value vraI dans
troIs cas: p vraI et q faux, p vraI et q vraI, p faux et q vraI.
Le condtonnel (SI p alors q not ) p q sera value vraI dans troIs
cas: p vraI et q vraI, p faux et q vraI, p faux et q faux.
Le bcondtonnel (SI et seulement sI note ) p q sera value vraI
dans deux cas: p vraI et q vraI, p faux et q faux.
La nycton (note ) p sera value vraI sI p est faux.

2
|Is en vIdence par l'auteur
0e U|L SQL 97
SI p et q correspondent aux proposItIons dfInIes prcdemment, nous
aurons l'expressIon, p q, value faux (Un domaIne est un ensemble et
Les autruches volent).
L'valuatIon des proposItIons composes peut tre obtenue en construIsant
une table de vrIt, pour les oprateurs ,,,, nous obtenons la table
de vrIt de la FIgure 62.
p q p q p q pq pq p
V V V V V V F
V F F V F F F
F V F V V F V
F F F F V V V
FIgure 62: table de vrIt des oprateurs logIques courants
Une tautologIe est une expressIon quI est toujours value vraI. Par
exemple: p p, le prIncIpe du tIers exclu est une tautologIe. Une
tautologIe est une expressIon quI comporte que des vraIs dans sa table de
vrIt.
p p pp
7 F 7
F 7 7
FIgure 6J: table de vrIt p p
Les logIcIens recherchent ces expressIons car elles sont des thoremes ou
des axIomes.
Rappels sur la logique des predicats
La logIque des prdIcats se propose d'analyser les proposItIons p, q, r
consIdres comme Inanalyses dont on savaIt prcdemment seulement sI
elles sont vraIes ou fausses. L'objectIf prIncIpal des prdIcats est donc
l'analyse des proposItIons.
En logIque des proposItIons, on a l'ensemble suIvant de proposItIons
les autruches volent : faux
les moIneaux volent : vraI
les pIes volent : vraI
les pIngouIns volent : faux
etc
Le prdIcat vole(x) quI assocIe pour chaque x prIs dans l'ensemble DIseaux la
valeur vraI ou faux permet d'analyser les proposItIons prcdentes.
vole : DIseaux [vraI, faux]
Un prdIcat ou formule ouverte est une expressIon dont la valeur de vrIt
reste IndtermIne car elle contIent des varIables. 0es que toutes ces
varIables sont remplaces par une valeur alors elle devIent vraIe ou fausse.
En effet, cet Instant le prdIcat s'est transform en proposItIon.
exemple:
SI (x) sIgnIfIe x entIer non nul est ImpaIr
(1) et (J) sont vraIs.
(2) et (4002) sont faux.
SI P(x) sIgnIfIe x entIer non nul est paIr
P(1) et P (J) sont faux.
P(2) et P (4002) sont vraIs.
L'autre possIbIlIt de transformer un prdIcat en proposItIon est de
quantIfIer ses varIables. l exIste deux possIbIlIts.
Par la qucnt]ccton unverselle , quI substItue la varIable tous les
lments de l'unIvers consIdr ou domaIne d'InterprtatIon, ce prdIcat.
SoIt:
x, f(x) quI se lIt: pour tout x, on a f(x)
Dn a par exemple, x, (x) est une proposItIon fausse car tous les nombres
ne sont pas ImpaIrs. Le domaIne d'InterprtatIon est IcI l'ensemble des
entIer posItIfs (pour sImplIer la notatIon, nous consIdrerons le domaIne
d'InterprtatIon comme ImplIcItement dfInI) Le quantIfIcateur unIversel est
quIvalent crIre la conjonctIon de toutes les proposItIons obtenues avec
un prdIcat, soIt dans notre exemple:
x, (x) (1) (2) (J) (4) ....
Par la qucnt]ccton exstentelle, quI substItue la varIable au moIns un
des lments de l'unIvers assocI ce prdIcat. SoIt:
x, f(x) quI se lIt: Il y a un x, tel que f(x)
Dn a par exemple, x, P(x) est une proposItIon vraIe, car J224 est un nombre
paIr. Le quantIfIcateur exIstentIel est quIvalent crIre la dIsjonctIon de
toutes les proposItIons obtenues avec un prdIcat, soIt dans notre exemple:
x, P(x) P(1) P(2) P(J) P(4) ....
Le calcul des prdIcats permet donc de manIpuler des expressIons
proposItIonnelles de longueur InfInIe (dnombrable).
Dn peut tendre les prdIcats en utIlIsant les oprateurs logIques vus
prcdemment. Dn aura par exemple les expressIons:
x, ((x) P(x)) quI est une proposItIon vraIe (tout x est paIr ou ImpaIr)
x, ((x) P(x)) quI est une proposItIon vraIe (Il n'exIste pas de x
ImpaIr et paIr)
Dn peut tendre les prdIcats en utIlIsant des expressIons avec plusIeurs
varIables. Par exemple:
0Istance(x,y,z) ou z est la dIstance entre x et y
La transformatIon d'un prdIcat en fonctIon est dfInIe de la faon suIvante:
Un prdIcat n'ayant plus aucune vcrcble lbre devIent une proposItIon.
Une varIable est lbre sI elle n'est pas lIe. Elle est le par:
une substItutIon avec une valeur
par une quantIfIcatIon.
0e U|L SQL 99
Lnsembles, propositions et predicats
Nous avons dj vu que les prdIcats dont toutes les varIables sont lIes
devIennent des proposItIons
Entre les ensembles et la logIque des proposItIons, Il exIste un IsomorphIsme
(lImIt) quI mcanIquement permet de transformer une proprIt du calcul
des classes en un thoreme du calcul des proposItIons et vIceversa. Dn
applIque les substItutIons suIvantes sur les varIables et les oprateurs:
A p
8 q
C r
Faux
U 7raI
Cet IsomorphIsme sIgnIfIe: c'est vraI pour les ensembles sI et seulement sI
c'est vraI pour les proposItIons.
Dn a par exemple:
La dIstrIbutIvIt de sur
SoIt: A (8 C) = (A 8) (A C)
devIent la dIstrIbutIvIt de sur , pour le calcul des proposItIons SoIt:
p (q r) = (p q) (p q).
Le prIncIpe du tIers exclu p p = vraI (car une tautologIe) devIent la
formule suIvante A (A) = U .
Cet IsomorphIsme est lImIt; le calcul des proposItIons est plus puIssant que
le calcul sur les ensembles, par contre, la notIon d'ensemble IntroduIt des
tats autres que vraI et faux (tout ou rIen).
Les ensembles et les prdIcats sont lIs par le prIncIpe d'abstractIon quI
spcIfIe que pour tout prdIcat est assocI au moIns un ensemble. Le
prdIcat devIent la fonctIon proposItIonnelle de l'ensemble. Dn a donc:
SI A est l'ensemble dtermIn par le prdIcat f(x), Il est quIvalent pour
tout x de dIre que x satIsfaIt la fonctIon f(x) ou que x est lment de
A. SoIt:
x (f(x) x A)
CecI est vraI pour les prdIcats une varIable, la dfInItIon du produIt
cartsIen va nous permettre de la rendre vraIe pour un prdIcat n
varIables.
0fInItIon:
SoIt A et 8 deux ensembles, A 8 est le produt ccrtsen de A par 8 et
dfInIt le nouvel ensemble suIvant:
A 8 = [(a,b) (a A) (b 8)]

Logique des classes
Logique des Propositions
Logiques des Prdicats

a A

f(a)=vrai
f(x)

FIgure 64: Ensembles, proposItIons et prdIcats
Une feuIlle d'agenda est le produIt cartsIen de Jour et Heure.
Agenda = Jour Heure
ou Jour = [lundI, mardI, ...., dImanche)
et Heure = [7h, 8h, ...., 19h]
Un chIquIer est un produIt cartsIen:
EchIquIer = [a,b,c,...,h] [1,2,...,8]
Et bIensur les coordonnes cartsIennes:
J0 =
Dn peut tendre la notIon de produIt cartsIen n ensembles:
A
1
A
2
A
J
... A
n

= A
I
, I=1..n
=[(a
1
,a
2
,...,a
n
) ( a
I ,
a
I
A
I)
I=1..n ]
AInsI un prdIcat portant sur plusIeurs varIables devIent la fonctIon
proposItIonnelle d'un ensemble contenu dans le produIt cartsIen de l'unIvers
de chaque varIable.
La FIgure 64 rsume les lIens exIstant entre les troIs formalIsmes:
Retour la definition de relation
Nous avons donc maIntenant tous les lments pour comprendre la dfInItIon
de la relatIon.

Une relatIon (ou schma de relatIon) F est compose
d'un ensemble F
+
de constItuants et
d'une formule F, appele prdIcat de la relatIon, dont les
varIables lIbres sont exactement les constItuants de F.
0e U|L SQL 101
Une relatIon F est une relatIon portant sur n varIables; dans le modele
relatIonnel, nous prfrons parler en termes de constItuants plutot que de
varIables
J
.
F
+
=[C
1
,C
2
,....,C
n
] dfInIt l'ensemble de constItuants de la relatIon
dom(C
I
), C
I
F
+
, I=1..n dfInIt le produIt cartsIen des domaInes. l
dfInIt donc la structure de la relatIon.
F(C
1
,C
2
,....,C
n
) dfInIt le prdIcat de la relatIon. l dfInIt la
smantIque de la relatIon.
llustrons cela avec les exemples suIvants:

La reIatIon SDhhE

SD||E+ = [CAUCHE, 0FDTE, TDTAL]
SD||E = (CAUCHE+0FDTE = TDTAL)

Ia reIatIon ETU0IANT

ETU0ANT
+
=[Nom, Prenom, Sexe, DrIgIne, 0ate_NaIssance]
dom(Nom) = mot [0upont, 0urant, ...]
dom(Prenom) = mot [Jean, |arIe, ...]
dom(Sexe) = mot [Homme, Femme]
dom(DrIgIne) = mot [SuIsse,France, Suede, ...]
dom(0ate_NaIssance) = date
et nous avons le prdIcat suIvant:
ETU0ANT(n, p, s, o, d) : La personne portant le nom n et le prnom p
est de sexe s, d'orIgIne o et elle est ne la date d et elle est actuellement
un tudIant de l'UnIversIt de Ceneve

0ans ce dernIer exemple le prdIcat se rduIt une expressIon atomIque,
c'est dIre non dcomposable, comprenant un symbole de prdIcat exprIm
en langue naturelle La personne portant le nom n et le prnom p est de
sexe s . et des varIables. Cette formule n'est pas valuable formellement
maIs dcrIt bIen l'IntentIon de la relatIon, elle fournIt la smantIque de cette
relatIon. SI l'on attrIbue des valeurs aux varIables, une personne connaIssant
le domaIne d'applIcatIon pourra valuer cette forumule vraI ou faux. La
formule dfInIssant une relatIon se rduIt la plupart du temps cette forme

J
La relatIon en mathmatIque est posItIonnelle (la premIere, seconde, etc varIable du
prdIcat). En nommant les varIables, Il est possIble de l'affranchIr de la posItIon de la
varIable, aInsI dans le modele relatIonnel la posItIon d'un constItuant est sans Importance.
Les deux relatIons suIvantes sont quIvalentes:
0Istance(0part,ArrIve,0Ist_en_Km) 0Istance(0Ist_en_Km,ArrIve,0part)
prdIcatIve de base, sauf pour des relatIons telles SD||E quI sont
calculables, c'est pourquoI on a choIsI de l'appeler prdIcat. Nous verrons
qu'avec l'algebre relatIonnelle on peut obtenIr des relatIons dont le prdIcat
sera compos partIr des prdIcats des relatIons de dpart.
Pour une relatIon, Il n'exIste qu'un seul prdIcat, donc qu'une seule
InterprtatIon possIble des donnes, un Instant fIx. Le domaIne
d'InterprtatIon est souvent ImplIcIte, IcI les tudIants de l'unIversIt de
Ceneve.
Dn note xF (ou type(F)) le produIt cartsIen des domaInes des constItuant de
F+, soIt xF = dom(C
I
), C
I
F
+
, I=1..n. l dfInIt donc la structure de la
relatIon.

0fInItIon:
Un nuplet r de R est un lment du produIt cartsIen, soIt :
r dom(C
I
), C
I
F
+

Une entt r de R est un nuplet de F tel que F(r) est vraI
SoIt F une relatIon, X F
+
et r une entIt de F, alors on note r.X la
valeur que r prend pour les constItuants de X

FIgure 65 : InterprtatIon de la relatIon
Le nuplet est un lment d'une relatIon ayant des valeurs prIses dans les
domaInes des constItuants maIs dont on ne dIt rIen sur le prdIcat. l
appartIent unIquement au produIt cartsIen. Par contre l'entIt vrIfIe le
prdIcat de la relatIon. Nous avons par exemple:
Le nuplet (0upont,Paul,Homme,France,1686J) pour la relatIon
ETU0ANT et sI La personne portant le nom 0upont est le prnom PauI
est de sexe Homme, d'orIgIne France et elle est ne la date 16-8-63
et elle est actuellement un tudIant de l'UnIversIt de Ceneve alors
c'est une entIt de la relatIon.
dom(Ci)
||R(C1,C2,....,Cn)||
(C1,C2,....,Cn)
interprtation du prdicat
classes
proposition
vrai faux
entit
n-uplet
0e U|L SQL 10J
SI r est l'entIt prcdente et X=[Prenom, Nom) alors r.X = (0upond,
Paul)
Chaque nuplet est donc une proposItIon value vraI ou faux. Seules les
entIts, nous Intressent, elles formeront l'Instance de la relatIon.
0fInItIon:
Une nstcnce de R est l'ensemble des entIts de cette relatIon (note
IF): IF = [r
1
,r
2
, ..., r
n
]
Nous dIstInguons donc la relatIon quI est dfInIe par sa structure et son
prdIcat, de l'Instance quI est une InterprtatIon du prdIcat pour les valeurs
autorIses par la structure. Cette dIstInctIon nous conduIt aux dfInItIons
suIvantes:
Une modlIsatIon |d est un ensemble de relatIons soIt:
|d = [F
1
,F
2
, ..., F
n
]
Une base de donnes I|d correspond une Instance de modlIsatIon
|d, soIt l'ensemble des Instances des relatIons de cette modlIsatIon, d
soIt:
I|d = [IF
1
,IF
2
, ..., IF
n
]
I|d correspond une InterprtatIon pour un domaIne d'InterprtatIon
donn (les tudIants de 8oston), un Instant fIx (hIer 12hJ4).

FIgure 66 : 0u modele l'Instance
La modlIsatIon possede deux aspects. 0'une part nous avons la structure
dcrIte en termes de produIts cartsIens de constItuants dfInIs par leur
domaIne et d'autre part la dImensIon smantIque dfInIe par les prdIcats
des relatIons. L'Instance d'une modlIsatIon est la base de donnes, c'est
dIre, l'ensemble des entIts appartenant la structure et vrIfIant les
prdIcats. Les systemes de gestIon de base donnes sont essentIellement
structurels.
dom(Ci)
||R(C1,C2,....,Cn)||
modlisation
interprtation
structure
smantique syntaxe
base de donnes
0ans les chapItres suIvants, nous verrons comment nous pouvons tablIr des
modlIsatIons afIn que leur mIse en oeuvre avec des systemes InformatIques
soIt la plus fIdele possIble.
Lxercices
Questions sur 11
3
Trouvez les domaInes et le type des domaInes de chaque constItuant.
EcrIvez un prdIcat pour les relatIons suIvantes dont l'InterprtatIon
correspond l'nonc.
7hIcule(noChassIs, noPlaque, mIseEnServIce, modele, noStatIon)
Type(modele,nbPlaces,catgorIe,typeCarburant,automatIque,poIds)
Chauffeur(noChauffeur, nom, prnom, adresse, noStatIon)
Reponses sur 11
3
0omaIne des constItuants:
adresse texte
automatIque boolen
catgorIe mot (A,81,82,C ...)
descrIptIon texte
heure entIer [0..2J]
kIlometrage entIer posItIf
lItres rel [0..500]
mIseEnServIce date
modele mot (mercedesJ00,audI200,car80pl,...)
nbPlaces entIer [4..80]
noChassIs entIer posItIf
noChauffeur entIer posItIf
noJour entIer [1..J66]
nom mot (0upont, 0urant, ...)
noPlaque entIer [1..9999]
noStatIon entIer [1..6]
noZone entIer [1..99]
poIds entIer [500..15000]
prnom mot (Jean, |arIe, ...)
tempsParcours entIer posItIf (en mInutes)
trancheHoraIre mot (A,8,C)
typeCarburant mot (super,normal,sansplomb,dIesel)
zoneA entIer [1..99]
0e U|L SQL 105
zone0e entIer [1..99]
PrdIcat des relatIons
7hIcule(nc,np,s,m,ns) : Le vhIcule portant le numro de ChassIs
nc et ImmatrIcul np a t mIs en servIce le s, Il est du modele m et
appartIent la statIon ns
Type(modele,nbPlaces,catgorIe,typeCarburant,automatIque,poIs)
Type(m,s,c,tc,a,p) : Le modele m de vhIcule peut contenIr s
personnes, pese p [kg], consomme du carburant tc, la bote vItesse
est a, le permIs c est ncessaIre pour le conduIre
Chauffeur(nch,n,p,a,ns) : Le chauffeur portant le nom n et le
prnom p habIte a. Il est IdentIfI par le numro nch et Il est assIgn
la statIon ns
Dn remarque que le noStcton et le modle se trouvent dans deux relatIons
et que leur sens dpend du contexte, c'estdIre, de la relatIon dans
laquelle Ils se sItuent.
0e U|L SQL 107
7. Modelisation et definition des
donnees
"Il n'y a pas de pense sans langage symbolique. Les
syntaxes et les grammaires nous imposent, certes, une
mdiation qui est autant une traduction qu'une dformation.
Mais ce biais et cet loignement du rel offrent des
contreparties. Il y a en effet une fcondit surprenante de
l'activit symbolique." (Philippe Quau - Eloge de la
simulation)
Nous dsIrons exprImer notre modlIsatIon Indpendamment du systeme de
gestIon de base de donnes que nous allons utIlIser. A cette fIn, nous
dfInIrons un langage de descrIptIon de modlIsatIon (L0|). Cette
descrIptIon est spcIfIe l'aIde de dIagrammes syntaxIques. Nous donnerons
deux exemples de modlIsatIon d'un mme champ d'applIcatIon. EnfIn, nous
dfInIrons la syntaxe SQL du langage de descrIptIon des donnes (L00) quI
est le moyen de traduIre, pour un systeme de gestIon de base de donnes, la
modlIsatIon.
Diagrammes syntaxiques
Les dIagrammes syntaxIques sont un moyen sImple et graphIque pour
reprsenter de manIere formelle la grammaIre d'un langage. ls sont une
alternatIve descrIptIon 8NF, 8ackusNaurForm; du nom des deux auteurs
ayant dfInI ALCDL 60 [NAU6J]. Jensen K. et N. WIrth ont rendu les
dIagrammes syntaxIques populaIres en les utIlIsant pour la dfInItIon du
PASCAL [JEN75].
Chaque regle de grammaIre est dfInIe par un dIagramme. Un dIagramme est
compos des symboles termInaux contenus dans des botes aux coIns ronds et
de symboles nontermInaux contenus dans des botes rectangulaIres. Les
symboles termInaux dtermInent des chanes de caracteres quI apparaIssent
dans une phrase du langage et les symboles nontermInaux renvoIent une
autre regle. CertaIns symboles lexIcaux comme les IdentIfIcateurs et les
nombres sont consIdrs comme des nontermInaux. 0ans ce cas, Ils
renvoIent la regle lexIcale.
Langage de description de modelisation
Ce langage permet de dfInIr une modlIsatIon, c'estdIre, un ensemble de
relatIons. Une relatIon est dfInIe par son nom, sa lIste de constItuants, son
prdIcat. Un constItuant est dfInI par son domaIne. Les types de domaInes
sont ceux vus prcdemment.
modlIsatIon

declaratIonrelatIon

declaratIondomaIne

type

lIstevaleur

lIsteIntervalle

NomrelatIon, nomconstItuant sont des IdentIfIcateurs,
nterprtatIon et nomvaleur sont des chanes caracteres,
borneInf et bornesup sont des nombres.

FIgure 71: Une rservatIon dans un hotel
UtIlIsons ce langage pour modlIser un systeme de rservatIon des chambres
dans un hotel. Notre hotel est constItu de chambres rserves par des
chambre 12,
120 Irs, WC,TV
2 lits, 3 pers
client no 300
Dupont, Paul
13 rue de la voirie
arrivee 13-nov-90
depart 16-nov-90
0e U|L SQL 109
clIents pour une prIode donne. La fIgure 1a montre les dIffrentes
caractrIstIques d'une rservatIon.

FIgure 72: 0Iagramme de classes pour Hotel

Une premIere modlIsatIon de Hotel (versIon 1)
Htel(NumChambre, NumClient, Nom, Prenom, Adresse,
Prix, NbrLit, NbrPers, DateArr, DateDep, Confort,
Equipement)
predicat: "||Htel(a,b,c,d,e,f,g,h,i,j,k,l)|| Le
client, portant le numro b nomm d,c habitant e
arrivant le i et partant le j, a rserv la chambre
portant le numro a qui contient g lits et peut loger
h personnes, ayant pour confort k et quipement l et
cote f francs par nuit"
NumChambre dom numrique entier [1..50]
NumClient dom numrique entier [1..999999]
Nom dom mot (Dupont, Durand, ...)
Prenom dom mot (Jean, Marie, ...)
Adresse dom texte
Prix dom numrique rel [100..1000]
NbrLit dom numrique entier [1..3]
NbrPers dom numrique entier [1..3]
DateArr dom date
DateDep dom date
Confort dom mot ordonn (wc,douche,bain)
Equipement dom mot (sans,TV)
Cette entIt (12, J00, 0upont, Paul, 1J rue de la voIrIe, 120, 2, J, 1JNov
92, 16Nov92, WC, T7) est l'InterprtatIon du faIt :Le clIent, portant le
numro 300 nomm 0upont, PauI habItant "13 rue de Ia voIrIe" arrIvant le
Clients
NumClient : integer
Nom : string
Prenom : string
Adresse : string
Chambres
NumChambre : integer
Prix : real
NbrLit : integer
NbrPers : integer
ConIort : string
Equipement : string
Rservations
DateArr : date
DateDep : date
* *
NumChambre : integer
Prix : real
NbrLit : integer
NbrPers : integer
ConIort : string
Equipement : string
DateArr : date
DateDep : date
NumClient : integer
Nom : string
Prenom : string
Adresse : string
1JNov92 et partant le 16Nov92, a rserv la chambre portant le numro
12 quI contIent 2 lIts et peut loger 3 personnes, ayant pour confort WC et
quIpement TV et coute 120 francs par nuIt.
Nous allons voIr une deuxIeme modlIsatIon du mme champ d'applIcatIon
(7ersIon 2):
Chambres(NumChambre, Prix, NbrLit, NbrPers, Confort,
Equipement)
predicat:"||Chambres(a,b,c,d,e,f)|| La chambre portant
le numro a qui contient c lits et peut loger d
personnes a pour confort e et quipement f et cote b
francs par nuit"
Clients(NumClient, Nom, Prenom, Adresse)
predicat:"||Clients(a,b,c,d)|| Le client portant le
numro a se nomme c,b et habite d"
Rservation(NumChambre, NumClient, DateArr, DateDep)
predicat:"||Rservation(a,b,c,d)|| Le client, portant
le numro b arrivant le c et partant le d, a rserv
la chambre portant le numro a"
NumChambre dom numrique entier [1..50]
NumClient dom numrique entier [1..999999]
Nom dom mot (Dupont, Durand, ...)
Prenom dom mot (Jean, Marie, ...)
Adresse dom texte
Prix dom numrique rel [100..1000]
NbrLit dom numrique entier [1..3]
NbrPers dom numrique entier [1..3]
DateArr dom date
DateDep dom date
Confort dom mot ordonn (wc,douche,bain)
Equipement dom mot (sans,TV)
Le faIt exprIm prcdemment devIent IcI les troIs entIts suIvantes: Une
entIt de ClIents (J00, 0upont, Paul, 1J rue de la voIrIe) exprImant le faIt:
Le clIent portant le numro 300 se nomme 0upont, PauI et habIte 13 rue
de Ia voIrIe .Une entIt de Chambres (12, 120, 2, J, WC, T7) exprImant le
faIt: La chambre portant le numro 12 quI contIent 2 lIts et peut loger 3
personnes a pour confort WC et quIpement TV et coute 120 francs par
nuIt. Et une entIt de FservatIon (12, J00, 1JNov92, 16Nov92)
exprImant le faIt :Le clIent, portant le numro 300 arrIvant le 13-Nov-2 et
partant le 16-Nov-2, a rserv la chambre portant le numro 12.
Les deux modlIsatIons semblent dIre la mme chose (elles sont bases sur
les mmes constItuants) et pourtant elles sont structurellement dIffrentes,
l'une dcompose l'ensemble des constItuants en une relatIon, l'autre en troIs.
Ces problemes sont centraux lors du processus de modlIsatIon. 0ans le
chapItre suIvant, nous verrons comment Il est possIble de traduIre le
dIagramme des classes en un schma de relatIon. Pour l'Instant, examInons,
0e U|L SQL 111
comment Il est possIble de traduIre une modlIsatIon en descrIptIon de
donnes pour un SC80.

FIgure 7J: EquIvalence entre une table et une Instance de relatIon F
Langage de description des donnees (SQL)
Pour dIffrencIer les relatIons de la modlIsatIon de celles manIpules par un
SC80, nous appelons ces dernIeres tables. La structure de table est
quIvalente pour une relatIon F au produIt cartsIen du domaIne de ses
constItuants. Chaque colonne de la table sera un constItuant. Les valeurs
possIbles dans une colonne sont celles du domaIne de ce constItuant. Le
contenu de la table est quIvalent une Instance de F. Une lIgne de la table
est quIvalent une entIt de F.
Nous voyons IcI les premIers dIagrammes syntaxIques de SQL pour la cratIon
des tables. Nous IndIquons les dIffrences prIncIpales avec le standard dans
les notes de bas de page.
CratIon de structure de table vIde
4
: on IndIque le nom de la table
(ventuellement prcd du nom de l'utIlIsateur) et la lIste des descrIptIons
de colonnes. Nous revIendrons sur les notIons de contraIntes dans le chapItre
sur les regles d'IntgrIt.

4
Les clauses (table storage et cluster) concernant la faon de mmorIser les tables ne sont
pas standardIses.
R
C1 C2 Cn ...
c1 c2 cn
...
entite
iR
dom(C1)
NewcolumnlIst
5
: une colonne est spcIfIe par son nom et son type et
ventuellement par une valeur par dfaut donne la cratIon d'une entIt

datatype
6
:les types de donnes sont tres classIquement ceux que l'on trouve
dans les langages de programmatIon avec une redondance (sans doute due
la normalIsatIon) quI permet de dfInIr de plusIeurs manIeres le mme type.

charactertype: permet de dfInIr un caractere (character), une chane de
caracteres (lImIte 255 pour char)

datetype: une date dfInIe la seconde pres

floattype: des nombres en vIrgule flottante (notatIon scIentIfIque)

decImaltype: des nombres vIrgule fIxe (en comptabIlIt)

Integertype: des nombres entIers

bInarytype: des InformatIons bInaIres (son, Image, ...)

5
Le standard ne mentIonne pas de valeur par dfaut
6
7AFCHAF, LDNC, FAW ne sont pas des types standardIss, leur utIlIsatIon lImIte les
possIbIlIts de manIpulatIon des relatIons quI les contIennent.
0e U|L SQL 11J
En se restreIgnant la clause number, Il est possIble de dclarer tous les
types numrIques:
number: un nombre rel
number(m): un nombre entIer de m chIffres
number(m,n): un nombre dcImal de m chIffres avec n dcImales ou
mn
Le choIx des longueurs des chanes de caracteres dpend entIerement du
champs d'applIcatIon, la longueur maxImum des symboles de chaque
domaIne est une borne acceptable.
Feprenons notre deuxIeme modlIsatIon est traduIsonsla:
CREATE TABLE CLIENTS (
NUM_CLIENT NUMBER (6) not null ,
NOM CHAR (20),
PRENOM CHAR (20),
ADRESSE CHAR (40))
CREATE TABLE CHAMBRES (
NUM_CHAMBRE NUMBER (2),
PRIX NUMBER (8,2),
NBR_LITS NUMBER (1),
NBR_PERS NUMBER (1),
CONFORT CHAR(6),
EQUIPEMENT CHAR(3))
CREATE TABLE RESERVATIONS (
NUM_CLIENT NUMBER (6),
NUM_CHAMBRE NUMBER (2),
DATE_ARR DATE,
DATE_DEP DATE )
En soumettant ces troIs dclaratIons un systeme de gestIon de bases de
donnes, troIs structures de tables vIdes seront cres. 0ans chacune, Il sera
possIble d'Insrer des entIts correspondant la ralIt du champ
d'applIcatIon. La descrIptIon de donnes ne concerne que la partIe
structurale de la modlIsatIon. Une table est le produIt cartsIen des
domaInes de chaque constItuant, rIen n'est spcIfI sur le prdIcat des
relatIons. En effet, le prdIcat concerne unIquement la smantIque du
champ d'applIcatIon modlIs. SI l'on trouve dans un systeme de gestIon de
base de donnes la table suIvante:
CREATE TABLE PERSONNES (
NUM_PERSONNE NUMBER (6) not null ,
NOM CHAR (20),
PRENOM CHAR (20),
ADRESSE CHAR (40))
S'agItIl des personnes que je connaIs, de celles quI sont employes par une
entreprIse, de celles quI sont surveIlles par la CA, ... : Seule la
modlIsatIon et plus prcIsment le prdIcat de la relatIon PEFSDNNE peut
nous donner cette IndIcatIon. Dn trouvera par exemple:
Personnes(Num_Personne, Nom, Prenom, Adresse)
predicat:"||Personnes(a,b,c,d)|| Le membre du club de
Football de Rouen portant le numro a se nomme c,b et
habite d"
Et que dIre de la table suIvante:
CREATE TABLE R1 (
C1 NUMBER (6) not null ,
C2 CHAR (20),
C3 CHAR (20),
C4 CHAR (40))
cI les noms des constItuants ne nous guIdent en rIen. Cela peut tre une
table de personnes, une nomenclature de pIeces dtache, un herbIer, ... l
est IndIspensable de connatre la modlIsatIon pour pouvoIr Interprter une
table. Car une mme structure de table peut correspondre une multItude
de prdIcats possIbles. 0e plus, Il est fortement recommand de donner des
noms claIrs aux constItuants des tables, les requtes aux SC80 devIennent
plus longues crIre maIs elles gagnent surtout en lIsIbIlIt.

FIgure 74: les troIs tapes pour une base de donnes
Nous avons rsum dans la FIgure 74, les concepts manIpuls par
l'laboratIon d'une base de donnes. A partIr des objets du champ
d'applIcatIon et par le processus de modlIsatIon (cas d'utIlIsatIon,
dIagramme de classes, traductIon en relatIons) nous obtenons le modele |d.
Ce modele peut se concrtIser dans un ensemble d'Instances (la base de
donnes). Ces Instances sont obtenues en Interprtant les objets du champ
d'applIcatIon par rapport au prdIcat de la modlIsatIon.
Lxercices
Nous reportons les exercIces concernant ce chapItre au chapItre suIvant !

iR1
...
iRn
Md
objets
du
C.A. modlisation
concrtisation
interprtation
0e U|L SQL 115
8. Des classes aux relations
Il joue de mieux en mieux car linquitude est venue
nuancer son caractre trop ingnu et optimiste
Lempreinte de lange Nancy Huston
Ce chapItre est le poInt de jonctIon entre les deux modeles. Pour
conceptualIser, nous utIlIsons le modele objet, pour stocker, nous utIlIsons le
modele relatIonnel. 0ans ce chapItre, nous allons donner un ensemble de
regles sImples pour passer d'un modele l'autre.
Le passage de l'objet au relatIonnel est effectu lors de l'ImplmentatIon
d'un champ d'applIcatIon. Le chemIn Inverse du relatIonnel l'objet
s'effectue sur des systemes d'InformatIon n'ayant pas taIent conus avec
une approche objet. l s'agIra dans ce cas de retrouver une InterprtatIon ou
de documenter cette applIcatIon.
Fappelons les concepts des modeles utIlIss.
Le modele relatIonnel, notre cIble, utIlIse structurellement troIs concepts :
La relatIon quI regroupe un ensemble d'attrIbuts ;
L'attrIbut quI est dfInIt sur un domaIne ;
Le domaIne quI est dfInIt sur ensemble de valeurs.
Nous laIssons de cot le prdIcat de la relatIon. La notIon de domaIne est
IdentIque celle de type pour les dIagrammes de classes. Nous utIlIserons
donc des domaInes IdentIques.
Notre traductIon du modele objet vers le modele relatIonnel doIt donc tenIr
que de deux concepts la relatIon et les attrIbuts.
Chaque classe devient une relation
La regle est assez sImple, chaque classe devIent une relatIon . Chaque
attrIbut de la classe de devIent un attrIbut de la relatIon. 0ans l'exemple
suIvant, pour la classe Rectcnyles, nous aurons une relatIon Rectcnyles avec
deux attrIbuts largeur et hauteur. En termes SQL, nous avons :
Create Table Rectangle (
largeur number,
hauteur number)

Comment IdentIfIer les objets dans une relatIon : 0ans le monde des objets,
Il exIste par dfInItIon un DId (Dbject IdentIfIer) pour tout objet. Ce n'est
pas le cas pour les relatIons. SoIt Il exIste une cl naturelle, par exemple un
numro d'employ, (ou un groupe d'attrIbuts), alors on choIsIra ces attrIbuts
comme cl de la relatIon. SInon, on ajoute une cl artIfIcIel la relatIon.
0ans notre exemple de la classe Rectcnyle, Il n'exIste pas de cl (on peut
bIen sur choIsIr largeur et hauteur comme cl). l est donc ncessaIre
d'ajouter un attrIbut supplmentaIre la relatIon. Dn en profIte pour
IndIquer gestIonnaIre de la base de donnes que cet attrIbut est la cl
prImaIre en ajoutant derrIere la dclaratIon de type les mots prmcry key.
Nous obtenons donc la dclaratIon suIvante :
Create Table Rectangle (
Id_rectangle integer primary key,
largeur number,
hauteur number)
Que faire avec les methodes ?
l n'exIste pas de solutIon unIque pour les mthodes. L'avantage de la
programmatIon objet est de rapprocher les donnes des traItements. 0ans le
cas des SC80 relatIonnels, les traItements doIvent tre dcrIt dans un
langage procdural tel que 7Isual 8asIc, PL/SQL ou Java. Les traItements
peuvent tre extrIeurs la base de donnes ou stocks dans le serveur de
la base de donnes.
Nous donnons IcI troIs possIbIlIts pour traIter des mthodes sans faIre appel
des traItements procduraux.
Memoriser les attributs calcules
Pour les mthodes quI ne modIfIent pas l'tat de l'objet et dont but est de
retourner une valeur sur l'tat de l'objet, Il est possIble de rendre statIque
ces mthodes en leur substItuant un attrIbut quI correspond la valeur de
l'objet. Pour notre exemple, nous obtenons la dclaratIon suIvante :
Create Table Rectangle1 (
Rectangles
largeur : real
hauteur : real
perimetre()
surIace()
agrandir()
diagonal()
largeur : real
hauteur : real
perimetre()
surIace()
agrandir()
diagonal()
0e U|L SQL 117
Id_rectangle integer primary key,
largeur number,
hauteur number)
surface number,
perimetre number,
diagonal number)
L'InconvnIent de ce choIx rsIde dans l'aspect statIque. Lors de
modIfIcatIon des attrIbuts dont dpendent ces mthodes, Il faut mettre
jour les attrIbuts correspondants aux mthodes. 0ans notre cas, sI l'on
modIfIe la largeur d'un rectangle, Il faut mettre jour les attrIbuts sur]cce,
permetre, dcyoncl.
Utiliser des vues
Nous consacrons un chapItre complet aux vues. |aIs ds maIntenant, nous
pouvons soulIgner que les vues peuvent tre une solutIon dynamIque aux
mthodes quI ne modIfIent pas l'tat de l'objet et dont but est de retourner
une valeur sur l'tat de l'objet. Dn peut dIre que la vue va sImuler une table
semblable celle de Rectcnyle1. |aIs les attrIbuts sur]cce, permetre,
dcyoncl seront calculs chaque foIs que la table sera requIse dans une
slectIon.
Create vue Rectangle2 as
Select
Id_rectangle,
largeur,
hauteur
largeur*hauteur surface,
2*(largeur+hauteur) perimetre
sqrt(largeur*largeur+hauteur*hauteur) diagonal)
from Rectangle
Utiliser les methodes de mise jour
Nous consacrons aussI un chapItre la mIse jour des relatIons. Et cette
technIque peut tre parfoIs utIlIser pour crIre des scrIpts de mIse jour
correspondant une mthode modIfIant l'tat de l'objet. Sans entrer dans
les dtaIls, nous pouvons transcrIre la mthode doubler de Rectcnyle dans la
requte SQL suIvante :
Update Rectangle
Set largeur=2*largeur, hauteur=2*hauteur
Where num_rectangle=
Nous verrons qu'Il exIste pratIquement toujours une solutIon la
transcrIptIon des mthodes que l'utIlIsatIon d'un langage procdural permet
de traIter tous les cas. |aIs cecI ne remplace pas completement les
mthodes surtout dans les aspects d'hrItage !
1raduire les associations
L'objectIf est de mmorIser les lIens entre les objets de A et de 8. La
solutIon cette mmorIsatIon dpend de la cardInalIt de l'assocIatIon quI
lIe A et 8, plus exactement de ses maxImums.

Le tableau suIvant examIne les cas possIbles concernant le maxImum des
cardInalIts de A et de 8. SI un des deux maxImums est gal 1, alors Il est
possIble de sImplement ajouter une des cls dans une des relatIons. SI les
deux maxImums sont plus grands que 1, alors Il faut crer une nouvelle
relatIon.
|axA
|ax8 v
1 1
1 sI la cl de A = la cl de 8, ne
rIen faIre
Ajouter la cl de 8 dans la
relatIon de A comme attrIbut
ou Ajouter la cl de A dans la
relatIon de 8 comme attrIbut
Ajouter la cl de 8 dans la
relatIon de A comme attrIbut
1 Ajouter la cl de A dans la
relatIon de 8 comme attrIbut
Crer une relatIon A8 ayant
comme attrIbut la cl de A et
la cl de 8
ExamInons des exemples de ces cas
Un des maximum est egal un
0ans l'exemple suIvant une vIlle est rattache un canton au plus, par
contre un canton peut possder plusIeurs vIlles.

Villes
NomVille : string
Population : integer
NomVille : string
Cantons
NomCanton : string
SurIace : integer
NomCanton : string
SurIace : integer
rattache a
* 1

A
Cle de A : type
B
Cle de B : type Cle de A : type Cle de B : type
Association AB
min..maxA min..maxB
0e U|L SQL 119
Nous crons d'abord les relatIons Ccntons et \lles dIrectement partIr des
classes. NomCanton et Nom7Ille sont les cls des classes. Comme la
cardInalIt est de 1 au maxImum, nous devons ajouter, la relatIon \lles,
l'attrIbut Rcttcche. Nous pouvons ajouter que l'attrIbut Rcttcche doIt
toujours faIre rfrence une valeur dans la relatIon Ccntons (Cet aspect
sera plus amplement dIscut dans le chapItre sur les regles d'IntgrIt.

Create Table Cantons(
NomCanton varchar(20) primary key,
Surface number)

Create Table Villes(
NomVille varchar(20) primary key,
Population number
Rattache varchar(20)
references Cantons(NomCanton))

0ans l'exemple suIvant, nous avons le cas d'une assocIatIon quI lIe des objets
de la mme classe. La classe Personnes n'a pas de cl (Nom et Prnom ne
forment pas une cl sure car Il exIste toujours la possIbIlIt de doublons).
Nous ajoutons donc l'attrIbut ld_personne supplmentaIre la FelatIon
Personnes.

L'assocIatIon marI sera transcrIte par l'ajout d'un attrIbut ConjoInt
faIsant rfrence une personne exIstante. Nous obtenons fInalement le
schma suIvant :
Create Table Personne(
Id_personne number primary key,,
Nom varchar(20),
Prenom varchar(20),
DateNaiss date,
Personnes
Nom : string
Prenom : string
dateNaissance : date
Nom : string
Prenom : string
marie a
epoux
epouse
0..1
0..1
Conjoint number references Personne(Id_personne))

Les objets et les lIens de notre exemple, se reprsenteront dans la table
sous la forme suIvante

Id_personne Nom Prenom 0ateNaIss ConjoInt
11 |arIe 1J
12 Paul
1J Jean 11
14 Anne
Dn remarquera que la maIntenance des InformatIons ConjoInts demande une
attentIon accrue, car cette assocIatIon requIert la modIfIcatIon de deux
lIgnes sImultanment.
Les deux maximum sont plus grand que un
0ans l'exemple suIvant un lIvre peut tre assocI plusIeurs auteurs et un
auteur peut avoIr crIt plusIeurs lIvres. |anIfestement pour traIter cette
multIplIcIt de lIens, Il n'est pas possIble de sImplement ajouter un attrIbut
dans une relatIon ou l'autre. l faut ajouter une relatIon pour mmorIser ces
lIens.

Nous crons d'abord les relatIons Auteurs et Lvres avec leur cl respectIve.
Create Table Auteurs(
Id_auteur number primary key,
Nom varchar(20),
Personnes::Marie:
Personnes::Jean:
Personnes::Anne:
Personnes::Paul:
maries
Auteurs
Idauteur : integer
Nom : string
Prenom : string
Livres
ISBN : integer
Titre : string
Idauteur : integer
Nom : string
Prenom : string
ISBN : integer
Titre : string
ecrit par
* 1..*
0e U|L SQL 121
Prenom varchar(20))

Create Table Livres(
ISBN number primary key,,
Titre varchar(20))

EnsuIte, nous crons la relatIon EcrtPcr pour transcrIre l'assocIatIon.
Femarquons que la cl prImaIre de cette relatIon est forme par l'ensemble
de ces attrIbuts.

Create Table EcritPar(
Id_auteur number references Auteurs,
ISBN number references Livres,
primary key(Id_auteur, ISBN))

Feprenons l'exemple de la classe Personnes, ajoutons luI une assocIatIon
cm de. cI aussI, l'ajout d'un attrIbut ne suffIt pas, Il faut une nouvelle
relatIon que nous nommons Am_de.

Create Table Ami_de(
Id_personne number references Personne,
Id_ami number references Personne(id_personne),
primary key(Id_personne, Id_ami))

Etendons l'exemple d'objets et de lIens. Nous montrons dans la table
comment nous devons tenIr compte des lIens d'amItIs.
Personnes
Nom : string
Prenom : string
Nom : string
Prenom : string
marie a epoux
epouse
0..1
0..1
ami de
*
*

d_personne d_amI
12 11
11 12
12 1J
1J 12
1J 14
14 1J
A nouveau, nous attIrons votre attentIon sur la dIffIcult maIntenIr la
symtrIe et ventuellement la transItIvIt (ce que nous ne faIsons pas).
Association attribuee
L'assocIatIon attrIbu est traIte comme l'assocIatIon laquelle elle est
attache. 0ans le cas ou Il a suffIt d'ajouter un attrIbut cl dans une des
deux relatIons, Il suffIt aussI d'ajouter les attrIbuts de l'assocIatIon attrIbue
dans cette mme relatIon. 0ans le cas ou Il a fallu crer une nouvelle
relatIon, Il faut ajouter les attrIbuts de l'assocIatIon attrIbue dans cette
relatIon.
ExamInons l'exemple suIvant :

Nous crons les relatIons Personnes et 7Illes. Pour tenIr compte de
l'assocIatIon, nous crons la relatIon Trcvcller_c .avec les attrIbuts cls des
Personnes::Marie:
Personnes::Jean:
Personnes::Anne:
Personnes::Paul:
maries
ami
ami
ami
Travailler
depuis : date
jusqua : date
Personnes
Nom : string
Prenom : string
Villes
NomVille : string
Nom : string
Prenom : string
NomVille : string
depuis : date
jusqua : date
* *
0e U|L SQL 12J
relatIons Personnes et \lles. FInalement, nous ajoutons les attrIbuts 0epus
et 1usquc.

Create Table Personnes(
Id_personne number primary key,
Nom varchar(20),
Prenom varchar(20),
DateNaiss date)

Create Table Villes(
NomVille varchar(20) primary key,
Population number)

Create Table Travailler_a(
Id_personne number references Personnes,
NomVille varchar(20) references Villes,
Depuis date,
Jusqua date,
primary key(Id_personne, NomVille))

Agregation et composition
L'agrgatIon et la composItIon se traItent comme les assocIatIons. (La
dpendance entre les classes est souvent une IndIcatIon pour l'utIlIsatIon du
delete ccsccde, pour plus de dtaIl voIr le chapItre sur les regles
d'IntgrIt).
0ans l'exemple suIvant, les polygones sont composs de poInts et en plus Il
exIste une contraInte d'ordre sur les poInts le premIer, second, etc. poInt du
polygones. Cette contraInte d'ordre est traduIte par un attrIbut num_ordre
quI permet d'ordonner les poInts. Dn remarquera aussI que la relatIon PoInts
ne possede pas de cl propre, la cl est forme par les attrIbuts. ldPolyyone
et num_ordre.

Polygones
IdPolygone : integer
Couleur : string
Points
x : real
y : real
x : real
y : real
IdPolygone : integer
Couleur : string
ordonne}
1 3..*
Create Table Polygones(
IdPolygone number primary key,
Couleur varchar(20))

Create Table Points(
IdPolygone number references Polygones,
num_ordre number,
x number,
y number,
primary key (IdPolygone, num_ordre))
Generalisation
La gnralIsatIon ou l'hrItage est un concept quI n'a pas d'quIvalent dans
le modele relatIonnel. l faut donc faIre un choIx entre regrouper toutes les
partIcularIt dans une seule relatIon ou conserver chaque partIcularIt dans
une relatIon propre. ExamInons ces deux solutIons
1out dans un
Cette solutIon consIste mettre tous les attrIbuts dans la mme table,
ajouter un constItuant donnant le genre de l'objet.

create table Gnral(
Id_gnral number primary key,
genre varchar(20), -- valeurs possibles G, P1, P2
attributs_de_gnral ,

attributs_de_particulier1,
Gnral
Idgeneral : integer
Attributsgeneral : type
Particulier1
Attributsparticulier1 : type
Pariculier2
Attributsparticulier2 : type
Idgeneral : integer
Attributsgeneral : type
Attributsparticulier1 : type Attributsparticulier2 : type
0e U|L SQL 125

attributs_de_particulier2,
)

Les attrIbuts non utIlIss sont laIsss null. Dn peut crer une vue pour
chaque classe pour retrouver exactement la descrIptIon d'une classe
partIculIere.
l Important de voIr que cette solutIon correspond conceptuellement au faIt
que l'on consIdere les classes 6nrcl, Pcrtculer1 et Pcrtculer2 comme
une seule classe. Cette agrgatIon faIt perdre de la fInesse la
modlIsatIon, surtout sI les sousclasses entretenaIent des assocIatIons quI
leurs taIent propres.
Chacun sa place
0ans cette solutIon, chaque classe devIent une relatIon. Dn ajoute
ventuellement un attrIbut de genre dans la relatIon Cnral.

create table Gnral(
id_gnral number primary key,
genre varchar(20), -- valeurs possibles G, P1, P2
attribut_de_gnral )

create table Particulier1(
id_gnral number references Gnral,
attribut_de_particulier2 )

create table Particulier2(
id_gnral number references Gnral,
attribut_de_particulier2 )

cI le probleme devIent celuI de l'clatement de l'InformatIon. Dn peut aussI
crer une vue pour chaque classe pour retrouver exactement la descrIptIon
d'une classe partIculIere.
l Important de voIr que cette solutIon correspond conceptuellement au faIt
que l'on consIdere les classes 6nrcl, Pcrtculer1 et Pcrtculer2 lIes par
des assIocIatIons. Cette substItutIon faIt perdre de la fInesse la
modlIsatIon, maIs sI les sousclasses entretenaIent des assocIatIons quI leurs
taIent propres, cellescI restent dIstInctes.
ExamInons l'exemple suIvant avec les deux solutIons

Avec la solutIon tout dans un, nous retrouvons tous les attrIbuts dans la
relatIon 8ossons. L'assocIatIon composton est lIe maIntenant dIrectement
8oIsson, Il seraIt donc possIble de donner la composItIon d'un alcool. Pour
se prserver de cecI, Il faudra ajouter des contraIntes.
Create table Boissons(
Nom_boisson varchar(20) primary key,
Commentaire varchar(1000),
Genre char(7), -- Boisson, Eau, Alcool
Source varchar(20),
Teneur_en_alcool number)

Create table Sel_mineral(
Nom_sel varchar(20) primary key,
Formule varchar(100))

Create table Composition(
Nom_boisson varchar(20) references Boissons,
Nom_sel varchar(20) references Sel_mineral,
Quantite_mg number,
primary key (Nom_boisson, Nom_sel))

Nous antIcIpons un peu sur le chapItre des vues et nous donnons un exemple
de vue quI permet de reconstItuer le concept de classe Ecux:

Create view Eaux as
Select Nom_boisson, Commentaire, Source
From Boisson
Where genre =Eau
Boissons
NomBoisson : string
Commentaire : string
Eaux
Source : string
Alcools
DegreAlcool : integer
Sel Minraux
NomSel : string
Formule : string
composition
quantite : real
NomSel : string
Formule : string
quantite : real
Source : string
NomBoisson : string
Commentaire : string
DegreAlcool : integer
* *
0e U|L SQL 127
La solutIon chacun sa place, nous apporte une relatIon pour chaque classe.
L'assocIatIon composton est lIe maIntenant dIrectement Eaux, Il n'est
donc plus possIble de donner la composItIon d'un alcool. Par contre, une
boIsson doIt se grer dans plusIeurs relatIons ce quI complexIfIe la gestIon
des modIfIcatIons de la base de donnes.

Create table Boisson(
Nom_boisson varchar(20) primary key,
Commentaire varchar(1000),
Genre char(7)) -- Boisson, Eau, Alcool

Create table Eaux(
Nom_boisson varchar(20) references Boisson,
Source varchar(20),
primary key Nom_boisson)

Create table Alcools (
Nom_boisson varchar(20) references Boisson,
Teneur_en_alcool number,
primary key Nom_boisson)

Create table Sel_mineral(
Nom_sel varchar(20) primary key,
Formule varchar(100))

Create table Composition(
Nom_boisson varchar(20) references Eaux,
Nom_sel varchar(20) references Sel_mineral,
Quantite_mg number
primary key (Nom_boisson, Nom_sel))

Exemple de vue:
Create view Mineral as
Select m.Nom_boisson, b.Commentaire, m.Source
From Boisson b, Mineral m
Where m.nom_boisson=b.nom_boisson

Tableau rsumant les traductIons

hodIe Dbjet hodIe PeIatIonneI
Classe FelatIon
AttrIbut AttrIbut
|thode (vue, fonctIon, attrIbut,
procdure)
AssocIatIon
0..1,1..1 AttrIbut
0..n, n..m FelatIon
AssocIatIon attrIbue (voIr la cardInalIt de
l'assocIatIon)
AgrgatIon
0..1,1..1 AttrIbut (+valeur null)
0..n, n..m FelatIon
CnraIIsatIon
Tout dans un AttrIbut (+valeur null)
Chacun sa place FelatIon

Nous sommes maIntenant en mesure de lIre et d'Interprter une descrIptIon
de base de donnes accompagne de sa modlIsatIon. La prochaIne tape est
l'InterrogatIon d'une base de donnes.
Lxercices
Questions sur 11
3
1. En utIlIsant les regles de traductIons passer du dIagramme des classes
celuI des relatIons.
2. A partIr de l'ensemble des relatIons de TT
J
, En utIlIsant le langage de
modlIsatIon, 0onnez les prdIcats des relatIons
J. FemplIr des tables correspondant aux Instances des relatIons afIn
d'exprImer le texte quI suIt: Tout se passe le premIer de l'an
(NoJour=1), dans la tranche horaIre A. Le vhIcule ImmatIcul No 11
portant le numro de chassIs 249J est conduIt par le chauffeur |arcel
0upont. l est le chauffeur numro 7 et va chercher son taxI la
statIon No 4. l possede les permIs 81 et C. l faIt le pleIn du vhIcule
avec J0 lItres de super pour J20 KIlometres rouls. Une consommatIon
modre pour un modele 8UCK automatIque de 5 places
4. ExprImer l'aIde du langage de descrIptIon de donnes SQL, les
relatIons prcdentes.
0e U|L SQL 129
Reponses sur 11
3
Relations de 11
3

Type(modele,nbPlaces,catgorIe,typeCarburant, automatIque, poIds)
Chauffeur(noChauffeur,nom, prnom, adresse, noStatIon)
Carburant(noPlaque, noJour, kIlometrage, lItres, typeCarburant)
EntretIen(noChassIs, noJour, descrIptIon)
PermIs(noChauffeur, catgorIe)
PlannIng(noChauffeur, noChassIs, noJour, trancheHoraIre)
StatIon(noZone, noStatIon)
0Istance(heure, zone0e, zoneA, tempsParcours)
SItuatIon(noChassIs, noZone)
Predicats de 11
3

predIcat: 7hIcule(nc,np,s,m,ns) Le vhIcule portant le numro de
ChassIs nc et ImmatrIcul np a t mIs en servIce le s, Il est du modele
m et appartIent la statIon ns
Type(modele,nbPlaces,catgorIe,typeCarburant, automatIque, poIds)
predIcat: Type(m,s,c,tc,a,p) Le modele m de vhIcule peut
contenIr s personnes, pese p [kg], consomme du carburant tc, la bote
vItesse est a, le permIs c est ncessaIre pour le conduIre
predIcat: Chauffeur(nch,n,p,a,ns) Le chauffeur portant le nom n
est le prnom p habIte a. Il est IdentIfI par le numro nch et Il est
assIgn la statIon ns
Carburant(noPlaque, noJour, kIlometrage, lItres, typeCarburant)
predIcat: Carburant(np,j,k,l,tc) Le jour j, le vhIcule ImmatrIcul
np a effectu un pleIn de I lItres de tc carburant apres avoIr roul k
kIlometres
EntretIen(noChassIs, noJour, descrIptIon)
predIcat: EntretIen(nc, j, d) Le jour j, le vhIcule avec numro de
chassIs nc a subI l'entretIen d
PermIs(noChauffeur, catgorIe)
predIcat: PermIs(nch,c) Le chauffeur portant le numro nch
possede un permIs c
PlannIng(noChauffeur, noChassIs, noJour, trancheHoraIre)
predIcat: PlannIng(nch,nc,j,h) Le chauffeur portant le numro nch
doIt conduIre le vhIcule portant le numro de chassIs nc le jour j
durant la tranche horaIre h
StatIon(noZone, noStatIon)
predIcat: StatIon(nZ,nS) La statIon nS se trouve dans la zone nZ
0Istance(heure, zone0e, zoneA, tempsParcours)
predIcat: 0Istance(h,zd,za,t) A l'heure h, pour aller de zd za, on
estIme qu'Il faut t mInutes
SItuatIon(noChassIs, noZone)
predIcat: SItuatIon(nc,nz Actuellement, le vhIcule portant le
numro de chassIs nc attend dans la zone nz
Semantique : Lntites du champ d'application
7hIcule( noChassIs noPlaque mIseEnServIce modele noStatIon)
249J 11 8uIck 4

Type( modele nbPlaces catgorIe typeCarburant automatIque poIds)
8uIck 5 ouI

Carburant( noPlaque noJour kIlometrage lItres typeCarburant)
11 1 J20 J0 super

EntretIen( noChassIs noJour descrIptIon)

Chauffeur( noChauffeur nom prnom adresse noStatIon)
7 0upont |arcel 4

PermIs( noChauffeur catgorIe)
7 b1
7 c

PlannIng( noChauffeur noChassIs noJour trancheHoraIre)
7 249J 1 a

StatIon( noZone noStatIon)

Dn constate que certaInes entIts sont Incompletes par rapport l'nonc.
0e U|L SQL 1J1
Creation de table
Dn commence par donner un domaIne SQL chaque constItuant:
adresse texte varchar(80)
automatIque boolen char(1)
catgorIe mot (A,81,82,C ...) char(2)
descrIptIon texte varchar(240)
heure entIer [0..2J] number(2)
kIlometrage entIer posItIf number
lItres rel [0..500] number(J)
mIseEnServIce date date
modele mot (mercedesJ00,...) varchar(12)
nbPlaces entIer [4..80] number(2)
noChassIs entIer posItIf number
noChauffeur entIer posItIf number
noJour entIer [1..J66] number(J)
nom mot (0upont, ...) varchar(24)
noPlaque entIer [1..9999] number
noStatIon entIer [1..6] number(1)
noZone entIer [1..99] number(2)
poIds entIer [500..15000] number(5)
prnom mot (Jean, |arIe, ...) varchar(24)
tempsParcours entIer posItIf number(J)
trancheHoraIre mot (A,8,C) char(1)
typeCarburant mot (super,) varchar(12)
zoneA entIer [1..99] number(2)
zone0e entIer [1..99] number(2)

CREATE TABLE Vehicule( noChassis number,
noPlaque number,
miseEnService date,
modele varchar(12),
noStation number(1))

CREATE TABLE Type( modele varchar(12),
nbPlaces number(2),
categorie char(2),
typeCarburant char(12),
automatique char(1),
poids number(5))

CREATE TABLE Carburant( noPlaque number,
noJour number(3),
kilometrage number,
litres number(3),
typeCarburant varchar(12))

CREATE TABLE Entretien( noChassis number,
noJour number(3),
description varchar(240))

CREATE TABLE Chauffeur( noChauffeur number,
nom varchar(24),
prenom varchar(24),
adresse varchar(80),

CREATE TABLE Permis( noChauffeur number,
categorie char(2))

CREATE TABLE Planning( noChauffeur number,
noChassis number,
noJour number(3),
trancheHoraire char(1))

CREATE TABLE Station( noZone number(2),

CREATE TABLE Distance( heure number(2),
zoneDe number(2),
zoneA number(2),
tempsParcours number(3))

CREATE TABLE Situation( noChassis number,
noZone number(2))

9. Algbre relationnelle
"Le processus de la pense dans son ensemble nous est
encore relativement mystrieux, mais je crois que toutes
les tentatives de cration de machines pensantes nous
seront d'une grande aide pour dcouvrir comment nous
pensons nous-mmes" Alan Turing Cit par Andrew
Hodges dans Alan Turing ou l'nigme de l'intelligence
Avant d'examIner, l'InterrogatIon en SQL d'une base de donnes, nous allons
dfInIr l'algebre relatIonnelle d'une part, car elle est le fondement des
mcanIsmes mIs en oeuvre dans l'InterrogatIon SQL. 0'autre part car elle
nous permettra d'explIcIter sImplement des regles d'IntgrIt lorsque nous
aborderons ce chapItre.
L'unIon, la dIffrence, la projectIon, le produIt cartsIen et la slectIon sont
les cInq opratIons de base sur les relatIons quI dfInIssent l'algebre
relatIonnelle. Une des proprIts d'une algebre est que sI l'on utIlIse une
opratIon de cellecI sur des lments pour laquelle elle est dfInIe, le
rsultat est aussI un lment de cet unIvers. 0ans notre cas, cela sIgnIfIe que
le rsultat d'une expressIon de l'algebre relatIonnelle dfInIe sur des
relatIons est aussI une relatIon. L'algebre relatIonnelle, nous permet donc de
manIpuler les relatIons et d'obtenIr de nouvelles relatIons. L'Intrt de
l'algebre relatIonnelle rsIde dans le faIt que les expressIons algbrIques
peuvent tre Interprtes comme la spcIfIcatIon d'InterrogatIon sur une
base de donnes.
Operations algbriques
Nous utIlIsons, pour les exemples, les deux Instances de relatIon suIvantes:
F S
A 8 C 0 E F
a b c b g a
d a f d a f
c b d
Les opratIons algebrIques ont un rsultat quI est une relatIon. ls sont donc
dfInIs selon les deux dImensIons, l'une structurale quI IndIque le produIt
cartsIen, les constItuants et les domaInes du rsultat et l'autre smantIque
quI spcIfIe le prdIcat du rsultat. Ces dfInItIons sont bases sur les
relatIons ImplIques dans l'opratIon.
0e U|L SQL 1J5
En mathmatIque, Il n'y a pas de dIstInctIon entre la relatIon et son Instance.
La dfInItIon des opratIons algbrIques est posItIonnelle par rapport aux
constItuants, C
r2
dfInIt le 2 Ieme constItuant de la relatIon F. L'crt dune
relcton F correspond la cardInalIt de F
+
soIt : F
+
. 0ans notre cas,
L'arIt de F et de S est gale J. La cardInalIt de la relatIon correspond au
nombre d'entIts qu'elle contIent (note F). La cardInalIt de F est J et
celle de S est 2.
L'union
0fInItIon:
SoIt F et S des relatIons telles que F
+
= S
+
(mme arIt)
Alors T= F S dnote l'unon de R et S
ou
1) C
tI
T
+
tel que dom(C
tI
)= dom(C
rI
) dom(C
sI
)
2) = F S , en renommant les constItuants s'Ils sont
dIffrents dans F et S.
Exemple:
T=F S

a b c
d a f
c b d
b g a
La cardInalIt du rsultat est IT IF + IS.
Au nIveau des Instances on aura :
Un nuplet t sera une entIt de F S sI et seulement sI (F S)(t) =
vraI, cd sI et seulement sI F (t) = vraI S (t) = vraI donc sI et
seulement sI t est une entIt de F ou une entIt de S. En d'autre termes : on
obtIendra l'Instance de F S correspondante en faIsant IF IS.
Les domaInes des constItuants du rsultat sont forms par l'unIon des
domaInes des constItuants des oprandes (en respectant leur posItIon). Le
prdIcat du rsultat spcIfIe que les entIts sont des entIts appartenant
F, plus celles appartenant S.
L'unIon permet de dfInIr de nouvelles relatIons quI ont pour prdIcat le ou
logIque des prdIcats des relatIons oprandes. Par exemple, les personnes
absentes sont les personnes malades ou les personnes en vacances, soIt:
PEFS_A8SENTES = PEFS_|ALA0ES PEFS_EN_7ACANCES
La difference
0fInItIon:
+
=S
+
(mme arIt)
Alors T=F S dnote la d]]rence de S sur R
ou
1) T
+
= F
+

2 = F S
Exemple:
T=F S
A 8 C
a b c
c b d
La cardInalIt du rsultat est IT IF
Pour les Instances,on a: IT = IF - IS
Les domaInes des constItuants du rsultat sont les domaInes des constItuants
du premIer oprande. Le prdIcat du rsultat spcIfIe que les entIts sont
des entIts appartenant F et n'appartenant pas S.
La dIffrence permet de dfInIr de nouvelles relatIons quI vrIfIent le
prdIcat logIque du premIer oprande et quI ne vrIfIent pas celuI du
deuxIeme. Par exemple, les plantes non comestIbles sont des plantes sauf
celles quI sont comestIbles, soIt:
NDN_CD|EST8LE= PLANTES PLANTES_CD|EST8LES
La projection
0fInItIon:
SoIt F une relatIon , X=[ X
1
, ., X
k
] et X F
+

Alors T=F[X] dnote la pro]ecton de R sur X
7

ou
1) T
+
= X
2) = X
1
, ., X
k
. F
Exemple:
T=F[A,C]
A C
a c
d f
c d
Femarques:
La cardInalIt du rsultat est IT IF
Pour les Instances, on a : IT = [t T r IF . r.X = t ].

7
autre notatIon courante : F[X
1
,X
2
,...X
n
] =
X
1
,X
2
,...X
n
(F)
0e U|L SQL 1J7
Les domaInes des constItuants du rsultat sont quIvalents ceux de la
relatIon oprande. Le prdIcat du rsultat est restreInt aux constItuants de
la projectIon.
La projectIon permet de conserver les constItuants Intressants. Par
exemple, les couleurs des plantes comestIbles est dfInI par la projectIon
des plantes comestIbles sur le constItuant CDULEUF(en supposant qu'Il
exIste), soIt
CDULEUF_0ES_CD|EST8LE= PLANTES_CD|EST8LES[CDULEUF]
Par extensIon, on peut utIlIser l'oprateur de projectIon sur une entIt.
r.[X] est quIvalent r.X .
Le produit
0fInItIon:
+
S
+
=
Alors T=F S dnote le produt (ccrtsen) de S et R
ou
1) T
+
=F
+
S
+

2) = = F S
Exemple:
T=F S
A 8 C 0 E F
a b c b g a
a b c d a f
d a f b g a
d a f d a f
c b d b g a
c b d d a f
La cardInalIt du rsultat est IT = IF*IS
L'Instance IT de T = F S correspondant aux Instance IF et IS de F et S est
[t T t.F+ IF t.S+ IS].
Les constItuants du rsultat sont forms par l'unIon des constItuants des
oprandes. Le prdIcat du rsultat spcIfIe que les entIts projetes sur F
+

sont des entIts appartenant F et projetes sur S
+

sont des entIts
appartenant S.
Le produIt permet de dfInIr des nouvelles relatIons quI sont le produIt
cartsIen de deux autres relatIons. Par exemple, un agenda sera le produIt
cartsIen des jours de la semaIne et des heures ouvrables, soIt:
ACEN0A = JDUFS_SE|ANE HEUFES_DU7FA8LES
La selection
0fInItIon:
SoIt F une relatIon et F une formule comprenant:
I) des oprandes (des noms de constItuants de F
+
)
II) des oprateurs de comparaIson (,,=,...)
III) des connecteurs logIques (,)
Alors T= (*F) F dnote la slecton de R pcr F
8

ou
1) T
+
=F
+

2) T = F = F
Exemple: IcI la formule slectIonne les entIts dont la projectIon sur 8 est
gal b
(* 8='b') F
A 8 C
a b c
c b d
La cardInalIt du rsultat est IT IF.
Dn a pour l'Instance IT, IT = [t IF. F(t)]
Les domaInes des constItuants du rsultat sont quIvalents ceux de la
relatIon oprande. Le prdIcat du rsultat est celuI de la relatIon oprande
restreInt la fonctIon de slectIon.
La slectIon permet de dfInIr de nouvelles relatIons quI restreIgnent les
entIts de la relatIon oprande par une fonctIon de slectIon sur ses
constItuants. Par exemple, les plantes vertes sont des plantes dont la
couleur est verte, soIt:
PLANTES_7EFTES= (*CDULEUF=verte) PLANTES
Jointures
Nous avons vu les cInq opratIons de base de l'algebre relatIonnelle, nous
allons examIner d'autres opratIons drIves de cellescI. L'opratIon de
]onture est l'opratIon la plus fondamentale dans la manIpulatIon des
relatIons, elle permet d'assocIer deux relatIons par des constItuants ayant
une mme smantIque. 0ans les exemples quI suIvent nous utIlIserons, la
relatIon F et S suIvantes (les constItuants sont IndIcs par le nom de la
relatIon):
F S
A
F
8
F
C
F
C
S
0
S

a b 1 1 d

8
autre notatIon courante : (*F) F =
F
(F)
0e U|L SQL 1J9
d a 6 J e
c b J 1 b

La jointure (la theta-jointure)
0fInItIon:
+
S
+

=
Alors T=F
C
F
C
S

S dnote la ]onture de S et R .
est un oprateur logIque de comparaIson (=,,, ...)
ou
1) T
+
=F
+
S
+

2) T = F S C
F
C
S

Exemple: les C
F
sont strIctement plus petIts que les C
S

T=F CF CS S
A 8 C
F
C
S
0
a b 1 J e
La cardInalIt du rsultat est IT IF*IS
Les constItuants du rsultat sont forms par l'unIon des constItuants des
oprandes. Le prdIcat du rsultat spcIfIe que les entIts projetes sur F
+

sont des entIts appartenant F et projetes sur S
+
sont des entIts
appartenant S, et de plus que les entIts vrIfIent la condItIon pour les
constItuants spcIfIs.
La joInture permet de dfInIr une nouvelle relatIon dont les entIts
respectent une condItIon sur les constItuants de la joInture. Par exemple,
supposons que le constItuant SDL soIt commun aux relatIons PLANTES et
FECDNS, alors la joInture de FECDNS et PLANTES par rapport l'galIt
de SDL dans chacune aura pour rsultat toutes les plantes compatIbles avec
le sol d'une rgIon, soIt:
PLANTES_FECDNNAL= PLANTES
SDL
PLANTES
=SDL
FECDNS
FECDNS
Dn peut exprImer la joInture, l'aIde des opratIons de base:
F
C
F
C
S

S = (*
C
F
C
S
) (F S)
Dn peut tendre la condItIon plusIeurs constItuants. Les entIts du rsultat
doIvent alors vrIfIer toutes les condItIons:
F (
C
F1
C
S1
)(
C
F2
C
S2
) ... (
C
Fn
C
Sn
)

S
Variations sur la jointure
l exIste plusIeurs varIatIons de la joInture. Sur la base de l'InventaIre
effectu par P. |Ishra et |.H. EIch [|SH92], nous en donnerons une
dfInItIon quIvalente en terme des oprateurs de base de l'algebre
relatIonnelle.
Lqui-jointure
L'oprateur le plus courament utIlIs est celuI de l'galIt; l'opratIon est
alors appele qu]onture.
quIjoInture : T=F CF CS S
A 8 C
F
C
S
0
a b 1 1 d
a b 1 1 b
c b J J e
L'quIjoInture est quIvalente l'expressIon algbrIque:
F
C
F
= C
S

S = (*
C
F
= C
S
) (F

S)
Jointure naturelle
Les colonnes joIntes ont toujours un contenu IdentIque, on peut donc en
supprImer une (celle de la deuxIeme relatIon). 0ans ce cas, l'opratIon est
appele ]onture ncturelle , que l'on note F*S, Il faut cependant que les
constItuants joIndre portent le mme nom.
joInture naturelle : T=F * S
A 8 C 0
a b 1 d
a b 1 b
c b J e
Dn appelle chcrnre de R et S , l'IntersectIon de F
+
et S
+
note FS
+

SoIt les constItuants (IndIcs) S appartenant la charnIere :
SFS
+
=[C
S1
, C
S2
, ..., C
Sn
] et ceux de F FFS
+
=[C
F1
, C
F2
, ..., C
Fn
]
La joInture naturelle est quIvalente l'expressIon algbrIque:
F*S = (*(
C
F1
= C
S1
)(
C
F2
= C
S2
) ... (
C
Fn
= C
Sn
) (F

S))[(F
+
S
+
)SFS
+

]
Semi-jointure
0ans la joInture, les constItuants de F et de S sont prsents dans le rsultat,
dans la semIjoInture seuls ceux de F sont conservs, elle est note :
F
C
F
C
S

S
semIjoInture : T = F
C
F
= C
S

S
A 8 C
0e U|L SQL 141
a b 1
a b 1
c b J
La semIjoInture est quIvalente l'expressIon algbrIque:
F
C
F
C
S

S = (*
C
F
C
S
)(F

S)[F
+
]

Jointure externe
0ans la joInture, un certaIn nombre d'entIts ne sont pas prIses en
consIdratIon. La joInture externe permet de rajouter au rsultat les entIts
d'une des deux relatIons (cecI permet de travaIller avec des donnes
Incompletes ayant des valeurs nulles). Dn dIstInguera la ]onture externe
ycuche, note F= S quI ajoute les entIts de F compltes par des
valeurs nulles pour les constItuants de S; la ]onture externe drote, note F
= S quI ajoute les entIts de S compltes par des valeurs nulles pour
les constItuants de F et ]onture externe complte, note F= = S quI
ajoute les entIts de F et de S compltes par des valeurs nulles pour les
constItuants respectIfs nondfInIs.
semIjoInture gauche : T= F= S
A 8 C
F
C
S
0
a b 1 1 d
a b 1 1 b
c b J J e
d a 6

La joInture externe gauche est quIvalente l'expressIon algbrIque
9
:
F= S = ((*
C
F
= C
S
)(F

S)) F
S

Lxpression algebrique
Nous avons vu Isolment chaque opratIon, voyons maIntenant comment
nous pouvons former des expressIons. Nous donnons premIerement le
vocabulaIre de nos expressIons et ensuIte la dfInItIon d'expressIons
algbrIques bIen formes.
7ocabulaIre: troIs catgorIes de symboles apparaIssent dans les expressIons
algbrIques
I) les noms des relatIons appartenant la modlIsatIon
[F
1
, F
2
, ...,F
m
]= |d.

9
Pour dfInIr formellement cette opratIon, Il faut tendre la dfInItIon de l'unIon au
traItement des valeurs nulles. F
S
dnote la relatIon F tendue aux constItuants de S avec
des valeurs nulles.
II) les noms des constItuants contenus dans F
I
+
, I=1..m
III) les formule F telle que:
1) les constantes et les noms de constItuants sont des atomes
2) la forme ( atome
a
atome) est une formule
ou
a
[,,=,=,...]
J) la forme ( formule
l
formule) est une formule
ou
l
[, ]
4) la forme ( formule) est une formule
5) rIen d'autre n'est une formule
F
+
dsIgne l'ensemble des constItuants utIlIss dans une formule F
Dn dIt qu'une expressIon (algbrIque) est bIen forme (ebf) sI elle est
obtenue par les regles suIvantes:
I) un nom de relatIon est une ebf.
II) sI E
1
et E
2
sont des ebf alors
1) (E
1
E
2
), (E
1
E
2
) et (E
1
E
2
) sont des ebf sI E
1
+
=E
2
+

2) (E
1

E
2
) est une ebf sI E
1
+
E
2
+
=
J) (E
1
(*F) E
2
) est une ebf sI F
+
E
1
+
E
2
+
et E
1
+
E
2
+
=
4) (E
1
[X]) est une ebf sI X E
1
+

5) ((*F)E
1
) est une ebf sI F
+
E
1
+

III) rIen d'autre n'est une ebf
Femarques:
Dn peut supprImer le test de l'IntersectIon vIde entre deux relatIons sI l'on
IndIce le nom de tous les constItuants d'une relatIon.
Dn peut supprImer des parentheses sI la smantIque de l'ebf est sans
ambIgut
Langage algebrique, un langage d'interrogation
Nous avons suggr que les expressIons algbrIques sont la reprsentatIon de
questIons que l'on peut formuler sur un champ d'applIcatIon. ExamInons le
processus d'InterrogatIon. 0ans l'Idal nous dIrIgerIons dIrectement vers le
champ d'applIcatIon notre InterrogatIon en vue d'obtenIr une rponse, maIs
la ralIt est relatIvement muette. Nous avons modlIs le champ
d'applIcatIon, en vue d'y effectuer des calculs symbolIques, Il faut donc
transformer notre InterrogatIon portant sur le champ d'applIcatIon en une
InterrogatIon portant sur la modlIsatIon. Cette InterrogatIon correspond
une expressIon algbrIque. l suffIt alors de concrtIser cette expressIon en
la calculant avec les valeurs des Instances de la base de donnes. le rsultat
est une Instance quI doIt tre Interprte comme la rponse de la questIon
InItIale sur le champ d'applIcatIon.
La qualIt de cette rponse dpend des troIs tapes suIvantes:
la modlIsatIon est fIdele dans le contexte de la questIon
0e U|L SQL 14J
les Instances des relatIons sont des InterprtatIons correctes du champ
d'applIcatIon
la formulatIon de l'InterrogatIon est smantIquement correcte. En
effet une expressIon algbrIque bIen forme correspond une
InterrogatIon, maIs pas forcment l'InterrogatIon InItIale.
Exemple d'InterrogatIon
Pour facIlIter la formulatIon des InterrogatIons, nous pouvons reprsenter
notre modlIsatIon graphIquement. 0eux types de nuds sont reprsents:
les constItuants et les relatIons. Les artes non orIentes lIent les
constItuants la relatIon dont Ils font partIe. Pour le champ d'applIcatIon
Hotel, nous obtenons le graphe de la FIgure 92.

FIgure 91 : InterrogatIon avec une expressIon algbrIque
Le processus de modlIsatIon de l'InterrogatIon suIt le schma suIvant:
spcIfIer les constItuants de la slectIon
spcIfIer les constItuants du rsultat (projectIon)
les tapes a) et b) dfInIssent les relatIons ImplIques dans l'expressIon
algbrIque.
dfInIr les joIntures entre les relatIons
1) Les chambres avec baIn et T7 :
iR1
...
iRn
Md
objets
du
C.A.
interrogation
rponse du CA
Formulation
expr. algbrique
rsultat
calcul avec
les instances
interprtation

FIgure 92 :modlIsatIon graphIque d'HDTEL
Les InformatIons baIn et T7 appartIennent respectIvement aux domaInes des
constItuants Confort et EquIpement, le rsultat est dfInIt par les
constItuants de la relatIon Chambres. Seule la relatIon chambre est
ImplIque dans cette InterrogatIon, donc nous ne spcIfIons pas de joInture.
Nous obtenons donc l'expressIon suIvante:
(* ((Confort=baIn)(EquIpement=T7))) Chambres
2) Les numros des chambres et leur capacIt :
Seules les InformatIons sur les constItuants Numchambre et NbrPers, nous
Intressent. Nous obtenons donc l'expressIon suIvante:
(Chambres [NumChambre, NbrPers])
J) Les noms des clIents ayant rservs une chambre pour le 251289 :
La slectIon porte sur les constItuants 0ateArr et 0ate0ep de la relatIon
FservatIon. Le constItuant du rsultat Nom appartIent la relatIon ClIents.
l faut donc dfInIr le lIen entre les relatIons ClIent et FservatIon, nous
utIlIsons IcI la joInture naturelle portant sur le constItuant NumClIent
commun aux deux relatIons.
(*((0ateArr = 251289)(0ate0ep 251289))(ClIents*FservatIon))[Nom]
NOM
PRENOM
ADRESSE
NUMCLIENT
NUMCHAMBRE
PRIX
NBLIT
NBPERS
CONFORT
EQUIPEMENT
DATEDEP
DATEARR
CLIENTS
CHAMBRES
RESERVATION
0e U|L SQL 145

FIgure 9J :modlIsatIon graphIque de la questIon: Les noms des clIents
ayant rservs une chambre pour le 251289 :
4) Le nom des clIents et le confort des chambres qu'Ils ont rservs:

FIgure 94 :modlIsatIon graphIque de la questIon: Le nom des clIents et le
confort des chambres qu'Ils ont rservs:
Le constItuant du rsultat Nom appartIent la relatIon ClIents et le
constItuant Confort appartIent Chambres. l faut donc dfInIr le lIen entre
les relatIons ClIents et Chambres, pour cela Il faut aussI ImplIquer la relatIon
FservatIon. Nous utIlIsons IcI la joInture naturelle portant sur le constItuant
NumClIent commun aux relatIons ClIents et FservatIon, ensuIte,.nous
utIlIsons IcI la joInture naturelle portant sur le constItuant NumChambre
commun l'expressIon prcdemment calcule et la relatIon Chambres.
((ClIents * FservatIon) * Chambres)[Nom, Confort]
5) La capacIt thorIque d'accueIl de l'hotel :
Pour rpondre cette questIon, Il est ncessaIre d'effectuer la somme
de toutes les valeurs de NbrPers dfInIe pour chaque chambre. Notre
langage algbrIque, ne peut pas exprImer une telle expressIon.
L'expressIon de cette InterrogatIon est donc remIse au chapItre suIvant.
|NOM|
DATEDEP 25-12-89
DATEARR ~25-12-89
CLIENTS
RESERVATION
*
NUMCLIENT
|NOM|
|CONFORT|
CLIENTS
CHAMBRES
RESERVATION
*
NUMCLIENT
*
NUMCHAMBRE
Lxercices
Questions sur 11
3
1) EtablIr le graphe de relatIons de la modlIsatIon de TT
J
2) ExprImer les InterrogatIons suIvantes avec une expressIon algbrIque, en
suIvant le schma dfInIt plushaut.
La zone ou est sItu le vhIcule ayant le no de chassIs J24.
Le plannIng du chauffeur nomm 0upont.
La lIste des entretIens effectus sur le vhIcule ayant le no de chassIs
J24.
La lIste des vhIcules dont le pleIn a t effectu avec un type de
carburant quI n'taIt pas celuI spcIfI par le modele du vhIcule.
La lIste des chauffeurs pouvant conduIre le vhIcule ayant le no de
chassIs J24.
La lIste des chauffeurs pouvant conduIre le vhIcule ayant le no de
chassIs J24 et quI appartIennent la mme statIon que ce vhIcule.
Reponses sur 11
3
graphe de relatIons de la modlIsatIon de TT
J
Nous avons regroup NoZone, Zone0e, ZoneA car Il s'agIt de synonymes
exprImant la mme notIon. Par contre, nous avons consIdr que NoJour quI
apparaIssaIt dans plusIeurs relatIons recouvraIt des notIons dIffrentes;
NoJour_du_pleIn, NoJour_de_l_entretIen, etc et que des joIntures naturelles
sur un tel constItuant ne donnaIent que des InformatIons faIblement
assocIes. En faIt, EntretIen * Carburant permutent tous les entretIens et
tous les pleIns effectus le mme jour.

ExpressIon algbrIque
a) La zone ou est sItu le vhIcule ayant le no de chassIs J24.
a1) (((*NochassIs=J24)7hIcule) * SItuatIon)[NoZone]
l est Intressant de voIr que par les proprIts de l'algebre relatIonnelle, la
slectIon peut tre place avant la joInture ou apres (a2) sans modIfIer le
rsultat
a2) ((*NochassIs=J24)(7hIcule * SItuatIon))[NoZone]
Une autre joInture (aJ) permet aussI d'assocIer les NoZone et les NoChassIs,
maIs le NoZone a un sens completement dIffrent, Il s'agIt de la zone du
vhIcule quand Il est gar sa statIon.
aJ) ((*NochassIs=J24)(7hIcule * StatIon))[NoZone]
b) Le plannIng du chauffeur nomm 0upont.
b1) ((*Nom='0upont')(Chauffeur * PlannIng))[PlannIng
+
]
0e U|L SQL 147
S'Il exIste plusIeurs 0upont dans la compagnIe, nous allons trouver les
plannIng des 0upont.

FIgure 95 :modlIsatIon TTJ
c) La lIste des vhIcules dont le pleIn a t effectu avec un type de
carburant quI n'taIt pas celuI spcIfI par le modele du vhIcule.
c1) ((*typecarburant
Carburant
=typecarburant
7hIcule
)
((Carburant * 7hIcule) * Type))[Carburant
+
]
d) La lIste des chauffeurs pouvant conduIre le vhIcule ayant le no de chassIs
J24
d1) ((*NochassIs=J24)
(((7hIcule*Type)* permIs)* Chauffeur))[Chauffeur
+
]
e) La lIste des chauffeurs pouvant conduIre le vhIcule ayant le no de chassIs
J24 et quI appartIennent la mme statIon que ce vhIcule
Pour rpondre cette questIon, Il faut spcIfIer une condItIon
supplmentaIre sur d1)
d1) ((*NochassIs=J24)(NoStatIon
7hIcule
=NoStatIon
Chauffeur
)
(((7hIcule*Type)* permIs)* Chauffeur))[Chauffeur
+
]
Vhicule
Type
Chauffeur
Station
Carburant Entretien
Permis
Planning
Situation
Distance
noChassis
modle
typeCarburant
noZone
zoneDe
zoneA
catgorie
noPlaque
miseEnService
nbPlaces
automatique
poids
nom
prnom
adresse
noJour
kilometrage
litre
noJour
description
noJour
trancheHoraire
heure
tempsParcours
noChauffeur
noStation
F SELECT * FFD| F
F[X] SELECT C
1
,

C
2
, ..., C
n
FFD|
F
(*F)F SELECT * FFD| F WHEFE F
F S SELECT F.*,S.* FFD| F,S
F
C
F
C
S

S SELECT F.*,S.* FFD| F,S WHEFE
F.C
1
S.C
1

F S = SELECT * FFD| F unIon
SELECT * FFD| S
SELECT C1, C2, ..., Cm
FROM R1, R2, ... , Rn
WHERE F
J0. Interrogation en SQL
"Le jour l'aurore
les arbres tremblent
comme un dlire
le langage le monde
ne nous appartiennent pas"
Patrick Laupin - Le jour l'aurore
Nous allons tablIr la correspondance entre le langage algbrIque et les
dclaratIons de slectIon en SQL. CecI nous donnera un premIer modele
d'une machIne SQL quI calculeraIt le rsultat de la slectIon partIr des
tables. EnsuIte, nous examInerons la syntaxe complete de la slectIon en SQL
et au fur et mesure, nous tendrons le modele de la machIne SQL aux
dIffrentes clauses. La machIne SQL est un modele quI nous permet de
dtermIner de faon sure le rsultat d'une requte d'InterrogatIon.
Du langage algebrique SQL
La clause de la requte SQL est forme prIncIpalement de troIs mots cls
SELECT ... FPDh ... WHEPE ... Le premIer dtermIne les constItuants de la
table rsultat. Le second dtermIne les tables ImplIques dans la requte.
Le dernIer Impose une condItIon sur les entIts. Nous pouvons donc tablIr
les correspondances suIvantes entre les expressIons algbrIques et les
requtes SQL.
La relatIon F
La projectIon F[X] ou X=[C
1
,

C
2
, ..., C
n
]
La slectIon (*F)F
Le produIt F S
La joInture de F et S
L'unIon (IntersectIon, dIffrence) F S
0'une manIere gnrale, la requte SQL suIvante:
0e U|L SQL 149
(*F) F1 F2 ... Fn [C1,
C2, ..., Cm]
SELECT * FROM CHAMBRES
NUM_CHAMBRE PRIX NBR_LITS NBR_PERS CONFOR EQU
----------- ---------- ---------- ---------- ------ ---
10 80 1 2 WC NON
20 80 1 2 WC NON
30 80 1 2 WC NON
40 80 1 2 WC NON
11 90 2 2 WC NON
21 90 2 2 WC NON
31 90 2 2 WC NON
41 90 2 2 WC NON
12 100 2 2 DOUCHE NON
13 120 1 2 BAIN NON
23 120 1 2 BAIN NON
33 120 1 2 BAIN NON
43 120 1 2 BAIN NON
14 140 2 2 BAIN TV
24 140 2 2 BAIN TV
est quIvalente l'expressIon algbrIque suIvante:
Ce rsultat nous donne le modele de la machIne SQL (FIgure 101):
faIre le produIt cartsIen de toutes les relatIons cItes apres le FRDM
slectIonner les entIts satIsfaIsant la condItIon dcrIte apres WHERE
projeter sur les constItuants cIts apres le SELECT

FIgure 101 :|odele , modele sImplIfI de la machIne SQL
Pour nos exemples, nous utIlIserons l'exemple Hotel avec les Instance
suIvantes des relatIons, que nous obtenons avec les requtes suIvantes:
R1 R2 ... Rn
From .... Produit catsien
Where .... prdicat
select .... projection
n-uplet
entit
relation
34 140 2 2 BAIN TV
44 140 2 2 BAIN TV
15 180 3 4 BAIN TV
25 180 3 4 BAIN TV
35 180 3 4 BAIN TV
45 180 3 4 BAIN TV
SELECT * FROM CLIENTS
NUM_CLIENT NOM PRENOM ADRESSE
---------- ---------- ---------- --------------------------------
1000 GASCON GASTON 12 av. du Gnral 1239 ICI
1001 DUPONT PIERRE 12 ch. des hirondelles 1238 LABAS
1002 DUFOUR JEAN 10 av. de la gar 1300 AILLEURS
1003 ZORO DIEGO 10 ch des voleurs Los Angeles
1004 EINSTEIN ALBERT 10 rt la relativit 1004 PLUS-LOIN
1005 DUMAS ALEXANDRE 10 route du moulins LE-SUD
1007 NOBODY FRANCOISE 403 route de l inconnu 75000 Paris
1006 ROMULUS BERNADETTE 241 route de rome 1409 Lion
1009 AGDA BRUNO 10 route de l impossible 1508 TEXAS
1008 CHADOK AMELIE 25 rue de la rame 1456 Tombouctou
SELECT * FROM RESERVATIONS
(* ((Confort=baIn)(EquIpement=T7)) Chambres
devIent en SQL
SELECT *
FROM CHAMBRES
WHERE confort='BAIN' AND equipement='TV'
NUM_CHAMBRE PRIX NBR_LITS NBR_PERS CONFOR EQU
----------- ---------- ---------- ---------- ------ ---
14 140 2 2 BAIN TV
24 140 2 2 BAIN TV
34 140 2 2 BAIN TV
44 140 2 2 BAIN TV
15 180 3 4 BAIN TV
25 180 3 4 BAIN TV
35 180 3 4 BAIN TV
45 180 3 4 BAIN TV
(Chambres [NumChambre,
NUM_CLIENT NUM_CHAMBRE DATE_ARR DATE_DEP
---------- ----------- --------- ---------
1000 11 11-JAN-90 15-JAN-90
1001 21 10-JAN-90
1002 34 20-DEC-89 27-DEC-89
1003 44 24-DEC-89 27-DEC-89
1005 45 23-DEC-89 28-DEC-89
1006 14 01-DEC-89 28-DEC-89
1007 23 01-DEC-89 02-DEC-89
1007 23 08-DEC-89 09-DEC-89
1007 23 15-DEC-89 16-DEC-89
1007 23 22-DEC-89 23-DEC-89
1007 23 29-DEC-89 30-DEC-89
Feprenons les exemples du chapItre prcdent:
1) Les chambres avec baIn et T7 :
2) Les numros des chambres et leur capacIt :
0e U|L SQL 151
NbrPers])
devIent en SQL
SELECT Num_chambre, nbr_pers
FROM CHAMBRES
NUM_CHAMBRE NBR_PERS
----------- ----------
10 2
20 2
30 2
40 2
11 2
21 2
31 2
41 2
12 2
22 2
32 2
42 2
13 2
23 2
33 2
43 2
14 2
24 2
34 2
44 2
15 4
25 4
35 4
45 4
(*((0ateArr = 251289)(0ate0ep 251289))(ClIents*FservatIon))[Nom]
devIent en SQL
SELECT Nom
FROM CLIENTS,RESERVATIONS
WHERE Date_Arr<=to_date('25-dec-89')
AND Date_Dep> to_date('25-dec-89')
AND Clients.num_client=Reservations.num_client
NOM
--------------------
DUFOUR
ZORO
DUMAS
ROMULUS
Dn remarque que la joInture naturelle de l'expressIon est explIcIte dans la
requte SQL.
((ClIents * FservatIon) * Chambres)[Nom, Confort]
devIent en SQL
J) Les noms des clIents ayant rservs une chambre pour le 251289 :
4) Le nom des clIents et le confort des chambres qu'Ils ont rserves:
SELECT Nom, Confort
FROM CHAMBRES, CLIENTS, RESERVATIONS
WHERE Clients.num_client=Reservations.num_client
AND Chambres.num_chambre=Reservations.num_chambre
NOM CONFOR
-------------------- ------
GASCON WC
ROMULUS BAIN
DUPONT WC
NOBODY BAIN
NOBODY BAIN
NOBODY BAIN
NOBODY BAIN
NOBODY BAIN
DUFOUR BAIN
ZORO BAIN
DUMAS BAIN
SELECT sum(nbr_pers)
FROM CHAMBRES
SUM(NBR_PERS)
-------------
56
Syntaxe des requtes SQL
Nous avons examIn la traductIon des expressIons algbrIques en SQL. Nous
allons examIner maIntenant systmatIquement toutes les regles de
l'expressIon de slectIon SQL.
Cette premIere regle est un peu comme une table des matIeres du SELECT
en SQL, nous y trouvons les partIes suIvantes:
dIspIayed coIumn : permet de spcIfIer la nature du rsultat (la
projectIon et les expressIons calcules)
seIected-tabIe : permet de spcIfIer les relatIons ImplIques dans la
requte (le produIt cartsIen)
CondItIon : permet de spcIfIer la condItIon de slectIon
Connect-CIause : permet de spcIfIer un parcours et une condItIon
arborescents
Croup-CIause : permet de spcIfIer les regroupements, pour le calculs
des fonctIons agrgatIves
Set-CIause: permet de spcIfIer les opratIons ensemblIstes
Drder-CIause : permet de spcIfIer les crIteres de trI sur le rsultat
Update-CIause: permet de spcIfIer les crIteres de verrouIllage pour la
concurrence
SELECTcommand
5) La capacIt thorIque d'accueIl de l'hotel :
Cette questIon, nonformulable avec les expressIons algbrIques trouve la
spcIfIcatIon suIvante:
0e U|L SQL 15J

Une des dIffrences entre la relatIon et la table (l'ImplantatIon InformatIque
de la relatIon) est que dans une relatIon une entIt ne peut tre prsente
qu'une foIs (par dfInItIon) alors que dans la table une range peut
apparatre plusIeurs foIs. Dn parle alors de doublons. Pour lImIner ces
doublons du rsultat d'une requte, on doIt le spcIfIer avec le mot rserv
dIstInct. Cette lImInatIon demande une comparaIson deux deux des
ranges du rsultat, on peut acclrer cette comparaIson en trIant les
ranges. Le cout de l'lImInatIon des doublons correspond donc celuI du trI
de la table du rsultat. 0ans l'exemple quI suIt, on veut tous les types de
chambres, c'est dIre les dIffrentes assocIatIons quI exIstent entre le
confort et les quIpements, en utIlIsant dIstInct, on lImIne les doublons.
SELECT confort, equipement
FROM CHAMBRES
CONFOR EQU
------ ---
WC NON
WC NON
WC NON
WC NON
WC NON
WC NON
WC NON
WC NON
DOUCHE NON
DOUCHE NON
DOUCHE NON
DOUCHE NON
BAIN NON
BAIN NON
BAIN NON
BAIN NON
BAIN TV
BAIN TV
BAIN TV
BAIN TV
BAIN TV
BAIN TV
BAIN TV
BAIN TV
SELECT distinct confort, equipement
FROM CHAMBRES
CONFOR EQU
------ ---
BAIN NON
BAIN TV
DOUCHE NON
WC NON
Le mot rserv aII spcIfIe que l'on dsIre toutes les ranges du rsultat, par
dfaut on obtIent toutes les entIts
En spcIfIant *, on obtIent toutes les colonnes de toutes les tables de la
clause FFD|
La projection
0ans cette clause, nous spcIfIons la nature des colonnes du rsultat. Ce
rsultat peut tre la totalIt des colonnes d'une table, un constItuant
partIculIer, le rsultat d'une expressIon arIthmtIque ou le rsultat d'une
fonctIon d'agrgatIon (regroupement)
dIsplayed column

Nous pouvons obtenIr toutes les colonnes d'une table en spcIfIant tabIe-
name.*. Lors de la cratIon d'une table, le SC80 mmorIse avec la table,
l'IdentIfIcatIon du proprItaIre de la table. Nous verrons ultrIeurement
comment ces InformatIons sont utIlIses dans les mcanIsmes de scurIt. En
prfIxant une table de l'IdentIfIcateur du proprItaIre, on IndIque au SC80
que l'on dsIre la table cre par ce proprItaIre. l est aInsI possIble que
plusIeurs utIlIsateurs possedent des tables ayant des noms IdentIques. 0ans
notre exemple, le proprItaIre est assocI au nom du projet HDTEL. Les
troIs requtes suIvantes sont donc quIvalentes
SELECT * FROM CHAMBRES
SELECT CHAMBRES.* FROM CHAMBRES
SELECT HOTEL.CHAMBRES.* FROM CHAMBRES
SELECT num_chambre "Numro de Chambre", prix/nbr_pers "prix
par pers"
FROM Chambres
WHERE equipement='TV'
Numro de Chambre prix par pers
L'alias permet de donner un tItre une colonne, dans le cas des
expressIons ou sImplement de renommer une colonne.
Exemple:
Le prIx par personne des chambres ayant une T7 :
0e U|L SQL 155
----------------- -------------
14 70
24 70
34 70
44 70
15 45
25 45
35 45
45 45
Lxpression
ExpressIon

Une expressIon est un terme ou une suIte de termes connects par les
oprateurs arIthmtIques + ou .
Un terme est un facteur ou une suIte de facteurs connects par les
oprateurs arIthmtIques * ou /.
Terme

Un facteur appartIent aux catgorIes suIvantes:
la constante non sIgne quI est un nombre (12.43, 324, 1.56E-23)
ou une chane de caracteres ('bain'). Les chanes de caracteres
peuvent tre concatnes avec l'oprateur || ('bain'||' et
WC')
la varIable quI est un nom de colonne. Eventuellement prfIxe par le
nom de la table, dans le cas ou ce nom appartIent plusIeurs tables
manIpules dans une mme requte (numchambre,
Chambres.numchambre).
une fonctIon avec ses parametres d'appel: power(taux_annuel,
nombre_annees). Les fonctIons dIsponIbles dpendent du SC80
utIlIs. Nous donnons en annexe un apperu de l'tendue de cellescI.
une fonctIon de regroupement avec ses parametres d'appel:
count(*), avg(prix/nbpers). Nous donnons une explIcatIon
dtaIlle dans la clause de regroupement.
une expressIon entre parentheses afIn d' oter les ambIguts:
(a+b)*(c+d)
Factor

La syntaxe permet de construIre des expressIons sans lImItatIon de
complexIt: (-a*sum(power(a,b)+c)*d)). Plus loIn, dans la syntaxe, nous
utIlIsons nouveau la notIon d'expressIon. Nous faIsons rfrence alors
expressIon telle que nous venons de la dfInIr.
Les relations du produit cartesien
Les relatIons nommes dans la clause FROM sont celles quI seront ImplIques
dans le calcul de la requte. Les noms des colonnes apparaIssant dans les
expressIons doIvent appartenIr ces tables.
selectedtable

La table est sImplement nomme, elle est ventuellement prfIxe par le
nom de son proprItaIre. L'alIas permet de renommer une table afIn de luI
donner un nom plus court ou bIen un autre nom dans le cas ou une table est
utIlIse plusIeurs foIs dans une mme requte. CecI permet l'autojoInture,
par exemple les chambres ayant le mme confort et le mme quIpement
qu'une autre chambre maIs ayant un prIx InfrIeur de 10 cellecI
SELECT distinct c1.num_chambre
FROM CHAMBRES c1, CHAMBRES c2
WHERE c1.confort=c2.confort
AND c1.equipement=c2.equipement
AND c1.prix*1.1<c2.prix
NUM_CHAMBRE
-----------
10
14
20
24
30
34
40
44
0e U|L SQL 157
SELECT num_chambre, prix, confort
FROM CHAMBRES
WHERE (prix<=80)
OR ((confort='BAIN') AND (prix<=120))
NUM_CHAMBRE PRIX CONFOR
----------- ---------- ------
10 80 WC
20 80 WC
30 80 WC
40 80 WC
13 120 BAIN
23 120 BAIN
33 120 BAIN
43 120 BAIN
Un facteur logIque appartIent aux catgorIes suIvantes:
une comparaIson entre deux expressIons (=,>,<, ...)
un test d'appartenance un ensemble (in)
un test d'appartenance une chane de caracteres (like)
un test d'appartenance un Intervalle (between).
une comparaIson avec la valeur null
un prdIcat quantIfI (exists, all, any)
une condItIon entre parentheses afIn d'oter les ambIguts.
logIcalfactor
0ans ce cas, le SC80 agIt comme s'Il exIstaIt deux Instances IdentIques de
CHA|8FE.
Condition
La clause WHERE est assocIe une condItIon quI exprIme un prdIcat sur les
ranges du produIt cartsIen. Chaque lment de cette condItIon est valu
vraI ou faux. Un terme peut tre nI par par le mot cl not. Les termes
peuvent tre connects par le ou logIque InclusIf l'aIde du mot cl OR.
CondItIon
Un terme logIque est un facteur ou des facteurs connects par le et logIque
l'aIde du mot cl AND. Les oprateurs logIques sont IdentIques ceux
dcrIts dans le chapItre des rappels sur la logIque.
exemple:
Les chambres coutants au max. 80 francs ou ayant un baIn et valant au max.
120

Comparaison entre deux expressions
Les oprateurs de comparaIson sont:
exp1 = exp2 ; l'galIt du rsultat exp1 et exp2
exp1 < exp2 ;exp1 est strIctement InfrIeur exp2
exp1 <= exp2 ;exp1 est InfrIeur ou gal exp2
exp1 > exp2 ;exp1 est strIctement suprIeur exp2
exp1 >= exp2 ;exp1 est suprIeur ou gal exp2
exp1 <> exp2 ;exp1 est dIffrent de exp2 (aussI not != ou ^=)
Les expressIons sont du type de celles vues prcdemment, l'exclusIon des
fonctIons d'agrgatIon (quI font l'objet d'une clause spcIale having). Le
rsultat d'une expressIon est un nombre, une chane de caracteres ou une
date. La relatIon d'ordre utIlIse est dfInIe en fonctIon du rsultat. 0ans le
cas ou les rsultats appartIennent des types dIffrents, Il faut utIlIser les
fonctIons de conversIon de type.
SI une des deux expressIons est value la valeur null, alors le rsultat de
la comparaIson est toujours faux. (null=null est aussI valu faux). Pour
l'galIt, nous avons le tableau suIvant:
exp1/exp2 =null null
=null vrai ou Iaux Iaux
null Iaux Iaux
Appartenance un ensemble
l exIste deux possIbIlIts pour dfInIr l'ensemble avec lequel on doIt tester
l'appartenance d'un lment. L'une consIste nummer explIcItement les
lments de l'ensemble; on constItue aInsI une lIste de ces lments. L'autre
consIste dfInIr les lments par une sousrequte. SI l'ensemble est
{c
1
,c
2
,c
3
, ... c
n
} alors les condItIons suIvantes sont quIvalentes:
Exp1 in (c
1
,c
2
,c
3
, ... c
n
)
(Exp1 = c
1
) AND (Exp1 = c
2
) AND ...(Exp1 = c
n
)
0e U|L SQL 159
SELECT num_chambre FROM CHAMBRES
WHERE confort in ('BAIN','DOUCHE')
NUM_CHAMBRE
-----------
12
22
32
42
13
23
33
43
14
24
34
44
15
25
35
45
SELECT sum(prix)
FROM CHAMBRES Ch
WHERE num_chambre in
SELECT num_chambre
FROM Reservations R
WHERE date_arr<='25-dec-89'
AND date_dep>'25-dec-89'
SUM(PRIX)
----------
600
Appartenance une chane de caractres
Dn test IcI sI une chane de caracteres ressemble un pctron. CecI est
partIculIerement utIle sI l'on doIt effectuer des recherches sur un constItuant
dont le domaIne de modlIsatIon est du type texte. En effet, Il permet
d'effectuer une slectIon l'IntrIeur mme des chanes. 0eux patrons sont
dIsponIbles. Le quI est substItuable n'Importe quelle chane de caracteres
y comprIs la chane vIde. Le _ (soulIgn) quI est substItuable un seul
caractere.
expset
Exemples:
Chambres avec un moyen de se laver
Fecette du 25dcembre1989
matchstrIng

Exemples:
Nom du clIent commenant par 0U
SELECT nom
FROM CLIENTS
WHERE Nom like 'DU%'
NOM
--------------------
DUPONT
DUFOUR
DUMAS
SELECT nom
FROM CLIENTS
WHERE Nom like '___O%'
NOM
--------------------
DUPONT
DUFOUR
ZORO
NOBODY
exp1 between exp2 AND exp3
(exp2 <= exp1) AND (exp1 <= exp3)
SELECT count(num_chambre)
FROM CHAMBRES
WHERE prix between 85 AND 120
COUNT(NUM_CHAMBRE)
------------------
12
Nom du clIent ayant un 0 pour quatrIeme lettre
Appartenance un intervalle
La clause between est une facIlIt d'crIture. Les deux condItIons suIvantes
sont quIvalentes:
Exemple:
nombre de chambres dont le prIx est entre 85 et 120 francs
0e U|L SQL 161
Comparaison avec la valeur null
La clause Is null permet de tester sI une expressIon est IndfInIe. Dn avaIt vu
prcdemment que l'oprateur d'galIt ramenaIt toujours la valeur fausse.
Le rsultat de l'valuatIon est donn dans le tableau suIvant:
exp1 exp1 is null
=null Iaux
null vrai
Les deux condItIons suIvantes sont quIvalentes:
not (exp1 is null)
exp1 is not null
SELECT Nom
FROM ClIENTS, RESERVATIONS
WHERE ClIENTS.num_client=RESERVATIONS.num_client
AND date_dep is null
NOM
--------------------
DUPONT
Predicat quantifie
La clause exists permet de tester s'Il exIste au moIns une range
correspondant au prdIcat de la sousrequte. Comme Il s'agIt de tester
unIquement l'exIstence de certaInes ranges, les valeurs des colonnes de ces
dernIeres sont sans Importance, on peut donc spcIfIer une constante comme
rsultat, soIt:
Exists (SELECT 'Vrai' FROM .... WHERE ...)
Exp1 all (SELECT col1 FROM ... WHERE ...)
(Exp1 c1) AND (Exp1 c2) AND ...(Exp1 cn)
Exp1 any (SELECT col1 FROM ... WHERE ...)
(Exp1 c1) OR (Exp1 c2) OR ...(Exp1 cn)
Exemple:
ClIents n'ayant pas fIx leur date de dpart
La clause all permet de tester sI toutes les ranges, correspondant au
prdIcat de la sousrequte, vrIfIent une certaIne condItIon. Par exemple,
sI la sousrequte (SELECT col1 FROM ... WHERE ...) donne pour
rsultat {c
1
,c
2
,c
3
, ... c
n
} alors les condItIons suIvantes sont
quIvalentes (ou est un oprateur de comparaIson, =,,, ...):
La clause any permet de tester sI au moIns une range, correspondant au
prdIcat de la sousrequte, vrIfIe une certaIne condItIon. Par exemple, sI
la sousrequte (SELECT col1 FROM ... WHERE ...) donne pour
rsultat {c
1
,c
2
,c
3
, ... c
n
} alors les condItIons suIvantes sont
quIvalentes (ou est un oprateur de comparaIson, =,,, ...):
Exp1 in (SELECT col1 FROM ... WHERE ...)
Exp1 = any (SELECT col1 FROM ... WHERE ...)
Exp1 all (SELECT col1 FROM ...
WHERE ...)
not Exists (SELECT 'Vrai' FROM ....
WHERE ... AND not(exp1 col1))
exemple: affIcher tous les numros de chambre et le numro du clIent ayant
rserv la chambre pour le 25dcembre1989.
SELECT Ch.num_chambre, num_client
FROM Chambres Ch,Reservations R
WHERE Ch.num_chambre=R.num_chambre
AND date_arr<='25-dec-89'
AND date_dep>'25-dec-89'
NUM_CHAMBRE NUM_CLIENT
----------- ----------
14 1006
34 1002
44 1003
45 1005
SELECT Ch.num_chambre, num_client
FROM Chambres Ch,Reservations R
WHERE Ch.num_chambre=R.num_chambre(+)
AND date_arr(+)<='25-dec-89'
AND date_dep(+)>'25-dec-89'
NUM_CHAMBRE NUM_CLIENT
La clause In et any sont quIvalentes pour l'oprateur de comparaIson =.
Nous avons l'quIvalence suIvante:
Fappelons qu'Il est possIble de passer du quantIfIcateur unIversel
l'exIstentIel par une double ngatIon:
x, (P(x)) x, (P(x))
Cette quIvalence est aussI applIcable aux condItIons de SQL. SoIt:
quantIfIedfactor
Jointure externe
En postfIxant les colonnes d'une table par (+), on spcIfIe une joInture
externe avec cette table. SI aucune range de la table ne satIsfaIt les
condItIons de slectIon, alors le SC80 met des valeurs null pour les colonnes
de cette table.
0e U|L SQL 16J
----------- ----------
10
11
12
13
14 1006
15
20
21
22
23
24
25
30
31
32
33
34 1002
35
40
41
42
43
44 1003
45 1005
S'Il n'exIste pas de rservatIon pour une chambre, elle sera compose avec
une entIt fIctIve de FservatIon n'ayant que des valeurs nulles.
Sous-requtes
Une sousrequte permet de dfInIr un ensemble d'entIts. Elle permet
d'exprImer une condItIon ou une expressIon par rapport au contenu des
tables. Elle sera aussI utIlIse plus loIn pour Insrer des ranges dans une
table, pour InItIalIser une table (Insert, CREATE) et pour dfInIr l'tendue
d'une modIfIcatIon (Update, Delete)
Subquery

exemple: prIx moyen des chambres ayant le mme confort que celle du
clIent No 1006 :
SELECT avg(prix) FROM Chambres
WHERE Confort =
(SELECT Confort FROM Chambres, Reservations
WHERE Chambres.num_chambre
=Reservations.num_chambre
AND num_client=1006)
AVG(PRIX)
----------
146.666667

FIgure 102 :|odele , modele avec les sousrequtes de la machIne SQL
La sousrequte est ImbrIque dans une autre requte. 0ans une sous
requte, on peut faIre rfrence des varIables dfInIes un nIveau
suprIeur. l faut alors les consIdrer comme des parametres quI sont
modIfIs pour chaque range du produIt cartsIen du nIveau suprIeur.
exemple: chambre ayant un prIx 10 InfrIeur la moyenne pour une mme
catgorIe de confort
SELECT Num_chambre,confort FROM Chambres a
WHERE prix < (SELECT avg(prix)*0.90 FROM Chambres b
WHERE b.confort=a.confort)
NUM_CHAMBRE CONFOR
----------- ------
13 BAIN
23 BAIN
33 BAIN
43 BAIN
La sousrequte calcule le prIx moyen d'une chambre ayant le confort fIx
par la valeur a.confort prIse par la range de la requte du nIveau
suprIeur.
R1 R2 ... Rn
Where .... prdicat
entit
relation
n-uplet
T1 T2 ... Tm
Where .... prdicat
n-uplet
entit
relation
0e U|L SQL 165
Nous devons donc modIfIer notre modele de machIne SQL pour tenIr compte
des sousrequtes. CellescI s'Inserent dans le module de la clause WHEFE.
Elles y IntroduIsent la rcursIvIt car chaque clause WHEFE peut contenIr des
sousrequtes (FIgure 102)
Regroupements
Cette clause permet de spcIfIer le regroupement d'un certaIn nombre
d'entIts selon un crItere de partIonnement afIn d'valuer une fonctIon
agrgatIve. Le rsultat ne donne donc qu'une seule entIt pour chaque
regroupement. Les prIncIpales fonctIons d'agrgatIon sont:
avg : calculer la moyenne d'une lIste
count : dnombrer les lments d'une lIste
min : dtermIner l'lment mInImum d'une lIste
max : dtermIner l'lment maxImum d'une lIste
sum : calculer la somme d'une lIste
Les parametres de la fonctIon sont une expressIon quI peut tre prfIxe par
les mots cl all et distinct. Par dfaut all est utIlIs; dans ce cas
toutes les valeurs de la lIste sont prIses en consIdratIon. Avec distinct,
seules les valeurs dIffrentes sont consIdres. Les valeurs null, ne sont pas
slectIonnes. Cependant Count(*) permet de dnombrer une lIste en
tenant compte de ces dernIeres.
L'expressIon de la clause GROUP BY dtermIne le partIonnement. CeluIcI
est effectu sur les ranges quI sont slectIonnes par la clause WHERE. Les
ranges lImInes par la condItIon de slectIon ne partIcIpent donc pas
l'agrgatIon. L'expressIon de regroupement doIt tre quIvalente toutes les
expressIons comportant des varIables apparaIssant dans le rsultat.
Le processus de regroupement Intervenant apres la slectIon des ranges, Il
est possIble d'exprImer une condItIon de slectIon sur les valeurs agrges
dans la condItIon de la clause having. La clause having permet de
spcIfIer le crItere sur les entIts regroupes La clause WHERE permet de
spcIfIer le crItere sur les entIts Intervenant dans le regroupement
CroupClause

exemples:
PrIx moyen des chambres par type de confort:
SELECT Confort,AVG(Prix) "prix moyen"
FROM Chambres
GROUP BY Confort
CONFOR prix moyen
------ ----------
BAIN 146.666667
DOUCHE 100
WC 85
PrIx mInImum et maxImum des chambres par type de confort:
SELECT Confort,Min(Prix),Max(Prix)
FROM Chambres
GROUP BY Confort
CONFOR MIN(PRIX) MAX(PRIX)
------ ---------- ----------
BAIN 120 180
DOUCHE 100 100
WC 80 90

FIgure 10J :|odele , modele avec les regroupements de la machIne SQL
PrIx mInImum et maxImum des chambres par type de confort, maIs dont le
prIx |In est plus petIt que 100:
SELECT Confort,Min(Prix),Max(Prix)
FROM Chambres
GROUP BY Confort Having Min(Prix)<100
CONFOR MIN(PRIX) MAX(PRIX)
------ ---------- ----------
WC 80 90
R1 R2 ... Rn
Where .... prdicat
relation
n-uplet
Group by .... regroupement
et calcul
Having ... prdicat
0e U|L SQL 167
Nous devons donc modIfIer notre modele de machIne SQL pour tenIr compte
des regroupements. CeuxcI se placent apres le test du prdIcat: un premIer
module permet les regroupements et le calcul des fonctIons agrgatIves
ensuIte on effectue une slectIon sur les valeurs prIses par les fonctIons
agrgatIves.
Lnsembles
Cette clause permet d'effectuer des requtes en utIlIsant les oprateurs
ensemblIstes: union
10
, intersect, minus (0Iffrence) ont le sens
habItuel. Les oprandes, le rsultat de slectIon, de ces oprateurs doIvent
avoIr la mme arIt (nombre de constItuants) et les constItuants doIvent tre
gaux en type, pas forcment en taIlle. L'utIlIsatIon de ces oprateurs
ImplIque ImplIcItement la clause 0STNCT, donc l'lImInatIon des doublons.
SI les colonnes des dIffrentes slectIons sont IdentIques alors Il est possIble
d'effectuer une seule slectIon en utIlIsant les oprateurs logIques.
SetClause

Exemple:
Les termes employs pour une chambre
SELECT confort "Termes"
FROM CHAMBRES
union
SELECT equipement
FROM CHAMBRES
Termes
------
BAIN
DOUCHE
NON
TV
WC
Cette clause permet de parcourIr une relatIon en fIxant un ordre
hIrarchIque. La clause prior doIt tre utIlIse pour fIxer la relatIon

10
UNDN ALL permet de faIre l'unIon par concatnatIon des rsultats.
Arborescences
ConnectClause
parentenfant pour le parcours de l'arbre (la profondeur maxImum de l'arbre
est lImIte 256). Le cot gauche dfInIt le parent et le cot droIte l'enfant
sI la clause prIor prcede l'expressIon, et l'Inverse sI elle la succede. La
clause start with dfInIt la racIne de l'arbre (ou les racInes)
exemple: SoIt la relatIon
Emp(Nom,Num_Emp,Num_|anager,SalaIre):
E|P(a,b,c,d) La personne, portant le numro b et se nommant a a
un manager portant le numro c et peroIt le salaIre d
avec l'Instance suIvante:
NOM NUM_EMP NUM_MANAGER SALAIRE
------------ ---------- ----------- ----------
DOMINIQUE 1 10000
MARIE 2 1 6000
JEAN 3 1 5000
PAUL 4 2 5000
MARTINE 5 2 5000
VINCENT 6 4 5500
HENRI 7 4 4000
MADELEINE 8 3 4000
ANNE 9 3 3000
EtablIr une lIste des noms de personne par ordre hIrarchIque.
SELECT lpad('-',3*level)||Nom "Hirarchie"
FROM EMP
Connect by prior Num_Emp=Num_Manager
Start with Num_Manager is NULL
Hirarchie
---------------------------
-DOMINIQUE
-MARIE
-PAUL
-VINCENT
-HENRI
-MARTINE
-JEAN
-MADELEINE
-ANNE
SELECT Nom
FROM EMP E1
WHERE exists (SELECT * FROM EMP E2
WHERE E1.num_emp=E2.num_manager)
NOM
------------
DOMINIQUE
MARIE
La fonctIon level IndIque le nIveau d'un noeud dans l'arborescence. La
fonctIon lpad permet d'Insrer des blancs gauche (cadrer droIte)
autres exemples avec les fonctIons prdIcatIves:
QuI est responsable d'employs :
0e U|L SQL 169
JEAN
PAUL
SELECT Nom
FROM EMP E1
WHERE E1.salaire< any (SELECT salaire FROM EMP E2
NOM
------------
PAUL
SELECT Nom FROM EMP E1
WHERE exists (SELECT * FROM EMP E2
AND E1.salaire> all (SELECT salaire FROM EMP E2
NOM
------------
DOMINIQUE
MARIE
JEAN
exemple:
SELECT nom, adresse
FROM Clients
ORDER BY nom asc
NOM ADRESSE
-------------------- ----------------------------------------
AGDA 10 route de l impossible 1508 TEXAS
QuI est chef d'un employ mIeux pay que luImme:
QuI est Chef absolu, aucun employ mIeux pay que luImme :
1rier
Cette clause permet de trIer une relatIon afIn de l'affIcher dans un ordre
donn. Seule la reprsentatIon externe est affecte par ce trI. Le trI est
spcIfI par une lIste, dont les lments les plus gauche sont les plus
sIgnIfIcatIfs dans le trI. Pour chaque lment, le trI peut tre croIssant (asc)
ou dcroIssant (desc). Par dfaut, Il est croIssant. Un lment est une
expressIon de la clause SELECT. l peut aussI tre un nombre IndIquant le
numro de la colonne trIer. Ce type de spcIfIcatIon du crItere de trI est
oblIgatoIre dans le cas ou le rsultat est obtenu par utIlIsatIon d'un oprateur
ensemblIste (en effet les colonnes provIennent de requtes dIffrentes)
DrderClause
Sorteddef
CHADOK 25 rue de la rame 1456 Tombouctou
DUFOUR 10 av. de la gar 1300 AILLEURS
DUMAS 10 route du moulins LE-SUD
DUPONT 12 ch. des hirondelles 1238 LABAS
EINSTEIN 10 route de la relativit 1004 PLUS-LOIN
GASCON 12 av. du Gnral 1239 ICI
NOBODY 403 route de l inconnu 75000 Paris
ROMULUS 241 route de rome 1409 Lion
ZORO 10 ch des voleurs Los Angeles
Modle de la machine SQL
FInalement, nous obtenons le modele de la FIgure 104pour la machIne SQL.
Les relatIons d'une opratIon ensemblIste sont calcules Indpendament. Le
trI est effectu en dernIer sur le rsultat fInal.

FIgure 104 :modele complet de la machIne SQL
Ce modele n'a d'utIlIt que de dtermIner le rsultat d'une requte SQL. Lors
de l'excutIon relle d'une requte, le SC80 va optImIser la requte afIn
d'vIter de travaIller sur les nuplets du produIt cartsIen. Cette optImIsatIon
(traIte plus loIn) utIlIse d'une part les proprIts de l'algebre relatIonnelle
et d'autre part les structures de donnes accompagnant les tables
mmorIses.
R1 R2 ... Rn
Where .... prdicat
relation
n-uplet
Group by .... regroupement
et calcul
Having ... prdicat
...
Union, intersect, minus ....
Oprations ensemblistes
Order by .....
Tri du rsultat
0e U|L SQL 171
Lxpression graphique d'une requte
Les SC80 sont pratIquement tous munIs d'une Interface graphIque pour
l'InterrogatIon des donnes. Pour l'utIlIsateur occasIonnel, cette solutIon est
tres effIcace car IntuItIvement, Il peut spcIfIer une requte sans se
proccuper de la syntaxe SQL. Cependant pour des requtes complexes,
cette approche graphIque peut devenIr plus complexe que la spcIfIcatIon
textuelle de la requte.

0ans la FIgure 105, nous montrons une requte graphIque effectue avec
Access de |Icrosoft. Nous voulons une lIste des vhIcules dIesel avec la
catgorIe de permIs. Conceptuellement, Il faut procder de la mme
manIere, c'estdIre, dtermIner les relatIons du contexte de la requte.
0ans notre cas Il s'agIt de \hcule et de Type, apres les avoIr slectIonnes
dans une lIste, le systeme les prsente sur la surface de travaIl. En utIlIsant
les InformatIons sur les attrIbuts et les cardInalIts, le systeme propose de
composer, les deux relatIons par l'attrIbut modle.
En clIquant sur les champs NochassIs, typeCarburant et categorIe, nous les
faIsons apparatre dans le tableau InfrIeur. 0ans ce mme table, nous allons
prcIser les crIteres de slectIon, de projectIon, de trI et ventuellement de
slectIon

A tout moment, Il est possIble d'obtenIr d'autres vues de la requte.
Celle de l'excutIon (FIgure 106) et celle de sa traductIon en SQL (FIgure
107).


Lxercices
Questions sur 11
3
Nous avons les Instances suIvantes des relatIons:
SELECT * FROM Vehicule
NOCHASSIS NOPLAQUE MISEENSER MODELE NOSTATION
---------- ---------- --------- ------------ ----------
100001 121 11-DEC-91 TAXI1 1
100002 122 24-JAN-92 TAXI2 1
100003 123 14-DEC-91 TAXI1 2
100005 125 20-DEC-91 TAXI2 2
100004 124 13-OCT-91 BUS 2
SELECT * FROM Type
MODELE NBPLACES CA TYPECARBURAN A POIDS
------------ ---------- -- ------------ - ----------
TAXI1 5 V ESSENCE N 850
TAXI2 7 V DIESEL Y 1200
BUS 35 PL DIESEL N 6500
SELECT * FROM Carburant
NOPLAQUE NOJOUR KILOMETRAGE LITRES TYPECARBURAN
---------- ---------- ----------- ---------- ------------
121 1 300 30 ESSENCE
122 1 300 20 DIESEL
123 1 300 30 ESSENCE
124 1 300 60 DIESEL
125 1 300 20 DIESEL
121 2 310 30 ESSENCE
122 2 320 20 DIESEL
123 2 300 31 ESSENCE
124 2 300 62 DIESEL
125 2 300 21 DIESEL
121 3 310 31 ESSENCE
0e U|L SQL 17J
122 3 320 21 DIESEL
123 3 300 32 ESSENCE
124 3 300 58 DIESEL
125 3 300 22 DIESEL
125 4 10 1 ESSENCE
SELECT * FROM Entretien
NOCHASSIS NOJOUR DESCRIPTION
---------- ---------- ------------------
100001 1 VIDANGE
100001 1 BOITE A VITESSE
100002 2 VIDANGE
100003 3 VIDANGE
100004 1 VIDANGE
SELECT * FROM Chauffeur
NOCHAUFFEUR NOM PRENOM ADRESSE NOSTATION
----------- ---------- ----------- --------- ----------
1 DUPONT JEAN ici 1
2 MAX MAXIM ici1 1
3 BOL PAUL labas 2
4 PASBOL PAUL labas2 2
SELECT * FROM Permis
NOCHAUFFEUR CA
----------- --
1 V
2 V
3 V
4 V
1 PL
3 PL
SELECT * FROM Planning
NOCHAUFFEUR NOCHASSIS NOJOUR T
----------- ---------- ---------- -
1 100001 1 A
2 100002 1 A
3 100003 2 A
4 100005 1 A
1 100001 1 B
4 100003 2 A
1 100004 3 A
SELECT * FROM Station
NOZONE NOSTATION
---------- ----------
10 1
12 2
SELECT * FROM Distance
HEURE ZONEDE ZONEA TEMPSPARCOURS
---------- ---------- ---------- -------------
10 10 20 5
11 10 20 6
12 10 20 10
13 10 20 5
10 20 10 5
11 20 10 6
12 20 10 10
13 20 10 5
10 10 10 0
11 10 10 0
12 10 10 0
13 10 10 0
10 20 20 0
11 20 20 0
12 20 20 0
13 20 20 0
13 20 20 0
SELECT * FROM Situation
NOCHASSIS NOZONE
---------- ----------
1000001 10
1000002 20
1000003 20
1000005 20
0onnez une requte SQL pour chaque poInt cIdessous, utIlIsez le graphe de
relatIon pour effectuer les joIntures:
0e U|L SQL 175
SELECT *
FROM VEHICULE
ORDER BY nochassis
NOCHASSIS NOPLAQUE MISEENSER MODELE NOSTATION
---------- ---------- --------- ------------ ----------
100001 121 11-DEC-91 TAXI1 1
100002 122 24-JAN-92 TAXI2 1
100003 123 14-DEC-91 TAXI1 2
100004 124 13-OCT-91 BUS 2
100005 125 20-DEC-91 TAXI2 2
1) lIste des vhIcules par numro de chassIs croIssant
2) lIste des vhIcules et leur catgorIe de permIs
J) lIste des vhIcules de plus de 20 places
4) lIste des vhIcules ayant entre 5 et 8 places
5) lIste du poIds total des vhIcules (poIds du vhIcule + 65 kg par personne)
6) lIste alphabtIque des chauffeurs et de leur permIs
7) lIste des prnoms partags par plusIeurs chauffeurs en utIlIsant count()
8) lIste des prnoms partags par plusIeurs chauffeurs en utIlIsant EXSTS
9) lIste des vhIcules ayant un numro de plaque commenant par un 1 et un
J en troIsIeme posItIon
10) lIste des vhIcules ayant un entretIen dont le lIbell comporte
successIvement les mots 8DTE et 7TESSE
11) lIste des vhIcules que peut conduIre le chauffeur No 4 (avec le N)
12) lIste des vhIcules que peut conduIre le chauffeur No 4 (avec des
joIntures seulement)
1J) dtermIner sI un vhIcule a t remplI avec un carburant ne
correspondant pas son modele
14) consommatIon totale de chaque vhIcule, trIe par type de carburant
15) consommatIon totale par jour, par statIon, par type de carburant
16) consommatIon moyenne de chaque vehIcule pour 100 km
17) consommatIon moyenne journalIere de chaque vhIcule pour 100 km
18) lIste des pleIns anormaux (20 de plus que la consommatIon moyenne du
vhIcule)
19) le plannIng du chauffeur No 1 trI par jour et tranche horaIre
20) pour un clIent appelant depuIs la zone 10 1J heure, donnez la lIste des
vhIcules Inoccups par ordre de proxImIt.
Reponses sur 11
3
1) lIste des vhIcules par numro de chassIs croIssant
2) lIste des vhIcules et leur catgorIe de permIs
SELECT nochassis,v.modele
FROM VEHICULE v, TYPE t
WHERE v.modele=t.modele
NOCHASSIS MODELE
---------- ------------
100004 BUS
100001 TAXI1
100003 TAXI1
100002 TAXI2
100005 TAXI2
SELECT nochassis,nbplaces
AND nbplaces>20
NOCHASSIS NBPLACES
---------- ----------
100004 35
AND nbplaces between 5 AND 8
NOCHASSIS NBPLACES
---------- ----------
100001 5
100003 5
100002 7
100005 7
SELECT nochassis,poids+65*nbplaces "Poids total"
NOCHASSIS Poids total
---------- -----------
100004 8775
100001 1175
100003 1175
100002 1655
100005 1655
SELECT ch.nochauffeur,nom,prenom,categorie
FROM CHAUFFEUR ch, Permis pe
WHERE ch.nochauffeur=pe.nochauffeur
ORDER BY nom,prenom
J) lIste des vhIcules de plus de 20 places
4) lIste des vhIcules ayant entre 5 et 8 places
5) lIste du poIds des vhIcules (65 kg par personne)
6) lIste alphabtIque des chauffeurs et de leur permIs
0e U|L SQL 177
NOCHAUFFEUR NOM PRENOM CA
----------- -------------- ----------------- --
3 BOL PAUL V
3 BOL PAUL PL
1 DUPONT JEAN V
1 DUPONT JEAN PL
2 MAX MAXIM V
4 PASBOL PAUL V
SELECT distinct prenom
FROM CHAUFFEUR
GROUP BY prenom having count(prenom)>=2
PRENOM
------------------------
PAUL
SELECT distinct prenom
FROM CHAUFFEUR ch1
WHERE exists(SELECT 'vrai'
FROM CHAUFFEUR ch2
WHERE ch1.nochauffeur<>ch2.nochauffeur
AND ch1.prenom=ch2.prenom)
PRENOM
------------------------
PAUL
SELECT nochassis,noplaque
FROM VEHICULE
WHERE noplaque like '1_3%'
NOCHASSIS NOPLAQUE
---------- ----------
100003 123
SELECT nochassis,description
FROM ENTRETIEN
WHERE description like '%BOITE%VITESSE%'
NOCHASSIS DESCRIPTION
---------- ---------------
100001 BOITE A VITESSE
7) lIste des prnoms partags par plusIeurs chauffeurs en utIlIsant count()
8) lIste des prnoms partags par plusIeurs chauffeurs en utIlIsant EXSTS
9) lIste des vhIcules ayant un numro de plaque commenant par un 1 et un
J en troIsIeme posItIon
10) lIste des vhIcules ayant un entretIen dont le lIbell comporte
successIvement les mots 8DTE et 7TESSE
11) lIste des vhIcules que peut conduIre le chauffeur No 4 (avec le N)
AND categorie in (SELECT pe.categorie
FROM CHAUFFEUR ch, Permis pe
WHERE ch.nochauffeur=pe.nochauffeur
AND ch.nochauffeur=4)
NOCHASSIS MODELE
---------- ------------
100001 TAXI1
100005 TAXI2
100002 TAXI2
100003 TAXI1
FROM VEHICULE v, TYPE t,CHAUFFEUR ch, Permis pe
AND ch.nochauffeur=pe.nochauffeur
AND pe.categorie=t.categorie
AND ch.nochauffeur=4
NOCHASSIS MODELE
---------- ------------
100001 TAXI1
100003 TAXI1
100002 TAXI2
100005 TAXI2
AND typecarburant <> any (SELECT typecarburant
FROM carburant tc
WHERE v.noplaque=tc.noplaque)

NOCHASSIS MODELE
---------- ------------
100005 TAXI2
SELECT typecarburant,noplaque,sum(litres)
FROM CARBURANT
GROUP BY typecarburant,noplaque
ORDER BY typecarburant
TYPECARBURAN NOPLAQUE SUM(LITRES)
------------ ---------- -----------
DIESEL 122 61
DIESEL 124 180
DIESEL 125 63
12) lIste des vhIcules que peut conduIre le chauffeur No 4 (avec des
joIntures seulement)
1J) dtermIner sI un vhIcule a t remplI avec un carburant ne
correspondant pas son modele
14) consommatIon totale de chaque vhIcule, trIe par type de carburant
0e U|L SQL 179
ESSENCE 121 91
ESSENCE 123 93
ESSENCE 125 1
SELECT nojour, nostation ,typecarburant ,sum(litres)
FROM CARBURANT c, VEHICULE v
WHERE c.noplaque=v.noplaque
GROUP BY nojour, nostation ,typecarburant
NOJOUR NOSTATION TYPECARBURAN SUM(LITRES)
---------- ---------- ------------ -----------
1 1 DIESEL 20
1 1 ESSENCE 30
1 2 DIESEL 80
1 2 ESSENCE 30
2 1 DIESEL 20
2 1 ESSENCE 30
2 2 DIESEL 83
2 2 ESSENCE 31
3 1 DIESEL 21
3 1 ESSENCE 31
3 2 DIESEL 80
3 2 ESSENCE 32
4 2 ESSENCE 1
SELECT noplaque ,
(sum(litres)/sum(kilometrage))*100 "consommation moyenne
globale"
FROM CARBURANT c
GROUP BY noplaque
NOPLAQUE consommation moyenne globale
---------- ----------------------------
121 9.89130435
122 6.4893617
123 10.3333333
124 20
125 7.03296703
17) consommatIon moyenne journalIere de chaque vhIcule pour 100 km
SELECT noplaque,nojour ,
(sum(litres)/sum(kilometrage))*100 "moyenne journaliere"
FROM CARBURANT c
GROUP BY noplaque,nojour
NOPLAQUE NOJOUR moyenne journaliere
---------- ---------- -------------------
121 1 10
121 2 9.67741935
121 3 10
122 1 6.66666667
122 2 6.25
122 3 6.5625
123 1 10
15) consommatIon totale par jour, par statIon, par type de carburant
16) consommatIon moyenne de chaque vehIcule pour 100 km
123 2 10.3333333
123 3 10.6666667
124 1 20
124 2 20.6666667
124 3 19.3333333
125 1 6.66666667
125 2 7
125 3 7.33333333
125 4 10
SELECT noplaque,nojour,litres*100/kilometrage
FROM CARBURANT c1
WHERE litres*100/kilometrage
> (SELECT
1.2*(sum(litres)*100/sum(kilometrage))
FROM CARBURANT c2
WHERE c2.noplaque=c1.noplaque)
NOPLAQUE NOJOUR LITRES*100/KILOMETRAGE
---------- ---------- ----------------------
125 4 10
SELECT nochauffeur,nojour,tranchehoraire,nochassis
FROM PLANNING c1
WHERE nochauffeur=1
ORDER BY nojour,tranchehoraire
NOCHAUFFEUR NOJOUR T NOCHASSIS
----------- ---------- - ----------
1 1 A 100001
1 1 B 100001
1 3 A 100004
SELECT s.nochassis,s.nozone,tempsparcours
FROM SITUATION S,DISTANCE D
WHERE s.nozone=d.zonede
AND d.zonea=10
AND d.heure=13
ORDER BY tempsparcours
NOCHASSIS NOZONE TEMPSPARCOURS
---------- ---------- -------------
1000001 10 0
1000002 20 5
1000003 20 5
1000005 20 5
18) lIste des pleIns anormaux (20 de plus que la consommatIon moyenne du
vhIcule)
19) le plannIng du chauffeur No 1 trI par jour et tranche horaIre
20) pour un clIent appelant depuIs la zone 10 1J heure, donnez la lIste des
vhIcules Inoccups par ordre de proxImIt.
0e U|L SQL 181
JJ. Modification des donnees
"Un matin, au sortir d'un rve agit, Grgoire Samsa
s'veilla transform dans son lit en une vritable vermine"
(Franz Kafka - La mtamorphose)
Les champs d'applIcatIon quI ne se transforment pas au cours du temps sont
extrmement peu frquent (dans le domaIne de l'analyse statIstIque
d'enqute). La modIfIcatIon des objets du champ d'applIcatIon est ncessaIre
dans la majorIt des cas. Ces modIfIcatIons touchent l'Instance de la base de
donnes. En poursuIvant l'Ide que l'Instance de la base donnes est une
InterprtatIon du champ d'applIcatIon l'Instant t, pour obtenIr l'Instance de
la base l'Instant t', Il suffIt en thorIe de rInterprter le contenu du
champ ce moment l (FIgure 111). La modlIsatIon et sa concrtIsatIon,
fIxes lors de la conceptIon InItIale, sont consIdres comme des InvarIants
par rapport aux modIfIcatIons des objets du champs d'applIcatIon.

FIgure 111 : 7IsIon de la modIfIcatIon travers les prdIcats.
L'exploItatIon d'une base de donnes par une rInterprtatIon contInue du
champ d'applIcatIon n'est pas possIble. L'InItIalIsatIon de la premIere
Instance peut dj tre longue dans la dure. 0e plus, Il seraIt dIffIcIle de
fIxer l'Intervalle de temps entre deux rInterprtatIons. Cette vIsIon de la
modIfIcatIon travers les prdIcats ne doIt tre donc conserve que comme
iR1
...
iRn
Md
objets
du
C.A. modlisation
concrtisation
interprtation
iR1'
...
iRn'

C.A'.
iR1''
...
iRn''

C.A''.
transfor-
mation
transfor-
mation
conception
initiale
Exploitation
t t' t''
TEMPS
rfrence pour valIder d'autres mIses en oeuvre des modIfIcatIons.
Cependant, une telle vIsIon nous auraIt permIs de faIre l'conomIe de
l'analyse des transformatIons du champ d'applIcatIon.
Notre modele des modIfIcatIons demande l'IntroductIon d'un nouveau
concept, celuI d'vnement. L'occurence d'un vnement applIqu au champ
d'applIcatIon modIfIe ce dernIer. Par exemple, nous avons l'vnement: Un
clIent rserve une chambre et son occurence: le clIent No 1004 rserve la
chambre 24 du 1jan90 au 4jan90. L'occurence d'un vnement modIfIe
les objets du champ d'applIcatIon. En effet un vnement sans consquence
sur les donnes ne pourraIt pas laIsser de trace dans le champ d'applIcatIon.
La recherche des vnements se sItue au nIveau du champ d'applIcatIon, les
vnements sont donc sIgnIfIcatIfs pour les utIlIsateurs.

FIgure 112 : 7IsIon de la modIfIcatIon travers les vnements.
L'vnement est traduIt par une squence de prImItIves de modIfIcatIon dans
le modele relatIonnel; on appelle cette squence transactIon. FInalement,
l'excutIon de ces prImItIves sur la base de donnes modIfIe les Instances des
relatIons. Pour l'exemple prcdant, l'vnement de la rservatIon
correspond la cratIon d'une nouvelle entIt de la relatIon FservatIon.
L'occurence de l'vnement correspond l'InsertIon de la range (1004, 24,
1jan90, 4jan90) dans la table FservatIon.
Ce modele est donc bas sur le faIt que de petItes modIfIcatIons du champ
d'applIcatIon sont reportes comme de petItes modIfIcatIons de la base de
donnes (FIgure 112). Les objets du champ d'applIcatIon sont Interprts
InItIalement au temps t comme l'Instance 80
t
. Les occurences des
iR1
...
iRn
objets
du
C.A.
modlisation

C.A'.
t
t'

occurence
d'vnements
Squence
de primitives
de modication

C.A''.
t''
interprtation
initiale
excution
0e U|L SQL 18J
vnements de t t' sont reports en excutant les prImItIves
correspondantes donnant l'Instance 80
t'
. Et aInsI de suIte .
Ce modele amene les remarques suIvantes. La base de donnes contIent le
reflet du champ d'applIcatIon pour un Instant dtermIn dans le temps. La
base de donnes ne mmorIse pas l'hIstoIre de ses modIfIcatIons car
l'occurence des vnements entranent ImmdIatement son actualIsatIon. SI
l'on veut conserver cette hIstoIre, Il faut la modlIser explIcItement (ou
travaIller avec un SC80 hIstorIque). La base de donnes au temps t est le
reflet de l'ensemble des vnements depuIs l'InItIalIsatIon et devraIt tre
gale une Instance InItIalIse au temps t. La valIdIt de cette galIt est
soumIse des hypotheses et des contraIntes que l'on doIt valIder sur le
modele. Nous rsumons le modele des modIfIcatIons par les 5 quatIons de la
FIgure 11J.
1. Le champ d'applIcatIon actuel est gal la squence des occurences
des vnements applIqus au champ d'applIcatIon InItIal.
2. La base de donnes actuelle est gale la squence des prImItIves de
modIfIcatIon excutes sur la base de donnes InItIale.
J. L'Instance de la base de donnes InItIale est une InterprtatIon
correcte du champ d'applIcatIon InItIal.
4. La squence d'occurence des vnements est quIvalente la
squence d'excutIon des prImItIves de modIfIcatIon
5. L'Instance de la base de donnes actuelle est une InterprtatIon
correcte du champ d'applIcatIon actuel.
Ces quatIons sont des hypotheses fortes, examInons les possIbles faIblesses
de ce systeme.
L'quatIon 1 est vraIe sI la totalIt des vnements peuvent tre enregIstrs
(ou perus). l est donc essentIel que tous les vnements soIent mIs en
vIdence et que leurs sources d'occurence soIent IdentIfIes. SInon, les
transformatIons du champ d'applIcatIon apparaIssent comme spontanes,
sans cause. Et cecI rend ImpossIble la mIse jour de la base de donnes par
l'excutIon des prImItIves. 0ans le cas ou de tels vnements sont Inhrents
au champ d'applIcatIon, Il est IndIspensable de rInItIalIser prIodIquement
la base de donnes afIn de rduIre l'cart entre le champ d'applIcatIon et son
InstancIatIon. Par exemple, dans un magasIn par rapport la gestIon de son
stock, les vols de marchandIses sont InvItables et ne peuvent tre prIs en
compte par le systeme d'InformatIon (par dfInItIon le vol doIt passer
Inapperu). Un InventaIre prIodIque permet la rInItIalIsatIon de la base de
donnes.

FIgure 11J : EquatIons sous jacentes du modele de modIfIcatIon.
L'quatIon 2 est vraIe par dfInItIon, elle constItue la spcIfIcatIon mme
des prImItIves de modIfIcatIon d'un SC80. Cependant, sa valIdIt dpend de
mcanIsmes tels que la gestIon des transactIons dans le SC80, d'une gestIon
correcte de la concurrence de l'excutIon des transactIons, de la scurIt des
donnes par rapport aux dfaIllances du matrIel.
L'quatIon J est vraIe sI d'une part la modlIsatIon est fIdele et d'autre part
sI l'Instance InItIale est une InterprtatIon correcte du champ d'applIcatIon.
La fIdlIt de l'InterprtatIon dpend de la justesse de l'analyse des objets
du champ d'applIcatIon et de leur modlIsatIon. La qualIt de l'Instance
InItIale doIt tre controle mInutIeusement, par exemple par des requtes
dont les rsultats sont dj connus dans le champ d'applIcatIon.
L'quatIon 4 est vraIe sI l'on restreInt la consquence des vnements aux
objets Inclus dans la modlIsatIon. Cette restrIctIon est Importante car elle
ampute l'vnement d'une partIe de son InformatIon concernant son
adquatIon la modlIsatIon, au modele, au paradIgme de gestIon utIlIs.
Pour nous, l'vnement est porteur de modIfIcatIon sur ces autres nIveaux et
l'organIsatIon doIt tre attentIve cellescI. Par exemple, la transformatIon
des habItudes de payement des clIents par l'utIlIsatIon de carte de crdIt
doIt tre prIse en compte dans la modlIsatIon, en ajoutant les constItuants
ncessaIres. CecI est encore plus manIfeste sI la structure du champ
d'applIcatIon n'est pas bIen tablIe. Par exemple dans le domaIne de la
cognItIon, la comprhensIon de ce lIvre n'est par rductIble l'InsertIon des
mots dans une hypothtIque table contenue dans la tte du lecteur. Au fur
et mesure de sa progessIon dans la lecture, maIs chaque vnement
modIfIe peu peu son modele et fInalement tablIt un paradIgme IntrIorIs
des systemes d'InformatIon. Les vnements des champs d'applIcatIons bIen
structurs entranent prIncIpalement des modIfIcatIons sur les objets et plus
rarement des modIfIcatIons sur la structure explIquant le succs des SC80
dans ces domaInes.
Champ
d'application
Initial
+ vnements
BD
Actuel
BD
Initial
Champ
d'application
Actuel
+ primitives

1
2
3 4 5

0e U|L SQL 185

FIgure 114 : Spectre des modIfIcatIons dont l'vnement est porteur.
L'quatIon 5 est vraIe pour autant que les quatIons prcdentes soIent
vrIfIes. A terme, un cart InvItable se cre entre le champ d'applIcatIon
et la base de donnes, oblIgeant le concepteur et l'organIsatIon (par ordre
dcroIssant de frquence):
rInItIalIser la base de donnes
restructurer la modlIsatIon des donnes et des vnements
changer de modele (InformatIque)
changer de paradIgme de gestIon
Le dfI actuel des systemes d'InformatIon rsIde dans l'assurance d'une
contInuIt par rapport ces dIffrents changements (quI sont ImprvIsIbles)
Primitives de modification
Les prImItIves sont le reflet de troIs vnements lmentaIres du champ
d'applIcatIon:
La cratIon; un objet
11
nouveau apparat dans le champ d'applIcatIon,
donc Il doIt tre enregIstr dans la base de donnes (un nouveau clIent
de l'hotel)
La mIse jour; un objet dj prsent dans le champ d'applIcatIon se
modIfIe et cecI doIt tre report dans la 80 (un clIent modIfIe sa date
de dpart)
La suppressIon; un objet enregIstr dans la 80 sort du champ
d'applIcatIon et doIt donc tre lImIn de la 80 (Une chambre est
amnage en salon)
Une prImItIve ne modIfIe qu'une seule relatIon et une seule entIt. Pour
s'excuter, elle doIt vrIfIer certaInes prcondItIons et apres son excutIon
on peut toujours vrIfIer certaInes postcondItIons. Dn notera par: [pr
condItIons] prImItIve [postcondItIons], l'effet de la prImItIve.
Creation
SoIt F(C
1
,C
2
,....,C
n
) et IF une Instance de F, r un tuple de F

11
Un objet du champ d'applIcatIon peut tre modlIs par plusIeurs relatIons.
interprtations
structures
modles
paradigmes ...
Evnement
primitives
Alors la cratIon de r dans F note c(F,r) est l'opratIon quI modIfIe
l'Instance IF de la manIere suIvante:
[r IF] c(F,r) [r IF]
Dn dclenche cette prImItIve pour le tuple r lorsque le prdIcat de F devIent
valIde pour les valeurs de r.
exemple: un nouveau clIent
c(ClIents,(0umas,Alexandre,le vIeux moulIn...))

FIgure 115 : AssocIatIon des vnements lementaIres aux prImItIves.
Suppression
SoIt F(C
1
,C
2
,....,C
n
Alors la suppressIon de r dans F note s(F,r) est l'opratIon quI modIfIe
l'Instance IF de la manIere suIvante:
[r IF] s(F,r) [r IF]
champ
d'application
sort du C.A.
se transforme
entre dans le C.A.
maj de
constituants
suppression
d'entits
cration
d'entits
0e U|L SQL 187
Dn dclenche cette prImItIve pour le tuple r, lorsque le prdIcat de F
devIent InvalIde pour les valeurs de r et que r n'est pas remplac par un
autre ayant d'autres valeurs.
exemple: transformatIon d'une chambre en salon
s(Chambres,(2J,120,1,2 ,8AN,NDN ))
Mise jour
SoIt F(C
1
,C
2
,....,C
n
Alors la mIse jour de r dans F pour le constItuant C par la valeur v est
l'opratIon note m(F,r,C,v) est l'opratIon quI modIfIe l'Instance IF de la
manIere suIvante:
[r IF] m(F,r,C,v) [r[C]=v ]
Dn dclenche cette prImItIve pour le tuple r lorsque le prdIcat de F devIent
InvalIde pour r , maIs reste valIde sI r prend la valeur v pour le
constItuant C.
Exemple: modIfIcatIon de la date de dpart d'une rservatIon
m(FservatIon,(1006,14,010EC89,280EC89),0atedep,J00EC89).
1ransaction
Une transactIon est dfInIe par une squence de prImItIves de modIfIcatIon.
T = p
1
, p
2
, ... p
n

0e plus l'excutIon de la transactIon doIt vrIfIer les proprIts suIvantes
[CFA81]:
La consIstance; la transactIon doIt obIr aux protocoles lgaux. Les
protocoles lgaux apparaIssent comme un ensemble de regles
respecter pour que la concurrence des acces soIt cohrentes. Cet
ensemble dpend de la technIque choIsIe dans l'archItecture du SC80.
NanmoIns, tous les protocoles exIgent que la transactIon accdant
un tat consIstent de la base de donnes transforme celuIcI en un
tat consIstent sI on l'excute Isolment (cecI rapport la dfInItIon
des regles d'IntgrIt que l'on verra ultrIeurement)
L'atomIcIt; L'excutIon des transactIons doIt tre vue comme un tout,
Il n'exIste pas de transactIon Inacheve. Les transformatIons de la base
sont conserves sI la transactIon s'acheve, donc sI toutes les prImItIves
de modIfIcatIons se sont excutes normalement. SI la transactIon est
Inacheve, les transformatIons sont effaces et l'on restItue l'tat
prcdent.
La durabIIIt; une foIs qu'une transactIon est confIrme, on ne peut
plus l'annuler (sauf par une nouvelle transactIon)
La transactIon munIe de ces concepts est l'unIt de transformatIon de la base
de donnes et aussI l'unIt de rcupratIon des erreurs. Un ensemble de
technIques ont t dveloppes pour assurer ces proprIts. Elles
permettent la modIfIcatIon d'une base de donnes par plusIeurs utIlIsateurs
en toute scurIt. Et aussI elles supplent aux ventuelles dfaIllances du
matrIel.
Les protocoles de gestIon de la concurrence sont rgIs par le prIncIpe
d'quIvalence des ordonnancements des transactIons [PAP79]. magInons que
nous ayons l'ensemble [T
1
, T
2
, ... T
n
] de transactIons excuter de manIere
concurrente. SI nous avIons une machIne InfInIment rapIde, la dure
d'excutIon des transactIons seraIt ramene zro et le rsultat de la
modIfIcatIon correspondraIt l'excutIon squentIelle d'une des
permutatIons possIbles de l'ensemble de dpart. Nous ne possdons pas une
telle machIne par contre, quI fIxe l'ensemble des permutatIons excutes
squentIellement comme rfrence admIssIble. Les protocoles de gestIon (en
utIlIsant des verrous sur les donnes) de la concurrence vont permettre un
entrelacement entre les prImItIves des transactIons maIs assurer que le
rsultat fInal soIt quIvalent une des permutatIons. Autrement dIt ces
protocoles ne permettent pas aux transactIons de communIquer entreelles.
Une transactIon peut modIfIer la base de donnes et cette modIfIcatIon ne
doIt pas tre perue par d'autres transactIons tant qu'elle n'est pas confIrme
(acheve).
0ans les SC80, Il en va de mme, une transactIon peut modIfIer le contenu
complet de la base de donnes, ces modIfIcatIons ne seront perues qu'au
moment de la confIrmatIon.
L'atomIcIt de la transactIon doIt prvenIr la base de donnes de
modIfIcatIons Incompletes. CellescI peuvent tre dues une transactIon ne
pouvant s'achever (mauvaIs parametres, lImIte des ressources), une
transactIon errone (les condItIons errones sont prvues et la transactIon
provoque ellemme l'abandon), ou plus sImplement une dfaIllance
matrIelle durant l'excutIon. Cette dernIere peut provoquer une perte du
contenu de la mmoIre vIve ou d'un mdIa de la mmoIre secondaIre.
Quelqu'en soIt la raIson, l'atomIcIt exIge que les effets des transactIons en
cours soIent lImIns et que ceux des transactIons confIrmes soIent
restItus (sI dtruIts). La tenue d'un journal (stock Indpendamment de la
base de donnes) des modIfIcatIons entreprIses par les transactIons constItue
gnralement la technIque employe pour assurer l'atomIcIt. En cas
d'InterruptIon, Il suffIt de parcourIr le journal, pour refaIre les transactIons
confIrmes et pour dfaIre celles quI ne le sont pas. Cette reprIse ellemme
sujette des dfaIllances doIt pouvoIr tre rexcuter autant de foIs qu'Il le
faut.
Une part Importante du code d'un SC80 est consacre la rsolutIon de ces
problemes et l'on peut consIdrer qu'un logIcIel quI nglIgeraIt ces concepts
ne peut pas tre exploIt raIsonablement par une entreprIse.
0e U|L SQL 189
Langage de manipulation de donnees en SQL
Le langage SQL offre des prImItIves semblables. Elles dfInIssent un sous
ensemble quI permet de manIpuler les donnes des tables du SC80. Aux troIs
prImItIves de base sont ajoutes les commandes permettant de spcIfIer des
transactIons et celles permettant dfInIr les verrous pour la gestIon de la
concurrence.

Cette clause permet d'Insrer soIt une nouvelle range dfInIe explIcItement
ou bIen d'Insrer un ensemble de ranges dfInIes par le rsultat d'une
requte. Les colonnes non dfInIes lors de l'InsertIon prennent la valeur null
pour cette range. La lIste des colonnes peut tre vIte, dans ce cas les
valeurs se sont assocIes aux colonnes dans l'ordre de la dclaratIon de la
table (CFEATE ...)
Insertcommand

Exemple:
cratIon d'une nouvelle rservatIon pour un nouveau clIent
insert into clients
(num_client, nom, prenom, adresse)
values(2000,'New','Man','12 rue de la dcouverte')
insert into reservations
(num_client, num_chambre, date_arr, date_dep)
values(2000,12,'12-jan-91','14-jan-91')
La premIere modIfIcatIon est quIvalente :
insert into clients
values(2000,'New','Man','12 rue de la dcouverte')
magInons que nous ayons cr une table CLENTS_FECENTS quI doIt contenIr
les clIents ayant rserv partIr de l'anne 1990. Nous avons l'ordre de
cratIon suIvant et l'InItIalIsatIon de la table peut s'effectuer avec une
InsertIon accompagne d'une sousrequte.
CREATE TABLE CLIENTS_RECENTS (
NOM CHAR (20),
PRENOM CHAR (20),
ADRESSE CHAR (40))
insert into CLIENTS_RECENTS
(num_client, nom, prenom, adresse)
SELECT c.num_client, nom, prenom, adresse
FROM CLIENTS c, RESERVATIONS r
WHERE c.num_client=r.num_client
AND date_arr>='1-jan-90'
l est Intressant de noter que ce type d'InsertIon conduIt crer des
InformatIons redondantes. En effet, les InformatIons quI sont Insres sont
dj par dfInItIon dans la base de donnes.
Updatecommand

Cette clause permet de mettre jour une colonne ou un groupe de colonne.
L'expressIon de mIse jour est soIt une expressIon sImple ou bIen une sous
requte. La condItIon de la clause WHERE permet de spcIfIer les ranges quI
doIvent tre mIse jour.
Exemple:
modIfIcatIon de la date de dpart du clIent 1006
update reservations
set date_dep='30-DEC-89'
WHERE num_client=2000 AND date_dep='28-DEC-89';
augmentatIon de tous les prIx de 10
sImpleupdate

update chambres
set prix=prix*1.10
augmentatIon des prIx de 10 pour les chambres avec baIn
update chambres
set prix=prix*1.10
WHERE confort='BAIN';
augmentatIon des prIx de 10 + 5 Francs par personne pouvant occuper la
chambre;
update chambres
set prix=prix*1.10 + 5*nbr_pers
0e U|L SQL 191
augmentatIon des prIx au prIx moyen en fonctIon du confort (IcI les ranges
de la table modIfIer sont utIlIses comme varIable dans la sousrequte;
update chambres c1
set (prix)=(SELECT avg(prix)
FROM chambres c2
WHERE c1.confort=c2.confort)
subqueryupdate

deletecommand

Exemple:
SuppressIon de la chambre 2J
delete FROM chambres
WHERE num_chambre=23
SuppressIon de toutes les chambres
delete FROM chambres
transactIoncommand

Cette clause permet de spcIfIer les transactIons. Le dbut de la transactIon
est ImplIcIte, Il est sItu dIrectement apres le dernIer poInt de confIrmatIon
ou au dbut de la sessIon de travaIl.
La commande commit dfInIt la fIn de la transactIon. Les commandes de
manIpulatIon de la modlIsatIon (CREATE, drop, ...) provoquent
ImmdIatement apres leur excutIon un commit ImplIcIte.
La commande set transaction permet de dfInIr explIcItement le dbut
d'une transactIon dans le cas ou l'on veut excuter plusIeurs requtes
consIstentes par rapport la lecture. L'optIon read only dfInIt que cette
transactIon ne fera pas de modIfIcatIon.
La commande savepoint ... permet de dfInIr des poInts de retour
l'IntrIeur mme de la transactIon. l sera possIble de revenIr explIcItement
l'tat dfInI en ces poInts.
La commande rollback ... permet de retourner l'tat dfInI au dbut de
la transactIon. En spcIfIant un savepoInt, on revIent l'tat dfInI ce
poInt.
exemple:
Une transactIon confIrme
update chambres
set prix=prix*1.10
commit
Apres rceptIon de ce message, les effets de la transactIons sont vIsIbles
pour d'autres processus Interrogeant la base de donnes
Une transactIon annule
update chambres
set prix=prix*1.10
rollback
Les effets de la transactIon sont annuls
lockcommand

La gestIon des verrous est, par dfaut, assure par le SC80. Cependant, Il
est possIble de spcIfIer pour une transactIon les verrous demands. CecI
sont poss au nIveau de la table ou au nIveau de la range. 0ans le cas ou un
verrou est dj pos par un autre processus, l'optIon nowait spcIfIe que la
transactIon ne doIt pas attendre maIs retourne le controle l'utIlIsateur.
Lockmode

Les dIffrents mode de verouIllage sont les suIvants:
share; au nIveau de la table, mode partag en lecture, sans mIse
jour possIble
exclusive; au nIveau de la table, mode exclusIf en lecture, ne
permettant aucune modIfIcatIon
row share (ou row update); au nIveau des ranges, mode
partag en lecture, InterdIt un acces exclusIf de la table.
row exclusive; au nIveau des ranges, mode partag en lecture,
InterdIt un acces partg de la table.
0e U|L SQL 19J
share row exclusive; au nIveau des ranges, mode partag en
lecture, InterdIt un acces partg de la table et la modIfIcatIon des
ranges.
subqueryCFEATE

Nous ajoutons cette clause IcI car elle cumule deux effets, la cratIon d'une
table et l'InsertIon ImmdIate de donnes. Nous pouvons donc exprImer les
deux requtes prcdentes pour CLENTS_FECENTS en une seule:
CREATE TABLE CLIENTS_RECENTS AS
SELECT c.num_client, nom, prenom, adresse
FROM CLIENTS c, RESERVATIONS r
WHERE c.num_client=r.num_client
AND date_arr>='1-jan-90'
Par dfaut, les noms et les types des colonnes sont prIs dans le rsultat de la
requte.

FIgure 116 : |asque de modIfIcatIon pour les clIents.
Interfaces utilisateurs
l est vIdent que les commandes SQL vues plus haut ne peuvent pas tre
utIlIses dIrectement par l'utIlIsateur. Ces dernIeres doIvent tre Insres
dans une Interface permettant le dIalogue entre l'utIlIsateur et le SC80.
Cette Interface peut tre ralIse avec un gnrateur d'cran ou avec un
langage de programmatIon (C++, Java, .) Cette Interface prsentera
l'utIlIsateur un masque de saIsIe classIque; dans chaque champ, Il pourra
entrer ses donnes. L'Interface fera, elle l'appel au SC80 avec la commande
SQL. 0ans un mme masque (FIgure 116), Il est possIble de crer,
slectIonner, mettre jour et supprImer des donnes.
Dn peut effectuer certaInes vrIfIcatIons la saIsIe, maIs nous allons voIr,
dans le chapItre suIvant, qu'Il est aussI ncessaIre de complter la
modlIsatIon avec des regles d'IntgrIt portant sur l'ensemble des Instances.
Lxercices
Questions sur 11
3
0onnez une requte SQL pour chaque poInt cIdessous:
1. Insrer l'entretIen peInture carosserIe du vhIcule 100004 au jour No
24
2. mettre jour l'adresse du chauffer No 1 quI est actuellement 2J
chemIn de l'avenIr
J. supprImer les InformatIons sur le plannIng concernant les jours
InfrIeurs 100
Reponses sur 11
3
insert into Entretien (Nochassis, nojour, description)
values(100004, 24, 'peinture carosserie')
2) Dn remarque les deux apostrophes pour en Insrer un !
update Chauffeur
set adresse='23 chemin de l''avenir'
WHERE nochauffeur=1
J)
delete FROM planning
WHERE nojour<100;
Dn supprIme l'effet de ces transactIons avec le Follback
Rollback

1)
0e U|L SQL 195
J2. Les Rgles d'integrite
"Chaque pice occupe une case et chaque case ne peut
contenir qu'une seule pice." (Camil Seneca - Les checs)
Nous avons vu comment Insrer, modIfIer et supprImer des entIts dans une
Instance. Ces modIfIcatIons doIvent tre le reflet d'vnements appartenant
au champ d'applIcatIon. l est vIdent qu'Il est tres sImple de commettre des
erreurs grossIeres lors de ces opratIons. Cependant, le champ d'applIcatIon
est soumIs des InvarIants appels regles d'IntgrIt quI permettent de
rduIre les rIsques de produIre des Instances InconsIstantes. Par exemple, on
ne peut pas rserver une chambre quI n'exIste pas un clIent Inconnu.

FIgure 121 : ntgratIon des regles d'IntgrIt dans le processus de
modlIsatIon
Les regles d'IntgrIt sont des prdIcats quI sont toujours valus vraI. A
noncer, elles semblent tre des lapalIssades : la date d'arrIve prcede la
date de dpart. |aIs elles constItuent un puIssant moyen de vrIfIcatIon et
d'lImInatIon des Instances quI ne peuvent pas exIster dans un champ
d'applIcatIon. La modlIsatIon du champ d'applIcatIon s'accompagne donc
d'une phase de recherche des InvarIants que l'on exprIme sous forme de
regles d'IntgrIt. Lors de l'tape de concrtIsatIon, elles sont transformes
en un ensemble de mcanIsmes quI valIdent ces regles.
Ces mcanIsmes sont varIs Ils peuvent tre Intgrs aux masques de saIsIe
ou faIre partIe du noyau du SC80 et tre spcIfIs lors de la cratIon d'une
table ou plus sImplement tre des requtes quI dtectent la prsence
d'anomalIes dans la base de donnes.
iR1
...
iRn
Md
RI
objets
du
C.A.
modlisation
& invariants
concrtisation
interprtation
validation
des RI
Definitions et proprietes
lR est l'ensemble des Instances de F
F=[IF IF est une Instance de F]
l80 est l'ensemble des Instances de la base de donnes
80 = [I80 I80 F
j
,j=1..n]
Une regle d'IntgrIt r est un prdIcat ayant 80 pour domaIne
rI : 80 {vraI, faux]
Dn dIra quI I80 80 vclde la regle d'IntgrIt rI sI et seulement sI
rI(I80)= vraI
l80/r est l'ensemble des Instances de la base de donnes valIdant rI
Rl dsIgne l'ensemble des rI d'une modlIsatIon
F = [rI
1
, ., rI
n
]
Dn dIra quI I80 80 vaIIde l'ensemble F (ou est consIstent par rapport
F) sI et seulement sI I80 valIde chaque rI
j
de F.
F : 80 {vraI, faux]
F(I80) = rI
j
(I80) , j=1..n
= rI
1
(I80) rI
2
(I80)

...

rI
n
(I80)

l80/Rl est l'ensemble des Instances de la base de donnes valIdant F
80/F= [I80 F(I80)]
Dn remarque que
80/F= 80/rI
1
80/rI
2

...

80/rI
n

80 dfInIt un espace dont chaque dImensIon correspond une relatIon.
Chaque poInt de cet espace est assocI une Instance de la base de
donnes. 80/rI dfInIt le sousensemble des Instances de la base de donnes
valIdant la regle rI. 80/F est l'IntersectIon de tous ces sousensembles.
l s'agIt donc d'tablIr des regles que valIde le champ d'applIcatIon
Indpendamment des valeurs des objets de ce dernIer.
0ans le travaIl de N.H. Le Pham [PHA90] sur les regles d'IntgrIt, on trouve
les proprIts suIvantes:
Un ensemble F est trvcl sI et seulement sI toutes les Instances
valIdent F, soIt:
F est trIvIal 80/F=80
Par exemple, rI: (0ate_Arrs0ate_0ep) (0ate_Arr0ate_0ep) est une rI
trIvIale, n'Importe quel couple de dates satIsfaIt cette regle.
Un ensemble F est scts]cscble sI et seulement s'Il exIste une Instance
valIdant F, soIt:
F est satIsfaIsable 80/F =
0ans le cas contraIre on dIt que F est nscts]cscble, soIt
0e U|L SQL 197
F est satIsfaIsable 80/F =
Par exemple, rI: (0ate_Arr0ate_0ep) (0ate_Arr0ate_0ep) est une rI
InsatIsfaIsable, aucun couple de dates satIsfaIt cette regle.
La notIon de satIsfaIsabIlIt est rapprocher de celle de consIstance en
logIque. Nous nous Intressons donc qu'aux ensembles de regles
satIsfaIsables.
La regle rI est mplque par F (note FrI ,ou est la consquence
logIque de F) sI et seulement sI toutes les Instances valIdant F valIdent
aussI rI, soIt
(FrI) (80/F 80/rI)
Par exemple, rI2: (0ate_Arrs0ate_0ep + n jours) ou n est posItIf, est
ImplIque par la rI1 : (0ate_Arrs0ate_0ep).
L'ensemble F est quvclent F' sI et seulement sI toutes les Instances
valIdant F valIdent aussI F' et toutes les Instances valIdant F' valIdent
aussI F, soIt
(FF') (80/F = 80/F')
Par exemple, rI1: (0ate_Arrs0ate_0ep) (0ate_Arr0ate_0ep) est
quIvalente rI2: (0ate_Arr=0ate_0ep).
L'ensemble F est plus contrcyncnt que F' sI et seulement sI toutes les
Instances valIdant F valIdent aussI F', soIt
(FsF') (80/F 80/F')
Par exemple, rI1: (0ate_Arr1jan90) est plus contraIgnante que rI2:
(0ate_Arr1jan89).
La ]ermeture de F est l'ensemble des contraIntes ImplIques par F.
F
++
=[rI FrI]
F est rredondcnt sI et seulement s'Il n'exIste aucune regle rI F telle
que (F[rI])rI. Aucune rI ne peut donc se dduIre des autres.
Les notIons de fermeture et d'Irredondance seront partIculIerement utIles
lorsque nous aborderons l'tude des dpendances fonctIonnelles, un groupe
partIculIer de regles d'IntgrIt. Elles permettront de rechercher l'ensemble
mInImal de rI.
La consistance d'une transaction
Nous sommes maIntenant en mesure de comprendre la proprIt de la
consIstance d'une transactIon. Une transactIon T s'excute sur une Instance
consIstante I80 et transforme cellecI en une autre Instance consIstante I80'
par rapport un ensemble de regles d'IntgrIt prvalant sur la base de
donnes. En termes de pr et postcondItIons, nous pouvons noter:
[I80 80/F] T [I80' 80/F]
Pendant la dure de la transactIon, l'tat de la base de donnes peut tre
InconsIstant. |aIs ces tats ne sont perus que par la transactIon T.
L'atomIcIt et les protocoles de gestIon de la concurrence assurent que seul
l'tat I80' sera vIsIble (ou I80 sI on annule la transactIon).
0ans la fIgure 2, les prImItIves de modIfIcatIon dfInIssent les sauts
mInImaux d'un tat l'autre de la base de donnes. La transactIon dfInIt un
parcours commenant et se termInant par un tat consIstant.
Ces regles d'IntgrIt sont stctques Car l'tat InItIal et fInal ne sont pas lIs,
par opposItIon aux regles dyncmques ou ces tats sont lIs. ClassIquement
l'tat cIvIl d'une personne est un exemple d'une regle dynamIque, en effet
l'tat marI ne peut succder que l'tat veuf ou dIvorc (sI l'on exclut les
annulatIons de marIage, tres rares !)

FIgure 122 : Fegles d'IntgrIt et transactIons
Portee de la rgle d'integrite
ExamInons les troIs regles d'IntgrIt suIvantes:
rI1: Le nombre des membres de l'DulIpo est un nombre premIer et un nombre
de Queneau.
12

rI2: La date de dpart d'une rservatIon doIt tre postrIeure la date
d'arrIve, soIt
rI2: r FservatIons (r.datedep r.datearr)
rIJ: Une mme chambre ne peut tre rserve par deux clIents dIffrents le
mme jour
rIJ: r FservatIons, r' FservatIons tel que:
r.NumclIent = r'.NumclIent
et r.Numchambre = r'.Numchambre
et r.0atearr s r'.0atedep
et r.0atedep r'.0atearr
rI4:Les numros de clIents dans FservatIon sont dfInIs dans ClIents
rI4: FservatIon[Num_clIent] ClIents[Num_clIent]

12
PoInt 8 des ndIcatIons lImInaIres de Jacques Foubaud In La bIblIotheque DulIpIenne,
EdItIons Famsay, 1987
Modlisation
donnes
Primitives
modification
Rgles
d'intgrit
IBD
IBD/RI
iBDI'
iBDI
Transaction T
0e U|L SQL 199
rI5:Les numros de clIents sont unIques
rI5: r ClIents, r' ClIents tel que:
r[Nom,Prenom,Adresse] = r'[Nom,Prenom,Adresse]
et r.NumClIent = r'.NumClIent

Dn peut remarquer que la valIdatIon des rI prcdentes demande des
connaIssances dIverses sur les Instances de la base de donnes.
rI1 peut tre valIde dIrectement sur le constItuant nombre_de_membres (sI
l'on constItuaIt une base de donnes hIstorIque pour l'DulIpo). Cette regle est
de type domcne, Il suffIt de connatre la valeur prIse par le constItuant pour
valIder la regle. Normalement, ces regles sont dfInIes au nIveau du domaIne
du constItuant, cependant la complexIt de certaInes dpasse les capacIts
de modlIsatIon des domaInes (type, Intervalle, ...)
rI2 peut tre valIde dIrectement sur l'entIt de FservatIon . Cette regle est
de type ntrctuple Il suffIt de connatre la valeur prIse par l'entIt pour
valIder la regle.
rIJ peut tre valIde dIrectement sur l'Instance de la relatIon FservatIon.
Cette regle est de type ntrcrelcton, Il suffIt de connatre la valeur prIse
par plusIeurs des entIts d'une Instance pour valIder la regle.
rI4 demande pour tre valIde les Instances de plusIeurs relatIons
dIffrentes. Cette regle est de type nterrelcton.
rI5 peut tre valIde dIrectement sur l'Instance de la relatIon ClIents. Cette
regle est de type ntrcrelcton. Dn dIt aussI que NumclIent est une cl de la
relatIon ClIents. Une cl est un ensemble de constItuants (mInImum) quI
dtermIne de manIere unIque tous les autres constItuants de la relatIon (Dn
revIendra sur cette notIon dans le chapItre sur les dpendances
fonctIonnelles).
La fIgure J rsume ces dIffrents types. La complexIt de la valIdatIon du
type dpend dIrectement de l'tendue de la regle. Un des objectIfs lors de la
conceptIon de la base de donnes est de mInImIser les couts de valIdatIon de
ces regles d'IntgrIt.
0Irectement lIe la valIdatIon d'une regle d'IntgrIt, nous avons la notIon
de porte d'une regle d'IntgrIt. Une prImItIve de modIfIcatIon appartIent
la porte d'une regle rI sI elle peut rendre InvalIde l'Instance de la 80. C'est
dIre qu'elle peut Influencer la consIstance de la base de donnes par
rapport rI

FIgure 12J : tendue des dIffrents types de regles d'IntgrIt
0fInItIon
SoIt P l'ensemble des prImItIves applIcables au schma S=[F1, F2, ...,
Fn] la porte dune ryle r est l'ensemble des prImItIves de
modIfIcatIon quI peuvent rendre InvalIde une Instance I80, soIt:
P
p
(rI) =[p P [I80 80/rI] p [I80' 80/rI]]
Pour les rI prcdentes, nous avons (C=cratIon, |=mIse jour,
S=suppressIon, les _ correspondent aux parametres non spcIfIs des
prImItIves):
P
p
(rI1)=[C(DulIpo,_),
|(DulIpo,_,nombre_de_membres,_)]
P
p
(rI2)=[C(FservatIons,_),
|(FservatIons,_,date_Arr,_),
|(FservatIons,_,date_0ep,_)]
P
p
(rIJ)=[C(FservatIons,_),
|(FservatIons,_,num_clIent,_),
|(FservatIons,_,num_chambre,_),
|(FservatIons,_,date_Arr,_),
|(FservatIons,_,date_0ep,_)]
P
p
(rI4)=[C(FservatIons,_),
S(ClIents,_),
|(ClIents,_,num_clIent,_)]
P
p
(rI5)=[C(ClIents,_),
Dn peut constater que la porte est en rapport avec les types de regle. La
porte est utIle pour dtermIner les controles suffIsants et ncessaIres pour
la 80 par rapport aux transactIons et aux Interfaces utIlIsateurs.
R
C1 C2 Cn ...
cn
ri-intra
entite
ri-intra
relation
S
ri-inter
relation
ri-domaine
T
0e U|L SQL 201
0'une manIere Inverse, on peut dfInIr la sensblt d'une prImItIve par
l'ensemble des rI dont elle est lment de la porte.
S
p
(p)=[rI F p P
p
(rI)]
Avec les rI cIdessus, nous avons:
S
p
(C(FservatIons,_))=[rI2, rIJ, rI4]
S
p
(S(ClIents,_))=[rI4]
Dn peut tendre les notIons de porte et de sensIbIlIt au nIveau de la
transactIon.
SoIt A une applIcatIon dfInIe comme l'ensemble des transactIons [T
1
, T
2
, ...
T
n
] ou chaque T
I
est dfInIe par un ensemble de prImItIves de modIfIcatIon
T
I
= [ p
I1
, p
I2
, ... p
Im
].
La porte de la regle rI par rapport l'applIcatIon A est alors dfInIe comme
l'ensemble des transactIons dont une des prImItIves appartIent la porte de
la rI.
P
T
(rI)=[T A p T ou p P
p
(rI)]
Dn peut aussI dfInIr la sensblt d'une transactIon par l'ensemble des rI
dont elle est lment de la porte.
S
T
(T)=[rI F T P
T
(rI)]
Actuellement, les SC80 permettent de valIder certaInes regles d'IntgrIt
exprImes lors de la conceptIon du schma. Ces regles sont restreIntes des
catgorIes bIen dfInIes, dont la porte en terme de prImItIves est
ImplIcItement assocIe aux parametres de la catgorIe. Cela sIgnIfIe que le
SC80 dtermIne automatIquement la porte de ces regles et valIde ces
dernIeres des qu'une de ces prImItIves est excute. Ces catgorIes sont:
une regle ntrctuple, exprIme par un prdIcat sur les constItuants
d'une relatIon . Les prImItIves de la porte sont la cratIon d'une
entIt et la mIse jour d'un des constItuants du prdIcat de la regle
exemple, rI: prIx 50 * nbr_pers
P
p
(rI)=[ C(Chambres, _ ),
|(Chambres,_,prIx,_),
|(Chambres,_,nbr_pers,_)]
une regle portant sur l'unct des valeurs prIses par un ensemble de
constItuants X d'une relatIon (on verra plus loIn que cecI est une cl).
SoIt rIF,r'IF r[X]=r'[X]. l n'exIste donc pas deux entIts ayant
mme valeur pour X. Les prImItIves de la porte sont la cratIon d'une
entIt et la mIse jour d'un des constItuants de X.
exemple, rI: UnIcIt sur Num_chambre dans Chambres
P
p
(rI)=[ C(Chambres, _ ),
|(Chambres,_,num_chambre,_)]
une regle portant sur l'InclusIon entre deux ensembles d'entIts,
exprIme par F[X] S[Y] (dpendance d'InclusIon). Les prImItIves de la
porte sont la cratIon d'une entIt de F, la mIse jour d'un des
constItuants de X, la suppressIon d'une entIt de S et la mIse jour
d'un des constItuants de Y,
exemple dj cIt,
rI4: FservatIon[Num_clIent] ClIents[Num_clIent]
P
p
(rI4)=[ C(FservatIons,_),
S(ClIents,_),
En dfInIssant une de ces regles d'IntgrIt dIrectement dans le SC80, le
concepteur ne doIt plus se proccuper de sa valIdatIon lors d'une
transactIon. Le SC80 la valIde automatIquement, cependant Il doIt rcuprer
les messages d'erreur afIn de les rInterprter pour l'utIlIsateur.
Pour les regles d'IntgrIt n'entrant pas dans ces catgorIes, le concepteur
peut envIsager troIs types de solutIons.
La vcldcton loccle de la rI, pendant l'excutIon de la transactIon;
dans le code de la transactIon, l'excutIon de la prImItIve dangereuse
pour l'IntgrIt de la rI est soumIse des prcondItIons valIdant la rI.
Cette solutIon permet de mInImIser les couts de la valIdatIon. En
effet, on connat au moment de l'excutIon de la prImItIve tous ses
parametres et on peut donc les utIlIser pour cIrconscrIre le contexte
de la valIdatIon. Par exemple, pour assurer qu'une chambre n'est pas
loue deux foIs le mme jour, lors de la transactIon de rservatIon, la
valIdatIon ne portera que sur la chambre et la prIode concerne par
les parametres de la transactIon. Cette solutIon a le dsavantage de
coder dans les transactIons les regles. En cas de modIfIcatIons de ces
regles, Il faut revoIr toutes les transactIons appartenant leur porte.
La vcldcton ylobcle de la rI, apres l'excutIon de la transactIon;
avant la confIrmatIon de la transactIon, on valIde toutes les regles
d'IntgrIt appartenant la sensIbIlIt de la transactIon. 0ans cette
solutIon, on perd l'effIcacIt de la solutIon prcdente, par contre, on
gagne en souplesse en cas de modIfIcatIon des regles d'IntgrIt.
Le dcynostc; aucune valIdatIon n'est effectue pendant l'excutIon
des transactIons. La base de donnes peut devenIr InconsIstante. l
exIste cependant pour chaque regle, une possIbIlIt de dIagnostIquer
les anomalIes. Ces dIagnostIcs sont excuts avant d'entreprendre
certaInes transactIons ou Il est IndIspensable que la base soIt
consIstante. La stratgIe est donc de permettre la mmorIsatIon des
donnes et d'effectuer prIodIquement des correctIons sur les
anomalIes.
Un systeme d'InformatIon complexe ncessIte gnralement l'utIlIsatIon des
troIs types de solutIons. La valIdatIon locale pour son effIcacIt et pour
prserver des temps de rponse acceptables. La valIdatIon globale lorsque
les regles sont rgulIerement modIfIes (plus vIte que le temps de
0e U|L SQL 20J
reprogrammatIon des transactIons). Le dIagnostIc quand Il est Important de
saIsIr au plus vIte l'InformatIon, en assumant une prIode de consolIdatIon
des donnes pour lImIner les anomalIes.
7.4. Les rgles d'integrite en SQL
ExamInons la syntaxe du langage SQL pour dfInIr les regles d'IntgrIt. Ces
dernIeres sont spcIfIes soIt la cratIon de la table ou bIen lors d'une
modIfIcatIon de la structure de la table. 0eux types de regles sont admIs,
l'un portant sur une seule colonne et l'autre portant sur un groupe de
colonnes. Un IdentIfIant (nom) peut tre assocI chaque regle.
CFEATETA8LE

newcolumnlIst

Les regles portant sur une colonne seulement sont dclares ImmdIatement
apres le type de la colonne. Dn trouve les clauses suIvantes:
Null/ Not Null : InterdIt que la colonne puIsse prendre des valeurs
nulles (nondfInIes).
Unique : la colonne est une cl de la table. Les valeurs de cette
colonne sont toutes dIstInctes les unes des autres. (La colonne doIt
aussI tre spcIfIe comme not null)
Primary Key : IdentIque unIque. La cl prImaIre est la cl que le
concepteur prIvIlgIe dans les acces et les joIntures avec cette table,
elle est Indexe.
References ... : les valeurs de cette colonne doIvent tre des
lments de la table projete sur la colonne de rfrence. La colonne
de rfrence doIt tre spcIfIe comme unIque (ou cl prImaIre)
Check(...) : un prdIcat est assocI la colonne, Il utIlIse
seulement les noms des constItuants de la table et se vrIfIe
localement sur la range (cecI exclut les sous requtes)
columnconstraInt

l est possIble de dclarer des regles portant sur plusIeurs colonnes. Dn
trouve les clauses suIvantes:
Unique(...) : le groupe de colonnes est une cl de la table. Les
valeurs de ces colonnes sont toutes dIstInctes les unes des autres. (Les
colonne doIvent aussI tre spcIfIes comme not null)
Primary Key(...) : IdentIque la clause unIque. Une seule cl
prImaIre est autorIse par table.
Foreign Key () References ... : les valeurs de ce groupe de
colonnes doIvent tre des lments de la table projete sur le groupe
de rfrence. Les colonnes de rfrence doIvent tre spcIfIes
comme unIque (ou cl prImaIre)
Check(...) : dj vu plus haut
newconstraIntlIst

tableconstraInt

deftableconstraInt

Exemple:
Feprenons notre modlIsatIon Hotel et ajoutons les regles d'IntgrIts lors de
la cratIon des tables. Nous obtenons:
CREATE TABLE CLIENTS (
NOM CHAR (20) not null
check (NOM=upper(NOM)) constraint CLIENTS_RI1,
PRENOM CHAR (20),
ADRESSE CHAR (40),
primary key (NUM_CLIENT) constraint CLIENTS_RI2)
0e U|L SQL 205
Num_clIent est la cl. Tous les noms sont en majuscule.
CREATE TABLE CHAMBRES (
NUM_CHAMBRE NUMBER (2) not null,
PRIX NUMBER (8,2) not null,
NBR_LITS NUMBER (1) not null
check (NBR_LITS between 1 AND 4) constraint CHAMBRES_RI1,
NBR_PERS NUMBER (1) not null
check (NBR_PERS>NBR_LITS)
constraint CHAMBRES_RI2,
CONFORT CHAR(6) not null
check (CONFORT in ('bain','WC','douche'))
EQUIPEMENT CHAR(3) not null
check (EQUIPEMENT in ('TV','NON'))
primary key (NUM_CHAMBRE)
constraint CHAMBRES_RI5)
Num_chambre est la cl. Le nombre de lIts est comprIs entre 1 et 4. Le
nombre de personnes est suprIeur au nombre de lIts. Le confort et les
quIpements sont restreInts certaInes valeurs.
CREATE TABLE RESERVATIONS (
NUM_CLIENT NUMBER (6) not null,
NUM_CHAMBRE NUMBER (2) not null,
DATE_ARR DATE not null
check (DATE_ARR<DATE_DEP)
constraint RESERVATIONS_RI1,
DATE_DEP DATE,
primary key (NUM_CHAMBRE,DATE_ARR)
foreign key (NUM_CLIENT)
references CLIENTS(NUM_CLIENT)
foreign key (NUM_CHAMBRE)
references CHAMBRES(NUM_CHAMBRE)
constraint RESERVATIONS_RI5)
La cl prImaIre est le groupe num_chambre et date_arr. Les chambres et les
clIents de rservatIons sont connus dans les relatIons de rfrence. La date
de dpart est postrIeure la date d'arrIve.
mposer un ensemble de valeurs pour une colonne est dlIcat du poInt de vue
de la conceptIon, car le jour ou se groupe volue Il faut modIfIer la regle et
Il semble que les SC80 aIent encore quelques dIffIcults lors de telles
modIfIcatIons. Par exemple, dans le futur, Il faudra peuttre ajouter 'sauna'
aux valeurs de confort. CecI est donc rserver des groupes tres stables
(ouI/non, par exemple) autrement, Il faut dfInIr des tables pour les codes.
Les regles dfInIes avec des rfrences dtermInent un ordre de cratIon et
de suppressIon des tables. En effet, la table de rfrence doIt tre cre
avant celle quI y faIt rfrence et supprIme apres cette dernIere. AInsI Il
faudra supprImer les relatIons d'hotel dans l'ordre suIvant.
CREATE TABLE T2
(A char(8) not null unique,
B char(8) not null references T1(B))
alter TABLE T1 add ( foreign key (A) references T2(A))
Rappelons que certaines ri ne sont pas exprimables directement
dans le SGBD. Par exemple: pas deux rservations le mme jour
pour la mme chambre. On peut alors crire, des requtes pour
dterminer les anomalies. Dans notre cas, aprs insertion
d'une rservation errone, on obtient:
insert into reservations values(1004,14,'27-DEC-89','30-DEC-
89');
rem: ne tient pas compte des valeurs nulles de date_dep
SELECT *
FROM Reservations r1, Reservations r2
WHERE r1.num_chambre=r2.num_chambre
AND r1.num_client<>r2.num_client
AND r2.date_arr between r1.date_arr AND r1.date_dep
AND r2.date_arr<>r1.date_dep;
Rem: on dfait notre requte pour liminer les donnes du test
rollback;
Dans le chapitre suivant, nous allons examiner les dpendances
fonctionnelles qui sont un type de rgles d'intgrit qui
permettent de trouver les cls d'une relation, les dpendances
d'inclusion et surtout d'tudier les proprits d'une
dcomposition.
Exercice
Questions sur TT3
1) Redfinir le schma de TT3 pour tenir compte des rgles
d'intgrit
2) Dterminer l'ordre de suppression des tables (inverse de
l'ordre de cration)
3) Dfinir des ri ne pouvant tre directement valides par le
SGBD pour TT3 et donner l'ordre SQL pour dtecter les
anomalies.
Rponses sur TT3
Cration du schma
0e U|L SQL 207
CREATE TABLE Station(
noZone number(2),
noStation number(1) not null
primary key constraint station_RI1);CREATE TABLE
Type(
modele char(12) not null
primary key
constraint Type_RI1,
nbPlaces number(2) not null
check (nbPlaces>0)
Constraint Type_RI2,
categorie char(2) not null
check (categorie in ('V','PL'))
typeCarburant char(12) not null
check (typeCarburant in ('ESSENCE','DIESEL'))
automatique char(1) not null
check (automatique in ('Y','N'))
poids number(5) not null
check (poids>0)
Constraint Type_RI6);
CREATE TABLE Distance( heure number(2),
zoneDe number(2) not null,
zoneA number(2) not null,
tempsParcours number(3) not null
check (tempsParcours>0)
Constraint Distance_RI1,
primary key (zoneDe,zoneA)
constraint Distance_RI2);
CREATE TABLE Vehicule(
noChassis number
primary key
constraint Vehicule_RI1,
noPlaque number not null
unique
miseEnService date not null,
modele char(12) not null
references Type(modele)
references Station(noStation)
constraint Vehicule_RI4);
CREATE TABLE Chauffeur(
noChauffeur number not null
primary key constraint Chauffeur_RI1,
nom char(24) not null,
prenom char(24) not null,
adresse char(80) not null,
references Station(noStation)
constraint Chauffeur_RI2);
CREATE TABLE Situation(
noChassis number not null
primary key
constraint Situation_RI1
references Vehicule(noChassis)
constraint Situation_RI2,
noZone number(2) not null);
CREATE TABLE Carburant(
noPlaque number not null,
noJour number(3) not null,
kilometrage number not null
check (kilometrage>0)
Constraint Carburant_RI1,
litres number(3) not null
check (litres>0)
typeCarburant char(12) not null
check (typeCarburant in ('ESSENCE','DIESEL'))
primary key (noPlaque,noJour,kilometrage)
constraint Carburant_RI4);
CREATE TABLE Entretien(
constraint Entretien_RI1,
description char(240) not null,
primary key (noChassis,noJour)
constraint Entretien_RI2);
CREATE TABLE Permis(
references Chauffeur(noChauffeur)
constraint Permis_RI1,
categorie char(2) not null
check (categorie in ('V','PL'))
Constraint Permis_RI2,
primary key (noChauffeur,categorie)
constraint Permis_RI3);
CREATE TABLE Planning(
references Chauffeur(noChauffeur)
0e U|L SQL 209
constraint Planning_RI1,
constraint Planning_RI2,
trancheHoraire char(1) not null
check (trancheHoraire in ('A','B','C'))
Constraint Planning_RI3,
primary key (noChauffeur,noChassis,noJour)
constraint Planning_RI4);
SuppressIon du Schma
drop TABLE Carburant;
drop TABLE Entretien;
drop TABLE Planning;
drop TABLE Permis;
drop TABLE Situation;
drop TABLE Vehicule;
drop TABLE Chauffeur;
drop TABLE Distance;
drop TABLE Type;
drop TABLE Station;
Autres rgIes d'IntgrIt
rechercher d'autres regles pertInentes

0e U|L SQL 211
J3. Dependances fonctionnelles
"Ds que l'on pose une question quelle qu'elle soit, on
introduit le doute, on cesse de rciter, on va voir. Et des tas
de surprises nous attendent, y compris dans ce qui a
l'apparence du banal" (Boris Cyrulnik - De la parole comme
une molcule)
0epuIs son IntroductIon par Codd en 1970, le concept de dpendance
fonctIonnelle reste un des outIls prIncIpaux du concepteur de base de
donnes. l permet :
d'exprImer des InvarIants de la modlIsatIon ;
de dfInIr des modlIsatIons quIvalentes (conduIsant des
ImplantatIons dIffrentes) ;
d'assurer l'utIlIsatIon correcte des charnIeres lors de la composItIon ;
d'tre un outIl d'analyse lors du processus de conceptIon (ou de
restructuratIon) de la 80.
Les dpendances fonctIonnelles sont un outIl d'analyse des relatIons car elles
sont fondes sur les proprIts exIstant entre les constItuants euxmmes,
sans tenIr compte des regroupements de ces dernIers en relatIon. Les
relatIons sont donc subordonnes aux dpendances fonctIonnelles.
0fInItIon: la dpendance fonctIonnelle (df)
SoIt F une relatIon ou X F
+
et Y F
+

Alors Y dpend ]onctonnellement de X (not: X Y) sI et seulement sI
r et r' IF ( r.X=r'.X r.Y=r'.Y)

Dn dIt aussI que X dtermne Y. CecI sIgnIfIe que sI on a deux entIts de F
ayant des valeur IdentIques pour X alors elles ont aussI des valeurs
IdentIques pour Y.
0ans notre exemple Hotel, nous avons Num_ClIent Nom. Nous avons donc
pour un numro clIent qu'un seul nom. La dpendance fonctIonnelle spcIfIe
donc l'unIcIt entre deux groupes de constItuants. Nous ne pouvons pas dIre
l'Inverse Nom Num_ClIent, car Il peut exIster deux personnes s'appelant
0upont assocIes des numros clIents dIffrents.
l ne faut pas confondre les dpendances fonctIonnelles avec les cls des
relatIons (bIen qu'une cl dtermIne toujours une df). Les dpendances
fonctIonnelles permettent de dtermIner les cls et non l'Inverse.
Les dpendances fonctIonnelles sont consIdrer comme des regles
d'IntgrIt. Pour l'exemple Hotel, nous avons l'ensemble de df suIvant:
Num_chambre PrIx
Num_chambre Confort
Num_chambre Nbr_lIt
Num_chambre Nbr_pers
Num_chambre EquIpement
Num_clIent Nom
Num_clIent Prnom
Num_clIent Adresse
Num_chambre,0ateArr 0ate_0ep
Num_chambre,0ateArr Num_clIent
l exIste aussI une reprsentatIon graphIque des df (utIle pour la recherche
des cls). Les noeuds sont constItuants et les toIles reprsentent les df. Les
arcs orIents du graphe dtermIne les groupes de constItuants Intervenant
dans les df.

FIgure 1J1 : reprsentatIon graphIque de la df A8 C0

FIgure 1J2 : reprsentatIon graphIque des df d'Hotel
En regardant la FIgure 1J2, on a envIe de dIre IntuItIvement: SI
Num_chambre et 0ate_Arr dtermInent Num_clIent et sI Num_clIent
dtermIne Nom alors Num_chambre et 0ate_Arr dtermIne Nom SoIt:
Num_chambre,0ateArr Num_clIent
Num_clIent Nom
Num_chambre,0ateArr Nom
A
B
C
D
df
Numchambre
Prix
Confort
Nbr_lit
Nbr_pers
Equipement
Prnom
Adresse
DateDep
DateArr
Numclient
Nom
0e U|L SQL 21J
A partIr des dpendances fonctIonnelles, on peut drIver de nouvelles df.
FormalIsons notre IntuItIon.
Iermeture et consequence logique de I
0fInItIons
Le schmc de relcton est le couple S=(F,F) ou F est la modlIsatIon
d'une relatIon et F est un ensemble de dpendances fonctIonnelles
exprImes sur F
SoIt S=(F,F) et f une df sur F, on dIra que f est la consquence loyque
de F sI toutes les Instances de F valIdent f. (Dn notera F f)
SoIt S=(F,F), la ]ermeture de F, note F
++
est l'ensemble des
dpendances fonctIonnelles quI sont la consquence logIque de F. SoIt:
F
++
=[X Y F X Y]
La fermeture de F rpond notre questIonnement prcdant. Nous avons le
droIt de dduIre une nouvelle df sI elle appartIent la fermeture de F, donc
sI toutes les Instances de F valIdent f. 0ans la fIgure J, nous explIcItons
cette notIon de fermeture quI apparat des que nous avons un ensemble
InItIal de df et un ensemble de regles de manIpulatIon de l'ensemble InItIal.
l est alors Important de dtermIner ce que nous pouvons produIre partIr
de l. 0ans les jeux tlvIss ou les concurrents doIvent dtermIner un
nombre donn partIr d'un ensemble lImIt de nombres de dpart en
utIlIsant les opratIons arIthmtIques, Il s'agIt de dtermIner sI le nombre
donn est dans la fermeture de l'ensemble des nombres InItIaux. Les lIvres
sont dans la fermeture des mots du dIctIonnaIre, structurs par les regles de
grammaIre.
La fermeture d'un ensemble de df F doIt tre dtermIne par les Instances
des relatIons valIdant F.
Exemple: soIt le schma S(F;[A, 8, C],[A 8, C]
Le tableau suIvant exprIme toutes les df possIbles pour le schma S. Pour le
remplIr, nous avons utIlIs les raIsonnements suIvant:
ouIIdentIt: par dfInItIon XX
ouIcontenu: par dfInItIon XY est vraI sI Y est contenu dans X
noncontreexemple: l'Instance du contreexemple vrIfIe la df du
schma maIs ne vrIfIe pas la df du tableau, par exemple
a b c
a' b' c
a'' b c''
ouIdf: La df du tableau peut tre dfInIe partIr de la df du schma,
par exemple AC 8 car on a dj A 8
C 8 8C A AC A8 A8C
C DU
0ENTTE
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
8 NDN DU NDN NDN NDN NDN NDN
CDNTFEEX 0ENTTE CDNTFEEX CDNTFEEX CDNTFEEX CDNTFEEX CDNTFEEX
8C DU
CDNTENU
DU
CDNTENU
DU
0ENTTE
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
NDN
CDNTFEEX
A DU0F DU0F DU0F DU
0ENTTE
DU0F DU0F DU0F
AC DU
CDNTENU
DU0F * DU0F DU
CDNTENU
DU
0ENTTE
DU0F DU0F
A8 DU0F DU
CDNTENU
DU0F DU
CDNTENU
DU0F DU
0ENTTE
DU0F
A8C DU
CDNTENU
DU
CDNTENU
DU
CDNTENU
DU
CDNTENU
DU
CDNTENU
DU
CDNTENU
DU
0ENTTE

Dn constate que le calcul de la fermeture est un travaIl fastIdIeux sI l'on doIt
passer par les Instances. Comment calculer la fermeture sans devoIr passer
explIcItement par l'ensemble des Instances de F soumIses F : Nous allons
voIr qu'Il exIste un systeme de dductIon quI partIr du schma, nous
permet de travaIller sur les df sans devoIr examIner les Instances.
Un systme de deduction
Les axIomes de Armstrong [AF|74] constItuent un systeme de dductIon. En
effet, en les applIquant sur un schma S, Il est possIble de dduIre de
nouvelles dpendances fonctIonnelles.
0fInItIon: Fegles de dductIon
SoIt un schma s=(F,F)
0F1 (rfIexIvIt):
SI X Y F
+
alors Y X est une consquence logIque de F
0F2 (augmentatIon):
SI X Y est une consquence logIque de F et Z F
+
alors XZ YZ est
une consquence logIque de F
0F3 (transItIvIt):
SI X Y et Y Z sont des consquences logIques de F alors X Z
est une consquence logIque de F
Exemple:
SoIt le schma S=(F(A,8,C) ,[A , C])
En utIlIsant 0F1, on dduIt:
0F1 A8C A , car A A8C
A8 A , car A A8
A A , car A A
A8C 8 , car 8 A88
...
En utIlIsant 0F2, on dduIt:
0F2 applIqu A 8 et 8C F
+
A8C 8C
0F2 applIqu A 8 et C F
+
AC 8C
0e U|L SQL 215
En utIlIsant 0FJ, on dduIt:
0FJ applIqu A 8 et C A C
Les df obtenues par drIvatIon peuvent leur tour tre utIlIses dans un
processus de drIvatIon
0F2 applIqu A C8 F
+
A8 8C
Ce systeme de drIvatIon nous permet donc de drIver mcanIquement de
nouvelles df. Avant de l'utIlIser, nous devons nous assurer qu'Il est valIde et
complet.
Le systeme estIl vaIIde: C'est dIre: toutes les df dduItes sontelles des
consquences logIques de F donc quI sont valIdes par les Instances de F.
Le systeme estIl compIet: C'est dIre: toutes les consquences logIques de
F sontelles des df dductIbles du systeme.

FIgure 1JJ : 7alIdIt et compltude du systeme de dductIon
Dn peut calculer la fermeture de F par deux mcanIsmes. La valIdIt et la
compltude du systeme de dductIon se proccupent de l'galIt de ces deux
fermetures.
Validite du systme de deduction
ProposItIon 1
0F1, 0F2, 0FJ sont valIdes
Preuve:
0F1 : applIquer la dfInItIon de df
X Y ssI r et r' IF ( r.X=r'.X r.Y=r'.Y)
maIs Y X donc sI r.X=r'.X on a aussI r.Y=r'.Y
0F2: par contradIctIon de XZ YZ
Par dfInItIon, on a r et r' IF tel que
1) r.XZ=r'.XZ et 1') r.YZ=r'.YZ
maIs X Y 2) r.X=r'.X et 2') r.Y=r'.Y
1) et 2) ImplIquent r.Z=r'.Z
IR
soumis
consquence
logique
F
F++ par le systme
de dduction
F++ par
la consquence
logique
o > valide
o > complet
1') et 2') ImplIquent r.Z=r'.Z
on a une contradIctIon donc a bIen XZ YZ vraI
0FJ: par les dfInItIons
1) X Y r et r' IF ( r.X=r'.X r.Y=r'.Y)
2) Y Z r et r' IF ( r.Y=r'.Y r.Z=r'.Z)
maIs 1) et 2) r et r' IF ( r.X=r'.X r.Z=r'.Z) soIt la dfInItIon de X Z
Lxtension du systme de deduction
Avec les regles 0F1, 0F2 et 0FJ, on peut construIre de nouvelles regles utIles
dans la manIpulatIon des df.
ProposItIon 2
SoIt S=(F; F)
0F4 (Pseudo transItIvIt) :
sI X Y et YW Z sont des consquences logIques
alors XWZ est une consquence logIque
0F5 (UnIon) :
sI X Y et X Z sont des consquences logIques
alors X YZ est une consquence logIque
0F6 (0composItIon) :
sI X Y est une consquence logIque et Z Y
alors X Z est une consquence logIque
Preuve:
Les regles 0F5 et 0F6, nous donnent une quIvalence entre
X Y
1
Y
2
...Y
n

et
X Y
1

X Y
2

...
X Y
n

0F4:
0F2 sur X Y avec W XW YW
0FJ sur XW YW et YW Z XW Z
0F5.
0F2 sur X Y avec X 1) X XY
0F2 sur X Z avec Y 2) XY YZ
0FJ sur 1) et 2) X YZ
0F6
0F1 Z Y Y Z
0FJ sur X Y et Y Z X Z
0e U|L SQL 217
Iorme canonique de I et saturation de X
Dn dIra que F est en ]orme ccnonque sI toutes les df de F ont un seul
constItuant dans la partIe droIte
0fInItIon
SoIt le schma S=(F,F) et X F
+
alors on dIt que X
++
est la scturcton de
X
ou X
++
=[C F
+
X C F
++
]
Les constItuants de X
++
sont dtermIns par F partIr de X. Les constItuants
de X
++

s'Interpretent comme les InformatIons que l'on peut dtermIner en
connaIssant seulement X dans un schma F contraInt par F.
Sur un graphe de df, Il est possIble de dtermIner sImplement X
++
en
procdant aInsI:
1) mettre tous les noeuds de F
+

2) dessIner le graphe de F
J) marquer les noeuds de X
4) sI tous les noeuds de la partIe gauche d'une df sont marqus alors
marquer tous les noeuds de la partIe droIte
5) sI on n'a pas trouv de df pour applIquer le poInt 4) alors contInuer
en 6) sInon contInuer en 4)

6) les noeuds marqus correspondent X
++

Par analogIe, on peut voIr les df comme des vannes et les constItuants
comme des robInets quI doIvent tre ouverts pour laIsser passer le flux. Ce
flux se propage de proche en proche. La saturatIon correspond alors tous
les robInets quI sont ouverts.
Exemple: SoIt (F(A,8,C,0,E); [A , C, 80 E]
[A]
++
=[A,8,C]

[0]
++
=[0]

[A0]
++
=[A,8,C,0,E]

ProposItIon J
SoIt S=(F; F) alors X Y est dductIble Y X
++

Preuve
A B C
D E
A B C
D E
A B C
D E
Completude du systme de deduction
Nous sommes maIntenant en mesure de dmontrer que notre systeme de
dductIon est complet
ProposItIon4
0F1, 0F2, 0FJ forment un systeme complet
Preuve:
La compltude sIgnIfIe f F
++
Il exIste une dductIon de F donnant f.
Ide de la preuve:
par la contrapose: on va montrer que sI X Y n'est pas drIvable de F alors, Il
exIste IF telle que toutes les df de F sont vrIfIes dans IF (1) maIs X Y ne l'est pas
ce quI ImplIque que X Y n'est pas une consquence logIque de F (2)
Dn construIt IF avec 2 entIts de la faon suIvante pour la dmonstratIon:

iR
X
++

R
+
-X
++

111...111 111...111

111...111 000...000

montrons (1)
SoIt 7 W F supposons W=[W
1
.. W
n
]
Notre Instance IF valIde 7 W sI et seulement sI 7 W
I
est vrIfIe pour chaque
I=1..n

7
WI
X
++
F
+
X
++
commun X
++
et F
+
X
++

X
++
vraI vraI vraI
F
+
X
++
non maIs
ImpossIble
vraI vraI
Le tableau prcdent analyse tous les cas possIbles de 7 et W par rapport X
++
et F
+
X
++
. Le seul cas quI est ngatIf pour IF est ImpossIble car:
7 X
++
et la proposItIon sur la saturatIon ImplIque X 7, on a aussI 7 W
I
et 0FJ
ImplIque X W
I
, en applIquant nouveau la proposItIon sur la saturatIon on a W
I

X
++
(on n'est plus dans la case que l'on analysaIt). CecI rend donc ImpossIble le cas
ngatIf.
Dn vrIfIe bIen 7 W dans tous les cas.
montrons (2)
) X Y et 0F6 (dcomposItIon)
Y
I
Y , X Y
I

par dfInItIon de la saturatIon Y
I
Y ,Y
I
X
++

)Y X
++

Y
I
Y ,Y
I
X
++
par dfInItIon de la saturatIon X Y
I
Y
I
Y , X Y
I
et 0F5 (unIon) on a X Y
0e U|L SQL 219
X Y n'est pas dductIble ImplIque X Y n'est pas une consquence logIque de F
la proposItIon sur la saturatIon donne (X Y) (Y X
++
)
, Il exIste r et r' dans IF
tels que r.X=r'.X et r.Y=r'.Y. EffectIvement XX
++
et YF
+
X
++
donc r et r' sont les 2
entIts notre Instance IF, nous avons donc que X Y n'est pas une consquence
logIque de F
Thoreme:
Les regles 0F1, 0F2 et 0FJ constItuent un systeme valIde et complet
Preuve:
Lquivalence,
couverture et irredondance de I
A partIr de maIntenant, la questIon de savoIr sI une df a t obtenue par le
concept de drIvatIon ou par le concept de consquence logIque perd de son
Importance car ce thoreme nous assure de l'quIvalence des concepts

FIgure 1J4 : quIvalence entre les deux concepts permettant d'obtenIr la
fermeture de F
La fermeture de F est un ensemble tres volumIneux quI comporte toutes les
df possIbles. CertaInes de ces df peuvent tre lImInes car elles sont
redondantes. La redondance dans la partIe droIte est lImIne par la notIon
de forme canonIque quI assure qu'Il n'y a qu'un seul constItuant dans la partIe
droIte. La redondance dans la partIe gauche est lImIne par la notIon de
dpendcnce lmentcre.
0fInItIon:
Une dpendance fonctIonnelle X Y est lmentaIre s'Il n'exIste pas
X X' tel que X' Y
Exemple:
SoIt S=(F(A,8,C);[A , C])
F
++
=[ A , df lmentaIre
A8 , df non lmentaIre
A8C , df non lmentaIre
... ]
IR
soumis
consquence
logique
F
F++ par le systme
de dduction
F++ par
la consquence
logique
proposItIon 1 sur la valIdIt et proposItIon 4 sur la compltude

l exIste encore une autre faon de crer de la redondance: des df
lmentaIres peuvent tre combInes entre elles avec la regle de dductIon
transItIve et produIre de nouvelles dpendances quI sont aussI lmentaIres.
La notIon d'ensemble de df rredondcnt lImIne ces dernIeres
Exemple:
SoIt S=(F(A,8,C);[A , C])
F
++
=[ A 8, df lmentaIre
8 C df lmentaIre
A C, df lmentaIre (dpendance transItIve)
... ]
En lImInant des df, Il faut faIre attentIon conserver un quIvalent celuI
de dpart. La notIon de couverture d'un ensemble de df dfInIt cette
quIvalence.

FIgure 1J5 : LIens entre les dIffrentes dfInItIons sur les ensembles de df
0fInItIon [LED88]
C (un ensemble de df) est une couverture de F sI F
++
=C
++

La base complete de F (note F
+
) est l'ensemble des dpendances
lmentaIres de F
++

C est une base sI C F
+

C (un ensemble de df) est une couverture Irredondante de F s'Il n'exIste
pas f C tel que (C[f])
++
=F
++

G un ens de df

G forme canonique

G couverture de F

G base de F G couverture irredondante de F

G base irredondante de F

F+ base complte de F

F++ fermeture de F
F
0e U|L SQL 221
C est une base Irredondante de F sI C est une base de F et sI C est une
couverture Irredondante de F.
0ans la FIgure 1J5, on voIt comment sont relIs les dIffrents concepts
portant sur deux ensembles de df. Par rapport un ensemble F, la recherche
et l'analyse de ses bases Irredondantes sont essentIelles lors de la conceptIon
de la base de donnes. La base complete de F sera utIle lorsque l'on travaIlle
sur un sousensemble de constItuants du schma, Il sera alors possIble de
projeter dIrectement les df de la base complete sur ce sousensemble et
aInsI connatre toutes les df quI concernent ce dernIer.
Les questIons pragmatIques et pertInentes maIntenant sont de savoIr
comment:
tester l'quIvalence de F et C sans calculer les fermetures
calculer la base complete de F
calculer les bases Irredondantes de F
Algorithme lie au df
1ester l'equivalence de I et G sans calculer les fermetures
de: pour chaque df de F vrIfIer sI elle peut tre dduIte de C et pour
chaque df de C vrIfIer sI elle peut tre dduIte de F
Equivalence(F,G)
pour chaque g G faire
si non (droite(g) satX(gauche(g),F)
alors Equivalence faux
quitter
finsi
refaire
pour chaque f F faire
si non (droite(f) satX(gauche(f),G)
alors Equivalence faux
quitter
finsi
refaire
Equivalence vrai
fin Equivalence
satX(X,F)

-- saturation de X
satX X
nouveau vrai -- si on a trouv un cst
tant que nouveau faire
nouveau faux
si (gauche(f) satX) (droite(f) satX)
alors satX satX droite(f)
nouveau vrai
finsi
refaire
refaire
X
++
satX
fin X
++

Calculer la base complte de I
de:
pour chaque df de F vrIfIer sI elle est lmentaIre (lImIner la redondance
dans la partIe gauche de la df). EnsuIte gnrer toutes les dpendances
obtenues par transItIvIt.
base_complete(F)
base_complete Transitive_de(Elmentaire_de(F))
fin base_complete
Elmentaire_de(F)
Elmentaire F
pour chaque f Elmentaire faire
si cardinalit(gauche(f)>1
alors pour chaque C gauche(f) faire
-- tester si l'limination du cst dtermine
-- toujours la mme partie droite
f' (gauche(f)-C) droite(f)
si droite(f) satX(gauche(g),Elmentaire-ff'
alors Elmentaire Elmentaire-ff'
finsi
refaire
finsi
refaire
Elmentaire(F) Elmentaire
fin Elmentaire_de
Transitive_de(F)
Transitive_de
nouveau faux
alors Transitive_de Transitive_de
{(gauche(f)) satX(gauche(f),F)}
finsi
refaire
refaire
0e U|L SQL 22J
Transitive_de(F) Transitive_de
fin Transitive_de
Calculer une base irredondante de I
Ide: pour chaque df de F vrIfIer sI elle est lmentaIre (lImIner la
redondance dans la partIe gauche de la df). EnsuIte lImIner les df quI sont
redondantes (dans le cas ou F est cyclIque Il exIste plusIeurs choIx possIbles
pour cette lImInatIon donc plusIeurs bases Irredondantes, IcI la base
Irredondante dpend donc de l'ordre dans lequel on teste les df).
irredondant_de(F)
irredondant_de Elmentaire_de(F)
pour chaque f irredondant_de faire
-- tester si l'limination de f dtermine
-- toujours la mme couverture
si equivalence(irredondant_de,irredondant_de-f)
alors irredondant_de irredondant_de-f
finsi
refaire
irredondant_de(F) irredondant_de
fin irredondant_de
Lxercices
Questions sur 11
3
Les df de TTJ sont les suIvantes:
1) noChassIs noPlaque mIseEnServIce modele noStatIon
2) modele nbPlaces catgorIe typeCarburant automatIque poIds
J) noPlaque noJour kIlometrage lItres typeCarburant
4) noChassIs noJour descrIptIon
5) noChauffeur nom prnom adresse noStatIon
6) noChassIs noJour trancheHoraIre noChauffeur
7) noStatIon noZone
8) noChassIs noZone
9) heure zone0e zoneA tempsParcours
a) Feformuler en franaIs ce que sIgnIfIent ces df
b) Fpondre aux questIons suIvantes en basant vos arguments unIquement
sur la modlIsatIon (domaIne des constItuants, des relatIons et des
dpendances fonctIonnelles; voIr questIon 0):
Un vhIcule peutIl avoIr plusIeurs numros de plaque :
Non Ccr l exste lc d] noChcsss > noPlcque dductble de lc d]1
vclde pcr les entts de lc relcton vhcule
1. Un mme vhIcule peutIl tre conduIt par deux chauffeurs le
mme jour et la mme tranche horaIre :
2. Un chauffeur peutIl conduIre deux voItures le mme jour et la
mme tranche horaIre :
J. Un chauffeur peut faIre le pleIn de son vhIcule plus d'une foIs par
jour :
4. Le type de carburant estIl ncessaIre dans le relatIon carburant :
5. Un mme vhIcule peutIl tre assocI deux zones dIffrentes
un mme Instant :
c) Pour les troIs questIons suIvantes, sItuez claIrement la dIffrence avant et
apres.
1) La dpendance fonctIonnelle cIdessous est nonlmentaIre par
rapport celles de l'nonc. SI on l'acceptaIt comme lmentaIre,
qu'ImplIqueraItelle dans le champ d'applIcatIon du poInt de vue
organIsatIonnel : noPlaque noJour kIlometrage lItres typeCarburant
2) SI l'on ajoutaIt la dpendance fonctIonnelle suIvante qu'ImplIqueraIt
elle dans le champ d'applIcatIon du poInt de vue organIsatIonnel :
noChauffeur noJour trancheHoraIre noChassIs
J) La dpendance fonctIonnelle cIdessous est contradIctoIre par rapport
celles de l'nonc. SI on l'acceptaIt comme lmentaIre
organIsatIonnel :
noPlaque noJour kIlometrage lItres typeCarburant
Reponses sur 11
3
a) Feformuler en franaIs ce que sIgnIfIent ces df
1) A un noChassIs est assocI un seul noPlaque, une seule mIseEnServIce, un
seul modele et un seul noStatIon
2) A un modele est assocI un seul nbPlaces, une seule catgorIe, un seul
typeCarburant, un seul statut automatIque et un seul poIds
J) A un noPlaque et un noJour est assocI un seul kIlometrage, une seule
consommatIon lItres et un seul typeCarburant
4) A un noChassIs et un noJour est assocIe une seule descrIptIon
5) A un noChauffeur est assocI un seul nom, un seul prnom, une seule
adresse et un seul noStatIon
6) A un noChassIs , un noJour et une trancheHoraIre est assocI un seul
noChauffeur
7) A un noStatIon est assocI un seul noZone
8) A un noChassIs est assocI un seul noZone
9) A une heure, une zone0e et une zoneA est assocI un seul tempsParcours
Dn peut vrIfIer que ces assertIons sont bIen exactes dans le champ
d'applIcatIon.
b) Fpondre aux questIons suIvantes en basant vos arguments unIquement
sur la modlIsatIon :
0e U|L SQL 225
1) Un mme vhIcule peutIl tre conduIt par deux chauffeurs le
mme jour et la mme tranche horaIre :
Non ccr lc d] ) ndque le contrcre
2) Un chauffeur peutIl conduIre deux voItures le mme jour et la
mme tranche horaIre :
Du ccr cucune d] tel qu sut ne peut tre ddute de lensemble
cctuel
noChcu]]eur no1our trcncheHorcre > noChcsss
J) Un chauffeur peut faIre le pleIn de son vhIcule plus d'une foIs
par jour :
non ccr lc d] J cssoce un seul plen c un vhcule (ou s le chcu]]eur
condut deux vhcules d]]rents)
4) Le type de carburant estIl ncessaIre dans le relatIon
carburant :
Du ccr l nexste pcs de d] noPlcque > noChcsss qu permettrct de
ddure noPlcque > typeCcrburcnt
5) Un mme vhIcule peutIl tre assocI deux zones dIffrentes
un mme Instant :
Non s lon sen tent strctement c lc d] noChcsss > noZone.
Du s lon vot que:
d] cssoce un noChcsss c un noChcu]]eur
d]5 cssoce un noChcu]]eur c un noStcton
et d]Z noStcton c un noZone
donc un vhcule est cuss cssoc c lc zone du chcu]]eur qu le
condut et donc elle peut tre d]]rente de lc zone o est stctonn
le vhcule.
c) Pour Ies troIs questIons suIvantes, sItuez cIaIrement Ia dIffrence avant
et aprs.
1) La dpendance fonctIonnelle cIdessous est nonlmentaIre par
rapport celles de l'nonc. SI on l'acceptaIt comme lmentaIre,
organIsatIonnel :
Avcnt l ntct pcs possble de ]cre pluseurs plens pour un vhcule
le mme ]our.
Aprs l serc possble de ]cre pluseurs plens pour un vhcule le
mme ]our s les klomtrcyes sont d]]rents.
2) SI l'on ajoutaIt la dpendance fonctIonnelle suIvante
organIsatIonnel :
noChauffeur noJour trancheHoraIre noChassIs
Avcnt un chcu]]eur pouvct condure deux vhcules le mme ]our c
lc mme trcnche horcre
Aprs l ne peut condure quun seul vhcule.
J) La dpendance fonctIonnelle cIdessous est contradIctoIre par
rapport celles de l'nonc. SI on l'acceptaIt comme lmentaIre
organIsatIonnel :
Dn ne pourrct plus quenreystrer un seul et unque plen pour un
vhcule.
0e U|L SQL 227
J4. Cles
"AIL - Mangez en beaucoup. Il rajeunit l'organisme et
loigne les importuns" (Alexandre Vialatte - Almanach des
quatre saisons)
Une cl d'une relatIon est un ensemble de constItuants (mInImum) quI
dtermIne de manIere unIque tous les autres constItuants de la relatIon. En
exprImant cecI en termes de dpendances fonctIonnelles, on peut dIre que
les constItuants d'une relatIon dpendent fonctIonnellement de sa cl (sI elle
est unIque).
0u poInt de vue de la conceptIon, la connaIssance des cls est Importante
car Il suffIt de connatre les valeurs des constItuants de la cl pour
dtermIner de faon unIque un tuple dans une relatIon et aInsI dtermIner
les autres valeurs de ses constItuants.
0fInItIon: cl de F
SoIt un schma S=(F,F).
Alors K est une cl de F sI et seulement sI K satIsfaIt les condItIons
suIvantes:
1) K F
+

2)

F
+

K
++

J) K' strIctement contenu dans K tel que F
+

K'
++

Les condItIons dfInIssant la cl s'Interpretent de la faon suIvante:
1) une cl est contenue dans les constItuants de la relatIon
2) une cl dtermIne tous les constItuants de la relatIon (les
constItuants de F sont contenus dans la saturatIon de la cl)
J) une cl est mInImale, car tous ses lments sont essentIels.
Cette dfInItIon permet de dpasser la sImple IntuItIon quI nous faIt dIre,
par exemple, que [ND| PFEND|] est une cl pour une relatIon. Nous
sommes maIntenant en mesure de tester sI effectIvement un ensemble
d'attrIbuts est une cl. Les cls sont entIerement dtermInes par les
dpendances fonctIonnelles valIdes par le schma. SI le schma a aucune
dpendance fonctIonnelle pour une relatIon F alors la cl est constItue par
F
+
luImme. Dn constate donc que les dpendances fonctIonnelles doIvent
tre attentIvement dtermInes pour que les cls soIent prcIses.
Examinons un exemple:
SoIt ((A,8,C,0,E); [A , C, 80 E]
[A0] est cl de F car
1) [A0] F
+

2)

[A0]
++
=[A,8,C,0,E] ce quI ImplIque F
+

K
++

FIgure 141 : Calcul de la saturatIon de [A0]
J) K' strIctement contenu dans K tel que F
+

K'
++
en effet
[A]
++
=[A,8,C] et [0]
++
=[0] ne dtermInent par F
Algorithme de recherche de cles
Dn peut systmatIquement tester tous les sousensembles possIbles de F
+
.
Nous obtenons alors l'algorIthme suIvant [LED88]:
Cls (R:relation,F:ensemble de df)
C
pour chaque X 2
R+
faire
si X
++
=R
+

alors C C {X} finsi
refaire
Cls min(C)
fin Cls
2
R+
-- ensemble des parties de R
+

P
P P {}
pour chaque A R
+
faire
pour chaque E P faire
P P { {}}
refaire
refaire
2
R+
P
fin 2
R+

X
++

-- saturation de X
satX X
nouveau faux
si (gauche(f) satX) (droite(f) satX)
alors satX satX droite(f)
nouveau vrai
finsi
refaire
A B C
D E
0e U|L SQL 229
refaire
X
++
satX
fin X
++

min(XYZ) -- chercher les lments minimaux
min
pour chaque X XYZ faire
minOK vrai
pour chaque Y XYZ-{X} faire
si Y X alors minOK faux finsi
refaire
si minOK alors min min {X} finsi
refaire
min(XYZ) min
fin min
Cet algorIthme est tablI dIrectement partIr de la dfInItIon de la cl. Dn
construIt de manIere explIcIte tous les sousensembles possIbles de F
+
. Pour
chacun, on teste sI la saturatIon contIent F
+
. Et fInalement, on ne conserve
que les sousensembles quI n'en contIennent aucun autre.
Le nombre d'lments tester est de 2
F+
ou F
+
est la cardInalIt de F.
20 attrIbuts nous amenent un mIllIon de cls potentIelles tester.
Attributs puits et source
En utIlIsant la notIon de source et de puIts sur un schma S=(F;F), on
dImInue le nombre d'lments de 2
F+
examIner pour chercher les cls
0fInItIon:
Une source C est constItuant de F
+

telle que
f F, C droIte(f)
Un puts C est un constItuant de F
+

tel que
f F, C gauche(f)
et C n'est pas une source (constItuant Isol)
CraphIquement, les sources sont les noeuds ou aucune arte aboutIt et les
puIts sont les noeuds ou aucune arte part.

FIgure 142 : PuIts et Source du Craphe de 0F
Les sources du schma prcdent sont [A,0] et Il possede un puIts quI est
[F].
Proposition: sur les cles, puits et sources
SoIt K l'ensemble des cls de S=(F;F)
A B C
D E
F
1) sI C est un puIts alors k K C k
Un puIts n'appartIent aucune cl
2) sI C est une source alors k K C k
Une source appartIent toutes les cls
Preuve:
Cette proposItIon nous permet d'effectuer la partItIon de F
+
en troIs partIes:
Les sources quI appartIennent toujours une cl.
Les puIts quI appartIennent aucune cl.
Les autres attrIbuts quI doIvent tre tests

FIgure 14J : PartItIon de F
+

Unicite de la cle dans les graphes de df acycliques
Un autre cas Intressant est celuI ou le graphe de df ne contIent pas de
cycles car alors la cl est unIque et gale aux sources du graphe.
0fInItIon:
Un graphe de df F est acyclIque sI
[f
1
,f
2
, ..., f
n
], n1, f
I
F tel que
1) I [1..n1] , droIte(f
I
) gauche(f
I+1
) =
2) droIte(f
n
) gauche(f
1
) =

FIgure 144 : Exemple de graphe cyclIque.
ProposItIon:
SI le graphe de dpendances est acyclIque alors Il exIste une seule cl
forme des sources
Preuve:
R+
source
puits
toujours dans
les cls
jamais
dans les cls permutation
A
B
C
1) SI C taIt pas lment d'une cl k, k ne seraIt pas mInImal car k
++
=(k[C])
++
tant
donn que C est lment d'aucune partIe gauche de df, condItIon pour apporter des
lments nouveaux dans la saturatIon d'un ensemble
2) SI C n'taIt lment d'une cl k, k ne seraIt pas une cl car C k
++
tant donn que
C est lment d'aucune partIe droIte de df, condItIon pour que C soIt dans la
saturatIon d'un ensemble
0e U|L SQL 2J1
L'exemple de la FIgure 141 est un graphe acyclIque dont la cl [A0]
constItue aussI les sources du graphe.
L'Inverse n'est pas vraI, un graphe cyclIque peut avoIr une cl unIque. Par
exemple:
Exemple:
S(A,B,C,D};A B, B C, C B, C D})

FIgure 145 : Exemple de graphe cyclIque cl unIque
Le graphe de F est cyclIque (8C).
Les sources de F sont [A]
Les puIts de F sont [0]
La cl de F est [A]
Cet exemple montre que l'on peut lImIner des cls possIbles les attrIbuts
appartenant la saturatIon des sources.
ProposItIon:
SoIt S=(F;F) et SDUFCES l'ensemble des sources du schma.
alors aucun lment de SDUFCES
++
SDUFCES appartIent une cl de F.
Preuve:
Heuristiques pour la recherche des cles
0es proposItIons prcdentes, on peut dduIre les heurIstIques suIvantes:
HeurIstIque 1: dduIte de la proposItIon sur les puIts et sources:
Dn peut lImIter la recherche des cls aux ensembles quI contIennent
que toutes les sources et quI ne contIennent aucun puIts.
HeurIstIque 2: dduIte de la proposItIon sur les graphes de df acyclIques:
7rIfIer sI le graphe de df est acyclIque; sI ouI, former la cl avec les
sources.
HeurIstIque J : dduIte de la proposItIon sur la saturatIon des sources:
Dn peut lImIner des cls les attrIbuts quI appartIennent la
saturatIon des sources.
D
C B
A
1) L'ensemble S des sources est une cl, en effet sI S n'est pas une cl cela sIgnIfIe
qu'Il exIste un constItuant X lment de la cl et pas lment de S, maIs dans ce cas X
doIt tre un noeud appartenant un cycle du graphe de df ce quI est contraIre aux
hypotheses du thoreme
2) L'unIcIt de la cl; on ne peut retIrer un lment de S car tous sont ncessaIre dans
une cl (voIr proposItIon sur les cls, puIts et sources). Dn ne peut pas ajouter un
lment la cl cause de la mInImalIt d'une cl.
L'ensemble S des sources faIt partIe de toutes les cls, ajouter un lment dj
dtermIn par la saturatIon des sources n'amene pas d'attrIbut nouveau et de plus
rend non mInImal la cl.

FIgure 146 : Nouvelle partItIon de F
+

L'applIcatIon des ces heurIstIques permet de rechercher manuellement les
cls d'un schma sur le graphe de dpendances fonctIonnelles.
Autres exemples:
Exemple 1)

FIgure 147 : Craphe de l'exemple 1
S=([A,8,C,0,E,F];[A C, C 0, 0 F, C8 E,
E F])
Le graphe de F est acyclIque.
Les sources de F sont [A,8]
La cl unIque de F est [A,8]
Exemple 2)
S=([A,8,C,0,E];[A 8, 8 C, C 0, 0 A])

FIgure 148 : Craphe de l'exemple 2
Le graphe de F est cyclIque.
Les sources de F sont [E]
Les cls de F sont [EA],[E8],[EC],[E0]
R+
source
puits
toujours dans
les cls
jamais
dans les cls permutation
source++
B E
F
D
C A
E D
C
B
A
0e U|L SQL 2JJ
Decomposition d'une relation
Nous avons examIn le cas de la cl d'un schma une seule relatIon avec un
ensemble de df alors que nous devons envIsager un ensemble de relatIons
dcomposant notre schma.
0fInItIon:
La dcomposItIon d'une relatIon F ou F
+
=[C
1
,C
2
, ..., C
n
] est un
ensemble d
F
de relatIons d
F
=[F
1
,F
2
, ..., F
n
] tel que
F
+
=F
1
+

F
2
+

... F
n
+

Les F
I
+

ne sont pas forcment dIsjoInts. Nous examInerons dans le prochaIn
chapItre les proprIts assocIes la dcomposItIon. Notre probleme actuel
est de trouver les cls de chaque lment de la dcomposItIon. l nous faut
adapter les df de F chaque relatIon FI.
0fInItIon:
La projectIon de F sur un ensemble Z de constItuants
F[Z]=[X Y F
++
XY Z]
La cl d'une relatIon de la dcomposItIon est celle du schma form par (F
I
+
;
F[F
I
+
]).
AlgorIthme pour calculer une base de F[Z] avec la base complete de F:
FZ(F,Z) -- F[Z]
FZ
pour chaque f F
+
faire
si (gauche(f) droite(f) Z)
alors FZ FZ f
finsi
refaire
FZ(F,Z) FZ
fin FZ(F,Z)
Exemple:
soIt le schma S=([A,8,C];[A 8, 8 C]) et la dcomposItIon d
F
=[A8, AC]
La base complete est [A 8, 8 C, A C]
donc nous avons les projectIons suIvantes
F[A8] = [A 8] et F[AC] = [A C]
la cl de A8 est donc A et celle de AC est aussI A.
Lxercices
Questions sur les cles
7oIcI 10 relatIons et leurs dpendances fonctIonnelles. ConstruIre le rseau
de noeuds et d'toIles de chacune d'elles et dtermIner leurs cls.
1. R1 (ABCDE)
A -~ B
B -~ C
C -~ D
D -~ E
2. R2 (ABCDEF)
A -~ B
B -~ C
C -~ D
D -~ E
3. R3 (ABCD)
A -~ C
B -~ C
C -~ D
4. R4 (ABCD)
A B-~ C
C -~ D
5. R5 (ABCD)
A -~ C
B -~ C
C -~ D
D -~ B
6. R6 (ABCDE)
AB-~ C
C -~ D
D -~ B
7 R7 (ABCD)
A -~ B
B -~ C
C -~ A
8. R8 (ABCD)
A -~ C
DC -~ A
B -~ D
AC -~ B
9. R9 (ABCD)
ABCD -~ A
10. R10 (ABCD)
aucune dependance Ionctionnelle
Questions sur 11
3

Les df de TTJ sont les suIvantes:
1) noChassIs noPlaque mIseEnServIce modele noStatIon
2) modele nbPlaces catgorIe typeCarburant automatIque poIds
J) noPlaque noJour kIlometrage lItres typeCarburant
4) noChassIs noJour descrIptIon
5) noChauffeur nom prnom adresse noStatIon
6) noChassIs noJour trancheHoraIre noChauffeur
0e U|L SQL 2J5
7) noStatIon noZone
8) noChassIs noZone
9) heure zone0e zoneA tempsParcours
Chercher pour les relatIons de la modlIsatIon les cls
7hIcule(noChassIs noPlaque mIseEnServIce modele noStatIon)
Type(modele nbPlaces catgorIe typeCarburant automatIque poIds)
Carburant(noPlaque noJour kIlometrage lItres typeCarburant)
EntretIen(noChassIs noJour descrIptIon)
Chauffeur(noChauffeur nom prnom adresse noStatIon)
PermIs(noChauffeur catgorIe)
PlannIng(noChauffeur noChassIs noJour trancheHoraIre)
StatIon(noZone noStatIon)
0Istance(heure zone0e zoneA tempsParcours)
SItuatIon(noChassIs noZone)
Reponses sur les cles

1. cl A
2. cl AF
J. cl A8
4. cl A8
5. cl A
6. cls ACE, A0E, A8E
7 cls A0, 80, C0
8. cls A, 8C, C0
9. cl A8C0
10. cl A8C0
Reponses sur 11
3
Les cls sont donnes par les constItuants soulIgns. La projectIon de F sur
les relatIons de la dcomposItIon donnent une df par relatIon (sauf pour
PermIs); la cl est donc la partIe gauche de cette df. Pour la relatIon PermIs
nous n'avons pas de df donc le tout est la cl.
7hIcule(noChassIs noPlaque mIseEnServIce modele noStatIon)
Type(modele nbPlaces catgorIe typeCarburant automatIque poIds)
Carburant(noPlaque noJour kIlometrage lItres typeCarburant)
EntretIen(noChassIs noJour descrIptIon)
Chauffeur(noChauffeur nom prnom adresse noStatIon)
PermIs(noChauffeur catgorIe)
PlannIng(noChauffeur noChassIs noJour trancheHoraIre)
StatIon(noZone noStatIon)
0Istance(heure zone0e zoneA tempsParcours)
SItuatIon(noChassIs noZone)
0e U|L SQL 2J7
JS. Decomposition d'une relation
Le logogramme dessine le mot ou la chose. Le systme
logo-syllabique devient syllabique et dcoupe le mot, parl
maintenant; il devient bientt consonantique, puis un vrai
alphabet, o les syllabes se rpartissent en lettres. Ds
lors, le dessin, sur la plage, la tablette ou le parchemin,
analyse tout autre chose que lobjet quil est cenc
dsigner. Il est le signe de signe de signe. Michel Serres -
Les origines de la gomtrie.
Fappelons qu' une dcomposItIon d'une relatIon F est un ensemble d
F
de
relatIons d
F
=[F
1
,F
2
, ..., F
n
] tel que
F
+
=F
1
+

F
2
+

... F
n
+

Nous voyons qu'Il exIste donc beaucoup de possIbIlIts pour effectuer celle
cI. Pour F=[A8C], nous avons, en excluant la possIbIlIt qu'une relatIon soIt
sousensemble d'une autre, les dcomposItIons suIvantes:
[A, 8, C]
[A8, C]
[A, 8C]
[AC, 8]
[A8, 8C]
[AC, 8C]
[A8, AC]
[A8C]
Toutes ne sont pas quIvalentes. CertaInes dcomposItIons de F jouIssent
de bonnes proprIts et cecI par rapport aux dpendances fonctIonnelles
qu'elles doIvent valIder. Ces proprIts sont exprImes par rapport:
I'InterrogatIon: la conservatIon de l'InformatIon par la dcomposItIon.
Ia modIfIcatIon: l'lImInatIon des anomalIes de mIse jour
Ies rgIes d'IntgrIt: la prservatIon des dpendances fonctIonnelles
En prenant le schma S=(A8C, [A 8, 8 C]) on peut dresser le tableau
suIvant par rapport aux dIffrentes dcomposItIons (une croIx IndIque sI elle
possede la proprIt).
Decomposition inIormation ok anomalie ok ri ok
A, B, C} X
AB, C} X
A, BC} X
AC, B} X
AB, BC} X X X
AC, BC} X
ABC} X X

Dn constate qu'une seule satIsfaIt toutes les proprIts et que la
dcomposItIon trIvIale (gale ellemme) ne pose que des problemes en
terme de mIse jour. SInon les autres ne conservent pas l'InformatIon nI ne
prservent les dpendances fonctIonnelles.
0ans la suIte de ce chapItre nous analysons la dcomposItIon et nous donnons
quelques IndIcatIons sur les processus permettant de concevoIr des
dcomposItIons ayant de bonnes proprIts.
Conservation de l'information
L'InterprtatIon du champ d'applIcatIon se faIsaIt par rapport une relatIon
F et donnaIt l'Instance IF. SI l'on projette IF sur les relatIons de la
dcomposItIon, peuton encore retrouver IF :
Nous ne nous Intressons donc qu'aux dcomposItIons ]oncbles, celles ou Il
exIste un ordre de composItIon (celuI nonc dans la donne de la
dcomposItIon) telle que la joInture naturelle donne les constItuants de F.
SoIt:
(F
1
* F
2
* ...* F
n
)
+
= F
+

SI la dcomposItIon n'est pas joInIable, cela peuttre le sIgne que deux
domaInes d'applIcatIon dIstIncts sont modlIss sImultanment (la phIlatlIe
et le vIgnoble du bordelaIs n'ont pas de raIson d'avoIr une relatIon lIant des
constItuants appartenant aux deux domaInes!). 0ornavant, nous sous
entendons toujours que la dcomposItIon est joInIable.

FIgure 151 : prservatIon de l'InformatIon
Exemple: Hotel
Hotel(NumChambre, NumClIent, Nom, Prenom, Adresse, PrIx, NbrLIt,
NbrPers, 0ateArr, 0ate0ep, Confort, EquIpement)
d
Hotel
= [
Chambres(NumChambre, PrIx, NbrLIt, NbrPers, Confort,
EquIpement),
champ
d'application
iR idRiR1,iR2,..., IRn}
interpretation
composition
projection
Equivalence d'inIormation?
0e U|L SQL 2J9
ClIents(NumClIent, Nom, Prenom, Adresse),
FservatIon(NumChambre, NumClIent, 0ateArr,
0ate0ep)]
Aton conserv l'InformatIon contenue dans hotel :
Les Instances de la dcomposItIon sont toujours gales leur projectIon sur
la relatIon dcompose
IHotel[ClIents
+
] = IClIents
IHotel[Chambres
+
] = IChambres
IHotel[FservatIons
+
] = IFservatIons
Pour la composItIon cela n'est pas toujours vraI.
IClIent* IFservatIon * IChambre = IHotel (:)
ExamInons une dcomposItIon ne prservant pas l'InformatIon
Exemple canonIque:
SoIr F(A,8,C), F=[], d
F
=[F
1
(A8),F
2
(AC)]
et les Instances suIvantes
IF
a1 b1 c1
a1 b2 c1
a1 b1 c2

IF
1

a1 b1
a1 b2

IF
2

a1 c1
a1 c2

F
1
*F
2
= F car la composItIon gnere le tuple (a1 b2 c2)
Par contre, on a F F
1
*F
2
(la dcomposItIon Invente des tuples)
Propriete de la decomposition
notatIon:
j=1..n
IF[F
j
+
] = IF[F
1
+
] * IF[F
2
+
] * ...* IF[F
j
+
]
SoIt d
F
=[F
1
,F
2
, ..., F
n
] une dcomposItIon de F alors:
a) IF
j=1..n
IF[F
j
+
]
b) (
j=1..n
IF[F
j
+
])[F
I
+
]=IF[F
I
+
] pour I=1,. ..., n

c)
l=1..n
(
j=1..n
IF[F
j
+
])[F
l
+
] =
k=1..n
IF[F
k
+
]
Le processus projectIoncomposItIon peut crer de nouvelles InformatIons.
Par contre la rptItIon de ce processus ne cre plus rIen de nouveau.

FIgure 152 : quIvalence de IF et IF'
Decomposition totale
0fInItIon
SI un schma (F;F) est dcompos dans les relatIons d
F
=[F
1
,F
2
, ..., F
n
].
Dn dIt que la dcomposItIon est totcle sI pour chaque Instance IF
valIdant F, on a
iR =
j1..n
iR|R
j
|
SI la dcomposItIon est totale, on peut alors ne plus faIre de dIffrence
entre la relatIon et sa dcomposItIon. En utIlIsant une base de donnes ou
les InformatIons sont stockes dans des tables correspondant une
dcomposItIon total d
F
, on ne perd aucune InformatIon par rapport une
seule table correspondant F et contraInte par F.
Comment tester une dcomposItIon sans passer par les Instances de la
relatIon :
1ester si une decomposition est totale
SoIt les parametres
R
+
={C
1
,C
2
, ..., C
n
}
F un ensemble de df
d
R
={R
1
,R
2
, ..., R
k
}
Total(R
+
,F,d
R
) -- Algorithme de test [ULL82]
-- initialiser un tableau t de k lignes et n colonnes
si C
j
R
i
+
alors t
ij
C
j

sinon t
ij
b
ij

changement vrai
tant que changement faire
changement faux
chercher une ligne i et une ligne j
tel que lignei[gauche(f)]=lignej[gauche(f)]
et lignei[droite(f)]lignej[droite(f)]
si trouver i et j alors
iR
iR|R1|
iR|Rn|
iR'
* projection composition
...
iR iR' (?}
0e U|L SQL 241
pour chaque C
l
droite(f) faire
-- l un indice de colonne
si t
il
=C
l
alors t
jl
C
l

sinon t
il
t
jl
changement vrai
refaire
refaire
refaire
si une ligne est remplie de C
i
alors total vrai
sinon total faux
fin total
Exemple: Hotel
Nous avons prIs les abrvIatIons suIvantes:
NCL NumClIent
N Nom
P Prenom
A Adresse
NCH NumChambre
PX PrIx
C Confort
E EquIpement
L NbrLIt
0A 0ateArr
00 0ate0ep

F=Hotel(NCL,N,P,A,NCH,PX,C,E,L,0A,00)
dF=[ F
1
=ClIents(NCL,N,P,A)
F
2
=Chambres(NCH,PX,C,E,L)
F
J
=FservatIon(NCL,NCH,0A,00)]
F=[ f
1
=NCL N,P,A
f
2
=NCH PX,C,E,L
F
J
=NCL NCH 0A 00]
En suIvant l'algorIthme on obtIent le tableau InItIal suIvant:
1 2 3 4 5 6 7 8 9

NC
L
N P A NC
H
PX C E L DA DD
R
1
NC
L
N P A b
15
b
16
b
17
b
18
b
19
b
1
b
1

R
2
b
21
b
22
b
23
b
24
NC
H
PX C E L b
2
b
2

R
3
NC
L
b
32
b
33
b
34
NC
H
b
36
b
37
b
38
b
39
DA DD

Dn cherche applIquer une df dont la partIe gauche exIste dans deux lIgnes
et dont la partIe droIte n'exIste pas dans ces deux lIgnes
avec f1 on a gauche(f
1
)=NCL et droIte(f
1
)=[N,P,A]
les lIgnes 1 et J sont gales pour NCL
la lIgne J est modIfIe selon l'algorIthme de la faon suIvante pour N,P,A:
1 2 3 4 5 6 7 8 9

NC
L
N P A NC
H
PX C E L A DD
R
1
NC
L
N P A b
15
b
16
b
17
b
18
b
19
b
1
b
1

R
2
b
21
b
22
b
23
b
24
NC
H
PX C E L b
2
b
2

R
3
NC
L
N P A NC
H
b
36
b
37
b
38
b
39
DA DD

avec f2 on a gauche(f
2
)=NCHet droIte(f
2
)=[PX,C,E,L]
les lIgnes 2 et J sont gales pour NCH
la lIgne J est modIfIe selon l'algorIthme de la faon suIvante pour PX,C,E,L:
1 2 3 4 5 6 7 8 9

NC
L
N P A NC
H
PX C E L DA DD
R
1
NC
L
N P A b
15
b
16
b
17
b
18
b
19
b
1
b
1

R
2
b
21
b
22
b
23
b
24
NC
H
PX C E L b
2
b
2

R
3
NC
L
N P A NC
H
PX C E L DA DD

La lIgne J est complete donc d
F
est totale
Cet algorIthme nous donne en plus l'ordre de joInture des relatIons. Nous
avons utIlIs les lIgnes 1 et J et ensuIte la lIgne 2. Nous avons donc
(F
1
*F
J
)*F
2.
.
En utIlIsant une base de donnes ou les InformatIons sont stockes dans des
tables correspondant une dcomposItIon totale d
F
, on ne perd aucune
InformatIon par rapport une seule table correspondant F et contraInte
par F.
En examInant l'algorIthme de plus pres, on constate que deux relatIons sont
composables sI elles possedent en commun la partIe gauche d'une df et que
la projectIon de cette df est contenue dans l'une des deux. Cette proprIt
est connue sous le nom du thoreme de dcomposItIon.
Thoreme: dcomposItIon bInaIre
SoIt d
F
=[F
1
,F
2
] une dcomposItIon de (F;F).
0e U|L SQL 24J
F
1
,F
2
est une dcomposItIon totale sI et seulement sI
(F
1
+
F
2
+
) (F
1
+
F
2
+
) F
++

ou (F
1
+
F
2
+
) (F
2
+
F
1
+
) F
++

preuve:
R
1
R
2

R
1
-R
2

R
2
-R
1

R
1
C ... C C ... C b ...b
R
2
C ... C b ...b C ... C
Ce thoreme nous permet de concevoIr un algorIthme de dcomposItIon
bInaIre quI nous permet de chercher les dcomposItIons totales d'une
relatIon. Pour cela nous utIlIsons les df du schma pour couper les relatIons
en deux.
Dcomposition_de(R,F)
DR R
nouveau vrai -- si on a trouv une dcomposition
nouveau faux
pour chaque r DR faire
-- df strictement contenue dans r
si (r
+
gauche(f) droite(f))
alors -- on substitue r les deux relations
-- formes partir de f
DR DR - r
DR DR ( gauche(f) droite(f))
DR DR ( r
+
- droite(f))
nouveau vrai
finsi
refaire
refaire
refaire
Dcomposition_de(R,F) DR
fin Dcomposition_de
En utIlIsant l'algorIthme sur HDTEL, on retrouve la dcomposItIon que l'on a
utIlIse.
astuce de la preuve: utIlIser l'algorIthme pour tester sI une dcomposItIon est
totale avec la table suIvante:
Dn voIt que la seule faon de complter la lIgne 1 ou 2 correspond bIen l'exIstence
d'une des deux df nonces dans le thoreme.

FIgure 15J : dcomposItIon de l'exemple HDTEL
Pour applIquer cet algorIthme, on part avec une base Irredondante de F.
0ans le cas ou Il exIste des cycles, Il exIstera plusIeurs dcomposItIons
possIbles car Il exIste plusIeurs bases possIbles. Le choIx de l'une ou l'autre
dpend du champ d'applIcatIon et du contexte d'utIlIsatIon.
Preservation des df
La questIon est de savoIr sI les dpendances fonctIonnelles F quI taIent
ImplIques par les Instances de IF sont toujours ImplIques par les Instances
IF
j
(et leur composItIon) de la dcomposItIon d
F
.

FIgure 154 : Les df sontelles encore la consquence logIque pour la
dcomposItIon :
0fInItIons:
La projectIon de F sur un ensemble Z de constItuants
F[Z]=[X Y F
++
XY Z]
Dn dIra que la dcomposton d
R
prserve F sI l'unIon des F[F
I
] est une
couverture de F soIt:
( F[F
I
])
++
= F
++

Dn veut pouvoIr vrIfIer que F est prserve dans les IF
j
sans devoIr recourIr
leur composItIon. Les df doIvent donc tre localement valIdes par les
Instances des relatIons de la dcomposItIon
Exemple:
7Ille = 7, Fue = F, Numro postal = N
F=(F7N)
F=[7F N, N 7]
(NCL,N,P,A,NCH,PX,C,E,L,DA,DD)
(NCL,N,P,A)
(NCL,NCH,PX,C,E,L,DA,DD)
(NCH,PX,C,E,L)
(NCL,NCH,DA,DD)
NCL -> N P A
NCH -> PX C E L
dependances
Ionctionnelles
iR idRiR1,iR2,..., IRn}
Valide
composition
projection
Equivalence des contraint es ?
0e U|L SQL 245
Cette dcomposItIon est totale
car ([7N] [FN]) ([7N] [FN])
N 7 est une df de F
SoIt les Instances suIvantes:
i(VN) i(RN)
7 N F N
Ceneve 1207 12 rue du Lac 1207
Ceneve 1205 12 rue du Lac 1205
Calculons les df projetes:
F[7N] = [N 7]
+

F[FN] = []
+

I(7N) et I(FN) satIsfont les df des F projetes. |aIs I(7N)*I(FN) ne
satIsfaIt plus F malgr la dcomposItIon totale car F7 N n'est pas
vrIfIe
I(7N)*I(FN)
7 F N
Ceneve 12 rue du Lac 1207
Ceneve 12 rue du Lac 1205

La proprIt de dcomposItIon totale et de prservatIon des df sont des
proprIts Indpendantes.
1ester la preservation des df
Soit (R;F) et d
R
R
1
,R
2
, ..., R
k
}, en theorie, il Iaut:

1) calculer F
++

2) projeter F
++
sur chaque F
I
J) unIon des F[F
I
] = C
4) calculer la fermeture de cette unIon C
++

5) tester l'galIt de F
++

et C
++

Fappelons que calculer F
++
est de complexIt exponentIelle, par exemple:
pour F=[X
0
X
1
,X
0
X
2
, ... ,X
0
X
n
]
on a X
0
2
[X0,X1,X2, ... ,Xn]

F
++

L'Ide de l'algorIthme quI suIt rsIde dans le faIt que pour XY

F sI C taIt
connu alors Il suffIraIt de tester sI Y X
++
pour C.
l reste trouver comment calculer X
++

sans calculer C. CecI est possIble en
restreIgnant la saturatIon de X la projectIon de chaque F
I
lors du calcul (on
lImIne tout ce quI dpasse!)
Algorithme: test de la prservation des df
Paramtres de Prservation (d
R
,F):
R
+
={C
1
,C
2
, ..., C
n
}
F un ensemble de df
d
R
={R
1
,R
2
, ..., R
k
}

Prservation (d
R
,F)
Z gauche(f)
tant que changement de Z faire
pour i=1 k faire
Z Z (saturation(Z R
i
+
) R
i
+
)
refaire
refaire
si droite(f) pas contenu dans Z
alors Prservation (d
R
,F) non
fin si
refaire
Prservation (d
R
,F) oui
fin prservation
exemple: test prservatIon
F=(F7N), d
F
=[F1=(7N), F2=(FN)]
F=[7F N, N 7]
les saturatIons utIlIses dans l'algorIthme sont:
7F
++
=[7FN]
N
++
=[N7]
F
++
=[F]

InItIalIsatIon
Z gauche(7F N)=7F
ItratIon avec F1
((7FFN)
++
FN)7F
=(F
++
FN)7F
=F7F
=7F
ItratIon avec F2
V
R N
R2
R1
0e U|L SQL 247
((7F7N)
++
7N)7F
=(7
++
7N)7F
=77F
=7F
Z n'a pas t modIfI
Dn a pas droIte(f)=N 7F, donc les df ne sont pas prserves
Inclusion des df dans les Ri
0ans l'exemple Hotel, la saturatIon des df (partIe gauche) peut tre
entIerement calcule l'IntrIeur d'un lment de la dcomposItIon. La
partIe gauche sera donc contenue dans la saturatIon.

FIgure 155 : Les df sont toutes contenues dans les relatIons de la
dcomposItIon
Dn peut donc noncer la proposItIon
ProposItIon:
SoIt une dcomposItIon d
F
et les df F.
SI f F, F
I
d
F
telle que gauche(f) droIte(f) F
I
alors d
F
prserve F
Llimination des anomalies de mise jour
Une anomalIe de mIse jour est mIse en vIdence dans un schma lorsque
l'excutIon d'une prImItIve de modIfIcatIon sur une relatIon pour une entIt
n'a pas l'effet dsIr. Une premIere modlIsatIon de Hotel (ChapItre J) taIt:
Htel(NumChambre, NumClient, Nom, Prenom, Adresse,
Prix, NbrLit, NbrPers, DateArr, DateDep, Confort,
Equipement)

Cette modlIsatIon accumule toutes les anomalIes de mIse jour:
lors de la cratIon d'une entIt, Il est possIble d'IntroduIre une entIt
quI respecte la dpendance InduIte par la cl de la relatIon, maIs quI
n'en valIde aucune autre.
NCL
N
P
A
DA DD
NCH
PX
C
E
L
lors de la suppressIon d'une entIt, Il est possIble que pour supprImer
un clIent, Il soIt ncessaIre de dtruIre d'autres entIts faIsant
rfrence celuIcI. 0e plus, la suppressIon d'un clIent peut aussI
entraner la suppressIon de la dfInItIon d'une chambre.
lors de la mIse jour d'une entIt, Il est possIble que pour mettre
jour une InformaIton, Il soIt ncessaIre de mettre jour d'autres
entIts faIsant rfrence cellecI .
0ans la deuxIeme modlIsatIon propose: Aucun de ces effets n'apparat:
Chambres(NumChambre, Prix, NbrLit, NbrPers, Confort,
Equipement)
Clients(NumClient, Nom, Prenom, Adresse)
lors de la cratIon d'une entIt, sI elle respecte les df InduItent par la
cl de la relatIon alors elle valIde toutes les autres df du schma.
lors de la suppressIon d'une entIt, l'objet est supprIm sans effet de
bord.
lors de la mIse jour, une seule entIt est affecte.

Les anomalIes de mIse jour sont synonymes de redondance de
l'InformatIon. 0ans les bonnes dcomposItIons, une entIt ne doIt pas
contenIr plusIeurs objets ayant des exIstences Indpendantes. L'absence de
dpendance transItIve et de dpendance partIelle traduIt cette bonne
proprIt.
Les Formes Normales remdIent (en partIe) ces anomalIes
Jer forme normale JNI
L'objectIf de la 1NF est de sImplIfIer la structure d'une relatIon en lImInant
les structures Internes
0fInIon : 1NF
Une relatIon est en 1NF sI tous les constItuants sont atomIques.
La 1NF vIte donc la confusIon entre le constItuant et la relatIon. Un
constItuant atomIque ne peut pas avoIr une structure Interne (vecteur,
enregIstrement, champ rptItIf, poInteur)
0ans un langage de programmatIon structur, nous avons pour dclarer un
fIchIer d'employs le code suIvant:
date = record of
jour : 1..31;
mois : 1..12;
anne: 1900..2100;
end;
enfant = record of
prnom: char(20);
datenaiss : date;
end;
0e U|L SQL 249
pntpersonne = ^personne;
personne = record of
nom: char(20);
sexe : (F,M);
pere: pntpersonne ;
mere: pntpersonne ;
end;
employ = record of
nom,prenom: char(20);
nbenfant: 1..12;
descriptenfant: array[1..nbenfant]
of enfant;
salaire: array [1..12] of real;
end;
var fp:file of employ;
0ans la forme 1FN, pour un SC80, toutes les structures doIvent tre
dcomposes, nous avons les troIs relatIons suIvantes quI sont quIvalentes
au fIchIer fp dclar cIdessus.
Create table personne(idpers number,
nom char(20),
prnom char(20) ,
nbenfant number )
Create table salempl(idpers number,
priode number(2),
salaire number)
Create table enfant(idpers number,
prnom char(20),
jour number(2),
mois number(2),
anne number(4))
Un autre exemple de dclaratIon en pseudopascal donne:
statistiqueTrimeste = array[1900..1999,1..4] of
real;
cI, nous avons la relatIon suIvante quI chaque trImeste assocIe une entIt.
stattrim(anne,numtrimeste,valeur)
0ans ce cas, l'anne est restItue avec une trIple joInture quI peut tre
relatIvement couteuse . SI l'InformatIon trImestrIelle n'est pas exploIte de
manIere Indpendante, on peut choIsIr la relatIon suIvante:
stattrimbis(anne,trim1,trim2,trim3,trim4)
Elle est non normalIs , maIs elle peut tre plus effIcace pour certaIns
traItements.
2eme forme normale 2NI
La 2NF lImIne les objets dcrIts d'une manIere dpendante par rapport
d'autres. Elle lImIne aInsI les anomalIes suIvantes:
Lors de la cratIon: on ne peut pas crer l'objet sans l'attacher un
autre
Lors de la suppressIon: elle entrane celle de celuI quI dpend de luI
Lors de la maj : la modIfIcatIon doIt tre reproduIte s'Il exIste
plusIeurs occurences de l'objet
0fInItIon: dpendcnce pcrtelle
SoIt F, X et K une cl de F, on dIt que X est une dpendance
partIelle de F sI X est contenu dans K et A n'est pas contenu dans X
0ans la FIgure 156, on peut voIr que le groupe de constItuants X et A dfInIt
un objet Indpendant. En dcompant F en F1 et F2, on lImIne la
dpendance transItIve ou:
F1 = F
+
A
F2 = X

FIgure 156 : schma de la dpendance partIelle
exemple de relatIon contenant une dpendance partIelle:
Rservation(Num_chambre, num_client, date_arrive,
date_dpart, prix)
NCL,NCH,DA -> DD
NCH -> PX
NCH est contenu dans la cl de Rservation qui est
NCL,NCH,DA
0fInIon : 2NF
Une relatIon en 1NF est en 2NF s'Il n'exIste pas de dpendance partIelle
Exemple: soIt les deux relatIons suIvantes et leurs df
Commande(NoCom, NoClient, Nom, Adresse, PrixTotal)
Ligne(NoCom, NoArt, Prix, Qte, Art_total)
NoCom PrixTotal, NoClient
NoClient Nom, Adresse
NoArt Prix
NoCom, NoArt Qte
Nous avons ycuche(NoArt Prx ) cl(Lyne) donc LIgne n'est pas en 2FN
R
A X K
0e U|L SQL 251
Pour transformer le schma en 2NF Il convIent de le rcrIre comme suIt:
LigneCommande (NoCom, NoArt, Qte, Art_total)
Article (NoArt, Prix)
3eme forme normale 3NI
La JNF lImIne aussI les objets dcrIts d'une manIere dpendante par
rapport d'autres.0ans ce cas, la dpendance est transItIve.
0fInItIon: dpendance transItIve
SoIt F, X et K une cl de F, on dIt que X est une dpendance
transItIve de F sI X n'est pas contenu dans K et A n'est pas contenu dans
X
0ans la FIgure 157, on peut voIr que le groupe de constItuants X et A dfInIt
un objet Indpendant. En dcomposant F en F1 et F2, on lImIne la
dpendance transItIve ou:
F1 = F
+
A
F2 = X

FIgure 157 : schma de la dpendance transItIve
Exemple de relatIon contenant une dpendance transItIve
gographie(Ville, Pays, Superficie)
Ville Pays
Pays Superficie est une df transitive
0fInIon : JNF
Une relatIon en 2NF est en JNF s'Il n'exIste pas de dpendance transItIve
Exemple: soIt les troIs relatIons suIvantes et leurs df
NoClient Nom, Adresse (1)
NoArt Prix
NoCom, NoArt Qte
Nous avons gauche(NoClIent Nom, Adresse ) quI n'est pas contenu dans la
cl(Commande) donc Commande n'est pas en JFN
R
A X K
Pour transformer le schma en JNF Il convIent de le rcrIre comme suIt:
Commande(NoCom, NoClient, PrixTotal)
Client (NoClient, Nom, Adresse)
Iorme normale Boyce-Codd (BCIN)
0ans cette forme normale toutes les partIes gauches des df d'une relatIon
contIenne une cl
0fInItIon 8CFN
Dn dIt que le schma (F;F) est en 8CFN sI pour X une dpendance
valIder sur F telle que A n'est pas contenu dans X alors on a K une cl de
F contenue dans X.
Exemple de relatIon quI n'est pas en 8CNF:
R=(RVN)
F={VR N, N V}
F n'est pas en 8CFN, car N 7 est valIder et N ne contIent pas de cl (cl
de F est 7F)
La 8CFN est une forme (trop) contraIgnante car on ne peut pas toujours
trouver pour F et F une dcomposItIon dont les schmas ont sImultanment
les proprIts de 8CFN, de dcomposItIon totale et de prservatIon des df.
Exemple: soIt les relatIons suIvantes et leurs df
Commande(NoCom, NoClient, PrixTotal)
Client (NoClient, Nom, Adresse)
NoClient Nom, Adresse
NoArt Prix
NoCom, NoArt Qte
La dcomposItIon est en 8CNF
Cependant en ajoutant
prix , Qte Art_total
0ans les df projetes sur LIgneCommande , on a la df:
NoArt, Qte Art_total
dont la partIe gauche NoArt, Qte ne contIent pas de cl de
LIgneCommande , donc LIgneCommande n'est pas en 8CNF
A l'extreme LIgneCommande doIt tre dcompose en
LigneCommande (NoCom, NoArt, Qte)
0e U|L SQL 25J
Table_multiplication(Prix, Qte, Art_total)
Nous verrons dans le chapItre suIvant que les vues permettent d'vIter une
telle extrmIt; la df prIx , Qte Art_total exprIme en faIt une dpendance
de calcul.
La 3IN une relaxation de la BCIN
Une dfInItIon quIvalente de la JFN permet de voIr que la JFN est une
relaxatIon de la 8CFN.
0fInItIon: constItuant premIer
Nous dIrons qu'un constItuant C est premIer s'Il appartIent une cl
sInon Il est nonpremIer.
0fInItIon 2 : JFN
Dn dIt que le schma (F;F) est en JFN sI pour X une dpendance
valIder sur F telle que A n'est pas contenu dans X alors on vrIfIe une
des deux condItIons suIvantes:
1) Il exIste K une cl de F contenu dans X
2) A est premIer
La condItIon 1 est IdentIque celle de la 8CFN. La JFN est donc bIen une
relaxatIon des contraIntes JFN. 0onc toutes les relatIons 8CFN sont en JFN
JFN.
FIgure 158 : mbrIcatIons des formes normales
Les moyens de ne pas tre en JFN sont donc:
La 1FN: spcIfIe qu'un constItuant ne soIt pas un schma F
la 2FN: X est un sousensemble strIct d'une cl
on dIt que X A est une dpendance partIelle
la JFN: X est sous ensemble d'aucune cl
on dIt que X A est une dpendance transItIve
Sans entrer dans les dtaIls, nous dIrons qu'Il exIste toujours une
dcomposItIon (ou plusIeurs sI le graphe des df a des cycles) quI possede
sImultanment les troIs proprIts que nous avons examInes (totale,
prserve les df et JFN). Par contre, le trIplet (total, prserve les df et 8CFN)
peut tre vIde.
Notre objectIf n'tant pas de faIre de la conceptIon, nous ne donnons pas
d'exercIce sur la dcomposItIon. ToutefoIs le lecteur peut constater que
pratIquement toutes les modlIsatIons des tudes de cas sont en JFN et
possedent les bonnes proprIts de la dcomposItIon totale et de la
1FN
2FN
3FN
plus constituantrelation
plus de dI partielle
plus de dI transitive
prservatIon des dpendances fonctIonnelles (quand cela n'est pas le cas,
une questIon y faIt rfrence).

FIgure 159 : nterdpendances des proprIts sur la dcompsItIon
Decomposition
Totale
Preservation
des DF
3FN
BCFN
toujours
non-vide
peut tre
vide
0e U|L SQL 255
J6. Vues
"Le rve semblait toujours si vivant, si exact, moins
distorsion du rel que simulacre, illusion si riche en dtails
de la vie veill que Nashe ne souponnait jamais qu'il tait
en train de rver." Paul Auster - La musique du hasard
Jusqu' prsent, une relatIon taIt toujours assocIe une Instance quI
stockaIt physIquement les entIts. Une vue permet de dclarer un schma de
relatIons quI est dfInI partIr d'autres relatIons (ou ventuellement d'autres
vues). L'Instance d'une vue est value au moment ou elle est utIlIse dans
une requte; une vue ne possede donc pas d'Instance physIque.
CecI permet de crer des redondances logIques dans le schma sans InduIre
pour autant des anomalIes de mIse jour. Par contre, une vue devant tre
rvalue chaque foIs que l'on s'y rfere, cela peut entraner une
dImInutIon de performance dans certaIns cas.

FIgure 161 : FcIture de la requte SQL
Le modele d'excutIon d'une requte SQL doIt tre complt, par un module
de rcrIture de la requte quI substItue lexIcalement les termes de la
requte par ceux de la vue (parfoIs, c'est l'Inverse quI est pratIqu). Au
mInImum, nous avons les substItutIons suIvantes:
a) l'IdentIfIcateur de la vue dans la clause FROM de la requte est
substItu par les IdentIfIcateurs spcIfIs dans la clause FROM de la
vue.
b) les colonnes de la vue sont substItues par les expressIons
spcIfIes dans la clause SELECT de la vue.
c) la clause WHERE de la vue est ajoute la clause WHERE de la
requte.
d) 0ans les cas les plus sImples, la clause GROUP BY de la vue est
ajoute la requte (ce type de cas est problmatIque comme on le
verra plus loIn).
ExamInons un cas, soIt la vue et la requte suIvante:
requte
Rcriture de la requte en
termes de relation
Modle de la machine SQL figure 4 chapitre 5
Dfinitions des vues
CREATE VIEW Chambre_avec_tv_2
(Num_chambre, prix_par_pers)
AS SELECT num_chambre,prix/nbr_pers
FROM Chambres
WHERE equipement='TV';
SELECT num_chambre, prix_par_pers
FROM Chambre_avec_tv_2
WHERE num_chambre=44;
L'applIcatIon de la regle a) donne:
SELECT num_chambre, prix_par_pers
FROM Chambres
L'applIcatIon de la regle b) donne:
SELECT num_chambre, prix/nbr_pers
FROM Chambres
L'applIcatIon de la regle c) donne:
SELECT num_chambre, prix/nbr_pers
FROM Chambres
WHERE num_chambre=44
AND equipement='TV';
C'est la requte que nous aurIons crIt sI la vue n'exIstaIt pas.
Vues en SQL
La clause CREATE-VIEW permet d'assocIer un schma de vue une requte.
CFEATE7EW

Par dfaut, le schma de la vue est celuI de la requte. Les noms et les
types des colonnes sont ceux quI apparaIssent dans la clause de projectIon
de la requte.
Exemple: Une vue dfInIe pour les chambres ayant une T7 :
AS SELECT *
FROM Chambres
En Interrogeant la vue on obtIent:
SELECT * FROM Chambre_avec_tv_1;
l est aussI possIble de donner un nom chaque colonne de la vue en les
mentIonnant apres le nom de la vue.
0e U|L SQL 257
(Num_chambre, prix_par_pers)
AS SELECT num_chambre,prix/nbr_pers
FROM Chambres
En Interrogeant la vue on obtIent:
SELECT * FROM Chambre_avec_tv_2;
0ans l'exemple suIvant, on cre une vue quI correspond l'agrgatIon des
prIx moyens.
CREATE VIEW Prix_moyen_par_confort
(confort, prix_moyen)
AS SELECT confort, avg(prix)
FROM Chambres
GROUP BY confort;
SELECT * FROM Prix_moyen_par_confort;
Normalement l'ImplmentatIon des vues consIste en une rcrIture de la
requte utIlIsant la vue, donc les deux requtes suIvantes devraIent tre
Illgales, comme le soulIgne C.J. 0ate [0AT87]. Cependant le SC80 Dracle
(que l'on utIlIse pour tester les requtes de ce lIvre) les accepte. CecI
s'explIque par le faIt que pour ces cas, Il cre temporaIrement une table
correspondant la vue.
Cette partIcularIt est premIere vue tres pratIque, maIs dans certaIns cas
elle peut pnalIser fortement la performance de l'excutIon. Surtout dans le
cas de joInture sur une vue agrge car les optImIsatIons quI peuvent
normalement s'effectuer ne sont plus possIbles et le systeme doIt valuer et
stocker temporaIrement la vue chaque appel.
SELECT * FROM Prix_moyen_par_confort
WHERE prix_moyen>100;
13

SELECT avg(prix_moyen) FROM Prix_moyen_par_confort;
14

Les modIfIcatIons travers une vue sont restreIntes aux vues quI n'utIlIsent
pas les opratIons suIvantes:
La joInture
Les agrgatIons (GROUP BY)
Les connexIons (connect by)
La clause distinct
0ans le cas de colonnes rsultats d'expressIon, ces dernIeres ne peuvent pas
tre mIses jour. Tous ces cas sont IndtermIns, car Il correspondent la
modIfIcatIon , partIr d'une valeur, de plusIeurs ranges ou de plusIeurs
colonnes d'une table. SI une colonne est absente dans la table de rfrence
alors elle prend la valeur null.

1J
La rcrIture devraIt donner where avg(prix)>100, ce quI est InterdIt car on doIt
utIlIser la clause having
14
cI on devraIt avoIr avg(avg(prix)), ce quI n'a pas de sens.
La clause with check option permet de spcIfIer que les modIfIcatIons
sont faItes l'IntrIeur de l'Instance de la vue. C'est dIre qu'une slectIon
travers la vue doIt pouvoIr slectIonner le rsultat de la modIfIcatIon (Dn
peut donner un nom cette contraInte).
Exemple: la mIse jour de la colonne quIpement faIt sortIr la range du
l'Instance de la vue.
insert into Chambre_avec_tv_1
(num_chambre,prix,nbr_lits,
nbr_pers,confort,equipement)
values(99,100,2,2,'BAIN','TV');
update Chambre_avec_tv_1
set equipement='VD'
delete FROM Chambre_avec_tv_1;
Crons une vue sImIlaIre avec la clause de vrIfIcatIon d'appartenance la
vue et soumettons les mmes modIfIcatIons.
CREATE VIEW Chambre_avec_tv_1_valide
AS SELECT *
FROM Chambres
WHERE equipement='TV'
with check option constraint valide_la_vue;
insert into Chambre_avec_tv_1_valide
(num_chambre,prix,nbr_lits,
nbr_pers,confort,equipement)
values(99,100,2,2,'BAIN','TV');
update Chambre_avec_tv_1_valide
set equipement='VD'
delete FROM Chambre_avec_tv_1_valide;
L'execution de la mise a jour a ete rejetee car elle viole notre contrainte d'integrite.
Multiplier les representations logiques
Nous donnons un certaIn nombre de cas ou les vues sont utIles. L'Ide central
tant de crer une Indpendance logIque entre le schma de la base de
donnes et les applIcatIons quI l'utIlIsent. CellecI n'est pleInement ralIse
que dans le cas de l'InterrogatIon et dans un nombre de cas lImIts de
modIfIcatIon de la base.
Creer des vues contextuelles
La cratIon des vues contextuelles permet de construIre partIr d'un
ensemble de relatIons, une nouvelle relatIon. L'utIlIsateur en utIlIsant le
contexte devIent alors Indpendant des modIfIcatIons quI peuvent tre
apportes au schma sousjacent.
0e U|L SQL 259
0ans l'exemple suIvant, on cre la vue sur la relatIon unIverselle. (Elle n'est
pas quIvalente la relatIon unIverselle car elle ne prend en compte que les
entIts quI sont joIntes. Pour une dIscussIon approfondIe sur ce theme
consulter le travaIl de C. Falquet [FAL89])
CREATE VIEW hotel
(NUM_CLIENT, NOM, PRENOM, ADRESSE,
NUM_CHAMBRE, PRIX, NBR_LITS,
NBR_PERS, CONFORT, EQUIPEMENT,
DATE_ARR, DATE_DEP)
AS SELECT CLIENTS.NUM_CLIENT, NOM, PRENOM, ADRESSE,
CHAMBRES.NUM_CHAMBRE, PRIX, NBR_LITS,
NBR_PERS, CONFORT, EQUIPEMENT,
DATE_ARR, DATE_DEP
La vue hotel permet un utIlIsateur de faIre abstractIon des schmas
CHA|8FES, CLENTS, FESEF7ATDNS. Ces dernIers peuvent tre modIfIs. l
suffIt de maIntenIr une vue quIvalente pour satIsfaIre l'utIlIsateur de la vue.
Interfacer un schema
Supposons que vous ayez achet une applIcatIon 80, cellecI possede dj un
schma de relatIons. La socIt quI l'a dvelopp est susceptIble de le
modIfIer. Cependant vous aImerIez dvelopper une extensIon. Pour tre
Indpendant, Il suffIt de travaIller sur des vues du schma de l'applIcatIon.
En cas de modIfIcatIon, vous adaptez vos vues afIn de les rendre
smantIquement quIvalentes. CecI permet aussI de crer un schma traduIt
dans une autre langue peu de fraIs.
exemple: Une chane anglaIse d'hotels tend notre applIcatIon HDTEL. Elle
aura Intrt travaIller sur la vue ClIents suIvante:
CREATE VIEW Customer
(ident_cust, name, surname, address)
AS SELECT NUM_CLIENT, NOM, PRENOM, ADRESSE
FROM Clients
Creer des dependances calculees
Souvent la valeur d'un constItuant est entIerement dtermIne par de
l'InformatIon quI exIste dj dans la base de donnes. Stocker physIquement
ces InformatIons demande qu' chaque modIfIcatIon elles soIent remIses
jour, ce quI rend plus complexe les programmes de modIfIcatIon.
ExamInons le cas suIvant:
Un clIent a un nom et une adresse. Une commande est assocIe un clIent
et le prIx total de la commande est la somme des lIgnes de cette commande.
Une lIgne de commande correspond un artIcle command selon une
certaIne quantIt. Le prIx total de la lIgne correspond au produIt du prIx de
l'artIcle par sa quantIt. A chaque artIcle est assocI un prIx.
Ce champ est soumIs aux dpendances fonctIonnelles suIvantes:
NoCom PrIxTotal, NoClIent
NoClIent Nom, Adresse
NoArt PrIx
NoCom, NoArt Qte
La dcomposItIon suIvante est tout faIt admIssIble:
ClIent (NoClIent, Nom, Adresse)
Commande(NoCom, NoClIent, PrIxTotal)
LIgneCommande (NoCom, NoArt, Qte, Art_total)
ArtIcle (NoArt, PrIx)
Le faIt de stocker PrIxTotal et Art_total ImplIque que les programmes de
l'applIcatIon modIfIant les lIgnes de commandes et les artIcles doIvent les
remettre jour.
Formellement on devraIt ajouter la dpendance fonctIonnelle suIvante (quI
encode la multIplIcatIon)
prIx , Qte Art_total
Dn a alors les relatIons suIvantes:
LIgneCommande (NoCom, NoArt, Qte)
CalculPrIx (PrIx, Qte, Art_total)
Les vues permettent d'vIter de telles extrmIts
Supposons le schma suIvant :
ClIent (NoClIent, Nom, Adresse)
Commande(NoCom, NoClIent)
LIgneCommande (NoCom, NoArt, Qte)
ArtIcle (NoArt, PrIx)
CREATE VIEW
LigneCommAvecPrix(NoCom, NoArt, Qte, Art_total)
AS SELECT Nocom, a.NoArt, Qte, Prix*Qte
FROM lignecommande a, article b
WHERE a.NoArt=b.NoArt
CREATE VIEW
CommAvecPrix (NoCom, NoClient, PrixTotal)
AS SELECT b.Nocom, NoClient, sum(Art_total)
FROM lignecommande a, Commande b
WHERE a.NoCom=b.NoCom
GROUP BY b.Nocom, NoClient
Dn a lImIn les constItuants calculs des relatIons stockes. Par contre, on
a spcIfI des vues quI permettent tout moment de les recalculer.
Nous retrouvons la dualIt de la redondance contre l'valuatIon, l'une avec
son cout en complexIt accrue de programmatIon (la place physIque n'tant
0e U|L SQL 261
plus gnralement l'argument prIncIpal) contre un cout en ressource de
calcul (dIrectement lI la performance)
Deduire de l'information
A partIr d'un ensemble de faIts et d'un ensemble de regles de dductIon, Il
est possIble de produIre de nouvelles InformatIons. La programmatIon
logIque, exprIme formellement par les clauses de Horn (voIr l'ouvrage de F.
KowalskI [KDW79]), permet de dfInIr de telles regles de dductIon. Le
langage de programmatIon PFDLDC [CLD81] est une ImplmentatIon de
cette approche dductIve. Les bases de donnes relatIonnelles peuvent tre
consIdres comme un cas partIculIer de la programmatIon logIque. Les faIts
sont reprsents par les entIts et les requtes sont des clauses logIques
dont les rponses sont des InterprtatIons possIbles. 0ans ce contexte, les
vues peuvent tre perues comme des regles de dductIon (la lImIte tant
que l'on ne peut pas exprImer des regles rcursIvement)
ExamInons l'exemple classIque de l'arbre gnalogIque. SoIt les deux
relatIons suIvantes. Les personnes sont IdentIfIes par un nom et assocIes
un sexe. La relatIon CEN dtermIne que le parent est un des gnIteurs de
l'enfant.
CREATE TABLE pers(nom char(20),
sexe char(1));
CREATE TABLE geni(parent char(20),
enfant char(20));
Nous avons entr les donnes suivantes:
A partIr de ces donnes, nous aImerIons poser les questIons:
quI est la soeur de ... :
quI sont les grandparents ... :
quI est le cousIn de ... :
quI est l'anctre de ... :
Les vues suIvantes rpondent ces questIons:
CREATE VIEW femme
AS SELECT nom
FROM pers
WHERE sexe='F';
CREATE VIEW homme
AS SELECT nom
FROM pers
WHERE sexe='H';
CREATE VIEW pere_de
AS SELECT parent pere
15
,enfant
FROM geni,homme
WHERE geni.parent=homme.nom;

15
L'utIlIsatIon d'un alIas permet de renommer la colonne de la vue
CREATE VIEW mere_de
AS SELECT parent mere,enfant
FROM geni,femme
WHERE geni.parent=femme.nom;
CREATE VIEW soeur_de
16

AS SELECT a.enfant soeur,b.enfant nom
FROM geni a,geni b,femme
WHERE a.parent=b.parent
AND a.enfant=femme.nom
AND a.enfant<>b.enfant
17
;
CREATE VIEW frere_de
AS SELECT a.enfant frere,b.enfant nom
FROM geni a,geni b,homme
WHERE a.parent=b.parent
AND a.enfant=homme.nom
AND a.enfant<>b.enfant;
CREATE VIEW grandpere_de
AS SELECT a.pere grandpere,b.enfant petitenfant
FROM pere_de a,geni
18
b
WHERE a.enfant=b.parent;
CREATE VIEW grandmere_de
AS SELECT a.mere grandmere,b.enfant petitenfant
FROM mere_de a,geni b
WHERE a.enfant=b.parent;
CREATE VIEW grandparent_de(grandparent, petitenfant)
AS SELECT grandpere, petitenfant
FROM grandpere_de
union
SELECT grandmere, petitenfant
FROM grandmere_de;
Nous pouvons faire un test sur nos donnes.
SELECT distinct * FROM soeur_de
WHERE nom='jacques';
SELECT distinct * FROM grandparent_de
WHERE petitenfant='amlie';
La questIon des anctres est plus dlIcate car elle faIt IntervenIr la notIon de
rcursIvIt. C'est dIre:
X anctre de Z sI
1)X est le gnIteur de Z
ou bIen 2) sI X est anctre de Y et Y est le gnIteur de Z
Dn constate que l'on peut applIquer nouveau la dfInItIon d'anctre dans la
condItIon 2). En toute gnralIt, Il n'est pas possIble de crer des vues

16
AussI les demIsoeurs
17
Cette condItIon InterdIt que l'on soIt la soeur de soImme.
18
En remplaant CEN par PEFE_0E, on a le grand pere parternel
0e U|L SQL 26J
rcursIves. Au plus, on peut dplIer la dfInItIon et crer une vue de
gnIteur(gnIteur(gnIteur( ....)))) en joIgnant plusIeurs foIs la relatIon
CEN. Cependant, l'extensIon CDNNECT 8Y au standard SQL permet de rendre
rcursIves certaInes requtes.
La sousrequte de la vue ancetre_de calcule les descendants de A. La
dfInItIon d'anctre devIent alors: A est anctre de 8 sI 8 est dans les
descendants de A.
CREATE VIEW ancetre_de
AS SELECT a.nom ancetre,b.nom descendant
FROM pers a, pers b
WHERE b.nom in (SELECT enfant FROM geni
connect by prior enfant=parent
start with parent=a.nom);
SELECT * FROM ancetre_de
WHERE descendant='amlie';
Pour termIner cet exemple on peut se poser la questIon de savoIr sI deux
personnes ont des anctres communs.
CREATE VIEW meme_famille(dans_la, de)
AS SELECT a.descendant,b.descendant
FROM ancetre_de a, ancetre_de b
WHERE a.ancetre=b.ancetre;
SELECT * FROM meme_famille
WHERE dans_la='amlie' AND de='eliot';
SELECT * FROM meme_famille
WHERE dans_la='amlie' AND de='nolwenn';
Le nombre de rponses correspond aux sIx anctres communs.
Nous voyons que l'IntroductIon des vues dpasse le cadre de la
reprsentatIon des donnes. Elles permettent de construIre, au dessus des
faIts, des regles structures sur les lIens smatIques exIstant entre ces faIts
et aInsI de dduIre de nouvelles InformatIons.
Lxercices
Les deux exercices suivants sont destines a montrer la puissance des vues.
Le jeu des trois des

Soit le de modelise de la Iaon suivante:
CREATE TABLE D (v number(1));
insert into D values(1);
A partir de cette unique table creer des vues et des requtes aIin de:
crer troIs ds Indpendants
chercher la somme pour un jet de J ds
le nombre de jets de J ds possIbles
les dIffrentes faons d'obtenIr 7 avec troIs ds
le nombre de possIbIts de jets de troIs ds assocIs chaque
somme
dresser un tableau en terme de statIstIque pour chaque somme
Produit scalaire et le produit matriciel
l est Intressant de remarquer qu'une relatIon peut facIlement reprsenter
un vecteur. La relatIon 7ect donne chaque lment le nom du vecteur
auquel Il appartIent, sa posItIon et sa valeur
CREATE TABLE vect(nomvect char(10),
i number(3),
value number);
AInsI les vecteurs 7=(1,2,4) et W=(1,0.5,0.25) sont reprsents par l'Instance
7ECT suIvante:
Le produIt scalaIre de deux vecteurs est gal la somme des produIts de
chaque lment des deux vecteurs occupant la mme posItIon.
Dn a donc 7*W=(1*1+2*.5+4*.25)=J
et 7*7=(1*1+2*2+4*4)=21
Chercher une vue quI calcule tous les produIts scalaIres de 7ect
(normalement les deux vecteurs doIvent avoIr la mme longeur)
Une matrIce correspond un tableau de valeurs, on peut tendre notre
dfInItIon de 7ECT la relatIon |AT quI dfInIt le nom de la matrIce, la
lIgne, la colonne et la valeur pour chaque lment.
CREATE TABLE mat(nommat char(10),
l number(3),c number(4),
value number);
Les deux matrIces A et 8 sont donc reprsentes par l'Instance suIvante de
|AT.
1 2 B 1 2 3
A 2 4 1 2 3
3 6
Le produIt de deux matrIces donne une nouvelle matrIce dont chaque
lment correspond au produIt scalaIre d'une lIgne et d'une colonne des
matrIces multIplIes. AInsI A*8 donnera pour l'lment 1,1 du rsultat le
produIt scalaIre de la lIgne 1 de A et de la colonne 1 de 8 soIt J l'lment 1,2
du rsultat est le produIt scalaIre de la lIgne 1 de A et de la colonne 2 de 8
soIt 6, etc.
3 6 9
A * B 6 12 18
9 18 27
0e U|L SQL 265
EcrIre une vue quI effectue le produIt matrIcIel de toutes les matrIces de
|AT (normalement le nombre de colonnes de la premIere matrIce doIt tre
gale au nombre de lIgnes de la deuxIeme matrIce)
Sur 113
EtablIr une vue quI permette de rpondre aux questIons suIvantes,par des
requtes sans de joInture .
lIste des vhIcules et leur catgorIe de permIs
lIste des vhIcules de moIns de 20 places
lIste des vhIcules ayant entre 5 et 8 places
Etendre la vue prcdente pour tenIr compte de la relatIon carburant.
l doIt maIntenant tre facIle de donner la consommatIon par modele, par
catgorIe, par nbr de place.
EtablIr une vue quI regroupe ces statIstIques.
0onner les groupes quI consomment moIns de 10 lItres aux 100.
Reponses
Le jeu des troIs ds
crer troIs ds Indpendants
CREATE VIEW D1
AS SELECT * FROM D;
CREATE VIEW D2
AS SELECT * FROM D;
CREATE VIEW D3
AS SELECT * FROM D;
chercher la somme pour un jet de J ds
CREATE VIEW sum3D (v1,v2,v3,sum3)
AS SELECT D1.v,D2.v,D3.v,D1.v+D2.v+D3.v
FROM D1,D2,D3;
le nombre de jets de J ds possIbles
SELECT count(*)
FROM sum3D;
les dIffrentes faons d'obtenIr 7 avec troIs ds
SELECT * FROM
sum3D
WHERE sum3=7;
le nombre de possIbIts assocIes chaque somme
SELECT sum3,count(sum3)
FROM sum3D
GROUP BY sum3;
dresser un tableau en terme de statIstIque pour chaque somme
SELECT sum3 somme,
(count(sum3)/216)*100 probabilite,'%'
FROM sum3D
GROUP BY sum3;
Les vecteurs et les matrIces
La condItIon de joInture porte sur la posItIon dans le vecteur.
CREATE VIEW prod_scalaire(a,b,prod)
AS SELECT a.nomvect,b.nomvect,sum(a.value*b.value)
FROM vect a,vect b
WHERE a.i=b.i
GROUP BY a.nomvect,b.nomvect;
SELECT * FROM prod_scalaire;
La vue prod_scalaIre calcule l'lment (l,c) du rsultat, la condItIon de
joInture porte sur la posItIon dans la lIgne l et la colonne c.
CREATE VIEW prod_scalaire_LC(a,b,l,c,prod)
AS SELECT a.nommat,b.nommat,a.l,b.c,sum(a.value*b.value)
FROM mat a,mat b
WHERE a.c=b.l
GROUP BY a.nommat,b.nommat,a.l,b.c;
Le produIt matrIcIel est l'ensemble possIble des valeurs des produIts
scalaIres. Nous avons ajout la condItIon quI empeche de donner le rsultat
pour des matrIces noncompatIbles
CREATE VIEW prod_mat(a,b,l,c,value)
AS SELECT a,b,l,c,prod
FROM prod_scalaire_lc
WHERE exists (SELECT 'vrai'
FROM mat a, mat b
WHERE a.nommat=a AND b.nommat=b
GROUP BY a.nommat, b.nommat
having max(a.c)=max(b.l));
Seules A * 8 et 8*A sont possIbles
SELECT * FROM prod_mat;
sur TT3
CREATE VIEW vhc_type
AS SELECT nochassis,noplaque,miseenservice,v.modele,nostation,
nbplaces,categorie,typecarburant,automatique,poids
FROM vehicule v, type t
WHERE v.modele=t.modele;
SELECT nochassis,categorie
FROM vhc_type;
FROM vhc_type
WHERE nbplaces<20;
FROM vhc_type
WHERE nbplaces between 5 AND 8;
0e U|L SQL 267
CREATE VIEW vhc_type_carb
AS SELECT nochassis,v.noplaque,miseenservice,
v.modele,nostation,
nbplaces,categorie,v.typecarburant
carburantrequis,automatique,poids,
nojour,kilometrage,litres,
c.typecarburant carburantplein
FROM vhc_type v, carburant c
WHERE v.noplaque=c.noplaque;
SELECT * FROM vhc_type_carb
WHERE carburantrequis<>carburantplein;
CREATE VIEW analyse_consomation
(critere,valeur,consom100)
AS SELECT 'modele',
modele,(sum(litres)/sum(kilometrage))*100
FROM vhc_type_carb
GROUP BY modele
union
SELECT 'nbplaces',
to_char(nbplaces),(sum(litres)/sum(kilometrage))*100
FROM vhc_type_carb
GROUP BY to_char(nbplaces)
union
SELECT 'carburant',
carburantplein,(sum(litres)/sum(kilometrage))*100
FROM vhc_type_carb
GROUP BY carburantplein;
SELECT *
FROM analyse_consomation;
SELECT *
FROM analyse_consomation
WHERE consom100<10;
0e U|L SQL 269
J7. Optimisation et performance
"Ainsi certaines fourmis naissent avec d'normes
mandibules cisaillles pour tre soldat, d'autres possdent
des mandibules broyantes pour produire de la farine de
crales, d'autres sont quipes de glandes salivaires
surdveloppes pour mouiller et dsinfecter les jeunes
larves." Bernard Weber - Les fourmis.
La premIere partIe de ce chapItre est consacre l'optImIsatIon des requtes
SQL. Jusqu' prsent, nous avons faIt abstractIon de l'ImplmentatIon
physIque des relatIons et nous avons dcrIt le fonctIonnement de la machIne
SQL en termes purement logIques. Les Instances des relatIons dans un SC80
sont stockes physIquement; au schma logIque des relatIons est assocI un
schma physIque. Ce dernIer spcIfIe pour chaque relatIon le modele
physIque et les parametres de stockage utIlIss.
La rIchesse des modeles utIlIss dpend du constructeur du SC80. Le choIx
du schma physIque dpend alors de l'utIlIsatIon de la base de donnes. Pour
que les requtes SQL restent logIquement Indpendantes du schma
physIque, le SC80 est munI d'un optmseur de requtes quI traduIt la
requte SQL en une squence d'actIons la plus approprIe au schma
physIque exIstant. Une mme requte a donc une traductIon dIrectement
dpendante du schma physIque. L'optImIseur utIlIse les InformatIons du
dIctIonnaIre et les proprIts thorIques pour effectuer sa traductIon.
0ans la deuxIeme partIe ce chapItre, nous traItons des pIeges de la
normalIsatIon et de l'utIlIsatIon gnralIse des vues. Nous montrons que
l'approche gnralement prconIse consIstant :
analyser les donnes et concevoIr le schma
tablIr des vues pour facIlIter la programmatIon des traItements
choIsIr un schma physIque de stockage (placer judIcIeusement des
Index)
peut mener des systemes ayant de mauvaIses performances. CecI montre
que des solutIons localement Idales peuvent mener une solutIon
globalement InsatIsfaIsante.
AfIn d'vIter cecI, Il faut que les contraIntes de performance, d'acces aux
donnes et la spcIfIcatIon des traItements usuels et frquents soIent
consIdrs en parallele avec la conceptIon des donnes. Nous prconIsons
donc une approche quI ne prIvIlgIe pas les donnes aux dpends des
traItements.
Optimisation des requtes SQL
L'optImIseur utIlIse d'une part les proprIts de l'algebre relatIonnelle et
d'autre part les structures de donnes accompagnant les tables mmorIses.

FIgure 171 : DptImIsatIon des requtes SQL
Les proprIts de l'algebre relatIonnelle nous donnent des regles de
rcrIture ou des quIvalences entre expressIons. Ces quIvalences sont
utIlIses pour lImIner les nuplets quI ne satIsferont pas le prdIcat de la
requte. Par exemple, sI un prdIcat de slectIon ne faIt IntervenIr qu'une
relatIon, alors on a l'quIvalence suIvante:
(*
F
F1
F
F2
...
F
Fn
) (F
1

F
2
...F
n
) + (*
F
F1
F
1
)

(*
F
F2
F
2
) ...(*
F
Fn
F
n
)
En utIlIsant cette quIvalence, on voIt qu'Il est possIble de dplacer le
produIt cartsIen apres les slectIons sur les relatIons. En procdant aInsI, on
lImIne un trs grand nombre de nuplets quI n'auraIent pas satIsfaIt le
prdIcat. magInons que nous ayons 1000 clIents, 1000 rservatIons et 100
chambres dans notre hotel. La requte suIvante, produIraIt 100'000'000 de n
uplets tester, alors qu'en effectuant d'abord la slectIon du numro de
clIent sur CLENT, Il nous reste que 100'000 nuplets joIndre
SELECT Nom, prix, datedeb, datefin
AND Clients.num_client=1001
SQL permet de mmorIser des relatIons et de les Interroger sans spcIfIer les
structures de donnes ou les chemIns d'acces ces donnes. Cependant sI de
tels chemIns d'acces exIstent, le SC80 pourra optImIser la requte afIn
d'lImIner prIorI des nuplets quI ne satIsfont pas le prdIcat. Ces chemIns
d'acces sont surtout utIles pour l'opratIon d'quIjoInture. ls ne jouent pas
Dans le dictionnaire du SGBD:

schema logique
des relations

schema physique
des relations

statistiques sur
la BD
connaissances theoriques:

- sur l'algebre relationnelle
- sur les modeles physiques
OPTIMISEUR
requte SQL
Sequences d'actions
sur la BD
Instances des relations
Resultats de la requte
BD
0e U|L SQL 271
de role au nIveau smantIque de la relatIon. Dn peut tout moment les
ajouter, les supprImer ou modIfIer la structure de stockage des tables. Les
structures utIlIses sont celles que l'on tudIe dans un cours de structures de
donnes: les arbres, les 8arbres, les fonctIons de hashcodIng, les
partItIonnements, les Index, etc.
Les Index sont une InformatIon supplmentaIre quI permet dIrectement
d'accder aux ranges ayant une certaIne valeur. En prenant comme
mtaphore les lIvres, s'Il n'exIste pas d'Index, pour rechercher une
InformatIon, on est oblIg de parcourIr tout le lIvre, l'Index permet de
retrouver dIrectement la page Intressante. l en va de mme pour une
relatIon, sans Index, le SC80 doIt la parcourIr completement, avec un Index,
Il poInte dIrectement sur la partIe Intressante. Comme pour un lIvre, l'Index
n'ajoute aucune InformatIon Intressante part une facIlIt d'acces. En
construIsant un Index sur les numros de clIent pour la relatIon CLENTS, les
numro de clIent pour la relatIon FESEF7ATDNS et un Index sur les numros
de chambre pour la relatIon CHA|8FES, la requte prcdante quI exIgeaIt
100'000'000 de tests sur des nuplets se rduIt aux parcours de poInteurs dans
un 8arbre (la structure de l'Index) et quelques entres/sortIes sur les
dIsques. 0ans la FIgure 172, on peut suIvre le chemInement de l'optImIsatIon
suIvante produIte par le SC80:
0ans la relatIon CLENTS
chercher Clients.num_client=1001
pour chaque nuplet trouv
0ans la table FESEF7ATDNs
chercher Clients.num_client=Reservations.num_client
0ans la table CHA|8FES
chercher Chambres.num_chambre=Reservations.num_chambre
effectuer la projectIon.
Cette requte optImIse auraIt pu tre crIte par un programmeur. La
dIffrence rsIde dans le faIt que le SC80 faIt voluer dynamIquement le
rsultat de ses optImIsatIons en fonctIon des chemIns d'acces exIstant au
moment de l'excutIon de la requte. Alors que le programme crIt reste
statIque et ne peut aucunement voluer en fonctIon des besoIns mergeant
du champ d'applIcatIon ou d'une meIlleure connaIssance de ce dernIer.

1001
INDEX num_client
sur CLIENTS
1001
CLIENTS
1001
INDEX num_client
sur RESERVATIONS
1001
RESERVATIONS
12
INDEX num_chambre
sur CHAMBRES
CHAMBRES
12
12
FIgure 172 : UtIlIsatIon des Index lors de la slectIon.
Le processus d'optImIsatIon dpend fortement de l'ImplantatIon du SC80.
L'optImIsatIon se dcoupe gnralement dans les tapes suIvantes:
Par la rcrIture de la requte SQL. Cette phase traduIt une requte
SQL en une autre requte SQL quIvalente du poInt de vue
smantIque, maIs quI exploItera au maxImum les connaIssances des
modeles physIques de stockage. La requte obtenue est plus
performante car elle sera plus slectIve du poInt de son excutIon.
Cependant cette phase est entIerement syntaxIque et peut s'excuter
sans utIlIser les InformatIons sur les schmas physIques.
Par la transformatIon de la requte SQL en une squence d'actIons sur
les donnes physIques. Ce comment on va rlement le faIre doIt
dtermIner et choIsIr les chemIns d'acces aux donnes, l'ordre des
joIntures et les mthodes pour effectuer les joIntures. Cette phase
s'excute sur la base des schmas physIques et ventuellement sur la
base d'InformatIons statIstIques sur les Instances.
En gnral les SC80 permettent de connatre la planIfIcatIon d'actIons que
l'optImIseur a effectues.
Reecriture de la requte SQL
L'Ide sousjacente chaque transformatIon est d'obtenIr des expressIons quI
accederont plus dIrectement l'InformatIon. C'est dIre quI pourront tre
utIlIses dIrectement lors de la planIfIcatIon des actIons. Par exemple dans:
SELECT * FROM Chambres WHERE not (prix>100)
Dn souhaIte obtenIr toutes les ranges quI ne sont pas slectIonnes. Le
SC80 ne saIt que faIre des slectIons Il est donc prfrable de luI faIre
excuter la requte quIvalente suIvante:
SELECT * FROM Chambres WHERE prix<=100
Sans tre exhaustIf, nous donnons une lIste des prIncIpales transformatIons
syntaxIques que l'optImIseur peut effectuer.
lImInatIon des expressIons constantes (l'expressIon est value qu'une seule
foIs)
prix <840/7 -- (prix la semaine)
-> prix <120
transformatIon des recherches dans les chanes de caracteres en galIt
(utIlIsable par les Index)
nom like 'Dumas'
-> nom = 'Dumas'
transformatIon des expressIons d'appartenance en une expressIon dIsjonctIve
confort in ('BAIN','DOUCHE')
-> confort='BAIN' OR confort='DOUCHE'
0e U|L SQL 27J
transformatIon des expressIons ANY explIcItes en une expressIon dIsjonctIve
prix < any (100,840/7)
-> prix < 100 OR prix < 840/7
transformatIon des expressIons ALL explIcItes en une expressIon conjonctIve
prix < all (100,840/7)
-> prix < 100 AND prix < 840/7
transformatIon des expressIons ANY ImplIcItes en une expressIon EXSTS
augmente de la condItIon (plus slectIve)
a < any (SELECT prix FROM chambres
WHERE confort ='BAIN'))
-> Exists (SELECT 'vrai' FROM chambres
WHERE confort ='BAIN'
AND a<prix)
transformatIon des expressIons ALL ImplIcItes en une expressIon EXSTS
augmente de la condItIon Inverse (plus slectIve)
a < all (SELECT prix FROM chambres
WHERE confort ='BAIN'))
-> not Exists (SELECT 'vrai' FROM chambres
WHERE confort ='BAIN'
AND a>=prix)
transformatIon des expressIons 8ETWEEN en une expressIon conjonctIve
prix between 100 AND 120
-> prix >= 100 AND prix <= 120
sImplIfIcatIon des expressIons NDT en utIlIsant l'oprateur Inverse
not (prix < 100 OR confort ='WC')
-> prix >=100 AND confort <>'WC'
transformatIon des clauses dIsjonctIves en sousrequtes lIes par un UNDN
ALL (utIlIsatIon possIble des Index dans les sousrequtes)
SELECT * FROM chambres
WHERE confort='BAIN' OR confort='DOUCHE'
-> SELECT * FROM chambres WHERE confort='BAIN'
UNION ALL
SELECT * FROM chambres WHERE confort='DOUCHE'
transformatIon des sousrequtes en une requte quIvalente utIlIsant une
joInture (utIlIsatIon possIble des Index dans les sousrequtes)
SELECT * FROM revervation
WHERE num_chambre in (SELECT chambres.num_chambre
FROM chambres
WHERE confort='BAIN')
-> SELECT revervation.* FROM revervation, chambres
WHERE revervation.num_chambre=chambres.num_chambre
AND confort='BAIN')
Ces transformatIons ne sont pas toujours possIbles, la sous requte doIt alors
tre value pour chaque range de la requte sI elle en dpend.
SELECT * FROM chambres c1
WHERE c1.prix > (SELECT avg(c2.prix)
FROM chambres c2
WHERE c1.confort=c2.confort)
-> pas de requte quivalente avec une jointure
L'optImIseur Integre aussI les vues dans les requtes (dj dIscut dans le
chapItre sur les vues). Les transformatIons que nous avons examInes sont
toutes syntaxIques, c'est dIre que l'on peut les effectuer sans connaIssance
du schma physIque de la base de donnes. L'tape suIvante va consIster
slectIonner les chemIns d'acces.
Chemins d'accs
Les donnes sont stockes dans des structures physIques quI ont chacune des
mthodes d'acces partIculIeres. Pour notre expos, nous ne consIdrons que
les structures de tables squentIelles et d'Index. Cependant les SC80
mettent d'autres structures dIsposItIon du concepteur telles que les tables
dont les donnes sont regroupes physIquement sI elles possedent des
valeurs communes pour certaIns constItuants (cluster); les tables dont la
place des donnes est fIxe par un algorIthme de hcsh codny; ou bIen des
structures de tables squentIellement Indexes. Pour ces structures, on
applIque les mmes crIteres de choIx que pour les deux cas que nous
examInons.
1able sequentielle
0ans cette structure, les donnes sont ranges squentIellement dans
l'espace quI est allou la table. Chaque range est IdentIfIe par un
IdentIfIcateur de range (rowId
19
) entIerement dpendant de la place
physIque de la range.

FIgure 17J : Structure de la table squentIelle

19
L'IdentIfIcateur de range dans DFACLE IndIque le numro du fIchIer, le numro du bloc
dans ce fIchIer, la place dans ce bloc de la range
rangee 1
rangee 2
rangee i
Table R
identiIicateur
de la rangee 1
0e U|L SQL 275
Les mthodes de recherche d'une range pour cette structure sont:
la lecture squentIelle de toute la table, range apres range (]ull
sccn tcble)
l'acces une range par son IdentIfIcateur (by rowd)
Exemple sur Hotel (les plans d'excutIons sont obtenus avec l'ordre Explain
plan du SC80 Dracle. Les plans dcrIvent la mthode et l'acces utIlIs. Les
condItIons de slectIon sont utIlIses lors de l'acces soIt comme cl d'acces
ou bIen comme fIltre):
SELECT * FROM chambres WHERE num_chambre=12;
Cherchons le rowId d'une range
SELECT rowid FROM chambres WHERE num_chambre=12;
WHERE rowid='0000004E.0008.0002';
L'excutIon est bIen conforme ce quI taIt prvu
L'IdentIfIcateur de range est accessIble, maIs son utIlIsatIon est assocIe
d'autres structures de donnes telles que les Index.

FIgure 174 : Structure d'Index assocI une table
Les index
Cette structure est assocIe une table, elle est construIte sur un certaIn
nombre de constItuants de la table. A chaque groupe de valeurs est assocI
un ou plusIeurs IdentIfIcateurs de range. Les valeurs sont ellesmmes
organIses dans une structure quI facIlIte la recherche, souvent sous forme
d'arbre bInaIre (pour une InformatIon de base, examIner l'ouvrage de N.
WIrth [WF76]).
La commande de cratIon de ces Index est une clause SQL quI est ajoute au
standard. 0ans le SC80 Dracle, nous avons la clause suIvante:

Dn assocIe donc un IdentIfIcateur d'Index une table et une lIste de
colonnes. La clause unIque spcIfIe que ce groupe est une cl de la table
donc qu'Il n'y a qu'un seul IdentIfIcateur de range pour une valeur des
colonnes Indexes.
rangee 1
rangee 2
rangee i
Table R
Index de R sur C
c1
c2
ci
idenIicateur
de rangee
pointant sur
les rangees
ayant
ci pour
valeur
Exemple:
CREATE unique index chambres_by_number
on chambres(num_chambre);
Les mthodes prIncIpales de recherche d'un IdentIfIcateur de range pour
cette structure sont:
l'acces un IdentIfIcateur de range avec un Index unIque(0nque
sccn)
l'acces une lIste d'IdentIfIcateurs de range avec un Index (rcnye
sccn)
Pour que ces acces soIent possIbles, Il faut connatre les valeurs des
constItuants dfInIssant l'Index. Le plan d'excutIon de la requte
prcdante devIent alors:
Chercher le rowId dans l'Index pour num_chambre=12
Chercher la range portant ce rowId dans la table Chambres
20

SELECT * FROM chambres WHERE num_chambre=12;
En crant un Index sur prIx, on a des recherches quI nous ramenent tous les
IdentIfIcateurs ayant un mme prIx.
CREATE index chambres_by_prix on chambres(prix);
SELECT * FROM chambres WHERE prix=100;
Choix des chemins d'accs
L'optImIseur va donc examIner toutes les possIbIlIts d'accder aux ranges
des tables. Pour cela Il utIlIsera donc les condItIons de slectIon de la
requte.
Le choIx d'un chemIn est dtermIn sImplement par une pondratIon de la
prfrence quI reflete dIrectement la performance de l'acces (lIste par ordre
de prfrence):
acces une range par un IdentIfIcateur de range
acces par un Index unIque
acces par un Index
acces squentIel la table
Le crItere d'acces peut tre raffIn sI l'on possede des InformatIons
statIstIques sur l'Instance de la base de donnes (les proprIts
dIscrImInantes des Index, la taIlle des tables par exemple, etc). 0es regles
du modele physIque peuvent alors tre utIlIses automatIquement. Une telle
regle sera par exemple, sI l'on accede plus de 25 des ranges d'une table
en utIlIsant un Index alors Il faut prfrer l'acces squentIel ou encore sI la
taIlle d'une table est plus petIte que 4 Koctets alors prfrer l'acces

20
Les plans d'excutIon se lIsent l'envers, Ils correspondent un arbre, les commandes les
plus ImbrIques sont excutes en premIer.
0e U|L SQL 277
squentIel. Les statIstIques permettent de vrIfIer que les acces
sophIstIqus sont justIfIs.
Le travaIl effectu par l'optImIseur lors de la rcrIture est exploIt dans la
recherche des meIlleurs chemIns d'acces. Ajoutons un Index sur confort.
CREATE index chambres_by_confort on chambres(confort);
Le plan d'excutIon montre bIen que la requte t rcrIte sous forme
d'une concatnatIon de deux slectIons, l'une portant sur le prIx et l'autre
sur le confort
WHERE prix<100 OR confort='BAIN';
Choix de la methode de jointure
La dernIere tape de l'optImIsatIon consIste choIsIr une mthode et un
ordre de joInture entre les relatIons. Les mthodes de joInture sont
dpendantes des chemIns d'acces (et donc des structures physIques de
stockage). Avec les structures retenues, nous avons deux mthodes:
la joInture par trI et fusIon
la joInture par boucle ImbrIque
Jointure par tri et fusion
SoIt deux tables F et S joIndre par le groupe de constItuants C, alors
l'algorIthme est le suIvant
LE TRI
trier R avec C comme cl de tri
placer le rsultat dans une table Rt=(C, rowid)
trier S avec C comme cl de tri
placer le rsultat dans une table St=(C, rowid)
LA FUSION
21

lire la premiere range de Rt
lire la premiere range de St
pour chaque range de Rt faire
tant que st.C <=rt.C faire
lire prochaine range de St
si st.C =rt.C alors
joindre st.rowid & rt.rowid
mettre dans la relation RES
refaire
refaire
Cette mthode de joInture ncessIte une lecture squentIelle de chaque
table, les trIs et la fusIon. Le trI est l'opratIon la plus sensIble car sa

21
La fusIon propose est correcte sI C est une cl de F, sI cela n'est pas le cas, Il faut
complter l'algorIthme par une possIbIlIt de retourner en arrIere dans la table St pour
relIre des valeurs lorsqu'on rencontre deux valeurs IdentIques se succdant dans Ft.
complexIt est de D(n.log(n)), les autres sont d'ordre D(n) ou n est la
cardInalIt de la plus grande table.
Elle ne ncessIte pas de structure physIque partIculIere.
Jointure par boucle imbriquee
SoIt deux tables F et S joIndre par le groupe de constItuants C, alors
l'algorIthme est le suIvant
BOUCLE IMBRIQUEE
pour chaque range de R faire
pour chaque range de S faire
si s.C =r.C alors
joindre s & r
mettre dans la relation RES
refaire
refaire
Sans structure physIque partIculIere, cette mthode de joInture ncessIte
une lecture squentIelle de la table F et n lectures squentIelles de la table
S ou n est la cardInalIt de F. 0u poInt de vue performance, elle est
catastrophIque sI n est grand ou sI S est grande. La joInture par trIfusIon est
prfrable. Cependant sI on peut acceder aux ranges de S travers un
Index sur la charnIere C de la joInture, cet algorIthme est trs performant.
Ordre et methode
0ans le cas de joInture de plus de 2 relatIons, les relatIons sont toujours
joIntes deux par deux, maIs alors une des relatIons est le rsultat d'une
joInture. L'optImIseur examIne et attrIbue une note toutes les possIbIlIts
de joIntures. l examIne aussI les couples quIvalents F*S et S*F quI peuvent
dIffrer dans leur taIlle et les Index exploIter. Ces algorIthmes d'valuatIon
sont assez complexes et dpendent troItement des structures physIques
mIses en oeuvre dans le SC80.
Pour termIner examInons deux exemples:
Cette requte dans une structure sans Index utIlIse la mthode de trIfusIon
SELECT r.num_chambre,prix
FROM chambres c,reservations r
WHERE c.num_chambre=r.num_chambre;
Apres la cratIon d'un Index sur les numro de chambre, l'optImIseur utIlIse,
pour la mme requte, la fusIon par boucle ImbrIque ou la boucle
IntrIeure est un acces travers un Index portant sur la charnIere de la
joInture.
La requte suIvante porte sur troIs relatIons, sans structure d'Index. Un trI
fusIon est effectu entre les clIents et les rservatIons (on utIlIse la
0e U|L SQL 279
condItIon de slectIon sur le nom pour dImInIuer le nombre de ranges du
rsultat). Le rsultat est reprIs dans un deuxIeme trIfusIon avec la relatIon
chambres.
SELECT nom,r.num_chambre,prix
FROM chambres c,reservations r,clients cl
WHERE c.num_chambre=r.num_chambre
AND cl.num_client=r.num_client
AND cl.nom='DUMAS';
CREATE index reservations_by_num_client
on reservations(num_client);
CREATE index clients_by_nom
on clients(nom);
Apres avoIr cr troIs Index (sImIlaIre la FIgure 172), nous obtenons un
plan d'excutIon quI utIlIse tous les Index. l s'agIt de boucles ImbrIques quI
portent seulement sur quelques ranges
Pour crer une applIcatIon performante, le concepteur doIt connatre:
les mcanIsmes utIlIss par le SC80
les schmas physIques de son applIcatIon
les traItements de l'applIcatIon
0ans la deuxIeme partIe de ce chapItre, nous examInons comment ces
dIffrents poInts sont Interdpendants.
Une perception holistique de la conception
Nous Illustrons notre propos par un exemple sImplIfI, tIr de la
comptabIlIt. Nous avons gard, le coeur d'une base de donnes comptable,
savoIr enregIstrer des crItures ventIlant, sur des comptes, des pIeces
comptables regroupes dans des journaux comptabIlIss pour une prIode
comptable. Nous avons conserv l'aspect multIsocIt.
Nous avons retenu les constItuants suIvants:
Date_jour dom date
Date_Valeur dom date
Debit_Credit dom mot ('D','C')
Lib_Ecriture dom texte
Lib_journal dom texte
Lib_Piece dom texte
Montant dom numrique rel
Num_Compte dom numrique entier [1..999999]
Num_Ecriture dom numrique entier [1..999999]
Num_journal dom numrique entier [1..999999]
Num_Piece dom numrique entier [1..999999]
Periode_comptable dom mot ('9301', '9302', ... )
Societe dom mot ('SA', ... )
Le prdIcat portant sur ces constItuants est:
Tout(Date_jour, Date_Valeur, Debit_Credit,
Lib_Ecriture, Lib_journal, Lib_Piece, Montant,
Num_Compte, Num_Ecriture, Num_journal, Num_Piece,
Periode_comptable, Societe)
predicat:"||Tout(dj,dv,dc,le,lj,lp,mt,nc,ne,nj,np,pc,s
o)|| L'criture libelle le, au (dbit/crdit) dc, du
montant mt, portant sur le compte nc appartient la
pice np, libelle lp, la date de valeur dv, et est
comptabilise dans le journal nj, libell lj, la
date dj, pour la priode pc"
Le schma valIde les dpendances fonctIonnelles suIvantes:
Societe,Date_jour Periode_comptable
Societe,Num_journal Lib_journal, Date_jour
Societe,Num_Piece Num_journal,Date_Valeur,Lib_Piece
Societe,Num_Piece,Num_CompteMontant,Debit_Credit,Lib
_Ecriture
Ces dpendances fonctIonnelles forment un base Irredondante (pas de
cycle), nous avons donc dIrectement une dcomposItIon en JFN (les cls sont
soulIgnes).
Periode(Societe, Date_jour, Periode_comptable)
Journal(Societe, Num_journal, Lib_journal, Date_jour)
Piece(Societe, Num_Piece, Num_journal, Date_Valeur,
Lib_Piece)
Ecriture(Societe,Num_Piece,Num_Compte,Montant,
Debit_Credit,Lib_Ecriture)
Nous obtenons donc le schma de cratIon suIvant pour le SC80:
CREATE TABLE PERIODE (
Societe CHAR(3) not null,
Date_Jour DATE not null,
Periode_Comptable CHAR(4) not null)
CREATE TABLE JOURNAL (
Num_Journal NUMBER (6) not null,
Date_Jour DATE not null,
Lib_Journal CHAR(30))
CREATE TABLE PIECE(
Num_Piece NUMBER (6) not null,
Num_Journal NUMBER (6) not null,
Date_Valeur Date not null,
Lib_Piece CHAR(30))
0e U|L SQL 281
CREATE TABLE ECRITURE(
Num_Compte NUMBER (6) not null,
Montant Number(13,2) not null,
Debit_Credit char(1) not null,
Lib_Ecriture CHAR(30))
Pour facIlIter notre travaIl , on peut dfInIr la vue Tout. 0'un poInt de vue
mthodologIque, travaIller sur des vues devraIt mInImIser les modIfIcatIons
dans les traItements sI l'on doIt changer le schma de la base de donnes.
CREATE VIEW tout AS
SELECT
D.societe,D.date_jour,D.periode_comptable,
J.Num_journal,J.lib_journal,
P.num_piece,P.date_valeur,P.lib_piece,
E.num_compte,E.Montant,E.debit_credit,E.lib_ecriture
FROM periode D,journal J, piece P, Ecriture E
WHERE D.societe=J.societe
AND D.date_jour=J.date_jour
AND J.societe=P.societe
AND J.num_journal=P.num_journal
AND P.societe=E.societe
AND P.num_piece=E.num_piece;
Nous avons retenu les traItements suIvants:
1) calculer le mouvement d'un compte pour une prIode
2) rechercher les pIeces et les crItures d'un journal
J) rechercher les crItures d'une pIece
4) vrIfIer qu'un groupe d'crItures est balanc (somme des dbIts est
gale la somme des crdIts pour chaque pIece)
Pour effectuer les joIntures et effectuer les dIffrents acces, nous
dfInIssons les Index suIvants:
CREATE unique index periode_i1
on periode(societe,date_jour);
CREATE unique index journal_i1
on journal(societe,num_journal);
CREATE unique index piece_i1
on piece(societe,num_piece); -- pour accder par les
pices
CREATE index piece_i2;
on piece(societe,num_journal);
CREATE index ecriture_i1
on ecriture(societe,num_piece);
CREATE index ecriture_i2
on ecriture(societe,num_compte); -- pour accder par les
comptes
Pour ces quatres questIons, nous avons crIt une requte SQL utIlIsant la vue
Tout. Les rsultats sont prsents dans un tableau comportant la requte,
son cout d'excutIon et son plan d'excutIon.
Q SQL cot Accs utilis
1 SELECT decode(debit_credit,'D',-
montant,montant)
FROM tout
WHERE societe='SA'
AND num_compte=11
AND periode_comptable='9304';

17 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY ROWID PERIODE
INDEX RANGE SCAN PERIODE_I1
TABLE ACCESS BY ROWID JOURNAL
INDEX RANGE SCAN JOURNAL_I1
TABLE ACCESS BY ROWID PIECE
INDEX RANGE SCAN PIECE_I2
TABLE ACCESS BY ROWID ECRITURE
INDEX RANGE SCAN ECRITURE_I2

2 SELECT *
FROM tout
WHERE societe='SA'
AND num_journal=11;

3 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX UNIQUE SCAN JOURNAL_I1

3 SELECT *
FROM tout
WHERE societe='SA'
AND num_piece=1;

15 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
INDEX UNIQUE SCAN PIECE_I1

4 SELECT
num_piece,sum(decode(debit_credit,'D',-
montant,montant))
FROM tout
WHERE societe='SA'
AND num_piece between 1 AND 100
GROUP BY num_piece
having sum(decode(debit_credit,'D',-
montant,montant))<>0;

36 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS

Pour ces tests, nous avous utIlIs une petIte base de donnes d'envIron 5000
crItures, portant sur 4 prIodes.
A premIere vue, pas de FULL SCAN, tous les acces se font par des Index.
EffectIvement dans chaque requte, on spcIfIe la socIt donc on peut
toujours accder avec un Index (juste sur la premIere cl). |algr la
0e U|L SQL 28J
dIversIt des requtes, on accede toujours dans le mme ordre aux tables
PEFD0E JDUFNAL PECE ECFTUFE.
Cette ordre est fIx par la vue Tout. En effet, les valeurs d'acces sont
substItues lexIcalement dans la vue. La contraInte sur la socIt portera
toujours sur le constItuant socIt de prIode, alors que sI l'on dsIre
accder par le numro de journal, Il faut contraIndre celuI de la table
Journal pour profIter des Index.
En effectuant des test sur dIx foIs plus d'entIts, les couts peuvent
facIlement centupler. Le relatIvement bon score de la questIon deux
s'explIque par le faIt que le SC80 a utIlIs l'Index sur le numro de pIece et
que le nombre de ranges ce stade de la rsolutIon taIt faIble (500). La
vue Tout telle qu'elle est dfInIe ne correspond en faIt aucun type d'acces
qu'Il faut prIvIlgIer du poInt de vue des traItements.
Specialiser les vues pour un accs principal
En examInant la vue Tout et nos traItements, on peut constater que l'on doIt
accder, par les journaux, par les pIeces et par les crItures. l faut donc
crer troIs vues, prservant un acces prIvIlgI pour ces types de slectIon
(en gras, on trouve les dIffrences avec la vue Tout.
CREATE VIEW tout_E AS -- par les critures
SELECT
E.societe,J.date_jour,D.periode_comptable,
E.num_piece,P.date_valeur,P.lib_piece,
FROM
periode D,journal J, piece P, Ecriture E
WHERE E.societe=J.societe
AND D.date_jour=J.date_jour
AND E.societe=P.societe
AND P.societe=E.societe
CREATE VIEW tout_J AS -- par les journaux
SELECT
J.societe,J.date_jour,D.periode_comptable,
FROM
periode D, piece P, Ecriture E,journal J
WHERE J.societe=D.societe
AND J.date_jour=D.date_jour
AND J.societe=P.societe
AND J.societe=E.societe

CREATE VIEW tout_P AS -- par les pices
SELECT
P.societe,J.date_jour,D.periode_comptable,
P.Num_journal,J.lib_journal,
E.num_compte,E.Montant,
E.debit_credit,E.lib_ecriture
FROM
periode D, piece P, Ecriture E,journal J
WHERE P.societe=D.societe
AND J.date_jour=D.date_jour
AND P.societe=P.societe
AND J.societe=E.societe
En utIlIsant ces vues, on obtIent le tableau quI suIt

Q SQL co
t
Accs utilis
montant,montant)
FROM tout_E
WHERE societe='SA'
AND num_compte=11
AND periode_comptable='9304';

15 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL PERIODE
TABLE ACCESS BY ROWID
ECRITURE

2 SELECT *
FROM tout_J
WHERE societe='SA'
AND num_journal=11;

2 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
JOURNAL
INDEX UNIQUE SCAN PERIODE_I1

3 SELECT *
FROM tout_P
WHERE societe='SA'
AND num_piece=1;

2 NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
FILTER
TABLE ACCESS FULL JOURNAL

0e U|L SQL 285
4 SELECT
montant,montant))
FROM tout
WHERE societe='SA'
GROUP BY num_piece

23 FILTER
SORT GROUP BY
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL JOURNAL
ECRITURE

Dn constate que les questIons 2 et J ont bnfIcI de ce remanIement. Leur
excutIon accede maIntenant dIrectement la table la plus dIscrImInante.
L'excutIon de 4 reste couteuse, car elle est mal formule, la rponse
cette questIon peut tre calcule unIquement dans le contexte de la table
des crItures. La vue nous oblIge faIre des joIntures pour obtenIr des
InformatIons quI sont InutIles pour cette questIon.
Q SQL co
t
Accs utilis
4 SELECT
montant,montant))
FROM Ecriture
WHERE societe='SA'
GROUP BY num_piece

1 FILTER
SORT GROUP BY
ECRITURE

Denormalisation
La questIon 1 ne peut pas tre optImIse par une vue, ou par une rductIon
de contexte. En effet, dans ce schma, elle est IntrInsequement couteuse,
car elle ncessIte troIs joIntures, pour accder sImultanment la prIode
et au numro de compte. La seule solutIon consIste dnormalIser, c'est
dIre crer une redondance dans les donnes. 0ans notre cas Il faut ajouter
l'InformatIon prIode sur l'crIture. Les programmes de saIsIe des donnes
doIvent tenIr compte de cette redondance. Le cout de cette dnormalIsatIon
se traduIt aussI dans une augmentatIon de la place utIlIse pour stocker
cette InformatIon supplmentaIre pour chaque crIture. (dIlemme entre
calculer et mmorIser). Nous ajoutons donc le constItuant prIode la table
crIture. l prend pour valeur celle assocIe la pIece et au journal.
CREATE TABLE ECRITURE(
Num_Compte NUMBER (6) not null,
Priode CHAR(4) not null,
Montant Number(13,2) not null,
Debit_Credit char(1) not null,
Lib_Ecriture CHAR(30))
Nous remplaons l'Index ecrture_2 par l'Index suIvant portant en plus sur la
prIode:
CREATE index ecriture_i2bis on
ecriture(societe,num_compte,periode);
La questIon 1 peut maIntenant se calculer localement dans le contexte de la
table crIture.

Q SQL co
t
Accs utilis
montant,montant)
FROM ecriture
WHERE societe='SA'
AND num_compte=11
AND periode='9304';

1 TABLE ACCESS BY ROWID ECRITURE
INDEX RANGE SCAN ECRITURE_I2BIS

Une requte SQL donne toujours une rponse, maIs cellecI peut arrIver
apres une courte ternIt ... l faut donc tre tres vIgIlant dans l'crIture des
requtes. La dure maxImale d'une requte devraIt tre Inverse sa
frquence.
Frquence dure
moIs heures
jour quart d'heure
heure mInute
mInute seconde
Avant de penser changer de machIne, Il faut examIner mInutIeusement les
requtes quI sont un goulot d'trangle ment. En changeant de machIne, on
peut gagner un facteur 10 (selon ses moyens). En rcrIvant une requte, on
peut gagner parfoIs un facteur 1000.
Nous avons utIlIs l'approche prconIse consIstant :
analyser les donnes
concevoIr le schma normalIs
tablIr des vues pour facIlIter la programmatIon des traItements
choIsIr un schma physIque de stockage
programmer les traItements
Chaque tape taIt optImale
Le schma taIt en troIsIeme forme normale
Les traItements opraIent travers une vue
Tous les Index ncessaIres taIent prsents
Pourtant le rsultat de l'excutIon des traItements avaIent de mauvaIses
performances. La normalIsatIon peut loIgner des InformatIons qu'Il seraIt
souhaItable de garder couples, car elles prennent sens lorsqu'elles sont
ensemble. Les vues peuvent rendre Inoprantes les optImIsatIons. Les Index
peuvent tre utIlIss partIellement. CecI montre que des solutIons
0e U|L SQL 287
localement Idales peuvent mener une solutIon globalement
InsatIsfaIsante.
AfIn d'vIter cecI, Il faut que les contraIntes de performance, d'acces aux
donnes et de spcIfIcatIon des traItements usuels et frquents soIent
consIdrs en parallele avec la conceptIon des donnes. Nous prconIsons
donc une approche:
ne prIvIlgIant pas les donnes aux dpends des traItements.
valIdant les choIx du concepteur (par prototypage par exemple).
L'Indpendance entre les nIveaux conceptuels, logIques et physIques; entre
les modeles de donnes, de traItements et des regles d'IntgrIt donne un
cadre thorIque pour le chercheur et un cadre cognItIf pour le concepteur.
Cependant lors de la ralIsatIon d'un systeme d'InformatIon, les frontIeres de
ces cadres doIvent tre assouplIes, la conceptIon s'y effectue en parallele,
les ItratIons tant nombreuses. Les nIveaux et les modeles devIennent
Interdpendants. Cette Interdpendance est lIe aux objectIfs et aux choIx
des concepteurs.
0e U|L SQL 289
J8. INVLS1
Lnonce
Une socIt de gestIon de portefeuIlle a dcId de faIre voluer ses
applIcatIons de gestIon. Elle a choIsI de les Implanter l'aIde d'un systeme
de gestIon de bases de donnes relatIonnel et de remplacer aInsI ses
ancIennes applIcatIons crItes en 8ASC avec des fIchIers squentIels
Indexs. nvest gere des portefeuIlles de valeur pour dIffrents clIents. Elle
achete et elle vend des tItres. Elle peroIt les revenus. Elle gere les
portefeuIlles en francs suIsses, maIs peut acheter des valeurs dans une autre
monnaIe. Tous les jours, elle Interroge un serveur la bourse quI luI IndIque
le cours du jour pour un tItre et les cours de change.
Un consultant a tudI les InformatIons de nvest et propose l'analyse quI
suIt. l a volontaIrement cart les problemes touchant la comptabIlIt et
la fIscalIt dans la gestIon des portefeuIlles.
nvest gere des valeurs quI sont IdentIfIes par un numro NumVaIeur.
Chaque valeur possede un Cenre quI spcIfIe le type de valeur (une actIon
ou une oblIgatIon par exemple); une ranche IndIquant le domaIne d'actIvIt
conomIque (chImIe, assurance, banque, mtallurgIe ....); le Pays metteur
de la valeur; la monnaIe dans laquelle cette valeur est cote
honnaIeCotatIon; un lIbell pour la valeur LIbeIIeVaIeur. Dn luI assocIe
aussI une apprcIatIon Interne CatgorIe permettant de spcIfIer le type de
placement par rapport aux clIents (ScurIt, FevenuFIxe, SpculatIf, ...).
Pour les oblIgatIons, on trouve un supplment d'InformatIon, IndIquant le
taux d'Intrt Taux, aInsI que la premIere et la dernIere date d'chance des
coupons des oblIgatIons PremEcheance, 0ernEcheance. La premIere date
d'chance correspond une anne apres la date d'mIssIon.
Pour chaque valeur, on mmorIse un hIstorIque journalIer 0ateCotatIon des
Cours de la valeur dans sa monnaIe de cotatIon. Les portefeuIlles sont grs
en francs suIsses; pour effectuer les conversIons de monnaIes, on possede un
hIstorIque journalIer 0ateChange des cours de change CoursChange des
monnaIes trangere honnaIeEtrangere.
Un dossIer est constItu pour chaque clIent IdentIfI par un numro
NumCIIent. Pour chaque clIent, on enregIstre son Nom, Prnom, Adresse et
numro de TIphone. Le clIent peut mettre des contraIntes dans la
composItIon de son portefeuIlle, par exemple qu'Il ne veut pas plus de
100'000 FFS de valeurs spculatIves. Une contraInte assocIe donc un montant
maxImum hontanthax pour une catgorIe et un clIent.
Les transactIons sont IdentIfIes par un numro de transactIon unIque
NumTrans. Dn spcIfIe le clIent, la valeur, le type de transactIon TypeTrans
(Achat, 7ente, SplIt, ....), la quantIt te, le montant de la transactIon
hontantTrans en francs suIsses et la date de la transactIon 0ateTrans.
Lorsqu'un clIent touche un revenu, on IdentIfIe celuIcI par un numro unIque
NumPevenu. Dn spcIfIe le clIent, la valeur, le type de revenu TypePevenu
(0IvIdende, CouponDblIg, ...), le montant du revenu hontantPevenu en
francs suIsses et la date du revenu 0atePevenu.
Le consultant pense qu'avec ces donnes, Il peut faIre des estImatIfs, des
InventaIres, vrIfIer des regles de gestIon (ne pas vendre des tItres que l'on
ne possede pas), etc ...
Domaine des constituants
Adresse texte
8ranchemot (chImIe, assurance, banque, mtallurgIe ....)
CategorIe mot (ScurIt, FevenuFIxe, SpculatIf, ...)
CoursChange nombre
Cours nombre
0ateChange date
0ateCotatIon date
0ateFevenu date
0ateTrans date
0ernEcheance date
Cenre mot (actIon, oblIgatIon, ....)
LIbelle7aleur texte
|onnaIeCotatIonmot (FFS, FF, 0|, SUS, ...)
|onnaIeEtrangeremot (FFS, FF, 0|, SUS, ...)
|ontant|ax nombre
|ontantFevenu nombre
|ontantTrans nombre
Nom mot
NumClIent entIer [1..99999]
NumFevenu entIer
NumTrans entIer
Num7aleur entIer [1..9999999999]
Pays mot
PremEcheance date
Prenom mot
Qte entIer
Taux nombre [0..100]
Telephone texte
TypeFevenu mot (0IvIdende, CouponDblIg, ...)
0e U|L SQL 291
TypeTrans mot (Achat, 7ente, SplIt, ....)
Semantique
Exemple de faIts mmorIser dans notre modele
Le clIent numro J42 se nommant Jean 0upont a achet hIer 100 actIons
amrIcaInes de 8IgHamburger (Numvaleur=140140) de la branche AlImentaIre
au cours de 14JS. Le taux de change taIt de 1.45 FFS/S. Aujourd'huI, Il a
touch un dIvIdende de 10J0 FFS sur ces mmes actIons. Ce clIent a spcIfI
qu'Il voulaIt un maxImum de 100'000 dans les tItres spculatIfs. L'oblIgatIon
de la banque du CasIno (Num7aleur = 1J01J0) est mIse pour 5 ans partIr
du 1 avrIl 2002 18

speculatiI:Categories 100'000 max:
140140:Valeurs
LibelleValeur : stringBigHamburger
Branche : stringAlimentaire
Pays : stringusa
:Revenus
DateOperationaujourd'hui
TypeRevenu : stringdividendes
MontantRevenu : real1030
LibelleValeur : stringBigHamburger
Branche : stringAlimentaire
Pays : stringusa
traite en
DateOperationaujourd'hui
TypeRevenu : stringdividendes
342:Dossiers
Nom : stringDupont
Prenom : stringJean
Nom : stringDupont
Prenom : stringJean
pour
en Iaveur
:Transactions
Qte : integer100
DateOperationhier
TypeTrans : stringachat
Qte : integer100
DateOperationhier
TypeTrans : stringachat
porter sur
130130:Obligations
LibelleValeur : stringBanque du casino
Taux : real18
PremEcheance : date1/4/2002
LibelleValeur : stringBanque du casino
Taux : real18
PremEcheance : date1/4/2002
MontantRevenu : real1030
$:Monnaies
143:
hier
1.45:
hier hier
hier
cote a
echange a
Diagramme des classes

Relations
VaIeur (Num7aleur, LIbelle7aleur, 8ranche, Cenre, Pays,
|onnaIeCotatIon, CategorIe)
DbIIgatIon (Num7aleur, Taux, PremEcheance, 0ernEcheance)
Change (0ateChange, |onnaIeEtrangere, CoursChange)
CotatIon (Num7aleur, 0ateCotatIon, Cours)
0ossIer (NumClIent, Nom, Prenom, Adresse, Telephone)
Obligations
PremEcheance : date
Taux : real
DernEcheance : date
Changes
CoursChange : real
DateChange : date
Cotations
DateCotation : date
Cours : real
PremEcheance : date CoursChange : real
Cours : real
Valeurs
NumValeur : string
LibelleValeur : string
Branche : string
Genre : string
Pays : string
Oprations
DateOperation : date
NumOperation : integer
Revenus
TypeRevenu : string
MontantRevenu : real
DateOperation : date
NumOperation : integer
*
NumValeur : string
LibelleValeur : string
Branche : string
Genre : string
TypeRevenu : string
MontantRevenu : real
Dossiers
NumClient : integer
Nom : string
Prenom : string
Adresse : string
Telephone : string
Contraintes
MontantMax : integer MontantMax : integer
NumClient : integer
Nom : string
Prenom : string
Adresse : string
Telephone : string
*
*
*
1
1
compose
porte sur
1
Transactions
TypeTrans : string
Qte : integer
MontantTrans : real
TypeTrans : string
Qte : integer
MontantTrans : real
Catgories
CodeCategorie : string CodeCategorie : string
1
Pays : string
est
*
1
DateCotation : date
1
*
Taux : real
cours de
Monnaies
CodeMonnaie : string CodeMonnaie : string
1
*
traite en
DateChange : date
1
*
cours de
DernEcheance : date
0e U|L SQL 29J
TransactIon (NumTrans, NumClIent, Num7aleur, TypeTrans, 0ateTrans,
Qte, |ontantTrans)
Pevenu (NumFevenu, NumClIent, Num7aleur, TypeFevenu,
0ateFevenu, |ontantFevenu)
ContraInte (NumClIent, CategorIe, |ontant|ax)
Dependances fonctionnelles
1) Num7aleur LIbelle7aleur, 8ranche, Cenre Pays, |onnaIeCotatIon,
CategorIe
2) Num7aleur Taux, PremEcheance, 0ernEcheance
J) 0ateChange, |onnaIeEtrangere CoursChange
4) Num7aleur, 0ateCotatIon Cours
5) NumClIent Nom, Prenom, Adresse, Telephone
6) NumTrans NumClIent, Num7aleur, TypeTrans, 0ateTrans, Qte,
|ontantTrans
7) NumFevenu NumClIent, Num7aleur, TypeFevenu, 0ateFevenu,
|ontantFevenu
8) NumClIent, CategorIe |ontant|ax
1ables type
7aleur Num7aleur LIbelle7aleur 8ranche Cenre Pays |onnaIeCotatIon CategorIe

DblIgatIon Num7aleur Taux PremEcheance 0ernEcheance

Change 0ateChange |onnaIeEtrangere CoursChange

CotatIon Num7aleur 0ateCotatIon Cours

0ossIer NumClIent Nom Prenom Adresse Telephone

TransactIon NumTrans NumClIent Num7aleur Type
Trans
0ate
Trans
Qte |ontant
Trans


Fevenu NumFevenu NumClIent Num7aleur Type
Fevenu
0ate
Fevenu
|ontant
Fevenu

ContraInte NumClIent CategorIe |ontant|ax

Sur la modelisation
Fpondre aux questIons suIvantes en basant vos arguments unIquement sur la
modlIsatIon
1) Peuton acheter une mme quantIt d'une valeur, le mme jour, un
mme prIx, pour un mme clIent:
2) SI on runIt les relatIons 7aleur et DblIgatIon dans une unIque relatIon:
7aleurbIs(Num7aleur, LIbelle7aleur, 8ranche, Cenre, Pays,
|onnaIeCotatIon, CategorIe, Taux, PremEcheance, 0ernEcheance)
donner les avantages et dsavantages qu'on obtIent, chercher la cl de
cette nouvelle relatIon et dIscuter des anomalIes de mIse jour aInsI
que du respect de la dcomposItIon
J) SI on runIt les relatIons 7aleur et CotatIon dans une unIque relatIon:
7aleurter (Num7aleur, LIbelle7aleur, 8ranche, Cenre, Pays,
|onnaIeCotatIon, CategorIe, 0ateCotatIon, Cours)
cette nouvelle relatIon et dIscuter des anomalIes de mIse jour aInsI
que du respect de la dcomposItIon
4) ExplIcItez toutes les dpendances exIstentIelles vrIfIer sur la
modlIsatIon (sous la forme F[C] S[C] )
5) 0onnez l'ordre de cratIon quI permet de crer la relatIon
TransactIon (NumTrans, NumClIent, Num7aleur, TypeTrans, 0ateTrans,
Qte, |ontantTrans)
avec les clauses sur toutes les contraIntes d'IntgrIt
6) magInez une rI quI exIsteraIt dans le champ d'applIcatIon telle que:
a) une prImItIve de la relatIon TransactIon feraIt partIe de la porte de
cette rI et
b) cette rI ne pourraIt pas tre prIse en compte lors du CFEATE de la
relatIon TransactIon (donc elle ne peut fIgurer dans la rponse 5)
Requtes
Fpondre en SQL aux questIons suIvantes:
1) LIste des valeurs mIses en Espagne, pour lesquelles aucune
transactIon n'a t mIse, par ordre alphabtIque
0e U|L SQL 295
2) LIste des oblIgatIons franaIses et suIsses ayant une chance dans le
XX sIecle. ( rem : pour utIlIser une date apres 1999, utIlIser la fonctIon
to_date. ex: to_date('05|AF2020', '00|||YYYY') )
J) EtablIr un InventaIre (QTE actuelle pour chaque valeur d'un portefeuIlle)
pour le clIent J42
4) LIste des cotatIons du jour (22692) dans la monnaIe de base
5) LIste par pays des revenus perus entre le 1191 et le J11291 pour le
clIent 0upont (en le supposant unIque)
6) LIste des valeurs ayant gagn 20 dans les 6 dernIers moIs (dans leur
monnaIe de cotatIon). (rem : utIlIser la fonctIon
months_between(date1,date2))
Rgles d'integrite
...Le clIent peut mettre des contraIntes dans la composItIon de son
portefeuIlle, par exemple qu'Il ne veut pas plus de 100'000 FFS de valeurs
spculatIves. Une contraInte assocIe donc un montant maxImum pour une
catgorIe et un clIent... Ce montant est comparer avec la somme des
montants engags pour les valeurs de cette catgorIe. Le montant engag
pour une valeur est la somme des montants des transactIons concernant
cette valeur.
0onnez la porte de cette rI en remplIssant le tableau de contexte suIvant
(mettre une croIx sI la case appartIent la porte)

PrImItIve
/relatIon
Insrer Sup
prImer
maj maj maj maj maj maj maj
TransactIon Num
Tran
s
Num
ClIe
nt
Num
7ale
ur
Type
Tran
s
0ate
Trans
Qte |ont
antT
rans
7aleur Num
7ale
ur
LIbel
le7al
eur
8ran
che
Cenr
e
Pays |onn
aIeC
otatI
on
Cate
gorIe
0ossIer Num
ClIen
t
Nom Pren
om
Adre
sse
Tele
phon
e
contraInte Num
ClIen
t
Cate
gorI
e
|ont
ant|
ax

0onner une requte SQL quI permette de dtecter les contraIntes quI ne sont
pas respectes dans un dossIer

0e U|L SQL 297
J9. SLCUR
Lnonce
La fIducIaIre SECUF est spcIalIse dans la gestIon des fonds de prvoyance.
Ce march est en pleIne expansIon depuIs que l'tat avaIt rendu oblIgatoIre
l'adhsIon de tous les salarIs d'une entreprIse un fond de prvoyance
convrant l'InvalIdIt et la retraIte. 0es centaInes de fond de prvoyance
s'taIent crs travers tout le pays. Les entreprIses avaIent confIs la
gestIon des fonds des InstItutIons fInancIeres et s'taIent dcharges de la
partIe comptable et admInIstratIve sur les fIducIaIres.
SECUF dans une phase de nouveau dveloppement InformatIque a entreprIs
l'tude d'une base de donnes permettant de grer les InformatIons
ncessaIres ces fonds de prvoyance.
Le champ d'applIcatIon couvert par les ImpratIfs de la gestIon de cette
compagnIe de transport concerne donc la parc de vhIcules, son entretIen,
l'admInIstratIon de chauffeurs et de leur emploI du temps, la gestIon des
appels des clIents la centrale tlphonIque.
Le texte quI suIt est une descrIptIon du champ d'applIcatIon tel qu'Il apparat
la suIte d'une tude avec les comptables (les mots en style gras sont les
constItuants quI sont retenus dans la modlIsatIon)
ExtraIt du rapport
Un fond de prvoyance est IdentIfI par un IdentIfIcateur unIque IdentFond.
Le fond est connu sous une raIson socIale PaIsonFond ayant une adresse
AdrFond pour la correspondance. Une personne cotIsant un fond est un
assur, IdentIfI par un numro IdentAssur. Une personne peut tre
assure par plusIeurs fonds. Un assur est dcrIt par un numro de ScurIt
socIale NumAVS, Il possede un nom Nom, un prnom Prnom, une date de
naIssance NaIssAssur, un sexe Sexe, un tat cIvIl EtatCIvII.
Pour effectuer des calculs actuarIels, Il taIt aussI ncessaIre de connatre
des InformatIons sur les membres de la famIlle de l'assur. Pour les enfants
d'un assur, on enregIstre leur prnom PrnomEnfant et leur date de
naIssance NaIssEnfant. 0ans le cas ou un assur et marI, on doIt aussI
connatre le prnom du conjoInt PrnomConjoInt et sa date de naIssance
NaIssConjoInt.
Un assur faIt partIe d'une certaIne catgorIe CatgorIeAssur par rapport
aux fonds, Il est soIt actIf (verse ses cotIsatIons annuelles), InvalIde (est au
bnfIce d'une rente d'InvalIdIt), retraIt (est au bnfIce d'une rente de
retraIte), dcd (son conjoInt est au bnfIce d'une rente de survIvant
et/ou ses enfants sont au bnfIce d'une rente d'orphelIn) ou quItt (
quItter ce fond, ses cotIsatIons ont t verse sur un autre fond) Un taux
Taux d'actIvIt ou d'InvalIdIt doIt tre IndIqu pour ces catgorIes.
L'appartenance ces catgorIes est hIstorIse, c'est dIre que l'on IndIque le
dbut 0butPrIode et la fIn de la prIode FInPrIode ou l'assur
appartenaIt une catgorIe. En ne spcIfIant pas la fIn de la prIode (valeur
nulle), on IndIque qu'Il s'agIt de la catgorIe actuelle. Ces catgorIes sont
exclusIves entre elles, sauf dans le cas d'une InvalIdIt partIelle ou l'on
admet que l'assur peut avoIr une actIvIt partIelle (la somme des taux ne
devant pas excder 100)
Chaque anne, les assurs actIfs doIvent verser une cotIsatIon
hntCotIsatIon. Cette cotIsatIon est dtermIne en applIquant un certaIn
taux personnel TauxPersonneI au salaIre annuelle SaIaIreAnnueI de l'assur.
Ce taux de partIcIpatIon personnel TauxPartIcIpatIon est tablI en fonctIon
du sexe de l'assur et de son age. 0e plus chaque anne, l'tat fIx une
fourchette mImum SaIaIrehIn et maxImum SaIaIrehax pour les salaIres
soumIs la partIcIpatIon au fond de prvoyance. 0'autres types de cotIsatIon
TypeCotIsatIon sont possIbles, l'apport InItIal quand un assur rentre dans le
fond, la cloture quand un assur quItte le fond, les Intrts annuels. Le
montant d'une cotIsatIon est posItIf sauf dans le cas de la cloture.
Les prestatIons hntPrestatIon verses mensuellement un assur. Dn note
le dbut 0butPrestatIon et la fIn FInPrestatIon de la prIode pendant
laquelle on verse une certaIne rente. Dn IndIque aussI le type de prestatIon
verse TypePrestatIon.
AdrFond texte
Age entIer [18..120]
Anne entIer [1980..2100]
CatgorIeAssur mot (actIf,InvalIde,retraIt,dcd,quItt)
0ateCotIsatIon date
0butPrIode date
0butPrestatIon date
EtatCIvIl mot (clIbataIre,marI,dIvorc,veuf_ve)
FInPrIode date
FInPrestatIon date
dentAssur entIer [10000..99999]
dentFond entIer[100..999]
|ntCotIsatIon rel
|ntPrestatIon rel
NaIssAssur date
NaIssConjoInt date
NaIssEnfant date
Nom texte
0e U|L SQL 299
NumA7S entIer [10000000000..99999999999]
Prnom texte
PrnomConjoInt texte
PrnomEnfant texte
FaIsonFond texte
SalaIreAnnuel rel
SalaIre|ax rel
SalaIre|In rel
Sexe mot (H,F)
TauxPartIcIpatIonrel [0..1]
TauxPersonnel rel
Taux rel [0..100]
TypeCotIsatIon mot(ApportnItIal, CotIsAnnuelle, ntrtAnnuel, Cloture)
TypePrestatIon mot (rente,InvalIdIt,survIvant,orphelIn)
Schema des relations
arme (Sexe, Age, TauxPartIcIpatIon)
Fourchette (Anne, SalaIre|In, SalaIre|ax)
Assur (dentAssur, NumA7S, Nom, Prnom, Sexe, NaIssAssur,
EtatCIvIl)
0ansFond (dentAssur, dentFond)
ConjoInt (dentAssur, PrnomConjoInt, NaIssConjoInt)
Fond (dentFond, FaIsonFond, AdrFond)
Enfant (dentAssur, PrnomEnfant, NaIssEnfant)
CatgorIe (dentAssur, 0butPrIode, CatgorIeAssur, FInPrIode,
Taux)
CotIsatIon (dentAssur, dentFond, TypeCotIsatIon, 0ateCotIsatIon,
SalaIreAnnuel, TauxPersonnel, |ntCotIsatIon)
PrestatIon (dentAssur, dentFond, TypePrestatIon, 0butPrestatIon,
FInPrestatIon, |ntPrestatIon)
(les Instances des relatIons valIdent ces d.f. !)
1) Sexe,Age TauxPartIcIpatIon
2) Anne SalaIre|In, SalaIre|ax
J) dentAssur NumA7S, Nom, Prnom, Sexe, NaIssAssur, EtatCIvIl,
PrnomConjoInt, NaIssConjoInt
4) dentFond FaIsonFond, AdrFond
5) dentAssur,PrnomEnfant NaIssEnfant
6) dentAssur,0butPrIode,CatgorIeAssur FInPrIode, Taux
7) dentFond, dentAssur,TypeCotIsatIon,0ateCotIsatIon SalaIreAnnuel,
TauxPersonnel, |ntCotIsatIon
8)dentFond, dentAssur,TypePrestatIon,0butPrestatIon FInPrestatIon,
|ntPrestatIon
9) 0ateCotIsatIon, NaIssAssur Age
10) NumA7S dentAssur
Diagramme des cas d'utilisation

Secur
Assure actiI
Gestionnaire du Iond
Cotiser
InIormer les assures
Assure preste
Actuaire
Calculer les risques
Verser les prestations
Organe de contrle
Surveiller
0e U|L SQL J01

Semantique
FemplIr les tables correspondant aux Instances des relatIons afIn d'exprImer
le texte quI suIt:
Assurs
NumAVS : string
IdentAssure : real
Nom : string
Prenom : string
NaissAssure : date
EtatCivil : string
Enfants
PrenomEnIant : string
NaissEnIant : date
Catgories
DebutPeriode : date
FinPeriode : date
TypeCotisation : date
Taux : integer
NumAVS : string
IdentAssure : real
Nom : string
Prenom : string
NaissAssure : date
EtatCivil : string
PrenomEnIant : string
NaissEnIant : date
Prestations
TypePrestation : string
DebutPrestation : date
FinPrestation : date
MntPrestation : real
Cotisations
typeDeCotisation : string
DateCotisation : date
SalaireAnnuel : real
TauxPersonnel : real
MntCotisation : real
Conjoints
PrenomConjoint : string
NaissConjoint : date
TypePrestation : string
DebutPrestation : date
FinPrestation : date
MntPrestation : real
typeDeCotisation : string
DateCotisation : date
SalaireAnnuel : real
TauxPersonnel : real
MntCotisation : real
PrenomConjoint : string
NaissConjoint : date
DebutPeriode : date
FinPeriode : date
TypeCotisation : date
Taux : integer
Fonds
IdentFond : string
RaisonFond : string
AdrFond : string
IdentFond : string
RaisonFond : string
AdrFond : string
Fourchettes
Annee : undeIined
SalaireMin : real
SalaireMax : real
Barmes
TauxParticipation : real
Sexe : char
Age : integer
TauxParticipation : real
Sexe : char
Age : integer
Annee : undeIined
SalaireMin : real
SalaireMax : real
En 199J, le salaIre assujettI mInImum et maxImum sont respectIvement
18'000. et 56'000.. L'assur (No 147J9) actIf 100 depuIs le J/11/1985 est
|. 0upond Paul n en 4/10/1950 marI HenrIette ne le 19/2/1952. ls ont
deux enfants |arIe ne le 1/9/1974 et Edgar n le 4/2/1977, Pour les
hommes de 4J ans le taux est de 11. Une CotIsatIon annuelle au J1/12/90 a
t enregIstre pour |. 0upond pour un salaIre de 48600. l est membre du
fond LIfe portant le numro 421.
1able type
8arme Sexe Age TauxPartIcIpatIon

Fourchette Anne SalaIre|In SalaIre|ax

Assur dent
Assur
NumA7S Nom Prnom Sexe NaIssAssur Etat
cIvIl

0ansFond dentAssur dentFond

ConjoInt dentAssur PrnomConjoInt NaIssConjoInt

Enfant dentAssur PrnomEnfant NaIssEnfant

Fond dentFond FaIsonSocIale AdrFond

CatgorIe dentAssur 0but
PrIode
CatgorIe
Assur
FIn
PrIode
Taux

CotIsatIon dent
Assur
dent
Fond
Type
CotIsatIon
0ate
CotIsatIon
SalaIre
Annuel
Taux
Personnel
|nt
CotIsatIon

0e U|L SQL J0J

PrestatIon dent
Assur
dent
Fond
Type
PrestatIon
0but
PrestatIon
FIn
PrestatIon
|nt
PrestatIon

Sur la modelisation
modlIsatIon
1) Un assur peutIl avoIr un nombre dIffrent d'enfant pour deux
fonds dont Il est adhrent:
2) Un assur peutIl avoIr pour une date de cotIsatIon donne
plusIeurs taux de partIcIpatIon:
J) Un assur peutIl tre sImultanment dans les catgorIes InvalIde,
retraIt et quItt :
4) En utIlIsant F01 (l'outIl rechercher des cls du laboratoIre de
80), avec les dpendances fonctIonnelles de l'nonc, on trouve
les cl suIvantes.
Anne IdentAssur IdentFond PrnomEnfant 0butPrIode
CatgorIeAssur TypeCotIsatIon 0ateCotIsatIon TypePrestatIon
0butPrestatIon
Anne NumAvs IdentFond PrnomEnfant 0butPrIode
CatgorIeAssur TypeCotIsatIon 0ateCotIsatIon TypePrestatIon
0butPrestatIon
En supposant que l'on substItue partout le constItuant NumAVS au
constItuant IdentAssur, en justIfIant votre rponse avec la
thorIe, dfInIr ce que trouvera F01 apres une telle substItutIon.
5) 0crIvez ce quI se passe, sI l'on supprIme la relatIon 0ansFond
(IdentAssur, IdentFond) et que l'elle soIt remplace par la vue
suIvante:
CREATE VIEW DansFond (IdentAssur, IdentFond)
AS SELECT distinct IdentAssur, IdentFond
FROM cotisation;
6) ExplIcItez les dpendances fonctIonnelles exIstentIelles vrIfIer
sur la modlIsatIon (sous la forme F[C] S[C] ):
Requtes
1) 0onnez une lIste de tous les fonds par ordre alphabtIque
2) 0onnez la lIste des assurs du fond 'ForEver' par ordre
alphabtIque
J) 0onnez le montant total des cotIsatIons de |.SmIth (pour tous les
fonds)
4) 0onnez le montant total des prestatIons par type de prestatIon
pour le fond No 421
5) 0onnez la rpartItIon des tats cIvIl en pour l'ensemble des
fonds
6) 0onnez la lIste des personnes quI taIent retraItes le 1jan90
dans le fond 'ForEver'
7) Trouver toutes les cotIsatIons quI ne font pas rfrence un
assur
Rgles d'integrite
...Cette cotIsatIon est dtermIne en applIquant un certaIn taux personnel
TauxPersonneI au salaIre annuelle SaIaIreAnnueI de l'assur. Ce taux de
partIcIpatIon personnel TauxPartIcIpatIon est tablI en fonctIon du sexe de
l'assur et de son age...
PrImItIve
/relatIon
Insrer Sup
prImer
Assur de
ntA
ssur

Nu
mA
7S
Nom Prn
om
Sexe NaIs
sAss
ur
Eta
tcIv
Il
CotIsatIon de
ntA
ssur

Typ
eCo
tIsa
tIon
0ate
CotI
satIo
n
SalaI
reAn
nuel
Taux
Pers
onne
l
|nt
CotI
satI
on
de
ntF
ond
8arme Sex
e
Age Taux
PartI
cIpa
tIon

0onner une requte SQL quI permette de dtecter les cotIsatIons quI n'ont
pas le bon taux par rapport l'age de la personne au moment de la
cotIsatIon .
(l'expressIon suIvante calcule l'age de la personne !)
to_char(0ateCotIsatIon),'YYYY')to_char(0ateCotIsatIon),'YYYY')

0e U|L SQL J05
20. UL1IMA
Lnonce
Une socIt fabrIquant des composants lectronIques a dcId de faIre
voluer ses applIcatIons de gestIon. Elle a choIsI de les Implanter l'aIde d'un
systeme de gestIon de base de donnes relatIonnelle et aInsI de remplacer
ses applIcatIons crItes en CD8DL avec des fIchIers squentIels Indexs.
Cependant l'IntgratIon et le partage des InformatIons par plusIeurs
applIcatIons ont faIt merger de manIere aIgue le probleme de la scurIt et
de la confIdentIalIt. En effet, comment donner acces la table des
personnes aux applIcatIons de controle de productIon sans leur donner acces
aux salaIres de ces mmes personnes.
Un groupe scurIt ULT|A a donc t form pour tudIer ce probleme.
L'Ide tant que la scurIt doIt tre Intgre des le dbut dans la
conceptIon des autres applIcatIons.
Le groupe ULT|A a tudI la structure organIsatIonnelle de l'entreprIse,
savoIr qu'une personne est IdentIfIe par un numro d'employ NumEmp et
dcrIte par un Nom, un Prnom et qu'elle travaIlle pour un seul
dpartement 0ept. Un dpartement peut dpendre hIrarchIquement d'un
autre dpartement 0eptSup. LIbeIIe0ept est une descrIptIon tendue du
dpartement.
Un rsultat de l'tude de ULT|A est que la structure organIsatIonnelle de
l'entreprIse n'est pas adquate pour grer la confIdentIalIt des donnes. En
effet, des personnes travaIllant au seIn d'un mme dpartement ont acces
des InformatIons dIffrentes, l'apprentI du bureau du personnel et son
dIrecteur ont des droIts dIffrents. Cependant cette structure a t
conserve car elle peut mettre en vIdence les InformatIons partages par
les dIffrents dpartements.
Une autre structure taIt donc ncessaIre. Elle est dcrIte par un groupe
d'InformatIons IdentIfI par Croupe, (avec un lIbell LIbeIIeCroupe). 0e plus
un groupe peut hrIter les InformatIons d'un autre groupe HerIte0e. Un
employ peut aInsI tre rattach aux dIffrents groupes d'InformatIon
auxquels Il a droIt par dfaut.
Ce systeme tant dans un premIer temps lImIt aux InformatIons du SC80
(lettres, feuIlles de calcul ne sont pas Inclues), les InformatIons sont donc les
tables IdentIfIes par NomTabIe et une descrIptIon SemantIque aInsI que le
nombre d'entIts approxImatIfs NbrEntItes. Les constItuants des tables sont
IdentIfIs par NomConstItuant, un Type et un degr de SecurIte (0 publIc ...
9 = tres confIdentIel ) est aussI donn
La descrIptIon des droIts par dfaut est donne par un 0roIt, que l'on
attrIbue un groupe sur le constItuant d'une table sur une certaIne prIode
(de 0but FIn)
La descrIptIon des droIts personnels est donne par un 0roIt, que l'on
attrIbue un groupe sur le constItuant d'une table sur une certaIne prIode
(de 0but FIn). Ces droIts sont ceux qu'une personne en plus des droIts
donns par son rattachement aux groupes d'InformatIon.
La fIgure suIvante montre les lIens d'hrItage, la personne rattache au
groupe C2 possede par hrItage les droIts du groupe C0.

0ebut date
0ept mot (Compta SalaIre, FabrIc, Pers, nform ....)
0eptSup mot (Compta SalaIre, FabrIc, Pers, nform ....)
0roIt mot (SELECT, CFEATE, delete, update)
FIn date
Croupe mot (FessHum, Adresse, PrIx, ComtaCen, ...)
HerIte0e mot (FessHum, Adresse, PrIx, ComtaCen, ...)
LIbelle0ept texte
LIbelleCroupe texte
NbrEntItes entIer
NomConstItuant mot (Tous_Cst, Nom, 0ate7aleur, PIece, ...)
NomTable mot (Employe, EcrIture, Nomemclature, ...)
G0
G1
G2
G3
G4
droit
hrite
rattach
droit
personnel
0e U|L SQL J07
Nom texte
NumEmp entIer [1..99999]
Prenom texte
SecurIte entIer [0..9]
SemantIque texte
Type mot (Integer, char, date, real)

Relations
(une cl de la relatIon est IndIque par un soulIgnement)
0epartement (0ept, 0eptSup, LIbelle0ept)
Personnes (NumEmp, 0ept, Nom, Prenom)
Croupes (Croupe, HrIte0e, LIbelleCroupe)
Pattacher (NumEmp, Croupe)
TabIes (NomTable, SemantIque, NbrEntItes)
ConstItuants (NomTable,NomConstItuant, Type, SecurIte)
0roItCroupe (Croupe, NomTable, NomConstItuant, 0roIt, 0but, FIn)
0roItPers (NumEmp, NomTable, NomConstItuant, 0roIt, 0but, FIn)
Dn admet aussI pour la suIte de l'nonc qu'Il exIste une vue
TousLesCroues(6rpRccne,6rpAncetre)
quI pour un groupe racIne donne tous les anctres (c'est dIre tous les
groupes dont Il hrIte) CecI permet d'avoIr explIcItement la lIste des groupes
auxquels on a acces travers le mcanIsme d'hrItage.
1) 0ept 0eptSup, LIbelle0ept
2) NumEmp 0ept, Nom, Prenom
J) Croupe HerIte0e, LIbelleCroupe
4) NomTable SemantIque, NbrEntItes
5) NomTable,NomConstItuant Type, ScurIt
6) Croupe,NomTable,NomConstItuant,0roIt,0but FIn
7) NumEmp,NomTable,NomConstItuant,0roIt,0but FIn

Semantique
le texte quI suIt:
Jean SrIen (employ numro 54) travaIlle au dpartement Fourn (les
fournIsseurs) quI dpend de la Compta. l a acces au groupe Four_CA quI
contIent les InformatIons sur les chIffres d'affaIres et hrIte du groupe
Four_SocIal, les InformatIons sur les raIsons socIales des fournIsseurs. La
table HIsto_Four_CA, l'hIstorIque des chIffres d'affaIre contIent envIron
10'000 ranges. Elle est compose entre autre d'une colonne Annee et d'une
Dpartements
LibelleDept : string
Dept : string
Groupes
LibelleGroupe : string
Groupe : string
Tables
NomTable : string
Semantique : string
NbrEntites : integer
Constituants
NomConstituant : string
Type : string
Securite : integer
LibelleDept : string
LibelleGroupe : string
*
NomTable : string
Semantique : string
NbrEntites : integer
enIant
Type : string
Securite : integer
Personnes
Numemp : integer
Prenom : string
Nom : string
DroitPers
Droit : string
Debut : date
Fin : date
Numemp : integer
Prenom : string
NomConstituant : string
Droit : string
Debut : date
Fin : date
Nom : string
*
Dept : string
* 1
*
Groupe : string
*
*
appartient
inI
rattache a
*
DroitGroupe
Droit : string
Debut : date
Fin : date
*
*
Droit : string
Debut : date
Fin : date
* 1
base sur
1
1
sup
inclus
parent
herite
0e U|L SQL J09
colonne CA. CA est de type real avec un degr de scurIt 6. Annee est de
type Integer avec un degr de scurIt 0. Le groupe Four_CA a le droIt
SELECT sur CA et Jean SrIen a le droIt update sur CA depuIs le 1192
1ables 1ype
0epartement 0ept 0eptsup LIbelle0ept

Croupes Croupe HerIte0e LIbelleCroupe

Personnes Numemp 0ept Nom Prenom

Fattacher Numemp Croupe

Tables NomTable SemantIque NbrEntItes

ConstItuants NomTable NomConstItuant Type SecurIte

0roItCroupe Croupe NomTable NomConstItuant 0roIt 0ebut FIn

0roItPers Numemp NomTable NomConstItuant 0roIt 0ebut FIn

Sur la modelisation
modlIsatIon
1) Une personne peutelle tre assocIe une table, un constItuant
et un droIt IdentIque pour des prIodes dIffrentes (dbut fIn):
2) En supprImant le constItuant HerIte0e, peuton encore exprImer
des InformatIons IdentIques dans la 80 (sI ouI comment, sInon
pourquoI):
J) ExplIcItez les dpendances fonctIonnelles exIstentIelles vrIfIer
sur la modlIsatIon (sous la forme F[C] S[C] )
4) 0onnez l'ordre de cratIon quI permet de crer la relatIon
0roItCroupe (Croupe, NomTable, NomConstItuant, 0roIt, 0but,
FIn)
avec les clauses sur les contraIntes d'IntgrIt
5) 0onnez un exemple de rI quI pourraIt exIster dans ce champ
d'applIcatIon et quI ne peut tre prIs en compte lors du CFEATE
pour la relatIon 0roItCroupe (donc quI ne peut fIgurer dans la
rponse 4)
6) En ajoutant la df NumEmp Croupe, que cela sIgnIfIet'Il et
comment peutt'on en tenIr compte dans la dcomposItIon:
Requtes
1a) Trouver la lIste des employs ayant explIcItement acces au groupe
d'InformatIon Four_CA
1b) Trouver la lIste des employs ayant ImplIcItement acces au groupe
d'InformatIon Four_CA
2) Trouver les employs quI ont acces (SELECT,maj,...) au
constItuant SalaIre, travers les droIts de groupe.
J) 0onner le degr moyen, max de scurIt du groupe Four_CA
(sans tenIr compte des constItuants hrIts) en fonctIon du degr
de scurIt des constItuants auxquels Il a acces
4) 0onnez les nouveaux droIts du groupe Four_CA entre le 1191 et
le 1192
5) Le nombre d'employs par dpartement
6) Les groupes dont aucun autre est hrItIer.
Rgles d'integrite
En reprenant l'nonc, le groupe ULT|A ajouter que l'hrItage doIt se
faIre de manIere prserver un ordre par rapport au degr de scurIt des
groupes (dfInI comme le maxImum du degr des constItuants auxquels Il a
acces). 0onc Un groupe ne peut hrIter que d'un groupe ayant un degr
InfrIeur ou gal
PrImItIve
/relatIon
Insrer Sup
prImer
maj maj maj maj maj maj
0roItCrou
pe
Croupe NomTable NomConst
Ituant
0roIt 0ebut FIn
0e U|L SQL J11
ConstItuan
ts
NomTable NomConst
Ituant
Type SecurIte
Croupe Croupe HerIte0e LIbelleCr
oupe

0onner une requte SQL quI permette de dtecter les groupes quI ne
satIsfont pas la regle.
0e U|L SQL J1J
2J. BIGSMAC
La socIt 8Csmac est, depuIs cInq ans, spcIalIse dans la vente
d'ordInateurs IndIvIduels. Elle a faIt face plusIeurs tourmentes dans le
pass: changement de structures du march, chute des prIx, dIversIfIcatIon
des produIts et des servIces. Actuellement, elle veut prendre une part actIve
sur un march dcentralIs, tendu aux clIents loIgns des grandes
concentratIons urbaInes. Pour cela, elle dsIre mettre au poInt une base de
donnes accessIble par mInItel. Le clIent peut y trouver les servIces suIvants:
tre conseIll sur la confIguratIon adapte ses besoIns
acheter des artIcles au dtaIl
accder aux donnes technIques des produIts
connatre la compatIbIlIt entre les produIts
connatre les dlaIs de lIvraIson pour les artIcles hors stock
Apres une premIere runIon, on a obtenu les InformatIons quI suIvent.
Un clIent est IdentIfI par son NoCIIent, on luI connat un nom, un prnom,
une adresse et un numro de Carte de CrdIt NoCarteCrdIt par lequel on
luI dbIte son compte pour ses commandes. Une commande est IdentIfIe
par son NoCmd; on luI assocIe une date dateCmd, un dIaI quI correspond
au dlaI maxImum de lIvraIson des artIcles de la commande et le prIx total
de la commande prIx_Cmd. La commande se dcompose en lIgnes, chacune
correspondant un artIcle (quantIt de 1). Une InformatIon IndIque sI
l'artIcle est rserv dans le stock dans le cas ou toute la commande n'est pas
encore lIvrable. Un prIx est IndIqu pour chaque artIcle. Un artIcle est
IdentIfI par sa catgorIe et un NoArt.
Pour dfInIr certaInes confIguratIons type, 8Csmac a dfInI des usages
(domestIque, bureau, serveur, CAD, PAD, ...) pour orIenter le clIent. Use est
le code de l'usage et IIb_usage son lIbell. Aux usages sont assocIs des
logIcIels et des confIguratIons. Une confIguratIon est IdentIfIe par un
NoConfIg; elle est dcrIte par le lIbell IIb_confIg, un rabaIs est accord sur
tous les artIcles de la confIguratIon et le prIx total correspond prIx_confIg.
0ans une confIguratIon peut entrer les catgorIes d'artIcles suIvantes:
CatInDut: les ImprImantes et scanners quI sont dcrIts par les parametres
technIques.
taIIIe_doc la taIlle du document (A4, AJ)
prcIsIon_dpI la prcIsIon des ImpressIons (J00, 600, ...)
coIor la possIblIt d'ImprImer en couleur
nbr_coIor le nombre de couleurs
vItesse la vItesse d'ImpressIon en pages par mInute
Cat0Isque: les dIsques et les moyens de stockages auxIlIaIres quI sont dcrIts
par les parametres technIques.
VItesse_de transfert en |8ytes par seconde
accs_moyen le temps moyen d'un acces une InformatIon
capacIt la capacIt de stockage
crIture la possIbIlIt d'crIre (C0FD|)
CatEcran: les crans quI sont dcrIts par les parametres technIques.
TaIIIe en pouces
pt_haut le nombre de poInts en hauteur
pt_Iarg le nombre de poInts en largeur
coIor la possIblIt d'affIcher en couleur
nbr_coIor le nombre de couleurs
CatCPU: les unIts centrales avec processeur quI sont dcrItes par les
parametres technIques.
processeur son type
horIoge la vItesse de son horloge
FPU l'exIstence d'une unIt arIthmtIque
ethernet l'exIstence d'une Interface de communIcatIon
nb_sIot le nombre de cartes d'Interface possIble
CatAcc: les accessoIres quI sont dcrIts par les parametres technIques.
IIb_accessoIre une descrIptIon
CatLog: les logIcIels quI sont dcrIts par les parametres technIques.
IogIcIeI une descrIptIon
versIon le numro de versIon
domaIne le domaIne d'utIlIsatIon
mmoIre_exIge la mmoIre recommande par le fabrIcant
Une confIguratIon assocIe donc un certaIn nombre de ces artIcles. Au
mInImum, Il faut un CPU, un dIsque et un cran. Le clIent peut aussI
effectuer sa propre confIguratIon; pour cela Il est aId dans la dtectIon des
IncompatIlIts entre un CPU et des artIcles.
Pour chaque artIcle, on constItue un hIstorIque des prIx et des quantIts
achetes ces condItIons. 0ans un Intervalle de temps (depuIs jusqu), on a
le prIx d'achat (prIx_achat), le prIx clIent (prIx_cIIent), la quantIt encore
en stock (qte_stock) et le dIaI de raprovIsIonnement. Ces donnes
permettent de fIxer le prIx des confIguratIons et des commandes. Dn peut
aussI calculer les marges et les prIx moyens d'achat et de ventes sur des
artIcles restant en stock.
Le consultant pense qu'avec ces donnes, Il peut satIsfaIre les demandes
prIncIpales exprImes par la socIt.
0e U|L SQL J15
acces_moyen nombre (en mIllIsecondes)
adresse texte
capacIt entIer [1..99999] (en |8ytes)
Cat mot (ACC, CPU, 0SK, ECF, D, LDC)
CatAcc mot (ACC)
CatCPU mot (CPU)
Cat0Isque mot (0SK)
CatEcran mot (ECF)
CatnDut mot (D)
CatLog mot (LDC)
color mot (non, ouI)
dateCmd date
dlaI entIer [1..52] (en semaInes)
depuIs date
domaIne mot (jeux, traIt_texte, tableur, sgbd, dessIn,... )
crIture mot (non, ouI)
ethernet mot (non, ouI)
FPU mot (non, ouI)
horloge nombre [10..1000] (en |Hz)
jusqu date
lIb_accessoIre texte
lIb_confIg texte
lIb_logIcIel texte
lIb_usage texte
mmoIre_exIgeentIer [1..16000] ( en K8ytes)
nbr_color entIer [1..24]
nb_slot entIer [1..8]
NoArt entIer [1..99999]
NoArt_cpu (Idem que NoArt)
NoCarteCrdIt texte
NoClIent entIer [1..99999]
NoCmd entIer [1..99999]
NoConfIg entIer [1..99999]
nom texte
prnom texte
prcIsIon_dpI entIer [1..2400] (en poInts par pouce)
prIx nombre
prIx_achat nombre
prIx_clIent nombre
prIx_Cmd nombre
prIx_confIg nombre
processeur mot(68040, 68060, 80J86, 80486, ...)
pt_haut entIer [100..2400]
pt_larg entIer [100..2400]
qte_stock entIer [0..1000]
rabaIs_confIg nombre
remarque texte
rserv entIer [0..1]
TaIlle entIer [9..21] (en pouces)
taIlle_doc mot(A4, AJ, ....)
use mot (domestIque, bureau, serveur, CAD, PAD, ...)
versIon texte
vItesse entIer [1..100] (en pages par mInute)
vItesse_transfert nombre (en |8ytes par seconde)
L'vIdence de ce cas est la relatIon d'hrItage suIvante :

Disques
vitesseTransIert : integer
accesMoyen : integer
capacite : integer
ecriture : boolean
UniteCPU
Processeur : string
horloge : integer
FPU : boolean
ethernet : boolean
nbslot : integer
Logiciels
memoireExigee :
integer
version : string
liblogiciel :
string
Domaine : string
memoireExigee :
integer
Processeur : string
Article
NoArt : integer
Ecrans
nbrcolor : integer
Taille : integer
pthaut : integer
ptlargeur : integer
color : boolean
Accessoires
Libaccessoire : string
InOut
TailleDoc : string
PrecisionDPI : integer
color : boolean
nbrcolor : integer
vitesse : string
version : string
liblogiciel :
string
Domaine : string
nbrcolor : integer
Taille : integer
pthaut : integer
ptlargeur : integer
color : boolean
NoArt : integer
TailleDoc : string
PrecisionDPI : integer
color : boolean
nbrcolor : integer
vitesse : string
vitesseTransIert : integer
accesMoyen : integer
capacite : integer
ecriture : boolean
Libaccessoire : string
horloge : integer
FPU : boolean
ethernet : boolean
nbslot : integer

0e U|L SQL J17

Justement les vIdences sont trompeuses et dans le cas prsent, la dIversIt
et l'volutIon possIble du matrIel vendre seraIt mIeux gr par la
modlIsatIon suIvante :
Utilisations
Libusage : string
Use : integer
Configurations
rabaisconIig : integer
libconIig : string
prixconIig : real
Logiciels
Compatible
Remarque : string
Libusage : string
rabaisconIig : integer
*
1
1
*
Clients
NoClient : integer
Nom : string
Prenom : string
Adresse : string
NoCarteCredit : string
Commandes
NoCmd : integer
dateCmd : date
delai : date
prix : real
NoCmd : integer
dateCmd : date
delai : date
prix : real
NoClient : integer
Nom : string
Prenom : string
Adresse : string
NoCarteCredit : string
*
1
Prix
depuis : date
jusqua : date
prixClient : real
prixAchat : real
Qtestock : integer
delai : integer
depuis : date
jusqua : date
prixClient : real
prixAchat : real
Qtestock : integer
delai : integer
*
LigneCMD
reserve : integer
Prix : real
libconIig : string
prixconIig : real
*
*
reserve : integer
Prix : real
* *
*
1
Article
NoArt : integer
Disques Ecrans UniteCPU Accessoires InOut
Use : integer
*
Remarque : string
NoArt : integer
*
*

Relations
ClIents (NoClIent, nom, prnom, adresse, NoCarteCrdIt)
Commande (NoCmd, NoClIent, dateCmd, dlaI, prIx_Cmd)
LIgne_Cmd (NoCmd, Cat, NoArt, rserv, prIx)
UtIlIsatIon (use, lIb_usage)
FaIt_pour (use, CatLog, NoArt)
ConseIll (use, NoConfIg)
ConfIguratIon ( NoConfIg, lIb_confIg, rabaIs_confIg, prIx_confIg)
nConfIg (NoConfIg, Cat, NoArt)
nDut (CatnDut, NoArt, taIlle_doc, prcIsIon_dpI, color,
nbr_color, vItesse)
0Isques (Cat0Isque, NoArt, vItesse_transfert, acces_moyen,
capacIt, crIture)
Ecrans (CatEcran, NoArt, TaIlle, pt_haut, pt_larg, color, nbr_color)
UnIteCPU (CatCPU, NoArt, processeur, horloge, FPU, ethernet,
nb_slot)
AccessoIres (CatAcc, NoArt, lIb_accessoIre)
LogIcIels (CatLog, NoArt, lIb_logIcIel, versIon, domaIne,
mmoIre_exIge)
CompatIble (CatCPU, NoArt_cpu, Cat, NoArt, remarque)
prIx (Cat, NoArt, depuIs, jusqu, prIx_clIent, prIx_achat,
qte_stock, dlaI)
Article2
NoArt : integer
Description
Libdescription : string
Catgories
Categorie : string
Valeurs
ValeurR : string
NoArt : integer
Categorie : string
Libdescription : string
ValeurR : string
*
1 1
*
* *
0e U|L SQL J19
1) NoClIent nom, prnom, adresse, NoCarteCrdIt
2) NoCmd NoClIent, dateCmd, dlaI, prIx_Cmd
J) NoCmd, Cat, NoArt rserv, prIx
4) use lIb_usage
5) NoConfIg lIb_confIg, rabaIs_confIg, prIx_confIg
6) CatnDut, NoArt taIlle_doc, prcIsIon_dpI, color, nbr_color, vItesse
7) Cat0Isque, NoArt vItesse_transfert, acces_moyen, capacIt, crIture
8) CatEcran, NoArt TaIlle, pt_haut, pt_larg, color, nbr_color
9) CatCPU, NoArt processeur, horloge, FPU, ethernet, nb_slot
10) CatAcc, NoArt lIb_accessoIre
11) CatLog, NoArt lIb_logIcIel, versIon, domaIne, mmoIre_exIge
12) CatCPU, NoArt_cpu, Cat, NoArt remarque
1J) Cat, NoArt , depuIs jusqu, prIx_clIent, prIx_achat, qte_stock
14) Cat, NoArt dlaI
Semantique
le texte quI suIt:
HIer le clIent no 577 Paul NIoumane (carte crdIt 8798798) a command
(no J4J) une confIguratIon STAFTEF (confIg. no 5) avec 10 de rabaIs.
CellecI se compose de:
un processeur 680486 100 |HZ avec FPU et 2 slot (art. no 100)
un cran 16'', 256 couleurs (art. no 200)
un dIsque de J20 |byte (art. no J00)
Pour la prIode de 1 juIn 9J au 1 septembre 9J, le dlaI d'approvIsIonnement
de ces artIcles est de 5 semaInes et les prIx de vente de ces artIcles sont les
suIvants:
no 100, 1200 FFS.
no 200, 600 FFS.
no J00, 1000 FFS.
1ables type

ClIents NoClIent nom prnom adresse NoCarteCrdIt

Commande NoCmd NoClIent dateCmd dlaI prIx_Cmd

LIgne_Cmd NoCmd Cat NoArt rserv prIx

ConfIguratIon NoConfIg LIb_confIg rabaIs_confIg prIx_confIg

nConfIg NoConfIg Cat NoArt

UnIteCPU CatCPU NoArt processeur horloge FPU ethernet nb_slot

Ecrans CatEcran NoArt TaIlle pt_haut pt_larg color nbr_color

0Isques Cat0Isque NoArt vItesse_transfert acces_moyen capacIt crIture

nDut CatnDut NoArt taIlle_doc precIsIon_dpI color nbr_color vItesse

CompatIble CatCPU NoArt_cpu Cat NoArt remarque

prIx Cat NoArt depuIs jusqu prIx_clIent prIx_achat qte_stock dlaI

Sur la modelisation
modlIsatIon
1) Peuton avoIr plusIeurs confIguratIons conseIlles pour un mme usage:
2) SoIt la df et la relatIon suIvantes:
Cat, NoArt dlaI
0e U|L SQL J21
prIx(Cat, NoArt, depuIs, jusqu, prIx_clIent, prIx_achat, qte_stock,
dlaI)
0Iscuter des anomalIes de mIse jour. Peuton proposer une
amlIoratIon de la dcomposItIon :
J) SI on runIt les relatIons nDut, 0Isques, Ecrans, UnIteCPU et AccessoIres
dans une unIque relatIon:
|atrIel (Cat, NoArt, taIlle_doc, prcIsIon_dpI, color, nbr_color,
vItesse, vItesse_transfert, acces_moyen, capacIt, crIture, TaIlle,
pt_haut, pt_larg, processeur, horloge, FPU, ethernet, nb_slot,
lIb_accessoIre)
cette nouvelle relatIon et dIscuter des anomalIes de mIse jour
4) ExplIcItez toutes les dpendances d'InclusIon vrIfIer sur la
modlIsatIon (sous la forme F[C] S[0] )
5) 0onnez l'ordre de cratIon SQL quI permet de crer la relatIon
LIgne_Cmd(NoCmd, Cat, NoArt, rserv, prIx)
avec les clauses sur toutes les contraIntes d'IntgrIt
6) magInez une rI quI exIsteraIt dans le champ d'applIcatIon telle que:
a) une prImItIve de la relatIon Commande feraIt partIe de la porte de
cette rI et
b) cette rI ne pourraIt pas tre prIse en compte lors du CFEATE de la
relatIon Commande
Requtes
1) LIste des artIcles des confIguratIons ddIes la CAD par ordre croIssant
du prIx de la confIguratIon, de la catgorIe et du numro de l'artIcle.
2) 0onner les prIx actuels des crans en couleur
J) 0onner le lIbell des usages pour lesquels le nombre de logIcIels dpasse
20.
4) EtablIr la lIste des commandes dont le dlaI de lIvraIson a t dpass
(date1date2 = nbr de jours) ou est Inconnu
5) 0onner la prIode ou l'ImprImante no 100 a atteInt son prIx le plus bas
6) Chercher les noms et prnoms des clIents quI ont achet des artIcles,
lors d'une commande, sans acheter de CPU
Rgles d'integrite
...Les confIguratIons proposes doIvent tre compatIbles... .
0onner Ia porte de cette rI en rempIIssant Ie tabIeau de contexte
suIvant (mettre une croIx sI Ia case appartIent Ia porte)

prImI
tIve/
relat
Ion
Ins
rer
supp
rIme
r

0onner une requte SQL quI permette de dtecter les confIguratIons quI
contIennent des IncompatIbIlIs (CPUImprImantes, CPUdIsques, etc...)
(IndIcatIon: commencer par dfInIr une vue quI assocIe une confIguratIon,
son CPU et ses autres artIcles)

0e U|L SQL J2J
22. DUI
La socIt 0UF (0IstrIbuteur UnIversel FranaIs) est, depuIs cInquante ans,
spcIalIse dans la dIstrIbutIon des lIvres et des revues. Elle joue le role
d'IntermdIaIre entre les dIteurs quI sont membres de son groupe et les
lIbraIres. Elle a faIt face plusIeurs tourmentes dans le pass: changement
de structures du march, chute des prIx, dIversIfIcatIon des servIces.
Actuellement, elle veut transformer son outIl de gestIon en un outIl d'aIde
la dcIsIon pour facIlIter le dImensIonnement des offIces (les lIbraIres
reoIvent chaque moIs un ensemble de lIvres d'offIce, qu'Ils payent maIs
qu'Ils peuvent retourner au dIstrIbuteur) quI sont envoys aux lIbraIres. Pour
cela, elle dsIre mettre au poInt une base de donnes. Les dIteurs et les
lIbraIres pourront y trouver les servIces suIvants:
ventes, retours pour chaque tItre, auteur
ventes, retours par rgIon
ventes, retours par genre lIttraIre
tre un outIl de gestIon des stocks
tre un outIl de gestIon fInancIer
Apres une premIere runIon, on a obtenu les InformatIons quI suIvent.
Le consultant pense qu'avec ces donnes, Il peut satIsfaIre les demandes
prIncIpales exprImes par la socIt.
Les dIteurs
Les dIteurs sont IdentIfIs par un numro d'dIteur NoEdIteur, on connat
pour chacun une raIson SocIale PaIsonSocIaIeEd, une adresse AdresseEd et
un soIde fInancIer reprsentant le total payer cet dIteur. Un dIteur
produIt des lIvres quI sont IdentIfIs par un numro de rfrence NoPef, on
connat pour chacun son tItre, son auteur, sa date de parutIon
datepubIIcatIon, son prIx de vente en lIbraIrIe prIxvente et son prIx de
dIstrIbutIon prIxdIstrIbutIon. Un lIvre peut tre assocI plusIeurs genres
(numro de genre Nogenre). Les auteurs sont IdentIfIs par un numro
d'auteur NoAuteur, on connat pour chacun son nom et son prnom.
L'dIteur lIvre prIodIquement des nouveaux ouvrages (ou des rdItIons)
pour rapprovIsIonner le stock de 0UF. Chaque lIvraIson est assocIe une
date et une quantIt.
Chaque dIteur possede un journal des crItures comptables quI luI sont
Imputables. Une crIture est assocIe un dIteur, un lIbell LIb, une date
d'opratIon date_op et un montant mnt.
Les IIbraIrIes
Les lIbraIrIes sont IdentIfIes par un numro de lIbraIrIe NoIIbraIrIe, on
connat pour chacune une raIson SocIale PaIsonSocIaIeLIb, une adresse
AdresseLIb et un soIde fInancIer reprsentant le total recevoIr de cette
lIbraIrIe.
Une lIbraIrIe effectue rgulIerement des transactIons avec 0UF. Chaque
transactIon est dcompose en lIgnes concernant un lIvre pour une certaIne
quantIt qte (on en dduIt un prIx) et un type de transactIon type_trans. La
transactIon est effectue une date dateTrans et TotaITrans rcapItule le
total des lIgnes de la transactIon.
Chaque lIbraIrIe possede un journal des crItures comptables quI luI sont
Imputables. Une crIture est assocIe une lIbraIrIe, un lIbell LIb, une date
d'opratIon date_op et un montant mnt.
Pour sImplIfIer l'tude, le consultant a faIt quelques Impasses sur les
payements en monnaIes trangeres, les reprsentants chargs du contact
avec les lIbraIres, ...
AdresseEd texte
AdresseLIb texte
datelIvraIson date
dateTrans date
date_op date
datepublIcatIon date
lIb mot ('payement','facture', ...)
lIbgenre mot ('socIologIe','roman','hIstoIre','art', ...)
mnt nombre
NoAuteur entIer [1..99999]
NoEdIteur entIer [1..99999]
NoCenre entIer [1..99999]
NoLIbraIrIe entIer [1..99999]
NoLIgne entIer [1..999]
nom mot ('0UPDNT', ...)
NoFef entIer [1..99999]
NoTrans entIer [1..99999]
prnom Texte
prIx nombre
prIxdIstrIbutIon nombre
prIxvente nombre
Qte entIer [999..999]
qte_lIvree entIer [99999..99999]
FaIsonSocIaleEd mot ('La renaIssance', 'KalImard...)
FaIsonSocIaleLIbmot ('Aux vIeux lIvres', ...)
0e U|L SQL J25
FegIon mot ('ParIs','Lyon','Canada',...
Solde nombre
TItre texte
TotalTrans nombre
type_trans mot ('dpot','offIce','retour','commande',...)

Relations
Auteur (NoAuteur, nom, prnom)
EdIteur (NoEdIteur, FaIsonSocIaleEd, AdresseEd, Solde)
EcrIture_Ed (NoEdIteur, date_op, LIb, mnt)
Duvrage (NoFef, TItre, NoEdIteur, NoAuteur, datepublIcatIon,
prIxvente, prIxdIstrIbutIon )
CenreDuvrage (NoFef, Nogenre)
Cenre (Nogenre, genre)
Stock (NoFef, datelIvraIson, qte_lIvree)
LIbraIrIe (NoLIbraIrIe, FaIsonSocIaleLIb, AdresseLIb, FegIon, Solde)
TransactIon (NoTrans, NoLIbraIrIe, dateTrans, TotalTrans)
LIgne_Trans (NoTrans, NoLIgne, NoFef, type_trans, Qte, prIx)
EcrIture_LIb (NoLIbraIrIe, date_op, LIb, mnt)

1) NoAuteur nom, prnom)
2) NoEdIteur FaIsonSocIaleEd, AdresseEd, Solde)
J) NoEdIteur, date_op mnt
4) NoFef TItre, NoEdIteur, NoAuteur, datepublIcatIon, prIxvente,
prIxdIstrIbutIon
5) Nogenre genre)
6) NoFef, datelIvraIson qte_lIvree
7) NoLIbraIrIe FaIsonSocIaleLIb, AdresseLIb, FegIon, Solde
8) NoTrans NoLIbraIrIe, dateTrans, TotalTrans
9) NoTrans, NoLIgne NoFef, type_trans, Qte, prIx
10) NoLIbraIrIe, date_op mnt
Cette premIere modlIsatIon prsente les dIteurs et les lIbraIres comme
deux entIts dIffrentes

La modlIsatIon suIvante ne faIt plus de dIstInctIon entre les dIteurs et les
lIbraIres.
Auteurs
NoAuteur : integer
Nom : string
Prenom : string
Genre
NoGenre : integer
LibelleGenre : string
LignesTrans
Qte : integer
NoLigne : integer
TypeTrans : string
Prix : real
Qte : integer
Editeurs
NoEditeur : integer
RaisonSocialeEd : string
AdresseEd : string
Solde : real
Ouvrages
NoReI : integer
DatePublication : date
PrixVente : real
PrixDistribution : real
Titre : string
Librairies
Solde : real
NoLibrairie : integer
RaisonSocialeLib : string
AdresseLib : string
Region : string
NoReI : integer
PrixVente : real
Solde : real
NoGenre : integer
EcrituresEdit
DateOp : date
Lib : string
Mnt : real
DateOp : date
Lib : string
Mnt : real
NoEditeur : integer
RaisonSocialeEd : string
AdresseEd : string
Solde : real
*
1
EcrituresLib
dateOp : date
Lib : string
Mnt : real
NoLibrairie : integer
RaisonSocialeLib : string
AdresseLib : string
Region : string
dateOp : date
Lib : string
Mnt : real
1
*
Stock
DateLivraison : date
qtelivree : integer
*
NoAuteur : integer
*
DateLivraison : date
1 *
qtelivree : integer
1
*
Titre : string
Nom : string
Prenom : string
*
*
Transactions
NoTrans : integer
DateTrans : date
TotalTrans : real
NoTrans : integer
DateTrans : date
TotalTrans : real
NoLigne : integer
TypeTrans : string
*
1
1
*
*
1
Prix : real
0e U|L SQL J27

Ouvrages
NoReI : integer
Titre : string
PrixVente : real
Genre
NoGenre : integer
NoReI : integer
Partenaires
NoPartenaire : integer
RaisonSociale : string
Adresse : string
Solde : real
NoPartenaire : integer
RaisonSociale : string
Adresse : string
Solde : real
Editeurs'
LignesTrans
NoLigne : integer
TypeTrans : string
Qte : integer
Prix : real
Transactions
NoTrans : integer
DateTrans : date
TotalTrans : real
NoTrans : integer
DateTrans : date
TotalTrans : real
1
*
*
1
Ecritures
dateOp : date
Lib : string
Mnt : real
dateOp : date
Lib : string
Mnt : real
*
1
*
1
NoLigne : integer
TypeTrans : string
Qte : integer
Prix : real
*
1
Librairies'
Regions : string Regions : string
*
*
NoGenre : integer
Auteurs
NoAuteur : integer
Nom : string
Prenom : string
Titre : string
PrixVente : real
*
*
NoAuteur : integer
Nom : string
Prenom : string

Semantique
le texte quI suIt:
L'dIteur NET (no 10) a lIvr 2000 lIvres de son dernIer ouvrage Java et
nternet (ref 12J) de James Sun (auteur 25). L'ouvrage est class dans les
genres technologIe (no 4) et InformatIque (no 7). Son prIx de dIstrIbutIon est
de 60 francs. L'dIteur a t crdIter de 20,000 francs pour avance sur
recette.
La lIbraIre CUTEN8EFC de Lyon (n0 JJJ) reu son offIce du moIs (1.7.96)
pour une valeur de 12400 francs (transactIon 555), on y trouvaIt 10
exemplaIres de Java et nternet. Cette transactIon a faIt l'objet d'une
facture.

1ables type
Auteur NoAuteur nom prnom

EdIteur NoEdIteur FaIsonSocIaleEd AdresseEd Solde

EcrIture_Ed NoEdIteur date_op LIb mnt

Duvrag
e
NoFe
f
TItr
e
NoEdIteu
r
NoAuteu
r
datepublIcatIo
n
prIxvent
e
prIxdIstrIbutIo
n

CenreDuvrage NoFef Nogenre

Cenre Nogenre genre

Stock NoFef datelIvraIson qte_lIvree

LIbraIrIe NoLIbraIrIe FaIsonSocIaleLIb AdresseLIb FegIon Solde

TransactIon NoTrans NoLIbraIrIe dateTrans TotalTrans

LIgne_Trans NoTrans NoLIgne NoFef type_trans Qte prIx

0e U|L SQL J29

EcrIture_LIb NoLIbraIrIe date_op LIb mnt

Sur la modelisation
modlIsatIon (domaIne des constItuants, relatIons et dpendances
fonctIonnelles).

Un lIvre peutIl tre crIt par plusIeurs auteurs:
o sI ouI comment socker IntroductIon C crIt par A.dunIx et
8.Chelle:
o sI non comment modIfIer le schma des relatIons et des df:
EcrIture_LIb et EcrIture_Ed sont tres semblables peuton faIre une
fusIon et sous quelles condItIons :
ExplIcIter toutes les dpendances d'InclusIon vrIfIer sur la
0onner la requte SQL quI permet de crer la relatIon :
Duvrage (NoFef, TItre, NoEdIteur, NoAuteur, datepublIcatIon,
prIxvente, prIxdIstrIbutIon )
avec les clauses sur toutes les contraintes d'intgrit
magIner une regle d'IntgrIt dont le contexte seraIt [Auteur,
Duvrage, EdIteur] maIs que l'on ne peut exprImer lors de la cratIon du
schma (pas un check, prImary key, ou une foreIgn key ...).
Requtes
(tracez les motscls nonutIlIss sI ncessaIre)
1) 0onner la lIste des rfrences par ordre croIssant de la date de
publIcatIon.
2) 0onner le nom et le prnom des auteurs ayant publI chez NET en
1996.
J) 0onner le nombre total d'exemplaIres vendus de Java et nternet
en juIn 1996.
4) 0onner le chIffre d'affaIre des ventes par rgIon en 1995.
5) 0onner la lIste des rfrences ayant un retour de plus de 50 (2
lIvres plus (qte posItIve) de 1 retourne (qte ngatIve) )
Rgles d'integrite
Pour vIter des abus sur les retours, 0UF veut attrIbuer un maxImum de
retours par genre (Cenre (Nogenre, genre, max_retour))
0onner la porte de cette rI en remplIssant le tableau de contexte suIvant

prImItIve/
relatIon
Insrer supprIm
er
maj maj maj maj maj maj

EcrIre une vue permettant de retrouver les anomalIes sur maxImum de
retour.

0e U|L SQL JJ1
23. IAML
Lnonce
Fame
22
est une cole clebre quI forme de jeunes danseurs, musIcIens et
comdIens. Fpute pour son srIeux et son nIveau lev, elle attIre les
jeunes du monde entIer. Crce au dynamIsme de la dIrectrIce de l'cole,
Fame n'a cess de s'agrandIr et de se dvelopper ces dernIeres annes:
augmentatIon du nombre des salles, dIversIfIcatIon des cours,
renouvellement du matrIel, augmentatIon du nombre d'tudIants et
d'enseIgnants. 7IctIme de ce succes, la dIrectrIce de l'cole a de la peIne
grer toutes ces InformatIons. 0es amIs luI conseIllent d'utIlIser un systeme
de gestIon de bases de donnes relatIonnel pour stocker et manIpuler les
donnes de l'cole. Elle faIt donc appel des InformatIcIens de gestIon et
leur dcrIt le champ d'applIcatIon suIvant au cours d'une runIon:
L'cole offre troIs fIlIeres: danse, musIque et thtre. Elle dcerne des
dIplomes dans chacune de ces fIlIeres (p.ex: danse classIque, art
dramatIque, etc...). Un dIplome est IdentIfI par un sIgle (SIgIe0Ip) et Il a
un lIbell (LIb0Ip). l est rattach une fIlIere (FIIIre). Son obtentIon
ncessIte un nombre mInImum de crdIts (NbCrdIts).
Le plan d'tudes d'un dIplome est compos d'un ensemble de cours. Un cours
est IdentIfI par un numro (NoCours). l possede un tItre (TItre) et Il est
rattach une fIlIere (p.ex: le cours de ballet est rattach la fIlIere
danse). Lorsqu'un cours est dans le plan d'tudes d'un dIplome, Il est
oblIgatoIre ou optIonnel (Type) et Il est pondr par un nombre de crdIts
(CrdIts). Un cours d'une fIlIere peut fIgurer dans le plan d'tudes d'un
dIplome rattach une autre fIlIere (p.ex: le cours ballet est un cours
optIon pour le dIplome art dramatIque de la fIlIere thtre).
L'cole comporte vIngt salles. Chaque salle est IdentIfIe par un numro
(NoSaIIe), dcrIte par un lIbell (LIbeIISaIIe) et contIent du matrIel
(EquIpement). Un cours est donn par un enseIgnant dans une salle de
l'cole; l'enseIgnant et la salle peuvent changer d'une anne une autre.
Chaque enseIgnant est IdentIfI par un numro (NoEnseIgnant). Dn connat
son nom (Nom), son prnom (Prnom), sa natIonalIt (Pays) et son adresse
(AdresseE).
Un tudIant est IdentIfI par un numro d'ImmatrIculatIon (NoImmat). l a un
nom (Nom), un prnom (Prnom), une natIonalIt (Pays) et une adresse
(Adresse). l s'InscrIt en une anne (AnneIns) un dIplome et l'obtIent plus
tard (AnneDbt) avec une mentIon (hentIon). Un tudIant ne peut pas

22
L'nonc de base de ce travaIl est due LIna AljadIr (et est un fIlm connu des annes
80)
effectuer deux dIplomes en mme temps. Par contre, Il peut commencer un
deuxIeme dIplome apres avoIr termIn le premIer. l se peut qu'un tudIant
n'obtIenne pas son dIplome (Interrompu) en raIson d'un dpart volontaIre ou
d'une exclusIon.
Pour obtenIr son dIplome, un tudIant doIt suIvre tous les cours oblIgatoIres
du plan d'tudes correspondant et un certaIn nombre de cours optIon pour
totalIser un nombre de crdIts gal ou suprIeur celuI requIs par son
dIplome. Un tudIant obtIent les crdIts d'un cours unIquement s'Il russIt
l'examen de ce cours en fIn d'anne (PussIte). S'Il choue, l'tudIant peut se
rInscrIre et passer l'examen l'anne suIvante. S'Il choue la deuxIeme
tentatIve, Il est exclu de l'cole.
Adresse texte
Anne entIer [1950..2200]
Annens entIer [1950..2200]
AnneDbt entIer [1950..2200]
CrdIts entIer [5..10]
EquIpement texte
FIlIere mot (danse, musIque, thtre)
nterrompu mot (dpart, exclusIon)
LIbell0Ip texte
LIbellSalle texte
|entIon mot (sans_mentIon, assez_bIen, bIen, tres_bIen)
NbCrdIts entIer [60..100]
NoCours entIer [1..99]
NoEnseIgnant entIer [1..99]
Nommat texte
Nom mot
NoSalle entIer [1..20]
Pays mot
Prnom mot
FussI mot (ouI, non)
SIgle0Ip mot
TItre texte
Type mot (oblIgatoIre, optIonnel)
0e U|L SQL JJJ
Diagramme de classes

Relations
0Iplome (SIgle0Ip, LIbell0Ip, FIlIere, NbCrdIts)
Cours(NoCours, TItre, FIlIere)
PlanEtudes(SIgle0Ip, NoCours, Type, CrdIts)
Diplome
SigleDip : string
LibelleDip : string
NbCredits : integer
Cours
NoCours : integer
Titre : string Planetudes
Type : string
Credits : integer
Salles
NoSalle : integer
LibelleSalle : string
Equipement : string
NoCours : integer
Titre : string
Type : string
donne par
*
NoSalle : integer
LibelleSalle : string
Equipement : string
InscriptionDip
AnneeIns : integer
AnneeObt : integer
Interrompu : string
Mention : string
InscriptionCours
Annee : integer
Reussi : boolean
AnneeIns : integer
AnneeObt : integer
Interrompu : string
SigleDip : string
LibelleDip : string
NbCredits : integer
Personnes
NoPers : integer
Nom : string
Prenom : string
Pays : string
Adresse : string
Etudiants Enseignants
NoPers : integer
Nom : string
Prenom : string
Pays : string
Adresse : string
1
* *
Mention : string
Annee : integer
Reussi : boolean
1
*
*
* *
Planning
Annee : integer Annee : integer
1
*
dans
*
*
Filires
Filiere : string Filiere : string
Credits : integer
1
1
*
Salle(NoSalle, LIbellSalle, EquIpement)
EnseIgnant (NoEnseIgnant, NomE, PrnomE, PaysE, AdresseE)
HoraIre (NoCours, AnneH, NoEnseIgnant, NoSalle)
EtudIant (Nommat, Nom, Prnom, Pays, Adresse)
nscrIptIon0Ip(Nommat, Annens, SIgle0Ip, AnneDbt, |entIon, nterrompu)
nscrIptIonCours(Nommat, NoCours, Anne, FussI)
1) SIgle0Ip LIbell0Ip, FIlIere, NbCrdIts
2) NoCours TItre, FIlIere
J) SIgle0Ip, NoCours Type, CrdIts
4) NoSalle LIbellSalle, EquIpement
5) NoEnseIgnant NomE, PrnomE, PaysE, AdresseE
6) NoCours, AnneH NoEnseIgnant, NoSalle
7) Nommat Nom, Prnom, Pays, Adresse
8) Nommat, Annens SIgle0Ip, AnneDbt, |entIon, nterrompu
9) Nommat, SIgle0Ip Annens, AnneDbt
10) Nommat, NoCours, Anne FussI
Semantique
le texte quI suIt:
0ans la fIlIere danse fIgure le dIplome danse contemporaIne. l a le sIgle
0CL et ncessIte 110 crdIts.
Son plan d'tudes contIent les cours oblIgatoIres ballet 1 (no 54), ballet 2
(no 52), musIque contemporaIne 1 (no 24), et le cours optIon art
moderne (no 10). Les deux premIers sont rattachs la fIlIere danse,
tandIs que le troIsIeme et le quatrIeme sont dans la fIlIere musIque et
thtre respectIvement.
Le cours ballet 1 est donn cette anne par |me JulIa 0urand (no 7) la
salle de danse (no 15) quI est quIpe d'un lecteur C0.
L'tudIante japonaIse Sue SuzukI (no 9911), quI s'est InscrIte au dIplome
danse comptemporaIne en 1999, suIt cette anne les cours ballet 2 et art
moderne.

0Iplome SIgle0Ip LIbell0Ip FIlIere NbCrdIts

Cours NoCours TItre FIlIere
0e U|L SQL JJ5

PlanEtudes SIgle0Ip NoCours Type CrdIts

Salle NoSalle LIbellSalle EquIpemen
t

EnseIgnant NoEnseIgnant NomE PrnomE PaysE AdresseE

HoraIre NoCours AnneH NoEnseIgnant NoSalle

EtudIant Nommat Nom Prnom Pays Adresse

nscrIptIon0Ip Nommat Annens SIgle0Ip AnneDbt |entIon nter
rompu

nscrIptIonCours Nommat NoCours Anne FussI

Sur la modelisation
Fpondre aux questIons suIvantes en basant vos arguments unIquement sur
la modlIsatIon (domaIne des constItuants, relatIons et dpendances
fonctIonnelles).
SI toutes les InformatIons taIent mIses dans une seule.relatIon FU,
quelle(s) cl(s) auraIt cette relatIon (la relatIon unIverselle)
EstIl possIble d'obtenIr la relatIon FU, au moyen des relatIons du
schma par composItIon.:
ExplIcIter toutes les dpendances d'InclusIon vrIfIer sur la
0onner la requte SQL quI permet de crer la relatIon
HoraIre (NoCours, AnneH, NoEnseIgnant, NoSalle)
avec Ies cIauses sur toutes Ies contraIntes d'IntgrIt
magIner une regle d'IntgrIt dont le contexte seraIt [HoraIre, Cours]
quI ne soIt pas une dpendance d'InclusIon.
Repondre en SQL aux questions suivantes:
0onner la lIste des dIplomes par ordre croIssant du nombre de crdIts.
0onner le nom et le prnom des tudIants ayant obtenu un dIplome en
1994.
0onner le tItre, la fIlIere et le crdIt des cours optIonnels du dIplome
danse classIque.
0onner le nombre d'tudIants InscrIts en 95 pour chaque cours.
0onner le tItre des cours quI ne sont oblIgatoIres dans aucune fIlIere.
Vues
EcrIre une requte SQL quI permet de crer la vue SItuatIonActuelle. Cette
vue donne pour un tudIant InscrIt actuellement un dIplome le nombre de
crdIts qu'Il a totalIss jusqu' prsent pour ce dIplome.
Rgles d'integrite
Un tudIant ne peut obtenIr son dIplome que sI la somme des crdIts des
cours qu'Il a russIs est suprIeure ou gale celle demande par son
dIplome.
0onner la porte de cette rI en remplIssant le tableau de contexte
suIvant (mettre une croIx sI la case appartIent la porte)
prImItIve/
relatIon
Insrer supprImer maj maj maj maj maj maj

CItez et explIquez quelles sont les opratIons quI pourraIent paratre
partIculIerement Injustes et cruelles aux yeux des leves ayant russI
un cours et que devraIt s'InterdIre la dIrectIon de l'cole :
EcrIre un trIgger correpondant une croIx du tableau de contexte
(rutIlIser la vue sItuatIonActuelle!).
0e U|L SQL JJ7
24. LLLC1A
La socIt de sondage ELECTA est spcIalIse dans l'tude des rsultats
concernant des votatIons natIonales. Dn luI a command une tude sur les
dernIeres votatIons franaIses.
ELECTA dans une phase de nouveaux dveloppements InformatIques a
entreprIs l'tude d'une base de donnes permettant de grer les InformatIons
ncessaIres ces analyses.
Le texte quI suIt est une descrIptIon du champ d'applIcatIon tel qu'Il apparat
la suIte d'une tude avec les analystes (les mots en style gras sont les
constItuants quI sont retenus dans la modlIsatIon)
ExtraIt du rapport
La France est dcoupe en dpartements (LIb0ept) ayant un numro (0ept).
Les dpartements sont dcoups en cIrconscrIptIons (LIbCIrc) ayant un
numro (CIrc). Les bureaux de votes (urVot) sont attachs aux
cIrconscrIptIons.
Le monde polItIque est dcoup en dIffrentes appelatIons (ApPoI) ayant
chacune un sIgle (SIg). Les candIdats (Cand) ont un nom (Nom) et un Prnom
(Prnom). Une votatIon est IdentIfIe par son anne (EIecAn), elle a lIeu en
deux tours (Tour). Dn compte le nombre d'lecteurs (NbEIect), le nombre de
votants (NbVot), le nombre d'abstentIons (NbAbs) et le nombre de voIx pour
chaque candItat (NbvoIx). Par cIrconscrIptIon, un seul candIdat est lu
(CandEIu)
ApPoI texte
urVot entIer
Cand entIer
CandEIu entIer
CIrc entIer
0ept entIer [1..95]
EIecAn entIer [9J, 97, ...]
LIbCIrc texte
LIb0ept texte
NbAbs entIer
NbEIect entIer
NbvoIx entIer
NbVot entIer
Nom mot (|Ignon, 0urand, ...)
Prnom mot (jean, paul, anne, ...)
SIg mot (FPF, U0F, PS, PP|, ...)
Tour entIer[1..2]
Diagramme de classes

Qui dit que la democratie cèst simple !
Relations
ureauVote (EIecAn, Tour, urVot, CIrc, NbEIect, NbVot, NbAbs)
CIrconscrIptIon (CIrc, LIbCIrc, 0ept, LIb0ept)
PoIItIque (SIg, ApPoI)
CandIdat (Cand, Nom, Prnom)
InscrIptIon (EIecAn, Cand, SIg, CIrc)
Dpartements
Dept : integer
Libdept : string
BureauxVote
BurVot : string
PartiPolitiques
Sigle : string
ApPol : string
Rsultats
NbVoix : integer
Tour : integer
inscription
* *
AnneElectorale
ElecAN : integer ElecAN : integer
Sigle : string
ApPol : string
*
*
*
*
Circonscriptions
Libcirc : string Libcirc : string
Dept : integer
Libdept : string
*
*
*
1
1
*
Candidats
Prenom : string
Nom : string
NbVoix : integer
Tour : integer
Prenom : string
Nom : string
*
resultat
*
elu
*
Votation
NbElect : integer
NbVot : integer
NbAbs : integer
Tour : integer
NbElect : integer
NbVot : integer
NbAbs : integer
Tour : integer
BurVot : string
*
1
0e U|L SQL JJ9
PesuItatTour (EIecAn, Tour, urVot, Cand, NbvoIx )
PesuItatEIec (EIecAn, CIrc, CandEIu)
Z (CandEIu, Cand)
1. ElecAn, Tour, 8ur7ot NbElect, Nb7ot, NbAbs
2. 8ur7ot CIrc
J. CIrc LIbCIrc, 0ept
4. 0ept LIb0ept
5. SIg ApPol
6. Cand Nom, Prnom
7. ElecAn, Cand SIg, CIrc
8. ElecAn, Tour, 8ur7ot, Cand NbvoIx
9. ElecAn, CIrc CandElu
10. CandElu Cand
Sur la modelisation
1)
a) ExplIquez ce que sIgnIfIe NbvoIx dans la relatIon PesuItatTour,
en utIlIsant les df pour supporter votre explIcatIon.
b) Le calcul 100 * NbvoIx l NbEIect, pour une cIrconscrIptIon et un
rsultat de tour, reprsentet'Il le pourcentage de voIx obtenu par
ce candIdat pour cette cIconscrIptIon :

2) 0termInez sI la dcomposItIon est totale

A
p
P
o
l
B
u
r
V
o
t
C
a
n
d
C
a
n
d
E
l
u
C
i
r
c
D
e
p
t
E
l
e
c
A
n
L
i
b
C
i
r
c
L
i
b
D
e
p
t
N
b
A
b
s
N
b
v
o
i
x
N
b
V
o
t
N
o
m
P
r
n
o
m
S
i
g
T
o
u
r
N
b
E
l
e
c
t

ureauVote

CIrconscrIp.

PoIItIque

CandIdat

InscrIptIon

PesuItatTour

PesuItatEIec

Z

J) 0onnez le chemIn de composItIon (pour retrouver la relatIon
unIverselle) auquel vous tes arrIv
4) ExplIquez le role de Z (dans l'algorIthme de dcomposItIon totale).
0oIton rellement socker Z sI l'on saIt que CandElu = Cand
5) La relatIon cIrconscrIptIon n'est pas en troIsIeme forme normale.
ExplIquez pourquoI.
a) En termes d'anomalIes de mIse jour
b) En termes de df
6) UtIlIsez le thoreme de la dcomposItIon bInaIre pour dcomposer la
relatIon cIrconscrIptIon.
7) les les contraIntes rfrencIelles suIvantes sont vrIfIer:
a) InscrIptIon [dentAssur] PoIItIque [SIg]
b) InscrIptIon [Cand] CandIdat [Cand]
nous devons effectuer les prImItIves suIvantes
1) Insert Into CandIdat ( 888,'|oI', 'ElIe');
2) Insert Into InscrIptIon (1999, 888, 'PL', 789);
3) Insert Into PoIItIque ('PL','PartI LIbre');
ndIquer dans le tableau suIvant la premIere regle quI n'est pas valIde
ou sI la squence est ok

squence de
prImItIves
ne valIde pas a) ne valIde pas b) ok
12J
1J2

J12

21J

2J1

J21

8) La base de donnes utIlIse par ELECT ne possede pas la possIbIlIt de
vrIfIeer automatIquement les contraIntes rfrencIelles. 0onner pour
l'exemple suIvant la porte de la contraInte: Tous les InscrIptIons sont
attachs un candIdat quI exIste. 0onner la porte de cette rI en
remplIssant le tableau de contexte suIvant (mettre une croIx sI la case
appartIent la porte)

prImItIve/
relatIon
Insrer supprImer maj maj maj maj maj maj

0e U|L SQL J41
2S. CONILR
Lnonce
CDNFEF est une assocIatIon quI organIse des confrences dans dIffrents
domaInes, pour le compte de dIffrents groupes de recherche. CDNFEF
organIse toute la confrence pour ces groupes depuIs la dIstrIbutIon des
appels aux contrIbutIons jusqu' la locatIon des salles. AfIn de rester
comptItIf, le conseIl d'admInIstratIon de CDNFEF s'est Interrog sur
l'opportunIt de ralIser l'organIsatIon des confrences entIerement avec les
outIls d'nternet.
A cette fIn, Ils ont engag une procdure d'analyse de l'exIstant. Et Ils se
sont plus partIculIerement concentrs sur la soumIssIon des papIers.
ls ont trouv que les acteurs de cette actIvIt soumettre des papIers
taIent:
les auteurs (ceux quI soumettent les papIers)
les rfrs (ceux quI commentent et jugent les papIers)
Le scnarIo retenu est gnralement le suIvant:
L'auteur reoIt un appel soumettre un papIer une confrence (une
publIcIt)
L'auteur envoIe une lettre d'IntentIon de communIquer un papIer
Le comIt d'organIsatIon luI envoIe des InformatIons sur la forme de la
communIcatIon (nbr de mots, format, ...)
L'auteur envoIe son papIer en 4 exemplaIres
Apres la date de soumIssIon, le comIt d'organIsatIon se runIt et
dtermIne sur la base d'une lIste de rfrs, l'attrIbutIon des papIers
aux rfrs.
Dn envoIe chaque rfr un ensemble de papIers, avec une fIche
d'valuatIon pour chaque papIer.
Chaque rfr renvoIe les fIches d'valuatIon remplIes avec
d'ventuelles annotatIons sur les papIers
Le comIt scIentIfIque se runIt pour slectIonner les papIers pour la
confrence. Chaque papIer est soIt accept soIt refus.
Le comIt scIentIfIque communIque son travaIl au comIt
d'organIsatIon.
Le comIt d'organIsatIon renvoIe aux auteurs les fIches d'valuatIon et
les papIers annots par les rfrs aInsI que la dcIsIon d'acceptatIon
ou de refus
Les auteurs accepts renvoIent une copIe dfInItIve de leur papIer
pour l'ImpressIon des actes de la confrence.
...
Questions
1) 0crIvez ce scnarIo avec un graphe utIlIsant les symboles des
usecase
2) A partIr du graphe, dfInIssez la responsabIlIt du comIt
scIentIfIque aInsI que les objets avec lesquels Il travaIlle.
J) 0crIvez comment avec les outIls nternet (Web, emaIl, ...) et les
bases de donnes, Il est peuttre possIble de satIsfaIre CDNFEF.

0e U|L SQL J4J
26. 39,2 Le matin
Lnonce
|onsIeur l'admInIstrateur se trouvaIt assIs derrIere son bureau, un
observateur extrIeur auraIt pu penser qu'Il rvaIt. En faIt Il pensaIt la
rdactIon d'une tude qu'Il devaIt envoyer la semaIne prochaIne aux moyens
et coordInatIons de l'InformatIque admInIstratIve quI supervIsaIt l'ensemble
des projets InformatIques.
L'admInIstratIon de cette cole de commerce avec ses deux mIlle leves, ses
cInq cents enseIgnants n'allaIt pas toujours toute seule, car les moyens en
personnel taIent lImIts quatre secrtaIres. La seule chappatoIre
semblaIt tre l'InformatIsatIon d'un certaIn nombre de tches rptItIves.
Le poInt le plus chaud de l'anne taIt la rentre et sa prparatIon. Une foIs
l'horaIre tablI, tche quI consIstaIt satIsfaIre les contraIntes d'horaIres
des enseIgnants et celles des cours du plan d'tude de chaque degr, Il
fallaIt tablIr deux types de documents :
le plan des cours par classe, un pour chaque leve;
l'horaIre de l'enseIgnant.
l se pencha pour examIner les documents, Ils taIent IdentIques dans leur
prsentatIon, sous forme de grIlle horaIre :
Les jours taIent (LU, |A, |E, 7E, SA).
Les tranches horaIre
1 : 08h.00 08h.45
2 : 08h.50 09h.J5
J : 10h.00 10h.45
4 : 10h.50 11h.J5
5 : 14h.00 14h.45
6 : 14h.50 15h.J5
7 : 15h.50 16h.J5
8 : 16h.50 17h.J5.
Le nom des enseIgnants fIguraIt sur certaIns documents.
La classe taIt note par un chIffre dsIgnant le degr et une lettre
(ex. JH). Les classes avaIent en moyenne 20 leves.
Les dIscIplInes (souvent abrges) : droIt, comptabIlIt, franaIs,
anglaIs, dactylographIe.
SI ce systeme InformatIque pouvaIt rpondre dIffrents types
d'InterrogatIons, Il y avaIt une actIvIt qu'Il fallaIt qu'Il assume, celle dont
s'occupaIt |me Xeres; Il s'agIssaIt du servIce des remplacements. En effet,
chaque jour Il fallaIt veIller ce que tous les cours soIent donns mme en
cas de maladIe d'un professeur. Et ce n'taIt qu'en dernIer recours que l'on
donnaIt cong aux leves.
Cette actIvIt l'InquItaIt un peu, car d'une part |adame Xeres allaIt partIr
la retraIte et que d'autre part elle exIgeaIt que la personne quI s'en occupe
arrIve avant tout le monde 7 heures pour prendre les messages (sur le
rpondeur tlphonIque) des matres quI taIent tombs malades depuIs la
veIlle. Et parmI les autres secrtaIres de l'cole aucune n'avaIt montr
d'Intrt pour cette tche quI n'taIt pas tres complexe, maIs quI demandaIt
de l'organIsatIon. Une foIs Il en avaIt parl avec |me Xeres quI luI avaIt
dclar :
7oIl comment je procede :
Le matIn j'arrIve, j'coute toute la bande du rpondeur et je note au
fur et mesure le nom des enseIgnants quI seront absents et la dure
suppose de leur absence, sI elle est connue.
EnsuIte je vaIs chercher la fIche de chaque enseIgnant et je repere
lesquels ont des heures d'enseIgnement cette journe. 8Ien entendu, Il
faut se proccuper des heures de la matIne en premIer lIeu.
Apres je vaIs consulter le fIchIer des remplaants. l y en a 200
envIron, maIs la dIffIcult est de trouver ceux quI sont dIsponIbles
pour la tranche horaIre consIdre car chacun suIt des cours
l'UnIversIt et Ils ne sont pas toujours dIsponIbles. 0e plus Il faut qu'Ils
soIent capables d'enseIgner la matIere. Heureusement que j'aI une
bonne mmoIre car ce fIchIer n'est pas pratIque; Il est class par ordre
alphabtIque et ne se prte pas ce type de recherche (voIr fIche en
annexe).
EnsuIte, je tlphone au remplaant pour vrIfIer s'Il luI est possIble
de donner ce cours et je luI IndIque l'heure des cours qu'Il doIt
remplacer, le degr de la classe et la dIscIplIne. Je luI donne aussI le
nom du professeur et son numro de tlphone pour qu'Il puIsse
prendre des renseIgnements sur le programme suIvre.
Souvent je doIs tlphoner plusIeurs remplaants car Ils ne sont pas
chez eux ou Ils effectuent dj des remplacements pour d'autres
coles.
Plus tard dans la journe, je recherche des remplaants satIsfaIsant
les mmes crIteres maIs sur une plus longue dure sI l'absence de
l'enseIgnant doIt se prolonger.
DuI, une bonne mmoIre se dIt l'admInIstrateur en examInant une fIche
type d'horaIre de classe. Le nombre de professeurs absents taIt
relatIvement faIble : de J, maIs en hIver ce chIffre pouvaIt monter jusqu'
8. En rsum, ce qu'Il luI fallaIt, c'taIt un systeme permettant de se
substItuer ce bac de cartes de remplaants quI taIt tres dIffIcIle utIlIser.
0e U|L SQL J45

fIgure 1 : fIche horaIre de classe
L'admInIstrateur commena rdIger sa demande et son analyse.
Nous vous demandons d'effectuer l'analyse que va faIre cet admInIstrateur. l
s'agIt d'analyser le champ d'applIcatIon, en partIculIer les dIffrents acteurs
et Intervenants et leurs actIvIts, de dcrIre les donnes quI doIvent tre
stockes, d'tablIr une modlIsatIon possIble de cellescI (en utIlIsant U|L
les cas d'utIlIsatIon, les classes et les objets) , d'envIsager les archItectures
InformatIques possIbles pour supporter et facIlIter ces actIvIts.

fIgure 2: fIche horaIre de professeur
LU

Dactylo
Franais
Franais

Anglais
Anglais
InIo
InIo
MA

Droit
Droit

Histoire
Compta
Compta
ME

Economie
Anglais
Anglais
Geographie
Compta
Compta
Steno
Steno
VE

Dactylo
Franais
Franais

Allemand
Allemand
Gestion
Gestion
SA

Math
Math
Economie
Economie
Tranche
Horaire
1
2
3
4
5
6
7
8
Horaire de classe
Numero de la classe : 3H
Horaire - ProIesseur

Nom: Hugo
Adresse: 15, avenue de France
MA

Histoire/3H
Franais/3G
Franais/3G
LU

Franais/3H
Franais/3H

ME

VE

Franais/3H
Franais/3H
Histoire/3G
SA

Franais/3G
Franais/3G
Tranche
Horaire
1
2
3
4
5
6
7
8
Prenom: Victor
Num.Tel. : 15.15.15

fIgure J: fIche du remplaant

Horaire - ProIesseur

Nom: .................... ...............
Adresse: ................ ................
Annee immatriculation : . .........
Falculte: ............... ................
Disciplines possibles :

Prenom: ................. ........
Num.Tel. : .............. ........
Licence : ............... ..........
MA

LU

ME

VE

SA

Tranche
Horaire
1
2
3
4
5
6
7
8
1) ...................... ....
2) ...................... ....
3) ...................... ....
4) ...................... ....
Table de disponibilite : (mettre une croix si disponible)
39,2 le matin
enseignant
remplacant
etudiant
organiser les remplacements
remplacer
Proposer ses services
Annoncer son absence
Actiivites de
39,2 le
matin
include~~
secretaire
0e U|L SQL J47

39,2 le matin
enseignant
remplacant
etudiant
organiser les remplacements
remplacer
Proposer ses services
Annoncer son absence
Actiivites de
39,2 le
matin
include~~
secretaire

fIgure: J9,2 le matIn
Classes
Idclasse : string
degre : integer
Tranches
heure : string
jour : string
Remplacants
anneeImatriculation : integer
repondre au telephone()
s'inscrire()
licence : string
decider()
Disciplines
discipline : string
anneeImatriculation : integer
repondre au telephone()
discipline : string
Prfrence
preIerence : integer preIerence : integer
rpondeur
messages : undeIined
ecouter()
enregistrer()
messages : undeIined
Personnes
nom : string
prenom : string
adresse : string
telephone : string
Enseignants
dateEngagement : Date
Enseignements
dateEngagement : Date
s'inscrire()
nom : string
prenom : string
adresse : string
telephone : string
*
donne 1
licence : string
ecouter()
enregistrer()
*
destine a
1
*
decider()
heure : string
jour : string
disponible
*
*
*
1
concerne
planiIie le
*
*
Idclasse : string
degre : integer 1
0e U|L SQL J49
27. QCM ligth

Une petIte rvolutIon secoue l'Agence NatIonale pour la ScurIt FoutIere
(ANSF) depuIs quelques moIs, l'ANSF a dcId d'InformatIser la gnratIon
des examens thorIques du code de la route. Les examens, dj sous la
forme de QuestIonnaIres ChoIx |ultIples (QC|), seront entIerement
InformatIss. Une premIere tape consIste :
entrer dans une base de donnes, l'ensemble des questIons d'examen
par domaIne;
gnrer automatIquement des QC|;
Installer des salles d'examen InformatIses.
La seconde tape prvoIt:
l'tude statIstIque des rponses;
l'dItIon d'un logIcIel grand publIc (accompagnant le code de la route);
une tude sur la pdagogIe.
Une prtude a tablI les InformatIons quI suIvent:
L'enseIgnement est rpartI en dIffrentes catgorIes (CD0E, PFDFTE,
SECDUFS|E, ...) IdentIfIes par d_0omaIne. A chaque domaIne, on assocIe
un lIbell LIb_0omaIne. Selon l'Importance du domaIne, un nombre mInImal
Nbr_|In_questIons de questIons est exIg pour chaque domaIne.
Chaque domaIne est couvert par un ensemble de questIons possIbles (Un
QC| est un sousensemble de ces questIons). Une questIon est IdentIfIe par
un numro d_QuestIon. L'nonc de la questIon est un texte LIb_QuestIon.
Une questIon est assocIe un seul domaIne. Un renvoI A_revoIr prcIse la
ou les pages quI concernent cette questIon. Un nIveau de dIffIcult
NIveau_dIffIcult de 1 10 value chaque questIon.
A chaque questIon est assocI un ensemble de rponses possIbles. Une seule
rponse est correctE. Une rponse est IdentIfIe d_Feponse par A, 8, C , ...
(une des possIblIts du QC|). L'nonc de la rponse est un texte
LIb_Feponse. Une rponse est assocIe une seule questIon. Pour chaque
rponse, on value sI elle est juste (ouI/non).
Les InformatIons dcrItes cIdessus permettent de dcrIre, pour chaque
domaIne, un ensemble de questIons et leurs rponses. A partIr de ces
InformatIons, Il est possIble de gnrer des QC|.
Un QC| est IdenfI par un numro d_QC|. Dn luI assocIe la date de
l'examen 0ate_examen pour lequel Il a t cr. Les questIons du QC| sont
numrotes de 1 100 No_QuestIon_QC|. Chaque questIon du QC| est
assocI une seule questIon possIble d'un des domaInes enseIgns.
Un examen est l'ensemble des rponses apportes par une personne un
QC|. 0onc chaque QC| faIt l'objet d'un ensemble d'examens.
Une personne est IdentIfIe par numro d_Personne. Une personne porte un
prnom et un nom. Un examen est remplI par une seule personne et porte
sur un seul QC|. Pour chaque questIon, de l'examen, on conserve les
rponses de la personne. Ces dernIeres permettent de donner un rsultat
l'examen resultat_obtenu.

A_revoIr texte
0ate_examen date
d_0omaIne mot (CD0E, PFDFTE, SECDUFS|E, ...)
d_personne entIer [1..9999999]
d_QC| entIer [1..9999]
d_QuestIon entIer [1..9999]
d_Feponse mot (A, 8,C)
Juste mot (ouI, non)
LIb_0omaIne texte
LIb_QuestIon texte
LIb_Fponse texte
Nbr_|In_questIons entIer [J..10]
NIveau_dIffIcult entIer [1..10]
nom texte
No_QuestIon_QC| entIer [1..100]
prenom texte
resultat_obtenu entIer [0..100]
Relations
0omaInes_EnseIgns (d_0omaIne, LIb_0omaIne, Nbr_|In_questIons)
QuestIons_PossIbles(d_QuestIon, LIb_QuestIon, d_0omaIne,
NIveau_dIffIcult, A_revoIr)
Feponses_PossIbles(d_QuestIon,d_Feponse, LIb_Fponse, Juste)
QC|(d_QC|, 0ate_examen)
QuestIon_QC|(d_QC|, No_QuestIon_QC|, d_QuestIon)
Personnes( d_personne, nom, prenom)
Examen(d_personne, d_QC|, resultat_obtenu)
Feponses_Examen(d_personne, d_QC|, No_QuestIon_QC|, d_Feponse)

0e U|L SQL J51
1) d_0omaIne LIb_0omaIne, Nbr_questIons
2) d_QuestIon, LIb_QuestIon, d_0omaIne, NIveau_dIffIcult, A_revoIr
J) d_QuestIon,d_Feponse LIb_Fponse, Juste
4) d_QC| 0ate_examen
5) d_QC|, No_QuestIon_QC| d_QuestIon
6) d_personne nom, prenom
7) d_personne, d_QC| resultat_obtenu
8) d_personne, d_QC|, No_QuestIon_QC| d_Feponse)
Semantique
PempIIr Ies tabIes correspondant aux Instances des reIatIons afIn
d'exprImer Ie texte quI suIt:
Caston LeFoux (personne12J) rpondu la JJeme questIon de son examen
QC| (144) par le choIx 8.
La JJeme questIon de ce QC| est la qestIon (numro 4500) quI
appartIennent au domaIne SCNALSATDN. Son nonc est L'InterdIctIon de
cIrculer est un panneau. Son nIveau de dIffIcult est J.
Les rponses choIx sont:
A) cIrculaIre, avec un bord blanc et un fond rouge (faux)
8) cIrculaIre, avec un bord rouge et un fond blanc (juste)
Un QC| comporte au mInImum 10 questIons sur le domaIne SCNALSATDN.

0omaInes_enseIgns d_0omaIne LIb_0omaIne Nbr_|In_questIons

QuestIons_
PossIbles
d_QuestIon LIb_QuestIon d_0omaIne NIveau_
dIffIcult
A_revoIr

Feponses_PossIbles d_QuestIon d_Feponse LIb_Fponse Juste

QC| d_QC| 0ate_examen

QuestIon_QC| d_QC| No_QuestIon_QC| d_QuestIon


Personnes d_personne nom prenom

Examen d_personne d_QC| resultat_obtenu

Feponses_Examen d_personne d_QC| No_QuestIon_QC| d_Feponse

Questions de modelisation
CompIter Ie schma quI suIt en pIaant Ies assocIatIons manquantes et
en donnant des cardInaIIts en rapport avec notre nonc.

REPONSESPOSSIBLES
ID_REPONSE
LIB_REPONSE
QUESTIONSPOSSIBLES
ID_QUESTION
LIB_QUESTION
NIVEAU_DIFFICULTE
A_REVOIR
QUESTIONSDUQCM
NO_QUESTION_QCM
QCM
ID_QCM
DATE_EXAMEN
PERSONNES
ID_PERSONNE
PRENOM
NOM
EXAMEN
RESULTAT_EXAMEN
DOMAINESENSEIGNES
ID_DOMAINE
LIB_DOMAINE
NBR_QUESTIONS
0e U|L SQL J5J
Repondre en SQL
1) LIste des domaInes par ordre alphabtIque
2) LIste des personnes (Nom et prnom) ayant 0 faute.(100 poInts)
J) 0IffIcult moyenne des questIons possIbles par domaIne
4) LIste des questIons possIbles ayant aucune rponse possIble juste
(erreur de saIsIe)
5) LIbell des questIons et des rponses justes du QC| 144 par
ordre croIssant.
6) Quel est l'nonc de cette requte :
select a.id_qcm, sum(b.niveau_diffficult)
from Questions_du_QCM a , Questions_Possibles b
where a.id_question=b.id_question
group by a.id_qcm
order by sum(b.niveau_diffficult)
select nom, prenom
from Personnes p, Examen e, QCM q
where p.id_personne=e.id_personne
snd e.id_qcm=q.id_qcm
and q.date_examen between '1-jan-94' and '31-dec-94'
select nom, prenom, count(e.id_personne)
from Personnes p, Examen e
where p.id_personne=e.id_personne
group by nom, prenom
having count(e.id_personne) >=5

0e U|L SQL J55
28. ML1GL

(|enuIserIe En Tout Cenre et EbnIsterIe)

|ETCE
2J
est une entreprIse de menuIserIe, dont la plupart de l'actIvIt est
orIente dans l'quIpement des nouveaux btIments. Elle fournIt et pose
dans les Immeubles les cadres de porte, les portes, les cadres de fentre et
les armoIres. L'entreprIse est dIvIse en quatre dpartements :
le bureau technIque quI tablIt les soumIssIons et quI s'occupe des
nouvelles conceptIons;
l'atelIer quI commande les matIeres premIeres, fabrIque et prpare les
lments d'un contrat pass |ETCE;
le dpartement chantIer quI est charg du montage et de la pose des
lments dans les Immeubles;
le dpartement de gestIon quI s'occupe de la comptabIlIt et de la
gestIon admInIstratIve de l'entreprIse.
PV de Ia PunIon :
0ans le bureau du dIrecteur de |ETCE sont runIs le 0Irecteur (0), le
CestIonnaIre (C), le chef d'atelIer (A), le technIcIen (T) et le Chef de
chantIer (C) (dans le dIalogue quI suIt nous n'utIlIserons que l'InItIale des
personnages pour dsIgner celuI quI parle).
0 : 7ous n'Ignorez pas que nous avons, Il y a 6 moIs, prIs la dcIsIon de
fabrIquer nousmmes les armoIres et que nous avons effectu des
InvestIssements dans plusIeurs machInes spcIalIses. Avant cette dcIsIon,
nous achetIons chez AF|D8LDC les armoIres toutes quIpes que nous
n'avIons plus qu' poser. 0epuIs, nous achetons chez ACLD SA le boIs quI est
prdcoup et sur lequel nous faIsons toutes les opratIons ncessaIres
l'obtentIon d'une armoIre. Nous avIons sousestIm les dIffIcults de gestIon,
de coordInatIon et de calcul que demandent ces opratIons. 0es erreurs de
calcul, de fabrIcatIon nous ont oblIgs envoyer au rebut des lments de
chez ACLD SA car Ils n'avaIent pas les bonnes dImensIons ou bIen, comme
cela est arrIv sur le dernIer chantIer, dmonter une partIe des blocs dj
poss, car le perage pour fIxer la barre de penderIe taIt trop bas. 0e plus,
l'nervement et les heures supplmentaIres demandes par la gestIon de
cette nouvelle fabrIcatIon contrIbuent un mauvaIs clImat de travaIl. Je
comprends bIen que chacun de vous faIt de son mIeux et je tIens ce que la
bonne humeur quI rgnaIt dans notre entreprIse revIenne. |.C., que j'aI
engag Il y a deux ans pour restructurer et modernIser nos outIls de gestIon

2J
sujet labor avec le professeur JeanClaude Courbon
et d'analyse fInancIere, peut certaInement nous aIder dans ce cas aussI. l
peut nous effectuer une analyse de la sItuatIon, quI nous servIra ensuIte
comme cahIer des charges pour prendre contact avec des entreprIses de
servIces InformatIques. Cette faon de procder nous avaIt pargn bIen des
peInes, Il y a dj deux ans, lors de notre prIse de contact avec les
InformatIcIens purs. |.C., je vous laIsse la parole.
C : Je croIs que le plus sImple est de suIvre le parcours d'une armoIre depuIs
le dpart jusqu' sa pose. Du cela dbutetIl : (C sort un bloc et prend des
notes).
T : En ce quI concerne le bureau d'tude technIque, nous recevons les
demandes de soumIssIon, que nous effectuons sur plan ou apres vIsIte du
chantIer. La soumIssIon consIste tablIr le prIx dtaIll de l'ensemble
poser, celuIcI varIe en fonctIon du nombre de botes poser.
C : Qu'entendezvous par bote :
T : Une bote est l'lment le plus sImple d'un ensemble d'armoIres. Nous
mesurons la longueur totale de l'ensemble que nous dIvIsons en botes, selon
les dsIrs de l'archItecte, par exemple une longueur de 160 cm peut tre
dIvIse en troIs botes (60cm 50cm 50cm). Un autre poInt Important est la
sItuatIon de l'armoIre par rapport au mur, nous avons quatre cas :
(le technIcIen sort son stylo et dessIne).

fIgure 1 : sItuatIon d'un bloc d'armoIres
A : En effet, c'est Important car lors de la commande du boIs, Il faut en tenIr
compte car les cots vIsIbles doIvent tre aussI recouverts du stratIfI
demand par le clIent.
T : La couleur du stratIfI faIt partIe de la soumIssIon, car le prIx change en
fonctIon des couleurs, le blanc tant le moIns cher.
C : l y a quelque chose que ne ne comprends pas, sI l'on juxtapose des
botes, Il y a deux paroIs pour les partIes que se touchent, c'est une perte.
C : 7ous avez raIson, on parle de botes maIs en faIt Il s'agIt de botes sur
lesquelles Il manque le cot gauche, et quI ont aInsI une forme de C, sur la
dernIere on ajoute un panneau de termInaIson pour complter le tout.
Niche Angle gauche visible
Angle droit visible Arriere visible
0e U|L SQL J57
C. dessIne aussI !

fIgure 2 : assemblage d'un bloc d'armoIre
C : Ah ouI, je voIs, contInuons avec la soumIssIon.
T : 7oyons ! Un ensemble de botes a la mme hauteur, mme profondeur.
|aIs chaque bote a sa propre largeur et une ou deux portes. S'Il n'y a qu'une
porte Il faut prcIser sI elle s'ouvre gauche ou droIte. (l allume une
cIgarette.)
Je voIs que l'on a faIt le tour de l'extrIeur de la bote. |aIntenant, passons
son amnagement IntrIeur. L'archItecte doIt prcIser le nombre de
rayonnages par bote et sI ventuellement Il y a une penderIe. Dn est
complet :
C : DuI.
C : Comment s'tablIt le prIx de la soumIssIon :
T : C'est assez sImple, avec l'exprIence, nous avons prIs des temps de pose
et de fabrIcatIon moyens et nous nous sommes aperus que ceuxcI taIent
en fonctIon du nombre de portes d'une bote, nous comptons donc en portes.
par porte l'atelIer 1h.J0
et par porte sur le chantIer 2h.00.
C : A Fr. 52. l'heure d'ouvrIer, selon notre dernIere analyse.
T : DuI, c'est cela. L'autre lment Important est la surface de boIs utIlIse
Fr. 9,50 / m2 pour le blanc et des surplus pour les autres couleurs.
A : 7ous oublIez les garnItures, vIs, serrures, poIgnes et les gonds. Dn
compte envIron Fr. 40. de garnIture par bote.
T : 7ous avez raIson. Avec tous ces lments, on calcule le prIx de la
soumIssIon que l'on envoIe au clIent. TroIs cas se prsentent, Il accepte
cellecI, ou bIen Il la refuse et dans certaIns cas on nous demande certaInes
modIfIcatIons, ce quI nous oblIge tout recalculer. Les soumIssIons
comportent entre 50 et J00 botes.
C : DuI, c'est beaucoup de travaIl quand on saIt que nous avons effectu 450
soumIssIons l'anne passe et que nous avons 20 de taux d'adjudIcatIon pour
des soumIssIons.
0 : C'est, je pense, tres Important, de lImIter les InvestIssements en temps
humaIn dans les soumIssIons, tout en conservant une prcIsIon et une
comptItIvIt des prIx sur le march. Et en plus cela prend beaucoup de
place, ces dossIers, quand on pense que certaInes soumIssIons sont gardes
deux ans.
C : Quelqu'un veutIl un caf :
C;T;A : ouI, volontIers.
0 : DuI, je vaIs aller les chercher, je croIs que nous en avons termIn avec
les soumIssIons, contInuez sans moI. (Le dIrecteur sort).
T : DuI, des que la soumIssIon est accepte nous la transfrons l'atelIer.
A : C'est l que nous Intervenons, nous effectuons une commande ACLD SA
des dIffrents panneaux de boIs stratIfI en IndIquant les mesures dsIres
aInsI que la couleur. 0es que nous les rceptIonnons, nous les calIbrons, car
Ils sont dcoups grossIerement, ensuIte nous effectuons toutes les
opratIons de prparatIon l'assemblage, c'estdIre :
pose des charnIeres sur les portes;
perage des trous pour les rayonnages;
collage des bandes de stratIfI sur les bords apparents des panneaux;
et dIverses prparatIons concernant les dos des botes, les poIgnes ...
C : Du se sItuent les dIffIcults :
A : Elles sont sur les calculs des dIffrentes cotes de perage et sur les
dImensIons de panneaux commander. Les calculs sont sImples, maIs Il ne
faut pas oublIer des dtaIls comme de tenIr compte de l'paIsseur des
panneaux euxmmes. Ce travaIl est rptItIf et ennuyeux, et malgr son
Importance, Il arrIve que l'on se trompe.
C : Etesvous sI sur de sa sImplIcIt :
A : Dh ouI, pour l'apprentI j'aI prpar un schmatype, avec les dIffrentes
cotes, et les regles de calcul. l luI suffIt d'applIquer systmatIquement les
regles de calcul pour obtenIr les bonnes dImensIons.
C : Et que se passetIl ensuIte, lorsque tout est prpar :
C : C'est l'quIpe du chantIer quI travaIlle, elle passe au magasIn chercher les
garnItures :
8 vIs d'assemblage sImple par bote
1 poIgne par rayon
4 taquets par rayon
(les trIngles habIt sI ncessaIre).
Dn charge, bIen sur, les panneaux prpars sur un camIon et l'on va monter
le tout dans un Immeuble. (Le dIrecteur revIent avec les cafs.)
C : Quels sont les problemes quI peuvent apparatre sur le chantIer :
C : Normalement aucun sI toutes les tapes prcdentes se sont droules
correctement ... ParfoIs, on perd du temps reconnatre les lments d'une
bote, Il seraIt pratIque de pouvoIr tIqueter les pIles, pour sImplIfIer le
montage.
0 : DuI, c'est vraI. |aIs je croIs que les tapes en amont sont prIorItaIres. C,
avezvous suffIsamment d'InformatIon pour esquIsser un systeme
d'InformatIon assIstant la gestIon de cette nouvelle fabrIcatIon :
0e U|L SQL J59
C : Un dernIer poInt. QuI d'entre vous est susceptIble de se servIr d'un
systeme InformatIs mettre en place :
T : |oI, oblIgatoIrement pour grer toutes les soumIssIons et les contrats
sIgns.
A : Nous en aurons besoIn pour tablIr les commandes chez ACLD SA, maIs
aussI pour pouvoIr consulter les lments de rglage des machInes.
C : |oI, Il suffIt d'un lIstIng, surtout sI l'tIquetage est bIen faIt.
0 : C'est tout :
C : DuI, je pense. l est mIdI, je vaIs aller manger et je feraI cette analyse
cet apresmIdI. Et je propose que nous nous runIssIons 17 heures pour en
dbattre.
(Les gens se dIsent aurevoIr et partent manger. C ramasse un dessIn faIt
par A reprsentant un bloc d'armoIre).

fIgure J : un bloc d'armoIres
Nous vous demandons d'effectuer l'analyse que va faIre ce |onsIeur C., de
reconstruIre le parcours de cette armoIre, des dIffrents acteurs et
Intervenants, des tches qu'Ils effectuent, de dcrIre les donnes quI doIvent
tre stockes, de dcrIre une modlIsatIon possIble de cellescI, d'envIsager
les archItectures InformatIques possIbles pour supporter et facIlIter cette
nouvelle fabrIcatIon.
CertaInes InformatIons sont absentes du dIalogue, par exemple un clIent a
une adresse, un chantIer a une adresse, etc. Nous vous demandons de les
complter avec le bon sens, en mentIonnant nous faIsons l'hypothese que
.... Par aIlleurs, d'autres InformatIons peuvent tre Inconnues de |onsIeur
C., et nous vous demandons de dresser une lIste de questIons que devra
poser C. lors de la runIon 17 heures pour affIner son analyse.
bote 2 bote 1 bote n
largeur 1
largeur totale
hauteur
proIondeur

PaIsonSocIaIe texte
Accept boolen (DuI, Non)
Adresse entIer
CouIeur mot(blanc, rouge, vert, .)
0ateSoumIssIon date
0ebutTravaux date
FInTravaux date
Hauteur rel
Largeur rel
LargeurTotaIe rel
NbroIte entIer
NbreExempIaIreentIer
NbrePorte entIer [1..2]
NbrePayon entIer
NooIte entIer
NoChantIer rel
NoCIIent entIer
NoEnsembIe entIer
Boites
NoBoite : integer
Largeur : real
NbrePorte : integer
OuverturePorte : string
NbreRayon : integer
Penderie : boolean
NoBoite : integer
Largeur : real
NbrePorte : integer
OuverturePorte : string
NbreRayon : integer
Penderie : boolean
Armoires
NoEnsemble : real
Hauteur : real
ProIondeur : real
Visibilite : string
LargueurTotale()
NbreBoite()
SurIaceTotale()
NbreExemplaire : integer
Couleurs
Couleur : string
Prix : real
NoEnsemble : real
Hauteur : real
ProIondeur : real
Visibilite : string
LargueurTotale()
NbreBoite()
SurIaceTotale()
NbreExemplaire : integer
Couleur : string
Prix : real
1
Clients
RaisonSociale : undeIined
Adresse : undeIined
StatistisqueSoumission()
Adresse : undeIined
StatistisqueSoumission()
1
Soumissions
NoChantier : integer
DateSoumission : date
DebutTravaux : date
FinTravaux : date
PrixTotal()
Accepte : boolean
DebutTravaux : date
FinTravaux : date
PrixTotal()
Accepte : boolean
*
1 * * 1
*
0e U|L SQL J61
DuverturePorte mot( Cauche, 0roIte, Centrale)
PenderIe boolen (DuI, Non)
PrIx rel
PrIxTotaI rel
Profondeur rel
SurfaceTotaIe rel
VIsIbIIIt mot( NIche, AngleCauche, .)

Relations
Dn remarque le choIx d'Implmenter les mthodes comme des attrIbuts
stocks.
CLIENTS (NoClIent , FaIsonSocIale, Adresse)
CDULEUPS (Couleur, PrIx)
SDUhISSIDNS (NoChantIer, NoClIent, 0ateSoumIssIon, 0ebutTravaux,
FInTravaux, Accept, PrIxTotal)
APhDIPES (NoEnsemble, NoChantIer, Profondeur, 7IsIbIlIt,
NbreExemplaIre, LargeurTotale, Nbr8oIte, SurfaceTotale)
DITES (No8oIte, NoEnsemble, Largeur, NbrePorte, DuverturePorte,
NbreFayon, PenderIe)
Questions
1) 0onnez le dIagramme des cas d'utIlIsatIon.
2) La modlIsatIon est entIerement fate avec des assocIatIons, peuton
utIlIser dans certaIn cas la composItIon sI ouI pourquoI.
Cas ou on peut utIlIser la composItIon :
Cas ou on peut pas utIlIser la composItIon :
Compltez le dIagramme suIvant :

Soumissions
Clients
Armoires Boites
Couleurs

J) Pour mmorIser les constantes de calcul, le concepteur hsIte entre deux
modlIsatIons de classe. AIdez le en dressant un tableau des avantages et
InconvnIents (pensez en termes de complexIt et d'volutIvIt !)

constante1 constante2
Avantages
Inconvenients

4) Pour mesurer les prIx de revIent, Il a t dcIder de rajouter les lments
suIvants la modlIsatIon. Quelles sont les relatIons ajouter :

5) 0onner l'ordre SQL pour crer la table 8DTES et Insrer un exemple de
donnes dans cellecI avec un ordre SQL.
Constantes1
NomConst : string
ValeurConst : real
Constantes2
TempsPosePorte : real
TempsMontagePorte : real
CoutHeureOuvrier : real
Visserie : real
Soumissions
DebutTravaux : date
FinTravaux : date
PrixTotal()
Accepte : boolean
Ouvriers
NoOuvrier : integer
Nom : string
Prenom : string
TariIHoraire : real
Heures
NbreHeuresEIIectuees : integer
* *
DebutTravaux : date
FinTravaux : date
PrixTotal()
Accepte : boolean
NoOuvrier : integer
Nom : string
Prenom : string
TariIHoraire : real
NbreHeuresEIIectuees : integer
0e U|L SQL J6J
6) Fpondre en Langage AlgbrIque sI possIble et en SQL aux questIons
suIvantes:

1) 0onnez une lIste de tous les clIents par ordre alphabtIque
2) 0onnez une lIste des clIents dont une des soumIssIons acceptes
taIent d'un montant suprIeur un mIllIon de francs
J) 0onnez une reqte quI permette de calculer le taux
d'adjudIcatIon (nbr de soumIssIons / nbr de celle quI sont
accepts)
4) 0onnez une lIste des armoIres dont la largeur totale n'est pas
gale la somme de la largeur de ses boItes.

0e U|L SQL J65
29. L1UDL DL CAS : A B C D
24

P.8. plaa dans la platIne une nouveaut qu'Il n'avaIt pas encore coute, quI
sIlencIeusement fut avale par le lecteur. l ImagIna le rayon du laser la
recherche des trous du dIsque compact (C0). Les cIrcuIts lectronIques quI
reconstruIsaIent le sIgnal sonore. DuI, c'taIt vraIment de la musIque cela !
0errIere son comptoIr, Il regarda le magasIn, mInuscule peuttre, maIs quI
contenaIt dj 9.000 C0s. l essaya de se le rappeler 9 moIs auparavant, vIde
quand avec son assocI Il taIt venu le vIsIter. l se dIt qu'Ils avaIent encore
une certaIne navet, ce qu'Ils voulaIent c'taIt vendre des dIsques, crer un
magasIn de C0s ou l'on pourraIt couter le dIsque, obtenIr un renseIgnement,
faIre une rservatIon, dIscuter musIque et bIen entendu acheter un C0 au
prIx le plus avantageux. En rsum, les C0s au prIx des grandes surfaces avec
tous les servIces et les aspects humaIns d'un petIt commerant.
Ces objectIfs avaIent faIllI tourner court. En effet, Ils avaIent sous estIm les
charges de gestIon et de manIpulatIon exIges par ce magasIn. Ces actIvIts
taIent telles qu'Ils avaIent de moIns en moIns de temps consacrer aux
clIents. l y a deux moIs, Ils avaIent dcIds d'InformatIser une partIe des
actIvIts de gestIon du magasIn. Cette ordInateur seraIt un peu comme le
troIsIeme assocI (quI dans la sItuatIon actuelle n'auraIt pas pu tre
rtrIbu).
0e l'InformatIque, Il n'avaIt pas de connaIssances spcIfIques maIs les
premIers contacts avec cet unIvers furent frustrants, Il n'avaIt trouv que
des gens quI parlaIent |byte, |S/0DS, CCA, Lotus, 80, FS2J2, .... Son
expressIon favorIte C'est |artIen taIt tout faIt de cIrconstance. En effet,
aucun ne s'taIt Intress son probleme; tous ne voulaIent que luI vendre
un ordInateur. Cependant, cecI taIt une carIcature, car Il avaIt trouv une
personne quI avant de luI parler dans un langage hermtIque l'avaIt cout
et s'taIt dplac dans le magasIn pour examIner les actIvIts quotIdIennes
InformatIser.
Ce soIr, Il se sentaIt rassur. |. Ccoute semblaIt avoIr comprIs leur
probleme. l s'taIt promen dans le magasIn toute la journe, avaIt pos des
questIons, prIs des notes, observ leur comportement.
L'actIvIt du magasIn taIt entIerement orIente vers le C0. Quand un C0
arrIvaIt, on effectuaIt les opratIons suIvantes :
S'Il est nouveau, on luI attrIbue un numro et l'on cre un fIche sur
carte.
Dn enregIstre sur la fIche le nombre d'exemplaIre quI sont entrs.

24
sujet labor avec le professeur JeanClaude Courbon
Dn place dans le prsentoIr la pochette du C0 (avec un numro
IdentIfIant la fIche correspondante).
Dn place le dIsque dans un tIroIr fermm clef. (|algr ces
opratIons, on enregIstraIt encore quelques vols de pochettes vIdes !).
Lorsqu'un clIent achetaIt un C0, avec le numro InscrIt, on dcrmentaIt le
stock d'une unIt sur la fIche et l'on recherchaIt le dIsque dans le tIroIr.
Le fIchIer taIt spar en troIs bacs de cartes de couleurs dIffrentes,
IndIquant un style de musIque :
8leu ClassIque
Jaune Fock 7arIt
Fouge Jazz
|. Ccoute avaIt demand sI la numrotatIon actuelle pourraIt tre modIfIe
afIn de ne pas transporter des InformatIons (la couleur) quI n'auraIent plus
leur place dans un systeme InformatIs. P.8. avaIt rpondu que seul le style
de musIque luI ImportaIt.
Ces fIches taIent la mmoIre de l'entreprIse A8C0, tout y taIent not,
maIs c'taIt une mmoIre d'amnsIque car comment rechercher un tItre, un
auteur dans J000 fIches : Comment grer les commandes, les ruptures de
stock :
En examInant une fIche, on voyaIt que chacune comportaIt, un auteur, un
style, un tItre, un numro Interne (pour son classement dans le magasIn), un
dIteur, un numro externe (celuI quI est marqu par l'dIteur) et dIffrents
parametres de gestIon tels que la quantIt en stock ou en commande et son
code de prIx de vente.
L'estImatIon de la demande taIt le poInt le plus dlIcat de la gestIon des
C0s. CertaIns C0s allaIent tre vendus plusIeurs dIzaInes d'exemplaIres sur
quelques moIs alors que d'autres ne seraIent que le faIt de la demande d'un
unIque clIent pendant plusIeurs annes. l y avaIt une centaIne de tItres qu'Il
fallaIt surveIller quotIdIennement. La courbe des ventes s'amoraIt
lgerement au dpart, puIs elle atteIgnaIt un plateau quI se maIntenaIt
pendant un certaIn temps puIs c'taIt la chute soudaIne.

fIgure 1 : 7entes quotIdIennes d'un tItre
l fallaIt donc estImer les ventes futures probables et se rapprovIsIonner en
consquence en vItant qu'un stock Important reste Invendu.
TEMPS
VENTE
0e U|L SQL J67
Les commandes s'effectuaIent chez les dIstrIbuteurs suIsses des maIsons
d'dItIon des dIsques. SoIt un reprsentant passaIt au magasIn ou bIen P8 ou
son assocI tlphonaIt au dIstrIbuteur et passaIt sa commande. Une
commande faIsaIt l'objet d'un bulletIn de lIvraIson et sur celuIcI pour un C0
command on avaIt troIs possIbIlIts :
l taIt lIvr.
l taIt en rupture de stock (manque suIvra) et parfoIs une anne plus
tard on recevaIt le C0.
l n'taIt pas dIsponIble en SuIsse.
Le cas 2) taIt noter soIgneusement car le relIquat d'une commande taIt
consIdrer dans le stock car Il seraIt tot ou tard lIvr. Le cas J) pouvaIt faIre
l'objet d'une ImportatIon de l'tranger donc d'une nouvelle commande. Le
cas 1) demandaIt une vrIfIcatIon assIdue, car l Il fallaIt controler que :
Les C0s lIvrs avaIent bIen t commands.
Les quantIts taIent exactes.
La facture correspondaIt ce quI avaIt t convenu sur les prIx.
En effet, le prIx d'achat des C0s taIt source de ngocIatIon, le prIx taIt
dIscut en fonctIon de la quantIt commande et du chIffre d'affaIre que le
magasIn avaIt ralIs avec le dIstrIbuteur. 0'aIlleurs P8 tenaIt ce que
l'ordInateur luI IndIque le chIffre d'affaIre ralIs avec le dIstrIbuteur. CecI
allaIt dans la stratgIe payer le C0 au meIlleur prIx et vendre le C0 au
meIlleur prIx par rapport la concurrence. Ces rabaIs de quantIt suIvaIent
une chelle. Par exemple pour 4 C0s on payaIt prIx fort et pour 100 on avaIt
un rabaIs de J0. CecI renforaIt la ncessIt d'estImer les ventes
journalIeres, car Il valaIt mIeux commander le lot optImal en une seule foIs
plutot qu'en plusIeurs commandes. FInalement, un autre cas se prsentaIt, le
prcommande. l s'agIssaIt de la sortIe d'une nouveaut quI taIt annonce
plusIeurs moIs l'avance et quI le mme jour seraIt sur toute la planete,
dans tous les magasIns de C0. Ce cas taIt encore plus pIneux que les
autres car Il fallaIt estImer un an l'avance les chances de succes d'une
nouveaut.

fIgure 2 : fIche pour un C0
Avant que |. Ccoute parte, P8 luI avaIt rsum ses dsIrs :
Le stock en temps rel.
L'estImatIon des ventes journalIeres.
Le controle des lIvraIsons.
Les IndIcatIons de ngocIatIons avec les dIstrIbuteurs.
|. Ccoute est rentr chez luI avec des InformatIons sImIlaIres celles
donnes dans cette tude de cas.
0crIvez le travaIl qu'Il va faIre, donnez la modlIsatIon de donnes.
EtablIssez une (ou des) proposItIons de systeme InformatIque avec leurs
justIfIcatIons.

abcd
client
Iournisseur
acheter un CD
Iaire commander un CD
commander des CD
receptionner les CD
gerant
analyser les ventes

article : .............................. No ...........
.............................................................
.............................................................

Date QTE Fournisseur Entre Sortie Stock Client Observation
Gabriel Peter 2519
titre SO
Virgin
257 587
50
49
45
44
43
42
40
MV
1/9/86
3/9/86
4/9/86
5/9/86
7/9/86
8/9/86
commande le 10/9/86
11/9/86
10/9/86
40
+10
50
0e U|L SQL J69

CommentaIres :
Dn remarquera que le suIvI des lIvraIsons n'est pas sImple en effet une
lIvraIson physIque peut :
Concerner une lIgne de commande et tre juste quantIt
Fegrouper plusIeurs lIgnes de commande (regroupement chez le
fournIsseur)
Etre Incomplete (ncessIte plusIeurs lIvraIsons)

Fiche Article
NoInterne : integer
ReIFournisseur : string
QTE en magasin()
QTE en commande()
Titre : string
Auteur : string
Genre : string
LigneCMD
NoLigneCMD : integer
Quantite : integer
PrixUnitaire : real
Livraisons
NoLIV : integer
dateLIV : date
LigneLIV
NoLigneLIV : integer
Quantite : integer
PrixUnitaire : real
PrixVente
CodePrix : string
Prix : real
NoLigneCMD : integer
Quantite : integer
PrixUnitaire : real
NoLIV : integer
NoLigneLIV : integer
Quantite : integer
PrixUnitaire : real
CodePrix : string
NoInterne : integer
ReIFournisseur : string
QTE en magasin()
QTE en commande()
Fournisseurs
NoFournisseur : integer
Adresse : string
Vente
DateJour : date
Quantite : integer
NoFournisseur : integer
Adresse : string
1
1
DateJour : date
Quantite : integer Prix : real
Titre : string
Auteur : string
Genre : string
*
1
*
1
* *
Commandes
NoCMD : integer
dateCMD : date
1 *
1
dateLIV : date
*
*
*
NoCMD : integer
dateCMD : date
*
1
Attribution
QteAttribuee : integer QteAttribuee : integer
Clients
NoClient : integer
Nom : string
Prenom : string
Adresse : string
Telephone : undeIined
MontantFidelite : real
*
*
NoClient : integer
Nom : string
Prenom : string
Adresse : string
Telephone : undeIined
MontantFidelite : real
*
0..1
0e U|L SQL J71
30. PLANS, PLANS, RA1APLAN
|. Saroule avaIt t engag dans un dpartement de l'admInIstratIon
publIque. l avaIt choIsI l'admInIstratIon car, depuIs ses tudes l'unIversIt,
Il aImaIt les organIsatIons et la gestIon de leur InformatIon, en somme les
systemes complexes. Le dpartement auquel Il appartenaIt taIt charg du
rseau routIer, plus de 10.000 kIlometres de routes et de tous les ouvrages
(tunnel, pont, ...). Ce dpartement possdaIt un servIce quI archIvaIt les
plans et les documents concernant l'excutIon des chantIers relatIfs au
rseau routIer.
Le servIce des archIves employaIt une dIzaIne de personnes quI rpondaIent
aux dIffrents besoIns du dpartement. Par exemple, lors de l'entretIen ou
de la rfectIon d'une route, Ils fournIssaIent les plans ncessaIres aux
travaux. SI un chantIer modIfIaIt les plans exIstants, Ils taIent chargs de
mettre jour l'tat des archIves. 8Ien entendu, autour de ces routes,
d'autres InformatIons cIrculaIent, celles relatIves au controle prIodIque
des ouvrages, au constat des dgts dus aux IntemprIes et toutes les
InformatIons sur les couts de constructIon et d'entretIen quI n'taIent pas du
ressort du servIce des archIves.
A son entre, |. Saroule avaIt peru la lenteur et l'IneffIcacIt du servIce des
archIves, dues entre autres au manque de personnel, la masse consIdrable
de documents et la grande dImensIon des plans (format A0). Cette
IneffIcacIt du servIce se traduIsaIt dans le reste du dpartement par des
retards et des Incompltudes dans les dossIers. Par exemple, des
renseIgnements sImples du genre: Quel est le bureau d'IngnIeur quI s'est
occup du dernIer chantIer de la sectIon 5 du tronon 14 de la route
natIonale 11 : pouvaIent rester dans le servIce des archIves sur la pIle des
urgents pendant plusIeurs jours. l s'agIssaIt donc de questIons auxquels un
systeme InformatIs auraIt pu apporter rapIdement des rponses prcIses.
Pour faIre face ces problemes de gestIon, le dpartement avaIt dbloqu
un crdIt d'InformatIsatIon du dpartement quI s'taleraIt sur une prIode de
cInq ans. Une petIte quIpe d'InformatIcIens seraIt recrute pour la
ralIsatIon et la maIntenance du systeme. |aIs au pralable, Il fallaIt que les
besoIns du dpartement soIent claIrement explIcIts. Un groupe de travaIl
avaIt donc t form et |. Saroule devaIt au seIn de ce groupe tudIer les
besoIns du servIce des archIves.
Pour mIeux cerner, les donnes manIpules par le servIce des archIves et
afIn d'Illustrer son dossIer, Il avaIt faIt un croquIs (fIgure 1)
S'Il avaIt du commenter ce schma, Il auraIt dIt Le rseau routIer se rpartIt
entre plusIeurs catgorIes de routes: les autoroutes, les routes natIonales,
les routes cantonales, les routes communales. Chacune est IdentIfIe par un
nom unIque (A10, FN17, FC206, ....). Chaque route est dcoupe en
tronons et chaque tronon est luImme dcoup en sectIons. A chaque
sectIon est assocI l'ensemble des chantIers concernant cette sectIon. Les
chantIers sont reprs par une date de dbut et de fIn. La supervIsIon d'un
chantIer est excute par un bureau d'IngnIeur. Ce dernIer est dcrIt par un
ensemble de caractrIstIques (nom, adresse, ...) utIlIses dans la
correspondance ou dans les dIffrents rapports excuts par le dpartement.
Chaque chantIer apporte une nouvelle versIon des plans de la sectIon (un
plan d'ensemble et les dIffrents plans de dtaIl). En ce quI concerne le
rangement, chaque plan est rang dans un local quI comporte un certaIn
nombre d'armoIres dIvIses ellesmmes en plusIeurs tIroIrs.
Les sectIons avaIent en moyenne une longueur de 1 kIlometre et les tronons
entre J et 20 kIlometres. Chaque sectIon possdaIt un chantIer (celuI de sa
cratIon), maIs certaInes sectIons avaIt dj subI une quInzaIne de
modIfIcatIons (et donc autant de chantIers).
Un autre poInt Important du systeme d'InformatIon laborer taIt celuI des
mIcrofIlms. En effet, le volume des archIves taIt devenu tellement
Important qu'une partIe des plans, ceux concernant des chantIers ancIens,
taIent actuellement stocks dans un autre btIment. l avaIt t dcId de
mIcrofIlmer ces plans. Le systeme InformatIque devraIt donc donner une
IndIcatIon sur la nature des plans (grandeur nature ou mIcrofIlm). Par
aIlleurs, le systeme devraIt aussI slectIonner les plans mIcrofIlmer sur des
crIteres tels que le nombre de versIons et l'ancIennet des chantIers pour
une mme sectIon.
CecI permettraIt de ne conserver sur papIer que les versIons les plus
rcentes et aInsI de mInImIser la surface des locaux d'archIves.
La dIsponIbIlIt des InformatIons du servIce des archIves dans l'ensemble du
dpartement taIt souhaItable. Chaque servIce devraIt donc avoIr acces aux
donnes, maIs seul le servIce des archIves auraIt la possIbIlIt de faIre des
modIfIcatIons. AInsI les demandes les plus sImples (quI s'est occup de tel
chantIer :) seraIent dIrectement satIsfaItes. Pour les demandes ncessItant
par exemple la copIe d'un plan, Il faudraIt envIsager un moyen de
communIcatIon entre les dIffrents servIces du dpartement et le servIce des
archIves.
|. Saroule resta encore tard dans son bureau pour rdIger son analyse
prlImInaIre pour la runIon du groupe de travaIl.
Nous vous demandons d'effectuer l'analyse que va faIre ce |onsIeur Saroule,
d'examIner le servIce des archIves, les dIffrents acteurs et Intervenants, les
tches qu'Ils effectuent, de dcrIre les donnes quI doIvent tre stockes, de
dcrIre une modlIsatIon possIble de cellescI, d'envIsager les archItectures
InformatIques possIbles pour supporter et facIlIter ce systeme d'InformatIon
aInsI que les types d'utIlIsatIon qu'Il permettra et les procdures pour les
accomplIr.
0e U|L SQL J7J
CertaInes InformatIons sont absentes de l'nonc. Nous vous demandons de
les complter avec le bon sens, en mentIonnant nous faIsons l'hypothese
que ....

fIgure 1

chantier: elargissement de la chaussee
date du 1.2.87 au 1.6.87
RN15 tronon 6
sect 1
sect 2
sect 3
sect 4
bureau d'ingenieur XXX
local 102
armoire12
tiroir 4
plans
0e U|L SQL J75
3J. BIBLIOGRAPHIL
[AF|74] Armstrong W. W.
0ependency structures of data base relatIonshIps ProceedIng FP 1974,
North Holland
[8DE76] 8oehm 8.W.
Software EngIneerIng, EEE, TransactIon computer C25, 0ecember 1976
[8DN99] 8onjour |. ; Falquet C. ; Cuyot J. ; Le Crand A.
Java : de l'esprIt la mthode, dIstrIbutIon d'applIcatIons sur nternet
EdItIon 7uIbert, 1999
[8FE90] 8reton P.
Une hIstoIre de l'InformatIque EdItIon de la 0couverte, 1990
[CHE74] ChenIque F.
Comprendre lc loyque moderne. Ed. 0unod 1974
[CLD81] ClocksIn W.F.; |ellIsh C.S.
, SprInger7erlag, 1981
[CD070] Codd E.F.
A relatIonal |odel of 0ata for Large Shared 0ata 8anks CommunIcatIon
AC|, 7ol 1J, No 6, June 1970
[0AT87] 0ate C.J.
A yude to the SQL stcndcrd AddIsonWesley 1987
[0EL82] 0elobel C.; AdIba |.
8cses de donnes et systmes relctonnels, 0unod 1982
[FAL89] Falquet C.
lnterroycton de bcses de donnes c lcde dun modle smcntque Ed.
Systemes et nformatIon Ceneve, 1989
[FFY76] Fry J.P.; SIbley E.H.
EvolutIon of data base management systems, ComputIng Surveys AC|, 7ol
8, No 1, 1976
[CDL72] ColdstIne H.
The computer FFD| Pascal to von Neuman PrInceton UnIversIty Press,
1972
[CFA81] Cray J.N.
the transactIon concept: vIrtues AN0 lImItatIons ProceedIng 7th
nternatIoal conferenc 1981, EEE 7ery Large 0ata base System.
[HDT89] HottoIs C.
Penser lc loyque. Ed. 0e 8oeck UnIversIt 1989
[HDU88] HouIllere P.
Le schma dIrecteur d'un systeme d'InformatIon, Eyrolles, 1988
[JAC92] . Jacobson, |. ChrIsterson, P. Jonsson, C. Dvergard
DbjectDrIented software engIneerIng : A use case AddIsonWesley 1992
[JAC94] . Jacobson, |. CrIss, A. Jacobson
The object advantage : 8usIness Process FeengIneerIng wIth object
techonology AddIsonWesley 1994
[JAC97] . Jacobson, ,|. CrIss, P. Jonsson
software Feuse : ArchItecture, Process and DranIzatIon for 8usIness
Success AddIsonWesley 1997
[JEN75] Jensen K.; WIrth N.
PASCAL user mcnucl AN0 report, SprInger 7erlag, 1975
[KDW79] KowalskI F.
Loyc ]or problem solvny, North Holland, 1979
[LED88] Lonard |.
Structure des bcses de donnes. Ed. 0unod 1988
[LS94] LIskov 8.; WIng J.
"A 8ehavIoral NotIon of SubtypIng", AC| TransactIons on ProgrammIng
Languages and Systems, 7ol 16, No 6, November, 1994, pages 18111841
[|SH92] |Ishra P.; EIch |.H.
JoIn processIng In FelatIonal 0atabases, AC| computIng surveys, 7ol 24, No
1, |arch 1992
[NAU6J] Naur P.
Feport on the algorIthmIc langage ALCDL 60, AC| 6, No 1, 196J
[D|C99] Dbject |anagement Croup
UnIfIed |odellIng Language dernIere versIon: www.omg.org
[PAP79] PapadImItrIou C.H.
serIalIzabIlIty of concurrent database updates. Journal AC|, 7ol 26, No 4 ,
Dct. 1979
[PHA90] Le Pham Ngung Huong
DptImIsatIon globale des controles d'IntgrIt dans une base de donnes
EdItIons systemes et InformatIon, 1990
[FEE50] Fees |.
The federal computIng machIne program reproduIt dans Annals of hIstory
of computIng vol 7, No 2, 1985
[ULL82] Ullman J. 0.
Prncples o] 0ctcbcse systems Computer ScIence Press, 1982
[WAF99] J. 8. Warmer; A. C. Kleppe
The Db]ect Constrcnt Lcnyucye: Precse Modelny wth 0ML , AddIson
Wesley, 1999
[WF76] WIrth NIklaus
Alyorthms + 0ctc Structures = Proyrcms , PrentIce Hall, 1976

J77

J79

32. Index
, 148
_, 148
1NF, 40, 2J6
2NF, 2J8
JNF, 2J9
abstractIon, 15, 60
Access, 160
ccteur, 50, 54
Acteur, 62
acyclIques, 218
agrgatIon, 154
AgrgatIon, J7, 11J
algebre relatIonnelle, 12J, 257
ALCDL 60, 96
AlgorIthme, 2J4
de recherche de cls, 216
lI au df, 209
alias, 14J
all, 146
aII, 14J, 150, 154, 260
AND, 146
anomalIe, 185, 191, 195, 225, 24J
anomalIes de mIse jour, 2J6
any, 146
any, 150, 158, 260
appartenance
un ensemble, 146, 147
un Intervalle, 146, 149
une chane de caracteres, 146
Appartenance
une chane de caracteres, 148
arborescence, 156
crt, 124
Armstrong, 202
asc, 158
assocIatIon, 25, 108
attrIbu, 112
AssocIatIon bInaIre, J0
assocIatIons, 22, 25
atomIcIt, 176
attrIbuts, 24, 112
augmentatIon, 202
autojoInture, 145
avg, 154
axIome, 202
axIomes, 88
8ackusNaurForm, 96
8arbres, 258
base
complete, 209, 210, 221
Irredondante, 211, 267
base de donnes I|d, 9J
besoIns, 50
between, 146
between, 149
8ETWEEN, 260
bIcondItIonnel, 87
bIen forme, 1J1
bInaIres, 102
8NF, 96
8ooch, 17
8PF, 50, 5J
by rowId, 262
calcul
des classes, 90
des proposItIons, 90
caractere, 101
cardInalIt, 27, J1, 108
cardInalIt de la relatIon, 124
cas d'utIlIsatIon, 50
chane de caracteres, 144
chanes de caracteres, 86, 101
character, 101
charnIere, 199
charnIere, 129
Check, 192
chemIns d'acces;, 261, 26J
classe, 21, 105
Classe, 55
Classe d'assocIatIon, J2
classes, 20
classIfIcatIon, 4J
clauses de Horn, 249
cl, 106, 199, 215
prImaIre, 194
unIque, 219
Codd, 199
colonne, 100
columnconstraInt, 192
commIt
ImplIcIte, 180
commIt, 180
communIcable, 15
comparaIson, 146
compltude, 20J
Compltude, 206
comportement, 20
comportement homogene, 86
J80

Composants, 54
composItIon, J8, 41, 11J
concatn, 144
concurrence, 141
concurrence, 17J, 176, 187
condItIon, 146
CondItIon, 141
condItIonnel, 87
confIrmatIon, 180
conjonctIon, 87
CDNNECT 8Y, 251
ConnectClause, 141, 156
connecteurs logIques, 126
consquence logIque, 202
consquence logIque, 201
conservatIon de l'InformatIon, 225
consIstance, 176
consIstance, 186
consIstent, 185
constante non sIgne, 144
constItuant, 100
constItuant, 86
contraInte, J4
contraInte de navIgabIlIt, J7
contraInte entre assocIatIons, J7
contraInte entre roles, J6
contraIntes, 101
Controleur, 62
conversIon de type, 147
Count, 154
couts
de valIdatIon, 188
couverture, 208
covarIance, 47
CFEATETA8LE, 192
CFEATE7EW, 244
cratIon, 174
cratIon, 178
cratIon d'une entIt, 101
croIssant, 158
cycle de vIe, 18
d'tatstransItIons, 64
date, 101
declaratIondomaIne, 97
declaratIonrelatIon, 97
0clenchement, 55
dcomposItIon
bInaIre, 2J0
d'une relatIon, 225
joInIable, 226
proprIt, 227
0composItIon, 204
d'une relatIon, 221
totale, 228
dcroIssant, 158
dductIon, 249
dduIre, 202
delete, 180
deletecommand, 180
dnombrable, 84
dnombrer, 154
0normalIsatIon, 272
dpend fonctIonnellement, 199
dpendance
calcule, 247
d'InclusIon, 190
lmentaIre, 207
fonctIonnelle, 199
drIvatIon, 20J
desc, 158
dtermIne, 199
dveloppement, 52
dIagnostIc, 191
dIagramme, 55
0Iagramme d'objets, 24
0Iagramme de classes, 22
dIagrammes, 66
syntaxIques, 96
syntaxIques de SQL, 100
dIffrence, 124
dIsjonctIon, 87
dIsplayed column, 141
dIstInct, 142, 154
dIstrIbutIvIt, 90
dom, 86
domaIne, 84
domaInes, 84
doublons, 156
doublons, 142
durabIlIt, 176
dynamIques, 187
ebf, 1J1
lments, 64
enjeux, 59
ensemble
de constItuants, 92
de dpendances fonctIonnelles, 201
de donnes, 86
de prImItIves, 190
de relatIons, 9J
de valeurs, 84
des constItuants, 86
des domaInes, 86
des entIts, 94
des Instances, 185
des rI, 185
ensembles, 84
entIt, 20
entIt, 100
EntIt, 62
entIt r, 92
quIjoInture, 128
J81

EquIvalence, 209
quIvalence, 204
quIvalence des ordonnancements, 177
et logIque, 146
tat, 20
consIstent, 176
toIle, 200
vnement., 171
exclusIve, 181
exIsts, 146
exists, 150, 157
ExIsts, 260
expressIon, 144
expressIons
algbrIques, 1J0, 1J7
arIthmtIques, 14J
calcules, 141
proposItIonnelles, 89
expset, 148
facteur, 144
Factor, 144
FactorIser, 45
faux, 87
]ermeture, 186, 201
fonctIon
de regroupement, 144
de slectIon, 127
proposItIonnelle, 90
fonctIon, 144
Forme canonIque, 205
forme normale, 40
Forme normale 8oyceCodd, 240
formule, 1J0
FPDh, 1J7, 145, 24J
frontIere, 15, 59
gnralIsatIon, 4J, 46, 114
CnralIsatIon, 41
gestIon de la concurrence, 177, 178
grammaIre d'un langage, 96
graphIque des df, 200
GROUP BY, 154, 244
CroupClause, 141, 154
hashcodIng, 258
having, 147, 154
hrItage, 41, 4J
hrItage multIple, 48
HrItage |ultIple, 46
HeurIstIque, 219
IdentIfIcateur de range, 261
IdentIfIcateurs, 97
ImplmentatIon physIque, 256
in, 146, 260
In, 147
Indpendance logIque, 246
Index, 258, 262
Index, 26J, 268
InformatIons redondantes, 179
InItIalIser une table, 152
InsatIsfaIsable, 186
Insrer, 102
Insert, 178
Insertcommand, 178
InsertIon, 178
Instance, 104, 124
de la relatIon, 9J
de R, 9J
nteractIons, 56
Interdpendance, 274
nterface, 62
Interface graphIque, 160
InterprtatIons correctes, 1J1
Interprter une valeur, 87
InterrelatIon., 188
InterrogatIon, 12J, 1J2, 225
Intersect, 156
Intra
relatIon,, 188
tuple, 188, 190
InvarIant, 199
InvarIants, 170
Irredondant, 186, 208
IsomorphIsme, 90
Jacobson, 18, 50
Java, 106
]onture, 192, 259, 264, 268
externe, 1J0
naturelle, 140
naturelle, 129
par boucle ImbrIque, 264
par trI et fusIon, 264
]onture, 127, 1J7
JoInture
externe, 151
journal, 177
l'arIt, J0
L'encapsulatIon, 22
l'Instance, 24
langage
de descrIptIon de modlIsatIon, 96
de descrIptIon des donnes, 96, 100
de manIpulatIon de donnes, 178
langage procdural, 106
langages
de programmatIon, 84
langages de programmatIon, 101
l'volutIon de l'InformatIque, 12
IIens, 24, J5
lIgne, 100
like, 146
lIke, 149, 260
lIsIbIlIt, 10J
LIskov, 44
J82

lIsteIntervalle, 97
lIstevaleur, 97
Lockmode, 181
logIcalfactor, 146
l'D|C, 17
l'optImIsatIon ;des requtes SQL. Jusqu' prsent, nous
avons faIt abstractIon de l'ImplmentatIon
physIque.I.ImplmentatIon physIque; des relatIons et
nous avons dcrIt le fonctIonnement de la machIne SQL
en termes purement logIques. Les Instances des relatIons
dans un SC80 sont stockes physIquement; au schma
logIque des relatIons est assocI un schma
physIque.I.schma, 256
machIne SQL, 1J7, 159
machIne SQL, 1J8
masque de saIsIe, 18J
masques de saIsIe, 184
matchstrIng, 149
max, 154
maxImum, 154
mcanIsmes de scurIt, 14J
mthode, 106
mthodes, 20, 22
min, 154
mInImum, 154
minus, 156
mIse jour, 174, 176, 179
modele, 15, 105
|odele de dpIoyement, 19, 6J
|odele de raIIsatIon, 19, 6J
|odele des cas d'utIIIsatIon, 18, 6J
|odele des cIasses, 18, 6J
|odele des tats, 18, 6J
|odele des InteractIons, 18, 6J
modele |d, 104
modlIsatIon, 12, 97
modlIsatIon, 85
modlIsatIon |d, 9J
modlIsatIon graphIque, 1J2
modlIsatIons
quIvalentes, 199
modIfIcatIon, 225, 245
|D0FCATDN
0ES 0DNNEES, 170
moyenne, 154
ngatIon, 87
nombres, 86
vIrgule fIxe, 102
en vIrgule flottante, 101
entIers, 102
not, 146
Not Null, 192
notatIon, 22
nowaIt, 181
noyau du SC80, 184
null, 115, 146, 150, 246
null, 151
Null, 192
nuplet, 92
objectIf, 15
objectIfs, 51
Dbjets, 20
occurence, 171
DCL, 65
DId, 106
DDSE, 17
oprateurs
arIthmtIques, 144
de comparaIson, 126, 147
de projectIon, 126
ensemblIstes, 156
logIque, 128
logIques, 87, 146
opratIons
de comparaIson, 86
de slectIon, 85
ensemblIstes, 141
optImIsatIon, 159
optImIseur, 257
OR, 146
DrderClause, 141, 158
ordre
de joInture, 264
hIrarchIque, 156
lexIcographIque, 85
ou loyque, 124, 146
package, 2J
paquetages, 65
PASCAL, 18J
PASCAL, 96
patron, 148
performance, 256, 27J
performance, 26J
plan d'excutIon;., 269
porte d'une regle, 189
prdIcat, 88, 184
quantIfI, 146
prdIcat, 90, 102, 146
prservatIon des df, 225
PrservatIon des df, 2J2
prImary key, 106
PrImary Key, 192
prImItIve de modIfIcatIon, 188
prImItIves de modIfIcatIon, 171, 174
PrIncIpe de substItutIon, 44
prior, 156
processus, 62
de conceptIon, 199
de modlIsatIon, 100
d'InterrogatIon, 1J1
produIt
cartsIen, 84, 92, 100, 126, 141, 145, 257
produt, 126, 1J7
J8J

cartsIen, 90
programmatIon, 22, 40
programmatIon logIque, 249
projectIon, 14J
de F, 221
pro]ecton, 125, 1J7, 141
PFDLDC, 249
proposItIon, 89
compose, 87
sImple, 87
proposItIon, 87
proposItIons
logIques, 84
protocoles lgaux, 176
Pseudo transItIvIt, 204
puts, 217
quantIfIcateur unIversel, 151
quantIfIcatIon
exIstentIelle, 89
unIverselle, 89
quantIfI, 150
racIne, 157
raffInements, 41
raItement, 256
range scan, 26J
read only, 180
recherche des cls, 219
recherche des InvarIants, 184
rcupratIon des erreurs, 176
rcursIvIt, 250
rcursIvIt, 154
redondances logIques, 24J
rcrIture, 257, 259
rcrIture de la requte, 245
Feferences, 192
rflexIvIt, 202
regles d'IntgrIt, 101, 176, 184, 225
en SQL, 192
regroupement, 141, 14J, 144
regroupement, 154
relatIon, 105
d'ordre, 85, 147
parentenfant, 157
unIverselle, 247
relcton, 124, 1J7
ncre, 84, 91
relatIon d'extensIon, 57
relatIon d'InclusIon, 57
relatIon de communIcatIon, 57
renommer une colonne, 14J
reprsentatIons
logIques, 246
reprIse, 177
requtes SQL, 1J7
restructuratIon, 199
rutIlIsatIon, 45
rIsque, 59
roles multIples, 26
rollback, 181
row
exclusIve, 181
share, 181
rowId, 261
Fumbaugh, 17
satIsfaIsable, 185
saturatIon, 205, 215
savepoInt, 180
scnarIo, 55
ScnarIo, 61
schma
de relatIon, 201
physIque, 256
scurIt des donnes, 17J
SELECT, 1J7, 24J
SELECTcommand, 141
selectedtable, 145
selectedtable, 141
slectIon, 257
slecton, 127, 1J7
slectIon en SQL, 1J7
smantIque, 102
de la relatIon, 92
smantIque, 94
semIjoInture, 129
gauche, 1J0
sensIbIlIt d'une prImItIve, 190
squence
de prImItIves, 176
squences, 64
Set-CIause, 141, 156
SC80 hIstorIque, 172
share, 181
row exclusIve, 182
somme, 154
source, 217
sousrequte, 150, 152, 178
spcIfIcatIon, 50, 51
SQL, 12J
start wIth, 157
statIques, 187
statIstIques, 259
strotype, 65
strotypes, 2J
Strotypes, 5J
stockage, 256
structure, 9J
structur, 10
structure de table, 100, 101, 10J
structures de donnes, 257
Subquery, 152
subqueryCFEATE, 182
substItutIon, 24J
J84

sum, 154
suppressIon, 174, 175
SuppressIon, 180
symboles
nontermInaux, 96
termInaux, 96
syntaxe SQL, 96
systeme de dductIon, 202
systemes InformatIques, 94
table squentIelle, 261
tablename.*, 14J
tables, 100
tautologIe, 90
tautologIe, 88
terme, 144
thoremes, 88
thtajoInture, 127
tIers exclu, 90
traductIons, 118
transactIon, 59, 171, 176, 180
annule, 181
confIrme, 181
errone, 177
Inacheve, 176
transactIon, 186
transactIoncommand, 180
transItIvIt, 202
trI, 158
trI, 141
trIvIal, 185
type, 84, 101
boolen, 86
date, 86
domaIne, 188
mot, 85
mot ordonn, 85
numrIque, 86
texte, 85
types numrIques, 102
typologIe des domaInes, 85
ull scan table, 262
unIcIt, 190
unon, 124, 1J7, 156
UnIon, 204
unIque, 26J
UnIque, 192
UnIque scan, 26J
update, 179
Update, 107
UpdateClause, 141
Updatecommand, 179
utIlIsateurs, 50
valeur par dfaut, 101
valIdatIon
globale, 191
locale, 191
valIde, 185
valIdIt, 20J
valIdIt des donnes, 86
varIable lIbre, 89
varIables, 20, 88
lIbres, 84
vrIfIcatIon, 184
verrouIllage, 141
verrous, 177, 178, 181
versIon, 45
vIde, 148
7EW, 244
vraI, 87
vue, 115, 24J, 268, 270
vues, 107
WHEPE, 1J7, 146, 154, 179, 24J
WIrth, 96
wIth check optIon, 246
J85

Uml Vers MLD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml Vers MLD

Uploaded by

Copyright:

Available Formats

0e U|L SQL 1

Editions systmes et information

proposItIon 1 sur la valIdIt et proposItIon 4 sur la compltude

You might also like