Capitolul

Organizarea datelor în fişiere şi baze de date

În acest capitol ne propunem să abordăm cea mai importantă problemă privitoare la
stocare datelor geografice. Vom face o trecere în revistă a principalelor noţiuni şi a
modului de organizare a datelor punând accent pe unele aspecte privitoare la stocarea
datelor spaţiale. Pentru o mai bună înţelegere a acestei chestiuni, vom face referire şi la
structuri de date nespaţiale, care în parte sunt cunoscute de cititor. Vom continua apoi cu
bazele de date, tipurile de baze de date şi în final bazele de date spaţiale care sunt utilizate
acum. Deşi unele tipuri de baze de date, cum ar fi cele arborescente şi cele reticulare nu
se mai folosesc pentru stocarea datelor geografice, considerăm că este util să le
prezentăm şi pe acestea, mai mult pentru a vedea cum au evoluat bazele de date şi de ce
cele de ultimă generaţie sunt structurile cele mai potrivite. Şi în fine vom prezenta pe
scurt noile tendinţe în stocarea şi prelucraerea datelor geografice, care la momnetul actual
nu sunt implementate în softuri comerciale.

Înţelegerea noţiunilor ce urmează a fi prezentate este foarte importantă pentru a deosebi sistemele
bazate pe fişiere şi cele de baze de date, dar şi pentru gestionarea datelor. Voi încerca să abordez
această problematică de o manieră care să fie accesibilă atât începătorilor cât şi celor care au deja
cunoştinţe mai avansate despre aceste noţiuni.

În vorbirea curentă se face abuz de noţiunea de bază de date, ea desemnând o colecţie de

date de orice natură cum ar fi fişiere Excel, shapefile, hărţi scanate, rastere de orice fel
(inclusiv imagini satelitare) ş.a.m.d. Acest lucru se întâmplă deoarece atunci când se
învaţă aceste noţiuni, ele nu sunt prezentate corespunzător de către cel care explică. Pe de
altă parte, foarte multe date cu care suntem în contact direct sau indirect au într-adevăr
structură de BD (datele de intreprindere, sau bănci) şi atunci, prin analogie, transferăm
noţiunea înspre fişiere de date.

Noţiunea de fişier are multe înţelesuri. Din punct de vedere a sistemului de operare orice
structură date care are un nume şi ocupă un spaţiu pe disc este fişier. Exemplele sunt de
natură diversă: un document (fişier word), un fişier Excel, un fişier mp3, fişier DLL, un
driver, însuşi softul word conţine un fişier executabil, care este de fapt programul word
(word.exe), dar şi un fişier de date cu extensia dbf. Acesta din urmă are, în schimb, o
structură de tip bază de date.

1. Structuri de date
Înainte de toate consider că este util să reamintim câteva noţiuni generale privitoare la
structurile de date în general, care vor fi folositoare pentru înţelegerea în profunzime a
modului de organizare a fişierelor de date şi a bazelor de date.
Noţiunea de structură de date se referă la forma conceptuală a datelor, adică aşa
cum este percepută de utilizator.
Stocarea în memorie a unui număr presupunea două entităţi: adresa locaţiei şi
locaţia în care este înregistrat numărul respectiv. Memoria principală a calculatorului este
organizată ca un ansamblu de celule separate, care au adrese consecutive. Spunem că
aceasta este organizarea din punct de verdere fizic. A gestiona direct o astfel de structură
este foarte dificil astfel că de cele mai multe ori este mai convenabil să li se asocieze un

1
alt mod de aranjare. Astfel a apărut noţiunea de structură conceptuală, adică aşa cum
este perceput utilizator. Corespondenţa cu înregistratra fizică este făcută de un soft
special sau de sistemul de operare (SO).
Cele mai simple structuri de date sunt tablourile. Ele pot fi unidimensionale sau
multidimensionale. Pentru tablourile unidimensionale se mai foloseşte termenul de
vector. Am evitat folosirea acestui termen pentru a nu se crea confuzie cu structurile
spaţiale vectoriale. Următoarea structură, în ordinea complexităţii este cea de tablou
bidimensional. În fig. 1 am înfăţişat un model conceptual pentru acest caz şi organizarea
corespunzătoare (fizică) în memorie .

Fig 1. Un tablou bidimensional conceptual şi stocat în ordinea liniilor

Să considerăm un şir de caractere care reprezintă temperaturile luate pe o perioadă de

timp într-o anumită locaţie. Forma cea mai comodă de organizare conceptuală pentru
acesată problemă este cea de tablou unidimensional. În acest caz conversia de la
organizarea conceptuală la cea fizică este destul de directă. Datele pot fi stocate într-o
secvenţă de celule de memorie care au adrese comsecutive, în aceeaşi ordine. În cazul
tablorilor multidimensionale, conversia nu este atât de simplă. Să luăm acelaşi exemplu
dar temperaturile sunt luate în mai multe locaţii pe aceleaşi perioade de timp. Nu este
complicat să ne imaginăm că avem un tablou bidimensional. În acest caz extragerea
informaţiilor din tabel presupune găsirea valorii care se află pe o anumită linie şi coloană.
Dar, aşa cum am amintit memoria nu are o structură matricială, ci celule individuale cu
adrese consecutive. De aceea structura tabelului trebuie simulată. O posibilitate este de a
stoca datele linie cu linie, adică se stochează prima linie, apoi în continuare a doua linie
ş.a.m.d. Ne putem imagina o situaţie similară şi pentru cazul tridimesional. Printr-un
program se poate extrage orice element din tablou. O caracteristică importantă a
tablourilor este aceea că forma şi dimensiunile lor sunt fixe; prin urmare simularea lor în
memoria calculatorului este în esenţă un proces de conversie a locaţiei conceptuale a unui
element în locaţia reală. Există însă şi structuri dinamice, cu formă şi dimensiuni
variabile. De exemplu avem o listă de proprietari de teren. Poate să apară noi proprietari
sau să dispară alţii. În astfel de cazuri, pe lângă localizarea elementelor în cadrul
structurii ne vom confrunta şi cu variaţii ale acesteia. În aceste condiţii avem nevoie de
un instrument care să realizeze acest lucru, care se numeşte pointer. Un pointer (sau
indicator de adresă) este un element ce reprezintă o adresă, pe baza căreia pot fi referite
(legate) componentele unei structuri de date.
Pointerul este unul din cele mai importante concepte în domeniul structurilor
dinamice. Reamintim faptul că locaţiile din memorie sunt identificate prin adrese
numerice. Asfel, pentru a identifica un element (dintr-un tablou de exemplu) trebuie să

2
identificăm adresa sa. Situaţia este şi reciprocă: dacă ştim adresa vom şti şi elementul
care se găseşte la această adresă. Fiind vorba de valori numerice, adresele sunt, la rândul
lor, foarte uşor de stocat în memorie. Prin urmare, aşa cum elementul propriu-zis poate fi
înregistrat într-o celulă din memorie, şi adresa lui poate fi stocată în altă celulă. Într-un
fel, putem spune că celula care conţine adresa elementului „indică” elementul respectiv,
de unde şi numele de pointer (point) care se dă celulelor care conţin adrese. Alte exemple
de pointeri sunt adresele URL utilizate pentru legarea între ele a documentelor hipertext,
cu diferenţa că ele sunt pointeri către locaţii din Internet. Această noţiune va fi folosită
mai târziu şi în structurile bazelor de date.
De exemplu un nod al unei structuri de date arborescente (fig. 2 a) conţine pe
lângă alte informaţii pointeri corespunzători subarborilor din nod. De asemenea, o celulă
a unei liste unidirecţionale va avea un câmp a cărui valoare reprezintă pointerul
corespunzător celulei succesoare din listă (fig. 2 b)

Fig. 2 Pointer sau indicator de adresă

2. Fşiere de date
Din punct de vedere al unui utilizator un fişier de date este o grupare de date omogene din
punct de vedere al semnificaţiei acestora şi a cerinţei de prelucrare. Ele sunt create cu un
anumit soft (limbaje de programare sau soft specializat), fiind dependente de acesta.
Fişierul este o structură de organizare care prezintă un dublu aspect: unul fucţional
sau logic, legat de natura datelor pe care le conţine şi unul fizic, legat de suportul pe care
este înregistrat. Nivelul logic este forma sub care este văzut de utilizator, iar cel fizic este
legat atât de suport (cum se stocheză) cât şi de sistemul de operare. Nivelul fizic
condiţionează nivelul logic de organizare al fişierului.
Elementul de bază al unui fişier, sub aspect funcţional, este articolul sau
înregistrarea logică, iar sub aspect fizic este blocul sau înregistrarea fizică.

2.1. Organizarea logică a fişierelor.

Articolul este o grupare de date asociate, care poate fi identificată şi tratată fie ca o unitate,
fie prin datele individuale (câmpurile) care le compun. El reflectă caracteristica de structură
uniformă a datelor.
Din punct de vedere logic, fişierul este o mulţime organizată de articole.

Exemplul 1. Considerăm un fişier ce conţine date privitoare la un bazin hidrografic, pe care

îl vom numi HIDRO. O strutcură posibilă este:

Cod râu_____Denumire râu Supraf bazinală Lungime Debit mediu

N(8) AN(15) N(8.4) N(4) N(6.4)

Unde AN indică un câmp alfanumeric, iar N un câmp numeric. În paranteze s-a indicat
lungimea câmpului.

3
 Rămâne să completaţi dvs. lungimea şi conţinutul articolelor.
Exemplul 2. Fiind dat un teritoriu (să zicem judeţul Cluj), pe care îl vom numi CLUJ,
considerăm următoare structură de articol:

Denumire localitate Supraf. Supraf.agric. Populaţie

Conţinutul articolului este dictat de necesităţile practice de prelucrare. În momentul

creării (vezi mai jos), ea rămâne definitivă.
Tratarea fişierelor presupune următoarele operaţii:
1) crearea - operaţia prin care se înregistrează pe suport articolele care constituie
fişierul în prima sa formă;
2) exploatarea (consultarea)- operaţia prin care se extrag datele din fişier în vederea
prelucrării;
3) actualizarea - operaţia prin care se modifică conţinutul unui articol, se şterg sau
se adaugă altele noi.
Aceste operaţii se excută prin intermediul unor programe specifice fiecărei aplicaţii
scrise într-un limbaj de programare. Operaţia de exploatrea presupune un anumit tip de
acces la date.
În cele ce urmează va fi utilizat termenul de acces având sensul de modalitate de
localizarea a unei înregistrări oarecare din cadrul unui fişier. Oricare ar fi operaţia care se
face asupra fişierelor, accesul, adică înscrierea unui articol pe suport sau citirea lui, se poate
face în două moduri: secvenţial şi selectiv.

În acces secvenţial articolele sunt tratate unul după altul, începând cu primul articol
înregistrat şi terminând cu cel căutat. Accesul poate fi utilizat fie în scriere, fie în citire.
Avantaj: organizare simplă. Dezavantaj: viteză redusă de acces datorită parcurgerii tuturor
articolelor care îl preced pe cel căutat. Procesul poate fi considerabil simplificat dacă este
ordonat după un anumit câmp numit câmp cheie. Pentru actualizarea unui fişier secvenţial,
noile date sunt înregistrate (adăugate) mai întâi sub forma unui alt fişier secvenţial, cunoscut
sub numele de fişier tranzacţional. Apoi acesta este sortat după aceeaşi cheie şi înregistrările
din fişierul iniţial sunt actualizate în ordinea lor de apariţie. Această organizare este
inadecvată pentru fişiere mari.
În acces selectiv, articolele pot fi tratate direct, fără a parcurge toate articolele care îl
preced şi are două variante: acces indexat şi acces direct. În acces direct (random access
adică acces aleator) înregistrările conţin pointeri înspre alte înregistrări. Deoarece accesul
indexat este foarte important şi pentru baze de date, va fi abordat mai detaliat.
Un index este o colecţie de date care permite să se localizeze mai rapid anumite
înregistrări dintr-un fişier. Un index pentru un fişier sau bază de date este similar unui index
dintr-o carte. Este o structură asociată unui fişier, la care se poate face referire atunci când se
caută un articol, la fel ca şi căutarea în indexul unei cărţi. Un index elimină parcurgerea
secvenţială a fişierului.
Pentru generearea unui fişier index trebuie specificat un câmp care are valoare unică
(două articole nu pot avea aceeaşi valoare a câmpului respectiv) care se numeşte câmp
cheie. Un index pentru un fişier constă dintr-o listă de valori care apar în câmpurile cheie ale
fişierului, la care se adaugă poziţia înregistrării pe suport. Adică :
(cheie, adresă fizică)

4
Lista elementelor care au forma de mai sus se numeşte tabel de index, care se materializează
pe disc sub forma unui fişier numit fişier de index, iar fişierul de date căruia i s-a asociat un
fişier de index se numeste fişier indexat.

De exemplu, dacă avem o listă de proprietari de parcele, am putea construi un index care să
conţină lista numerelor de identificare a proprietarilor cum ar fi CNP, care este unic şi care
este de fapt cheia. Într-un astfel de fişier, regăsirea înregistrării unui anumit proprietar
presupune căutarea în index a CNP respectiv şi apoi citirea înregistrării corespunzătoare de
la poziţia indicată.
Această tehnică este foarte generală. Într-un fel, sistemul de operare a unui calculator
consideră că toate fişierele stocate pe disc formează un fişier foarte mare, iar directorul este
un index stocat pe disc, pe care SO îl utilizează pentru a localiza fişierele solicitate.

2.3. Organizarea indexului

Să studiem acum mărimea indexului. Deoarece pentru a căuta ceva în el, indexul trebuie să
fie mai întâi transferat în memoria principală, dimensiunea lui trebuie să se încadreze în
nişte limite rezonabile. Dacă numărul de înregistrări creşte foarte mult (şi aceasta este
situaţia cel mai des întâlnită la baze de date), acest lucru poate cauza nişte probleme. O
tehnică de rezolvare a acestei probleme este de a se utiliza indexul pentru a găsi poziţia
aproximativă a înregistrării dorite : se ordonează secvenţial fişierul după cheie, apoi se
împarte în dimensiuni mai mici, care conţin fiecare mai multe înregistrări. Fiecare segment
astfel obţinut este reprezentat în index printr-un singur articol, care în mod normal este
ultima valoare a câmpului cheie din cadrul segmentului. În acest mod se obţine un index
parţial, care conţine doar unele din câmpurile cheie din fişierul de date (fig. 3). În cadrul
acestei situaţii, pentru regăsirea unei înregistrări se caută în index prima valoare mai mare
sau egală cu valoarea dorită şi se parcurge apoi secvenţial segmentul corespunzător. Această
organizare este o combinaţie între un fişier secvenţial şi un fişier inxeat se mai numeşte
organizare secvenţial-indexată, iar fişierul în cauză fişier secvenţial-indexat.

Fig 3. Fişier care utilizează un index parţial

5
 Atunci când un fişier de index este prea mare, iar organizarea secvenţial-indexată nu
dă rezultate, timpul de căutare creşte. Pentru a optimiza timpul de căutare s-a introdus
termenul de index cu niveluri multiple. Acesta presupune crearea unui nou index al
indexului, de dimensiune mai mică. Cu alte cuvinte fişierul de index este tratat ca şi un fişier
de date oarecare şi căruia i se ataşează un alt index. Acesta se numeşte index de nivelul 2.
Procedeul se poate repeta, în cazul structurilor de date mari, generânduse din tabela de
indecşi de nivelul 2 un alt tabel index pe care îl vom numi index de vivelul 3. Procedeul se
poate repeta, teoretic, pentru index de nivelul n. După cum vom vedea mai jos în acest
capitol, nivelul 3 este suficient pentru accesarea optimă a majorităţii structurilor de date
inclusiv a celor geografice.

2.4. Organizarea fizică a fişierelor.

Am văzut că din punct de vedere fizic un fişier este stocat în memoria externă care poate fi
considerată ca fiind constituită din unităţi de citire/scriere. O astfel de unitate este o suită de
octeţi care pot fi citite "în bloc" atunci când o operaţie fizică elementară execută un schimb
de informaţii cu memoria internă. Un astfel de şir de octeţi este numit înregistrare fizică sau
bloc. Din punct de vedere fizic, fişierul este o mulţime organizată de înregistrări. În
consecinţă atunci când se manipulează un fişier se pune în funcţiune un mecanism de
citire/scriere ce realizează o înregistrare fizică completă.
O înregistrare fizică poate conţine mai multe înregistrări logice, dar şi o înregistrare
logică poate conţine mai multe înregistrări fizice (teoretic) şi o altă posibilitate este ca o
înregistrare fizică să fie incompletă. Această diferenţă depinde atât de mărimea articolului
cât şi de cea a blocului, aceasta din urmă fiind specifică calculatorului (de fapt e dictată de
Sistemul de Operare).
Deoarece acestă organizare este transparentă pentru utilizator, nu vom intra în
detalii.

2.5. Neajunsul structurilor bazate pe fişiere

Sistemele tradiţionale bazate pe fişiere, au anumite limitări, pe care le vom evidenţia în
cele ce urmează.
Separarea şi izolarea datelor. Atunci când date sunt izolate în fişiere diferite, cele care ar
trebui să fie disponibile sunt greu de accesat. Programatorul de aplicaţii trebuie să
sincronizeze prelucrarea a două fişiere, pentru a se asigura că datele sunt extrase corect.
Acesastă dificultate este sporită atunci când se cer date din mai multe fişiere.
Dublarea datelor. Din cauza modului de abordare descentralizat, tratarea bazată pe fişiere
a condus la dublarea (sau chiar multiplicarea) necontrolată a datelor. În afară de faptul că
introducerea de două sau mai multe ori ale aceloraşi date este o risipă de timp, mai
important este faptul că acest lucru duce la alterarea integrităţii datelor; cu alte cuvinte
datele nu mai concordă.
Dependenţa program - date. Structura fizică şi stocarea fişierelor de date este dependentă
de limbajul de programare cu care s-a făcut aplicaţia. Aceasta înseamnă că modificările în
structura fişierului este dificilă şi ia timp. De exemplu dacă într-un fişier dorim să
adăugăm un câmp sunt necesare următoarele etape:
- se dechide fişierul în cauză;
- se defineşte un nou fişier cu noua structură;
- se citeşte din primul fişier fiecare articol şi se depune în noul fişier;

6
 - se şterge vechiul fişier;
- se redenumeşte noul fişier cu numele celui dintâi.
Deoarece structura fişierelor este încorporată în programele de aplicaţie, ea este
dependentă de limbajul în care au fost scrise acestea. De asemenea codul intern în care
sunt stocate fişierele sunt diferite de la limbaj la limbaj. De aceea exploatrea fişierelor
scrise cu limbaje diferite este foarte complicată. Chiar în limbaje cunoscute, cum ar fi
Basic, cel puţin pentru versiunile din anii 80, codul intern pentru fişiere secvenţiale
(ASCII) este diferit de cele cu acces direct (cod binar propriu). În consecinţă nu există un
control al accesului şi manipulării datelor dincolo de cel impus de către programele de
aplicaţie. Astfel portabilitatea este cvasiinexistentă.

Pe de altă parte cerinţele impuse de sistemele informatice tot mai complexe au condus la
necesitatea ca în proiectarea sistemelor de prelucrare a datelor să ţină seama de
dezideratul că mai mulţi utilizatori să aibă acces la aceeaşi colecţie de date, iar
organizarea să fie astfel realizată încât să fie satisfăcute în mod optim cerinţele de
prelucare multiuser.

Utilizarea metodelor şi a tehnicilor clasice de organizare a informaţiei, în această nouă

situaţie, ar fi dus la creşterea continuă a redundanţei datelor, fiind necesară reprezentarea
aceloraşi date în mai multe fişiere în scopul deservirii optime a diverselor programe de
aplicaţie. În aceste condiţii a apărut ca necesară cerinţa de control şi minimizare a
redundanţei, numită şi cerinţă de integrare a fişierelor de date. Apar astfel tehnici de
organizarea a datelor care permit permit reprezentarea datelor cât şi a relaţiilor intrinseci
dintre ele, având ca rezultat utilizarea fişierelor integrate. Trecerea la utilizarea fişierelor
integrate nu a rezolvat însă o problemă foarte importantă şi anume aceea a independenţei
programelor de aplicaţii vis-à- vis de modul de organizare a datelor. Una din primele
soluţii abordate şi implemetate la ora respectivă (anii 60-70) a fost aceea de a crea o
interfaţă între fişierele integrate şi programele de aplicaţii, interfaţă care avea rolul tocmai
de a realiza independenţa dorită. În scurt timp s-a dovedit că şi acest lucru nu este
corespunzător pentru volume mari de date, astfel că s-a elaborat un nou concept, anume
de bază de date, cu care ne vom ocupa în cele ce urmează.

3. Baze de date
Există mai multe definiţii pentru baza de date, fiecare dintre ele scoţând în evidenţă anumite
aspecte, care de cele mai multe ori sunt asociate cu anumite domenii aplicative. În cele ce
urmează vom da două definiţii, care oarecum se completează una pe alta. Pentru a păstra
originalitatea noţiunilor, nu am combinat acele definiţii. Ne-am mulţumit să le comentăm.
Din aceste comentarii va rezulta clar esenţa noţiunii de BD, care este atât de utilizată fie
corect fie abuziv, aşa cum am menţionat mai sus.
După "Le Journal Officiel" (17 ian. 1982) baza de date (BD) este un ansamblu de
date organizate în vederea utilizării sale prin programe corespunzătoare aplicaţiilor
distincte şi de manieră de a facilita evoluţia independentă a datelor şi programelor.
Deoarece, la prima vedere s-ar părea că nu există o deosebire esenţială între un fişier
şi o bază de date (BD), în cele ce urmează vom comenta conţinutul acestei definiţii, în
primul rând pentru a înţelege mai bine această noţiune şi în al doilea rând pentru a vedea

7
deosebirile dintre aceasta şi fişierul de date. În mod inevitabil, pentru a scoate în evidenţă
aceste deosebiri vom relua caracteristicile din definiţie, într-o manieră mai sintetizată.
1. <Un ansamblu de date organizate...>. O BD este deci ca un fişier, un ansamblu
de date. Se distinge deci un al doilea tip de ansamblu de date, deoarece fişierele sunt
inadaptate la anumite sarcini. Fişierele sunt create, în principiu, pe parcursul dezvoltării unor
aplicaţii, în măsura necesităţilor. De cele mai multe ori informaţiile stocate sunt redundante,
incoerente sau insuficient structurate.
Fişierele sunt redundante, deoarece aceleaşi date se regăsesc în final, în mai multe
fişiere. Aceasta implică un volum mare de informaţii de stocat şi multe operaţii de
actualizare.
Fişierelor le lipseşte coerenţa, deoarece datorită redundanţei este dificil de a
actualiza toate fişierele în acelaşi timp (aflându-se de multe ori în locuri diferite).
Fişierelor le lipseşte structurarea, deoarece fiind create pe parcurs şi fără nici o
viziune globală, seamănă cu date prea specifice care nu permit utilizarea lor pentru o nouă
tratare.
Pentru a remedia aceste defecte, noţiunea de BD vizează înlocuirea diferitelor fişiere
printr-o singură BD pusă la dispoziţia utilizatorilor: ea unifică structurarea şi stocarea
informaţiei datorită unui model unic şi coerent de date.
2. <...în vederea utilizării prin programe corespunzătoare unor aplicaţii
distincte...>. Acest model unic de date nu trebuie legat de o aplicaţie specifică care să-i
"îngheţe" structura. Din contră el trebuie să fie suficient de general pentru a se putea adapta
la toate situaţiile particulare.
Concepţia unei BD necesită, în consecinţă, o analiză globală şi de perspectivă a
datelor.
3. <...şi de manieră să faciliteze evoluţia independentă a datelor şi
programelor.>. În mod tradiţional, în limbajele COBOL, Pascal, BASIC, fişierele sunt
create în programe care le şi exploatează, sau în programe înlănţuite (unul creează, altul
exploatează şi eventual altul actualizează), aceasta depinzând de natura aplicaţiei. Deci
datele şi programele sunt legate în mod intim. Într-o BD, datele sunt descrise independent de
programe, toate găsindu-se într-un singur loc (ca un container). Aceasta evită redescrierea
datelor în diferite programe care le utilizează şi permite modificarea programelor (sau a
datelor) fără ca datele (sau programele) să fie atinse.
Această definiţie are un neajuns, anume că nu face referire la relaţii între structurile
de date. Pentru a lămuri şi această caracteristică vom da şi o altă definiţie (Connolly ş.a.,
2001) pe care o vom adăuga la cea de mai sus.
O bază de date este o colecţie partajată de date, între care există relaţii logice (şi o
descriere a acestor date), proiectată pentru a satisface necesităţile informaţionale ale unei
organizaţii.
4. < … colecţie partajată de date…>. La o bază de date poate avea acces un singur
utilizator (monouser) sau mai mulţi utilizatori simultan (multiuser). Administratorul de BD stabileşte
maniera de acces la BD utilizatorilor externi pentru a proteja BD de accesul neautorizat.

5. < … între care există relaţii logice (şi o descriere a acestor date)…>. Atunci când se
analizează necesităţile informaţionale ale unei organizaţii, se încercă identificarea entităţilor
atributelor şi a relaţiilor. O entitate este un obiect distinct (o persoană, un poligon, un concept sau un
eveniment) care trebuie reprezentat în baza de date. Un atribut este o proprietate care descrie un

8
aspect oarecare al obiectului pe care dorim să-l înregistrăm, iar o relaţie este o asociaţie între mai
multe entităţi.
Această parte din definiţie este de o deosebită importanţă în stabilirea relaţiilor în
cadrul datelor geografice, după cum vom vedea mai departe.

Tratarea datelor prin sisteme de BD, în care se separă definirea datelor de

programele de aplicaţie, este foarte asemănătoare cu abordarea folosită în realizarea
modernă a programelor, în care se oferă o definiţie internă a unui obiect şi o definiţie
externă. Utilizatorii văd doar definiţia sa externă, fără a cunoaşte modul în care acesta este
definit fizic şi cum funcţionează. Un avantaj al acestei tratări, cunoscute sub numele de
abstractizare a datelor, constă în faptul că face posibilă modificarea definiţiei interne a unui
obiect fără a afecta utilizatorii acestuia, cu condiţia ca definiţia externă să rămână aceaeşi
(Connolly ş.a., 2001). Dacă sunt adăugate noi structuri de date sau sunt modificate cele
existente, atunci programele de aplicaţie nu sunt afectate cu condiţia să nu depindă direct de
ceea ce se modifică. De exemplu dacă creem un câmp nou, aplicaţiile existente nu sunt
afectate, dar dacă eliminăm un câmp utilizat de către un program de aplicaţie, acesta este
afectat de modificare şi trebuie modificat în consecinţă.
Ca şi fişierul, BD este o structură de organizare care prezintă un dublu aspect: cel
logic, care descrie organizarea datelor la nivel conceptual, independent de toate restricţiile
tehnice şi cel fizic care descrie organizarea datelor la nivelul implementării pe un calculator.
În principiu, există mai multe modele fizice diferite pentru un acelaşi model logic. Aceasta
permite schimbarea modelului fizic fără a se modifica modelul logic, pentru îmbunătăţirea
performanţelor unei BD. De asemenea posibilitatea schimbării modelului fizic duce la o
portabilitate mai mare a produsului, adică facilitează transferul aplicaţiilor de pe o maşină pe
alta. Astfel programele pot fi descrise unic la nivel logic, trecerea la nivel fizic făcându-se
automat prin intermediul unui sistem de gestiune a BD. Regăsim aici tendinţa de prevalare
în evoluţia informaticii: ea se îndepărtează din ce în ce mai mult de maşină pentru a se
apropia mai mult de utilizator.

4. Sisteme de Gestiune ale Bazelor de Date (SGBD)

Aşa cum fişierele sunt dependente de limbajele de programare, şi BD sunt dependente de un
soft specific cu ajutorul cărora se generează şi se exploatează BD. Un sistem de gestiune a
bazelor de date (SGBD) este un sistem complex de programe aflate în interacţiune care
asigură desfăşurarea corectă a tuturor prelucrărilor: descrierea, memorarea, interogarea,
modificarea, tratarea şi întreţinerea datelor ce constituie o bază. SGBD poate fi conceput ca
un supersistem de gestiune de fişiere. Termenul englez este Data Base Management System.
Complexitatea unui SGBD este reflectată în mulţimea componentelor şi a structurii
relaţiilor funcţional dependente.
O BD, indiferent de tip este asociată întotdeauna cu un SGBD. De aceea atunci când
se vorbeşte de un anumit tip de BD este acelaşi lucru dacă se vorbeşte despre un anumit
SGBD. Sigur că ele nu trebuie să se confunde dar, în limbaj curent atunci când se face
referire la modele, o noţiune se foloseşte în locul celeilalte.

4.1. Principalele funcţii ale SGBD

În cele ce urmează vom descrie succint principalele funcţii ale SGBD, fără a specifica un
anumit SGBD.

9
 Descrierea datelor se face atât la nivel logic (utilizator) cât şi la nivel fizic (suport).
Funcţia de descriere permite definirea structurii datelor (a modelului de date) şi al relaţiilor
dintre acestea. De asemenea, tot prin intermediul acestei funcţii se definesc şi condiţiile de
acces la informaţiile conţinute în BD. Descrierea structurii se realizează cu ajutorul unui
limbaj de descriere propriu fiecărui SGBD.
Utilizarea datelor. În mod obişnuit se disting: interogarea BD şi punerea la zi
(actualizarea). Aceste două tipuri de operaţii se fac fie direct prin limbajul de manipulare a
datelor (limbaj autonom), fie prin intermediul unor instrucţiuni specifice scrise într-un
anumit limbaj de programare (limbaj gazdă). Funcţia de utilizare permite comunicarea între
utilizator şi BD sub aspectul asigurării mijloacelor de comunicare care îl avantajează cel mai
mult. Utilizarea eficientă a datelor implică posibilitatea de acces indexat la date pentru
mărirea vitezei.
Coerenţa datelor. Un SGBD trebuie să permită unui utilizator să definească reguli
precise pentru menţinerea coerenţei (se mai zice "integritate") datelor unei baze. Aceste
reguli sunt numite restricţii de integritate ale BD. Ele nu permit, de exemplu, într-o BD de
personal ca două persoane să aibă acelaşi matricol.
Confidenţialitatea datelor. Un SGBD trebuie să permită definirea drepturilor de
acces utilizatorilor la date pentru a le consulta sau actualiza. Aceasta se realizează prin chei
de protecţie, parole sau informaţie criptată.
Securitatea datelor. Dacă în cursul unei manipulări a BD, se produce un incident
fizic (de exemplu întrerupere de curent) sau de programe, SGBD trebuie să preîntâmpine
acestea prin diferite strategii. De asemenea accesul la BD trebuie să fie controlat pentru a
preîntâmpina accesul neautorizat. Adiminstratorul de BD este responsabil în atribuirea
accesului (numai în citire sau în citire şi scriere).
Concurenţa accesului. Dacă utilizatori diferiţi doresc să acceseze în acelaşi timp
aceleaşi date, SGBD trebuie să regleze această concurenţă ordonând cererile. Nu toate
SGBD-urile au această funcţie, după cum vom vedea mai departe

4.2. Tipuri de SGBD. Scurt istoric.

Primele modele de BD, cu SGBD aferent, care au apărut în anii ’60 şi începutul anilor
’70, au fost modelul ierarhic (arborescent) şi mai apoi cel în reţea (reticular). Prima
abordare a fost făcută de IBM pentru stocarea informaţiilor enorme din cadrul
programului Apollo. Modelul reticular a apărut pentru a rezolva unele neajunsuri ale
modelului ierarhic cum ar fi incapacitatea de a reprezenta relaţii complexe. Aceste două
abordări reprezintă prima generaţie de SGBD. Ele prezintă câteva dezavataje
fundamentele (Connolly ş.a., 2001) :
-era necesar să se scrie programme complexe pentru a răspunde chiar la interogări simple,
bazate pe accesul navigaţional orientat înspre înregistrări;
-exista o independenţă de date minimală;
-nu exista nici un fundament teoretic larg acceptat.
În 1970 Codd a publicat un articol de referinţă, în care a analizat dezavatajele
modelelor existente şi oferind un nou model numit modelul relaţional, care s-a dovedit
mult superior. De atunci s-au implemntat nenumărate SGBDR atât pentru mainframe cât
şi, ceva mai târziu, pentru PC. SGBDR au fost denumite sisteme de generaţia a doua. Şi
aceste sisteme au slăbiciunile lor (aşa cum vom vedea), în special aspectele privind
modelarea, astfel că în anul 1976 Chen a prezentat modelul Entitate-Relaţie, care în

10
prezent (Connolly ş.a., 2001) constituie tehnică larg acceptată pentru proiectarea BD.
Însuşi Codd a încercat să abordeze un nou model, propunând o versiune extinsă a
modelului relaţional, denumit RM/T (1979), iar mai recent RM/V2 (1990). Încercările de
a oferi un model de date care să reprezinte mai fidel « lumea reală » au fost clasificate ca
modelări semnatice.
Ca răspuns la creşterea complexităţii aplicaţiilor au apărut noi modele şi anume :
modelul de date orientat spre obiecte şi modelul de date relaţional cu obiecte. Aceste noi
abordări în tehnologia bazelor de date au condus la ceea ce se numeşte generaţia a treia
de sisteme SGBD.
Există aplicaţii care se fac cu anumită dificultate şi pe aceste SGBD, astfel că s-au
abordat tipuri noi, care acum sunt în dezvoltare, anume SGBD deductive şi obiect
deductive. Acestea sunt puţin implementate la ora actuală, dar se anticipează că vor fi larg
acceptate în viitor.
Pe de altă parte, apariţia şi răspândirea reţelelor de calculatoare a avut ca rezultat
dezvoltarea într-o nouă direcţie a SGBD-urilor, acestea căpătând un caracter multiuser. De
asemenea, au apărut bazele de date distribuite, care reprezintă BD logic integrate, dar fizic
distribuite pe mai multe sisteme de calcul. Utilizatorul unei asemenea baze de date o vede ca
pe o bază unică, compactă (acesta este nivelul logic), cu toate că, în realitate, ea este
împărţită pe mai multe calculatoare diferite evident legate între ele (nivelul fizic). Această
organizare a dus la o creştere substanţială a vitezei de acces la o BD într-o reţea, eliminându-
se pe cât posibil, transferurile de date între calculatoare (care limitează viteza de lucru). Tot
datorită distribuirii se măreşte considerabil limita maximă a dimensiunii unei BD, care nu
mai este determinată de capacitatea fizică a unui singur sistem de calcul.
În plus independenţa de programe a datelor a permis evoluţia SGBD fără ca firmele
de soft să fie preocupate de compatibilitatea în jos, aceasta făcându-se automat.

5. Modele de organizare şi strucurare a bazelor de date

În cele ce urmează vom detalia principalele tipuri de BD cu SGBD aferent, atât pentru
structuri de date alfanumerice cât şi pentru cele geografice.
Structura unei BD este ansamblul formelor de organizare a datelor din baza
respectivă. Modurile de organizare sunt determinate de necesităţile aplicaţiei, tipul de SGBD
utilizat şi de tipul echipamentului pe care este implementată.
Un model de organizare a datelor este un şablon în conformitate cu care datele sunt
organizate logic la nivelurile semantice de descriere a datelor. Acesta constă în reprezentarea
unităţilor logice de date (entităţi) şi a relaţiilor dintre ele. Modelele utilizate în BD diferă în
principal prin modul de reprezentare a relaţiilor dintre date. Acestea se stabilesc între en-
tităţi, între o entitate şi atribut sau între atribute. Vor fi abordate: modelul ierarhic (sau
arborescent), modelul reticular, vom continua cu modelul relaţional, care va fi trata mai
detaliat, modelul relaţional extins, baze de date orientate obiect, baze de date obiect
relaţionare, şi în fine baze de date deductive şi obiect-deductive. Acestea diferă între ele prin
modul de prezentare şi manipulare a datelor, dar şi prin manieara de realizare a aplicaţiilor.
Cele mai uzuale BD implementate la ora actuală sunt cele relaţionale. De altfel, pentru
sistemele nerelaţionale se pot construi interfeţe care să le transpună în formă relaţională.

5.1. Modelul ierarhic (sau arborescent).

11
Este unul din cele mai vechi (apărut în jurul anului 1965). Structura fundamentală care
susţine o ierarhie este arborele. Structura cuprinde noduri conectate prin legături numite
arce sau muchii. Nodul cel mai de sus este numit nod rădăcină şi poate avea zero sau mai
multe noduri « copil », fiecare, la rândul lor putând avea zero sau mai multe alte noduri
« copil ». Ca urmare, structura poate fi definită recursiv. Cu alte cuvinte într-o structură
ierarhică pe mai multe nivele, orice element este în relaţie cu cel mult un element aflat la
nivelul imediat superior şi opţional cu mai multe elemente aflate la nivelul imediat inferior.
O informaţie este accesibilă numai pornind de la un punct de intrare unic: rădăcina. În afară
de nodul rădăcină, toate nodurile din arbore trebuie să aibe un nod « părinte ». Orice
porţiune a arborelui cu o originea într-un nod, în afară de nodul rădăcină, este numit
subarbore. În termeni practici, fiecare nod poate fi reprezentat printr-un tip de înregistrare,
iar fiecare legătură fie printr-un pointer înglobat în fiecare tip de înregistrare, fie prin
aranjarea fizică a înregistrărilor. Acest mod de organizare conduce la metode rapide de acces
la date pe verticală.
Sistemele ierarhice presupun că fiecare nivel poate fi atins folosind o cheie de
identificare. Între acestea şi atributele asociate există o legătură foarte precisă. Accesul la
date prin intermediul cheilor este foarte uşor, însă foarte dificil prin intermediul atributelor
asociate. Cheile de identificare formează un fişier index. În cazul BD mari, fişierele index
sunt şi ele voluminoase şi trebuiesc întreţinute. Aceasta conduce la o repetare a unor
atribute, conducând astfel la o redundanţă, BD mărindu-se în mod inutil.
Pentru structurile informaţionale, accesul obişnuit este de sus în jos. Aceasta
deoarece cele mai semnificative date, care sunt accesate frecvent, sunt plasate la nivelurile
superioare ale arborelui. De regulă, datele stocate la nivelurile inferioare sunt dependente
logic de datele aflate la nivelurile superioare şi, dacă este necesar vor fi regăsite în
conjuncţie cu acestea.

[Avantaje şi dezavantaje]
O caracteristică importantă a structurilor ierarhice este că apariţiile « copil » este
condiţionată de existenţa « părinte ». Prin urmare, în cadrul acestui model este constituită o
dependenţă, astfel încât, dacă se şterge o radăcină, atunci este şterasă întreaga structură în
jos. Un neajuns important este incapacitatea de a stoca tipuri de înregistrări care nu au o
apariţie de tip « părinte ». Un alt neajuns constă în dificultatea de a modela realţii de tipul
mai mulţi - la - mai mulţi sau alte relaţii complexe, care nu sunt ierarhice, în care un tip de
înregistrare are relaţii distincte cu mai multe alte înregistrări.
Dintre structurile ierarhice mai cunoscute în informatică amintim structura
sistemului de oparare Windows. De asemenea sistemul de organizare ierarhic este
binecunoscut în cercetarea mediului înconjurător, fiind folosit pentru taxonomii de plante
sau animale, clasificări de soluri, etc.
Datele geografice pot fi stocate într-o structură ierarhică într-un mod care reflectă
realitatea. Un exemplu este atunci când nivelurile unui model ierarhic corespund
nivelurilor administrării realităţii, de exemplu într-o ţară, judeţ, municipiu sau oraş.
Sistemele de baze de date ierarhice sunt uşor de extins şi de întreţinut. Totuşi, ele necesită
fişiere index mari, trebuie frecvent întreţinute şi sunt susceptibile la multe intrări. Căutările sunt
rapide, dar rutinele de căutare sunt fixate şi îngrădite de structuri. Astfel, înregistrările de la
acelaşi nivel nu pot fi căutate, şi nici nu se pot defini noi legături sau noi rutine de căutări.
Elementele de structură sunt corelate doar prin conexiunile unul la mai mulţi.

12
 Această constrângere impune presupunerea că toate interogările sunt cunoscute
dinainte şi că se ţine cont de acestea în procesele de structurare şi de intrare a datelor.
Această constrângere nu este întotdeauna naturală sau potrivită pentru aplicaţiile GIS. Ca
rezultat, sistemele de baze de date ierarhice sunt de obicei restricţionate la stocarea
datelor hărţii în GIS
În fig. 5 am exemplificat o BD arborescentă atribut, iar în figura 6 o BD spaţială.

Figura 5 (adapatare după Bernhardsen, 1992)

Stocarea datelor nespaţiale într-o BD arborescentă

13
Figura 6 (adapatare după Bernhardsen, 1992)
Stocarea datelor spaţiale într-o BD arborescentă. De observat faptul că liniile şi punctele sunt
stocate de două ori. Aici avem un table de indecşi spaţiali

5.2. Modelul reticular (în reţea)

În BD ierarhice, accesul se face doar pe verticală iar în multe situaţii sunt necesare legături,
altele decât cele pe verticală, şi care sunt mult mai rapide. Legăturile pe orizontală se fac lent
şi sunt de fapt simulate. Astfel a fost necesară introducerea conceptului de structură
reticulară care se caracterizează prin posibilitatea relaţiei cu mai multe elemente aflate la
nivele superioare. Teoretic orice element poate fi legat de orice alt element. Sunt structuri
mai complexe care permit accesul la un anumit element pe căi multiple. Structura reticulară
este un caz mai general de structură de date, dar şi foarte greu de gestionat.
Structurile reticulare sunt foarte economice din punct de vedere al utilizării spaţiului
pe disc, dar trebuiesc stabilite dinainte. "Ruperea" accidentală a unei legături, care nu
întotdeauna este sesizată, poate avea efecte imprevizibile în exploatarea ulterioară a BD.
Fiecare element sau o colecţie de înregistrări asemănătoare, are conexiuni cu
anumite elemente de nivel diferit. Interconexiunile sunt făcute astfel încât o caracteristică
poate fi asociată cu două obiecte principale. Structura de tip reţea rezultată reprezintă cu
o mai mare acurateţe interrelaţiile complexe care există deseori între obiectele geografice
din lumea reală. Elementele structurii pot fi corelate prin conexiunile unu – la - mai
mulţi, mai mulţi - la - unu şi mai mulţi – la - mai mulţi.

14
Figura 7 (adapatare după Bernhardsen, 1992)
Stocarea datelor spaţiale într-o BD reticulară. Aici avem un table de indecşi spaţiali

Scopul structurii de tip reţea a fost să îmbunătăţească flexibilitatea şi să reducă

intrările multiple ale structurii ierarhice. Punctele şi liniile sunt introduse o singură dată.
Căutările nu trebuie să treacă prin toate nivelurile şi o pot lua pe scurtături. Totuşi,
volumul de date index este mai mare decât volumul din structura ierarhică.
O structură de tip reţea permite conexiuni rapide între date care sunt stocate fizic
în diferite sectoare ale discului. Totuşi, menţinerea datelor stocate într-o structură de tip
reţea este complexă. Deşi folosirea unei structuri de tip reţea este mai adecvată în cazul
datelor geografice decât folosirea unei structuri ierarhice, aceasta a fost rareori folosită în
aplicaţiile GIS.
Structura spaţială care se pretează cel mai bine acestui model este cea de utilităţi
(apă, canal, electricitate, gaz, telecomunicaţii).

5.3. Modelul relaţional

Bazele de date relaţionale (BDR), împreună cu SGBDR, au devenit, în zilele noastre,
elementul de software dominant în prelucrarea datelor. Modelul relaţional a fost propus
pentru prima dată de Codd în anul 1970, în articolul său intitulat „Un model relaţional de
date pentru bănci de date partajate de dimensiuni mari”. Acest articol este acum general
acceptat ca un moment hotărâtor în dezvoltarea sistemelor de baze de date, în el fiind
tratată complet teoria matematică a bazelor de date relaţionale. Este curios faptul că deşi
acest model este, din punct de vedere conceptual mai simplu decât celelalte modele
prezentate mai sus, a apărut mai târziu. Deoarece acest model este implementat pe
sofware GIS actuale, vom rezerva un spaţiu mai larg decât celelalte două.
Modelul relaţional se bazează pe conceptul matematic de relaţie, care este
reprezentat fizic sub formă de tabel. Codd, care era un matematician versat, a utilizat
terminologia din matematică, în principal teoria mulţimilor şi logica predicativă. În cele
ce urmează vom expune terminologia BDR, într-o manieră cât mai accesibilă.
Un SGBDR impune ca BDR să fie percepută de către utilizator doar sub formă de
tabele. De notat, totuşi, că această percepţie se aplică numai structurii logice a BD, adică
la nivelurile externe. Nu se aplică şi structurii fizice a BD, care poate fi implementată
utilizând o varietate de structuri de stocare. O strucură relaţională este un tabel cu coloane
şi rânduri. Un atribut este o coloană a unei relaţii, cu o anumită denumire. Cu alte
cuvinte, o relaţie este reprezentată printr-un tabel bidimensional, în care rândurile
acestuia corespund înregistrărilor individuale, iar coloanele corespund atributelor.
Atributele pot apărea în orice ordine, relaţia rămânând neschimbată, prin urmare păstrând
acelaşi înţeles. Un rând dintr-o relaţie se mai numeşte tuplu. Numărul de atribute
(coloane) pe care îl conţine o relaţie se numeşte grad. O relaţie cu un singur atribut are
gradul I şi este denumită relaţie unară sau un-tuplu. O relaţie cu două atribute este
denumită binară, una cu trei atribute se numeşte ternară, una cu n atribute se numeşte n-
ară. O altă noţiune importantă este cardinalitatea unei relaţii, care este definită ca fiind
numărul de tupluri conţinute de aceasta. Faţă de cele expuse mai sus, mai există un set de
termeni care se utilizează uneori. Astfel o relaţie poate fi denumită fişier, tuplurile sunt
înregistrări, iar atributele sunt câmpuri (Connolly ş.a., 2001). Un ultim concept
important este acela de domeniu. Acesta permite utilizatorului definirea sensului şi sursei

15
de valori pe care le poate lua atributul. Prin aceasta se poate evita introducerea incorectă a
datelor sau introducerea unor operaţii incorecte din punct de vedere semnatic. Acest lucru
constituie cea ce se numeşte o validare proforma. De exemplu dacă într-o BDR privind
clădirile avem un atribut care reprezintă anul, acesta nu poate fi mai mare decât anul
curent şi nici mai mic decât cea mai veche casă, să zicem 1940.

Relaţii matematice. Pentru a înţelege sensul adevărat al termenului de relaţie vom

introduce câteva concepte elementare, însoţite de exemple.
Să considerăm două mulţimi A şi B, unde A={3,4} şi B={1,2,5}. Produsul
cartezian AB reprezintă mulţimea tuturor perechilor, astfel că primul element să aparţină
mulţimii A, iar al doilea element să aparţină mulţimii B, adică

AB={(3,1), (3,2), (3,5), (4,1), (4,2), (4,5)}

La modul general produsul cartezian se scrie simbolic:

AB={(x,y)| x A, yB}

O submulţime oarecare a unui produs cartezian este o relaţie,  AB. De exemplu:

 = {(3,1), (4,1)}

este o relaţie. Dar şi tot produsul cartezian poate fi o relaţie.

Dacă considerăm că mulţimea A are n elemente şi B are m elemente, adică A={a1, a2,
a3, ... an} şi B = {b1, b2, b3, ... bm}, relaţia se mai scrie

ai  bj (i=1,2,...n; j=1,2,..,m)

şi citim: ai este în relaţie cu bj (bineînţeles i şi j sunt fixaţi). Practic această structură

reprezintă tablouri bidimensionale, care poate fi înfăţişată într-o manieră mai sugestivă

b1 b2 b3 ... bj ... bm
a1 r11 r12 r13 ... r1j ... r1m
a2 r21 r22 r23 ... r2j ... r2m
a3 r31 r32 r33 ... r3j ... r3m
...
ai ri1 ri2 ri3 ... rij ... rnm
...
an rn1 rn2 rn3 ... rni ... rnm
Aici rij reprezintă valoarea propriu-zisă a relaţiei (celulei).
Proprietăţile relaţiei.
O relaţie are următoarele carcateristici (Connolly ş.a., 2001)
- are o denumire, diferită de toate celelalte denumiri de relaţii;
- fiecare celulă conţine exact o singură valoare (rij);
- fiecare atribut are o denumire distinctă;
- ordinea atributelor nu are nici o importanţă;
- fiecare tuplu este distinct, adică nu există dubluri;

16
 - teoretic ordinea tuplurilor nu are nici o importanţă (totuşi, în practică, ordinea poate
afecta eficienţa accesării tuplurilor).
Într-o relaţie matematică, ordinea elementelor dintr-un tuplu este importantă. De exemplu
perechea (3,1) este diferită de perechea (1,3). Acest lucru nu este valabil şi pentru relaţiile din
modelul relaţional, care impune în mod special ca ordinea atributelor să nu prezinte importanţă.
Motivul este că anteturile coloanelor definesc cărui atribut îi aparţin valorile. Aceasta însemnă că
nu contează ordinea anteturilor coloanelor, dar odată aleasă structura unei relaţii, ordinea
elementelor din interiorul tuplurilor trebuie să corespundă ordinii denumirilor atributelor.

Pentru o percepţie mai facilă şi mai ales pentru a nu crea confuzii între noţiunile consacrate în
sistemele tradiţionale şi cele geografice, sintetizăm următoarele: tuplu = linie (sau rând), atribut =
coloană (câmp).

În sistemul de baze de date relaţional, nu există o ierarhie şi nici chei specifice care să
facă trimitere la diferite înregistrări. Toate câmpurile dintr-o linie pot fi privite ca fiind
permanent conectate între ele, dar tabelele individuale nu conţin nici o altă informaţie
despre alte tabele. Cu toate acestea, orice câmp dintr-un tabel poate reprezenta o cheie
pentru accesarea datelor din alt tabel. Sistemul permite ca toate rândurile şi coloanele să
fie corelate între ele. Aceasta înseamnă că o colecţie de date a mai multor obiecte cu
relaţii complexe poate rezulta într-un număr mare de tabele – un neajuns al abordării
relaţionale.
Aşa cum am precizat fiecare coloană descrie un anumit atribut. În cadrul unei
relaţii cel puţin un atribut trebuie să aibă o valoare unică pentru fiecare tuplu. Acest
atribut se numeşte cheie primară. Ea identifică un tuplu şi alte atribute care sunt
dependente de acesta şi nu trebuie să aibă o valoare nulă. Stabilirea relaţiilor este
importantă pe tot parcursul proiectării bazei de date dar şi pe parcursul implementării de
aplicaţii. Acest lucru înlătură redundanţa şi păstrează consistenţa BD atunci când se fac
modificări. Pentru tabela de atribut a unui strat tematic BDR este ideală. În fig. 8 avem
două tabele corelate. Problemele apar la entităţile spaţiale şi la relaţiile dintre ele, aşa cum
vom vedea mai jos.

Figura 8 (adapatare după Bernhardsen, 1992)

Stocarea datelor nespaţiale într-o BD relaţională. Fiecare câmp dintr-un tabel poate fi o cheie
pentru localizarea datelor în alt tabel

Spre deosebire de modelul ierarhic şi cel reticular nu există pointeri în tabelele de date.
Tabelele index interne sunt folosite pentru direcţionarea comunicaţiilor intertabelare, ceea
ce înseamnă că sistemul trebuie să deschidă cel puţin un tabel de indecşi pentru fiecare
conexiune între tabele de date. Aceasta poate duce la apariţia unui număr mare de tabele
şi poate îngreuna accesul. Mai mult, căutările pentru înregistrări sau câmpuri trebuie să
fie secvenţiale în tabele. Rezultatul este că sistemele de baze de date relaţionale sunt
inerent mai încete decât sistemele de baze de date ierarhice sau de tip reţea. Acest lucru
este compensat de performanţele hardware.

17
Figura 9 (adapatare după Bernhardsen, 1992)
Stocarea datelor spaţiale într-o BD relaţională

Totuşi, un câmp poate fi rapid localizat într-un tabel dat şi datele accesate pot fi
manipulate. Structurile simple ale sistemelor de baze de date relaţionale au permis
dezvoltarea limbajelor de interogare standard, unul din aceste limbaje fiind SQL
(Standard Query Language).
SGBD-urile relaţionale sunt, în prezent, tipul cel mai folosit în aplicaţiile GIS,
mai ales datorită structurilor sale simple şi flexibile. Un alt motiv este acela că susţin
relaţiile complexe, des întâlnite în cadrul obiectelor geografice din lumea reală. Intrările
multiple sunt mai puţin frecvente decât în sistemele de baze de date ierarhice sau de tip
reţea, cu toate că timpul de căutare este, de obicei, mai îndelungat. Acest lucru este mai
ales întâlnit în operaţii specifice pe date geografice digitale, de exemplu atunci când se
formează poligoane sau când folosim plasarea automată a textului.

6. Baze de date relaţionale extinse. Conceptele de modelare prezentate sunt adecvate, în

principal, pentru BD tradiţionale. În ceea ce priveşte structurile de date geografice, aşa
cum am văzut, întâmpină anumite dificultăţi, în special pentru date spaţiale. Cele mai
multe implementări ale datelor geografice sunt structuri vectoriale topologice asociate cu
tabele relaţionale care conţin coordonatele punctelor, a segmentelor de linii sau a
poligoanelor, împreună cu tabele care conţin informaţia topologică. De asemenea, aşa
cum am precizat mai sus, atributele pot fi stocate în acelaşi tabel cu datele spaţiale sau în
tabele separate, care sunt legate intrinsec de cele spaţiale. De asemenea dezvoltarea şi a
altor produse care manipulează date grafice, cum ar fi CAD, sau alte aplicaţii cum ar fi
multimedia şi beineînţeles GIS, a dus la o extindere a BDR deoarece cerinţele privind BD
care conţin structuri grafice sunt mai stricte decât pentru cele tradiţionale. Aceasta a
stimulat necesitatea dezvoltării de concepte adiţionale de modelare semnatică. Astfel au

18
fost propuse mai multe modele de date semantice diferite care să poată gestiona mai
eficient noile structuri dar să păstreze totodată şi proprietăţile relaţionare. Dintre acestea
vom prezenta modelul entitate – relaţie (ER) şi modelul entitate – relaţie extins (EER).
Menţionăm faptul că aceste modele au un grad de abstractizare şi dificultate mai ridicat.

6.1 Modelul entitate - relaţie

Modelul Entitate-Relaţie (ER) este un model de date conceptual de nivel înalt, dezvoltat
de Chen (1976) pentru a facilita proiectarea BD. Un model de date conceptual este
constituit dintr-un set de concepte care descriu structura unei BD şi tranzacţiile de
regăsire şi reactualizare asocialte (Connolly ş.a., 2001). Scopul principal al realizării unui
model de date de nivel înalt este de a asigura perceperea datelor de către utilizator şi de a
ascunde aspectele tehnice de proiectare. Mai mult, un model de date conceptual este
independent de tipul particular de SGBD şi de platforma hardware.
Conceptul de bază al modelului ER este tipul de entitate care reprezintă un set de
« obiecte » din « lumea reală » cu aceleaşi proprietăţi. Ca exemplu putem da o conductă
de alimentare cu apă, un stâlp, un transformator, un turn etc. Cu alte cuvinte putem spune
că o entitate este o abstracţie care reprezintă o clasă de obiecte similare, care este unic
identificabilă. De remarcat faptul că nu există tocmai o definiţie pur formală a acestui
concept, ci o definiţie de conţinut, ceea ce înseamnă că diferiţi proiectanţi pot identifica
entităţi diferite.
Fiecare tip de entitate este identificat printr-un nume şi o listă de proprietăţi. Deşi
un tip de entitate are un set distinct de atribute, fiecare entitate are propriile sale valori
pentru fiecare atribut. De aceea se mai spune că o entitate este o instanţă a unui tip de
entitate, care este unic identificabilă.
Un tip de relaţie conectează mai multe tipuri de entităţi. Proprietăţile particulare a
unei entităţi sunt denumite atribute. Fiecărui atribut îi este asociată o mulţime de valori
numită domeniu. Domeniul defineşte valorile potenţiale pe care le poate avea un atribut.
Relaţia poate avea ea însăşi propriul ei tabel de atribut, care este independentă de
orice atribut al entităţilor participante. Modelul ER permite un domeniu limitat de
restricţii privind integritatea. Tipul de relaţii este subdivizat în relaţii : mai multe – la –
mai multe şi unu – la – mai multe.
Avantajul SGBDR extins este că deţine o metodologie riguroasă de proiectare,
toate celelalte structuri de baze de date putând fi reduse la un set de tabele relaţionale,
uşor de utilizat comparativ cu alte SGBD-uri, uşor de modificat (se pot adăuga
înregistrări noi sau tabele noi), flexibil şi oferă o procesare rapidă.

6.2. Modelul entitate - relaţie extins (EER). Deoarece modelul ER are anumite limitări
s-a propus un model extins al acestuia care, aşa cum vom vedea mai departe se apropie de
modelele obiect - relaţionare, care se vor dovedi cele mai eficiente. Modelul EER
presupune construirea de clase, superclase şi categorii, care sunt strâns legate de
operaţiunile de generalizare şi specializare precum şi de mecanismul de moştenire a
atributelor. Acestea permit o descriere a datelor din BD cu mai multă semnificaţie şi
conduce la modelarea orientată obiect.
Supercalsa este un tip de entitate care include subclase distincte, care trebuie să
fie reprezentate într-un model de date. O subclasă este un tip de entitate care are un rol
distinct şi este membru a unei superclase. În unele cazuri, un tip de entitate poate avea

19
mai multe subclase distincte. De exemplu supreclasa poligon poate fi clasificată în
trinunghiuri şi dreptunghiuri. Cu alte cuvinte entitatea Poligon reprezintă o superclasă a
subclaselor trinunghi şi dreptunghi. Fiecare membru a unei subclase este şi un membru a
superclasei corespunzătoare. Sau dacă vreţi, membrul subclasei este acelaşi ca entitatea
superclasă, dar are un rol distinct. Relaţia dintre clasă şi superclasă este de unu-la-unu
(1 :1). Există două motive importante pentru introducerea conceptelor de clasă şi
superclasă în EER. În primul rând se evită scrierea conceptelor similare mai mult decât o
singură dată, ceea ce are ca efect economisirea timpului de proiectare şi face ca diagrama
EER să fie mai lizibilă. Un al doilea motiv este că în faza de proiectare se adaugă mai
multe informaţii semanatice, într-o formă accesibilă mai multor utilizatori. Operaţiunea
de formare a subclaselor din superclasă este numită specializare, iar operaţiunea de
formare a superclasei din subclasă se numeşte generalizare. Cele două operaţiuni sunt
inverse. Cu alte cuvinte specializarea este procesul de creare a unei noi clase astfel că
fiecare apariţie a subclasei este o apariţie a superclasei şi subclasa are aceleaşi atribute ca
şi superclasa şi câteva în plus. Subclasa intră în aceleaşi relaţii în care este implicată
superclasa şi eventual în alte relaţii. Întreaga colecţie de superclase şi subclase într-un
model particular EER se numeşte ierarhie. Proprietăţile superclasei sunt transmise
subclaselor din ierarhie. Acest proces se numeşte moştenire.
O problemă tehnică privind generalizarea poate apărea atunci când realizăm
această operaţiune pornind de la tipuri de entităţi eterogene. Dificultatea poate proveni
din a găsi un set de identificatori ale atributelor pentru clasa generală, deoarece subclasele
pot să aibă identificatori diferiţi. Aceste considerţii conduc la conceptul de categorizare,
în care mai multe entităţi eterogene (care au propri lor identificatori şi relaţii) se combină
într-o categorie comună (Elmasri, Narathe, 1994). Categorizarea adaugă o putere
considerabilă procesului de modelare.

7. Baze de date orientate spre obiecte

Odată înţelese noţiunile prezentate la ER şi EER, bazele de date orientate obiect (BDOO)
sunt mai accesibile. Pentru înţelegerea în profunzime a acestui tip de BD, precum şi cele
ce urmează se recomandă parcurgerea paragrafului aferent noţiunii de obiect. Cele mai
importante avantaje, des citate în favoarea orientării spre obiecte sunt (Connolly ş.a.,
2001) :
-definiţia unui sistem prin intermediul obiectelor facilitează construcţia de
componenete software care seamănă îndeaproate cu domeniul de aplicaţie;
-datorită încapsulării şi ascunderii informaţiilor se încurajează proiectarea
modulară – implementarea unui obiect nu depinde de structura internă a altuia, ci doar de
modul în care acesta răspunde la mesaje;
-întrebuinţarea claselor şi a moştenirii promovează dezvoltarea de componente
reutilizabile şi extensibile în construcţia de noi sisteme sau pentru actualizarea celor
existente.
Cu toate că piaţa sistemelor SGBDOO este încă mică, ele continuă să găsească
noi domenii de aplicaţii, cum ar fi WWW.

În cele ce urmează vom da câteva definiţii importante (Connolly ş.a., 2001). Un model de
date orientat pe obiecte (MDOO) este un model (logic) de date care conţine semantica
obiectelor, acceptată în programarea orientată spre obiecte (POO). O bază de date

20
orientată spre obiecte (BDOO) este o colecţie de obiecte persistente şi partajabile care
sunt definite de MDOO. SGBDOO este administratorul unei BDOO. Aceste definiţii nu
sunt deloc descriptive şi tind să reflecte faptul că nu există nici un model de date orientat
spre obiecte echivalent modelului de date relaţional. Fiecare sistem asigură interpretarea
lui proprie a funcţionalităţii de bază. De exemplu, Zdonik şi Maier (citat de Connolly,
2001) prezintă un minim de condiţii pe care trebuie să-l satisfacă un SGBDOO :
-trebuie să asigure funcţionalitatea bazei de date;
-trebuie să accepte identitatea obiectelor;
-trebuie să asigure încapsularea;
-trebuie să accepte obiecte cu stare complexă.
Autorii afirmă că, moştenirea poate fi utilă însă nu este esenţială în definirea SGBDOO.

Pe de altă parte Khoshafian şi Abnous (1990) definesc un SGBDOO astfel :

-orientarea spre obiecte = tipuri de date abstracte (ADT) + moştenire+identitatea
obiectelor;
-SGBDOO = orintarea spre obiecte + capacităţi de baze de date

Deoarece SGBDOO nu sunt prezente în softurile GIS ne vom opri aici cu detaliile. Mult
mai importante şi de actualitate sunt SGBD obiect – relaţinonale.

8. Baze de date relaţionale şi orientate spre obiecte

Mulţi dezvoltatori de SGBDR au realizat faptul că că SGBDOO prezintă deficienţe
pentru anumite genuri de aplicaţii, între care şi GIS. Orecum şi pentru evitarea unei
concurenţe directe, dar şi conştienţi de avantajele oferite de programarea obiectuală,
aceştia au oferit, în cadrul BDR şi facilităţi obiectuale. Astfel au apărut ceea ce se numesc
SGBD obiect – relaţinonale (SGBDOR). Reprezentând un hibrid între SGBDR şi
SGBDOO, conceptul SGBDOR păstrează bogăţia de cunoştinţe şi exeperienţa SGBDR la
care au adăugat şi facilităţile obiectuale (identitatea obiectelor, încapsularea, moştenirea,
polimorfismul, legarea dinamică a metodelor).

Încă de la începutul anului 2001 trei producători de SGBD au lansat pe piaţă extensii
pentru BD spaţiale la SGBDR proprii: IBM DB2 Spatial Extender, Informix Spatial
Datatable şi Oracle Spatial Option. Deşi sunt diferite din punct de vedere al tehnologiilor,
el oferă stocarea, interogarea şi managementul obiectelor geografice. Trebuie remarcat
faptul că niciunul dintre ele nu este soft GIS propriu-zis. Scopul acestor extensii se
rezumă doar la stocarea datelor spaţiale şi nespaţiale, regăsirea şi managementul lor,
neavând însă posibilitatea pentru editări şi analiză spaţială. De aceea ele se folosesc
împreună cu softurile GIS. În fig. YYY am înfăţişat modul în care lucrează GIS împreună
cu SGBD.

8.1. Stocarea datelor în tabele

Nivelul de bază (cel mai de jos) al interacţiunii utilizatorului cu baza de date geografică
este clasa de obiecte (numită şi un strat), care este o colecţie organizată de date axată pe o
temă particulară (ex: reţeaua hidrografică sau toate punctele de elevaţie dintr-un model

21
digital de elevaţie). Clasele de obiecte sunt stocate în tabele bază de date. Un tabel este o
structură bidimensională care conţine înregistrări (rânduri) şi coloane. Fiecare clasă de
obiecte este stocată într-un singur tabel în cadrul BD gestionată de un SGBD. Rândurile
(înregistrările) conţin obiectele (instanţe ale clasei de obiecte), iar coloanele conţin
proprietăţile obiectelor sau atributele (fig de mai jos).

AICI PUN O FIG cu tabeliul unui Feature Class Comentariu XXX

Data determinată de intersecţia unui rând cu o coloană se mai numeşte valoare. Tabelele
baze de date geografice se deosebesc de tabelele ne-geografice prin prezenţa unei coloane
geometrice (numită adesea coloana shape). Pentru a economisi spaţiu şi pentru a
îmbunătăţi performanţele, valorile coordonatelor pot fi stocate într-un format binar
compactat obiectual, astfel că acestea nu pot fi citite direct, ca şi alte tipuri de date cum ar
fi cele numerice (întregi, reale) alfanumerice (text) sau de tip dată. Ideea principală este
că un tabel relaţionar conţine o coloană de obiecte. Accesul la obiecte se face prin
interfaţă obiectuală.
Bazele de date relaţionale se compun din tabele. Fiecare clasă de obiecte
geografice este stocată ca un tabel.

Există însă situaţii când unele câmpuri se repetă, cum ar fi de ex: o clădire are mai multe
apartamente, o parcelă are mai mulţi proprietari. În această situaţie, pentru a elimina
redundanţa (repetarea unor înregistrări) se reorganizează tabelul principal (astfel încât să
avem doar o singură înregistrare pentru clădire) şi se generează un alt tabel care poate fi
asociat cu acesta (apartamentele). Aceste două tabele se reunesc în momentul interogării
BD sau a unor prelucrări (relate).

9. Baze de date deductive. Pe lângă SGBD-urile prezentate, mai există şi alte tipuri,
dintre care menţionăm SGBD deductive, care nu sunt încă implementate în software GIS
comerciale. O BD deductivă se bazează pe limbaje logice cum ar fi Prolog. Programarea
logică constă în două părţi : un sistem de programare logic, care reprezintă cunoştinţe
declarative şi un mecanism de deducere folosit pentru a răspunde interogărilor ce se
bazează pe acele cunoştinţe. O interogare pe un model de BDR poate fi văzut ca o
expresie a unui set de de stări. O BD deductivă include nu numai un set de stări ci şi
propoziţii. Stocarea propoziţiilor produce o evitare a stocării de date. De asemenea o BD
deductivă permite să se facă deduceri din date. Utilizarea logicii oferă o metodă naturală

22
şi intuitivă de generare precisă a unor definiţii ale geometriei şi un înalt nivel de relaţii
spaţiale (Worboys, 1995).
Utilizarea logicii în proiectare nu este nouă. Dintre aplicaţii posibile amintim pe
cele privind structuri gramaticale şi sistemele bazate pe raţionament (Chase, 1989;
Damski, Gero, 1996; Heisserman; Krishnamurti, 1992). Implementărea formelor
gramaticale au anumite limitări datorate problemelor computaţionale. În alte aplicaţii
cum ar fi cele privind proiectarea obiectelor, apar anumite neajunsuri deoarece cu
anumite excepţii, acestea nu suportă reiteraţii. Formalismul algebric ale geometriei (map
algebra) este extins prin utilizarea logicii pentru a-l face mai precis, mai general, fiind
posibile generarea definiţiilor parametrice ale geometriei şi ale relaţiilor spaţiale.
BD deductivă poate fi privită, într-un fel, ca şi ca o generalizare a BDR. Ea
conţine o extensie (similară cu BDR clasice) şi o intensiune (intension). Intensiunea
constă în relaţii virtuale care sunt definite în termenii altor relaţii, utilizând logica.
Important este faptul că avem relaţii care sunt definite, nu prin specificarea tuplelor, ci ca
şi combinaţii logice ale altor relaţii, care în cazul BD deducive se numesc ‘relaţii
virtuale’. Astfel BD deducive permit manipularea datelor implicate prin memorarea
explicită a faptelor / acţiunilor permiţând anumite genuri de operaţiuni care nu se
regăsesc în bazele de date convenţionale. Această abilitate este potenţial relevantă pentru
GIS, în care este stocată multă informaţie în formă explicită.
Utilizarea logicii oferă o metodă naturală şi intuitivă pentru generarea precisă a
definirilor geometriei parametrizate şi un înalt nivel de relaţii spaţiale. Utilizarea lor ca
specificaţii şi instrumente ale programării au devenit destul de răspândite în ultimele două
decade, oferind o serie de avantaje vis à vis de metodele de programare procedurale,
printre care abilitatea de a specifica cunoştinţe care pot fi încapsulate într-un model
(descriptiv) fără a fi necesară specificarea procedurilor de manipulare a datelor. Utilizarea
logicii facilitează metoda top-down, de la abstract la concret. Abstracţiunile simbolice ale
formulărilor logice permite specificarea tuturor claselor din structura de date, ignorându-
se detaliile. Aceasta poate fi o metodă mai naturală de dezvoltare decât dacă avem de-a
face cu formulări neintuitive.
Prin utilizarea deducţiilor se execută calcule şi intetrogări într-o BD deductivă. O
bază de date convenţională constă într-un ansamblu de date într-un format structurat (sub
formă de tabele în cazul BDR) definite şi accesate printr-un limbaj. Cele mai multe GIS
stochează datele în această manieră, fie sub formă de tabele într-o BDR, fie fie într-o
structură spaţializată de baze de date. În contrast cu acestea BD deductivă utilizează
logica ca un fundament pentru definirea bazei de date, interogarea şi manipularea. Ea
manipulează un ansamblu de expresii într-un limbaj bazat pe logică care permit formarea
de propoziţii, descrierea inter-relaţiilor şi managementul (gestiunea) stocării lor. În
acestea se definesc structuri de date care acţionează ca un limbaj de interogare şi un
mecanism de control. BD operează prin aplicarea (acţionarea) deducţiilor în expresii
logice pentru a evalua valoarea de adevăr sau pentru a găsi valori care le satisface.
În proiectarea BD deductivă trebuie să alegem o mare varietate de aserţiuni logice
care urmează a fi implementate. Sistemul logic trebuie să fie suficient de expresiv, să nu
încetinescă accesul la BD prin interogări şi să permită o mare varietate de modele
posibile. Datele trebuie stocate într-un format compact şi flexibil. Informaţia geografică
are o componentă spaţială şi în plus se pretează la aplicarea logicii. În cazul GIS nu sunt
necesare doar reguli deductive bazate pe date tabelare, ci şi reguli complexe bazate pe

23
obiect, adică un sistem care ia ce e bun din orientarea obiectuală, iar baza de date şi
deducerile logice devine un real suport pentru interfaţa grafică interactivă. Tehnologia
BD deductive este o speranţă în rezolvarea unor astfel de probleme. Orientarea obiectuală
şi logica nu sunt exclusive şi există anumite tentative de a le unifica în contextul GIS.

10. Bazele de date Obiect-Deductive. Bazele de date Obiect-Deductive constituie

printre cele mai recente cercetări în managementul bazelor de date spaţiale. Combinaţia
dintre metodologiile O-O şi cele deductive poate oferi o înaltă performanţă sistemului.
Un model baze de date spaţial deductiv şi orientat obiect (Deductive Object Oriented
Spatial Data Base– DOOSDB) a fost propusă, între alţii, de Lu şi Han (1990) în care
obiectele spaţiale complexe suportă o interfaţa de interogări deductive de un înalt nivel.
Un astfel de DOOSDB este potrivit pentru aplicaţii spaţiale cum ar fi cele gestionate de
GIS.
Un DOOSDB conţine date spaţiale, date nespaţiale, reguli deductive precum şi
metode complexe din punct de vedere computaţional. El constă în trei componente
majore (Ullman, 1989) : (1) o bază de date geografică (GDB), care stochează entităţile
spaţiale, (2) o bază de date extinsă (EDB) care stochează datele în formă relaţională şi
(3) o bază de date intensională (IDB), care constă în relaţii virtuale definite prin
intermediul regulilor şi rutinelor spaţiale, referite ca metode. Un DOOSDB suportă o BD
spaţială cu o interfaţă de un înalt nivel de interogare. Sintaxa poate fi preluată fie din
SQL, fie dintr-un limbaj cum ar fi Prolog. Pentru o procesare eficientă, regulile deductive
sunt precompilate, funcţiile spaţiale sunt optimizate, iar metodele sunt stocate şi
analizate. Mai mult decât atât sistemul poate analiza şi stoca statistici ale bazelor de date,
metadate, precum şi cunoştinţe, în vederea optimizării interogărilor (Wei Lu, 1993).
Conceptual o bază de date DOO conţine o colecţie persistentă de date spaţiale şi
nespaţiale care aparţin unor clase (şi care la rândul lor sunt organizate în ierarhii) într-o
schemă de BD. Rădăcina este o clasă mai specială de obiecte care conţine metodele
comune tuturor celorlate clase derivate. Fiecare clasă este asociată cu set de atribute
şi/sau reguli deductive, rutine, reguli de moştenire, ierarhii de clase derivate, asocieri
între clase sau valori concrete.
DOO oferă importante facilităţi pentru baze de date spaţiale temporale (Langran,
1992). Indexarea în cazul structurilor spaţio-temporale este o extinderea a indexului
spaţial R-tree, numit TR-tree, care incorporează atât informaţii temporale cât şi cele
spaţiale.

11. SGBD distribuite

Până acum am abordat sistemele de baze de date centralizate, adică sistemele cu o singură bază
de date logică, localizată fizic într-un singur loc şi aflată sub controlul unui singur SGBD. În acest
paragraf ne vom ocupa cu sisteme de baze de date care permit utilizatorilor să acceseze date
stocate în diferite locaţii. Tehnologia sistemelor de gestiune a bazelor de date distribuite
(SGBDD) constituie una dintre realizările majore în domeniul sistemelor de baze de date.
O motivaţie importantă a apariţiei sistemelor de baze de date distribuite este
necesitatea de a integra datele operaţionale ale unei organizaţii şi de a furniza un acces
controlat la aceasta. Dezvoltarea de reţele de calculatoare promovează un astfel de mod
de lucru.
Toate noţiunile (conceptele) prezentate la sistemele centralizate se regăsesc şi în
sistemele distribuite, la care se adaugă câteva noi.

24
 O bază de date distribuită este o colecţie intercolerată logic de date partajate (şi o
descriere a acestora), distribuite din punct de vedere fizic pe o reţea de calculatoare
(Connolly ş.a., 2001). Un SGBD distribuit este sistemul software care permite
gestionarea BD distribuite şi face ca distribuirea să fie transparentă pentru utilizator
(Connolly ş.a., 2001).
O bază de date ditribuită (BDD) este formată dintr-o singuă bază de date logică,
divizată într-un număr de fragmente. Fiecare fragment este stocat pe unul sau mai multe
calculatoare, sub controlul unui SGBD separat, cu calculatoare legate printr-o reţea de
comunicaţii. Fiecare sit este capabil să prelucreze independent cererile utilizatorilor care
necesită accesul la date locale şi de asemenea este capabil să prelucreze datele stocate pe
alte calculatoare din reţea. Deci fiecare sit are propria sa BD.
Punctul cheie în definirea unei baze de date distribuite constă în faptul că sistemul
este format din date, care sunt distribuite fizic în reţea. Dacă datele sunt centralizate,
chiar dacă alţi utilizatori pot să le acceseze prin reţea, aceasta nu este considerată a fi un
SGBDD, ci o simplă prelucrare distribuită.
Din punct de vedere al utilizatorului, un SGBDD nu se deosebeşte foarte mult de
un SGBD nedistribuit, însă din perspectiva implementării, a protocoalelor şi a
algoritmilor necesari pentru a oferi această funcţionalitate ridică o serie de probleme.
Toate acestea conduc la necesitatea ca distribuţia să fie transparentă faţă de utilizator,
care ascunde detaliile de implemetare faţă de acesta. De exemplu într-un SGBD
centralizat, independenţa de date este o formă de transparenţă, adică ascunde
utilizatorului organizarea BD. Un SGBDD poate prezenta diferite nivele de transparenţă,
dar toate au acelaşi obiectiv : să facă utilizarea BDD echivaelntă cu cea a unei BD
centralizate. Sunt mai multe tipuri de transparenţă, dar ne vom opri doar la unul singur,
anume transparenţa tranzacţiilor. Motivul pentru care facem acest lucru este că
versionarea BD geografice implică înţelegerea acesei noţiuni, după cum vom vedea mai
departe.
Prin transparenţa tranzacţiilor într-un SGBDD se garantează că toate tranzacţiile
distribuite păstrează integritatea şi coerenţa BDD. Printr-o tranzacţie distribuită se
accesează datele stocate în mai mult decât o locaţie. Fiecare tranzacţie este împărţită într-
un număr de subtranzacţii, câte una pentru fiecare sit care este necesar să fie să fie
accesat. Deoarece în majoritatea sistemelor informatice geografice avem doar un sistem
centralizat, nu există subtranzacţie.
Pentru a înţelege mai bine noţiunea de tranzacţie, vom da un exemplu. Să
presupunem că dorim să accesăm de pe calcultorul personal contul dintr-o bancă la care
suntem arondaţi şi dorim ca să transferăm bani din contul curent în contul de depozit. Un
astfel de transfer ţine aproximativ 0,01 secunde. Pe toată durata intervenţei, BD este
blocată până când transferul a fost efectuat. Adică orice altă tranzacţie este amânată până
la deblocare. Dacă dorim să transferărm bani din contul curent într-un cont din altă bancă
tranzacţia ţine mai mult. DB este din nou blocată o perioada scurtă de timp, iar până la
confirmarea transferului de către banca externă, suma tranferată este în « pending », dar
aceesul la BD este posibil.

12. SGBD paralele

Un SGBD paralel este un SGBD rulat pe mai multe procesoare şi discuri, care au fost
proiectate să execute operaţii în paralel ori de câte ori este posibil, pentru a îmbunătăţi

25
performanţele. Raţiunea pentru care au fost dezvoltate astfel de siteme se bazează pe
premisa că sistemele cu un singur procesor nu face faţă prelucrărilor, păstrând totodată şi
o performanţă ridicată. Astfel în sistemele de baze de date paralele se leagă mai multe
maşini mici, pentru a obţine acelaşi transfer ca al unei singure maşini mari, adeseori cu o
scalabilitate şi fiabilitate mai mare. De obicei tehnologia paralelă este utilizată pentru
sistemele care trebuie să prelucreze baze de date foarte mari (de ordinul a teraocteţilor)
sau pentru sistemele care trebuie să prelucreze mii de tranzacţii pe secundă.
Există şi ceea ce se numeşte prelucraere distribuită şi paralelă, care combină cele
două caracteristici. Este cazul sistemelor GRID, care constă din mai multe calculatoare
conectate şi controlate de servere. Aceste calculatoare sunt considerate a fi în « standby »,
adică operaţionale dar care în momnetul trimiterii sarcinilor căre acestea ele sunt
neutilizate de proprietar. Astfel, dacă serverul este soliciat să facă mai multe taskuri, el va
decide care calculator va fi folosit pentru un task specific. Sigur că acesta din urmă
conţine toate componentele soft care să realizeaze sarcina. Serverul va direcţiona
taskurile după nişte reguli bine precizate către calculatoarrelde disponibile în acel
moment.
Vom face deosebire între un SGBDD şi un SGBD paralel. Un SGBD poate fi
numai paralel, numai distribuit, dar poate fi paralel şi distribuit.

26