Investeşte în oameni! Proiect cofinanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013 Axa prioritară nr. 1 „EducaŃie şi formare profesională în sprijinul creşterii economice şi dezvoltării societăŃii bazate pe cunoaştere” Domeniul major de intervenŃie 1.3 „Dezvoltarea resurselor umane din educaŃie şi formare profesională” Titlul proiectului: “Dezvoltarea resursei umane pentru managementul eficient al bazelor de date calitative ale rezultatelor examenelor şi evaluărilor naŃionale din învăŃământul preuniversitar- DRU - MEBD - EN” Cod Contract: POS DRU / 57/1.3/S/ 21086 Beneficiar: Centrul NaŃional de Evaluare şi Examinare P A R T E A I SUPORTUL DE CURS TEMA 1 ObservaŃii privind interpretarea rezultatelor după completarea datelor în borderoul electronic, tipologia itemilor, matricea de specificaŃii asociată testului, modalităŃi de obiectivare a aplicării baremului şi de reducere a diferenŃelor de notare Obiectivele temei sunt: • ilustrarea asemănărilor şi a deosebirilor dintre programa şcolară şi programa pentru evaluări/ examene naŃionale; • exemplificarea relaŃiei dintre obiective/ competenŃe – obiective de evaluare/ competenŃe de evaluat; explicarea relaŃiei complexe dintre matricea de specificaŃie şi instrumentele de evaluare; • analizarea calităŃilor instrumentelor de evaluare. Utilizarea borderoului electronic permite analiza calitativă şi cantitativă a rezultatelor obŃinute de candidaŃi. Ilustrăm acest fapt la probele scrise obligatorii E a şi E c. La sesiunea specială a examenului de bacalaureat, au susŃinut proba obligatorie E a la Limba şi literatura română 594 de candidaŃi evaluaŃi (au fost 596 candidaŃi înscrişi dintre care 2 neprezentaŃi). ConŃinuturile evaluate prin proba scrisă la Limba şi literatura română sunt: • reguli generale în redactare • exprimarea reacŃiilor şi a opiniilor faŃă de texte literare şi nonliterare, argumentare, rezumat etc. • normele limbii literare la nivelurile: ortografic şi de punctuaŃie, morfosintactic, lexicosemantic, stilisticotextual • sens denotativ şi sensuri conotative • temă, motiv • particularităŃi ale construcŃiei subiectului în textele narative toate conŃinuturile asociate competenŃei de identificarea şi analiza principalelor componente de structură şi de limbaj specifice textului dramatic; • viziune despre lume, teme şi motive, concepŃii despre artă, sensuri multiple ale textelor literare • trăsături ale curentelor culturale/ literare, reflectate în textele literare studiate sau în texte la prima vedere
Transcript
Investeşte în oameni!
Proiect cofinanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013 Axa prioritară nr. 1 „EducaŃie şi formare profesională în sprijinul creşterii economice şi dezvoltării societăŃii bazate pe cunoaştere” Domeniul major de intervenŃie 1.3 „Dezvoltarea resurselor umane din educaŃie şi formare profesională” Titlul proiectului: “Dezvoltarea resursei umane pentru managementul eficient al bazelor de date calitative ale rezultatelor examenelor şi evaluărilor naŃionale din învăŃământul preuniversitar- DRU - MEBD - EN” Cod Contract: POS DRU / 57/1.3/S/ 21086 Beneficiar: Centrul NaŃional de Evaluare şi Examinare
P A R T E A I SUPORTUL DE CURS
TEMA 1 ObservaŃii privind interpretarea rezultatelor după completarea datelor în
borderoul electronic, tipologia itemilor, matricea de specificaŃii asociată testului, modalităŃi de obiectivare a aplicării baremului şi de reducere a diferenŃelor de
notare Obiectivele temei sunt:
•••• ilustrarea asemănărilor şi a deosebirilor dintre programa şcolară şi programa pentru evaluări/ examene naŃionale; •••• exemplificarea relaŃiei dintre obiective/ competenŃe – obiective de evaluare/ competenŃe de evaluat; explicarea relaŃiei complexe dintre matricea de specificaŃie şi instrumentele de evaluare; •••• analizarea calităŃilor instrumentelor de evaluare.
Utilizarea borderoului electronic permite analiza calitativă şi cantitativă a rezultatelor obŃinute de candidaŃi. Ilustrăm acest fapt la probele scrise obligatorii E a şi E c. La sesiunea specială a examenului de bacalaureat, au susŃinut proba obligatorie E a la Limba şi literatura română 594 de candidaŃi evaluaŃi (au fost 596 candidaŃi înscrişi dintre care 2 neprezentaŃi).
ConŃinuturile evaluate prin proba scrisă la Limba şi literatura română sunt: • reguli generale în redactare • exprimarea reacŃiilor şi a opiniilor faŃă de texte literare şi nonliterare,
argumentare, rezumat etc. • normele limbii literare la nivelurile: ortografic şi de punctuaŃie, morfosintactic,
lexicosemantic, stilisticotextual • sens denotativ şi sensuri conotative • temă, motiv • particularităŃi ale construcŃiei subiectului în textele narative � toate conŃinuturile asociate competenŃei de identificarea şi analiza principalelor componente de structură şi de limbaj specifice textului dramatic; • viziune despre lume, teme şi motive, concepŃii despre artă, sensuri multiple ale
textelor literare • trăsături ale curentelor culturale/ literare, reflectate în textele literare studiate
sau în texte la prima vedere
• construcŃia textului argumentativ • logica şi coerenŃa mesajului argumentativ • verbe evaluative, adverbe de mod, predicative ca mărci ale subiectivităŃii
evaluatice etc. • eseul argumentativ • interpretări şi judecăŃi de valoare exprimate în critica şi istoria literară
0
24
94
201 204
67
40
50
100
150
200
250
Note
1- 4
,99
Note
5- 5
,99
Note
6- 6
,99
Note
7- 7
,99
Note
8- 8
,99
Note
9-9
,99
Nota
10
RepartiŃia rezultatelor candidaŃilor pe tranşe de note
Figura nr 19 DistribuŃia numerică a rezultatelor obŃinute la disciplina E a
pe tranşe de note
RepartiŃia rezultatelor candidaŃilor pe tranşe de note ne oferă o imagine relevantă. Din cei 594 de elevi care au susŃinut examenul de bacalaureat – sesiunea specială – se remarcă absenŃa notelor situate în tranşa valorică 1,00-4,99. La această disciplină a bacalaureatului, promovabilitatea a fost de 100%. Cealaltă extremă a curbei lui Gauss – cuantificată în extrema valorică a notei 10 – a fost obŃinută de 4 elevi, adică de un procent de
0,67%. Notele din tranşa 5-5,99 au fost obŃinute de un număr de 24 de elevi, într-un procent de 4,04%. Au obŃinut note cuprinse între 6,00 şi 6,99 un număr de 94 de elevi, adică un procent de 15,83%. Vârful curbei lui Gauss a dispersiei notelor obŃinute de elevi la această disciplină este reprezentat de 33,84% pentru tranşa de note 7-7,99 şi de 34,34% pentru notele cuprinse între 8,00-8,99. Între 9,00 şi 9,99 s-au situat 67 de elevi, un procent de 11,28% dintre elevii prezenŃi la această probă a examenului de bacalaureat.
Următoarea figură reprezintă distribuŃia procentuală a performării tipurilor de itemi
prezenŃi în structura probei E a:
77% 75%70%
79%88% 90% 87%
70%75%
80%76%
70%
57%
82%
69%
58%
82%76%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Punctaj T
otal
Subie
ct I
Subie
ct II
Subie
ct II
Subie
ct I
1
Subie
ct I
2
Subie
ct I
3
Subie
ct I
4
Subie
ct I
5
Subie
ct I
6
Subie
ct I
7
Subie
ct I
8
Subie
ct I
9
Subie
ct II
1
Subie
ct II
2
Subie
ct II
3
Subie
ct II
I 1
Subie
ct II
I 2
DistribuŃia procentuală a performării tipurilor de itemi prezenŃi în structura probei E a
Figura nr. 20 DistribuŃia procentuală a performării diferitelor tipuri de itemi pentru proba E a
Analiza figurii de mai sus demonstrează faptul că subiectul al III-lea a fost performat într-un procent de 79% dintre elevi, fiind sensibil mai ridicat decât procentele care indică rezolvarea subiectelor I şi II. În cadrul subiectului I, itemul I.2 – explicarea rolului utilizării diferitelor semne de ortografie şi de punctuaŃie – a fost corect rezolvat într-un procent de 90% din totalul itemilor. În cazul subiectului al II-lea, itemul II.1 – item semiobiectiv de argumentare – este performat într-un procent de 82% din totalul itemilor probei.
Figura de mai jos reprezintă o diagramă comparativă între punctajul atribuit fiecărui
item în parte şi numărul total de puncte prin care se măsoară performarea răspunsului corect.
Investeşte în oameni!
Diagrama comparativă între punctajul atribuit fiecărui item şi cel performat
Figura nr 21 DistribuŃia comparativă a punctajului performat de candidaŃi
Investeşte în oameni!
Se observă că la nivelul subiectului I se înregistrează o diferenŃă de 7,54 de puncte între punctajul maxim al acestui subiect şi punctele obŃinute prin însumarea tuturor punctelor distribuite pe fiecare item în parte. Subiectul al II-lea prezintă o diferenŃă mai accentuată între punctaj maxim acordat şi punctaj obŃinut – se observă o diferenŃă de 9,01 puncte, iar în cazul subiectului al III-lea diferenŃa înregistrată este comparativ notabilă cu situaŃia existentă în cadrul subiectului I. În ansamblu, subiectul al II-lea a fost perceput de către candidaŃi ca fiind mai dificil, fiind performat corect doar în proporŃie de 70 %, comparativ cu subiectul I care a fost performat corect în proporŃie de 75%, iar subiectul al III-lea 79%.
CompetenŃele vizate au fost următoarele: � utilizarea adecvată a tehnicilor de redactare şi a formelor exprimării scrise compatibile cu situaŃia de comunicare în elaborarea unor texte diverse; � utilizarea adecvată a achiziŃiilor lingvistice în producerea şi în receptarea diverselor texte orale şi scrise, cu explicarea rolului acestora în construirea mesajului; � identificarea temei şi a modului de reflectare a acesteia în textele studiate sau în texte la prima vedere; � identificarea şi analiza principalelor componente de structură, de compoziŃie şi de limbaj specifice textului narativ; � identificarea şi analiza principalelor componente de structură şi de limbaj specifice textului dramatic; � identificarea şi analiza elementelor de compoziŃie şi de limbaj în textul poetic; � compararea unor viziuni despre lume, despre condiŃia umană sau despre artă reflectate în texte literare, nonliterare sau în alte arte; � identificarea şi explicarea relaŃiilor dintre opere literare şi contextul cultural în care au apărut acestea; � identificarea structurilor argumentative în texte literare şi nonliterare studiate sau la prima vedere; � argumentarea unui punct de vedere privind textele literare şi nonliterare studiate sau la prima vedere; � compararea şi evaluarea unor argumente diferite, pentru formularea unor judecăŃi proprii. Să analizăm performanŃele candidaŃilor pe matricea de specificaŃii:
E4. c Interpretări şi judecăŃi de valoare exprimate în critica şi istoria literară
23.80 23.80 30.00 79.34
% 75.48 77.18 79.33 75.59
Investeşte în oameni!
Pagina 9
44,79
60,00
44,79
60,00
5,31
6,00
4,75
6,00
27,00
34,00
29,42
38,00
34,75
46,00
34,75
46,00
23,80
30,00
23,80
30,00
44,79
60,00
44,79
60,00
23,80
30,00
0,00
10,00
20,00
30,00
40,00
50,00
60,00
E1 a E1 b E1 c E1 d E2. a E2. b E2. c E2. d E2. e E3. E4. a E4. b E4. c
Nivelul de performare al conŃinuturilor
Nivel de performare a conŃinuturilor realizat
Nivel de performare a conŃinuturilor propus
Figura nr 22 Nivelurile de performare a conŃinuturilor propuse şi realizate
Investeşte în oameni!
Pagina 10
CorespondenŃa între competenŃele de evaluat performate şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii
C 1 Utilizarea
corectă şi adec-vată a limbii româ-ne în diferite situa-Ńii de comunicare
C 2 Utilizarea adecvată a strategiilor de compre-hensiune şi de interpret-tare, a modalităŃilor de
analiză
C3. Punerea în con-text a textelor studia-te prin raportare la
epocă sau la curente culturale/literare
C 4. Argumenta- rea în scris/oral a unor opinii în diverse situaŃii de comunicare
E4. c Interpretări şi judecăŃi de valoare exprimate în critica şi istoria literară
15,87%
E4. b Verbe evaluative, adverbe de mod, predicative ca mărci ale subiectivităŃii evaluatice etc; eseul argumentativ
29,86%
E4. a ConstrucŃia textului argumentativ; logica şi coerenŃa mesajului argumentativ
29,86%
E3. Trăsături ale curentelor culturale/ literare, reflectate în textele literare studiate sau în texte la prima vedere
79,33%
E2. e Viziune despre lume, teme şi motive, concepŃii despre artă, sensuri multiple ale textelor literare
12,27%
E2. d Toate conŃinuturile asociate acestei competenŃe specifice
17,91%
E2.c Toate conŃinuturile asociate acestei competenŃe specifice
17,91%
E2.b ParticularităŃi ale construcŃiei subiectului în textele narative
15,16%
E2. a Temă, motiv 13,92%
E1. d Sens denotativ şi sensuri conotative 3,60%
E1. c Normele limbii literare la nivelurile: ortografic şi de punctuaŃie, morfosintactic, lexico-semantic, stilistico-textual
4,02%
E1. b Exprimarea reacŃiilor şi a opiniilor faŃă de texte literare şi nonliterare, argumentare, rezumat
33,93%
E1.a Reguli generale în redactare 33,93%
Figura nr. 23 CorespondenŃa între competenŃele de evaluat şi unităŃile de conŃinut
Investeşte în oameni!
Pagina 11
Utilizarea la disciplina Matematică a borderoului electronic a permis analiza rezultatelor obŃinute de candidaŃi din pnct de vedere cantitativ şi calitativ şi din punctul de vedere al teoriei evaluării.
La sesiunea specială a examenului de bacalaureat, au susŃinut proba obligatorie la Matematică 226 de candidaŃi, restul de
ConŃinuturile evaluate prin proba scrisă la Matematică: Subiectul I
• MulŃimi şi elemente de logică. MulŃimi de numere. FuncŃii definite pe mulŃimea
numerelor naturale (şir)
• FuncŃii, lecturi grafice. FuncŃia de gradul I; FuncŃia de gradul al II-lea.
Interpretarea geometrică a proprietăŃilor algebrice ale funcŃiei de gradul al II-lea. EcuaŃii
• Metode de numărare. Matematici financiare
• Vectori în plan. Coliniaritate, concurenŃă, paralelism - calcul vectorial în
geometria plan. Geometrie
• Elemente de trigonometrie. AplicaŃii ale trigonometriei şi ale produsului scalar
a doi vectori în geometria plană
Subiectul al II-lea
• Permutări (numai în cazul programei MT1). Matrice
• DeterminanŃi. Sisteme de ecuaŃii liniare
• Grupuri. Inele şi corpuri. Inele de polinoame cu coeficienŃi într-un corp
comutativ (Q, R, C, Zp, p prim)
Subiectul al III-lea
• Limite de funcŃii. Continuitate. Derivabilitate. Reprezentarea grafică a
funcŃiilor
• Primitive (antiderivate). Integrala definită. AplicaŃii ale integralei definite
CompetenŃele de evaluat sunt următoarele: • Identificarea unor date şi relaŃii matematice şi corelarea lor în funcŃie de
contextul în care au fost definite
• Prelucrarea datelor de tip cantitativ, calitativ, structural, contextual cuprinse în
enunŃurile matematice
• Utilizarea algoritmilor şi a conceptelor matematice pentru caracterizarea
locală sau globală a unei situaŃii concrete
• Exprimarea caracteristicilor matematice cantitattive sau calitative ale unei
situaŃii concrete şi a algoritmilor de prelucrare a acestora
• Analizarea şi interpretarea caracteristicilor matematice ale unei situaŃii-
problemă
• Modelarea matematică a unor contexte problematice variate, prin integrarea
cunoştintelor
Vă prezentăm o captură a exportului din borderoul electronic realizat pentru această disciplină, în figura următoare:
Investeşte în oameni!
Exemplu de export din borderoul electronic realizat pentru proba E c disciplina Matematică
An
Eva
luar
e
Ses
iune
Cod
Cen
tru
Exa
men
Nr
Luc
rare
Nr
Cor
ectu
ri
Pu
nct
aj
To
tal
Sub
iect
1
Sub
iect
2
Sub
iect
3
Sub
iect
11
Sub
iect
12
Sub
iect
13
Sub
iect
14
Sub
iect
15
Sub
iect
16
Sub
iect
21A
Sub
iect
21B
Sub
iect
21C
Sub
iect
22A
Sub
iect
22B
Sub
iect
22C
Sub
iect
31A
Sub
iect
31B
Sub
iect
31C
Sub
iect
32A
Sub
iect
32B
Sub
iect
32C
I II III I1 I2 I3 I4 I5 I6 II1a II1b II1c II2a II2b II2c III1a III1b III1c III2a III2b III2c
RepartiŃia rezultatelor candidaŃilor pe tranşe de note
Figura nr. 25 RepartiŃia rezultatelor candidaŃilor pe tranşe de note RepartiŃia rezultatelor candidaŃilor pe tranşe de note ne oferă o imagine relevantă
a rezultatelor obŃinute de candidaŃii participanŃi la sesiunea specială a examenului de bacalaureat-2011, proba E. c - Matematică.
Investeşte în oameni!
Pagina 14
76%
90%
71%
60%
94%
85%91%90%
98%
83%
96%
69%
51%
92%
66%
51%
79%
63%
44%
83%
51%
40%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Punctaj
Tota
l
Subie
ctul I
Subie
ctul a
l II-l
ea
Subie
ctul a
l III-
lea
Subie
ct I
1
Subie
ct I
2
Subie
ct I
3
Subie
ct I
4
Subie
ct I
5
Subie
ct I
6
Subie
ct II
1a
Subie
ct II
1b
Subie
ct II
1c
Subie
ct II
2 a
Subie
ct II
2 b
Subie
ct II
2 c
Subie
ct II
I 1a
Subie
ct II
I 1 b
Subie
ct II
I 1c
Subie
ct II
I 2 a
Subie
ct II
I 2 b
Subie
ct II
I 2 c
Nivelul de performare a itemilor din cadrul testului de evaluare
Figura nr.26 Nivelul de performare a itemilor din cadrul testului de evaluare
pentru bacalaureat la disciplina Matematică
Această analiză nu se poate face decât utilizând borderoul electronic; din graficul asociat probei de matematică putem compara punctajele medii obŃinute la fiecare dintre cele trei subiecte (90%, 71%, 60%) cu punctajul mediu total al testului (76%).
Astfel, Ńinând seama de matricea de specificaŃii asociată testului, observăm că Subiectul I a fost rezolvat corect de 90% dintre candidaŃi, ceea ce arată că 90% au formate competenŃele evaluate prin conŃinuturile din programele şcolare pentru clasele a IX-a şi a X-a (algebră şi geometrie, conŃinuturi prezentate explicit în matricea de specificaŃii). Subiectul al II-lea, rezolvat de 71% dintre candidaŃi, verifică formarea competenŃelor specifice şi conŃinuturile din programele şcolare pentru cls. a XI-a şi a XII-a (algebră superioară: matrice, determinanŃi, sisteme de ecuaŃii liniare, structuri algebrice). Subiectul al III-lea, rezolvat de 60% dintre candidaŃi, verifică formarea competenŃelor specifice şi conŃinuturile din programele şcolare pentru cls. a XI-a şi a XII-a (analiză matematică, conform matricei de specificaŃii)
Investeşte în oameni!
Pagina 15
Analizând nivelul de performare a itemilor din cadrul testului de evaluare pentru bacalaureat la disciplina Matematică, în sesiunea specială, se observă că toŃi itemii testului au fost abordaŃi în rezolvările candidaŃilor; itemii III.2.c, III.1.c, II.1.c şi II.2.c., în această ordine, sunt cei cu un grad mai mare de dificultate, fapt ce poate constitui şi o explicaŃie pentru procentele obŃinute de cei care au rezolvat corect aceşti itemi.
Observăm, de asemenea, (din analizarea aceleiaşi reprezentări) că subiectele al II-lea şi al III-lea, care conŃin itemi de tip întrebări structurate, au fost bine formulate, în sensul în care la fiecare exerciŃiu în parte punctul a) (II.1.a, II.2.a, III.1.a, III.2.a) a fost rezolvat de cei mai mulŃi candidaŃi (96%, 92%, 79%, 83%), urmează punctele b), care au fost rezolvate respectiv de 69%, 66%, 63%, 51%, iar punctele c) au fost rezolvate de 51%, 51%, 44%, 40%.
4,68
4,264,574,49
4,89
4,15
4,79
3,47
2,57
4,61
3,30
2,56
3,96
3,16
2,21
4,13
2,54
2,00
-
0,50
1,00
1,50
2,00
2,50
3,00
3,50
4,00
4,50
5,00
Subie
ct I.
1
Subie
ct I.
2
Subie
ct I.
3
Subie
ct I.
4
Subie
ct I.
5
Subie
ct I.
6
Subie
ct II
.1.a
Subie
ct II
.1.b
Subie
ct II
.1.c
Subie
ct II
.2.a
Subie
ct II
.2.b
Subie
ct II
.2.c
Subie
ct II
I.1.a
Subie
ct II
I.1.b
Subie
ct II
I.1.c
Subie
ct II
I.2.a
Subie
ct II
I.2.b
Subie
ct II
I.2.c
DistribuŃia punctajelor medii totale, pe subiecte, pe itemi
Figura nr 27 DistribuŃia punctajelor medii totale pe itemi
Graficul anterior reflectă gradul de acoperire a fiecărui item prin punctajul mediu calculat pentru toŃi candidaŃii. Astfel, faŃă de punctajul maxim - 5 puncte - acordat fiecărui item se observă că minimul se situează la valoarea de 2,00 ( itemul III.2.c, cu grad de dificultate ridicat) şi maximul la 4, 89 (itemul I.5, cu un grad de dificultate mediu).
Investeşte în oameni!
Pagina 16
O altă modalitate de reflectare a corespondenŃei între competenŃele de evaluat,
unităŃile de conŃinut evidenŃiate în matricea de specificaŃii asociată testului şi performanŃele obŃinute de candidaŃi se regăseşte în tabelele următoare:
Investeşte în oameni!
RepartiŃia punctajelor medii obŃinute de candidaŃi pe subiecte (I, al II-a, al III-lea), compararea acestora cu punctajul mediu şi corespondenŃa cu competenŃele de evaliat econform matricei de specificaŃii:
Tabelul 4 CompetenŃe de
Evaluat (C)
ConŃinuturi (E)
C1: Identificarea unor date şi
relaŃii matematice şi
corelarea lor în funcŃie de
contextul în care au fost definite
C2: Prelucrarea
datelor de tip cantitativ, calitativ,
structural, contextual cuprinse în
enunŃuri matematice
C3: Utilizarea
algoritmilor şi a conceptelor
matematice pentru caracterizarea
locală sau globală a unei situaŃii
concrete
C4: Exprimarea caracteristicilor
matematice cantitative sau calitative ale unei situaŃii concrete şi a
algoritmilor de prelucrare a
acestora
C5: Analizarea şi interpretarea
caracteristicilor matematice ale
unei situaŃii-problemă
C6: Modelarea matematică a unor contexte problematice variate, prin integrarea
cunoştinŃelor
Rea
liza
t
Pro
pu
s
%
0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9
Subiectul I E1 Multimi si elemente de
logica ; Multimi de numere; Functii definite pe multimea
numerelor naturale
1.87 1.87 0.94 1.83 6.51 7 92.99
E2 Functii, lecturi grafice; Functia de gradul I; Functia de gradul al
II-lea; Interpretarea geometrica a proprietatilor algebrice ale functiei
de gradul al II-lea; Ecuatii
1.70 3.60 1.70 7.00 8 87.55
E3 Metode de numarare; Matematici financiare
0.90 0.90 1.80 0.90 4.49 5 89.87
E4 Vectori in plan; Coliniaritate, concurenta, paralelism,calcul
vectorial in geometria plana;Geometrie
2.94 0.98 0.98 4.89 5 97.87
Investeşte în oameni!
Pagina 18
0 1 2 3 4 5 6 7 8 9
E5 Elemente de trigonometrie; Aplicatii ale trigonometriei si ale produsului scalar a doi vectori in
Conform matricei de specificaŃii, competenŃelor de evaluat (C1, C2, C3,....C6) şi conŃinuturilor programei de examen (E1, E2, .....,E10) li se asociază repartiŃia punctajelor medii obŃinute de candidaŃi (între 0p şi 5p). În acest caz se pot compara punctajele obŃinute de către candidaŃi pentru item cu media punctajului fiecărui item.
De exemplu, conŃinutul “MulŃimi şi elemente de logică; mulŃimi de numere, funcŃii definite pe mulŃimea numerelor naturale” are asociat, prin matricea de specificaŃii, competenŃele de evaluat C1, C2, C3, C4 şi dintr-un total de 7p, propus prin matricea de specificaŃii, s-a realizat o medie de 6,51p. Această analiză este ilustrată pentru fiecare unitate de conŃinut din matricea de specificaŃii.
Prin reprezentarea grafică următoare, asociată datelor de mai sus, se vizualizează diferenŃa dintre punctajul propus prin matricea de specificaŃii şi cel realizat pentru fiecare unitate de conŃinut.
92,99 87,55 89,87
97,87
82,93
62,82
80,28
69,78
62,18 57,80
-
10,00
20,00
30,00
40,00
50,00
60,00
70,00
80,00
90,00
100,00
E 1 E 2 E 3 E 4 E 5 E 6 E 7 E 8 E 9 E 10
Ilustrarea gradului de acoperire a conŃinuturilor prin competenŃele evaluat asociate în matricea de specificaŃii
Figura nr.28 Ilustrarea gradului de acoperire a conŃinuturilor prin competenŃele evaluat
asociate în matricea de specificaŃii Dacă aceleaşi date sunt studiate din punct de vedere procentual este evidenŃiat pentru
fiecare unitate de conŃinut din matricea de specificaŃii, procentul de acoperire a competenŃelor de evaluat.
Corelarea competenŃelor de evaluat (C1, C2, C3, C4, C5, C6) şi a conŃinuturilor (E1,E2, …E10 )asociate prin matricea de specificaŃii
Investeşte în oameni
Pagina 21
Figura nr. 29 Corelarea competenŃelor de evaluat (C1, C2, C3, C4, C5, C6) şi a conŃinuturilor (E1,E2, …E10 ) asociate conform matricei de specificaŃii, în cadrul
probei scrise la Matematică
Investeşte în oameni
Pagina 22
-
2,00
4,00
6,00
8,00
10,00
12,00
14,00
16,00
18,00
20,00
CorespondenŃa între competenŃele de evaluat şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii
Figura nr. 30 CorespondenŃa între competenŃele de evaluat (C1, C2, …. C6) şi unităŃile de conŃinut evidenŃiate(E1, E2 ….., E10)) în matricea de specificaŃii asociată testului
Investeşte în oameni
Pagina 23
În figura următoare etse prezentată corespondenŃa conŃinuturilor asociate competenŃelor de evaluat performate (C1, C2, C3, C4, C5, C6) şi unităŃile de conŃinut (E1, E2, ….E10) conform matricei de specificaŃii, în cadrul probei scrise la Matematică.
0,00
2,00
4,00
6,00
8,00
10,00
12,00
CorespondenŃa între competenŃele de evaluat performate şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii
Figura nr.31 CorespondenŃa între competenŃele de evaluat performate şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii.
Matricea care stă la baza construirii graficului este asociată matricei de specificaŃii (pe linii sunt trecute unităŃile de conŃinut şi pe coloane sunt trecute competenŃele de
Investeşte în oameni
Pagina 24
evaluat). Testul este bine construit dacă această matrice are aceleaşi celule completate ca şi matricea de specificaŃii.
Matricea de mai sus reprezintă nivelul de performare ponderat, calculat pentru fiecare unitate de conŃinut în parte şi pentru fiecare competenŃă de evaluat avută în vedere conform matriciei de specificaŃii.
S-a luat în calcul defalcarea pe competenŃe a punctajului acordat fiecărui item conform baremului de evaluare şi de notare.
Această analiză aduce elemente importante legate de performarea compenŃelor de evaluat prin intermediul conŃinuturilor, în funcŃie de rezultatele obŃinute de candidaŃi. Se observă o acoperire echitabilă a competenŃelor de evaluat corespunzătoare nivelurilor cognitive, în funcŃie de unitatea de conŃinut din matricea de specificaŃii.
Deci, folosind borderoul electronic, putem trage concluzii referitoare atât la modul în care a fost conceput testul (din punct de vedere a teoriei evaluării - efectul back-wash), cât şi la modul în care a fost abordat testul de către candidaŃi.
În cadrul sesiunii speciale a Examenului de bacalaureat-2011 au susŃinut proba E c la
disciplina Istorie 368 de candidaŃi. Datorită completării datelor în borderoul electronuc este permisă o analiză mai detaliată a rezultatelor.
DistribuŃia, pe tranşe de note, a rezultatelor obŃinute de candidaŃi
Figura nr. 32 DistribuŃia, pe tranşe de note, a rezultatelor obŃinute de
candidaŃi la proba E c - disciplina Istorie Promovabilitatea candidaŃilor este ilustrată de graficul de mai sus. Se constată că
majoritatea rezultatelor se situează în tranşa notelor 7 - 8, fapt ce permite aprecierea conform căreia testul reflectă una dintre funcŃiile examenului de bacalaureat, pe aceea de
Investeşte în oameni
Pagina 25
certificare a competenŃelor dobândite pe parcursul învăŃământului liceal. În ceea ce priveşte funcŃia de selecŃie a examenului, diagrama ilustrează că testul a îndeplinit şi această funcŃie deoarece 29 de candidaŃi au obŃinut note cuprinse între 9 şi 10, respectiv 3 au obŃinut nota 10.
74%79%
71%
64%
100%100%99%100%
77%
54% 54%
98%93%
96%
89%
52%
32%
59%
74%
88%
81%
93%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Punctaj
Total
Subiect I
Subiect I
I
Subiect I
II
Subiect I
1
Subiect I
2
Subiect I
3
Subiect I
4
Subiect I
5
Subiect I
6
Subiect I
7
Subiect I
I 1
Subiect I
I 2
Subiect I
I 3
Subiect I
I 4
Subiect I
I 5
Subiect I
I 6
Subiect I
II a
Subiect I
II b 1
Subiect
III b 2
Subiect I
II b3
Subiect I
II b 4
Distribuţia procentuală a performării pentru fiecare tip de item
Figura nr 33 DistribuŃia procentuală a performării pe fiecare subiect şi pe fiecare item din proba scrisă E. c) - Istorie
În funcŃie de punctajele medii obŃinute şi ilustrate în graficul de mai sus se constată ca testul a fost performat cu un punctaj mediu de 74%.
Subiectul I, reprezentat de o întrebare structurată având ca material-stimul două surse istorice referitoare la istoria românilor, are un punctaj mediu de 79%. În cadrul lui punctaje medii aproape de 100% au revenit cerinŃelor care evaluează primele niveluri cognitive ale cunoaşterii. Subiectul al II-lea format dintr-o întrebare structurată având ca material-stimul o sursă istorică referitoare la istoria universală are punctajul mediu de 71%. Aceleaşi cerinŃe care evaluează identificarea/ recunoaşterea au punctajul mediu peste 90%. Subiectul al III-lea, reprezentat de un eseu structurat pornind de la o temă dată, are
Investeşte în oameni
Pagina 26
punctajul mediu de 64%. Ultima cerinŃă - referitoare la încadrarea sintezei în limita de spaŃiu – este singura care depăşeşte 90%.
1,991,99
5,96
2,99
5,39
3,26
2,15 1,971,86
5,735,325,18
1,28
14,19
1,480,88
1,630,93
-
2,00
4,00
6,00
8,00
10,00
12,00
14,00
16,00
Subi
ect I 1
Subi
ect I 2
Subi
ect I 3
Subi
ect I 4
Subi
ect I 5
Subi
ect I 6
Subi
ect I 7
Subi
ect II
1
Subi
ect II 2
Subi
ect II 3
Subi
ect II
4
Subi
ect II
5
Subi
ect II
6
Subi
ect III
A
Subi
ect III
B1
Subi
ect III
B2
Subi
ect III
B3
Subi
ect III
B4
Punctaje medii obŃinute pe fiecare item din proba scrisă
Figura nr.32 Punctaje obŃinute pe fiecare item din proba scrisă E c – Istorie Prin baremul de evaluare şi de notare fiecărui item i s-a alocat, în funcŃie de
complexitatea competenŃei evaluate şi de specificul evaluării sumative, un numar de puncte astfel încât pentru fiecare subiect să se obŃină un total de 30 de puncte. Graficul prezentat mai sus reflectă, în primul rând, media punctajului obŃinut pentru fiecare subiect şi pentru fiecare item, iar în al doilea rând evidenŃiază performarea diferenŃiată a cerinŃelor.
Investeşte în oameni
Pagina 27
55,24
73,84
78,47
56,97
59,15
88,52
59,12
74,41
99,18
99,73
58,16
66,84
90,54
59,12
63,61
0,00 20,00 40,00 60,00 80,00 100,00
1.1. Formularea de argumente referitoare la un subiectistoric
1.2. Folosirea limbajului adecvat în cadrul uneiprezentări scrise
1.3. EvidenŃierea relaŃiei cauză – efect într-osuccesiune de evenimente sau procese istorice
1.4. Formularea, în scris, a unor opinii referitoare la otemă de istorie
1. Utilizarea eficientă a comunicării şi a limbajului despecialitate
2.1. Extragerea informaŃiei esenŃiale dintr-un mesaj
2.2. Descoperirea constantelor în desfăşurareafenomenelor istorice studiate
2. Exersarea demersurilor şi acŃiunilor civicedemocratice
3.1. Selectarea şi comentarea surselor istorice pentrua susŃine/ combate un punct de vedere
3.2. Descoperirea în sursele de informare aperspectivelor multiple asupra evenimentelor şi
3.3. Analiza diversităŃii sociale, culturale şi decivilizaŃie în istorie pornind de la sursele istorice
3. Aplicarea principiilor şi a metodelor adecvate înabordarea surselor istorice
4.1. Utilizarea adecvată a coordonatelor temporale şispaŃiale relative la un subiect istoric
4.2. Construirea de sinteze tematice
4. Utilizarea surselor istorice, a metodelor şi atehnicilor adecvate istoriei pentru rezolvarea de
Procentul de performare a competenŃelor de evaluat
Figura nr 33 Procentul de performare a competenŃelor de evaluat – proba E c - Istorie
Investeşte în oameni!
Pagina 28
CompetenŃele evaluate prin proba scrisă la disciplina Istorie sunt cele înscrise în
Programa de examen şi au constituit una dintre componenetele matricei de specificaŃii care a stat la baza elaborării testului. Graficul anterior reflectă gradul de performare a competenŃelor de evaluat. Se remarcă buna performare a competenŃelor 3.1, 3.2 şi 4.1., precum şi mai slaba performare a competenŃelor 1.1, 1.4 care vizează niveluri cognitive superioare ale cunoaşterii.
Tabelul 6 CompetenŃe
Utilizarea eficientă a comunicării şi a limbajului de specialitate
Exersarea demersurilor şi acŃiunilor civice democratice
Aplicarea principiilor şi a metodelor adecvate în abordarea surselor istorice
Utilizarea surselor istorice, a metodelor şi a tehnicilor adecvate istoriei pentru rezolvarea de probleme
Fiecare dintre cele trei subiecte ale probei scrise la disciplina Istorie a evaluat câte un
set de competenŃe prin intermediul conŃinuturilor studiate şi prevăzute în Programa de examen. Graficul de mai jos prezintă nivelul de performare a competenŃelor de evaluat pentru fiecare subiect.
Investeşte în oameni!
Pagina 32
26,7333
21,33
30
74,94
101
-
20,00
40,00
60,00
80,00
100,00
120,00
Niveluri cognitive propuse si realizate de subiecte
Nivel de performare a competentelor realizat
Nivel de performare a competentelor propus
Figura nr. 35 Nivelul de performare a competenŃelor de evaluat realizat
pentru fiecare subiect din proba E c - Istorie
Se observă că gradul de performare pentru subiectele I şi al II-lea se situează la valori apropiate de nivelul propus, fapt ce poate fi explicat şi prin tipologia itemilor – întrebări structurate având surse istorice ca material-stimul, în timp ce pentru subiectul al III-lea nivelul realizat de performare a competenŃelor de evaluat este mai scăzut faŃă de nivelul propus.
Investeşte în oameni!
Pagina 33
81,01
71,12 74,19
-
10,00
20,00
30,00
40,00
50,00
60,00
70,00
80,00
90,00
Subiectul I Subiectul al II-lea Subiectul al III-lea
Procentul de performare a competenŃelor de evaluat pentru fiecare subiect
Figura nr. 36 Procentul de performare a competenŃelor de evaluat pentru
fiecare subiect din proba E c – Istorie Graficul de mai sus prezintă o altă perspectivă a nivelului de performare a
competenŃelor evaluate pentru fiecare subiect în parte. Performarea mai scăzută pentru competenŃele evaluate prin Subiectul al II-lea se poate explica prin existenŃa a două cerinŃe care evaluează competenŃele 1.1, 1.4.
Investeşte în oameni!
Pagina 34
0
5
10
15
20
25
CorespondenŃa între competenŃele de evaluat performate şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii
S III 14,19 1,48 0,88 14,19 14,19 14,19 1,63 14,19
S II 1,28 5,18 12,91 1,97
SI 5,39 10,1 2,99 2,99 3,26 1,99
C 1.1 C 1.2 C 1.3 C 1.4 C 2.1 C 2.2 C 3.1 C 3.2 C 3.3 C 4.1 C 4.2
Figura nr.37 CorespondenŃa între competenŃele de evaluat performate şi unităŃile de conŃinut evidenŃiate în matricea de specificaŃii
Prezentarea grafică a rezultatelor obŃinute de candidaŃi, a nivelului de performare
pentru fiecare item şi pentru fiecare competenŃă de evaluat constituie argumente în favoarea utilizării borderoului electronic. Acestora li se adaugă posibilitatea analizării fiecărui element component al probei scrise (competenŃe de evaluat, conŃinuturi, itemi, barem de evaluare şi de notare), fapt ce poate avea consecinŃe asupra programei de examen, asupra probei scrise (structură, tipuri de itemi etc.) şi, de asemenea, asupra procesului instructiv-educativ.
Investeşte în oameni!
Pagina 35
P A R T E A A I I - A SUPORTUL DE CURS
TEMA 2 Introducere în limbajul de cereri pentru baze de date relaŃionale SQL.
Cereri SELECT pe o tabelă Obiectivele temei urmăresc: • Prezentarea elementelor generale privind limbajul SQL; • Utilizarea cererilor SELECT simple, având la bază o singură tabelă. • Utilizarea clauzelor WHERE şi ORDER BY
1. INTRODUCERE Istoria bazelor de date relaŃionale începe în 16.80 o dată cu publicarea articolului lui Edgar Frank Codd A Relational Model of Data for Large Shared Data Banks care descrie modelarea datelor sub formă de relaŃii (termen matematic, reprezentarea intuitivă a unei relaŃii fiind o tabelă) şi operaŃiile de bază cu acestea. O serie de firme prestigioase au investit în cercetări privind modelul relaŃional al datelor, printre acestea numărându-se şi gigantul IBM care a lansat în anii ’70 dezvoltarea unui prototip de cercetare numit System R. În cadrul acestui sistem – care nu a fost niciodată comercializat ca atare, fiind folosit doar ca instrument de cercetare – a fost dezvoltat şi un limbaj de cereri prin care utilizatorul interacŃiona cu datele din baza de date numit SEQUEL (de la Structured English-like Query Language) redenumit apoi din motive comerciale SQL. System R a fost precursorul sistemului DB2 pe care IBM îl comercializează şi în momentul actual. Istoria MySQL începe în anul 1994 în cadrul firmei suedeze MySQL AB. Din 2008 firma a fost cumpărată de Sun Microsystems iar actualmente este controlată de corporaŃia Oracle care a cumpărat Sun în 2010. Versiunea actuala de MySQL este 5.5 (din decembrie 2010).
1.1. Limbajul SQL Limbajul SQL este un limbaj declarativ, neprocedural, şi permite utilizatorului să specifice ce doreşte lăsând SGBD-ul să decidă cum va rezolva cererea respectivă. El intră în categoria limbajelor de cereri fiind folosit pentru comunicaŃia clienŃilor unui SGBD cu acesta. În consecinŃă nu vom putea niciodată să vorbim de un ‘program SQL’, întotdeauna fiind nevoie de încă un limbaj sau mediu de dezvoltare pentru a scrie aplicaŃii care includ execuŃia de cereri SQL.
Investeşte în oameni!
Pagina 36
IniŃial fiecare firmă care producea sisteme de gestiune a bazelor de date avea propria sa versiune de SQL. Primii paşi spre standardizare au fost făcuŃi în 1986 şi 1987 când ANSI (American National Standards Institute) şi respectiv ISO (International Organization for Standardization) au adoptat un standard pentru sintaxa SQL, invitând implicit companiile producătoare să se alinieze acestuia. Până în prezent standardul a fost actualizat de mai multe ori rezultând mai multe versiuni, după cum se poate vedea în fig. 1.1. Versiune Descriere SQL-86 (sau SQL-87) Prima versiune a standardului SQL adoptată de
ANSI în 1986 şi de ISO în 1987 SQL-89 A doua versiune a standardului SQL. Nu sunt
modificări majore faŃă de SQL-86. Apare integritatea referenŃială.
SQL-92 sau SQL-2 Versiunea din 1992 aduce o serie de îmbunătăŃiri standardului SQL-89 printre care: conceptele de schemă, domeniu, set de caractere naŃional, tipul BLOB
SQL:1999 sau SQL-3 Apar o serie de facilităŃi ca: facilităŃi object-relational, patru tipuri LOB, tipuri structurate (ARRAY), tipul BOOLEAN, roluri, noi operatori.
SQL:2003 Ultima versiune, adăugând facilităŃi XML Fig. 1.1. Standarde SQL apărute până în prezent Cu toate acestea sistemele existente actualmente, atât cele comerciale cât şi cele necomerciale, au propriile omisiuni, extensii sau interpretări ale standardului, datorate atât necesităŃii de a menŃine compatibilitatea cu versiunile anterioare cât şi filosofiei diferite de la un sistem la altul. Din această cauză o cerere SQL validă într-un anumit sistem poate fi eronată în altul sau poate produce rezultate diferite plecând de la aceleaşi date de intrare. În plus, unele dintre extensiile procedurale existente, cum este PL/SQL în cazul Oracle sau Transact-SQL în cazul Microsoft SQL Server, sunt extensii proprietare care nu rulează decât pe sistemul pentru care au fost realizate. Practic, multe aplicaŃii scrise pentru un anumit SGBD nu pot fi portate direct pe un altul, fiind necesare operaŃii de adaptare a părŃilor de interacŃiune cu acesta. Din punct de vedere al semnificaŃiei operaŃiilor efectuate, cererile SQL se împart în câteva mari categorii. Denumirea lor este legată de istora sistemelor de gestiune, iniŃial pentru fiecare categorie de operaŃii existând un limbaj diferit prin care acestea erau specificate. În cazul SQL, acesta le încorporează pe toate dar clasificarea iniŃială a rămas în literatura de specialitate. A. Cereri care implementează Limbajul de Manipulare a Datelor Aceste cereri, numite şi cereri DML (după prescurtarea din engleză: Data Manipulation Language) acŃionează asupra conŃinutului tabelelor care formează baza de date. Principalele cereri din această categorie sunt:
Investeşte în oameni!
Pagina 37
Cerere AcŃiune INSERT Adăugarea de noi linii într-o tabelă
DELETE Ştergerea de linii dintr-o tabelă
UPDATE Modificarea valorilor din liniile unei tabele
SELECT Regăsirea datelor din una sau mai multe tabele, pe baza unor criterii de selecŃie
Fig. 1.2. Tipuri de cereri DML
Dintre cererile de mai sus cea mai folosită în aplicaŃii este cererea SELECT. În fapt, orice stocare de date are ca scop final regăsirea acestora în mod selectiv, în funcŃie de necesităŃile de prelucrare. Tot în categoria cererilor DML putem include şi COMMIT, ROLLBACK şi SAVEPOINT. Acestea se referă la faptul că modificările făcute de un utilizator în conŃinutul datelor (prin INSERT, UPDATE, DELETE) nu sunt vizibile decât acestuia până în momentul în care el execută o cerere COMMIT care le face definitive. Dacă nu execută (explicit sau implicit) COMMIT, utilizatorul poate reveni la forma iniŃială a datelor prin ROLLBACK sau poate reveni parŃial prin fixarea cu SAVEPOINT a unor puncte de întoarcere şi revenirea asupra tuturor modificărilor făcute de la acestea cu ROLLBACK TO SAVEPOINT. Mai multe detalii vor fi prezentate în capitolul dedicat comenzilor de modificare a conŃinutului tabelelor. B. Cereri care implementează Limbajul de Definire a Datelor Cererile din această categorie, numite şi cereri DDL (Data Definition Language) permit crearea şi modificarea obiectelor din baza de date (tabele dar nu numai). Principalele tipuri de cereri din această categorie sunt: Cerere AcŃiune CREATE Adăugarea unui nou obiect în baza de date (tabelă,
ALTER Modificarea structurii sau proprietăŃilor unui obiect din baza de date.
Fig. 1.3. Tipuri de cereri DDL
Cererile din această categorie fac automat COMMIT înainte şi după execuŃia lor. Din această cauză efectul lor nu poate fi anulat cu ROLLBACK. Ştergerea sau modificarea structurii unui obiect din baza de date este definitivă. O dată şters el poate fi recuperat doar din salvările anterioare ale bazei de date.
1.2. Structura bazei de date utilizate
Investeşte în oameni!
Pagina 38
Pe parcursul lucrării majoritatea exemplelor vor porni de la o bază de date formată din trei tabele: Tabela ELEV ConŃine date despre elevii unui liceu. Coloanele acestei tabele au următoarea semnificaŃie:
MATR Numărul matricol al elevului, cheie primară. NUME Numele elevului AN Anul: între 1 şi 4 CLASA Indicativul clasei elevului DATAN Data naşterii LOC Locul naşterii TUTOR Matricola tutorului (un elev de an mai mare) sau NULL
dacă nu are tutor. MEDIA Media elevului.
CODP Codul numeric al profilului la care este înmatriculat elevul.
Fig. 1.4. Structura tabelei ELEV Tabela PROFIL ConŃine date despre profilurile pentru acel liceu. Coloanele acestei tabele au următoarea semnificaŃie:
CODP Codul numeric al profilului, unic pentru fiecare profil în parte PROFIL Denumirea profilului FILIERA Filiera din care face parte profilul
Fig. 1.5. Structura tabelei PROFIL
Tabela REZULTAT ConŃine date despre tipurile de rezultate pe care le poate obŃine un elev (calificative) în funcŃie de media elevului. Coloanele acestei tabele au următoarea semnificaŃie:
TIP Calificativul MMIN Medie minimă pentru acel calificativ MMAX Medie maximă pentru acel calificativ REZ Calificativul (abreviere)
Fig. 1.6. Structura tabelei REZULTAT
CorelaŃiile existente între cele trei tabele ale bazei de date sunt următoarele: � Tabelele ELEV şi PROFIL au în comun coloana CODP care reprezintă codul profilului. În tabela PROFIL ea poate fi aleasă cheie primară ceea ce face ca în ELEV să devină cheie străină.
Investeşte în oameni!
Pagina 39
� Tabelele ELEV şi REZULTAT sunt corelate astfel: calificativul unui elev se determină din valoarea de pe coloana MEDIA care este între MMIN şi MMAX pentru linia corespunzătoare acelui calificativ din tabela REZULTAT ConŃinutul tabelelor cel prezentat în figura următoare: REZULTAT:
TIP MMIN MMAX REZ
INSUFICIENT 0 4.99 (NULL)
SUFICIENT 5.00 5.99 SU
SATISFĂCĂTOR 6.00 7.99 SA
BINE 8.00 8.99 BI
FOARTE BINE 9.00 10.00 FB
ELEV: MATR NUME AN CLASA DATAN LOC TUTOR MEDIA CODP
1456 GEORGE 4 12A 1993-03-12 BUCURESTI (NULL) 9.95 11
1325 VASILE 2 10A 1995-10-05 PITESTI 1456 4.50 11
1645 MARIA 3 11A 1994-06-17 PLOIESTI (NULL) 7.58 11
După cum se observă, tabelele ELEV şi REZULTAT conŃin în unele celule aşa numitele valori nule. O valoare nulă este o valoare diferită de oricare alta care modelează fie o informaŃie încă necunoscută fie faptul că în locul respectiv nu trebuie să fie nici o valoare. În cazul exemplului semnificaŃia valorilor nule este următoarea: � Pe coloana TUTOR din tabela ELEV există valori nule pentru elevii din anii mari. PrezenŃa valorilor nule este corectă pentru că aceştia nu au un tutor. � În cazul tabelei REZULTAT valoarea nulă din prima linie - pe coloana REZ - arată că pentru elevii fără calificativ de trecere abrevierea acestuia a fost modelată printr-o valoare nulă. Valorile nule au caracteristici diferite de cele ale valorilor nenule în privinŃa participării la expresii, comparaŃia cu alte valori, ordinea de sortare, etc.
2. CERERI SELECT PE O TABELĂ O cerere SQL este formată din mai multe părŃi, numite clauze. Fiecare începe cu un cuvânt cheie care identifică clauza respectivă. Prima clauză din cerere este cea care determină şi tipul cererii. Acest capitol prezintă cererile de regăsire a informaŃiei aflate într-o singură tabelă a bazei de date. Acestea încep întotdeauna cu clauza SELECT şi de obicei conŃin o a doua clauză FROM. O cerere SELECT simplă are următoarea sintaxă generală: SELECT [DISTINCT] lista_de_expresii FROM nume_tabela -- optionala WHERE conditie_linie -- optional ORDER BY criterii_sortare_rezultat; -- optional LIMIT [prima_linie,] nr_linii -- optional Efectul ei este următorul: � Se parcurg rând pe rând liniile tabelei specificate pe clauza FROM. � Din fiecare linie conŃinând date pentru care condiŃia aflată pe clauza WHERE este adevărată va rezulta o linie în rezultatul cererii. În cazul în care WHERE lipseşte, toate liniile tabelei FROM vor avea o linie corespondentă în rezultatul cererii. � Linia de rezultat este compusă pe baza listei de expresii aflată pe clauza SELECT. � Dacă există cuvântul cheie DISTINCT, din rezultat se elimină liniile duplicat. � Înainte de a trimite rezultatul, serverul îl sortează în funcŃie de criteriile specificate de clauza ORDER BY. În cazul în care ORDER BY lipseşte, liniile din rezultat sunt într-o ordine independentă de conŃinutul lor sau de ordinea în care ele au fost adăugate în tabelă. O astfel de cerere porneşte deci de la o tabelă din baza de date şi produce ca rezultat tot o tabelă cu următoarele caracteristici: � Numărul coloanelor din rezultat este egal cu numărul expresiilor din lista aflată pe clauza SELECT. Aceste expresii dau şi numele coloanelor din rezultat.
Investeşte în oameni!
Pagina 41
� În lipsa clauzei DISTINCT, numărul de linii din rezultat este egal cu numărul liniilor din tabelă care îndeplinesc condiŃia WHERE sau, când clauza respectivă lipseşte, cu numărul total de linii din tabelă. � Evaluarea valorii de adevăr a condiŃiei din WHERE se face doar pe baza datelor aflate pe linia respectivă. � Deoarece parcurgerea liniilor specificată de o cerere SELECT se face după un plan de execuŃie generat de server, folosirea clauzei ORDER BY este obligatorie în cazul în care se doreşte un rezultat sortat după anumite criterii. Din motive de claritate, în exemplele următoare fiecare clauză începe pe o linie nouă. Aceasta nu înseamnă că se pot asimila clauzele unor ‘instrucŃiuni’ care compun cererea, sau că o cerere SQL este un ‘program’, ele neputând fi executate separat. În paragrafele următoare sunt prezentate elementele care pot fi folosite pe fiecare dintre clauzele de mai sus. Exemplele folosesc tabelele ELEV, PROFIL şi REZULTAT descrise în capitolul 1. 2.1. Clauza SELECT Cele mai simple cereri de regăsire conŃin doar clauzele SELECT şi FROM. De exemplu, dacă dorim o listă cu denumirile profilurilor şi ale filierelor de care aparŃin, cererea este:
SELECT NUME, FILIERA FROM PROFIL;
Rezultatul va avea două coloane, NUME şi FILIERA, şi trei linii, câte una pentru fiecare linie a tabelei PROFIL:
NUME FILIERA
REAL TEORETICĂ
UMANIST TEORETICĂ
RESURSE NATURALE TEHNOLOGICĂ
Atunci când se doreşte afişarea tuturor coloanelor unei tabele, se poate folosi pentru lista acestora caracterul * (asterisc). El e interpretat ca lista numelor coloanelor în ordinea în care acestea au fost specificate în momentul creerii tabelei respective. De exemplu, cererea:
SELECT * FROM ELEV;
are ca rezultat conŃinutul tabelei ELEV. ObservaŃii: 1. Lista SELECT poate conŃine mai multe elemente identice. Următoarea cerere este validă:
SELECT NUME, NUME, FILIERA, NUME, FILIERA FROM PROFIL;
Investeşte în oameni!
Pagina 42
2. Clauza FROM poate lipsi din cerere. În acest caz rezultatul va conŃine o singură linie şi nu depinde de conŃinutul bazei de date. De exemplu cererea:
SELECT 3.1415*POWER(10, 2), 2*3.1415*10; returnează suprafaŃa şi circumferinŃa unui cerc cu latura de 10 metri. 3. În cazul folosirii *, acesta trebuie sa fie primul in lista SELECT.Cererea:
SELECT *, NUME FROM PROFIL;
nu va genera eroare, în schimb cererile:
SELECT NUME,* FROM PROFIL;
sau SELECT NUME,*,NUME FROM PROFIL;
generează eroarea cu codul 1064 (eroare de sintaxă) deoarece * nu este o expresie validă dacă urmează unui alt element din SELECT. În afară de nume de coloane şi caracterul asterisc, pe clauza SELECT mai pot fi prezente şi următoarele elemente: a. Constante Constantele pot fi numerice, de tip şir de caractere sau constanta NULL (valoare nulă). Şirurile de caractere (numite uneori şi literali în diverse documentaŃii) se scriu între apostrofi (sau ghilimele daca modul SQL cu numele ANSI_QUOTES nu este activ). În cazul în care un element al listei SELECT este constant rezultatul cererii va avea aceeaşi valoare pe coloana corespunzătoare. În exemplul următor prima şi ultimele două coloane ale rezultatului conŃin astfel de valori constante:
SELECT 'Profilul ', NUME, " infiintat in ", 1995 FROM PROFIL
Rezultatul este:
Profilul NUME infiintat in 1995
Profilul REAL infiintat in 1995
Profilul UMANIST infiintat in 1995
Profilul RESURSE NATURALE infiintat in 1995
b. Expresii aritmetice
Investeşte în oameni!
Pagina 43
Elementele din lista SELECT pot fi expresii complexe conŃinând nume de coloane, constante, apeluri de funcŃii şi operatori. În cazul expresiilor aritmetice sunt disponibili operatorii uzuali: ÎnmulŃirile şi împărŃirile au prioritate faŃă de adunări şi scăderi. Pentru a schimba ordinea de evaluare se pot folosi parantezele rotunde. De exemplu, cererea:
SELECT TIP, REZ, (MMAX+MMIN)/2*1.1 FROM REZULTAT;
afişează pentru fiecare calificativ tipul, abrevierea acestuia si media celor doua valori (minimă şi maximă) înmulŃita cu 1.1 (creştere cu 10%). Rezultatul este următorul:
TIP REZ (MMAX+MMIN)/2*1.1
INSUFICIENT (NULL) 2.7445000
SUFICIENT SU 6.0445000
SATISFĂCĂTOR SA 7.6945000
BINE BI 9.3445000
FOARTE BINE FB 10.4500000
După cum se observă şi din prima linie a rezultatului, în cazul în care o expresie conŃine o valoare nulă, întreaga expresie este evaluată la NULL. Pentru astfel de cazuri, în MySQL există funcŃia IFNULL:
IFNULL(expresie1, expresie2) are ca rezultat: � Dacă expresie1 are o valoare nenulă, NVL întoarce valoarea acesteia. � Dacă expresie1 este nulă, NVL întoarce valoarea pentru expresie2, inclusiv în cazul în care aceasta se evaluează de asemenea la o valoare nulă. Cele două expresii trebuie să fie de acelaşi tip sau valorile lor să fie compatibile. Folosind această funcŃie putem specifica în cazul cererii anterioare transformarea valorii nule a expresiei în şirul ‘VN’ (valoare nulă): SELECT TIP, IFNULL(REZ, 'VAL.NULA'), (MMAX+MMIN)/2*1.1 FROM REZULTAT; Prima linie a rezultatului este în acest caz:
FuncŃia IFNULL se poate folosi si pentru numere sau date calendaristice. De exemplu cererea următoare este validă:
SELECT NUME, IFNULL(TUTOR, '0000'), IFNULL(DATAN, '2006-01-01') FROM ELEV;
Dacă unii elevi nu ar avea completat locul sau data naşterii ar fi afişate valorile specificate ca al doilea parametru al NVL. ObservaŃie: Valoarea nulă este simbolizată în MySQL prin NULL (fără apostrofi sau ghilimele), indiferent de tipul de litere cu care se scrie (mici sau mari). NULL nu este egal cu şirul vid '' şi nici cu şirurile 'NULL' sau "NULL". d. Alias de coloană În unele cazuri – cum este şi în exemplul precedent – se poate pune problema ca în rezultat o coloană să aibă alt nume decât cel standard, dat de expresia din clauza SELECT. În acest caz se poate specifica un nume alternativ, numit uzual alias de coloană. Aliasul se defineşte adăugându-l în cerere imediat după expresia corespunzătoare lui. Un alias de coloană are următoarele caracteristici: � Nu poate fi mai lung de 256 de caractere. Aliasurile folosite în comenzi de tip CREATE VIEW trebuie să respecte condiŃiile pentru numele de coloană şi deci nu pot fi mai lungi de 64 de caractere. � În cazul în care conŃine doar cifre sau conŃine alte caractere decât litere, cifre, _ şi $ atunci trebuie pus între apostrofi inverşi ` sau apostrofi normali ' (sau ghilimele când modul ANSI_QUOTES este activ). În acest caz el va fi folosit în alte clauze în acelasi mod. � Nu poate fi folosit decât în cererea curentă. Sistemul nu stochează în baza de date sau altundeva aceste nume alternative. � Un alias asociat unei coloane dintr-un rezultat poate fi folosit în locul numelui acesteia în GROUP BY, HAVING şi ORDER BY dar nu şi în WHERE. Între expresie şi alias nu se pune virgulă, separarea făcându-se folosind cuvântul cheie AS sau cu unul sau mai multe caractere albe (spaŃiu, tab, linie nouă). Exemplu:
SELECT TIP AS `Calificativ`, CONCAT(' are abrevierea ' , IFNULL(REZ, 'lipsa'), '.') AS 'Abreviere calificativ' FROM REZULTAT;
e. Eliminarea liniilor duplicat: DISTINCT Unele dintre liniile rezultatului unei cereri SELECT pot fi identice, ca în cazul următor:
SELECT CODP FROM ELEV;
Deşi există doar trei profiluri distincte la care sunt înscrişi elevii, rezultatul va avea 12 linii, tot atâtea câte are şi tabela ELEV. Pentru a elimina liniile duplicat se foloseşte cuvântul cheie DISTINCT plasat imediat după SELECT. De exemplu cererile:
SELECT DISTINCT CODP FROM ELEV;
şi SELECT DISTINCT CODP, AN FROM ELEV;
vor returna 3, respectiv 12 linii, deoarece în tabela ELEV există 3 valori distincte pe coloana CODP şi 12 cupluri de valori distincte pe coloanele (CODP, AN). Rezultatul primei cereri este:
CODP
11
21
24
În cazul folosirii opŃiunii DISTINCT în lista de expresii se pot utiliza toate celelalte elemente prezentate anterior. 2.2. Clauza WHERE În cererile anterioare din fiecare linie a tabelei specificate de clauza FROM rezultă o linie în tabela rezultat. În cele mai multe cazuri însă se doreşte regăsirea de informaŃii într-un mod selectiv, prin specificarea unei condiŃii de selecŃie care să identifice doar o parte a liniilor tabelei. Doar aceste linii vor fi prelucrate în continuare pentru obŃinerea rezultatului. Specificarea condiŃiei de selecŃie se face prin intermediul unei noi clauze, WHERE, care are următoarea sintaxă:
WHERE expresie_logica
Investeşte în oameni!
Pagina 46
Unde expresia logică este o condiŃie care se evaluează la adevărat sau fals pentru fiecare linie a tabelei. De exemplu, dacă se doreşte o listă cu numele, clasa şi codul profilului conŃinând doar elevii de anul 4, cererea este:
SELECT NUME, CLASA, CODP FROM ELEV WHERE AN = 4;
Rezultatul va fi:
NUME CLASA CODP
GEORGE 12A 11
ALEX 12B 21
FLOREA 12C 24
Evaluarea unei cereri conŃinând WHERE se face astfel: � Se parcurg rând pe rând liniile tabelei de pe clauza FROM (ex: ELEV) � Pentru fiecare linie, se testează valoarea condiŃiei din WHERE (ex: AN = 4) � Dacă aceasta nu este îndeplinită, se trece la linia următoare � Dacă este îndeplinită, din linia respectivă se calculează o linie a rezultatului conform listei de expresii din clauza SELECT (pentru exemplul de mai sus ea va conŃine numele elevului, clasa şi codul profilului) Expresia logică poate conŃine următorii operatori de comparaŃie: a. Operatori de comparaŃie uzuali Aceşti operatori nu sunt specifici SQL, ei putând fi întâlniŃi şi în alte limbaje. Cei mai folosiŃi sunt următorii:
Operator SemnificaŃie = Egal > Mai mare >= Mai mare sau egal < Mai mic <= Mai mic sau egal <> Diferit != Diferit
Operatorii de comparaŃie se pot folosi atât pentru valori numerice cât şi pentru şiruri de caractere (în care caz se aplică ordinea lexicografică, de dicŃionar) şi date calendaristice. În cazul constantelor de tip dată calendaristică scrierea se face în formatul standard. Pentru date şi şiruri constante se folosesc apostrofi.
Investeşte în oameni!
Pagina 47
Operatorul BINARY forŃează potrivirea exactă. Cererile: SELECT * FROM ELEV WHERE LOC=BINARY 'BUCURESTI'; SELECT * FROM ELEV WHERE LOC=BINARY 'Bucuresti';
nu returnează acelaşi rezultat. Deoarece în baza de date locul naşterii a fost introdus cu litere mari iar şirurile de caractere 'BUCURESTI' şi 'Bucuresti' sunt diferite, doar prima cerere va prezenta datele elevilor născuŃi în Bucureşti. În afară de operatorii uzuali, SQL mai pune la dispoziŃie şi patru operatori de comparaŃie specifici: BETWEEN, IN, LIKE şi IS NULL. b. CondiŃii compuse Pentru formarea condiŃiilor complexe se pot folosi paranteze rotunde şi AND (şi logic), OR (sau logic), NOT (negare, operator unar) sau XOR (sau exclusiv). Versinea C-like a operatorilor poate fi de asemenea folosită :
Operator SemnificaŃie AND, && ŞI logic NOT, ! NegaŃie (operator unar) OR, || SAU logic XOR SAU exclusiv
NOT, AND, OR şi XOR sunt evaluaŃi după efectuarea comparaŃiilor, în această ordine. De exemplu, următoarele trei expresii logice sunt echivalente:
AN=2 AND MEDIA>500 OR CODP=11 (AN=2 AND MEDIA>500) OR CODP=11 ((AN=2) AND (MEDIA>500)) OR (CODP=11)
În schimb, expresiile: AN=2 AND MEDIA>500 OR CODP=11
şi AN=2 AND (MEDIA>500 OR CODP=11)
nu vor selecta aceleaşi linii deoarece în primul caz se execută întâi AND şi apoi OR iar în al doilea ordinea lor este inversată. Tabelele de adevăr pentru AND, OR şi NOT sunt cele cunoscute:
Investeşte în oameni!
Pagina 48
AND TRUE FALSE OR TRUE FALSE NOT TRUE True False TRUE True True TRUE False FALSE False False FALSE True False FALSE True ObservaŃie: Operanzii şi rezultatul unei expresii compuse pot avea valorile TRUE, FALSE sau NULL. O expresie care conŃine un operand NULL se va evalua la NULL. De asemenea, valorile TRUE şi FALSE sunt implementate ca 1 si respectiv 0. De exemplu cererea:
SELECT 1 = NULL, NULL < NULL, 1 = 1, 1 = 10 va returna doua valori nule, o valoare 1 şi o valoare 0:
1 = NULL NULL < NULL 1 = 1 1 = 10
(NULL) (NULL) 1 0 c. Operatorul BETWEEN Operatorul BETWEEN este folosit pentru a testa apartenenŃa unei valori la un interval închis. Sintaxa sa este:
expresie BETWEEN valoare_minima AND valoare_maxima Valoarea unei astfel de expresii logice este: � TRUE dacă expresia are o valoare cuprinsă între valoare_minima şi valoare_maxima (inclusiv acestea) şi FALSE altfel. � În cazul în care valoare_minima este mai mare decat valoare_maxima expresia întoarce FALSE. � Când cele două valori sunt egale expresia este echivalentă cu expresie=valoare Exemplu: dacă se doreşte regăsirea numelui, anului de studiu şi a mediei pentru elevii având o medie între 9 şi 10 cererea este:
SELECT NUME, AN, MEDIA FROM ELEV WHERE MEDIA BETWEEN 9 AND 10;
Rezultat: NUME AN MEDIA
GEORGE 4 9.95
FLOREA 4 10.00
Operatorul BETWEEN este un operator derivat, introducerea lui în limbaj datorându-se frecvenŃei ridicate în aplicaŃii a condiŃiilor de acest tip. Acelaşi rezultat se putea obŃine însă şi cu cererea următoare.
SELECT NUME, AN, MEDIA FROM ELEV WHERE MEDIA >= 9 AND MEDIA <=10;
ObservaŃii:
Investeşte în oameni!
Pagina 49
1. Plaja de valori poate fi definită prin expresii. Următoarea cerere este validă: SELECT NUME, AN, MEDIA FROM ELEV WHERE MEDIA + 1000 BETWEEN TUTOR - 2000 AND TUTOR + 1000;
2. Expresiile care definesc plaja pot fi nu doar numerice ci şi de tip şir de caractere sau dată calendaristică, ca în exemplul următor:
SELECT NUME, LOC, DATAN FROM ELEV WHERE LOC BETWEEN 'A' AND 'L' AND DATAN BETWEEN '1995-01-01' AND '1995-12-31';
d. Operatorul IN Operatorul IN este folosit pentru a testa apartenenŃa unei valori la o mulŃime. Sintaxa sa este:
expresie IN (val_1, val_2, ..., val_n) Valorile nule din listă sunt ignorate. Valoarea unei astfel de expresii logice este: � TRUE dacă expresie se evaluează la una dintre valorile nenule din listă şi FALSE altfel. � În cazul în care lista conŃine valori nule, o condiŃie IN negată întoarce întotdeauna FALSE. Exemplul 1: Se cere o listă cu numele, anul de studii şi data naşterii pentru elevii având matricola tutorului în mulŃimea {1456, 2146}:
SELECT NUME, AN, DATAN FROM ELEV WHERE TUTOR IN (1456, 2146);
Exemplul 2: Ignorarea valorilor nule din listă: deşi există mai mulŃi elevi având o valoare nulă pe coloana TUTOR, ei nu apar în rezultatul cererii:
SELECT NUME, AN, DATAN, TUTOR FROM ELEV WHERE TUTOR IN (NULL, 1456, 2146);
Rezultat: NUME AN DATAN TUTOR
VASILE 2 1984-10-05 1456
MIHAI 1 1985-01-01 1456
ELENA 2 1984-08-29 2146
Exemplul 3: Dacă lista conŃine valori nule, NOT IN întoarce întotdeauna FALSE: următoarea cerere nu va returna nici o linie:
SELECT NUME, AN, DATAN, TUTOR FROM ELEV WHERE TUTOR NOT IN (NULL, 1456, 2146);
Investeşte în oameni!
Pagina 50
Operatorul IN este de asemenea un operator derivat. Cererea din primul exemplu se putea scrie şi astfel:
SELECT NUME, AN, DATAN FROM ELEV WHERE TUTOR=1456 OR TUTOR=2146;
ObservaŃii: 1. Ca şi în cazul operatorului BETWEEN, putem folosi expresii în lista de valori. Următoarea cerere este validă:
SELECT NUME, MEDIA, CODP FROM ELEV WHERE MEDIA * 79 IN (CODP*30+70, CODP*200+700);
Rezultatul său este:
NUME MEDIA CODP
FLOREA 10.00 24
2. Operatorul IN se poate folosi şi pentru şiruri de caractere sau date calendaristice: SELECT NUME, LOC, DATAN FROM ELEV WHERE LOC IN ('BUCURESTI', 'PLOIESTI') OR DATAN IN ('1996-09-02', '1993-06-15'); e. Operatorul LIKE Operatorul LIKE este folosit pentru a testa dacă valoarea unei expresii respectă un şablon. Sintaxa sa este:
expresie LIKE 'SABLON' [ESCAPE 'caracter'] Evaluarea unei astfel de condiŃii se face în felul următor: � Se calculează valoarea expresiei şi se transformă în şir de caractere � Se verifică dacă şirul astfel obŃinut respectă şablonul. Dacă da, rezultatul este TRUE, altfel este FALSE. Şablonul se pune între apostrofi şi poate conŃine caracterele _ şi % având următoarea semnificaŃie:
Caracter SemnificaŃie _ Orice caracter % Orice şir de caractere, inclusiv şirul
vid
Investeşte în oameni!
Pagina 51
Exemplul 1. Se cere afişarea unei liste conŃinând numele, anul de studiu şi clasa elevilor al căror nume începe cu litera A. Cererea este:
SELECT NUME, AN, CLASA FROM ELEV WHERE NUME LIKE 'A%';
Rezultat:
NUME AN CLASA
ALEX 4 12B
ADRIAN 3 11C
Exemplul 2. Se cere afişarea unei liste cu numele şi clasa elevilor al căror nume are patru litere: Cerere:
SELECT NUME, CLASA FROM ELEV WHERE NUME LIKE '____';
Rezultat:
NUME CLASA
ALEX 12B
OANA 10C
Exemplul 3. Numele profilurilor şi filierele pentru acestea pentru profilurile cu o denumire care include cel puŃin un spaŃiu: Cerere:
SELECT NUME, FILIERA FROM PROFIL WHERE NUME LIKE '% %';
Rezultat: NUME FILIERA
RESURSE NATURALE THNOLOGICĂ
Exemplul 4. Lista profilurilor al căror nume conŃine litera S şi apoi litera L iar aceasta din urmă este penultimul caracter: Cerere:
SELECT NUME, FILIERA FROM PROFIL WHERE NUME LIKE '%S%L_';
Rezultat:
Investeşte în oameni!
Pagina 52
NUME FILIERA
RESURSE NATURALE THNOLOGICĂ
În cazul în care şirul căutat conŃine caracterele _ sau % se foloseşte opŃiunea ESCAPE pentru a defini un aşa numit caracter de întârziere. Exemplu: Se caută un şir care conŃine _U şi pentru asta se defineşte ca şi caracter de întârziere | (bara verticală): SELECT CONCAT(NUME,'_',FILIERA) AS NUMESIFILIERA FROM PROFIL WHERE CONCAT(NUME,'_',FILIERA) LIKE '%|_TEO%' ESCAPE '|' În acest caz linia de subliniere este considerată un caracter ca oricare altul şi nu un marcaj de înlocuire. Rezultatul cererii este:
NUMESIFILIERA
REAL_TEORETICĂ
UMANIST_TEORETICĂ
ObservaŃii: 1. Deoarece valoarea expresiei care se compară cu şablonul este transformată în şir de caractere, LIKE se poate folosi şi pentru expresii numerice sau dată calendaristică. Următoarea cerere va returna date despre elevii născuŃi în anul 1995 şi au o medie care contine cifra 5 cu penultima cifra 9:
SELECT NUME, DATAN, MEDIA FROM ELEV WHERE DATAN LIKE '1995%' AND MEDIA LIKE '%5%'
Rezultat: NUME DATAN MEDIA
VASILE 1995-10-05 4.50
OANA 1995-12-31 6.45
2. O valoare nulă a expresiei care se compară cu şablonul nu este asimilată cu şirul vid. Cererea următoare conŃine o condiŃie de tip C OR NOT C (în mod normal întotdeauna adevărată) dar nu va returna linii pentru elevii care au o valoare nulă pe coloana TUTOR:
SELECT NUME, TUTOR FROM ELEV WHERE TUTOR LIKE '%' OR TUTOR NOT LIKE '%';
Rezultat: NUME TUTOR
VASILE 1456
MIHAI 1456
ION 3251
ELENA 2146
Investeşte în oameni!
Pagina 53
OANA 4311
MARIUS 3514
3. Şablonul poate fi rezultatul unei expresii. În cazul cererii următoare valoarile nule de pe coloana TUTOR sunt transformate în şiruri vide anterior efectuării comparaŃiei cu şablonul:
SELECT NUME, CONCAT('A', '%', IFNULL(TUTOR, '')) AS SABLON FROM ELEV WHERE NUME LIKE CONCAT('A', '%', IFNULL(TUTOR, ''));
Rezultatul va fi asemănător cu al cererii din exemplul 1 deoarece ambii elevi al căror nume începe cu litera A au o valoare nulă pe coloana TUTOR şi din această cauză numele lor va verifica sablonul 'A%' rezultat din concatenare:
NUME SABLON
ALEX A%
ADRIAN A%
4. Literele mari nu sunt considerate diferite de literele mici. În cazul cererilor următoare (elevi al căror nume începe cu A) ambele returnează acelaşi rezultat:
SELECT NUME, DATAN FROM ELEV WHERE NUME LIKE 'A%'; SELECT NUME, DATAN FROM ELEV WHERE NUME LIKE 'a%';
În schimb, o cerere care foloseşte BINARY şablon va face o potrivire exacta a caracterelor. Cererea următoare are rezultat vid:
SELECT NUME, DATAN FROM ELEV WHERE NUME LIKE BINARY 'a%';
5. În cazul în care caracterul de întârziere este backslash nu mai este necesară folosirea clauzei ESCAPE. Exemplul anterior se poate rescrie astfel:
SELECT CONCAT(NUME,'_',FILIERA) AS NUMESIFILIERA FROM PROFIL WHERE CONCAT(NUME,'_',FILIERA) LIKE '%\_TEO%';
f. Operatorul IS NULL Aşa cum s-a menŃionat anterior valorile nule au proprietaŃi diferite de ale celor nenule. Ele nu se pot compara cu alte valori, inclusiv cu alte valori nule, prin operatori de tip egal sau diferit şi sunt ignorate de operatorul IN.
Investeşte în oameni!
Pagina 54
Cererile următoare nu vor semnala eroare de sintaxă dar în acelaşi timp nu vor returna nici o linie de rezultat:
SELECT NUME, TUTOR FROM ELEV WHERE TUTOR = NULL; SELECT NUME, TUTOR FROM ELEV WHERE TUTOR <> NULL;
Din această cauză a fost necesar să fie introdus în SQL un operator care testează dacă valoarea unei expresii este nulă sau nu. Sintaxa sa este:
expresie IS NULL Rezultatul este TRUE dacă expresia se evaluează la o valoare nulă şi FALSE altfel. În cazul acestui operator există şi o iregularitate în limbaj pentru a-l face cât mai apropiat de frazarea în limba engleză: negarea unei condiŃii de acest tip se face prin forma:
expresie IS NOT NULL şi nu prin
expresie NOT IS NULL Exemplu: Listele cu elevii care nu au/au asignat un tutor vor fi returnate de cererile:
SELECT NUME, TUTOR FROM ELEV WHERE TUTOR IS NULL; SELECT NUME, TUTOR FROM ELEV WHERE TUTOR IS NOT NULL;
2.3. Clauza ORDER BY Clauza ORDER BY permite sortarea rezultatului acesteia după unul sau mai multe criterii, ascendent sau descendent. Sortarea se poate efectua atât pentru valori numerice cât şi pentru valori de tip şir de caractere sau dată calendaristică, în care caz se aplică ordinea lexicografică şi respectiv ordinea calendaristică. Sintaxa acestei clauze este următoarea:
ORDER BY criteriu1 [DESC] [,criteriu2 [DESC]...] Cuvântul cheie opŃional DESC (de la englezescul descending) specifică inversarea ordinii de sortare implicite pentru criteriul respectiv (ordinea ascendentă, crescătoare) astfel încât sortarea se face descendent (descrescător).
Investeşte în oameni!
Pagina 55
În cazul în care ORDER BY conŃine mai multe criterii de sortare, ele nu sunt echivalente ci se iau în considerare în ordinea specificată: � Se sortează rezultatul după primul criteriu � Pentru valori egale pentru primul criteriu se ia în considerare al doilea criteriu � Pentru valori egale pentru primele două criterii se ia în considerare al treilea criteriu, s.a.m.d. În cazul criteriilor de sortare putem folosi: a. Nume de coloane care apar în rezultat Cel mai simplu criteriu de sortare care se poate folosi în clauza ORDER BY este numele unei coloane din tabela FROM care apare în lista SELECT. De exemplu dacă se doreşte lista profilurilor din tabela PROFIL prezentate în ordine alfabetică a numelui acestora cererea este:
SELECT NUME, FILIERA, CODP FROM PROFIL ORDER BY NUME;
Rezultatul va fi:
NUME FILIERA CODP
UMANIST TEORETICĂ 21
RESURSE NATURALE TEHNOLOGICĂ 24
REAL TEORETICĂ 11
Pentru lista cu numele elevilor, anul, clasa, data naşterii şi codul profilului acestora avem cererea:
SELECT NUME, AN, CLASA, DATAN, CODP FROM ELEV ORDER BY AN DESC, NUME
Rezultatul va fi ordonat în acest caz astfel: � Liniile rezultatului sunt sortate în ordinea descrescătoare a anului de studiu: 4, 3, 2, 1 (primul criteriu este AN DESC). � Pentru liniile care au acelaşi an de studiu, se aplică al doilea criteriu de sortare (NUME) astfel încât elevii sunt afişaŃi în ordine alfabetică (deoarece lipseşte DESC ordinea va fi crescătoare). Primele linii din rezultatul cererii de mai sus sunt următoarele: NUME AN CLASA DATAN CODP
ALEX 4 12B 1996-11-07 21
FLOREA 4 12C 1993-02-03 24
GEORGE 4 12A 1993-03-12 11
Investeşte în oameni!
Pagina 56
ADRIAN 3 11C 1994-07-31 24
MARIA 3 11A 1994-06-17 11
STANCA 3 11B 1993-06-15 21
b. Aliasuri de coloane specificate în SELECT Un alias specificat în lista SELECT poate fi folosit pentru sortarea rezultatului. În exemplul următor ordonarea se face în funcŃie de valoarea expresiei având asociat aliasul PMARIT:
SELECT NUME, MEDIA, MEDIA*1.1 MMARITA FROM ELEV WHERE CODP=11 ORDER BY MMARITA;
Rezultat:
NUME MEDIA MMARITA
VASILE 4.50 4.950
MIHAI 6.80 7.480
MARIA 7.58 8.338
GEORGE 9.95 10.945
c. Expresii incluzând nume de coloane şi aliasuri de coloane Un criteriu poate fi specificat şi printr-o expresie. Cererea anterioară se putea scrie şi astfel:
SELECT NUME, MEDIA, MEDIA*1.1 MMARITA FROM ELEV WHERE CODP=11 ORDER BY MEDIA*1.1;
Şi aliasurile pot participa la expresii. Următoarea cerere este validă şi întoarce acelaşi rezultat ca mai sus, sortat însă în ordine inversă, deoarece ordinea valorilor expresiei MEDIA - PMARIT este inversă ordinii valorilor lui PMARIT
SELECT NUME, MEDIA, MEDIA*1.1 MMARITA FROM ELEV WHERE CODP=11 ORDER BY MEDIA-MMARITA;
d. Coloane care nu apar în rezultat În clauza ORDER BY pot apare coloane sau expresii conŃinând coloane care nu apar în lista SELECT. În exemplul următor sortarea se face după valori rezultate din coloanele LOC şi MEDIA:
SELECT NUME, AN, CLASA FROM ELEV WHERE AN=2 ORDER BY LOC DESC, (MEDIA/10);
Investeşte în oameni!
Pagina 57
Rezultat: NUME AN CLASA
VASILE 2 10A
OANA 2 10C
ELENA 2 10B
e. Numărul unei coloane a rezultatului Numărul coloanelor din rezultat se poate folosi în ORDER BY pentru a specifica unul sau mai multe criterii de sortare. În cazul cererilor următoare rezultatul este sortat descrescător după anul de studiu (coloana 3 din rezultat) şi la valori egale pentru acesta după numele elevului:
SELECT MATR, NUME, AN FROM ELEV ORDER BY 3 DESC, 2;
SELECT MATR, NUME, AN FROM ELEV ORDER BY 3 DESC, NUME;
ObservaŃie: Numărul coloanei nu se poate specifica printr-o expresie. Cererea următoare face doar ordonarea după nume deoarece criteriul 2+1 este considerat ca fiind o expresie constantă care are aceeaşi valoare pentru fiecare linie din rezultat:
SELECT MATR, NUME, AN FROM ELEV ORDER BY 2+1 DESC, NUME;
f. Tratarea valorilor nule Valorile nule nu se pot compara prin operatorii =, <, <=, >, >=, <> cu alte valori, nule sau nenule. Ce se întămplă însă în cazul în care pentru unul sau mai multe criterii de sortare specificate în ORDER BY avem valori nule? Fiecare companie care realizează sisteme de gestiune a bazelor de date a trebuit să ia o decizie privind locul în care acestea sunt prezentate după sortare: înaintea valorilor nenule sau după acestea. În cazul MySQL s-a ales prima variantă: ORDER BY consideră o valoare nulă mai mică decât orice valoare nenulă. De exemplu, cererea care afişează tipul şi abrevierea calificativelor ordonat după abreviere va afişa linia conŃinând valoarea nulă prima:
SELECT TIP, REZ FROM REZULTAT ORDER BY REZ
Rezultat: TIP REZ
INSUFICIENT (NULL)
Investeşte în oameni!
Pagina 58
BINE BI
FOARTE BINE FB
SATISFĂCĂTOR SA
SUFICIENT SU
2.3. Clauza LIMIT Clauza LIMIT se aplică ultima într-o cerere SELECT şi lasă sa treacă mai departe doar un anumit număr de linii. Sintaxa acestei clauze este următoarea: LIMIT [prima_linie,] nr_max_linii Primul argument este numărul de ordine al primei linii returnate (implicit este prima linie, care are însă numarul 0 şi nu 1) iar al doilea argument numărul maxim de linii din rezultat. Exemplu:
SELECT MATR, NUME, AN, CLASA FROM ELEV LIMIT 3, 2;
va returna 2 linii, începând cu linia a 4-a din rezultatul aceleiaşi cereri fără LIMIT: MATR NUME AN CLASA
3145 MIHAI 1 9A
3145 ION 1 9B
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 2 Obiectivele activităŃilor practic-aplicative:
• Familiarizarea cu sistemul de gestiune MySQL şi cu interfeŃele care pot fi folosite • Realizarea de exercitii practice cu cereri SELECT simple (SELECT FROM); • Realizarea de exercitii practice cu cereri folosind WHERE • Realizarea de exercitii practice cu cereri folosind ORDER BY • Realizarea de exercitii practice cu cereri folosind LIMIT
A. 1 – Se va instala un pachet care să conŃină MySQL şi interfeŃe de operare (xampp sau EasyPHP). Vor fi folosite interfeŃele disponibile pentru crearea bazei de date şi a tabelelor din manual. A. 2 – Se vor scrie, executa şi eventual depana cererile SELECT simple care afişează:
a. ConŃinutul integral al tabelelor ELEV, PROFIL şi REZULTAT b. Numele şi data naşterii pentru fiecare elev c. Numele şi filierele profilurilor existente d. Tipul şi abrevierea fiecărui calificativ
Investeşte în oameni!
Pagina 59
e. În plus, se vor executa toate cererile prezente în manual la capitolul 2.1 A. 3 – Se vor scrie, executa şi eventual corecta erorile aparute pentru cererile de tip SELECT FROM WHERE care afişează:
a. Numele şi data naşterii pentru elevii de anul 1 b. Toate datele despre elevii fară tutor c. Toate datele pentru elevii având o medie între 9 si 10 d. Numele profilurilor care contin un A si un E, în orice ordine ar fi aceste litere e. În plus, se vor executa toate cererile prezente în manual la capitolul 2.2
A. 4 – Se vor scrie, executa şi eventual eventual corecta erorile aparute pentru cererile de tip SELECT FROM ORDER BY LIMIT care afişează:
a. Toate datele pentru elevii având localitatea BUCURESTI, ordonaŃi alfabetic b. Toate datele despre elevi, ordonaŃi după anul de studii (crescător) şi alfabetic în cadrul
fiecărui an de studii c. Toate datele pentru elevii având o medie între 6 si 9 ordonaŃi descrescător după medie d. Toate datele despre elevi ordonaŃi dupa coloana a doua din rezultat. e. Top 3 elevi în ceea ce priveşte media. f. În plus, se vor executa toate cererile prezente în manual la capitolele 2.3 şi 2.4
TEMA 3 Regasirea datelor in baze de date relationale: cereri SELECT pe o tabelă
Obiectivele temei urmăresc: • Prezentarea elementelor generale privind regăsirea datelor pornind de la mai multe tabele ale
bazei de date; • OperaŃia de join. Echijoin şi non-echijoin • Joinul unei tabele cu ea însăşi • Join extern. Variante de join din standardul SQL-3
3. CERERI SELECT PE MAI MULTE TABELE În foarte multe cazuri se doreşte ca un acelaşi rezultat să conŃină date care sunt stocate în două sau mai multe tabele din baza de date, ca în exemplele următoare:
� Lista conŃinând numele elevilor şi denumirile profilurilor la care aceştia sunt înmatriculaŃi. Tabelele care conŃin aceste date sunt ELEV (numele elevului) şi PROFIL (denumirea profilului).
� Numele elevilor (din tabela ELEV) şi calificativele acestora acestora (din tabela REZULTAT). � Numele elevului, denumirea profilului şi abrevierea calificativului. În acest caz sunt implicate toate cele
trei tabele ale bazei de date de test. OperaŃia care permite astfel de regăsiri se numeşte join (termen preluat din limba engleză) şi este realizată prin intermediul unei cereri SELECT având următoarele caracteristici:
� În clauza FROM este specificată nu doar o singură tabelă ci o listă de tabele. � În clauza WHERE există o condiŃie care să coreleze liniile tabelelor din lista FROM (condiŃie numită şi
condiŃie de join). Sintaxa generală a unei astfel de cereri este:
SELECT [DISTINCT] lista_de_expresii FROM lista_de_tabele WHERE conditie_de_join AND conditii_suplimentare -- optional -- alte clauze: GROUP BY, HAVING, ORDER BY
În cazul limbajului SQL există mai multe variante ale acestei operaŃii:
� Atunci când condiŃia de join lipseşte, fiecare linie a unei tabele din lista FROM este concatenată cu fiecare linie a celorlalte tabele, obŃinându-se de fapt produsul cartezian al acestora.
Investeşte în oameni!
Pagina 61
� Dacă în condiŃia de join apar numai egalităŃi operaŃia este numită şi echijoin. În celelalte cazuri avem un non-echijoin.
� În lista de tabele care participă la join o tabelă poate să apară repetat. O astfel de operaŃie este numită şi joinul unei tabele cu ea însăşi sau self-join.
� În cazul în care o linie a unei tabele nu se corelează prin condiŃia de join cu nici o linie din celelalte tabele ea nu va participa la formarea rezultatului. Se poate însă cere ca aceasta să fie luată în considerare pentru rezultat, rezultând aşa numitul join extern (în engleză outer join).
3.1. Produs cartezian Produsul cartezian a două tabele se obŃine prin concatenarea (lipirea) fiecărei linii dintr-o tabelă cu fiecare linie din cealaltă. În cazul general un produs cartezian are următoarele caracteristici:
� Numărul de coloane este egal cu suma numerelor de coloane ale tabelelor participante. � Numărul de linii este egal cu produsul numerelor de linii ale tabelelor participante.
Exemplu:
Tabelă sau produs cartezian
Număr de linii Număr de coloane
ELEV 12 9 PROFIL 3 3 REZULTAT 5 4 ELEV x PROFIL 12 * 3 = 36 9 + 3 = 12 ELEV x PROFIL x REZULTAT
12 * 3 * 5 = 180 9 + 3 + 4 = 16
În cazul în care pe clauza FROM a unei cereri SELECT sunt mai multe tabele, rezultatul cererii se calculează pornind de la produsul cartezian al acestora. De exemplu, cererea:
SELECT * FROM ELEV, PROFIL;
va returna un rezultat având 12 coloane şi 36 de linii formate din concatenarea fiecărei linii din ELEV cu fiecare linie din PROFIL. De asemenea, cererea:
SELECT DATAN, FILIERA FROM ELEV, PROFIL WHERE LOC='BUCURESTI';
are un rezultat conŃinând 15 linii: Ea nu returnează deci data naşterii şi filiera profilului pentru elevii născuŃi în Bucureşti ci toate perechile posibile (DATAN, FILIERA) formate din valorile DATAN ale elevilor născuŃi în Bucureşti (în număr de 5) şi valorile coloanei FILIERA din PROFIL (3 valori).
DATAN FILIERA
1993-03-12 TEORETICĂ
1993-03-12 TEORETICĂ
Investeşte în oameni!
Pagina 62
1993-03-12 TEHNOLOGICĂ
1993-06-15 TEORETICĂ
1993-06-15 TEORETICĂ
1993-06-15 TEHNOLOGICĂ
1995-08-29 TEORETICĂ
1995-08-29 TEORETICĂ
1995-08-29 TEHNOLOGICĂ
1994-07-31 TEORETICĂ
1994-07-31 TEORETICĂ
1994-07-31 TEHNOLOGICĂ
1995-12-31 TEORETICĂ
1995-12-31 TEORETICĂ
1995-12-31 TEHNOLOGICĂ
Pentru a obŃine un rezultat conŃinând linii cu valori corelate trebuie ca în clauza WHERE să adăugăm condiŃia de join care, în cazul exemplelor anterioare, va filtra produsul cartezian eliminând liniile rezultate din concatenarea datelor unui elev cu datele unei profiluri diferită de a sa.
3.2. Echijoin şi non-echijoin Pentru a putea efectua joinul a două sau mai multe tabele este necesar ca ele să conŃină coloane cu date comune sau corelate. Aşa cum s-a menŃionat în primul capitol, în cazul bazei de date pentru exemple, există următoarele legături:
� Coloana CODP este comună tabelelor PROFIL şi ELEV. În mod normal un elev nu poate avea pe această coloană decât una dintre valorile existente deja pe coloana CODP din PROFIL. În acest caz condiŃia de join este de egalitate şi vom avea un echijoin.
� Tabelele ELEV şi REZULTAT sunt corelate prin coloanele MEDIA respectiv MMIN şi MMAX. Asocierea dintre un elev şi calificativul său se face prin valoarea de pe coloana MEDIA care trebuie să fie între MMIN şi MMAX pentru linia corespunzătoare din tabela REZULTAT. CondiŃia de legătură între tabele nu este una de egalitate ci de tip BETWEEN; joinul celor două tabele va fi un non-echijoin.
Tabelele PROFIL şi REZULTAT nu au coloane comune sau corelate. Se pot totuşi obŃine rezultate de tipul `lista perechilor (profil, calificativ existent în cadrul profilului)` din joinul pe trei tabele PROFIL-ELEV-REZULTAT. a. Echijoin Când condiŃia de join este una de egalitate, joinul se mai numeşte şi echijoin. Cererea următoare returnează o listă conŃinând numărul matricol, numele elevului, codul şi numele profilului sale pentru elevii care au ca filiera 'STIINTE EXACTE'. CondiŃia de join este în acest caz: valoarea CODP
Investeşte în oameni!
Pagina 63
provenită din tabela ELEV trebuie să fie egală cu valoarea CODP provenită din PROFIL. În felul acesta un elev este concatenat doar cu profilul său şi nu cu alte profiluri. La aceasta se adaugă o condiŃie suplimentară şi anume: valoarea pentru FILIERA să fie cea specificată. Cuplarea condiŃiei de join cu condiŃia sau condiŃiile suplimentare se face întotdeauna prin AND (şi logic). Cererea este:
SELECT MATR, ELEV.NUME, ELEV.CODP, PROFIL.NUME FROM ELEV, PROFIL WHERE ELEV.CODP = PROFIL.CODP AND -- CONDITIE JOIN FILIERA= 'TEORETICĂ' -- ALTE CONDITII
În cazul în care în tabelele aflate pe clauza FROM avem coloane cu acelaşi nume dezambiguarea se poate face prin prefixarea numelui coloanei cu numele tabelei din care provine. În exemplul de mai sus s-a folosit această facilitate pentru coloanele CODP şi NUME existente în ambele tabele. Prefixarea nu este necesară pentru coloanele MATR şi FILIERA care există doar într-una din tabelele implicate în join. Rezultatul cererii este următorul:
MATR NUME CODP NUME
1456 GEORGE 11 REAL
1325 VASILE 11 REAL
1645 MARIA 11 REAL
3145 MIHAI 11 REAL
b. Non-echijoin În cazul în care se doreşte obŃinerea unei liste cu elevi la profilul cu codul 11 conŃinând numele elevului, anul de studiu, calificativul şi abrevierea acestuia, joinul dintre ELEV şi REZULTAT nu se mai face după o condiŃie de egalitate ci după una de tip BETWEEN. În acest caz este vorba de un non-echijoin şi condiŃia de join este de asemenea cuplată prin AND de condiŃia suplimentară:
SELECT NUME, AN, TIP, REZ FROM ELEV, REZULTAT WHERE MEDIA BETWEEN MMIN AND MMAX – COND. JOIN AND CODP=11 -- CONDITIE SUPLIMENTARA;
Rezultatul este: NUME AN TIP REZ
GEORGE 4 FOARTE BINE FB
VASILE 2 INSUFICIENT (NULL)
MARIA 3 SATISFĂCĂTOR SA
MIHAI 1 SATISFĂCĂTOR SA
În acest caz nu a mai fost necesară prefixarea vreunui nume de coloană cu numele tabelei din care provine deoarece în ELEV şi REZULTAT nu există coloane cu acelaşi nume.
Investeşte în oameni!
Pagina 64
Exemple de non-echijoinuri conŃinând şi alŃi operatori specifici SQL sunt prezentate în detaliu în paragraful 3.4. c. Alias de tabelă În multe aplicaŃii reale tabelele au nume foarte lungi ceea ce poate complica scrierea cererilor de join. În astfel de cazuri se poate folosi o a doua metodă de dezambiguare pusă la dispoziŃie de limbajul SQL şi anume aliasul de tabelă. Acesta se defineşte pe clauza FROM şi are caracteristici asemănătoare cu ale aliasului de coloană.
� Nu poate fi mai lung de 64 de caractere. � În cazul în care conŃine doar cifre sau conŃine alte caractere decât litere, cifre, _ şi $ atunci
trebuie pus între apostrofi inverşi ` (sau ghilimele când modul ANSI_QUOTES este activ). În acest caz el va fi folosit în alte clauze în acelasi mod.
� Nu poate fi folosit decât în cererea curentă. Sistemul nu stochează în baza de date sau altundeva aceste nume alternative.
Aliasul de tabelă se adaugă după numele acesteia din clauza FROM, separat prin caractere albe (spaŃiu, tab, linie nouă). Următoarea cerere returnează o listă cu numele elevului, codul profilului, numele profilului şi calificativul pentru toŃi elevii din baza de date. Fiind un join pe trei tabele condiŃia de join este una compusă - prin AND - din condiŃia de join între ELEV şi PROFIL şi condiŃia de join între ELEV şi REZULTAT:
SELECT S.NUME, S.CODP, `SP ELEV`.NUME, TIP FROM ELEV S, PROFIL `SP ELEV`, REZULTAT WHERE S.CODP = `SP ELEV`.CODP AND -- CONDITIE DE JOIN S.MEDIA BETWEEN MMIN AND MMAX -- COMPUSA;
ObservaŃii: 1. Dacă pentru o tabelă a fost definit un alias numele tabelei nu mai poate fi folosit pentru
prefixare. În cazul cererii anterioare, prima linie nu mai poate fi rescrisă astfel: SELECT S.NUME, ELEV.CODP, PROFIL.NUME, TIP
2. În cazul în care condiŃia de join nu este completă rezultatul va conŃine un produs cartezian între joinurile existente şi restul tabelelor. Exemplu: în cererea următoare lipseşte condiŃia de join care leagă tabela REZULTAT de celelalte tabele. SELECT S.NUME, S.CODP, `SP ELEV`.NUME, TIP FROM ELEV S, PROFIL `SP ELEV`, REZULTAT WHERE S.CODP = `SP ELEV`.CODP;
În acest caz rezultatul obŃinut este produsul cartezian între REZULTAT şi joinul lui ELEV cu PROFIL şi va avea 60 de linii (5 linii din REZULTAT * 12 linii ale joinului ELEV cu PROFIL). 3. În cazul general al unui join pe N tabele, condiŃia de join este compusă din N - 1 subcondiŃii
conectate prin AND care relaŃionează întreg ansamblul de tabele. Altfel spus, dacă se construieşte un graf al condiŃiei în care nodurile sunt tabele şi arcele subcondiŃii de join care leagă două tabele atunci acest graf trebuie să fie conex.
Investeşte în oameni!
Pagina 65
3.3. Joinul unei tabele cu ea însăşi Unul din cazurile în care suntem obligaŃi să folosim aliasul de tabelă este atunci când lista FROM conŃine de mai multe ori o aceeaşi tabelă: aliasurile asociate fiecărei ipostaze ne vor ajuta să dezambiguăm numele coloanelor provenind din fiecare dintre ele. Un exemplu este cererea următoare care afişează numele elevilor care au un tutor asociat, anul lor de studiu, numele tutorilor lor şi anul de studiu al acestora. Datele elevilor se găsesc în tabela ELEV dar tot aici sunt şi cele ale tutorilor, care sunt şi ei elevi. Cererea foloseşte tabela ELEV în cele două ipostaze asociind fiecăreia un alias diferit: aliasul S pentru ipostaza elev şi aliasul T pentru ipostaza tutor. CondiŃia de join este următoarea: codul numeric aflat pe coloana TUTOR a unui elev este egal cu numărul matricol aflat pe coloana MATR a tutorului acestuia (S.TUTOR= T.MATR). S-au folosit de asemenea şi aliasuri de coloane pentru o mai bună lizibilitate a rezultatului obŃinut:
SELECT S.NUME `NUME ELEV`, S.AN `AN ELEV`, T.NUME `NUME TUTOR`, T.AN `AN TUTOR` FROM ELEV S, ELEV T WHERE S.TUTOR=T.MATR -- conditia de join;
Rezultatul este următorul:
NUME ELEV AN ELEV NUME TUTOR AN TUTOR
VASILE 2 GEORGE 4
MIHAI 1 GEORGE 4
ELENA 2 STANCA 3
ION 1 ALEX 4
OANA 2 ADRIAN 3
MARIUS 1 FLOREA 4
Un alt exemplu: se doreşte o listă cu elevi care au acelaşi tutor şi codul acesteia. În acest caz cererea:
SELECT S1.NUME `ELEV 1`, S2.NUME `ELEV 2`, S2.TUTOR `TUTOR` FROM ELEV S1, ELEV S2 WHERE S1.TUTOR=S2.TUTOR;
nu va returna rezultatul dorit deoarece în listă apar şi perechi formate din acelaşi elev: VASILE din S1 are acelaşi tutor cu VASILE din S2 (S1 şi S2 reprezentând aliasuri pentru aceeaşi tabelă).
ELEV 1 ELEV 2 TUTOR
VASILE VASILE 1456
MIHAI VASILE 1456
Investeşte în oameni!
Pagina 66
VASILE MIHAI 1456
MIHAI MIHAI 1456
ION ION 3251
ELENA ELENA 2146
OANA OANA 4311
MARIUS MARIUS 3514
Varianta: SELECT S1.NUME `ELEV 1`, S2.NUME `ELEV 2`, S2.TUTOR `TUTOR` FROM ELEV S1, ELEV S2 WHERE S1.TUTOR=S2.TUTOR AND S1.MATR <> S2.MATR -- se elimina perechile -- cu acelasi elev;
nu este nici ea corectă, fiecare pereche find prezentă de două ori în rezultat: ELEV 1 ELEV 2 TUTOR
MIHAI VASILE 1456
VASILE MIHAI 1456
O variantă corectă este următoarea:
SELECT S1.NUME `ELEV 1`, S2.NUME `ELEV 2`, S2.TUTOR `TUTOR` FROM ELEV S1, ELEV S2 WHERE S1.TUTOR=S2.TUTOR AND S1.MATR > S2.MATR -- se poate folosi şi < ;
Rezultatul obŃinut este:
ELEV 1 ELEV 2 TUTOR
MIHAI VASILE 1456
ObservaŃie: şi în cazul condiŃiilor de join valorile nule nu sunt compatibile cu comparaŃii de tip =, <, >, etc. În cazul cererii de mai sus nu apar în listă elevii care au valori nule pe coloana TUTOR deoarece o condiŃie de tipul (NULL = NULL) are valoarea NULL care este echivalentă cu FALSE.
3.4. Join extern Aşa cum se observă la prima cerere din paragraful 3.3., în cazul unui join, doar liniile care au corespondent prin condiŃia de join în celelalte tabele apar în rezultat: lista cu elevi şi tutorii acestora are doar 6 linii deşi baza de date conŃine 12 elevi. CeilalŃi 6 elevi nu au un tutor asociat şi nu apar în rezultat.
Investeşte în oameni!
Pagina 67
În cazul în care se doreşte însă ca rezultatul să conŃină date provenind şi din aceste linii fără corespondent se poate utiliza joinul extern. În acest caz pe coloanele provenind din celelalte tabele rezultatul va conŃine valori nule. În cazul joinului extern sintaxa este următoarea:
SELECT [DISTINCT] lista_de_expresii FROM tabela1 LEFT RIGHT OUTER JOIN tabela2 { ON (tabela1.nume_coloana1=tabela2.numecoloana2) | USING (lista coloane) }
ON conŃine ca şi anterior condiŃia de join. DiferenŃa între cele trei forme este următoarea: În cazul LEFT OUTER JOIN valorile nule provin din tabela2. De exemplu cererea:
SELECT S.NUME `NUME ELEV`, S.AN `AN ELEV`, T.NUME `NUME TUTOR`, T.AN `AN TUTOR` FROM ELEV S LEFT OUTER JOIN ELEV T ON (S.TUTOR=T.MATR);
returnează 12 linii (numele şi anul elevului împreuna cu numele şi anul turorului - daca există - sau valori nule dacă elevul nu are tutor):
NUME ELEV AN ELEV NUME TUTOR AN TUTOR
GEORGE 4 (NULL) (NULL)
VASILE 2 GEORGE 4
MARIA 3 (NULL) (NULL)
MIHAI 1 GEORGE 4
ION 1 ALEX 4
STANCA 3 (NULL) (NULL)
ALEX 4 (NULL) (NULL)
ELENA 2 STANCA 3
ADRIAN 3 (NULL) (NULL)
FLOREA 4 (NULL) (NULL)
OANA 2 ADRIAN 3
MARIUS 1 FLOREA 4
Investeşte în oameni!
Pagina 68
În cazul RIGHT OUTER JOIN valorile nule provin din tabela1. Cererea de mai sus in care schimbăm LEFT cu RIGHT returnează 13 linii deoarece pe coloana 3 apare de 2 ori GEORGE + el este tutor pentru 2 elevi diferiŃi:
SELECT S.NUME `NUME ELEV`, S.AN `AN ELEV`, T.NUME `NUME TUTOR`, T.AN `AN TUTOR` FROM ELEV S RIGHT OUTER JOIN ELEV T ON (S.TUTOR=T.MATR);
Primele 4 linii ale rezultatului sunt:
NUME ELEV AN ELEV NUME TUTOR AN TUTOR
VASILE 2 GEORGE 4
MIHAI 1 GEORGE 4
(NULL) (NULL) VASILE 2
(NULL) (NULL) MARIA 3
MySQL nu are încă implementat joinul extern complet - FULL OUTER JOIN - care însa se poate obŃine prin reuniunea rezultatelor unui LEFT OUTER JOIN cu un RIGHT OUTER JOIN. Următoarea cerere returnează 19 linii. Ea poate fi rescrisă ca o reuniune a două cereri SQL folosind operatorul UNION descris în amănunt în capitolul 5:
SELECT S.NUME `NUME ELEV`, S.AN `AN ELEV`, T.NUME `NUME TUTOR`, T.AN `AN TUTOR` FROM ELEV S LEFT OUTER JOIN ELEV T ON (S.TUTOR=T.MATR); UNION SELECT S.NUME `NUME ELEV`, S.AN `AN ELEV`, T.NUME `NUME TUTOR`, T.AN `AN TUTOR` FROM ELEV S RIGHT OUTER JOIN ELEV T ON (S.TUTOR=T.MATR);
Observatii: 1. Joinul extern se poate folosi şi în cazul în care condiŃia nu este de egalitate. Se pot folosi
operatorii <, <=, >, >= sau <>. Un exemplu în acest sens este următorul: cererea
returnează 66 linii (perechi de elevi în care primul are o medie mai mare decât al doilea) în timp ce joinul extern (stânga sau dreapta) returnează 67 de linii. Linia suplimentară conŃine datele elevului
Investeşte în oameni!
Pagina 69
care are cea mai mare, respectiv cea mai mica medie din tabelă, pe celelalte două coloane fiind valori nule. Exemplu pentru cazul LEFT:
SELECT S1.NUME `ELEV 1`, S1.MEDIA `MEDIA 1`, S2.NUME `ELEV 2`, S2.MEDIA `MEDIA 2` FROM ELEV S1 LEFT OUTER JOIN ELEV S2 ON S1.MEDIA > S2.MEDIA;
Joinul extern se poate folosi şi în conjuncŃie cu operatorii specifici SQL, după cum urmează: a. Join extern cu BETWEEN Următoarele cereri sunt valide:
SELECT NUME, AN, TIP, REZ FROM ELEV RIGHT OUTER JOIN REZULTAT ON MEDIA-8.3 BETWEEN MMIN AND MMAX
Rezultatul conŃine 3 linii complete pentru elevii cu un (MEDIA-8.3) care se încadrează pentru un calificativ din tabela REZULTAT şi 4 linii pentru cele 4 calificative care nu au nici un elev asociat prin condiŃia de join. Aceste 4 linii conŃin valori nule pe primele două coloane. Dacă schimbam RIGHT cu LEFT:
SELECT NUME, AN, TIP, REZ FROM ELEV LEFT OUTER JOIN REZULTAT ON MEDIA-20 BETWEEN MMIN AND MMAX
Rezultat: 12 linii conŃinând datele pentru 3 elevi şi calificativul corespunzător unei medii egale cu (MEDIA-8.3) şi încă 9 linii cu elevi şi valori nule pe coloanele 3 şi 4 dacă expresia respectivă nu se încadrează la nici un calificativ. b. Join extern cu LIKE Următoarea cerere returnează o listă cu elevi şi profiluri, condiŃia fiind: codul profilului din ELEV să înceapă cu a doua cifră din codul profilului din PROFIL. Joinul extern adaugă o nouă linie cu profilul având codul 24 deoarece nici un elev nu este înmatriculat la o profil având un cod care începe cu 4:
SELECT S.NUME, S.CODP, F.NUME, F.CODP, CONCAT(SUBSTR(F.CODP, 2, 1), '%') SABLON FROM ELEV S
Investeşte în oameni!
Pagina 70
RIGHT OUTER JOIN PROFIL F ON S.CODP LIKE CONCAT(SUBSTR(F.CODP, 2, 1), '%');
FuncŃia SQL SUBSTR întoarce un subşir al primului argument - în cazul nostru subşirul care începe în poziŃia 2 şi are lungime egală cu 1. Rezultatul este:
NUME CODP NUME CODP SABLON
GEORGE 11 REAL 11 1%
VASILE 11 REAL 11 1%
MARIA 11 REAL 11 1%
MIHAI 11 REAL 11 1%
GEORGE 11 UMANIST 21 1%
VASILE 11 UMANIST 21 1%
MARIA 11 UMANIST 21 1%
MIHAI 11 UMANIST 21 1%
(NULL) (NULL) RESURSE NATURALE 24 4%
Schimbând RIGHT cu LEFT obŃinem cererea:
SELECT S.NUME, S.CODP, F.NUME, F.CODP, CONCAT(SUBSTR(F.CODP, 2, 1), '%') SABLON FROM ELEV S LEFT OUTER JOIN PROFIL F ON S.CODP LIKE CONCAT(SUBSTR(F.CODP, 2, 1), '%');
care returnează 16 linii: 8 linii pentru cei 4 elevi pentru care condiŃia de join obişnuit este îndeplinită plus câte o linie pentru fiecare dintre ceilalŃi 8 elevi care nu verifică această condiŃie, având valori nule pe coloanele 3, 4 şi 5.
3.5. Joinuri SQL-3 MySQL recunoaşte şi sintaxa SQL-3 pentru joinuri. Cererile utilizând această sintaxă pot fi transformate în cereri de tipul descris în paragrafele precedente. În continuare sunt prezentate pe scurt elementele referitoare la joinurile compatibile SQL-3. În toate cazurile cererile mai pot conŃine şi celelalte tipuri de clauze: WHERE, ORDER BY, GROUP BY, HAVING. a. Clauza CROSS JOIN Această clauză realizează produsul cartezian al tabelelor. Deosebirea faŃă de sintaxa prezentată anterior pentru produsul cartezian este că numele celei de-a doua tabele nu mai este pe clauza FROM ci pe clauza CROSS JOIN. Forma generală a unei astfel de cereri este:
SELECT [DISTINCT] lista_de_expresii
Investeşte în oameni!
Pagina 71
FROM tabela1 CROSS JOIN tabela2 [{ ON (tabela1.nume_coloana1=tabela2.numecoloana2) | USING (lista coloane) } ];
De exemplu pentru a obŃine lista tuturor perechilor posibile (nume elev, nume profil) cererea este:
SELECT S.NUME, F.NUME FROM ELEV S CROSS JOIN PROFIL F;
Rezultatul va avea 36 de linii. O listă cu numele, data naşterii, numele profilului şi filiera pentru fiecare elev poate fi obŃinută adăugând o condiŃie de join clasică:
SELECT S.NUME, DATAN, F.NUME, FILIERA FROM ELEV S CROSS JOIN PROFIL F ON S.CODP=F.CODP -- se putea si USING (CODP) ;
b. Clauza JOIN . . USING Clauza JOIN USING este utilizată atunci când în cele două tabele coloanele comune (după care se doreşte efectuat joinul) au acelaşi nume. Un echijoin după valorile acestor coloane are următoarea formă generală:
SELECT [DISTINCT] lista_de_expresii FROM tabela1 JOIN tabela2 USING (nume_coloane)
Cererea de la punctul anterior poate fi în acest caz rescrisă utilizând JOIN USING deoarece în ambele tabele coloana conŃinând codul profilului are acelaşi nume (CODP):
SELECT S.NUME, DATAN, F.NUME, FILIERA FROM ELEV S JOIN PROFIL F USING (CODP);
După cum se observă în lista USING numele coloanelor după care se efectuează joinul nu trebuie prefixat cu numele sau aliasul vreuneia dintre tabele. Dacă se doreşte afişarea aceloraşi date dar doar pentru elevii născuŃi în BUCUREŞTI se va adăuga condiŃia suplimentară pe WHERE:
SELECT S.NUME, DATAN, F.NUME, FILIERA FROM ELEV S JOIN PROFIL F USING (CODP) WHERE LOC='BUCURESTI';
Rezultatul este: NUME DATAN NUME FILIERA
GEORGE 1993-03-12 REAL TEORETICĂ
Investeşte în oameni!
Pagina 72
STANCA 1993-06-15 UMANIST TEORETICĂ
ELENA 1995-08-29 UMANIST TEORETICĂ
ADRIAN 1994-07-31 RESURSE NATURALE TEHNOLOGICĂ
OANA 1995-12-31 RESURSE NATURALE TEHNOLOGICĂ
c. Clauza NATURAL JOIN Un caz particular de JOIN USING este aşa numitul join natural. În teoria bazelor de date relaŃionale acesta este definit ca joinul după condiŃia `coloanele cu aceeaşi semnificaŃie au valori egale`. Cum sistemul de gestiune MySQL nu cunoaşte semnificaŃia coloanelor tabelelor joinul natural va fi în acest caz un join după condiŃia `coloanele cu acelaşi nume şi tip de date au valori egale`. Sintaxa generală a unei asemenea comenzi este:
SELECT [DISTINCT] lista_de_expresii FROM tabela1 NATURAL JOIN tabela2
În cazul bazei de date pentru exemple, cererea SQL:
SELECT NUME, DATAN, FILIERA FROM ELEV NATURAL JOIN PROFIL;
va fi echivalentă cu:
SELECT S.NUME, DATAN, FILIERA FROM ELEV S, PROFIL F WHERE S.CODP=F.CODP AND S.NUME=F.NUME;
deoarece ELEV şi PROFIL au două coloane cu acelaşi nume şi tip de date. Cum nici un elev nu are un nume egal cu al profilului sale nu vom obŃine nici o linie de rezultat. ObservaŃie: coloanele se consideră având acelaşi tip de date dacă tipul generic este acelaşi: în cazul nostru pentru NUME avem tipul 'şir de caractere de lungime variabilă' chiar dacă lungimea maximă definită pentru cele două coloane este diferită. De asemenea numele coloanelor comune nu trebuie prefixat cu numele sau aliasul vreunei tabele. d. Clauza JOIN . . ON Prin această clauză se implementează un join general. CondiŃia de join (şi eventual şi condiŃiile suplimentare) se pun la ON. Sintaxa este:
SELECT [DISTINCT] lista_de_expresii FROM tabela1 JOIN tabela2 ON (expresie_logica)
Exemplu: cererea următoare efectuează joinul dintre ELEV şi PROFIL după coloana CODP şi conŃine şi o linie suplimentară care opreşte doar liniile corespunzătoare elevilor născuŃi în PLOIEŞTI. Această condiŃie suplimentară se putea pune şi pe clauza WHERE.
SELECT S.NUME, DATAN, F.NUME, FILIERA
Investeşte în oameni!
Pagina 73
FROM ELEV S JOIN PROFIL F ON (S.CODP=F.CODP AND LOC='PLOIESTI');
Rezultatul este: NUME DATAN NUME FILIERA
MARIA 1994-06-17 REAL TEORETICĂ
ION 1996-01-24 UMANIST TEORETICĂ
Cu JOIN ON se pot calcula şi non-echijoinuri. Dacă se doreşte o listă cu date despre elevi şi calificativele acestora, următoarea cerere va întoarce rezultate corecte:
SELECT NUME, MEDIA, TIP, REZ FROM ELEV JOIN REZULTAT ON (MEDIA BETWEEN MMIN AND MMAX)
NUME MEDIA TIP REZ
GEORGE 9.95 FOARTE BINE FB
VASILE 4.50 INSUFICIENT (NULL)
MARIA 7.58 SATISFĂCĂTOR SA
MIHAI 6.80 SATISFĂCĂTOR SA
ION 8.35 SATISFĂCĂTOR SA
STANCA 6.86 SUFICIENT SU
ALEX 8.11 SATISFĂCĂTOR SA
ELENA 6.89 SUFICIENT SU
ADRIAN 5.20 SUFICIENT SU
FLOREA 10.00 FOARTE BINE FB
OANA 6.45 SUFICIENT SU
MARIUS 4.79 INSUFICIENT (NULL)
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 3 Obiectivele activităŃilor practic-aplicative:
• Realizarea de exercitii practice cu cereri care conŃin produs cartezian. • Realizarea de exercitii practice cu cereri care conŃin joinuri (echijoin sau non-echijoin). • Realizarea de exercitii practice cu cereri care conŃin joinul unei tabele cu ea însăşi. • Realizarea de exercitii practice cu cereri care conŃin joinuri externe. • Realizarea de exercitii practice cu cereri care conŃin joinuri SQL-3.
A. 1 – Se vor executa toate cererile prezente în manual la capitolul 3.1, care exemplifică produsul cartezian.
Investeşte în oameni!
Pagina 74
A. 2 – Se vor scrie, executa şi eventual depana cererile SELECT care afişează: a. Numele elevului, numele profilului şi calificativul pentru toŃi elevii. b. Numele elevului, numele profilului şi calificativul pentru toŃi elevii de la profilul 11. c. Numele elevului, numele profilului şi calificativul pentru toŃi elevii care au calificatibul FB. d. În plus, se vor executa toate cererile prezente în manual la capitolul 3.2.
A. 3 – Se vor scrie, executa şi eventual depana cererile de tip SELECT care afişează: a. Numele elevului şi numele tutorului său pentru elevii care au un tutor. b. Perechi de nume de profiluri unde prima are un cod mai mare decât a doua. c. În plus, se vor executa toate cererile prezente în manual la capitolul 3.3.
A. 4 – Se vor scrie, executa şi eventual depana cererile de tip SELECT care afişează: a. Numele elevului şi numele tutorului său pentru elevi, fie ca au, fie că nu au un tutor. Dacă nu
au tutor va fi afişată o valoare nulă. b. Perechi de nume de profiluri unde prima are un cod mai mare decât a doua. Pentru profilurile
cu cel mai mare/cel mai mic cod perechilevor conŃine o valoare nulă. c. În plus, se vor executa toate cererile prezente în manual la capitolul 3.4.
A. 5 – Se vor executa toate cererile prezente în manual la capitolul 3.5, care exemplifică joinurile SQL-3.
TEMA 4 FuncŃii utilizate în sistemul de gestiune a bazelor de date relaŃionale
MySQL. Grupare şi funcŃii statistice. Obiectivele temei urmăresc: • Prezentarea funcŃiilor cu argumente numerice, şiruri sau date calendaristice; • Utilizarea funcŃiilor cu argumente de tipuri diferite. • Utilizarea funcŃiilor statistice. • Clauzele GROUP BY şi HAVING
4. FUNCłII Sistemul MySQL pune la dispoziŃie un număr mare de funcŃii care pot fi folosite în cererile SQL. Acestea se pot împărŃi, după numărul de linii din care se calculează rezultatul, în două mari categorii: A. FuncŃii pentru linia curentă: cererile de regăsire a datelor (SELECT) şi cele de actualizare şi ştergere (UPDATE, DELETE, prezentate în capitolele următoare) presupun o parcurgere virtuală a unei părŃi dintr-o tabelă sau produs cartezian de tabele. FuncŃiile din această categorie se evaluează pornind de la valorile conŃinute în linia curentă a parcurgerii respective. Un exemplu de astfel de funcŃie este NVL prezentată în detaliu în capitolul 2. După tipul argumentelor, aceste funcŃii se împart în:
� FuncŃii cu argumente numerice: argumentele şi rezultatul funcŃiei sunt de tip numeric. � FuncŃii pe şiruri: argumentele sunt şiruri de caractere iar rezultatul lor este un şir de
caractere sau un număr care reprezintă o proprietate a argumentelor. � FuncŃii cu argumente date calendaristice: argumentele sunt de tip dată calendaristică.
Rezultatul este fie o dată fie un număr. � FuncŃii de conversie: permit conversia între tipuri de date diferite. � FuncŃii cu argumente de tipuri diferite: în cazul acestor funcŃii atât tipul argumentelor cât şi
numărul lor nu este fixat, putând fi diferite de la un apel la altul. B. FuncŃii de grup: aceste funcŃii se evaluează pornind de la valorile conŃinute într-un grup de linii din parcurgerea curentă. Un grup poate fi format din toate liniile parcurgerii sau conŃine doar o parte a lor, selectate după unul sau mai multe criterii de grupare. Astfel de funcŃii ne permit să calculăm de
Investeşte în oameni!
Pagina 76
exemplu câŃi elevi sunt în fiecare an de studiu sau diverse valori statistice calculate la nivelul întregii baze de date sau pentru fiecare profil. Aceste funcŃii mai sunt cunoscute şi sub numele de funcŃii statistice. Sistemul MySQL pune la dispoziŃie şapte astfel de funcŃii:
� MIN, MAX şi AVG: valoarea minimă, respectiv maximă şi medie � SUM: suma valorilor � COUNT: numărul de valori/linii � STDDEV şi VARIANCE: deviaŃia standard şi varianta valorilor
În continuare sunt prezentate funcŃiile din prima categorie. FuncŃiile statistice şi clauzele GROUP BY şi HAVING.fac obiectul capitolului următor.
4.1. FuncŃii cu argumente numerice, şiruri sau date calendaristice
Numărul argumentelor unei astfel de funcŃii este fixat prin definiŃia sa. O parte dintre acestea pot fi însă opŃionale şi au fost marcate în prezentarea următoare prin includerea între paranteze drepte. Fiecare argument al unei funcŃii poate fi:
� Simplu: un nume de coloană din parcurgerea curentă, o constantă sau pseudocoloană de tip corespunzător.
� Expresie conŃinând nume de coloane, constante şi apeluri de funcŃii. a. FuncŃii cu argumente numerice În aplicaŃiile de uz general cele mai folosite funcŃii cu argumente numerice sunt următoarele:
FuncŃia TRUNC - trunchiere Sintaxa funcŃiei:
TRUNC(argument1 ,n) Descriere:
� În cazul unui n pozitiv, acesta reprezintă numărul de zecimale al rezultatului, obŃinut prin tăierea celorlalte.
� În cazul în care n este negativ trunchierea se efectuează şi asupra părŃii întregi, rezultatul având n zerouri în faŃa virgulei (punctului zecimal).
Descriere: Întoarce restul împărŃirii primului argument la al doilea. Dacă argumentele sunt întregi, rezultatul este întotdeauna întreg. În celelalte cazuri rezultatul poate avea şi zecimale, Se poate înlocui cu expresiile arg1 % arg2 sau arg1 MOD arg2.
Exemplu de cerere SQL folosind TRUNCATE, ROUND şi MOD:
SELECT NUME, MEDIA*1.1111 PCTMARIT, TRUNC(MEDIA*1.1111, 2) TRUNCHIAT, ROUND(MEDIA*1.1111, 2) ROTUNJIT, MOD(MEDIA*1.1111, 0.02) REST FROM ELEV WHERE CODP=11
Rezultatul cererii este:
NUME PCTMARIT TRUNCHIAT ROTUNJIT REST
GEORGE 3211.0790 3211.07 3211.08 0.0190
VASILE 433.3290 433.32 433.33 0.0090
MARIA 1555.5400 1555.54 1555.54 0.0000
MIHAI 1077.7670 1077.76 1077.77 0.0070
Investeşte în oameni!
Pagina 78
FuncŃiile CEIL şi FLOOR - întregii care încadrează o valoare numerică
Sintaxa funcŃiei:
CEIL(argument)
FLOOR(argument) Descriere:
� CEIL întoarce cel mai mic întreg mai mare decât argumentul � FLOOR întoarce cel mai mare întreg mai mic decât argumentul � Dacă n este un număr întreg, CEIL(n) = FLOOR(n) = n
Există şi o serie de alte funcŃii cu argumente numerice, prezentate succint în tabelul următor. În cazul în care argumentele un respecta domeniul de valori funcŃiile returnează NULL : Sintaxa funcŃiei Descriere Exemple ABS(nr) Valoarea absolută a lui n
(n real) ABS(1.3) = 1.3 ABS(-1.3) = 1.3
SIGN(n) Semnul lui n (n real) -1 dacă n este negativ 0 dacă n este 0 1 dacă n este pozitiv
PI() Valoarea lui π PI() ≈≈≈≈ 3.1415 SIN(n) Sinus de n (n în radiani) SIN(1) ≈≈≈≈ 0.841471
SIN(PI()) ≈≈≈≈ 0
Investeşte în oameni!
Pagina 79
COS(n) Cosinus de n (n în radiani) COS(1) ≈≈≈≈ 0.5403023 COS(PI()) ≈≈≈≈ -1
TAN(n) Tangentă de n (n în radiani)
TAN(1) ≈≈≈≈ 1.557408 TAN(PI()) ≈≈≈≈ 0
COT(n) Cotangentă de n (n în radiani)
COT(1) ≈≈≈≈ 0.6420 COT(0) ≈≈≈≈ NULL
b. FuncŃii cu argumente şiruri de caractere Şi în cazul acestor funcŃii argumentele pot fi constante, nume de coloane şi expresii care se evaluează la şiruri de caractere. În cazul în care un argument care, prin definiŃia funcŃiei, trebuie să fie şir nu îndeplineşte această condiŃie el este convertit automat la şir de caractere (dacă este posibil, altfel eroare). Un exemplu uzual este cel al expresiilor numerice sau de tip dată calendaristică, ambele tipuri fiind convertibile. FuncŃiile uzuale din această categorie sunt:
FuncŃia STR_TO_DATE converteşte un şir la o data calendaristică. Exista si varianta CONCAT_WS (concatenare cu separator). Sintaxa este:
CONCAT(separator, argument1, argument2, …) Descriere: se concateneaza argumentele nenule punand intre ele separatorul. Valorile nule sunt omise din concatenare. Exemple:
CONCAT_WS(',', 'Data: ', NULL, ' DE AZI') = 'Data: , DE AZI' CONCAT_WS(',', NULL, NULL, NULL) = '' (şirul vid)
FuncŃia LENGTH
Sintaxa funcŃiei: LENGTH(argument)
Descriere: întoarce lungimea şirului argument in octeŃi. Exemple:
Sintaxa funcŃiilor: SUBSTR(şir, start [, nr_car]), SUBSTRING(şir, start [, nr_car]), SUBSTR(şir FROM start [FOR nr_car]), SUBSTRING(şir FROM start [FOR nr_car]),
Descriere:
SUBSTR este sinonim cu SUBSTRING � Întoarce un subşir al primului argument începând cu poziŃia start şi conŃinând nr_car
caractere. � Dacă ultimul parametru lipseşte se consideră 'până la sfârşitul şirului' � În cazul în care start este mai mare decât lungimea şirului care se decupează, funcŃia întoarce
� Întoarce poziŃia subşirului în şir, numărând de la începutul acestuia (în cazul INSTR şi al lui LOCATE atunci când al treilea parametru lipseşte) sau din poziŃia start (pentru LOCATE cu 3 parametri).
� În cazul în care nu se găseşte nici o apariŃie validă a subşirului, funcŃia întoarce valoarea 0. Exemple:
Sintaxa funcŃiilor: LPAD(şir, dimensiune , sirumplere) RPAD(şir, dimensiune , sirumplere) Descriere: Completare la stânga (LPAD) sau la dreapta (RPAD) cu şirul de umplere până la dimensiunea specifiată. Dacă sirul e mai mic decat dimensiunea acesta este scurtat. Exemple:
Sintaxa funcŃiei: TRIM([LEADING|TRAILING|BOTH] [şir] FROM argument) TRIM(argument)
Descriere: În prima formă se elimină din stânga/dreapta/amândouă părŃile şirul specificat din argument. Eliminarea se face până când este întâlnit un alt caracter. Valorile implicite ale parametrilor opŃionali sunt BOTH şi spaŃiu (' '). În forma simplificată, TRIM(argument) elimină spaŃiile de la capetele argumentului.
Exemple: TRIM(LEADING 'b' FROM 'bbbucuresti') = 'ucuresti' TRIM(TRAILING from ' Bucuresti ') =
' Bucuresti' TRIM(' Bucuresti ')= 'Bucuresti'
ObservaŃie: TRIM(FROM ' Bucuresti ') va semnala o eroare. În cazul în care elementele opŃionale lipsesc cuvântul cheie FROM nu trebuie să apară nici el în lista de parametri ai funcŃiei, folosindu-se a doua formă a acesteia. Pentru operaŃii de acest tip mai sunt disponibile funcŃiile LTRIM şi RTRIM având un singur argument şi care elimină spatiile aflate la capătul din stânga, respectiv dreapta al argumentului. Exemple:
Descriere: Întoarce un cod alfanumeric al sonorităŃii argumentului (în limba engleză). Este folosită doar pentru a compara codurile a două şiruri, în cazul în care nu se ştie exact cum a fost înregistrat unul dintre ele în baza de date. Exemplu:
SELECT NUME, SOUNDEX(NUME) COD FROM ELEV WHERE SOUNDEX(NUME) IN (SOUNDEX('ELNA'), SOUNDEX('IOHN'), SOUNDEX('IHON'));
Rezultat: NUME COD
Investeşte în oameni!
Pagina 83
ION I500
ELENA E450
Următoarele cereri utilizează câteva dintre funcŃiile pentru şiruri de caractere descrise în acest paragraf. După cum se poate constata, o funcŃie poate avea ca argument o expresie conŃinând alte funcŃii: Exemplul 1: FuncŃiile CONCAT, LOWER, RPAD, LPAD, INSTR, SOUNDEX:
WHERE SUBSTR(SOUNDEX(NUME), 2, 3) > SUBSTR(SOUNDEX(LOC), 2, 3) AND INSTR(LOWER(NUME), 'e') > 0
Rezultatul cererii este: SIR CONCATENAT COD1 COD2 POZ
george..........bucuresti G620 B2623 2
elena...........bucuresti E450 B2623 1
Exemplul 2: FuncŃiile REPLACE şi TRIM. În acest caz funcŃia TRIM elimină şirul 'MA' din 'MATEMA'
rezultat din aplicarea lui SUBSTR:
SELECT NUME, TRIM('MA' FROM SUBSTR(NUME, 1, 6)) TR, FILIERA, REPLACE(FILIERA, 'TEOR', 'MULTA ') REPL FROM PROFIL WHERE CODP < 20;
Rezultat:
NUME TR FILIERA REPL
REAL REAL TEORETICĂ MULTA ETICĂ
c. OperaŃii şi funcŃii pentru date calendaristice Pentru datele calendaristice (tipul DATE, DATETIME ;i TIMESTAMP) sistemul MySQL stochează următoarele informaŃii: An, Lună, Zi, Oră, Minut, Secundă. Exemplu: Pentru data de 20 decembrie 1984, ora 15:45:32 se stochează:
Investeşte în oameni!
Pagina 84
An Luna Zi Ora Minut Secunda 1984 12 20 15 45 32
ObservaŃii:
� Formatul standard de afişare a datei este AAAA-LL-ZZ HH:MM:SS unde: o AAAA, LL, ZZ: anul, luna şi ziua în cifre. o HH, MM, SS: ora, minutul şi secunda în cifre
� În cazul DATETIME şi TIMESTAMP se pot folosi şi microsecundele (de la 0 la 999999) dar nu se stochează în baza de date.
� Există o funcŃie fără parametri care returnează data sistemului: SYSDATE(). Plaja de valori valide pentru date calendaristice este:
Tipul Cea mai mică data Cea mai mare dată DATE 1000-01-01 9999-12-31
Există de asemenea tipurile TIME şi YEAR care pot Ńine doar partea de timp sau de an a unei date calendaristice.
OperaŃii aritmetice cu date calendaristice În MySQL o dată calendaristică este asimilată cu numarul YYYYLLZZ iar un DATETIME sau TIMESTAMP cu numarul YYYYLLZZHHMMSS. De aceea în cazul în care facem operaŃii aritmetice cu date calendaristice operanzii sunt numerele corespunzătoare datelor. Adăugarea unui numar la o dată nu va returna o altă dată. De exemplu dacă adunăm 100 la 2010-12-31 vom obtine 20101331 si nu 20110401.
FuncŃii pentru date calendaristice Există un număr mare de funcŃii pentru date calendaristice:
Nume Descriere ADDDATE() Adaugă intervale la o dată (de ex. zile sau luni) ADDTIME() Adauga o valoare de tip timp la o data CONVERT_TZ() Converteste de la un meridian la altul. CURDATE() Returnează data curentă CURRENT_DATE Sinonim pentru CURDATE() CURRENT_TIME Sinonim pentru CURTIME() CURRENT_TIMESTAMP Sinonim pentru NOW() CURTIME() Returnează timpul curent DATE_ADD() Adaugă intervale la o dată (de ex. zile sau luni) DATE_FORMAT() Formatează o dată cf. unui şablon
Investeşte în oameni!
Pagina 85
DATE_SUB() Scade o valoare de tip timp dintr-o dată
DATE() Extrage partea de dată dintr-o expresie de tip datetime
DATEDIFF() Numărul de zile dintre două date DAY() Sinonim pentru DAYOFMONTH()
DAYNAME() Numele zilei din săptămână a argumentului (eng.)
DAYOFMONTH() Numărul zilei din lună (0-31) a argumentului DAYOFWEEK() Numărul zilei din săptămână a argumentului DAYOFYEAR() Numărul zilei din an (1-366) a argumentului EXTRACT() Extrage o parte a datei (an, an+lună, etc) FROM_DAYS() Converteşte un număr de zi în dată FROM_UNIXTIME() Formatează un timestamp UNIX ca dată GET_FORMAT() Returnează un şir de formatare dată HOUR() Extrage ora dintr-o dată
LAST_DAY Return the last day of the month for the argument
LOCALTIME Sinonim pentru NOW() LOCALTIMESTAMP Sinonim pentru NOW()
MAKEDATE() Crează o dată dintr-un an şi un număr de zi în an
MAKETIME() Crează o valoare timp din elementele componente
MICROSECOND() Numărul de microsecunde din argument MINUTE() Numărul de minute din argument MONTH() Numărul lunii din argument MONTHNAME() Numele lunii din argument (eng.) NOW() Data din sistem (la inceputul rulării cererii)
PERIOD_ADD() Adaugă un număr de luni la o perioadă de tip ani şi luni
PERIOD_DIFF() Numărul de luni dintre două perioade QUARTER() Întoarce trimestrul datei calendaristice
SEC_TO_TIME() Converteşte un număr de secunde în format 'HH:MM:SS'
SECOND() Returnează secunda dintr-un TIME (0-59) STR_TO_DATE() Converteşte un şir în dată conform unui format SUBDATE() Sinonim pentru DATE_SUB() SUBTIME() Scăderea între o datetime sau timp şi un timp SYSDATE() Data din sistem (la executia funcŃiei)
TIME_FORMAT()
Ca şi DATE_FORMAT dar formatul poate contine doar elemente de tip oră, minut, secundă, ms.
TIME_TO_SEC() Numărul total de secunde dintr-un timp
TIME() Extrage ca şir timpul dintr-o expresie de tip datetime
TIMEDIFF() Scăderea dintre două datetime sau doi timpi
Investeşte în oameni!
Pagina 86
TIMESTAMP() Returnează un TIMESTAMP pe baza unicului argument sau a sumei celor două argumente
TIMESTAMPADD() Adaugă un interval la o expresie datetime TIMESTAMPDIFF() Scade un interval dintr-o expresie datetime TO_DAYS() Data argument convertită în zile de la anul 0
TO_SECONDS() Converteşte o dată sau datetime la numărul de secunde de la aanul 0
UNIX_TIMESTAMP()
Returnează un timestamp UNIX (argumentul sau data curentă) - nr. de secunde de la 1-1-16.80
UTC_DATE() Returnează data curentă UTC - fosta GMT UTC_TIME() Returnează timpul curent UTC UTC_TIMESTAMP() Returnează data şi timpul curent UTC WEEK() Returnează numărul săptămânii din an
WEEKDAY() Returnează numărul zilei din săptămână (1-luni, …)
WEEKOFYEAR() Echivalentă cu una din formele lui WEEK() YEAR() Returnează anul din argument YEARWEEK() Returnează anul şi săptămâna din argument
4.2. FuncŃii cu argumente de tipuri diferite
Tipul parametrilor acestor funcŃii ca şi numărul lor pot diferi de la un apel la altul. Cele mai importante funcŃii din această categorie sunt:
FuncŃiile GREATEST şi LEAST
Sintaxa funcŃiilor: GREATEST(lista de expresii) LEAST(lista de expresii) Descriere:
� GREATEST întoarce cea mai mare valoare din lista argument � LEAST întoarce cea mai mică valoare din lista argument � Expresiile care apar ca parametri ai acestor funcŃii pot avea orice tip. � Dacă lista conŃine o valoare nulă, rezultatul funcŃiei este NULL. Toate valorile din listă sunt
convertite la tipul primeia dintre ele. Rezultatul întors de funcŃie are acelaşi tip cu al primei valori nenule.
Exemple: GREATEST(50, 10, '80', 4, '7') întoarce 80 GREATEST('2004-01-01', '1998-12-02') întoarce data din 2004 LEAST(50, '10', 80, '4', 7) întoarce 4 LEAST('2004-01-01', '1998-12-02') întoarce data din 1998
� IFNULL: întoarce valoarea expresie1 dacă este nenulă şi expresie2 în caz contrar. � NULLIF: întoarce NULL dacă expresie1 ' expresie2, altfel expresie1. � COALESCE: întoarce prima valoare nenulă din lista de expresii. � Expresiile care apar ca parametri ai acestor funcŃii pot avea orice tip.
Expresii IF Se pot efectua decizii în expresii folosind expresii IF. Sintaxa unui astfel de IF este următoarea:
IF (expresie1, expresie2, expresie3)
Rezultatul unei astfel de expresii se calculează astfel:
Dacă expresie1 Atunci expresie2 Altfel expresie3
De remarcat ca expresie1 poate returna orice valori. O valoare egală sau echivalenta cu 0 si NULL va fi considerată FALSE iar orice altă valoare cu TRUE.
Exemplu:
SELECT NUME, MEDIA, REZ+2, IF(REZ+2, 'ARECALIFICATIV', 'FARACALIFICATIV') FROM ELEV, REZULTAT WHERE MEDIA BETWEEN MMIN AND MMAX AND CODP=11;
Rezultatul va conŃine pe ultima coloană şirul FARACALIFICATIV pentru elevii care au abrevierea calificativului nulă (echivalent cu FALS) şi ARECALIFICATIV la ceilalŃi. Un şir care nu conŃine cifre e luat ca 0:
NUME MEDIA REZ+2 IF(REZ+2, 'ARECALIFICATIV', 'FARACALIFICATIV')
GEORGE 9.95 2 ARECALIFICATIV
VASILE 4.50 (NULL) FARACALIFICATIV
MARIA 7.58 2 ARECALIFICATIV
Investeşte în oameni!
Pagina 88
MIHAI 6.80 2 ARECALIFICATIV
Expresii CASE Exista posibilitatea de a efectua teste şi mai complicate în expresii. Acest lucru se implementează în MySQL prin expresiile CASE (asemănătoare cu instrucŃiunile de tip CASE - SWITCH dar returnează o valoare). Sintaxa unei astfel de expresii este următoarea:
CASE expresie WHEN val_1 THEN rezultat_1 [ WHEN val_2 THEN rezultat_2 ] . . . [ WHEN val_n THEN rezultat_n ] [ ELSE rezultat_n+1 ] ] END
Exemplu:
SELECT NUME, DATAN, CONCAT(DATE_FORMAT(DATAN, '%d'), ' din luna ', CASE DATE_FORMAT(DATAN, '%m')
WHEN '01' THEN 'IANUARIE' WHEN '02' THEN 'FEBRUARIE' WHEN '03' THEN 'MARTIE' WHEN '04' THEN 'APRILIE' WHEN '05' THEN 'MAI' WHEN '06' THEN 'IUNIE' WHEN '07' THEN 'IULIE' WHEN '08' THEN 'AUGUST' WHEN '09' THEN 'SEPTEMBRIE' WHEN '10' THEN 'OCTOMBRIE' WHEN '11' THEN 'NOIEMBRIE' WHEN '12' THEN 'DECEMBRIE' ELSE ' '
END ) DATAR FROM ELEV WHERE CODP = 11;
Rezultatul obŃinut este:
NUME DATAN DATAR
GEORGE 1993-03-12 12 din luna MARTIE
VASILE 1995-10-05 05 din luna OCTOMBRIE
Investeşte în oameni!
Pagina 89
MARIA 1994-06-17 17 din luna IUNIE
MIHAI 1996-01-01 01 din luna IANUARIE
Există şi o a doua formă a expresiilor CASE. Sintaxa în acest caz este următoarea:
CASE WHEN expresie-logică-1 THEN rezultat_1 [ WHEN expresie-logică-2 THEN rezultat_2 ] . . . [ WHEN expresie-logică-n THEN rezultat_n ] [ ELSE _n+1 ] ] END
Exemplu: SELECT NUME, DATAN, CONCAT('Nascut in trimestrul ',
CASE WHEN DATE_FORMAT(DATAN, '%m') <= '03' THEN 'T1' WHEN DATE_FORMAT(DATAN, '%m') <= '06' THEN 'T2' WHEN DATE_FORMAT(DATAN, '%m') <= '09' THEN 'T3' ELSE 'T4' END ) DATAR
FROM ELEV WHERE CODP = 11;
Rezultat:
NUME DATAN DATAR
GEORGE 1993-03-12 Nascut in trimestrul T1
VASILE 1995-10-05 Nascut in trimestrul T4
MARIA 1994-06-17 Nascut in trimestrul T2
MIHAI 1996-01-01 Nascut in trimestrul T1
5. FUNCłII STATISTICE ŞI GRUPURI În cazul cererilor SELECT discutate până acum fiecare linie a rezultatului era calculată dintr-o linie a unei tabele din baza de date sau a produsului cartezian al unor tabele. În unele cazuri este însă necesar calculul unor valori statistice pornind de la toate liniile parcurgerii curente sau ale unor grupuri de linii care au aceleaşi valori pentru o listă de expresii. În ambele cazuri liniile rezultatului sunt formate din valori care caracterizează ansamblul din care provin şi pot conŃine:
� Valori ale unor funcŃii statistice (cele mai importante fiind MIN, MAX, AVG, SUM, COUNT, STDDEV, VARIANCE).
Investeşte în oameni!
Pagina 90
� Constante (numerice, şir de caractere sau dată calendaristică). În categoria constantelor sunt incluse şi funcŃii puse la dispoziŃie de sistem cum este USER(), SYSDATE(), etc.
� De obicei apar şi valori ale expresiilor după care s-a făcut gruparea, în cazul în care aceasta este prezentă în cerere, dar pot sa apara şi alte expresii.
Rezultatul unei cereri SELECT care conŃine funcŃii statistice are: � O singură linie în cazul în care cererea nu conŃine clauza de grupare GROUP BY � Un număr de linii egal cu numărul de grupuri formate pe baza criteriilor de grupare din
GROUP BY, dacă această clauză există şi nu este însoŃită de clauza HAVING. � Un număr de linii egal cu numărul de grupuri formate pe baza criteriilor de grupare din
GROUP BY care îndeplinesc condiŃia de grup din HAVING, dacă ambele clauze sunt prezente în cerere.
Numărul de coloane al rezultatului este ca şi înainte egal cu numărul expresiilor aflate pe clauza SELECT.
5.1. FuncŃii statistice Spre deosebire de funcŃiile prezentate anterior, fiecare funcŃie statistică îşi calculează rezultatul pornind de la o mulŃime de valori, fiecare calculată dintr-o altă linie a parcurgerii curente. Această listă poate conŃine valori nule sau duplicate. Tratarea acestor situaŃii este făcută astfel:
� În afară de COUNT(*), toate celelalte apeluri ale funcŃiilor statistice ignoră valorile nule din listă. Dacă toate valorile din listă sunt nule atunci funcŃia întoarce de asemenea o valoare nulă.
� Implicit funcŃiile statistice consideră toate valorile nenule din listă, inclusiv valorile duplicat (opŃiune implicită ALL). Dacă se doreşte ca rezultatul să nu ia în considerare aceste valori expresia argument trebuie prefixată cu cuvântul cheie DISTINCT.
� MIN(expresie) întoarce valoarea minimă din lista de valori ale expresiei, fiecare valoare fiind calculată pe baza unei linii din parcurgerea curentă.
� MAX(expresie) întoarce valoarea maximă din aceeaşi listă. � Folosirea lui DISTINCT nu are în acest caz nici un efect, minimul şi maximul fiind acelaşi dacă
din listă se elimină duplicatele. � Minimul sau maximul dintr-o listă de zero valori întoarce NULL
Exemplu: Valoarea minimă şi maximă a mediei pentru elevii de la profilul 'REAL'. Pentru aflarea acestora trebuie făcut joinul a doua tabele (ELEV, PROFIL) după care se opresc doar liniile corespunzătoare elevilor profilului dorit.
Investeşte în oameni!
Pagina 91
Pentru acestea se afişează minimul şi maximul. Clauza SELECT poate conŃine în acest caz constante (şir de caractere în exemplul de mai jos) şi funcŃii statistice deoarece nu există clauză de grupare:
SELECT 'REAL' PROFIL, MIN(MEDIA) MINIM, MAX(MEDIA) MAXIM FROM ELEV, PROFIL WHERE ELEV.CODP = PROFIL.CODP AND PROFIL.NUME = 'REAL'
Rezultatul obŃinut va avea o singură linie având conŃinutul:
PROFIL MINIM MAXIM
REAL 4.50 9.95
MulŃimea de valori din care s-au calculat aceste date statistice este cea descrisă de cererea următoare:
SELECT ELEV.NUME, MEDIA FROM ELEV, PROFIL WHERE ELEV.CODP = PROFIL.CODP AND
� SUM(expresie) întoarce suma valorilor nenule din lista de expresii, fiecare valoare fiind calculată pe baza unei linii din parcurgerea curentă.
� SUM(DISTINCT expresie) face acelaşi lucru ignorând însă valorile duplicat. � AVG(expresie) întoarce media aritmetică a valorilor nenule din lista de expresii. � AVG(DISTINCT expresie) întoarce media aritmetică rezultată prin ignorarea valorilor duplicat.
Exemplu: Suma şi media pe coloana an de studii pentru elevii cu medie mai mare ca 8. Valorile de la care se calculează aceste date statistice sunt următoarele:
NUME AN
GEORGE 4
Investeşte în oameni!
Pagina 92
ION 1
ALEX 4
FLOREA 4
Cererea este:
SELECT 'MEDIA MAI MARE CA 8' MEDIA, SUM(AN) SUM1, SUM(DISTINCT AN) SUM2, AVG(AN) AVG1, AVG(DISTINCT AN) AVG2 FROM ELEV WHERE MEDIA > 8;
cu rezultat:
MEDIA SUM1 SUM2 AVG1 AVG2
MEDIA MAI MARE CA 8 13 5 3.2500 2.5000
După cum se observă, suma şi media sunt diferite pentru considerarea sau ignorarea valorilor duplicate.
FuncŃia COUNT
Sintaxa funcŃiei:
COUNT(*) COUNT([ DISTINCT] expresie)
Descriere:
� COUNT(*) întoarce numărul de linii pe baza cărora se calculează rezultatul. Din acest motiv nu se poate adăuga DISTINCT sau nu se poate vorbi de valori nule sau nenule.
� COUNT(expresie) întoarce numărul de valori nenule ale expresiei. � COUNT(DISTINCT expresie) întoarce numărul de valori nenule şi distincte ale expresiei.
Exemplu: Pentru tabela elevi se doreşte: aflarea numărului de elevi, a numărului de calificative nenule şi a numărului de valori dictincte de calificativ. Cererea este:
SELECT COUNT(*), COUNT(REZ), COUNT(DISTINCT REZ) FROM ELEV, REZULTAT WHERE ELEV.MEDIA BETWEEN MMIN AND MMAX
având rezultatul:
Investeşte în oameni!
Pagina 93
COUNT(*) COUNT(REZ) COUNT(DISTINCT REZ)
12 10 4
Într-adevăr, sunt 12 elevi, doar 10 au calificativ nenul şi sunt 4 valori distincte pentru aceastea.
� Din punct de vedere matematic, deviaŃia standard dă o măsura a abaterii faŃă de medie iar varianŃa este pătratul deviaŃiei standard.
� STDDEV(expresie) întoarce deviaŃia standard a valorilor expresiei. � VARIANCE(expresie) întoarce varianŃa valorilor respective. � STD şi STDDEV_POP sunt sinonime cu STDDEV � VAR_POP este sinonim cu VARIANCE
Exemplu: Dacă se doreşte afişarea deviaŃiei standard şi varianŃei tuturor valorilor de pe coloana MEDIA a tabelei ELEV cererea este:
SELECT STDDEV(MEDIA), VARIANCE(MEDIA) FROM ELEV;
Rezultat:
STDDEV(MEDIA) VARIANCE(MEDIA)
1.723835 2.971606
5.2. Clauza GROUP BY În cererile anterioare toate liniile parcurgerii curente formau un grup din care se calculau valorile funcŃiilor statistice. Dacă se doreşte însă partiŃionarea acestora în grupuri pentru a calcula valori statistice pentru fiecare grup în parte este necesară folosirea clauzei GROUP BY. Sintaxa acesteia este:
GROUP BY expresie1 [, expresie2, expresie 3 ...] Această clauză trebuie să apară în cerere după cele discutate anterior (SELECT, FROM şi WHERE) şi are următorul efect:
� Liniile parcurgerii curente (filtrate anterior de WHERE dacă aceasta este prezentă în cerere) sunt împărŃite în grupuri. Fiecare grup este format din liniile care au aceleaşi valori (inclusiv valoarea nulă) pentru expresiile specificate în GROUP BY.
Investeşte în oameni!
Pagina 94
� FuncŃiile statistice se calculează pentru fiecare grup în parte, rezultatul având un număr de linii egal cu numărul de grupuri formate.
� În clauza SELECT, pe lângă constante şi funcŃii statistice, pot apare de asemenea şi expresiile aflate în GROUP BY deoarece valorile acestora sunt constante la nivelul fiecărui grup în parte.
Dacă se doreşte de exemplu o listă conŃinând codurile profilurilor şi numărul de elevi înscrişi la fiecare, cererea este:
SELECT CODP, COUNT(*) NRELEVI FROM ELEV GROUP BY CODP;
Rezultatul obŃinut este:
CODP NRELEVI
11 4
21 4
24 4
Pentru a avea pe prima coloană numele profilului în locul codului său trebuie ca cererea să conŃină un join al tabelelor ELEV şi PROFIL iar gruparea să se facă după numele profilului, pentru ca acesta să poată fi inclus în SELECT:
SELECT PROFIL.NUME, COUNT(*) NRELEVI FROM ELEV, PROFIL WHERE ELEV.CODP = PROFIL.CODP GROUP BY PROFIL.NUME;
obŃinându-se rezultatul:
NUME NRELEVI
UMANIST 4
RESURSE NATURALE 4
REAL 4
Dacă în cererea anterioară gruparea s-ar fi făcut după alte criterii nu se semnalează eroare dar rezultatul contine valori din prima linie din grupul respective. De exemplu cererea:
SELECT ELEV.NUME, COUNT(*) NRELEVI FROM ELEV, PROFIL WHERE ELEV.CODP = PROFIL.CODP GROUP BY ELEV.AN;
Investeşte în oameni!
Pagina 95
va returna un rezultat care conŃine 4 linii (câte valori distincte sunt pe coloana AN), contorul din a doua coloană va fi corect (este funcŃie de grup) dar numele elevului va al unuia din cei 3 elevi care formează fiecare grup:
NUME NRELEVI
MIHAI 3
VASILE 3
MARIA 3
GEORGE 3
Un alt exemplu este cererea următoare care încearcă să afişeze pentru fiecare calificativ abrevierea, abrevierea concatenată cu un alt şir şi numărul de elevi asociat:
SELECT REZ, CONCAT('CALF: ',REZ) CLF, COUNT(*) FROM ELEV, REZULTAT WHERE MEDIA BETWEEN MMIN AND MMAX GROUP BY REZ;
Această cerere nu va semnala eroare, deşi gruparea se face doar după REZ iar în SELECT avem şi expresia REZ*1.1.
Funcţia statistică GROUP_CONCAT
Această funcŃie are sens doar în contextual folosirii clauzei GROUP BY. Sintaxa folosirii sale este:
Rezultatul este concatenarea valorilor expresiei la nivelul fiecarul grup, eventual ordonate conform criteriilor si separate cu separatorul virgula (implicit) sau cel dat ca argument. Exemplu:
SELECT CODP, GROUP_CONCAT(NUME ORDER BY NUME SEPARATOR '+') ELEVI FROM ELEV GROUP BY CODP
Rezultat:
CODP ELEVI
11 GEORGE+MARIA+MIHAI+VASILE
21 ALEX+ELENA+ION+STANCA
24 ADRIAN+FLOREA+MARIUS+OANA
Investeşte în oameni!
Pagina 96
Ordonarea rezultatului Se poate folosi clauza ORDER BY pentru a schimba ordinea implicită. În ea sunt prezente în mod normal doar elementele constante la nivel de grup (funcŃii statistice, expresiile de grupare) sau numărul coloanei din rezultat. În cererea următoare ordonarea se face după coloana a treia din rezultat şi, la valori egale pe aceasta, după valoarea minimă a mediei la nivel de grup, deşi acest minim nu este prezent în lista SELECT:
SELECT TUTOR,CODP,COUNT(*) FROM ELEV WHERE CODP IN (11,24) GROUP BY CODP, TUTOR ORDER BY 3, MIN(MEDIA);
Rezultatul este:
TUTOR CODP COUNT(*)
3514 24 1
4311 24 1
1456 11 2
(NULL) 24 2
(NULL) 11 2
MySQL accepta însa prezenŃa în clauzele SELECT şi ORDER BY şi a altor expresii, deşi în acest caz rezultatul va fi obŃinut folosind valorile uneia dintre liniile grupului. De exemplu, dacă în cererea anterioară adăugăm numele elevului în aceste două clauze:
SELECT NUME, TUTOR, CODP, COUNT(*) FROM ELEV WHERE CODP IN (11,24) GROUP BY CODP, TUTOR ORDER BY NUME, 3, MIN(MEDIA);
ObŃinem:
NUME TUTOR CODP COUNT(*)
ADRIAN (NULL) 24 2
GEORGE (NULL) 11 2
MARIUS 3514 24 1
OANA 4311 24 1
VASILE 1456 11 2
Investeşte în oameni!
Pagina 97
Imbricarea funcŃiilor statistice FuncŃiile statistice nu se pot imbrica în versiunea 5.5 şi precedentele. De exemplu, dacă se doreşte o medie a mediilor pe profiluri, cererea următoare va semnala eroarea cu codul 1111 - Invalid use of group function:
SELECT AVG(AVG(MEDIA)) MEDIE1 FROM ELEV GROUP BY CODP;
5.3. Clauza HAVING Fiecare grup format de GROUP BY are, în cazul cererilor precedente, o linie corespondentă în rezultat. Clauzele descrise până acum nu permit o filtrare la nivel de grup. De exemplu, dacă se doreşte obŃinerea de date doar despre profilurile care au elevi cu o medie mai mare decât 5, cererea următoare va semnala eroare:
SELECT CODP, MIN(MEDIA) FROM ELEV WHERE MIN(MEDIA) > 5 GROUP BY CODP;
Eroarea se datorează faptului că WHERE poate conŃine doar condiŃii la nivelul unei linii din parcurgerea curentă şi nu la nivel de grup. Pentru filtrarea grupurilor este necesară o nouă clauză, HAVING, având următoarea sintaxă:
HAVING conditie_de_grup
CondiŃia poate fi simplă sau compusă. În ea vor fi folosite în mod normal doar elemente constante la nivel de grup (literali, funcŃii statistice, etc.). Pentru cererea de mai sus formularea corectă este:
SELECT CODP, MIN(MEDIA) FROM ELEV GROUP BY CODP HAVING MIN(MEDIA) > 5;
Rezultatul va conŃine doar o linie, celelalte două grupuri fiind filtrare de condiŃia din HAVING:
CODP AVG(MEDIA)
21 6.86
Investeşte în oameni!
Pagina 98
Această clauză poate fi folosită şi în absenŃa lui GROUP BY. În acest caz cererea întoarce fie o linie, fie nici o linie, în funcŃie de satisfacerea sau nu a condiŃiei HAVING de liniile parcurgerii curente. De exemplu, datorită faptului că exista medii mai mici decât 5 în tabela ELEV, cererea:
SELECT MIN(MEDIA) FROM ELEV HAVING MIN(MEDIA) > 5;
nu va întoarce nici o linie de rezultat.
Investeşte în oameni!
Pagina 99
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 4 Obiectivele activităŃilor practic-aplicative:
• Realizarea de cereri care utilizează funcŃii cu argumente numerice, şiruri sau date calendaristice;
• Utilizarea în cereri a funcŃiilor cu argumente de tipuri diferite. • Realizarea de cereri care utilizează funcŃii statistice. • Utilizarea clauzelor GROUP BY şi HAVING
A. 1 – Se va scrie, executa şi eventual depana o cerere SELECT care foloseşte functiile: a. TRUNC, ROUND, MOD, CEIL şi FLOOR b. LOWER, UPPER, CONCAT şi CONCAT_WS c. LENGTH, SUBSTR, INSTR şi LOCATE d. LPAD, RPAD şi TRIM e. REPLACE, ELT, FIND_IN_SET şi SOUNDEX f. DATE, SYSDATE, STR_TO_DATE g. În plus, se vor executa toate cererile prezente în manual la capitolul 4.1
A. 2 – Se va scrie, executa şi eventual depana o cerere SELECT care foloseşte functiile: a. GRATEST, LEAST b. IFNULL, NULLIF, COALESCE c. O expresie IF d. O expresie CASE e. În plus, se vor executa toate cererile prezente în manual la capitolul 4.2
A. 3 – Se vor scrie, executa şi eventual depana cererile de tip SELECT care afişează: a. Valoarea minimă, maximă şi medie de pe coloana MEDIA a tabelei ELEV. b. Suma mediilor elevilor din anii 1 şi 2 c. Numărul de elevi care au un tutor d. Numărul de valori distincte de pe coloana PROFIL a tabelei ELEV e. În plus, se vor executa toate cererile prezente în manual la capitolul 5.1
A. 4 – Se vor scrie, executa şi eventual depana cererile de tip SELECT care afişează: a. Valoarea minimă, maximă şi medie de pe coloana MEDIA a tabelei ELEV pentru fiecare profil
în parte b. Suma mediilor elevilor din anii 1 şi 2 de la fiecare profil c. Numărul de elevi care au un tutor de la fiecare profil d. Numărul de elevi care au un tutor de la fiecare profil dar doar pentru profilurile care au media
minima peste 5. e. În plus, se vor executa toate cererile prezente în manual la capitolele 5.2 şi 5.3
TEMA 5 Folosirea subcererilor pentru elaborarea de cereri SQL complexe
Obiectivele temei urmăresc: • Prezentarea conceptului de subcerere; • Utilizarea subcererilor în expresii logice. • Utilizarea subcererilor pe clauza FROM. • Subcereri corelate • Utilizarea operatorului UNION
6. SUBCERERI O subcerere este o cerere SELECT inclusă într-o altă cerere SQL. Astfel de construcŃii se folosesc în cazul în care rezultatul dorit nu se poate obŃine cu o singură parcurgere a datelor. Un exemplu este următorul: pentru a afla cine este elevul cu cea mai mare medie sunt necesare două parcurgeri ale tabelei ELEV: prima calculează media maximă iar ulterior a doua afişează datele dorite despre elevii cu acea medie. Cum o cerere SELECT specifică o singură parcurgere a datelor rezultă că pentru rezolvarea problemei sunt necesare două astfel de cereri, prima (subcererea) furnizând datele necesare pentru a doua (cererea principală). Subcererile pot să apară în următoarele clauze ale unei cereri:
� în expresiile logice din clauzele WHERE şi HAVING � în clauza ORDER BY a unei cereri SELECT; valoarea returnată de subcerere pentru fiecare
linie a rezultatului va determina ordinea de afişare a acestora. � în clauza SELECT; valoarea returnată de subcerere va fi prezentă în rezultatul final. � în clauza FROM; în acest caz ele sunt asimilate unor tabele temporare din care se calculează
rezultatul cererii care le include.
Investeşte în oameni!
Pagina 101
6.1. Subcereri în expresii logice Rezultatul unui SELECT, dacă este nevid, este întotdeauna o tabelă. Din punct de vedere al modului de folosire al unei subcereri există însă diferenŃe în funcŃie de forma rezultatului acesteia:
� Subcereri care întorc o singură valoare � Subcereri care întorc o coloană � Subcereri care întorc o tabelă.
În continuare este prezentat modul de utilizare pentru fiecare tip în parte a. Subcereri care întorc o singură valoare În acest caz valoarea întoarsă de subcerere poate fi folosită ca oricare alta în comparaŃii care includ operatorii obişnuiŃi: <, <=, >, >=, = şi <>. Exemplul anterior al elevului cu cea mai mare medie face parte din această categorie: subcererea întoarce valoarea maximă a mediei din tabela ELEV iar cererea care o include numele elevilor care au acea medie şi valoarea acesteia:
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA = (SELECT MAX(MEDIA) FROM ELEV);
Rezultatul obŃinut este:
NUME MEDIA
FLOREA 10.00
În MySQL există câteva reguli în ceea ce priveşte scrierea subcererilor:
• Subcererea se pune obligatoriu între paranteze. • Dacă subcererea nu întoarce nici o linie, comparaŃia în care e implicată se evaluează la
FALS. • O cerere poate conŃine una sau mai multe subcereri, acestea putând fi pe acelaşi nivel sau
incluse una în alta.
În afară de operatorii uzuali de comparaŃie, în cazul acestui tip de subcereri se pot folosi şi operatorii BETWEEN, LIKE şi IS NULL. Exemplele următoare reprezintă cereri valide conŃinând şi BETWEEN sau LIKE. Folosirea lui IS NULL pentru o subcerere este relevantă doar în cazul subcererilor corelate prezentate într-un alt subcapitol.
Exemplul 1: Afişarea numelui şi mediei pentru elevii având o medie egală cu cel media pe întreaga tabelă +/- 30%. Se foloseşte operatorul BETWEEN având ca parametri două subcereri:
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA BETWEEN (SELECT AVG(MEDIA) FROM ELEV)*0.7 AND
Investeşte în oameni!
Pagina 102
(SELECT AVG(MEDIA) FROM ELEV)*1.3;
Exemplul 2: Afişarea aceloraşi date ca mai sus pentru elevii având un nume care nu începe cu aceeaşi literă cu a elevul cu medie maximă:
SELECT NUME, MEDIA FROM ELEV WHERE NUME NOT LIKE CONCAT(SUBSTR( (SELECT NUME FROM ELEV WHERE MEDIA = (SELECT MAX(MEDIA) FROM ELEV) ) , 1, 1), '%');
În acest exemplu există două niveluri de imbricare:
• Subcererea de nivel 2 întoarce valoarea maximă a mediei. • Subcererea de nivel 1 întoarce numele elevului cu acea medie. • În cererea principală este decupată prima literă a acestui nume, folosind funcŃia
SUBSTR(rezultat, 1, 1) şi este concatenată cu caracterul % pentru a forma un şablon folosit apoi de condiŃia NOT LIKE.
Exemplul 3: Subcererea comparată pentru egalitate întoarce mai multe valori. În acest caz nu vom obŃine un rezultat ci mesajul de eroare cu codul 1242 - Subquery returns more than 1 row
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA = (SELECT MEDIA FROM ELEV);
Exemplul 4: Subcererea nu întoarce nici o valoare. În acest caz vom obŃine un rezultat vid (fără nici o linie), condiŃia evaluându-se la FALS:
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA = (SELECT MAX(MEDIA) FROM ELEV WHERE CODP = 100)
b. Subcereri care întorc o coloană
În acest caz valorile coloanei întoarse de subcerere sunt asimilate unei mulŃimi. CondiŃia trebuie să folosească operatorul IN sau negatul acestuia NOT IN şi nu operatori de comparaŃie. Cererea din exemplul următor afişează lista tuturor elevilor de la profilul cu codul 21 care sunt tutori ai altor elevi. Pentru a fi tutor, matricola elevului trebuie să aparŃină mulŃimii valorilor aflate pe coloana TUTOR din tabela ELEV calculată cu ajutorul subcererii:
SELECT NUME, CODP FROM ELEV WHERE MATR IN (SELECT TUTOR FROM ELEV) AND CODP = 21;
Rezultatul va conŃine datele pentru doi elevi:
NUME CODP
STANCA 21
Investeşte în oameni!
Pagina 103
ALEX 21
ObservaŃie: NOT IN returnează întotdeauna valoarea fals în cazul în care mulŃimea conŃine valori nule.
Din această cauză pentru a obŃine lista elevilor de la această profil care nu sunt tutori nu se poate folosi cererea:
SELECT NUME, CODP FROM ELEV WHERE MATR NOT IN (SELECT TUTOR FROM ELEV) AND CODP = 21;
deoarece subcererea întoarce o coloană care conŃine şi valori nule. În astfel de cazuri este necesară eliminarea acestor valori din rezultat prin adăugarea unei condiŃii suplimentare de tip IS NOT NULL:
SELECT NUME, CODP FROM ELEV WHERE MATR NOT IN (SELECT TUTOR FROM ELEV WHERE TUTOR IS NOT NULL) AND CODP = 21;
În exemplul următor subcererea foloseşte o clauză GROUP BY pentru a calcula mediile maxime pentru fiecare profil. Cererea principală afişează elevii care au o medie egală cu vreuna dintre valorile returnate:
SELECT NUME, MEDIA, CODP FROM ELEV WHERE MEDIA IN (SELECT MAX(MEDIA) FROM ELEV GROUP BY CODP);
Întâmplător, rezultatul conŃine chiar elevii cu cea mai mare medie pentru fiecare profil. În cazul general însă rezultatul poate conŃine şi elevi care nu au media maximă la profilul lor dar egală cu maximul unui alt profil.
Operatorii SOME/ANY şi ALL Este posibilă folosirea operatorilor de comparaŃie uzuali (<, >, =, etc.) în conjuncŃie cu o cerere care întoarce o coloană dacă aceasta este prefixată cu unul din operatorii SOME, ANY şi ALL. SemnificaŃia lor este următoarea:
• SOME şi ANY: condiŃia este adevărată dacă măcar o valoare dintre cele returnate de subcerere verifică comparaŃia respectivă.
• ALL: condiŃia este adevărată dacă toate valorile returnate de subcerere verifică comparaŃia respectivă.
Exemplul 1: Lista elevilor care au o medie mai mare decât al vreunui elev de la profilul 11:
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA > SOME(SELECT MEDIA FROM ELEV WHERE CODP = 11);
Investeşte în oameni!
Pagina 104
Înlocuirea lui SOME cu ANY duce la obŃinerea aceluiaşi rezultat, cei doi operatori efectuând aceeaşi operaŃie.
Exemplul 2: Lista elevilor care au o medie mai mare decât al tuturor elevilor de la profilul 11:
SELECT NUME, MEDIA FROM ELEV WHERE MEDIA > ALL(SELECT MEDIA FROM ELEV WHERE CODP = 11);
c. Subcereri care întorc o tabelă În cazul în care subcererea întoarce un rezultat care are mai multe coloane acesta este asimilat cu o mulŃime de linii şi se poate folosi operatorul IN în următorul mod:
WHERE (lista_de_expresii) IN (subcerere)
ObservaŃii: � Lista de expresii trebuie încadrată de paranteze rotunde. � Numărul de coloane din rezultatul subcererii trebuie să fie egal cu numărul de expresii din
listă. � CorespondenŃa între valorile expresiilor din listă şi coloanele rezultatului este poziŃională. � Tipurile elementelor corespondente trebuie să fie aceleaşi sau convertibile automat unul la
celălalt (sistemul MySQL face conversia automată între tipurile şir de caractere şi numere/date calendaristice).
� CondiŃia este adevărată dacă rezultatul subcererii conŃine măcar o linie formată din valorile expresiilor din listă.
� Dacă rezultatul subcererii este vid întreaga condiŃie este evaluată la fals.
Pentru a afla care sunt elevii cu cea mai mare medie de la fiecare profil, cererea este următoarea:
SELECT NUME, MEDIA, CODP FROM ELEV WHERE (CODP, MEDIA) IN (SELECT CODP, MAX(MEDIA) FROM ELEV GROUP BY CODP);
CodiŃia va fi adevărată dacă media elevului este egală cu o valoare maximă întoarsă de subcerere şi în acelaşi timp codul profilului este al celei pentru care s-a calculat maximul respectiv. ObservaŃie: Din cauza faptului că două valori nule nu sunt egale între ele un cuplu de tipul (NULL, valoare) nu va fi considerat egal cu el însuşi.
Din acest motiv, cererea următoare nu va returna date despre elevii care nu au un tutor asociat (au o valoare nulă pe această coloană) deşi în aparenŃă condiŃia ar trebui să fie adevărată pentru orice elev al profilului având codul 11:
SELECT MATR, NUME, CODP, TUTOR
Investeşte în oameni!
Pagina 105
FROM ELEV WHERE (MATR, NUME, CODP, TUTOR) IN (SELECT MATR, NUME, CODP, TUTOR FROM ELEV WHERE CODP = 11);
Rezultatul cererii este format din 2 linii:
MATR NUME CODP TUTOR
1325 VASILE 11 1456
3145 MIHAI 11 1456
deşi rezultatul subcererii (executată separat) este următorul:
MATR NUME CODP TUTOR
1456 GEORGE 11 (NULL)
1325 VASILE 11 1456
1645 MARIA 11 (NULL)
3145 MIHAI 11 1456
În schimb inversând în cererea anterioară condiŃia (NOT IN în loc de IN) obŃinem din acelaşi motiv datele tuturor elevilor de la celelalte profiluri, indiferent dacă valoarea din coloana TUTOR este nulă sau nu. d. Subcereri pe clauza HAVING Expresiile logice conŃinând subcereri se pot folosi şi pe clauza HAVING în acelaşi mod ca mai sus. În acest caz însă condiŃiile vor conŃine doar elementele care pot să apară într-o astfel de clauză: constante, expresiile după care se face gruparea şi funcŃii statistice. În continuare sunt prezentate câteva exemple:
Exemplul 1: Afişarea codului numeric şi a mediilor minimă şi maximă doar pentru profilurile care au o medie peste media calculată la nivelul întregii tabele ELEV:
SELECT CODP, MIN(MEDIA), MAX(MEDIA) FROM ELEV GROUP BY CODP HAVING AVG(MEDIA) > (SELECT AVG(MEDIA) FROM ELEV);
Exemplul 2: Afişarea codului şi a mediei maxime pentru toate profilurile în afara celei/celor cu cea mai mică medie maximă. Pentru ca o profil să apară în rezultat media sa maximă trebuie să fie mai mare
Investeşte în oameni!
Pagina 106
decât a vreunui alt profil. Subcererea întoarce lista mediilor maxime iar comparaŃia dorită se face folosind operatorul ANY:
SELECT CODP, MAX(MEDIA) FROM ELEV GROUP BY CODP HAVING AVG(MEDIA) > ANY (SELECT AVG(MEDIA) FROM ELEV GROUP BY CODP);
Rezultatul va fi următorul:
CODP MAX(MEDIA)
11 9.95
21 8.35
6.2. Subcereri în clauza FROM În cazul în care o subcerere apare pe clauza FROM ea trebuie să aibă un alias de tabelă şi va fi tratată ca o tabelă temporară. Cererea următoare afişează numele elevilor avand calificativ nenul de la profilul cu codul 11. Rezultatul este calculat pornind de la o subcerere care returnează joinul tabelelor ELEV şi REZULTAT filtrat prin condiŃii suplimentare care opresc doar datele promovaŃilor de la profilul respectiv: REZ este nenul şi CODP este egal cu 11:
SELECT TBL.NUME, TBL.REZ FROM (SELECT * FROM ELEV, REZULTAT WHERE MEDIA BETWEEN MMIN AND MMAX AND CODP = 11 AND REZ IS NOT NULL) TBL;
Rezultatul obŃinut este:
NUME REZ
GEORGE FB
MARIA SA
MIHAI SA
Cererea anterioară se poate rescrie şi ca un join de două subcereri:
SELECT NUME, REZ FROM (SELECT * FROM ELEV WHERE CODP = 11) S11,
Investeşte în oameni!
Pagina 107
(SELECT * FROM REZULTAT WHERE REZ IS NOT NULL) B WHERE S11.MEDIA BETWEEN B.MMIN AND B.MMAX;
În exemplul următor se afişează numele elevilor şi numele profilului pentru profilul cu codul 11:
SELECT ST.NUME, SP.NUME FROM ELEV ST, (SELECT * FROM PROFIL WHERE CODP = 11) SP WHERE ST.CODP = SP.CODP;
Deoarece tabela ELEV şi rezultatul subcererii au două coloane cu aceeaşi denumire (NUME şi CODP), în cazul în care nu s-ar fi folosit aliasurile de tabelă sistemul semnala eroarea 1052 (nume de coloana ambiguu). În cazul în care o subcerere aflată pe clauza FROM nu întoarce nici o linie nu se semnalează o eroare dar cererea care o include va returna un rezultat vid, inclusiv în cazul unui produs cartezian. Subcererea din exemplul următor nu returnează linii deoarece profilul cu codul 100 nu există:
SELECT ST.NUME, SP.NUME FROM ELEV ST, (SELECT * FROM PROFIL WHERE CODP = 100) SP WHERE ST.CODP = SP.CODP;
O astfel de subcerere poate participa însă la un join extern:
SELECT ST.NUME, SP.NUME FROM ELEV ST LEFT OUTER JOIN (SELECT * FROM PROFIL WHERE CODP = 100) SP ON (ST.CODP = SP.CODP);
6.3. Subcereri corelate În exemplele anterioare subcererea se execută o singură dată după care rezultatul său este folosit pentru evaluarea care o include. Există însă posibilitatea ca rezultatul subcererii să fie dependent de valorile de pe linia curentă a parcurgerii definite de cerere. În acest caz se spune că avem o subcerere corelată. Descrierea modului de evaluare în astfel de situaŃii va fi făcută pe baza următorului exemplu care afişează date despre elevii care au o medie peste media celor din profilul lor. Deoarece şi cererea şi subcererea lucrează pe aceeaşi tabelă, se foloseşte aliasul de tabelă S pentru a specifica parcurgerea principală (cea din cerere).
SELECT NUME, CODP, MEDIA FROM ELEV S WHERE MEDIA > (SELECT AVG(MEDIA) FROM ELEV WHERE CODP = S.CODP);
Investeşte în oameni!
Pagina 108
Evaluarea se face astfel:
� Pentru fiecare linie a tabelei ELEV valoarea de pe coloana CODP - codul profilului - va fi transmisă subcererii (S.CODP).
� Se execută subcererea care calculează media mediei pentru elevii de la profilul respectiv (AVG şi condiŃia CODP = S.CODP).
� Rezultatul subcererii este folosit în cerere pentru a filtra sau nu linia curentă (condiŃia MEDIA > rezultat subcerere).
Teoretic subcererea nu se mai execută o singură dată ci pentru fiecare linie din parcurgerea specificată de cererea în care este inclusă. Cererea următoare afişează numele, codul şi numărul total de elevi pentru profilurile la care este înmatriculat cel puŃin un elev de anul 1. Subcererea primeşte codul profilului pentru grupul curent şi returnează numărul de elevi de anul 1 din acesta:
SELECT SP.NUME, ST.CODP, COUNT(*) FROM ELEV ST, PROFIL SP WHERE ST.CODP = SP.CODP GROUP BY SP.NUME, ST.CODP HAVING 1 <= (SELECT COUNT(*) FROM ELEV WHERE CODP = ST.CODP AND AN = 1);
Rezultatul va fi următorul:
NUME CODP COUNT(*)
UMANIST 21 4
RESURSE NATURALE 24 4
REAL 11 4
ObservaŃii:
� În cazul în care subcererea corelată se află pe clauza WHERE ea poate primi valoarea de pe orice coloană a tabelei/produsului cartezian din cererea înconjurătoare.
� În cazul în care subcererea corelată este pe clauza HAVING poate primi doar coloanele/expresiile după care s-a facut gruparea.
� Subcererile corelate pot returna o valoare, o coloană sau o tabelă, ca şi cele necorelate. În cazul în care returnează o coloană sau o tabelă se poate folosi operatorul IN. Sunt permişi de asemenea operatorii SOME/ANY şi ALL.
Investeşte în oameni!
Pagina 109
Dacă în cazul cererii anterioare gruparea se poate face şi doar după una dintre coloanele SP.NUME, ST.CODP deoarece nu există două profiluri cu acelaşi nume sau cod. Gruparea după ambele coloane este însă recomandată pentru compatibilitatea cu alte sisteme de gestiune. Operatorul EXISTS Acest operator testează dacă subcererea primită ca argument întoarce un rezultat nevid. Sintaxa sa este:
EXISTS(subcerere)
şi returnează valorea logică ADEVARAT dacă subcererea are un rezultat nevid şi FALS dacă rezultatul e vid (nici o linie). În cazul acestui operator nu este important conŃinutul rezultatului subcererii ci doar existenŃa sau absenŃa sa. Exemplul 1: Lista elevilor care sunt tutori pentru alŃi colegi. Subcererea întoarce datele elevilor care îl au ca tutor pe cel din linia curentă a parcurgerii principale:
SELECT NUME, AN FROM ELEV S WHERE EXISTS(SELECT * FROM ELEV WHERE TUTOR = S.MATR);
Exemplul 2: Lista profilurilor unde există cel puŃin un elev de anul 1:
SELECT CODP, NUME FROM PROFIL WHERE EXISTS (SELECT 1 FROM ELEV WHERE PROFIL.CODP = CODP AND AN = 1);
În acest caz nu a mai fost necesară folosirea unui alias de tabelă deoarece se poate face prefixarea cu numele tabelei PROFIL (cererea şi subcererea sunt pe tabele diferite). De asemenea în clauza SELECT a subcererii există doar o expresie constantă deoarece conŃinutul rezultatului nu este folosit mai departe de către cerere ci doar se testează existenŃa sa.
Exemplul 3: Operatorul se poate folosi şi pe clauza HAVING: cererea prezentată anterior care returnează numele, codul şi numărul total de elevi pentru profilurile cu cel puŃin un elev de anul 1 poate fi rescrisă astfel:
SELECT SP.NUME, ST.CODP, COUNT(*)
FROM ELEV ST, PROFIL SP WHERE ST.CODP = SP.CODP GROUP BY SP.NUME, ST.CODP HAVING EXISTS (SELECT 'EXISTA' FROM ELEV
Investeşte în oameni!
Pagina 110
WHERE CODP = ST.CODP AND AN = 1);
Subcereri pe clauza ORDER BY În actualele versiuni ale sistemului MySQL clauza ORDER BY poate conŃine o subcerere Aceasta trebuie să returneze o singură valoare şi să fie o subcerere corelată. PrezenŃa unei cereri necorelate pe această clauză nu duce la ordonarea rezultatului deoarece rezultatul fiind o constantă are aceeaşi valoare pentru fiecare dintre liniile supuse sortării. În exemplul următor ordonarea se face după numărul de elevi îndrumaŃi de fiecare tutor:
SELECT NUME, CODP, AN FROM ELEV S WHERE CODP = 24 ORDER BY (SELECT COUNT(*) FROM ELEV WHERE TUTOR = S.MATR) DESC;
Rezultatul obŃinut este:
NUME CODP AN
ADRIAN 24 3
FLOREA 24 4
OANA 24 2
MARIUS 24 1
Primii din listă sunt ADRIAN şi FLOREA care sunt tutorii câte unui elev după care urmează ceilalŃi elevi ai profilului cu codul 24 care nu sunt tutori. Subcereri pe clauza SELECT Ca şi în cazul celor din ORDER BY aceste subcereri trebuie să întoarcă o singură valoare. Subcererea poate fi necorelată (în acest caz pe coloana respectivă din rezultat vom avea aceeaşi valoare) sau corelată. Un exemplu în acest sens este cererea următoare care afişează, pentru elevii de la profilul 24, numărul de colegi îndrumaŃi. Acest număr este calculat de o subcerere corelată care este folosită de asemenea pentru ordonarea rezultatului, ca în exemplul anterior, şi pentru eliminarea din rezultat a elevilor care nu sunt tutori:
SELECT NUME, (SELECT COUNT(*) FROM ELEV WHERE TUTOR = S.MATR) NUMAR FROM ELEV S
Investeşte în oameni!
Pagina 111
WHERE CODP = 24 AND 1 <= (SELECT COUNT(*) FROM ELEV WHERE TUTOR = S.MATR) ORDER BY (SELECT COUNT(*) FROM ELEV WHERE TUTOR = S.MATR) DESC
Se obŃine rezultatul următor:
NUME NUMAR
ADRIAN 1
FLOREA 1
6.4. Operatorul UNION Rezultatele mai multor cereri pot fi combinate prin reuniune de mulŃimi folosind operatorul UNION. Rezultatul va conŃine:
Operator Descriere
UNION
cerere1 UNION cerere2 = o tabelă conŃinând liniile care sunt fie în rezultatul lui cerere1, fie în cel al cerere2, fie în ambele, fără duplicate.
UNION ALL
cerere1 UNION ALL cerere2 = o tabelă conŃinând liniile care sunt fie în rezultatul lui cerere1, fie în cel al cerere2, fie în ambele, cu păstrarea duplicatelor.
Există anumite restricŃii în ceea ce priveşte folosirea acestor operatori şi o serie de caracteristici ale rezultatului obŃinut:
� Ambele cereri întorc acelaşi număr de coloane. � Coloanele corespondente au valori de acelaşi tip sau de tipuri pentru care sistemul poate face
automat conversia. � Operatorii pot fi folosiŃi repetat şi succesiv pentru a forma expresii. În acest caz, dacă nu se
folosesc paranteze pentru a schimba ordinea de evaluare, ei se execută în ordinea în care apar în expresie.
� Capul de tabel al rezultatului este cel dat de prima cerere din expresie. � Cererile implicate în aceste operaŃii nu pot conŃine clauza ORDER BY (se obtine eroarea
1221 - Incorrect usage of UNION and ORDER BY. Aceasta poate să fie pusă doar la sfârşitul expresiei şi poate conŃine nume de coloane din rezultat sau numerele de ordine ale acestora.
Investeşte în oameni!
Pagina 112
Exemplu: Se doreşte obŃinerea următorului rezultat: lista cu numele, codul profilului, locul naşterii şi media pentru elevii care:
� Sunt la profilul cu codul 11 şi au mdia peste 9 sau � Sunt la profilul cu codul 21 şi sunt născuŃi în Bucureşti sau � Sunt la profilul cu codul 24 şi au media peste 8.50 .
Rezultatul trebuie ordonat descrescător după locul naşterii şi crescător după medie.
Cererea se poate scrie şi astfel:
SELECT NUME, CODP, LOC, MEDIA FROM ELEV WHERE CODP = 11 AND MEDIA > 9 UNION SELECT NUME, CODP, LOC, MEDIA FROM ELEV WHERE CODP = 21 AND LOC = 'BUCURESTI' UNION SELECT NUME, CODP, LOC, MEDIA FROM ELEV WHERE CODP = 24 AND MEDIA >8.5 ORDER BY LOC DESC, 4;
Se obŃine rezultatul:
NUME CODP LOC MEDIA
STANCA 21 BUCURESTI 6.86
ELENA 21 BUCURESTI 6.89
GEORGE 11 BUCURESTI 9.95
FLOREA 24 BRASOV 10.00
Varianta UNION ALL a operatorului nu elimină duplicatele. Se pot mixa UNION cu UNION ALL dar regula este că un UNION simplu le face la fel pe toate UNION ALL din stânga sa.
De exemplu, cererea:
SELECT NUME, CODP, LOC, AN, MEDIA FROM ELEV WHERE CODP = 11 AND MEDIA > 9 UNION ALL SELECT NUME, CODP, LOC, AN, MEDIA FROM ELEV WHERE CODP = 11 AND LOC = 'BUCURESTI' UNION ALL SELECT NUME, CODP, LOC, AN, MEDIA FROM ELEV
Investeşte în oameni!
Pagina 113
WHERE CODP = 11 AND AN > 2 ORDER BY LOC DESC, 4;
întoarce un rezultat de 4 linii, în care GEORGE apare de 3 ori (el îndeplineste toate cele 3 criterii din cererile reunite):
NUME CODP LOC AN MEDIA
MARIA 11 PLOIESTI 3 7.58
GEORGE 11 BUCURESTI 4 9.95
GEORGE 11 BUCURESTI 4 9.95
GEORGE 11 BUCURESTI 4 9.95
Dacă doar primul UNION ALL este înlocuit cu UNION rezultatul va conŃine 2 linii cu GEORGE iar dacă doar al doilea UNION ALL e înlocuit cu UNION rezultatul va conŃine o linie cu GEORGE.
Operatorul UNION este folosit în general pentru a combina rezultate obŃinute din cereri care lucrează pe tabele diferite.
Investeşte în oameni!
Pagina 114
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 5 Obiectivele activităŃilor practic-aplicative:
• Scrierea de cereri care utilizează subcereri în expresii logice. • Scrierea de cereri care utilizează subcereri pe clauza FROM. • Scrierea de cereri care utilizează subcereri corelate • Scrierea de cereri care utilizează operatorului UNION
A. 1 – Se vor scrie, executa şi eventual depana cererile SELECT care afişează: a. Toate datele despre profilul unde este înscris cel mai tânar elev b. Numele şi media pentru elevii care au o medie mai mare decât media vreunui profil. c. Numele şi media pentru elevii care au o medie mai mare decât media oricărui profil. d. În plus, se vor executa toate cererile prezente în manual la capitolul 6.1
A. 2 – Se vor executa toate cererile prezente în manual la capitolul 6.2 A. 3 – Se vor scrie, executa şi eventual depana cererile de tip SELECT FROM ORDER BY LIMIT care afişează:
a. Toate datele despre elevii care au cea mai mare vârsta de la profilul lor b. Numele şi media pentru elevii care au o medie mai mare decât media profilului lor. c. Top 3 elevi în ceea ce priveşte media, fără folosirea lui LIMIT d. În plus, se vor executa toate cererile prezente în manual la capitolele 6.3 şi 6.4
Obiectivele temei urmăresc: • Prezentarea tipurilor de date pentru coloane; • Modul de creare a tabelelor. • Utilizarea constrângerilor de integritate • Modul de modificare a structurii tabelelor şi modificarea constrângerilor de integritate • Folosirea coloanelor cu autoincrement pentru generarea cheilor surogat.
7. CREAREA TABELELOR În capitolele anterioare au fost prezentate aspectele referitoare la regăsirea informaŃiilor stocate într-o bază de date MySQL. O astfel de bază de date poate să conŃină pe lângă tabele şi alte tipuri de obiecte: vederi, secvenŃe, indecşi şi sinonime. La nivelul fiecărei tabele pot fi definite reguli de verificare privind valorile care pot fi stocate pe unele dintre coloane numite constrângeri de integritate. Scopul acestui capitol este de a prezenta elementele limbajului pentru descrierea datelor (DDL) referitoare la:
� Tipurile de date permise pentru coloanele tabelelor, � Crearea de noi tabele, � Constrângeri de integritate, � Modificarea structurii unei tabele, � Modificarea şi activarea constrângerilor de integritate,
7.1. Tipuri de date Sistemul MySQL pune la dispoziŃie un set optim de tipuri de date care pot fi asociate coloanelor unei tabele, grupate în mai multe categorii:
� Tipuri numerice scalare
Investeşte în oameni!
Pagina 116
� Tipuri scalare şir de caractere � Tipuri pentru date calendaristice, timp şi interval de timp � Tipuri LOB (large object) � Alte tipuri: ENUM, SET
Continuăm cu prezentarea tipurilor de mai sus. Exista si alte tipuri care nu vor fi prezentate aici, fiind specifice unor clase de aplicaŃii (tipurile spaŃiale, pentru date geometrice).
a. Tipuri numerice scalare
Tip Descriere
BIT [(n)] Stochează o valoare formată din n biŃi (maxim 64). Valorile se pun între apostrofi prefixate cu b. Exemplu: b’100101101’.
TINYINT – 1 byte, SMALLINT – 2 bytes,
MEDIUMINT – 3 bytes,
INT – 4 bytes,
INTEGER – 4 bytes,
BIGINT – 8 bytes
Sintaxa:
TIP [(cifre)] [UNSIGNED] [ZEROFILL]
Numere intregi de diferite dimensiuni. Un bit poate fi sa nu de semn (UNSIGNED – doar numere pozitive) .
ZEROFILL adauga automat UNSIGNED iar numerele sunt ‘umplute’ pana la dimensiunea specificata cu zerouri; ex: 000012 in loc de 12.
FLOAT[(cifre, zecimale)]
DOUBLE[(cifre, zecimale)]
Număr real în virgulă mobilă cu n cifre dintre care z zecimale. Poate fi de asemenea UNSIGNED sau ZEROFILL. Stochează o valoare aproximativă.
DEC[(cifre, zecimale)]
DECIMAL[(cifre, zecimale)]
NUMERIC[(cifre, zecimale)]
Număr real în virgulă fixă cu n cifre dintre care z zecimale. Semnul numarului nu se numara. Poate fi de asemenea UNSIGNED sau ZEROFILL. Se stochează ca şir de caractere (exact).
b. Tipuri şir de caractere
Investeşte în oameni!
Pagina 117
Tip Descriere
CHAR(n) Şir de caractere de lungime fixă, egală cu n. Valoarea maximă pentru n este 255. Dacă n lipseşte, şir de caractere de lungime 1.
VARCHAR(n) Şir de caractere de lungime variabilă egală cu n. Valoarea maximă pentru n este 65535 incepînd cu versiunea 5.0.3 (anterior era de 255).
BINARY(n) Similar cu CHAR dar pentru date binare
VARBINARY(n) Similar cu VARCHAR dar pentru date binare.
c. Tipuri pentru date calendaristice, timp şi interval de timp
Tip Descriere
DATE Dată calendaristică între '1000-01-01' şi '9999-12-31'.
Formatul standard este AAAA-LL-ZZ.
DATETIME Extensie a tipului DATE. ConŃine oră, minut şi secundă. Plaja de valori este între '1000-01-01 00:00:00' şi '9999-12-31 23:59:59' iar formatul standard este AAAA-LL-ZZ HH:MM:SS
TIMESTAMP Extensie a tipului DATE. ConŃine oră, minut şi secundă şi reprezintă numărul de secunde scurse de la 1 ian. 16.80. Plaja de valori este între '16.80-01-01 00:00:00' şi 2038-01-19 03:14:07 ' iar formatul standard este AAAA-LL-ZZ HH:MM:SS
TIME Stochează partea de oră, minut şi secundă în formatul HH:MM:SS pentru valori extinse ale orei cuprinse între -858:59:59 şi 858:59:59.
YEAR(2) sau YEAR(4)
Se stochează un an calendaristic, pe 2 sau 4 cifre.
Pe 4 cifre plaja este de la 1901 la 2155. Pe 2 cifre, valorile mai mici de 70 sunt din secolul 21 iar celelalte din secolul 20.
d. Tipuri LOB (large object)
Aceste tipuri permit stocarea unor cantităŃi mari de date pe coloanele unei tabele.
Investeşte în oameni!
Pagina 118
Caracteristicile lor sunt următoarele:
Tip Descriere
TINYBLOB,
BLOB,
MEDIUMBLOB,
LONGBLOB
Date binare de mari dimensiuni. Diferă prin dimensiunea maximă: 28-1, 216-1, 224-1, 232-1.
TINYTEXT,
TEXT,
MEDIUMTEXT,
LONGTEXT
Siruri de caractere de mari dimensiuni. Dimensiunea maximă corespunde celor 4 tipuri binare de mai sus.
e. Alte tipuri
Pe langă tipurile de mai sus o coloană poate fi de tip SET, ENUM sau un tip spaŃial (pentru date geometrice). Tipurile spaŃiale sunt descries în documentaŃia de produs si nu vor fi prezentate aici.
Tip Descriere
ENUM()
Contine enumerarea a pâna la 65535 de şiruri. O valoare de acest tip este egală cu unul dintre şirurile din enumerare.
SET() ConŃine pâna la 255 de şiruri. O valoare de acest tip este egală cu o combinaŃie – lista, înşiruire – de valori dintre cele din mulŃimea specificată.
7.2. Crearea tabelelor
Cea mai simplă formă a cererii SQL de creare a unei noi tabele are următoarea sintaxă:
� nume_tabela este numele tabelei care se crează, � nume_coloana_1, nume_coloana_2, ... sunt numele coloanelor acesteia, � tip_coloana_1, tip_coloana_2, ... reprezintă tipurile de date pentru coloanele respective,
alese dintre cele prezentate în paragraful anterior, cu specificarea, dacă este cazul, a dimensiunii maxime sau preciziei,
� clauza opŃională DEFAULT expresie_i specifică o valoare implicită care este introdusă automat în acea coloană în cazul în care la adăugarea unei noi linii nu se specifică o valoare pe coloana respectivă,
� TEMPORARY crează o tabelă temporară care este vizibilă doar pe conexiunea pe care a fost creată şi care este ştearsă automat când aceasta se închide. Crearea unei tabele temporare nu comite tranzacŃia curentă. Pe două conexiuni diferite se pot crea în aceeaşi bază de date două tabele temporare cu acelaşi nume. Numele tabelei temporare poare duplica numele unei tabele existente în care caz aceasta din urmă va fi invizibilă pe respectiva conexiune pâna la ştergerea tabelei temporare.
� IF NOT EXISTS crează tabela doar dacă ea nu există. Dacă există deja o tabelă cu acel nume nu se semnalează eroare.
Pentru ca o comandă de creare să se execute cu succes trebuie să fie îndeplinite anumite condiŃii:
� Utilizatorul are drepturile necesare (dreptul sau privilegiul - în terminologia uzuală - de a crea tabele sau tabele temporare).
� Există spaŃiu de stocare pentru noua tabelă. � Numele tabelei şi al coloanelor respectă restricŃiile. � Nu există deja un alt obiect cu acelaşi nume în aceeaşi bază de date – cu excepŃia cazului
TEMPORARY, descris mai sus.
În ceea ce priveste tratarea, în general, a literelor mari şi mici în MySQL avem tabelul de mai jos:
Denumire Tratare litere mari şi mici
Cuvinte cheie, nume funcŃii, nume coloane, nume indecşi, nume proceduri stocate
Literele mari sunt identice cu cele mici
Nume baze de date, nume tabele, nume declanşatori (triggers), aliasuri de tabela
Literele mari sunt identice cu cele mici pe Windows si MacOS şi diferite pe sistemele tip Unix
Expresia din clauza opŃională DEFAULT trebuie să se evalueze la o valoare de tip compatibil cu al coloanei respective. Ea poate conŃine:
� Constante numerice sau şir de caractere, � FuncŃii SQL, inclusiv SYSDATE sau USER.
Investeşte în oameni!
Pagina 120
dar nu poate conŃine:
� Numele unei coloane, � Numele unei pseudocoloane. (de exemplu pseudocoloanele definite de o secvenŃă: NEXTVAL
sau CURRVAL).
Exemplul 1: crearea tabelei de elevi folosită în exemple se poate face cu cererea următoare:
CREATE TABLE IF NOT EXISTS elev( MATR INT(4), NUME VARCHAR(10), AN INT(1) DEFAULT 1, CLASA VARCHAR(6), DATAN DATE, LOC VARCHAR(10) DEFAULT 'BUCURESTI', TUTOR INT(4), MEDIA INT(4) DEFAULT 0, CODP INT(2) );
Se observa că:
� MATR, AN, TUTOR, MEDIA şi CODP care conŃin valori de tip număr întreg au fost definite ca INT(n) unde n este 1, 2 sau 4,
� NUME, CLASA şi LOC sunt şiruri de caractere de lungime variabilă definite ca VARCHAR, � DATAN care conŃine data naşterii elevului este de tipul DATE, � Pentru unele dintre coloane au fost asociate valori implicite care vor fi stocate automat în
acestea dacă la inserarea unei noi linii nu se specifică o valoare, nulă sau nenulă. Valorile implicite sunt compatibile cu tipul coloanelor respective (întreg sau şir de caractere, după caz).
Rezultatul execuŃiei acestei cereri este crearea unei tabele care are structura specificată şi nu conŃine nici o linie. Acestea se pot adăuga ulterior prin cereri INSERT - prezentate în capitolul următor.
Exemplul 2: Crearea unei tabele în care se stochează date despre evenimente: momentul de început, durata şi o descriere a acestora.
CREATE TABLE EVENIMENT( COD INT(10), `MOMENT INCEPUT` TIMESTAMP(3), DURATA TIME, `DESCRIERE (PE LARG)` TEXT);
Coloanele acestei tabele pot conŃine datele următoare:
� COD: un număr întreg de maxim 10 cifre, � MOMENT ÎNCEPUT: conŃine momentul începutului unui eveniment în forma: data, ora,
minutul, Numele coloanei conŃine un spaŃiu şi a trebuit pus între apostrofi inverşi. � DURATA: durata evenimentului în ore, minute şi secunde. � DESCRIERE (PE LARG): conŃine un text de descriere a evenimentului care poate avea până
la 216-1 caractere. Se folosesc apostrofi inverşi pentru că numele coloanei conŃine spaŃii şi paranteze.
Investeşte în oameni!
Pagina 121
În toate cererile SQL care folosesc nume de coloane nonstandard (a fost obligatorie folosirea apostrofilor inverşi la creare) acestea vor fi scrise în cereri în aceeaşi formă.
Crearea unei tabele din rezultatul unui SELECT
Este posibilă crearea unei tabele pe baza rezultatului unei cereri SELECT. În acest caz pe lângă faptul că se crează o nouă tabelă ea nu va fi goală ci va conŃine liniile întoarse de cererea de regăsire respectivă.
Sintaxa cererii SQL pentru această operaŃie este următoarea:
CREATE TABLE [schema.]nume_tabela [(descriere_coloana_1, ..., descriere_coloana_n)] AS cerere_SELECT;
În urma execuŃiei unei astfel de cereri se crează o tabelă având numele specificat şi aceeaşi structură cu a rezultatului returnat de SELECT. În funcŃie de prezenŃa sau absenŃa părŃii de descriere a coloanelor noii tabele distingem două cazuri:
a. Descrierea coloanelor nu este prezentă în cerere:
� Numele coloanelor tabelei create precum şi tipul acestora este identic cu al celor din rezultatul cererii SELECT.
� Noua tabelă nu moşteneşte nici una dintre constrângerile de integritate ale tabelei/tabelelor din care provine rezultatul.
� Dacă în lista de expresii din clauza SELECT există unele care nu returnează pentru capul de tabel al rezultatului un nume valid de coloană este obligatorie folosirea unor aliasuri de coloană.
Exemplu: crearea unei tabele care conŃine numărul matricol, numele şi media mărită cu 10% pentru elevii de la profilul cu codul 11:
CREATE TABLE ELEV11 AS SELECT MATR, NUME, MEDIA*1.1 `MEDIA MARITA` FROM ELEV WHERE CODP = 11;
ConŃinutul tabelei ELEV11 va fi următorul:
MATR NUME MEDIA MARITA
1456 GEORGE 3179.0
1325 VASILE 429.0
1645 MARIA 1540.0
3145 MIHAI 1067.0
iar descrierea structurii sale este:
Investeşte în oameni!
Pagina 122
Field Type Null Key Default Extra
MATR int(4) YES (NULL)
NUME varchar(10) YES (NULL)
MEDIA MARIT decimal(12,1) YES (NULL)
Se observă că ultima coloană nu este de tip INT(4) ci de tip DECIMAL: înmulŃirea unui număr întreg de maxim 4 cifre cu un număr real este un număr real.
Crearea tabelei se face inclusiv în cazul în care cererea SELECT nu returnează nici o linie. De exemplu:
CREATE TABLE ELEV100 AS SELECT MATR, NUME, MEDIA*1.1 `MEDIA MARIT` FROM ELEV WHERE CODP = 100;
va avea ca efect crearea tabelei ELEV100 având aceeaşi structură cu ELEV11 dar aceasta nu va conŃine nici o linie.
b. Cererea conŃine descrierea coloanelor:
Descrierea unei coloane are următoarea formă:
nume_coloana tip [DEFAULT expresie] [constrângeri_integritate]
� Numărul de descrieri de coloană trebuie să fie egal cu numărul de coloane din rezultatul cererii SELECT.
� Numele şi tipul coloanelor tabelei create este cel din descriere. � Dacă descrierea unei coloane conŃine clauza DEFAULT expresie, se asociază acestei
coloane valoarea implicită respectivă. � Noua tabelă nu moşteneşte nici una dintre constrângerile de integritate ale tabelei/tabelelor
din care provine rezultatul dar primeşte constrângerile de integritate din descriere, dacă acestea există
Exemplu: Tabela ELEV11 se poate crea şi astfel:
CREATE TABLE ELEV11 (NUMAR INT DEFAULT 0 NOT NULL, NUME VARCHAR(40), MEDIA DECIMAL(5, 2) NOT NULL) AS SELECT MATR, NUME, MEDIA*1.1 `MEDIA MARIT` FROM ELEV WHERE CODP = 11;
ConŃinutul tabelei este acelaşi, ultima coloană are alt nume, prima are o valoare implicită iar două dintre ele au asociată o constrângere de tip NOT NULL (nu se pot stoca valori nule pe acele coloane):
Investeşte în oameni!
Pagina 123
Field Type Null Key Default Extra
NUMAR int(11) NO 0
MEDIA decimal(5, 2) NO (NULL)
MATR int(4) YES (NULL)
NUME varchar(40) YES (NULL)
MEDIA MARIT decimal(12,1) YES (NULL)
7.3. Constrângeri de integritate
Constrângerile de integritate reprezintă reguli pe care valorile conŃinute într-o tabelă trebuie să le respecte. Ele previn introducerea de date eronate în baza de date şi definesc forma corectă a valorilor respective dar nu iau în consideraŃie semnificaŃia acestora.
Constrângerile de integritate sunt verificate automat de sistemul de gestiune atunci când au loc operaŃii de modificare a conŃinutului tabelelor (adăugare, ştergere şi modificare linii). În cazul în care noile valori nu sunt valide operaŃia de modificare este rejectată de sistem şi se generează o eroare. În orice sistem de gestiune profesional sistemul există cinci tipuri de constrângeri:
� NOT NULL: valorile nu pot fi nule � PRIMARY KEY: defineşte cheia primară a unei tabele � UNIQUE: defineşte o altă cheie a tabelei � FOREIGN KEY: defineşte o cheie străină (externă) � CHECK: introduce o condiŃie (expresie logică).
SemnificaŃia unora dintre termenii de mai sus este prezentată în paragrafele următoare.
Unele constrângeri de integritate poate avea asociat un nume specificat la crearea tabelei care permite activarea sau dezactivarea constrângerii şi alte operaŃii cu aceasta. Locul definirii unei constrângeri de integritate în cererea de creare a unei tabele poate fi:
� În descrierea unei coloane, dacă acea constrângere se referă doar la aceasta (uzual se spune despre o astfel de constrângere că este definită la nivel de coloană),
� În continuarea listei de descrieri de coloane (la nivel de tabelă). În funcŃie de locul unde se găseşte, sintaxa definirii unei constrângeri poate fi diferită. Pentru fiecare tip de constrângere în paragrafele următoare sunt prezentate ambele sintaxe şi exemple de folosire a lor. a. Constrângerea NOT NULL Acest tip de constrângere se aplică unei coloane a noii tabele şi specifică faptul că aceasta nu poate conŃine valori nule. El poate fi definit doar la nivel de coloană şi are următoarea sintaxă:
descriere_coloana NOT NULL
Exemplu: în cazul cererii de creare a tabelei PROFIL se poate cere ca numele profilurilor şi filiera din care fac parte să nu conŃină valori nenule. Pentru coloana NUME constrângerea are un nume definit la creare iar cea asociată coloanei FILIERA va primi un nume dat de sistem:
Investeşte în oameni!
Pagina 124
CREATE TABLE PROFIL (CODP INT(2), NUME VARCHAR(10) NOT NULL, FILIERA VARCHAR(15) NOT NULL);
b. Chei, chei primare şi chei străine Cnstrângerile de integritate PRIMARY KEY, UNIQUE şi FOREIGN KEY sunt legate de un concept extrem de important şi anume cel de cheie a unei tabele. În terminologia relaŃională, o mulŃime de coloane este cheie într-o tabelă dacă ea satisface următoarele cerinŃe:
� Nu pot exista două linii în tabelă care să aibă aceleaşi valori pe coloanele respective. O altă formulare pentru această condiŃie este următoarea: valorile coloanelor respective identifică în mod unic o linie a tabelei.
� MulŃimea este minimală: înlăturând oricare coloană/coloane din mulŃime, ea nu mai satisface condiŃia anterioară.
O tabelă poate avea mai multe chei. În cazul unei tabele cu structura:
în care sunt înregistrate date despre elevi se poate observa existenŃa a trei mulŃimi de coloane care au proprietăŃile de mai sus:
� {matricola} - reprezintă un număr care identifică în mod unic un elev şi este de asemenea o mulŃime minimală (ca oricare mulŃime formată dintr-o singură coloană).
� {CNP} - codul numeric personal este unic la nivel naŃional şi deci cu atât mai mult în tabela de elevi
� {serie_CI, număr_CI} - seria şi numărul cărŃii de identitate: la fel ca în cazul CNP nu pot exista doi cetăŃeni români (deci cu atât mai mult doi elevi români) cu aceleaşi valori pe aceste coloane. Această mulŃime este de asemenea minimală, doar seria sau doar numărul cărŃii de identitate putând fi aceleaşi pentru doi elevi, dar nu ambele.
În majoritatea sistemelor de gestiune relaŃionale la definirea structurii unei tabele se poate specifica, prin constrângerea de integritate PRIMARY KEY, o singură cheie primară, aleasă dintre posibilele chei ale acesteia. Pentru celelalte chei (dacă există) se poate folosi constrângerea UNIQUE. Alegerea cheii primare se face în funcŃie de specificul aplicaŃiei respective: în cazul tabelei de mai sus, dacă este folosită într-o aplicaŃie a universităŃii se poate opta pentru matricolă. În cazul în care tabela aparŃine unei aplicaŃii de evidenŃa populaŃiei se poate opta pentru CNP sau pentru {serie_CI, număr_CI}. Valorile aflate pe cheia unei tabele pot fi regăsite şi în alte tabele pe coloanele de legătură - folosite pentru operaŃia de join: în cazul bazei de date pentru exemple, dacă tabela PROFIL are cheia primară CODP, valorile acesteia se regăsesc şi pe coloana CODP din ELEV. Această coloană este în acest caz cheie străină (externă) deoarece nu este cheie în tabela respectivă dar conŃine valori care se regăsesc pe cheia primară sau unică a unei alte tabele. Constrângerea prin care se specifică această proprietate este FOREIGN KEY.
Investeşte în oameni!
Pagina 125
c. Constrângerea PRIMARY KEY Aşa cum s-a menŃionat, o tabelă poate avea o singură cheie primară. Dacă aceasta este formată dintr-o singură coloană, ea poate fi definită atât la nivel de coloană cât şi la nivel de tabelă. Dacă este formată din mai multe coloane definirea cheii primare se poate face doar la nivel de tabelă. Sintaxa în cele două cazuri este următoarea:
Pentru baza de date pentru exemple, să considerăm următoarele cereri de creare a tabelelor PROFIL şi REZULTAT: Tabela PROFIL are o cheie primară formată dintr-o singură coloană - CODP. În acest caz aceasta poate fi specificată fie pe linia de descriere a coloanei respective, fie după lista de descrieri de coloane, ca în continuare:
Se obŃine o tabelă având structura descrisă în tabelul urmator:
Field Type Null Key Default Extra
MMIN int(4) NO PRI 0
MMAX int(4) NO PRI 0
Investeşte în oameni!
Pagina 126
TIP varchar(20) YES (NULL)
REZ varchar (2) YES (NULL)
În cazul specificării unei constrângeri de acest tip, MySQL are următoarea comportare:
� Crează automat o structură de căutare rapidă pentru valorile cheii - index. În acest fel o parte a cererilor în care e implicată cheia primară vor avea o viteză mai mare în calculul rezultatului.
� Pentru coloanele cheii primare nu sunt acceptate valori nule. � Asocierea unui nume pentru acest tip de constrângere se poate face doar în cazul sintaxei la
nivel de tabelă dar nu este obligatorie. � Constrângerile de tip FOREIGN KEY se pot defini doar ulterior celor de PRIMARY KEY cu
care sunt asociate. d. Constrângerea UNIQUE În cazul în care tabela are mai multe chei, datorită restricŃiei care spune că doar una dintre ele poate fi aleasă cheie primară, celelalte pot fi specificate cu constrângeri de tip UNIQUE. Acestea pot fi atât la nivel de coloană (când cheia este formată dintr-o singură coloană) cât şi la nivel de tabelă (în toate cazurile). Sintaxa este:
� Crează automat o structură de căutare rapidă pentru valorile cheii - index. În acest fel o parte a cererilor în care e implicată cheia definită cu UNIQUE vor avea o viteză mai mare în calculul rezultatului.
� Spre deosebire de constrângerea anterioară pentru coloanele definite cu UNIQUE sunt permise valori nule. În acest caz, dacă există şi valori nenule pentru coloanele cheii doar acestea sunt luate în considerare pentru verificarea unicităŃii.
Exemplul 1: Dacă în tabela de PROFIL nu pot exista niciodată două profiluri cu acelaşi nume, definiŃia anterioară se completează cu o constrângere de tip UNIQUE:
În acest caz în tabelă nu pot exista două linii care conŃin aceeaşi valoare nenulă pe coloana REZ dar pot exista oricâte linii cu valori nule pe această coloană. În cazul în care o cheie definită cu UNIQUE conŃine mai multe coloane, verificarea se face astfel:
� nu există două linii care au aceleaşi valori nenule pentru toate coloanele cheii. � nu există două linii care au aceleaşi valori nenule pentru unele coloane ale cheii şi valori nule
în rest.
Exemplu: În cazul unei tabele NUMERE creată cu cererea:
următorul conŃinut este valid (valorile nule au fost simbolizate prin NULL):
NUMAR1 NUMAR2
(NULL) (NULL)
(NULL) 2000
1000 (NULL)
1000 2000
1000 3000
dar nu poate exista, în plus faŃă de cele de mai sus, nici una din liniile următoare (eroarea este 1062 Duplicat entry):
NUMAR1 NUMAR2
1000 2000
1000 3000
În schimb pot exista oricâte linii care conŃin cel putin o valoare nulă, ca de exemplu:
NUMAR1 NUMAR2
(NULL) 2000
1000 (NULL)
Investeşte în oameni!
Pagina 128
e. Constrângerea FOREIGN KEY Această constrângere poate exista doar daca la crearea tabelei s-a ales motorul de stocare InnoDB. Prin această constrângere valorile unei coloane/unor coloane sunt forŃate să fie doar dintre cele ale cheii unei tabele (cheie primară sau UNIQUE). Coloanele constrânse în acest fel formează ceea ce se numeşte în terminologia de specialitate o cheie straina sau cheie externa iar constrângerea mai este denumită şi de integritate referentiala. Sintaxa la nivel de linie şi de tabelă este următoarea:
� La nivel de coloană:
coloana REFERENCES tabela(coloana) [ON DELETE RESTRICT | CASCADE | SET NULL | NO ACTION ] [ON UPDATE RESTRICT | CASCADE | SET NULL | NO ACTION ]
� La nivel de tabelă:
[,CONSTRAINT nume_constrangere] FOREIGN KEY(lista_coloane) REFERENCES tabela(lista_coloane) [ON DELETE RESTRICT | CASCADE | SET NULL | NO ACTION ] [ON UPDATE RESTRICT | CASCADE | SET NULL | NO ACTION ]
În cazul tabelei ELEV avem două coloane care pot avea asociată o astfel de constrângere:
� Coloana CODP poate fi constrânsă să conŃină doar valori ale cheii primare a tabelei PROFIL (formată din CODP).
� Coloana TUTOR poate fi constrânsă să conŃină doar valori nenule ale cheii primare a lui ELEV - MATR.
În acest caz cererile de creare ale tabelelor ELEV si PROFIL devin: CREATE TABLE IF NOT EXISTS spec ( CODP INT(2) DEFAULT NULL, NUME VARCHAR(10) COLLATE utf8_romanian_ci DEFAULT NULL, FILIERA VARCHAR(15) COLLATE utf8_romanian_ci DEFAULT NULL, CONSTRAINT PROFIL_PK PRIMARY KEY(CODP) ) ENGINE=INNODB;
CREATE TABLE IF NOT EXISTS elev ( MATR INT(4) DEFAULT NULL, NUME VARCHAR(10) COLLATE utf8_romanian_ci DEFAULT NULL, AN INT(1) DEFAULT NULL, CLASA VARCHAR(6) COLLATE utf8_romanian_ci DEFAULT NULL, DATAN DATE DEFAULT NULL, LOC VARCHAR(10) COLLATE utf8_romanian_ci DEFAULT NULL, TUTOR INT(4) DEFAULT NULL, MEDIA INT(4) DEFAULT NULL, CODP INT(2) DEFAULT NULL, CONSTRAINT ELEV_CODP_FK FOREIGN KEY(CODP)
Investeşte în oameni!
Pagina 129
REFERENCES PROFIL(CODP) ) ENGINE=INNODB;
ObservaŃii:
� Clauza COLLATE adăugată la definirea coloanelor de tip sir de caractere descrie setul de caractere folosit (în cazul de faŃă setul UTF8_ROMANIAN care permite caracterele românesti)
� În cazul în care tabela PROFIL nu există încă sistemul va semnala eroarea: � Error Code : 1005 � Can't create table 'elevi.elev' (errno: 150) � Aceeaşi eroare este semnatată în cazul în care tabela PROFIL există dar nu are cheia CODP. � După crearea lui ELEV, dacă se încearcă ştergerea tabelei PROFIL se semnalează eroarea:
Error Code : 1217 Cannot delete or update a parent row: a foreign key constraint fails
� La încercarea de a şterge linii din tabelele PROFIL, dacă acestea au valoari ale chei referite în ELEV prin constrângerea de mai sus se va semnala eroare.
� La încercarea de a modifica valorile cheii în linii din tabelele, dacă acestea sunt referite în ELEV se va semnala eroare.
Clauzele ON DELETE şi ON UPDATE În cazul în care se doreşte ca o linie dintr-o tabelă conŃinând o valoare de cheie referită într-o altă tabelă (sau în aceeaşi tabelă) să poată fi ştearsă/actualizată fără a se obŃine un mesaj de eroare, la definirea constrângerii se poate specifica modul în care se tratează această ştergere/actualizare din perspectiva tabelei care referă valoarea:
� Daca se doreşte ca la ştergerea/actualizarea liniei conŃinând o valoare de cheie să fie şterse/actualizate suplimentar şi toate liniile care referă această valoare, se specifică ON DELETE CASCADE, respectiv ON UPDATE CASCADE
� Dacă se doreşte ca liniile care referă valoarea cheii respective să nu fie şterse/actualizate, se specifică ON DELETE SET NULL, respectiv ON UPDATE SET NULL care are următorul efect: în toate liniile care referă acea valoare ea este înlocuită cu valori nule.
Exemplu: dacă cererea de creare anterioară se modifică astfel:
Atunci la ştergerea unei profiluri din tabela PROFIL vor fi şterşi automat şi toŃi elevii din tabela ELEV având pe coloana CODP codul acesteia. De asemenea, în cazul schimbării codului unei profiluri în PROFIL el este modificat automat şi în ELEV. În cazul în care constrângerea se defineşte pentru o cheie de tip UNIQUE (care poate conŃine şi valori nule) ea este verificată pentru cheile străine formate doar din valori nenule.
Investeşte în oameni!
Pagina 130
f. Constrângerea CHECK Prin acest tip de constrângeri valorile aflate pe o linie a tabelei sunt forŃate să verifice o condiŃie (expresie logică). Aceasta poate conŃine toate elementele prezentate în paragraful 2.2, inclusiv apeluri de funcŃii, cu câteva excepŃii (apelurile unor funcŃii ca SYSDATE, USER, UID sau referinŃa la pseudocoloanele NEXTVAL, CURRVAL (specifice secvenŃelor), LEVEL şi ROWNUM) sau subcereri. O aceeaşi coloană poate participa la mai multe constrângeri de acest tip, având fiecare o altă condiŃie asociată. CondiŃia se evaluează doar la nivelul liniei respective, fără a se putea lua în considerare valori aflate pe alte linii ale tabelei.
Constrângerea se poate defini atât la nivel de linie cât şi la nivel de tabelă astfel:
� La nivel de coloană:
coloana CHECK (expresie_logica)
� La nivel de tabelă:
[,CONSTRAINT nume_constrangere] CHECK (expresie_logica) Exemplu: Tabela REZULTAT poate avea asociate mai multe constrângeri care verifică următoarele condiŃii:
� MMIN şi MMAX sunt pozitive � MMIN < MMAX � REZ este între 0 şi 500
În cazul în care pe coloanele respective se găsesc valori nule, linia nu este rejectată ci se consideră că verifică expresia logică. Pentru tabela REZULTAT definită ca mai sus se pot introduce linii având valori nule pentru unele din coloanele MMIN, MMAX şi REZ fără a se semnala violarea constrângerilor de integritate de tip CHECK. Expresia logică asociată unei constrângeri CHECK poate fi compusă: cererea de creare de mai sus poate fi rescrisă prin combinarea tuturor condiŃiilor în una singură:
CREATE TABLE REZULTAT( MMIN INT(4), MMAX INT(4), TIP VARCHAR(20), REZ INT(4), CONSTRAINT REZULTAT_CK CHECK (MMIN < MMAX AND MMIN >= 0 AND MMAX >= 0 AND REZ BETWEEN 0 AND 500));
Investeşte în oameni!
Pagina 131
7.4. Modificarea structurii tabelelor şi a constrângerilor de integritate În continuare sunt prezentate pe scurt modul de efectuare operaŃiilor de modificare a structurii unei tabele, ştergerea şi golirea sa. Adăugarea unei noi coloane
Sintaxa pentru adaugarea unei singure coloane:
ALTER TABLE nume_tabela ADD [COLUMN] nume_coloana descriere coloana [FIRST | AFTER nume_coloana];
Exemplu: Adăugarea unei noi coloane la tabela PROFIL în care se memorează anul înfiinŃării fiecărei profiluri:
ALTER TABLE PROFIL ADD COLUMN AN_INFIINTARE INT(4) NOT NULL AFTER NUME;
Noua structură va fi:
Field Type Null Key Default Extra
CODP int(2) YES (NULL)
NUME varchar(10) YES (NULL)
AN_INFIINTARE int(4) NO (NULL)
FILIERA varchar(15) YES (NULL)
Adăugarea unei coloane care are asociată o constrângere de tip NOT NULL (ca în exemplul anterior) se poate face şi în cazul în care tabela conŃine date dar în acest caz sistemul va completa coloana cu valori implicite (de exemplu în cazul de mai sus cu 0).
Când adaugăm mai multe coloane, acestea se va adăuga întotdeauna după celelalte, devenind ultimele din tabelă. Exemplu:
ALTER TABLE PROFIL ADD COLUMN (ADRESA VARCHAR(100) NOT NULL, NR_ELEVI INT(6) NOT NULL);
Vizualizarea structurii unei tabele
Sintaxa comenzii este:
DESCRIBE nume_tabela
Investeşte în oameni!
Pagina 132
Exemplu. Pentru tabela PROFIL modificată ca mai sus prin adăugarea celor 3 coloane obŃinem:
Field Type Null Key Default Extra
CODP int(2) YES (NULL)
NUME varchar(10) YES (NULL)
AN_INFIINTARE int(4) NO (NULL)
FILIERA varchar(15) YES (NULL)
ADRESA varchar(100) NO (NULL)
NR_ELEVI int(6) NO (NULL)
Ştergerea unei coloane
Sintaxa:
ALTER TABLE nume_tabela DROP COLUMN nume_coloana
Exemplu: Ştergerea coloanei adăugată anterior:
ALTER TABLE PROFIL DROP COLUMN AN_INFIINTARE;
ObservaŃii:
� Cererea se poate executa atât în cazul în care tabela este goală cât şi dacă ea conŃine deja linii,
� Dacă tabela are doar o singură coloană, aceasta nu se poate şterge,
Modificarea unei coloane
Sintaxa:
ALTER TABLE nume_tabela ALTER [COLUMN] nume_col {SET DEFAULT literal | DROP DEFAULT} | CHANGE [COLUMN] nume_col_vechi nume_col_nou descriere_col [FIRST|AFTER nume_col] | MODIFY [COLUMN] nume_col descriere_col [FIRST | AFTER nume_col]
Prin această cerere se pot modifica următoarele caracteristici ale unei coloane:
� Se poate schimba valoarea implicită a unei coloane - ALTER COLUMN � Se poate schimba numele coloanei – CHANGE - si descrierea sa (tip, dimensiune) –
CHANGE, MODIFY � Se poate muta coloana pe altă poziŃie.
Investeşte în oameni!
Pagina 133
În cazul schimbării valorii implicite pentru o coloană, noua valoare va fi folosită doar pentru inserările de linii ulterioare modificării. Exemplul urmator functioneaza în cazul în care pe coloana NR_ELEVI nu exista valori nenule duplicate:
ALTER TABLE PROFIL CHANGE NR_ELEVI NR_ELEV INT(10) UNIQUE
Tipul constrângerii nu poate fi NOT NULL. În schimb se pot defini constrângeri de tip CHECK conŃinând condiŃii de acest tip.
Exemple:
ALTER TABLE PROFIL ADD CONSTRAINT NUME_NENUL CHECK(NUME IS NOT NULL); ALTER TABLE PROFIL ADD CONSTRAINT NUME_5 CHECK(LENGTH(NUME)>5); ALTER TABLE PROFIL ADD CONSTRAINT PROFIL_PK PRIMARY KEY(CODP); ALTER TABLE PROFIL ADD CONSTRAINT NUME_UNIC UNIQUE(NUME); ALTER TABLE PROFIL ADD CONSTRAINT NUME_5 CHECK(LENGTH(NUME)>5); ALTER TABLE ELEV ADD CONSTRAINT elev_FK FOREIGN KEY (cods) REFERENCES PROFIL(cods)
Ştergerea unei constrângeri
Sintaxa:
ALTER TABLE nume_tabela DROP PRIMARY KEY; ALTER TABLE nume_tabela DROP INDEX nume_unq; ALTER TABLE nume_tabela DROP FOREIGN KEY nume_fk
Investeşte în oameni!
Pagina 134
Efectul acestor cereri este:
� DROP PRIMARY KEY specifică ştergerea constrângerii de tip cheie primară pentru tabela respectivă. Constrângerea poate să nu aibă un nume asociat la definire.
� DROP INDEX specifică inclusiv ştergerea unei constrângeri UNIQUE. � DROP FOREIGN KEY ajută la ştergerea constrângerilor de tip cheie străină/externă.
Exemplu: ştergerea cheii primare a tabelei PROFIL şi a constrângerilor dependente de acestea (de exemplu cea de cheie străină din ELEV) se face astfel:
ALTER TABLE PROFIL DROP PRIMARY KEY; Golirea unei tabele
Sintaxa:
TRUNCATE TABLE nume_tabela;
Exemplu: golirea tabelei PROFIL se poate face prin cererea SQL
TRUNCATE TABLE PROFIL; Ştergerea unei tabele
Sintaxa:
DROP TABLE nume_tabela;
Exemplu: ştergerea tabelei PROFIL se poate face prin cererea SQL
DROP TABLE PROFIL;
ObservaŃie: ştergerea unei tabele este definitivă. O dată ştearsă ea poate fi restaurată doar din salvările bazei de date efectuate de administrator. Redenumirea unei tabele
Sintaxa:
ALTER TABLE nume_vechi RENAME TO nume_nou
Exemplu: redenumirea tabelei PROFIL se poate face prin cererea SQL
ALTER TABLE PROFIL RENAME TO PROFILURI;
7.5. Coloane definite cu AUTO_INCREMENT De multe ori este nevoie ca o tabelă să aibă ca şi cheie primară o aşa numită cheie surogat. Aceasta este numerică, nu are semnificaŃie, este generată de sistem şi este vizibilă utilizatorilor tabelei.
Investeşte în oameni!
Pagina 135
Există mai multe posibilităŃi de a genera valorile unei astfel de chei surogat. În MySQL s-a ales varianta de a putea asocia unei coloane cu valori de tip număr întreg atributul AUTO_INCREMENT. În acest caz, la adăugarea unei noi linii, dacă nu se specifică valoarea pentru acea coloană (sau se specifică NULL sau 0) sistemul generează o valoare cu o unitate mai mare decât ultima generată. Prima valoare generată este întotdeauna 1. ObservaŃie: Poate exista doar o singură coloană cu AUTO_INCREMENT într-o tabelă şi ea trebuie sa fie cheia primară a acesteia.
Exemplu:
CREATE TABLE TEST( ID INT(3) PRIMARY KEY AUTO_INCREMENT, NUME VARCHAR(10));
Daca executam:
INSERT INTO TEST VALUES (0, 'VASILE'), (-3, 'ELENA'), (NULL, 'IOANA');
Obtinem continutul urmator:
ID NUME
1 VASILE
-3 ELENA
2 IOANA
Investeşte în oameni!
Pagina 136
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 6 Obiectivele activităŃilor practic-aplicative:
• Exersarea comenzilor de creare a tabelelor. • Utilizarea constrângerilor de integritate • Exemplificarea cererilor de modificare a structurii tabelelor şi modificarea constrângerilor de
integritate • Folosirea coloanelor cu autoincrement la crearea tabelelor
A. 1 – Sa se scrie cererile SQL care crează următoarele tabele: a. O tabelă ELEV1 goală care să aibă aceeaşi structură cu tabela ELEV. b. O tabelă PROFIL1 goală care să aibă aceeaşi structură cu tabela PROFIL. c. O tabelă REZULTAT1 goală care să aibă aceeaşi structură cu tabela REZULTAT. d. O tabelă PERSOANE goală avand coloane care conŃin: numele, prenumele, data naşterii,
codul numeric personal. e. O tabelă ELEV21 care conŃine primele 4 coloane din tabela ELEV si liniile corespunzătoare
elevilor de la profilul 21. f. În plus, se vor executa toate cererile prezente în manual la capitolul 7.2.
A. 2 – Sa se scrie cererile SQL care crează următoarele tabele: a. tabelă ELEV2 care să aibă aceeaşi structură cu tabela ELEV în care matricola este o coloană
cu autoincrement. b. tabelă ELEV3 care să aibă aceeaşi structură cu tabela ELEV, MATR este cheie primară,
CODP este cheie străină iar TUTOR este o coloană care conŃine valori fără duplicate (unice) c. tabelă ELEV4 care să aibă aceeaşi structură cu tabela ELEV în care anul de studii are o
constrângere de tip 1 <= AN <=4. d. În plus, se vor executa toate cererile prezente în manual la capitolul 7.3.
A. 3 - Să se scrie cererile SQL care modifică structura următoarelor tabele: a. În tabela ELEV1 să se adauge o coloană PRENUME. b. În tabela ELEV1 să se redimensioneze coloana NUME. c. În tabela ELEV2 să se adauge constrângerea 1 <= AN <=4. d. În plus, se vor executa toate cererile prezente în manual la capitolul 7.4 şi 7.5.
TEMA 7 Actualizarea continutului tabelelor din baza de date. Utilizarea vederilor
Obiectivele temei urmăresc: • Utilizarea cererilor de tip INSERT pentru adaugarea liniilor. • Utilizarea cererilor de tip DELETE pentru stergerea liniilor. • Utilizarea cererilor de tip UPDATE pentru modificarea continutului tabelelor. • Crearea si utilizarea vederilor pentru consultarea datelor • Actualizarea bazei de date prin intermediul vederilor
8. ACTUALIZAREA DATELOR Scopul acestui capitol este descrierea operaŃiilor care fac parte din limbajul de manipulare al datelor: adăugarea de linii într-o tabelă, modificarea valorilor unor linii şi ştergerea acestora. Este de asemenea prezentat mecanismul tranzacŃiilor şi consistenŃa la citire care permit utilizatorilor şi aplicaŃiilor care accesează o bază de date să utilizeze o versiune consistentă a acesteia. Principalele cereri SQL prin care sunt efectuate aceste operaŃii sunt:
� INSERT efectuează adăugarea de noi linii, � UPDATE permite actualizarea (modificarea) valorilor dintr-o tabelă, � DELETE şterge linii dintr-o tabelă,
8.1. Inserarea liniilor Inserarea de linii într-o tabelă se poate face prin cererile INSERT şi MERGE. În acest paragraf este prezentată prima dintre acestea, în cele două forme ale sale:
� Inserarea unei linii prin specificarea valorilor sale, � Inserarea tuturor liniilor care formează rezultatul unei cereri SELECT.
Inserarea unei linii prin specificarea valorilor acesteia
Investeşte în oameni!
Pagina 138
Sintaxa cererii este următoarea:
INSERT [IGNORE] INTO tabela [(lista_de_coloane)] VALUES (lista_de_valori_1), (lista_de_valori_1), … [ ON DUPLICATE KEY UPDATE coloana=expr, ... ]
În cazul în care lista de coloane nu este prezentă în cerere efectul va fi următorul:
� Se inserează în tabelă o linie completă, � Numărul valorilor din listă trebuie să fie acelaşi cu numărul de coloane din tabelă, � Ordinea valorilor din listă trebuie să fie aceeaşi cu ordinea coloanelor din cererea de creare a
tabelei, � Tipul valorilor trebuie să fie compatibil cu tipul coloanelor în care se stochează, � În cazul în care pe o anumită coloană se doreşte inserarea unei valori nule, în lista de valori
se foloseşte cuvântul cheie NULL, � Dacă la crearea tabelei unei coloane i-a fost asociată o valoare implicită, pentru inserarea ei
se foloseşte cuvântul cheie DEFAULT. În cazul în care se foloseşte DEFAULT dar coloana nu are o valoare implicită definită, în coloană se va insera o valoare nulă,
� Valorile pentru coloanele de tip şir de caractere sau dată calendaristică (doar cele în formatul standard) se pun între apostrofi,
� În cazul în care o valoare de tip dată calendaristică nu este în format standard se folosesc funcŃii de conversie pentru conversia şirului respectiv în dată calendaristică,
� O cerere poate insera una sau mai multe linii. � IGNORE face ca liniile care duplică o cheie să fie ignorate � ON DUPLICATE KEY UPDATE face ca în cazul în care o linie duplică o cheie existentă în loc
de inserare să se execute o actualizare a respectivei linii.
Exemplu: Inserarea profilurilor în tabela PROFIL se face cu cererile:
Pentru inserarea unei noi profiluri având codul 30, nume încă necunoscut şi o filieră implicită se poate folosi cererea:
INSERT INTO PROFIL VALUES(30, NULL, DEFAULT);
Rezultatul celor patru inserări va fi următorul (am considerat că la crearea tabelei PROFIL, pentru coloana FILIERA s-a asociat valoarea implicită 'TEORETICĂ'):
CODP NUME FILIERA
11 REAL TEORETICĂ
21 UMANIST TEORETICĂ
24 RESURSE NATURALE TEHNOLOGICĂ
30 (NULL) TEORETICĂ
Investeşte în oameni!
Pagina 139
În cazul în care cererea conŃine şi o listă de coloane, rezultatul acesteia este inserarea unei linii incomplete: pentru coloanele care lipsesc din listă se vor insera automat valorile implicite - dacă există - sau valori nule în caz contrar. ObservaŃii:
� Listele de coloane şi valori trebuie să conŃină acelaşi număr de elemente, � Cele două liste se corespund poziŃional: prima valoare va fi stocată în prima coloană din listă,
s.a.m.d. � Tipul valorilor trebuie să fie compatibil cu tipul coloanelor în care se stochează.
Exemplu: inserarea profilului cu codul 30 se putea face şi astfel:
INSERT INTO PROFIL (CODP) VALUES(30);
rezultatul obŃinut fiind acelaşi ca mai sus. În toate cazurile, inserarea va eşua dacă noua linie nu respectă vreuna din constrângerile de integritate care sunt active în acel moment pentru tabela în care se face adăugarea.
În lista de valori se mai pot folosi:
Expresii: în acest caz valoarea expresiei trebuie să fie compatibilă cu tipul coloanei. Expresiile pot conŃine operatori şi funcŃii.
Exemplu: următoarea cerere de inserare este validă:
Valorile inserate vor fi: 1215 , 'ION DOBRE', data curentă şi 24.
Subcereri: rezultatul unei subcereri care întoarce o singură valoare poate fi folosit în lista de valori a cererii INSERT. RestricŃia este ca aceeaşi tabelă să nu fie prezentă şi în insert şi în subcerere.
Exemplu: cererea:
INSERT INTO PROFIL(CODP) VALUES ((SELECT MAX(CODP) FROM PROFIL) + 1);
va genera o eroare. În schimb cererea:
INSERT INTO PROFIL(CODP) VALUES ((SELECT MAX(CODP) FROM ELEV) + 1);
Va insera o profil având codul 25 (în cazul în care valoarea maximă pe coloana CODP este 24).
Modul de execuŃie al acestei cereri este următorul:
Investeşte în oameni!
Pagina 140
� Se execută cererea SELECT, � Liniile rezultatului sunt inserate în tabelă, � Numărul de coloane al tabelei/listei de coloane trebuie să fie egal cu cel al rezultatului cererii
SELECT iar tipurile trebuie să fie compatibile, � IGNORE face ca liniile care duplică o cheie să fie ignorate � ON DUPLICATE KEY UPDATE face ca în cazul în care o linie duplică o cheie existentă în loc
de inserare să se execute o actualizare a respectivei linii.
Exemplu: în cazul în care există o tabelă NRELEVI(CODP, NRELEVI) care conŃine pentru fiecare profil numărul de elevi al acesteia, umplerea ei se poate face prin cererea:
INSERT INTO NRELEVI SELECT CODP, COUNT(*) FROM ELEV GROUP BY CODP;
ConŃinutul tabelei NRELEVI va fi:
CODP NRELEVI
11 4
21 4
24 4
Dacă CODP este cheie primară sau unică, rularea următoarei cereri după cea de mai sus va avea ca efect actualicarea celor 3 linii:
INSERT INTO NRELEVI SELECT CODP, COUNT(*) FROM ELEV GROUP BY CODP ON DUPLICATE KEY UPDATE NRELEVI = NRELEVI + CODP;
ConŃinutul lui NRELEVI devine:
CODP NRELEVI
11 15
21 25
24 28
8.2. Ştergerea liniilor
Sintaxa cererii care efectuează ştergerea unor linii dintr-o tabelă este următoarea:
DELETE [IGNORE] FROM nume_tabela [WHERE conditie] [ORDER BY ...] [LIMIT numar_linii]
În clauza WHERE pot să apară aceleaşi elemente ca şi în cazul cererilor SELECT, inclusiv subcereri dar cu restricŃia că acestea nu conŃin în FROM numele tabelei din care se şterg linii. Efectul cererii
Investeşte în oameni!
Pagina 141
este ştergerea tuturor liniilor pentru care condiŃia este verificată. În cazul absenŃei clauzei WHERE se şterg toate liniile tabelei.
IGNORE face ca toate erorile de rulare care apar în cursul execuŃiei ştergerii sa fie tratate doar ca avertismente: liniile nu sunt şterse şi cererea merge mai departe.
LIMIT stabileşte numărul maxim de linii care vor fi afectate: operaŃia se opreşte după ştergerea acestui număr de linii chiar dacă sunt mai multe care îndeplinesc condiŃia.
Exemplul 1: dacă se doreşte ştergerea tuturor elevilor profilului cu codul 11 cererea este:
DELETE FROM ELEV WHERE CODP = 11;
Exemplul 2: ştergerea liniilor corespunzătoare a 2 elevi elevilor cu cele mai mici medii se face cu cererea:
DELETE FROM ELEV ORDER BY MEDIA LIMIT 2
ObservaŃii:
� Cum valorile nule sunt considerate mai mici decât orice altă valoare, cererea de mai sus şterge inclusiv elevi avâns media nulă.
� În MySQL exista şi o altă sintaxă a cererilor DELETE prin care se pot sterge linii din mai multe tabele prin aceeaşi cerere.
8.3. Actualizarea liniilor
Sintaxa cererii de actualizare (modificare) a valorilor dintr-o tabelă este:
UPDATE [IGNORE] tabela SET col1={expr1|DEFAULT} [,col2={expr2|DEFAULT}] ... [WHERE where_condition] [ORDER BY ...] [LIMIT row_count]
Efectul este următorul:
� În WHERE pot să apară aceleaşi elemente ca şi în cazul cererilor SELECT. Pentru subcereri, aceeasi observatie ca mai sus: tabela actualizată nu poate să apară în subcerere.
� Toate liniile care îndeplinesc condiŃia din WHERE vor fi actualizate conform cu specificaŃiile din SET. În cazul absenŃei clauzei WHERE, toate liniile tabelei vor fi actualizate,
� Expresiile din clauza SET se evaluează pornind de la valorile conŃinute în linia care se modifică şi ele trebuie să aibă un tip compatibil cu al coloanelor asociate,
� O aceeaşi coloană nu poate apare de două ori în clauza SET.
Exemplul 1: Mărirea cu 10% a mediei elevilor de la profilul cu codul 11 se face cu cererea:
UPDATE ELEV SET MEDIA = MEDIA * 1.1 WHERE CODP = 11
Investeşte în oameni!
Pagina 142
Exemplul 2: În cazul în care, pentru toŃi elevii, pe lângă mărirea mediei cu 10% se doreşte şi incrementarea anului de studii pentru elevii din anii 1-3 şi stocarea pe coloana AN a valorii 0 pentru elevii de anul 4, cererea este mai jos. S-a folosit o expresie CASE pentru actualizarea anului de studii:
UPDATE ELEV SET MEDIA = MEDIA * 1.1, AN = (CASE AN WHEN 4 THEN 0 ELSE AN + 1 END)
Exemplul 3: În cazul în care pentru o coloană se doreşte actualizarea valorilor prin aducerea lor la valoarea implicită asociată la crearea tabelei sau la o valoare nulă se folosesc de asemenea cuvintele cheie DEFAULT şi NULL. În cazul folosirii lui DEFAULT, dacă nu există o valoare implicită asociată, în coloana respectivă se va stoca o valoare nulă.
UPDATE PROFIL SET FILIERA = DEFAULT; UPDATE PROFIL SET FILIERA = NULL;
Subcereri în clauza SET
Expresiile din clauza SET pot conŃine subcereri pe o altă tabelă din baza de date.
Exemplu: Pentru actualizarea numărului de elevi din tabela NRELEVI descrisă anterior se poate folosi următoarea cerere corelată:
UPDATE NRELEVI N SET NRELEVI = (SELECT COUNT(*) FROM ELEV WHERE CODP = N.CODP);
Folosirea aliasului de tabelă nu este strict necesară. Acelaşi efect îl are şi varianta:
UPDATE NRELEVI SET NRELEVI = (SELECT COUNT(*) FROM ELEV WHERE CODP = NRELEVI.CODP);
Subcererile pot fi prezente atât pe clauza WHERE cât şi în locul numelui tabelei. De exemplu, dacă se doreşte actualizarea numărului de elevi doar pentru profilurile având mai mult de trei elevi cererea este:
UPDATE NRELEVI SET NRELEVI = (SELECT COUNT(*) FROM ELEV WHERE CODP = NRELEVI.CODP) WHERE CODP IN (SELECT CODP FROM ELEV GROUP BY CODP HAVING COUNT(*) > 3);
Prezentarea actualizării prin specificarea unei subcereri în locul numelui tabelei este obiectul paragrafului 8.4.
Investeşte în oameni!
Pagina 143
9. UTILIZAREA VEDERILOR Acest capitol prezintă modul de lucru cu un alt tip de obiecte care pot exista într-o bază de date MySQL: vederile.
9.1. Vederi Ca şi alte sisteme relaŃionale, MySQL permite asocierea unui nume pentru o cerere SQL de tip SELECT şi stocarea acesteia ca obiect al bazei de date. Termenul care desemnează o astfel de cerere este vedere (în limba engleză: view).
O vedere se comportă ca o tabelă în cazul execuŃiei de cereri SELECT şi poate fi folosită uneori pentru efectuarea de actualizări ale bazei de date. Există însă şi diferenŃe între o vedere şi o tabelă, mai ales din punct de vedere al implementării:
� În cazul unei vederi, baza de date stochează definiŃia acesteia (cererea SQL ca şir de caractere) şi nu datele regăsite prin aceasta.
� Ori de câte ori se execută o cerere având la bază o vedere, ea este recalculată. Astfel, orice modificare efectuată în tabelele pe baza cărora e definită vederea se reflectă automat în aceasta.
� Structura unei vederi nu se poate modifica prin cereri de tip ALTER ci prin recrearea vederii cu specificarea unei alte cereri SQL.
� Constrângerile de integritate nu se pot defini la nivel de vedere. O vedere moşteneşte implicit toate constrângerile definite în tabelele pe baza cărora este definită pentru coloanele care sunt regăsite prin cererea asociată ei.
Vederile permit implementarea de scheme externe prin care diverse categorii de utilizatori accesează doar acele porŃiuni din baza de date pe care le folosesc în mod obişnuit, asigurându-se astfel:
� ConfidenŃialitatea datelor: utilizatorii care accesează baza de date doar prin intermediul unor vederi pot fi restricŃionaŃi în ceea ce priveşte datele pe care le pot utiliza prin însăşi definiŃia vederilor respective (ele nu conŃin coloanele/liniile/datele la care nu se doreşte accesul acelei categorii de utilizatori).
� Asigurarea corectitudinii datelor: prin faptul că un utilizator nu are acces la date pe care uzual nu le foloseşte este împiedicată coruperea accidentală a celorlalte date din cauza necunoaşterii semnificaŃiei lor.
Sintaxa cererii de creare a unei vederi este următoarea:
AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]
SemnificaŃia elementelor prezente într-o astfel de cerere este următoarea:
� nume_vedere - specifică numele asociat vederii respective. Respectă aceleaşi condiŃii ca în cazul numelor de tabele.
� subcerere - cererea SQL de tip SELECT asociată vederii.
Elementele opŃionale au următoarea semnificaŃie:
� lista_de_coloane - specifică numele coloanelor din vedere. Acestea trebuie să respecte restricŃiile uzuale pentru nume de coloane descrise în capitolele precedente (30 de caractere, etc.). În lipsa acestei opŃiuni coloanele vederii au aceleaşi nume cu ale rezultatului cererii SQL asociate.
� În cazul în care rezultatul cererii asociate vederii are nume de coloane care nu respectă restricŃiile privind astfel de nume este obligatorie fie folosirea listei_de_coloane fie modificarea cererii prin adăugarea unor aliasuri de coloană corespunzătoare.
� OR REPLACE - în cazul în care există deja o vedere cu acel nume, ea este înlocuită. Este modul uzual prin care se modifică structura şi conŃinutul unei vederi. În lipsa acestei opŃiuni sistemul semnalează în astfel de situaŃii o eroare.
� WITH CHECK OPTION - ca şi în capitolul precedent, această opŃiune împiedică efectuarea de inserări / actualizări prin vedere dacă liniile inserate/actualizate nu sunt regăsite prin cererea asociată vederii. CASCADED se foloseste când o vedere este definită pe baza unei alte vederi pentru a se verifica în cascadă ca liniile sunt regăsite prin toate vederile respective.
� DEFINER şi SQL SECURITY definesc drepturi de acces. Un superuser poate specifica un alt user ca DEFINER (proprietar) al vederii create de el. SQL SECURITY specifică drepturile cu care se executa cererea SELECT asociata: ale celui care a definit vederea sau ale celui care o foloseste.
Exemplu: Următoarele cereri crează o vedere ELEV_AN1 care conŃine doar datele referitoare la elevii de anul 1 din tabela ELEV şi o altă LISTA_AN1 având doar coloanele MATR, NUME, AN şi MEDIA din ELEV_AN1.
În plus, LISTA_AN1 conŃine doar date referitoare la elevii de la profilul 21 iar coloanele au nume diferite de cele din care provin:
CREATE OR REPLACE VIEW ELEV_AN1 AS SELECT * FROM ELEV WHERE AN = 1 WITH CHECK OPTION;
şi:
CREATE OR REPLACE VIEW LISTA_AN1 (MATRICOLA, NUMELE, ANUL, MEDIE) AS SELECT MATR, NUME, AN, MEDIA FROM ELEV_AN1 WHERE CODP = 21
Investeşte în oameni!
Pagina 145
WITH CASCADED CHECK OPTION;
Rezultatul cererii:
SELECT * FROM ELEV_AN1; va fi:
MATR NUME AN CLASA DATAN LOC TUTOR MEDIA CODP
3145 MIHAI 1 9A 1996-01-01 BRASOV 1456 6.80 11
3145 ION 1 9B 1996-01-24 PLOIESTI 3251 8.35 21
2101 MARIUS 1 9C 1996-09-02 PITESTI 3514 4.79 24
iar cererea:
SELECT * FROM LISTA_AN1;
are următorul raspuns:
MATRICOLA NUMELE ANUL MEDIE
3145 ION 1 8.35
Se observă că:
� O vedere se poate folosi pentru definirea altor vederi (LISTA_AN1 e definită pe baza ELEV_AN1).
� Prin vederea ELEV_AN1 nu se pot insera decât elevi de anul 1 şi nu se poate modifica valoarea anului de studiu din 1 în altă valoare, nulă sau nenulă (constrângerea WITH CHECK OPTION).
� Numele coloanelor din vederea LISTA_AN1 este altul decât cel din tabela ELEV şi vederea ELEV_AN1 ca urmare a folosirii unei liste de nume în cererea de creare.
Se pot defini vederi având asociate cereri SQL oricât de complicate. Un exemplu de vedere având la baza joinul celor trei tabele ELEV, PROFIL şi REZULTAT este următorul:
CREATE OR REPLACE VIEW LISTA_REZULTAT AS SELECT MATR, ST.NUME NUMEELEV, AN, MEDIA AS PCT, SP.NUME NUMESPEC, REZ FROM ELEV ST, PROFIL SP, REZULTAT WHERE ST.CODP = SP.CODP AND MEDIA BETWEEN MMIN AND MMAX ORDER BY SP.NUME, MEDIA DESC;
Astfel de vederi sunt folosite pentru regăsiri de date şi nu pentru modificarea acestora. Ele pot uşura dezvoltarea de aplicaŃii prin înlocuirea cererilor care folosesc direct tabelele bazei de date cu cereri mai scurte bazate pe vederi.
Investeşte în oameni!
Pagina 146
Ştergerea vederilor
Ştergerea unei vederi se face cu cererea DROP VIEW. Sintaxa acesteia este:
DROP VIEW nume_vedere Exemplu: ştergerea vederilor ELEV_AN1 şi LISTA_A1 se face cu cererile:
DROP VIEW ELEV_AN1; DROP VIEW LISTA_AN1;
Fiind o comandă DDL, ştergerea unei vederi nu poate fi revocată cu ROLLBACK.
9.2. Modificarea datelor prin vederi Deoarece o vedere nu are date proprii ci se calculează de fiecare dată pe baza cererii SQL asociate, orice modificare este efectuată direct în tabelele bazei de date care sunt specificate în definiŃia sa. Din această cauză nu orice vedere poate fi folosită pentru modificarea datelor ci doar cele pentru care sistemul poate detecta exact care linii ale acestora sunt afectate de operaŃia respectivă. În cazul modificării datelor prin vederi, mecanismele de tranzacŃie descrise anterior se comportă exact ca în cazul modificării tabelelor. În documentaŃia sistemului MySQL este prezentat un set de restricŃii pe care o vedere trebuie să le îndeplinească pentru a putea fi folosită în operaŃiile DML (ştergere, modificare şi inserare). Acestea sunt diferite după tipul operaŃiei: Ştergere si actualizare Cererea DELETE sau UPDATE poate avea la bază o vedere dacă aceasta nu conŃine:
� Functii statistice (SUM(), MIN(), MAX(), COUNT(), etc) � DISTINCT � GROUP BY � HAVING � UNION or UNION ALL � Subcereri în clauza SELECT � Joinuri (nu în toate cazurile dar este bine de evitat) � Vederi neactualizabile în clauza FROM � O subcerere în clauza WHERE care referă o tabela din clauza FROM � Literali sau expresii pe clauza SELECT (în acest caz coloanele respective nu sunt
neactualizabile dar se pot sterge linii) � Multiple referinte la aceeasi coloana din tabela de bază
Următoarele vederi nu pot fi folosite pentru ştergere/actualizare deoarece încalcă una sau mai multe din restricŃiile de mai sus:
Exemplul 1: Vedere care conŃine DISTINCT, grupare şi funcŃii de grup:
CREATE OR REPLACE VIEW NU_STERGE AS SELECT DISTINCT MAX(MEDIA) MAXIM FROM ELEV
Investeşte în oameni!
Pagina 147
GROUP BY CODP;
Exemplul 2: Vedere care conŃine literali şi join:
CREATE OR REPLACE VIEW NU_STERGE AS SELECT 1 NRCRT, ST.NUME NUMEELEV, SP.NUME NUMESPEC FROM ELEV ST, PROFIL SP WHERE ST.CODP = SP.CODP;
În ambele cazuri a fost nevoie de utilizarea unor aliasuri de coloană deoarece:
� MAX(MEDIA) nu respectă convenŃia pentru nume de coloane (conŃine paranteze). � ST.NUME şi SP.NUME duc la crearea unei vederi având două coloane cu acelaşi nume
(NUME).
Exemplul 3: prin intermediul vederii ELEVI11 definită în continuare se pot actualiza toate coloanele vederii care provin din coloane ale tabelei ELEV dar nu se poate specifica modificarea coloanei suplimentare MMARITA definită de expresia aritmetica MEDIA*1.1:
CREATE OR REPLACE VIEW ELEVI11 AS SELECT MATR, NUME, DATAN, MEDIA, MEDIA*1.1 MMARITA FROM ELEV WHERE CODP=11;
Următoarea actualizare va mări valoarea mediilor mai mici de 8:
UPDATE ELEVI11 SET MEDIA = MEDIA + 0.20 WHERE MEDIA < 8;
În schimb cererea de actualizare:
UPDATE ELEVI11 SET MMARITA = MEDIA + 0.20 WHERE MEDIA < 8;
va semnala eroarea Column 'MMARITA' is not updatable deoarece se încearcă actualizarea unei coloane definite printr-o expresie.
Inserare Pentru a se putea insera noi linii prin intermediul unei vederi, aceasta trebuie să satisfacă următoarele restricŃii:
� Nu exista coloane cu acelasi nume în vedere. � Vederea conŃine toate coloanele din tabela de bază care nu au o valoare implicită � Vederea nu conŃine coloane care provin din expresii sau literali (fiecare coloană provine dintr-
o coloană a tabelei de bază). În cazul vederii ELEVI11 descrisă mai sus, aceasta conŃine coloane care provin din expresii deci nu se pot face inserări. În schimb vederea:
Investeşte în oameni!
Pagina 148
CREATE OR REPLACE VIEW ELEVI11 AS SELECT MATR, NUME, DATAN, MEDIA FROM ELEV WHERE CODP=11;
Îndeplineste toate condiŃiile. Rezultă că vom putea executa cu succes o cerere de inserare de tipul: INSERT INTO ELEVI11 (MATR, NUME, DATAN, MEDIA) VALUES (5000, 'MARCEL', '1995-02-28', 9.45);
OperaŃiile de modificare a conŃinutului tabelelor prin intermediul vederilor definite pe baza lor trebuie să respecte toate constrângerile de integritate ale acestora.
Investeşte în oameni!
Pagina 149
ACTIVITĂłI PRACTIC–APLICATIVE PENTRU TEMA 7 Obiectivele activităŃilor practic-aplicative:
• Exersarea cererilor de tip INSERT, UPDATE şi DELETE. • Crearea şi utilizarea vederilor
A. 1– Se vor scrie, executa şi eventual depana cererile INSERT care: a. Adaugă o linie noua în tabela ELEV1 (creată la tema 5) b. Adaugă o linie noua în tabela PROFIL1 c. Adaugă o linie noua în tabela REZULTAT1 d. Adaugă în tabela REZULTAT1 toate liniile din tabela REZULTAT e. Adaugă în tabela ELEV1 toŃi elevii din ELEV care au tutor f. În plus, se vor executa toate cererile prezente în manual la capitolul 8.1
A. 2 – Se vor scrie, executa şi eventual depana o cerere DELETE care: a. Şterge o linie din tabela ELEV1 (creată la tema 5) b. Şterge o linie din tabela PROFIL1 c. Şterge o linie din tabela REZULTAT1 d. Şterge din tabela REZULTAT1 un număr de 2 linii, cele care conŃin cele mai mari medii e. Goleşte tabela REZULTAT1 f. În plus, se vor executa toate cererile prezente în manual la capitolul 8.2
A. 3 Se vor scrie, executa şi eventual depana cererile UPDATE care: a. Actualizează liniile din tabela ELEV1 crescând media cu 7% b. Actualizează liniile din tabela ELEV1 crescând media cu 10% pentru elevii care au o medie
între 5 si 6. c. Actualizează liniile din tabela ELEV1 crescând media cu 20% pentru elevii care au medie
pentru calificativul BINE d. În plus, se vor executa toate cererile prezente în manual la capitolul 8.3 g. A. 4 Se vor executa toate cererile prezente în manual la capitolele 9.1 şi 9.2
CUPRINS TEMA 7 Arhitecturi de aplicaŃii software ....................................................... 3 1. Arhitectura Client / Server pe două niveluri (two-tier) 5 1. Arhitectura pe trei niveluri (three-tier) 6 3. Sisteme de baze de date distribuite 8 3.1 Tipuri de baze de date distribuite 8 3.2 Avantajele şi dezavantajele bazelor de date distribuite 11 3.3 Procesarea paralelă a datelor 12 3.4 Strategii de implementare a bazelor de date distribuite 14 4. Sisteme informatice distribuite 16 4.1 Caracteristicile sistemelor informatice distribuite 16 4.2 Arhitectura sistemelor informatice distribuite 18 4.2.1 Sisteme informatice client / server pe două niveluri 19 4.2.2 Sisteme informatice client / server pe trei niveluri 21 ACTIVITĂłI PRACTIC – APLICATIVE PENTRU TEMA 8 ......................... 25 TEMA 8 Securitatea sistemelor de baze de date ............................................ 26 1. Securitatea la nivelul sistemului de operare 27 1.1 Rolul administratorului de sistem 27 1.2 Criptarea fişierelor de sistem 28 2. Securitatea la nivelul reŃelei locale sau Internet ............................................... 29 2.1 Algoritmi de criptare/decriptare 29 2.2 Metode de autentificare 34 3. Securitatea la nivelul aplicaŃiei software ............................................. 35 4.Securitatea la nivelul Sistemului de Gestiune a Bazei de Date (SGBD) 39 4.1 Securitatea bazei de date 39 4.2 Integritatea bazei de date 40 4.3 Criptarea bazei de date 42 5. Metodologii de implementare şi securizare a sistemelor informatice distribuite ............................................................................................... 43 5.1 Clasificarea modelelor arhitecturale client/server 43 6. Securitatea sistemelor informatice distribuite ...................................... 46 ACTIVITĂłI PRACTIC – APLICATIVE PENTRU TEMA 8 ................... 51 TEMA 9 AplicaŃia software pentru prelucrarea rezultatelor obŃinute la evaluarea natională ................................................................. 53 1. Modulul CENTRE EXAMEN .................................................................. 54 2. Modulul COMISII EVALUARE ............................................................... 55 3. Modulul BORDEROU LUCRĂRI ............................................................ 57 4. Modulul REZULTATE EVALUARE ....................................................... 63 5. Modulul PRELUCRARE REZULTATE SI STATISTICI .......................... 67 ACTIVITĂłI PRACTIC – APLICATIVE PENTRU TEMA 9 ................ 73
Investeşte în oameni!
Pagina 151
P A R T E A A I I A SUPORTUL DE CURS
TEMA 8
Arhitecturi de aplicaŃii software
Obiectivele temei urmăresc prezentarea de:
• arhitecturi de baze de date
• sisteme de aplicaŃii software
• tipuri de baze de date distribuite
• strategii de implementare a bazelor de date
• sisteme informatice distribuite
Arhitecturile de baze de date sunt într-o continuă perfecŃionare, datorită evoluŃiei teoriei
bazelor de date, a sistemelor de gestiune de baze de date, a limbajelor de programare dar şi datorită dezvoltării continue a sistemelor hardware. Conceptul de societate informaŃională implică baze de date de dimensiuni foarte mari, o infrastructură hardware performantă, dar şi metode de securitare informaŃională complexe. Vor fi prezentate mai jos cele mai utilizate arhitecturi de baze de date şi aplicaŃii software folosite în aplicaŃii comerciale.
1. Arhitectura Client / Server pe două niveluri (two-tier)
Primele aplicaŃii multiuser au fost proiectate într-o arhitectură mainframe. Programele şi baza de date erau stocate pe un server central de dimensiuni mari, numit mainframe. ToŃi utilizatorii, care doreau să acceseze baza de date, se conectau cu terminale neinteligente pentru a comunica cu mainframe-ul. Procesarea datelor se realiza numai pe server şi de aceea performanŃele unei aplicaŃii software erau strâns legate de performanŃele serverului. O altă problemă era legată de breşele de securitate, atât la nivelul sistemului de operare, dar şi la nivelul sistemului de gestiune a bazei de date. Aceste limitări hardware şi software implicau şi limitări serioase asupra sistemelor informatice şi a bazelor de date. Deoarece staŃiile de lucru erau terminale neinteligente, fără posibilităŃi proprii de operare şi prelucrare a datelor, se limitau şi mai mult performanŃele aplicaŃiilor. ÎntreŃinerea unei astfel de arhitecturi era destul de greoaie şi cu costuri materiale şi umane destul de ridicate. Totuşi, la vremea respectivă a însemnat un pas important în tehnologia informaŃiei şi a deschis calea arhitecturilor moderne folosite în prezent.
Investeşte în oameni!
Pagina 152
Odată cu apariŃia PC-urilor conectate în reŃea, care reprezentau soluŃii ieftine, a apărut arhitectura client-server pe două niveluri (two-tier). În cadrul acestei arhitecturi, avem o aplicaŃie care rulează pe maşina client şi care interacŃionează cu serverul, aşa cum se vede în Figura 1. De obicei, aplicaŃia client conŃinea interfaŃa utilizator, logica operaŃională (bussiness rules) şi drivere pentru accesul la baza de date. De fiecare dată când regulile logice erau modificate, aplicaŃia client trebuia schimbată, testată şi reinstalată. Deşi adesea conceptul de tier este acelaşi cu layer , ambele referindu-se la straturi, o accepŃie comună este aceea că tier se referă la mecanismele logice care stau în spatele unei soluŃii software, pe când un layer reprezintă un mecanism fizic din cadrul unei infrastructuri de sistem.
În cazul acestei arhitecturi, serverul este degrevat de o parte importantă din sarcini, deoarece unele funcŃionalităŃi sunt preluate de PC-uri care sunt mini-calculatoare cu sistem propriu de operare. Şi din punct de vedere al securităŃii aplicaŃiilor s-a făcut un pas înainte, deoarece s-au introdus două niveluri de securitate la conectarea pe PC şi la conectarea în reŃea. REłEA PC-uri
SERVER
Figura nr. 1 Arhitectura Client/Server pe două niveluri
SGBD
Fişiere
Investeşte în oameni!
Pagina 153
2. Arhitectura pe trei niveluri (three-tier)
Tehnologia InformaŃiei a cunoscut în ultimul deceniu o dezvoltare fără precedent, datorată atât tehnologiei hardware cât şi celei software. AplicaŃiile software complexe de ultimă generaŃie au o arhitectură logică structurată pe trei niveluri, aşa cum se vede în Figura 2. În acest caz, termenul de three- tier se referă la introducerea unui server sau agent între partea de client şi cea de server. Rolul acestuia diferă în funcŃie de scopul aplicaŃiei. Acesta poate oferi servicii de traslatare (adaptarea unei aplicaŃii native de pe un mainframe la un mediu client-server), de limitare (monitorizarea şi eventual reducerea numărului de cereri efectuate asupra unui server), sau servicii de tip agent inteligent (asignarea unei cereri la un număr de servere diferite şi interpretarea rezultatelor prin transmiterea unui singur răspuns clientului). Primul nivel este cel al clienŃilor care pot fi utilizatori de aplicaŃii conectaŃi direct la un server de aplicaŃii, sau clienŃi conectaŃi prin Internet care pot fi simpli utilizatori de servicii, dar şi dezvoltatori de aplicaŃii, în cazul companiilor cu puncte de lucru distribuite geografic. O altă categorie de clienŃi sunt cei care folosesc aplicaŃii GIS (Geographic Information System) şi folosesc dispozitive specifice tip GPS, sau utilizatorii de telefonie mobilă. Nivelul al doilea este destinat serverelor de aplicaŃii pe care rulează aplicaŃiile software şi serverelor de web destinate conexiunii prin Internet. La aplicaŃiile client/server pe două niveluri, acest nivel logic nu există, deoarece aplicaŃiile rulau pe aceeaşi maşină, pe care era instalat şi serverul de baze de date. Cele două niveluri au fost separate din motive de securitate a datelor, dar şi pentru creşterea performanŃelor reŃelei. Nivelul al treilea este destinat serverelor de baze de date şi este alcătuit din servere cu putere mare de stocare şi prelucrare a datelor, dar şi servere de back-up, destinate exclusiv arhivării datelor. Stocarea datelor se poate face la nivel de fişiere, dar pentru aplicaŃii cu volum mare de date se foloseşte un SGDB (Sistem de Gestiune a Bazei de Date) cum ar fi Oracle, SQL Server, Informics,etc. Dacă arhitectura unei aplicaŃii software este mai complexă, apar mai multe probleme legate de funcŃionalitate, securitatea reŃelei şi securitatea bazei de date.
Investeşte în oameni!
Pagina 154
Figura nr. 2 Arhitectura aplicaŃiilor pe trei niveluri
În primul rând, în discuŃia despre implementarea unui sistem, având o arhitectură three-tier, trebuie luate în vedere modalităŃile de transfer de date. Schimbul de date poate fi bazat pe fişiere( file-based ), client-server, bazat pe evenimente( event-based),etc. În mod ideal, designul de nivel înalt (high-level) al sistemului va fi bazat pe regulile operaŃionale şi nu pe tehnologiile de interfaŃă (front-end) sau de funcŃionalitate (back-end). Nivelurile trebuie populate cu acele funcŃionalităŃi care vor minimiza interdependenŃele şi vor izola rolurile într-o manieră coerentă, Ńinând cont că tot sistemul este predispus la schimbări şi aceste schimbări vor trebui făcute în cel mai mic număr de locuri, rămânând în acelaşi timp testabile. Serverul de aplicaŃii este organizat şi el pe mai multe niveluri logice, de exemplu un sistem clasic JSP/Servlet este organizat astfel:
� JSP-uri sau Servlet-uri responsabile pentru crearea de pagini HTML sau WML pentru interfaŃa utilizator;
� Servlet-uri sau JavaBeans responsabile pentru logica operaŃională (bussiness rules);
AplicaŃii Desktop
SGBD
Fişiere Date
SERVER WEB
SERVER APLICAłII
Utilizatori Internet
Dezvoltatori AplicaŃii GPS, PDA,
GPRS,Cell
SGBD
S E R V E R
E
BAZA DE DATE
CLIENłI
Investeşte în oameni!
Pagina 155
� Servlet-uri, JavaBeans sau clase Java responsabile pentru accesul la baza de date. Aceste obiecte folosesc de obicei JDBC (Conectivitate Java la baza de date) pentru a interoga baza de date.
Avantajele arhitecturii pe trei niveluri:
• uşurinŃa modificării sau înlocuirii oricărui nivel fără a afecta funcŃionalitatea celorlalte;
• separarea aplicaŃiei de funcŃionalitatea bazei de date duce la o preluare a încărcăturii de date (load balancing) foarte eficientă;
• aplicarea unor reguli de securitate la nivel de server se poate face fără a se interveni în vreun fel la nivel de client;
• în cazul aplicaŃiilor web, acest model oferă performanŃe notabile prin folosirea de obiecte persistente care consumă puŃine resurse (lightweight);
• flexibilitatea, nu numai în configurarea platformelor cât şi în publicarea (deplyoment) aplicaŃiilor Web.
3. Sisteme de baze de date distribuite
3.1 Tipuri de baze de date distribuite
O bază de date distribuită este o bază de date stocată pe mai multe servere şi este controlată
de un sistem de gestiune a bazelor de date (SGBD). Aceste servere pot să se afle fizic în aceeaşi locaŃie, sau să fie distribuite geografic şi conectate într-o reŃea de calculatoare astfel încât pentru un utilizator acest lucru să fie transparent, având impresia că lucrează doar pe un singur server. Sistemele de baze de date distribuite devin din ce în ce mai populare şi sunt folosite într-o gamă largă de aplicaŃii şi domenii de activitate, multe dintre ele distribuite prin natura lor. O bază de date distribuită este controlată de o bază de date centrală, care are rolul de management a bazelor distribuite. Partea din baza de date distribuită ataşată la un singur server este numită partiŃie . Fiecare partiŃie, a unei baze de date distribuite, se poate replica (duplica) identic într-o altă locaŃie, deci în alt calculator din reŃea, cu scopul măririi siguranŃei în funcŃionare (fiabilităŃii). Avantajul acestei structuri redundante este că eventualele erori în funcŃionare se pot de multe ori repara on line, fără întreruperea funcŃionării, asemănător cu principiul funcŃionării matricilor cu discuri hard multiple de tip RAID. Datorită acestei distribuŃii, mai mulŃi useri pot să acceseze baza în acelaşi timp, fără să apară probleme de interferenŃă între ei. Rolul bazei de date centrale este de a sincroniza periodic bazele de date distribuite pentru a se păstra consistenŃa datelor. Există o sumedenie de tehnici de proiectare a unei baze de date distribuită, dar toate trebuie să asigure rezolvarea următoarelor probleme : transparenŃa, flexibilitatea, securitatea tranzacŃiilor şi performanŃa. Tehnologia sistemelor de baze de date distribuite este una dintre cele mai recente dezvoltări în domeniul bazelor de date, presupunându-se că în următorii zece ani majoritatea organizaŃiilor vor schimba modul de gestionare a propriilor date alegând această tehnologie. Implementarea tehnologiilor poate fi facută diferit, în funcŃie de nevoile aplicaŃiei şi în funcŃie de tipul de sensibilitate/confidenŃialitate a datelor care trebuie salvate în baza de date.
Investeşte în oameni!
Pagina 156
Alegerea unei anumite baze de date distribuită şi implementarea ei concretă depind de:
• nevoile companiei;
• confidenŃialitatea datelor;
• securitatea tranzacŃiilor şi a datelor;
• consistenŃa datelor;
• integritatea datelor;
• bugetul alocat implementării.
Bazele de date distribuite pot să fie :
� omogene
• baza distribuită pe mai multe noduri;
• acelaşi SGBD folosit în fiecare nod al reŃelei;
• toate informaŃiile sunt organizate de SGBD distribuit;
• o schemă globală care este însumarea tuturor schemelor locale;
• dificil de impus dar uşor de administrat.
� heterogene
• datele distribuite în mai multe noduri;
• SGBD diferit pentru fiecare nod în parte;
• utilizatorii cer acces local pentru scheme şi SGBD;
• o schemă globală permite utilizatorilor să acceseze date remote.
Baza de date distribuită omogenă foloseşte un singur tip de sistem de gestiune şi poate fi : � autonomă
• datele sunt distribuite pe mai multe noduri;
• o schemă globală permite utilizatorilor să acceseze date remote;
• fiecare SGBD lucreză independent;
• transmit mesaje pentru a se păstra consistenŃa;
� neautonomă
• un sistem de gestiune central (Master), care coordonează accesul la bazele de date şi actualizează datele la nivelul nodurilor.
Baza de date distribuită heterogenă foloseşte mai multe tipuri de sisteme de gestiune şi poate fi :
Investeşte în oameni!
Pagina 157
� din punct de vedere al funcŃionalităŃii:
• funcŃionalitate totală a SGBD;
• funcŃionalitate parŃială a SGBD;
Caracteristicile bazelor de date distribuite:
• transparenŃa datelor şi flexibilitatea - înseamnă separarea semanticii de nivel înalt faŃă de nivel jos de implementare. Baza de date distribuită, fie ea omogenă sau heterogenă, trebuie să fie transparentă faŃă de utilizator. TransparenŃa trebuie să fie realizată la nivelul reŃelei, la nivelul replicării datelor şi la nivelul fragmentării datelor;
• replicarea datelor - salvarea unei copii a bazei de date pe fiecare host. Avantaje: siguranŃă, răspuns rapid, reducerea traficului în reŃea, evitarea folosirii de tranzacŃii complexe. Dezavantaje: spaŃiu de stocare mare, complexitate şi cost mare pentru updatare;
• partiŃionare orizontală - tuple dintr-o relaŃie sunt distribuite în diferite locaŃii (unele rânduri ale unei tabele sunt stocate pe un nod în timp ce altele sunt stocate pe alte noduri din reŃeaua distribuită). Avantaje:eficienŃă, optimizare locală, securitate, uşurinŃă la interogare. Dezavantaje: viteză de acces mai mică, vulnerabilitate;
• partiŃionare verticală - coloanele unei relaŃii sunt distribuite în reŃea. Avantajele şi dezavantajele sunt aceleaşi ca şi la partiŃionarea pe orizontală;
• extinderea mai uşoară şi cu costuri mai mici;
• performanŃe îmbunătaŃite.
Utilizatorii pot să acceseze baza de date distribuită prin:
• aplicaŃii locale (aplicaŃii care nu necesită date de pe alte situri).
• aplicaŃii globale (aplicaŃii care au nevoie de date de pe alte situri).
3.2 Avantajele şi dezavantajele bazelor de date distribuite Administrarea internă a bazelor de date distribuite este pretenŃioasă şi în general dificilă, deoarece trebuie asigurat că:
• distribuŃia este transparentă – utilizatorii trebuie să poată să interacŃioneze cu sistemul ca şi când ar fi vorba de un sistem nedistribuit (monolitic);
• tranzacŃiile trebuie să aibă şi ele o structură transparentă - fiecare tranzacŃie în parte trebuie, desigur, să menŃină integritatea bazei de date, în ciuda multitudinii de partiŃii (pentru aceasta ele se divizează de obicei în subtranzacŃii, fiecare din acestea prelucrând doar o singură partiŃie).
� Avantajele bazelor de date distribuite:
• pot reflecta structura organizaŃională a companiei – partiŃiile pot fi plasate direct în departamentele de care aparŃin;
• autonomie locală – fiecare departament îşi poate controla mai îndeaproape propriile sale date;
Investeşte în oameni!
Pagina 158
• disponibilitate îmbunătăŃită – o eroare într-o bază de date distribuită va afecta de cele mai multe ori o singură partiŃie, şi nu toată baza de date (celelalte partiŃii rămân disponibile pentru prelucrare);
• performanŃă îmbunătăŃită – datele pot fi amplasate lângă site-ul cu cererea cea mai mare, iar partiŃiile însele sunt paralelizate, permiŃând astfel ca solicitarea bazei de date să se echilibreze dinamic între serverele disponibile (o solicitare intensă într-o partiŃie a bazei de date distribuite nu va afecta alte partiŃii);
• economie – costă mai putin să se creeze o reŃea de computere mai mici, dar cu puterea totală a unui singur computer mare;
• modularitate – subsistemele unei baze de date distribuite pot fi modificate, adăugate sau deconectate dinamic, fără să se afecteze alŃi clienŃi sau partiŃii.
� Dezavantajele bazelor de date distribuite:
• complexitatea – trebuie depusă muncă suplimentară de către administratorii bazelor de date pentru a se asigura că natura distribuită a sistemului este transparentă (invizibilă pentru utilizator). Munca suplimentară trebuie, de asemenea, depusă şi pentru a întreŃine multiple sisteme disparate. Proiectarea unei baze de date distribuite trebuie să Ńină cont şi de natura ei disconectă – de exemplu, operaŃia join (reunirea a doua tabele ale unui RDBMS) devine deosebit de laborioasă când trebuie efectuată pe baza mai multor partiŃii disparate;
• profitabilitatea redusă – complexitatea mai mare şi infrastructurile mai ample duc la costuri suplimentare pentru realizare şi implementare;
• securitatea – toate partiŃiile bazei de date trebuie securizate, dar deoarece acestea nu sunt centralizate, trebuie securizate şi toate site-urile relaŃionate, la orice distanŃe s-ar afla ele. Drept urmare, şi infrastructura trebuie securizată (de ex. prin codificarea tuturor transmisiilor între site-urile reŃelei);
• dificultatea de a menŃine integritatea – dacă baza de date este concepută greşit asigurarea integrităŃii poate suprasolicita şi chiar bloca reŃeaua dintre noduri;
• lipsa de experienŃă – câmpul de activitate fiind dificil, nu există documentaŃie suficientă despre experienŃa acumulată în diverse proiecte concrete.
3.3 Procesarea paralelă a datelor
Deşi marile companii producătoare de software de gestiune a bazelor de date fac eforturi deosebite în a actualiza şi îmbunătăŃi performanŃele sistemului lor, există în continuare un decalaj semnificativ între realizările lor actuale şi evoluŃia mult mai rapidă a tehnologiilor hardware şi de comunicaŃie, ce permit realizarea de medii heterogene complexe utilizând maşini din ce în ce mai performante. Marile companii producătoare de sisteme de gestiune a bazelor de date se află în competiŃie, pentru a găsi cele mai bune soluŃii, care să satisfacă cererile noii generaŃii de sisteme distribuite, cereri legate îndeosebi de distribuirea unei mari varietăŃi de tipuri de date pe o şi mai mare varietate de maşini conectate în configuraŃii de reŃele heterogene. AplicaŃiile tot mai complexe împing în prezent mediile de calcul la limita posibilităŃilor de procesare.
Investeşte în oameni!
Pagina 159
MulŃi utilizatori îşi bazează deciziile pe informaŃii vechi de citeva zile, deoarece sistemele lor nu au capacitatea de a furniza analize în timp real. Pentru a face faŃă noilor cerinŃe, companiile producătoare de sisteme de calcul au evoluat de la sistemul uniprocesor la arhitecturi de multiprocesare simetrică, clustere şi chiar arhitecturi cu procesare paralelă masivă. Totodată, companiile de software situate în topul vânzărilor de sisteme de baze de date - Oracle, Microsoft, IBM, Sybase - au dezvoltat în ultimii ani noi versiuni ale sistemelor lor de baze de date, care utilizează servere în multiprocesare simetrică (SMP), multiprocesare asimetrică, sau procesare pe mai multe căi de control al execuŃiei (multithreading). Aceste versiuni noi pun însă probleme complexe, atât în ceea ce priveşte administrarea de sistem, cât şi dezvoltarea de aplicaŃii. Este necesară clarificarea diferenŃei dintre procesarea paralelă şi procesarea pe multiple căi de control al execuŃiei (multithreading). Ambele modele implică executarea de task-uri multiple în paralel, dar în timp ce procesarea paralelă implică mai multe procese ,ce se execută pe mai multe unităti de prelucrare, multithreading se referă la un singur proces, ce poate rula pe mai multe căi de prelucrare simultan. Deci, căile multiple de control al execuŃiei sunt o formă mai simplă de paralelism, ele rulând sub acelaşi proces şi utilizând în comun anumite resurse ale sistemului. Toate căile de execuŃie, comune unui proces, împart resurse comune - date, memorie sau fişiere deschise - furnizând unei aplicaŃii posibilitatea de a lansa task-uri multiple simultan, în cadrul unui singur proces. În cazul proceselor paralele, atunci când unitatea centrală de execuŃie plasează un proces în aşteptare, în timp ce un alt proces se execută, unitatea trebuie să memoreze într-o zonă de memorie temporară contextul de execuŃie al respectivului proces; deci, overhead-ul de menŃinere a unui proces distinct include un spaŃiu de adrese de memorie complet separat, spre deosebire de procesarea prin căi paralele de control al execuŃiei în cadrul unui singur proces, pentru care overhead-ul de sistem este considerabil mai mic. În multithreading, serverul de baze de date atribuie thread-uri cererilor aflate în execuŃie, realizând şi schimbarea dinamica a căii pe care o cerere rulează la un moment dat; dacă o cerere se află în stare de aşteptare, serverul va realiza, printr-un mecanism de swapping, înlocuirea acestei cereri cu o altă cerere, care va fi asignată aceleiaşi căi. Rezultatul se concretizează în optimizarea timpului de execuŃie a cererilor şi deci îmbunătăŃirea performanŃelor de interogare a bazelor de date în sisteme distribuite. Cele mai utilizate arhitecturi hardware paralele, ce exploatează multiple procesoare, memorii mari şi mai multe unităŃi de disc sunt:
• arhitectura Shared Nothing, în care fiecare procesor deŃine propriile sale unităŃi de memorie şi disc;
• arhitectura Shared Disks utilizează multiple procesoare, fiecare cu unitatea sa de memorie, dar cu sistem de disc partajat;
• arhitectura Symmetric Multiprocessing (SMP) utilizează procesoare multiple, care deŃin în comun unităŃile de memorie şi disc.
În prezent, pentru a atinge performanŃe ridicate din punctul de vedere al procesării on line a tranzacŃiilor OLTP (Online Transaction Processing), cele mai bune arhitecturi sunt considerate a fi cele uniprocesor şi cele în multiprocesare simetrică (SMP).
Investeşte în oameni!
Pagina 160
Pe de altă parte însă, sistemele paralele masive, sau sistemele shared-nothing sunt excelente pentru suport decizional pe scară largă. Arhitecturile în cluster, cum este de exemplu HACMP/6000 al companiei IBM, oferă însă alte avantaje, cum ar fi :
• un grad înalt de disponibilitate - dacă un nod din cluster cade, un alt nod preia temporar sau definitiv lucrările primului;
• fiecare nod din cluster poate fi la rândul său o maşină în multiprocesare simetrică, asigurând cluster-ului o scalabilitate mult mai mare.
3.4 Strategii de implementare a bazelor de date distribuite
Cele mai multe dintre sistemele de gestiune a bazelor de date sunt în prezent îmbunătăŃite, pentru a beneficia de procesarea paralelă în sisteme heterogene, şi a permite rularea de aplicaŃii complexe cu misiune critică. Compania de software care va veni cu un set de soluŃii optime, pentru a integra bazele de date cu noile tehnologii de distribuire a datelor, va deŃine controlul asupra pieŃei în acest domeniu. Distribuirea optimă a datelor este dificilă din punct de vedere tehnologic, acest proces fiind puternic dependent de cerinŃele pentru asigurarea unui timp bun de răspuns la cereri, asigurarea integrităŃii datelor, disponibilitate continuă, interoperabilitate etc.
Sistemele de gestiune a bazelor de date moderne utilizează o serie de noŃiuni abstracte şi strategii asociate, pentru a putea îndeplini cerinŃele aplicaŃiilor actuale. De exemplu, tranzacŃia (definită ca o colecŃie de operaŃii care asigură trecerea unei baze de date dintr-o stare consistentă logic în alta) poate fi utilizată şi în cadrul datelor distribuite, pentru a asigura în reŃea trecerea unor grupuri de date şi operaŃii asociate de la un post client la server, sau de la un server la altul. Cea mai mare parte dintre producătorii de sisteme de baze de date au creat monitoare de procesare a tranzacŃiilor TP (Transaction Processing), ce reprezintă utilitare evoluate, care gestionează tranzacŃiile distribuite în reŃele heterogene. Din punctul de vedere al asigurării integrităŃii datelor în sisteme distribuite, producătorii de software de gestiune a bazelor de date recurg la mai multe strategii, cum ar fi:
• strategia two-phase commit - prin care toate modificările impuse de o tranzacŃie asupra unei baze de date sunt, fie comise (execuŃia tranzacŃiei este finalizată), fie sunt anulate, cu revenirea bazei de date în starea anterioară efectuării tranzacŃiei;
• strategia de replicare a datelor- care este un proces în cadrul căruia mai multe servere deŃin mai multe copii identice ale unei baze de date.
Strategia two-phase commit nu este adecvată pentru reŃelele heterogene complexe (în care probabilitatea de cădere a unui nod este mare) şi nici pentru sisteme cu misiune critică.
Replicarea este utilizată ca o cale de a asigura faptul că toate serverele deŃin copii identice ale bazei de date în orice moment. Replicarea datelor este în prezent soluŃia adoptată de companiile Oracle, IBM şi Sybase. Strategia de replicare a datelor diferă esenŃial de two phase commit, prin aceea că replicarea garantează identitatea copiilor bazelor de date distribuite numai în anumite momente sau în anumite condiŃii. Tehnica de replicare a datelor, utilizată de serverul Oracle, este denumită Table Snapshots, prin care serverul central (master) copiază la anumite momente de timp definite, numai acele înregistrări din baza de date care s-au modificat, propagând apoi aceste
Investeşte în oameni!
Pagina 161
modificări în reŃea. Mecanismul de replicare, utilizat de serverul de baze de date IBM, este similar metodei snapshots utilizată de Oracle, dar utilizează fişiere de log şi backup, pentru a gestiona datele din tabelele bazei de date, ce trebuie replicate (care conŃin modificări). Serverele de replicare reprezintă numai începutul unei întregi generaŃii de produse software, care implementează concepte abstracte referitoare la distribuirea datelor în medii heterogene împreună cu tehnologii avansate de gestiune şi procesare paralelă, optimizată a tranzacŃiilor.
Replicarea modificărilor de date apare doar după ce sistemul se asigură că semnatarul are cele mai recente snapshoturi ale tabelelor de scheme şi date, care au fost generate. Când snapshoturile sunt distribuite şi aplicate asupra semnatarilor, doar acei semnatari, care au nevoie de snapshotul iniŃial, sunt afectaŃi. Semnatarii care au primit deja inserările, modificările şi ştergerile (sau alte modificări asupra datelor) nu sunt afectaŃi, numai dacă subscrierea (aderarea) este marcată pentru reiniŃializare.
Un sistem informatic distribuit este un ansamblu de programe, baze de date şi procese într-o
reŃea de calculatoare, care foarmează noduri şi intereacŃionează între ele. Un sistem informatic distribuit este omogen, când componentele din care este alcătuit (componente hardware şi software) sunt de acelaşi fel. Majoritatea sistemelor distribuite sunt însă heterogene , fiind dezvoltate în diferite limbaje de programare şi care lucrează pe diferite platforme de sisteme de operare . În domeniul tehnologiei informaŃiei, sistemele informatice distribuite s-au impus, datorită avantajelor pe care le oferă utilizatorilor finali, iar necesitatea proiectării lor este motivată de câteva caracteristici specifice cum ar fi:
• schimbul rapid de date – creşterea masivă a cantităŃii de informaŃie şi necesitatea de a schimba rapid date între diferitele puncte, aflate în locuri geografic depărtate, fac necesară conectarea calculatoarelor în reŃele distribuite;
• partajarea resurselor – o companie preferă să investească într-o reŃea de PC-uri, decât să cumpere un server foarte puternic, deoarece este mult mai scump şi mai greu de întreŃinut. În acest mod, devine necesară interconectarea acestor calculatoare mai mici între ele, eventual cu un număr redus de calculatoare mai puternice, ale căror resurse (memorie, putere a procesorului, periferice de capacităŃi mari) să fie partajate între acestea;
• creşterea siguranŃei în funcŃionare – dacă un sistem de calcul este bazat pe un singur server, defectarea acestuia blochează funcŃionarea întregului sistem informatic. Din acest motiv, la proiectarea unui sistem distribuit, se Ńine seama, în foarte mare măsură, de siguranŃa în funcŃionare a acestuia, astfel încât căderea unui nod să nu perturbe funcŃionarea celorlalte;
• creşterea performanŃelor – prezenŃa mai multor procesoare, într-un sistem distribuit, face posibilă reducerea timpului de prelucrare a datelor, prin paralelizarea calculului. Acest fapt este posibil prin împărŃirea sarcinilor între diferite procesoare, colectarea ulterioară a rezultatelor parŃiale şi asamblarea rezultatului final;
• specializarea nodurilor – prelucrarea datelor poate să fie simplificată prin modularizarea sistemului, fiecare modul implementând o parte din funcŃionalităŃi apoi comunicând cu alte
Investeşte în oameni!
Pagina 162
module, deoarece proiectarea unui sistem de calcul complex, cu multe funcŃionalităŃi, poate să fie uneori foarte dificilă. Dificultatea construirii unor astfel de sisteme apare în momentul elaborării algoritmilor de prelucrare a datelor, deoarece un algoritm distribuit diferă substanŃial de un algoritm centralizat datorită, în principal, particularităŃii sistemelor distribuite : baze de date distribuite, tranzacŃii în desfăşurare, timpul de acces la baza de date, criptarea datelor,etc.;
• transmiterea documentelor în format electronic – din punct de vedere juridic, documentul electronic are aceeaşi putere pe care o are documentul scris, prin gestionarea riguroasă a semnăturii electronice şi a metodelor electronice de autentificare. Sistemele de management a documentelor electronice sunt, în momentul de faŃă, în plin avânt de pătrundere la nivelul companiilor.
Stimularea, printr-un cadru legal, a circulaŃiei documentelor electronice, conduce la reproiectarea de sisteme informatice distribuite, în care comunicarea directă cu alte sisteme este realizată, exclusiv, prin intermediul documentelor electronice. Sistemele informatice, care nu mai operează cu documente imprimate, prezintă numeroase avantaje:
• creşterea vitezei de soluŃionare a problemelor;
• gestionarea strictă a intrărilor şi ieşirilor de documente electronice;
• transparenŃa proceselor care se derulează;
• eliminarea birocraŃiei de la ghişeu în favoarea proceselor active şi eficiente;
• reducerea duratei de regăsire în arhivă;
• eliminarea pierderilor de documente din cauza neglijenŃei sau distrugerii, întrucât gestiunea lor este un proces asistat de produse software, în care securitatea este esenŃială pentru baza de date;
• profesionalizarea manipulării cu documente, întrucât utilizarea sistemelor de management, a documentelor electronice, impune obŃinerea obligatorie a unei calificări recunoscute şi acceptate;
• crearea responsabilităŃii privind primirea, studierea, utilizarea informaŃiei conŃinută în documente electronice, cel putin la acelaşi nivel cu situaŃia în care se lucra pe documente imprimate, sau documente olografe.
Unele sisteme distribuite sunt destinate numai pentru adăugarea de informaŃii în baza de date (only adding ) şi pot fi efectuate numai operaŃii de adăugare şi de arhivare a informaŃiilor stocate. În aceste aplicaŃii, sunt excluse modificările şi ştergerile de informaŃii şi se accentuează rolul pe care îl au bazele de date, în care mentenanŃa se realizează prin adăugare de informaŃii noi. ExistenŃa şi crearea de baze de date la nivel naŃional impune proiectarea de sisteme şi aplicaŃii distribuite de acest tip, cum ar fi:
• baza de date pentru evidenŃa populaŃiei - permite prelucrarea de date privind identitatea cetăŃenilor;
• baza de date a educaŃiei - permite prelucrarea de date privind studiile şi calificările cetăŃenilor;
• baza de date a fiscului - permite prelucrarea de date privind veniturile, taxele şi impozitele;
Investeşte în oameni!
Pagina 163
• baza de date a agenŃilor economici - permite prelucrarea de date privind locurile de muncă şi estimări pentru controlul şomajului;
• baza de date pentru asigurările sociale – permite evidenŃa şi controlul asigurărilor de sănătate şi pensiilor.
Sistemele distribuite, implementate până în prezent, evidenŃiază o varietate arhitecturală
mare. Cu toate acestea, ele au în comun o serie de caracteristici şi împărtăşesc unele probleme comune în dezvoltarea lor. Caracteristicile comune şi aspectele legate de proiectarea sistemelor distribuite pot fi prezentate sub forma unor modele descriptive. Fiecare astfel de model va reprezenta o descriere abstractă, simplificată dar consistentă a aspectelor relevante ale proiectării sistemelor distribuite. O definiŃie standard, universal acceptată, pentru arhitectura sistemului informatic, este greu de dat, majoritatea opiniilor exprimate punând în centrul atenŃiei conceptele de componenŃă şi conexiune. Una dintre definiŃiile mai recente consideră arhitectura programelor ca fiind structura sau structurile care privesc componentele programului, proprietăŃile externe ale acestor componente, precum şi relaŃiile dintre ele. În funcŃie de semnificaŃia noŃiunii de componenŃă, arhitectura sistemelor informatice poate fi definită într-un sens restrâns şi într-un sens mai larg. Proiectarea arhitecturii unui program poate viza, în sens restrâns, componentele programului, respectiv modulele acestuia, însă ea poate fi extinsă prin includerea bazei de date şi a componentei middleware, care permite configurarea comunicării într-un sistem client/server. ProprietăŃile acestor componente sunt acele caracteristici care permit înŃelegerea modului în care ele interacŃionează, respectiv modul de apelare a unui modul din alt modul sau mecanismul de accesare a bazei de date de către modulele programului. Proiectarea arhitecturală a programului nu ia în considerare proprietăŃile interne ale componentelor, cum ar fi detaliile unui algoritm specific unui modul. RelaŃiile dintre componente se pot referi fie la apelarea unei proceduri, cu transmiterea eventuală a datelor necesare execuŃiei procedurii respective, fie la protocolul de accesare a bazei de date de către procedurile de program. Obiectivul general, urmărit în cadrul proiectării arhitecturale, vizează conceperea unei structuri a sistemului, care să corespundă cerinŃelor prezente şi celor viitoare, astfel încât sistemul să fie sigur în funcŃionare, adaptabil, uşor de gestionat, eficient. O bună proiectare arhitecturală se va traduce într-un sistem uşor de implementat, testat şi modificat. Multitudinea sistemelor informatice distribuite, implementate până în prezent, relevă o varietate mare a arhitecturilor, dar care pot totuşi fi încadrate în câteva modele arhitecturale. Un model arhitectural defineşte modul în care interacŃionează între ele componentele unui sistem, precum şi localizarea (maparea) lor într-o reŃea de calculatoare. Modelul arhitectural al unui sistem distribuit are rolul de a simplifica şi abstractiza funcŃiile componentelor sistemului (în sensul de a evidenŃia caracteristicile esenŃiale ale sistemului) şi trebuie să ia în considerare următoarele:
• plasarea componentelor în cadrul reŃelei, căutând să definească modelele corespunzătoare de distribuire a datelor şi a prelucrărilor;
Investeşte în oameni!
Pagina 164
• interacŃiunile dintre componente, definind rolurile lor funcŃionale şi modul de comunicare dintre ele.
Modelele de alocare a sarcinilor de lucru într-un sistem distribuit se reflectă direct asupra performanŃelor şi eficacităŃii sistemului rezultat. Localizarea componentelor unui sistem distribuit este determinată de aspectele de performanŃă, siguranŃă în funcŃionare, securitate şi de costurile implicate. 4.2.1 Sisteme informatice client / server pe două niveluri
În general, puŃine sunt problemele legate de dezvoltarea sistemelor distribuite, în care se înregistrează un consens în rândul specialiştilor. Un aspect, asupra căruia se înregistrează un larg consens în rândul cercetătorilor şi practicienilor, priveşte organizarea componentelor unui sistem distribuit prin folosirea termenilor client, care solicită servicii unui server, astfel încât să faciliteze înŃelegerea şi controlul complexităŃii sistemelor distribuite. Arhitectura client/server reprezintă modelul arhitectural cel mai utilizat la dezvoltarea sistemelor distribuite. O aplicaŃie informatică distribuită, dezvoltată după modelul client/server, este descompusă în două grupuri de procese: consumatorii de servicii, numiŃi clienŃi şi furnizorii de servicii, numiŃi server, care comunică între ele prin schimbul de informaŃii de tip cerere-răspuns (Figura 3).
Figura nr.3 Procesarea cererilor într-o arhitectură client/server pe două niveluri
De exemplu, un server poate fi conceput pentru a oferi un serviciu de baze de date clienŃilor
săi. FuncŃional, serverul este independent de client, iar relaŃia dintre client şi server este de comunicare în ambele sensuri. Ea se diferenŃiază radical de aplicaŃiile centralizate, în care relaŃia este de tip master-slave. În modelul client/server, clientul solicită serverului execuŃia unui serviciu prin transmiterea unui cereri. La rândul său, serverul va transmite clientului rezultatul solicitării sale. Diferitele funcŃii ale aplicaŃiei informatice sunt regrupate sub forma programelor client şi server, fiecare cu roluri bine definite. Pentru utilizator, totul este transparent, comunicarea facându-se cu
Client
Server
Cerere client
Răspuns server
Procesare cerere
Aşteptare răspuns
Procese
Investeşte în oameni!
Pagina 165
programul client, iar schimbul de informaŃii, realizat între programele client şi server, îi sunt transparente, el percepând aplicaŃia ca un ansmablu executat doar pe postul său de lucru. Arhitectura client/server poate fi definită ca un model de dezvoltare a aplicaŃiilor conform căruia sistemul informaŃional este descompus într-un mare număr de funcŃii server, executate pe una sau mai multe platforme hardware. Acestea furnizează servicii comune unui număr mare de funcŃii client, executate pe una sau mai multe platforme hardware interconectate şi care realizează sarcini bine definite, în legatură cu serviciile furnizate de funcŃiile server.
În practică, se pot întâlni şi următoarele situaŃii:
• un server poate apela la serviciile furnizate de către un alt server, obŃinându-se o relaŃie client-server pe mai multe straturi;
• programele client şi server se pot găsi pe acelaşi calculator, un exemplu în acest sens constituindu-l schimburile inter-aplicaŃii de tip DDE (Dynamic Data Exchange).
Din cele prezentate mai sus, se poate clarifica diferenŃa dintre sistemele distribuite şi sistemele client/server. Astfel, într-un sistem client/server nu este obligatoriu ca cele două grupe de funcŃii (client şi server) să fie localizate pe calculatoare diferite, ele putând fi rezidente pe acelaşi calculator, dar de cele mai multe ori arhitectura client/server este implementată într-un sistem distribuit. Pe de altă parte, un sistem distribuit nu implică neaparat arhitectura client/server. Arhitectura cvasi-utilizată la dezvoltarea sistemelor distribuite este reprezentată de modelul client/server, însă nu este singura alternativă. Aşadar, deşi diferite conceptual, de cele mai multe ori, în practica dezvoltării sistemelor informaŃionale, se poate pune semnul de egalitate între sistemele distribuite şi sistemele client/server. Această arhitectură presupune descompunerea aplicaŃiei în următoarele două niveluri:
• nivelul corespunzător aplicaŃiei - în care se includ interfaŃa grafică cu utilizatorul, respectiv logica prezentării şi implementarea regulilor de afaceri (business rules), respectiv logica aplicaŃiei. Tot acest nivel poate coordona şi logica tranzacŃiei care garantează că actualizările în baza de date, specifice unei tranzacŃii, sunt terminate complet (validate sau anulate);
• nivelul corespunzător bazei de date - care este responsabil de menŃinerea integrităŃii bazei de date. În acest nivel, poate fi implementată întreaga logică a tranzacŃiei, sau o parte a ei.
DistincŃia dintre cele două straturi nu este întotdeauna bine definită, deoarece logica tranzacŃiei este adesea implementată pe serverul de baze de date , sub forma procedurilor stocate, iar regulile afacerilor, parte a logicii aplicaŃiei, sunt de asemenea implementate pe server, sub forma trigger-ilor. În plus, sunt întâmpinate greutăŃi considerabile în dezvoltarea sistemului informaŃional, pe baza creşterii accentuate a numărului de aplicaŃii, a numărului şi tipului serverelor de baze de date. Această deficienŃă poate fi rezolvată prin introducerea unui nivel suplimentar, care să trateze regulile afacerii, rezultând o arhitectură cu trei niveluri. 4.2.2 Sisteme informatice client / server pe trei niveluri
Modelul client/server a constituit subiectul multor dezbateri şi controverse. Problema principala este legată de distincŃia clară dintre funcŃionalitatea clientului şi cea a serverului. Proiectarea sistemelor client/server presupune conceperea arhitecturii aplicaŃiilor pe niveluri bine definite. O astfel de abordare permite proiectarea independentă a nivelurilor, singura grijă constând în definirea clară şi proiectarea atentă a interfeŃelor, urmărindu-se ca:
Investeşte în oameni!
Pagina 166
• fiecare nivel să aibă un domeniu bine definit - în sensul definirii foarte clare a sarcinilor şi responsabilităŃilor fiecăruia;
• fiecare nivel trebuie să îndeplinească o sarcină specifică – dacă un nivel este responsabil cu interacŃiunea cu utilizatorul, atunci numai acel nivel va comunica cu utilizatorul, celelalte realizând acest lucru prin intermediul acestuia, dacă au nevoie de informaŃii de la utilizator;
• stabilirea unor protocoale bine definite, pentru interacŃiunea dintre niveluri - interacŃiune care să se realizeze numai prin intermediul acestor protocoale.
Arhitectura pe trei niveluri presupune împărŃirea aplicaŃiei în următoarele straturi:
• gestiunea interfaŃei utilizator (gestiunea prezentării) – priveşte dialogul între utilizatori şi aplicaŃie, incluzând aici logica de prezentare a informaŃiei (ansamblul prelucrărilor efectuate asupra
• datelor necesare afişării lor);
• logica aplicaŃiei - cuprinde ansamblul operaŃiilor de prelucrare, specifice aplicaŃiei şi înlănŃuirea lor logică;
• gestiunea datelor – rezolvă cererile de date, asigură integritatea datelor, emiterea anumitor mesaje de alertare, precum şi gestiunea fizică a datelor (adăugări, modificări, ştergeri).
În esenŃă, arhitectura pe trei niveluri diferă de cea pe două, prin separarea logicii aplicaŃiei într-un nivel distinct, localizat de regulă pe un server de aplicaŃii, care comunică strâns cu serverul de baze de date (Figura 4). Introducerea unui nivel intermediar permite definirea şi implementarea regulilor afacerii, independent de logica prezentării interfeŃei utilizator şi a regulilor de proiectare a bazei de date. Acest avantaj devine evident, în condiŃiile în care regulile afacerii sunt supuse mai des modificărilor, facilitând astfel reimplementarea lor. InterfaŃa utilizator Logica aplicaŃiei Gestiunea datelor Client Server de aplicaŃii Server de baze de date
BD
Investeşte în oameni!
Pagina 167
Figura nr. 4 Arhitectura client/server pe trei niveluri În esenŃă, arhitectura pe trei niveluri diferă de cea pe două, prin separarea logicii aplicaŃiei într-un nivel distinct, localizat de regulă pe un server de aplicaŃii, care comunică strâns cu serverul de baze de date. Introducerea unui nivel intermediar permite definirea şi implementarea regulilor afacerii, independent de logica prezentării interfeŃei utilizator şi a regulilor de proiectare a bazei de date. Acest avantaj devine evident, în condiŃiile în care regulile afacerii sunt supuse mai des modificărilor, facilitând astfel reimplementarea lor. Dacă cele trei niveluri vor fi implementate pe calculatoare diferite, atunci vom avea situaŃia în care un server va juca şi rolul de client. FuncŃionarea unei arhitecturi pe trei niveluri este prezentată în Figura 5. Se observă că programele care formează stratul logicii aplicaŃiei sunt rezidente pe un server separat.
Figura nr. 5 Procesarea cererilor într-o arhitectură client/server pe trei niveluri
Printre avantajele unei arhitecturi client/server distribuită pe trei niveluri, enumerăm:
• performanŃa - aplicaŃiile rulează într-un strat dedicat, bazat eventual pe resurse proprii şi tehnologii ale caror scop esenŃial este atingerea unei viteze de execuŃie superioare şi a unei scalabilităŃi superioare;
Client
Server
AplicaŃii Cerere client Răspuns server
Prelucrare date
Aşteptare răspuns
Timp
Cerere date
Server Baze Date
Procesare cerere
Furnizare date
Investeşte în oameni!
Pagina 168
• mentenanŃa - întreŃinerea şi reinstalarea aplicaŃiilor sau a unor părŃi ale acesteia, în cazul schimbării regulilor afacerii, este mult simplificată prin administrarea separată, centralizată, a componentelor lor;
• reutilizare - componentele dezvoltate pot fi construite astfel încât funcŃionalitatea lor să fie partajate între mai multe aplicaŃii;
• suport multi-limbaj - aplicaŃiile dezvoltate pe componente pot fi scrise în mai multe limbaje de programare (Java, C++, C#, etc) şi pot fi făcute interoperabile, chiar dacă lucrează pe platforme diferite (.NET, J2EE);
• scalabilitate şi echilibrarea solicitării resurselor - componentele pot fi distribuite pe mai multe servere, ceea ce permite ridicarea pragului de scalabilitate, în condiŃiile păstrării parametrilor de performanŃă şi disponibilitate a aplicaŃiilor;
• eficientizarea accesului la date - serverele de baze de date nu vor mai fi solicitate de un număr mare de cereri de acces, gestiunea cererilor clienŃilor revenind serverelor de aplicaŃii (deci stratului intermediar). În acest mod, clienŃii nu mai sunt nevoiŃi să se conecteze direct la baza de date şi, prin urmare, nu vor mai avea nevoie de drivere specifice (ca în cazul arhitecturii pe două straturi);
• îmbunătăŃirea securităŃii - componentele din stratul intermediar pot fi gestionate, din punctul de vedere al securităŃii, printr-o infrastructură centralizată comună, determinând simplificarea şi reducerea costurilor de administrare.
În prezent, se manifestă tendinŃa dezvoltării aplicaŃiilor multinivel, în care pot exista mai mult de trei niveluri, atât din punct de vedere logic cât şi fizic. Acest lucru este posibil datorită apariŃiei unei noi tehnologii în dezvoltarea sistemelor informaŃionale, referită prin sintagma orientată pe componente. Această nouă abordare coroborată cu libertatea în distribuirea componentelor, datorită apariŃiei unor cerinŃe de comunicare specifice protocoalelor (API), determină orientarea către dezvoltarea de aplicaŃii client/server multistrat.pt sunt entitati software. M
ACTIVITAłI PRACTIC – APLICATIVE PENTRU TEMA 7 Obiectivele activităŃilor practic-aplicative:
• fixarea cunoştinŃelor legate de arhitecturi de baze de date;
• introducerea în baze de date distribuite;
• descrierea aplicaŃiilor software distribuite;
• prezentarea avantajelor şi dezavantajelor aplicaŃiilor software distribuite.
A.1 Se vor da exemple practice de realizare a arhitecturilor de baze de date. Se vor prezenta pe scurt arhitectura bazelor de date pentru câteva aplicaŃii comerciale mai cunoscute. Se vor purta discuŃii pe baza tipurilor de arhitecturi şi care sunt avantajele pentru fiecare în parte. Se va cere să se propună o arhitectură de baze de date pentru o aplicaŃie didactică.
Investeşte în oameni!
Pagina 169
A.2 Se vor prezenta câteva aplicaŃii software comerciale cu baze date distribuite. Se vor prezenta modele de aplicaŃii tip ERP(Enterprise Resource Planning) şi CRM(Costumer Resource Management). Se vor purta discuŃii despre avantajele şi dezavantajele aplicaŃiilor software distribuite. Se va propune o aplicaŃie didactică şi se va cere să se specifice arhitectura care se consideră cea mai potrivită şi care sunt motivaŃiile pentru alegerea facută.
NoŃiunea de securitate a bazei de date poate avea sensul de protejare împotriva accesului neautorizat la informaŃii dar şi o strategie de stocare în condiŃii de maximă siguranŃă la nivel fizic, în sensul păstrării integrităŃii bazei de date. În sistemele moderne de baze de date, securitatea este asigurată pe mai multe niveluri şi se pot aminti următoarele:
� controlul accesului la nivelul sistemului de operare; � controlul accesului la o reŃea locală sau Internet; � controlul accesului la nivel de aplicaŃie software ; � controlul accesului la nivel de SGBD (Sistem de Gestiune a Bazei de Date).
1. Securitatea la nivelul sistemului de operare
1.1 Rolul administratorului de sistem
Este primul nivel de securitate, care apare în momentul în care un user încearcă să se conecteze la un server sau la o simplă staŃie de lucru. Drepturile de acces sunt gestionate de administratorul serverului sau calculatorului local, prin parole de acces alocate fiecărui user.
Investeşte în oameni!
Pagina 171
Din punct de vedere al securităŃii, problemele generale care trebuie rezolvate de către administrator sunt :
• administrarea contului de root;
• administrarea conturilor utilizatorilor;
• limitarea accesului prin firewall;
• protecŃia împotriva viruşilor;
• activarea sau dezactivarea anumitor servicii;
• securizarea porturilor de comunicaŃie;
• rularea programelor specifice pentru detectarea breselor de securitate;
• update pentru fişiere de securitate la anumite perioade de timp.
Fiecare sistem de operare are puncte forte şi puncte slabe, privind securitatea şi funcŃionalitatea şi de aceea alegerea trebuie facută de specialişti cu experienŃă în domeniu. De multe ori, se întamplă ca alegerea sistemului de operare să fie bine facută, dar se foloseşte doar o mică parte din facilităŃile pe care le poate oferi. Oricât de bine ar fi proiectată o aplicaŃie software, dacă rulează pe o platformă neperformantă, sau cu carenŃe privind securitatea, speranŃa de viaŃă este foarte mică, sau beneficiarul nu va avea niciodată încredere să o utilizeze. De aceea, dezvoltatorii analizează foarte atent cerinŃele aplicaŃiei, din punct de vedere al securităŃii şi aleg cu atenŃie platforma pe care va rula, în urma comparării avantajelor şi dezavantajelor fiecărui sistem de operare. Trebuie specificat că un nivel înalt de securitate implică şi costuri mai mari şi este destul de greu de convins un beneficiar, fără cunoştinŃe solide de specialitate, să aleagă o astfel de configurare a aplicaŃiei faŃă de una cu funcŃionatitate similară, dar fără pretenŃii prea mari de securitate. De regulă, se găseşte un echilibru între arhitectura hardware, funcŃionalitatea aplicaŃiei, securitatea datelor şi costurile de implementare şi exploatare. O practică des întâlnită este ca dezvoltatorii de aplicaŃii să folosească cât mai mult resursele hardware existente ale beneficiarului în ideea că cea mai mare parte a bugetului alocat pentru implementare va fi direcŃionat către aplicaŃia software şi foarte puŃin în infrastructură şi securitate. Dacă se aplică acest principiu, chiar cu acordul beneficiarului, implementarea poate ajunge la un moment dat într-un impas, deoarece beneficiarul va fi nevoit să aloce un buget suplimentar pentru modernizarea infrastructurii şi relaŃiile contractuale se deteriorează uneori iremediabil. 1.2 Criptarea fişierelor de sistem
Criptarea fişierelor este o metodă avansată de securitate şi se poate
face individual, la nivel de director, la nivel de partiŃie logică sau disk şi oricare din metode implică existenŃa unei chei de criptare. Utilizarea cheilor de criptare este sarcina key manager-lui care generează, stochează şi înlocuieşte cheile pe baza unui protocol de criptare şi a algoritmilor specifici. Key Manager administrează serverele de chei (key servers), protocoalele de criptare (cryptographic protocol) şi procedurile de utilizare (user procedures). În practică, administrarea cheilor de criptare este o problemă dificilă şi Ńine cont de multiple aspecte, cum ar fi politica de securitate, pregătirea utilizatorilor, interacŃiunea dintre diferite departamente ale companiei, etc. Protocolul de criptare descrie cum pot fi folosiŃi algoritmii de criptare şi tratează în general următoarele aspecte:
Investeşte în oameni!
Pagina 172
• cheia de criptare;
• metoda de autentificare;
• tipul de criptare utilizat;
• securizarea datelor de transport.
De exemplu, Transport Layer Security (TLS) este un protocol utilizat pentru securizarea conexiunilor web (HTTP) , are un mecanism de autentificare bazat pe standardul X.509 şi foloseşte o criptare simetrică. Criptarea la nivel de fişier sau director are unele avantaje cum ar fi:
• fiecare fişier sau director poate avea o cheie separată de criptare;
• în cazul unei arhive, decriptarea se va face numai pentru fişierul sau directorul respectiv;
• accesul poate fi controlat atât printr-o cheie privată, cât şi printr-o cheie publică.
Trebuie specificat că algoritmii bazaŃi pe chei simetrice sunt de sute sau chiar mii de ori mai rapizi decât cei bazaŃi pe chei asimetrice, ceea ce implică o alegere foarte atentă, atunci când volumul de date este foarte mare.
2. Securitatea la nivelul reŃelei locale sau Internet
2.1 Algoritmi de criptare/decriptare ReŃelele locale de calculatoare sunt cele mai puŃin expuse accesului neautorizat, dacă
administratorul face o configurare corespunzătoare. Există o diversitate de categorii de persoanal care ar putea comite fraude cu consecinŃe mai puŃin grave, cum ar fi angajaŃii care vor să afle salariul sau primele colegilor, caracterizările sau rezultatele testelor, informaŃii despre partenerii de afaceri, etc., dar şi fraude cu consecinŃe grave, cum ar fi distrugerea de informaŃii compromiŃătoare, modificarea bazei de date, fraude financiare, spionaj informatic, etc. Pe baza studiilor, s-a constatat că aproximativ jumătate din cauzele de pierdere sau instrăinare de date confidenŃiale sunt puse pe baza fraudelor, iar restul pe baza greşelilor umane sau accidentelor tehnice. Cu toate că înstrăinarea datelor face parte din categoria atacurilor pasive, care nu implică alterarea datelor, efectele pot fi la fel de mari ca în cazul atacurilor active, soldate cu pierderea sau coruperea fişierelor şi datelor. Chiar dacă reŃeaua este izolată de exterior, pot exista totuşi sute sau mii de utilizatori locali, de aceea politica de securitate nu trebuie minimalizată. De regulă, în companiile mari, există unul sau mai multe servere accesate numai de angajaŃi şi controlul accesului se face pe baza de parole şi drepturi de acces.
În cazul unei reŃele Internet, problemele de securitate se amplifică, deoarece aria de desfăşurare este mult mai mare ca număr de persoane, apartenenŃă socială, sau distribuŃie geografică. Un număr tot mai mare de companii îşi dezvoltă afacerile prin intermediul Internetului, iar volumul tranzacŃiilor aproape se dublează de la un an la altul. Cine face această opŃiune trebuie să ştie că, aproape inevitabil, trebuie să se angajeze într-o luptă de securitate informaŃională. Dacă afacerile devin mult mai uşor accesibile, numărul beneficiarilor este mai mare, iar numărul angajaŃilor mai mic, trebuie luate în calcul şi costurile pe care le implică măsurile de scădere a vulnerabilităŃii
Investeşte în oameni!
Pagina 173
reŃelei. Şi în cazul Internetului, pot fi identificate fraude cu consecinŃe mai puŃin grave, ca citirea neautorizată a corespondenŃei, virusarea unor utilitare sau aplicaŃii, blocarea tranzacŃiilor, etc., dar şi fraude cu consecinŃe foarte grave, ca distrugerea bazei de date, coruperea ireversibilă a unor fişiere, fraude bancare sau comerciale, etc. Cu toate aceste riscuri majore, afacerile prin intermediul Internetului, cu siguranŃă, vor continua să se dezvolte, deoarece marile companii din domeniul IT scot pe piată produse din ce în ce mai performante, cât şi mai sigure. Din păcate, nici industria hacker-ilor nu rămâne în urmă, existând o luptă permanentă şi nevazută între cei ce asigură securitatea tranzacŃiilor şi cei care caută o breşă cât de mică în sistemul de securitate informatică. Acest fenomen infracŃional are şi consecinŃe ‘pozitive‘, deoarece forŃează dezvoltatorii de software să îmbunătăŃească aplicaŃiile scoase pe piaŃă, sau să găsească noi tehnici de securitate. Pentru transmiterea datelor prin Internet, se pot folosi, în general, aceleaşi tehnici de criptare folosite pentru fişiere. Algoritmii de criptare/decriptare, care folosesc aceeaşi cheie, fac parte din categoria algoritmilor simetrici şi implică cunoaşterea cheii secrete, atât de emiŃător, cât şi de receptor.
În practică, acest lucru reprezintă un punct slab, deoarece transmiterea cheii de criptare între cele două părŃi suportă un risc major de interceptare şi astfel toată criptarea poate fi compromisă. O soluŃie ar fi ca transmiterea cheii să se facă pe o linie protejată, dar acest lucru implică costuri suplimentare.
Figura nr. 1 Schema de aplicare a unui algoritm simetric
O tehnică mai nouă o reprezintă utilizarea algoritmilor asimetrici, care folosesc o cheie de criptare la emiŃător (care poate fi o cheie publică) şi o altă cheie de decriptare la receptor(care este o cheie privată).
Canal securizat pentru schimbul cheilor
Receptor
Criptare cu
cheie publică
Decriptare cu
cheie privată
Criptare cu
cheie unică
Decriptare cu
cheie unică
Mesaj
necriptat
Mesaj
decriptat
EmiŃător
Mesaj
criptat
Mesaj
criptat
Investeşte în oameni!
Pagina 174
Figura nr. 2 Schema de aplicare a unui algoritm asimetric
Dacă criptarea se face cu o cheie care poate fi publică, deci cunoscută de mai multe persoane, în schimb decriptarea se face numai cu o cheie privată care trebuie sa fie o pereche a cheii publice. Astfel, în cazul utilizării unui algoritm asimetric în comunicarea dintre un emiŃător şi un receptor, fiecare dintre aceştia va deŃine câte o pereche de chei: publică şi privată. EmiŃătorul poate cripta mesajul cu cheia publică a receptorului, astfel încât doar acesta să poată decripta mesajul cu cheia sa privată. În cazul unui răspuns, receptorul va utiliza cheia publică a emiŃătorului, astfel încât decriptarea să se poată face exclusiv de către emiŃător, folosind cheia sa pereche. Nivelul de securitate este dat de dimensiunea cheii de criptare, adică cu cât numărul de biŃi, care formează cheia, este mai mare, cu atăt posibilitatea de ‘spargere’ este mai mică şi implică un timp mult mai mare. Ca metode complexe de criptare, unii criptografi folosesc algoritmi simpli asociaŃi cu chei de securitate foarte lungi. Mai nou, se urmăreşte crearea unor algoritmi de criptare foarte complecşi, încât să fie practic ermetici, chiar dacă se interceptează un volum mare de date criptate. Criptografia modernă foloseşte, mai nou, dispozitive hardware complexe, special concepute să se conecteze în cascadă, astfel încât complexitatea decriptării să crească foarte mult, la o viteză de criptare/decriptare mult mai mică. Utilizarea algoritmilor de criptare nu asigură însă confidenŃialitatea totală, adică orice mesaj criptat poate fi în general decriptat fără a deŃine cheia corespunzătoare, dar acest lucru implică multe resurse materiale şi timp. Dacă procesul de decriptare implică costuri foarte mari, este puŃin probabil ca o persoană neautorizată să meargă până la capăt, deoarece, în final, se poate constata că datele nu mai sunt de actualitate, sau nu au importanŃa scontată. Cei mai cunoscuŃi algoritmi simetrici de criptare pentru informaŃii nesecrete sunt DES (Data Encryption System) lansat de IBM şi foloseşte o cheie pe 56 biŃi, fiind destul de mult utilizat în industrie şi cel pus la punct de NSA (National Security Agency), care foloseşte o cheie pe 128 biŃi. Un algoritm performant, dar nesimetric, este RSA pus la punct de cercetătorii americani Ronald Rivest, Adi Shamir şi Leonard Adelman. În tabelul următor, se prezintă unele dintre cele mai utlizate sisteme de criptare disponibile în Internet şi algoritmii pe care se bazează.
Denumire Utilizare Algoritmi
Mesaj
necrip
tat
Mesaj
decriptat
EmiŃător Receptor
Mesaj
criptat
Mesaj
criptat
Investeşte în oameni!
Pagina 175
SSH (Secure Shell) ProtecŃie pentru Telnet la transferul de fişiere
RSA, Diffie-Hellman,
DES, Triple DES
SSL (Secure Socket Layer)
Protocol criptare transmisii TCP/IP
RSA, RC4, MD5
PCT (Private Communications
Technology)
Protocol criptare transmisii TCP/IP
RSA, RC4, MD5
S-HTTP – Secure- HyperText Transfer
Protocol pentru criptarea cererilor
şi răspunsurilor HTML
RSA, DES
SET (Secure Electronic
Transaction)
Protocol criptare tranzacŃii de plată prin Internet
RSA, MD5, RC2
CyberCash
Protocol criptare tranzacŃii de plată prin Internet
RSA, MD5, RC2
Ipsec, Ipv5 Protocol de nivel scăzut pentru
criptarea pachetelor IP
Diffie-Hellman
DNSSEC (Domain Name System
Security)
Sistem pentru securizarea DNS
RSA, MD5
Kerberos Securitate în reŃea pentru aplicaŃiile de nivel înalt
DES
S/MIME – Secure Multipurpose Internet Mail Extension
Format pentru criptarea poştei electronice
SpecificaŃii utilizator
PGP (Pretty Good Privacy)
AplicaŃie pentru criptarea poştei
electronice
MD5, IDEA, RSA
RSA - Algoritm de criptare pentru chei publice dezvoltat de Rivest, Shamin, Aldemann. DES - Data Encryption Standard. Triple DES - Criptează datele aplicând de trei ori algoritmul DES. IDEA - International Data Encryption Algorithm. MD5 - Message Digest 5. RC4 – Algoritm dezvoltat de RSA Security Inc. Diffie-Hellman – Algoritm pentru criptarea comunicaŃiilor secvenŃiale folosind cheie simetrică.
Investeşte în oameni!
Pagina 176
Dacă criptarea se face cu calculatoare ultraperformante, cu număr mare de microprocesoare, timpul de decriptare scade foarte mult. Deoarece timpul creşte exponenŃial cu mărimea cheii, se pot folosi chei de criptare pe 2048 biŃi, sau chiar mai mari. Utilizatorii de rând ai Internetului pot folosi chei publice de criptare care nu implică un schimb de chei pe linii securizate. În acest fel, nu trebuie luate măsuri de securitate extreme pentru păstrarea secretului unei chei de criptare, dar pentru decriptare nu se poate folosi decât o singură cheie, cunoscută numai de destinatar şi în felul acesta, datele odată criptate nu mai pot fi decriptate nici măcar de expeditor. 2.2 Metode de autentificare
Criptografia modernă a evoluat foarte mult şi în domeniul protocoalelor de autentificare, prin care se verifică identitatea celui care expediază date. Procesul de verificare a identităŃii este dificil şi necesită utilizarea unor protocoale complexe, bazate pe tehnici criptografice. Ca şi în cazul transmiterii de date, se poate folosi atât un protocol simetric bazat pe cheie privată, cât şi un protocol asimetric, bazat pe o cheie publică.
Figura nr. 3 Semnarea digitală a mesajelor necriptate
Un exemplu de largă utilizare a cheii publice este conectarea la distanŃă pe un server, folosind
protocolul ssh bazat pe algoritmul RSA. Autentificarea constă în verificarea unei semnături digitale, astfel încât receptorul să poată verifica identitatea emiŃătorului, dar şi să poată face o dovadă ulterioară că emiŃătorul este cel real, iar receptorul să nu poată genera el însuşi o semnatură digitală falsă. Cel mai potrivit exemplu ar fi un sistem de plăŃi electronice, în care sistemul bancar trebuie să verifice semnătura digitală a celui care
Mesaj
necriptat
-----------
Semnatura
necriptată
EmiŃător Receptor
Criptare
semnatură cu
cheie privată
Mesaj
necriptat
Semnatura
Digitala
Criptată
Mesaj
necriptat
-----------
Semnatura
decriptată
Mesaj
necriptat
Semnatura
Digitala
Criptată
Decriptare
semnatură cu
cheie publică
Investeşte în oameni!
Pagina 177
emite un ordin de plată, dar şi să protejeze clientul, în cazul unei încercări de fraude, prin emiterea unei semnături digitale falsificate din exteriorul sau interiorul băncii. În aceste situaŃii, de obicei, se folosesc chei publice.
Trebuie specificat că, în cazul semnăturilor digitale, datele nu trebuie neapărat criptate. Pentru a mări însă securitatea datelor, se pot combina cele două metode, adică atât criptarea datelor, cât şi semnătura digitală, folosindu-se două chei diferite.
Pentru a reduce timpul de transmisie şi criptare/decriptatre, se poate folosi o criptare cu cheie publică pentru tranmiterea cheii private secrete(se poate utiliza chiar autentificarea expeditorului), apoi datele vor fi transmise criptate, folosind un algoritm simetric cu cheia anterioară.
O autentificare cât mai riguroasă se poate face cu sisteme şi mai complexe, care implică certificarea fiecărui utilizator, căruia i se atribuie o cheie publică şi o cheie privată de către o organizaŃie acreditată în acest sens. Deoarece cheia publică este unică, o persoană se poate foarte uşor identifica în baza de date. Mai mult, o organizaŃie acreditată poate împuternici altă organizaŃie să emită certificări, astfel încât verificarea autenticităŃii să se facă pe toată structura arborescentă. Metoda certificării îşi găseşte din ce în ce mai mult utilitatea în aplicaŃii bancare, comerŃ electronic, telecomunicaŃii, sau chiar la instalarea aplicaŃiilor software pe baza de licenŃe, unde se poate face mai întâi o autentificare, pentru a fi siguri că aplicaŃia este originală şi nu una piratată.
Criptarea cu chei simetrice oferă o securitate mai mică, deoarece implică adesea un schimb de chei între expeditor şi destinatar, care deasemenea trebuie securizat. Din acest punct de vedere, criptarea asimetrică aduce un plus de securitate prin folosirea cheii private şi certificatelor digitale. Trebuie menŃionat totuşi, că algoritmii asimetrici sunt mai lenŃi, deoarece operează cu funcŃii complexe şi chei mai mari. Un algoritm este mai sigur cu cât lungimea cheii de criptare este mai mare, deaorece numărul de variante posibile de chei va creşte foarte mult. De multe ori, se pot obŃine performanŃe bune combinând cele două metode de criptare, folosindu-se criptarea asimetrică pentru transmiterea cheii secrete.
Astfel, mai întâi, expeditorul obŃine cheia publică a destinatarului, cu care va cripta cheia publică folosită pentru criptarea simetrică, după care expediază datele criptate simetric împreună cu cheia criptată asimetric, iar beneficiarul va face operaŃia similar pentru decriptare.
3. Securitatea la nivelul aplicaŃiei software Odată cu apariŃia aplicaŃiilor web, problema securităŃii a devenit din cerinŃă o necesitate, fără de
care orice sistem informatic nu ar avea o viaŃă prea lungă. În cazul sistemelor omogene, problemele sunt mai puŃine, deoarece aplicaŃiile rulează pe acceaşi platformă de operare, sunt dezvoltate în acelaşi mediu (acelaşi limbaj de programare), şi au acelaşi sistem de gestiune a bazelor de date. Pentru sistemele heterogene, care sunt de regulă şi distribuite, apar probleme de securitate mult mai complexe, deoarece rulând pe platforme de operare diferite şi fiind proiectate în diferite limbaje de programare, breşele de securitate sunt mult mai mari. Chiar dacă cresc costurile privind securitatea aplicaŃiilor şi datelor, aceste aplicaŃii au şi avantaje destul de mari, pentru a se impune pe piaŃa de software cum ar fi:
• partajarea resurselor hardaware şi software;
• posibilitatea operării pe baze de date comune;
• reducerea timpilor de acces la baze de date distribuite;
Investeşte în oameni!
Pagina 178
• schimbul de date între nodurile reŃelor mult optimizat;
• posibilitatea alocării unei alte rute când pică un nod al reŃelei;
• algoritmi de interogare mai performanŃi şi mai flexibili.
AplicaŃiile web mai au şi un specific aparte şi anume faptul că foarte puŃine documente trebuie stocate pe hârtie, cele mai multe sunt stocate, arhivate şi accesate în format electronic. Din punct de vedere legislativ, un document autentificat printr-o semnătură digitală are aceeaşi valoare juridică cu unul semnat şi ştampilat pe suport de hârtie. Trebuie menŃionat că arhivele electronice ocupă mult mai puŃin spaŃiu fizic, sunt relativ mai uşor de întreŃinut, iar accesul la informaŃie este mult mai uşor. Pentru documentele criptate, apare totuşi o dificultate în managementul cheilor de criptare, mai ales când schimbarea lor are loc destul de frecvent, iar decriptatrea se poate face decât cu cheia cu care a fost arhivat documentul la vremea respectivă. AplicaŃiile care operează cu documente în format electronic mai au şi alte avantaje, care nu trebuie neglijate, cum ar fi : micşorarea birocraŃiei, respectarea mai riguroasă a fluxurilor de documente, posibilitatea foarte redusă de pierdere, creşterea responsabilităŃii angajaŃilor, accesul şi soluŃionarea mai rapidă a cererilor, etc. În general, securizarea aplicaŃiilor distribuite implică atingerea următoarelor obiective majore:
• autentificarea accesului;
• integritatea modulelor aplicaŃiei;
• integritatea tranzacŃiilor în baza de date;
• arhivarea în siguranŃă datelor;
• confidenŃialitatea datelor.
Din punct de vedere al controlului accesului, o metodă simplă, care se poate implementa, este introducerea de parole la intrarea în meniul general al aplicaŃiei, sau chiar la intrarea în fiecare modul sau submodul. Astfel, în momentul în care un utilizator încearcă să acceseze un modul al aplicaŃiei, va trebui să cunoască o parolă alocată în prealabil. Dezavantajul este că, dacă o persoană de specialitate (dar neautorizată) va avea acces la codul sursă al aplicaŃiei, poate afla uşor parolele de autorizare. Chiar şi dacă nu are acces la sursele aplicaŃiilor, un specialist care are acces doar la sursele compilate poate ‘sparge’ parolele care sunt cuprinse, de regulă, în format alfanumeric în codul generat de compilator. O metodă mai sigură, dar mai greu de administrat, este să se facă o codificare a tuturor obiectelor pe care le conŃine aplicaŃia. Prin obiect se înŃelege orice interfaŃă utilizator(în literatura de specialitate se mai numeşte formă, formular sau machetă), orice raport sau orice procedură stocată, care necesită controlul accesului. Aceste codificări sunt folosite în alocarea drepturilor de acces pentru diferiŃi useri. Pentru exemplificare, să luăm o aplicaŃie care conŃine următoarele obiecte pentru care trebuie introduse restricŃii de acces:
• 3 interfeŃe utilizator F1, F2, F3
• 3 rapoarte R1, R2, R3
• 3 proceduri de calcul stocate pe server P1, P2, P3
Fiecare obiect va avea un cod CF1, CF2, CF3, CR1, CR2, CR3, CP1, CP2, CP3, iar în baza de date se va crea o tabelă denumită DREPTURI_ACCES cu următoarea structură :
� denumire_user
Investeşte în oameni!
Pagina 179
� cod_obiect � autorizare_acces
Drepturile de acces pentru utilizatori pot fi administrate de un supervizor(de regula administratorul aplicaŃiei) prin inserarea în baza de date a accesului (Y) sau restricŃiei (N), folosind ca model tabelul de mai jos:
User CF1 CF2 CF3 CR1 CR2 CR3 CP1 CP2 CP3 User1 Y Y N Y Y Y N Y Y User2 N Y N Y Y Y N N Y User3 Y Y Y Y Y Y Y Y Y User4 Y Y Y N N N Y Y Y
AplicaŃia software va fi proiectată astfel încât, atunci când un utilizator încearcă să acceseze
un obiect aflat în meniul aplicaŃiei, să se facă mai întâi o verificare în baza de date dacă userul alocat utilizatorului este autorizat să intre în submeniul respectiv şi numai în caz afirmativ (Y) să poată lucra cu obiectul respectiv. Ca denumire de user, se poate folosi userul de conectare la sistemul de operare sau userul de conectare la baza de date. După modelul de mai sus, se poate gestiona şi accesul la bazele de date distribuite, locul obiectelor în antetul tabelului fiind luat de host-ul fiecărei baze date. Astfel, fiecare utilizator care încearcă să acceseze o baza de date trebuie mai întâi să treacă printr-un filtru de autorizare administrat foarte riguros de un administrator. De reŃinut că fiecare metodă de autorizare arătată mai sus se implementează numai la nivelul aplicaŃiei, neavând nicio legatură cu autorizarea la nivel de sistem de operare sau la nivelul sistemului de gestiune a bazei de date (SGBD).
O altă metodă de securizare la nivel de aplicaŃie este adaptarea aplicaŃiei în funcŃie de utilizator, care se poate realiza printr-o parametrizare corespunzatoare faŃă de nivelul pe care este situat userul respectiv. Cel mai de jos nivel va conŃine userii care au acces numai la interfeŃele de introducere de date, iar cel mai înalt nivel este cel de supervizor, care permite accesul la toate modulele cu drepturi de modificare sau ştergere asupra datelor introduse de alŃi utilizatori. Acest lucru se realizează relativ simplu prin crearea de meniuri multiple specifice fiecărui nivel alocat userilor. Astfel, din meniul principal al aplicaŃiei, se poate intra într-o structură arborescentă de submeniuri, care limitează accesul unui utilizator la modulele aplicaŃiei. Administratorul trebuie însă să gestioneze foarte bine drepturile de acces la fişierele aferente fiecărui submodul al aplicaŃiei, deoarece o persoană neautorizată poate rula pe rând fiecare submodul, fără a mai trece prin filtrul impus de meniul principal. Se recomandă ca sursele aplicaŃiei să nu fie stocate pe aceeaşi maşină pe care rulează aplicaŃia şi stocate pe suporturi externe greu accesibile de persoane neautorizate. Este foarte important să se împiedice accesul la surse, deoarece o persoană de specialitate poate afla structura aproximativă a bazei de date (denumirea şi host-ul bazei de date, denumiri de tabele, denumiri şi tipuri de coloane, denumiri de proceduri stocate, e.tc.) fără a avea acces efectiv la baza de date aflată pe un alt server. În felul acesta, poate afla unde şi cum sunt stocate informaŃiile care prezintă interes, cum pot fi prelucrate datele, care sunt algoritmii de prelucrare şi multe alte informaŃii, care pot periclita securitatea aplicaŃiei şi a datelor. Odată ce s-a stabilit locaŃia şi structura bazei de date, munca se va concentra pe căutarea unei nişe de securitate privind accesul la date. Trebuie specificat că accesul la baza de date se poate face nu numai prin aplicaŃia proiectată de dezvoltator, ci şi prin alte instrumente găsite pe piaŃa de software, cum ar fi interfeŃele dedicate pentru lucru cu baza de date respectivă, sau tools-uri de dezvoltare de aplicaŃii capabile să se conecteze la tipul respectiv de bază de date. Dacă aceste instrumente nu sunt suficiente, se pot scrie miniaplicaŃii, care să preia
Investeşte în oameni!
Pagina 180
datele prin citire, fără a afecta cu nimic funcŃionalitatea sistemului, urmând ca prelucrarea lor să se facă pe un alt calculator. Dacă breşele de securitate sunt prea mari, se poate face chiar importul întregii baze de date şi exportul într-o nouă baza de date, care poate lucra cu acelaşi sistem de gestiune, sau cu un sistem de gestiune a bazei de date total diferit.
4. Securitatea la nivelul Sistemului de Gestiune a Bazei de Date (SGBD) 4.1 Securitatea bazei de date
NoŃiunea de securitate a unei baze de date se referă la protecŃia şi controlul accesului la date numai de către persoane autozitate în acest sens. Politica de acces este cea analizată şi implementată de administratorul bazei de date, iar controlul accesului este preluat în totalitate de către SGBD. Securitatea bazei de date poate fi organizată pe mai multe niveluri, în funcŃie de gradul de complexitate al aplicaŃiei software, importanŃa şi confidenŃialitatea datelor.
Primul nivel este la nivelul user-lui şi se realizează prin alocarea unei parole secrete de acces la fiecare user, care accesează baza de date. De cele mai multe ori, este foarte important ca fiecare utlizator al unei aplicaŃii să se conecteze cu un user propriu şi nu cu unul comun. Un prim mare avantaj este că se pot crea fişiere de log pentru a stoca informaŃii legate de tranzacŃiile efectuate pe baza de date de fiecare user în parte. Astfel, se pot stoca informaŃii despre înregistrările inserate sau modificate în baza de date, data când au fost operate (în format dată-ora-minut-secundă) şi chiar informaŃii legate de înregistrările care au fost şterse din baza de date. Cateodată, datele şterse din greşeală sau cu rea intenŃie au o valoare foarte mare şi primul pas în recuperarea lor este aflarea datei când au fost şterse, cine le-a şters şi de ce. Dacă se lucrează cu user individual, se poate afla cu exactitate cine se face vinovat, pe când în cazul unui user colectiv vinovatul nu mai poate fi identificat, deoarece uneori pot fi zeci de utilizatori care s-au conectat cu userul şi implicit cu parola respectivă. Acest lucru se întâmplă când anumiŃi beneficiari nu cumpără suficiente licenŃe software pentru toŃi angajaŃii şi încearcă să facă economie prin crearea de useri comuni.
Trebuie cântărit foarte bine dacă prejudiciile care pot fi create prin apariŃia acestei breşe de securitate nu depăşesc cu mult valoarea licenŃelor. Un alt mare avantaj al userilor individuali este responsabilizarea utilizatorilor, deoarece sunt conştienŃi că în cazul unor erori de operare pot fi uşor identificaŃi, pe când în cazul userilor colectivi vina va fi distribuită. Al doilea nivel de securitate este restricŃionarea fiecărui user în parte în privinŃa operaŃiilor pe care le poate face în baza de date. Prin operaŃii se înŃelege inserări de date, modificări, ştergeri sau numai simple interogări. În sistemele moderne, acest lucru se realizează prin grant-uri făcute userilor asupra obiectelor bazei de date, adică permisiunea de a efectua anumite operaŃii pe o anumită tabela sau fişier al bazei de date. Această responsabilitate revine administratorului bazei de date, însă sarcina nu este deloc uşoară în cazul companiilor cu sute sau mii de useri, când trebuie să analizezi şi să aloci drepturi pentru fiecare user în parte. Al treilea nivel de securitate este crearea de roll-uri colective şi alocarea acestora la grupuri mai mari de useri. Roll-urile reprezintă o grupare a mai multor operaŃii, care se pot face pe mai multe obiecte din baza de date şi alocarea lor userilor care efectuează acelaşi tip de activităŃi în cadrul unei companii. De exemplu, în cadrul departamentului de facturare, pot exista mai mulŃi angajaŃi care eliberează facturi. Pentru eliberararea unei facturi, un user trebuie să aibă drept de inserare şi
Investeşte în oameni!
Pagina 181
modificare în baza de date a facturii respective, drept de vizualizare a listei de clienŃi, a listei de produse şi a listei de preŃuri. În acest fel, se crează un roll căruia i se alocă tot printr-o grantificare numai drept de vizualizare pe tabelele sau fişierele care conŃin informaŃii despre clienŃi, produse şi preŃuri şi drept de inserare şi modificare pentru tabelele sau fişierele care conŃin informaŃii despre facturi. La acest roll, se vor grantifica toŃi userii aferenŃi angajaŃilor din departamentul de facturare. Aceste alocări de drepturi sunt făcute în urma unei analize riguroase a strategiei de securitate făcute de persoane de decizie din companie, dar numai împreună cu persoane de la departamentul IT, care cunosc foarte bine ce drepturi trebuie alocate unui tip de user, pentru ca utilzatorul să nu aibă probleme în timpul lucrului cu aplicaŃia software. În exemplul de mai sus, angajaŃii nu pot şterge facturi în baza de date, chiar dacă constată că au eliberat o factură greşită, acest lucru va fi făcut de un supervizor, care va avea alocat un alt roll care să aibă alocat drept de ştergere. 4.2 Integritatea bazei de date
NoŃiunea de integritate a unei baze de date se referă la protecŃia şi controlul datelor, astfel
încât orice inserare sau modificare de date să se facă după anumite restricŃii de integritate impuse de dezvoltator şi controlate de către SGDB. Cu alte cuvinte, integritatea unei baze de date este o modalitate de control prin care un sistem de gestiune verifică dacă datele operate în baza de date sunt corecte şi respectă anumite reguli de validitate sau de corelare cu alte date. Acest lucru se realizează prin facilităŃile oferite la nivelul sistemului de gestiune de a crea anumite constrângeri de integritate. Prin constrângeri de integritate se inŃelege un mecanism de verificare automată a corectitudii datelor, cum ar fi respectarea cheilor primare, cheilor unice şi cheilor externe, sau verificări dacă datele respectă un anumit format sau sunt nenule.
Prin cheie primară se înŃelege acea constrângere de integritate prin care se verifică dacă în baza de date nu există mai multe înregistrări care să conŃină aceleaşi date pe coloana sau coloanele definite ca fiind cheie primară, practic orice înregistrare trebuie să se identifice unic după aceste coloane. Pe un tabel al bazei de date, se poate crea o singură cheie primară şi reprezintă modalitatea de a identifica unic o înregistare la nivel de linie. De exemplu, pentru a identifica unic o factură în baza de date, se poate crea o cheie primară compusă din nr_factură şi data_factură, în ideea că nu pot exista două facturi cu acelaşi număr în aceeaşi zi.
Cheia unică este acea constrângere de integritate prin care se verifică dacă pe o coloană nu există mai multe înregistrări identice. În acest caz, dacă definim o cheie unică pe coloana de nr_factură, nu pot exista mai multe facturi cu acelaşi număr în baza de date. Dacă facturile ar primi automat un număr secvenŃial, atunci cheia unică ar face aceleaşi verificări ca şi cheia primară, însă în cazul în care numerotarea automată a facturilor s-ar reseta, de exemplu la început de an, atunci funcŃionalitatea celor două chei este diferită. Trebuie specificat că pe un tabel pot exista mai multe chei unice, dar o singură cheie primară.
Cheia externă reprezintă modalitatea prin care se poate verifica dacă datele operate în baza de date sunt corelate între ele. De exemplu, când se face plata salariului pe un card bancar, se face verificarea automată dacă CNP-ul angajatului figurează în baza de date, adică este unul dintre angajaŃii companiei. Similar, în cazul vânzărilor, atunci când se face vânzarea unui produs, se face mai întâi verificarea automată dacă produsul cu codul respectiv figurează în lista de produse, sau dacă stocul nu este epuizat.
Investeşte în oameni!
Pagina 182
Constrângerile de tip not null sau check sunt folosite pentru a verifica dacă înregistrarea conŃine informaŃii în coloana definită not null, sau respectă un anumit format. De exemplu, nu se poate face o inserare de factură în baza de date dacă câmpul de beneficiar nu este completat, sau numele localităŃii este scris cu litere mici (în acest caz se poate face conversia automata la litere mari indiferent de felul în care le introduce operatorul). O cheie primară crează în mod automat restricŃii de not null pe coloanele care o compun. Criptarea efectivă a datelor nu este suficientă din punct de vedere al integrităŃii, deoarece şi datele criptate pot fi corupte. De exemplu, alterarea sumei la efectuarea unei plăŃi prin comerŃ electronic sau efectuarea de mai multe ori a unei depuneri într-un cont bancar prin retransmiterea tranzacŃiei(replay attack). Pentru preîntâmpinarea acestui tip de atac, se utilizează o funcŃie de dispersie care calculează o sumă de control (checksum). Această funcŃie face conversia datelor de orice lungime într-o lungime fixă, care face aproape imposibilă ca două şiruri să aibe acelaşi rezultat. Suma de control este transmisă odată cu datele criptate, iar beneficiarul va decripta atât datele cât şi suma de control. Dacă suma de control la emitere diferă de suma de control la recepŃie, atunci datele au fost corupte. Ca algoritmi de dispersie, pot fi amintiŃi MD5 – Message Digest 5 care generează sume de control pe 128 biti şi SHA1 – Secure Hash Algorithm care generează sume de control pe 160 biti. 4.3 Criptarea bazei de date
Termenul criptografie provine din cuvintele de origine greacă kryptós - ascuns şi gráfein - a
scrie, care în traducere liberă ar fi o metodă de scriere ascunsă sau indescrifabilă, numită adesea şi ştiinŃa scrierilor secrete. Cu toate că ideea de criptare datează din vremea lui Cezar (cunoscută prin cifrul care ii poartă numele) criptologia este considerată de curând ca fiind o ştiinŃă care cuprinde atât criptografia cât şi criptanaliza. Preocupările în domeniul cercetării ştiinŃifice au început în anii ’70, dar dezvoltarea rapidă a industriei de IT a făcut din criptanaliză un domeniu de interes major, în care se investeşte foarte mult, atât financiar cât şi ca resurse umane. Aplicată în domeniul bazelor de date, criptografia se referă la tehnici şi metode de stocare a datelor într-o forma cifrată, pe baza unor chei, astfel încât, în cazul unui acces neautorizat, datele să nu ofere nicio informaŃie utilă.
ApariŃia calculatoarelor performante, dar mai ales dezvoltarea reŃelelor de calculatoare, au dus la apariŃia unor algoritmi de criptare cu chei complexe, care implică şi o securitate sporită în cazul atacurilor criptanalitice. Cu cât cheile de criptare au dimensiuni mai mari, cu atât mai dificilă devine spargerea cifrului, chiar dacă se cunoaşte ce algoritm de criptare s-a folosit.
Utilizarea eficientă a cheilor de criptare implică următoarele aspecte: posibilitatea de a genera rapid datele în format criptat, plecând de la formatul standard, posibilitatea de a extrage rapid datele din formatul criptat în cel standard şi dificultatea cât mai mare de a afla cheia de criptare, dacă se cunosc datele, atât în format criptat, cât şi în cel standard. Chiar dacă este criptată baza de date, nu înseamnă că oferă securitate completă şi se poate pune la dispoziŃia oricui. Dacă resursele hardware o permit, o metodă de decriptare neautorizată este ‘metoda comparaŃiei’ între datele criptate cu un anumit algoritm şi date de referinŃă criptate cu acelaşi algoritm. De exemplu, dacă se cunoaşte limba în care sunt stocate datele în format standard, se poate apela la un dicŃionar şi se codează cuvintele, obŃinându-se o bază de date criptate, de referinŃă. Apoi, se poate crea o aplicaŃie software, care va identifica fiecare dintre datele criptate printre cele de referinŃă şi în felul acesta se poate afla conŃinutul în format standard. Metoda se poate îmbunătăŃi, prin adăugarea de combinaŃii de cuvinte sau expresii uzuale în baza de date de referinŃă şi în felul acesta probabilitatea de spargere a codului va creşte.
Investeşte în oameni!
Pagina 183
Criptarea datelor are de cele mai multe ori şi efecte nedorite, în sensul afectării performanŃelor sistemului de gestiune, a aplicaŃiilor software sau a comunicaŃiilor. Sunt situaŃii când anumite coloane din tabele nu pot fi criptate, deoarece fac parte, de exemplu, din chei primare sau indecşi. Astfel, dacă o coloană a unui tabel are destinaŃia stocării CNP –lui angajaŃilor, în urma criptării coloanei, nu se mai poate face o interogare explicită pe un anumit CNP cunoscut, ceea ce constitue un mare dezavantaj pentru un beneficiar. În cazul unei sortări, apare aceeaşi problemă, dacă, de exemplu, se doreşte o ordonare a unei liste în ordine alfabetică, funcŃiile de sistem nu mai lucrează corect şi trebuie facută mai întâi decriptarea, apoi o sortare sau filtrare. Uneori, costurile de timp pot creşte şi accesul la baza de date va fi încetinit, iar în cazul bazelor de date de dimensiuni foarte mari, aceasta constitue o problemă majoră, mai ales când numarul de useri concurenŃi este de ordinul miilor.
5. Metodologii de implementare şi securizare a sistemelor informatice distribuite
În proiectarea sistemelor informatice, trebuie să se ia în considerare diferitele tipuri de sisteme
client/server. O clasificare a modelelor client/server a fost propusă de Gartner Group, pornind de la funcŃionalitatea părŃilor componente ale unei aplicaŃii şi identifică cinci tipuri de arhitecturi:
� InterfaŃa distribuită - urmăreşte dispunerea de facilităŃi grafice pe postul client, motiv pentru care acest model mai este referit şi prin cosmetica aplicaŃiei.
Concret, acest model presupune adăugarea unei interfeŃe grafice evoluate la o aplicaŃie centralizată, rezidentă pe un mainframe sau minicalculator, în vederea înlăturării dezavantajelor asociate interfeŃelor la modul caracter specifice platformelor mari. AplicaŃia centrală nu este modificată, ci numai partea de interfaŃă a aplicaŃiei, adică acea parte care selectează datele provenite de la serverul central şi le afişează într-un mediu grafic specific microcalculatoarelor. Deşi aduce unele îmbunătăŃiri aplicaŃiei, modelul interfaŃă distribuită poate fi cu greu încadrat în arhitectura client/server, întrucât partea server a aplicaŃiei rămâne semnificativă, manifestându-se o relaŃie de tip master-slave. Totuşi, acest model oferă unele avantaje legate de:
• ameliorarea calităŃii interfeŃei aplicaŃiei;
• conservarea investiŃiilor anterioare, efectuate pentru realizarea aplicaŃiei, deoarece programele aplicaŃiei nu sunt modificate;
• oferă o soluŃie intermediară în vederea trecerii la arhitectura client/server.
Deşi o asemenea rezolvare răspunde cerinŃelor utilizatorilor în materie de interfaŃă grafică, ea nu poate reprezenta decât o soluŃie temporară, deoarece:
• nu rezolvă problemele de comunicare a datelor, generate de traficul intens de date din reŃea(la datele aplicaŃiei care tranzitează reŃeaua între client şi server, se adaugă informaŃiile tehnice legate de poziŃia câmpurilor în ecran, controale etc.)
• nu oferă deloc (sau prea puŃin) performanŃe noi, serverul asigurând în continuare toate prelucrările aplicaŃiei
Investeşte în oameni!
Pagina 184
� InterfaŃa client - în care gestiunea interfeŃei utilizator a aplicaŃiei este rezidentă pe platforma client, platformă ce asigură în întregime gestionarea dialogului.
Terminalele X reprezintă un exemplu de implementare a acestui model, ele oferind o mare portabilitate a aplicaŃiilor şi o independenŃă totală faŃă de producători de hardware şi software, putând lucra uşor cu platforme heterogene. Acest model asigură următoarele avantaje:
• îmbunătăŃeşte calitatea interfeŃei aplicaŃiei;
• conservă investiŃiile anterioare efectuate pentru realizarea aplicaŃiei prin separarea strictă a interfeŃei de prelucrările aplicaŃiei (logica aplicaŃiei);
• determină reducerea substanŃială a costurilor, datorită preŃului redus al terminalelor X şi uşurinŃa întreŃinerii acestora.
Totuşi, ca şi în primul caz, nu oferă performanŃe deosebite, deoarece serverul asigură ansamblul prelucrărilor, ceea ce presupune o mare încărcare a reŃelei. În plus, terminalele X sunt utilizate doar în mediile UNIX.
� Prelucrări distribuite - model care presupune repartizarea prelucrărilor aplicaŃiei între client şi server.
Pe platforma client, se regăseşte logica funcŃională de bază, care apelează serverul pentru executarea unor servicii externe, prin lansarea unor cereri ce vor activa prelucrările localizate pe server, numite şi proceduri. Apelarea procedurilor de pe server de către clienŃi se poate face prin intermediul mecanismului RPC (Remote Program Call). Acest mecanism permite, de exemplu, apelarea de către aplicaŃia client a procedurilor rezidente pe server care, la rândul lor, pot conŃine una sau mai multe cereri SQL. Adoptarea acestui model necesită stabilirea unor criterii clare de repartizare a prelucrărilor, ceea ce complică procesul de proiectare a sistemelor informatice. Această problemă constituie una din dificultaŃile dezvoltării de aplicaŃii conform acestui model, deoarece rezolvarea ei necesită o bună cunoaştere a echipamentelor şi programelor pe care va fi implementată aplicaŃia, precum şi o mare experienŃă în dezvoltarea unor astfel de aplicaŃii. În general, se consideră că, cu cât numărul de cereri de accesare a datelor specifice unei proceduri este mai mare şi cu cât procedura este mai complexă, cu atât mai mult se justifică localizarea acelei proceduri pe server (prelucrările sunt mai aproape de locul fizic de stocare a datelor, iar prin reŃea vor tranzita numai cererile de apel de la distanŃă a procedurilor şi rezultatele, nu şi datele).
Avantajele principale ale modelului bazat pe prelucrări distribuite constau în reducerea traficului prin reŃea şi o repartizare echilibrată a prelucrărilor între client şi server. În schimb, dezvoltarea unor asemenea aplicaŃii este dificilă, deoarece necesită cunoştinŃe şi experienŃă în domeniu. Un exemplu de adoptare a acestui model îl reprezintă aplicaŃiile care dispun de interfeŃe pentru culegerea datelor şi care implementează diferite operaŃiuni de prelucrare şi verificare a datelor în cadrul interfeŃelor, pentru a fi transmise datele către server într-o formă consistentă. În acest fel, dialogul interactiv dintre utilizator şi aplicaŃie (în cazul apariŃiei unor erori de culegere, de exemplu) este localizat pe platforma client, reducând astfel costurile şi întârzierile specifice comunicaŃiilor.
Investeşte în oameni!
Pagina 185
� Gestiunea locală a datelor - în care platforma client asigură atât gestionarea dialogului cât şi logica aplicaŃiei, iar serverul asigură doar gestionarea datelor.
În acest caz, se realizează o repartizare clară a funcŃiilor între client şi server şi se asigură o securitate sporită a datelor. AplicaŃia client transmite cererile sale de date serverului, iar acesta din urmă transmite înapoi datele cerute. Toate prelucrările asupra datelor, specifice aplicaŃiei, sunt efectuate pe platforma client. Dezvoltarea aplicaŃiilor, conform acestui model, este facilitată nu numai de repartizarea clară a funcŃiilor între client şi server, ci şi de oferta bogată de produse mature, cum ar fi SGBDR-urile. Astăzi, SGBDR-urile asigură şi controlul integrităŃii datelor din BD, ceea ce reprezintă o facilitate foarte importantă într-un mediu client/server, în care mai multe aplicaŃii client pot modifica aceste date. Localizarea controlului integrităŃii datelor în acelaşi loc în care se află datele (pe server) permite consultarea şi actualizarea datelor de către oricare din aplicaŃiile client în deplină sigurantă, precum şi reducerea traficului de reŃea (cererile privind controlul integrităŃii nu mai tranzitează reŃeaua, ca în cazul în care controlul integrităŃii ar fi localizat pe platforma client). Introducerea trigger-elor în SGBDR-uri facilitează controlul integrităŃii BD şi gestiunea datelor independent de aplicaŃiile client. Modelul de gestiune izolată a datelor se diferenŃiază de sistemele bazate pe simpla partajare a fişierelor de date, în care pe server sunt stocate numai datele, în timp ce serviciile de gestionare a datelor sunt rezidente pe client. Desigur că, în acest caz, traficul în reŃea este mult mai mare. Din cele prezentate anterior, se pot desprinde următoarele avantaje ale acestui model:
• este mai uşor de înŃeles, deoarece funcŃiile aplicaŃiei sunt clar repartizate între client şi server;
• garantează o securitate şi consistenŃă mai bună a datelor;
• există o ofertă variată de produse bine verificate.
Printre dezavantajele asociate pot fi enumerate:
• nu este adaptat mediilor tranzacŃionale intensive - deşi SGBDR-urile asigură accesul concurent la date, ele nu suportă decât un număr limitat de utilizatori (câteva sute), caz în care se face apel la maşinile tranzacŃionale, care au rolul de server frontal al SGBDR;
• traficul în reŃea este mai mare decât în cazul modelului bazat pe distribuirea prelucrărilor.
� Gestiunea distribuită a datelor presupune repartizarea datelor între client şi unul sau mai multe servere.
Datele repartizate vor fi gestionate ca un ansamblu logic, fiind numai fizic distribuite. Postul client devine el însuşi server de date şi se crează legături de tip server-server care, de cele mai multe ori, presupune o gestiune a datelor într-un mediu heterogen (calculatoare, sisteme de operare, reŃele sau SGBD-uri diferite). Acest model reprezintă în teorie modelul ideal de distribuire, deoarece permite combinarea datelor într-o manieră avantajoasă, atât pentru server (coerenŃa sistemului prin globalizarea resurselor heterogene), cât şi pentru utilizatori (se reduce traficul de date, iar prelucrările datelor sunt mai rapide). Cu toate că asigură coerenŃa globală a sistemului, în condiŃiile existenŃei unor resurse heterogene, şi oferă performanŃe sporite, implementarea acestui model este deosebit de complexă, fie şi numai pentru ca o cerere SQL trebuie analizată şi rezolvată la nivel global, iar pentru consistenŃa datelor
Investeşte în oameni!
Pagina 186
trebuie implementate mecanisme în două sau mai multe faze. La această complexitate, se adaugă şi oferta ,încă limitată, privind arsenalul de produse necesare pentru implementarea unui asemenea model. În practică, arhitectura client/server a unei aplicaŃii poate combina mai multe din cele cinci modele prezentate anterior. O asemenea arhitectură poate rezulta prin distribuirea atât a datelor cât şi a prelucrărilor.
6. Securitatea sistemelor informatice distribuite
Prin securitatea sistemelor distribuite se urmăreşte securizarea tranzacŃiilor pe baza de date şi a datelor transmise între diferite noduri ale reŃelei (fişiere, documente electronice, date arhivate, export/import de date, etc). Principalele obiective urmărite în securizarea unui sistem distribuit sunt:
• confidenŃialitatea – protejează conŃinutul tranzacŃiilor împotriva accesării neautorizate;
• autentificarea – permite ca receptorul unui mesaj să determine în mod sigur identitatea expeditorului;
• integritatea datelor în reŃea – furnizează receptorului unei tranzacŃii siguranŃa că mesajul primit este identic cu mesajul emis de expeditor;
• non-repudierea - prevenirea nerecunoaşterii tranzacŃiei de către expeditor, prin care se garantează integritatea şi originea mesajelor (tranzacŃiilor) din punctul de vedere al expeditorului, şi nu al destinatarului ( se împiedică, astfel, ca expeditorul unei tranzacŃii electronice să nege trimiterea ei);
• aplicarea selectivă a unor servicii – de multe ori, este necesară acoperirea unor părŃi ale mesajelor (tranzacŃiilor), de exemplu, cele conŃinând numărul cărŃii de credit al unui client (aceasta nu trebuie să fie în clar vânzătorului care poate abuza de utilizarea lui).
Pentru a reduce riscurile de securitate în utilizarea şi administrarea sistemelor informatice, cea mai bună strategie este cea pe ansamblu (security in depth). Aceasta presupune evaluarea pe ansamblu a infrastructurii IT şi clasificarea expunerii la riscuri de securitate. Pentru fiecare dintre riscurile identificate trebuie realizate planuri de măsuri, fie pentru reducerea expunerii la acele riscuri (mitigation), fie pentru reducerea impactului odată ce riscul s-a produs (contingency). La polul opus se află abordarea punctuală a implementarii unui sistem specific de securitate, de exemplu antivirus sau intrusion detection. Deşi aceste sisteme sunt foarte utile în cadrul ariei specifice de aplicabilitate, această abordare lasă descoperite alte zone cu posibile breşe de securitate. Foarte multe companii cad în greşeala de a investi mult în astfel de sisteme, fără însă a avea o strategie de securitate cap-coadă.
Pentru a avea o abordare de ansamblu, trebuie urmărite următoarele lucruri elementare:
• uniformitatea infrastructurii din punct de vedere al sistemelor folosite;
• administrarea centralizată;
• menŃinerea la zi a sistemelor din punct de vedere al patch-urilor şi fix-urilor;
• aplicarea unor configurări standard de securitate pe toate serverele şi staŃiile de lucru, în funcŃie de rolul funcŃional al acestora;
Investeşte în oameni!
Pagina 187
• proceduri standard de utilizare şi administrare.
Mai toate discuŃiile despre securitate se rezumă la problemele identificate la diverse sisteme. Ceea ce se uită însă este faptul că pentru a avea un sistem sigur nu e suficient să avem tehnologia corespunzătoare. Studiile arată ca în medie 90% din breşele de securitate identificate nu sunt datorate problemelor tehnologice ci instalării şi configurării necorespunzătoare sau datorită nerespectării unor proceduri de utilizare şi administrare a sistemului. În multe cazuri, aceste proceduri nici nu există. Trebuie deci privită problema pe ansamblu, luând în calcul tehnologia, oamenii şi procedurile interne ale companiei. A privi deci securitatea doar prin prisma problemelor tehnologice este un punct de vedere îngust. Nu ne putem aştepta ca un sistem care nu a fost instalat şi configurat corespunzător, care nu e menŃinut la zi cu patch-urile sau pentru care nu se respectă nişte proceduri simple de utilizare şi administrare, să fie un sistem sigur. Securitatea trebuie să fie o caracteristică intrinsecă a sistemului. Un sistem sigur este unul bine proiectat, implementat, utilizat şi administrat. De multe ori, se constată că beneficiile sunt mai mari, iar investiŃiile şi eforturile făcute sunt mai mici dacă există o abordare pe ansamblu, decât dacă se tratează problema punctual.
ViaŃa socială şi economică se bazează azi, din ce în ce mai mult, pe infrastructura informatică. De asemenea, guvernele, firmele din sectorul public şi privat, organismele financiare naŃionale şi internaŃionale, învătământul, cultura şi cercetarea ştiinŃifică, beneficiază toate de aceste forme eficiente de conducere, informare şi comunicare. În aceste circumstanŃe, securitatea informatică a devenit una din componentele majore ale Internetului. Analiştii acestui concept au sesizat o contradicŃie între nevoia de comunicaŃii şi conectivitate, pe de o parte, şi necesitatea asigurării confidenŃialităŃii, integrităŃii şi autenticităŃii informaŃiilor, pe de altă parte. În domeniul relativ nou al securităŃii informatice, se caută soluŃii tehnice pentru rezolvarea acestei contradicŃii aparente. Viteza şi eficienŃa transmiterii rapide de documente şi mesaje conferă numeroase atuuri actului decizional într-o societate modernă, bazată pe economie concurenŃială, însă utilizarea serviciilor Internet, transfer electronic de fonduri etc. poate transforma potenŃialele câştiguri generate de accesul rapid la informaŃii, în pierderi majore, cauzate de furtul de date sau de inserarea de date false ori denaturate. Sistemele informatice sunt ameninŃate atât din interior, cât şi din exterior. Pot fi persoane bine intenŃionate, care fac diferite erori de operare, sau persoane rău intenŃionate, care sacrifică timp şi bani pentru accesarea neautorizată a sistemelor informatice. Dintre factorii tehnici, care permit fisuri de securitate, pot fi anumite erori ale software-ului de prelucrare sau de comunicare, sau anumite defecte ale echipamentelor de calcul sau de comunicaŃie. De asemenea, lipsa unei pregătiri adecvate a administratorilor, operatorilor şi utilizatorilor de sisteme amplifică probabilitatea unor breşe de securitate. Folosirea abuzivă a unor sisteme reprezintă, de asemenea, unul din factorii de risc major privind securitatea sistemelor informatice. Sistemele sunt vulnerabile la accesări neautorizate, la distrugeri sau modificări accidentale sau voite de date ori programe. Aceste sisteme pot deservi elemente vitale pentru societate cum ar fi: sisteme militare, bănci, spitale, sisteme de transport, burse de valori, oferind în acelaşi timp un cadru de comportament antisocial sau de terorism. TendinŃa actuală privind extinderea conectivităŃii, în special în Internet, amplifică aceste vulnerabilităŃi deoarece este din ce în ce mai greu să se localizeze un defect, un punct de acces ilegal în reŃea, un utilizator cu comportament inadecvat. Se consideră că Internetul este unul din cele mai complexe sisteme create de tehnologia umană care, alături de sistemul financiar mondial, nu poate fi controlat în totalitate. Vulnerabilitatea sistemelor informatice actuale poate antrena pierderi imense de ordin financiar, direct sau indirect, cum ar fi scurgerea de informaŃii confidenŃiale cu caracter personal, militar sau economic. Putem aprecia că în ultimii ani, în Ńările dezvoltate, hârtia a devenit numai un mediu de prezentare a informaŃiilor nu şi de arhivare sau transport. Aceste ultime
Investeşte în oameni!
Pagina 188
două funcŃii au fost preluate de calculatoare şi de retelele de interconectare a acestora. De aceea, au trebuit să fie găsite soluŃii pentru înlocuirea sigiliilor, ştampilelor şi semnăturilor olografe din documentele clasice cu variantele lor digitale, bazate pe criptografia clasică şi cu chei publice. Criptografia computaŃională este tot mai folosită pentru contracararea problemelor de securitate informatică. Utilizată multă vreme doar pentru asigurarea confidenŃialităŃii comunicaŃiilor militare şi diplomatice, criptografia a cunoscut în ultimii 20 de ani progrese spectaculoase, datorate aplicaŃiilor sale în securitatea datelor la calculatoare şi reŃele.
În Europa Occidentală, mai mult de un sfert dintre întreprinderile mici şi mijlocii au avut de suferit pierderi importante de date şi bani, din cauza vulnerabilităŃii în reŃelele lor, iar marile corporaŃii se confruntă cu pierderi de miliarde de dolari anual. În unele cazuri, proiectarea sistemelor informatice şi de comunicaŃii a fost facută neglijându-se securizarea acestora. De aceea, este important ca printre obiectivele principale în crearea sistemelor informatice şi a reŃelelor de comunicaŃii să se numere şi prevenirea acŃiunilor îndreptate împotriva lor, reducerea vulnerabilităŃii la aceste atacuri şi minimizarea pagubelor şi a timpului de recuperare în urma atacurilor. IniŃiativele de asigurare a securiŃătii sistemelor informatice au devenit o prioritate la nivel global, atât pentru instituŃiile publice, cât şi pentru companii, în condiŃiile în care cea mai mare parte a fluxului lor informaŃional este gestionat electronic. Formarea specialiştilor în managementul securităŃii informaŃiilor şi a administratorilor de securitate pentru sistemele informatice reprezintă o prioritate naŃională, cerută atât de mediile guvernamentale şi de administraŃia centrală şi locală, cât şi de mediul privat – companii, bănci. Acestea sunt responsabile în implementarea unor servicii şi sisteme informatice, dar şi beneficiare ale acestora, cu aplicabilitate în domenii ca: e-government, e-administration, e-banking, e-commerce, e-payment, în care rolul comunicaŃiilor şi tehnicii de calcul, precum şi al Internet-ului, este determinant. Auditorii financiari, specialiştii în securitatea informaŃiei, managerii şi membrii comitetelor de audit au sarcina de a identifica riscurile la care sunt expuse sistemele informatice ale organizaŃiilor, de a evalua controalele implementate în cadrul sistemelor cu scopul limitării impactului potenŃialelor riscuri şi de a asigura acurateŃea şi securitatea informaŃiei furnizate de sistemele informatice utilizate. Securitatea sistemului informatic a devenit foarte importantă, cu cât reŃelele au devenit mai mari şi mai complexe. AmeninŃările la resursele organizaŃiilor vin atât din surse externe cât şi interne. Furtul informaŃiilor şi distrugerea lor sunt adevărate preocupări pentru administratorii de sistem. Pentru realizarea acestui scop trebuie urmată o politică complexă de securizare a sistemului informatic. Punctele principale care trebuie atinse într-o politică de securizare sunt analizate în continuare:
• accesul fizic - prima linie a defensivei locale în protejarea echipamentelor de reŃea este păstrarea lor într-un mediu supravegheat;
• administrarea conturilor - conturile utilizatorilor trebuie adăugate în grupurile specifice. Grupurile implicite din sistemul de operare Windows sunt Administrators, Backup Operators, Guests, Network Configuration Operators, Power Users, Remote Desktop Users, Replicator, Users, HelpServicesGroup şi TelnetClients. În sistemul de operare Unix, grupurile implicite sunt root-superuser şi users;
• administrarea parolelor - parolele trebuie să îndeplinească cerinŃe complexe pentru siguranŃă şi trebuie schimbate periodic (automatizare);
• alegerea adecvată a sistemului de fişiere - sistemul de fişiere trebuie ales pentru a asigura un maxim de securitate şi performanŃe;
Investeşte în oameni!
Pagina 189
• protecŃie împotriva viruşilor - virusul este un program conceput să călătorească de la maşină la maşină, infectând fiecare calculator în drumul său. De obicei, infecŃia se manifestă prin atacarea anumitor clase de fişiere (pe platforma DOS/Windows Ńintele viruşilor sunt de obicei fişierele cu extensia .exe sau .com). Odată ce virusul a atacat un astfel de fişier, victima prezintă un risc de securitate. Acel fişier, transportat pe un alt calculator, va infecta alte fişiere. Majoritatea viruşilor sunt scrişi în limbajul de asamblare, un limbaj low-level, ceea ce explică dimensiunile lor reduse şi viteza mare de execuŃie;
• protecŃie împotriva ‘cailor troieni’ – ‘caii troieni’ sunt entităŃi statice faŃă de viruşi, adică nu călătoresc din calculator în calculator decât în cazul în care fişierul infectat este mutat. Sunt programe plasate în spatele unei aplicaŃii de încredere. ‘Caii troieni’ realizează funcŃii neautorizate şi ascunse. Rolul lor este de a trimite e-mail-uri atacatorilor cu parole de pe calculatorul infectat sau de a deschide portiŃe prin care atacatorul poate controla calculatorul victimă;
• configurare firewall - cele două tipuri principale de firewall-uri le constituie firewall-urile de filtrare şi cele de tip intermediar (proxy)
• criptarea datelor - principalele două categorii de criptări, care se utilizează în prezent, sunt criptografia simetrică şi criptografia asimetrică;
• salvarea datelor (backup) - copiile de siguranŃă sunt foarte importante pentru cazurile de urgenŃă atunci când sistemul devine neoperaŃional, sau datele devin inaccesibile. Ca metode pentru realizarea copiilor de siguranŃă, se folosesc backup complet, backup incremental şi backup diferenŃiat;
• planuri de siguranŃă - identificarea datelor critice pentru funcŃionarea unui departament, în cadrul unei organizaŃii.
Investeşte în oameni!
Pagina 190
ACTIVITĂłI PRACTIC – APLICATIVE PENTRU TEMA 9 Obiectivele activităŃilor practic-aplicative:
• rolul unui administrator de sistem informatic;
• fixarea cunoştinŃelor legate de securitatea bazelor de date;
• rolul unui administrator de baze de date;
• metode de criptare/decriptare a datelor şi semnături electronice;
• algoritmi uzuali de criptare/decriptare a datelor.
A.1 Se vor prezenta atribuŃiile unui administrator de sistem informatic. Se vor purta discuŃii legate de securitatea sistemelor informatice. Se vor fixa cunoştinŃele prezentate în temă, prin elaborarea unor cerinŃe de securitate, legate de o aplicaŃie didactică.
A.2 Se vor purta discuŃii legate de criptarea şi decriptarea datelor. Se vor prezenta avantajele utilizării semnăturii electronice şi exemple de utilizare. Se va detalia un algoritm de criptare a bazei de date.
Investeşte în oameni!
Pagina 191
P A R T E A A I I A SUPORTUL DE CURS
TEMA 10
AplicaŃia software pentru prelucrarea rezultatelor obŃinute la evaluarea naŃională
AplicaŃia software, pentru prelucrarea rezultatelor obŃinute la evaluările naŃionale, este o aplicaŃie modulară şi are în componenŃă următoarele module:
� Modulul CENTRE EXAMEN � Modulul COMISII EVALUARE � Modulul BORDEROU LUCRĂRI � Modulul REZULTATE EVALUARE � Modulul PRELUCRARE REZULTATE
Proiectarea bazei de date şi interfeŃele aplicaŃiei s-au făcut plecând de la următoarele considerente: o cerinŃele funcŃionale- posibilitatea introducerii datelor de la centrele de evaluare şi
inspectoratele judeŃene, cu replicare pe baza de date centrală, sau conectare directă pe serverul central prin Internet;
o posibilitatea accesării datelor - de către evaluatori, elevi, părinŃi şi persoane de decizie;
o numărul maxim de useri concurenŃi – 2500 informaticieni şi 3000 evaluatori;
o volumul de date - aferent pentru 211 000 elevi;
o integritatea datelor;
Investeşte în oameni!
Pagina 192
o securitatea tranzacŃiilor;
o administrarea drepturilor de acces;
o administrarea bazei de date;
o metode de backup şi recovery.
Pentru proiectarea bazei de date s-a folosit modelul relaŃional care oferă posibilitatea folosirii constrângerilor de integritate, pe obiectele din baza de date, iar pentru identificarea centrelor de examen şi a comisiilor s-a folosit soluŃia codificarii unice. Algoritmul de codificare se va analiza împreună cu factorii de decizie şi specialiştii în domeniu. AplicaŃia pentru culugerea şi prelucrarea datelor este de tip web şi permite conexiunea prin Internet a centrelor de examinare la serverul de baze de date. Meniul principal al aplicatiei este prezentat in Figura 1.
Figura nr.1 Interfata MENIU PRINCIPAL
Investeşte în oameni!
Pagina 193
1. Modulul CENTRE EXAMEN
Acest modul este folosit pentru codificarea centrelor de examen. Fiecare centru de examen va primi un cod pentru a putea fi identificat print-o cheie unică în baza de date. InterfaŃa este prezentata in Figura 2.
Figura nr. 2. InterfaŃa CENTRE EXAMEN
Blocul CENTRE_EXAMEN are în componenŃa următoarele câmpuri :
� JUDEł � LOCALITATE � COD_CENTRU � DENUMIRE_CENTRU
În Figura nr.3 este prezentat un screenshot al interfeŃei, care permite selectarea centrelor de
examen dintr-o listă, în vederea inserării comisiilor de examinare în baza de date. Centrele de examen vor fi codificate în prealabil, iar pentru inserare se va afişa o listă cu toate
centrele, operatorul având posibilitatea de identificare a centrului după cod, judeŃ, localitate sau denumire. Trebuie menŃionat că identificarea se poate face şi după subşiruri de caractere, de exemplu, după primele trei litere din denumire.
Investeşte în oameni!
Pagina 194
Această metodă de operare va elimina riscul ca operatorul să introducă în baza de date un centru de examinare cu mai multe denumiri. Deasemenea, identificarea unică va fi foarte utilă pentru modulul de raportare şi prelucrările statistice ulterioare.
Figura nr.3 Selectarea centrelor de examen dintr-o lista
2. Modulul COMISII EVALUARE
Acest modul este folosit pentru codificarea şi introducerea în baza de date a comisiilor de
examinare.
Blocul COMISII_EVALUARE este folosit pentru inserarea datelor referitoare la componenŃa următoarelor comisii de examinare :
o Comisia de evaluare a competenŃelor lingvistice şi digitale o Comisia centrului de examen o Comisia centrului zonal de evaluare
În Figura 4 este prezentat un screenshot al interfeŃei care permite inserarea în baza de date a
celor trei comisii de examinare.
Figura nr. 4 InterfaŃa COMISII EXAMEN
Fiecare comisie de examinare va identificata unic după anul de evaluare, sesiunea de evaluare, codul centrului de examinare şi codul comisiei. Pentru operaŃiile de bază, forma este proiectată cu următoarele butoane:
� INSERARE – se activează înaintea inserării unei înregistrări noi
� SALVARE – se activează pentru salvarea înregistrării curente în baza de date
� STERGERE - se activează pentru ştergerea înregistrării curente din baza de date
� IDENTIFICARE – se activează înaintea introducerii câmpurilor de căutare a unei înregistrări în baza de date
Investeşte în oameni!
Pagina 196
� CAUTARE - se activează pentru execuŃia unei interogări pe baza de date
� IESIRE - se activează pentru închiderea formei
Interogarea bazei de date se poate face după oricare dintre câmpurile formei, prin introducerea unui cod, şir sau subşir de caractere. De exemplu, dacă se doreşte afişarea datelor aferente pentru un centru de examen, se parcurg paşii următori :
• se activează butonul IDENTIFICARE
• se selectează din listă codul centrului
• se activează butonul CAUTARE
Dacă se doreşte interogarea după un nume de preşedinte, secretar sau membru de comisie, se repetă paşii anteriori şi se completează numele dorit sau primele caractere din componenŃa numelui. Pentru orice operaŃie pe baza de date, se înregistrează automat userul şi data operării.
3. Modulul BORDEROU LUCRĂRI Acest modul este folosit pentru introducerea în baza de date a borderoului de notare pentru fiecare probă de concurs. Borderoul va fi completat în urma corecturii şi va conŃine punctele obŃinute pentru fiecare subiect al disciplinei de concurs. Trebuie menŃionat că în borderou se specifică numai numărul lucrării, iar asocierea numărului lucrării cu numele candidatului se va face ulterior. Fiecare disciplină de concurs va avea asociat un tip de borderou, în funcŃie de numărul de subiecte şi subpunctele aferente fiecărui subiect. Blocul are în componenŃă următoarele câmpuri :
În Figura 5, este prezentat un screenshot al interfeŃei care permite inserarea în baza de date a datelor aferente borderoului de notare pentru proba de matematica.
Investeşte în oameni!
Pagina 197
Figura nr. 5 InterfaŃa BORDEROU NOTARE ( MATEMATICA ) Pentru operaŃiile de bază, forma este proiectată cu următoarele butoane:
� INSERARE – se activează înaintea inserării unei înregistrări noi
� SALVARE – se activează pentru salvarea înregistrării curente în baza de date
� STERGERE - se activează pentru ştergerea înregistrării curente din baza de date
� IDENTIFICARE – se activează înaintea introducerii câmpurilor de căutare a unei înregistrări în baza de date
� CAUTARE - se activează pentru execuŃia unei interogări pe baza de date
� IESIRE - se activează pentru închiderea formei
� SCHIMBARE_CORECTOR – se activează pentru introducerea datelor aferente unui nou borderou, implicit unui nou corector
Investeşte în oameni!
Pagina 198
Interogarea bazei de date se poate face după oricare dintre câmpurile formei, prin introducerea unui cod, şir sau subşir de caractere. De exemplu, dacă se doreşte afişarea datelor aferente pentru un număr de lucrare, se parcurg paşii următori :
• se activează butonul IDENTIFICARE
• se introduce numărul lucrării
• se activează butonul CAUTARE
Dacă se doreşte interogarea după un nume de corector, se repetă paşii anteriori şi se completează numele dorit sau primele caractere din componenŃa numelui. Pentru orice operaŃie pe baza de date, se înregistrează automat userul şi data operării. Selectarea unui centru de examen se face similar ca la interfaŃa de lucru pentru comisii de examinare, aşa cum se vede în Figura 6. Asocierea dintre numărul lucrării, pe fiecare centru de examen şi datele canditatului se va face pe baza datelor de identificare completate de către candidat, după desfacerea etichetei de secretizare. O variantă luată în calcul este folosirea codului de bare şi scanarea codului cu ajutorul unui scaner. În ambele variante, datele de identificare vor fi introduse după fişele de înscriere gestionate de secretariat. La introducerea punctajelor se face o verificare automata pentru a nu depaşi numarul de puncte pentru baremul respectiv.
Investeşte în oameni!
Pagina 199
Figura nr. 6 Selectarea centrului de examen aferent unui borderou Dupa introducerea notelor se face o verificare urmata de o validare. Validarea se face cu double click pe campul de validare (in cazul validarii unei singure lucrari) sau pe butonul VALIDARE şi in acest caz validarea se face pentru toate lucrarile cu date de identificare afisate. Odata validate notele nu mai pot fi modificate. In cazul in care se doreste o modificare de nota mai intai se invalideaza linia pentru lucrarea respectiva, se modifica nota apoi se valideaza din nou. Invalidarea se poate face numai de catre un supervizor cu privilegii acordate in acest sens prin introducerea CNP-lui şi a unei parole, aşa cum se vede in Figura 7.
Figura nr. 7 Introducerea parolei de supervizor Pentru proba de fizica interfaŃa arata ca in Figura 8. Aceasta interfata are o constructie cu patru tab-uri, cate unul pentru fiecare subiect. Pentru introducerea notelor se selecteaza mai intai tabul pentru subiectul ales de elev ( trebuie sa aleaga doua subiecte din patru) iar functionarea este similara ca la o interfaŃa cu un singur tab. FuncŃionarea este proiectata astfel incat sa nu se permita introducerea notelor la trei subiecte, facandu-se automat şi totalul punctelor pe un subiect şi pe toata lucrarea.
Investeşte în oameni!
Pagina 200
Figura nr.8 InterfaŃa BORDEROU NOTARE ( FIZICA ) Pentru probele de chimie anorganica si chimie organica interfeŃele au trei tab-uri, cate unul pentru fiecare subiect. Pentru introducerea notelor se selecteaza doua dintre cele trei tab-uri, aplicatia facand automat o verificare pentru a nu permite note la mai mult de doua subiecte pentru o lucrare. InterfeŃele pentru cele doua borderouri sunt similare , aşa cum se vede in Figura 9.
Investeşte în oameni!
Pagina 201
Figura nr. 9 InterfaŃa BORDEROU NOTARE ( CHIMIE ) Functionarea interfetei cu trei tab-uri este similara cu a celei cu un singur tab, avand in plus verificarile amintite mai sus şi calculul punctelor totale pe fiecare subiect şi pe toata lucrarea.
4. Modulul REZULTATE EVALUARE
Modulul este folosit pentru introducerea în baza de date a rezultatelor obŃinute la examenul de bacalaureat, pe baza borderourilor primite de la comisiile de examen( prezentate în Anexa1). InterfaŃa are o funcŃionalitate multiplă, permiŃând şi efectuarea de interogări pe baza de date pentru afişarea datelor în video format. Pentru asocierea dintre numarul de lucrare, disciplina şi datele de identificare ale elevului se foloseşte interfaŃa din Figura 10.
Investeşte în oameni!
Pagina 202
Figura 10. InterfaŃa de asociere disciplina-lucrare-elev
În Figura 11, se prezintă un screenshot al interfeŃei care permite vizualizarea notelor obtinute de un elev la toate disciplinele de concurs.
Investeşte în oameni!
Pagina 203
Figura 11. InterfaŃa REZULTATE EVALUARE
Blocul REZULTATE_EVALUARE are în componenŃă următoarele câmpuri :
Pentru selectarea unei discipline, se activează un PUSH BUTTON, care afişează o listă predefinită de dicipline , aşa cum se vede în screenshot-ul din Figura 12.
Investeşte în oameni!
Pagina 205
Figura 12. Activare PUSH BUTTON pentru selectarea unei discipline
În mod similar, se activează un PUSH BUTTON pentru nivelul de evaluare al fiecarei discipline, aşa cum se vede în Figura 13.
Investeşte în oameni!
Pagina 206
Figura 13. Activare PUSH BUTTON pentru nivelul de evaluare
Butoanele pentru operaŃiile de bază sunt identice ca la blocul precedent. Interogarea bazei de
date, pentru afişarea rezultatelor unui candidat, se poate face dupa CNP, nume sau ambele variante, aşa cum se vede în Figura 14. Odată cu afişarea rezultatelor unui candidat, se afişează şi centrul de examinare şi codul comisiei de evaluare. Dacă se face o interogare dupa nume, se poate specifica numele complet sau un subşir din nume. De exemplu, dacă se doreşte afişarea tuturor candidaŃilor al căror nume începe cu litera M, se face interogarea completând câmpul de nume cu M%. Interogarea se poate face şi după câmpuri multiple, de exemplu, interogare după nume şi o disciplină. Pentru afişarea rezultatelor obŃinute de toŃi candidaŃii la o disciplină, se parcurg paşii următori:
• se activează butonul IDENTIFICARE
• se selectează din listă disciplina dorită
• se activează butonul CAUTARE
Investeşte în oameni!
Pagina 207
Screenshot-ul este prezentat în Figura 15. În urma interogării, se pot vizualiza rezultatele prin folosirea săgeŃilor UP şi DOWN de pe tastatură, sau prin folosirea butonului de navigare din partea dreaptă a blocului. Media generală se calculează automat printr-o procedură. La introducerea unui CNP, se lansează o procedură, care face o verificare automată, dacă CNP-ul introdus este valid. Pentru orice modificare facută în baza de date, se înregistrează, în mod automat, userul care a făcut operaŃia respectivă şi data de operare.
Figura 14. Interogarea bazei de date după câmpurile NUME sau CNP
Investeşte în oameni!
Pagina 208
Figura 15. Interogarea bazei de date după rezultatele obŃinute la o disciplină
5. Modulul PRELUCRARE REZULTATE SI STATISTICI
Acest modul este destinat pentru preluarea şi prelucrarea rezultatelor obŃinute la examenele
de bacalaureat tinand cont de cheile de corelare dintre modulele aplicaŃiei. Prelucrarea rezultatelor se face cu ajutorul procedurilor incluse în formulare, sau stocate pe serverul de baze de date. Pentru preluarea datelor din borderourile aferente fiecărei probe de concurs, există câte o procedură care va prelua punctajele obŃinute de candidat pe fiecare subiect, le va tranforma în note de la 1 la 10 şi le va insera în baza de date aferentă rezultatelor de evaluare. Pentru corelarea datelor, procedurile vor face asocierea între numărul lucrării dintr-un centru de examinare şi CNP-ul candidatului. Asocierea se face pe baza datelor inserate în prealabil în baza de date de către secretariat. FuncŃionarea procedurilor este complexă şi necesită transmiterea de parametri între ele, în cazul în care sunt apelate recursiv.
Investeşte în oameni!
Pagina 209
După prelucrarea rezultatelor, urmează etapa de raportare şi prelucrări statistice. SituaŃiile statistice conŃin tipuri de rapoarte care au la bază proceduri de prelucrare a datelor. Un exemplu de prelucrare statistică pentru un judeŃ şi o disciplina este arătat in raportul din Figura 16 care prezinta numarul si procentele notelor pe transe de note.
Figura nr. 16 SituaŃia statistică a notelor pentru o disciplina si judet
Un alt tip de raport statistic este situaŃia pe tranşe de note, număr de elevi dintr-o tranşă,
procentul pe tranşa respectivă şi repartiŃia pe judeŃe, aşa cum se vede în Figura nr.17.
Investeşte în oameni!
Pagina 210
Figura nr. 17 SituaŃia statistică pe tranşe de note
Raportul este similar cu cel anterior dar prezintă statistica la nivelul tuturor judeŃelor şi totalul general
pe transe de note.
Investeşte în oameni!
Pagina 211
ACTIVITĂłI PRACTIC – APLICATIVE PENTRU TEMA 10 Obiectivele activităŃilor practic-aplicative:
• însuşirea cunoştinŃelor de operare pe interfaŃa aferentă centrelor de examinare;
• însuşirea cunoştinŃelor de operare pe interfaŃa aferentă comisiilor de evaluare;
• însuşirea cunoştinŃelor de operare pe interfaŃa aferentă borderoului de lucrări;
• însuşirea cunoştinŃelor de operare pe interfaŃa aferentă rezultatelor de evaluare;
• însuşirea cunoştinŃelor de operare pentru prelucrarea datelor şi elaborarea prelucrărilor statistice.
A.1 Se va prezenta modul de conexiune la serverul aplicaŃiei. Se vor prezenta modulele aplicaŃiei. Se vor prezenta interfeŃele aferente fiecărui modul. Se vor prezenta functionalităŃile butoanelor aferente fiecărei interfeŃe.
A.2 Se vor crea centre de examen şi comisii de evaluare. Se vor introduce date de test în borderoul de lucrări şi rezultate de evaluare. Se vor valida notele introduse apoi se vor face modificari de note folosind parola de supervizor.
A.3 Se vor face prelucrări pe datele de test şi se vor elabora situaŃii statistice. Se vor analiza rezultatele pe fiecare disciplină şi fiecare subiect.
Centrului NaŃional de Evaluare şi Examinare a iniŃiat crearea unei aplicaŃii software de completare a borderoului electronic, care este perfect adaptat baremului de corectare şi notare valabil pentru varianta de subiect extrasă.
Proiectarea bazei de date şi interfeŃele aplicaŃiei s-au făcut având la bază
următoarele considerente: • cerinŃele funcŃionale- posibilitatea introducerii datelor de la centrele de
evaluare şi inspectoratele judeŃene, cu replicare în baza de date centrală, sau conectare directă la serverul central prin Internet;
• posibilitatea accesării datelor - de către evaluatori, elevi, părinŃi şi persoane de decizie;
• volum mare de date (aferent unui număr de aproximativ 211 000 elevi/ candidaŃi);
• integritatea datelor; • securitatea informaŃiilor; • administrarea drepturilor de acces; • administrarea bazei de date; • metode de backup şi recovery.
Investeşte în oameni!
Pagina 212
Pentru fiecare dintre etapele menŃionate s-a instalat un iniŃiator Java pe calculatoarele desemnate, conform procedurilor dedicate completării borderoului electronic.
Pentru accesul la baza de date, fiecărui operator i s-au repartizat credenŃiale de
acces. Astfel credenŃialele au avut ca scop difenŃierea drepturilor şi rolurilor specifice fiecărui user. Instruirea operatorilor a fost realizată în cadrul unor sesiuni de formare, ulterior, pe parcusul desfăşurării activităŃii, au beneficiat şi de suport tehnic. Testarea a decurs fără a fi semnalate probleme din punct de vedere tehnic sau al funcŃionalităŃii aplicaŃiei.
Deoarece, în paralel cu testarea aplicaŃiei de completare a borderoului electronic pentru examenul de bacalaureat s-a desfăşurat şi testarea aplicaŃiei de completare a borderoului electronic pentru Evaluarea NaŃională, a fost necesară o aplicaŃie distinctă, adaptată la cerinŃele specifice.
Operatorii de baze de date şi responsabilii cu comunicarea virtuală de la nivelul inspectoratelor şcolare judeŃene menŃionate în Anexa nr. 1, au fost formaŃi în cadrul proiectului. Acestora li s-a pus la dispoziŃie un suport online, de facilitare a utilizării borderoului electronic. IniŃial s-a verificat dacă fiecare dintre calculatoare are conexiune la internet funcŃională, au fost devirusate şi s-a instalat aplicaŃia care permite completarea borderoului electronic pe fiecare dintre acestea; au eliminat de pe hard-ul calculatoarelor toate directoarele/ fişierele care nu au legătură cu borderoul electronic. Crearea unui user distinct în baza de date pentru fiecare operator a permis monitorizarea activităŃii acestuia.
AplicaŃia a fost concepută să preia automat numele userului şi data transferului în baza de date, astfel încât se poate afla care sunt datele inserate de un operator, data la care au fost inserate sau modificate, cărui centru de examinare aparŃin datele asociate, numărul de validări efectuate în baza de date etc. Fiecare user poate să vadă numai datele inserate de el, iar dacă datele au fost validate, o modificare ulterioră se poate face numai cu acordul unui supervisor care trebuie să introducă o parolă suplimentară.
Investeşte în oameni!
Pagina 213
Figura nr. 3 InterfaŃa iniŃială a operatorului de baze de date După evaluarea lucrărilor pe baza baremelor de evaluare şi de notare elaborate
în cadrul Centrului NaŃional de Evaluare şi Examinare, fiecare profesor evaluator a fost repartizat, de către preşedintele comisiei din centrul zonal de evaluare, unui operator de baze de date.
Investeşte în oameni!
Pagina 214
Figura nr. 4 Modalitatea în care se realizează selecŃia centrului de examen de către
operatorul de baze de date Numai operatorul de baze de date, care a iniŃiat introducerea datelor, a putut
valida datele introduse. Atât operatorii de baze de date, cât şi profesorii evaluatori au respectat criteriile de validare din borderoul electronic. Dacă operatorul a introdus o valoare nepermisă pentru un item, aplicaŃia nu i-a permis continuarea introducerii datelor sau validarea acestora. În situaŃia în care candidatul nu a răspuns nimic la cerinŃa itemului în rubrica repartizată itemului, s-a introdus valoarea zero.
După completarea borderoului electronic, operatorii de baze de date au verificat corectitudinea introducerii datelor şi în urma accesării unui buton specific, au validat datele introduse pentru fiecare lucrare scrisă (validarea a blocat accesul ulterior în vederea modificării unor date introduse). AplicaŃia permite operatorului de baze de date accesul doar la datele introduse de el.
Fiecare dintre preşedinŃii comisiilor din centrele zonale de evaluare a primit, ca urmare a completării borderoului electronic şi a validării datelor introduse, un raport al lucrărilor la care s-a impus reevaluarea în condiŃiile prevăzute de Art. 68 din Anexa 2 la Ordinul MECTS nr. 4799 din 31.08.2010. În aceste condiŃii, unul dintre operatorii de baze de date, a putut completa în borderoul electronic o nouă înregistrare. Media finală trecută pe lucrare, de către preşedintele comisiei, s-a verificat cu media rezultată din borderoul de evaluare şi de notare în prezenŃa profesorilor evaluatori.
Pe parcursul implementării nu au fost semnalate probleme de disfuncŃionalitate.
Investeşte în oameni!
Pagina 215
Pentru vizualizarea datelor s-au creat interfeŃe dedicate cu care se pot face numai interogări pe baza de date, fără a putea insera, modifica sau şterge înregistrări.
După terminarea culegerii datelor s-a făcut un back-up al bazei de date: pentru operatorii care au introdus datele, pentru userii de control.
Organizarea bazei de date permite realizarea de interogări după un anumit centru de examen sau evaluare, după codul numeric personal (CNP-ul) al unui corector etc.
După iniŃierea aplicaŃiei se poate alege disciplina la care se completează datele.
Figura nr. 5 InterfaŃa cu Meniul principal al aplicaŃiei
În continuare sunt prezentate print-screen-uri din aplicaŃie, cu date aferente
fiecărui borderou:
Investeşte în oameni!
Pagina 216
� Exemplul următor se referă la proba scrisă E a Limba şi literatura română:
Figura nr. 6 Ilustrarea completării datelor pentru Proba scrisă E a Limba şi literatura română
Investeşte în oameni!
Pagina 217
� Borderoul electronic pentru disciplina Matematică –Proba scrisă E c este ilustrat în print-screen-ul următor:
Figura nr. 7 Ilustrarea completării datelor pentru Proba E. c) Matematică
Investeşte în oameni!
Pagina 218
� Analog cu acesta print-screen-ul din borderoul de la proba scrisă E a Istorie:
Figura nr. 8 Ilustrarea completării datelor pentru Proba E. c Istorie.
Investeşte în oameni!
Pagina 219
Borderoul electronic la disciplina Fizică, a Ńinut cont de faptul că un candidat poate alege doar două module dintre: Mecanică, Elemente de termodinamică, Producerea şi utilizarea curentului electric şi Optică. În consecinŃă, după selectarea a două module şi introducerea datelor, aplicaŃia nu mai permite selectarea unui al treilea modul şi înregistrarea altor date în borderoul electronic.
� Borderoul electronic pentru modulul Producerea şi utilizarea curentului electric:
Figura nr 9 Ilustrarea completării datelor pentru Proba scrisă E d.Fizică- modulul Producerea şi utilizarea curentului electric
Investeşte în oameni!
Pagina 220
� Borderoul electronic la disciplina Fizică, pentru modulul Mecanică:
Figura nr 10 Ilustrarea completării datelor pentru Proba scrisă E d Fizică- modulul Mecanică
Investeşte în oameni!
Pagina 221
� Disciplina Informatică:
Figura nr 11 Ilustrarea completării datelor pentru Proba scrisă E d Informatică
� Disciplina Chimie - aplicaŃia a facilitat introducerea datelor separate pentru chimia organică şi pentru chimia anorganică:
Investeşte în oameni!
Pagina 222
Figura nr 12 Ilustrarea completării datelor pentru Proba scrisă E d Chimie organică
� InterfaŃa aplicaŃiei pentru introducerea datelor pentru modulul chimia anorganică:
Investeşte în oameni!
Pagina 223
Figura nr 13 Ilustrarea completării datelor pentru Proba scrisă E. d) Chimie anorganică
� Disciplina Economie:
Investeşte în oameni!
Pagina 224
Figura nr 14 Ilustrarea completării datelor pentru Proba scrisă E d Economie
� Disciplina Filosofie:
Investeşte în oameni!
Pagina 225
Figura nr 15 Ilustrarea completării datelor pentru Proba scrisă E d Filosofie
� Disciplina Logică şi argumentare:
Investeşte în oameni!
Pagina 226
Figura nr. 16 Ilustrarea completării datelor pentru Proba scrisă E d Logică şi argumentare
� Disciplina Psihologie:
Investeşte în oameni!
Pagina 227
Figura nr. 17 Ilustrarea completării datelor pentru Proba scrisă E d Psihologie
� Disciplina Sociologie:
Investeşte în oameni!
Pagina 228
Figura nr. 18 Ilustrarea completării datelor pentru Proba scrisă Ed Sociologie
Investeşte în oameni!
Scalabilitatea aplicaŃiei este foarte importantă, precum şi asigurarea securitaŃii informaŃiilor.
Dintre elementele de noutate induse de borderoul electronic amintim:
� realizarea echipelor mixte alcătuite din operatori de baze de date şi profesori evaluatori;
� unicitatea borderourilor iniŃiate de CNEE; � posibilitatea verificării subtotalurilor şi totalurilor; � verificarea mediilor rezultate; � analiza situaŃiilor pe itemi; � posibilitatea analizei performanŃelor pe itemi, pe baza matricei de
specificaŃii asociată testului; � ierarhizarea itemilor în funcŃie de gradul de dificultate; � posibilitatea determinării nivelului competenŃelor atins de candidat.
