Operații concurente asupra bazelor de date

INTRODUCERE

Până nu demult, conceptul nostru despre bazele de date a fost unul în care programele care accesează o bază de date sunt rulate unul după altul. De multe ori aceasta este situaţia în care ne aflăm. Astăzi există de asemenea numeroase aplicaţii în care mai mult de un program, sau diferite execuţii ale aceluiaşi program rulează simultan accesând aceeaşi bază de date. Un astfel de exemplu este un sistem de rezervare a locurilor la o companie aeriană, unde mai mulţi agenţi pot vinde bilete sau face rezervări de locuri. Problema care intervine este aceea că dacă nu suntem atenţi cum permitem la mai mult de două programe să acceseze baza de date, putem vinde acelaşi loc de două ori. Intuitiv, două procese care citesc şi schimbă valoarea aceluiaşi obiect nu trebuie rulate concurent .

Un al doilea exemplu este acela al unei baze de date statice, unde mai mulţi utilizatori pot face interogări în acelaşi timp. Aici, atât timp cât nimeni nu schimbă datele, nu este important în ce ordine procesele citesc datele, putem lăsa sistemul de operare să programeze simultan cererile de citire cum doreşte. În acest gen de situaţii, unde se face numai citire, dorim să permitem un număr maxim de operaţii concurente, ca să economisim timp. În cazul sistemului de rezervări, unde citirea şi scrierea sunt amândouă în progres, avem nevoie de restricţii pentru cazurile în care permitem ca două programe să ruleze concurent.

În această lucrare vom considera modele de procese concurente care sunt legate de operaţiile pe bazele de date. Modelele se disting în primul rând prin detaliile care descriu accesul la elementele din baza de date. Pentru fiecare model vom descrie o cale rezonabilă de a permite acele operaţii concurente care păstrează integritatea bazelor de date şi să prevenim acele operaţii care pot distruge integritatea unei baze de date, atât cât un model cu detalii limitate ne poate spune despre integritate. Şi ca o regulă, cu cât modelul este mai detaliat cu atât mai mult putem permite concurenţa în siguranţă.

De asemenea în această lucrare vom discuta şi despre felul în care sunt abordate operaţiile concurente pe baze de date în limbajul de programare Visual FoxPro. Partea practică a acestei lucrări o reprezintă aplicaţia “Administraţia unui cămin studenţesc”, care reprezintă un sistem informatic pentru un cămin studenţesc. Această aplicaţie simulează serviciile de cazare şi plată a taxei de cămin care se realizează într-un cămin studenţesc.

TRANZACŢII ASUPRA BAZELOR DE DATE

1. CONCEPTE DE BAZĂ

O tranzacţie este o singură execuţie a unui program. Acest program poate fi o simplă interogare sau un program complex cu apeluri din unul din limbajele QUEL, SEQUEL, etc… Mai multe execuţii independente ale aceluiaşi program pot fi în progres simultan; fiecare dintre aceste execuţii este o tranzacţie.

ITEM-URI

Ne imaginăm că baza de date este împărţită în item-uri (articole) care sunt porţiuni din baza de date care pot fi blocate. Prin blocarea unui item o tranzacţie poate preveni alte tranzacţii să mai acceseze acel item, până când tranzacţia care deţine blocajul nu deblochează itemul respectiv. O parte a DBMS (DataBase Maneger System) numită managerul de blocaje asigneză şi înregistrează blocajele, ca de altfel şi arbitrarea între două sau mai multe cereri de a bloca acelaşi item.

Natura şi mărimea item-urilor sunt subiectele unor teme ce urmează în continuare. De exemplu, în modelul relaţional de date, putem alege item-uri mari, cum sunt relaţiile, sau item-uri mici ca tuple individuale sau componente din tuple. Putem alege o mărime intemediară pentru item-uri, de exemplu item-urile pot fi colecţii de 100 de tuple din aceeaşi relaţie. În modelul de reţea, de exemplu, un item poate fi o colecţie a tuturor înregistrărilor unui singur tip.

Alegând item-uri mari sistemul poate pica în timpul menţinerii blocărilor, în timp ce alegând item-uri mici putem permite mai multor tranzacţii să opereze în paralel. Dacă o tranzacţie tipică (într-un sistem relaţional) citeşte sau modifică un tuplu, care se găseşte cu ajutorul unui index, ar fi mai convenabil de tratat tuplele ca item-uri. Dacă o tranzacţie tipică face o operaţie de join pe două sau mai multe relaţii, atunci poate ar fi mai bine să tratăm relaţiile ca item-uri.

În ceea ce urmează, vom presupune că atunci când o parte a unui item este modificată, întreg item-ul este modificat şi primeşte o valoare unică şi neegală cu nici o altă valoare care poate fi obţinută prin orice altă modificare. Facem această presupunere nu numai pentru a simplifica modelarea tranzacţiilor. În practică, necesită multă muncă din partea sistemului pentru a deduce fapte ca acela că rezultatul unei modificări a unui item dă acelui item aceeaşi valoare pe care o avea după câteva modificări precedente. Mai mult dacă sistemul poate să-şi amintească, când o parte a unui item a rămas neschimbată după ce item-ul a fost modificat, acesta poate de asemenea să împartă item-ul în mai multe item-uri mai mici. O consecinţă a presupunerii noastre despre indivizibilitatea item-urilor este că nu vom greşi dacă vom considera item-urile ca simple variabile, aşa cum sunt folosite în limbajele de programare obişnuite.