Sunteți pe pagina 1din 8

CONTROLUL ACCESELOR CONCURENTE LA BAZE DE DATE

Introducere.
Sistemele de programe care realizeaz controlul concurenei sunt acea paret a sistemului de gestiune
a bazei de date (SGBD), care urmrete execuia simultan a tranzaciilor, astfel nct s fie
produse aceleai rezultate ca i n cazul unei execuii secveniale.
Formulnd n mod diferit ideea de mai sus, putem defini cotrolul concurenei ca o activitate de
divizare, sau dustribuire a datelor coninute n baza de date, ntre diferii utilizatori ai acesteia, n o
astfele de maier nct procesul acestei divizri s fie complet transparent pentru utilizatori.
O soluie primitiv n vederea atingerii obiectivului de mai sus, ar pute fi izolarea ntregii baze de
date n timpul execuiei- sau prelucrrii- fiecrei tranzacii, izolarea fiind realizat de ctre SGBD.
Aceast modalitate de control este simpl, dar neeficient. Performanle unui sistem de baze de date
ce folosete un astfel de mod de prelucrare se vor deteriora repede, pn la un nivel inacceptabil,
odat cu creterea numrului utilizatorilor bazei de date. Drept consecin, proiectanii de siteme de
gestiune au cutat s elaboreze algoritmi simpli, care s asigure un grad nalt de concuren, odat
cu realizarea unor performane acceptabile.
n cele de mai sus, au fost folsite concepte generale care nu au fost nc definite n mod specific, n
contextul tematic abordat. Acestor concepte le corespund termenii de concuren a acceselor,
tranzacie, performane. Pe parcursul paragrafelor urmtoare, aceti termeni vor fi definii n o
manier mai specific.
Integritatea datelor
Integritatea datelor este reprezentat de concordana acestora cu proprietile sistemelor din lumea
real pe care le modeleaz. Respectarea integritii datelor este o problem esenial n cazul
bazelor de date la care au loc accese concurente.
Schema unei baze de date conine descrierea datelor i, implicit, restriciile de integritate crora
trebuie s se supun aceste date.
Restriciie de integritate este o aseriune care trebuie s fie respectat, sau verificat, de ctre date n
anumite momente determinate.
O baz de date este coerent dac datele pe care le conine respect ansamblul restriciilor de
integritate implicit sau explicit ce au fost definite n contextul definirii bazei de date.
Pentru a aprofunda nelegerea restriciilor de integritate, s admitem exemplul unei baze de date de
lucru format din urmtoarele relaii:
Cumprare (CP, DC, CC),
Vnzare (CP; DV; CV),
Stoc (CP, CS),
Produs (CP, NP, NFU, NFA).
n schemele relaiilor, atributele au sensurile: CP- cod produs, DC- data cumprrii, CC- cantitatea
cumprat, DV- data vnzrii, CV- cantitatea vndut, CS- cantitatea n stoc, NP- numele
produsului, NFU- numele furnizorului, NFA- numele fabricantultui.
n una din clasificrile adoptate, restriciile de integritate sunt de tipurile de mai jos:
a) restricii de integritate privind un element de date. La rndul lor, acestea se pot referi la tipul
da date i la domeniul de valori (de exemplu, CC este un numr ntreg, iar 1 < CV < 10
000).
b) Restricii de integritate privind mai multe elemente de date. Acestea pot fi: restricii de
dependen duncional (de exemplu, CP - > NP), restricii de dependen multi valoare ( CP
- >> NFU, CP - >> NFA), restricii de dependen refernial ( de exemplu, fiecare tuplu din
relaia Stoc trebuie s corespund uneui tuplu din relaia Produs).

c) Restricii de redundan, car trebuie respectate de mai multe elemente de date (pentru fiecare
produs, cantitatea n stoc CS trebuie s rmn egal cu diferena dintre suma cantitilor
cumprate CS i suma cantitilor vndute CV).
d) Restricii ce au n vedere unii invariani ( ca exemplu, menionm c suma general a tuturor
valorilor deinute de o banc trebuie s rmn constant la execuia unui transfer).
e) Restricii temporare de integritate, respectate numai n anumite momente sau intervale de
timp (de pild, n o banc anumite valori au o valoare determinat numai la sfrit de lun).
Pentru exprimarea i analiza formal a restriciilor de integritate (n afara celor temporare) se poate
folosi logica predicatelor de ordinul nti.
Tranzacii. Aciuni.
Potrivit unei definiii larg acceptate, tranzacia este o unitate de prelucrare secvenial efectuat
pentru un utilizator, care aplicat unei baze de date coerente, restitue o baz de date coerent.
Restriciile de integritate sunt ntotdeauna invariante pentru tranzacii. n general, un sistem de baze
de date execut un ansamblu de tranzacii n mod simultan, pentru diferii utilizatori. Problemele
dificile n realizarea concurenei decurg din interferenele care pot s apar ntre aceste tranzacii
diferite, ca urmare a partajrii datelor ntre utilizatorii bazelor de date.
Tranzaciile sunt compuse din uniti de prelucrare mai fine, ce poart numele de aciuni. Aciunea
este o comand indivizibil, executat de sistemul de gestiune n cadrul unei tranzacii. Citirea unei
informaii din memorie, sau nregistrarea unei informaii, sunt nelese, n general, ca aciuni.
Probleme de concuren a acceselor.
Definirea conceptelor de tranzacie i de aciune permite punerea n lumin a unor probleme
elementare ce pot s apar atunci cnd mai multe tranzacii ncearc s efectueze operaiuni de
acces la aceleai elemente (sau obiecte) de date. Astfel de tentative conduc la situaii de conflict
ntre aciuni, respectiv ntre tranzacii. Aa cum se va vedea, operaiunile respective au loc la
momente de timp foarte apropiate, fr ns a fi simultane n adevratul sens al acestui termen. n
cele ce urmeaz, ne vom referi la dou tipuri de probleme: pierderile de operaie i inconsistenele.
Pierderi de operaie. Un caz reprezentativ de pierdere de operaie este pierderea de actualizare,
care poate fi urmrit n Fig. 1. Aa cum se vede, o tranzacie T1 poate, n decursul efecturii unei
aciuni ai, s citeasc un obiect de date ntr-un registru tampon de memorie (care i aparine),
urmnd ca apoi s modifice valoarea acestui obiect (de exemplu, s o incrementeze cu o unitate) i
s nregistreze noua valoare n memori, n decursul unei alte aciuni aj (j > i). Este ns posibil ca o
alt tranzacie T2
Tranzacia T1

__

ai : Read X -> x1

-------------

aj : x1 + 1 -> x1
Write x1 -> X

Tranzacia T2
ak : Read X -> x2
x2 + 1 -> x2
Write x2 -> X

Fig. 1
s fi efectuat o actualizare (incrementare) a aceluiai element de date, printr-o aciune ak, amplasat
ntre aciunile ai i aj. Actualizarea reprezentat de aciunea ak, n tranzacia T2, este ns pierdut.
Inconsistene. Mai nti, vom trata cazul n care o tranzacie afieaz coninutul unei baze de date
care se gsete n stare tranzitorie. Admitem c baza de date (desigur, foarte elementar, format
2

numai din elementele de date A i B) trebuie s respecte restricia de integritate A = B. Aa cum se


vede n Fig. 2, tranzacia T2 citete A dup ce acest element de date a fost modificat de tranzacia
T1, respectiv citete elementul B nainte ca acesta s fi fost incrementat de T1. n acest mod,
tranzacia T2 va afia pentru A o valoare diferit de valoarea lui B.
Tranzacia T1
Read A -> a1
a1 + 1 -> a1
Write a1 -> A

Read B -> b1
b1 + 1 -> b1
Write b1 -> B

A=B
----------------------------------

Tranzacia T2

Read A -> a2
Print a2
Read B -> b2
Print b2

Fig. 2

S presupunem acum c tranzacia T2 ncearc s actualizeze baza de date atunci cnd aceasta este
n regim tranzitoriu, respectiv se gsete ntr-o stare de ne-coeren, n care elementele de date nu
sunt egale (A este diferit de B). Evoluia tranzaciilor T1 i T2 este descris mai jos, n Fig. 3:
Tranzacia T1
Read A -> a1
a1 + 1 -> a1
Write a1 -> A

Read B -> b1
b1 + 1 -> b1
Write b1 -> B

A=B
----------------------------------------

Tranzacia T2

Read A -> a2
a2 x 2 -> a2
Write a2 -> A
Read B -> b2
b2 x 2 -> b2
Write b2 -> B

Fig. 3
Se poate observa imediat c prin aranjarea n timp de mai sus a aciunilor tranzaciilor T1 i T2, se
obine n final o baz de date necoerent, caracterizat prin nclcarea restriciei de integritate A=B.
n mod obinuit, se afirm c printr-o asemenea dispunere n timp a aciunilor, tranzaciile T1 i T2
se gsesc n stare de conflict, respective execuia (sau planificarea lor) implic un conflict. Este deci
firesc s cutm condiiile n care execuiile de tranzacii sunt astfel planificate, nct s fie evitate
conflictele.

Planificri fr conflict
Mai nti, vor fi introduce cteva alte noiuni care ocup un loc nsemnat n studiul acceselor
concurente, respective al planificrii fr conflict a execuiei tranzaciilor. Prin controlor (n
literature strin se folosesc termenii controller sau scheduler) nelegem un modul al
sistemului de gestiune a bazelor de date care urmrete i comand accesul concurrent la
informaiile coninute n o baza de date. n acelai context, denumim granul o unitate component
a unei baze de date, care este controlat n mod individual de un controlor.
Una din problemele care se ridic n contextul prelucrrii bazelor de date n regim de concuren a
acceselor este alegerea unor dimensiuni adecvate ale granulelor. Aceste dimensiuni se pot nscrie n
o gam ntins de la lungimea unei nregistrri pn la lungimea unei pagimi sau a unui ntreg fiier.
La limit, ntreaga baz de date poate reprezenta o granul.
De dimensiunile granulelor sunt legate performanele procesului de acces al tranzaciilor la o baz
de date. n o abordare general, se nelege c atunci cnd baza de date este divizat ntr-un numr
mare de granule de dimensiuni mici, au acces la informaie mai multe tranzacii, n acest mod
realizndu-se un grad mai nalt de paralelism n prelucrarea bazei de date. Pe de alt parte, n
acest caz procesul de control al concurenei acceselor este mai complex i va reclama un interval de
timp mai lung. n practic se recomand o dimensiune variabil a granulelor.
Datele coninute n fiecare granul trebuie s respecte restricii de integritate care decurg din
restriciile generale acceptate pentru ansamblul bazei de date. Vom observa aici c n procesul
modificrii bazei de date, granulele se modific de asemenea, ca efect al execuiei unor aciuni. Ne
reamintim c aciunile sunt uniti funcionale de prelucrare secvenial, care nu trebuie s ncalce
restriciile de integritate valabile pentru datele ce aparin granulelor i, deci, respect coerena
intern a acestora.
Avnd n vedere elementele de mai sus, vom nelege prin operaie o succesiune de aciuni care
ndeplinesc o funcie bine definit asupra granulei, respectnd coerena intern a acesteia. n funcie
de tipul sistemului de gestiune i de modul n care sunt controlate accesele concurente, natura
operaiilor poate fi diferit. n unele cazuri, operaiile sunt interpretate ele nsele ca procese- sau
aciuni- indivizibile, ce efectueaz prelucrri elementare (nscrieri de informaie, citiri, inserri etc.)
asupra unor elemente de date de tipul nregistrrilor, paginilor, etc. Starea unei granule n urma
efecturii unei operaii, ca i unele efecte secundare la care a condus execuia operaiei, poart
numele de rezultat al operaiei. De pild, rezultatul execuiei unei tranzacii care prelucreaz o baz
de date este starea granulelor bazei de date dup ncheierea tranzaciei, precum i coninutul
eventualelor mesaje editate n urma acestui proces.
Planificarea (execuia) unei mulimi de tranzacii.
O idee central avut n vedere pe parcursul consideraiunilor anterioare, const n faptul c n
procesul prelucrrii unei baze de date, sub controlul sistemului de gestiune, este efectuat o
succesiune de aciuni care fac parte dintr-un ansamblu de tranzacii concurente. Evident c n
funcie de poziia pe care ne situm, ca observatori, n decursul prelucrrii unei baze de date, putem
concepe, pregti, urmri i controla procesul execuiei tranzaciilor concurente, sau putem analiza
modul n care acest proces s-a desfurat, dup ncheierea sa. Avnd n vedere aceste poziii,
denumirile atribuite procesului prelucrrii tranzaciilor sunt diferite. n cazul prim, se folosete
termenul de planificare sau execuie (n literatura strin, schedule), iar n cel de al doile caztermenul de istorie sau chiar cel de nregistrare sau de jurnal (log).
Fie mulimea de tranzacii { T1, T2, ...., Tn }. Atunci, prin ( T1, T2, ...., Tn ) putem nelege fie
succesiune a tranzaciilor efectuate, deci o istorie a sistemului care prelucreaz accese concurente,
fie o planificare a viitoarei execuii concurente a acestor tranzacii.
Avnd n vedere execuia viitoare a tranzaciilor, putem defini planificarea ( T1, T2,...., Tn ) a
acestora ca o succesiune de aciuni, obinut printr-o intercalare a aciunilor din compunerea
tranzaciilor T1, T2, ..., Tn, respectnd ordinea intern n care se gsesc aceste aciuni n
fiecare tranzacie. Vom remarca faptul c putem nelege n mod similar i istoria execuiei

grupului de tranzacii. Aadar, o planificare respect cu exactitate ordinea aciunilor fiecrei


tranzacii constituente, fiind- prin definiie- secvenial.
Pentru a ilustra consideraiunile de mai sus, fie exemplul traanzaciilor T1 i T2, ale cror aciuni
sunt ns enumerate n ordinea lor, fr a mai fi indicat amplasarea n timp ( Fig. 4 ):

Tranzacia T1

Tranzacia T2

Read A -> a1
a1 + 1 -> a1
Write a1 -> A
Read B -> b1
b1 + 1 -> b1
Write b1 -> B

Read A -> a2
a2 x 2 -> a2
Write a2 -> A
Read B -> b2
b2 x 2 -> b2
Write b2 -> B
Fig. 4

n descrierea dat, tranzaciile T1 i T2 modific elementele A i B, legate prin restricia de


integritate A=B. Elementele A i B aparin la dou granule distincte, ceea ce contribute la creterea
posibilitilor de concuren. n continuare ( Fig. 5 i Fig. 6 ), sunt prezentate dou planificari
posibile pentru tranzaciile T1 i T2. PLanificarea din Fig. 6 este inacceptabil, deoarece conduce la
o pierdere de operaie.
Tranzacia T1

Tranzacia T2

Read A -> a1
a1 + 1 -> a1
Write a1 -> A

Read A -> a2
a2 x 2 -> a2
Write a2 -> A

Read B -> b1
b1 + 1 -> b1
Write b1 -> B

Read B -> b2
b2 x 2 -> b2
Write b2 -> B
Fig. 5

Tranzacia T1

Tranzacia T2
Read A -> a2
a2 x 2 -> a2

Read A -> a1
a1 + 1 -> a1

Write a2 -> A
Read B -> b2
b2 x 2 -> b2

Write a1 -> A
5

Read B -> b1
b1 + 1 -> b1
Write b1 -> B

Write b2 -> B.
Fig. 6

Planificare serializabil
Aa cum am vzut, unele planificri de tranzacii conduc la pierderi de operaii sai inconsistene. Un
obiectiv principal al controlului concurenei acceselor este de a nu permite dact execuia acelor
planificri, care nu sunt nsoite de pierderi de operaie sau de inconsistene.
O soluie posibil a problemei de mai sus poate fi execuia succesiv (serial) a tranzaciilor. Prin
adoptarea unei asemenea planificare se poate evita complet apariia pierderilor de operaie i
inconsistenelor, efectuarea aciunilor ce compun fiecare tranzacie desfurndu-se separat i
independent de evoluia altor tranzacii, fr intercalarea n timp a acestor aciuni. Execuia serial a
unui grup de tranzacii poart numele de succesiune.
Drept consecin a considerentelor expuse, rezult c n scopul excluderii posibilitii de conflict
ntre aciunile tranzaciilor, trebuie permise numai acele planificri care conduc la aceleai rezultate
ca cele date de o succesiune, pentru fiecare dintre tranzacii. Planificrile de acest tip se numesc
serializabile. Prin definiie, o planificare a tranzaciilor (T1, T2, ......,Tn) este serializabil,
dac pentru fiecare tranzacie participant ea conduce la aceleai rezultate ca o succesiune a
tranzaciilor (T1, T2, ....,Tn).
Prin urmare, din punctul de vedere al controlului concurenei acceselor diferitelor tranzacii la
informaiile coninute n o baza de date, sarcina sistemelor de gestiune (fie ele centralizate sau
distribuite) este de a genera numai planificri serializabile. n acest mod, este asigurat absena
conflictelor ntre aciunile tranzaciilor. Pentru realizarea acestui deziderat, operaile din care este
compus execuia tranzaciilor trebuie s posede proprieti specifice.
Proprieti ale operaiilor.
Vom distinge dou clase de operaii care, prin proprietile lor, pot asigura serializabilitatea
planificrii tranzaciilor: operaii compatibile i operaii permutabile.
nainte de a defini operaiile compatibile, vom observa c dou operaii ce fac parte din tranzacii
diferite i care nu efectueaz modificri n nicio entitate, pot fi ntotdeauna executate simultan, fr
a intereveni schimbri reciproce asupra rezulatelor lor. Cu alte cuvinte, de exemplu, orice fel de
intercalare de operaii care nu fac dect citiri, conduce la rezultate identice n cazul unei execuii
succesive a operaiilor.
Prin definiie, operaiile O1 i O2 sunt compatibile dac i numai dac, oricare ar fi execuia lor
simultan , rezultatul acesteia este acelai cu cel al execuiei secveniale (seriale) a operaiei O1
urmat de operaia O2, sau a operaiei O2 urmat de O1. Remarcm faptil c rezultatele execuiilor
O1 urmat de O2, respectiv O2 urmat de O1, pot fi diferite.
Pentru aprofundqreq considerqiilor preyentqte pot fi folosite exemplele din Fig. 7, n care
operaiile O11 i O21 sunt compatibile, pe cnd O21 i O22, respectiv O13 i O23 nu sunt
compatibile.
O11

Read A -> a1
a1 x 2 -> a1
Print a1

O21

Read A -> a2
a2 + 1 -> a2
Print a2

O12

Read A -> a1
a1 x 2 -> a1
Write a1 -> A

O22

Read A -> a2
a2 + 1 -> a2
Write a2 -> A

O13

Read A -> a1
a1 + 1 -> a1
Write a1 -> A

O23

Read A -> a2
a2 + 10 -> a2
Write a2 -> A

Fig. 7
Este evident c operaiile care prelucreaz granule diferite sunt ntotdeauna compatibile, ntruct
pentru un asemenea caz nu pot surveni pierderi de operaie dac operaiile se intercaleaz. Se
nelege c atunci cnd exist posibilitatea de intercalare prin care se genereaz o pierdere de
operaie, operaiile implicate nu vor fi compatibile.
Ordinea n care pot fi executate operaiile i rezultatele acestei execuii determin o alt proprietate
important a unor clase de operaii. S ncepem prin a remarca faptul c, n unele situaii,rezultatele
unei execuii de operaii poate depinde de ordinea n care aceasta este realizat. Pe de alt parte, n
alte cazuri ordinea poate fi indiferent. n acelai context, s mai observm c proprietatea de
compatibilitate a operaiilor este independent de ordinea axestora.
Vom defini dou operaii O1 i O2 ca fiind permutabile, dac i numai dac orice execuie a
acestor operaii n ordinea O1, O2 conduce la acelai rezultat cu execuia n ordinea O2, O1.
Revenind la Fig. 7, operaiile O13 i O23 sunt permutabile, n timp ce O12 i O22 nu sunt
permutabile. Sunt ntotdeauna permutabile dou operaii care prelucreaz granule diferite, execuia
uneia din aceste operaii neputnd schimba rezultatul execuiei celei de a doua operaii i invers.
Compatibilitate, permutabilitate, serializabilitate
n cele ce urmeaz, va fi pus n lumin dependena proprietii de serializabilitate a unei execuii
de tranzacii, de proprietile de compatibilitate i permutabilitate ale operaiilor care compun
tranzaciile.
Mai nti, subliniem dou transformri de baz la care pot nfi supuse planificarile de tranzacii:
-separarea operaiilor compatibile O1 i O2 executate de dou tranzacii diferite, const n
nlocuirea execuiei simultane E( O1, O2) a acestora, printr-o secven care conduce la acelai
rezultat, respectiv (O1, O2), sau (O2, O1). Aadar, procesul de separare permite aranjarea n
succesiune a oparaiilor compatibile executate de ctre tranzacii diferite.
-Permutarea operaiilor permutabile O1 i O2, executate de dou tranzacii diferite, const n
schimbarea ordinei de execuie a acestor operaii (de pild, secvena (O1, O2) este nlocuit cu
secvena (O2, O1).
Lund n considerare cele dou transformri definte anterior, rezult c o condiie suficient
pentru ca o planificare de tranzacii s fie serializabil este ca prin separarea operaiilor
compatibile i prin permutarea operaiilor permutabile, planificarea s fie transformat n o
succesiune de tranzacii componente.
Pentru a ilustra consideraiunile prezentate, s examinm exemplul planificrii din Fig. 5. Dac ne
oprim numai asupra operaiilor, planificarea poate fi reprezentat n forma:
T1 :
T2 :
T1 :
T2 :

A + 1 -> A
A x 2 -> A
B + 1 -> B
B x 2 -> B.

Operaiile A x 2 -> A i B + 1 -> B sunt permutabile, deoarece lucreaz asupra unor granule
diferite. n consecin, planificarea poate fi transformat n urmtoarea:
T1 : A + 1 -> A
T1 : B + 1 -> B
7

T2 : A x 2 -> A
T2 : B x 2 -> B.
Noua planificare obinut este o succesiune de tranzacii, respectiv tranzacia T1 urmat de
tranzacia T2. Ca urmare, planificarea reprezentat n Fig. 5 este serializabil.
Grafuri de preceden.
Vom defini mai nti noiunea de precedn, pentru orice planificare ce nu conine operaii
simultane (spre exemplu, planificri obinute prin separare de operaii compatibile). n acest scop,
s admitem c P este o planificare ce nu conine operaii simultane. Pein definiie, afirmm c n
planificarea P are loc precedena tranzaciei T1 fa de tranzacia T2 (adic T1 precede T2, cu
notaia T1 < T2 ), dac i numai dac exist dou operaii nepermutabile O1 i O2, astfel nct
operaia O1 este executat de tranzacia T1 nainte ca operaia O2 s fie executat de tranzacia T2.
Pentru a descrie interaciunile dintre tranzacii n timpul unei execuii poate fi folosit graful de
preceden. n graful de preceden al unei planificri se asociaz un nod cu fiecare tranzacie,
ntre nodurile T1 i T2 fiind trasat un arc orientat de la nodul T1 la nodul T2 dac i numai dac
tranzacia T1 precede tranzacia T2. Potrivit unei teoreme specifice, pe care nu o demonstrm aici, o
condiie suficient ca o planificare de tranzacii s fie serializabil este ca graful de preceden
asociat cu planificarea s nu conin contururi nchise sau bucle proprii.
Pentru exemplificare, n Fig. 8 este prezentat graful de preceden al planificrii din Fig. 5. n graf
nu avem conturi nchise, deci planificarea este serializabil.
T1

T2
Fig. 8

Un alt exemplu, cel urmtor, se refer la planificarea din Fig. 9, care nu este serializabil.
T1
T2
T2
T1

:
:
:
:

A + 1 -> A
A x 2 -> A
B x 2 -> B
B+ 1 -> B

T1

T2

Aa cum se vede, graful de precedn al planificrii reprezentat n aceeai figur- are un contur
nchis, fapt care potrivit teoremei enunate confirm ne-serializabilitatea planificrii propuse.

S-ar putea să vă placă și