Performanțele tranzacțiilor în funcție de nivelurile de izolare [601962]

Universitatea “Politehnica” din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației
Performanțele tranzacțiilor în funcție de nivelurile de izolare
în Microsoft SQL Server 2012
Proiect de diplomă
prezentat ca cerință parțială pen tru obținerea titlului de
Inginer în domeniul Calculatoare și Tehnologia Informației
programul de studii de licență Ingineria Informației (CTI – INF)
Conducător științific Absolvent ă
As.Drd.Ing Valentin Pupezescu Ioana Iuliana M. Vasile
2012

Declarație de onestitate academică
Prin prezenta declar că lucrarea cu titlul „Performanțele tranzacțiilor în
funcție de nivelurile de izolare în Microsoft SQL Server 2012 ”, prezentată în cadrul
Facultății de Electronică, Telecomunicații și Tehnologia Informației a Uni versității
“Politehnica” din București ca cerință parțială pentru obținerea titlului de Inginer
în domeniul domeniul Calculatoare și Tehnologia Informației, programul de studii
Ingineria Informației (CTI – INF) , este scrisă de mine și nu a mai fost prezent ată
niciodată la o facultate sau instituție de învățământ superior din țară sau străinătate.
Declar că toate sursele utilizate, inclusiv cele de pe Internet, sunt indicate în
lucrare, ca referințe bibliografice. Fragmentele de text din alte surse, reprodu se
exact, chiar și în traducere proprie din altă limbă, sunt scrise între ghilimele și fac
referință la sursă. Reformularea în cuvinte proprii a textelor scrise de către alți
autori face referință la sursă. Înțeleg că plagiatul constituie infracțiune și se
sancționează conform legilor în vigoare.
Declar că toate rezultatele simulărilor, experimentelor și măsurătorilor pe
care le prezint ca fiind făcute de mine, precum și metodele prin care au fost
obținute, sunt reale și provin din respectivele simulări, ex perimente și măsurători.
Înțeleg că falsificarea datelor și rezultatelor constituie fraudă și se sancționează
conform regulamentelor în vigoare.

București, 1 iulie 2012

Absolventă Ioana Iuliana Vasile

_________________________

INTRODUCERE ………………………….. ………………………….. ………………………….. …………………….. 11
1 Noțiuni teoretice introductive ………………………….. ………………………….. ………………………….. 13
1.1 Bază de date ………………………….. ………………………….. ………………………….. …………………… 13
1.1.1 Definiție ………………………….. ………………………….. ………………………….. …………………… 13
1.1.2 Componentele unui sistem de baze de date ………………………….. ………………………….. .. 13
1.2. Modelul entitate – asociere ………………………….. ………………………….. ………………………….. 14
1.3. Modelul de date relațional ………………………….. ………………………….. ………………………….. .. 15
1.4. Limbajul SQL ………………………….. ………………………….. ………………………….. ………………… 16
1.5. Constrângeri de integritate ………………………….. ………………………….. ………………………….. . 18
1.5.1 Constrângeri de domeniu ………………………….. ………………………….. ………………………… 18
1.5.2 Constrângerile de tuplu ………………………….. ………………………….. ………………………….. . 18
1.5.3 Constrângerile in ter – relații ………………………….. ………………………….. ……………………. 19
1.5.4 Constrângerile impuse prin dependențe de date ………………………….. ……………………… 20
1.6 Gestiunea tranzacțiilor ………………………….. ………………………….. ………………………….. ……… 21
1.6.1 Definiție ………………………….. ………………………….. ………………………….. …………………… 21
1.6.2 Proprietățile tranzacțiilor ………………………….. ………………………….. ………………………… 22
1.7 Controlul concurenței ………………………….. ………………………….. ………………………….. ………. 23
1.7.1 Anomalii de interferență ………………………….. ………………………….. …………………………. 24
1.7.2 Tehnici de control al concurenței ………………………….. ………………………….. …………….. 25
1.7.2 Niveluri de izolare ………………………….. ………………………….. ………………………….. …….. 26
2 Tehnologii folosite ………………………….. ………………………….. ………………………….. …………….. 29
2.1 Microsoft SQL Server 2012 ………………………….. ………………………….. ………………………….. 29
2.1.1 Noutățile aduse de versiunea 2012 ………………………….. ………………………….. …………… 29
2.1.2 Limbajul Transact – SQL ………………………….. ………………………….. ……………………….. 30
2.1.3 Controlul Concurenței ………………………….. ………………………….. ………………………….. .. 31
2.1.4 Modalitatea de blocare a datele în SQL Server ………………………….. ………………………. 34
2.2 HTML ………………………….. ………………………….. ………………………….. ………………………….. .. 37
2.3 JavaServer Pag es ………………………….. ………………………….. ………………………….. …………….. 37 Cuprins

2.4 Java DataBase Connectivity ………………………….. ………………………….. ………………………….. 39
3 Implementare ………………………….. ………………………….. ………………………….. ……………………. 41
3.1 De scrierea aplicației ………………………….. ………………………….. ………………………….. ………… 41
3.2 Cerințele hardware și software ………………………….. ………………………….. ………………………. 41
3.3 Baza de date ………………………….. ………………………….. ………………………….. …………………… 42
3.4 Interfața Web ………………………….. ………………………….. ………………………….. ………………….. 44
3.5 Testarea și rezultatele obținute ………………………….. ………………………….. ………………………. 54
3.5.1 Implementarea aplicației de testare ………………………….. ………………………….. ………….. 54
3.5.2 Rezultatele obținute ………………………….. ………………………….. ………………………….. …… 57
3.5.3 Interpretarea rezultatelor ………………………….. ………………………….. …………………………. 61
4 CONCLUZII ………………………….. ………………………….. ………………………….. …………………….. 63
ANEXE ………………………….. ………………………….. ………………………….. ………………………….. ……… 65
ANEXA 1 ………………………….. ………………………….. ………………………….. ………………………….. .. 65
ANEXA 2 ………………………….. ………………………….. ………………………….. ………………………….. .. 66
ANEXA 3 ………………………….. ………………………….. ………………………….. ………………………….. .. 66
ANEXA 4 ………………………….. ………………………….. ………………………….. ………………………….. .. 67
ANEXA 5 ………………………….. ………………………….. ………………………….. ………………………….. .. 67
ANEXA 6 ………………………….. ………………………….. ………………………….. ………………………….. .. 67
ANEXA 7 ………………………….. ………………………….. ………………………….. ………………………….. .. 68
ANEXA 8 ………………………….. ………………………….. ………………………….. ………………………….. .. 68
ANEXA 9 ………………………….. ………………………….. ………………………….. ………………………….. .. 69
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. … 71

LIST A ACRONIMELOR
ACID Atomicitate, Consistență, Izolare, Durabilitate
API Application Programming Interface
BU Bulk Update
CSS Cascading Style Sheets
FN1 Formă Normală 1
FN2 Formă Normală 2
FN3 Formă Normală 3
FNBC Formă Normală Boyce Codd
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IS Zăvor de intenție de citire
IX Zăvor de intenție de scriere
J2EE Java 2 Platform, Enterprise Edition
JDBC Java DataBase Connectivity
JSP JavaServer Pages
LDD Limbaj de Descriere a Datelor
LMD Limbaj de Manipular e a Datelor
NIST Institutul Național de Standarde și Tehnologii
S Zăvor de citire
Sch – M Modificările Schemei
Sch – S Stabilitatea Schemei
SGBD Sistem de Gestiune a Bazelor de Date
SIX Zăvor de citire cu intenție de scriere
SQL Limbaj Structurat d e Interogare
T -SQL Transact – SQL
U Zăvor de actualizare
URL Uniform Resource Locator
X Zăvor de scriere

11
Importanța bazelor de date pentru orice fel de aplicație este incontestabilă în zilele
noastre. Rețelele de neuroni din creierul uman încep să fie ajutate și, uneori înlocuite, de
metodele digitale de stocare. De aceea, într -o societate a vitezei, bazele de date reprezintă o
provocare pentru programatori – acestea trebuie construite în așa fel încât să își mențină
rapiditat ea, efectuând în același timp corect operații din ce în ce mai complicate.
Obiectivul principal al proiectului este studierea performanțelor tranzacțiilor în funcție de
nivelurile de izolare folosit în sistemul de gestiune a bazelor de date Microsoft SQL S erver 2012.
Pentru exemplificarea acestora am creat o aplicație de rezervare a biletelor la un cinematograf
care include o bază de date și o interfață web.
Pentru realizarea aplicației am folosit tehnologiile JSP, HTML și CSS, iar pentru
simularea tranzac țiilor concurente pentru testele de performanță am folosit firele de execuție
puse la disponibile de Java prin clasa Thread .
Am ales această temă pentru că mulți utilizatori sunt incerți în privință selectării
nivelului de izolare ale procedurile pe care le execută în baza de date și consecințele acestora
asupra vitezei de terminare a acestora și a rezultatelor corect obținute.
Rezultatele obținute sunt în conformitate cu așteptările teoretice: nivelul de izolare cel
mai mic oferă o concurență mai mare a t ranzacțiilor, dar posibilitatea apariției anomaliilor de
interferență duce la anularea acestora, pe când nivelul de izolare cel mai ridicat au o concurență
mai scăzută dar rezultatele obținute sunt aceleași ca în cazul execuției secvențiale a tranzacției.

INTRODUCERE

12

13
1.1 Bază de date
Înainte de apariția calculatoarelor, modul de stocare a datelor se realiza rudimentar, în
arhive. Cea mai dificilă operație era de căutare a unei informații în volumul mare de documente
ce se adunau de-a lungul timpului. Nevoia unui sistem mai performant, care să găsească mai
rapid anumite informații a fost accentuată de creștere economică, de apariția de companii cu
foarte mulți angajați și a comunicațiilor. Pentru toate aceste domenii, dar și pentru alte le,
cantitatea de date stocată a început să crească. Calculatoarele au soluționat această problemă.
1.1.1 Definiție
„O bază de date este o colecție de date creată și menținută computerizat, care permite
operații de introducere, ștergere, actualizare și int erogarea datelor ”. (1)
Primele modele de baze de date, cel e ierarhic e și cele rețea, deși aduceau o schimbare
profundă în modul de stocare a datelor și regăsirea informațiilor, erau inflexibile și necesitau
memorarea unor legături explicite pentru navigare. Programatorii și cei care utilizau aceste baze
de date trebuiau să fie bine instruiți. Marele avân t în domeniul bazelor de date a avut loc odată cu
apariția bazelor de date relaționale. Acesta a fost introdus în 1970 de E.F. Codd (de la firma
IBM) în lucrarea „ Un model relațional de date de baze distribuite ”. Datorită simplității acestuia,
acest model a fost un progres major atât pentru utiliza tori cât și pentru proiectanți. Totuși, la
început, conceptul era privit ca fiind nepractic datorită congestiei aduse calculatoarelor din acel
moment. Această problemă a fost rezolvată odată cu creșterea spectaculoasă a puterii de calcul și
descreșterea prețului calculatoarelor. (2)
1.1.2 Componentele un ui sistem de baze de date
„Un sistem de baze de date ( Database System ) este un sistem computerizat de menținere
a evidenței unei anumite activități, f olosind baze de date. Componentele u nui sistem de baze de
date sunt hardware, date persistente, software și utilizatori ” (1) (în ordinea în care ele
interacționează) . 1 Noțiuni teoretice introductive

14

Figura 1.1 Componentele unui sistem de baze de date (1)
Componenta hardware este constituită din dispozitive de memorare secundare (de ob icei
discuri magnetice) și procesoarele asociate pentru accesarea și prelucrarea datelor. Astfel,
sistemele de baze de date se vor regăsi în calculatoarele de uz general, servere, calculatoare
paralele, etc. Acest aspect nu ține neapărat de sis temul de baz e de date, influențând cel mult
capacitatea de date care pot fi memorate de baza de date. (1)
„Sistemul de gestiune a bazei de date – SGBD recepționează cererile utilizatorilor de
acces la baza de date, le interpretează, execu tă operațiile corespunzătoare și returnează rezultatul
către utilizatori ”. (1)
O funcție importantă a SGBD – ului este de a îl scuti pe utilizatorul bazei de date de
detaliile de la nivelul hardware, oferindu -i astfel o viziun e de nivel înalt a bazei de date . (1)
Utilizatorii se pot împărți în mai multe categorii: programatorii de aplicații, utilizatorii
finali, administratorii bazei de date. Fi ecare are un rol important − un sistem uzual de baze d e
date are nevoie de programatori care să îl realizeze, administratori care să s e ocupe de buna
funcționare și de securitatea acesteia, iar nu în ultimul rând , de utilizatori finali care să se
folosească efectiv de ea. (1)
Limbajele suportate de un SGDB sunt:
– „Limbajele de descriere a datelor (Data Description Language) permit definirea
conceptuală a datelor fără referire la modul de memorare fizică a acestora. ” (1)
– „Limbajele de manipulare a datel or (Data Manipulation Language) permit
specificarea operațiilor de introducere, actualizare, ș tergere și interogare a datelor. ”
(1)
1.2. Modelul entitate – asociere
Deoarece este mai ușoară examinarea structurilor grafice decâ t descrierea lor în cuvinte,
proiectanții de baze de date preferă să folosească instrumente grafice pentru descrierea entităților
și asocierile lor. De aceea, modelul entitate – asociere este un standard acceptat pentru modelarea
datelor. (1)

15
Acest model a fost prezentat prima oară de Peter Chen în anul 1976 și a avut mare succes
pentru complementa conceptele modelului relațional de baze de dat e. Diagrama entitate –
asociere este reprezentarea grafică a componentelor bazei de d ate.
O entitate este orice (persoană, loc, eveniment, lucru) despre care se poate colecta și
stoca date. Cum o entitate reprezintă un anumit tip de obiect din lumea reală, fiecare instanță a
unei entități este unică si distinctă. Ea poate fi un obiect fizi c sau o abstractizare . (2)
Un atribut este o caracteristică a unei entități. Spre exemplu, o persoană poate avea ca și
caracteristici nume, prenume, data nașterii, adresă. O asociere descrie o conexiune între entități.
Există trei tipuri de asocieri din punct de vedere al cardinalității: unu la unu ( one to one ), unu la
multe ( one to many ), multe la multe ( many to many ). (2)
1.3. Modelul de date relațional
„Modelul de date relațional ( Relationship Model ) se bazează pe noțiunea de relație din
matematică, care corespunde unei mulțimi de entități de același tip și are o reprezentare ușor de
înțeles și de manipulat, ce constă dintr -un tabel bidimensional, compus din linii și coloane.
Fiecare linie din t abel reprezintă o entitate și este compusă din mulțimea valorilor atributelor
entității respective, fiecare atribut corespunzând unei coloane a tabelului. ” (1)
Modelul de date relațional a adus o schimbare majoră, ajutându -i pe proiectanți să se
concentreze pe reprezentarea logică a datelor și legăturilor dintre acestea, în detrimentul
detaliilor despre stocarea lor. Folosirea tabelelor are avantajul independenței structurilor și
datelor care asigură o înțelegere mai facilă a m odelului, dar face și ca baza de date să fie mai
eficientă. (2)
„Pe baza acestor noțiuni, se po ate sintetiza esența modelului relațional prin următoarele
caracteristici:
– Datele sunt percepute de utilizatori ca tabele și numai tabele;
– Operatorii relaționali care pot fi folosiți pentru prelucrarea datelor generează un tabel
rezultat din tabelele operanzi;
– Asocierea dintre tabele se realizează prin intermediul egalităților valorilor unor
atribute comune, ceea ce permite rezolvarea oricărei interogări , fără să fie necesar să
se prevadă legături explicite ca în cazul modelelor pre – relaționale. ” (1)
„O bază de date relațională este compusă dintr -o mulțime finită de relații, fiecare relație
reprezentând un tip de entitate sau o asociere dintre două sau mai multe tipuri de entități. ” (1)
„Atributele unei relații sunt atributele tipului de entitate sau de asociere pe care îl
reprezintă relația respectivă. ” (1)

16
„Un domeniu de definiție este o mulțime cu nume de valori atomice de același tip, având
o anumită semnificație, din care își iau valori atributele relațiilor. ” (1)
Spre exemplu, relația Client poate avea ca atribu te Nume, Prenume, Adresă, Telefon,
Data Nașterii. Iar domeniul de definiție pentru atributul Data Nașterii este o dată compusă din zi,
lună, an.
„Schema relației, notată R(A 1,A2,…,A i,…A n), este compusă din numele rel ației și din lista
ordonată a atri butelor sale, fiecare atribut A i definit pe domeniul său de definiție, D(A i).” (1)
„O relație R definită pe schema R(A 1,A2,…,A i,…A n) este o mulțime de n – tupluri t,
fiecare tuplu fiind o listă ordonată de n valori t=<v 1, v2,..vi,…v n>, unde 1 ≤ i ≤ n și v i este
valoarea atributului A i aparținând domeniul său de definiție D(A i).” (1)
Spre exemplu, un tuplu al relației mai sus amintită, Client (Nume, Prenume, Adresă,
Telefon, Data Nașterii) , poate fi: <Popescu, Ion, Bd. Iuliu Maniu nr 111, 021 4344046,
11/11/1944>.
Asocierea dintre relații și tabel se face prin: numele tabelului îi corespunde numelui
relației, coloanele sunt corespunzătoare cu atributele relației, liniile corespund tuplurilor , tipul de
dată al fiecărei coloane corespunde domeniului de definiție.
1.4. Limbajul SQL
SGBD – ul asigură accesul la date printr -un limbaj de interogare neprocedural. Structured
Query Language (SQL) este de drept cel mai răspândit limbaj de interogare și acces al datelor,
fiind suportat de majo ritatea SGBD – urilor actuale, dar și primul limbaj comercial pentru bazele
de date relaționale. SQL definește metodele prin care se creează (tabele, vizualizări, indecși, etc)
și se manevrează (adăugare, modificare , ștergere și găsire) aceste tipuri de baze de date. (2)
SQL a devenit standard al Institutului Național American de Standarde (ANSI) în anul
1986 și în anul 1987 și al Organizației Internaționale pentru Standarde (ISO). Cu to ate acestea,
mulți producători de SGBD – uri folosesc „dialecte” proprii ale acestui standard: Oracle
folosește PL/SQL, Microsoft Transact – SQL, iar Post greSQL PL/pgSQL. (3)
An lansare Nume Cunoscut ca și
1986 SQL -86 SQL -87
1989 SQL -89 FIPS 127 -1
1992 SQL -92 SQL2, FIPS 127 -2
1999 SQL: 1999 SQL3
2003 SQL: 2003 SQL 2003
2006 SQL: 2006 SQL 2006
2008 SQL: 2008 SQL 2008
Tabel 1.1 Evoluția standardului SQL (3)

17
Cea mai mare schimbare s -a produs î n standardul SQL -92, printre care mai multe tipuri
de date, mai multe operații (cele mai notabile cele de joncțiune și operații scalare), nivele de
izolare pentru tranzacții, cursori, modificarea definiției schemei prin instrucțiunile ALTER și
DROP, etc. (3)
Funcțiile SQL se împart în cele două limbaje suportate de SGBD: de descriere a datelor
(LDD) și de manipulare a datelor (LMD).
Instrucțiuni LDD:
– CREATE este comanda prin care se creează tabele noi, iar sintaxa ei este
următ oarea: CREATE TABLE [numele tabelului] ([definirea
coloanelor])
– DROP este comanda prin care se șterg tabele, indecși sau vizualizări, iar sintaxa
ei este următoarea: DROP tipul obiectului numele obiectului .
– ALTER este comanda prin care se modifică un obi ect al bazei de date, iar sintaxa
ei este: ALTER tipul obiectului [numele obiectului]
parametrii .
Instrucțiuni LMD:
– SELECT este folosit pentru interogarea și afișarea datelor , iar s intaxa comenzii
arată în felul următor: SELECT listă de coloane [INTO tabel nou]
[FROM tabelul sursă ] [WHERE condiții de căutare ]
[GROUP BY expresie de grupare ] [HAVING condiții de
căutare] [ORDER BY expresie de ordonat [ASC|DESC]].
– INSERT este comanda prin care se introduc valori noi în tabel care are sintaxa:
INSERT INTO tabel (coloana 1 [coloana 2, coloana 3,…] )
VALUES ( valoare 1, [valoare 2, valoare 3,…] ).
– UPDATE se utilizează pentru actualizarea sau modificarea unor valori deja
existente în tabel . El are următoarea sintaxă: UPDATE numele tabelului SET
numele coloanei = valoa re [, numele coloanei = valoare… ] [WHERE condiție ].
– DELETE șterge linii dintr -un tabel, sintaxa comenzii fiind: DELETE FORM
numele tabelului [WHERE condiții ].

18
1.5. Constrângeri de integritate
„Constrângerile de integritate sunt reguli care se definesc la proiectarea unei baze de date
și care trebuie să fie respectate la proiectarea unei baze de date și care trebuie să fie respectate de
orice stare a acesteia. ” (1)
O bază de date consistentă este aceea în care datele respect ă toate constrângerile de
integritate. Acestea trebuie definite în limbaj relațional și stocate în sistem, nu la nivel de
aplicație.
„Ele pot fi clasificate:
– Constrângeri de domeniu , care sunt condiții ce se impun valorilor atributelor și
asigură integrita tea domeniilor atributelor.
– Constrângerile de tuplu , care sunt condiții ce se impun tuplurilor unei relații și
asigură identificarea corectă a tuplurilor prin intermediul cheilor.
– Constrângerile impuse prin dependențe de date (funcționale) , care sunt
const rângeri prin care valorile unor atribute ale unei relații determină valorile altor
atribute ale aceleiași relații.
– Constrângeri inter – relații sunt reguli care se impun între două sau mai multe
relații. Cele mai importante sunt constrângerile de integrita te referențială, care se
realizează prin intermediul cheilor străine și asigură asocierea corectă a relațiilor. ” (1)
1.5.1 Constrângeri de domeniu
Una din constrângerile cele mai uzuale de domeniu es te clauza NOT NULL. Acesta
oblig ă respectivul atribut să ia o valoare diferită de NULL (nicio informație) . Astfel, utilizatorul
trebuie să adauge o valoare pentru atribut conform tipului de date al acestuia. (1)
Constrângerea de verificare CHECK este ut ilă când se dorește impunerea unor restricții la
tipurile de date implicite sau crearea de tipuri noi. Sintaxa acestei constrângeri este:
CONSTRAINT nume constrângere CHECK (condiție) . (1)
În mod obișnuit, dacă nu se specifică o valoare pentru un anumit atribut dintr -un tuplu,
valoarea adăugată implicit de sistem este NULL. Totuși, dacă se dorește o altă valoare implicită,
se folosește clauza DEFAULT. (1)
1.5.2 Constrângerile de tuplu
„O relație es te definită ca o mulțime de tupluri, deci tuplurile unei relații trebuie să fie
distincte. Aceasta însemnă că într -o relație nu pot exista două sau mai multe tupluri care să
conțină aceeași combinație de valori ale tuturor atributelor. ” (1)

19
Unicitatea fiecărui tuplu este dezirabil ă, dacă două sau mai multe tupluri conțin aceeași
combinație de valori ale atributelor înseamnă că există redundanțe în baza de date, iar acest lucru
duce la scăderea perfo rmanțelor sistemului și poate produce erori neașteptate. (1)
„O super – cheie a unei relații este o submulțime de atribute ale relației care prezintă
proprietatea de unicitate, adică orice combinație de valori ale atributelor super – cheii este unică
pentru orice stare a relației. ” (1)
„O cheie candidată este o super – cheie ireductibilă, care prezintă următoarele două
proprietăți:
– Unicitate: nu există două tupluri diferite ale relației care să conțină aceeași combinație
de va lori ale atributelor cheii;
– Ireductibilitate: nu există nicio submulțime proprie, nevidă a cheii care să aibă
proprietatea de unicitate.” (1)
„O cheie primară este o cheie candidată căreia proiectantul îi conferă un rol specia l de
accesare și identificare a tuplurilor relației. ” (1)
O cheie primară poate să fie naturală sau artificială. Cheia primară naturală reflectă un
atribut deja necesar, existent în structura tabelului, cum ar fi atributul CNP pentru o tabelă
Persoană . Cheia artificială este un atribut unic adăugat în configurația tabelului pentru a
satisface constrângerea de tuplu în cazul în care nu există un atribut natural care să verifice
condiția de unicitate. Cheia artificială se preferă a fi folosită pentru a înlătura orice posibilitate de
încălcare a acestei constrângeri.
1.5.3 Constrângerile inter – relații
„O cheie străină este o submulțime FK de atribute ale unei relații R1 care referă relația R2
și satisface următoarele condiții:
– Atributele cheii străine FK sunt definite pe domenii compatibile cu cele ale atributelor
unei chei candidate a relației R 2
– Combinația de valori ale atributelor FK într -un tuplu din relația R 1, fie este identică
cu combinația de valori ale atributelor cheii candidate a unui tuplu oarecare din starea
curentă a relației R 2, fie ia valoarea NULL. ” (1)
Spre exemplu, relația Localitate are atributul Nume Județ care este o cheie străină către
atributul relației Județ, Nume.

20
„Integrit atea referențială este proprietatea bazei de date care garantează că oricare valoare
a unei chei străine se regăsește printre valorile cheii candidate corespunzătoare din relația
referită, sau cheia străina are valoarea NULL (dacă atributele acesteia nu su nt supuse
constrângerii NOT NULL). ” (1)
Sintaxa pentru adăugarea unei chei străine în SQL este:
[CONSTRAINT nume constrângere] FOREIGN KEY (cheia străină)
REFERENCES nume relație (cheie candidată) clauză ștergere
De aceste cons trângeri referențiale trebuie să se țină seama când se fac operații de
introducere, șterge și actualizare a tuplurilor relațiilor.
Când se introduce o instanță noua a relației care conține o cheie străină, trebuie să se
verifice că există valoarea ce dore ște a fi adăugată în relația referită. (1)
Când se dorește să se șteargă un tuplu din relația referită, trebuie să se respecte clauza
dată constrângerii de cheie străină. Dacă aceasta a fost de ștergere în cascadă, atunci toat e
tuplurile care făceau referire către tuplu șters, vor fi la rândul lor eliminate. O altă clauză poate fi
setarea cheii străine la valoarea NULL, dar acest lucru se poate dacă se permite cheii să ia
valoarea NULL. Dacă acestea opțiuni nu sunt specificate, atunci ștergerea tuplului va fi
restricționată. (1)
„Operația de actualizare poate fi privită ca o ștergere urmată de o introducere, deci
restricțiile de actualizare reprezintă combinația restricțiilor de introducere și de șt ergere. Într -o
relație care referă, actualizarea cheii străine a unui tuplu este admisă dacă noua valoare a cheii
străine se regăsește ca valoare a cheii candidate corespunzătoare într -unul din tuplurile relației
referite. Într -o relație referită, actualiz area valorii cheii secundare poate fi făcută în acel eași
moduri ca și ștergerea tuplurilor. ” (1)
1.5.4 Constrângerile impuse prin dependențe de date
„Dependențele de date reprezintă constrângeri care se impun valorilor atribut elor unei
relații și care determină proprietățile relației în raport cu operațiile de inserare, ștergere și
actualizare a bazei de date. ” (1)
Normalizarea este procesul prin care se evaluează și se corectează o structura de ba ze de
date pentru a se minimiza redundanțele și anomaliile care pot apărea. Aceasta se realizează prin
patru etape, care se numesc forme. (1)
„O formă normală a unei relații presupune anumite condiții pe care trebuie să le
îndeplinească valorile atributelor și depende nțele de date definite pe acea relație. ” (1)

21
„O dependență funcțională este o constrângere între două submulțimi de atribute X și Y
ale unei relații R. ” (1)
„O relație este normalizată în prima formă normală (FN1) dacă fiecare atribut ia numai
valori atomice și scalare din domeniul său de definiție. ” (1)
„O relație este normalizată în a doua formă normală (FN2) în raport cu o m ulțime de
dependențe funcționale F, dacă este în FN1 și dacă în F+ nu există nici o dependență funcțională
parțială a uni atribut neprim față de o cheie a relației. Deci, dacă orice cheie a unei relații este
formată dintr -un singur atribut, atunci relația e ste în FN2 .” (1)
„O relație este normalizată în a treia formă normală (FN3) în raport cu o mulțime de
dependențe funcționale F, dacă este în FN2 și dacă în F+ nu există nicio dependență funcțională
netrivială a uni atribut ne prim față de alt atribut neprim al relației .” (1)
„O relație cu schema R este în forma normală Boyce – Codd (FNBC) în raport cu o
mulțime F de dependențe funcționale dacă este în FN1 și dacă, prin orice dependență funcțională
netrivială X →Y din F+, unde X este o cheie a relației R. ” (1)
1.6 Gestiunea tranzacțiilor
„Conceptul de gestiune a tranzacțiilor se referă la problematica menținerii într -o stare
consistentă a bazei de date în condițiile în c are accesul la date se face în regim concurent și este
posibi lă apariția unor defecte.” (4)
„O bază de date este într -o stare consistentă dacă respectă toate constrângerile de
integritate a datelor definite asupra sa. În timpul operațiilor de adăugare, ștergere și actualizare
baza de date trece dintr -o stare în alta. Evident , starea rezultată după orice prelucrare asupra
bazei de date trebuie să fie o stare consistentă, chiar dacă în timpul prelucrării , baza de date s -a
găsit te mporar într -o stare inconsistentă. ” (4)
1.6.1 Definiție
„O tranzacție este o unitate logică de prelucrare care asigura consistența și siguranța
bazei de date. În principiu orice execuție a unui program se poate considera o tran zacție în baza
de date este într -o stare consistentă atât înainte cât și după execuția sa. Consistența bazei de date
este garantată in dependent de faptul că tranzacția a fost executată în mod concuren t cu alte
tranzacții sau că au apărut defecte în timpul execuției tranzacției. ” (4)
„În general, o tranzacție constă din tr-o secvență de operații de cit ire și scriere a bazei de
date, la care se adaugă o serie de operații de calcul. Baza de date poate fi într -o stare temporar
incons istentă în timpul executării tranzacției, dar trebuie să fie în stări consistente atât înainte, cât
și după execuția tranzacției. ” (4)

22
„Orice tranzacție trebuie să se termine, indiferent de situaț ia existentă, chiar și în cazul
unor defecte. Dacă tranzacția reușește să execute cu succes toate operațiile prevăzute, atunci
aceasta se va termina printr -o operație de validare ( commit ). În schimb, dacă tranzacția nu
reușește dintr -un motiv sau altul să își execute complet toate opera țiile prevăzute, atunci se va
termina printr -o operație de abandonare ( abort , rollback ). În cazul abandonării, execuția
este oprită, iar efectele tuturor operațiilor pe care le -a executat până în acel moment sunt anulate
astfel încât baza de date revine la starea de dinaintea lansării tranzacției. ” (4)
„Comanda de validare a unei tranzacții are dublu rol:
– Indică SGBD – ului momentul de la care efectele tranzacției pot fi reflectate în baza
de date și devin vizibile altor tranzac ții;
– Marchează momentul începând de la care efectele tranzacției nu mai pot fi anulate
(tranzacția nu se mai poate anula) și modificările efectuate în baza de date devin
permanente. ” (4)
Validarea este foarte importantă în sist emele cu tranzacții concurente, evitându -se
fenomenul de anulare în cascadă a tranzacțiilor. Fără validare, dacă o tranzacție folosește date
din altă tranzacție, și cea din urmă se abandonează, atunci și tranzacția inițială trebuie anulată.
Dar, dacă efect ele tranzacției sunt vizibile doar după ce aceasta a fost validată, celelalte tranzacții
vor beneficia de informații consistente din baza de date și nu vor mai exista probleme de genul
anulare în cascadă. (4)
1.6.2 Proprietățil e tranzacțiilor
„Prin definiție tranzacțiile sunt unități de execuție care garantează consistența li siguranța
bazei de date. Pentru aceasta, orice tranzacție trebuie să satisfacă un se t de patru condiții
sintetizate în literatură sub acronimul ACID – atom icitate, consistență , izolare, durabilitate. ” (4)
 Atomicitatea
„Se referă la faptul că o tranzacție este considerată ca o unitate elementară de prelucrare.
Aceasta înseamnă că execuția unei tranzacții se face după regula „totul sau nimic”, adică ori sunt
executate toate operațiile din tranzacție, ori nu se execută nimic. Dacă o tranzacție este î ntreruptă
datorită unor cauze oarecare, atunci îi revine SGBD – ului sarcina de a asigura, într -un fel sau
altul, terminarea tranzacției . După eliminarea cauzei care a dus la întreruperea tranzacției, în
funcție de stadiul de execuție în care s -a aflat aceasta în momentul apariției întreruperii, se poate
completa operațiile rămase neexecutate din cadrul tranzacțiilor, fie se poate anula to ate efectele
operațiilor executate de tranzacție până în momentul întreruperii. ” (4)
 Consistența
„Consistența unei tranzacții constă pur și simplu în corectitudinea sa. Orice tranzacție,
dacă este executată independent, trebuie să mențină consistența bazei de date. Astfel spus, o

23
tranzacție este un program corect care transformă baza de date dintr -o stare consistentă într-o altă
stare consistentă , care înseamnă satisfacerea tuturor constrângerilor de integritate implicite sau
explicite (unicitatea cheilor primare, integritatea referențială ).
Nu se pune problema verificării tuturor constrângerilor după ce se termină fiecare
tranzacție, deci rămâne ca orice tranzacție să fie corectă din punct de vedere logic. Consistența
este asigu rată de corectitudinea codului scris de programator. ” (4)
 Izolarea
„Se referă la propri etatea oricărei tranzacții de a vea acces doar la stările consistente ale
bazei de date. Aceasta înseamnă că modificările efectuate de către orice tranzacție sunt
inaccesibile altor tranzacții concurente până în momentul validării acesteia. Prin proprietatea de
izolare se creează iluzia că fiecare tranzacție este executată singură în sistem. Utilizatorul care a
lansat o tranzacție nu va percepe în niciun fel faptul că alte tranzacții sunt executate în același
timp în sistem.
Proprietate de izolare este importantă deoarece elimină fenomenul de anulare în cascadă a
tranzacțiilor .” (4)
 Durabilitatea
„Durabilitatea unei tranzacții este proprietatea prin care se garantează faptul ca o dată ce
tranzacția este validată, rezultatele sale devin permanente și sunt înscrise în baza de date. Chiar
dacă după momentul validării apare un defect care î mpiedică înscrierea normală a rezultatelor
tranzacției în baza de date, acestea vor fi trecute în baza de date după reluarea activității.
Rezultatele tranzacțiilor validate vor supraviețui unor căderi de sistem.
Mecanismul prin care se realizează proprietatea de durabilitate are la bază conceptul de
jurnal (log). Jurnalul este un fișier secvențial în care sunt înregistrate toate operațiile efectuate de
tranzacțiile din sistem. Jurnalul conține istoria evoluției întregului sistem. El este folosit la
reluarea activității de către proceduril e de recuperare care vor completa eventualele operații
neterminate ale tranzacțiilor care au fost validate înainte de apariția defectului. ” (4)
1.7 Controlul concurenței
Într-o bază de date în care doar un utilizator poate modi fica baza de date, nu există
tranzacții concurente, așadar, după încheierea oricărei tranzacții baza de date se va afla într -o
stare consistentă . Însă, dacă baza de date este accesată simultan, pot apărea tranzacții concurente
în situații de conflict. De a ceea, controlul concurenței este foarte important , fiind necesar pentru
a păstra proprietățile tranzacțiilor și implicit, consistența bazei de date .
„Controlul concurenței se ocupă cu mecanismele de sincronizare a acceselor astfel încât
să fie menținută in tegritatea bazei de date. Atunci când controlul concurenței este realizat prin

24
mecanismele de blocare mai apare altă problemă colaterală, și anume aceea a interblocărilor.
Datorită importanței sale problema gestiunii interblocărilor este de multe ori trata tă ca o
problematică de sine stătătoare a gestiunii tranzacțiilor.” (4)
„Modul de rezolvare al conflictului depinde de natura cererilor de acces la baza de date:
de citire sau de actualizare. ” (4)
„Dacă cererile de acces sunt de citire (regăsire), atunci secvențializarea accesului la
mediu de memorare este suficientă pentru nu a nu mai fi nevoie de alte precauții. Rezolvarea
situațiilor conflictuale cauzate de operațiile de citire simultane poate fi lăsată în seama sistemului
de operare care stabilește ordinea de satisfacere a cererilor după criteriul asigurării concurenței
maxime de operare minimizând timpul global de satisfacere a cererilor. ” (4)
„Dacă cererile de acces sunt de tipul actualizare este necesară aplicarea unor strategii
adecvate de tratare a cererilor de acces. Două procese care citesc și modifică valoarea aceluiași
obiect ar putea interacționa în mod nedorit atunci când sunt executate simultan. Pentru evita rea
acestor situații este necesară impunerea unor restricții asupra execuției concurente a proceselor
care execută operații de citire și modificare a datelor. ” (4)
Cea mai simplă metodă care rezolvă aceasta problemă este execut area secvențială a
tranzacțiilor. Dar, ideea de executare concurentă a tranzacțiilor pune accentul pe rapid itate, iar
executarea secvențială încetinește accesul la baza de date. De aceea, s -a definit un nou model de
izolare, denumit serializabilitate. Aces t mod încearcă să asigure că tranzacțiile se execută în așa
fel încât par a fi executate pe rând, adică serial, nu concurent. Cu toate acestea, executarea
tranzacțiilor trebuie să ofere un compromis între nivelu l de izolare și performanțele bazei de
date. (4)
1.7.1 Anomalii de interferență
Standardul SQL92 definește p atru niveluri de izolare a tranzacțiilor cu diferite impacte
asupra execuției t ranzacțiilor. Acestea sunt definite în termeni de trei anomalii de interferență
care trebuie să fie prevenite în cazul execuției concurente ale tranzacțiilor.
1. Actualizare pierdută ( lost update )
„Corespunde unui conflict de tip scriere – scriere și constă în faptul că rezultatul
actualizării efectuate de o tranzacție se pierde ca urmare a r eactualizării aceleiași date de către o
altă tranzacție, fără ca reactualizarea să fie influențată de rezultatul primei actualizări. ” (4)
2. Citire improprie ( dirty read s)
„Corespunde unui conflict de tip scriere – citire și apare atunci când o tranzacție
surprinde o stare temporar inconsistentă a bazei de date ” (4), adică se citește o dată scrisă de o
tranzacție care nu a fost validată , iar în final, aceasta este anulată .

25
3. Citire nereproductibilă (non-repeatable reads )
„Corespunde unui conflict de tip citire – scriere și apare atunci când aceeași tranzacție
găsește valori diferite la cit iri repetate ale aceleiași date ” (4), pentru că , între citiri, o altă
tranzacție care a fo st deja validată a modificat acea dată.
4. Citire fantomă ( phantom read )
„Apare când o tranzacție prelucrează un set de linii rezultat al unei interogări, dacă în
timpul acestei prelucrări o altă tranzacție a inserat sau șters o line care satisface condiția
interogării respective, atunci pot apărea sau dispărea linii din mulțumea de linii rezultate
interogării. ” (1)
1.7.2 Tehnici de control al concurenței
Cele mai utilizate tehnici de control al concurenței sunt cele prin blocare (care utilizează
zăvoare – locks ) și prin mărci de timp ( timestamps ).
„Controlul concurenței prin blocare încearcă să prevină execuții incorecte a unor operații
prin punerea în așteptare a tranzacțiilor care execută operații conflictuale ” (4). Aceasta se
realizează cu ajutorul zăvoarelor.
„Un zăvor este o variabilă asociată cu un articol al unei baze de date care descrierea
starea acelui articol în raport cu operațiile care se pot aplica acelui articol .” (1) Zăvoarele se pot
clasifica în funcție de numărul de stări pe care acesta le are: binare (două stări: blocat, liber) sau
multiple (trei stări: liber, blocat pentru citire – sau mod partajat , blocat pentru scriere – sau mod
exclusiv ). (1)
Pentru ambele cazuri de zăvoare se impune un protocol de blocare în două faze: toate
operațiile de blocare a zăvoarele preced operația de deblocare a zăvoarelor . Din această cauză,
pot apărea diverse situații neplăcute, cum ar fi impa sul (deadlock ). (1)
„Impasul este o blocare a execuției tranzacțiilor care apare atunci când două sau mai
multe tranzacții se așteaptă una pe cealaltă ca să elibereze un zăvor” (1). Modalitatea de tratare a
impasului diferă de la SGBD la altul.
Alte reguli ce trebuie urmate de o tranzacție care utilizează zăvoare cu stări multiple:
– „O tranzacție nu poate lansa o nouă operație de citire dacă deține în mod partajat sau
exclusiv zăvorului acelui artic ol;
– O tranzacție nu poate lansa o nouă operație de scriere dacă deține deja în mod partajat
sau exclusiv zăvorul articolului respectiv;
– O tranzacție nu poate executa o operație de eliberare a unui zăvor dacă nu îl deține în
mod partajat sau exclusiv. ” (1)

26
„În tehnica de control al concurenței bazat pe ordonarea operațiilor după mărci de timp,
ori de câte ori o tranzacție încearcă să citească sau să scrie într -un articol, se compară marca ei de
timp cu mărcile de timp de citire și de scriere ale articolului pentru a verifica ordinea
operațiilor. ” (1)
1.7.2 Niveluri de izolare
Nivelurile de izolare specifică ce tipuri de blocări se impun pentru anumite unități de
acces. Astfel, cu cât nivelul de izola re este mai mic, cu atât se aplică mai puține blocări pe unități
de acces de granularitate mai mic. Deci, un nivel de izolare mai mic crește concurența bazei de
date, dar face ca apariția inconsistențelor să aibă o probabilitate mai mare.
„Izolarea de gra dul 0 nu blochează nicio unitate de acces în citire și blochează unitățile de
acces pentru scriere doar pe durata operației de scriere. O asemenea tranzacție ignoră toate
tipurile de conflict posibile și poate cauza apariția de anomalii de actualizare pier dută, citire
improprie și citire nereproductibilă. Aceste tipuri de tranzacții se execută practic fără întârzieri în
mediul concurent, dar pot produce stări inconsistente ale bazei de date. ” (4)
„Izolarea de grad ul 1 blochează pe toată durata execuției sale unitățile de acces în care se
face scrierea, dar nu blochează deloc unitățile din care se face citiri. La acest nivel de izolare sunt
tratate corect conflictele de tip scriere – scriere și este eliminată anomalia de actualiza re pierdută.
Nivelul de concurență este ridicat, deoarece tranzacția poate fi pusă în așteptare numai pentru
operațiile de scriere. O tranzacție de gradul 1 de izolare poate citi datele unor tranzacții
nevalidate (citire improprie) și poate observa fenomen ul de citire nere productibilă. ” (4)
„Izolarea de gradul 2 blochează unitățile de acces în care face scriere pe toată durata
execuției sale, în schimb datele care sunt numai citire se blochează doar pe durata operației de
citire . Tranzacțiile executate cu gradul 2 de izolare tratează corect conflictele de tip scriere –
scriere și scriere – citire. Nu sunt posibile actualizări pierdute sau citiri ale unor date nevalidate,
dar este posibilă anomalia de citire nereproductibilă. Nive lul de concurență este mediu, fiind
posibile întârzieri din cauza blocărilor în scriere și întârzieri mai mici din cauza blocărilor de
scurtă durată pentru operațiile de citire. ” (4)
„Izolarea de gradul 3 blochează pe toată dur ata execuției lor orice unitate de acces pe care
o accesează fie în scriere, fie în citire. Este singurul grad de izolare care tratează corect toate
tipurile de conflict și garantează serializabilitatea planificărilor . Nivelul de concurență este mai
redus decât la toate celelalte grade de izolare, deoarece tranzacțiile pot fi puse în așteptare atât
pentru operațiile de scriere, cât și pentru cele de citire.” (4)
În SGBD -urile actuale nivelurile de izolare sunt disponibile sunt f ormă de opțiuni pe care
utilizatorul le poate seta înainte de începerea tranzacției. De asemenea, nivelul de izolare 0 nu
este implementat în niciuna din sistemele actuale , încercând să se evite starea d e inconsistență a

27
bazei de date, iar majoritatea SGBD – urile implementează și un nivel de izolare de nivel și
mare, care simulează execuția secvențială a tranzacțiilor. (4)
Cele patru niveluri de izolare definite de standardul SQL92 sunt prezentate în tabelul de
mai jos, în func ție de anomaliile care pot apărea :
Nivel de izolare Citire improprie Citire nereproductibilă Citire fantomă
Citire nevalidată Posibil Posibil Posibil
Citire validată Imposibil Posibil Posibil
Citire repetată Imposibil Imposibil Posibil
Serial Imposi bil Imposibil Imposibil
Tabelul 1.2 Niveluri de izolare (1)
Cu toate acestea, unele SGBD –uri implementează și alte niveluri de izolare pe lângă cele
definite în standard , cum ar fi nivelul „Snapshot ” din Microsoft SQL Server . Dar, sunt și
altele care nu au disponibile toate nivelurile din standard, cum este cazul Oracle, care nu
implementează citire nevalidată și citire repetată.

29
2.1 Microsoft SQL Server 2012
Microsoft SQL Server este un sistem complex de gestiune a bazelor de date relați onale
oferit de firma Microsoft , oferit în mai multe ediții în funcție de aplicația căreia îi este de stinată.
Limbajele de interogare suportate de SQL Server sunt Transact – SQL și SQL ANSI.
În 1987, Microsoft a format un parteneriat cu Sybase pentru a crea un SGBD, Sybase
având drepturile de distribuire pe platformele Unix/Mini, iar Microsoft pe sistemele de operare
proprii. Câțiva ani mai târziu, în 1994, parteneriatul a fost anulat, pentru că cele două companii
dorea u dezvoltarea în alte direcții, mai ales că Microsoft dorea dezvoltarea doar pe platformele
NT. La scurt timp, a fost lansată versiunea 6.0 a SQL Server care era considerabil diferită de
versiunea precedentă. (5)
2.1.1 Noutățile aduse de versiunea 2012
Ultima versiune, SQL Server 2012 , a fost lansată pe 6 martie 2012, și este prima
platformă de acest gen pregătită pentru cloud computing , devenind o soluție hibridă: o
organizație care folosește SQL Server 2012 poate să își dezvolt e aplicațiile non – virtualizat, într-
un cloud privat sau în totalitate pe un cloud public. (6)
Noua versiune aduce îmbunătățiri la disponibilitate, organizare, programabilitate,
scalabilitate, performanță, și securitate.
SQL Se rver AlwasyOn este o nouă tehnologie care asigură o disponibilitate mai ridicată
decât precedentele versiuni, care reunește uneltele pentru disponibilitate care înainte erau
separate: oglindirea baze de date, clustering , sincronizarea jurnalelor ( log shipp ing). Astfel, nu
mai este necesară ajustare manuală din partea utilizatorului , totul fiind automat, eliminând surse
de potențiale erori. (6)
Pe partea de scalabilitate și performanță s -au îmbunătățit: indecșii de coloană, supor t
crescut pentru partiții, mentenanța indecșilor se poate face în timp ce baza de date rulează . De
asemenea, tot în timp ce aceasta rulează se pot adăuga coloane cu valori implicite, fiind nevoie
doar de un zăvor exclusiv pe obiect, care durează mai pu țin decât zăvoare le exclusive pe tabele
care duc la o întrerupere mai mare . (6)
Securitatea în SQL Server 2012 se menține la același nivel ridicat ca și înainte. În studiul
din 2011 prezentat de Institutul Naționale de Standard e și Tehnologii (NIST) , se arată că din 2 Tehnologii folosite

30
ianuarie 2002 până în ianuarie 2010 cele mai puține vulnerabilități și expuneri uzuale au fost
raportate pentru SQL Server, după cum este prezentat în graficul de mai jos (6)

Figura 2.1 Vulnerabilități și expuneri uzuale raportate la NIST din perioada 2002 – 2010 (6)
Cel mai mare competitor al lui SQL Server, rămâne sistemul de gestionare a bazelor de
date oferit de Oracle. Numeroase studii s -au făcut pentru co mpararea celor două, cel de mai sus
privind securitatea fiind unul d intre ele. Dar Microsoft își încurajează clienții să aleagă SQL
Server în detrimentul Oracle pentru că poate suporta mai bine bazele de date cu misiune critică,
dar și oferă un cost total de administrare cu 460% mai mic decât Oracle, prin studiul efectuate de
Alinean (7). Astfel, cercetarea di n SUA pe 12 dintre cele mai mari organizații arată că anual
costul total al administrării pentru SGBD -ul Microsoft este de 1605 $, pe când la cel oferit de
Oracle este de 7385 $. Printre factorii importanți ai acestei diferențe considerabile se află:
numărul de utilizatori per bază de date, capacitatea bazei de date și numărul de administratori de
baze de date necesari. De asemenea, studiul arată că SQL Server este folosit în special pentru
aplicațiile web, pe când Oracle este folosit în speciale în aplicațiile de planificare a resurselor
companiilor (ERP). (7)
2.1.2 Limbajul Transact – SQL
Aces t limbaj este o extensie a limbajului SQL, ce aduce îmbunătățiri în ceea ce privește
programarea procedurală, variabile locale, diverse funcții pentru matematică și procesarea
caracterelor și a datelor, dar și schimbări ale operațiilor de UPDATE și DELETE (prin
permiterea folosirii de join). (8)

31
De asemenea, a fost introdusă și operație pentru inserarea de date în masă dintr -un fișier,
BULK INSERT , care are o performanță mult mai bună decât folosind individual operații de
insera re. A mai fost adăugată și logica „try – catch ” pentru a se efectua operații care pot genera
erori. (8)
2.1.3 Controlul Concurenței
Pentru că în lucrarea de față se discută despre performanțele tranzacțiilor în funcție de
nivel urile de izolare, este necesar să discutăm despre controlul concurenței în Microsoft SQL
Server. Acestea se pot clasifica în:
– controlul pesimis t al concurenței
Un sistem blochează datele și atunci când sunt citite, în felul acesta nicio acțiune
care este în conflict cu blocajul nu se poate realiza, cât timp acesta este activ. Acest tip de
control e ste folosit în mediile în care există concurență mare pentru date, iar costul
protecției datei respective cu zăvoare este mai mic decât costul anulării unei tran zacții în
caz de conflict. (9)
– controlul optimist al concurenței
– În acest caz, utilizatorii nu blochează datele pentru citire. Când se face o actualizare
a unei date, dacă nu există alta tranzacție care operează asupra ei, atu nci se continuă.
În caz contrar, apare o eroare care anulează și reia tranzacția. C ontrolul optimist al
concurenței este folosit în medi ile în care nu există competiții mari pentru date sau în
cazul în care costul anulării unei tranzacții este mai mic decâ t costul blocării datelor.
(9)
Tipul de control al concurenței în Microsoft SQL Server este specificat prin
selectarea nivelurilor de izolare a unei tranzacții cu ajutorul comenzilor T – SQL.
Nivelurile de izolare controlează :
– dacă zăvoarele sunt ridicat e când data este citită și ce tip de zăvor este solicitat;
– cât timp zăvoarele de citire sunt menținute;
– dacă o operație de citire care face referință către o linie modificată de o altă
tranzacție: va bloca data până când zăvorul de exclusivitate este ridicat, sau dacă
reface versiunea validată a linei care exista în momentul în care instrucț iunea sau
tranzacția a început sau d acă citește modificarea nevalidată a datelor . (10)
Alegerea unui nivel de iz olare nu afectează zăvoarele care sunt obținute pentru protecția
modificărilor datelor. O tranzacție mereu obține un zăvor de exclusivitate pentru orice data care
urmează a fi modificată și o va menține până când tranzacția se încheie, indiferent de nivelu l de
izolare setat . Pentru operațiile de citire, nivelul de izolare definesc nivelul de protecție față de
efectele modificărilor efectuate de alte tranzacții. (10)

32
Un nivel de izolare mai jos crește posibilitatea ca mai mulți u tilizatori să acceseze date în
același timp, dar totodată ridică numărul de efecte nedorite alte concurenței cum sunt citirile
improprii și actualizările pierdute ce pot apărea. În schimb, un nivel mai ridicat de izolare reduce
efectele concurenței, dar au nevoie de mai multe resurse de sistem și crește posibilitatea ca
tranzacțiile să se blocheze una pe alta. (10)
Microsoft SQL Server 2012 implementează toate nivelurile de izolare definite de
standardul ISO SQL92: citire nevali dată (nivelul cel mai de jos), citire validată (nivelul implicit),
citire repetată și serializabil (nivelul cel mai înalt în care tranzacțiile sunt c omplet izolate una de
cealaltă), dar mai are și un nivel nou, snapshot . (10)
Nivel de izolare Citire
improprie Citire
nerepetată Citire fantomă Model de
concurență
Citire nevalidată Da Da Da Pesimist
Citire validată Nu Da Da Pesimist
Citire repetată Nu Nu Da Pesimist
Snapshot Nu Nu Nu Optimist
Serializabil Nu Nu Nu Pesimist
Tabelu 2.1 Niveluri de izolare în Microsoft SQL Server (10)
Citire nevalidată
Specifică faptul că o instrucțiune poa te să citească rânduri care au fost modificate de o
tranzacție care nu a fost validată încă. Este cea mai puțin r estrictivă dintre toate nivelurile de
izolare. (11)
Tranzacțiile cu acest nivel de izolare nu emit zăvoare de citire pentru a preveni
modificarea de către alte tranzacții a datelor citite de tranzacția curentă. De asemenea, ace ste
tipuri nu sunt blocate de zăvoare de exclusivitate care ar preveni ca tranzacția curentă să citească
linii care au fost modificate, dar nu și validate. Când această opțiune este stabilită, este posibilă
citirea de modificări nevalidate, adică citiri im proprii. (11)
Citire validată
Specifică faptul că o instrucțiune nu poate să citească date care au fost modificate, dar nu
au fost validate de alte tranzacții. Acest lucru previne citirile improprii. Datele pot fi modificate
de alte tranzacții între instrucțiunile individuale din cadrul aceleiași tranzacții, putând să rezulte
citire nerepetate sau citiri fantomă. Această opțiune este implicită în Microsoft SQL Server 2012.
(11)

33
Citire repetată
Spec ifică faptul că o instrucțiune nu poate să citească date care au fost modificate, dar nu
au fost valida te încă de alte tranzacții și că nicio altă tranzacție nu poate să modifice data care a
fost citită de tranzacția curentă până când aceasta nu se termină . (11)
Zăvoare de citire sunt activate pe toate datele care sunt citite de fiecare instrucțiune în
tranzacție și sunt menținute până când tranzacția este validată. Astfel, se previne modificarea de
către alte tranzacții ale dat elor citite de tranzacția curentă. Alte tranzacții pot insera linii noi care
să se potrivească cu condițiile de căutare alte instrucțiunii executate de tranzacția curentă. Dacă
tranzacția curentă repetă instrucțiunea, aceasta va găsi și noile linii, care v a rezulta în citiri
fantomă. (11)
Snapshot
Specifică faptul că o dată citită de orice instrucțiune într -o tranzacție va fi din punct de
vedere tranzacțional versiunea consistentă a datei care exista în momentul începerii tranza cției.
Tranzacția poate doar să recunoască modificările care au fost validate la începutul tranzacției.
Modificările de date efectuate de alte tranzacții după începerea tranzacției curente nu sunt
vizibile instrucțiunilor executate în interiorul acesteia. Efectul este ca și cum instrucțiunile într -o
tranzacție văd doar „imaginea” datelor validate înaintea începerii tranzacției. (11)
Cu excepția momentului în care baza de date este în curs de recuperare, tranzacțiile
snapshot nu cer zăvoare când se citesc datele. Acest tip de tranzacție nu blochează scrierea sau
modificarea datelor de către alte tranzacții, iar acestea, la rândul lor, nu blochează tranzacțiile
snapshot în a citi datele. (11)
Pentru a p utea folosi nivelul de izolare snapshot , trebuie ca opțiunea
ALLOW_SNAPSHOT_ISOLATION să fie setată. (11)
O tranzacție care a fost începută cu un anumit nivel de izolare nu poate fi setată apoi la
nivelul snapshot . Totuși, dacă o tranzacție a început cu nivelul snapshot , poate fi schimbat
nivelul de izolare, și apoi din nou la nivelul snapshot . (11)
O tranzacție care rulează cu acest nivel de izolare poate să vizualizeze modificările
efectuate de ace asta. Adică, dacă tranzacție face o actualizare a unui tabel, apoi execută o
instrucțiune SELECT asupra aceluiași tabel, datele modificate vor fi incluse în setul returnat. (11)
Serializabil
Acest nivel specifică faptul că: o i nstrucțiune nu poate citi date care au fost modificate,
dar nu și validate de alte tranzacții; nicio al tă tranzacție nu poat e să modifice data care a fost
citită de tranzacția curentă până când aceasta nu se încheie; și alte tranzacții nu pot insera linii

34
noi cu valori ale cheilor în gama cheilor care sunt citite de instrucțiuni din tranzacția curentă
până când tranzacția curentă se termină. (11)
Astfel, se vor pune zăvoare pe toate liniile ale căror chei se potrivesc condițiilo r de
căutare ale fiecărei instrucțiuni executat e de tranzacții. În acest fel, vor bloca actualizările sau
inserările efectuate de alte tranzacții care ar putea interveni în executările instrucțiunilor
tranzacției curente. Deci, orice instrucțiune executată a doua oară va citi același set de linii.
Aceste zăvoare sunt menținute până la sfârșitul tranzacției. (11)
Acest nivel este cel mai restrictiv deoarece blochează un set de linii și le menține până
când se termină tranzacția, rezultând într -o concurență slabă. (11)
2.1.4 Modalitatea de blocare a datele în SQL Server
Nivelurile de izolare diferă între ele prin tipurile de blocare a datelor și care dintre aceste
date sunt vizate. De aceea este importa nt să se cunoască și modalitățile de blocare a datelor.
SQL Server 2012 are un sistem de blocare multi – granular care permite diferite tipuri de
resurse să fie blocat de o tranzacție. Pentru a minimiza costul blocării, SQL Server blochează
automat resurse le la un nivel adecvat sarcinii care se execută. Blocarea la granularități mai mici
(de exemplu la nivel de linie din tabel), sporește concurente, dar poate avea un cost auxiliar
determinat de numărul mai mare de zăvoare necesare dacă mai multe linii sunt blocate. Blocările
la granularități mai mari (cum ar fi la nivel de tabel) sunt mai slabe din punct de vedere al
concurenței, pentru că în timpul blocării unui tabel de o tranzacție, se restricționează accesul
altor tranzacții la datele din acel tabel. În schimb, acestea au un cost suplimentar mic, deoarece
se mențin mai puține zăvoare. (12)
SQL Server poate bloca următoarele resurse, în ordinea crescătoare a granularității:
Resursă Descriere
RID Identificatorul de linie – folosit pentru a bloca o singură linie dintr -un
tabel
KEY Blocarea liniei în interiorul unui index – folosit pentru protecția gamei
unei chei într -o tranzacție serializabiliă
PAGE 8 KB – pagini de date sau de indecși
EXTENT Grup învecinat de 8 pagini de d ate sau de indecși
HOBT Un bloc heap sau un arbore binar
TAB LE Între tabelul, inclusiv datele și indecșii
FILE Un fișier de bază de date
APPLICATION O resursă specificată de o aplicație
METADATA Zăvoare pe metadate
ALLOCATION_UNIT O unitate de alocar e
DATA BASE Întreaga bază de date
Tabel 2.2 Resursele ce pot fi blocate mecanismele bazei de date SQL Server

35
SQL Server blochează resursele folosind zăvoare diferite care determină în particular
care resursă poate fi accesată de tranzacțiile concurente. Zăvoarele sunt obținute automat de
sistem, dar a dițional, și utilizatorul pentru să blocheze manual datele. (13)
Zăvoarele folosite sunt:
– Citire (shared – S) este folosit pentru operațiile care nu schimbă sau actualizează
datele (operații doar citire), cum ar fi instrucțiunea „ SELECT ”. (13)
– Actualizare (update – U) este folosit pe resursele care pot fi actualizate . Previne o
impasurile comune care apar când mai multe sesiuni citesc, blochează și event ual
actualizează resursele mai târziu. (13)
– Exclusiv (exclusive – X) – este folosit pentru operațiile de modificare a datelor cum ar
fi „INSERT ”, „UPDATE ” sau „DELETE ”. Asigură imposibilitatea actualizărilor
multiple să fi făcu te pe aceiași resursă în același timp. (13)
– De intenție (Intent ) – este folosit pentru stabilirea unei ierarhii a blocărilor. Sunt trei
tipuri de zăvoare de acest tip: intenție de scriere (intent shared – IS), intenție de
exclu sivitate (intent exclusive – IX) și scriere cu intenție de exclusivitate (shared with
intent exclusive – SIX). (13)
– Schema (Schema ) – este folosit când operațiile depind de schema unui tabel care se
execută. Cele două tipuri de zăvoare schemă sunt: modificarea schemei ( schema
modification – Sch-M) și stabilitatea schemei ( schema stability – Sch-S) (13)
– Actualizare în masă (Bulk Update – BU) – este folosit când se copiază date într -un
volum foarte mar e într -un tabel și este sugestionată comanda „ TABLOCK ”. (13)
Zăvoarele pentru citire (S) permit tranzacțiilor concurente să citească o resursă. Nicio altă
resursă nu poate modifica data atâta timp cât zăvorul de citire există pe acea resursă. El e sunt
eliberat e de îndată ce data a fost citită, cu excepția cazului în care o tranzacție cu un nivel de
izolare este setat ă la citiri repetate sau mai sus ori este folosită o sugestie de blocare ( locking
hint ) pentru a reține z ăvorul pe întreaga durată de execuție a tranzacției. (13)
Zăvoarele de actualizare ( U) previn situațiile de impas . Un tipar de actualizare tipic
constă din următoarea înșiruire : o tranzacție citește o înregistrare, obține un z ăvor de citire pe
resursă (pagină sau linie), apoi modifică linia , care necesită schimbarea zăvorului către unul
exclusiv. Dacă cele două tranzacții achiziționează blocarea pentru citire a resurse i și apoi
încearcă să actualizez e data în mod co ncurent, una din tranzacții încearcă să obțină un zăvor
exclusiv. Conversia zăvorului de la unul pentru citire la unul exclusiv trebuie să aștepte deoarece
cealaltă tranzacț ie deține un zăvor de citire. Dacă cealaltă tranzacție dorește să actualizeze la
rândul ei resu rsa, încearcă să modifice zăvorul la unul exclusiv. Astfel, ambele tranzacții se
așteaptă una pe alta să treacă zăvorul la unul exclusiv , producându -se un impas . (13)

36
Pentru a se preveni potențialele probleme de impas , zăvorul de actualizare sunt folosite.
Doar o singură tranzacție poate să obțină acest tip de blocare pe o anumită resursă la un moment
dat. Dacă o tranzacție modifică o resursă, zăvorul de actualizare este convertit către unul
exclusiv. În celelalte cazuri, este convertit către unul de citire. (13)
Zăvoarele exclusive ( X) previn accesul la o resursă de către tranzacțiile concurente. Nicio
altă tranzacție nu poate să citească sau să modifice datele blocate în mod exclusiv. (13)
Un zăvor de intenție indică faptul că SQL Server dorește să obțină zăvoare de citire sau
exclusive pe anumite resurse aflate mai jos în ierarhie. Spre exemplu, un zăvor de intenție de
citire plasat la nivel de table înseamnă că tranzacț ia intenționează să plaseze zăvoare de citire pe
pagini sau linii din acel tabel. Setarea unui zăvor de intenție la nivel de table previne ca o altă
tranzacție să obțină ulterior un zăvor e xclusiv pe tabelul care conține pagina respectivă. Acest tip
de blo care îmbunătățește performanța deoarece SQL Server examinează zăvoarele de intenții
doar la nivelul tabelului pentru a determina dacă o tranzacție poate să achiziționeze în siguranță
un zăvor pe acel tabel. Acesta înlătură necesitatea de a examina fiecare zăvor de linie sau pagină
într-un table pentru a determina dacă o tranzacție poate să blocheze întregul tabel. (13)
Zăvorul de intenție de citire ( IS) indică dorința unei tranzacții de a citi câteva (dar nu
toate) din resursele aflate mai jos în ierarhie, plasând zăvoare de citire pe acele resurse
individuale. (13)
Zăvorul de intenție de exclusivitate ( IX) indică dorința unei tranzacții de a modifica
câteva (dar nu toate) resursele aflate mai jos în ierarhie, plasând zăvoare de exclusivitate pe acele
resurse individuale. IX este un super -set al lui IS. (13)
Citire cu intenție de exclusivitate ( SIX) indică dorința unei tranzacții de a citi toate
resursele aflate mai jos în ierarhie și să modifice câteva (dar nu toate), plasând zăvoare de
intenție de exclusivitate (IX) pe acele resurse individuale. Zăvoare IS concurente la resursele de
la niveluri superioare su nt permise. De exemplu, un zăvo r SIX pe un tabel permite zăvoare
concurente IS, și zăvoare IX pe pagini care sunt în curs de modificare și zăvoare de exclusivi tate
pe linii. Poate fi doar un singur zăvor SIX pe resursă la un moment dat, prevenind ac tualizările
resurselor de către alte tranzacții, deși tranzacțiile pot ci ti resursele aflate mai jos în ierarhie prin
obținerea unui zăvor IS la nivel de tabel. (13)
Zăvoarele de modificare a schemei ( Sch – M) sunt folosite când o operație din limbajul
de descriere a datelor (LDD) se efectuează. (13)
Zăvoarele de menținerea stabilității schemei ( Sch – S) sunt folosite când se compilează
interogările. Acestea nu blochează niciun zăvor tranzacțional , inclusiv zăvorul de exclusivitate.
Deci, alte tranzacții pot continua să r uleze cât timp o interogare este compilată. Cu toate acestea,
operații de tip DDL nu pot fi efectuate asupra tabelului. (13)

37
Zăvoarele de actualizare în masă (BU) sunt folosite când un volum mare de date este
copiat într -un tab el fie prin sugestia „ TABLOCK ” este specificat sau opțiunea de tabel „ table
lock on bulk load ” este setată folosind „ sp_tableoption ”. Aceste zăvoare permit
procesarea concurentă a volumului masiv de date prevenind alte procese decât cel de copiere a
datelo r să acceseze tabelul. (13)
2.2 HTML
Paginile Web sunt create cu ajutorul limbajului de marcare de hiper – text, HTML
(HyperText Markup Language). Acesta folosește un set special de instrucțiuni denumite etichete
(tags) sau ma rcaje (markup) pentru a defini structura și dispunerea unui document Web. (14)
Exemple de elementele cele mai folosite HTML definite între etichete:
– title (titlul paginii), <title> …</title>
– body (corpul paginii), <body>… </b ody>
– paragraph (paragaf). <p> …</p>
Pentru a permite definiri de stiluri se folosește Cascading Style Sheets (CSS) . Stilurile
sunt reguli care definesc aspectul unui element Web. (14)
Paginile sunt transmise prin HTTP ( Protoco lul de Transfer Hypertext ), care este un
protocol din nivelul aplicație al suitei de protocoale Internet . Alte informații de metadata sunt
transmise odată cu documentul pentru a -i permite browser -ului Web să știe să îl trateze. Aceste
includ de cele mai mu lte tipul de media Internet (exemplu text/html ) și tipul de codare al
caracterelor pe care le afișează. (15)
2.3 JavaServer Pages
JavaServer Pages, pe scurt JSP, este o tehnologie pentru dezvoltarea aplicațiilor web
dinamice in trodusă în anul 1999 de firma Sun Microsystem, și folosește limbajul de programare
Java. JSP a fost dezvoltat peste Java servlets și este parte din J2EE, folosindu -se de multe dintre
librăriile ale acesteia. (16)
Cu ajutorul JS P se pot încorpora ușor conținut dinamic de Java folosind etichete de
marcare ( markup tags ) în pagini statice de HTML. Când o pagină este cerută de un browser web,
se rulează codul și se decide ce se întoarce la browser. (16)
Aceasta tehnologie este cu atât mai importantă pentru că, spre deosebire de Java Servlets,
codul Java este introdus în pagina HTML, și astfel, se pot crea mai ușor pagini complexe cu
coduri HTML și CSS, fără să s e mai facă aceste apeluri prin out.println( ), oferind o
flexibilitate mult mai mare . (16)

38
Cum un server web are nevoie de un container pentru a furniza o interfață pentru servlet,
în același mod este nevoie de un container JSP pentru a procesa paginile JSP. Acesta este
responsabil pentru interceptarea cerințelor pentru paginile JSP. Pentru a procesa toate elementele
JSP din pagina, containerul convertește prima oară pagina într -un servlet. Aceasta conversie
implică transformarea tuturor părților de HTML/CSS în comenzi println(), iar toate elementele
de JSP sunt schimbate în cod Java care implementează comportamentul dinamic corespunzător.
Apoi, se compilează clasa servlet rezultată. Acestea descriu etapa de traducere a paginii JSP care
de obicei, ia o perioadă de timp sufic ient de mare pentru a fi observată de cel care accesează o
pagina JSP. (16)
Containerul JSP este responsabil, de asemenea, pentru invocarea clasei servlet generată
de etapa de traducere, care procesează fiecare cerere și genere ază răspunsul (etapa de procesare a
cererii). (16)
Atâta timp cât pagina JSP rămâne neschimbată, toate cererile ulterioare ajung direct la
etapa de procesare a cererii. Doar atunci când pagina JSP este modificată va trece din n ou prin
etapa de traducere a procesării. (16)
Elementele JSP
Există trei tipuri de elemente JSP care pot fi folosite: directivele, acțiunile și scenariile
(scripting ). (16)
Directivele specifică inf ormațiile despre pagină care rămân neschimbate între cereri:
– <%@ page … %> definește atributele dependente de pagină, cum ar fi urmărirea
sesiunii, paginile de eroare și cerințe de buffer;
– <%@ include … %> include un fișier în timpul etapei de traducere;
– <%@ taglib … %> declară o librărie de etichete care conține acțiuni
personalizate care sunt folosite în pagină.
Elementele de scripting ajută la adăugarea de bucăți de cod (în general Java) într -o pagină
JSP și sunt executate când pagina este solicitată. El ementele pot fi:
– <% …%> descrie un scriptlet folosit pentru încorporarea codului;
– <%= … %> este folosit când se dorește ca rezultatul să fie adăugat la răspuns;
– <%! … %> descrie declarațiile ce sunt folosite pentru a declara variabile de instanță
și metode în implementarea clasei paginii JSP.
Procesarea cererilor și gestionarea sesiunilor
În JSP, câteva obiecte Java sunt disponibile automat codului de scripting, deci nu ai
nevoie să le declari manual. Ele se numesc obiecte implicite, printre care și: request (cereri) ,

39
session (sesiune) și response (răspuns), care îți oferă mecanisme simple pentru accesarea
cererilor, gestionarea sesiunile și configurarea răspunsurilor. (17)
Codul pentru accesarea informațiilor trimise ca parte di n cerere este foarte simplu, spre
exemplu, pentru a lua parametrul email:
<% String email = request.getParameter( “email”);%>
Obiectul request este implicit o instanță a interfeței HttpServletRequest , iar
toate funcționalitățile acestei interfețe sunt dispo nibile prin acest obiect. (17)
Cum cererile HTTP sunt fără stare (stateless) , pentru a lega mai multe cereri de la un
singur utilizator, este o opțiune folosirea sesiunilor, prin intermediul obiectului implicit
session . Se pot stoca și returna date asociate sesiunii curente. (17)
Spre exemplu, pentru stocarea email -ului utilizatorului care s -a autentificat se poate stoca
valoarea acestuia prin operația:
session.setAttribute(“email”, email)
iar pentru recuperarea valorii email -ului se va folosi opera ția:
session.getAttribute (“email”).
2.4 Java DataBase Connectivity
Java DataBase Connectivity ( JDBC) este aplicația de interfață de programare (API –
Aplication Programming Interface) pentru conectarea pro gramelor în Java la SGBD – uri și este
definită în pachetele java.sql și javax.sql . Avantajul acestui tip de conexiune este că,
spre deosebire de PHP, oferă posibilitatea că se pot pasa obiecte complexe către applet -urile din
interiorul arhitecturii Java.
Pentru ca integrarea cu baza de date să fie completă, este necesar și un driver (adaptor la
client) pentru a converti cererile programelor în Java către un protocol pe care SGBD -ul îl poate
întelege. Pentru versiunea 2012 a SQL Server 2012, Microsoft pune la dispoziție un driver JDBC
gratuit, versiunea 4.0. Pentru a se încărca în aplicație driverul se folosește metoda:
Class.forName(„ com.microsoft. jdbc.sqlserver .SQLServerDriver”)
Pentru conectarea la baza de date dorită se instanțiază un obiect din clasa Connection
cu ajutorul metodei statice a clasei DriverManager, getConnection() , al cărui
parametru este URL -ul conexiunii la SGBD (în cazul nostru SQL Server 2012):
numeConexiune = DriverManager.getConnection(connectionURL )

40
unde :
connectionURL= jdbc:sqlserver ://[serverName [ \instanceName]
[:portNumber]] [;property=value [;property=value]]
Pentru rularea intrucțiunilor SQL este necesară instanțierea unui obiect de tip Statement,
cu ajutorul metodei createStatement() aplicată obiectului conexiune creat anterior, al cărui
parametru îl reprezintă instrucțiunea SQL ce se dorește a fi executată.
Statement nume = numeConexiune.cr eateStatemenet(instructiuneSQL)
Executarea propriu – zisă a instrucțiunii se poate face cu trei tipuri de metode în funcție
de tipul instrucț iunii SQL:
– executeQuery() dacă instrucțiunea este de SELECT
– executeUpdate() dacă instrucțiunea schimbă baza de date în vreun fel (exemplu:
INSERT, UPDATE, DELETE ,etc)
– execute() dacă nu este sigur de tipul instrucțiunii SQL.
Rezultatul metodei executeQuery () este un obiect din clasa ResultSet , care are
un cursor ce indică linia curentă. Totuși, înainte ca orice linie să fie încărcată, cursor ul
referențiază către o line ineexistentă înainte de prima linie rezultată. Pentru a mișca curso rul pe
linia următoar e se folosește metoda next ().

41
3.1 Descrierea aplicației
Realizarea aplicației presupune proiectarea și implementarea unei baze de date și a unei
interfețe web pentru rezervarea online a biletelor la un cinematograf . Utilizatorii acestei apl icații
sunt: clientul c are dorește să facă o rezervare și administratorul care adaugă o programare nouă a
unui film.
Baza de date va memora informații legate de client, filme care rulează la cinematograf,
sălile acestuia, orarul filmelor pe săli, a rezerv ărilor efe ctuate de clienți, dar și ale administratorul
care se ocupă de programările filmelor.
Interfața web deservește ca modalitate de introducere sau șterge de informații noi în baza
de date legate de: un client, o rezervare, o programare. Înregistrar ea în baza de date a unui
administrator, a unui film, a unei săli, a unui județ și al unei localități se face doar de către
administratorul bazei de date.
Clientul se folosește de interfața web pentru a vizualiza filme le care rulează la
cinematograf, programarea lor, iar pe baza acestor informații poate face rezervările dorite.
Precondiția rezervării este ca utilizatorul să fie autentificat pe website. Autentificarea se face cu
ajutorul e -mail-ului și parolei înscrise în baza de date. Dacă el nu are un con t valid, trebuie să se
înregistreze folosind un formu lar în care trebuie să introducă o adresă de e -mail validă, o parolă,
numele și prenumele, opțional data nașterii, numărul de telefon, adresa, localitatea și județul de
proveniență.
Administratorul se au tentifică prin interfața web pentru a punea face programările
filmelor disponibile în baza de date, pe z ile și ore, într -o sală disponibilă a cinematografului și
într-un interval orar corespunzător.
3.2 Cerințele hardware și software
Cerințele hardware și software pentru ca un client să ruleze aplicația sunt minime, având
nevoie fie de calculator de uz personal, telefon inteligent sau o tabletă , singura condiție fiind
accesul la internet printr -un browser web ( Internet Explorer, Google Chrome, Mozilla Firef ox).
Serverul, Apache Tomcat versiunea 7.0.27, este rulat pe un sistem cu procesor Intel Core
i3 m370, memorie RAM 4 GB, cu sistem de operare Windows 7.
3 Implementare

42
3.3 Baza de date
Menționez că baza de date se află în formă normală Boyce – Codd (FNBC)
Diagrama Ent itate – Asociere care descrie baza de date este prezentată în Anexa 1.
Baza de dată implementată conține opt relații:
– Client ( Id_utilizator , Email, Parola, Nume, Prenume, Data_Nașterii,
Id_localitate, Adresa, Telefon)
– Administrator ( Id_administrator , Email , Parola, Nume, Prenume)
– Localitate ( Id_localitate , Nume, Id_Județ)
– Județ ( Id_județ , Nume)
– Film (Id_film , Nume, Durată, Gen, Sinopsis)
– Sală ( Id_sală , Număr_locuri)
– Programări ( Id_programări , Id_administrator, Id_sală, Id_film, Dată_început,
Dată_sfârșit, L ocuri_libere, Preț_loc)
– Rezervări ( Id_rezervare , Id_client, Id_programări, Nr_locuri_rezervate)
Asocierile dintre entități sunt:
– Între Județ și Localitate există o asociere 1 – N, deci mai mult localități pot
aparține aceluiași județ . Relația referită, Lo calitate, conține cheia străina Id_Județ
– Între Localitate și Client există o asociere 1 – N, deci o localitate poate să fie
populată de mai mulți clienți . Relația referită, Client, conține cheia străină
Id_Localitate
– Între Client și Rezervări există o asoc iere 1 – N, astfel o rezervare aparține unui
singur client, pe când acesta poate să facă mai multe rezervări . Relația referită,
Rezervări, conține cheia străină id_client
– Între Programări și Rezervări există o asociere 1 – N, o rezervare putând fi făcută
pentru o singură instanța din relație Programări . Relația referită, Rezervări,
conține cheia străină id_programări
– Între Sală și Programări, și între Film și Programări există pentru ambele cazuri o
asociere 1 – N, o instanță a relației Programări având un singur film și o singură
sală asociată. Relația referită, Programări, conține cheile străine id_film și id_sala.
Un client trebuie să furnizeze adresa sa de e -mail, o parolă, numele și prenumele
obligatoriu. Celelalte atribute , Data_Nașterii, Id_localitate , Adresa, Telefon, pot luat valoarea
NULL . De asemenea, se impune o co nstrângere de unicitate pentru câmpul email, pentru a se
evita confuzii la autentificarea pe website.

43
Unui a dministrator i se atribuie o adresă de e -mail și o parolă, care se memorează în baza
de date alături de numele și prenumele acestuia. La fel ca și în cazul relației Client, atributului
email i se pune o constrângere de unicitate.
Relațiile Sală, Județ și Localitate au toate atributele cu opțiunea NOT NULL , deci sunt
obligatorii. T abela Film poate avea câmpurile gen și sinopsis nule.
Administratorul se ocupă cu programarea filmelor pe sală și oră, iar în funcție de aceste
programări, un client poate să își rezerve un număr maxim de 10 locuri pentru o programare.
Pentru a nu se depăș i numărul maxim, am introdus o constrângere de tip CHECK :
CONSTRAINT ck_numar_rezervari CHECK (nr_locuri_rezervate BETWEEN
1 AND 10)
De asemenea, un client nu poate să facă mai mult de o rezervare pentru o anumită
programare, care s -a soluționat printr -o constrângere de unicitate a mulțimii compuse din
atributele id_client și id_programare :
CONSTRAINT uq_rezervare UNIQUE (id_client, id_programari)
Pentru introducerea unei noi programări, se folosește o procedură stocată, care poate fi
găsită la Anexa 2 . Ac easta primește ca parametrii de intrare valorile de introdus în tabelă,
@id_sală , @id_administrator , @id_film , @preț_bilet , @data_început ,
@data_sfârșit și are un parametru de ieșire , @răspuns care semnalează erorile (dacă
apar) sau executarea cu succes a procedurii (este inițializat cu 0 în corpul procedurii) .
Se verifică mai întâi dacă intervalul în minute între data de începere și data de terminare
să nu fie mai mic ă decât durata filmului. Pentru aceasta s -a definit o variabilă @durată , care să
conțină d urata filmului și s -a folosit funcția T -SQL, datediff cu opțiunea minute . Dacă
intervalul este mai mic, atunci variabila de ieșire @răspuns ia valoarea 1.
Se definește un cursor în care se colectează toate valorile pentru data_început și
data_sfârșit din t abelă pentru care id_sală corespunde parametrului @id_sală .
DECLARE cursor_timp CURSOR FOR SELECT data_inceput, data_sfarsit
FROM PROGRAMARI where id_sala = @id_sala
Cu aju torul acestuia se poate testa dacă nu cumva programarea propusă de administrator
se suprapune cu altă programare deja existentă în baza de date. Dacă acest lucru se întâmplă,
atunci variabila de ieșire @răspuns ia valoarea 2. La sfârși t cursorul se închide și se face
dealocarea acestuia.
CLOSE cursor_timp
DEALLOCATE cursor_timp

44
În final, dacă @răspuns are valoarea inițială 0, ceea ce înseamnă că nu a apărut niciuna
din erorile menționate mai sus, se execută comanda de inserare a valorilor în baza de date, iar
tranzacția este validată.
Pentru rezervarea unor locuri de către client, se apel ează procedura
rezervare_bilete , ce se află la Anexa 3. Aceasta primește ca parametrii @id_client ,
@id_programare , @nr_bilete_rezervate și are ca variabilă de ieșire @răspuns care
semnalează erorile (dacă apar) sau dacă procedura s -a încheiat cu succes.
Se definește un cursor în care se păstrează toate valorile existente în baza de date ale
atributelor id_client și id_programari din rezervări .
DECLARE cursor_programari CURSOR FOR SELECT id_client,
id_programari FROM REZERVARI
Cu ajutorul acestuia se verific ă dacă clientul care dorește să facă o rezervare pentru
programarea respectivă nu a mai făcut altă rezervare. Astfel, se evită situația în care un client
face mai mult de o rezervare pentru o programare dată. La sfârșit cursorul se închide și se face
dealo carea acestuia.
CLOSE cursor_programari
DEALLOCATE cursor_programari
Dacă nu au intervenit alte erori, adică variabila @răspuns rămâne la valoarea zero, se
inserează în tabela Rezervări valorile parametrilor @id_client , @id_programare ,
@nr_bilete_rezervat e și se scade din valoarea atributului locuri_libere valoarea
parametrul @nr_bilete_rezervate din tabela Programări unde id_programari este
egal cu parametrul @id_programari .
Pentru anularea une i rezervări de către un client am creat o procedură stocată,
sterge_rezervare , al cărui cod se găsește în Anexa 4. Aceasta primește un singur
parametru , @id_rezervare , care corespunde rezervării care se dorește a fi anulată. Înainte, se
selectează numărul de locuri rezervate și cheia primară a programării asociate re zervării. Ele sunt
necesare pentru a actualiza atributul locuri_libere din tabela Programări, eliberându -se
astfel locurile ocupate de rezervare care se șterge. Operația de actualizare se face după ce s -a
șters rezervarea.
3.4 Interfața Web
Pagina este structurată după cum se observă în figura 3.1 . Această împărțire a paginii a
fost realizată cu ajutorul etichetei <div> din HTML cu identificatori care specifică
comportamentul prin elemente CSS.

45

Figura 3.1 Structura site-ului web
La antet se găsește logo-ul și legături către pagina principală (Home), pagina de contact
(Contact) și pagina dedic ată administratorului ( Admin), după cum se poate observa în figura 3. 2.

Figura 3.2 Antetul site -ului
Bara de navigare (figura 3.3) conține le gături către pagina pri ncipală HOME, pagina în
care se regăseș te programul cinematografului, PROGRAM, pagină cu lista filmelor aflate în baza
de date, FILME , pagina cu pro moțiile oferite de Cinemateca, PROMOȚII, și pagina dedicată
unui ghid care să ajute clien tul să rezerve bile te la film, CUM REZERV .

Figura 3.3. Bara de navigare
Bara laterală (figura 3.4) conține formularul de autentificare, formular de căutare, un
meniu lateral care conține legături către pagina principală, pagina programului și cea a filmelor,
dar și un meni u cu legături externe către site -uri destinate cinefililor.

46
Figura 3.4 Bara laterală de navigare
Un client se poate autentifica folosind formularul găsit în meniul lateral (după cum se
observă în figura 3.4) , scriindu -și corect e -mail-ul și parola cu care s-au înregistrat.
Autentificarea și deconectare a am realizat -o cu ajutorul sesiunilor HTTP. Astfel, dacă
utilizatorul este autentificat, se păstrează în sesiune atributul „email”, iar pentru deconectare se
invalidează sesiunea prin comanda request.getSes sion(false).invalidate() care
anulează sesiunea curentă fără să mai creeze o sesiune nouă.
Formularul de autentific are conține câmpul de tip text USER și câmpul de tip parola
(password ), PAROLA și un buton cu rolul de executare a acțiunii designate formul arului , a
cărei metodă de cerere HTTP este post .
Procesul de autentificare începe cu conectarea la baza de date, care se realizează cu
ajutorul driverului Microsoft SQL Server JDBC, prin comanda:
Connection con = DriverManager.getConnection ( jdbc:sqlserver ://+
serverName+";databaseName="+databaseName+"; integratedSecurity=true;")
unde serverName reprezintă numele serverului SQL, iar databaseName reprezintă numele
pe care îl are baza de date.

47
Dacă se realizează conexiunea cu baza de date, atunci se iau valor ile introduse de
utilizator în formular prin comanda request.getParamater („numeParamateru”) .
Apoi, se creează un șir de caractere ce conține instrucțiunea SQL care reîntoarce numele și
prenumele utilizatorului care au atributul email și atributul parolă e gale cu câ mpurile introduse în
formular. Se creează un obiect de tip Statement ce ține de conexiunea creată, cu ajutorul
căruia se va executa interogarea bazei de date. Rezultatele obținute sunt memorate de un obiect
ResultSet care menține un cursor. Metod a next() mută cursorul la altă line rezultată,
asemenea comenzii fetch din T – SQL. În cazul ideal se va obține o singură line, caz în care
valoarea returnată de next() este true (adevărat ); Altfel, dacă utilizatorul nu a introdus corect
datele, interogarea nu va returna nicio linie, caz în care valoarea returnată de metodă este false
(fals).
În cazul în care clientul își scrie greșit fie emailul, fie parola este redirecționat către
pagina de autentificare , după cum se observă în figura 3.5 . Principiul de fu ncționare al acestei
pagini este identică cu formularul de autentificare din bara laterală de navigare. Astfel, după
succesul autentificării, clientul este redirecționat către pagina din care a accesat inițial formularul
de autentificare.

Figura 3. 5. Pagină de autentificare

48
Dacă autentificarea este făcută cu succes, utilizatorul rămâne pe pagina de unde s -a
autentificat, și formularul devine un meniu (figura 3.6) din care utilizatorul își poate alege din
următoarele acțiuni: să vizualiz eze profilul sau r ezervările pe care acesta l -a făcut, să își schimbe
parola sau să se deconecteze de pe website.
Figura 3.6 Utilizator autentificat
Pentru schimbarea parolei, trebuie completat un formular (figura 3.7) cu trei câmpuri:
parola veche, parola nouă și rescrie rea parolei noi pentru verificare suplimentară. Dacă c ele două
parole noi nu sunt identice , se afișează un mesaj de eroare. Dacă toate câmpurile sunt valide se
execută comanda de actualizare a bazei de date cu ajutorul metodei executeUpdate() a
clasei Statement .
Figura 3.7. Formular schimbare parolă
În pagina Vizualizare Profil (figura 3.8 ), clientul poate să își verifice datele personale
înscrise în baza de date legate de nume, prenume, data nașterii, localitate, județ, adresă și telefon.
Datele sunt obț inute prin comanda de interogare a bazei de date, select , cu clauza: atributul
email din baza de date să fie identic cu atributul sesiunii email. Reprezentarea datelor se face
intr-un tabel. Totodată, utilizatorul are posibilitatea să își modifice aceste d ate, prin apăsarea
butonului „Editează” care îl redirecționează pe acesta către pagina corespunzătoare.
Figura 3.8 Vizualizare profil

49
Pagina de modificare profil (figura 3.9) conține un formular în care clientul își poate edita
datele personale existent e în baza de date. Câmpurile text sunt populate deja cu datele existente,
dar doar câmpurile referitoare la nume și la prenume sunt obligatorii. Pentru modificarea datei de
naștere există trei câmpuri în HTML de tip select (zi, lună, an), cu valoarea princ ipală data de
naștere existentă în baza de date, dacă aceasta există; celelalte câmpuri sunt de tipul text .
Operația SQL care face modificările atributelor este „ UPDATE ” cu clauza: atributul email din
baza de date să fie identic cu atributul sesiunii email .

Figura 3.9 Editare profil
Pagina Rezervările tale, care poate fi vizualizată în figura 3.10, conține toate rezervările
pe care clientul autentificat le -a efectuat. De asemenea, el are posibilitatea să anuleze rezervările.

Figura 3.10 . Rezervările un ui client
Rezervările efectuate de client sunt prezentate într -un tabel în care sunt înscrise numărul
sălii în care este proiectat filmul, data de începere a filmului, numele filmului și un buton pentru
anularea respectivei rezervări. Acestea au fost selec tate din baza de date cu ajutorul a două
joncțiuni între tabelele Rezervări și Client și între Programări și Filme. Din prima joncțiune se

50
selectează valorile pentru id_rezervare , id_programari și nr_locuri_rezervate
unde id_client ia valoarea id_client pentru care adresa de email este atributul email
stocat în sesiunea curentă. Cea de -a doua joncțiune selectează id_sala (care este de altfel și
numărul sălii cu care este identificat de client), data_inceput și numele filmului pentru care
id_programari este cel selectat în joncțiunea precedentă, iar id_film din tabela Programari este
egal cu id_film din tabela Film. Pentru ștergerea rezervării se apelează procedura stocată
sterge_rezervare . Aceasta se face cu ajutorul unui obiect din clasa
CallableStatement:
CallableStatement cstmt = con.prepareCall ("{call dbo.sterge_rezervare(?)}");
cstmt.setInt(1,Integer.parseInt(rezervare));
boolean ok = cstmt.execute();
Cu metoda setInt se setează parametrul de intrare al procedurii, care este id -ul
rezervării, iar apoi se execută cu metoda execute () care întoarce true (adevărat) dacă aceasta
s-a terminat corect, sau false (fals) dacă au intervenit erori și a fost anulată. Astfel, în funcție
de valoarea variabilei ok, clientul primește un mesaj corespunzător („Rezervarea a fost anulată”,
respectiv „Rezervarea nu a putut fi anulată”.
În cazul în care un client nu are un cont valid pe site, poate să se înregistreze apelând
pagina de înregist rare, care se poate observa în figura 3.11 .
Figura 3.11 Înregistrare
Aceasta este com pusă dintr -un formular cu câmpurile: user (adresa de e -mail), parola,
rescrierea parolei pentru confirmare, nume, prenume, data nașterii, telefon și adresa. Primele

51
cinci câmpuri sunt obligatorii și fără acestea formularul nu poate fi executat. Pentru intr oducerea
datei de naștere există trei câmpuri în HTML de tip select (zi, lună, an). Câmpul telefon
permite introducerea a doar 10 caractere numerice, corespunzătoare unui număr de telefon valid
din România. Formularul este pr ocesat prin apăsarea butonului Trimite sau se poate apăsat
butonul Rest pentru ștergerea tuturor datelor înscrise în câmpuri.
Se verifică inițial dacă adresa de e -mail furnizată de utilizator nu există deja în baza de
date. Atributul e -mail al tabelei Client are constrângere de unicita te, deoarece este imposibil ca
doi utilizatori să se autentifice pe site cu același e -mail. Pentru verificare se efectuează o
interog are a bazei de date, testându -se toate valorile atributului email existente.
În final, dacă cele două parole coincid, atunc i se poate efectua operația de inserare în
baza de date . Dacă aceasta a fost efectuată cu s ucces, utilizatorul primește mesaj de confirmare și
un link către pagina din care a accesat legătura către înregistrare. Odată ce s -a înregistrat, clientul
este aute ntificat automat, prin setarea atributelor de sesiune, email, nume și prenume.
Pagina de vizualizare a programului (figura 3.12) conține un tabel în care sunt prezentate
programările existente în baza de date , care încep după data în care se face vizualiz area.
Programările sunt efectuate de către administratori, prin intermediul paginii „Admin”.

Figura 3.12 . Programul filmelor de la cinematograf
Tabelul conține informații despre numărul sălii în care se proiectează filmul, data de
început, numele și dur ata filmului, prețul biletului și un buton pentru rezervare. Datele sunt
obținute în urma interogării bazei de date cu o operație de joncțiune între tabelele Sala,
Programări și Film. Se selectează cheia primară a sălii care corespunde numărului acesteia, data
de început și prețul din tabel Programări, numele și durata din tabela Film, ordonate crescător

52
după data de început. Selecția se face cu condițiile ca atributele id_sala din tabele Programări și
Sală să fie identice, și atributele id_film din tabelel e Programări și Film să coincidă de asemenea.
Prin apăsarea butonului Rezervă utilizatorul este redirecționat către pagina de rezervare
(figura 3.13) dacă este autentificat sau, în caz contrar, către pagina de autentificare . În pagina de
rezervare, clientu l vizualizează pentru confirmar e numărul sălii, data de începere și numele
filmului. Aici poate să aleagă numărul de bilete pe care dorește să le rezerve, care se face printr –
un meniu de tip select , unde se află numere de la unu la zece (cât este numărul m axim de
bilete rezervate). Apăsând butonul Rezervă , se apelează procedura stocată rezervare_bilete, cu
parametrii: id_client, id_programari, nr_bilete_rezervate și parametrul de ieșire răspuns. În
funcție de ce valoare întoarce parametrul de ieșire, utiliz atorul poate primi mesajele: de
confirmare a rezervării, de amintirea a faptului că a mai făcut înainte o rezervare pe același
programare și faptul că nu mai sunt locuri disponibile pentru această programare.
.
Figura 3.13. Rezervare
Pagina de vizualizare a filmelor (figura 3.14) afișează toate filmele existente în baza de
date în ordine crescătoare a numelui. Aici utilizatorul poate citi informații suplimentare despre
film: nume, durată, gen și sinopsis. Fiecare film este cuprins într -un fieldset , pentru a se face
o diferențiere mai bună între acestea.

53
Figura 3.14 Vizualizare filme
Pe lângă interfața web dedicată clientului, se mai găsește și o parte dedicată
administratorului. Acesta poate efectua programări noi cu ajutorul unui formular găsit la pagina
de Admin. Dacă administratorul accesează această pagină, dar nu este autentificat, va fi
redirecționat către pagina de autentificare destinată administratorilor , care poate fi observată în
figura 3.15 . Pagina funcționează în același mod ca și pagina de au tentificare a clientului, doar că
interogarea se face, evident, pe tabela Administrator.
Figura 3.15 . Autentificare administrator
Odată autentificat, este redirecționat către pagina de programare orar (figura 3.16) .
Aceasta conține un formular cu următoa rele câmpuri: număr sală, nume film, dată început, dată
sfârșit și preț bilet. Toate acestea sunt de tip select . În câmpul dedicat sălii se regăsesc valorile
din baza de date ale atributului id_sala , în cel al filmelor se regăsește numele tuturor filmelor
înscrise în baza de date. Câmpurile pentru cele două date sunt formate din cinci componente de
tip select: pentru an, pentru lună, pentru zi, pentru oră și pentru minut. Când se apasă but onul
Trimite se verifică mai întâi dacă datele de început și de sfârș it sunt valide, apoi se apelează

54
procedura stocată programare_orar , care primește ca parametrii id_sala ,
id_administrator , id_film , preț și parametru de ieșire răspuns . În funcție de
valoarea variabilei de ieșire, administratorul poate primi mesaje care co nfirmă efectuarea
programării, îl atenționează ca intervalul de timp alocat este mai mic decât durata filmului sau că
intervalul de timp se suprapune cu o altă programare.

Figura 3.16 . Programare orar
3.5 Testarea și rezultatele obținute
Pentru a simula accesul concurent la baza de date, am folosit firele de execuție
(thread ). Un fir de execuție este cea mai mică unitate de procesare care poate fi
planificată de un sistem de operare. În general, este folosit pentru îmbunătățirea
performanțelor de calcul, prin reducerea timpului de comutare între procese datorată
partajării memori ei și fișierelor (18). Folosirea firelor de execuție s -a putut realiza cu
ajutorul clasei Thread din Java. Mașina virtual ă Java (Java Virtual Machine )
permite unei aplicații să aibă fire de execuție multiple care rulează concurent.
3.5.1 Implementarea aplicației de testare
Pentru testare, am creat patru proceduri st ocate (care se găsesc la Anexele 5, 6, 7,
8), fiecare cu un alt nivel de izolare: citire ne validată, citire validată, citiri repetate și
serializabil. Setarea nivelurilor se izolare se face cu comanda:
SET TRANSACTION ISOLATION LEVEL nivel_izolare

55
unde nivel_izolare poate lua valorile: READ UNCOMMITTED , READ
COMMITTED , REPETABLE READ respectiv, SERIALIZABLE .
Cum pe baza de date, un sigur client poate face o rezervare la o anumită
programare, tranzacțiile nu doar introduc rezervări la o anumită programare, dar și
introduc clienți noi care să realizeze rezervările. În acest fel , procedura primește ca
parametrii un număr care reprezintă indexul tranzacției și care este folosit pentru a
introduce un client nou cu următoarele valori pentru atributele email, parolă, nume și
prenume: „email‟+număr, „parola‟+număr, „nume‟+număr, „prenume‟+număr. Astfel,
clientul de index 1 va avea valorile: email1, parola1, nume1, prenume1.
Ceilalți parametrii ai proc edurii sunt: id_programari și nr_locuri care
indică cheia primară a programului pe care se dorește a se face rezervarea și numărul de
bilete rezervate (care nu trebuie să depășească valoarea „10‟).
După adăugarea noului client, se citește cheia primară introdusă pentru acesta, iar
apoi se citește valoarea atributului locuri_libere din tabela Programări care corespunde
cheii primare dată ca parametru . Dacă numă rul de locuri libere este mai mic decât
numărul de locuri rezervate, tranzacția nu va mai continua. Altfel, se inserează valori
pentru atributele id_client , id_programari , nr_locuri_rezervate în
tabela Rezervări. Apoi, se actualizează tabela programări cu noua valoare a atributului
locuri_libere (valoarea precedentă minus valoarea parametrului număr de locuri
rezervate) și tranzacția este validată prin comanda COMMIT TRANSACTION .
Fiecare procedură este executată de un fir de execuție. Astfel, dacă se doreșt e
lansarea simultană a 100 de tranzacții, se vor instanția și rula 100 de fire de execuție.
Pentru ilustrarea performanțelor voi măsura timpul mediu de execuție al tranzacțiilor
individuale, dar și timpul de execuție al tuturor firelor de execuție lansate.
Pentru imple mentarea testului de performanță am folosit c odul Java , care se
găsește în Anexa 10. Am creat două clase, testThread și testare, iar funcționalitatea
acestor cl ase le voi descrie mai jos .
Am creat clasa testThread care extinde clasa Threads . Cu ajutorul acestei
clase se rulează o tranzacție. Constructorul acestei clase primește ca parametrii numărul
curent al tranzacției, nrCrt , cheia primară a programării folosite pentru rezervare,
idProg , numărul de bilete rezervate, bileteRezervate , conexiun ea existentă la
baza de date, con și nivelul de izolare dorit pentru tranzacție, nivel.
Clasa are trei metode, din care una este o suprascriere a metodei clasei Threads,
run. Aceasta conține instrucțiunile care vor fi rulate la startul firului de execuție. Aici se
instanțiază un obiect de tip CallableStatement , cstmt , care este folosit pentru

56
executarea unei proceduri stocate T -SQL. Apoi, în funcție de nivelul ales pentru firul de
execuție, se apelează metoda conexiunii con, prepareCall care returnează un o biect
CallableStatement . După aceea, folosind metodele de tip set, se configurează
parametrii de intrare ai procedurii, iar cu metoda registerOutParameter se
stabilește variabila de ieșire. Înainte de execuția propriu -zisă a procedurii stocate, se
inițiali zează variabila de tip Date , d1, cu valoarea date sistemului în acel moment , iar
imediat după apelul metodei execute() a obiectului cstmt , se inițializează variabila
de tip Date , d2, cu valoarea datei sistemului în acel moment, obținându -se în acest fel
timpul de execuție al tranzacției. Pe urmă, se memorează valoarea întoarsă de variabila de
ieșire, se închide prin metoda close(), obiectul cstmt și, în final se face calculul
diferenței între cele două variabile de timp. Corpul acestei metode este pus într -un bloc
de tip try – cacth pentru a punea trata erorile care apar în timpul execuțiilor
operațiilor descrise anterior. Dacă apare o eroare, înseamnă ca fie conexiunea nu mai este
validă, fie, cel mai probabil caz, că tranzacția nu a fost terminată. De acee a, în blocul
catch , valoarea variabilei care memorează răspunsul procedurii se inițializează cu
valoarea 1.
Celelalte două metode implementate, returneazaDiferenta() și
returneazaRaspuns() , întorc valorile răspunsului, respectiv valoarea timpului de
execuț ie a tranzacției.
Cealaltă clasă creată, testare , este folosită pentru rularea multiplelor fire de
execuție simultan. Constructorul acestei clase inițializează variabila n care determină
numărul de fire de execuție care vor apela tranzacțiile T –SQL. Clasa conține și două
metode folosite pentru realizarea conexiunii cu baza de date, getConnectionUrl()
care returnează o variabilă String cu URL -ul bazei de date și getConnection()
care face conectarea propriu -zisă.
Metoda începe primește ca parametru nivelul d e izolare pentru care se dorește
testarea performanțelor. După crearea conexiunii, se inițializează o variabilă Date , d1,
cu valoarea datei sistemului din acel moment. Apoi, se instanțiază un vectori de obiecte
testThreads de dimensiunea n. După aceea, cu ajutorul unei bucle for, se
inițializează aceste obiecte, unde valoarea primului parametru este indicele curent al
buclei. Pentru testarea s -a folosit programarea cu cheia primară 4 și un singur bilet
rezervat. Tot cu ajutorul unei bucle for, se pornesc bu clele de execuție cu metoda
start(). Apoi, se folosește metoda join() pentru ca următoarele operații să se
execute abia după ce toate firele de execuție s -au terminat. Se inițializează vectorii care
memorează rezultatele întoarse de metodele returneazaDife renta și returneazaRaspuns
pentru fiecare fir de execuție. La sfârșitul acestor operații se variabilă Date , d2, cu
valoarea datei sistemului din acel moment și se va calcula diferența dintre această

57
valoarea și cea memorată anterior, d1. În final, se execu tă un șir de operații care să
șteargă clienții noi creați de tranzacție (care implicit va șterge și rezervările, deoarece la
crearea referinței dintre cele două s -a setat opțiunea ON DELETE CASCADE , care șterge
liniile din tabel dacă cheia străină ia valoa rea NULL ), să reseteze indecșii cheilor primare
pentru tabelele Client și Rezervări, și care reinițializează cu valoarea maximă atributul
locuri_libere din tabela Pro gramări al cărui cheie primară 4.
Am mai implementat trei metode, getRaspuns() , getTimp() și dif() .
Prima returnează numărul de tranzacții terminate, a doua calculează timpul mediul al
fiecărei tranzacții, iar ultima returnează timpul total de execuție al celor n fire de
execuție.
3.5.2 Rezultatele obținute
Pentru a observa comportamentul tranz acțiilor am ales să lansez un număr n de
fire de execuție concurente. Acest număr ia valorile 50, 100, 250, 500, 750 și 1000.
Numărul maxim este dat de limitarea versiunii SQL Server 2012 gratuite, obținute prin
programul Microsoft Developer Network Academ ic Alliance (MSDNAA). Această
versiune, spre deosebire de cea comercial ă, impune limitarea apelurilor simulate de
tranzacții de către un singur utilizator la 1000, și, pe lângă aceasta, nu este posibilă
execuția pe mai multe procesoare, indiferent de confi gurația sistemului.
Mai jos, în figurile 3.17, 3.18, 3.19, 3.20, 3.21, 3.22, sunt prezentate sub formă de
diagramă bară, timpii de execuție obținuți la rularea aplicației de testare.

Figura 3.17 Timpi de execuție pentru 50 de tranzacții concurente 01020304050607080
Timpul mediu de execuție a unei
tranzacțiiTimpul de execuție a tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 50
Citire nevalidată Citire validată Citire repetată Serializabil

58

Figu ra 3.18 Timpi de execuție pentru 100 de tranzacții concurente

Figura 3.19 Timpi de execuție pentru 250 de tranzacții concurente 050100150200250300350400
Timpul mediu de execuție al unei
tranzacțiiTimpul de execuție ale tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 100
Citire nevalidată Citire validată Citiri repetate Serializabil
01002003004005006007008009001000
Timpul mediu de execuție a unei
tranzacțiiTimpul de execuție a tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 250
Citire nevalidată Citire validată Citiri repetate Serializabil

59

Figura 3.20 Timpi de execuție pentru 500 de tranzacții concurente

Figura 3.21 Timpi de execuție pentru 750 de tranzacții c oncurente 01002003004005006007008009001000
Timpul mediu de execuție a unei
tranzacțiiTimpul de execuție a tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 500
Citire nevalidată Citire validată Citiri repetate Serializabil
0200400600800100012001400160018002000
Timpul mediu de execuție a unei
tranzacțiiTimpul de execuție a tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 750
Citire nevalidată Citire validată Citiri repetate Serializabil

60

Figura 3.22 Timpi de execuție pentru 1000 de tranzacții concurente
În figura 3.23 se arată procentul de tranzacții terminate pentru 100, 500 și
respectiv, 1000 de fire de execuție lansate.
Figura 3.23 Procentul de tranzacții terminate 02004006008001000120014001600
Timpul mediu de execuție a unei
tranzacțiiTimpul de execuție a tuturor
tranzacțiilorTimp [μs]
Număr de tranzacții concurente = 1000
Citire nevalidată Citire validată Citiri repetate Serializabil
99,50%99,60%99,70%99,80%99,90%100,00%
100 500 1000
Citire nevalidata Citire validata Citiri repetate Serializabil

61
3.5.3 I nterpretarea rezultatelor
Așteptările teoretice al testului de performanță sunt:
– Nivelul de izolare cel mai jos ar trebui să aibă cei mai mici timpi de execuție , pe
când cel mai ridicat ar trebui să aibă cei mai mari timpi de execuție ;
– Nivelul de izolare c el mai de sus ar trebui să nu aibă nicio tranzacție anulată, pe
când celelalte niveluri poate să aibă tranzacții anulate .
Analizând figurile de la 3.17 la 3.22 , am observat că, în mare parte, se respectă
așteptările teoretice. Nivelul serializabil are cei mai mari timpi de execuție în toate cele
șase cazuri de număr de fire de execuții simultane , pe când nivelul citire nevalidată are
cei mai mici timpi de execuție. Deci, gradul de concurență scade cu creșterea
nivelului de izolare . Cu toate acestea, în anum ite cazuri izolate timpul nu a fost conform
cu așteptările pentru că firele de execuție din Java pe un calculator de uz general sunt
planificate de sistemul de operare, ordinea lor de execuție este arbitrară, și între execuții
pot fi planificate alte proce se dedicate sistemului de operare care rulează pe fundal.
Totuși, acest fapt era de așteptat având în vedere că testele nu au fost realizate pe sisteme
speciale de testarea performanțelor de tip benchmark.
Am mai observat că t impul mediu de execuție al fi ecărei tranzacții crește cu
numărul de fire de execuție lansate concurent . Acest fapt este previzibil și se datorează
faptului că pe instrucțiunile de actualizare și se inserare există zăvoare de exclusivitate
indiferent de nivelul de izolare, obligând tra nzacțiile concurente să se aștepte una pe alta
deoarece operațiile realizate înainte de aceste instrucțiunile nu au un volum de calcul
foarte ridicat .
Din figura 3.23 se confirmă faptul că nivelul serializabil conduce la aceleași
rezultate ca atunci când t ranzacțiile s -ar executa serial , fără concurență. La puține
tranzacții concurente și celelalte niveluri dau rezultate foarte bune .

63
Bazele de date au o utilizare largă, iar importanța în societate este incontestabilă.
Tranzacțiile sunt o parte nelipsită din majoritatea bazelor de date pentr u că aceste sunt folosite
atât pentru stocarea de informații, cât – mai ales – pentru prelucrarea intensă a datelor .
Cum viteza de lucru a calculatoarelor cr ește semnificativ de la un an la altul, bazele d e
date trebuie să își mențină rapiditate a în rapo rt cu execuția operațiilor. Ca atare , performanța
tranzacțiilor este un subiect important , dar această nu se rezumă doar la execuția rapidă, ci și la
rezultatele corect obținute.
Așadar, conform rezultatelor o bținute în testarea performanțelor, nivelul de izolare cel
mai redus oferă un timp de execuție mai bun față de nivelul de izolare cel mai de jos. Astfel,
utilizatorul bazei de date SQL Server 2012 trebuie să aleagă nivelul de izolare care se potrivește
cel mai bine cerințelor lui. Dacă dorește tranzacții rapide, fără să conteze dacă uneori o tranzacție
este anulată sau dacă numărul de tranzacții concurente este în general redus, atunci cu siguranță
poate să aleagă nivelul de izolare cel mai de jos. Dacă tra nzacțiile pe care dorește să le execută
sunt critice în aplicația acestuia, trebuie să sacrifice timpul de execuție în favoarea consistenței
bazei de date.
Pentru aplicația mea, tranzacțiile nu sunt criti ce, iar anularea uneia dintre ele nu este o
problemă majoră . În general , se preferă ca operația de re zervare să dureze cât mai puțin și nu
deranjează să reîncerce în caz de eșec. Mai mult, în momentul de față, nu mă aștept ca numărul
de tranzacții concurente să fie mare din cauza lipsei de popularitate a cinemato graful ui – acesta
fiind și motivul din cauza căruia am optat pentru nivelul de izolare citire validată . Însă, pentru un
cinematograf celebru, ar trebuit să se ia în considerare faptul că numărul de tr anzacții concurente
poate să ia valori foarte mari pe interval de vârf.
În viitor doresc să îmbunătățesc aplicația prin modificarea interfeței web pentru a o face
mai prietenoasă cu clienții și pentru a conține mai multe informații în legătură cu filmele oferite
de cinematograf (cum ar fi o imagine poster ). De asemenea, doresc ca website -ul să ofere
integrarea cu rețelele de socializare, Facebook și Twitter.
Pe măsură ce numărul de clienți va fi mai numeros, voi încerca să adopt un nivel de
izolare mai ridicat pentru ca numărul de tranzacții anulate să fi e mai mic, chiar dacă acest fapt
înseamn ă scăderea vitezei de execuție. 4 CONCLUZII

65

ANEXA 1
ANEX E

66
ANEXA 2
CREATE PROCEDURE programare_orar
@id_sala INT, @id_administrator INT, @id_film INT, @pret_bilet DECIMAL, @data_inceput
smalldatetime, @data_sfarsit smalldate time, @raspuns INT OUTPUT
AS
DECLARE @nr_locuri INT, @durata INT, @inceput smalldatetime, @sfarsit smalldatetime
DECLARE cursor_timp CURSOR FOR SELECT data_inceput, data_sfarsit FROM PROGRAMARI where id_sala =
@id_sala
OPEN cursor_timp
BEGIN TRANSACTION
SET @raspuns = 0
SELECT @nr_locuri = numar_locuri FROM SALA where id_sala = @id_sala
SET @durata = (SELECT durata FROM FILM WHERE id_film = @id_film)
FETCH cursor_timp INTO @inceput, @sfarsit
IF datediff(minute,@data_inceput,@data_sfarsit)<@durata set @raspuns=1
ELSE
WHILE (@@FETCH_STATUS = 0)
BEGIN
If((@data_inceput>=@inceput)and(@data_inceput<=@sfarsit))or
((@data_sfarsit>=@inceput) and (@data_sfarsit<=@sfarsit))
begin
set @raspuns = 2
break
end
FETCH cursor_timp INT O @inceput, @sfarsit
END
CLOSE cursor_timp
DEALLOCATE cursor_timp
if @raspuns = 0
INSERT INTO PROGRAMARI (id_sala, id_administrator, id_film, locuri_libere,
pret_loc, data_inceput, data_sfarsit) VALUES (@id_sala, @id_administrator, @id_film, @nr_lo curi,
@pret_bilet, @data_inceput, @data_sfarsit)
COMMIT transaction
ANEXA 3
CREATE PROCEDURE rezervare_bilete
@id_client INT, @id_programari INT, @nr_locuri_rezervate INT, @raspuns INT OUTPUT
AS
DECLARE @libere INT
DECLARE @client INT, @programari INT
DECLARE cursor_programari CURSOR FOR SELECT id_client, id_programari FROM REZERVARI
OPEN cursor_programari
BEGIN TRANSACTION
SET @raspuns = 0
SELECT @libere = locuri_libere FROM PROGRAMARI where id_programari = @id_programari
FETCH cursor_programari INTO @c lient, @programari
WHILE (@@FETCH_STATUS = 0)
BEGIN
if(@id_client=@client)and(@id_programari=@programari)
begin
set @raspuns = 1
break
end
FETCH cursor_programari INTO @client, @programari
END
CLOSE crusor_programari
DEALLOCATE cursor_programari
IF @nr_locuri_rezervate > 10 set @raspuns = 2
IF @libere<=@nr_locuri_rezervate SET @raspuns = 3
if @raspuns = 0
begin
INSERT INTO REZERVARI (id_client, id_programari, nr_locuri_rezervate) VALUES
(@id_client,@id_programari,@nr_ locuri_rezervate)
UPDATE PROGRAMARI SET locuri_libere=@libere -@nr_locuri_rezervate where
id_programari = @id_programari

67
END
COMMIT TRANSACTION
ANEXA 4
CREATE PROCEDURE sterge_rezervare
@id_rezervare INT
AS
DECLARE @locuri INT
DECLARE @id_programare INT
BEGIN TRANSACTION
SELECT @locuri=nr_locuri_rezervate FROM REZERVARI where id_rezervare=@id_rezervare
SELECT @id_programare=id_programari FROM REZERVARI where id_rezervare=@id_rezervare
DELETE FROM REZERVARI where id_rezervare=@id_rezervare
UPDATE PROGRAMAR I set locuri_libere=locuri_libere+@locuri where id_programari=@id_programare
COMMIT TRANSACTION
ANEXA 5
CREATE PROCEDURE testR U
@nr varchar(max), @id_programari INT, @nr_locuri INT, @raspuns INT OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
DECLARE @email varchar(max), @parola varchar(max), @nume varchar(max), @prenume varchar(max),
@id_client INT
DECLARE @libere INT, @client INT, @programari INT
BEGIN TRANSACTION
SET @email='email'+@nr
SET @parola='parola'+@nr
SET @nume='nume'+@nr
SET @prenum e='prenume'+@nr
INSERT INTO CLIENT (Email, Parola, Nume, Prenume) VALUES (@email,@parola,@nume,@prenume)
SELECT @id_client = @@IDENTITY
SET @raspuns = 0
SELECT @libere = locuri_libere FROM PROGRAMARI where id_programari = @id_programari
IF @nr_locuri > 10 set @raspuns = 2
IF @libere<=@nr_locuri SET @raspuns = 3
if @raspuns = 0
begin
INSERT INTO REZERVARI (id_client, id_programari, nr_locuri_rezervate) VALUES
(@id_client,@id_programari,@nr_locuri)
UPDATE PROGRAMARI SET locuri_libere=@libere -@nr_locuri w here id_programari =
@id_programari
END
COMMIT TRANSACTION
ANEXA 6
CREATE PROCEDURE testRC
@nr varchar(max), @id_programari INT, @nr_locuri INT, @raspuns INT OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
DECLARE @email varchar(max), @parola var char(max), @nume varchar(max), @prenume varchar(max),
@id_client INT
DECLARE @libere INT, @client INT, @programari INT
BEGIN TRANSACTION
SET @email='email'+@nr
SET @parola='parola'+@nr
SET @nume='nume'+@nr
SET @prenume='prenume'+@nr
INSERT INTO CLIENT (Ema il, Parola, Nume, Prenume) VALUES (@email,@parola,@nume,@prenume)
SELECT @id_client = @@IDENTITY
SET @raspuns = 0
SELECT @libere = locuri_libere FROM PROGRAMARI where id_programari = @id_programari
IF @nr_locuri > 10 set @raspuns = 2

68
IF @libere<=@nr_locuri SET @raspuns = 3
if @raspuns = 0
begin
INSERT INTO REZERVARI (id_client, id_programari, nr_locuri_rezervate) VALUES
(@id_client,@id_programari,@nr_locuri)
UPDATE PROGRAMARI SET locuri_libere=@libere -@nr_locuri where id_programari =
@id_programari
END
COMMIT TRANSACTION
ANEXA 7
CREATE PROCEDURE testRR
@nr varchar(max), @id_programari INT, @nr_locuri INT, @raspuns INT OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
DECLARE @email varchar(max), @parola varchar(max), @nume varchar(max), @prenum e varchar(max),
@id_client INT
DECLARE @libere INT, @client INT, @programari INT
BEGIN TRANSACTION
SET @email='email'+@nr
SET @parola='parola'+@nr
SET @nume='nume'+@nr
SET @prenume='prenume'+@nr
INSERT INTO CLIENT (Email, Parola, Nume, Prenume) VALUES (@em ail,@parola,@nume,@prenume)
SELECT @id_client = @@IDENTITY
SET @raspuns = 0
SELECT @libere = locuri_libere FROM PROGRAMARI where id_programari = @id_programari
IF @nr_locuri > 10 set @raspuns = 2
IF @libere<=@nr_locuri SET @raspuns = 3
if @raspuns = 0
begin
INSERT INTO REZERVARI (id_client, id_programari, nr_locuri_rezervate) VALUES
(@id_client,@id_programari,@nr_locuri)
UPDATE PROGRAMARI SET locuri_libere=@libere -@nr_locuri where id_programari =
@id_programari
END
COMMIT TRANSACTION
ANEXA 8
CREATE PRO CEDURE testSZ
@nr varchar(max), @id_programari INT, @nr_locuri INT, @raspuns INT OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
DECLARE @email varchar(max), @parola varchar(max), @nume varchar(max), @prenume varchar(max),
@id_client INT
DECLARE @l ibere INT, @client INT, @programari INT
BEGIN TRANSACTION
SET @email='email'+@nr
SET @parola='parola'+@nr
SET @nume='nume'+@nr
SET @prenume='prenume'+@nr
INSERT INTO CLIENT (Email, Parola, Nume, Prenume) VALUES (@email,@parola,@nume,@prenume)
SELECT @id_cl ient = @@IDENTITY
SET @raspuns = 0
SELECT @libere = locuri_libere FROM PROGRAMARI where id_programari = @id_programari
IF @nr_locuri > 10 set @raspuns = 2
IF @libere<=@nr_locuri SET @raspuns = 3
if @raspuns = 0
begin
INSERT INTO REZERVARI (id_client, id _programari, nr_locuri_rezervate) VALUES
(@id_client,@id_programari,@nr_locuri)
UPDATE PROGRAMARI SET locuri_libere=@libere -@nr_locuri where id_programari =
@id_programari
END
COMMIT TRANSACTION

69
ANEXA 9
package pachet;
import java.util.Date;
import java. sql.*;
class testThread extends Thread{
private int nrCrt;
private int idProg;
private int bileteRezervate;
private int timeDiff =0;
private int raspuns;
private int nivel;
private Connection con;
Date d1;
testThread() { nrCrt=0;}
testThread (int nrCrt, int idProg, int bileteRezervate, Connection con, int nivel){
this.nrCrt=nrCrt;
this.idProg=idProg;
this.bileteRezervate=bileteRezervate;
this.con = con;
this.nivel = nivel;
}
public void run (){

try{
CallableStatement cstmt;
switch (nivel){
case 1: cstmt = con.prepareCall("{call dbo.testRU(?,?,?,?)}");
break;
case 2: cstmt = con.p repareCall("{call dbo.testRC(?,?,?,?)}");
break;
case 3: cstmt = con.prepareCall("{call dbo.testRR(?,?,?,?)}");
break;
case 4: cstmt = con.prepareCall("{call dbo.testSZ(?,?,?,?)}");
break;
default: cstmt = con.prepareCall("{call dbo.testRC(?,?,?,?)}");
break;
}
cstmt.setString(1,Integer.toString(nrCrt));
cstmt.setInt(2,idProg);
cstmt.setInt(3,bileteRezervate);
cstmt.registerOutParameter(4, java.sql.Types.INTEGER);
d1= new Date();
cstmt.execute();
Date d2= new Date();
raspuns = cstmt.getInt(4);
cstmt.close();
timeDiff = (int) (d2.getTime() -d1.getTime());
}catch(Exception e){
raspuns = 1;
e.printStackTrace();
System.out.println("Error Trace in run : " + e.getMessage());
}}
public int returneazaDiferenta(){
return timeDiff;
}
public int returneazaRaspuns(){
return raspuns;
}}
public class testare {
private java.sql.Connection con = null;
private final String url = "jdbc:sqlserver://";
private final String serverName= " SORINA-PC\\IOANA";
private final String databaseName= "licenta";
private int difTimp[];
private int raspuns[];
int n;
private Date d1;
private Date d2;
private int dif;

70
public testare(int n){
this.n=n;
}
private String getConnectionUrl(){
return
url+serverName+";databaseName="+databaseName+";user=ioana;password=sorina;";
}
private Connection getConnection(){
try{
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerD river");
con = DriverManager.getConnection(getConnectionUrl());
if(con==null) System.out.println("Conexiunea nu s -a realizat!");
con.setAutoCommit(true);
}catch(Exception e){
System.out .println("Error Trace in getConnection() : " + e.getMessage());
}
return con;
}
public void incepe(int nivel){

int niv = nivel;
difTimp = new int[n];
raspuns = new int[n];
try{
con = this.getConnection();
d1 = new Date();
testThread threads[] = new testThread[n];
for (int i=0; i<n; i++)
threads[i]=new testThread(i,4,1,con,niv);
for(int i=0; i<n; i++){
threads[i].start();
}
for (int i=0;i<n; i++){
threads[i].join();
difTimp[i]=threads[i].returneazaDiferenta();
raspuns[i]=threads[i].returneazaRaspuns();
}
d2 = new Date();
dif = (int) (d2.getTime() -d1.getTime());
String sql = "delete from client where email like 'email%' and nume like
'nume%' and prenume like 'prenume%'";
Statement s = con.createStatement();
s.executeUpdate(sql);
s.executeUpdate("DBCC CHECKIDENT (client, RESEED, 24)");
s.executeUpdate("DBCC CHECKIDENT (rezervari, RESEED, 9)");
String sql2= "update PROGRAMARI set locuri_libere=1000 where
id_programari=4";
s.executeUpdate(sql2) ;
s.close();
con.close();
}catch (Exception e) {e.printStackTrace();System.out.println("Error Trace in
incepe : " + e.getMessage());}
}
public int getRaspuns (){
int terminate = 0;
for (int i=0;i<n;i+ +)
if (raspuns[i]==0) terminate++;
return terminate;
}
public int getTimp(){
int mediu = 0;
for (int i=0;i<n;i++)
mediu+=difTimp[i];
return mediu/n;
}
public int diff(){
return dif;
}}

71
1. Ionescu, Felicia. Baze de date relaționale și Aplicații. București : Editura Tehnică, 2004.
2. Coronel, Carlos, Morris, Steven and Rob, Peter. Database System: Design, Implementation
and Management. Ninth Edit ion. Boston : Cengage Learning, 2011.
3. SQL. Wikipedia. [Online] [Cited: Iunie 01, 2012.] http://en.wikipedia.org/wiki/Sql.
4. Dollinger, Robert. Baze de date și gestiunea tranzacțiilor. Cluj – Napoca : Editura Albastră,
2001.
5. Euan Garden's BLOG. MSDN Blogs. [Online] [Cited: Iunie 06, 2012.]
http://blogs.msdn.com/b/euanga/archive/2006/01/19/sql -mythbusters -sql-server -is-really -a-
sybase -product -not-a-microsoft -one.aspx.
6. Mistry, Ross and Misner, Stacia. Introducing Microsoft SQL Server 2012. Redmond :
Microsoft Press, 2012.
7. Alinean, Inc. Microsoft SQL Server and Oracle Database: A comparative Study on Total Cost
of Administration (TCA). Orlando : Aliean, Inc, Ianuarie 2012.
8. Transact -SQL. Wikipedia. [Online] [Cited: Iunie 07, 2012.]
http://en.wikip edia.org/wiki/Transact -SQL.
9. Types of Concurrency Control. MSDN. [Online] [Cited: Iunie 08, 2012.]
http://msdn.microsoft.com/en -us/library/ms189132(v=SQL.105).aspx.
10. Isolation Levels in the Database Engine. MSDN. [Online] Microsoft. [Cited: Iunie 08, 2012.]
http://msdn.microsoft.com/en -us/library/ms189122(v=SQL.105).aspx.
11. SET TRANSACTION ISOLATION LEVEL (Transact -SQL). MSDN. [Online] Microsoft.
[Cited: Iunie 08, 2012.] http://msdn.microsoft.com/en -us/library/ms173763(v=sql.105).aspx.
12. Lock Granu larity and Hierarchies. MSDN. [Online] Microsoft. [Cited: Iunie 09, 2012.]
http://msdn.microsoft.com/en -us/library/ms189849(v=sql.105).
13. Lock Modes. MSDN. [Online] [Cited: Iunie 09, 2012.] http://msdn.microsoft.com/en –
US/library/ms175519(v=sql.105).aspx .
14. Shelly, Gary B. and Woods, Denise M. HTML, XHTML, CSS. Boston : Cengage Learning,
2011. p. Sixth Edition. Bibliogra fie

72
15. HTML. Wikipedia. [Online] [Cited: Iunie 15, 2012.] http://en.wikipedia.org/wiki/HTML.
16. Bergsten, Hans. JavaServer Pages. Sebastopol : O'R eilly, 2004.
17. Fields, Duane K., Kolb, Mark A. and Bayern, Shwan. Web Development with JavaServer
Pages. Second Edition. Greenwich : Manning, 2002.
18. Ionescu, Felicia, et al. Calcul Pararel Lucări Practice. București : s.n.