Automatizarea prelucrarii bazelor de date prin intermediul unei aplicatii orientate Internet si securizarea informatiei

1. Recapitulare

De mult timp se cocheta cu idea crearii unei baze de date universale, adica o baza de date ce sa contina informatii din cit mai multe domenii si care sa poata fi accesata de un numar mare de persoane. Pina cu putin timp in urma acest ideal se mentinea in domeniul viselor. Odata cu aparitia a ceea ce numim astazi World Wide Web un astfel de vis a devenit realitate.

Inca din cele mai vechi timpuri oamenii au avut nevoie de informatii. O data cu informatia a aparut si necesitatea schimbului de informatii. Pentru aceasta era nevoie de un suport material care sa stocheze informatia si sa o transmita mai departe. S-a inceput cu cioplirea informatiilor in piatra si s-a continuat cu alte si alte solutii pana in zilele noastre, cand asistam la decaderea unui suport (hartia) si ridicarea altuia (suportul electro-magnetic).

 Odata cu evolutia omenirii, informatia a crescut ca dimensiune. Se pune deci problema, nu numai a stocarii datelor, ci si a stocarii unei mari cantitati de date. De asemenea, o alta problema este regasirea informatiei si cu ea rapiditatea obtinerii rezultatuluiI inca din zorii civilizatiei IT s-a observat ca - pe langa calculele cu care se chinuia tehnologia informatica embrionara - computerele s-ar preta binisor si la inmagazinarea si exploatarea volumelor mari de informatii. Astfel, incepand cu anul 1948 s-au facut mai multe studii, cercetari si experimente privind stocarea datelor, iar de-a lungul timpului s-au manifestat mai multe modele, arhitecturi si tehnologii privind bazele de date. Acceptand un punct de vedere oarecum teoretic, fara insa a intra in detalii aride, vom trece in revista principalele modele de conceptie si organizare a bazelor de date, dupa care ne vom ocupa de arhitecturile de implementare a sistemelor de gestiune a bazelor de date (SGBD).

2. Modele de baze de date

2.1. Modelul retea

Atomii semantici inruditi se leaga explicit prin identificatori (spre deosebire - de exemplu - de celulele unui rand de tabel care se refera implicit la o anume entitate informationala). In retea asocierile sunt realizate printr-o structura de legare (un tip de set are un tip de inregistrare 'owner" si mai multe tipuri de inregistrare 'member").

Orice relatie intre date poate fi doar binara (1-la-1 sau 1-la-n), iar reprezentarea bazei de date se poate asimila unui graf directionat.

- Entitatea informationala are un fisier cu campuri atribute si campuri de legatura.

- Operatiile permise sunt cautarea de entitati pe baza proprietatilor specificate (interogare) si cautarea informatiilor folosind legaturile dintre entitati (navigare).

Dezavantajul modelului consta in complexitatea structurilor de date si a limbajului de manipulare.

2.2. Modelul ierarhic

Asocierea intre atomii informationali este realizata printr-o structura ierarhica (arbore).
- Poate fi considerat un caz particular al modelului retea, in care diagrama asociata este o padure (baza de date poate fi asimilata unei multimi de arbori).

- Exista un tip de inregistrare definit ca radacina si - la orice alt nivel - mai multe tipuri de inregistrare subordonate (legatura intre doua niveluri succesive fiind de tip 1-la-n in jos si 1-la-1 in sus).

- Operatiile posibile se reduc in esenta la parcurgea arborilor, datele fiind inmagazinate pe mediul extern in succesiunea de parcurgere in preordine a arborilor (se favorizeaza cautarea descendentilor).

- Este un model asimetric: o inregistrare are semnificatie numai in contextul ierarhiei.
La noi in tara au existat implementari ale bazei de date ierarhice Socrate pe calculatoarele Felix si pe minisistemele Coral si Independent.

2.3. Modelul relational

Fiind actualmente cel mai raspandit, acesta inmagazineaza datele in tabele care se pot lega logic dupa valorile anumitor coloane

- sistemele de gestiune a bazelor de date relationale (RDMBS) au standardizat SQL-ul ca limbaj de cereri specific.

- Relatia dintre campuri realizeaza asocierea explicita, asociere care poate fi de durata (prin definirea relatiei) sau temporara (prin operatorul de jonctiune join).

- Este un model simetric: uniformitatea reprezentarilor datelor determina uniformitate in multimea operatorilor.
- Avand la baza teoria matematica a relatiilor (algebra relationala = colectie de operatori ce au ca operanzi relatii), modelul a facilitat tratarea algoritmica a problemei proiectarii bazelor de date, numita si problema normalizarii (normalizarea porneste de la o multime de atribute/campuri si o multime de dependente functionale intre acestea pentru a obtine asistat de calculator schema conceptuala a bazei de date).
Avantaje:

- usor de inteles (numar redus de concepte) si de controlat (sistemele ajung la o interfata prietenoasa);

- scalabilitatea sa este generoasa, fiind si singurul model care cunoaste implementari de baze de date distribuite;
- legi de integritate (reguli pentru protejarea datelor si structurilor) usor de inteles si de dezvoltat;

- spatiu de stocare si redundanta relativ reduse;

- independenta structurilor logice ale bazei de date de modul de stocare fizica a datelor (aplicatiile sunt independente de modul de inregistrare a datelor) - exceptiile au aparut doar motivate de cresteri ale performantelor;
- limbaje simple (bazate pe algebra relationala sau pe calcul relational): SQL, QBE.
Dezavantaj: incercarile modelului de a inmagazina si informatii multimedia (uzual realizate prin campuri BLOB si extensii particulare de SQL) nu au ajuns la un numitor comun standardizat.

2.4. Modelul obiectual

Bazele de date obiectuale sunt destinate sa suporte modele de obiecte complexe (organizare de tip heap cu referinte intre componente), deci modelul este oarecum asemanator retelei, iar prin faptul ca - pentru accesare directa - stocheaza o harta a ierarhiilor si relatiilor claselor de obiecte, are ascendent si in modelul ierarhic.

- Incapsularea specifica OO are ca efect independenta aplicatiilor atat fata de reprezentarea interna a datelor, cat si fata de semantica acestora (adica de operatiile care se pot executa asupra datelor).

- Modelul obiectual se preteaza pentru inmagazinarea informatiilor complexe: atribute descriptive asociate datelor multimedia, documentelor, desenelor, arhivelor etc.

- Solutiile unor probleme precum optimizarea bazei de date (paralelism, consistenta) si asigurarea mostenirii sunt inca perfectibile.

2.5. Modelele hibride

Sunt mixturi ale modelelor prezentate anterior, din care cel mai semnificativ pentru noi probabil ca este modelul relational-obiectual, obtinut prin extensii ale modelului de organizare tabelar si ale SQL-ului si izvorat din tendinta spre universalitate a bazei de date (entitati complexe si de naturi diferite, evoluand in conditii eterogene).

3. Nuante de istorie

Pana spre anii '80 contau doar mainframe-urile, minisistemele si supercomputerele, iar bazele de date aveau ambitia de a fi foarte mari (raspunzand unor cerinte dure impuse de beneficiari pretentiosi, pentru ca doar acestia aveau puterea financiara de a achizitiona tehnica motivat de probleme complexe si critice - este usor sa ne imaginam baze de date referindu-se la sute de mii sau milioane de entitati). Tendintele fortau mereu limite, iar de aici derivau problematici provocatoare privind performanta, accesibilitatea si mentenabilitatea. Prin anii '70, modelul relational s-a cristalizat ca solutie viabila, iar lupta concurentiala dintre marii jucatori de pe piata bazelor de date se va da pana in vremea noastra pe arena RDBMS si SQL.

Mult timp modelul de organizare centralizat (datele sunt depozitate pe un sistem central de unde utilizatorii le acceseaza) a raspuns cel mai bine cerintelor de exploatare a bazelor de date. si astazi pentru aproape orice mediu departamental (sau grup de lucru) organizarea centralizata a informatiilor - si nu ma refer neaparat la baze de date (de exemplu, sistemele de gestiune si control al circulatiei documentelor - unde documentele pot fi orice: documentatii, proiecte, desene CAD, arhive raster etc.) - constituie o prima optiune.

Odata cu raspandirea si dezvoltarea calculatoarelor s-au deschis si orizonturile, iar ca o prima tendinta s-a dovedit necesitatea descentralizarii si interoperarii. Proliferarea diverselor platforme (hardware si/sau sisteme de operare) au fortat definirea de standarde de schimb de date si de comunicatii, precum si dezvoltarea retelelor eterogene.

Iar pentru ca lucrurile se intamplau odata cu fluxul calculatoarelor personale, inevitabil programatorii s-au gandit la ceva intre SGBD si spreadsheet, iar de aici la aparitia unor baze de date desktop de genul lui dBASE n-a fost decat pasul materializarii.

Evolutia ramurii desktop a bazelor de date s-a facut in paralel cu mainstream-ul, dar influentandu-se reciproc. Cele mai evidente trend-uri se pot descrie pe scurt astfel: bazele de date mici doreau sa-si dezvolte functionalitati de sistem relational (sa poata defini relatii si sa incorporeze SQL) si sa-si extinda limitele, iar cele mari si-au aplecat atentia asupra accesibilitatii, materializata prin interfete utilizator facile chiar si pentru task-urile administrative (un GUI de calitate ajunge deseori un argument de piata.

4. Nuante comparative intre modelele arhitecturale Dupa ce ne-am facut o idee despre conceptia bazelor de date, ne vom apleca atentia asupra arhitecturilor de implementare care s-au manifestat in domeniu.

Modelul mainframe

Modelul centralizat initial presupunea ca baza de date este organizata si stocata integral pe un sistem performant (denumit mainframe, sistem sau minisistem in functie de criterii hardware) de unde poate fi accesata de mai multe console utilizator (terminale de acces cu putere de calcul redusa conectate la calculatorul central) prin intermediul unor aplicatii de exploatare rezidente tot pe mainframe.
Modelul s-a dovedit performant si sigur atat in implementare, cat si in utilizare, dar au existat si cateva puncte sensibile. Problema delicata la mainframe-uri nu este numarul de utilizatori suportati (cum am fi tentati sa credem), ci faptul ca aplicatiile au o infrastructura rigida, a caror extindere determina implicatii dure de organizare si administrare, pe langa cresterile nedorite ale traficului de date prin retea.
Extinctia dinozaurilor n-a fost deloc completa: multi inca mai fac fata aplicatiilor critice (care nici nu pot fi intrerupte fara pierderi), iar interoperabilitatea cu arhitecturile moderne nu-i incomodeaza deloc, ba parca-si retraiesc o a doua tinerete

Modelul integrat
Un mediu software independent, instalat pe un singur calculator, include atat baza de date propriu-zisa, cat si interfata de acces la date (un prim exemplu de astfel de mediu integrat este dBASE), astfel ca un singur utilizator va fi beneficiarul. Accesarea datelor se face fie printr-un limbaj de generatia IV (4GL) sau printr-un macrolimbaj, fie prin elemente de interfata (comenzi la prompter, dialoguri QBE, comenzi menu). Datele fiind organizate tabelar, exista posibilitatea de a proiecta aplicatii relationale.
Uzual, astfel de medii ingaduie dezvoltarea de aplicatii nerelationale, ceea ce se mai numeste si organizare plata sau bidimensionala, spre deosebire de organizarea relationala, care este multidimensionala (atentie, exista pericolul confuziei cu denumirea de "baza de date multidimensionala" care corespunde uzual domeniului data warehouse sau aplicatiilor DSS - decision support system - si OLAP - On-Line Analytical Processing, deservind analize economice necesare deciziilor manageriale, adica extragerii ad-hoc de informatii sintetice, unde dimensionalitatea are un caracter mai abstract si mai dinamic si nu necorespunde modului de stocare). Intr-un sistem nerelational (revenind la mediul independent), datele care altfel s-ar preta organizarii in nomenclatoare (tabele cu inregistrari unice, legate de celelalte tabele prin relatii 1-la-n) cunosc un grad excesiv de redundanta, iar actualizarea lor presupune un efort considerabil. (Redundanta datelor, adica faptul ca baza de date contine aceleasi date stocate de mai multe ori, ridica atat problema spatiului ocupat, cat mai ales dificultatea asigurarii consistentei si actualitatii.).

Modelul file-server

Este prima manifestare a organizari multiuser pentru universul PC, constand dintr-o retea centrata logic pe un calculator puternic, numit file-server, de unde se alimenteaza cu date/aplicatii celelalte PC-uri. File-server-ul partajeaza datele pentru mai multi utilizatori, dar acestia il vad doar ca pe un disc din retea (file-server-ul se comporta ca o extensie a mediului de stocare, denumirea "file-server" nefiind specifica bazelor de date!), astfel ca - in lipsa unor medii bine integrate in sistemul de operare al retelei - accesul la informatie inseamna accesul la fisier (iar daca acesta nu-i foarte mic, traficul prin retea devine greoi). Daca se bazeaza pe o retea centralizata (o stea organizata in jurul hub-ului este mult mai performanta decat cea liniara/bus sau peer-to-peer), implementarea LAN a unei baze de date medii poate satisface in foarte multe cazuri.

Modelul client/server
Suntem ispititi sa credem, ca un reflex al superficialitatii (acesta fiind unul dintre marile riscuri actuale ale informatizarii), ca daca se implementeaza o baza de date ce depaseste - sa zicem! - un milion de inregistrari, baza de date desktop (mediu integrat) nu mai face fata si trebuie sa ne orientam catre un SGBDR mare. Pentru operarea in regim monoutilizator lucrurile sunt destul de false: performantele (viteze de accesare si procesare a datelor) sunt cat se poate de comparabile daca este vorba de un hardware bine echilibrat (un PC care sa suporte fara probleme un SGBDR mare va favoriza si baza de date integrata). Vreau sa spun ca altele sunt criteriile care ne orienteaza catre SGBDR-uri mari organizate in model client/server:

- operarea multiuser concurentiala (considerat punctual, nici aici avantajele nu sunt nete deoarece un FoxPro/LAN cu file-server face fata onorabil);

- descongestionarea traficului prin retea datorita transmiterii doar a datelor tinta (adica un minim);

- controlul drepturilor utilizatorilor si monitorizarea activitatii (conectare si aplicatii);

- implementari unice de logica centralizata (reguli, proceduri, declansatoare - existente doar la nivelul serverului);
- gestionarea tranzactiilor ('tranzactia = succesiune de comenzi elementare, definind unitatea logica prin care opereaza un pachet client"), aspect care devine capital/critic atunci cand se administreaza un sistem complex de date distribuite sau un mediu OLTP (on-line transactions processing); ceva mai recent - sub influenta Internetului - tranzactiile au loc prin comunicatie asincrona (conversationala) sau chiar fara confirmare ('fire-and-forget");

- serverul asigura integritatea, consistenta si actualitatea datelor (propagari de actualizari prin mecanismele de integritate referentiala);

- optimizarea organizarii fizice a datelor (colaborarea la un nivel cat mai jos cu sistemul de operare si cu sistemul de fisiere) si optimizarea accesului la date. (Un exemplu de colaborare la nivel fizic este posibilitatea SGBD-urilor de a face duplicari ale datelor - copiile de siguranta fiind unul dintre primele niveluri ale tolerantei la defecte. Desigur ca si un LAN desktop - Novell, Windows NT - poate face mirroring, insa nuantele difera.)

- recuperarea datelor in caz de blocare/cadere a sistemului si refacerea tranzactiilor neterminate;

- jurnalizarea acceselor, tranzactiilor si a sesiunilor de lucru sau de administrare;

- economicitatea upgrade-ului: ridicarea performantelor globale rezida in principal in cresterea puterii calculatorului pe care ruleaza serverul bazei de date, privind mai putin calculatoarele client pe care se afla software-ul front-end etc.

Se cuvine sa facem o scurta descriere a organizarii client/server si sa evidentiem cateva particularitati interesante.
- Client si server pot fi vazute si ca doua procesoare distincte ruland pe masini diferite (mai rar pe aceeasi masina), bazate eventual (dar nu obligatoriu!) pe acelasi sistem de operare.
- Comunicatia prin care partea 'client" a aplicatiei solicita servicii partii "server" se face prin mesaje (message-passing), fiind complet transparenta utilizatorului.

- Posturile de lucru pot fi uzual PC-uri, laptop-uri, statii UNIX sau Macintosh, iar serverul poate fi un mainframe, un server departamental sau chiar un PC bine dopat.

- Software-ul bazelor de date implementate prin arhitectura client/server se prezinta generic astfel: SGBD-urile asigura partea de server, iar aplicatiile de exploatare a datelor se afla uzual la nivelul client (sculele de editare a aplicatiilor utilizator apartin de producatorii SGBD-urilor implementate sau pot fi din familia celor bazate pe specificatii deschise: ODBC, JDBC, Embeded SQL, DCOM, OLE etc.).

- Repartizarea datelor si a aplicatiei (logicii) intre straturile 'client" si 'server" nu este preimpusa, fiecare implementare fiind susceptibila de un optim.

Arhitectura client/server dovedeste suplete (modularitatea si scalabilitatea oferind disponibilitate crescuta la reorganizari si extinderi) si deschidere (chiar se considera ca ea a aparut din necesitatea de a asigura o deschidere si interoperabilitate superioare modelului centralizat cu mainframe).
Modelul client/server a fost si el susceptibil de perfectionari de principiu, iar una dintre cele mai interesante este impunerea de niveluri/straturi intermediare intre client si server (n-tier), ca raspuns la dilema legata de pozitionarea programelor de aplicatie (logica de operare/afacere): care dintre parti trebuie sa fie mai 'groase", clientul sau serverul? Intrucat avantajele locale erau permanent necomplementare (salutare, domnule Heissenberg!), s-a dezvoltat ideea unui strat intermediar, concretizat intr-un server de aplicatii interpus intre clientul subtire si serverul bazei de date (middle-tier), ambele capete fiind astfel descongestionate de partea de logica. Interesanta mi s-a parut si observatia unor analisti care asociau tendinta moderna de accentuare a clientului subtire cu revenirea la modelul mainframe + terminale 'chioare". Oricum, cerintele actuale privind deschiderea mediilor informationale determina diluarea granitei dintre modele, retelele eterogene fiind vazute ca solutia cea mai viabila de a mentine echilibrul intre permanentele inovatii si conservarea investitiilor anterioare.
Insa cele mai deranjante dezavantaje ale arhitecturii client/server deriva din complexitatea ei (cerinte asupra personalului implicat: intelegerea conceptuala a arhitecturii de catre persoanele de decizie, precum si cunostinte aprofundate pentru cei care implementeaza/dezvolta efectiv sistemul/aplicatiile) si din standardizarea insuficienta.

Majoritatea serviciilor Internetului se desfasoara in regim client/server (banala navigare inseamna un utilizator accesand datele dintr-un site-server prin intermediul unei aplicatii client, care este browserul de Web), astfel ca devine naturala implicarea SGBDR-urilor in aplicatii Internet (de genul e-business sau e-commerce). Sa ne imaginam urmatorul scenariu: un furnizor de produse isi organizeaza un catalog de produse (magazin virtual) pe care utilizatorii il pot consulta prin navigatorul de acasa. Lucrurile se desfasoara prin pagina HTML pe care serverul de Internet o trimite clientului, la randul ei respectiva pagina actionand ca sablon (formular/forma) de accesare a informatiilor comerciale din baza de date deservita de un server legat la site-server (cel mai frecvent baza de date contine si imagini daca nu chiar si alte date multimedia). Iar daca utilizatorul va co
manda din produsele expuse completand un formular din pagina Web (controlat printr-un script I), se declansaza o alta serie de comunicatii intre client si server.

5. Regulile definitorii ale bazelor de date relationale (interpretarea formularii expuse la cap1)

Modelul relational definit de dr. Codd avea sa fie incrustat in memoria comunitatii IT prin urmatoarele 13 reguli:

Informatiile din baza de date sunt reprezentate exclusiv sub forma tabelara.

Toate datele individuale dintr-un tabel sunt oricand accesibile prin specificarea numelui tabelului, a liniei si a coloanei.

Baza de date relationala poate include ca valide valorile nule (reprezentand lipsa informatiilor din celulele respective).

Baza de date reprezinta descrierea informatiilor inmagazinate intr-un format logic simplificat de genul tabelelor.

Modelul relational are ca limbaj principal de interfatare SQL, insa poate suporta si alte limbaje (eventual incluzand in cod instructiuni Embedded SQL).

Vederile sunt actualizabile, daca vederea curenta este un tabel.

Modelul relational trateaza toate relatiile (de baza sau derivate) ca un singur operand pentru operatiile de actualizare (update), inserare (insert) si eliminare (delete) efectuate asupra datelor (precum si asupra datelor recuperate).

Aspectele logice ale bazei de date sunt complet separate de aspectele fizice.

Datele sunt conservate atunci cand bazei de date i se aduc modificari ilogice.

Regulile de integritate sunt create in SQL, fiind stocate in catalogul bazei de date si nu in aplicatii individuale (asa cum se poate intampla la mediile independente).

Distributia datelor (copierea datelor intr-o baza de date aflata la distanta) catre programele de aplicatie are loc continuu.

Regulile si restrictiile de integritate nu pot fi ocolite de nici un limbaj de acces.

Sistemul manevreaza bazele de date folosind exclusiv caracteristicile relationale.

6. Baze de date distribuite

Adevaratul sens al atributului 'distribuit" in contextul SGBD-urilor corespunde nu faptului ca sistemul permite accesarea datelor de la distanta (prin retea), ci acelor implementari care ingaduie aplicatiilor si utilizatorilor sa trateze baza de date ca pe un singur depozit logic chiar daca datele constituente sunt repartizate in mai multe locatii ale retelei (transparenta completa a localizarii datelor). Totusi problema este delicata si pentru ca - din punctul de vedere al analizei - se poate oricand crea o aplicatie care sa trateze unitar tabele de date situate pe calculatoare diferite. Dar pentru ca adevarata baza de date se doreste independenta de limbaje (sau de mediile de dezvoltare) sunt de apreciat acele SGBD-uri care contin integrate functionalitati care sa asigure distribuirea datelor in nodurile retelei.
Tinand cont ca de obicei volumul si complexitatea datelor spulbera idealul 'un computer foarte performant cumuland intreaga baza de date si deservind toti utilizatorii intreprinderii/organizatiei" si trebuie gasita o solutie de compromis, devine foarte interesanta colectia de criterii practice de distribuire a datelor in cazul fiecarei implementari, particularitatile cerand un optim jalonat de urmatoarele aspecte:

- nu trebuie niciodata pierdut din vedere dezideratul vitezei;

- limita de stocare si puterea calculatoarelor gazda;

- limita de transfer a retelei;

- preferabil ca fiecare aplicatie sa acceseze uzual un singur depozit al bazei de date (fara a impiedica accesarea cu frecventa redusa a celorlalte noduri ale retelei);

- folosirea functiilor two-phase-commit existente pentru a asigura integritatea datelor actualizate distribuit;
- planificarea, controlul si minimizarea duplicarii de obiecte ale bazei de date;

- corelarea organizarii cu facilitatile de optimizare distribuita ale SGBD-ului.

Cercetatorul Chris Date (coleg de proiecte cu E.F. Codd) a enuntat cele 12 cerinte ideale carora trebuie sa se supuna bazele de date distribuite; dintre acestea 9 sunt urmatoarele:

Autonomia locala: datele locale sunt detinute si administrate local - nici un post nu depinde de altele pentru a functiona.

Toate posturile sunt egale: nici un post nu se bazeaza pe o statie centrala.
Functionare neintrerupta: nu trebuie sa fie necesara o oprire planificata (instalarile/stergerile efectuate la un post nu afecteaza functionarea celorlalte).

Transparenta amplasarii: utilizatorii nu sunt obligati sa stie unde sunt amplasate datele pentru a le extrage.
Transparenta fragmentarii: relatiile dintre componentele bazei de date pot fi fragmentate pentru stocare, dar acest lucru ramane transparent pentru utilizator.

Transparenta duplicarii: relatiile si fragmentele pot fi reprezentate fizic prin copii multiple stocate separat, dar transparent pentru utilizator.

Prelucrarea interogarilor distribuite: operatiile de citire/scriere se pot desfasura la mai multe posturi, permitand optimizarea locala si globala a interogarilor.

Actualizarile distribuite: tranzactiile singulare pot executa codul la mai multe posturi.

Independenta de hardware: toate calculatoarele participa ca membri egali.

Independenta de sistemul de operare: sunt suportate mai multe sisteme de operare conectabile la retea.
Independenta de retea: sunt suportate mai multe retele prin protocoale comune.

Independenta de bazele de date: se asigura accesul uniform (interfatare unica) pentru datele provenind din SGBD-uri diferite.