Caracteristici Esențiale ale SGBD și SGBC

1. TENDINŢE 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 către mai mulţi utilizatori simultan. Pentru aceasta, ele asigură mecanisme cel puţin pentru:

- memorarea (structurată a) datelor

- accesul la date

- protecţia datelor (la tentative de acces neautorizat)

- păstrarea integrităţii datelor

- recuperarea din erori.

SGBD sunt azi oferite pe o mare varietate de platforme de calcul, pornind de la calculatoarele personale (PC) şi până la sistemele de procesare paralelă masivă a datelor, sub medii extrem de diverse, incluzând DOS, Windows, Novell Netware, Macintosh, Unix, OS/2, VMS, OS/400, MVS. Majoritatea liderilor mondiali din industria de programare oferă cel puţin un SGBD, dacă nu mai multe; dintre aceştia, este suficient să amintim IBM, Computer Associates, Sybase Inc., Oracle, Microsoft, Borland.

Marile corporaţii ale lumii, ca şi foarte multe dintre cele medii sau mici, depind de peste două decenii de SGBD, cărora le sunt încredinţate funcţiuni critice în afaceri, precum urmărirea vânzărilor, cheltuielilor, stocurilor, încasărilor sau plata salariilor. Dar şi foarte mulţi oameni fac apel la SGBD pentru uzul personal, fie că este vorba de monitorizarea investiţiilor familiale, fie de bd gestionând biblioteca proprie de cărţi, reviste, fotografii, diapozitive, casete audio, video, discuri şi CD-ROM-uri audio, video sau de date etc. Industria de SGBD genera în 1994 venituri depăşind 5 miliarde de dolari anual în lume, cifră mereu în creştere!

Tranzacţii

Orice SGBD trebuie să asigure, în primul rând, 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 interogări şi/sau actualizări). Pentru a asigura partajarea datelor în medii multi-utilizator, SGBD trebuie să ofere mecanisme de grupare a tuturor operaţiilor care concură la îndeplinirea unei “sarcini logice unitare” într-o singură tranzacţie, astfel încât SGBD să poată garanta ori că execuţia unei tranzacţii a avut loc complet, fără a fi afectată de alte tranzacţii, ori că tranzacţia nu a fost deloc executată (bd nefiind deci afectată de tranzacţie).

Tranzacţiile sunt, prin urmare, singurele “instrucţiuni logice atomice” oferite de un SGBD; ca atare, ele ori se execută integral, ori deloc, în nici un caz parţial, dpdv al oricărei alte tranzacţii. Altfel spus, orice tranzacţie parţial executată (de exemplu, din cauza unei căderi de tensiune) trebuie abortată, iar toate efectele ei trebuie ignorate (“rolled back”). În caz contrar, în mod evident, ar putea rezulta stări inconsistente ale bd.

Exemplul 9.1

De exemplu, dacă o tranzacţie măreşte salariile angajaţilor unui departament cu 10%, iar o alta mută angajaţi din acel departament în alte departamente şi cele două tranzacţii nu s-ar executa atomic, ci execuţiile lor s-ar întrepătrunde, unii dintre angajaţii mutaţi ar putea avea salariile mărite înainte de mutare iar alţii nu! Pentru păstrarea consistenţei datelor, ori tranzacţia de mărire salarii a fost lansată prima iar cea de mutare angajaţi trebuie lansată după terminarea tuturor măririlor de salarii (cu efectul că toţi angajaţii mutaţi vor avea salariile mărite), ori, invers, tranzacţia de mutare angajaţi a fost lansată prima iar cea de mărire salarii trebuie lansată abia după încheierea tuturor mutărilor (cu efectul că nici unul dintre angajaţii mutaţi nu va avea salariul mărit).

Literatura de specialitate se referă, în acest sens, la cele patru proprietăţi ACIDe ale tranzacţiilor:

- Atomicitatea execuţiei (ori completă, ori deloc)

- Consistenţa (sau Corectitudinea) transformărilor induse conţinutului bd de către tranzacţie

- Izolarea execuţiei tranzacţiei, care nu trebuie să fie influenţată de modificările aduse bd de către orice altă tranzacţie concurentă

- Durabilitatea tranzacţiei, ale cărei modificări produse bd la terminarea execuţiei sale trebuie să fie permanente, supravieţuind oricăror căderi ale sistemului sau defecţiuni ale suporţilor de stocare a datelor.

Conceptul de tranzacţie şi de terminare a ei (“commit”, în engleză) joacă însă un rol la fel de important în controlul concurenţei, impunerea constrângerilor de integritate, salvarea datelor şi recuperarea din erori, aşa cum vom vedea în continuare.

Capitolele următoare discută despre problemele de implementare ale principalelor componente şi funcţii ale oricărui SGBD, indiferent de arhitectură sau de modelul suport al datelor, şi anume despre: controlul accesului concurent; securitate; integritate; indexuri; optimizare; cataloage; interfeţe de programarea aplicaţiilor (API); unelte utilitare.

De remarcat însă că, pe lângă 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 atât la noile cerinţe ale utilizatorilor, cât şi la avansurile tehnologice hard şi soft. Considerăm că cele mai semnificative tendinţe ce se manifestă azi în industria SGBD sunt următoarele:

- arhitecturile client / server

- mediile de calcul deschise, distribuite

- sistemele multiprocesor, cu procesare paralelă

- conceptualizarea orientată obiect

- integrarea în Internet.

Deşi toate acestea depăşesc cadrul fixat pentru prezenta lucrare, considerăm totuşi utilă măcar o trecere sumară în revistă a lor în continuarea acestui capitol introductiv al ultimei părţi.

Arhitecturi Client / Server

Până 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, corespunzând celor două tipuri de platforme de calcul existente până 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 priorităţi. Acest tip de SGBD primitiv mai este încă folosit şi azi în lume, nu doar din considerente de amortizare a investiţiilor uriaşe făcute în echipamente şi programe, sau din conservatorism, ci şi datorită faptului că prelucrarea batch este în continuare cea mai potrivită pentru aplicaţiile de mai lungă durată (tip liste de salarii, de stocuri etc.), intensive, ce nu necesită interacţiune în timp real şi care deci se pretează la execuţia în afara orelor de program ale majorităţii utilizatorilor (exemplu: noaptea), când resursele sistemului de calcul ar fi, altfel, aproape nefolosite.