TRANZACŢII
Conceptul de gestiune a tranzacţiilor se referă la problematica menţinerii într-o stare consistentă a bazei de date în condiţiile accesul la date se face în regim concurent si este posibilă apariţia unor defecte. În consecinţă se disting două domenii de sine stătătoare în cadrul problematicii generale a gestiunii tranzacţiilor:
- controlul concurenţei
Se ocupă cu mecanismele de sincronizare a acceselor astfel încât să fie menţinută integritatea bazei de date. Atunci când controlul concurenţei este realizat prin mecanismele de blocare(care la ora actuală sunt cele mai răspândite) mai apare o altă problemă, colaterală şi anume aceea a interblocărilor. Datorită importanţei sale problema gestiunii interblocărilor este de multe ori tratată ca o problematică de sine stătătoare a gestiunii tranzacţiilor.
- rezistenta la defecte
Se referă la tehnicile prin care se asigură atât toleranţa sistemului faţa de apariţia unor defecte, cât şi capacitatea de recuperare a acestuia, adică posibilitatea de revenire la o stare consistentă în urma apariţiei unui defect care a acuzat intrare lui într-o stare inconsistentă.
Definiţia conceptului de tranzacţie
Prin controlul concurenţei si rezistenţa la defecte se urmăreşte asigurarea consistenţei si sigurantei bazei de date. 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ă in timpul prelucrării baza de date s-a găsit temporar într-o stare incosnistentă.
Siguranţa bazei de date se referă la toleranţa acesteia faţă de defecte si la capacitatea de recuperare după apariţia unui defect.
O tranzacţie este o unitate logică de prelucrare care asigură consistenţa si siguranţa bazei de date. În principiu orice execuţie a unui program se poate considera o tranzacţie dacă baza de date este într-o stare consistentă atât înainte cât si dupa execuţia sa. Consistenţa bazei de date este garantată indepentent de faptul că :
1. tranzacţia a fost executată in mod concurent cu alte tranzacţii
sau că
2. au apărut defecte în timpul execuţiei tranzacţiei.
În general o tranzacţie constă dintr-o secvenţă de operaţii de citire si 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 inconsistentă în timpul executării tranzacţiei, dar trebuie să fie în stări consistente atât înainte, cât şi după execuţia tranzactiei.
Exemplu:
Fie un sitem de rezervare a locurilor pe liniile aeriene a cărei bază de date conţine 3 relaţii definite prin schemele:
ZBOR(Codz, Sursa, Dest, Libere)
CLIENT(Codc, Nume, Adresa)
REZERVARE(Codz, Codc, Observaţii).
Semnificaţia atributelor este următoarea:
Codz codul unic al zborului; este cheie în relaţia ZBOR;
Sursa, Dest sursa şi destinaţia zborului;
Libere numărul de locuri încă nevândute;
Codc codul unic al fiecărui client al companiei;
este cheia în relaţia CLIENT;
Nume, Adresa numele şi adresa clientului;
Observaţii informaţii referitoare la rezervarea în sine.
Pentru a face o rezervare se introduce codul zborului solicitat şi codul clientului care doreşte rezervarea. Tranzacţia corespunzătoare operaţiei de rezervare poate fi implementată, folosind o interfaţă SQL integrată într-un mediu PASCAL, astfel:
Begin_tranzaction Rezervare
Begin
Input (cod_zbor, cod_client);
EXEC SQL
Update zbor
SET Libere = Libere – 1
WHERE Codz = Cod_zbor;
EXEC SQL
INSERT INTO REZERVARE(Codz,Codc,Observatii)
VALUES(cod_zbor, cod_client, NULL);
Output(“Rezervare efectuata!”);
End.
După cum se poate observa din implementarea tranzacţiei, rezervarea unui loc presupune doua accese la baza de date:
• Primul acces se face în relaţia ZBOR pentru a decrementa numărul de locuri libere; este o operaţie de actualizare;
• Al doilea acces realizează scrierea unei noi înregistrări în relaţia în relaţia CLIENT. Înregistrarea unui nou client costituie obiectul unei alte tranzacţii.
2.1 Condiţii de terminare a tranzacţiilor
În exemplul de mai sus tranzacţia prin care se face rezervarea unui nou loc nu ia în considerare faptul că s-ar putea şa nu mai existe locuri libere pentru un zbor. Din contră, tranzacţia se bazează pe presupunearea implictă că întotdeauna există un loc liber, ceea ce este total nerealist. Rezultă că tranzacţia în cauză nu se poate realiza întotdeauna cu succes, ci trebuie analizate şi celelalte alternative. Totuşi orice tranzacţie trebuie să se termine, indiferent de situaţia existentă (chiar şi în cazul unoe 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ă, dintr-un motiv sau altul, tranzacţia nu reuşeşte să-şi execute complet operaţiile prevăzute, atunci se va termina printr¬-o operaţie de abortare (abort sau rollback). Motivele pentru care tranzacţie se abortează sunt numeroase, ele pot fi interne tranzacţiei sau externe acesteia (ex : detectarea de către SGBD a unei situaţii de interblocare). În cazul abortării execuţia tranzacţiei este oprită iar efectele tuturor operaţiilor pe care le-a executat până în acel moment sunt anulate astel încât baza de date revine la starea de dinaintea lansării tranzacţiei.
Comanda de validare a unei tranzacţii are un 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 aborta) şi modificările efectuate în baza de date devin permanente.
Operaţia de validare este vitală în cazul sistemelor concurente, deci acolo unde este posibilă executarea în acelaşi timp mai multor tranzacţii care accesesază aceeaşi bază de date. Prin validare se pot preveni o serie de fenomene nedorite cum este abortare în cascadă a tranzacţiilor.
Să presupunem că o tranzacţie T este abortată după ce a efectuat una sau mai multe operaţii de actualizare a bazei de date. În acest caz alterate de catre tranzacţia T vor fi readuse la valorile pe care le-au avut înainte de a fi modificate de aceast. Este, însă posibil ca unele dintre tranzacţiile executate în mod concurent cu tranzacţia T să fi accesat aceste date înainte de abortarea lui T. Aceste tranzacţii vor trebui să fie la rândul lor abortate deoarece au avut acces la date inconsistente din bază ceea ce înseamnă că rezultatele produse de ele pot fi compromise. Acest efect se poate propaga în continuare şi asupra altor tranzacţii, pe un număr nedefinit de nivele, conducând la abortarea în cascadă a tranzacţiilor. Fenomenul este cunoscut în literatura de specialitate sub numele de efect domino.
Dacă se foloseşte un mecanism de validare care respectă cele două reguli de mai sus, atunci apariţia fenomenului de abortare în cascadă devine imposibilă . Într-adevăr, conform primei reguli, nici o tranzacţiei nu va putea accesa datele modificate de către tranzacţia T decât validarea acesteia. Pe de altă parte, conform regulii a doua, după validarea sa tranzacţia T nu mai poate fi abortată, deci nu poate declanşa un lanţ de abortări în cascadă.
Validarea unei tranzacţii marchează, din punct de vedere logic, terminarea acesteia. Validarea nu se poate face înainte ca operaţiile specficate prin codul tranzacţiei să fie executate integral şi înainte ca tranzacţia să ajungă intr-o stare începând de la care există certitudinea că nu mai poate fi abortată.
Până în momentul validării, actualizările efectuate de tranazcţiei sunt indivizibile alor tranzacţii, au caracter tentativ şi pot fi oricând revocate(o dată cu abordare tranzacţiei). După validare actualizările se înscriu cu caracter permanent în baza de date şi devin irevocabile. După validare nu mai este posibilă abortarea tranzacţiilor.
Exemplu:
Pentru a lua în considerare şi situatia în care nu mai este nici un loc disponibil pentru un zbor dat, tranzacţia pentru exemplul din paragraful precedent poate fi rescrisa astfel:
Begin_tranzaction Rezervare
Begin
Input(cod_zbor, cod_client);
EXEC SQL
SELECT Libere
INTO temp
FROM ZBOR
WHERE Codz=cod_zbor;
If temp = 0 then
Begin
Output(“Nu mai sunt locuri libere!”);
ABORT
End
Else
Begin
EXEC SQL
UPDATE ZBOR
SET Libere = Libere-1
WHERE Codz = cod_zbor;
EXEC SQL
INSERT INTO
REZERVARE(Codz,Codc,Observaţii)
VALUES(cod_zbor,cod_client,NULL);
COMMIT;
Output(“Rezervare efectuată!”);
End
În această variantă a tranzacţiei numărul de locuri libere corespunzător zborului solicaitat este citit în variabila temp pentru a se verifica dacă mai sunt locuri libere. Dacă nu sunt locuri, atunci tranzacţia se termină prin abortare, după ce s-a semnalat printr-un mesaj lipsa de locuri. Dacă mai sunt locuri disponibile, atunci se face rezervarea şi tranzacţia se termină printr-o comnadă de validare (COMMIT). De remarcat că mesajul către utilizator indicând efectuarea cu succes a rezervării trebuie să succeadă comanda de validare, deoarece tranzacţia ar putea fi abortată în orice moment dinaintea validării datorită unor cauza externe tranzacţiei. Numai după validare există certitudinea că rezervarea nu mai poate fi anulată şi că va fi înregistrată cu caracter permanent în baza de date.
2.2 Proprietăţile tranzacţiilor
Prin definiţie tranzacţiile sunt unităţi de execuţie care garantează consistenţa şi siguranţa bazei de date. Pentru aceasta orice tranzacţie trebuie să satisfacă un set de 4 condtiţii sintetizate în literatură prin acronimul ACID-atomicitate, consistenţă, izolare, durabilitate.
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, SGBD-ul poate proceda în două moduri :
• Fie completează operaţiile rămase neexecutate din cadrul tranzacţiei terminând tranzacţia cu succes
• Fie anulează toate efectele operaţiilor executate de tranzacţie în momentul întreruperii, terminând tranzacţia prin abortare.
Consistenţa
Consistenţa unei tranzacţii constă pur şi simplu în corectitudinea sa. Orice tranzacţie, dacă este executată independent, trenuie să menţină consistenţa bazei de date. Altfel spus, o tranzacţie este un program corect care transformă baza de date dintr-o stare consistentă intr-o altă stare consistentă a sa. Prin consistenţa bazei de date înţelegem satisfacerea tuturor constrângerilor de integritate, explicite sau implicite, cum ar fi :
• Unicitatea cheilor primare;
• Integritatea referenţială;
• Orice predicat exprimat în sens de constrângere de integritate asupra bazei de date.
Bineînţeles că este de neconceput verificarea tuturor acestor condiţii după executarea fiecărei tranzacţii. De aceea unicul criteriu pentru stabilirea proprietăţii de consistenţă a unei tranzacţii rămâne corectitudinea sa din punct de vedere logic. Spre deosebire de celelalte proprietăţi din complexul ACID care sunt asigurate de către sistem, proprietatea de consistenţă a tranzacţiei cade în sarcina programatorului de aplicaţii. De remarcat faptul că stările intermediare prin care trece baza de date în timpul execuţiei unei tranzacţii nu sunt neapărat consistente.
Izolarea
Se referă la proprietatea oricărei tranzacţii de a avea acces doar la stările consistente ale bazei de date. Aceasta înseamnă că modificările efectuate de către o tranzacţie sunt incaccesible 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 nici un fel (cel puţin în ce priveşte rezultatele) faptul că alte tranzacţii sunt executate în acelaşi timp în sistem. Izolarea tranzacţiilor este asigurată prin algoritmii de control al concurenţei. Conceptul de izolare este aproximat adesea prin cel de serializabilitate, deşi nu se confundă cu acesta. Serializabilitatea, deşi este o condiţie suficientă pentru realizarea izolării, nu este şi necesară.
Proprietatea de izolare este importantă deoarece elimină fenomenul de abordare în cascadă a tranzacţiilor (efect domino). Într-adevăr dacă rezultatele incomplete ale unei tranzacţii ar fi vizibile altor tranzacţii înanite de validarea acesteia şi dacă se întâmplă ca această tranzacţie să aborteze, atunci toate tranzacţiile care au accesat rezultatele incomplete vor trebui abortate. Aceasta poate conduce la abortarea altor tranzacţii ş.a.m.d. rezultând efectul domino.
Durabilitatea
Durabilitatea unei tranzacţii este proprieteatea prin care se garantează faptul că odată tranzacţia 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ă propretatea de durabilitate are la bază conceptul de jurnal. Jurnalul este un fişier secvenţial în care sunt înregistrate toate operaţiile efectuate de tranzacţiile din sitem. Jurnalul conţine istoria evoluţiei întregului sitem. El este folosit la reluarea activităţii de către procedurile de recuperare care vor completa eventualele operaţii neterminate ale tranzacţiilor care au fost validate înainte de apariţia defectului.
CUPRINS
Capitolul II – Tranzacţii………………………………………………………8
2.1 Condiţii de terminare a tranzacţiilor………………………………......10
2.2 Proprietăţile tranzacţiilor.......................................................................12
2.3 Formalizarea conceptului de tranzacţie.................................................14
Capitolul III – Controlul concurenţei………………………………….........17
3.1 Anomalii de interferenţă……………………………….……………...18
3.2 Primitivele LOCK şi UNLOCK……….………………………………20
3.3 Unităţi de acces………………………………………………………...22
3.4 Serializabilitate………………………………………………………...22
3.5 Formalizarea conceptului de serializabilitate…………………………..24
3.6 Algoritmi de control al concurenţei în bazele de date centralizate……..28
3.7 Gestiunea interblocărilor în baze de date centralizate………………….41
Capitolul IV – Algebră relaţională…………………………………………....49
4.1 Algebra relaţională...................................................................................51
4.2 Calculul relaţional pe tupluri…………………………………………..56
4.3 Reducerea algebrei relaţionale la calculul relaţional pe tupluri………..59
4.4 Calculul relaţional pe domenii…………………………………………60
4.5 Reducerea calculului relaţional pe tupluri la calculul relaţional pe domenii…61
4.6 Reducerea calculului relaţional pe domenii la algebra relaţională……..62
