Caracteristici Esentiale Ale SGBD Si SGBC

Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008
Caracteristici eseniale ale SGBD i SGBC
CUPRINS
TENDINE ACTUALE N INDUSTRIA SGBD................................................................5 Sisteme de Gestiune a Bazelor de Date (SGBD)..............................................................5 Tranzacii..........................................................................................................................5 Arhitecturi Client / Server.................................................................................................6 Sisteme deschise i bd distribuite......................................................................................8 Baze de date distribuite.................................................................................................8 Programe interfa de acces..........................................................................................9 Medii de procesare paralel..............................................................................................9 Arhitecturi fr partajare.............................................................................................10 Arhitecturi cu discuri partajate....................................................................................10 Arhitecturi cu memorie partajat................................................................................11 Patru tipuri de cuplare a procesoarelor: strns, lejer, simetric, i asimetric.........11 Procesarea paralel a tranzaciilor i interogrilor .....................................................11 Procesarea paralel a indexurilor i a programelor utilitare........................................12 Sisteme orientate obiect..................................................................................................12 Gestiunea obiectelor persistente n arhitecturi client / server.....................................13 Un exemplu de bd orientat obiect..............................................................................14 Integrarea n Internet.......................................................................................................15 Cinci exemple de SGBD celebre.....................................................................................18 DATABASE2 (DB2) MVS / ESA versiunile 3 i 4 ale IBM ....................................18 Oracle 7.1 al Oracle.....................................................................................................18 SQL Server 10.0 al Sybase.........................................................................................19 NonStop SQL / MP al Tandem...................................................................................19 CA-OpenIngres al Computer Associates....................................................................19 Comentarii i referine bibliografice...............................................................................20 2. CONTROLUL CONCURENEI...................................................................................21 Lacte..............................................................................................................................21 Cele dou tipuri fundamentale de lacte: partajabil i exclusiv..................................21 Granularitatea..................................................................................................................22 Niveluri de izolare a lactelor.........................................................................................23 Izolarea citirilor repetabile..........................................................................................23 Stabilitatea cursorului.................................................................................................23 Blocarea n dou faze......................................................................................................24 Blocaje fatale...................................................................................................................25 Blocaje fatale globale n bd distribuite........................................................................25 Comentarii i referine bibliografice...............................................................................26 Controlul concurenei n DB2.....................................................................................26 Controlul concurenei n NonStop SQL......................................................................27 Controlul concurenei n Oracle..................................................................................28 Controlul concurenei n SQL Server al Sybase.........................................................29 Controlul concurenei n CA-OpenIngres...................................................................30 3. SALVRI I RECUPERAREA DIN EROARE............................................................32 Jurnale de actualizri.......................................................................................................32 Refacerea i desfacerea automat a actualizrilor.......................................................32 Puncte de verificare.........................................................................................................33 2
Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008 Recuperarea din dezastre.................................................................................................35 Comentarii i referine bibliografice...............................................................................35 Salvri i recuperri n DB2........................................................................................35 Salvri i recuperri n NonStop SQL.........................................................................36 Salvri i recuperri n Oracle.....................................................................................36 Salvri i recuperri n SQL Server al Sybase............................................................37 Salvri i recuperri n CA-OpenIngres......................................................................38 4. SECURITATEA DATELOR..........................................................................................39 Privilegii..........................................................................................................................39 Codificarea datelor i verificarea accesului....................................................................39 Ierarhia nivelurilor de acces utilizator n bd distribuite..................................................40 Comentarii i referine bibliografice...............................................................................40 Securitatea datelor n DB2..........................................................................................40 Securitatea datelor n NonStop SQL...........................................................................40 Securitatea datelor n Oracle.......................................................................................41 Securitatea datelor n SQL Server...............................................................................41 Securitatea datelor n CA-OpenIngres........................................................................41 5. IMPUNEREA CONSTRNGERILOR DE INTEGRITATE........................................42 Integritatea domeniilor de valori.....................................................................................42 Integritatea referinelor....................................................................................................42 Trgaciuri........................................................................................................................43 Procesarea n dou faze a terminrii execuiei tranzaciilor............................................43 Comentarii i referine bibliografice...............................................................................45 Impunerea constrngerilor n DB2..............................................................................45 Impunerea constrngerilor n NonStop SQL..............................................................46 Impunerea constrngerilor n Oracle...........................................................................46 Impunerea constrngerilor n SQL Server..................................................................46 Impunerea constrngerilor n CA-OpenIngres............................................................46 6. IMPLEMENTAREA FIIERELOR INDEX...............................................................47 Accesul talme-balme (hash)..................................................................................47 Arbori B+........................................................................................................................48 Memorarea grupat a tuplilor n pagini...........................................................................49 Comentarii i referine bibliografice...............................................................................49 Fiiere index n DB2...................................................................................................50 Fiiere index n NonStop SQL....................................................................................50 Fiiere index n Oracle................................................................................................50 Fiiere index n SQL Server........................................................................................50 Fiiere index n CA-OpenIngres.................................................................................50 7. OPTIMIZAREA PROCESRII I ACCESULUI LA DATE.....................................51 Optimizarea operatorului join.........................................................................................51 Implementarea bucl n bucl a joinului..................................................................51 Implementarea sort/reuniune a join-ului..................................................................51 Implementarea hibrid a joinului................................................................................52 Implementarea talme-balme a join-ului................................................................52 Implementarea folosind semijoin-uri n bd distribuite................................................52 Alte tipuri de optimizri ale procesrii datelor...............................................................53 Folosirea mai multor fiiere index per tabel: implementarea index AND i index OR a seleciilor................................................................................................................54 3
Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008 Optimizarea accesului la date bazat pe reguli...............................................................55 Optimizarea accesului la date bazat pe costuri..............................................................55 Mecanisme de control a optimizrii accesului la date....................................................55 Optimizarea global a accesului n bd distribuite...........................................................56 Comentarii i referine bibliografice...............................................................................57 Optimizarea n DB2....................................................................................................57 Optimizarea n NonStop SQL.....................................................................................58 Optimizarea n Oracle.................................................................................................58 Optimizarea n SQL Server.........................................................................................58 Optimizarea n CA-OpenIngres..................................................................................58 8. CATALOAGE DE META-DATE................................................................................59 Structura i coninutul cataloagelor.................................................................................59 Accesul utilizatorilor la cataloage...................................................................................59 Gestiunea cataloagelor n bd distribuite..........................................................................60 Comentarii i referine bibliografice...............................................................................60 Cataloagele n DB2.....................................................................................................60 Cataloagele n NonStop SQL......................................................................................61 Cataloagele n Oracle..................................................................................................61 Cataloagele n SQL Server..........................................................................................61 Cataloagele n CA-OpenIngres...................................................................................61 9. INTERFEE DE PROGRAMAREA APLICAIILOR (API).....................................62 Interfee ncorporate i interfee apel..............................................................................62 SQL static i dinamic. Proceduri memorate....................................................................62 Comentarii i referine bibliografice...............................................................................63 API n DB2..................................................................................................................63 API n NonStop SQL..................................................................................................63 API n Oracle..............................................................................................................63 API n SQL Server......................................................................................................64 API n CA-OpenIngres................................................................................................64
TENDINE ACTUALE N INDUSTRIA SGBD

Sisteme de Gestiune a Bazelor de Date (SGBD)
Sistemele de Gestiune a Bazelor de Date (SGBD) sunt programe care proceseaz datele privite ca resurse partajabile. Ele permit utilizatorilor structurarea datelor (conform unui model conceptual) n baze de date (bd) i exploatarea acestora concurent, de ctre mai muli utilizatori simultan. Pentru aceasta, ele asigur mecanisme cel puin pentru: memorarea (structurat a) datelor accesul la date protecia datelor (la tentative de acces neautorizat) pstrarea integritii datelor recuperarea din erori.
SGBD sunt azi oferite pe o mare varietate de platforme de calcul, pornind de la calculatoarele personale (PC) i pn la sistemele de procesare paralel masiv a datelor, sub medii extrem de diverse, incluznd DOS, Windows, Novell Netware, Macintosh, Unix, OS/2, VMS, OS/400, MVS. Majoritatea liderilor mondiali din industria de programare ofer cel puin un SGBD, dac nu mai multe; dintre acetia, este suficient s amintim IBM, Computer Associates, Sybase Inc., Oracle, Microsoft, Borland. Marile corporaii ale lumii, ca i foarte multe dintre cele medii sau mici, depind de peste dou decenii de SGBD, crora le sunt ncredinate funciuni critice n afaceri, precum urmrirea vnzrilor, cheltuielilor, stocurilor, ncasrilor sau plata salariilor. Dar i foarte muli oameni fac apel la SGBD pentru uzul personal, fie c este vorba de monitorizarea investiiilor familiale, fie de bd gestionnd biblioteca proprie de cri, reviste, fotografii, diapozitive, casete audio, video, discuri i CD-ROM-uri audio, video sau de date etc. Industria de SGBD genera n 1994 venituri depind 5 miliarde de dolari anual n lume, cifr mereu n cretere!
Tranzacii
Orice SGBD trebuie s asigure, n primul rnd, un limbaj de definire i manipulare a datelor, conform modelului de date suportat. Prin intermediul acestuia, se ofer utilizatorilor, n esen, posibilitatea de a memora datele structurate n bd i de a le accesa (pentru interogri i/sau actualizri). Pentru a asigura partajarea datelor n medii multi-utilizator, SGBD trebuie s ofere mecanisme de grupare a tuturor operaiilor care concur la ndeplinirea unei sarcini logice unitare ntr-o singur tranzacie, astfel nct SGBD s poat garanta ori c execuia unei tranzacii a avut loc complet, fr a fi afectat de alte tranzacii, ori c tranzacia nu a fost deloc executat (bd nefiind deci afectat de tranzacie). Tranzaciile sunt, prin urmare, singurele instruciuni logice atomice oferite de un SGBD; ca atare, ele ori se execut integral, ori deloc, n nici un caz parial, dpdv al oricrei alte tranzacii. Altfel spus, orice tranzacie parial executat (de exemplu, din cauza unei cderi de tensiune) trebuie abortat, iar toate efectele ei trebuie ignorate (rolled back). n caz contrar, n mod evident, ar putea rezulta stri inconsistente ale bd. Exemplul 9.1
De exemplu, dac o tranzacie mrete salariile angajailor unui departament cu 10%, iar o alta mut angajai din acel departament n alte departamente i cele dou tranzacii nu s-ar executa atomic, ci execuiile lor s-ar ntreptrunde, unii 5
Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008 dintre angajaii mutai ar putea avea salariile mrite nainte de mutare iar alii nu! Pentru pstrarea consistenei datelor, ori tranzacia de mrire salarii a fost lansat prima iar cea de mutare angajai trebuie lansat dup terminarea tuturor mririlor de salarii (cu efectul c toi angajaii mutai vor avea salariile mrite), ori, invers, tranzacia de mutare angajai a fost lansat prima iar cea de mrire salarii trebuie lansat abia dup ncheierea tuturor mutrilor (cu efectul c nici unul dintre angajaii mutai nu va avea salariul mrit).
Literatura de specialitate se refer, n acest sens, la cele patru proprieti ACIDe ale tranzaciilor: Atomicitatea execuiei (ori complet, ori deloc) Consistena (sau Corectitudinea) transformrilor induse coninutului bd de ctre tranzacie Izolarea execuiei tranzaciei, care nu trebuie s fie influenat de modificrile aduse bd de ctre orice alt tranzacie concurent Durabilitatea tranzaciei, ale crei modificri produse bd la terminarea execuiei sale trebuie s fie permanente, supravieuind oricror cderi ale sistemului sau defeciuni ale suporilor de stocare a datelor. Conceptul de tranzacie i de terminare a ei (commit, n englez) joac ns un rol la fel de important n controlul concurenei, impunerea constrngerilor de integritate, salvarea datelor i recuperarea din erori, aa cum vom vedea n continuare. Capitolele urmtoare discut despre problemele de implementare ale principalelor componente i funcii ale oricrui SGBD, indiferent de arhitectur sau de modelul suport al datelor, i anume despre: controlul accesului concurent; securitate; integritate; indexuri; optimizare; cataloage; interfee de programarea aplicaiilor (API); unelte utilitare. De remarcat ns c, pe lng toate aceste probleme clasice ce apar n implementarea SGBD, ca n mai toate domeniile (poate doar cu o vitez mult mai mare) i aceast industrie trebuie permanent s se adapteze att la noile cerine ale utilizatorilor, ct i la avansurile tehnologice hard i soft. Considerm c cele mai semnificative tendine ce se manifest azi n industria SGBD sunt urmtoarele: arhitecturile client / server mediile de calcul deschise, distribuite sistemele multiprocesor, cu procesare paralel conceptualizarea orientat obiect integrarea n Internet.
Dei toate acestea depesc cadrul fixat pentru prezenta lucrare, considerm totui util mcar o trecere sumar n revist a lor n continuarea acestui capitol introductiv al ultimei pri.
Arhitecturi Client / Server

Pn acum aproximativ un deceniu, SGBD erau aproape exclusiv proiectate pentru platforme de calcul centralizat, unicalculator, uniprocesor, care nu erau interconectate ntre ele. Dou clase de SGBD, corespunznd celor dou tipuri de platforme de calcul existente pn la acea dat, erau disponibile: off-line (batch, bazate pe job-uri procesate ulterior), rulau pe platforme mari (mainframe, tipic IBM, sub OS, SIRIS sau MVS), folosind cartele perforate, n regim uniutilizator, uniproces; programele nu se executau n timp real, ci erau procesate ulterior, pe baza unui sistem de prioriti. Acest tip de SGBD primitiv mai este nc folosit i azi n lume, nu doar din
considerente de amortizare a investiiilor uriae fcute n echipamente i programe, sau din conservatorism, ci i datorit faptului c prelucrarea batch este n continuare cea mai potrivit pentru aplicaiile de mai lung durat (tip liste de salarii, de stocuri etc.), intensive, ce nu necesit interaciune n timp real i care deci se preteaz la execuia n afara orelor de program ale majoritii utilizatorilor (exemplu: noaptea), cnd resursele sistemului de calcul ar fi, altfel, aproape nefolosite. on-line (asisten decizii, procesare tranzacii n timp real), rulau pe platforme mini (tipic DEC, sub RSX, VMS sau Unix), oferind acces multiutilizator, multiproces, de la mai multe terminale conectate la sistemul de calcul. Acest tip de SGBD este nc majoritar n lume, fiind n continuare folosit de mai toate marile corporaii, de la bnci la uzine, tendina fiind ns de evoluie spre arhitecturi deschise, client / server. Apariia PC-urilor, foarte ieftine i exploziv mai performante an dup an, oferind afiaj n culori, o grafic net superioar, icoane, mouse i lucru n ferestre accesibile nu doar programatorilor de calculatoare, a avut rapid un impact uria i asupra industriei SGBD, ducnd n foarte multe companii (mai ales mici i mijlocii) la desfiinarea departamentelor informatice, la descentralizarea total a procesrii datelor i la angrenarea nespecialitilor n programare n preluarea controlului direct asupra gestiunii datelor. Acestui pionierat n domeniu, nti sub CP/M, apoi DOS i Windows, i-au corespuns SGBD-uri de tip dBase. Foarte repede i nu doar din dorina de a utiliza n comun periferice scumpe (discuri hard de mare capacitate, imprimante laser, scanner, CD-ROM etc.) sau de a comunica ntre PC-uri prin mesaje i pot electronic, ci mai ales pentru integrarea bd, eliminarea redundanelor i accesul partajat la date, PC-urile au fost interconectate nti n reele locale de calculatoare (LAN) i apoi n reele regionale (WAN). n special sub Novell Netware, apoi i sub Windows NT, Windows 95, SunSoft sau Banyan, piaa de SGBD corespunztoare a fost i este nc dominat de FoxPro, Access i Paradox. Acestea pot fi configurate att pentru lucru local, individual, pe un singur PC neconectat n reea, ct i pentru lucrul n reea. Tipic, n acest din urm caz, unul sau mai multe calculatoare din reea sunt configurate ca server, iniial dedicat (de date i/sau de imprimare) iar celelalte drept, clieni cuplai iniial, la un moment dat, la un singur server de date i eventual la unul de imprimare. Ulterior, aceste arhitecturi arborescente iniiale au fost nlocuite cu arhitecturi mai flexibile (punct la punct) n care orice PC poate fi cuplat simultan la orice alt PC, cci fiecare PC poate fi configurat att server ct i client. Necesitatea de a factoriza datele comune ale unei companii i de a asigura accesul rapid la ele, n condiiile n care volumul i structura acestora sunt foarte mari, a condus la apariia de servere SGBD, n general rulnd pe un PC foarte puternic sau, mai ales, pe minicalculatoare, la care sunt cuplate clieni PC ntr-o arhitectur client / server. La un asemenea server (Oracle, Sybase, DB/2, OpenIngres, MS SQL Server etc.), oferind tipic bd relaionale accesabile n SQL (Structured Query Language, Limbaj Structurat de Interogare) sunt cuplabile LAN-uri heterogene din punct de vedere al sistemului de operare n reea i SGBD utilizat (de la Paradox 3.5 sub Novell, la Internet Explorer sub Windows95!). Principalele probleme de implementare relative la arhitecturile client / server sunt legate de: suport pentru diferite interfee de reea unelte i aplicaii de interfa utilizator (front-end) pe calculatoarele client pentru cuplarea la server mecanisme de monitorizare i optimizare a traficului n reea.
Sisteme deschise i bd distribuite

Pn acum un deceniu, ntreprinderile utilizau echipamente de calcul i programe oferite de un unic furnizor (n majoritate, IBM i DEC). ntre timp, oferta de platforme de calcul, reele de calculatoare, sisteme de operare i SGBD s-a diversificat enorm. O mare corporaie folosete azi, de obicei, mai multe SGBD simultan, pe diferite tipuri de calculatoare, aproape toate interconectate, cu mai multe servere SGBD (cte unul per departament sau grup important de departamente i unul sau mai multe centrale, deservind conducerea superioar a corporaiei). Aceste realiti oblig furnizorii de SGBD s asigure portabilitatea lor pe (sau variante dedicate pentru) platforme de calcul multiple, precum i interoperabilitatea ntre produsele proprii i cele similare ale concurenilor. Asemenea sisteme deschise gestioneaz n mod natural baze de date distribuite (bdD) i necesit diverse forme de interfee de acces.
Baze de date distribuite

Bd distribuite sunt, n multe privine, similare arhitecturilor client / server. Ambele abordri implic utilizarea simultan a mai multor sisteme de calcul interconectate, accesul la date aflate la distan i partajarea acestora, precum i procesarea distribuit. Totui exist i diferene importante ntre ele, dintre care dou ni se par eseniale, i anume: n bd distribuite sunt interconectate n reea doar SGBD server (fiecare dintre ele putnd sau nu avea conectai clieni proprii); serverele SGBD interconectate coopereaz ntre ele pentru gestiunea n comun a datelor, pentru accesul utilizatorilor locali la acestea, ca i pentru toate celelalte funciuni SGBD abordate n urmtoarele capitole; cea de-a doua diferen este legat de faptul c arhitecturile distribuite sunt concepute pentru a suporta bd globale, integrate, dei memorarea datelor i procesarea lor poate fi rspndit pe o arie geografic larg i, mai mult, tabelele bd pot fi partiionate (vertical, pe coloane i/sau orizontal, pe linii) ntre servere. Pentru mrirea performanelor, bd distribuite ncearc mereu s exploateze i localitatea accesului la ele. Aceasta presupune copierea (replicarea) unor poriuni ale bd gestionate de orice server distribuit pe alte servere, pentru a micora traficul n reea i a mri disponibilitatea datelor la nivelul local, unde copiile vor putea fi astfel procesate simultan (att n citire, ct i n scriere) de mai multe servere. Mai mult, pentru procesarea tranzaciilor, o bd distribuit poate folosi simultan oricte dintre serverele de SGBD disponibile pentru a optimiza performanele execuiei acestora folosind procesarea paralel. Dual ns, bd distribuite se bazeaz i pe autonomia local a fiecrui server SGBD component. Aceste sisteme sunt proiectate astfel nct administratorii locali de bd pstreaz controlul asupra bd locale corespunztoare, stabilind inclusiv asupra cror poriuni de date ofer acces (i cu ce privilegii) utilizatorilor locali ai altor servere. n plus, nici un server local nu depinde de vreun alt server pentru gestionarea i accesul la datele proprii, permind exploatarea lor chiar dac vreun alt server nu este temporar n serviciu sau dac, din cauza unei cderi a reelei de comunicaii interservere, vreun nod local rmne complet izolat de celelalte servere pentru o perioad de timp. Din punctul de vedere al utilizatorilor ns i, n special, al programatorilor, cea mai important caracteristic a noilor bd distribuite este transparena localizrii, adic obinerea independenei aplicaiilor fa de localizarea la un moment dat a datelor. n aceast abordare a bd distribuite, numit i imaginea unui singur sit (single-site image), distribuirea datelor este complet transparent utilizatorilor; ca atare, de exemplu, se pot muta date de pe un server pe altul fr ca utilizatorii s trebuiasc s tie acest lucru sau s fie n vreun fel afectai.
Principalul mecanism prin care este implementat transparena localizrii este includerea n numele global (systemwide name) al oricrui obiect aflat n gestiunea bd distribuite a locului naterii obiectului, deci a locaiei unde a fost creat iniial, i meninerea informaiilor despre obiect, pe toat durata existenei sale, de ctre SGBD al locului su de natere. Dac un obiect este mutat la o alt locaie, el este luat n eviden i de SGBD al noii locaii (i scos din evidena locului de unde s-a mutat, dac acesta nu este locul su de natere, ntocmai cum procedeaz Birourile de evidena populaiei sau Comisariatele militare!), dar SGBD de la locul naterii memoreaz automat un pointer ctre noua locaie a obiectului (sau l modific pe cel vechi). n fine, bd distribuite permit natural creterea incremental prin adugarea de noi noduri pe msur ce cerinele o impun. De cele mai multe ori, aceast soluie este, de departe, mult mai bun dect upgrade-ul vreunui server existent (ce nu ar putea s nu perturbe mcar o vreme utilizatorii locali ai acelui nod).
Programe interfa de acces

n finalul acestei seciuni sunt necesare i cteva cuvinte despre interfeele (middleware) i porile (gateways) de acces. n general, interfeele de acces (care au aprut la nceputul acestui deceniu) sunt programe care furnizeaz unor aplicaii o interfa consistent la nite servicii suport (ce sunt adesea furnizate de la distan, nu local) protejnd astfel aplicaia de diverse alte interfee native i de o mare parte din complexitatea laborioas impus cel mai adesea de accesul direct la respectivele servicii suport. De exemplu, o interfa de acces ar putea fi responsabil de rutarea unei cereri locale ctre unul sau mai multe servere aflate la distan, de suportul necesar n interaciunea cu diverse protocoale de reea, de eventuala traducere a cererii (de exemplu, dintr-un dialect al SQL n altul), de conversia datelor dintr-un format n altul etc. n particular, n domeniul bd, sunt oferite interfee de acces la date; acestea interfaeaz utilizatorii la diverse surse de date, precum diferite SGBD relaionale, non-relaionale, sau vechi sisteme fiier. Porile de acces sunt strmoii interfeelor de acces; aceste programe, de tip control (software driver), asigur conectivitatea (n general limitat) ntre dou sisteme de programe de tipuri precis definite (dar nu neaprat diferite! vezi, de exemplu, Novell Netware). Ele sunt n continuare folosite ori de cte ori nu exist (sau ar fi prea scump nc apelul la) interfee de acces adecvate.
Medii de procesare paralel

Platformele de calcul multiprocesor se vor impune din ce n ce, inclusiv pe piaa PC-urilor. Principalele avantaje oferite de ele sunt: costul mai redus, la aceeai putere de calcul oferit, n raport cu calculatoarele cu un singur procesor foarte puternic potenialul de scalabilitate inclus (clienii pot achiziiona nti unul sau doar dou procesoare, urmnd ca restul s poat fi achiziionate ulterior, pe msura necesitilor) posibilitatea procesrii paralele, crucial n mrirea performanelor oricrui SGBD gestionnd volume mari de date complex structurate. Procesarea paralel este un domeniu extrem de promitor, dei momentan nu exist prea multe SGBD-uri comerciale capabile de aa ceva. n special bd logice i relaionale ar putea profita din plin de procesarea paralel, n special n cazul volumelor mari de date, deoarece att expresiile logice sau de algebr relaional, ct i coleciile de tabele (i chiar tabelele) pot fi partiionate canonic iar fiecare dintre prile astfel rezultate pot fi ncredinate cte unui procesor pentru execuie simultan. n special bd multimedia (pentru care deja doi productori americani de aplicaii video la cerere au adoptat procesarea paralel!), care presupun gestiunea i accesul unor date avnd dimensiuni extrem de mari, dar i bd uzuale n care concurena tranzaciilor este foarte mare ar avea nevoie stringent de SGBD bazate pe procesare paralel.
Exist trei tipuri fundamentale de arhitecturi hardware multi-procesor (unele platforme comercializate oferind ns i combinaii ntre aceste arhitecturi), clasificate n funcie de resursele partajate de procesoare, fiecare dintre acestea cu avantajele i dezavantajele sale: nimic partajat; discuri partajate; memorie partajat (prin intermediul creia i discurile sunt partajate!).
Arhitecturi fr partajare
Arhitecturile fr partajare implic memorie, discuri, copii de sisteme de operare i SGBD distincte pentru fiecare procesor n parte. Ele formeaz baza sistemelor de procesare paralel masiv, utiliznd deja mii de procesoare ieftine per platform. Avantajul cel mai mare este c scalabilitatea e aproape liniar (adic performanele hardware ale sistemului cresc aproape proporional cu cele ale fiecrui nou procesor instalat). Principalul dezavantaj este ns acela c, software, ncrcarea echilibrat a procesoarelor este foarte greu de realizat (mai ales atunci cnd tranzaciile acceseaz des multe date comune, ceea ce are ca efect imposibilitatea unei partiionri simetrice a datelor i, deci, suprancrcarea unui procesor i nefolosirea celorlalte la puterea lor). n plus, la orice adugare a unui nou procesor datele trebuie repartiionate, iar sistemul de operare trebuie s suporte un trafic de mesaje greu pentru unica comunicaie posibil, cea interprocesoare. De asemenea, cderea unui procesor sau a memoriei sale au ca efect pierderea posibilitii de a mai accesa datele de pe discurile acestuia. Ca remediu, unele platforme ofer salvri interdiscuri precum i procesoare i memorii redundante, de rezerv. De notat n fine c bd distribuite pot fi considerate, n fond, echivalente unor asemenea arhitecturi multiprocesor fr partajare!
Arhitecturi cu discuri partajate

Arhitecturile cu discuri partajate implic doar memorii, copii de sisteme de operare i SGBD distincte pentru fiecare procesor, dar acces partajat la discuri (n general organizate la rndul lor ntr-o reea) printr-un mecanism comun de interconectare a memoriilor la ele. Aceast arhitectur, ce ofer acces concurent al procesoarelor la aceleai date, pune cele mai mari probleme software dintre toate cele trei tipuri fundamentale multi-procesor existente. Deoarece este oricnd posibil ca dou sau mai multe procesoare s acceseze simultan aceleai date de pe disc, pentru a pstra integritatea bd este nevoie de un mecanism global de blocare; acesta este numit gestionarul de blocri distribuit i e folosit n dou scopuri: pentru punerea i scoaterea lactelor (vezi capitolul urmtor) n funcie de starea tranzaciilor executate pe procesoarele concurnd la aceleai date; i pentru gestionarea coerenei zonelor tampon i/sau cache asociate procesoarelor concurente (cci e posibil ca un procesor s rescrie data accesat concurent, care nu va mai coincide cu copiile sale din memoria celorlalte procesoare; pentru sincronizarea lor, toate celelalte procesoare trebuie obligate imediat s reciteasc data respectiv). Principalul avantaj al acestei arhitecturi este c nu e nevoie de nici o partiionare a bd ntre procesoare i deci echilibrarea ncrcrii acestora este mult mai uoar. Scalabilitatea nu mai este ns liniar, iar performanele sistemului se degradeaz ori de cte ori prea multe procesoare au nevoie de access simultan la aceleai date. Unele platforme comerciale ns asigur suport hardware suplimentar pentru gestionarul de blocri distribuit, mrind astfel sensibil performanele sistemului.
10
Arhitecturi cu memorie partajat

Arhitecturile cu memorie partajat implic o unic memorie, oricte discuri partajate prin intermediul acesteia i o singur copie de sistem de operare i de SGBD, ambele ns de tip multiexecuie (multithreaded), singurul tip care poate s suporte i s exploateze un asemenea mediu multiprocesor. Fiecare procesor poate executa orice sarcin; acestea sunt de altfel preluate pe msur ce apar, n ordinea prioritilor ce le sunt asociate, de ctre primul procesor disponibil. Dezavantajele sunt legate de cderea ntregului sistem n cazul oricrei defeciuni a memoriei i de competiia procesoarelor asupra acesteia. Ea nu numai c necesit un mecanism delicat de interconectare a procesoarelor la memorie, dar scade dramatic scalabilitatea: orice nou procesor va interfera cu cele deja existente, ncurcndu-le prin memoria pe care le-o va fura. Ca atare, aceste arhitecturi nu pot practic folosi prea multe procesoare; peste un anumit prag, se nregistreaz o deteriorare continu a performanelor sistemului cu fiecare nou procesor adugat. Singura soluie viabil este cea cu un numr mic de procesoare, toate foarte puternice, ceea ce ns face ca aceast abordare s fie adesea prea scump.
Patru tipuri de cuplare a procesoarelor: strns, lejer, simetric, i asimetric

Arhitecturile cu memorie partajat se mai zic i sisteme strns cuplate. Iniial, doar arhitecturile fr partajare erau referite drept sisteme lejer cuplate, dar n ultimii ani acest calificativ a nceput s fie folosit pentru orice arhitectur n care memoria nu este partajat (incluznd deci i arhitecturile cu discuri partajate). n sfrit, sistemele multiprocesor simetrice (SMP) desemneaz arhitecturi cu memorie partajat (deci strns cuplate) particulare, n care fiecare procesor poate fi capabil s proceseze orice cerere (spre deosebire de cele asimetrice, n care unul sau mai multe procesoare sunt dedicate doar cererilor de un anumit tip).
Procesarea paralel a tranzaciilor i interogrilor

Procesarea paralel a tranzaciilor (zis i paralelism interinterogri) presupune execuia complet a cte unei tranzacii pe cte un procesor. Mult mai interesant este ns procesarea paralel a interogrilor (zis i paralelism intrainterogare) n care mai multe procesoare concur simultan la execuia unei singure interogri dintr-o tranzacie. Acest tip de paralelism se folosete pentru aplicaii de tip suport decizii care includ interogri complexe, doar n citire ns, implicnd join-uri multitabele. Sunt uzuale dou tipuri de abordri ale acestui paralelism: fiecare procesor execut aceeai cerere, dar asupra unei alte poriuni a datelor; interogarea este subdivizat n subinterogri i fiecare procesor execut cte una dintre acestea. Prima abordare este, pn n acest moment, cea mai rspndit n majoritatea sistemelor paralele comerciale. n esen, ea implic o partiionare prealabil adecvat a datelor (iar pentru join - i replicarea celor mai mici tabele dac discurile nu sunt partajate), procesarea paralel a interogrii i o reuniune final a rezultatelor pariale obinute de fiecare procesor n parte. Al doilea tip de abordare este abia la nceput, deoarece necesit un SGBD mult mai puternic, capabil de descompunerea optimizat a interogrilor pentru platforme multiprocesor. n plus, lucrurile se complic foarte mult n cazul arhitecturilor fr partajare, cci este nevoie ori de o optimizare global, ori de distribuirea optimizrii ntre procesoare, provocare ce nc constituie o problem deschis n domeniu.
11
Procesarea paralel a indexurilor i a programelor utilitare

Unele SGBD evoluate adaug alte tipuri de procesri paralele la cele dou descrise mai sus; dintre acestea, cele mai importante sunt procesarea paralel a indexurilor i cea a programelor utilitare. Ambele ofer o vitez sensibil mai mare n multe cazuri. Astfel, de exemplu, foarte multe tabele au mai mult de o coloan pentru care se menine un index; cum indexurile trebuie actualizate pentru fiecare actualizare a datelor, un astfel de SGBD va memora diferitele indexuri ai unei tabele pe discuri diferite putnd astfel s le actualizeze n paralel, prin folosirea a cte unui procesor per index. Similar, pentru tabele indexate foarte mari, indexurile sunt partiionate pe mai multe discuri, ceea ce permite chiar citirea lor n paralel (pentru o interogare, de exemplu). Utilitarele pot fi i ele executate n paralel (ntre ele sau cu alte tranzacii); de exemplu, salvrile, replicrile, ncrcarea datelor ntr-o tabel vid, reorganizarea unei bd, recuperarea din eroare, actualizarea cataloagelor de statistici etc. se preteaz cel mai adesea la procesri paralele. Dup o cdere de tensiune, de exemplu, ntr-o arhitectur fr partajare, fiecare procesor poate efectua n paralel cu celelalte recuperarea proprie din eroare.
Sisteme orientate obiect

Schimbrile survenite n domeniul inteligenei artificiale i limbajelor de programare odat cu introducerea conceptualizrilor orientate obiect ncep s aib impact nu doar asupra SGBD academice; primii pai pe piaa SGBD comerciale orientate obiect, chiar dac nc timizi, au fost deja fcui. SGBD orientate obiect (pure) difer esenial de cele relaionale n foarte multe privine. Prima dintre ele este desigur segmentul de pia vizat: n timp ce SGBD relaionale au fost concepute, n esen, pentru a susine aplicaii economico-financiare, SGBD obiectuale sunt mai degrab proiectate pentru aplicaii CAD/CAM, CAP, CASE (i.e. aplicaii asistate de calculator n domeniile proiectrii, publicisticii i ingineriei software). De aici rezult imediat cteva diferene cheie ntre condiiile pe care trebuie s le satisfac cele dou tipuri de abordri. Astfel, SGBD relaionale trebuie s fac fa urmtoarelor provocri: tipurile de date sunt foarte simple, puine i mereu aceleai (iruri de caractere, numere, date calendaristice, constante Boolene); tabela este singura structur de date necesar; tranzaciile sunt n majoritate scurte (n medie, sub un minut!) iar cele mai lungi sunt doar de ordinul ctorva ore; ns timpul de rspuns este cel mai adesea critic; interogrile sunt extrem de frecvente i imprevizibile (att ca expresie, ct i ca moment al lansrii cererii); concurena este foarte mare (ajungndu-se pn la mii de utilizatori simultani cernd acces la o aceeai dat); sunt necesare foarte multe tipuri de aplicaii i unelte de lucru pentru categorii foarte diferite de utilizatori, n majoritate nespecialiti n programare (operatori, personal cu funcii de conducere la nivel operativ, mediu, directori, asociai etc.) dar i administratori de bd i programatori specialiti (pentru care este important i cuplarea la ct mai multe limbaje de programare); robusteea facilitilor sistem pentru securitatea accesului la date, recuperarea din eroare, disponibilitatea bd i optimizarea performanelor este crucial; trebuie avute n vedere (i interconectate) toate platformele de calcul cu putin, de la calculatoare portabile pn la mainframes. Prin contrast, SGBD obiectuale trebuie s rspund la alt tip de provocri, i anume: sunt necesare tipuri i structuri de date foarte complexe, imprevizibile (utilizatorii trebuie s-i poat mereu defini altele noi); tranzaciile dureaz cel puin cteva ore, media ns fiind de sptmni! Ele trebuie ntrerupte i reluate cel puin zilnic; natura lucrului este iterativ, implicnd adesea renunarea la o parte din lucru i reluarea acestuia ntr-o alt variant (fie c este vorba de proiectul pentru o cldire, un cip, o instalaie industrial, o revist sau un SGBD!); este necesar memorarea i
12
prelucrarea mai multor versiuni ale obiectelor; dei foarte important, timpul de rspuns nu este critic; interogrile sunt mai rare i foarte previzibile; concurena este mult mai mic (civa proiectani, maxim zeci); sunt necesare foarte multe unelte de lucru performante dar strict pentru specialiti n timp ce eventualele unelte pentru alte categorii de utilizatori nu prea au mare importan; n schimb, este esenial cuplarea cu un limbaj de programare orientat obiect; facilitile de securitate, recuperare din eroare, disponibilitate etc. nu sunt att de importante; n general, platformele de lucru folosite sunt doar staii de lucru (sau PC foarte performante) interconectate ntr-un LAN sau cuplate la un SGBD server ntr-o arhitectur client / server.
n esen, se poate spune c SGBD obiectuale (SGBDO) sunt o extensie a limbajelor de programare orientate obiect (LPOO) prin asigurarea persistenei (memorarea pe disc dup terminarea programelor, n locul uciderii) obiectelor i partajabilitii lor ntre utilizatori concureni. Astfel, SGBDO motenesc flexibilitatea i bogia semantic a LPOO; preul ce trebuie pltit este ns dublu: pe de-o parte, specificarea iniial a structurii bd, ca i programarea ulterioar a tranzaciilor (care se face, tipic, n C++ nu n SQL!) sunt mult mai laborioase iar pe de alta, utilizatorii SGBDO trebuie s fie mult mai buni specialiti n programarea calculatoarelor dect cei ai SGBD relaionale.
Gestiunea obiectelor persistente n arhitecturi client / server

Multe dintre SGBDO se bazeaz pe o arhitectur client / server; pentru a mri performanele ns se ncearc minimizarea activitilor server-ului i maximizarea lucrului local, pe staiile client. Una dintre cele mai importante probleme de implementarea SGBDO este gestiunea obiectelor persistente pe aceste staii. Majoritatea SGBDO abordeaz aceast problem cu ajutorul cte unei tabele a obiectelor rezidente (n memorie) per client (TOR); fiecare rnd al unei asemenea tabele, ce corespunde cte unui obiect, are dou coloane: identificatorul obiectului i adresa din memorie la care rezid descriptorul su (acesta, la rndul lui, memoreaz desigur i adresa la care rezid obiectul propriu-zis). nlnuirea obiectelor este implementat cu ajutorul pointerilor astfel: descrierea fiecrui obiect conine un pointer ctre descriptorul urmtorului obiect din lan; figura 9.1 ilustreaz un TOR. Aceast abordare nu este doar dictat de swapping (vezi mai jos), ci i de considerente de performan: n asemenea SGBDO, rezultatul oricrei interogri, de exemplu, este o mulime de descriptori (i nu mulimea obiectelor propriu-zise) nu doar pentru c memoria ocupat de obiecte este, de obicei, mult mai mare dect cea necesar descriptorilor, dar i pentru c, cel mai adesea, aplicaiile nu au efectiv nevoie de toate obiectele sau, mcar, nu de toate odat. Atunci cnd SGBDO primete o cerere de acces la un obiect persistent al bd, el consult TOR (meninut n memoria RAM) pentru a determina dac obiectul este deja rezident n memorie sau nu. Pentru mrirea vitezei de cutare n tabel, aceasta este, de obicei, de tip hashed (talme-balme, vezi capitolul 14) pe identificatorul obiectelor. Dac obiectul cutat nu exist n tabel (este deci prima cerere de acces la el), SGBDO l cere server-ului, l convertete din formatul disc n cel memorie (de obicei aceste formate difer), i gsete loc n RAM unde l i ncarc, i construiete un descriptor i adaug o linie corespunztoare n TOR. Drept urmare, un asemenea server se zice i server obiect (cci unitatea de transfer cu clienii este un obiect). Dac, la un moment dat, gestionarul memoriei virtuale la dispoziia SGBDO are nevoie de mai mult memorie RAM dect a mai rmas disponibil, el alege (conform unei strategii de tip cel mai rar accesat, cel care nu a mai fost accesat de cel mai mult timp sau n cerc (round-robin) etc.) unul sau mai multe obiecte rezidente pe care le mut ntr-un fiier temporar disc (swapping) elibernd astfel memoria necesar. Descriptorii obiectelor astfel evacuate temporar din RAM rmn n memorie, dar pointerul lor ctre obiectul propriu-zis corespunztor este anulat (devine nil). Ulterior, la o nou cerere de acces la un asemenea obiect, SGBDO l va rencrca n RAM din fiierul disc temporar, fr nici un acces la server.
13
Un alt tip de implementare, mai nou, este cel folosit de serverele pagin. La acestea, formatul de memorare al obiectelor este acelai pe disc i n memoria RAM; transferul ntre server i clieni se face nu la nivel de obiect ci de pagin (care, de obicei, conine mult mai multe obiecte); nu mai exist TOR, ci doar o zon a memoriei virtuale a fiecrui client n care sunt memorate pagini de obiecte; n cazul n care se ncearc accesul la un obiect inexistent n aceast memorie, SGBDO proceseaz o capcan de pagin ce are ca efect aducerea de pe server a paginii ce conine obiectul respectiv; nu se mai folosesc descriptori de obiecte, toi pointerii indicnd obiectele direct; ca atare, atunci cnd obiectele sunt mutate n alt zon a memoriei virtuale (de exemplu, ca efect al swapping-ului), pointerii spre ele trebuie actualizai corespunztor. Desigur c, pentru anumite bd (n care o pagin conine mai multe obiecte) aceast abordare este mai performant, att datorit minimizrii transferurilor client / server, ct i prin eliminarea indirectrii referinelor la obiecte prin descriptori.
Cerere de acces la obiectul O Tabela Obiectelor Rezidente (TOR) ID_X ... Descriptor_X Obiectul X
Descriptor_O ID_O ... Obiectul O
ID_Y ...
Descriptor_Y
Obiectul Y
Figura 9.1 Un exemplu de memorare a obiectelor persistente nlnuite
Un exemplu de bd orientat obiect

Exemplificm abordarea orientat obiect a bd cu ajutorul SGBDO ObjectStore (al firmei Object Design, Inc.) ce se bazeaz pe C++. Cu ajutorul bibliotecii C++ Library Interface furnizate de acest SGBDO, vom crea o clas simpl numit colecie i vom scrie apoi un program care creaz instane persistente ale acestei clase. Instruciunile suplimentare ale SGBDO care nu exist n C++ vor fi scrise ngroat n acest exemplu numai pentru a le scoate n eviden. Orice element dintr-o colecie (o mulime ce admite duplicate!) este caracterizat simplu, doar de un identificator id_ob i un nume, plus un pointer urm_ob ctre urmtorul obiect al coleciei. Funciile membre ale acestei clase sunt i ele reduse la minim: un constructor (pentru crearea de noi obiecte membre ale coleciei); un destructor (pentru eliminarea unui obiect din colecie); i un vizualizator (pe ecran, al datelor despre un obiect). Declaraia colecie astfel definit este prezentat n figura 9.2. De remarcat n corpul constructorului c, dup asignarea primului i ultimului parametru (componentelor id_ob i, respectiv, urm_ob), este nti nevoie de a calcula lungimea celui de-al doilea parametru (numele obiectului) i de a aloca spaiul corespunztor pentru el, instruind ObjectStore s memoreze
14
aceast informaie n acelai segment al bd cu restul obiectului (lucru realizat de o form suprancrcat a operatorului C++ new) nainte de a copia al doilea parametru n nume. Figura 9.3 prezint un program simplu ce creeaz obiecte persistente nlnuite ale coleciei astfel definite i le afieaz. SGBDO ObjectStore deschide o bd anume (/u/guest/testdb, convenia de numire folosit conformndu-se standardului Unix); dup ce se obine de la utilizator numrul dorit de obiecte, SGBDO lanseaz o tranzacie de actualizare date (update) i se verific dac exist deja creat o rdcin (punct de intrare) pentru lista nlnuit a obiectelor coleciei; n caz contrar, se creeaz o asemenea rdcin. Dup crearea i listarea instanelor create, sunt nchise tranzacia de actualizare i bd.
Integrarea n Internet
Cea mai fascinant pagin din cte se scriu probabil n aceast perioad n domeniul tiinei calculatoarelor este probabil cea referitoare la spaiul cibernetic asociat Internet-ului. Chiar dac acest subiect depete cu mult cadrul prezentei lucrri, am dori s menionm totui cele trei provocri majore pe care considerm c Internet le adreseaz SGBD: SGBD multimedia, pentru gestiunea nu doar a datelor numerice, text i Boolene, ci i a celor audio-video; SGBD gestionnd meta-date, despre ierarhiile laticeale de date disponibile n Internet (structurare, ci de acces, eventual rezumate); mecanisme de fluidizare a traficului n reea i de garantare a accesului i optimizare a costului acestuia, n orice moment, la orice resurs de date, de la orice post de lucru conectat. Desigur c fiecare dintre acestea n parte au fost deja abordate de industria SGBD, dar nu nc sistematic i masiv n contextul Internet, care, prin complexitatea, vastitatea, lipsa de omogenitate i viteza exploziv de dezvoltare (Japonia a nceput comercializarea pe piaa sa a televizoarelor Sanyo, Mitsubishi i Sharp direct conectabile la Internet!) modific de cele mai multe ori n chip radical datele problemelor de proiectare i implementare aferente. Astfel, de exemplu, n SUA sunt deja operaionale de civa ani SGBD multimedia de tip filme la cerere (video-on-demand) prin care companii de televiziune prin cablu ofer abonailor nu doar filme preprogramate de compania respectiv, ci le permit acestora s-i aleag dintr-o bd de filme ce programe doresc fiecare s vizioneze i la ce or anume! Despre meta-date vom vorbi mai n amnunt, dar doar n contextul SGBD, n capitolul 16. La fel, despre fluidizarea traficului n reele de calculatoare, despre garantarea accesului la date i optimizarea acestuia n condiii de concuren vom discuta n urmtoarele capitole, dar, iari, din pcate, nu i n contextul Internet-ului. nc o dovad (dac mai era nevoie!) c viteza de evoluie n domeniul acesta este extraordinar o constituie lansarea recent pe pia (dup redactarea lucrrii, dar nainte de susinerea ei!) de ctre Microsoft a pachetului Office97, proiectat i realizat folosind tehnologiile Internet (format HTML, hiperlegturi, navigare Web etc.) pentru cuplarea oricrui PC la Internet, din orice component a sa, inclusiv din SGBD Access97. Principala caracteristic remarcabil a acestei noi versiuni este aceea c utilizatorii PC pot crea pagini Web coninnd imagini active ale datelor, astfel nct navigatoarele Web pot actualiza, terge sau aduga informaii. n plus, datele pot fi sincronizate prin replicare ntre calculatoarele conectate, astfel nct ultima lor versiune s fie tuturor accesibil rapid. ntr-un viitor extrem de apropiat, ntreaga planet va fi acoperit de o unic bd distribuit, plin cu PC-uri nu doar client ci i server de date! Mai mult, tehnologia Internet este, prin Office97, disponibil i n LAN (referite acum ca Intranet) fa de care nu mai exist, practic, nici o diferen!
15
// Fiier antet pentru clasa colecie // antete fiier I/O C++ i ObjectStore #include <iostream.h> #include < ostore/ostore.hh> class colecie public: // date membru publice int id_ob; // identificator obiect char *nume; // pointer ctre numele obiect colecie *urm_ob; // pointer ctre urmtorul obiect al coleciei // funcii (metode) membru publice colecie(const int, char*, colecie*); // constructorul de obiecte ~colecie(); // destructorul de obiecte void afieaz(); // vizualizatorul obiectelor instaniate ; // corpul funciilor membru publice // creare specificaii de tip pentru ObjectStore (obligatorii pentru toate // tipurile/clasele pentru care se cere instanierea de obiecte persistente) extern os_typespec char_type; // constructorul de noi instane ale coleciei colecie::colecie(const int num, char *nume, colecie *next) id_ob = num; urm_ob = next; // aloc spaiu pentru nume i copiaz-l int lung = strlen(nume)+1; thisnume = new(os_segment::of(this), lung, &char_type) char[lung]; strcpy(thisnume, nume); // destructorul dual colecie::~colecie() // terge spaiul alocat obiectului nume delete nume; // afieaz pe ecran informaiile despre un obiect void colecie::afieaz() cout << ID obiect: << id_ob << \t << Nume: << nume << endl;
Figura 9.2 Declaraia unei clase colecie n SGBDO ObjectStore (colecie.hh)
16
// Exemplu de program pentru crearea i afiarea unei colecii nlnuite de obiecte. // ObjectStore este folosit pentru asigurarea persistenei obiectelor create. #include colecie.hh os_typespec char_type(char); main() // declaraia clasei colecie
// iniializare variabile colecie *head = 0; // capul listei nlnuite de obiecte int numr = 0; // numrul de ID obiect char nume_ob[32]; // vector pentru numele obiect int total = 0; // numrul total de obiecte os_database *db1 = 0; // pointer la o bd ObjectStore os_database_root *root = 0; // pointer la o rdcin ObjectStore os_typespec col_type(colecie) objectstore::initialize(); db1 = os_database::open(/u/guest/testdb, 0, 0666); // cere numrul de obiecte dorite cout << Specificai numrul de instane dorite pentru colecie: << endl; cin >> total; OS_BEGIN_TXN(t1, 0, os_transaction::update) root = db1find_root(col_root); if (!root) root = db1create_root(col_root); head = (colecie*)rootget_value(); // creaz obiectele for (int i = 0; i < total; i++) cout << Specificai ID urmtorului obiect dorit: << endl; cin >> numr; cout << Specificai numele urmtorului obiect dorit: << endl; cin >> nume_ob; head = new(db1, 1, &col_type) colecie(numr, nume_ob, head); rootset_value(head); // afieaz toate obiectele coleciei cout << Lista tuturor obiectelor coleciei create: << endl; for (colecie* e = head; e; e = eurm_ob) eafieaz(); OS_END_TXN(t1) db1close();
Figura 9.3 Program ObjectStore pentru crearea i afiarea de obiecte persistente
17
Cinci exemple de SGBD celebre

Ambiia acestei pri a lucrrii de a schia, pe lng componentele i funciile clasice ale oricrui SGBD, i tendinele actuale n aceast industrie a avut i efectul limitrii investigaiilor noastre la doar cteva SGBD comerciale evoluate pentru ilustrarea teoriilor n domeniu. Ne-am oprit astfel, n esen, la 5 asemenea sisteme, de altfel printre cele mai cunoscute, vndute i utilizate n lume n acest moment i anume: DB2 (al IBM), Oracle (al Oracle), SQL Server (al Sybase), NonStop SQL (al Tandem) i CA-OpenIngres (acum al Computer Associates). n aceast seciune prezentm doar cte o vedere de ansamblu asupra lor; ultima seciune (de comentarii i referine bibliografice) a fiecrui capitol din aceast ultim parte este n principal dedicat modului n care sunt implementate considerentele teoretice dezvoltate anterior n aceste SGBD celebre. Pe lng acestea, sporadic, apar i referiri la Microsoft SQL Server [262], Microsoft Access95 [154,259], Microsoft Visual FoxPro [261] i Borland Paradox [74,255].
DATABASE2 (DB2) MVS / ESA versiunile 3 i 4 ale IBM

Cel mai rspndit i celebru SGBD din lume rmne deocamdat DATABASE2 (DB2) al IBM, lansat n 1983. Din aceast familie de produse (pentru diverse platforme de calcul) am ales pentru analiza noastr versiunea de vrf, pentru calculatoare mari (mainframes) proiectat a rula sub sistemul de operare MVS / ESA (n afar de aceast versiune complet a produsului, familia mai cuprinde nc 6 membri: DB2/2, pentru OS/2; DB2/6000, pentru AIX; DB2 pentru VM i VSE, adic fostul SQL/DS; DB2/400, pentru OS/400; DB2/HP/UX, pentru Unix-ul HP; i DB2 pentru Sun Solaris). E.F. Codd, printele modelului relaional al datelor (perioad n care era cercettor al IBM!), este i printele DB2, chiar dac indirect, prin prototipul System R. DB2 este un SGBD complet, ncorpornd toate funciunile cunoscute n domeniu, nclusiv distribuirea datelor i procesarea paralel. Informaiile furnizate n aceast a treia parte se refer la versiunea 3, curent n acest moment, dar sunt incluse i principalele mbuntiri anunate pentru versiunea 4 ce abia a fost lansat comercial. Trebuie notat i faptul, deloc neglijabil, c DB2 este oferit de IBM mpreun cu familii ntregi de utilitare i de alte produse IBM cu care DB2 coopereaz: compilatoare i interpretoare pentru aproape o duzin de limbaje de programare (vezi capitolul 17), aplicaii de tip suport decizii (gestionarul interogrilor, vizualizatorul datelor etc.), instrumente de asisten a dezvoltrii aplicaiilor (VisualGen, VisualAge), unelte pentru administratorii de sistem (DataHub, DB2PM, Estimator, DFSMS, RACF etc.) etc. n plus, o ntreag industrie complementar graviteaz n jurul DB2 (al IBM n general!) oferind diverse alte produse ale altor firme, att completnd (sau chiar concurnd) cele ale IBM, ct i oferind alte tipuri de aplicaii, unelte i conectivitate.
Oracle 7.1 al Oracle

Principalul concurent tradiional al IBM rmne Oracle, prima companie care a oferit pieei un SGBD comercial (n 1979, pentru VAX/VMS). Fondat n 1977 n California, micua firm de atunci a evoluat rapid ajungnd unul din cei mai mari productori mondiali de software, ale crui sisteme au fost realizate pentru i ruleaz nc pe mai mult de 80 de tipuri de platforme de calcul diferite. DEC, Sun i Sequent sunt cei mai mari productori de echipamente cu care Oracle are semnate contracte de colaborare permanente. i SGBD Oracle este bazat pe cercetrile Dr. E.F. Codd i ale colegilor si de la IBM, fiind centrat n jurul SQL. Analiza noastr are n vedere versiunea curent, 7.1, a serverului Oracle; acesta poate fi achiziionat singur sau mpreun cu opiunile pentru bd distribuite (Distributed Option) i/sau pentru medii de procesare paralel (Parallel Server Option i Parallel Query Option). i SGBD Oracle este furnizat n centrul a numeroase familii de produse complementare ale firmei Oracle i ale altor furnizori
18
de software. Mai interesant n aceast privin este ns Cooperative Development Environment (CDE) ce reprezint ncercarea Oracle de a furniza o mulime de oferte integrate care s acopere ntreg ciclul de via al dezvoltrii aplicaiilor.
SQL Server 10.0 al Sybase

Dac Oracle rmne principalul competitor al IBM n Europa, poziia sa de secund pe piaa S.U.A. a fost luat n ultimii ani de SGBD SQL Server al companiei americane Sybase. Fondat n 1984, ea a oferit pieei abia n 1987 prima versiune a acestui SGBD relaional pentru arhitecturi client / server i cu extensii orientate obiect, care poate rula pe diverse versiuni de Unix, OS/2, VMS, Netware .a. Principala opiune curent n afar de Secure Server (vezi capitolul 12) este Navigation Server, o extensie exploatnd procesarea paralel pe platforme NCR 3600. Pe lng acestea, sunt livrabile diferite alte pachete de aplicaii i utilitare. Versiunea curent a sistemului este 10.0. SQL Server al Sybase a fost folosit, prin contract, pn n 1994 i de Microsoft (nti doar sub OS/2, apoi i pentru Windows NT). De atunci, ntre cele dou companii a intervenit competiia, Microsoft achiziionnd patentul versiunii 4.2 i ncepnd modificrile i dezvoltarea unui Microsoft SQL Server propriu.
NonStop SQL / MP al Tandem

Fondat n 1974, Tandem a oferit la nceput doar platforme hardware cu componente redundante i software asociat pentru asigurarea unei nalte tolerane la erori. Pe parcurs, firma s-a specializat n arhitecturi pentru procesri paralele masive, multi-procesor (minim 2, maxim 16 procesoare) cuplate lejer, fiind celebre familiile Integrity i Himalaya; ultima dintre acestea este proiectat n plus pentru sisteme distribuite, permind cuplarea de 256 astfel de servere (fiecare avnd maxim 16 procesoare) ntr-un singur LAN sau WAN. Platformele Himalaya beneficiaz de un sistem de operare propriu, NonStop Kernel, care suport propriul SGBD lansat n 1987 (i ajuns acum la a treia generaie) NonStop SQL / MP. Celelalte platforme Tandem sunt proiectate, n general, pentru Unix, compania avnd contracte de colaborare i vnzri pentru ele cu muli productori celebri de software, dintre care se detaeaz Oracle, Informix i Sybase. NonStop SQL este unul dintre cele mai moderne i performante SGBD relaionale de pe pia, proiectat i construit pentru medii distribuite formate din noduri de calcul cu procesare paralel. El include o interfa conversaional pentru SQL (SQLCI) i suport pentru C, Pascal i COBOL. Firma mai ofer utilitare pentru administrarea sistemului, precum i faciliti reea, inclusiv gateways ctre Oracle, Sybase i Windows. Muli ali furnizori de software ofer produse suplimentare pentru NonStop SQL.
CA-OpenIngres al Computer Associates

Al doilea SGBD relaional important n ordinea lansrii pe pia a fost Ingres, comercializat ncepnd cu 1981 de firma Relational Technology Inc., fondat de nii autorii proiectului Ingres, cercettori la Berkeley sub conducerea lui Michael Stonebraker. Bazat tot pe teoria genialului E.F. Codd, Ingres nu a folosit ns abordarea algebric relaional (ce fundamenteaz SQL), ci calculul relaional predicativ al tuplilor; acesta a fundamentat limbajul QUEL, dezvoltat de Stonebraker i compania, n jurul cruia graviteaz nc Ingres (dei, ntre timp, sistemul ofer i SQL). Redenumit ulterior Ingres, Relational Technology este achiziionat n 1990 de grupul ASK (specializat n software pentru industria constructoare de maini). Din 1994, ASK Ingres a fost cumprat de puternicul concern Computer Associates. Acum numit CA-OpenIngres, acest SGBD ruleaz pe mai mult de 35 de tipuri de platforme hardware, n marea majoritate ns sub Unix i VMS. El include faciliti client / server i de bd distribuite
19
(prin interfaa Ingres / Net), plus The Knowledge Manager, care asigur mecanisme de controlul integritii datelor i utilizrii resurselor. Opiunea Object Manager, orientat obiect, ofer posibilitatea definirii de tipuri de date i metode utilizator. Informaiile din aceast ultim parte se refer la versiunile curente ale tuturor acestor componente i n special la versiunea R6.4 a motorului Ingres / Star al SGBD.
Comentarii i referine bibliografice

Literatura de specialitate abund n monografii dedicate att aspectelor teoretice, ct i celor de implementare ale SGBD. Dintre acestea menionm lucrrile de referin pe care le datorm celebrilor Ullman [336,337], Date [122,123] sau Papadimitriou [276], dar i monografii mai noi, precum cele de Gray i Reuter [166], Bontempo i Saracco [73] sau ElMasri i Navathe [133]. Dintre articolele specializate privitoare la arhitecturi client / server, recomandm pe cele din 1994 ale lui David Linthicum [227,228]. Din multitudinea de texte privitoare la sisteme deschise i bd distribuite, semnalm excelentele contribuii ale lui Bernstein [65] i ale IBM Corp. [179,180]. Pentru mediile de procesare paralel, Hsiao [174] i, din nou, o echipa IBM [265] reprezint certe autoriti n domeniu. SGBD orientate obiect sunt analizate n profunzime de cteva texte de referin, dintre care se disting contribuiile lui Kemper i Moerkotte [196], Stonebraker [325] i Jacobson and al. [186]. Extinderea modelului relaional i abordrile hibride iniiale (exemplu: proceduri memorate, trgaciuri, cmpuri foarte lungi sau BLOBs, tipuri de date i funcii definite de utilizator) propuse de POSTGRES [326] sau Starburst [233] au fundamentat SGBDO comerciale Illustra [325], respectiv DB/2 (chiar dac acesta din urm ncorporeaz doar cteva din caracteristicile Starburst). O abordare diferit ofer OpenODB [15] dezvoltat de Hewlett-Packard, care suprapune un strat de gestiune a obiectelor peste un SGBD pur relaional. Stratul orientat obiect suport un mnunchi de limbaje de programare extrem de heterogen, alctuit din aproape toate limbajele ce nc subzist pe pia (Fortran, COBOL, alturi de Pascal, C i C++) i folosete o interfa SQL orientat obiect. Dintre conceptele orientate obiect, OpenODB ofer tipurile de date utilizator, ierarhii de clase, motenire multipl i suprancrcare. Cadrul restrns al acestei lucrri nu permite tratarea n mai mare detaliu a abordrilor orientate obiect existente n acest domeniu n care, deocamdat, lipsete vreun model unitar sau vreo standardizare. Totui, n 1993, un numr de companii importante n domeniu (incluznd Object Design, Ontos, OS2 Technology, Objectivity i Versant) au format Object Database Management Group cu scopul de a schia un standard pentru un model obiectual al datelor i un limbaj de programare pentru SGBD orientate obiect [29]. Acestea includ limbaje de definire i manipulare a obiectelor, un limbaj nonprocedural de interogare obiectual (parial bazat pe SQL) i puni de legtur ctre Smaltalk i C++. SGBD ObjectStore cu care am exemplificat abordarea orientat obiect n subseciunea 9.6.2 este descris n [220]. Despre Internet curge probabil deja n lume un fluviu de cri i articole! Dintre ele, recomandm mcar [188]. Pentru informaiile referitoare la cele 5 SGBD celebre analizate n partea a treia a lucrrii, am apelat la urmtoarele surse bibliografice: pentru DB2, [104, 116, 122, 167, 180] pentru Oracle, [273] pentru SQL Server al Sybase, [327] pentru NonStop SQL al Tandem, [328] pentru CA-OpenIngres, [323]
20
2. CONTROLUL CONCURENEI
Lacte
Gestiunea accesului concurent la bd de ctre mai muli utilizatori simultan trebuie s garanteze consistena i integritatea datelor. Cel mai simplu mod de a le asigura este, evident, serializarea tranzaciilor, adic punerea ntr-o coad de ateptare a tuturor tranzaciilor i execuia lor pe rnd, una cte una (ntr-o ordine oarecare, bazat, de exemplu, pe prioriti i ordinea cronologic de lansare), pe msur ce execuia tranzaciiilor precedente se ncheie. Aceast strategie de implementare a controlului concurenei nu poate fi ns aplicat de nici un SGBD din cauza performanelor complet neacceptabile ce ar fi astfel oferite. Pentru a rezolva problema concurenei, SGBD controleaz traficul tranzaciilor folosind un mecanism de sincronizare software numit lact. Un lact este asociat unei date (structurate, de obicei rnd de tabel sau tabel ntreag) pentru a-i indica starea curent i a asista astfel sistemul n a decide dac acea dat este sau nu disponibil la un moment dat pentru un anumit tip de operaie (exemplu: modificare). Folosind lactele, SGBD ncearc mereu s asigure performane ct mai mari ale sistemului, fr a se altera datele bd (i.e. fr a se pierde actualizri, de exemplu permind unei tranzacii s rescrie sau s invalideze modificrile efectuate de o alt tranzacie). Exemplul 10.1 De exemplu, s considerm o firm cu doi asociai i un singur cont n banc. ntr-o zi, n care, de exemplu, soldul contului este de 1.000.000 lei, simultan, ambii asociai se duc fiecare la cte o alt sucursal a bncii care le gestioneaz contul, primul dorind s fac o plat prin banc de 500.000 lei, iar al doilea dorind s retrag din cont 300.000 lei. Dei este evident c, dac cele dou tranzacii sunt corect serializate, la sfritul lor soldul contului ar trebui s fie de 200.000 lei, n absena unui mecanism de control al concurenei de tipul lactelor soldul final ar putea fi incorect, de exemplu, n urmtoarea situaie: 1. Funcionarul primei sucursale citete din bd soldul de 1.000.000 al contului. 2. Funcionarul celei de-a doua sucursale citete din bd soldul de 1.000.000 al contului. 3. Funcionarul primei sucursale opereaz plata de 500.000 i scrie soldul final de 500.000 (1.000.000 - 500.000). 4. Funcionarul celei de-a doua sucursale opereaz retragerea de 300.000 i scrie soldul final de 700.000 (1.000.000 - 300.000). n acest mod, rezultatul primei tranzacii s-a pierdut, cci cea de-a doua a rescris-o! n majoritatea SGBD moderne, lactele sunt puse i scoase automat de sistem, fiind deci transparente utilizatorilor. Deoarece acest lucru nc ar putea conduce, n anumite situaii, la ineficiena sistemului, se permite i programatorilor s controleze lactele prin instruciuni dedicate de punere i scoatere a acestora. Pentru atingerea unui compromis ct mai acceptabil ntre controlul automat i cel manual, sunt practic utilizate mai multe tipuri de lacte iar datele sunt blocate cu lacte pe mai multe niveluri, aa cum se va vedea n subseciunile urmtoare.
Cele dou tipuri fundamentale de lacte: partajabil i exclusiv

Principalele dou tipuri de lacte oferite de aproape orice SGBD sunt partajabil i exclusiv. Lactele partajabile sunt asociate cu operaiile de citire; datele blocate cu un asemenea lact pot fi citite simultan de oricte tranzacii concurente. Lactele exclusive sunt asociate operaiilor de scriere; doar o singur tranzacie (cea care a reuit s le blocheze exclusiv) are acces la aceste date, toate celelalte tranzacii concurente neavnd nici mcar dreptul de citire. Lactele exclusive sunt deci incompatibile cu
21
orice alte lacte, n sensul c o tranzacie nu poate pune un asemenea lact pe nite date, dect dup scoaterea tuturor altor lacte de pe acele date. Lactele partajabile sunt compatibile ntre ele, adic orice tranzacie poate pune un asemenea lact pe nite date care mai sunt deja blocate de alte tranzacii, tot cu lacte partajabile. Figura 9.1 prezint un exemplu de control al concurenei mai multor tranzacii folosind lacte partajabile i exclusive. Diverse SGBD comerciale ofer i alte tipuri de lacte n afara acestora dou fundamentale deja discutate; cteva dintre ele vor fi trecute n revist n ultima seciune, de comentarii, a acestui capitol.
Granularitatea
Pe lng diversele tipuri de lacte oferite, SGBD asigur i diferite niveluri de control al blocrii datelor. Acestea determin granularitatea lactelor suportate de sistem, care poate varia de la o ntreag bd, la un fiier sau un articol dintr-un fiier. Diverse tipuri de lacte pot fi folosite pe diverse niveluri de granularitate.
Momente de timp t1 EVENIMENTE UTILIZATOREVENIMENTE SGBD ncepe tranzacia 1. Cerere de citire data A. Tranzacia 1 citete A. ncepe tranzacia 2. Cerere de citire data A. Tranzacia 2 citete A. ncepe tranzacia 3. Cerere de modificare A. Verific starea de blocare a lui A. Cum nici un lact nu e pus, se garanteaz un lact partajabil pentru tranzacia 1. Verific starea de blocare a lui A. A fiind blocat partajabil, se garanteaz un lact partajabil i pentru tranzacia 2. Verific starea de blocare a lui A. A fiind deja blocat (chiar dac doar partajabil!) se refuz blocarea exclusiv a lui A pentru tranzacia 3, care va trebui s atepte deblocarea A pentru a putea continua. Lactul partajabil pus asupra lui A de ea este scos (rmne ns cellalt lact!). Verific starea de blocare A. A fiind blocat partajabil, se garanteaz un lact partajabil i pentru tranzacia 4. Lactul corespunztor este scos (dar A este nc blocat de tranzacia 4!). Lactul corespunztor este scos i cum A nu mai este blocat de nici o alt tranzacie se garanteaz un lact exclusiv pentru tranzacia 3. Se scoate lactul exclusiv corespunztor, data A redevenind liber.
t2
t3
t4 t5
Se termin tranzacia 1. ncepe tranzacia 4.
t6 t7
Se termin tranzacia 2. Se termin tranzacia 4.
t8
Tranzacia 3 modific A. Se termin tranzacia 3.
Figura 10.1 Un posibil scenariu de utilizare a lactelor partajabile i exclusive
22
Raiunea de a introduce mai multe niveluri de granularitate este evident: unele tranzacii (precum cele din exemplul 9.1 de mai sus) pot avea nevoie de acces (ACID!) la mai multe date odat, n timp ce altele (precum cele din exemplul 10.1 de mai sus) au nevoie de acces (ACID!) la o singur dat. Desigur c, pentru a maximiza performanele sistemului, este important ca nivelurile de granularitate s fie bine alese i judicios folosite, astfel nct s nu se blocheze inutil date i s nu fie excesiv de multe blocri/deblocri (care adaug timp sistem). Majoritatea SGBD-urilor ofer cel puin trei niveluri de granularitate: articol fiier (rnd din tabel); pagin; fiier (tabel). Paginile de date sunt uniti de alocare a memoriei pe disc, a cror dimensiune, multiplu de 2Koct., variaz n funcie de sistemul de operare i de SGBD (tipic, ntre 2K i 64K). n general, o pagin conine un numr ntreg de articole, iar un fiier se ntinde pe mai multe pagini. n unele SGBD, o pagin poate conine articole din mai multe fiiere (cu date structural legate ntre ele). Dei paginile de date nu sunt conceptualizate de modelele de date suport ale SGBD, totui acest nivel de granularitate are sens, aa cum rezult din urmtorul exemplu: Exemplul 10.2
S presupunem c o tranzacie include o interogare ce se refer doar la articolele dintr-o pagin de date. Evident c blocarea acestei pagini doar cu un lact este preferabil att blocrii (inutile a) ntregului fiier, ct i blocrii cu cte un lact individual a tuturor articolelor paginii (soluie ce ar mri foarte mult ncrcarea sistemului).
Unele SGBD evoluate ofer n plus un mecanism automat de escalare a lactelor (sau blocare progresiv) pentru mrirea performanelor sistemului: atunci cnd un lact cu granularitate prea fin este repetat pus (ncrcnd excesiv sistemul) SGBD poate decide (dincolo de un prag setabil) c ar fi mai economic s mreasc granularitatea, nlocuind lactul cu unul mai larg (de exemplu, de la articol la pagin sau chiar la fiier). Aceast mrire progresiv a granularitii este fcut automat, fiind transparent tranzaciei implicate.
Niveluri de izolare a lactelor

Unele SGBD ofer, de asemenea, diverse niveluri de izolare a lactelor (sau durat a lactelor) ce controleaz momentul n care se scot lactele. Pentru lactele de citire (exemplu: partajabile) sunt comune cel puin dou asemenea niveluri: citiri repetabile i stabilitatea cursorului.
Izolarea citirilor repetabile

Izolarea citirilor repetabile foreaz SGBD s menin lactul (partajabil) pn la sfritul tranzaciei, asigurnd acesteia nemodificarea datelor astfel blocate pe tot parcursul execuiei tranzaciei (care va reciti deci mereu aceeai valoare a datelor respective). Desigur c asemenea izolri inhib execuia concurent a tuturor tranzaciilor ce ar trebui s modifice datele respective; pentru a nu afecta performanele sistemului, toate tranzaciile care necesit o asemenea izolare ar trebui s se termine ct mai rapid cu putin.
Stabilitatea cursorului
Stabilitatea cursorului impune SGBD s blocheze datele doar atta timp ct ele sunt cele curente. Atunci cnd cursorul (care indic articolul curent al fiierului din care se citete) este mutat pe alte date dect cele curent blocate, sistemul scoate automat lactul (partajabil) asociat datelor ce nu mai sunt indicate de cursor. Evident c aceast izolare a lactelor de citire este dual primeia, mrind
23
concurena; exist ns tranzacii pentru care ea este inaplicabil deoarece, desigur, o recitire ulterioar a acelorai date poate furniza valori diferite de citirea anterioar (cci, ntre timp, alte tranzacii au putut modifica datele respective).
Blocarea n dou faze

Idealul urmrit de orice mecanism de control al concurenei este, evident, garantarea serializabilitii, adic atingerea unui aceluiai coninut al bd cu cel care s-ar obine printr-o serializare a tranzaciilor (i.e. execuia tranzaciilor una dup alta, fr nici o concuren). Protocolul de blocare n dou faze garanteaz serializabilitatea; varianta sa iniial preciza doar c, ntr-o prim faz, tranzaciile trebuie s obin blocarea tuturor datelor de care au nevoie; n cea de-a doua, ele nu mai au voie s cear nici o nou blocare, ci dimpotriv, pe msur ce nu mai au nevoie de acces la datele respective, lactele sunt scoase unul dup altul. De aceea, prima faz se mai zice i faza de cretere (a numrului de lacte puse), n timp ce a doua se zice faza de restrngere. Datorit experienei oferite de bd distribuite ns, s-a dovedit c aceast variant iniial nc nu garanteaz serializabilitatea! Pentru a o obine, mai este necesar adugarea unei noi restricii: scoaterea lactelor nu se poate face dect la terminarea tranzaciei (aa nct faza de restrngere ar putea fi mai plastic denumit faz de dezumflare). Necesitatea acestei restricii suplimentare poate fi ilustrat cu ajutorul exemplului 9.3 (de unde se poate observa c problema este mai general, nu doar pentru bd distribuite, chiar dac riscurile apariiei unei situaii similare cresc exponenial de la platforme uni-procesor neinterconectate, la mediile de procesare paralel i apoi la bd distribuite): Exemplul 10.3
Fie urmtorul scenariu de execuie a dou tranzacii T i T: Timp Eveniment SGBD t1 T obine un lact exclusiv pentru A t2 T actualizeaz A t3 T elibereaz A t4 T obine un lact exclusiv pentru A t5 T actualizeaz A t6 T se termin, elibernd A t7 T aborteaz Evident c, la prima vedere, ambele tranzacii satisfac varianta iniial a protocolului de blocare n dou faze; ns deoarece T aborteaz dup scoaterea lactului asupra lui A, SGBD este obligat s cear un lact asupra lui A (n numele T!) pentru a desface tranzacia ce a abortat, ceea ce violeaz de fapt chiar varianta iniial a protocolului (cci se cere un lact n faza a doua). Mai mult, pentru a desface T, SGBD desface implicit i T (cci A revenind la vechea valoare dinaintea actualizrii sale de ctre T, actualizarea fcut de T se pierde!), lucru ce afecteaz integritatea datelor (deoarece T terminndu-se normal nu mai este executat din nou). Rezult de aici necesitatea restriciei suplimentare de eliberare a lactelor doar la terminarea tranzaciei.
Exemplul precedent demonstreaz desigur i faptul c protocolul ce implic stabilitatea cursorului nu este serializabil (cci nu menine lactele pn la terminarea tranzaciei).
24
Blocaje fatale
Ca n orice alt tip de control al concurenei utiliznd mecanisme de blocare i SGBD trebuie s evite o potenial problem major: blocajele fatale (deadlocks). Un asemenea blocaj poate aprea ori de cte ori fiecare dintre tranzaciile concurente la un moment dat sunt n ateptarea (circular) a alteia dintre ele. Cel mai simplu exemplu este cel cu doar dou tranzacii concurente, dintre care prima a blocat data d1 i ateapt s poat bloca i data d2, iar cea de-a doua a blocat data d2 i ateapt s poat bloca i d1. Evident c, n acest caz, nici una dintre ele nu mai poate continua vreodat, iar sistemul este blocat n mod fatal (numai o repornire a sa putnd debloca situaia, desigur cu pierderile de informaii i integritate a datelor aferente). Majoritatea SGBD vechi, trateaz aceast problem potenial oferind mecanisme de detectare a blocajelor fatale; n cazul n care se detecteaz un asemenea blocaj, sistemul l sparge abortnd una dintre tranzacii (de obicei cea care reuise s lucreze cel mai puin pn n acel moment), ceea ce permite celorlalte tranzacii s continue lucrul, urmnd ca tranzacia abortat pentru deblocare s fie apoi imediat repornit. SGBD mai performante, din noile generaii, ofer mecanisme de prevenire a blocajelor fatale: toate lactele necesare unei tranzacii la un moment dat pot fi cerute i se garanteaz sau se resping simultan, n mod atomic (n bloc). Desigur c preul evitrii apariiei blocajelor fatale n acest mod este ns reducerea concurenei. n cazul exemplului de mai sus, presupunnd c prima tranzacie a cerut i obinut blocarea simultan a datelor d1 i d2, cea de-a doua tranzacie nu le va mai putea bloca pn cnd prima nu le elibereaz. Prevenirea blocajelor fatale este fcut de SGBD prin meninerea unor grafuri de ateptare (wait-for graph) orientate: n ele sunt memorate att tranzaciile care au obinut lacte, ct i cele care sunt n ateptare deoarece au cerut lacte ce nu pot fi momentan garantate. Nodurile unui astfel de graf memoreaz identificatorii tranzaciei i ai datelor blocate sau a cror blocare e cerut, precum i tipul lactului, n timp ce orice arc orientat indic dinspre o dat blocat de o tranzacie ctre o alt tranzacie ce ateapt blocarea aceleiai date. Evident c orice bucl nchis ntr-un asemenea graf indic un blocaj fatal. Sarcina SGBD este deci de a preveni mereu nchiderea vreunei bucle.
Blocaje fatale globale n bd distribuite

Prevenirea blocajelor fatale n bd distribuite este mult ngreunat de posibilitatea apariiei blocajelor fatale globale, interservere. Exemplul 10.4 analizeaz o asemenea posibilitate: Exemplul 10.4
Fie dou servere distribuite aflate la locaiile L, respectiv M. Fie o tranzacie T ce se execut la L i are nevoie la un moment dat de a actualiza nite date ale M, nainte de a putea continua execuia. SGBD L iniializeaz pentru aceasta la M o tranzacie cohort T care trebuie s actualizeze datele de acolo din partea T. S presupunem c, pentru aceasta, T are nevoie s pun un lact ce nu poate fi deocamdat garantat de SGBD M, deoarece o alt tranzacie U a blocat datele respective n prealabil. Lucrurile se complic n momentul n care i U, printr-o tranzacie cohort U, dorete s blocheze date ale L deja blocate de T! Evident c acest blocaj fatal global nu poate fi prevenit de nici unul din grafurile de ateptare de la L sau M, care nu conin nici o bucl, deoarece ele nu au cum s reprezinte arcele de la T la T, respectiv de la U la U.
O posibil soluie pentru prevenirea acestui tip de blocaje este, desigur, introducerea unui gestionar global, centralizat al lactelor, care s menin un unic graf de ateptare pentru ntreaga bd
25
distribuit. Dezavantajele sunt pierderea autonomiei locale i, mai ales, aglomerarea traficului n reea, plus riscurile inerente dependenei de un singur server. Cea mai interesant propunere alternativ pare cea avansat, nc din 1982, de cercettorul Ron Obermark de la IBM [271]: se extinde graful de ateptri cu un nou tip de noduri care, mpreun cu arcele aferente, s memoreze informaii de tipul tranzacia local T este n ateptarea terminrii tranzaciei cohort T pe care a iniiat-o, respectiv tranzacia cohort U este ateptat s se termine de tranzacia U ce a iniiat-o. Apariia unui asemenea tip de nod ntr-un graf de ateptare este considerat de SGBD drept un potenial de blocaj fatal global i declaneaz imediat trimiterea subgrafului de ateptare relevant celuilalt SGBD implicat; acesta, reunindu-l cu graful propriu de ateptare, poate astfel preveni apariia vreunui blocaj fatal global. Datorit implicaiilor asupra traficului de comunicaii, timpului de execuie i spaiului disc suplimentare ce ar fi necesare implementrii acestei soluii (i, mai mult, oricror alte soluii ce au mai fost propuse) nici un sistem comercial nu ofer ns practic, deocamdat, vreun remediu elegant acestei probleme: dac un asemenea blocaj apare, SGBD pur i simplu aborteaz una dintre tranzaciile implicate dup scurgerea unui interval de timp prestabilit (time out) de la blocaj!

Alturi de monografiile generale datorate lui Ullman [336,337] i Date [122,123], care au i capitole dedicate acestui subiect, indispensabil n domeniul controlului concurenei este excelenta monografie a lui Papadimitriou [276].
Controlul concurenei n DB2

Pe lng lactele uzuale (tranzacionale), DB2 ofer i lacte de drenare (drain locks), pentru procesarea comenzilor i utilitarelor de sistem DB2, precum i zvoare (latches), pentru controlul anumitor evenimente interne sistem. Pentru tranzacii, se pot specifica diverse granulariti la crearea oricrui spaiu tabel; valoarea implicit (ANY) permite SGBD gestionarea automat a acestuia de ctre sistem prin escalare. Versiunea 3 permite trei niveluri de granularitate: pagin, tabel, spaiu tabel; versiunea 4 adaug i nivelul linie. Aceste niveluri nu sunt ns mutual exclusive: n practic, DB2 folosete diverse combinaii de lacte de intenie (intent locks), de nivel spaiu tabel i tabel, cu lacte de pagin i rnd pentru a obine un echilibru ct mai bun ntre necesitile conflictuale de asigurare a unei ct mai mari concurene i de evitare a blocajelor fatale. Exist trei asemenea tipuri suplimentare de lacte: intenia partajrii, intenia exclusivitii i partajabil cu intenia exclusivitii. nainte de a obine un lact pe o pagin, DB2 ncearc, n general, obinerea unui lact de intenie corespunztor. Astfel, intenia partajrii este cerut pentru operaiile exclusiv de citire; el permite tranzaciei tentative ulterioare de obinere de lacte non-exclusive asupra paginilor tabelei sau spaiului respectiv; celelalte tranzacii pot i ele citi concurent aceste pagini; intenia exclusivitii este cerut doar pentru operaiile de scriere asupra mai multor pagini ale unei tabele sau spaiu de tabele; el permite tranzaciei cererea ulterioar a oricrui tip de lact asupra paginilor; celelalte tranzacii concurente pot, la rndul lor, obine orice fel de lacte asupra paginilor vizate; partajabil cu intenia exclusivitii este similar cu intenia excusivitii; diferena rezid doar n faptul c celelalte tranzacii concurente nu mai pot obine lacte exclusive pentru scrierea n vreo pagin a tabelei sau spaiului respectiv; numele lactului sugereaz chiar faptul c acesta este o conjuncie a dou lacte: partajabil (care mpiedic deci obinerea unui lact exclusiv de vreo alt tranzacie) i intenia exclusivitii. Pe lng avantajele deja menionate, lactele de intenie simplific i munca sistemului, reducnd timpul pierdut de acesta pentru a putea decide garantarea sau nu a unui nou lact: ele
26
factorizeaz ntr-un sens tipurile de blocaj concomitent posibile asupra paginilor unei tabele/spaiu i scutesc DB2 s analizeze, de fiecare dat, lactele tuturor paginilor implicate. Programatorii pot decide modul iniial de blocare folosit de sistem cu instruciunea LOCK TABLE; astfel, ei pot cere direct un lact partajabil sau exclusiv asupra oricrei tabele (pentru spaii de tabele segmentate se pot obine astfel doar lacte cu intenie partajabil, respectiv exclusiv asupra spaiului, pe lng lactul cerut asupra tabelei). Clauza LOCKSIZE a instruciunii CREATE TABLESPACE mpiedic sistemul s garanteze pentru spaiul respectiv lacte de granularitate mai fin dect cel specificat; de exemplu, LOCKSIZE OF TABLE inhib lactele de pagin i linie. Versiunea 3 permite i controlul blocrii fiierelor index prin clauza SUBPAGES a instruciunii CREATE INDEX: valorile admise pentru ea (1, 2, 4, 8 sau 16) cer sistemului partiionarea fiecrei pagini a indexului ntr-un numr corespunztor de subpagini; lactele sunt apoi cerute i garantate pe cte o subpagin. Versiunea 4 folosete indexuri de tip 2 (vezi capitolul 14) care nu mai permit blocarea utilizator a indexurilor; aceasta se face automat, numai de sistem, cu ajutorul zvoarelor. DB2 folosete stabilitatea cursorului pentru a se asigura c lactele partajabile asupra paginilor sunt inute doar atta timp ct se citete din pagina respectiv; citirile repetabile garanteaz n schimb c toate lactele de pagin puse de o tranzacie sunt meninute pn la terminarea acesteia. Versiunea 4 ofer n plus un nivel nou de izolare: citirea datelor neterminate (uncommitted read). Acesta asigur o concuren mai mare dect stabilitatea cursorului i semnific faptul c tranzacia poate citi date a cror modificare (de ctre o alt tranzacie) nu a fost nc terminat. Pentru cazurile n care programatorii nu folosesc corect instruciunile ACQUIRE/RELEASE de punere/scoatere simultan a tuturor lactelor necesare la un moment dat (ceea ce poate conduce la blocaje fatale), DB2 menine grafuri de ateptare pentru a preveni automat asemenea situaii limit; n caz de potenial blocaj, DB2 selecteaz dintre tranzaciile implicate o victim, pe care o desface, dnd-o napoi i elibereaz astfel resursele pentru celelalte tranzacii concurente.
Controlul concurenei n NonStop SQL

Procesele disc interne ale NonStop SQL al Tandem sunt folosite i pentru gestiunea lactelor; dei ele utilizeaz peste 20 de tipuri de lacte, extern, programatorilor le sunt vizibile doar cele dou clasice (partajabil i exclusiv). Granularitatea lactelor include linia, toate liniile unei tabele care au aceeai valoare a prefixului cheii (nivel numit generic) i partiia; pentru a bloca o ntreag tabel este nevoie de blocarea tuturor partiiilor sale. Pentru nivelul generic este, evident, neaprat necesar specificarea parametrului de lungimea lactului (lock length): numrul de caractere/cifre al prefixului dorit din cheie. Acest nivel este desigur comparabil cu lactele de pagin ale DB2; diferena uria este dat de caracterul sintactic, fizic i fix dpdv al lungimii pentru pagini DB2, n comparaie cu caracterul semantic, logic i de lungime variabil (ca numr de linii blocate, nu doar ca lungime a lactului!) asociat nivelului generic din NonStop SQL. Pe lng stabilitatea cursorului (zis aici acces stabil) i citirea repetabil (zis acces repetabil) mai este oferit un nivel suplimentar de izolare: acces inspecie (browse access). Tranzaciile opernd n acest mod nu au nevoie de nici un lact; ele pot doar citi orice date, inclusiv cele tocmai n curs de modificare de ctre o alt tranzacie (ca atare, nu acesta este modul implicit de acces!); evident ns c acest mod de acces contribuie decisiv la mrirea concurenei, chiar dac trebuie folosit doar de tranzaciile ce nu depind critic de valorile exacte ale datelor. Optimizatorul NonStop SQL (vezi capitolul 15) alege i gestioneaz automat, folosind la nevoie escalarea, lactele necesare. Totui, sistemul permite utilizatorilor (cu ajutorul instruciunii CONTROL TABLE) s controleze durata lactelor (zise, n acest caz, lacte silite, n englez bounce locks), tipul lor i nivelurile de izolare. Dac sistemul are nevoie de o resurs blocat cu un
27
lact silit, el nu ateapt ns pur i simplu eliberarea resursei ci semnaleaz aplicaiei o eroare (excepie); aceasta va lua msurile pe care le crede de cuviin n contextul respectiv. Opernd mai degrab la nivelul instruciunilor SQL (dect la nivelul liniilor, tabelelor sau tranzaciilor), lactele silite permit programatorilor scheme de blocare mai sofisticate dect cele automat implementate de sistem. Blocajele fatale sunt rezolvate doar prin time out (nu cu grafuri de ateptare)!
Controlul concurenei n Oracle

Oracle folosete i el foarte multe lacte i zvoare interne. Cele externe, vizibile utilizatorilor, sunt numite lacte de date (sau lacte DML). Granularitatea lor depinde de valorile parametrilor de iniializare ROW_LOCKING i SERIALIZABLE. Implicit, ROW_LOCKING este ALWAYS, dar el poate fi setat la valoarea INTENT (ceea ce permite citiri concurente ale tabelei, dar oblig la scrieri serializabile, n timp ce ALWAYS serializeaz doar scrierea unei aceleiai linii!). SERIALIZABLE este FALSE implicit, dar poate fi setat la TRUE (ceea ce elimin i lactele partajabile la nivel de linii, rmnnd disponibile doar lactele de nivel tabel). Oracle este unic n modul de rezolvare a controlului concurenei asupra liniilor din tabele: el nu mpiedic citirea datelor n timpul actualizrii lor, fr ns a oferi la citire date murdare; acest lucru este realizat cu ajutorul unor fotografii (snapshot) ale datelor fcute ori de cte ori este nevoie iar datele sunt consistente. De exemplu, nainte de a garanta unei tranzacii blocarea exclusiv a unei linii, aceasta este fotografiat, urmnd ca, apoi, n timp ce linia este modificat, tranzaciile care doresc s o citeasc s i aib la dispoziie fotografia. Ca atare, la nivel de linie, nu exist, de fapt, lacte partajabile, ci doar exclusive. La nivelul tabelelor exist ns urmtoarele cinci tipuri de lacte: Lactele partajabile pe (grupuri de) linii implic faptul c tranzacia a blocat un numr de linii al unei tabele pentru a le modifica; ele sunt garantate instruciunilor de tip SELECT ... FROM ... FOR UPDATE OF; alte tranzacii pot actualiza sau obine lacte asupra celorlalte linii neblocate ale tabelei, dar nu pot bloca tabela n mod exclusiv. Lactele exclusive pe (grupuri de) linii sunt similare, diferenele constnd n faptul c ele sunt garantate instruciunilor INSERT, UPDATE i DELETE i c celelalte tranzacii nu pot bloca tabela nici mcar n mod partajabil. Lactele partajabile sunt garantate doar de instruciunea LOCK TABLE ... IN SHARE MODE; ele interzic altor tranzacii s actualizeze tabela; dac ns nu exist tranzacii concurente care s dein acelai tip de lact asupra tabelei, acest lact permite obinerea de lacte de linie (pentru actualizarea acestora). Lactele exclusive cu linii partajabile sunt garantate doar de instruciunea LOCK TABLE ... IN SHARE ROW EXCLUSIVE MODE; o singur tranzacie poate deine la un moment dat un asemenea lact pe o tabel; ea poate actualiza orice linie a tabelei n timp ce alte tranzacii le pot citi (direct, sau fotografiile corespunztoare, dup caz); nici o tranzacie nu poate ns obine n acest timp vreun lact partajabil, exclusiv sau exclusiv cu linii partajabile asupra tabelei. Lactele exclusive sunt garantate doar instruciunilor LOCK TABLE ... IN EXCLUSIVE MODE; tranzacia poate scrie, alte tranzacii pot citi fotografia curent a tabelei, dar nici o alt tranzacie nu poate deine vreun lact asupra tabelei. Modelul consistenei multi-versiune al Oracle impune implicit consistena de nivel instruciune; ea garanteaz consistena rezultatelor oricrei interogri individuale la momentul nceperii
28
execuiei interogrii. Aceasta nseamn, n esen, dou lucruri: orict de mult ar dura execuia interogrii, ea va accesa mereu aceleai valori ale datelor cu cele care erau memorate la momentul nceperii execuiei ei; pe de alt parte ns, tranzaciile concurente pot lucra n paralel, inclusiv pentru a actualiza datele procesate de interogare. Acest model se mai numete i tehnica de interogare fr blocaje, deoarece nici cititorii nu blocheaz scriitorii i nici invers. Interogrile vd mereu date consistente (absolut consistente, nu doar relativ consistente, precum n cazul stabilitii cursorului) chiar dac acestea nu sunt cele mai recente. Implementarea acestui model este relativ simpl: ori de cte ori o tranzacie se termin, n jurnalul de actualizri corespunztor este memorat i valoarea curent a unui numr de schimbri sistem (SCN) care, apoi, este imediat incrementat; fiecare bloc de date memorat pe disc conine i valoarea SCN la momentul ultimei scrieri a datelor blocului respectiv; la momentul nceperii execuiei unei interogri, Oracle memoreaz valoarea curent a SCN; atunci cnd interogarea acceseaz un bloc de date, acesta este livrat direct dac SCN-ul su este mai mic sau egal cu cel memorat la nceputul tranzaciei; n caz contrar, Oracle reconstruiete, cu ajutorul jurnalului de actualizri, o fotografie a datelor conform cu starea lor la momentul nceperii tranzaciei. Modelul consistenei multi-versiune poate fi ns schimbat de utilizatori explicit pentru a obliga Oracle s impun consistena citirilor la nivelul tranzaciilor n locul celei de nivel instruciune. Aceasta garanteaz tuturor instruciunilor unei tranzacii (n particular, tuturor interogrilor deci) accesul la o versiune consistent a datelor, ceea ce este comparabil cu citirile repetabile. Pentru tranzaciile care scriu, este necesar n acest caz obinerea n prealabil de lacte exclusive de linii sau de tabel (interogrile componente ce doar citesc date avnd nevoie numai de lacte exclusive de linii). Acest lucru determin, desigur, o scdere a concurenei. Dac tranzaciile doar citesc (i nu au deci nevoie de nici un fel de lact exclusiv), ele pot semnala acest lucru, pentru a permite o concuren mrit, prin instruciunea SET TRANSACTION READ ONLY; ea are ca efect garantarea consistenei de ctre Oracle cu ajutorul SCN, similar ca mai sus. Controlul utilizatorilor asupra concurenei este extins i n cazul instruciunilor SELECT ... FOR UPDATE prin clauza NOWAIT; n prezena acesteia, dac sistemul nu poate garanta imediat lactul partajabil pe grupul de linii corespunztor, el nu pune tranzacia n ateptarea momentului n care acesta va putea fi garantat (ca n cazul implicit, cnd opiunea NOWAIT lipsete) ci semnaleaz tranzaciei o eroare, pe care aceasta o trateaz cum crede de cuviin. Pentru prevenirea blocajelor fatale, Oracle menine grafuri de ateptare; dac este nevoit s aleag o victim, atunci i desface doar ultima dintre instruciuni, cea care a provocat blocajul, pasndu-i un mesaj n acest sens; tranzacia n cauz poate decide s se desfac integral, sau s atepte i s rencerce apoi instruciunea. n contextul bd distribuite, eventualele blocaje globale fatale sunt rezolvate prin time out.
Controlul concurenei n SQL Server al Sybase

Granularitatea lactelor oferite de SQL Server se bazeaz pe doar dou niveluri, pagin i tabel, care pot ns interaciona sinergic oarecum similar cu cazul DB2. Lactele de pagin pot fi de unul din urmtoarele patru tipuri: Partajabil; implicit scos la terminarea instruciunii de interogare. Actualizare; folosit doar n primul pas al unei operaii de actualizare (de pregtire a scrierii), n care pagina este doar citit n memorie; n acest rstimp, alte tranzacii pot citi i ele pagina; cnd tranzacia a terminat actualizarea datelor n memorie, nainte de a le scrie pe disc trebuie s obin un lact exclusiv asupra paginii.
29
Cerere; atunci cnd o tranzacie are de scris o pagin i nu are timp de ateptat dup tranzaciile care citesc, poate cere un asemenea lact; sistemul o va promova n capul listei de ateptare i nu va mai garanta nici un alt lact partajabil asupra paginii pn cnd tranzacia nu termin de scris. Exclusiv; nu este scos pn la sfritul tranzaciei. Lactele pentru tabele sunt de cinci tipuri: Partajabil, similar cu cel de nivel pagin. Cerere, idem. Exclusiv, idem, cu observaia c, n general, blocarea exclusiv se face doar la nivel de pagin; numai instruciunile UPDATE i DELETE ce nu refer coloane indexate necesit acest tip de lact. Intenie de partajare; folosit pentru citiri; proprietarul poate ulterior cere blocarea cu lacte partajabile a oricror pagini ale tabelei (ce i vor fi garantate, evident, doar dac ele nu sunt blocate exclusiv de vreo alt tranzacie); el este garantat interogrilor care refer att coloane indexate, ct i neindexate. Intenie de exclusivitate; folosit pentru scrieri; proprietarul poate ncerca ulterior obinerea de lacte de scriere pentru oricare pagin a tabelei (ce vor reui, desigur, doar dac paginile respective nu sunt blocate de alte tranzacii), dar i de lacte partajabile sau de actualizare; el este garantat pentru inserii, dar i pentru actualizri i tergeri dac acestea refer coloane indexate. SQL Server ncurajeaz utilizarea de lacte de pagin, pentru mrirea concurenei; dac totui o singur instruciune blocheaz mai mult de 200 de pagini ale unei tabele, sistemul escaleaz automat lactul la cel de tabel. O procedur memorat sistem permite administratorilor modificarea valorii variabilei de configuraie lock ce reprezint numrul maxim de lacte ce pot fi simultan garantate de sistem. Implicit, acesta este 5.000; maxim, el poate fi 2 miliarde! Sybase recomand utilizatorilor s estimeze c, n medie, este nevoie de cte 20 de lacte per tranzacie. Alt procedur memorat ofer administratorilor date despre toate lactele curente, incluznd identificatorii tabelelor i tranzaciilor implicate, precum i tipul lactelor. O funcie permite utilizatorilor s menin lactele partajabile asupra unei tabele pn la terminarea tranzaciei. Aceasta, coroborat cu instruciunea SET TRANSACTION ISOLATION LEVEL 3, ofer suport pentru citiri repetabile. SQL Server menine grafuri de ateptare pentru prevenirea blocajelor fatale; drept victim va fi aleas ntotdeauna (pentru a fi desfcut) tranzacia implicat ce a consumat cel mai puin timp procesor.
Controlul concurenei n CA-OpenIngres

CA-OpenIngres are un mecanism de control al concurenei similar cu cel al DB2 i SQL Server. Lactele de pagin pot fi doar partajabile sau exclusive, n timp ce cele de tabel mai pot fi i intenie de partajare, intenie de exclusivitate sau intenie de exclusivitate cu partajare. Pe lng acestea, Ingres mai folosete un zvor intern, transparent utilizatorilor, numit lact nul. Gestiunea lactelor se face automat, dar unele faciliti pot fi controlate i de utilizatori prin instruciunea SET LOCKMODE. Astfel, datele pot fi citite i fr a cere un lact partajat, cu SET LOCKMODE SESSION WHERE READLOCK = NOLOCK; desigur c aceasta mrete concurena, scade probabilitatea blocajelor fatale, dar poate oferi date murdare, inconsistente. Similar, pot fi escalate explicit lactele de pagin la nivelul tabelei, sau poate fi modificat pragul de escalare automat de ctre sistem (implicit, acesta este de 10 pagini blocate per tabel).
30
Cu aceeai instruciune, utilizatorii pot obliga sistemul s nu atepte la infinit garantarea unui lact, ci doar n limita valorii indicat de opiunea TIMEOUT; la scurgerea acestui interval de timp, sistemul desface instruciunea curent a tranzaciei n ateptare i i semnaleaz o eroare; tranzacia o va procesa cum crede de cuviin (rencercnd instruciunea desfcut sau renunnd i desfcnduse complet). Ingres suport opional stabilitatea cursorului, dei citirile repetabile sunt implicit asumate. De asemenea, sunt prevenite blocajele fatale; victima aleas este complet desfcut, lucru memorat n jurnalul de actualizri.
31
3. SALVRI I RECUPERAREA DIN EROARE

Un alt rol important al SGBD este prevenirea pierderii de date, ceea ce implic existena unor faciliti de salvare regulat a datelor i de recuperare din erori. Majoritatea SGBD ofer utilizatorilor dou tipuri de salvri: integrale (un ntreg fiier sau o ntreag bd) i pariale (sau incrementale, n care sunt salvate doar datele ce au fost modificate de la ultima salvare integral). Desigur c salvrile integrale sunt mult mai costisitoare, att ca spaiu de memorare ct i ca timp necesare, n raport cu cele incrementale; ca atare, primul tip este folosit mai rar (de obicei sptmnal sau chiar lunar), iar cel de-al doilea mult mai frecvent (zilnic). Strategiile de salvare a datelor sunt foarte diferite de la SGBD la SGBD; de exemplu, se pot face salvri ale datelor dintr-o tabel, dintr-un grup de tabele (logic interconectate sau doar create de un acelai utilizator), dintr-o bd sau dintr-o colecie de bd. Unele SGBD salveaz doar datele propriu-zise, n timp ce altele adaug i alte informaii (de exemplu, restriciile de securitate asociate). SGBD evoluate mresc performana lucrului oferind salvri n timp real (on-line) pentru bd care trebuie s fie disponibile clip de clip. Folosind salvrile (integrale i/sau pariale) SGBD pot reface starea bd corespunztoare ultimei salvri, asigurnd astfel cea mai banal recuperare din erori cu putin. Aceasta ns nu poate fi ntotdeauna mulumitoare, cci readucerea bd n starea din momentul erorii poate fi foarte costisitoare dac salvrile nu sunt suficient de recente. Ca atare, pe lng salvri, SGBD menin n plus i jurnale de actualizri.
Jurnale de actualizri
Un jurnal de actualizri memoreaz modificrile datelor dintr-o bd; el este de obicei memorat tot pe disc dur, ntr-un fiier separat de cele ale bd (plasat adesea, pentru mrirea siguranei, pe un alt disc dect cel pe care rezid bd). Unele SGBD ofer chiar precauia meninerii cte unui jurnal oglind, copie fidel a fiecrui jurnal, memorat pe alt disc dect jurnalul original, pentru maxim securitate. Dei nu exist nici n cazul jurnalelor de actualizri vreo soluie standard, majoritatea SGBD memoreaz n aceste jurnale momentul nceperii i terminrii execuiei fiecrei tranzacii, ca i vechile i noile valori ale datelor pentru fiecare actualizare de date n parte (evident mpreun cu numele tranzaciei corespunztoare). Cum toate scrierile pe disc se fac grupat, pe zone tampon relativ mari (pentru a mri viteza prin micorarea numrului de accese la disc), n scopul mririi siguranei n exploatare unele SGBD ofer protocoale de jurnalizare nainte de scriere (write-ahead) care foreaz scrierea pe disc a nregistrrilor din jurnal nainte de actualizarea corespunztoare a datelor. Asemenea protocoale evoluate asigur astfel posibiliti de recuperare din eroare imediat, de exemplu n cazul erorii la scrierea noii valori a unei date pe disc. Majoritatea SGBD evoluate ofer i posibilitatea de jurnalizare selectiv, prin inhibarea i repornirea la cerere a jurnalizrii. Inhibarea jurnalizrii mrete sensibil viteza sistemului, cu riscul imposibilitii recuperrii automate din eroare. Ea este ns necesar nu doar n teste, ci i n cazurile n care viteza este critic (exemplu: datele prelucrate sunt imagini, care ocup foarte mult spaiu de memorare) iar riscul acceptabil.
Refacerea i desfacerea automat a actualizrilor

32
Jurnalizarea i salvarea permit SGBD recuperarea din eroare complet i automat prin refacerea strii bd dinaintea erorii: dup restaurarea bd cu ajutorul copiilor salvate (n cazul n care acest lucru este necesar), refacerea actualizrilor bd se poate face, trivial, parcurgnd jurnalul respectiv de la cap la coad i refcnd corespunztor datele pentru toate tranzaciile care se i terminaser; restul tranzaciilor sunt apoi repornite. Mai mult ns, jurnalizarea permite i desfacerea actualizrilor (undo) produse de tranzacii, prin parcurgerea jurnalului n sens invers i efectuarea modificrilor inverse corespunztoare (rollback) asupra datelor actualizate de tranzaciile de desfcut. Aceast facilitate, extrem de util, poate fi necesar de exemplu pentru a nltura efectele execuiei pariale ale unei tranzacii care a fost abortat (sau s-a terminat neateptat) sau chiar pe cele ale unei tranzacii care s-a executat integral dar ale crei modificri n date conduc la violarea constrngerilor de integritate ale bd.
Puncte de verificare
Aa cum am menionat mai sus, pentru a mri performanele sistemului (avnd n vedere viteza mult mai sczut a acceselor la disc n raport cu cele la memoria RAM) SGBD nu scriu pe disc fiecare actualizare imediat, ci le grupeaz, folosind zone tampon relativ mari, astfel nct actualizrile sunt de fapt memorate doar n RAM i scrise pe disc mai trziu, mai multe deodat. De exemplu, chiar n absena unui protocol de jurnalizare nainte de scriere, este posibil ca sfritul unei tranzacii s fie scris n jurnal fr ns ca ultimele actualizri (poate chiar toate!) s fie i ele scrise pe disc (acest lucru urmnd a se face ulterior, la umplerea zonei tampon corespunztoare). Pentru a scurta timpul necesar refacerii actualizrilor la recuperarea din erori, unele SGBD folosesc punctele de verificare (checkpoints): acestea sunt nregistrri n jurnalele de actualizri fcute n momente n care sistemul a forat scrierea pe disc prealabil a tuturor zonelor tampon din memorie. n caz de eroare, vor trebui evident refcute doar actualizrile ulterioare ultimului punct de verificare. Cu ct sunt mai frecvente aceste puncte de verificare, cu att mai scurt este timpul de refacere a bd; desigur ns c fiecare punct de verificare n parte ncetinete viteza de procesare a tranzaciilor. Ca atare, ele trebuie cerute sistemului de ctre administratorii si n mod regulat (de obicei la intervale fixe de timp sau imediat dup terminarea unui numr fixat de tranzacii) dar astfel nct s se optimizeze performanele globale ale sistemului. Punctele de verificare permit recuperarea din eroare automat, chiar transparent utilizatorilor, fr a face apel la copiile de salvare ale bd afectate, aa cum se poate observa din exemplul urmtor: Exemplul 11.1
S considerm scenariul propus de figura 11.1. n acest caz, pentru a recupera din eroare, sistemul trebuie s parcurg urmtorii pai: Refacerea tuturor actualizrilor fcute de tranzaciile terminate dup ultimul punct de verificare (dar, desigur, naintea cderii sistemului); referindune la figura 11.1, aceasta implic tranzaciile 1, 3 i 6. Acest lucru este necesar deoarece nu este sigur c toate actualizrile produse de aceste tranzacii au i apucat s fie scrise pe disc (ele putnd fi scrise doar n zonele tampon din memoria volatil). Ignorarea tuturor tranzaciilor terminate nainte de ultimul punct de verificare (ce garanteaz c modificrile lor au fost scrise pe disc n ntregime); este cazul tranzaciei 2 din figur.
33
Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008 Desfacerea actualizrilor fcute de toate tranzaciile active n momentul cderii sistemului (tranzaciile 4 i 5 din figur); cum aceste actualizri sunt pariale, pstrarea lor ar putea lsa bd ntr-o stare inconsistent! Repornirea tranzaciilor active (4 i 5) n momentul cderii sistemului.
34
Tranzacii 1 2 3 4 5 6 axa timpului Punct de verificare ( reprezint terminarea execuiei tranzaciei)
Figura 11.1 Un posibil scenariu necesitnd recuperarea din eroare
Cdere sistem
Recuperarea din dezastre

Recuperarea din dezastre (naturale, precum cutremure, erupii vulcanice, inundaii, uragane etc. sau datorate omului, ca incendii, atentate cu explozibili, ntreruperea pe termen lung a alimentrii electrice etc.) necesit precauii speciale pentru bd critice, care trebuie s fie permanent n serviciu (precum cele deservind automatele de eliberare a banilor). n general, este adoptat soluia existenei unei alte platforme similare de calcul, de rezerv, aflat ntr-un alt loc (alt ora sau chiar alt ar), care dubleaz sistemul principal n funciune. Desigur c aceasta implic dou considerente la fel de importante: sistemul de rezerv trebuie s aib mereu datele ct mai recente n raport cu sistemul principal (lucru care se realizeaz prin mecanisme de replicare a datelor i jurnalelor de actualizri) i s poat prelua rapid procesarea tranzaciilor de la acesta n caz de dezastru.

Considerm suficient pentru acest subiect o singur referin bibliografic, de exemplu [73] sau [166]. Toate SGBD analizate n aceast seciune, cu excepia CA-OpenIngres, ofer facilitatea suplimentar de a defini puncte de salvare n orice programe (aplicaii, proceduri memorate, trgaciuri). Acestea au etichete n program i reprezint pentru SGBD echivalentul unor puncte de verificare pe care programul le poate oricnd referi, cernd sistemului desfacerea tuturor actualizrilor ulterioare i revenirea datelor la starea din punctul de salvare dorit.
Salvri i recuperri n DB2

Salvarea datelor n DB2 al IBM se face, fie total, fie incremental, cu utilitarul COPY. Se pot salva un ntreg spaiu tabel, o partiie a sa sau doar o mulime de date VSAM (Virtual Storage Access Method); salvrile diferitelor asemenea mulimi sau partiii ale unui aceluiai spaiu tabel se pot face n paralel, pentru creterea performanelor. Utilitarul MERGECOPY permite crearea unei singure copii pentru orice spaiu tabel, pornind de la o copie total i oricte copii incrementale ulterioare ale acestuia. Datele despre toate salvrile fcute sunt memorate n cataloage (vezi capitolul 16). Utilitarul RECOVER TABLESPACE permite recuperarea din eroare a unui spaiu tabel, folosind datele din catalog despre salvri, copiile disponibile, punctele de verificare i jurnalul de
35
actualizri. Cataloagele menin i date despre punctele de verificare. Restaurarea partiiilor unui spaiu tabel se poate face i ea n paralel. Pot fi salvate / restaurate i fiiere index ca i cataloagele sistem. Pentru mrirea performanelor, se pot face i salvri pe viu (on-line), n timp ce utilizatorii acceseaz datele respective; dac acetia actualizeaz datele n timpul salvrii, acestea se zic copii spulberate (fuzzy backup), deoarece ele nu pot fi utilizate pentru restaurarea datelor dect n conjuncie cu jurnalul de actualizri (ce trebuie s aduc la zi valorile datelor modificate dup salvare). Jurnalele de actualizri (care se pot menine n dou copii, pentru sporirea siguranei) memoreaz att valorile dinaintea ct i cele de dup fiecare actualizare. Vechile jurnale pot fi arhivate (de obicei pe benzi). Exist o mulime de date VSAM distins, numit bootstrap data set, care memoreaz date despre toate jurnalele active i arhivate, coninutul lor i punctele de verificare ce le conin; ea poate fi listat la cererea administratorului bd. Suplimentar, exist i un utilitar REPAIR care corecteaz rapid datele inconsistente, pentru ocaziile n care ori e vorba de date neimportante (exemplu, de test), sau se tie c datele au fost foarte puin afectate sau atunci cnd nu este timp pentru recuperarea corect din eroare; desigur c se impun mari precauii n acest ultim caz! Preocuparea deosebit a IBM pentru protecia datelor se manifest ns de la nivelul hardware: mainile IBM (pentru care a fost gndit DB2) sunt echipate cu uniti de control a memorrii de tip 3990 Model 6, care suport att copiere extins de la distan (XRC) pentru realizarea de copii umbr (shadowing) asincrone a volumelor DASD (Direct Access Storage Device), ct i copiere punct-la-punct (peer-to-peer) de la distan (PPRC) pentru realizarea de umbre sincrone a volumelor DASD. n plus, RAMAC Array DASD furnizeaz un nalt grad de disponibilitate i toleran la erori prin folosirea tehnologiei RAID (Redundant Array of Independent Disks). Versiunea 4 a DB2 suport de asemenea partajarea datelor pe platforma de procesare paralel IBM Parallel Sysplex, pe care pot rula simultan mai multe subsisteme DB2; dac vreunul din ele devine brusc indisponibil, orice tranzacie poate comuta cererile sale de acces la un alt subsistem DB2 ce are acces la datele respective.
Salvri i recuperri n NonStop SQL

Facilitatea de Monitorizare a Tranzaciilor (TMF) a fost, pn de curnd, procesorul specializat al firmei Tandem pentru salvarea i recuperarea din eroare n NonStopSQL; recent, el a fost nlocuit cu o versiune mai evoluat, NonStop TM / MP (NonStop Transaction Manager / Massively Parallel), despre care avem ns foarte puine date pn n momentul redactrii acestei lucrri. TMF realizeaz salvri (inclusiv spulberate) / restaurri (prin utilitarele BACKUP / RESTORE) i gestioneaz jurnalele de actualizri att sistem (ale cataloagelor, vezi capitolul 16), ct i utilizator; acestea conin valorile dinaintea i de dup fiecare actualizare, precum i cele relative la punctele de verificare (aici zise control points). Pentru siguran mrit, jurnalele sunt memorate pe alte discuri dect bd. Recuperarea din eroare se poate face automat sau readucnd datele la ultima lor stare consistent, sau la cea a oricrui moment consistent anterior. Remote Duplicate Database Facility (RDF) este o extensie a TMF ce permite utilizatorilor s copieze datele de pe un server aflat la distan, astfel nct, n cazul indisponibilitii brute a vreunuia din ele, un alt server s poat imediat prelua i activitile acestuia. Una din noutile aduse de NonStop TM / MP este cea privind suportul pentru overflow audit volumes: pentru a evita oprirea tranzaciilor din cauza lipsei de spaiu suplimentar pentru jurnalul de actualizri, acesta monitorizeaz praguri prestabilite (implicit sau explicit, de ctre administratorul bd) de umplere a jurnalelor i, la depirea lor, arhiveaz nceputul jurnalului pe un volum de debordare special.
Salvri i recuperri n Oracle

Salvarea (inclusiv spulberat) i restaurarea datelor n Oracle se poate face numai cu ajutorul utilitarelor oferite de sistemul de operare gazd. Oracle gestioneaz doar jurnalele de actualizri
36
i ofer instruciunea RECOVER pentru recuperarea din eroare pe baza jurnalului (ce trebuie, evident, executat doar dup restaurarea manual a fiierelor afectate!). Utilitarele pentru exportul i importul datelor pot ns servi i pentru salvarea i restaurarea datelor; ele permit copii totale sau incrementale (pentru care exist i un utilitar de compactare similar MERGECOPY al IBM) ale tuturor obiectelor unei bd, sau numai toate ori doar unele dintre cele ale unui proprietar oarecare. Jurnalele ns pot fi meninute n dublu exemplar, simultan pe dou discuri diferite, pentru sporirea siguranei. Pentru un jurnal, se aloc de fapt mai multe fiiere de lungime fix ce sunt utilizate circular (cnd unul se umple, sistemul trece la urmtorul, rescriind astfel cel mai vechi scris dintre ele). Implicit, punctele de verificare sunt constituite doar de momentele n care se schimb fiierul jurnal curent cu urmtorul; utilizatorii pot ns specifica i altele, suplimentare.
Salvri i recuperri n SQL Server al Sybase

SQL Server al Sybase ofer comenzi specializate pentru salvri i recuperarea din eroare, att a bd sistem MASTER, ct i a bd utilizator. Salvarea se face cu DUMP DATABASE ce copiaz mpreun o bd i jurnalul asociat; ea poate fi pe viu, dar nu poate fi spulberat, cci orice cerere de actualizare a datelor ce se salveaz trebuie s atepte terminarea salvrii. Dac jurnalul unei bd rezid pe alt disc dect bd, comanda DUMP TRANSACTION salveaz doar jurnalul, i terge din el toate nregistrrile privind tranzaciile terminate. Versiunea 10 ofer n plus un Backup Server capabil s redirecioneze salvrile spre un alt server, aflat la distan. De asemenea, el poate reduce considerabil timpul necesar salvrilor prin mprirea datelor de salvat (striping) n maxim 32 de partiii egale ce pot fi salvate concurent pe tot attea dispozitive hardware. Fiecare bd are obligatoriu asociat un jurnal de actualizri ce nu poate fi inhibat nicicnd; el memoreaz valorile dinaintea i de dup fiecare actualizare, precum i puncte de verificare la intervale regulate de timp. Aceste intervale pot fi modificate indirect de utilizatori prin impunerea unui interval de recuperare maxim; pe baza valorii respective, sistemul calculeaz ct de dese trebuie s fie punctele de verificare astfel nct recuperarea din eroare s nu dureze vreodat mai mult dect intervalul impus. Comanda DISK MIRROR are ca efect i duplicarea jurnalelor (mpreun cu bd) pe un alt disc; aceasta mrete sensibil sigurana i disponibilitatea datelor (ns cu pierderile de performan de rigoare). Comenzile LOAD DATABASE i LOAD TRANSACTION sunt duale celor similare de salvare i realizeaz refacerea bd i / sau a jurnalelor de actualizri. Pentru a evita blocajele datorate umplerii jurnalelor de actualizri, sistemul foreaz pentru fiecare din ele un prag al ultimei anse: dac spaiul disc scade sub acest prag, sistemul oprete temporar toate tranzaciile i invoc automat o procedur memorat sistem de salvare a jurnalului; apoi reiniializeaz jurnalul i reia execuia tranzaciilor. Administratorii bd i utilizatorii pot fixa ns praguri proprii, la atingerea crora sistemul poate lansa automat n execuie o procedur memorat utilizator care s elibereze spaiu suplimentar disc. Versiunea 10 ofer o facilitate original, de nentlnit la nici unul dintre celelalte SGBD analizate n lucrare, i anume posibilitatea de a scrie tranzacii structurate (nested transactions) pe subtranzacii. O subtranzacie este delimitat de instruciunile BEGIN TRANSACTION i COMMIT, putnd conine n interior oricte alte subtranzacii, pe oricte niveluri de adncime. n general, o asemenea structurare a tranzaciilor poate aprea atunci cnd o aplicaie are nevoie de sau provoac execuia mai multor proceduri memorate i/sau trgaciuri, fiecare dintre acestea putnd, la rndul lor, invoca sau provoca execuia altor proceduri memorate i/sau tranzacii. De notat ns c, de fapt, sistemul nu consider terminat nici o subtranzacie, chiar dac ea a executat COMMIT, pn cnd tranzacia nveli exterior a tuturor subtranzaciilor astfel structurate nu se termin; dac aceasta din urm este desfcut (din orice motiv ar fi) toate tranzaciile interioare, inclusiv cele ce s-au terminat, sunt desfcute la rndul lor.
37
Salvri i recuperri n CA-OpenIngres

CA-OpenIngres ofer i el comenzi pentru salvare (CKPDB, COPYDB i UNLOADDB) i recuperarea din eroare (ROLLFORWARDDB). CKPDB creeaz un punct de verificare, dezactiveaz intrrile aferente din jurnalul de actualizri i face o copie a bd pe band sau disc; copia poate fi i spulberat, caz n care ea va conine i toate nregistrrile din jurnalul de actualizri ulterioare salvrii i necesare refacerii corecte a datelor. Pentru a preveni debordarea jurnalelor, sistemul le arhiveaz pe viu, continuu: dac s-a specificat opiunea WITH JOURNALING a instruciunii CREATE TABLE, aceasta nseamn mutarea nregistrrilor pentru tranzaciile terminate din jurnalul curent ntr-unul arhiv; n caz contrar, aceste nregistrri sunt pur i simplu terse! Jurnalele memoreaz att valorile dinainte i de dup actualizri, ct i punctele de verificare. Recuperarea din eroare cu ROLLFORWARDDB se face automat, pn la momentul cderii, sau nainte de acesta (la cererea administratorului db; n plus, acesta are i opiunea de a reface doar tranzaciile ce au nceput dup o anumit or a unei zile ). COPYDB permite copierea integral a tuturor obiectelor proprietate a utilizatorului ce a invocat comanda (i.e. tabele, indexuri, puncte de vedere, proceduri, constrngeri). Aceste date pot fi ulterior restaurate pur i simplu (adic fr ca, dup aceea, sistemul s le mai actualizeze conform vreunui jurnal de actualizri). UNLOADDB permite administratorului copierea integral a unei bd pentru rencrcarea ei ntr-una nou, vid; i acest tip de copie poate fi utilizat pentru restaurri, n aceleai condiii ca i n cazul COPYDB.
38
4. SECURITATEA DATELOR
n foarte multe cazuri, nu toi utilizatorii bd trebuie s aib acces la orice date. Controlul accesului la date este realizat de SGBD prin posibilitatea acordrii de privilegii utilizatorilor autorizai. n general, recunoaterea acestora se face prin cte o pereche de tip (cont/utilizator, parol), administratorii bd fiind responsabili cu gestionarea privilegiilor garantate utilizatorilor autorizai.
Privilegii
Tipurile de privilegii oferite de diverse SGBD sunt foarte variate; n esen ns, ele includ dreptul de a citi date, a scrie date, a crea noi structuri de date (exemplu: bd sau tabele ntr-o bd existent) i dreptul de a executa anumite programe (utilitare). Privilegiile pot fi garantate implicit (de exemplu, administratorul unei bd poate avea automat dreptul de a crea noi tabele n bd, creatorul unei tabele s scrie i s citeasc coninutul ei etc.) sau explicit (de exemplu, administratorul unei bd poate garanta unor utilizatori dreptul de a crea tabele, altora doar pe cel de a scrie n tabelele existente, unora doar de a le citi, iar restului de utilizatori le poate interzice pn i citirea). Privilegiile sunt de obicei asociate: tuturor utilizatorilor autorizai (publicul); de exemplu, majoritatea datelor utilizate n comun de toi utilizatorii unei bd pot fi oricui accesibile n citire (i.e. datele publice, despre tranzacii bursiere, cursul valutelor, mersul trenurilor sau al avioanelor, cartea de telefon etc.); tuturor utilizatorilor dintr-un grup (definit de administratorul bd); de exemplu, toi angajaii serviciului de contabilitate al unei firme ar putea alctui un asemenea grup; privilegiile garantate grupului (de obicei de scriere/citire n anumite tabele i doar de citire n altele) sunt motenite de toi membri acestuia (acest tip de privilegiere grupat avnd, evident, dou mari avantaje: poate modela fidel organigrama firmelor i simplific munca administratorului bd); tuturor utilizatorilor sistem (administratori ai bd); de exemplu, pe lng privilegiul de a avea acces nelimitat la toate datele, acest grup sistem are i dreptul de a garanta anumitor grupuri sau utilizatori privilegiile de acces la bd, eventual i pe cel de a transmite acest drept (total sau parial) altor utilizatori; creatorilor (proprietarilor) de obiecte; de exemplu, creatorului unei tabele i se poate garanta nu doar dreptul de a scrie/citi tabela respectiv, ci i cel de a garanta la rndul lui privilegii altor utilizatori asupra tabelei sale; utilizatorilor individuali; de exemplu, unui utilizator oarecare U, i se poate garanta cu titlu individual (pe lng eventualele alte drepturi pe care le-ar avea ca membru n unul sau mai multe grupuri) dreptul de a scrie/citi (i) n tabela T. Privilegiile se pot acorda n unele SGBD doar pentru poriuni din tabele. De exemplu, orice angajat ar putea citi datele despre colegii si de colectiv, cu excepia salariului (accesibil doar efului de colectiv), fr ns a avea acces la datele despre ceilali angajai ai firmei. SGBD relaionale pot oferi asemenea privilegii pariale foarte uor prin intermediul punctelor de vedere (view) diferite asupra datelor.
Codificarea datelor i verificarea accesului

Pe lng conturi, parole i privilegii de acces la date, unele SGBD ofer mecanisme suplimentare de asigurare a securitii datelor. De exemplu, pentru ca datele s nu poat fi modificate sau citite fr a cunoate o parol suplimentar, se codific (cripteaz) datele nainte de scrierea lor pe
39
disc. SGBD evoluate ofer chiar posibilitatea codificrii folosind proceduri de criptare definite de utilizatori. Unele SGBD menin n plus dre de verificare (audit trails), jurnale n care memoreaz toate activitile din sistem (inclusiv eventualele tentative de acces neautorizat). Se pot astfel verifica utilizatorii care au modificat (poate chiar criminal!) datele sau au ncercat s violeze interdiciile de acces.
Ierarhia nivelurilor de acces utilizator n bd distribuite

Desigur c garantarea securitii datelor se complic n bd distribuite: este nevoie ca toi utilizatorii s aib acces partajabil la toate serverele? are vreunul nevoie de acces exclusiv pe toate serverele? IBM a publicat primul, n 1990 [179], o ierarhie pe patru niveluri de tipuri de acces oferite utilizatorilor, care a devenit ntre timp aproape un standard n domeniu: Cereri de la distan (remote requests): utilizatorii pot citi i modifica date ntr-un server aflat la distan, dar este permis o singur instruciune SQL per tranzacie i per server (deci o instruciune nu poate implica dect un server); Unitatea de lucru de la distan (remote unit of work): utilizatorul poate citi i modifica date ntr-un server aflat la distan, dar este permis o unic tranzacie, ce poate fi alctuit din oricte instruciuni SQL, implicnd ns doar acel server; Unitatea de lucru distribuit (distributed unit of work): utilizatorii pot citi i scrie date n mai multe servere per tranzacie, cu condiia ca orice instruciune SQL a tranzaciei s fac apel la un singur server; actualizarea datelor pe mai multe servere presupune utilizarea protocolului terminrii n dou faze (vezi capitolul 13); Cereri distribuite (distributed requests): utilizatorii pot citi i scrie date n mai multe servere per tranzacie; orice instruciune SQL a tranzaciei poate face apel la oricte servere; actualizarea datelor pe mai multe servere presupune utilizarea protocolului terminrii n dou faze (vezi capitolul 13); optimizarea global (vezi capitolul 15) este necesar (n special pentru operaii join i reuniune multi-server).

Pentru considerente generale legate de securitatea datelor, recomandm [71,73,166].
Securitatea datelor n DB2

DB2 al IBM suport instruciunile standard SQL de asignare / revocare a privilegiilor GRANT / REVOKE. Lista sa de privilegii este suficient de granular pentru a permite administratorilor bd controlul strns asupra securitii datelor. De exemplu, un utilizator ar putea primi dreptul de a crea tabele, dar nu i pe acela al invocrii unor utilitare asupra tabelelor respective. Pe lng aceasta, DB2 mparte utilizatorii n 6 clase: administratori sistem, operatori sistem, administratori de bd, operatori de gestiune a bd, operatori de control ai bd i public. Fiecare membru al unei asemenea clase motenete automat anumite privilegii. n plus, este oferit i un mecanism secundar de autorizare ce permite definirea de grupuri de utilizatori. DB2 menine automat i jurnale de control al accesului.
Securitatea datelor n NonStop SQL

NonStop SQL al Tandem nu are mecanisme proprii de securitate (nici mcar nu ofer GRANT / REVOKE din SQL!); el se bazeaz n aceast privin pe sistemul de operare NonStop Kernel cu care este strns cuplat. Acesta ns ofer doar privilegii la nivel de fiiere, asemntoare celor
40
din sistemul de operare VMS al DEC (patru privilegii: citire, scriere, execuie, tergere; patru clase de utilizatori locali: administrator sistem, proprietar obiect, grup, public; i trei de utilizatori distribuii: proprietar, grup, public).
Securitatea datelor n Oracle

Securitatea n Oracle este asigurat n mod standard SQL (GRANT / REVOKE). Trei clase de privilegii difereniaz trei tipuri de utilizatori: sistem (pentru administratorii bd), obiect (pentru utilizatori individuali obinuii) i roluri (pentru grupuri de utilizatori, dei, la crearea oricrei bd, Oracle i asigneaz cinci roluri sistem). Jurnalele de verificare a accesului sunt activate / inhibate manual (cu comenzile AUDIT / NOAUDIT).
Securitatea datelor n SQL Server

SQL Server al Sybase ofer Secure Server, un program ce se conformeaz standardelor de securitate de nivel B1 i B2 elaborate de Pentagon. Conform acestuia, utilizatorii trebuie nti s fie autorizai de a lucra cu Secure Server, apoi cu o bd oarecare (privilegiu pe care, de exemplu, un utilizator din categoria oaspete nu l are dect pentru date considerate publice, dac administratorul bd nu interzice i aceasta!) i abia n final cu un obiect al bd respective. Privilegiile sunt numite permisiuni , sunt gestionate n mod standard SQL (GRANT / REVOKE) i sunt de dou niveluri: comand (creare, salvare, interogare, modificare obiecte) i obiect (interogare i actualizare date ntr-o tabel). Ierarhia utilizatorilor include trei tipuri de roluri (administratori sistem, ofieri de securitate a datelor i operatori sistem), plus oricte alte niveluri inferioare de grupuri de utilizatori sau utilizatori individuali obinuii. Versiunea 10 include i un jurnal de verificare a accesului; diverse proceduri memorate (vezi capitolul 17) permit ofierilor de securitate (singurii care au acces la asemenea jurnale!) s urmreasc orice ncercare de acces, a oricui, la orice obiect.
Securitatea datelor n CA-OpenIngres

i viitoarea versiune anunat (1.1) a CA-OpenIngres se va conforma standardelor de securitate C2 ale Pentagonului. Versiunea curent ns este doar standard SQL (GRANT / REVOKE). Privilegiile sunt granulare, incluznd: selecie date, inserie, actualizare, tergere, toate cele precedente i execuie proceduri memorate (care nu necesit nici mcar privilegiul de selecie a datelor procesate de procedur!). Pentru accesul la Knowledge Manager sunt necesare privilegii speciale suplimentare. Pot fi create grupuri de utilizatori avnd aceleai privilegii; aplicaiile se bucur sau nu de roluri (numele generic al privilegiilor ce pot fi acordate sau nu programelor). Majoritatea bd gestionate de Ingres sunt publice; se pot ns defini bd private, la care au acces doar proprietarul bd, administratorul sistem i eventualii utilizatori crora le-au fost acordate privilegii de proprietar (administratorul sistem neavnd acest drept). Sunt meninute i jurnale de control al accesului, dei acestea sunt mai degrab o form primitiv de jurnale de actualizare (care nu exist) n care ns nu sunt memorate instruciunile i/sau valorile modificate, ci doar data i ora nceperii tranzaciei, identificatorul acesteia, numele utilizatorului, tipul de operaii efectuate (selecie, inserie, actualizare, tergere) i identificatorul fiecrei tabele accesate.
41
5. IMPUNEREA CONSTRNGERILOR DE INTEGRITATE

Meninerea integritii datelor este, de departe, cea mai important sarcin permanent a oricrui SGBD. Ca atare, sunt oferite diverse mecanisme de verificare a consistenei datelor i de impunere a constrngerilor de integritate. Ne vom focaliza din nou atenia numai asupra celor mai des ntlnite asemenea mecanisme. Cea mai simpl verificare cu putin este cea de ncadrare a tuturor valorilor pe care le au datele fiecrei coloane a oricrei tabele dintr-o bd ntr-un interval de valori (explicit precizat de administratorul bd pentru datele fundamentale sau implicit, pentru cele derivate). SGBD relaionale ofer n acest scop cel puin dou mecanisme suport pentru integritatea domeniilor (de valori) i integritatea referinelor.
Integritatea domeniilor de valori

Integritatea domeniilor de valori implementeaz constrngeri de tip min x max, unde min i max sunt valori dintr-un codomeniu oarecare fixat. Desigur c SGBD evoluate pot impune nu numai faptul c valorile oricrei coloane din orice tabel trebuie s satisfac un asemenea predicat, ci i operatorii ce sunt aplicabili coloanelor n consecin. De exemplu, dac domeniul de valori al unei coloane Sex este M,F , pe lng restricia c M i F sunt singurele valori admisibile pentru aceast coloan, SGBD poate deduce c operatorii de egalitate i non-egalitate sunt acceptabili pentru orice dou valori ale acestei coloane (egalitatea fiind necesar, de exemplu, pentru a putea rspunde la o ntrebare de tip Listeaz toi angajaii de sex feminin) n timp ce toi ceilali operatori relaionali de comparaie sau cei de calcul aritmetic nu ar avea sens s fie aplicai asupra acestor valori. Implementarea integritii domeniilor este de obicei fcut prin specificarea constrngerilor dorite la definirea sau redefinirea fiecrei coloane n parte (constrngeri ce pot fi implicite, atunci cnd se precizeaz doar codomeniul, caz n care min i max sunt cea mai mic, respectiv cea mai mare valoare oferite de acea implementare pentru codomeniul respectiv).
Integritatea referinelor
Ca efect al propagrii cheilor, al dependenelor de incluziune sau al constrngerilor de tip sisteme de reprezentani (vezi prima parte a lucrri), multe tabele ale unei bd relaionale conin coloane de pointeri spre alte tabele sau chiar spre tabela din care fac parte (iar cum pointerii sunt folosii i de SGBD non-relaionale, problema aceasta este mult mai general). Valorile dintr-o asemenea coloan (numit i cheie strin) trebuie ntotdeauna s fie strict printre valorile unei alte coloane ce face parte dintr-o cheie a unei tabele. De exemplu, coloana Jude dintr-o tabel de Localiti ar trebui s aib mereu valori din coloana CodJude, cheie n tabela de Judee. Acest tip de constrngere se numete integritatea referinelor. Precizarea i implementarea integritii referinelor poate fi fcut automat, transparent utilizatorilor, de un SGBD evoluat (i, de exemplu, Access o i face aa). Alte SGBD cer specificarea explicit a fiecrei asemenea constrngeri odat cu (re)definirea coloanei respective, fcnd ns apoi automat impunerea lor. Sunt ns i SGBD care ofer posibilitatea alternativ de impunere a integritii referinelor i de ctre proceduri utilizator (de tip trgaci, pe care le vom discuta mai jos) sau numai astfel, fr nici un suport alternativ de impunere automat.
42
Impunerea integritii referinelor nu este complet trivial, nici mcar n cazul actualizrii valorii pointerilor. Astfel, dac la inseria unui nou pointer sau la modificarea valorii unuia existent cu o valoare inexistent n coloana cheie referit de pointer exist soluia simpl a respingerii actualizrii respective, un SGBD evoluat ar trebui desigur s ntrebe utilizatorul dac nu cumva dorete s insereze un nou rnd n tabela referit, avnd noua valoare drept cheie, sau poate dorete s modifice una dintre valorile cheii referite n noua valoare (n loc de respingerea actualizrii, care de multe ori oblig utilizatorul s deschid i tabela referit n mod actualizare date, s insereze sau modifice n ea pentru a aduga noua valoare printre chei, nainte de a se rentoarce n tabela iniial pentru a relua operaia respins). Iar dac modificarea valorilor cheii referite poate conduce la complicaii (cci s-ar putea cere, din greeal, modificarea ntr-o alt valoare deja existent a cheii, tentativ ce trebuie respins desigur), mcar inserarea unei noi chei n tabela referit este o facilitate extrem de simplu de implementat i care economisete mult timp utilizator. n cazul actualizrii valorilor unei chei referite (de una sau mai multe coloane) prin tergerea unei valori existente, n coloanele ce refer cheia respectiv pot aprea probleme de implementare i mai mari. Astfel, dac tergerea ar fi pur i simplu permis (ceea ce se ntmpl nc, din pcate, n destule SGBD relaionale!) toi pointerii care refereau acea valoare a cheii rmn n aer, drept pentru care sunt referii ca pointeri ncurcnd lumea (dangling pointers). Desigur c cea mai simpl soluie este de a interzice orice asemenea tergere. ntr-o asemenea implementare ns, dac tergerea este uneori chiar necesar, utilizatorul va trebui nti s tearg toate referinele la acea valoare a cheii. S-ar putea deci oferi utilizatorilor posibilitatea de a opta pentru tergerea automat att a valorii cheii referite, ct i a tuturor referinelor la ea (sau nlocuirea acestora cu referine la obiectul necunoscut corespunztor). Poate nu chiar att de evident, ns cu att mai important de avut n vedere n rezolvarea acestei delicate probleme de implementare a SGBD, este faptul c i rndurile ce conin pointeri ce urmeaz a fi astfel teri pot fi, la rndul lor, referii de alte chei strine, pe oricte astfel de niveluri de recursivitate! Mai mult, ntr-un SGBD ce ar suporta printre constrngeri pe cele de tip sisteme de reprezentani (SR), cum ar fi unul construit pe baza MMED (vezi [253] i prima parte a lucrrii), s-ar putea oferi utilizatorilor i facilitatea de a reorganiza clasele de echivalen automat, inclusiv prin splitarea unei clase n mai multe noi clase (mai fine) sau, dual, prin contopirea mai multor clase ntr-una singur. Evident c asemenea operaii ridic noi probleme de implementare legate tot de faptul c, n asemenea situaii, ar fi necesar i modificarea corespunztoare a tuturor pointerilor ce refer cheile implicate (iar dac pentru contopiri acest lucru se poate face complet automat, transparent utilizatorului, n cazul splitrilor este desigur nevoie de consultarea utilizatorului pentru fiecare pointer n parte).
Trgaciuri
Oricte alte mecanisme de verificare i impunere a constrngerilor de integritate primitive ar mai oferi un SGBD, el tot trebuie s permit (pentru a putea garanta deplina consisten a bd) i impunerea de constrngeri bazate pe predicate oarecare, ad-hoc. Acest lucru este oferit de majoritatea SGBD sub forma procedurilor de tip trgaci (declanator). Un asemenea trgaci (trigger) este o procedur utilizator (scris pentru implementarea unei sau mai multor constrngeri predicative oarecare) creia i se asociaz la definire momentul n care execuia ei trebuie declanat automat de sistem. Implementrile uzuale specific pentru aceasta coloana (sau coloanele) n care, dac se ncearc scrierea unei/unor valori, SGBD apas automat pe trgaci; dac trgaciul constat c noile valori nu violeaz constrngerea pe care el o impune, SGBD va permite scrierea noilor valori; n caz contrar, scrierea este respins, iar SGBD obligat probabil s-i desfac tranzacia care a atentat astfel la integritatea bd.
Procesarea n dou faze a terminrii execuiei tranzaciilor

Pentru a asigura integritatea tranzaciilor atunci cnd dou sau mai multe SGBD concur la execuia lor se folosete aa-zisa procesare n dou faze a terminrii execuiei tranzaciilor. De exemplu, n cazul unei tranzacii de tip transfer electronic al unei sume de bani la distan (dintr-un cont
43
bancar n altul), trebuie sczut suma transferat din contul debitor (gestionat de un SGBD1) i crescut corespunztor suma n contul creditat la distan (care este gestionat de un SGBD2). Protocolul n dou faze a terminrii trebuie s garanteze faptul c cele dou SGBD ori au efectuat ambele aceste operaii, ori nici una dintre ele. n esen, acest protocol desemneaz un SGBD drept coordonator al execuiei tranzaciei, n timp ce celelelalte SGBD implicate trebuie s acioneze doar ca participani la aceasta, supunndu-se instruciunilor SGBD coordonator. Dup ce toate instruciunile tranzaciei au fost executate (de ctre SGBD corespunztoare) terminarea tranzaciei are loc n dou faze: 1. O faz de PREPARARE a terminrii, n care coordonatorul comand participanilor s termine tranzacia, ateptnd apoi (un interval de timp finit, prestabilit) de la fiecare confirmarea posibilitii terminrii acesteia. 2. O faz de TERMINARE propriu-zis sau de ROLLBACK, n funcie de confirmrile primite de la participani. Dac toi participanii implicai au confirmat posibilitatea terminrii tranzaciei, atunci coordonatorul emite pentru fiecare n parte instruciunea de terminare a acesteia (COMMIT); dac ns vreun participant nu confirm (fie din pricina unei erori locale, sau de transmisie, sau a unei cderi complete a sistemului etc.), atunci coordonatorul emite pentru toi participanii instruciunea de desfacere a (dare napoi, anulare a efectelor) tranzaciei (ROLLBACK), astfel nct integritatea datelor s nu fie afectat. Nevoia unui asemenea protocol poate aprea att n cadrul unei unice platforme (rulnd dou sau mai multe SGBD concurente, vezi cazul platformelor paralele, dar nu doar al acestora), ct i pentru arhitecturi de platforme interconectate (la distan sau local) ale cror SGBD trebuie s coopereze. Particularitile bd distribuite complic ns mult situaia i impun rafinri ale acestui protocol. Pentru a le nelege, s analizm urmtoarele dou exemple: Exemplul 13.1
Fie un coordonator i doi participani, ambii rspunznd pozitiv (i.e., gata de terminare) la prima faz. Ca atare, coordonatorul i nscrie n jurnal instruciunea de terminare COMMIT i ncearc s o transmit i celor doi participani. Dac unul dintre ei nu mai poate fi brusc contactat (exemplu, din cauza unei ntreruperi a transmisiunilor n reea), coordonatorul va fi obligat, pentru pstrarea integritii tranzaciei, s ncerce n mod repetat transmiterea COMMIT-ului pentru server-ul inaccesibil, pn cnd va obine de la acesta confirmarea recepionrii ei. Evident c aceasta cost coordonatorul timp de execuie aproape inutil, cci integritatea datelor este asigurat deja (manipularea datelor de ctre tranzacie ncheindu-se cu bine). Dar i server-ul care nu a primit instruciunea COMMIT are de suferit, cci nici unul din eventualele lacte puse de tranzacia n cauz asupra datelor locale nu poate fi scos pn la terminarea ei: ca atare, alte tranzacii pot fi temporar (dar poate pe termen inacceptabil de lung) blocate n ateptarea eliberrii lactelor n cauz.
Pe lng complicaiile ce pot aprea ca urmare a erorilor de transmisie n reele, sunt desigur posibile oricnd i cderi de sistem ale serverelor locale, ce antreneaz i ele costuri suplimentare pentru meninerea integritii datelor i tranzaciilor.
44
Exemplul 13.2
S presupunem exact aceeai situaie ca n exemplul 13.1, cu singura deosebire c toi participanii au primit instruciunea COMMIT, dar unul dintre ei are o cdere de sistem nainte de a apuca s o nscrie n jurnal. La repornire, dac ar considera tranzacia respectiv ca neterminat, ar trebui s o desfac nainte de a o lansa din nou, ceea ce ar viola, evident, integritatea datelor distribuite (cci tranzacia este de fapt terminat pe toate serverele). Ca atare, pentru a hotr ce tranzacii s-au terminat de fapt dintre cele aparent neterminate, SGBD repornit trebuie nti s se consulte cu coordonatorul fiecrei asemenea tranzacii n parte.
Drept urmare, pentru reducerea traficului de mesaje n reea, au fost aduse dou mbuntiri majore acestui protocol: terminarea presupus (presumed commit) i abortarea presupus (presumed abort) a tranzaciilor. n exemplul 13.1 de mai sus, atunci cnd participanii confirm coordonatorului posibilitatea terminrii tranzaciei, ei i nscriu n jurnal instruciunea de terminare presupus i pot astfel scoate toate eventualele lacte puse de tranzacie; la rndul su, la primirea tuturor confirmrilor, coordonatorul scrie i el n jurnal instruciunea de terminare presupus, iar dac nu mai poate s transmit COMMIT vreunui participant, nici nu mai ncearc acest lucru pn la restabilirea comunicaiilor cu acesta (de care va afla, la un moment dat, ori cnd va fi reapelat de acel participant, ori cnd va mai ncerca s-l contacteze pentru o alt tranzacie).

Constrngerile de integritate au fost introduse de printele modelului relaional, distinsul matematician E.F.Codd nc din 1970 [106]. Dependenele de incluziune ce formalizeaz integritatea referinelor au fost introduse abia un deceniu mai trziu de Fagin [136]! Trgaciurile se datoreaz echipei System R [27]. Ullman [336,337] i Date [122,123] dedic capitole ntregi problematicii constrngerilor de integritate a datelor.
Impunerea constrngerilor n DB2

DB2 al IBM a fost primul SGBD comercial care a suportat declaraii de constrngeri viznd integritatea referinelor (prin clauza FOREIGN KEY a instruciunii CREATE TABLE) i impunerea lor automat. El permite i specificarea politicii de urmat n cazul cererii de tergere a unei linii referite: interzicerea tergerii, tergerea n cascad, mpreun cu toate referinele, sau tergerea doar a liniei respective, cu anularea referinelor (cu excepia cazului n care, cel puin pentru o referin dintre cele implicate, valorile nule nu sunt permise; atunci tergerea este interzis). Actualizarea valorilor de chei primare referite de vreo linie (printr-o cheie strin) este interzis; similar, valorile cheilor strine pot fi modificate doar n una din valorile existente ale cheii primare referite. DB2 suport trgaciuri; n versiunea 4, verificarea integritii domeniilor este extins i la mulimi de valori enumerate (ce pot fi specificate cu ajutorul clauzei CHECK (nume_coloana IN (mulime_valori)). Administratorii bd pot suspenda temporar impunerea automat a constrngerilor (de exemplu, pentru a ncrca mai rapid o tabel cu date) pentru o tabel sau o partiie a sa; cnd se dorete revenirea la normal, invocarea utilitarului CHECK DATA va elimina liniile invalide (ce vor fi plasate n tabele de excepii) i va informa sistemul despre ncetarea suspendrii temporare a verificrilor de integritate pentru datele respective.
45
Impunerea constrngerilor n NonStop SQL

Integritatea domeniilor de valori este implementat n NonStop SQL al Tandem prin instruciunea CREATE CONSTRAINT; aceasta asociaz un nume fiecrei constrngeri i permite folosirea de expresii logice i algebrice n definirea lor.
Impunerea constrngerilor n Oracle

Oracle permite impunerea constrngerilor de codomenii (exact ca DB2, cu CHECK, care poate ns include i expresii logice i algebrice), de integritate a referinelor (tot ca n DB2, dar fr opiunea de tergere cu anularea pointerilor n referine) i trgaciuri. Trgaciurile sunt proceduri memorate speciale (vezi capitolul 17) scrise n limbajul de programare extins PL/SQL, care sunt ataate tabelelor i se execut automat exact nainte de sau dup un eveniment oarecare (exemplu, execuia unei instruciuni INSERT, UPDATE sau DELETE asupra tabelei), o dat per eveniment sau pentru fiecare linie procesat n cadrul evenimentului. Fiecrei tabele i se pot asocia oricte trgaciuri, inclusiv incluse unul n altul, ce vor fi executate de sistem ntr-o ordine arbitrar. Administratorii bd pot suspenda temporar execuia automat a trgaciurilor (din considerente de performan sau de indisponibilitate temporar a unor date).
Impunerea constrngerilor n SQL Server

SQL Server al Sybase ofer doar reguli (pentru specificarea integritii codomeniilor) i trgaciuri (maxim 3 per tabel, cte unul per INSERT, UPDATE, respectiv DELETE, dar care pot fi recursive -cel mult 16 apeluri- i pot apela alte trgaciuri). ncepnd cu versiunea 10 abia este disponibil i impunerea automat a integritii referinelor (dar tergerile liniilor referite sunt interzise; dac utilizatorul dorete altfel, el trebuie s-i defineasc, n continuare, un trgaci corespunztor).
Impunerea constrngerilor n CA-OpenIngres

CA-OpenIngres implementeaz integritatea codomeniilor cu ajutorul instruciunii CREATE INTEGRITY (mulimile enumerate necesit ns o expresie logic disjunctiv, deci de tipul c = k1 or c = k2 or ... , unde c este numele coloanei, iar kj sunt elementele codomeniului enumerat!). Trgaciurile se numesc reguli i sunt deocamdat singurul mod de a cere impunerea integritii referinelor! (abia versiunea urmtoare i-a propus, dup cum s-a anunat, automatizarea ei). Particularitatea interesant ns este generalizarea tipurilor de evenimente ce pot declana trgaciuri, prin posibilitatea specificrii de evenimente semnal de alarm (event alerters): acestea sunt evenimente externe SGBD (precum, de exemplu, scderea stocului sau preului la un produs sub un anume prag) care provoac ns i ele execuia imediat a unei aplicaii utilizator.
46
6. IMPLEMENTAREA FIIERELOR INDEX

Pentru mrirea performanei accesului la date SGBD permit definirea i folosirea fiierelor index. Un index este un fiier asociat uneia sau mai multor coloane dintr-o tabel (fiier de date) similar indexului din biblioteci de regsire rapid a crilor (depozitate ntr-o zon a unui raft, dintr-o sal, aflat la un etaj, din aripa unei cldiri etc.). n absena unui index, SGBD ar trebui s inspecteze secvenial tabela (fiierul de date) n cutarea oricrei date dorite. Indexurile pot fi automat creai de SGBD (pentru cheile tabelelor sau pentru a mri viteza de procesare a interogrilor) sau creai la cererea administratorilor sau utilizatorilor bd. Similar, actualizarea lor (pentru a reflecta actualizrile datelor indexate) se face automat, transparent utilizatorilor, de marea majoritate a SGBD evoluate, dei i acesta poate include comenzi de reindexare la ndemna utilizatorilor. tergerea indexurilor are acelai regim: automat, pentru indexurile temporar create de SGBD ori pentru tabelele terse, sau manual. La limit, desigur, se pot crea indexuri pentru toate coloanele tuturor tabelelor. Trebuie ns avut mereu n vedere faptul c fiecare index ocup spaiu disc i consum timp att pentru crearea, ct i pentru actualizarea sa. Implicit, SGBD moderne creeaz automat indexuri pentru fiecare cheie (coloan sau mulime de coloane minimal injectiv; vezi prima parte a lucrrii) n parte. Asemenea indexuri sunt zise unice, spre deosebire de cele non-cheie (care admit deci duplicate printre valorile indexate) care se zic neunice. Unele SGBD ofer i indexuri ciorchine (cluster) care asigur performane sensibil mrite pentru unele operaii (exemplu: gsirea tuturor articolelor tiinifice publicate pe o tem fixat n ordinea invers a publicrii lor). Aceasta implic ordonarea liniilor din tabel n ordinea indexului pentru fiecare ciorchine al tabelei (ciorchinele fiind o pagin disc n care sunt memorate mai multe linii). Cel mai rapid acces la date s-ar obine dac am putea indica SGBD adresa la care se gsete pe disc fiecare dintre tuplii pe care dorim s i accesm (aa-zisul identificator al tuplului, prescurtat IDT). Desigur c acest lucru este aproape imposibil pentru un volum mare al datelor, care se i modific continuu prin inserarea i tergerea de noi linii (articole). Exist foarte multe tehnici posibile de implementare a indexurilor; cele mai uzuale dintre ele sunt ns tabelele talme-balme (hash), care ncearc doar s calculeze IDT i arborii B+, care prefer memorarea tuturor IDT.
Accesul talme-balme (hash)

Dei este cunoscut i aplicat de mult, inclusiv de sistemele de operare, descriem i noi n aceast subseciune mecanismul de acces talme-balme (hash), zis i acces dispersat: n locul IDT al tuplului dorit, utilizatorul poate furniza sistemului doar o cheie de cutare talme-balme a acestuia, pe baza creia SGBD calculeaz apoi adresa corespunztoare. Unic per tabel, aceast cheie este constituit din una sau multe coloane ale tabelei (exemplu, pentru o tabel de angajai: numrul de identificare sau numele i prenumele angajailor). SGBD folosete o rutin (subprogram) de calcul al unei adrese de memorare unice pentru orice linie a tabelei pe baza valorilor acestei chei de cutare. n SGBD relaionale, cheia de cutare implicit este cheia (primar a) tabelei. Exist muli algoritmi pentru transformarea valorilor cheii de cutare n adrese. Cel mai adesea folosii sunt cei de tip aritmetic, ce au avantajul vitezei foarte mari de calcul (cteva instruciuni aritmetice cu operanzi deja n RAM fiind suficiente); de exemplu, se mparte valoarea cheii (interpretat ca un numr ntreg) la un numr prim suficient de mare, iar restul obinut este considerat a fi adresa dorit. Astfel, valoarea cheii de cutare poate fi direct i rapid transformat de SGBD n IDT corespunztor.
47
Obinerea IDT ns (care trebuie s fie unic pentru orice tuplu!) nu este garantabil de ctre algoritmii talme-balme. Desigur c este posibil coliziunea unor chei, adic apariia de sinonime (i.e. valori ale cheii pentru care rutina de transformare calculeaz o aceeai valoare). De exemplu, dac o companie are 50 de angajai, identificai de numere de la 1 la 50 memorate de o cheie talme-balme ID_Ang definit, pentru economie de spaiu, ca un numr binar pe 2 octei (putnd deci identifica 65.536 posibili angajai), iar rutina alege drept numr prim pe 47, atunci cheile 1 i 48, respectiv 2 i 49, ca i 3 i 50 vor fi sinonime, producnd coliziuni n calculul IDT. Cea mai frecvent metod de rezolvare a coliziunilor este gruparea fiecrui grup de sinonime n cte o gleat (bucket): ori se aloc spaiu pentru o singur gleat mare, n care sunt memorate toate sinonimele nlnuite (pe clase de echivalen); ori se aloc spaiu fix pentru fiecare sinonim, iar cnd o asemenea gleat se umple, ori se mresc toate gleile (ceea ce ar putea conduce la mari pierderi de spaiu, cci alte glei pot rmne aproape goale), ori tuplii care ar da pe dinafar sunt memorai nlnuit ntr-o unic gleat suplimentar (ca n prima variant). n oricare dintre implementri ns, n caz de coliziune, SGBD trebuie s caute secvenial n gleata respectiv tuplul dorit (pe baza valorii cheii de cutare). Oricum, accesul de tip talme-balme este util doar n anumite cazuri particulare, pentru acces aleator la cte un tuplu rzle; pentru accesul implicnd intervale de valori ale unor chei ordonate sau pentru aplicaii ce solicit sortarea rspunsului (cresctor sau descresctor) dup valoarea unei chei, arborii B+ sunt mult mai indicai. Totui, destule SGBD nc mai ofer i chei talme-balme.
Arbori B+
Arborii B+ sunt structuri de date arborescente special proiectate pentru implementarea indexurilor n bd. Fiierul index propriu-zis este partajat ntre frunzele arborilor; fiecare frunz conine mai multe perechi formate dintr-o valoare a cheii indexate i IDT corespunztor, ordonate (de obicei cresctor) dup valoarea cheilor. Celelalte noduri (interne) ale arborelui B+, inclusiv rdcina, sunt constituite de pagini (blocuri); o asemenea pagin conine ntotdeauna maxim k valori ale cheii indexate, intercalate printre k+1 pointeri ctre nodurile fii ale paginii respective (unde naturalul k este fixat prin calcule de optimizare a vitezei de acces la date prin arbore, innd cont att de minimizarea spaiului disc ocupat de index, ct mai ales de timpul necesar reorganizrii arborelui atunci cnd se depete capacitatea de memorare a unei pagini, ca i de timpul necesar reechilibrrii arborelui n urma inserrii i tergerii de chei indexate). Figura 14.1 ofer un exemplu de asemenea arbore B+; * din frunze figureaz IDT-uri; se observ c toate nodurile interne conin succesiuni de tip (pointer1, cheie1, pointer2, cheie2, ..., pointerk+1), unde pointerii sunt figurai prin * iar semnificaia oricrui pointerj este urmtoarea: nodul fiu indicat de acest pointer este ori frunza ce memoreaz toate valorile cheii indexate cuprinse n intervalul mrginit de cheiej-1 i cheiej+1, ori o alt pagin coninnd valori ale cheii aflate n acelai interval. Dac pointerul este primul sau ultimul din nod, atunci cheiej-1 respectiv cheiej+1 sunt considerate a fi valorile cheii corespunztoare din pagina tat a celei curente (adic cea aflat imediat la stnga, respectiv imediat la dreapta pointerului care indic pagina curent; n cazul rdcinii, n mod natural, la stnga primului pointer se consider a fi valoarea minim posibil a cheii, iar la dreapta ultimului pointer, dual, se consider valoarea maxim posibil a cheii). Principala proprietate a arborilor B+ este echilibrarea: n orice moment, distana de la rdcin la orice frunz trebuie s fie aceeai. Aceasta asigur SGBD aceeai vitez de regsire a oricrei valori a indexului i expansiunea arborelui nti pe orizontal, la maxim i abia apoi cu un nou nivel pe vertical (asigurndu-se mereu numrul minim posibil de niveluri de cutare); n plus, ea previne degenerarea arborelui ntr-o list nlnuit.
48
* 30 * 60 * pagina rdicin
*10 * 18 *
* 36 * 43 * 51 *
* 72 * 85 *
2*4*7*8*
11 * 15 * 18 *
19 * 30 *
31 * 35 *
37 * 38 * 41 *
44 * 45 * 51 * ..
Pointeri IDT ctre tuplii indexai
Figura 14.1 Un exemplu de arbore B+
Pe lng un acces suficient de rapid la orice tuplu, fr complicaii de tip coliziune, arborii B+ sunt extrem de eficieni pentru accesul implicnd intervale de valori ale unor chei ordonate sau pentru aplicaii ce solicit sortarea rspunsului (cresctor sau descresctor) dup valoarea unei chei astfel indexate. Mai mult, el permite furnizarea rspunsului la interogrile ce implic doar coloane indexate n mod simplu, direct din fiierul index, fr a mai fi necesar consultarea tabelei corespunztoare (acelai lucru e valabil i pentru joinuri, vezi capitolul 15).
Memorarea grupat a tuplilor n pagini

Majoritatea SGBD evoluate optimizeaz att spaiul disc ocupat de bd, ct i accesul la informaii memornd grupat tuplii n pagini. Ca atare, IDT sunt de fapt perechi de numere, n care primul indic pagina iar al doilea indic deplasamentul (offset) tuplului n pagin (i.e. distana de la nceputul paginii i pn la nceputul tuplului). Mai precis, cum numrul de tuplii ce ncap ntr-o pagin este fixat, se rezerv la sfritul fiecrei pagini cte o csu (slot) pentru memorarea deplasamentelor fiecrui tuplu din pagin. Aceast dubl indirectare are avantajul c, att timp ct un tuplu este memorat ntr-o aceeai pagin, IDT-ul su nu se modific (deci nici indexul su nu trebuie modificat, fie el tabel talmebalme, fie arbore B+), chiar dac poziia tuplului n pagin se schimb. Pe lng economia de timp astfel realizat, aceasta permite SGBD reorganizarea intern a paginilor memornd tuplii (pentru recompactarea sau sortarea lor) fr afectarea indexurilor.

Biblia structurilor de date, inclusiv deci tabele talme-balme, arbori, sortare etc.[210], rmne i astzi impresionanta serie de volume Arta programrii calculatoarelor a distinsului matematician american Donald E. Knuth. Arborii B au fost introdui de Bayer i McCreight [51] n 1972, nencetnd de atunci s fie perfecionai de nenumrate ori, inclusiv de Bayer [52], dar i de ali cercettori, precum Comer [113] sau Rosenberg i Snyder [300]. Acest lucru va continua probabil mereu, pentru a exploata noile performane hardware la dispoziie i a mri mereu viteza aplicaiilor de bd din ce n ce mai complexe.
49
Cea mai interesant generalizarea a arborilor B ni se par a fi cile de acces generalizat la date propuse de Haerder [168]. Alte texte de referin n domeniu includ, desigur, Ullman [336,337] i Date [122,123].
Fiiere index n DB2

DB2 al IBM folosete doar arbori B+ pentru orice index; spaiile index sunt automat create i gestionate de sistem la declararea indexurilor de ctre utilizatori. Pot fi definite indexuri unice, ciorchine i indexuri compuse (maxim 64 de coloane per index). Versiunea 4 ofer i aa-ziii indexuri de Tip 2: ele includ mbuntiri privind blocarea (aceste indexuri nu mai sunt blocate; doar tabelele se blocheaz!) i procesarea paralel (aceste indexuri sunt multi-nivel, nu au subpagini, iar IDT pentru cele neunice sunt sortate pentru mrirea performanelor n cazul existenei multor duplicate).
Fiiere index n NonStop SQL

NonStop SQL al Tandem creeaz implicit cte un index (arbori B+) unic pentru cheia primar (ce nu poate conine valori nule!) a fiecrei tabele (SYSKEY). El permite ns att tabele neindexate (pentru care ns lungimea liniei nu mai poate fi modificat dup introducerea de date n fiier), ct i tabele talme-balme. Indexurile pot fi unice, ciorchine i compuse (pentru care nu exist restricia adiacenei coloanelor componente!). Cea mai interesant inovaie n domeniul fiierelor index se refer ns la indexurile alternative (orice index, cu excepia celor pentru cheile primare ale tabelelor): acestea memoreaz nu doar valorile cheii respective, ci i pe cele ale cheii primare corespunztoare! Astfel, desigur, rspunsul la foarte multe interogri poate fi furnizat doar din indexuri, fr accesarea tabelelor propriu-zise.
Fiiere index n Oracle

Oracle ofer indexuri bazate pe arbori B*, unice sau neunice, ciorchine i compuse (maxim 16 coloane per tabel, nu neaprat adiacente). Accepiunea despre ciorchini de date este aceeai cu cea de la DB2, mai general dect cea menionat n prima seciune a capitolului, n sensul c fiecare ciorchine memoreaz linii din mai multe tabele legate ntre ele prin chei externe (de exemplu, toate localitile dintr-un jude sunt memorate mpreun cu linia corespunztoare din tabela de judee). Pentru aceasta, utilizatorul trebuie s furnizeze o cheie ciorchine, care s indice tabelele ce vor fi memorate astfel mpreun. Oracle ofer i ciorchini talme-balme.
Fiiere index n SQL Server

SQL Server al Sybase suport doar indexarea B+. Este permis un singur index ciorchine i maxim 249 non-ciorchine per tabel. Sunt oferite i indexuri unice i compuse (maxim 16 coloane).
Fiiere index n CA-OpenIngres

Fiierele index ale CA-OpenIngres pot fi partiionate i rspndite pe mai multe discuri, pentru mrirea performanelor sistemului. Se permit indexuri unice i compuse (maxim 32 coloane per tabel). Utilizatorii pot alege ei nii structura de date dorit pentru fiierele index (dar i de date!) dintre urmtoarele: talme-balme, arbori B+ i ISAM secveniale (fiiere sortate, statice, ce nu pot fi actualizate dect prin rescriere; folosite doar pentru date ce sufer modificri extrem de rar).
50
7. OPTIMIZAREA PROCESRII I ACCESULUI LA DATE

De cele mai multe ori exist mai multe posibiliti de a accesa datele dorite dintr-o bd. Orice SGBD care se respect are ncorporat, n consecin, un optimizator care o alege pe cea mai bun, la orice moment dat, n funcie de criteriul dorit. Strategia de acces la date aleas de optimizator este cel mai adesea decisiv n obinerea de performane ct mai bune. Ca atare, toi furnizorii de SGBD cheltuiesc enorm pentru perfecionarea optimizatoarelor cu care i doteaz produsele. Cea mai costisitoare operaie cu putin asupra datelor este, de departe, join-ul (vezi prima parte a lucrrii). Dei au fost proiectate foarte multe strategii de implementare a sa n diverse condiii, cercettorii n domeniu nc mai caut noi soluii, mai bune mcar n anumite circumstane. Este obligatorie, ca atare, nceperea acestui capitol cu studiul optimizrii join-ului. Mai general, orice acces la date (nu doar cel pentru calculul unui join sau a unei expresii de algebr relaional oarecare) poate fi uneori optimizat. Principalele dou tipuri existente de asemenea optimizri (pe care le vom studia, la sfritul acestui capitol n cazul SGBD relaionale, care le-am introdus i perfecionat iterativ) sunt bazate pe reguli, respectiv bazate pe costuri.
Optimizarea operatorului join

Dintre diversele variante de implementare a joinului, nu exist nici una care s fie cea mai bun n orice context; fiecare din cele analizate n continuare sunt mai bune dect celelalte numai n anumite condiii. Sarcina oricrui optimizator este ca, pe baza datelor statistice de care dispune (i, adesea, a unei euristici) s-o aleag pe cea mai bun dintre ele n orice moment.
Implementarea bucl n bucl a joinului

Implementarea cea mai simpl, prima care ar veni probabil oricui n minte, este cea de tip bucl n bucl (nested loop): algoritmul bucleaz pentru toate liniile din prima tabel i pentru fiecare din ele bucleaz pentru toate liniile din cea de-a doua tabel n cutarea eventualelor valori comune pentru coloanele implicate n join (urmnd, evident, ca la gsirea oricror dou linii din cele dou tabele care coincid pentru aceste coloane s genereze o linie n tabela join calculat). Dac n i m sunt, respectiv, numrul liniilor din cele dou tabele operand, este evident c acest algoritm este costisitor, complexitatea sa fiind proporional cu n*m. Aceast metod de calcul al joinului este, ca atare foarte scump dac tabelele sunt mari; pentru tabele mici ns sau chiar n cazul n care ele sunt mari dar exist un index pe coloana join din cea de-a doua tabel, ea poate fi mai bun dect orice alt implementare.
Implementarea sort/reuniune a join-ului

Dac coloanele join ale celor dou tabele sunt sortate n aceeai ordine (i.e. ambele cresctor sau ambele descresctor), algoritmul bucl n bucl poate fi imediat mbuntit n mod dramatic astfel: n bucla intern, dup gsirea unei egaliti, se mai continu scanarea tabelei sortate doar ct timp egalitatea se mai pstreaz; la prima linie pentru care cele dou coloane join difer, bucla intern este abandonat i algoritmul continu cu urmtoarea linie (a primei tabele) din bucla extern; profitnd i de sortarea primei tabele, cu ajutorul cte unui cursor pentru fiecare tabel i a unei variabile care s in minte mereu valoarea curent (din dreptul cursorului) a coloanei join din cea de-a doua tabel, se poate optimiza i bucla extern astfel nct fiecare linie a celei de-a doua tabele s fie citit tot o singur dat pe tot parcursul execuiei programului.
51
Evident c astfel pot fi economisite foarte multe accese la a doua tabel; este trivial faptul c, pstrnd notaiile introduse n seciunea anterioar, acest algoritm, numit sort/reuniune (sort/merge), are complexitatea proporional cu n+m. Dei aparent el este, ca atare, ntotdeauna mai bun dect primul (n+m < n*m, n,m naturali!), nu trebuie ns uitat c acest algoritm presupune sortarea ambelor coloane de join. Dac ele sunt deja sortate, aceast implementare este ntotdeauna preferat; n anumite condiii, chiar atunci cnd ele nu sunt sortate dar exist cte un index pentru fiecare, ea rmne cea mai bun soluie. Dac ns cele dou coloane nu sunt sortate, atunci SGBD trebuie s le sorteze n prealabil i acest cost suplimentar poate face aceast metod mai scump dect altele. n cazul tabelelor mari n care reuesc multe comparaii (i.e. sunt gsite multe egaliti i, deci, rezultatul joinului va avea multe linii), sort/reuniune rmne ns cea mai bun, chiar dac cele dou coloane trebuie nti sortate.
Implementarea hibrid a joinului

Una dintre implementrile recent propuse pentru join este o combinaie a celor dou metode clasice discutate mai sus, bucl n bucl i sort/reuniune, motiv pentru care ea se i numete hibrid. Ea presupune c o tabel are un index pe coloana join, iar cealalt are coloana join sortat n ordinea acestui index (dac nu este aa, atunci algoritmul debuteaz prin sortarea ei). Cu aceste condiii ndeplinite, algoritmul hibrid scaneaz indexul secvenial, construind, cu algoritmul "sort/reuniune, un join ntre tabela sortat i index (privit ca o tabel sortat cu dou coloane: cheia, coloan join sortat, i IDT, adic adresa liniei respective n tabela a doua, pentru care a fost construit indexul). Tabela rezultat obinut este apoi sortat cresctor dup coloana IDT (a adreselor tuplilor n tabela indexat) iar dup aceea, printr-un nou join "sort/reuniune" a acestei tabele intermediare cu tabela indexat (din care se elimin, desigur, coloana IDT) se obine rezultatul final. De remarcat c fiecare tuplu din cele dou tabele operand iniiale este citit doar o singur dat, ca n metoda "sort/reuniune". Desigur c se adaug costul operaiilor intermediare suplimentare ("sort/reuniune" cu indexul i sortarea tabelei intermediare), dar metoda devine cea mai bun pentru tabele mari cu multe duplicate n coloanele pe care se cere join-ul.
Implementarea talme-balme a join-ului

Dup cum sugereaz numele pe care l poart, aceast metod exploateaz viteza foarte mare cu care se pot calcula adrese din valori ale unei chei, prin accesul talme-balme (hash, vezi capitolul 14): din ambele coloane join se obine, cu un acelai algoritm talme-balme cte o tabel talme-balme; n fiecare dintre acestea, valorile egale vor ajunge, evident, n aceeai gleat. Cele dou tabele astfel obinute (fiecare din ele putnd conine ori doar IDT, adic adresa tuplului respectiv, ori tot tuplul, sau doar coloanele de interes) sunt apoi supuse unui join sort/reuniune (desigur, doar pentru intrrile lor nevide) care produce rezultatul cerut. Pentru mrirea performanelor acestui algoritm, se ncearc memorarea ambelor tabele talme-balme n RAM; dac acest lucru nu este posibil, se ncearc acest lucru mcar pentru una dintre ele. n general, se poate uor observa c performanele acestui algoritm scad pe msura creterii coliziunilor, n particular deci a numrului de duplicate n coloanele join.
Implementarea folosind semijoin-uri n bd distribuite

n contextul bd distribuite, costul transmisiei datelor depete cel mai adesea cu mult pe cel al procesrii lor propriu-zise. Ideea semijoin-urilor este tocmai de a optimiza joinul, atunci cnd cei doi operanzi rezid pe servere diferite, prin transferul minimului de informaii cu putin (ideal: doar al tuplilor joinabili).
52
Pentru aceasta, se proiecteaz nti una din tabele, de la locaia A (de regul, cea mai mic dintre ele, dac nu intervin alte considerente, vezi seciunea 15.6) pe coloana join, mpreun cu IDT (adresa tuplilor respectivi); tabela cu doar dou coloane rezultat al proieciei este mutat pe cellalt server B, unde se face un prim join ntre ea i cea de-a doua tabel; astfel sunt eliminate liniile ce nu trebuie transmise (cci nu iau parte efectiv la join). Se poate cere acum transmiterea de la A la B doar a acelor linii care sunt necesare, folosind IDT al acestora; n final, se poate calcula pe A join-ul cerut. Este evident faptul c reducerea costurilor de transfer a datelor astfel obinut poate fi considerabil, n special pentru tabele mari.
Alte tipuri de optimizri ale procesrii datelor

Metodele de implementare a joinurilor analizate n seciunea precedent nici nu sunt singurele i au i generat diverse variante mbuntite, n special prin utilizarea de fiiere index suplimentare. n plus ns, join-urile sunt rar necesare singure n aplicaiile uzuale de bd: cel mai adesea, ele sunt doar o parte din expresii algebrice complexe implicnd i selecii i proiecii (SPJ, vezi seciunea 1.4.4). Dei nu s-a putut gsi nici un algoritm general de optimizare a oricrei expresii de algebr relaional, literatura de specialitate conine att sugestii utile generale, ct i un algoritm de optimizare care este folosit, cu sau fr alte mbuntiri minore, de marea majoritate a SGBD pentru evaluarea expresiilor SPJ. Strategiile generale de optimizare includ: efectuarea seleciilor ct mai devreme cu putin (pentru eliminarea tuplilor ce nu vor mai participa n evaluarea n continuare a expresiei); pregtirea adecvat a cilor de acces (prin sortri i/sau creare de indexuri); memorarea rezultatelor subexpresiilor ce apar repetat ntr-o expresie (pentru a evita recalcularea lor la fiecare nou apariie; n special, este cazul punctelor de vedere utilizate repetat, cci definiia lor e ntotdeauna o subexpresie); evaluarea simultan a seleciilor i proieciilor adiacente asupra aceleiai tabele; combinarea proieciilor cu orice operaie binar adiacent (eliminarea unor coloane se poate face simultan cu citirea tabelei respective pentru efectuarea unei alte operaii); combinarea produselor carteziene cu acele selecii adiacente care le pot transforma n join (dac un produs cartezian este argumentul unei selecii ce conine i-uri logice de comparaii ntre coloanele operanzilor produsului, acesta se poate nlocui cu un join; de notat c, aa cum se poate uor demonstra, un produs cartezian este ntotdeauna mai scump dect orice join ntre operanzii si; merit semnalat aici de asemenea, c orice comparaie a seleciei ce nu implic nici o coloan a vreunuia din cei doi operanzi ai produsului cartezian poate fi mutat naintea produsului, ceea ce este preferabil chiar transformrii acestuia n join!). Folosind strategiile de mai sus, mpreun cu legile de asociativitate, comutativitate i distributivitate ale operatorilor algebrici relaionali, a fost proiectat algoritmul de optimizare a expresiilor relaionale menionat mai sus. n esen, construind un arbore sintactic pentru expresia de optimizat, acest algoritm const din urmtorii ase pai: 1. Transform orice conjuncie de selecii asupra unei expresii ntr-o cascad de selecii (asupra expresiei respective). 2. Mut orice selecie ct mai jos posibil n arbore (spre frunze). 3. Elimin proieciile inutile i mpinge toate proieciile ct mai jos posibil n arbore (eventual desfcnd unele din ele n dou, dac se poate, ori de cte ori proiecia nedesfcut nu mai poate cobor, dar mcar una din componentele sale ar mai putea-o face).
53
4. Combin cascadele de selecii i proiecii ntr-o singur selecie, o singur proiecie sau o selecie urmat de o proiecie. 5. Partiioneaz nodurile arborelui astfel rezultat n grupuri, dup cum urmeaz: fiecare nod interior reprezentnd un operator binar (produs, reuniune sau diferen) formeaz un grup ce mai conine toate nodurile strmoi adiacente reprezentnd operaii unare (selecii sau proiecii), precum i orice lanuri de descendeni unari ce se termin cu o frunz, cu excepia cazului n care operatorul binar e un produs cartezian ce nu este urmat de nici o selecie cu care s se poat combina pentru a se transforma n join. 6. Evalueaz grupurile independent unul de altul, cu singura restricie c nici un grup nu poate fi evaluat nainte de vreun grup descendent de-al su.
Folosirea mai multor fiiere index per tabel: implementarea index AND i index OR a seleciilor
Optimizatoarele SGBD moderne exploateaz i posibilitatea de a construi i menine mai mult de un fiier index per tabel, pentru mrirea performanelor implementrii operatorului relaional de selecie. Astfel, n cazul unor predicate de selecie compuse din conjuncii sau disjuncii de comparaii, existena cte unui index per comparaie permite implementarea index AND, respectiv index OR a seleciei. Exemplul 15.1
Fie o selecie asupra unei tabele T al crui predicat este o conjuncie de comparaii, fiecare din acestea implicnd cte o coloan diferit (C1 i C2) i dou constante (k1 i k2); n SQL, ea ar fi exprimat astfel: select * from T where C1 = k1 and C2 = k2 S presupunem c SGBD dispune de cte un index pentru fiecare din cele dou coloane; dac optimizatorul ar folosi doar unul dintre acetia, de exemplu cel pentru C1, ar putea selecta rapid doar toate liniile T pentru care C1 are valoarea k1; multe din acestea ns nu satisfac probabil predicatul de selecie, neavnd valoarea k2 n coloana C2 (i deci au fost inutil selectate, trebuind a fi eliminate din rspuns ntr-un al doilea pas). Folosirea concomitent a celui de-al doilea index ar putea, evident, optimiza implementarea acestei selecii.
Procesarea index AND pe care o schim n continuare presupune doi arbori B+ drept indexuri: optimizatorul scaneaz cele dou indexuri, selectnd din fiecare doar IDT ai tuplilor ce satisfac comparaia respectiv (pentru exemplu de mai sus, cei pentru care cheile index au valorile k1, respectiv k2); cei doi vectori (i.e. tabele unicoloan) de IDT astfel rezultai sunt apoi intersectai, obinndu-se n acest mod un vector ce conine doar IDT ai rspunsului cerut; pe baza sa, sunt n final citii din tabela T doar tuplii corespunztori. Evident c procesarea index OR este similar: dac predicatul seleciei din exemplul 15.1 ar fi or (n loc de and), este suficient nlocuirea interseciei cu reuniunea vectorilor de IDT.
54
Optimizarea accesului la date bazat pe reguli

n aceast abordare, SGBD examineaz interogrile i alege strategia de acces la datele necesare evalurii acestora lund n considerare eventualele indexuri existente pentru datele n cauz i sintaxa interogrii. n esen, aceasta presupune folosirea indexurilor ori de cte ori ele exist (pentru a evita cutrile secveniale n fiierele de date) i stabilirea unui set de reguli de optimizare a accesului. Un exemplu de astfel de regul ar putea fi urmtorul: dac accesul la date implic un join pe o coloan a unei tabele pentru care nu exist un index, atunci, nainte de calculul join-ului, construiete un index temporar pe acea coloan. Au fost propuse mai multe asemenea seturi ad-hoc de reguli, fr ns a se putea demonstra pentru vreunul eficiena sa n general sau mcar n raport cu vreun alt set de asemenea reguli. Mai mult, exist puternice indicii c aa ceva nici nu se poate demonstra vreodat. n plus, orice asemenea set presupune cunotine de specialitate din partea utilizatorilor (ca s poat formula interogri optimizabile) iar orice modificare ntr-un set de reguli necesit i modificarea unor tranzacii (deja scrise, testate i memorate pentru uzul curent) pentru a beneficia de noile optimizri posibile. Toate aceste considerente fac ca SGBD evoluate s prefere optimizarea bazat pe costuri.
Optimizarea accesului la date bazat pe costuri

n aceast abordare, SGBD consult nti statisticile aferente datelor implicate (i.e. dimensiunile tabelelor, existena i tipul indexurilor, cele mai mici i cele mai mari valori ale cheilor, distribuia valorilor pentru chei etc.) pentru a estima costurile asociate fiecrei posibile strategii de acces n parte. Statisticile despre date, fiind meta-date, sunt memorate n cataloage (vezi capitolul 16). Actualizarea lor este, n sine, o problem, cci ar micora sensibil performanele sistemului dac ar fi fcut la fiecare actualizare a datelor implicate. Ca atare, ea se face de ctre programe utilitare specializate la intervale mai mari de timp, de preferin cnd ncrcarea sistemului este minim. Pentru tabelele foarte mari i cu multe indexuri ea se poate face, opional, doar pe baza unui eantion aleator al tuplilor tabelei (ce poate fi precizat implicit, de sistem, sau explicit, de ctre administratorul bd). De asemenea, procesul evalurii costurilor i alegerii strategiei optime corespunztoare poate fi, la rndul su, foarte costisitor. De exemplu, dac o aceeai tranzacie este executat frecvent, reconsiderarea complet a optimizrii ei de fiecare dat este evitat de SGBD evoluate prin memorarea pe disc, n antetul tranzaciei, a programului de optimizare corespunztor; la o nou execuie ulterioar a ei, optimizatorul va avea deja toate cile de acces posibile, precum i formulele de calcul a costurilor asociate gata compilate, urmnd doar s refac calculele pentru valorile curente ale datelor statistice implicate.
Mecanisme de control a optimizrii accesului la date

Deoarece de eficiena optimizrilor depind critic performanele globale ale SGBD, acestea ofer de cele mai multe ori administratorilor de bd posibilitatea controlului optimizrilor (tuning). De exemplu, dac se constat c optimizatorul nu folosete niciodat (sau prea rar) un index s-ar putea hotr tergerea acelui index pentru a elibera spaiu disc i, mai ales, pentru a scurta timpul de decizie al optimizatorului; dual, dac se constat c optimizatorul construiete frecvent un index temporar, s-ar impune definirea sa cu titlu permanent. Pentru interogri al cror rezultat, ca urmare a seleciilor, conine doar puini tuplii, unele SGBD i bazeaz calculul costurilor doar pe un eantion restrns de date, micornd astfel cu mult timpul necesar fundamentrii alegerii strategiei optime.
55
Unele SGBD ofer chiar posibilitatea influenrii directe a comportrii optimizatorului ncorporat. De exemplu, prin modificarea sau adugarea unor reguli de optimizare sau prin specificarea n interogri a unor indicaii suplimentare de optimizare obligatorie a accesului ntr-un anumit mod (de exemplu, ignornd un index). Asemenea faciliti extrem de puternice trebuie desigur folosite cu foarte mari precauii: nu doar performanele de moment ale sistemului pot avea de suferit (mpiedicnd chiar SGBD s mai poat evalua, de exemplu, interogri pentru care este obligat s foloseasc un indice care, ntre timp, a fost ters!), dar i pe termen lung, cci asemenea tranzacii pot inhiba i versiuni ulterioare mbuntite ale SGBD s optimizeze poate mult mai bine performanele sistemului (pn nu se renun la indicaiile obligatorii). n general, optimizatoarele de azi sunt att de evoluate, nct recursul la asemenea tehnici directe de control al optimizrii este practic util doar n scop didactic.
Optimizarea global a accesului n bd distribuite

Optimizarea accesului n bd distribuite este, pe de-o parte, crucial (lipsa ei sau chiar slaba calitate a optimizrii putnd compromite total sistemul) iar pe de alta, extrem de dificil. Cei mai importani factori ce trebuie avui n vedere sunt cardinalitatea structurilor de date (de exemplu, numrul de linii ale unei tabele i dimensiunea liniei) i costurile comunicaiilor ntre servere. Aceasta se poate observa chiar i analiznd un simplu join, ca n exemplul 15.2: Exemplul 15.2
Fie trei servere distribuite la locaiile A, B i C; s considerm o tabel T cu 1.000 de linii memorat de A i o alta, T, cu 100.000 linii memorat de B; dac se cere din C un join al T cu T, aceast operaie se poate, evident, executa conform multor strategii, dintre care citm doar urmtoarele: 1. mut (copiaz) ambele tabele n C i efectueaz join-ul la C; 2. mut (copiaz) T n A, calculeaz join-ul n A i mut rezultatul n C; 3. mut (copiaz) T n B, calculeaz join-ul n B i mut rezultatul n C. Desigur c, fie i numai dpdv al cardinalitii, decizia nu este uoar: chiar dac, evident, a doua soluie poate fi eliminat ca fiind cea mai proast ntotdeauna, este greu de decis ntre prima i a treia! Astfel, dac rezultatul ar avea tot 100.000 linii, cele dou soluii sunt aproape la fel de costisitoare (prima probabil puin mai ieftin, cci, n general, rezultatul unui join are mai multe coloane dect fiecare operand n parte); dac el este mai mic, a treia variant e preferabil; dac el este mai mare, prima variant este preferabil! Dac ns se iau n calcul i costurile transmisiei, lucrurile se complic i mai mult, fiind posibil rsturnarea clasamentelor de mai sus!
Un bun optimizator ns va lua n considerare muli ali factori, printre care: ncrcarea curent a serverelor participante; performanele platformelor de calcul implicate; performanele reelelor implicate;
eventualele constrngeri administrative (exemplu, n perioade de vrf a ncrcrii locale, administratorii bd locali pot restrnge accesul la distan); constrngeri de spaiu disc disponibil;
56
alte costuri (de exemplu, dac timpul de rspuns nu este critic i dimpotriv, tarifele de comunicaie sunt mult mai avantajoase n anumite perioade de timp ale zilei, s-ar putea ca cea mai bun soluie pentru exemplul de mai sus s fie a doua!). Toate aceste considerente, care implic mult mai multe meta-date non-locale dect locale, depesc cu mult capacitile optimizatoarelor locale clasice i impun considerarea unor optimizatoare globale, capabile s menin statistici globale i s acceseze statisticile oricrui server participant.

Optimizarea join-ului a fost n atenia cercettorilor nc din faza de proiectare a primului prototip de SGBD relaional (System R al IBM), n 1976 [27] (dei Gotlieb [159] a fost cel care, n 1975, a prezentat primele dou metode de implementare a joinului). Autorii au proiectat, testat i evaluat patru tipuri de soluii, din care au reinut doar pe cele ce s-au i impus ulterior, ntr-adevr, n toate SGBD comerciale: bucl n bucl i sort/reuniune. n timp, au aprut diverse variante i mici mbuntiri ale acestora, din care multe sunt nc secrete, protejate cu gelozie de furnizorii de SGBD pentru pstrarea avantajelor fa de concuren. Optimizarea evalurii expresiilor algebrice relaionale, inclusiv euristica i algoritmul prezentate n seciunea 15.2, sunt descrise n amnunt de Ullman [336]; a doua ediie [337] prezint i optimizarea exact pentru interogrile conjunctive, o submulime a expresiilor SPJ.
Optimizarea n DB2
Optimizatorul DB2 al IBM, care a pornit de la prototipul System R, este considerat punctul forte al acestui SGBD. De exemplu, implementarea hibrid a joinului a fost proiectat pentru i utilizat prima dat n DB2; n plus, el suport index AND i index OR, ca i bucl n bucl i sort/reuniune. Mai mult, pentru a-i ajuta optimizatorul, DB2 calculeaz automat nchiderea tranzitiv a joinului: de exemplu, pentru joinul exprimat n SQL prin: select from where and el adaug automat: and Ta.C1 = Tc.C3 Utilizatorii care doresc s afle diversele variante avute n vedere de optimizator pentru evaluarea unei interogri, precum i strategia aleas n cele din urm (fr ca interpretorul s i evalueze interogarea, pentru a economisi timp!), pot invoca instruciunea EXPLAIN; efectul ei este doar memorarea datelor luate n calcul de optimizator, ca i a rezultatului deciziei acestuia ntr-o tabel PLAN_TABLE (al crui coninut, desigur, poate fi apoi interogat i a crui structur poate fi controlat i ea de utilizator, prin eliminarea unor cmpuri n cazul n care nu toate detaliile intereseaz). ncepnd cu versiunea 3, DB2 permite utilizatorilor influenarea optimizrii prin clauza OPTIMIZE FOR n ROWS a instruciunii SELECT; aceasta furnizeaz optimizatorului informaia c rezultatul interogrii respective va avea maxim n linii (dac, n realitate, ele vor fi mai multe, rspunsul va fi corect calculat totui, doar performanele evalurii putnd fi afectate). Pentru optimizarea n bd distribuite, DB2 ofer mai multe faciliti, din care se disting evidenierea n jurnale a activitilor iniiate la distan, mecanismele de citire i transmisie a datelor n blocuri mari (pn la 32 pagini cu o singur operaie de I/O) i execuia SQL static (vezi capitolul 17) de la distan. * Ta, Tb, Tc Ta.C1 = Tb.C2 Tb.C2 = Tc.C3
57
Optimizarea n NonStop SQL

NonStop SQL al Tandem, care permite programarea paralel, folosete intens joinul talmebalme care, mai ales pe platforme ce ofer asisten hardware procesrii paralele, se dovedete de foarte multe ori cea mai bun alegere n domeniu. i el utilizeaz toate celelalte metode de implementare a joinului, instruciunea EXPLAIN, precum i furnizarea de informaii utilizator suplimentare optimizatorului pentru a influena strategiile acestuia. Instruciunea CONTROL TABLE, de exemplu, poate chiar impune calea de acces dorit de utilizator (prin specificarea unui index obligatoriu). Citirea blocurilor mari de date cu o singur instruciune de I/O (aici referit ca sequential block buffering) permite accesul la 56K deodat; mai mult ns, operaiile de I/O cu discul pot fi nu doar fizice, ci i virtuale, pentru simplificarea sarcinii etajelor superioare ale SGBD: citirea fizic poate fi nsoit de selecii, proiecii i agregri GROUP BY ale datelor, ce mping astfel aceti operatori relaionali chiar n frunzele arborilor de evaluare optimizat a interogrilor!
Optimizarea n Oracle
Oracle mai suport nc optimizarea bazat pe reguli, dei s-a anunat c urmtoarele versiuni vor renuna la ea n favoarea optimizrii exclusiv bazat pe costuri. Statisticile pot fi i aici exacte sau aproximative; instruciunea EXPLAIN este i ea oferit. Utilizatorii pot influena deciziile optimizatorului, nu doar indicnd o cale de acces, ci chiar o anume implementare a joinului, sau scopul principal al optimizrii (exemplu, viteza gsirii primelor linii sau a tuturor liniilor rspunsului). Oracle este capabil de aplatizarea interogrilor, adic de recunoaterea subinterogrilor (SELECT n SELECT) ce exprim, de fapt, joinuri i de evaluarea lor ca atare (ceea ce este ntodeauna mai ieftin!); cu mici excepii ns, joinurile multitabele sunt evaluate n pai implicnd doar cte dou tabele la un moment dat.
Optimizarea n SQL Server

SQL Server al Sybase folosete doar index OR (nu i index AND!) dar construiete dinamic fiiere index temporare ori de cte ori acestea ar mri performanele evalurii. Datele statistice despre fiecare index includ i o pagin de distribuie a valorilor cheii respective n tabel, precum i densitatea indexului (numrul mediu de duplicate). O alt particularitate remarcabil este aa-numita utilizare a indexilor acoperitori (index covering): dac un index este definit pentru un produs de coloane, rspunsul la interogrile ce implic doar coloane din cele ce alctuiesc indexul este calculat doar pe baza fiierului index corespunztor, evitnd i consultarea tabelei indexate. SQL Server este i el capabil de aplatizarea interogrilor; mai mult, el poate calcula joinuri multitabel (implicnd ns maxim 4 tabele; un join de ase tabele, de exemplu, va fi calculat totui n doar doi pai n loc de cinci); din pcate ns el nu calculeaz automat nchiderea tranzitiv a joinului, aceasta rmnnd n sarcina utilizatorului. Joinul este implementat doar bucl n bucl!
Optimizarea n CA-OpenIngres
Optimizatorul CA-OpenIngres se bazeaz tot pe date statistice (exacte sau aproximative) i poate fi influenat de utilizatori, care pot vizualiza planurile de optimizare i strategiile de acces la date alese automat. Pentru datele cu distribuie neuniform, el poate menine statistici pentru pn la 250 valori distincte ale unei chei. Interogrile distribuite sunt optimizate i prin considerarea costurilor de transmisie i a performanelor procesor ale serverelor implicate. Joinul poate fi implementat i bucl n bucl i sort/reuniune; este implementat i aplatizarea interogrilor.
58
8. CATALOAGE DE META-DATE
Un catalog este un fiier sistem memornd meta-date (i.e. date despre datele memorate de bd). De exemplu, un catalog este necesar oricrui SGBD relaional pentru a memora date despre tabelele oricrei bd gestionate: nume, sinonime, data ultimei modificri, dimensiuni etc. Alte cataloage sunt necesare pentru memorarea tuturor utilizatorilor autorizai ai fiecrei bd, precum i a privilegiilor ce le sunt garantate. Cataloagele sunt automat create i gestionate de SGBD, care are permanent nevoie s le consulte (de exemplu, pentru a determina dac o tabel exist sau nu, dac un utilizator este ndreptit la un anumit tip de acces ntr-o tabel etc.). Optimizatoarele bazate pe costuri (vezi capitolul 15) au nevoie de memorarea i inerea permanent la zi a unor meta-date statistice suplimentare.
Structura i coninutul cataloagelor

Structura cataloagelor difer foarte mult de la un SGBD la altul, n funcie de serviciile oferite de acestea (i, desigur, de opiunile proiectanilor i programatorilor care le-au realizat). n mod normal, i ele ar trebui s constituie o bd sistem, structurat conform unui model oarecare al datelor, ca n SGBD relaionale, unde cataloagele sunt memorate n zeci de tabele interconectate prin chei strine. Coninutul cataloagelor este automat actualizat de sistem, obligatoriu i transparent utilizatorilor, pentru fiecare actualizare a structurii unei bd (crearea sau tergerea unei tabele, coloane, chei, fiier index, modificarea codomeniului unei coloane, structurii unei chei etc.), a privilegiilor garantate utilizatorilor autorizai etc. Unele meta-date ar putea ns fi actualizate manual, la comanda administratorului bd, pentru a mri performanele sistemului (de exemplu: recalcularea datelor statistice necesare optimizatoarelor bazate pe costuri). Pe lng meta-datele deja pomenite, cataloagele mai conin informaii despre constrngerile de integritate, punctele de vedere utilizator asupra datelor (views), trgaciuri, tranzaciile memorate, paginile disc de memorare a datelor, salvri, jurnale de actualizri, de verificare, de protecie la virui etc. Unele SGBD distribuite menin n plus meta-date despre serverele SGBD cu care sunt interconectate (nume, locaie etc.).
Accesul utilizatorilor la cataloage

Majoritatea SGBD moderne permit administratorilor bd accesul n citire la orice catalog i chiar n scriere la o parte din acestea. Cum administratorul poate garanta orice privilegii celorlali utilizatori, oricine poate, la limit, avea acces la meta-date. Accesul n scriere este chiar obligatoriu pentru anumite meta-date, cum ar fi cele referitoare la autorizarea utilizatorilor i privilegiile ce le sunt acordate. Accesul n citire este adesea cel mai important: doar cu ajutorul meta-datelor se poate realiza o bun administrare a bd, mbuntirea performanelor sistemului n condiii locale i/sau particulare de exploatare, ca i o corect i optim proiectare i programare a bd (de exemplu, cea mai bun documentaie despre structura unei tabele sau despre detaliile unui trgaci rmne cea memorat n cataloagele SGBD!). Desigur ns c, n esen, coninutul cataloagelor este destinat a fi actualizat n special automat, transparent utilizatorilor. Chiar atunci cnd se permite scrierea de ctre utilizatori a metadatelor, SGBD prefer, ori de cte ori acest lucru este posibil, s interfaeze cataloagele cu tranzacii care s mpiedice de fapt accesul direct n fiierele catalog, chiar dac scrierea meta-datelor necesit privilegii speciale, tocmai datorit riscului foarte mare de a grei (e omenesc!) cu consecine prea adesea incalculabile pentru integritatea bd gestionate.
59
Gestiunea cataloagelor n bd distribuite

Un optimizator global ar avea nevoie de acces la toate cataloagele serverelor distribuite. O prim soluie la acest problem a fost folosirea prefixrii uzuale a numelor tabelelor cu locaia serverului. Problema care rmne ns este c toate serverele trebuie s fie omogene din acest punct de vedere, adic s aib exact aceeai structur (inclusiv aceleai nume de tabele) pentru cataloagele gestionate. Cum azi un asemenea lucru este practic posibil de realizat doar foarte rar, datorit heterogenitii serverelor, urmtoarea soluie avut n vedere n bd distribuite a fost cea a meninerii unui catalog universal, care conine meta-date i date statistice despre toate tabelele din gestiunea fiecrui server. Acesta permite oricrui SGBD distribuit s optimizeze accesul la date n orice moment, indiferent de distribuia lor. Desigur c memorarea acestui catalog universal doar pe un singur server ar fi mult prea riscant (n cazul cderilor de sistem sau izolrii temporare a serverului implicat) i neperformant (cci ar ncetini mult optimizatoarele celorlalte servere); de aceea, n implementrile evoluate, el este replicat pe toate serverele. n sfrit, un al treilea tip de soluie exploateaz avantajele transparenei localizrii: catalogul de la locul naterii fiecrui obiect menine date despre el pn la tergerea obiectului; cu condiia omogenitii cataloagelor sistemului, se pot obine astfel meta-date i statistici despre orice tabel cu cel mult dou accese la distan. Dezavantajul soluiei (oricum inaplicabil pentru cataloage heterogene) este ns acela c, n cazul inaccesibilitii unui server implicat, datele de catalog despre obiectele nscute la acea locaie nu sunt temporar accesibile.

Din cauza diversitii extreme care domnete n aceast privin (practic, fiecare SGBD are structura sa proprie de cataloage precum i politica sa de acces la ele) sunt greu de gsit prea multe texte teoretice dedicate acestui subiect; recomandm totui [73]. Desigur c documentaia fiecrui SGBD ofer detalii despre soluia particular aleas n cazul respectiv. Am selectat, ca atare, pentru subseciunile ce urmeaz doar cteva particulariti ce ni s-au prut interesante ale celor mai importante SGBD de pe pia. Ar merita amintit n acest context i faptul c raportul tehnic [253] conine proiectul cataloagelor SGBD prototip MatBase; acestea au fost gndite ca o bd a crei schem este proiectat cu ajutorul MMED (vezi prima parte a lucrrii) ce fundamenteaz MatBase.
Cataloagele n DB2
DB2 al IBM, de exemplu, memoreaz i statistici pentru optimizarea accesului n catalogul su unic (din mai multe tabele, dar pentru toate bd gestionate). Datele statistice meninute pentru fiecare tabel n parte includ: numrul de linii; numrul de pagini (fizice disc alocate tabelei); fiierele index definite pe coloanele tabelei; pentru fiecare index (arbori B+): adncimea arborelui; numrul de pagini frunz; numrul de valori distincte ale cheii indexate;
60
valorile maxime i minime ale cheii, dar i prima dintre valorile imediat sub, respectiv deasupra acestora (pentru a evita derapaje statistice atunci cnd se calculeaz numrul probabil de linii al tabelelor rspuns); distribuia valorilor pentru primele 10 valori aprnd cel mai des n cheie.
Cataloagele n NonStop SQL

NonStop SQL al Tandem menine i el cte un catalog (implementat prin mai multe tabele) pentru fiecare bd, nu neaprat pe acelai disc cu bd respectiv. Fiind un SGBD ce suport mediile distribuite i procesarea paralel, fiecare nod menine, n plus, un catalog rdcin al nodului, ce conine meta-date despre toate cataloagele gestionate de nodul respectiv. O interesant particularitate este lipsa sintactic din limbaj a unei instruciuni de creare a unei noi bd; n schimb, exist instruciunea de creare a unui catalog (care are drept efect secundar crearea unei bd corespunztoare catalogului!). Clauza CATALOG a instruciunii de creare a unei tabele este singurul mod prin care se poate preciza apartenena tabelei la o bd. Meta-datele despre obiectele (tabele sau fiiere index) distribuite sunt replicate n catalogul corespunztor din fiecare nod implicat. Pentru meninerea integritii datelor, s-a optat pentru o uoar violare a autonomiei locale: crearea sau tergerea unui obiect distribuit nu este admis dect dac toate nodurile implicate sunt disponibile n acel moment (i.e. n stare de funcionare i accesibile n reea). Datele statistice sunt actualizate doar la cererea administratorilor de date; acetia pot ns cere NonStopSQL s fac automat actualizarea la intervale regulate de timp. Statisticile pot fi exacte (i.e. lund n calcul toate datele implicate) sau aproximative (pentru care administratorul trebuie s precizeze numrul de blocuri de 4K ce vor fi luate n considerare).
Cataloagele n Oracle
Oracle refer cataloagele drept dicionare de date. Fiecare bd are propriul catalog, memorat ntr-un segment de ncrcare (bootstrap segment) ntotdeauna alocat n spaiul de tabel SYSTEM. Printre datele statistice suplimentare gestionate de Oracle se numr cele ce pot fi asociate fiecrei instruciuni SQL; acestea includ timp total i timp procesor de execuie, numr de linii procesate, numrul de accese logice i fizice la disc etc.
Cataloagele n SQL Server

SQL Server al Sybase are i el cataloage separate pentru fiecare bd, memorate, la fel ca n Oracle, ntr-un segment al spaiului de tabel SYSTEM al bd respective. Bd MASTER a sistemului menine, n plus, un catalog global, cu meta-date sistem, att despre platforma de calcul (parametri de configurare, discuri, servere), ct i despre bd gestionate (obiecte, dependene, privilegii etc.).
Cataloagele n CA-OpenIngres
CA-OpenIngres al CA construiete i menine cte un catalog (tot din mai multe tabele) pentru fiecare bd n parte. n plus, fiind un SGBD distribuit, el menine i un catalog global, inclusiv cu date statistice, care i permite optimizarea interogrilor distribuite.
61
9. INTERFEE DE PROGRAMAREA APLICAIILOR (API)

Orice SGBD ofer cel puin o interfa de programare a aplicaiilor (API), care s permit programatorilor s fac uz de serviciile SGBD dintr-un limbaj de programare. Astfel, atunci cnd un program scris ntr-un limbaj care beneficiaz de un API are nevoie de acces la o bd gestionat de un SGBD corespunztor, el nu are nevoie nici s cunoasc detaliile de memorare a datelor (care poate sunt memorate la distan, pe o platform de un cu totul alt tip) i nici s complice codul program cu foarte multe instruciuni suplimentare (stabilirea i controlul derulrii comunicaiilor la distan, navigarea ntre tabele sau n tabele cu ajutorul indexurilor, sortare etc.). i din acest punct de vedere, ns, situaia este complet diferit pentru SGBD orientate obiect: aa cum am vzut (n capitolul 9) una din principalele caracteristici ale acestora este asigurarea doar a unei extensii pentru manipularea obiectelor persistente de ctre un limbaj de programare orientat obiect (sau cel mult dou asemenea limbaje). Ca atare, dei putem privi i aceste extensii ca pe o API pentru limbajul respectiv, nu aceasta este uzana ntr-un domeniu n care se urmrete mai degrab integrarea unui limbaj de programare existent n SGBD (acesta ndeplinind, ca atare, i rolul de limbaj de definire i manipulare a datelor). Prin urmare, restul consideraiilor dezvoltate n acest capitol exclud SGBDO. Dei sunt uzuale i alte tipuri de limbaje de definire i manipulare a datelor (precum QUEL, bazat pe calculul predicativ al tuplilor, sau QBE, bazat pe calculul predicativ al coloanelor) majoritatea SGBD ofer diverse variante de SQL (bazat pe algebra relaional). Cum i majoritatea implementrilor de QBE traduc intern n SQL, iar QUEL este foarte puin rspndit, ne vom focaliza atenia n acest capitol doar asupra SQL.
Interfee ncorporate i interfee apel

Dou tipuri de abordri ale API sunt comune n strategiile de a oferi acces la SQL din alte limbaje de programare: interfee cu SQL ncorporat (embedded SQL) i interfee de tip apeluri SQL (call-level SQL). Primul dintre ele este cel mai vechi, cel mai rspndit nc i de nivel mai nalt dect al doilea. Acest prim tip de abordare permite includerea instruciunilor SQL n programe scrise ntrun alt limbaj (gazd), precedate i terminate ns de diverse mecanisme sintactice de distingere a lor de restul liniilor de program scrise n limbajul gazd. Dezavantajul acestei abordri este acela c sunt necesare precompilatoare care s traduc SQL pentru compilatorul de limbaj gazd n apeluri la serviciile SGBD corespunztoare. Deoarece acest pas suplimentar cost timp, SGBD mai noi ofer i cel de-al doilea tip de API, care elimin necesitatea preprocesrii: biblioteci de programare cu primitive ce admit drept parametrii instruciuni SQL. i aceast abordare, de tip apeluri SQL, are ns un mare dezavantaj, cel puin deocamdat, deoarece, n absena oricrei standardizri n domeniu, programele ce fac apel la asemenea biblioteci (care difer foarte mult ntre ele) nu sunt portabile.
SQL static i dinamic. Proceduri memorate

Optimizarea accesului la date este, dup cum am mai vzut (capitolul 15), crucial n obinerea unor performane bune ale SGBD, dar costisitoare n acelai timp. Pentru unele aplicaii, a cror natur este ad-hoc dpdv al interogrilor (de exemplu, un program ce permite utilizatorilor n mod interactiv formularea oricrei ntrebri), nu se poate face nimic pentru mbuntirea performanelor n acest sens. De aceea, majoritatea SGBD ofer doar SQL dinamic, adic optimizare a accesului la date la fiecare execuie a oricrei tranzacii SQL.
62
Exist ns i multe aplicaii de bd mereu previzibile i care, n plus, trebuie reexecutate frecvent (exemplu: calculul i listarea vnzrilor, salariilor, stocurilor, comenzilor etc.). Pentru a le mri viteza de execuie, SGBD evoluate ofer i SQL static, care memoreaz pe disc diversele variante posibile de acces la ele i modul de calcul al strategiei optime pentru asemenea tranzacii. Singurul dezavantaj major (dac spaiul disc suplimentar nu e o problem) al acestei faciliti este, evident, acela c tranzaciile trebuie recompilate manual ori de cte ori apar sau dispar noi indexuri. O variant intermediar ntre aceste dou abordri, care elimin i dezavantajul amintit imediat mai sus, o constituie facilitatea procedurilor memorate pe care o pun la dispoziie cteva SGBD. Acestea nu memoreaz pe disc variantele de acces i algoritmul de alegere a celei mai bune strategii pentru o tranzacie (precum SQL static), dar, pentru procedurile memorate pe disc (n fond nite subtranzacii), pstreaz n RAM aceste informaii din momentul ncrcrii acestora n memorie i pn la momentul scoaterii lor din RAM. n tot acest rstimp, orice alt tranzacie care face apel la asemenea proceduri (cu excepia celei dinti, evident), beneficiaz de precompilarea optimizrii accesului la datele implicate.

Nu am gsit n literatura de specialitate teoretic dect cel mult cte o subseciune dedicat API n general. Desigur c documentaiile referitoare la diverse SGBD prezint fiecare, explicit sau nu, API oferite de SGBD respectiv. Merit poate menionat aici i efortul firmei Borland, care nc de la versiunea Paradox 3.5, la sfritul anilor 80, a pus la dispoziie att biblioteci de apeluri (chiar dac primitive, nu de SQL) pentru C i Pascal (Paradox Engine), ct i SQL Link, o interfa de acces la servere SQL. n ziua de azi, pe piaa SGBD doar pentru PC-uri, este frecvent posibilitatea cuplrii cel puin la Microsoft SQL Server pentru Windows NT (server dezvoltat de Microsoft pornind de la licena SQL Server versiunea 4.2, achiziionat de la Sybase). n paralel, se ofer de ctre orice produs care se respect (exemplu: Access95, 97, Visual FoxPro, Paradox for Windows etc.) mcar acces la bibliotecile Windows API.
API n DB2
DB2 al IBM ofer API ncorporat, cu SQL i static i dinamic, pentru foarte multe limbaje, incluznd COBOL, C, FORTRAN, PL/1, Assembler, Ada, APL2, Prolog i IBM Basic. Versiunea 4 suport i proceduri memorate.
API n NonStop SQL

NonStop SQL al Tandem ofer API ncorporat pentru C, Pascal i COBOL; un produs opional al firmei, numit NonStop ODBC Server, furnizeaz o interfa de tip apeluri la NonStop SQL care suport att biblioteca Open Client (DB-Library) a Sybase, ct i biblioteca Microsoft ODBC. SQL-ul su static, include numeroase faciliti de compilare, dintre care cea mai spectaculoas este evaluarea numelui obiectelor la momentul execuiei: se pot scrie astfel tranzacii templet ce pot fi apoi executate asupra mai multor tabele (eliminnd deci munca de programare repetitiv) i se pot uor verifica tranzaciile pe tabele de test.
API n Oracle
Oracle ofer doar SQL ncorporat dinamic i Oracle Call Interface (OCI), o API de tip apeluri, pentru mai multe limbaje, incluznd C, COBOL, FORTRAN, Ada, PL/1 i Pascal.
63
API n SQL Server

SQL Server al Sybase ofer API ncorporat i biblioteca de apeluri Open Client (DB-Library) pentru mai puine limbaje, care includ totui Ada, C, COBOL i FORTRAN. n plus ns, el ofer i proceduri memorate.
API n CA-OpenIngres
CA-OpenIngres, dei construit n esen pe baza QUEL, suport i SQL, care poate fi dinamic ncorporat n destul de multe limbaje, incluznd Ada, COBOL, C, FORTRAN, Pascal, PL/1 i Basic. De asemenea, este suportat i biblioteca Microsoft ODBC.
64

Caracteristici Esentiale Ale SGBD Si SGBC

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Caracteristici Esentiale Ale SGBD Si SGBC

Încărcat de

Drepturi de autor:

Formate disponibile

Facultatea de Matematic i Informatic, Universitatea Ovidius Curs SGBD I III, 2007 - 2008

Caracteristici eseniale ale SGBD i SGBC

TENDINE ACTUALE N INDUSTRIA SGBD

Arhitecturi Client / Server

Sisteme deschise i bd distribuite

Baze de date distribuite

Programe interfa de acces

Medii de procesare paralel

Arhitecturi cu discuri partajate

Arhitecturi cu memorie partajat

Patru tipuri de cuplare a procesoarelor: strns, lejer, simetric, i asimetric

Procesarea paralel a tranzaciilor i interogrilor

Procesarea paralel a indexurilor i a programelor utilitare

Sisteme orientate obiect

Gestiunea obiectelor persistente n arhitecturi client / server

Descriptor_O ID_O ... Obiectul O

Figura 9.1 Un exemplu de memorare a obiectelor persistente nlnuite

Un exemplu de bd orientat obiect

Figura 9.3 Program ObjectStore pentru crearea i afiarea de obiecte persistente

Cinci exemple de SGBD celebre

DATABASE2 (DB2) MVS / ESA versiunile 3 i 4 ale IBM

Oracle 7.1 al Oracle

SQL Server 10.0 al Sybase

NonStop SQL / MP al Tandem

CA-OpenIngres al Computer Associates

Comentarii i referine bibliografice

Cele dou tipuri fundamentale de lacte: partajabil i exclusiv

Se termin tranzacia 1. ncepe tranzacia 4.

Se termin tranzacia 2. Se termin tranzacia 4.

Tranzacia 3 modific A. Se termin tranzacia 3.

Figura 10.1 Un posibil scenariu de utilizare a lactelor partajabile i exclusive

Niveluri de izolare a lactelor

Izolarea citirilor repetabile

Blocarea n dou faze

Blocaje fatale globale n bd distribuite

Comentarii i referine bibliografice

Controlul concurenei n DB2

Controlul concurenei n NonStop SQL

Controlul concurenei n Oracle

Controlul concurenei n SQL Server al Sybase

Controlul concurenei n CA-OpenIngres

3. SALVRI I RECUPERAREA DIN EROARE

Refacerea i desfacerea automat a actualizrilor

Recuperarea din dezastre

Comentarii i referine bibliografice

Salvri i recuperri n DB2

Salvri i recuperri n NonStop SQL

Salvri i recuperri n Oracle

Salvri i recuperri n SQL Server al Sybase

Salvri i recuperri n CA-OpenIngres

Codificarea datelor i verificarea accesului

Ierarhia nivelurilor de acces utilizator n bd distribuite

Comentarii i referine bibliografice

Securitatea datelor n DB2

Securitatea datelor n NonStop SQL

Securitatea datelor n Oracle

Securitatea datelor n SQL Server

Securitatea datelor n CA-OpenIngres

5. IMPUNEREA CONSTRNGERILOR DE INTEGRITATE

Integritatea domeniilor de valori

Procesarea n dou faze a terminrii execuiei tranzaciilor

Comentarii i referine bibliografice

Impunerea constrngerilor n DB2