Izolarea instantanee (capturilor) și constrângerile de integritate

1. Introducere

Actualele arhitecturi ale sistemelor informatice sunt arhitecturi de tip multitier (multinivel), în care sistemele de baze de date construiesc nivelul backend care asigură persistenţa şi proprietăţile tranzacţionale. Contemporan, o dată cu creşterea nevoilor de access concomitent la aplicaţii online şi apariţia standardelor de web-service, aceste sisteme informatice se confruntă cu o imensă problemă în ceea ce priveşte scalabilitatea sistemelor. O soluţie comercială în vederea optimizării scalabilităţii este achiziţionarea unui software paralel, care reprezintă de altfel soluţia scumpă, în termeni de cost. O alternativă mai ieftină a acestei soluţii este replicarea bazei de date ceea ce necesită ca sistemul de baze de date să fie instalat pe un cluster de maşini, fiecare stocând cate o copie a bazei de date. În general, este folosită o abordare ROWA (Read-One-Write-All) care presupune citirea dintr-o singură replică, însă scrierea trebuie să fie realizată în toate replicile.

1.1. Replicarea bazei de date

În ultimii ani, au fost propuse mai multe soluții de replicare bazate pe cluster care s-au dovedit a oferi scalabilitate excelentă pentru volume de lucru tranzacționale. Clienţii se conectează la replicile bazei de date şi trimit cererile ca şi cum ar fi o bază de date nereplicată. Alte soluţii implementează logica replicării într-un nivel middleware între client şi replicile bazei de date. Middleware-ul oferă o interfaţă standard a bazei de date, cum ar fi un JDBC, şi controlează unde se execută scrierile şi citirile.

1.2. Corectitudine în bazele de date replicate

Majoritatea soluțiilor presupun că sistemul de baze de date care stă la bază oferă serializabilitate la nivel de izolare, folosind strict blocarea în două faze (2PL). Acest mecanism presupune că executarea în mediul replicat este echivalentă cu o execuție serială asupra unei copii logice unice a bazei de date. Recent, izolarea instantanee s-a dezvoltat ca un nou nivel de izolare, care este puţin mai slab decât serializabilitatea şi trebuie să devină foarte popular. Aceasta presupune ca tranzacţiile să citească date dintr-o captură comisă în momentul în care încep. Mai mult, dacă două tranzacţii vor să actualizeze aceleaşi date concomitent, una va fi abandonată. Faţă de mecanismul standard, implementările izolărilor instantanee permit mai multă concurenţă deoarece operaţiile de citire, citesc dint-o captură, înlăturând astfel nevoia de a bloca tabelele.

1.3. Contrângeri de integritate

Cu toate că literatura de specialitate a tratat în detaliu izolarea instantanee şi relaţia acesteia cu serializabilitatea, în ceea ce priveşte comportamentul cu privire la constrângerile de integritate, nu există precizări precise. După cum a subliniat şi Berenson et al. [1995], izolarea instantanee, având toate operațiunile bazate pe semantică, constrângerile de integritate, cum ar fi constrângerile cheile externe sunt ușor încălcate.

Adya [1999] tratează subiectul constrângerilor de integritate şi intergrarea acestora cu izolarea instantanee, propunând folosirea unui nivel de izolare serializabil pentru actualizarea tranzacţiilor, iar izolarea instantanee să fie folosită doar pentru tranzacţiile read-only .

2. Izolarea instantanee(capturilor) și constrângerile de integritate

O constrângere de integritate pune constrângeri cu privire la existența și valorile datelor obiectelor din sistem. În timpul executării unei tranzacții ar putea fi încălcate aceste constrângeri. Cu toate acestea, în momentul commit-ului, toate constrângerile trebuie îndeplinite.

Constrângerea cea mai simplă este cheia primară care nu permite existența a două înregistrări într-un tabel cu aceeași valoare în atributul cheie primară.

O constrângere foarte comună, este cheia externă.

Exemplu: considerăm tabele angajat și departament:

departament

id number(3)

angajat

cnp number(13)

nume varchar2(20)

prenume varchar2(40)

did number(3)

cnp este cheie primară pentru tabelul angajat, iar id este cheie primară în tabelul departament și cheie externă în tabelul angajat. Cheia externă cere ca dacă există o înregistrare în tabelul angajat unde id = ”id1”, atunci trebuie să existe o înregistrare în tabelul departament care să aibă id = ”id1”.

Pentru a efectua o astfel de operație, la primirea unor cereri de actualizare un sistem de baze de date trebuie să efectueze unele operațiuni de citire implicite. De exemplu, la inserția unui nou tuplu, sistemul verifică dacă există deja o înregistrare cu aceeași valoare cheie primară, și dacă da, întrerupe tranzacția. În exemplul anterior, la inserarea unei înregistrări angajat sau actualizarea câmpului id al unei înregistrări existente în tabela angajat, sistemul efectuează o operație de citire implicită pe tabela departament pentru a verifica dacă există înregistrarea cu valoarea corespunzătoare atributului id în această tabelă. În cazul în care există, inserarea / actualizarea înregistrării angajat este permisă, în caz contrar, tranzacția este anulată.

Execuția tranzacțiilor este definite prin intermediul istoricului . Un istoric H peste un set de tranzacții T descrie execuția tuturor tranzacțiilor din T.

O interogare a bazei de date accesează adesea un set întreg de date și efectuează o evaluare predicat. O tranzacție Ti poate avea predicat o operație de citire

ri (F: P: Oset (P): Iset (P))

P este o funcție peste un set de relații care definesc un predicat. Iset (P) conține o versiune pentru fiecare element de date a fiecărui raport specificat în P. Predicatele operații de citire sunt adăugate la istoric la fel ca operațiile normale de citire sau scriere.

În exemplul anterior cu privire la cheia externă, la introducerea unui tuplu angajat, importantă este existența unui tuplu departament corespunzător care poate fi exprimat doar ca un predicat citire. Problema este că, dacă aceste operații de citire ruleză sub izolare instantanee, constrângerile de integritate ar putea fi încălcate.

Pentru o mai bună înțelegere, vom considera exemplul următor(care este de fapt cel mai utilizat exemplu în literatura de specialitate pentru a arăta că izolarea instantanee nu oferă serializabilitate), de încălcare a constrângerii în situația în care suma a două conturi date ar trebui să fie mai mare de zero. Dacă tranzacțiile doresc să retragă bani de la unul din conturi valorile ambelor conturi trebuie să fie verificate: