curs 10

2. Utilizatorii de izolare.

3. tranzacții serializarea

1. Tranzacție și integritatea bazelor de date.

Menținerea mecanismului de tranzacție - un indicator al nivelului de dezvoltare a bazei de date. Întreținerea corectă a tranzacției, în același timp, este fundamentul integrității bazelor de date (și, prin urmare, tranzacția este destul de adecvată în baza de date cu caracter personal cu un singur utilizator), precum și formează baza de izolare de utilizator în sistemele multi-utilizator. Adesea, aceste două aspecte sunt luate în considerare separat, dar de fapt ele sunt interdependente, după cum vor fi afișate în acest capitol.

Rețineți că, deși, în ceea ce privește integritatea mecanismului de tranzacție a bazei de date ar trebui să fie menținute în baza de date cu caracter personal, în practică, de obicei nu este efectuată. Prin urmare, în timpul tranziției de la personal la multi-utilizator SGBD utilizatorii se confruntă cu nevoia de o înțelegere clară a naturii tranzacției.

În cadrul tranzacției a însemnat indivizibilă în ceea ce privește impactul asupra secvenței bazei de date a declarațiilor de manipulare a datelor (citi, șterge, se introduce, să actualizeze) astfel încât fie rezultatele tuturor operatorilor implicați în tranzacție sunt afișate în baza de date, sau impactul tuturor acestor declarații este complet absentă. Sloganul tranzacției - „totul sau nimic“: la încheierea unei tranzacții COMMIT de fix garantat în memoria externă (adică a comite - „repara“ rezultatele tranzacției); la finalizarea operatorului de tranzacții rezultate ROLLBACK garantează absența memoriei externe (sensul cuvântului rollback - pentru a elimina rezultatele tranzacției).

1. Tranzacție și integritatea bazei de date

Conceptul de tranzacție este direct legată de conceptul de integritate a bazei de date. Foarte des, baza de date poate avea o astfel de integritate restricții, care este pur și simplu imposibil să nu se rupă, care se efectuează numai o bază de date modificări operatorului. De exemplu, în integritatea ANGAJAȚI bazei de date departament de date este restricție naturale OTD_RAZMER valorile de potrivire într-un departament de relații atribut tuple, care descrie separat (de exemplu, separate 320), cu numărul de tuple ale SALARIATILOR relații astfel încât valoarea atributului este SOTR_OTD_NOMER 320. La fel ca în acest caz, luați pentru a lucra în departamentul de 320 nou angajat? Indiferent de ce operație va fi efectuată în primul rând, introducerea unui nou tuplu împotriva membrilor sau modificarea tuplu existente în raport separat, după efectuarea bazei de date este într-o stare de incompletitudine.

Prin urmare, pentru a menține astfel de constrângeri de integritate a permis încălcarea lor într-o tranzacție, cu condiția ca la finalizarea condițiilor de integritate tranzacției au fost îndeplinite. În sistemele cu mijloace avansate de control și monitorizare a integrității fiecărei tranzacții începe de la o stare consistentă, iar baza de date ar trebui să părăsească această integritatea statului după finalizarea acestuia. Nerespectarea (operatorul ROLLBACK m. E. COMMIT În schimb declarație este executată), astfel ca rezultat faptul că, în loc de stabilire a rezultatelor are loc o tranzacție derulată înapoi, iar baza de date este încă într-o stare în care a fost la începutul tranzacției, adică. E. Într-o stare consistentă .

Pentru a fi un pic mai precis, distinge între două tipuri de constrângeri: imediat verificate și retrase din circuitul agricol. Pentru a verifica instantaneu constrângerile de integritate includ astfel de restricții, verificați care este lipsit de sens sau imposibil să amâne. Un exemplu al limitărilor prin care să întârzie domeniu fără sens sunt limitări (personal de vârstă nu poate depăși 150 s). Mai multe controale de constrângere complexe, care nu pot fi amânate, este următorul: salariul angajat nu poate fi crescută într-un singur pas cu mai mult de 100.000 de ruble. Imediat constrângerile de integritate verificabile corespund nivelului de operatori la nivel de limbă SGBD individuale. Cu încălcarea lor nu se rostogolească înapoi tranzacția, ci pur și simplu a respins operatorul corespunzător.

constrângere de integritate Deferrable - este limitat la baza de date, și nu pe orice tranzacție individuală. În mod implicit, aceste constrângeri sunt verificate la sfârșitul tranzacției, iar încălcarea lor este înlocuirea automată a COMMIT la ROLLBACK. Cu toate acestea, în unele sisteme a sprijinit operatorul special de verificare în mod forțat constrângeri de integritate în cadrul unei tranzacții. În cazul în care, după un astfel de operator se constată că integritatea nu sunt îndeplinite condițiile, utilizatorul poate efectua o ROLLBACK, sau pentru a încerca să elimine cauzele bazei de date de stat neîmplinire într-o tranzacție (aparent, aceasta este semnificativă numai atunci când utilizați modul interactiv).

Și încă o remarcă. Din punctul de vedere al reprezentării externe la finalizarea unei tranzacții verificate toate constrângerile de integritate deferrable definite în baza de date. Cu toate acestea, atunci când punerea în aplicare a căuta în timpul tranzacției să aloce în mod dinamic aceste constrângeri de integritate, care ar fi cu adevărat rupte. De exemplu, în cazul în care efectuează tranzacții în baza de date TEAM-SECȚIUNILE în aceasta nu a fost efectuată inserarea operatorilor sau ștergerea tuplele a angajaților relații, verificarea integrității nu este necesară o restricție citată anterior (și verificarea unor astfel de restricții determină destul de multă muncă).

2. Utilizatorii de izolare

În sistemele multi-utilizator cu aceeași bază de date, în același timp, se poate ocupa mai mulți utilizatori sau aplicații. Scopul final al sistemului este de a asigura izolarea utilizatorilor, adică. E. Stabilirea unei iluzii credibile și de încredere că fiecare utilizator funcționează doar cu baza de date.

În legătură cu proprietatea de menținere a integrității tranzacțiilor de baze de date sunt unități de izolare utilizator corespunzătoare. Într-adevăr, în cazul în care fiecare sesiune cu tranzacția bazei de date asociate, fiecare utilizator începe cu starea consecventă a bazei de date, de ex., E. cu statul în care baza de date ar putea fi, chiar dacă utilizatorul lucra doar cu ea.

Sub rezerva cerinței obligatorii pentru a menține integritatea bazei de date, următoarele niveluri de izolare tranzacție:

Rețineți că este posibil să se asigure diferite niveluri de izolare pentru diferite tranzacții care rulează într-un sistem de baze de date (în special, operatorii respectivi sunt prevăzute în standardul SQL 2). Așa cum am observat, primul nivel este suficient pentru a menține integritatea. Există un număr de aplicații pentru care primul nivel este suficient (de exemplu, aplicații sau sistem de statistici utilitate pentru care incorectitudini date individuale nu este importantă). Astfel, este posibil să se reducă în mod semnificativ aeriene și pentru a îmbunătăți eficiența generală a bazei de date.

Pentru o probleme mai subtile de izolare tranzacție este așa-numita problemă kortezhey- „fantomelor“, provocând o situație care este, de asemenea, contrar izolării utilizatorului. Luați în considerare următorul scenariu. 1 execută o tranzacție un eșantion tuple ale relației cu condiția de eșantionare R S (m. E. O parte din tuplele selectate din relația R, satisfacand S). Înainte de finalizarea tranzacției tranzacției 1 2 introduce un nou raport tuplu R r, care satisfac condiția S, și finalizat cu succes. Tranzacție 1 re-execută operatorul A, iar rezultatul este un tuplu, care a fost absent în prima reprezentație a operatorului. Desigur, o astfel de situație este contrară ideii de izolare tranzacție, și poate avea loc chiar la al treilea nivel de izolare tranzacție. Pentru a evita tupluri fantomă, aceasta necesită o tranzacție de sincronizare nivel „logic“ mai mare. Idei de o astfel de sincronizare (predicat de sincronizare surprinde) au fost mult timp cunoscute, dar nu și puse în aplicare în majoritatea sistemelor.

3. tranzacții serializarea

Este clar că, în scopul de a realiza tranzacții de izolare în baza de date vor fi utilizate orice metode de reglementare a schimbului de tranzacții.

Planul (metoda) să efectueze un set de tranzacții se numește serialelor, în cazul în care rezultatul punerii în aplicare în comun a tranzacției este echivalentă cu rezultatul unei puneri în aplicare coerente a aceleiași tranzacții.

Serializare a tranzacției - acesta este mecanismul de punere în aplicare a acestora de către o parte a planului serialelor. Furnizarea unui astfel de mecanism este funcția principală a componentei de bază de date pentru gestionarea tranzacției. Sistemul, care susține serializarea izolarea tranzacției oferă utilizatorilor reali.

Problema principală este realizabilă în alegerea unei metode de serializarea unui set de tranzacții, care nu este prea va limita paralelismul lor. Vine în minte soluția banală este într-adevăr punerea în aplicare consecventă a tranzacției. Dar există situații în care operatorii pot efectua diverse tranzacții în orice ordine de conservare serialității. Exemple pot fi citite doar de tranzacțiile precum și tranzacții care nu intră în conflict pe obiectele bazei de date.

Între tranzacții pot exista următoarele tipuri de conflicte:

Metode practice serializa tranzacții se bazează pe contul acestor conflicte.