Protectia datelor
Un mediu eficient de baze de date cere mai mult decat un model de date logice valid din punct de vedere semantic si o implementare eficienta de baze de date fizice: baza de date trebuie de asemenea, sa fie disponibila utilizatorilor atunci cand ei au nevoie de ea; trebuie oferit un anume nivel de partajabilitate; accesul neautorizat trebuie prevenit. Acest capitol prezinta cele trei principii de baza pentru aceste servicii: refacerea, controlul concurential (controlul accesului partajat) si securitatea.
1. Conceptul de tranzactie.
Protectia datelor are ca obiectiv primar o inalta calitate a mediului de baze de date. Regulile de calitate pentru o baza de date pot include instructiuni ca: "A este intotdeuna egal cu B", "NUMAR_DEPARTAMENT trebuie luat din multimea ", "Daca COD_JOB este mai mare decat COD_RECLASIFICARE, atunci ELIGIBIL trebuie sa fie mai mic decat COMPENSARE", "Suma salariilor ANGAJATI_DEPARTAMENT nu poate depasi BUGET_SALARII_ DEPARTAMENT", etc. Este de dorit ca toti utilizatorii (persoane fizice sau programe) sa aiba vederi consistente asupra bazelor de date la orice moment. Aceasta este insa imposibil, daca consistenta este definita in reguli individuale, precum au fost cele de mai sus. Sa consideram, de exemplu, asertiunea "A este intotdeuna egal cu B". Daca un utilizator doreste sa adauge 2 atat lui A, cat si lui B, va exista o perioada de timp in care A va fi deja actualizat si B inca nu (sau invers). Adica, cele doua actiuni nu pot avea loc simultan, cu exceptia procesoarelor multiple si sincronizate. Daca consideram starea initiala consistenta (de ex.: A = B = 10), in momentul in care vom avea A = 12 si B = 10, datele vor fi inconsistente ele nesatisfacand restrictia. Consistenta nu poate fi impusa dupa fiecare actiune individuala si, in loc de aceasta, o serie de actiuni va fi verificata pentru pastrarea consistentei. Fiecare serie de actiuni de acest tip duce datele dintr-o stare consistenta intr-o stare temporara posibil inconsistenta si apoi intr-o stare consistenta. O astfel de serie de actiuni se numeste tranzactie, sau uneori, unitate logica de lucru. O tranzactie are urmatoarele proprietati:
se conformeaza regulilor de consistenta a bazei de date. Ea se lanseaza cu baza de date intr-o stare consistenta si actiunile ei se conformeaza regulilor de consistenta ale sistemului. Astfel, starea consistenta initiala este transformata intr-o noua stare consistenta.
se executa in intregime sau de loc. Ori toate rezultatele sale sunt inregistrate si tranzactia se spune ca s-a savarsit (sau s-a comis, in engleza "to commit") sau nici unul din efectele tranzactiei nu se pastreaza si tranzactie este abortata.
odata ce tranzactia este savarsita, ea nu poate fi anulata. Efectele unei tranzactii pot fi alterate numai prin executia unei alte tranzactii.
O tranzactie se incheie cu unul din doua rezultate: savarsire sau abortare. Fie s-a terminat cu succes sau nu a avut nici un efect asupra bazei de date. O tranzactie care se presupune a actualiza 25 de inregistrari nu se poate termina cu actualizarea a doar 12. O tranzactie savarsita este garantat completa si are efectele memorate in baza de date. Utilizatorul trebuie sa specifice marginile tranzactie. De exemplu, numai utilizatorul poate determina daca toate cele 25 de inregistrari trebuie actualizate impreuna. Daca actualizarile se pot face separat, atunci se pot specifica 25 de tranzactii separate. Majoritatea limbajelor de baze de date au comenzile BEGIN TRANSACTION si END TRANSACTION sau echivalente. Daca aceste margini nu sunt specificate, atunci ele se presupun a fi inceputul si sfarsitul unitatii de executie al programului.
Tranzactiile sunt unitati de baza pentru refacerea si controlul concurential al bazei de date. Refacerea asigura ca nici o tranzactie nu este lasata partial efectuata. Accesul partajat controleaza faptul ca tranzactiile nu interfereaza intre ele.
2. Necesitatea refacerii bazei de date.
Obiectivul refacerii bazei de date este de a face fata la esecuri sau la comportari nespecifice ale unui sistem. Esecurile pot avea multe cauze si efectul lor consta in a introduce erori in sistem, si posibil, in a face sistemul inaccesibil. Pentru a face fata la esecuri, un DBMS trebuie sa fie capabil sa sa detecteze si sa corecteze erorile. Ideal, un DBMS ar trebui sa notifice utilizatorii care au accesat date eronate in timpul dintre aparitia erorii si remedierea ei. De fapt, acesta este un serviciu foarte greu de oferit.
Procesul de corectare a erorilor datorate esecurilor se numeste refacere (recovery) si obiectivul lui este de a restaura baza de date intr-o stare acceptabila pentru utilizatori. Aici, statutul de "acceptabil" este judecat prin corectitudinea si consistenta continutului datelor.
O tehnica de refacere suporta refacerea din anumite tipuri de esecuri. Un sistem de gestiune a bazelor de date poate oferi o sumedenie de tehnici de refacere, fiecare adresand un anumit tip de esec.
Tipuri de esecuri. Tipurile de esecuri posibile intr-un sistem baze de date includ urmatoarele:
esec de mediu: de exemplu, cadere de tensiune, terminarea sistemului de operare datorita erorilor, oprirea sistemului ca urmare a actiunii operatorului.
esec software: de exemplu, terminarea falsificata a DBMS-ului, distrugerea DBMS-ului.
esec program: de exemplu, terminarea datorata depasirii timpului de executie sau a limitelor de spatiu.
esec in logica programului: de exemplu, actualizarea incorecta a bazei de date datorata erorilor de programare sau de validare a datelor.
esec de aparat fizic: de exemplu, defect capete de disc, fisiere necitibile pe disc.
Cele mai insinuoase din aceste probleme sunt esecurile din logica programului, deoarece ele sunt dificil de detectat. De exemplu, poate dura saptamani sau luni pentru a descoperi ca logica incorecta de validare date a permis ca date eronate sa fie introduse intr-o baza de date. Este usor sa determinam ca o eroare a aparut daca sistemul s-a oprit, daca a aparut un cod de eroare sistem sau daca un disc este defect, dar este mult mai greu sa gasim ca date eronate au fost scrise in baza de date datorita unui esec in logica programului. Unele din simptomele datelor gresite sunt:
informatii inconsistente in rapoarte.
intrebari de la utilizatori.
intrebari de la auditorii sistemului.
esec al altor programe sau tranzactii care acced baza de date.
Legarea acestor simptome de cauza precisa a datelor eronate este uzual imposibila. Cine stie de ce un debit dintr-un anume contul a fost prelucrat de doua ori? Cine stie de ce un loc preferat din avion este inregistrat gresit in fisierul agentiei de vioaj? Refacerea din aceste situatii nu este realizata automat de catre DBMS, se cere ca utilizatorii sa realizeze tranzactiile corective pentru a inlocui valorile incorecte. Cea mai buna cale pentru a evita esecurile din logica programului este de a le preveni, folosind tehnici de dezvoltare de programe care ajuta la asigurarea corectitudinii programelor. Alte tipuri de erori sunt mai usor de detectat si de corectat. In cazul cel mai nefavorabil, ele fac ca baza de date sa fie complet necitibila sau inaccesibila. Ele pot de asemenea cauza ca refacerea datelor sa fie neutilizabila si pot da seturi incomplete de modificari baze de date, cauzate de terminarea prematura a executiei programului. Tipic, ele pot fi manuite de tehnici de refacere mai mult sau mai putin automate. Motto: "As far as we know, our computer never had an undetected error".
Esecuri in medii distribuite. Exista multe posibilitati de esecuri pentru baze de date intr-un mediu distribuit, din cauza complexitatii crescute a serviciilor sistemului de operare distribuit si a serviciilor DBMS-ului distribuit. Cand aceste elemente sunt sigure, potentialul de esec este aproximativ acelasi ca si intr-un mediu centralizat. De fapt, impactul de esec intr-un mediu distribuit poate fi chiar mai mic decat intr-un mediu centralizat. Daca un calculator din retea se opreste, atunci, uzual, celelalte vor continua sa functioneze. O parte din baza de date poate deveni inaccesibila sau poate fi vatamata, fara ca restul datelor distribuite sa fie afectate. Redundanta componentelor (calculatoare, DBMS-uri, sisteme de operare, baze de date) inerenta intr-un mediu distribuit face ca sistemul sa fie "permisiv la esec" (failsoft): esecul unei componente poate micsora performanta sistemului, nu il va face sa se opreasca.
3. Tehnici de refacere.
O tehnica de refacere mentine date de refacere pentru a restaura baza de date. Aceste date de refacere inregistreaza continutul si modificarile bazei de date, astfel incat tranzactiile pot, mai tarziu, fi refacute (redo) sau nefacute (undo). Diferite tehnici de refacere mentin diferite tipuri de date de refacere si sunt eficiente numai daca datele lor de refacere nu au fost si ele contaminate sau distruse de catre esec.
Date de refacere. Exista mai multe tipuri de date de refacere, incluzandu-le pe urmatoarele:
inregistrare tranzactie: o copie a tranzactiilor de actualizare a bazei de date, in secventa in care ele apar, uzual cu ora la care apar si cu notatii despre sarcina pe care o realizeaza.
imagine, inainte de: o copie a unei portiuni a bazei de date, inainte de prelucrarea uneia sau mai multor actualizari ale acelei portiuni.
imagine, dupa ce: o copie a unei portiuni a bazei de date, dupa prelucrarea uneia sau mai multor actualizari ale acelei portiuni.
copia de checkpoint (copia de salvare): o copie completa a unei baze de date pe un mediu de arhivare, de exemplu banda magnetica.
urma de revizie (audit trail): o inregistrare a actiunilor de actualizare cat si de regasire pentru a permite examinarea viitoare si verificarea activitatii bazei de date.
Nu orice DBMS mentine toate aceste tipuri de date de revizie. Ce date de refacere se mentin se determina de catre tehnica de refacere pe care o foloseste DBMS-ul. Fisierul in care se scriu imaginil inainte de sau imaginile dupa ce se numeste log file sau jurnal. Inregistrarile tranzactie pot fi de asemenea inregistrate in jurnal.
Tehnici de refacere UNDO si REDO. Tehnicile de refacere de baza sunt UNDO si REDO. Sa consideram situatia din fig.1.
O copie de checkpoint a bazei de date a fost facuta la un moment T1 si la momentul T2 a aparut un esec, facand ca tranzactia sa fie prelucrata impropriu. La momentul T3 esecul a fost depistat. O tehnica de refacere este UNDO (numita si backout sau rollback) adica de "a nu face" actiunile care s-au prelucrat impropriu. Obiectivul este de a reface baza de date in starea dinaintea punctului de esec.
|
|
Fig.1. Intarziere intre aparitia si detectarea esecului.
Aceasta tehnica se bazeaza pe disponibilitatea datelor de refacere imagine inainte de. Procesul UNDO inlocuieste portiuni din baza de date cu imaginile lor "inainte de", corespunzatoare, in ordinea inversa in care imaginile inainte de au fost scrise (fig.2.)
Sa presupunem ca au existat trei tranzactii legate de SALARIU inainte de T2 si T3:
timpul T2 + a: SALARIU = SALARIU + 5000.
timpul T2 + a + b: SALARIU = SALARIU *1.05.
timpul T2 + a + b + c: SALARIU = SALARIU - 100.
Daca valoarea lui SALARIU la momentul T2 a fost 40000, atunci imaginile inainte de au fost inregistrare astfel:
timpul T2 + a: SALARIU = 40000.
timpul T2 + a + b: SALARIU = 45000.
timpul T2 + a + b + c: SALARIU = 47250.
La timpul T3, SALARIU = 47150 si secventa UNDO va fi:
SALARIU = 47250.
SALARIU = 45000.
SALARIU = 40000.
Rezultatul va fi refacerea SALARIU-lui la valoarea sa de la momentul T2. Sa notam ca imaginile inainte de dintr-un fisier log contin, tipic valori din mai multe campuri diferite de date din mai multe inregistrari. Intr-un mediu multitasking, imaginile inainte de pentru actualizari dintr-un task se pot intrepatrunde cu imaginile din alt task.
|
Bd cu erori |
||||||||||||||||||||||
Fig.2. Procesul UNDO, folosind date de refacere imagine inainte de.
|
Copie Ceckpoint Bd cu erori |
|||||||||||||||||||||||||||||||||||||||||||
Fig.3. Procesul REDO, cu reprelucrarea tranzactiilor.
Decat sa se mute inapoi in timp, de la baza de date curenta la starea ei de mai de vreme, procesul REDO se muta inainte in timp, de la o copie checkpoint a bazei de date. Procesul REDO poate apare in una din modalitatile:
Reprelucrarea tranzactiilor folosind copia de checkpoint a bazei de date si omitand orice tranzactie care ar fi putut cauza esecul (fig.3.).
REDO se bazeaza pe disponibilitatea fie a tranzactiilor fie a imaginilor dupa, plus o copie checkpoint a bazei de date.
|
Copie Ceckpoint Bd cu erori Timp Date de refacere imagine dupa Bd fara erori |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.4. Procesul REDO, folosind date de refacere imagine dupa.
Sa presupunem ca tranzactiile relative la SALARIU intre timpii T1 si T2 au fost:
timpul T1 + a: SALARIU = SALARIU *1.10.
timpul T1 + a + b: SALARIU = SALARIU + 500.
si ca SALARIU = 35910 la momentul T1.
Incepand cu momentul T1, imaginile dupa ce au putut fi inregistrate astfel:
timpul T1 + a: SALARIU = 39500.
timpul T1 + a + b: SALARIU = 40000.
Copia checkpoint la momentul T1 arata SALARIU = 35910 si secventa REDO va fi:
SALARIU = 39500.
SALARIU = 40000.
Acestea aduc baza de date inapoi in starea ei de la momentul T2.
Diferenta dintre REDO cu tranzactii si REDO cu imagini dupa ce este aceea ca prima varianta cere ca tranzactiile sa fie reexecutate. REDO cu imagini dupa ce se aplica rezultatelor acestor tranzactii, fara a le mai reexecuta.
Care dintre cele doua tehnici de refacere, UNDO sau REDO este mai potrivita depinde de urmatorii factori:
a) tipul de date de refacere disponibile: UNDO cere un fisier log cu imagini inainte de; REDO cu inlocuiri cere o copie checkpoint si un fisier log cu imagini dupa ce; REDO cu reprelucrare cere o copie checkpoint si un fisier log cu tranzactii.
b) momentul in care apare esecul: daca s-a efectuat un numar mic de tranzactii de la esec, UNDO cere mai putine prelucrari. Daca o eroare a aparut imediat dupa ce s-a facut ultima copie checkpoint si au avut loc totusi multe tranzactii in acest interval, atunci REDO cere mai putine prelucrari.
c) tipul de esec: anumit esecuri (de ex: esecurile de aparat fizic) pot afecta disponibilitatea datelor de refacere.
Ambele tehnici de refacere date, UNDO si REDO, trebuie sa respecte conceptul de tranzactie: efectele unei tranzactii nu pot fi partial refacute, indiferent daca se foloseste UNDO sau REDO. Refacerea trebuie sa lase efectele tranzactiei fie complet realizate, fie complet nerealizate. Un alt nume pentru tranzactie este unitate de refacere; un DBMS nu are voie sa efectueze refaceri in unitati de tranzactii partiale.
De exemplu, daca urmatoarele doua actiuni au fost parti ale aceleasi tranzactii:
SALARIU = SALARIU + 500.
SALARIU = SALARIU * 1.
atunci punctul in care baza de date a fost refacuta nu poate fi dupa una singura din operatiile de mai sus. Altfel baza de date va ramane intr-o stare inconsistenta sau va fi violata legea tranzactiei.
Secventa de evenimente in aplicarea unei tehnici de refacere UNDO unui program activ si folosind un fisier log pe banda magnetica (spooler) este urmatoarea:
Montati banda cu fisierul log.
Cititi fisirul log inainte pana cand intalniti EOF.
Descuiati fisierele din prelucrarea programului.
Cititi fisierul log inapoi, aplicand imaginile inainte de ale acestui program bazei de date.
Terminati refacerea atunci cand intalniti inregistrarea "start-log" a programului.
Restartati programul.
Secventa de evenimente cerute pentru restaurarea unei baze de date dupa o pierdere completa datorata unui esec de aparat fizic, folosind prelucrarea REDO cu imagini dupa ce, este urmatoarea:
Copiati ultima copie checkpoint, ca punct de plecare pentru baza de date restaurata.
Cititi fisierul log inainte, aplicand imaginile dupa bazei de date.
Restartati programul care a operat in punctul de esec, sau continuati prelucrarea, daca nici un program nu a operat.
Alte tehnici de refacere. UNDO si REDO sunt cele mai folosite tehnici de refacere. Pe lange ele mai exista insa si altele. Cand toate tehnicile de refacere esueaza, se poate folosi un program de salvare. Acest program proiectat special scaneaza baza de date dupa esec pentru a stabili daunele si a restaura a stare valida, salvand datele care mai sunt recunoscute. El nu foloseste date de refacere.
O alta tehnica de refacere consta in a pastra mai multe de o copie pentru fiecare fisier al bazei de date. Diferitele copii sunt identice, cu exceptia procesului de actualizare. Actualizarile pot fi expediate tuturor copiilor, care vor fi consistente atunci cand actualizarile se termina. Alternativ, o copie este activa si celelalte sunt de referinta. Actualizarile se efectueaza pe copia activa si intr-un moment ulterior, pe copiile de referinta.
Tehnici de refacere pentru medii distribuite. O dificultate in oferirea protectiei la esecuri pentru baze de date distribuite este coordonarea datelor de refacere si detectarea esecului intre procesoare. Daca o tranzactie trebuie sa fie nefacuta (UNDO) problema este ca actiunile ei au putut implica prelucrari la mai multe calculatoare, prin multe DBMS-uri, fiecare cu propriile date de refacere. Coordonarea devine, in special, dificila atunci cand tranzactiile sunt refacute afectand mai multe baze de date cu intervale de checkpoint diferite.
O alta dificultate prezenta intr-un mediu distribuit apare in legatura cu procesoarele care sunt scoase temporar din retea alaturi de portiuni ale unor baze de date. Scoaterea lor din retea se poate datora unor esecuri, unor operatii de intretinere sau altor motive.
Exista mai multe cai pentru a colecta actualizarile si a le aplica atunci cand procesoarele reintra in retea. O problema de coordonare apare din cauza esecurilor aditionale din perioada in care procesorul a fost nedisponibil, atunci cand actualizarile trebuie aplicate.
Bazele de date distribuite pot avea o parte sau toata redundanta lor memorata in retea. Daca o copie este inaccesibila din cauza unui esec, atunci poate fi folosita o alta copie. Atunci cand apar esecuri, cererile utilizatorilor pot fi directionate automat spre copia de salvare potrivita. O implicatie deosebita o constituie necesitatea unui dictionar de date distribuit de a lungul retelei, care furnizeaza locatiile datelor, statutul de copie primara sau secundara a datelor, starea datelor (ex: inaccesibile, accesibile noncurente, accesibile si curente). Nu toate cererile trebuie sa fie servite cu cea mai curenta versiune de date accesibile redundante. De exemplu, fie, balanta de conturi o data memorata redundant: o copie aflata la client si una la banca. Au copiile intotdeuna acelasi continut? Care este copia primara? Care copie se actualizeaza de catre client? Care copie se actualizeaza de catre banca? Cum se determina balanta daca se pierde o copie?
4. Stabilirea unei politici de refacere.
Tehnicile de refacere trebuie sa fie stabilite pentru medii individuale; nu exista o abordare generala care poate fi folosita pentru toate situatiile. Echipa de administrare date trebuie sa monitorizeze continuu politica de refacere a mediului si sa o potriveasca pentru a satisface nevoile. Politica de refacere a unui mediu poate decide:
I. Tehnicile de refacere care vor asigura protectia fata de oricare tip de esec.
II. Datele de refacere care sunt cerute pentru a suporta aceste tehnici.
III. Procedurile pe care le vor executa tehnicile de refacere.
Pentru a determina cerintele politicii de refacere trebuie sa se raspunda la intrebarile ca urmatoarele:
Cat de mult timp mort poate fi tolerat?
Cat de mult timp de refacere poate fi tolerat?
Ce tipuri de medii sunt disponibile pentru a memora datele de refacere?
Ce restrictii sunt impuse de catre sistemul de operare?
Cat de multa interventie operator poate fi tolerata?
Cat de mult se consuma din timpul sistemului cu refacerea?
Ce volum de costuri suplimentare e rezonabil sa folosim?
Cat din procesul de refacere se face automat si cat manual?
Care este responsabilitatea administratorului de date in localizarea tranzactiilor eronate, si in identificarea esecurilor din logica programelor?
Decizii de proiectare. Tehnicile de refacere folosite cu o baza de date particulara sunt decise de catre DBMS. Arareori, administratorii de date maresc aceste servicii cu tehnici aditionale.
Tipic, DBMS-ul suporta ambele tehnici REDO si UNDO, iar administratorul de date potriveste aceste tehnici pe mediul local si la cerintele locale. De exemplu, administratorul de date poate decide:
Cat de des sa se faca copiile de checkpoint? (saptamanal, zilnic, inainte de a executa sistemele majore, dupa aceea, la inceputul fiecarui proces).
Cat de des sa se faca imaginile inainte de si dupa ce? (inainte si dupa fiecare program, inainte si dupa fiecare tranzactie, inainte si dupa fiecare actualizare a bazei de date).
Cat este de mare portiunea din baza de date care se copiaza in imaginile inainte de si dupa ce?`(o pagina intreaga, o inregistrare, un camp).
Atat intretinerea unui fisier jurnal cat si crearea copiilor de checkpoint concureaza pentru resursele sistemului cu prelucrarea tranzactiilor. Ele introduc costuri suplimentare (regie). Datele de refacere trebuie sa fie scrise, gestionate si accesate. Utilizatorul resimte beneficiile acestor costuri doar indirect, prin abilitatea de refacere dupa esecuri si ideal, nici nu trebuie informat despre aparitia esecului.
5. Probleme si amenintari ale concurentei bazei de date.
Unul din obiectivele unui mediu baze de date este de a permite utilizatorilor sa acceada concurent date partajabile. Accesul concurent este relativ usor de suportat de catre un DBMS daca toate accesele sunt regasiri. Daca insa cel putin un utilizator face actualizari, atunci pot exista interferente, care dau situatii de inconsistenta.
Cele trei tipuri de inconsistente care pot fi evitate sunt actualizari pierdute, actualizari presupuse si citiri fantoma.
Actualizari pierdute. Un exemplu de actualizare pierduta este prezentat in fig.5. Tranzactia 1 intentioneaza sa adauge 5 la valoarea lui A, iar tranzactia 2 intentioneaza sa inmulteasca valoarea lui A cu 2. Sa presupunem ca valoarea lui la A momentul T0 este 10. Tranzactia 1 actualizeaza copia sa de lucru a lui A si memoreaza 15 in baza de date. In acelasi timp, tranzactia 2 isi actualizeaza copia de lucru a lui a si memoreaza 20 in baza de date. Efectul este pierderea actualizarii efectuate de tranzactia 1. Pierderea ar putea fi evitata daca tranzactia 2 nu ar citi valoarea lui A pana cand actualizarea din tranzactia 1 nu s-a incheiat.
|
T0 T1 T2 T3 T4 T5 Timp Valoare A |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.5. Exemplu de actualizare pierduta.
Actualizari presupuse. Un exemplu de actualizare presupusa incorect este prezentat in fig.6.
|
Timp Undo Ga-seste pe A Tranzactie2 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.6. Exemplu de actualizare presupusa.
Folosind aceleasi exemple, tranzactiile 1 si 2 se executa serial, cu actiunea tranzactiei 1 nefacuta (UNDO) pentru refacerea unui esec.
Efectul este presupunerea tranzactiei 1 ca fiind terminata cu succes. Problema poate fi evitata daca tranzactia 2 nu citeste valoarea lui A decat dupa ce s-a decis daca sa se comita efectele tranzactiei 1 sau nu.
Citiri fantoma. O citire fantoma apare in exemplul din fig.7. Tranzactia 4 este definita de urmatoarea secventa:
if POLICY exista
then DEDUCTIE = 1
else DEDUCTIE = 0
iar tranzactia 5 este definita de:
if POLICY nu exista
then do creaza POLICY
DEDUCTIE = 1
Executia tranzactiilor lasa baza de date intr-o stare inconsistenta, in care POLICY exista si DEDUCTIE = 0. Presupunand ca POLICY nu exista initial, atunci rezultatele consistente permise sunt:
POLICY exista si DEDUCTIE = 1 (Tranzactia 4, apoi 5).
POLICY nu exista si DEDUCTIE = 0 (Tranzactia 5, apoi 4)
Problema este ca exista doua stari definite pentru POLICY in timpul executiei tranzactiei 4, chiar daca ea nu actualizeaza POLICY. Problema poate fi evitata daca tranzactia 5 nu actualizeaza POLICY pana cand tranzactia 4 nu isi termina secventa sa de actiuni dependente de nonexistenta lui POLICY. Tranzactia 4 trebuie sa fie in stare sa incuie nonexistenta (fantoma) POLICY.
|
Policy 0 |
0 |
||||||||||||||||||||||||||||||||||||||||||||||||||
0
1
|
Actualizeaza deductie=1 |
|
Tranzactie5 |
Fig.7. Exemplu de citire fantoma.
6. Tehnici de control al concurentei.
Mai multe tehnici si concepte pot impreuna, sa controleze accesul concurent la date partajate. Aici se includ:
Executie serializabila.
Administrarea incuierilor.
Protocolul de incuiere in doua faze.
Timpi morti (deadlock).
stampilarea (timestamping).
Tehnicile optimiste.
Protocolul de comitere in doua faze.
Executie serializabila. Atunci cand tranzactiile se executa serial, toate actiunile unei tranzactii sunt realizate si de abia apoi se trece la realizarea actiunilor altei tranzactii. Astfel se elimina concurenta. Aceasta se numeste executie seriala. Atunci cand se executa serial, tranzactiile nu pot interfera intre ele, numai una fiind activa la un moment dat.
Atunci cand exista cereri de acces la baza de date concurente, ele in mod uzual nu se executa serial. DBMS-ul care deserveste mai multe programe, realizeaza una sau mai multe actiuni pentru un program, apoi una sau mai multe actiuni pentru alt program, etc. pana cand toate programele a fost deservite. Apoi se reia de la primul program. Exmplele din fig.5. - 7. sunt astfel de tranzactii intrepatrunse.
O executie de tranzactii intrepatrunse se spune a fi serializabila daca ea da acelasi rezultat ca si o executie seriala oarecare a acelorasi tranzactii. Serializabilitatea este in general acceptata ca un criteriu formal de consistenta. Daca un DBMS genereaza numai executii serializabile, atunci el garanteaza consistenta. Tranzactiile concurente serializabile asupra datelor partajate nu pot interfera.
Serializabilitatea nu implica faptul ca exista un singur set de valori rezultat corecte. Un grup de n tranzactii are n! executii seriale posibile, fiecare dand un set de rezultate propriu. Deoarece serializabilitatea cere numai potrivirea rezultatelor cu o executie seriala oarecare, exista n! seturi posibile de rezultate corecte. Sa consideram doua tranzactii: tranzactia 1 mareste salariul tuturor angajatilor cu 10%, iar tranzactia 2 calculeaza salariul mediu. Exista doua executii seriale ale acestor doua tranzactii, fiecare dand un rezultat diferit, dar consistent. Un rezultat inconsistent ar fi obtinut daca calculul salariului mediu s-ar efectua dupa ce doar salariul ar fi marit doar la o parte a angajatilor. Daca actiunile tranzactiei 1 s-au terminat inainte ca actiunile tranzactiei 2 sa inceapa, atunci intregul set de actiuni poate fi o singura tranzactie.
Este in general de dorit ca actiunile interdependente sa fie grupate intr-o tranzactie. Daca ordinea de executie este semnificativa, exista doua modalitati de grupare a celor doua tranzactii intr-una singura.
Fig.8. este un exemplu de planificare seriala, in care tranzactia 7 se executa dupa ce s-a terminat tranzactia 6. Tranzactia 6 adauga 5 atat lui A cat si lui B, iar tranzactia 7 ii inmulteste si pe A si pe B cu 2. Ambele tranzactii se conformeaza asertiunii de integritate "A = B". Ca atare fiecare tranzactie are doua actiuni ce trebuiesc executate ca o singura unitate de refacere. Inainte de executia tranzactiilor A = B = 10. Dupa executia tranzactiei 6, A = B = 15, iar dupa executia tranzactiei 7, A = B = 30. Restrictiile de consistenta sunt inalnite inainte si dupa fiecare tranzactie.
|
T0 T1 T2 T3 T4 Valoarea lui A Valoarea lui B Tranzactie6 A=A+5 B=B+5 Tranzactie7 A=A*2 B=B*2 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.8. Exemplu de executie seriala a doua tranzactii.
Fig.9. este o executie serializabila a tranzactiilor 6 si 7, dar ea nu este o executie seriala, caci actiunile tranzactiilor 6 si 7 se intrepatrund. Totusi, rezultatul este acelasi ca si in cazul executiei seriale. Astfel, rezultatul este consistent.
|
A=A+5 B=B+5 Tranzactie6 Tranzactie7 B=B*2 A=A*2 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.9. Exemplu de executie serializabila a doua tranzactii.
Fig.10. prezinta o executie neserializabila a tranzactiilor 6 si 7. Ca si in exemplul din fig.9., actiunile tranzactiilor 6 si 7 se intrepatrund. Spre deosebire de exemplul din fig.9., rezultatul nu este acelasi ca si in cazul executiei seriale si nu este un rezultat consistent. A = 30 si B = 25. Asertiunea "A = B" a fost violata.
|
Valoarea lui A Valoarea lui B A=A+5 B=B+5 Tranzactie6 Tranzactie7 B=B*2 A=A*2 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.10. Exemplu de executie neserializabila a doua tranzactii.
Incuieri (locking). Abordarea cea mai comuna pentru a garanta executia serializabila este o tehnica numita incuiere. In forma sa cea mai simpla, incuierea unei parti a unei baze de date previne citirea sau scrierea ei de catre orice alte tranzactii decat cea care a obtinut incuierea. La terminarea acestei tranzactii incuierea este eliberata. In continuare ne vom referi la "o portiune a bazei de date" prin "resursa de baza de date".
Un DBMS poate administra incuierile prin:
setarea unui bit intr-un camp, inregistrare, pagina sau fisier al bazei de date, indicand ca acea resursa este incuiata.
pastrarea unei liste cu resursele bazei de date care sunt incuiate.
pastrarea resurselor incuiate ale bazei de date intr-o arie speciala de memorie.
Exista incuieri exclusive care permit numai celui care a facut incuierea sa aiba acces la resursa baza de date incuiata si incuieri partajate, care permit mai multor utilizatori sa acceada resursa baza de date incuiata.
Anumite DBMS-uri suporta numai incuieri exclusive si, in aceste sisteme, o resursa baza de date este fie incuiata, fie libera.
O tranzactie sau un program poate cere o incuiere:
specificand incuierea in conjunctie cu o instructiune de manipulare de date, de ex: UPDATE EMP_REC WITH EXCLUSIVE LOCK SET SALAR = SALAR * 1.10. Acest tip de cerere de incuiere este facut adesea implicit. O cerere de actualizare poate cere implicit o incuiere exclusiva pe datele care se vor modifica.
specificand incuierea in conjunctie cu o comanda de incepere a tranzactiei, de ex: BEGIN TRANSACTION WITH EXCLUSIVE LOCK sau BEGIN TRANSACTION WITH SHARED LOCK.
specificand incuierea in conjunctie cu deschiderea unui fisier baza de date, de ex: OPEN EMP_DATABASE FOR EXCLUSIVE UPDATE sau OPEN EMP_DATABASE FOR SHARED READ.
Cererile de incuieri a unei resurse baza de date sunt compatibile daca pot fi satisfacute impreuna (fig.11.). O cerere pentru o incuiere exclusiva nu este compatibila cu nici o alta cerere pe aceasi resursa. O cerere pentru o incuiere partajata este compatibila cu o alte cereri de incuiere partajata dar este incompatibila cu o cerere de incuiere exclusiva.
|
Partajata |
Exclusiva |
|
|
Partajata |
DA |
NU |
|
Exclusiva |
NU |
NU |
Fig.11. Matrice de compatibilitate pentru tipuri de incuieri de baza.
Exista cinci principii de control concurential prin incuiere, care impreuna, evita inconsistentele discutate mai inainte. Primul principiu de control concurential este
1. Nici o tranzactie nu poate actualiza o resursa baza de date fara a dobandi inainte o incuiere care previne ca alte tranzactii sa actualizeze de asemenea resursa.
O incuiere exclusiva poate fi ceruta de catre o tranzactie care intentioneaza sa citeasca sau sa actualizeze o resursa baza de date. Nici o alta tranzactie nu poate sa castige accesul la acea resursa de date atat timp cat incuierea are loc. Incuierile partajate pot fi cerute de mai multe tranzactii, toate intentionand sa acceada o resursa specifica. Pentru a preveni inconsistenta, numai una din aceste tranzactii poate face actualizari, celelalte pot numai citi resursa baza de date incuiata.
2. Daca o incuiere nu poate fi obtinuta atunci cand este ceruta, tranzactia care o cere trebuie sa astepte.
Exista situatii in care o tranzactie cere o incuiere pe o resursa asupra careia o alta tranzactie are deja drepturi exclusive. A doua tranzactie trebuie sa astepte pana cand incuierea exclusiva este eliberata. A doua tranzactie se spune a fi blocata. Ea nu poate sa-si inceapa prelucrarea pana cand nu obtine incuierea ceruta. Incuierile partajate si exclusive administrate sub aceste doua principii previn actualizarile pierdute. Doua tranzactii nu-si pot avea actiunile intrepatrunse daca ambele actualizeaza aceasi resursa baza de date.
3. Dupa eliberarea unei incuieri, o tranzactie nu poate obtine o alta incuiere.
Orice tranzactie care elibereaza o incuiere si incearca apoi sa seteze o alta incuiere poate produce rezultate inconsistente. Situatiile din fig.5. Si 10. pot rezulta ambele din cererea de incuieri dupa eliberarea altor incuieri.
Orice tranzactie care satisface principiile 1. si 3. se spune a fi in doua faze, iar principiile 1. si 3. formeaza protocolul de incuiere in doua faze. Prima faza este faza de crestere, in care se obtin incuierile, iar faza a doua este faza de contractie, in care incuierile sunt eliberate.
4. Schimbarile necomise trebui sa ramana incuiate pana cand tranzactia se termina.
Acest principiu asigura protectia fata de problema actualizarilor presupuse. O tranzactie nu-si poate elibera incuierea sa de actualizare de date pana cand aceste actualizari nu au fost comise, si odata ce au fost comise acestea nu mai pot fi nefacute (UNDO). Principiile de pana aici nu previn insa citirile fantoma, caci date non-existente nu pot fi incuiate.
5. Pentru protejarea la citirile fantoma, trebuie obtinute incuieri exclusive inainte de a determina daca resursa exista.
Incuierile administrate conform acestor cinci principii vor evita problemele de actualizari pierdute si presupuse, precum si citirile fantoma.
Deadlock. Numim "deadlock" o situatie in care doua (sau mai multe) tranzactii sunt blocate in asteptarea eliberarii de resurse pe care si le ocupa reciproc. Nici una nu poate continua prelucrarea pana cand nu dobandeste o incuiere tinuta de cealalta. Fig.12a. ilustreaza o situatie deadlock.
Tranzactia 8 tine o incuiere pe date SALARIU si este blocata in asteptarea eliberarii unei incuieri pe data JOB_PERFORMANCE. In acelasi timp, tranzactia 9 tine o incuiere pe data JOB_PERFORMANCE si este blocata in asteptarea eliberarii unei incuieri pe data SALARIU.
Fig.12b. prezinta aceasta situatie folosind un graf de cereri de resurse. Fiecare nod este o tranzactie si fiecare arc orientat indica ca o tranzactie este blocata asteptand dupa o resursa care este incuiata de o alta tranzactie.
|
Tranzactia 8 Controlorul de incuieri Tranzactia 9 Cerere incuiere pe Job_performance Acordare incuiere Cerere incuiere pe Job_performance Wait Cerere incuiere pe Salariu Wait |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Fig.12a. Exemplu de secventa de cereri care conduc la deadlock.
|
|
Fig.12b. Graf de cereri de resurse prezentand un deadlock.
Deadlock-ul este detectat gasind cicluri in graful de cereri de resurse. Un DBMS mentine, de obicei, o lista de tranzactii cu tipuri de incuieri pe care le tin si resursele baza de date aferente, precum si o lista cu tranzactiile ce sunt blocate asteptand, de asemenea cu tipul de incuiere solicitata si resursa aferenta. Aceste liste, care reprezinta grafuri de cereri de resurse, pot fi analizate pentru a gasi situatiile de deadlock. Intr-un mediu baze de date cu multe tranzactii, verificarea continua a deadlock-urilor poate fi costisitoare. Pot exista si alte motive pentru care o tranzactie poate intra intr-o stare de asteptare, de exemplu asteptand activitate la un terminal, acces la imprimanta, sau asteptand un operator sa monteze o banda sau un disc. Anumite DBMS-uri cauta situatiile de deadlock numai printre tranzactiile care au asteptat mai mult de un anumit timp.
Odata ce un deadlock a fost detectat, DBMS-ul trebuie sa-l rezolve. Tehnica cea mai comuna pentru rezolvarea deadlock-ului este un UNDO pe una din tranzactii. DBMS-ul selecteaza una din tranzactiile din deadlock, aplica imaginile inainte pentru a derula inapoi actiunile prelucrate, elibereaza incuirile tranzactiei si astfel permite unei alte tranzactii sa-si execute prelucrarile.
Aici, UNDO este exact acelasi proces ca si cel folosit pentru refacerea bazelor de date. Un al saselea principiu de control al concurentei prin incuieri poate fi acum introdus:
6. Actualizarile se scriu intotdeauna prima data in fisierul jurnal si apoi in baza de date.
Acest principiu face scrierea imaginilor inainte de si dupa ce intr-un fisier jurnal, parte a procesului de comitere si asigura ca datele de refacere vor fi disponibile daca un esec ar apare in timpul actualizarii bazei de date.
Exista mai multe modalitati de a preveni deadlock-ul, printre care:
a permite unei tranzactii sa incuie numai o resursa la un moment dat. Aceasta este acceptabil numai daca o incuiere poate asigura mari portiuni din baza de date si necesitatea de concurenta este mica.
a cere ca o tranzactie sa foloseasca numai o operatie indivizibila pentru a incuia toate resursele de care are nevoie; tranzactia nu poate pastra o incuiere daca nu le-a obtinut pe toate de care are nevoie. Aceasta nu este de obicei acceptabil deoarece resursele pe care o tranzactie le cere sunt determinate, in mod uzual, dinamic si nu pot fi prezise la inceputul tranzactiei.
Exista si alte tehnici pentru a evita deadlock-ul in accesarea resurselor controlate de catre sistemul de operare, dar, in mod uzual, ele nu sunt aplicabile la resursele baze de date. DBMS-ul trebuie sa fie pregatit sa detecteze deadlock-urile si sa le rezolve pe masura ce apar.
Timestamping. Metoda timestamping asigneaza fiecarei tranzactii un identificator unic, care poate fi gandit ca momentul de inceput al tranzactiei. El este referit ca "timestamp". Tipic, valoarea sa este generata de catre sistem pe baza ceasului sistemului. Intr-un mediu distribuit, numele gazdei este adaugat valorii de timp, facand timestamp-ul unic in retea. Intr-un sistem cu timestamping, conflictele apar fie atunci cand o tranzactie cere sa citeasca o inregistrare care a fost actualizata de catre o tranzactie mai tanara, fie cand o tranzactie cere sa actualizeze o inregistrare care a fost deja citita de o tranzactie mai tanara.
Conflictele se rezolva restartand tranzactia solicitanta. Tranzactiei mai tinere i se permite sa continue iar tranzactia solicitanta va primi un nou timestamp atunci cand este restartata. Nu exista incuieri si, deci nu poate apare deadlock. Pentru a preveni ca o tranzactie sa aiba actualizari necomise, nici o actualizare fizica nu poate fi scrisa in timpul comiterii. Restartarea tranzactiei nu cere niciodata rollback (UNDO) deoarece actualizarile nu au fost scrise fizic. Tehnica timestamp de baza consta in a compara valoarea timestamp a tranzactiei solicitante (apelante) fata de valorile timestamp ale ultimelor tranzactii care au accesat inregistrarea ceruta.
fie LAST_READ, timestamp-ul ultimei tranzactii care a citit cu succes inregistrarea.
fie LAST_COMMIT, timestamp-ul ultimei tranzactii care a actualizat cu succes inregistrarea.
fie MY_START_TIME, timestamp-ul tranzactiei solicitante.
Daca tranzactia solicitanta cere sa citeasca, atunci timestamp-ul ei va fi comparat cu LAST_COMMIT.
if LAST_COMMIT < MY_START_TIME
atunci tranzactiei solicitante i se permite sa continue
LAST_READ = MY_START_TIME
else tranzactia solicitanta este restartata.
Daca tranzactia solicitanta cere sa comita, atunci timestamp-ul ei va fi comparat cu celelalte doua:
if LAST_COMMIT < MY_START_TIME and LAST_READ < MY_START_TIME
atunci tranzactiei solicitante i se permite sa continue
LAST_COMMIT = MY_START_TIME
else tranzactia solicitanta este restartata.
Nici unei tranzactii apelante nu i se permite sa interfereze cu o tranzactie mai veche care deja a citit sau a actualizat inregistrarea. Au fost propuse multe variatii ale tehnicii de baza de timestamping.
Timestamping-ul, la fel ca si incuierile, sincronizeaza executia intrepatrunsa a unui set de tranzactii. Reamintim ca incuierile sincronizeaza tranzactiile astfel incat executia lor sa fie echivalenta cu o executie seriala oarecare. Pe de alta parte, timetsamping-ul sincronizeaza tranzactiile astfel incat executia lor sa fie echivalenta cu o executie seriala specifica. Aceasta este ordinea seriala cronologica a timestamp-urilor tranzactiilor.
Tehnici optimiste. Tehnicile de control concurential optimiste pornesc de la premisa ca in bazele de date cu multe inregistrari conflictele intre tranzactii sunt rare. Aceste tehnici elimina incuierile si urmeaza presupunerea optimista ca majoritatea incuierilor setate in sistemele conventionale nu sunt necesare.
Abordarea da baza consta in a nu restrictiona tranzactiile de citire insa a restrictiona sever tranzactiile de actualizare. Fiecare tranzactie are doua sau trei faze:
Faza de citire de la inceputul tranzactiei pana chiar inaintea comiterii sau a terminarii. Daca exista actualizari, acestea se vor face pe copii locale ale datelor.
Faza de validare, pentru tranzactiile de citire, sistemul va determina cand este corect si actual rezultatul citirii. Pentru tranzactiile de actualizare, sistemul verifica daca schimbarile facute nu vor cauza o pierdere a integritatii.
Faza de scriere: actualizarile locale se fac globale si sunt comise.
Fiecarei tranzactii i se asigneaza un numar atunci cand este terminata faza de citire. Pentru ca tranzactia apelanta sa treaca testul de validare, trebuie sa fie indeplinita una din conditiile urmatoare:
Toate celelalte tranzactii trebuie sa-si terminat fazele lor de scriere inainte ca tranzactia in cauza sa-si fi inceput faza de citire.
Tranzactiile mai vechi trebuie sa nu scrie aceleasi date pe care tranzactia in cauza le citeste si tranzactiile mai vechi trebuie sa termine faza de scriere inainte ca tranzactia in cauza sa inceapa faza de scriere.
Tranzactiile mai vechi trebuie sa nu scrie aceleasi date pe care tranzactia in cauza le citeste sau le scrie si tranzactiile mai vechi trebuie sa termine faza de citire inainte ca tranzactia in cauza sa inceapa faza de citire.
Tranzactii fac prelucrarile pe copii locale de date. Atunci cand sunt gata de comitere, sistemul aplica testele de validitate si determina unde a fost un conflict care poate introduce date eronate. Speranta este ca astfel de conflicte apar rar. Daca validarea esueaza, atunci tranzactia in cauza este salvata si restartata ca o noua tranzactie. Aceasta abordare evita regia de administrare a incuierilor si un deadlock nu poate sa apara. Costul este acela al salvarii, atunci cand apare un conflict.
Tehnici pentru medii distribuite. Controlul concuretial intr-un mediu baze de date distribuit este semnificativ mai dificil decat intr-un mediu baze de date centralizat. Principala problema este comunicarea informatiei de control, peste marginile bazei de date. Intr-un mediu distribuit de baze de date, o tranzactie poate include actiuni care sunt executate de mai multe procesoare, fiecare asupra unei portiuni a bazei de date. Daca se foloseste incuierea ca si tehnica de sincronizare, atunci o tranzactie poate tine incuieri pe multe procesoare. Detectarea deadlock-ului inseamna atunci detectarea ciclurilor de proces-blocat de-a lungul retelei de calculatoare. O abordare consta in a avea un manager de incuieri global (lock manager), care contabilizeaza procesele care sunt incuiate pe diferite masini.
O alta problema intr-un mediu distribuit este coordonarea comiterii tranzactiilor. O abordare este protocolul de comitere in doua faze. Inainte de a comite actualizarile tranzactiei, fiecare subtranzactie (care este prelucrata pe o singura masina sub controlul DBMS-ului) trebuie sa indice ca este gata sa comita. Pentru a fi gata de a comite, toate actiunile sale trebuie sa se fi terminat cu succes. Daca toate subtranzactiile indica faptul ca sunt gata sa se comita, atunci ele primesc ordinul sa se comita. Daca oricare subtranzactie indica faptul ca pentru un motiv oarecare nu se poate comite, atunci toate subtranzactiile sunt abortate. Nici una din schimbari nu este comisa.
Fig.13. ilustreaza protocolul de comitere in doua faze. Inainte de comitere, fiecare subtranzactie isi scrie schimbarile in jurnalul sau local. DBMS-ul distribuit cicleaza pentru "gata de comitere" si emite instructiuni pentru a indeplini sau nu comiterea. Protocolul de comitere in doua faze are, asadar, o faza in care subtranzactiile devin gata de comitere. Odata ce fiecare dintre ele a spus ca este gata de comitere, ele nu mai pot autoaborta. Ele trebuie sa fie pregatite pentru comitere atunci cand se da instructiunea de a o face. A doua faza este perioada pentru comitere efectiva sau de abortare. In timpul fazei de comitere se pot folosi numai zonele de memorare sigura si trebuie sa fie posibila inregistrarea actualizarilor, indiferent de esecurile ce apar pe plan local in timpul procesului de comitere. Sa notam ca protocolul de comitere in doua faze nu este acelasi lucru cu protocolul de incuiere in doua faze. Incuierea in doua faze se refera la regula ca o tranzactie nu poate obtine noi incuieri dupa ce le-a eliberat pe cele vechi; fiecare tranzactie are o faza crescatoare (achizitia de incuieri) si o faza de contractie (eliberarea de incuieri). Pe de alta parte, protocolul de comitere in doua faze guverneaza coordonarea procesoarelor implicate intr-o tranzactie intr-un mediu baze de date distribuit.
O alta abordare pentru a manui accesul concurential intr-un mediu distribuit de baze de date este de a segrega perioadele de acces numai pentru regasire de cele pentru actualizare.
De exemplu, tranzactiile distribuite de regasire pot fi servite toate ziua fara a interfera intre ele. Tranzactiile de actualizare pot fi prelucrate in mod batch noaptea. Aceasta abordare nu este potrivita pentru toate mediile dar poate fi folosita in multe cazuri. Anumite banci folosesc aceasta abordare de multi ani chiar si cu baze de date centralizate.
Exista, de asemenea, si alte metode pentru a reduce costurile suplimentare de gestionare a incuierilor in sisteme distribuite de baze de date. De exemplu, metodele optimiste de control concurential care se bazeaza pe aparitia rara a conflictelor. Nu exista incuieri in acest caz. O alta tehnica, numita analiza grafului de conflicte foloseste incuieri, dar numai cand o analiza a tranzactiilor arata ca ar putea fi interferente.
Oferirea controlului de acces partajat este una dintre cele mai dificile probleme ale implementarii sistemelor distribuite de baze de date si ea este in special dificila in DBMS-urile distribuite care construiesc un coordonator global pe facilitati de gestionare baze de date locale existente. De exemplu, un DBMS local trebuie sa poata indica "gata" de a comite o actualizare, unei tranzactii, dar comiterea actualizarii nu este permisa pana cand coordonatorul global nu da instructiunea de comitere.
|
|
Fig.13. Protocolul de comitere in doua faze.
7. Stabilirea unei politici de partajare.
Proiectantii unui sistem baze de date trebuie sa puna in balanta problema concurentei cu cea a consistentei. La o extrema se gaseste starea de concurenta totala: oricine poate accesa orice parte a resursei de date la orice moment, atat pentru a citi cat si pentru a modifica date. In majoritatea mediilor, din cauza inconsistentelor datele ar deveni in scurt timp de nefolosit. La cealalta extrema se gaseste consistenta totala fara concurenta: numai o tranzactie poate accesa baza de date la un moment dat. Aceasta fortare la executie seriala poate deveni dezastruoasa in operatii de productie. Alte posibilitati includ:
Acces numai in citire cu o mare concurenta in timpul zilei si actualizari realizate serial noaptea.
Partitionarea datelor astfel incat o tranzactie sa poata accesa o partitie la orice moment dat.
Balansarea concurentei cu consistenta inseamna stabilirea unei politici de partajare care ofera o concurenta suficienta la un nivel acceptabil de costuri suplimentare.
Politica de control a accesului partajat a unui mediu poate stabili tehnica de sincronizare a proceselor, astfel incat ele sa nu interfereze, precum si procedurile de monitorizare a controlului accesului partajat.
Trebuie sa se ia decizii legate de problemele care urmeaza, pentru a determina cerintele politicii de control al accesului partajat:
Ce nivel de consistenta este cerut?
Ce costuri suplimentare sunt necesare?
Care sunt cerintele de acces partajat pentru interogari ale bazei de date?
Care sunt cerintele de acces partajat pentru actualizari ale bazei de date?
Cat de predictibile sunt cerintele de date ale tranzactiilor?
Cat dureaza o tranzactie?
Ce tipuri de control al accesului partajat sunt oferite in medii de catre DBMS? Ce tipuri de incuieri sunt suportate? Cat de mult din resursa de date poate fi incuiat intr-o singura cerere?
Trebuie sa fie suportat accesul partajat pentru bazele de date distribuite?
Decizii de proiectare. Tehnicile de control al accesului partajat folosite cu un DBMS particular sunt decise in primul rand de catre DBMS. Rareori poate un administrator de date sa mareasca aceste servicii prin tehnici aditionale si deci nivelul suportului de acces partajat trebuie investigat atunci cand se alege un DBMS. Majoritatea DBMS-urilor suporta atat incuieri partajate cat si incuieri exclusive. Administratorul de date poate potrivi, de obicei, tehnicile de control al accesului partajat in urmatoarele domenii:
granularitatea incuierii: cat de mult din resursa de date poate fi incuiata intr-o cerere?`(un fisier, o pagina, o inregistrare, un camp)
tipuri de incuieri: ce tipuri de incuieri pot fi cerute? (partajate, partajate cu intentie de citire, partajate cu intentie de actualizare, exclusive cu intentie de citire, exclusive cu intentie de actualizare, altele)
granularitatea tranzactiei: poate o tranzactie sa contina mai multe actiuni? Poate un program sa contina mai multe tranzactii? Poate o tranzactie sa implice mai multe programe?
Incuierea fina, adica incuierea obiectelor mici din baza de date (inregistrari sau campuri) permite mai multa concurenta decat incuierea grosiera. Dar ea mareste, de asemenea, costurile suplimentare pentru tranzactiile care au nevoia de a accesa un lot de date si pune multe incuieri. Incuierea grosiera ofera un acces controlat, relativ ieftin la mari colectii de date.
Controlul accesului partajat devine mai important pe masura ce tot mai multi utilizatori depind de serviciile bazei de date. Administratorul de date trebuie atunci sa fie sigur de folosirea facilitatilor potrivite de control pentru a oferi un nivel suficient de acces partajat. De asemenea el trebuie sa fie garanteze protejarea calitatii datelor la un cost acceptabil de regie.
8. Securitatea datelor.
Obiectul securitatii bazei de date este de a preveni modificarea si dezvaluirea neautorizata a continutului bazei de date. Securitatea se gaseste pe primele locuri intre problemele legate de calculatoare si practic oricine se loveste de ea. Chiar si asa, DBMS-urile actuale ofera numai cateva controale nesemnificative de securitate, si acelea dependente de sistemul de operare gazda.
Un sistem de securitate a bazei de date trebuie sa fie capabil sa determine cine cere acces, ce date sunt cerute, ce tip de acces este cerut si daca cel care cere este autorizat pentru tipul respectiv de acces la datele cerute. Intentia este de a ne asigura ca numai utilizatorii autorizati a accede tipuri particulare de date sunt capabili a accede acele date. Daca un utilizator nu este autorizat a actualiza tipuri particulare de date, atunci nu trebuie sa existe nici o posibilitate ca utilizatorul sa modifice aceste date. DBMS-urile suporta de obicei cel putin accesul "totul sau nimic" pe portiuni ale bazei de date. In aceste cazuri, daca un utilizator poate accede o portiune a bazei de date, atunci atat tranzactiile de citire, cat si cele de actualizare pentru acel utilizator vor fi acceptate. Nu se face distinctie intre diferitele tipuri de acces.
Alte DBMS-uri fac distinctia intre accesul numai in citire si cel de actualizare, iar altele disting chiar si diferitele tipuri de acces de citire. In aceste cazuri, anumiti utilizatori sunt autorizati a accede datele de pe linii, iar altii numai zonele de totaluri si datele de rezumat. De exemplu, un utilizator nu ar putea citi alte inregistrari individuale din baza de date guvernamentala de impozite, le-ar putea insa citi pe ale lui. Oricine ar avea insa acces la rezumatul statistic: taxe medii, media scalaritatii, media persoanelor per locuinta, etc.
Probleme si amenintari de securitate. Amenintarile la securitatea bazei de date includ:
ameninati accidentale: atunci cand, in mod neintentionat, un utilizator obtine un acces neautorizat, datorita unei erori sistem sau utilizator.
amenintari deliberate: atunci cand un utilizator obtine intentionat un acces neautorizat.
Amenintarile accidentale la securitate sunt comune. De exemplu, un utilizator se conecteaza la un terminal la care un utilizator precedent nu a inchis sesiunea de lucru cu logout. Utilizatorul precedent poate avea alte drepturi decat utilizatorul nou.
Exista mai multe tipuri de amenintari de securitate deliberate, incluzand urmatoarele:
Securitate fizica:
mediile fizice de memorare pot fi furate.
terminalele pot fi localizate in medii nesigure, unde sunt accesibile persoanelor neautorizate. Aceste persoane pot castiga acces neautorizat pur si simplu examinand ecranele sau listingurile de la terminal.
un utilizator poate obtine acces neautorizat intr-o camera cu calculatoare si poate sari peste mecanismul de securitate al sistemului de operare sau al DBMS_ului.
Comunicatii:
un utilizator poate sa se conecteze direct, fizic, de linii de comunicatii.
Proceduri externe:
mediile fizice de memorare pot fi copiate fara a folosi serviciile unui DBMS. Daca securitatea bazei de date este in singura responsabilitate a DBMS-ului, atunci copierea poate fi neautorizata.
un programator de aplicatii poate scrie software care se comporta diferit de specificatiile sale si codul rezultat poate sa nu se conformeze politicii de securitate.
un utilizator se poate masca intr-unul mai privilegiat, folosind la login o parola privilegiata.
un programator de sistem poate scrie cod care invalideaza mecanismele de securitate ale sistemului de operare sau ale DBMS-ului, permitand accesul la date altfel inaccesibile.
un administrator de date poate specifica incorect politica de securitate, dand autorizatii improprii unor utilizatori.
un utilizator autorizat poate vinde sau da date unui utilizator neautorizat.
un utilizator poate infera date pe care el este neautorizat a le accede din datele pe care este autorizat a le accede.
Dintre aceste amenintari, cele mai dificil de controlat sunt procedurile externe.
Compararea responsabilitatilor. Atat DBMS-urile cat si sistemele de operare sunt responsabile pentru protectia resurselor fata de referirea sau modificarea neautorizata, fata de autentificarea cererilor si pentru a oferi o tehnica de protectie simpla, sigura si eficienta. Exista totusi, diferente care fac mecanismul de protectie al sistemului de operare mai putin potrivit pentru securitatea bazei de date:
sistemele de operare protejeaza resursele fizice, de exemplu: fisiere, pagini, discuri, etc. DBMS-urile trebuie sa protejeze resursele logice, de exemplu: relatii, atribute, inrtegistrari si segmente.
sistemele de operare protejeaza o resursa in totalitatea sa. DBMS-urile trebuie sa fie capabile sa protejeze parti din resurse, de exemplu: campuri, inregistrari si subscheme din aceasi baza de date.
sistemele de operare disting intre acces in citire si acces in scriere. DBMS-urile trebuie sa distinga si intre tipuri aditionale de acces: dependente de continut si dependente de istorie.
Controlul accesului dependent de continut cere regasirea valorilor datelor din baza de date pentru a putea determina cand este utilizatorul autorizat a accede acele valori. De exemplu, managerii pot fi autorizati sa regaseasca salariile unei parti a angajatilor, acelora subordonati lor si nu a tuturor salariatilor firmei. Atfel, pentru a determina cand un utilizator particular este capabil sa regaseasca salariul lui Ion Popescu, DBMS-ul trebuie la inceput sa regaseasca inregistrarea lui Ion Popescu si apoi sa determine daca Ion Popescu este un subaltern al apelantului.
Controlul accesului dependent de context protejeaza fata de combinatiile de accese la valorile de date individuale. De exemplu, sa consideram o baza de date care este gandita a fi sigura ca nici un vanzator nu poate determina comisionul platit altcuiva. Cineva, totusi, poate determina totalul comisioanelor platite pentru contractele unui departament, ce contracte sunt ale fiecarui departament, tipul fiecarui contract si totalul comisioanelor platite pentru fiecare tip de contract. Sa presupunem ca vanzatorul stie:
Contractele A, B si C apartin departamentului XYZ.
Contractele A, B si D sunt contracte pe termen scurt.
Comisionul contractului D este 10000, D fiind un contract pentru care se plateste comision.
El poate atunci infera comisionul platit contractului C, utilizand interogarile:
Ce valoare de comisioane s-au platit pentru contractele departamentului XYZ?
Raspuns: 65000.
Ce valoare de comisioane s-au platit pentru contractele pe termen scurt?
Raspuns: 50000
Rezolvand ecuatiile: A + B + C = 65000; A + B + 10000 = 50000; rezulta C = 25000, ceea ce este o informatie la care vanzatorul nu avea acces.
Protectia fata de aceste accese se realizeaza prin limitarea numarului de cereri pe care un user neautorizat le poate pune bazei de date.
Controlul accesului dependent de istorie previne ca un utilizator sa faca o serie de cereri care impreuna sa ofere date pe care utilizatorul este nu este autorizat sa le obtina. De exemplu, un individ poate fi autorizat sa regaseasca bugetul departamentului si bugetul pentru proiectele de cercetare dezvoltare, dar nimeni sa nu fie autorizat sa regaseasca aceste bugete pentru toate departamentele.
9. Tehnici de control al securitatii.
Izolare fizica. Abordarea "izolare fizica" muta datele sensibile pe facilitati sigure, care au proceduri de intrare/iesire puternic controlate, nu suporta accesul prin modem si care sunt monitorizate cu grija. Daca exista linii de comunicatii spre facilitate, ele sunt bine protejate si se executa pe terminale care sunt, de asemenea, din facilitatea sigura. Intr-un mediu distribuit de baze de date, se pot stoca date in facilitati cu diferite nivele de securitate. Atunci cand aceasta are loc, variatele nivele de protectie trebuie sa fie verificate atunci cand se valideaza cererile.
Sisteme cifrate. Sistemele cifrate adreseaza problema infiltrarilor de securitate prin liniile de comunicatii si pot fi folosite, de asemenea, pentru protectia la accese neautorizate la fisierele disc sau banda. Un sistem cifrat codifica datele pentru a le ascunde semnificatia reala, adica pentru a le face neinteligibile cererilor neautorizate. Un sistem cifrat foloseste un algoritm si o cheie criptografica. Algoritmul include o procedura de incriptare si una de decriptare. Procedura de incriptare ia datele reale si cheia criptografica si produce datele criptate. Datele codificate pot fi decodificate mai tarziu cu procedura de decriptare utilizand aceasi cheie criptografica. Algoritmul unui sistem cifrat este, uzual, cunoscut public, cheia criptografica fiind pastrata secreta. Pentru ca un sistem cifrat sa fie eficient, nu trebuie sa existe un mod simplu de a gasi cheia. Un sistem cifrat foarte simplu foloseste urmatoare procedura de incriptare:
inversati ordinea cifrelor din datele reale.
inserati o cifra falsa intre perechi de cifre reale.
pentru fiecare cifra substituiti litera ordinala corespunzatoare din cheie.
Sa presupunem ca cheia este "wryip<adgj". Valoarea 12323487 va fi incriptata astfel:
dgapiyyiwyrd
Daca cheia de criptare ar fi fost "mcczljgdap", valoarea incriptata rezultata ar fi fost: "daglzcczmcbd".
Cuvinte de trecere (parole). Parolele sunt folositoare pentru a autentifica utilizatorii si pentru a identifica un utilizator printr-o informatie ce doar el o stie. Sistemele de operare folosesc parole pentru a determina daca cineva este autorizat sa se conecteze la sistem. Atunci cand un utilizator se autoidentifica, el ofera si parola sa. Sistemul verifica parola oferita cu cea inregistrata in sistem, pentru a permite accesul. In mod clar, protectia cu parole este atat de buna cat de bine se pastreaza secretul parolelor. Intr-un mediu baze de date, parolele se pot atasa fisierelor, dar nu inregistrarilor sau campurilor si pot exista parole diferite pentru acces in citire sau in scriere. Se poate ca un utilizator sa dea la inceput o parola pentru a accede sistemul de operare si apoi parole aditionale pentru a accede resurse de date.
Protectia cu parole este aproape intotdeuna oferita de catre sistemul de operare si nu de catre DBMS. Atunci cand un utilizator foloseste o comanda baza de date pentru a deschide un fisier baza de date, DBMS-ul prelucreaza cererea pasand-o impreuna cu parola utilizatorului, sistemului de operare.
Modificarea interogatiei. Modificarea interogatiei schimba cererile utilizatorului pentru a include reguli de protectie. Atunci cand este primita o cerere utilizator, se verifica prezenta regulilor de protectie; se regasesc orice date necesare validarii conditiei specificate in regula de protectie; apoi cererea utilizatorului este prelucrata.
De exemplu, daca regula de protectie este acea ca un manager poate regasi numai salariile angajatilor subordonati lui, atunci o cerere
SELECT SALARY
FROM ANGAJAT
WHERE DEPT# = 10
va fi modificata in
SELECT SALARY
FROM ANGAJAT
WHERE DEPT# = 10
AND MANAGER = nume_utilizator
Restrictia de protectie este adaugata automat de catre DBMS:
Vederi. Vederile sunt partitii logice ale unei baze de date, ele se mai numesc subscheme. Uzual, o cerere la o baza de date acceseaza o vedere. Vederile sunt definite pentru diferiti utilizatori in concordanta cu nevoile lor de date si ele pot fi folosite pentru a controla accesul la date. Depinzand de facilitatile DBMS-ului de a defini vederi, controlul poate fi mai mult sau mai putin precis.
De exemplu, in sistemele relationale, vederile se definesc uzual folosind limbajul de interogare. In aceste cazuri, granularitatea vederii poate fi atat de fina sau de grosiera cat se doreste. O vedere poate corespunde unei relatii de baza, poate combina relatii de baza, poate elimina anumite coloane dintr-o relatie de baza si poate elimina linii dintr-o relatie de baza, bazandu-se pe continutul lor.
Pe de alta parte, in alte DBMS-uri, o vedere este implementata ca un fisier separat. In aceste cazuri, definirea vederilor foarte fine implica implementarea bazei de date cu mai multe fisiere mici. Definirea vederilor grosiere, pe de alta parte, implica faptul ca baza de date va fi implementata cu mai putine fisiere si ca protectia de securitate va fi grosiera.
Securitatea pe medii distribuite. Protectia de securitate devine ceva mai complicata intr-un mediu distribuit de baze de date. Fie ca toate procesoarele ar putea implementa acelasi nivel de controale de securitate, fie ca mai multe zone de control se implementeaza atunci cand se valideaza cererile.
Pot exista costuri ascunse atunci cand se ofera protectie de securitate intr-un mediu distribuit de baze de date. De exemplu, fortarea controalelor de acces dependente de continut poate insemna accesarea datelor memorate pe diferite procesoare. De exemplu, sa presupunem ca data "salariu" este considerata a fi sensibila si este memorata in locatia sigura A. Datele despre cine o gestioneaza sunt memorate in locatia B. Pentru a prelucra cererea din exemplul de interogare de modificare, trebuie accesate ambele locatii, A si B.
Datorita capacitatii de a separa portiuni fizice dintr-o baza de date intr-un mediu distribuit, securitatea este mai usor de oferit decat intr-un mediu centralizat. La diferite nivele pot fi implementate diferite controale fizice, pot fi folosite diferite chei criptografice in algoritmi de incriptare la diferite nivele.
Controalele de securitate pot fi potrivite cu cerintele de protectie pentru tipuri particulare de date.
10. Stabilirea unei politici de securitate.
Tehnicile de securitate a bazelor de date incearca sa combata problemele cauzate de persoane fizice, iar tehnicile de control al accesului partajat si de refacere a bazelor de date incearca sa combata problemele cauzate de hard si soft. Stabilirea unei politici de securitate eficiente este, astfel, importanta in orice mediu interesat de evitarea scurgerii datelor spre persoane neautorizate.
Majoritatea DBMS-urilor ofera o mica protectie de securitate in plus fata de cea oferita de catre sistemul de operare gazda. Protectia de securitate se gaseste cel mai adesea in politicile de securitate stabilite in afara software-ului.
Politica de securitate poate decide:
Daca securitatea va fi controlata central de catre un administrator de date sau daca va fi controlata de diferiti administratori?
Procedurile pentru schimbarea controalelor de securitate si adaugarea de noi utilizatori si resurse de date la sistem.
Cerintele minimale pentru capacitatile de protectie a securitatii ale DBMS-ului care se vor folosi in mediu.
Procedurile pentru fortarea controalelor de securitate.
Responsabilii pentru fiecare tip de data din sistem.
Tipurile de acces distincte in oferirea controlului de securitate.
Pentru a stabili cerintele pentru politica de control a securitatii, trebuie sa se raspunda unor intrebari ca urmatoarele:
Cat de sensibile sunt datele?
Cat de dificil este pentru un utilizator a sparge protectia de securitate?
Ce nivel de control de securitate este cerut?
Ce costuri suplimentare este rezonabil a include pentru a oferi securitatea?
Cat de sigure fizic sunt facilitatile de calculator si de terminal?
Exista cerinte legate de securitate?
Exista cerinte de securitate al contractantului?
Decizii de proiectare. Un semn de pericol intr-un mediu cu date presupuse sensibile este lipsa unei politici de securitate. Securitatea este o arie in care este ceruta actiunea administratorului de date, caci DBMS-ul si sistemul de operare nu ofera prin ele insele o protectie adecvata.
DBMS-ul tipic foloseste parole pentru a controla accesul la portiuni ale bazei de date. Un anumit control se bazeaza pe tipul de acces si datele ce se acceseaza. Consideratiile de securitate pot afecta marginile fisierelor, partitionarea bazei de date de-a lungul procesoarelor, intr-un mediu distribuit, precum si folosirea incriptarii. Daca un DBMS se bazeaza in totalitate pe sistemul de operare pentru protectia de securitate, consideratiile de securitate se iau in considerare cand se proiecteaza marginile fisierelor in sistemul baze de date. Daca procesoarele retelei ofera nivele diferite de protectie de securitate, atunci consideratiile de securitate pot deveni factorul primar in decizia repartizarii datelor pe procesoare.
11. Comentarii finale.
Una din capacitatile care disting un DBMS de o metoda de acces bazata pe fisiere o constituie serviciile de protectie a datelor, care includ refacerea din diferite tipuri de esecuri, prevenirea conflictelor intre tranzactii care acced date partajate, precum si prevenirea accesului neautorizat la resursa de date. Protectia datelor este o arie de cercetare activa de multi ani. Serviciile de protectie a datelor oferite in DBMS-uri vor continua sa se dezvolte incorporand cercetari noi. Cu cat vom deveni mai dependenti de suportul de baze de date cu atat problema securitatii datelor va sta mai mult in atentia noastra.
Memento
Abort Esec soft
Imagine dupa Granularitate
Arhiva Jurnal
Urma Incuiere
Backout Unitate logica de lucru
Backup Control concurential optimist
Imagine inainte Parola
Executie seriala Incuieri partajate
Incuieri in doua faze UNDO
Checkpoint Unitate de refacere
Comitere Refacere
Cheie criptografica Tehnica de refacere
Deadlock (blocare) REDO
Decriptare Restart
Incriptare Rollback
Incuiere exclusiva Rollforward
Serializabilitate Program de salvare
Protocol de comitere in doua faze Tranzactie
Bibliografie
Bernstein, P.A.; Goodman, N. (1979) Approaches to concurency control in distributed database systems, Proceedings, 1979 National Computer Conference
*** (1980) Timestamp-based algorithms for concurency control in distributed database systems, Proceedings, Sixth International Conference on Very Large Databases, October 1980
Fernandez, E.B.; Summers,
R.C.; Wood, C. (1981) Database Security
and Integrity, Addison Wesley,
Verhofstad, J.S.M. (1978) Recovery Techniques for database systems, ACM Computing Surveys 10.
*** (1981) The transaction concept: Virtues and
Limitations, Proceedings, Seventh International Conference on Very Large
Databases,
|
Politica de confidentialitate |
 .com |
Copyright ©
2024 - Toate drepturile rezervate. Toate documentele au caracter informativ cu scop educational. |
Personaje din literatura |
| Baltagul – caracterizarea personajelor |
| Caracterizare Alexandru Lapusneanul |
| Caracterizarea lui Gavilescu |
| Caracterizarea personajelor negative din basmul |
Tehnica si mecanica |
| Cuplaje - definitii. notatii. exemple. repere istorice. |
| Actionare macara |
| Reprezentarea si cotarea filetelor |
Geografie |
| Turismul pe terra |
| Vulcanii Și mediul |
| Padurile pe terra si industrializarea lemnului |
| Termeni si conditii |
| Contact |
| Creeaza si tu |
