Sunteți pe pagina 1din 88

BAZE DE DATE

Crearea, gestionarea şi exploatarea bazelor de date


spaţiale

(note de curs)

1
Organizarea datelor. Concepte de bază

Afluxul fără precedent de informaţie de diferite tipuri şi pe diverse canale, necesită strategii
şi instrumente din ce in ce mai complexe pentru stocare, procesare şi, mai ales, interpretare. Din
acest motiv apare nevoia de a transforma informaţia în date şi organizarea acestora într-o asemenea
manieră încât în orice moment să poată fi extrasă informația dorită.
Datele sunt luate din lumea reală prin măsurători şi observaţii. Datele în sine nu au nici un
fel de semnificaţie, nefiind altceva decât o înşiruire de litere şi cifre. Acestea rămân în aceeaşi
stare până în momentul modificării lor de către administratorul bazei de date.
Informaţiile reprezintă date organizate, date care au fost filtrate şi ordonate după anumite
criterii. Pentru a face diferenţa dintre date şi informaţii, Hernandez propune următoarea axiomă:
Datele reprezintă ceea ce se înmagazinează; informaţia reprezintă ceea ce se extrage.

Dorinţa oricărui utilizator este obţinerea de informaţii şi nu manipularea unor date seci. Un
model de date corect alcătuit oferă posibilitatea transformării informaţiilor în date şi a acestora
înapoi în informaţii fără a denatura sensul lor iniţial. Pentru ca datele să poată fi transformate în
informaţie ele trebuie organizate astfel încât să poată fi prelucrate. Pentru a determina în cazul
unei aplicaţii modul de organizare a datelor, trebuie determinate acele caracteristici ale datelor
care permit extragerea esenţei înţelesului lor.

Un model de date reprezintă o mulţime formală şi consistentă de reguli.


Pentru o aplicaţie particulară a unui model de date, numele obiectelor bazei de date împreună
cu proprietăţile lor şi asocierile dintre ele se numeşte schemă.
Un ansamblu de date organizat după anumite criterii reprezintă o colecţie de date.
O colecţie de obiecte care au identitate proprie şi sunt caracterizate de o condiţie de
apartenenţă se numeşte mulţime.
Procesul de definire şi structurare a datelor în colecţii, gruparea lor precum şi stabilirea
elementelor de legătură dintre componentele colecţiei şi între colecţii reprezintă organizarea
datelor.

Evoluţia în timp a metodelor de organizare a datelor e legată de soluţiile tehnice de


înmagazinare a acestora şi cuprinde nivelele:
1. Nivelul I - organizarea datelor în fişiere clasice;
2. Nivelul II - organizarea mixtă în fişiere;
3. Nivelul III - organizarea datelor în bazele de date clasice;
4. Nivelul IV - organizarea datelor în bazele de date relaţionale;
5. Nivelul V - organizarea datelor în baze de date distribuite.

În cadrul acestei evoluții se disting etapele:

Prima etapă în evolutia organizarii si prelucrarii datelor o reprezinta fisierul. Un fisier consta intr-
un ansamblu de inregistrari fizice. In aceasta etapa datele sunt organizate sub forma de fisiere
secventiale stocate pe benzi magnetice (ca suport de memorare). Structura logica si structura fizica sunt
similare, neexistand o diferenta clara intre acestea. Modul de proiectare a datelor este realizat in scopul
de a deservi in principal unei singure aplicatii, aceasta fiind dependenta de date si ca urmare, in cazul
aparitiei unor modificari in structura datelor, acest fapt determina modificari si asupra programului
(aplicatiei).

A doua etapa este marcata de separarea structurii logice de cea fizica, posibila prin independenta
fizica a datelor. Sunt utilizate fisiere secvential-indexate, si cu acces direct, avand ca suport de
2
memorare discul magnetic. Separarea celor doua structuri asigura independenta aplicatiilor atat fata de
echipamentele hardware cat si fata de modul de organizare a fisierelor. Aceasta inseamna ca se pot schimba
dispozitivele de memorare fara a afecta aplicatiile, iar aceasta schimbare afecteaza, eventual, doar
structura fizica a datelor, nu si structura logica. In aceasta etapa apar primele facilitati simple de protectie a
datelor.

Etapa a treia marcheaza aparitia fisierelor integrate. Organizarea datelor sub forma fisierelor
integrate reduce redundanta datelor, fiind posibila utilizarea in comun a celorasi date fizice de catre mai
multe aplicatii. Integrarea fisierelor determina o structura logica care sa corespunda cerintelor tuturor
aplicatiilor. Aceste structuri integrate constituie originea notiunii de model conceptual din cadrul bazelor
de date actuale. El contine descrierea tuturor datelor si a legaturilor dintre ele.

Etapa a patra este etapa bazelor de date propriu-zise. Odata cu utilizarea fisierelor integrate, ce
confera mai multor aplicatii accesul la aceleasi date, a aparut si necesitatea realizarii aplicatiilor
independent de structura logica a datelor. Desprinderea din cadrul aplicatiilor a descrierii structurilor de
date determina crearea modelului extern. Astfel, pe langa independenta fizica a datelor se adauga si
independenta logica, in sensul ca sunt posibile modificari in structura logica a unei baze de date, fara ca
acestea sa afecteze aplicatiile. Tot in aceasta etapa apar tehnici si proceduri speciale pentru protectia si
securitatea datelor, si de asemenea si functia de administrare a bazei de date, iar redundanta datelor este
redusa la minim.

A) Organizarea datelor în fișiere


Fişierul este principalul tip de organizare a datelor o colecţie de date organizate pe criterii
calitative, de prelucrare şi de scop. Fiecare dată este descrisă independent în toate fișierele în care
apare, între fișiere neexistând o relatie definită explicit.
Tehnic, un fişier reprezintă o colecţie de date aflate în asociere ce are o denumire şi care este
reprezentat, de obicei, cu ajutorul unei secvenţe de bytes sub forma celor două vederi:
Vederea logică: reprezintă felul în care utilizatorul vede fişierul;
Vederea fizică: reprezintă felul în care fişierul este stocat în memoria externă a
calculatorului.
Fișierele pot fi organizate secvenţial sau în grupuri.

Un fişier secvenţial este foarte util la prelucrarea înregistrărilor aflate într-o ordine
predefinită pe baza unei chei de căutare.
Înregistrările din cadrul unui astfel de fişier sunt asociate pe baza unor pointeri ce permit
extragerea rapidă a datelor pe baza cheii de căutare. Înregistrările sunt înmagazinate fizic în
ordinea stabilită pe baza cheii de căutare, ceea ce duce la minimizarea numărului de blocuri ce
trebuie accesate, însă este dificil de păstrat această ordine pe măsură ce se fac introduceri sau
ştergeri de înregistrări.
Ştergerile pot fi gestionate cu ajutorul lanţului de pointeri, dar inserările pun probleme dacă
nu există spaţiu în locul în care trebuie plasate înregistrările. În cazul în care spaţiul necesar plasării
unei noi înregistrări este disponibil în locul indicat, înregistrarea poate fi plasată în acel loc, altfel
ea trebuie plasată în alt loc, iar pointerii trebuie reorganizaţi. În această situaţie anumite înregistrări
nu se vor afla în ordinea fizică specificată. Dacă numărul de înregistrări care nu se află în ordinea
fizică specificată este mic, nu vor exista probleme deosebite, dar dacă acest număr creşte prea mult
pointerii trebuie reorganizaţi, ceea ce presupune un mare consum de resurse şi, prin urmare, astfel
de operaţii trebuie efectuate numai atunci când sistemul nu este deloc sau este slab solicitat. Dacă
inserările se fac rar, fişierul poate fi păstrat în ordinea fizică stabilită iniţial, reorganizarea
pointerilor făcându-se la apariţia oricărei noi inserări, caz în care nu mai sunt necesare câmpurile
de pointeri.

3
Dezavantajele sistemelor de prelucrare bazate pe fisiere
 Redundanta si inconsistenta a datelor (cum pot fi actualizate datele din toate fisierele?)
 Dificultati în accesarea datelor (necesitatea unor noi programe de aplicatie?)
 Izolarea datelor (diferite formate, diferite fisiere)
 Imposibilitatea controlului concurentei (utilizatori multipli)
 Probleme de securitate
 Probleme de integritate a datelor (satisfacerea constrângerilor?)
 Definitia datelor este încorporata în programele aplicatie
 Nu exista controlul accesului si manipularii datelor

Separarea şi izolarea datelor


Cu sistemele de fişiere e dificilă o prelucrare a datelor atunci când acestea sunt izolate în
fişiere separate. În acest caz programatorul trebuie să sincronizeze prelucrarea a două sau mai
multe fişiere pentru a se asigura că datele extrase sunt cele corecte. Dificultatea este cu atât mai
mare cu cât datele necesare se află în mai multe fişiere.
Dublarea datelor
Se manifestă prin faptul că aceleaşi date se pot afla în două sau mai multe fişiere în funcţie
de numărul aplicaţiilor sau al utilizatorilor. În această situaţie pot apare o serie de probleme, cum
ar fi:
 creşterea costurilor prin creşterea spaţiului de memorare a datelor;
 apariţia inconsistenţei datelor prin faptul că o anumită dată poate fi memorată în mai multe
locuri; atunci când există mai multe copii ale aceleiaşi date e posibil ca prin actualizarea
unora dintre ele să existe valori diferite ale aceloraşi date (inconsistenţă); inconsistenţa mai
poate apare şi la introducerea greşită a unor date;
 imposibilitatea introducerii unor standarde;
 imposibilitatea aplicării restricţiilor de securitate;
 imposibilitatea menţinerii integrităţii datelor (consistenţă şi validare).

Dependenţa datelor
Structura fizică şi stocarea fişierelor de date şi înregistrărilor sunt definite în codul aplicaţiei.
Aceasta înseamnă că orice modificare efectuată în structura existentă impune scrierea unui
program de tip exe-off (adică un program ce este rulat o singură dată, după care poate fi înlăturat).
Acest program trebuie:
 să deschidă fişierul iniţial pentru a fi citit;
 să creeze un fişier temporar cu noua structură;
 să citească o înregistrare din fişierul iniţial, să transforme datele pentru a le încadra în noua
structură şi să scrie fişierul temporar. Acest lucru trebuie repetat pentru toate înregistrările
din fişierul iniţial;
 să şteargă fişierul iniţial;
 să redenumească fişierul temporar cu numele fişierului iniţial;
 să modifice toate programele ce apelează fişierul iniţial pentru a se conforma noii structuri.
Toate aceste operaţii necesită mult timp şi sunt supuse pericolului de apariţie a erorilor. Dacă
structura unui fişier trebuie modificată, trebuie modificat şi programul care îl foloseşte.

Formate de fişiere incompatibile


Este posibil ca fiecare fişier să fie apelat de către programe diferite. În acest caz se impune
să se scrie un program de transformare a fişierelor într-un format comun astfel încât să se poată
face prelucrarea datelor din mai multe fişiere.

4
Interogarea statică a programelor aplicaţie
În cazul în care apar noi cereri de interogare a datelor aflate în fişiere, trebuie rescrise
programele existente, deoarece, altfel, nu se poate răspunde decât la întrebările existente. În cazul
rescrierii programelor pot apare următoarele deficienţe:
 documentaţie limitată şi dificil de întreţinut;
 afectarea securităţii şi integrităţii datelor;
 refacerea datelor după defectarea sistemului e limitată sau inexistentă;
 accesul la fişiere e restrâns la câte un utilizator odată.

În concluzie, limitările tratării bazate pe fişiere se datorează faptului că definiţia datelor este
încorporată în programele aplicaţie, în loc să fie stocată separat şi independent și faptului că nu
există control al accesului şi manipulării datelor, în afara celui impus de către programele aplicaţie.

B) Organizarea datelor în bazelor de date


O bază de date reprezintă o colecţie integrată şi structurată de date operaţionale înmagazinate
pe un mediu de stocare. Scopul unei baze de date este acela de a înmagazina datele în aşa fel încât
să se poată obţine informaţia dorită în orice moment.

Organizarea datelor in baze de date constituie o forma de centralizare a acestora si prezinta


o serie de avantaje cum ar fi:
 reducerea redundantei datelor memorate;
 evitarea inconsistentei datelor memorate;
 posibilitatea partajarii datelor de catre mai multe aplicatii;
 introducerea standardelor impuse;
 posibilitatea aplicarii restrictiilor de securitate pentru fiecare tip de acces la date, pentru
fiecare data si la nivel de utilizator;
 mentinerea integritatii datelor care presupune atat consistenta datelor cat si plauzibilitatea lor,
prin introducerea unor proceduri de validare corespunzatoare.

Independenta datelor rezolva problema delimitarii intre reprezentarea fizica a datelor si


imaginea pe care o are utilizatorul asupra acestor date. Acesta inseamna ca modul de memorare si
organizare a datelor este transparent pentru utilizator. Astfel, utilizatorul trebuie sa fie preocupat doar
de problema pe care o are de rezolvat, detaliile de implementare nefiind esentiale pentru el, acestea
ramanand in sarcina sistemului. Independenta datelor se prezinta sub doua aspecte: independenta fizica a
datelor; independenta logica a datelor.

Independenta fizica a datelor consta in faptul ca modificarile in structura fizica de memorare a


datelor nu trebuie sa afecteze aplicatia si reciproc, modificarile aplicatiei nu trebuie sa determine
modificari ale structurii fizice a datelor. Din punctul de vedere al aplicatiei, datele trebuie privite ca entitati
cu nume, orice referire la ele din cadrul aplicatiei facandu-se prin aceste nume. Ramane la latitudinea
sistemului si a administratorului bazei de date modul optim de organizare a datelor si politicile de acces.

Independenta logica a datelor se refera la posibilitatea de a face modificari in structura logica a bazei
de date; este strans legata de problema adaugarii de noi entitati logice (fie ele campuri sau inregistrari)
la structura bazei de date si de modificarea relatiilor existente intre ele. In acest sens este posibila
dezvoltarea bazei de date prin definirea de noi campuri sau inregistrari si adaugarea de date. Singura
problema nerezolvabila este eliminarea de entitati din baza de date, aceasta avand repercursiuni
asupra utilizatorilor care fac referire la acea entitate eliminata. Prin independenta logica a datelor se
urmareste ca pentru fiecare utilizator se sa creeze impresia ca el este singurul beneficiar al unor date pe care,
in realitate, le foloseste in comun cu alti utilizatori. Independenta logica a datelor este mult mai greu de
realizat decat cea fizica, depinzand in mare masura de modelul de date folosit (ierarhic, retea, relational).

5
Domenii de utilizare a bazelor de date:
 Tranzactii bancare
 Linii aeriene: rezervari, planificari
 Universitati: evidenta studentilor, situatia scolara…
 Vânzari: evidenta clienti, produse, cumparari
 Urmarirea productiei: productie, inventar, comenzi, lantul de furnizori
 Resurse umane: înregistrarea angajatilor, salarizare, etc…
 Aplicații GIS
 etc.

Arhitectura unei baze de date


Dacă inițial arhitectura unei baze de date era prevazută
cu două niveluri (schema - abordare d.p.d.v. al
sistemului si subschema - abordare d.p.d.v. al
utilizatorului), asigurarea independentei fizice si logice a
datelor a impus adoptarea unor arhitecturi de baze de date
organizate pe cel putin trei nivele. Scopul a fost separarea
fiecărei vederi a utilizatorilor bazei de date de modul în
care aceasta este reprezentata fizic. Acest fapt
presupune necesitatea unei zone independente de
implementare care sa izoleze programele de
consideratiile de reprezentare de bază.

Nivelul intern (baza de date fizica) reprezintă o


colectie de fisiere care contin datele fizice, la care se
adauga structuri auxiliare menite sa asigure accesul
operativ la aceste date (directoare, indecsi, tabele de
dispersie…). Baza de date fizica este stocata in general pe
discuri magnetice sau optice, iar modul de organizare
este influentat in mare masura de configuratia
echipamentelor hardware si de sistemul de operare.
Schimbarea sistemului de operare sau modificari in
configuratia echipamentelor hardware pot atrage modificari ale bazei de date fizice. Daca este satisfacuta
conditia de independenta fizica a datelor, aceste modificari nu ar trebui sa afecteze nivelele superioare
nivelului intern.

Nivelul conceptual (modelul conceptual, schema conceptuala) este o abstractizare a unei parti
din lumea reala, si descrie structura logica a datelor (ce date sunt stocate într-o baza de date si
relatiile dintre acestea, prin specificarea unor constrângeri). Acesta realizează independenta fizică
a datelor.
Modelul conceptual specifica ce anume poate face parte din baza de date, respectiv ceea ce nu poate
face parte. Acest lucru este realizabil prin specificarea unor constrangeri explicite. Constrangerile se refera
la restrictii asupra valorilor pe care le pot lua datele si sunt declarate in descrierea modelului conceptual.
Daca o operatie de actualizare conduce la violarea vreunei constrangeri, atunci executia acesteia este oprita.
Prin modelul conceptual este realizata independenta fizica a datelor. Modelului conceptual i se
asociaza o transformare care defineste modul in care structura logica de date este transpusa in structura
fizica de memorare.

Nivelul extern (modelul extern, subschema, imaginea bazei de date) reprezintă vederea
utilizatorului asupra bazei de date. Descrie acea parte a bazei de date care este relevanta pentru
fiecare utilizator. Acest nivel cuprinde unitati logice din modelul conceptual si unitati logice care
6
nu exista in modelul conceptual si care nu au corespondent direct in baza de date fizica - unitati
logice virtuale. Acest nivel asigură independenta logica a datelor. Fiecarui utilizator îi corespunde
un model extern propriu, individualizat in raport cu cerintele specifice. Termenul folosit pentru
modelul extern este vedere.
Utilizarea acestora asigura securitatea bazei de date prin limitarea accesului la date a anumitor
categorii de utilizatori, pe de alta parte un utilizator poate avea drepturi de acces diferite in cadrul mai
multor vederi. O alta functie a vederilor este aceea ca fiind individualizate si oferind o forma simplificata
asupra bazei de date, ele ascund utilizatorului acele parti din descrierea bazei de date care nu-l intereseaza
pe acesta.
Prin modelul extern se realizeaza independenta logica a datelor. Fiecare vedere are ca si
corespondent a descriere a unitatilor logice din modelul conceptual. Aceasta descriere defineste
transformarile prin care structura logica de la nivelul conceptual devine model extern.

Avantajele utilizarii bazelor de date


 Memorarea convenabila si eficienta a datelor si posibilitatea generarii de informatii din
volume mari de date
 Eficienta si scalabilitate în ceea ce priveste accesul la date si regasirea acestora
 Independenta datelor
 Redundanta controlata
 Posibilitatea de a asigura integritatea si securitatea datelor
 Facilitati de acces concurent asupra datelor si posibilitatea recuperarii acestora în cazul
unui defect
 Încurajarea introducerii standardelor
 Administrarea uniforma a datelor
 Analiza datelor ( tehnici OLAP si Data Mining)

Diferenţa dintre conceptul de fişier şi cel de bază de date este reprezentată în figurile
următoare:

7
Date fişier 1 Rezultat 1
Aplicaţie 1

Date fişier 1

Aplicaţie 2 Rezultat 2
Date fişier 1

Fişiere: dependenţa aplicaţie/date

Date fişier 1 Rezultat 1


Aplicaţie 1

Date fişier 1 SGBD

Aplicaţie 2 Rezultat 2
Date fişier 1

Baze de date: independenţa aplicaţie/date

Scurt istoric al organizarii si prelucrarii datelor


 Sisteme traditionale bazate pe fisiere (1950-1960)
 SGBD bazate pe modelul de date ierarhic sau retea (1970)
 SGBD relationale
o Aparitia modelului relational (1970)
o Dezvoltarea SGBD relationale (1970)
o Aparitia SGBDR comerciale (1980)
o Maturizarea tehnolohgiei relationale pentru SGBD (1990)
 Sisteme de baze de date obiect-relationale
o Sisteme de baze de date deductive si sisteme de baze de date orientate
obiect.
 Sisteme de baze de date orientate spre aplicatii
o Baze de date spatiale, temporale, multimedia, Web...
o Sisteme de depozitare a datelor (Data warehousing), sisteme de analiza a
datelor si sisteme de explorare a datelor (data mining)

Sisteme de gestiune a bazelor de date (SGBD)

Un SGBD se constituie ca un intreg ansamblu software care trateaza toate cererile de acces ale
utilizatorilor la baza de date. El actioneaza ca o interfata care permite crearea, actualizarea si
consultarea bazei de date.

O cerere de acces la baza de date este formulata de catre utilizator, este interceptata de catre SGBD si
interpretata de catre o componenta a acestuia (LMD - limbaj de manipulare a datelor), rezultand o
reprezentare in format intern a interogarii. In continuare interogarea parcurge o serie de etape
8
succesive de prelucrare, rezulta o serie de comenzi de acces la fisierele fizice din baza de date. Cererile
de acces la fisierele fizice, rezultate din transformarea interogarii, sunt prelucrate si rezolvate de catre un
sistem de gestiune al fisierelor. Datele extrase din fisierele fizice, sub forma unor siruri de biti, parcurg apoi
calea inversa, rezultatul fiind un raspuns formulat sub forma de tabele, rapoarte, etc.

Din punct de vedere conceptual, gestiunea bazelor de date se bazează pe ideea separării
structurii bazei de date de conţinutul acesteia.

Structura bazei de date reprezintă o colecţie de descrieri statice ale tipurilor de entităţi
împreună cu relaţiile logice stabilite între ele.
Relaţiile logice reprezintă asociaţiile dintre mai multe entităţi.
O entitate este un obiect distinct ce trebuie reprezentat în baza de date.
Un atribut este o proprietate ce descrie un anumit aspect al obiectului ce se înregistrează în
baza de date.
Scopul unui sistem de gestiune al unei baze de date este acela de a oferi un mediu care să fie
şi convenabil, dar şi eficient pentru a putea fi folosit la:
 extragerea informaţiilor din baza de date;
 înmagazinarea datelor în baza de date.
Bazele de date sunt de obicei folosite la gestionarea unei mari cantităţi de date, ceea ce
presupune existenţa următoarelor funcții pentru un SGBD:
 descrierea datelor,
 actualizarea si interogarea bazei de date,
 conversia datelor dintr-un format intr-altul,
 asigurarea controlului integritatii, concurentei si securitatii datelor.

Descrierea datelor
SGBD-ul trebuie sa fie capabil sa defineasca datele prin intermediul unui limbaj specializat DDL
(Description Data Language) intr-o forma unificata numita schema sursa si apoi sa compileze aceasta schema
intr-o forma interna numita schema obiect.

Cele 3 niveluri de descriere a datelor (extern, conceptual si intern) si procedurile de trecere dintr-
unul in altul sunt inregistrate in dictionarul de date, unde informatiile sunt memorate in format sursa si
obiect (compilat). Un dictionar de date organizat sub forma de baza de date se numeste metabaza.

Actualizarea si interogarea bazei de date


In SGBD-uri implementarea functiei de interogare se realizeaza prin intermediul unor limbaje
declarative, care permit cautarea datelor dupa continut, fara a preciza procedurile de acces. Cel mai utilizat
limbaj de interogare a bazelor de date este in momentul de fata SQL (Structured Query Language -
Limbaj Structurat de Interogare).

O interogare se deruleaza in 4 etape: formularea interogarii utilizand limbajul de manipulare


a datelor (DML), compilarea, optimizarea si apoi executia.

SGBD-urile poseda un compilator (analizor) de cereri de interogare, care permite analiza sintactica si
evaluarea iterogarii. Pentru validarea interogarilor este folosit dictionarul de date. Interogarile sunt
descompuse in operatori relationali, pe care ii structureaza sub forma de arbore, in care nodurile
reprezinta operatorii iar elementele de pe ultimul nivel reprezinta relatiile.

O cerere de interogare este apoi optimizata in vederea executiei. Dupa procesul de optimizare,
cererile sunt transformate in tranzactii care vor fi executate, avandu-se in vedere doua aspecte:
 gestiunea tranzactiilor concurente
 executia propriu-zisa.
9
Conversia datelor
Consta in posibilitatile pe care SGBD-ul le ofera pentru trecerea datelor intre cele 3 niveluri: extern,
conceptual si intern. Pentru aceasta SGBD-ul trebuie sa cunoasca corespondentele existente intre niveluri.

Controlul integritatii datelor


SGBD-ul trebuie sa asigure coerenta datelor. Toate regulile implicite sau explicite care asigura
integritatea datelor se numesc restrictii de integritate. Dintre acestea amintim: integritatea cheii
primare, integritatea referirii si integritatea de domeniu.

Securitatea datelor
Un SGBD trebuie sa garanteze securitatea datelor. Acest lucru se realizeaza printr-un mecanism de
control al drepturilor de acces la date si de restaurare a bazei de date in caz de erori.

Orice sistem de gestiune al bazelor de date oferă facilitati de descriere a datelor prin
intermediul limbajului de descriere a datelor(DDL) și facilitati de manipulare a datelor prin
limbajul de manipulare a datelor (DML).

Limbajul de definire a datelor (Data Definition Language - DDL)


Cu ajutorul acestui limbaj se specifică tipurile de date şi structurile precum şi constrângerile
asupra datelor. Instrucţiunile limbajului sunt compilate şi transformate într-un set de tabele
înmagazinate într-un fişier special numit dicţionar de date sau catalogul sistemului (descrierea
datelor se întâlneşte sub denumirile de catalog de sistem, dicţionar de date sau meta-date ceea ce
înseamnă date despre date). Structura de înmagazinare a datelor precum şi metodele de acces
utilizate de sistemul bazei de date sunt specificate cu ajutorul unui set de definiţii folosit cu scopul
ascunderii detaliilor de implementare a schemelor bazei de date

Limbajul de manipulare a datelor (Data Manipulation Language - DML)


Acest limbaj este folosit pentru a ajuta utilizatorul să acceseze şi să folosească datele aflate
în baza de date într-un mod interactiv. Cu ajutorul acestui limbaj se pot:
 extrage date din baza de date;
 introduce date în baza de date;
 elimina date din baza de date;

Există doua tipuri de limbaje de manipulare a datelor:


 limbaje procedurale - trateaza bazele de date înregistrare cu înregistrare si specifica cum
se va obtine rezultatul dorit
 limbaje neprocedurale - opereaza asupra unor seturi de înregistrari si descriu numai ce
date vor fi obtinute (SQL)

Un SGBD mai ofera accesul controlat la baza de date, un mecanism de vizualizare, o colectie
de utilitare: editoare de rapoarte, generatoare de aplicatii, programe asistent, module de proiectare,
posibilitati de dezvoltare a unor aplicattii de tip CASE, etc.

Componentele unui sistem de gestiune al bazelor de date pot fi: hardware, software, date,
proceduri, resurse umane

10
Componenta hardware poate fi reprezentată de un singur calculator personal, un singur
calculator mainframe sau o reţea de calculatoare. De obicei, într-o reţea de calculatoare, se aplică
schema client-server, schemă în care programele back-end reprezintă serverul iar cele front-end
reprezintă clienţii.

Componenta software este alcătuită din:


 programele sistemului de gestiune al bazei de date;
 programele aplicaţie scrise de obicei în limbaje de programare de generaţia a III-a (C,
Pascal, Cobol) sau SQL încorporat într-un limbaj de generaţia a III-a;
 sistemul de operare;
 programe de reţea.

Datele acţionează ca o punte de legătură între componentele maşină (hardware şi software)


şi componenta umană. Baza de date conţine atât datele operaţionale (setul de înregistrări pe care
se lucrează) cât şi metadatele. Structura bazei de date este numită schemă.
Procedurile reprezintă instrucţiunile şi regulile aplicate în proiectarea şi utilizarea bazei de
date.
Acestea pot fi:
 deschiderea unei sesiuni de lucru în sistemul de gestiune al bazei de date;
 pornirea sau oprirea sistemului de gestiune al bazei de date;
 utilizarea unui program de aplicaţie sau a unei funcţii a sistemului de gestiune al bazei de
date;
 efectuarea de copii de siguranţă;
 tratarea defecţiunilor hardware şi software;
 modificarea structurii unui tabel, reorganizarea bazei de date, îmbunătăţirea
performanţelor, arhivarea datelor.

Resursele umane sunt reprezentate de:


1. Administratorul de date este responsabil de gestionarea resurselor de date şi proiectarea
conceptual / logică a bazei de date.
2. Administratorul bazei de date este responsabil de realizarea fizică a bazei de date ce
implică proiectarea şi implementarea acesteia. Administratorul bazei de date este o persoană care
are în răspundere controlul centralizat al datelor şi al aplicaţiilor ce folosesc aceste date.
Îndatoririle administratorului bazei de date cuprind:
 defineşte schema bazei de date, ceea ce presupune scrierea unui set de definiţii în limbajul
de definire a datelor care apoi să poată fi compilate de către un compilator DDL şi
transformate într-un set de tabele păstrate în catalogul sistemului;
 defineşte structura de stocare şi a metodele de acces prin scrierea unui set de definiţii
transferate compilatorului;
 modifică schema şi organizarea fizică prin scrierea unui set de definiţii utilizate de către
compilatorul DDL pentru a face modificările cerute în tabele;
 asigură securitatea prin acordarea drepturilor de acces utilizatorilor pe baza unor conturi
de utilizator create în acest scop;
 verifică respectarea constrângerilor de integritate ori de câte ori se introduc date în baza de
date;
 monitorizează toate activităţile utilizatorilor;
 monitorizează creşterea dimensiunilor bazei de date;
 îşi formează o imagine de ansamblu asupra sistemului, urmărind părţile tari şi slabe ale
acestuia;
 asigură controlul concurenţei prin alegerea tipului de blocare ce va fi folosit atunci când
aceleaşi date sunt folosite de mai mulţi utilizatori în acelaşi timp;
 asigură fiabilitatea sistemului în cazul apariţiei unor erori.
11
3. Proiectanţii de baze de date care pot fi:
a) Proiectant de baze de date logice:
 identifică datele (entităţi şi atribute);
 identifică relaţiile dintre date;
 identifică constrângerile;
 identifică regulile ce descriu principalele caracteristici ale datelor;
 implică utilizatori în realizarea modelului de date.
b) Proiectant de baze de date fizice:
 transpune modelul logic într-un set de tabele şi constrângeri;
 selectează structuri de stocare şi metode de acces specific;
 asigură securitatea datelor.
4. Utilizatorii finali care pot fi de următoarele categorii:
 Programatorii de aplicaţii. Aceştia sunt profesioniştii ce interacţionează cu sistemul
folosind instrucţiuni scrise în limbajul de manipulare a datelor pe care le încorporează
în cadrul unor interfeţe create în alte limbaje de programare. Precompilatorul DML
converteşte apelurile scrise în limbajul de manipulare a datelor în proceduri specifice
limbajului gazdă. Compilatorul limbajului gazdă generează apoi codul obiect.
 Utilizatori cu pregătire specială. Aceştia interacţionează cu sistemul fără a scrie
programe, dar ei formulează cereri pentru a extrage date din baza de date cu ajutorul
instrucţiunilor specifice limbajului de manipulare a datelor. Aceste cereri sunt
transmise procesorului de interogare care desparte o instrucţiune specifică limbajului
de manipulare a datelor în instrucţiuni specifice modulului de administrare a bazei de
date.
 Utilizatori specializaţi. Aceştia sunt utilizatori cu pregătire specială care scriu programe
aplicaţie specializate pentru diverse zone de interes (sisteme CAD, sisteme expert etc.).
 Utilizatori obişnuiţi. Aceştia sunt utilizatori care interacţionează cu sistemul folosind
interfeţele create de programatorii de aplicaţii.

Funcţiile sistemelor de gestiune a bazelor de date


1. Stocarea, regăsirea şi reactualizarea datelor.
Este funcţia fundamentală a unui sistem de gestiune a bazelor de date. Sistemul trebuie să
ascundă faţă de utilizatori detaliile privind implementarea fizică internă.
2. Asigurarea unui catalog accesibil utilizatorului
Catalogul sistemului conţine date despre scheme, utilizatori, aplicaţii. Acesta trebuie să
stocheze:
a. denumirile, tipurile şi dimensiunile articolelor de date;
b. denumirile relaţiilor;
c. constrângerile de integritate asupra datelor;
d. numele utilizatorilor autorizaţi care au acces la date;
e. schemele externe, conceptuale, interne precum şi transpunerile lor;
f. statistica utilizării (de exemplu: frecvenţa tranzacţiilor, contorizarea numărului de
accesări ale obiectelor din baza de date).
Utilizarea unui astfel de catalog de sistem asigură o serie de avantaje care sunt
prezentate în continuare:
- contribuie la controlul datelor ca resurse;
- se poate defini în sensul datelor;
- simplifică comunicarea;
- identifică utilizatorii;
- identifică cu uşurinţă redundanţa şi incoerenţa;
- înregistrează modificările din baza de date;
- impactul unei modificări poate fi determinat înainte de implementare;
- îmbunătăţeşte securitatea;

12
- îmbunătăţeşte integritatea;
- monitorizează operaţiile efectuate asupra bazei de date.
3. Asigurarea tranzacţiilor
Tranzacţia reprezintă un set de acţiuni prin care se accesează sau se modifică conţinuturile
bazei de date. Dacă tranzacţia eşuează (nu s-au efectuat toate modificările, sau modificările nu s-
au efectuat în toate cazurile) baza de date devine incoerentă şi, ca urmare, trebuie avut în vedere
un mecanism care să anuleze toate modificările efectuate în cadrul tranzacţiei şi să aducă baza de
date în ultima stare coerentă anterioară începerii tranzacţiei.
4. Asigurarea serviciilor de control concurente
Sistemul de gestiune al bazei de date trebuie să garanteze că nu vor avea loc interferenţe
atunci când mai mulţi utilizatori accesează baza de date.
5. Asigurarea serviciilor de reconstituire
În cazul în care în timpul funcţionării sistemului au avut loc defecţiuni de natură hardware
sau software, acesta trebuie readus într-o stare coerentă.
6. Asigurarea serviciilor de autorizare
În cazul în care în timpul funcţionării utilizatorii încearcă intenţionat sau accidental să
acceseze date pe care nu au dreptul să le prelucreze, sistemul de gestiune al bazei de date trebuie
să intervină.
7. Asigurarea unui suport pentru comunicarea datelor
Utilizatorii trebuie să poată accesa o bază de date centralizată de la locaţii aflate la distanţă.
8. Asigurarea serviciilor de integritate
Integritatea bazei de date se referă la corectitudinea şi coerenţa datelor stocate şi se exprimă
sub forma unor constrângeri care reprezintă regulile de coerenţă pe care baza de date nu are voie
să le încalce.
9. Asigurarea serviciilor pentru promovarea independenţei de date
Independenţa de date este obţinută printr-un mecanism de vedere sau subschemă. Completa
independenţă logică de date este dificil de obţinut. De obicei se pot adăuga entităţi, atribute, relaţii,
dar eliminarea lor nu este întotdeauna posibilă.
10. Asigurarea de servicii utilitare
Serviciile utilitare ajută la administrarea bazei de date. Câteva astfel de exemple sunt
următoarele:
- facilităţi de import;
- facilităţi de monitorizare, pentru urmărirea utilizării;
- programe de analiză statistică;
- facilităţi de reorganizare a indecşilor;
- compactarea şi realocarea spaţiului eliberat prin îndepărtarea unor înregistrări din
dispozitivele de stocare.

Avantajele sistemelor de gestiune a bazelor de date


Avantajele sistemelor de gestiune a bazelor de date faţă de sistemele clasice, cu fişiere sunt
următoarele:

1. Controlul redundanţei datelor


Risipa de spaţiu care se face prin stocarea aceloraşi informaţii în mai multe fişiere este mult
diminuată prin utilizarea bazelor de date, dar nu complet eliminată datorită altor cereri de
îmbunătăţire a performanţelor.
2. Coerenţa datelor
Dacă un articol de date e înmagazinat de mai multe ori trebuie să se garanteze că toate copiile
acestuia vor fi actualizate dacă se reactualizează o valoare a sa (valoarea articolului e aceeaşi
pentru toate copiile sale).
3. Mai multe informaţii de la aceeaşi cantitate de date
Se pot obţine prin integrarea fişierelor ce conţin informaţii diferite despre aceleaşi date.
4. Partajarea datelor
13
Datele pot fi utilizate de către mai mulţi utilizatori în acelaşi timp. De asemenea se pot face
modificări sau adăugiri la baza de date existentă fără a fi necesară definirea repetată a tuturor
cerinţelor referitoare la acestea.
5. Integritatea crescută a datelor
Se referă la validitatea şi coerenţa datelor înmagazinate şi se exprimă prin constrângeri
(reguli de coerenţă). Constrângerile se pot aplica articolelor de date din cadrul unei singure
înregistrări sau relaţiilor dintre înregistrări.
6. Securitatea crescută
Se realizează prin atribuirea unor nume de utilizatori şi parole ce permit identificarea
persoanelor autorizate să folosească baza de date şi impun modalitatea de utilizare a acestor date.
7. Aplicarea standardelor
Se referă la formatul datelor, convenţiile privind denumirile, documentarea, procedurile de
reactualizare, regulile de acces.
8. Reducerea costurilor
Prin realizarea integrării se alocă fonduri centralizat şi nu separat fiecărui departament.
9. Rezolvarea conflictelor
Fiecare utilizator va avea propriile cerinţe ce pot intra în conflict cu ale altora.
Administratorul bazei de date poate lua decizii ce duc la utilizarea optimă a resurselor.
10. Creşterea accesibilităţii datelor şi a capacităţii de răspuns
Se realizează prin intermediul utilizării limbajelor de programare din generaţia a IV-a (ex.
SQL, QBE).
11. Creşterea productivităţii
Prin furnizarea unor funcţii ce permit manipularea fişierelor şi a introducerii limbajelor de
programare din generaţia a IV-a ce reduc mult timpul de programare.
12. Independenţa datelor
Duce la creşterea capacităţii de întreţinere prin faptul că descrierile datelor sunt separate de
aplicaţii.
13. Controlul concurenţei este îmbunătăţit
Se garantează că dacă doi sau mai mulţi utilizatori accesează simultan aceleaşi date nu se
pierd informaţii sau nu se alterează integritatea acestora.
14. Asigurarea salvării de siguranţă şi a refacerii
Prin recuperarea ultimei stări coerente a bazei de date în cazul apariţiei unei defecţiuni hard
sau soft.

Dezavantajele sistemelor de gestiune a bazelor de date


1. Complexitatea
Trebuie avute în vedere o serie de probleme referitoare la date care se manifestă suplimentar
faţă de cazul aplicaţiilor clasice. Se face mai întâi o analiză amănunţită a datelor şi apoi a aplicaţiei
propriu-zise.
2. Dimensiunea
SGBD-urile ocupă mult spaţiu pe disc.
3. Costul
a) sistemelor SGBD;
b) elementelor hard achiziţionate;
c) conversiei aplicaţiilor existente la noul SGBD şi noua configuraţie hard.
4. Performanţa
Este mai redusă în cazul utilizării SGBD-urilor care au un caracter mai general, în locul unei
aplicaţii simple bazată pe fişiere care apelează o singură funcţie.
5. Efectul unei defecţiuni
Este mult mai mare datorită centralizării (o defecţiune minoră afectează toţi utilizatorii).

14
Modele de reprezentare a bazelor de date
Asa cum a fost precizat anterior, datele in sine nu constituie informatie. Pentru a putea fi
utile, ele trebuie organizate intr-un anumit mod. Modelarea datelor urmareste exact acest mod de a
organiza datele astfel incat ele sa reprezinte cat mai fidel situatia reala si sa fie adaptate reprezentarii si
prelucrarii electronice.
Un model este o abstractizare şi o structură ce simbolizează toate caracteristicile entităţilor
esenţiale ce prezintă interes pentru utilizator, o reprezentare şi o reflectare a lumii reale.
Un model de date reprezintă o colecţie integrată de concepte necesare descrierii datelor,
relaţiilor dintre ele, precum şi a constrângerilor asupra datelor (Connolly ş.a. 1998).
Un model de date este alcătuit din trei elemente de bază: entităţi, atribute, relaţii.
O entitate reprezintă un obiect sau concept din lumea reală, cum ar fi de exemplu un student
sau un curs descris în cadrul bazei de date.
Un atribut reprezintă acele caracteristici ce descriu aspecte sau condiţii ale unei entităţi,
cum ar fi de exemplu numele studentului sau situaţia acestuia.
Relaţia stabilită între două sau mai multe entităţi reprezintă o interacţiune între acele entităţi,
cum ar fi de exemplu asocierea dintre un student şi cursul pe care îl urmează.

Funcţiile modelelor sunt:


1. Reprezintă obiecte, evenimente precum şi asocierile dintre acestea.
2. Reprezintă aspecte esenţiale şi inerente, ignorând proprietăţile accidentale.
3. Au în vedere ansamblul entităţilor, atributelor şi relaţiilor dintre acestea.
4. Asigură regulile de bază şi relaţiile ce permit proiectanţilor şi utilizatorilor să comunice corect,
fără ambiguităţi.
Un model de date este alcătuit din următoarele componente:
1. Partea structurală ce reprezintă un set de reguli ce fundamentează baza de date.
2. Partea de manipulare ce defineşte tipurile de operaţii ce se pot efectua în baza de date:
 operaţii utilizate pentru actualizarea sau regăsirea datelor;
 operaţii utilizate pentru modificarea structurii bazei de date.
3. Set de reguli de integritate ce garantează faptul că datele sunt corecte.

Modelul ierarhic
A fost primul model utilizat in bazele de date, avand la baza structura arborescenta, in care nodul
parinte poate avea mai multe noduri copil, in timp ce un nod copil poate avea doar un singur nod parinte.
Acest model se bazeaza pe relatii de tip parinte-copil. Modelul de date ierarhic foloseste doua forme de
structurare a datelor: tipurile de inregistrari (pentru reprezentarea tipurilor de entitati) si legaturile
(pentru reprezentarea relatiilor intre multimi de entitati).

Modelul retea
Modelul retea are la baza structura de tip retea. Acest model este similar cu modelul ierarhic, un nod
parinte putand avea mai multi copii, deosebirea constand in faptul ca un nod copil poate avea mai multi
parinti. Reprezentarea modelului de date retea se realizeaza tot prin intermediul diagramelor de structura,
care se aseamana cu un graf, nodurile fiind inlocuite de tipurile de inregistrare.

Modelul relational
Este modelul conceptual cel mai des folosit de SGBD-uri. Sistemul care permite gestionarea bazelor
de date relationale se numeste sistem de gestiune a bazelor de date relationale - SGBDR.

15
Bazele de date relaționale
O baza de date relationala este alcatuita din mai multe tabele intre care se pot stabili relatii. Un tabel
contine inregistrari (randuri).
O inregistrare este alcatuita din mai multe campuri (coloane sau atribute).
In teoria relationala, intr-un tabel, inregistrarile nu se pot repeta. Liniile sunt identificate prin
valorile atributelor care le compun.
O cheie este un câmp ce are o valoare unică, corespunzătoare fiecărei înregistrări dintr-un
tabel. Sunt mai multe tipuri de chei, fiecare având propriile caracteristici.
Cheia candidat - este un atribut sau un set de atribute ce identifică în mod unic un tuplu
dintr-un tabel. O cheie candidata trebuie sa respecte trei conditii: sa fie unica (unicitatea se refera la
faptul ca o cheie identifica in mod unic o inregistrare), sa nu aiba valori nule (atributele care compun cheia
trebuie sa aiba valori nenule) si sa aiba o compozitie minimala.
Cheia primară - reprezintă una dintre cheile candidat desemnate în cadrul unui tabel. Orice
tabel trebuie să aiba o cheie primară.
O cheie primară trebuie să fie:
1. Stabilă. Valoarea unei chei primare nu trebuie să se modifice sau să devină nulă pe tot
parcursul existenţei unei entităţi (Brooks, 1992). O cheie primară stabilă ajută la păstrarea unui
model stabil (Whitener, 1989). De exemplu, dacă se analizează înregistrarea datelor unui
student, valoarea cheii primare nu trebuie să se modifice în timp, aşa cum se întâmplă cu
valorile din câmpul în care se păstrează vârsta acestuia.
2. Minimală. Cheia primară trebuie să fie alcătuită dintr-un număr minim de câmpuri ce sunt
capabile să asigure unicitatea.
3. Centrată pe date, nu pe informaţii. Nu trebuie să apară grupări de caracteristici în cadrul unei
valori a unei chei ce păstrează meta-informaţii adiţionale, deoarece nu se respectă principiul
atomicităţii atributelor, crescând astfel posibilitatea ca valorile cheii primare să se modifice.
4. Definitivă. În momentul introducerii unei noi înregistrări, trebuie să existe posibilitatea
introducerii unei valori. Cheia primară acţionează ca un mecanism de constrângere
suplimentară a entităţii deoarece nu poate fi introdusă o instanţă a unui tip de entitate dacă
aceasta nu are o valoare permisă în cheia primară.
5. Accesibilă. Oricine doreşte să creeze, citească, sau şteargă o înregistrare trebuie să poată
vizualiza valoarea cheii primare (Whitener, 1989).
Cheie alternativă - este o cheie candidat ce nu a fost desemnată drept cheie primară. Ea
poate deveni cheie primară dacă cheia primară aleasă iniţial nu mai corespunde la un moment dat.
Cheie externă - există doar în situaţia în care se stabilesc două sau mai multe relaţii între
tabelele bazei de date. Un atribut al unui tabel trebuie să existe şi în celălalt tabel legat de primul
printr-o relaţie.

Un astfel de model este simplu deoarece el poate fi descris cu ajutorul unui număr mic de
concepte care se referă la relaţii (structuri de date bidimensionale ce au proprietăţi speciale),
rânduri (datele aflate în cadrul relaţiilor), coloane (câmpurile datelor din rândurile
corespunzătoare) şi chei (mecanismul de identificare şi asociere a rândurilor aflate în unul sau mai
multe tabele).
Modelul relaţional are un suport teoretic foarte solid deoarece se bazează pe teoria
matematică a relațiilor între mulțimi, ceea ce înseamnă faptul că toate operaţiile sunt încheiate
cu succes, iar rezultatele operaţiilor sunt predictibile.
Cele trei componente ale modelului relaţional sunt:
a. componenta de structură a datelor (relaţii cu proprietăţi speciale);
b. componenta de manipulare a datelor (operaţii predefinite prin care tehnologia relaţională
foloseşte un optimizator inteligent pentru a găsi calea de acces la date);
c. componenta de integritate a datelor (reguli necesare protecţiei datelor la efectuarea unor
operaţii incorecte).
16
Principalul avantaj al modelului relaţional este acela că nu este necesară utilizarea atât a
pointerilor cât şi a datelor în cadrul tabelelor, folosind în schimb relaţii pentru a accesa valori
corespondente din mai multe tabele.
O relaţie constă dintr-o asociere între înregistrările aflate în două tabele ce au aceleaşi valori
ale atributelor. Deoarece tabelele relaţionale nu conţin pointeri, datele aflate în astfel de tabele
sunt independente de metodele folosite de către sistemul de gestiune al datelor în lucrul cu
înregistrările tabelelor.
Modelul de date relaţional foloseşte tabele bidimensionale ce reprezintă entităţile şi constă
din rânduri şi coloane. O coloană reprezintă un atribut al unei entităţi ce mai poartă şi denumirea
de câmp sau proprietate. Un rând reprezintă un tuplu care este o instanţă a unui tip de entitate sau
de relaţie sau orice altceva din baza de date. De obicei una dintre coloanele tabelului este numită
cheie primară şi are o valoare unică (Brown, The Relational Model).
Simplitatea modelului bazei de date relaţionale constă din simplitatea conceptelor cu care
operează: structuri simple şi abstracte de date, independenţa fizică de date, cadrul puternic, general
şi realist oferit aplicaţiilor ş.a.m.d.
Modelul relaţional oferă o interfaţă flexibilă ce este prevăzută cu cele mai potrivite
componente necesare oricărui utilizator la toate nivelele, oferind o mare independenţă a datelor
(produsul obţinut este relativ independent de implementarea internă).
Baza de date relaţională constă din unul sau mai multe relaţii sau tabele. Principalele
concepte ale modelului relaţional sunt:
1. Atributul – este o coloană ce are un nume propriu şi unic într-o relaţie (câmp). Fiecare relaţie
conţine o listă de atribute (sau coloane) definite pe un anumit domeniu.
2. Domeniul – reprezintă setul posibil de valori pe care îl poate avea unul sau mai multe atribute.
Utilizatorul poate defini domeniul de definiţie, dar numai în anumite produse îşi poate defini
propriile domenii.
3. Tuplu – un rând din cadrul unei relaţii (înregistrare). Un rând dintr-un tabel reprezintă
asocierea dintre seturile de valori. Fiecare relaţie conţine un set de tupluri (sau rânduri).
4. Intensia – structura unei relaţii împreună cu specificaţiile şi constrângerile de domeniu
aplicate. Se modifică rar.
5. Extensia – starea relaţiei (valorile din cadrul unei relaţii se pot modifica). Reprezintă conţinutul
curent al bazei de date ce corespunde schemei bazei de date şi se modifică frecvent.
6. Gradul – numărul de atribute dintr-o relaţie.
7. Cardinalitatea – numărul de tupluri dintr-o relaţie.
8. Baza de date relaţională – reprezintă o colecţie de relaţii ce pot fi modificate (tabele). O astfel
de colecţie este descrisă sub forma unui set de scheme de relaţii din cadrul bazei de date,
numite scheme relaţionale ale bazei de date. Relaţiile sunt alcătuite din două părţi:
- instanţa – un tabel cu rânduri şi coloane;
- schema – specifică numele relaţiei împreună cu numele şi tipul fiecărei coloane.
Termenul de relaţie este folosit în sensul său matematic acceptat:
Se dă o schemă de relaţie R  r  A1 , ..., An  pe un set de domenii D1 , D2 ..., Dn  . O relaţie
n-ară r reprezintă un subset al produsului cartezian al acestor domenii: D1  D2  ...  Dn .
Proprietăţile unei relaţii sunt:
 relaţiile sunt alcătuite din rânduri şi coloane;
 într-o relaţie nu are importanţă ordinea de apariţie a rândurilor sau coloanelor;
 între tabele nu există o asociere explicită (nici una vizibilă cuiva care accesează datele);
 fiecare înregistrare poate fi identificată în mod unic;
17
 fiecare rând din cadrul unui tabel are acelaşi set de coloane;
 fiecare coloană are un singur tip de dată (nu sunt acceptate redefiniri pentru diferite valori).
Datorită acestor proprietăţi şi a fundamentului matematic, modelul relaţional permite
proiectanţilor concentrarea mai întâi asupra semanticii datelor şi a relaţiilor dintre ele şi abia apoi
asupra implementarii fizice a semanticii respective pentru a se adapta cât mai bine cerinţelor şi
specificaţiilor impuse.

Avantajele bazelor de date relaţionale:


 Integritate încorporată la mai multe nivele. Integritatea datelor este integrată în cadrul
modelului la nivel de câmp pentru a asigura precizia datelor. La nivel de tabel asigură faptul
că o înregistrare nu mai poate fi introdusă încă o dată în baza de date, precum şi detectarea
lipsei valorilor din câmpurile cheie primară. La nivel de relaţie asigură validitatea acestora
între tabele. La nivel logic, asigură acurateţea logică a datelor.
 Independenţa logică şi fizică a datelor de programele aplicaţie: nici modificările efectuate de
către utilizator modelului logic al bazei de date, nici modificările efectuate de către
producătorul bazei de date implementării fizice a acesteia, nu vor afecta programele
aplicaţiilor care utilizează baza de date.
 Garantează consistenţa şi precizia datelor: datele sunt consistente şi precise datorită
multiplelor nivele de integritate ce pot fi introduse în baza de date.
 Extragerea cu uşurinţă a datelor din baza de date. În urma comenzilor introduse de către
utilizator, datele din baza de date pot fi extrase fie dintr-un singur tabel, fie dintr-o multitudine
de tabele asociate prin intermediul relaţiilor, ceea ce oferă posibilitatea prezentării datelor într-
un număr nelimitat de moduri.

Bazele modelului relaţional


Conceptul de bază de date introduce termenul de abstractizare a datelor prin mascarea faţă
de utilizator a detaliilor legate de tehnica de stocare a datelor în calculator. Principalul instrument
folosit la realizarea acestui scop este modelul de date, care este alcătuit dintr-un set de concepte
ce pot fi utilizate la descrierea structurii bazei de date, cum ar fi de exemplu, tipurile de date,
relaţiile şi constrângerile stabilite pentru datele reprezentate.
Există trei tipuri de modele de date: modelul de date conceptual, modelul de date logic şi
modelul de date fizic.
Modelul conceptual
Foloseşte o serie de concepte, cum ar fi entitate, relaţie şi atribut pentru a descrie cât mai
fidel modul în care este percepută de către utilizator realitatea ce urmează a fi reprezentată în
cadrul unei baze de date. Pentru a realiza un model conceptual cât mai corect se folosesc o serie
de instrumente ce ajută în modelare, dintre care cel mai folosit este diagrama entitate-relaţie. De
obicei, proiectarea unui model conceptual respectă următorul algoritm:
Pasul 1. Identificarea tipurilor de entităţi. Constă din identificarea şi documentarea
principalelor tipuri de entităţi din punct de vedere al beneficiarului bazei de date. În acest scop
este necesară citirea cu atenţie a tuturor specificaţiilor şi cerinţelor acestuia, urmată de crearea unei
liste a potenţialelor tipuri de entităţi. Tipurile de entităţi reprezintă obiectele sau conceptele ce
prezintă cel mai mare interes în cadrul sistemului. De obicei, se creează mai multe tipuri de entităţi
decât este necesar, urmând ca ulterior să se recurgă la o rafinare a acestora, eliminându-se unele
dintre ele.
Pasul 2. Eliminarea tipurilor de entităţi duplicat. În primul rând trebuie să se obţină
asigurarea că, într-adevăr, fiecare tip de entitate utilizat reprezintă un tip distinct de entitate şi nu
nume diferite ale aceluiaşi tip de entitate. Este foarte important să nu se cadă în capcana definirii
unui tip de entitate care să reprezinte întregul sistem. De exemplu, la modelarea unei biblioteci,
tipurile de entităţi pot fi cărţile, autorii, cititorii etc., dar în nici un caz nu poate fi definit un tip de
entitate biblioteca deoarece aceasta reprezintă întregul sistem.
18
Pasul 3. Identificarea tipurilor de relaţii. În cadrul acestei etape se recurge la identificarea
şi documentarea celor mai importante tipuri de relaţii ce se pot stabili între tipurile de entităţi
rămase după parcurgerea pasului anterior. În acest scop se examinează fiecare tip de entitate în
parte pentru a putea determina poziţia şi legăturile acesteia în cadrul sistemului. În acelaşi timp se
face o analiză a cardinalităţii şi a participării fiecărui tip de entitate, identificându-se totodată
constrângerile impuse tipurilor de entităţi participante.
Pasul 4. Identificarea şi asocierea atributelor corespunzătoare fiecărui tip de entitate
sau relaţie. În această etapă trebuie obţinută asigurarea că tipurile de entităţi sunt cu adevărat
necesare şi nu sunt atribute ale altor tipuri de entităţi. De exemplu, telefonul poate fi o entitate de
sine stătătoare sau un atribut exprimat sub forma unui număr de telefon atribuit tipului de entitate
Studenţi.
Pasul 5. Stabilirea domeniilor de valori ale atributelor. Se realizează printr-o analiză
amănunţită a situaţiilor ce pot apare, documentându-se fiecare hotărâre luată.
Pasul 6. Stabilirea atributelor cheie candidat şi primară. Dacă în cadrul analizei se
identifică mai multe chei candidat, se stabileşte cheia primară, documentându-se hotărârea luată.
Pasul 7. Specializare/generalizarea tipurilor de entităţi. Aceasta etapă este una opţională
în cadrul modelului relaţional şi are ca efect stabilirea superclaselor, respectiv a subclaselor
tipurilor de entităţi, dacă este cazul.
Pasul 8. Construirea diagramelor entitate-relaţie. Prin parcurgerea acestei etape se
asigură o mai bună înţelegere a realităţii care se modelează.
Pasul 9. Eliminarea tipurilor de relaţii duplicat.
Pasul 10. Revizuirea diagramei entitate-relaţie împreună cu beneficiarul bazei de date.

Modelarea realizată cu ajutorul unei diagrame entitate-relaţie este un proces iterativ. De


obicei, nu există o singură soluţie şi, ca urmare, nici o singură diagramă de acest fel. Din acest
motiv se practică crearea mai multor diagrame entitate-relaţie urmată de rafinarea fiecărei variante
din care se va alege ulterior, împreună cu beneficiarul bazei de date, diagrama optimă. De remarcat
este faptul că, de cele mai multe ori, nu se poate spune că o variantă este mai bună decât alta, dar
unele variante pot oferi soluţii mai bune decât altele.
Implementarea tipurilor de relaţii în cadrul tabelelor
Dându-se o relaţie R care se stabileşte între două tipuri de entităţi E şi F, se impun
următoarele reguli:
 dacă relaţia E-R-F este de tip unu-la-mulţi, cheia primară a relaţiei F se introduce în relaţia E;
 dacă relaţia E-R-F este de tip unu-la-unu, cheia primară a relaţiei E se introduce în relaţia F,
sau cheia primară a relaţiei F se introduce în relaţia E;
 dacă relaţia E-R-F este de tip mulţi-la-mulţi, se creează o nouă relaţie ce conţine cheile primare
atât ale lui E cât şi ale lui F;
 dacă relaţia R are atribute, acestea trebuie transferate în cadrul unei relaţii folosindu-se cheile
externe.

Modelul logic
Acest model foloseşte concepte ce mai pot fi înţelese încă de către utilizator, dar care
presupun reprezentări referitoare la modul în care utilizatorul doreşte să vizualizeze datele. În
continuare tehnicile de înmagazinare a datelor rămân transparente utilizatorului. Proiectul logic al
unei baze de date relaţionale creează şi validează modelul logic de date local. Scopul urmărit este
acela de a construi un model logic de date bazat pe modelul conceptual de date creat anterior, după
care se trece la validarea acestui model cu ajutorul tehnicii normalizării. Un astfel de model
parcurge, de regulă, următorul algoritm:
Pasul 1. Transformarea modelului conceptual local în model logic local de date. În acest
scop se trece la rafinarea modelului conceptual de date local, prin eliminarea caracteristicilor
incomode:
a. eliminarea relaţiilor mulţi-la-mulţi;
b. eliminarea relaţiilor complexe;
19
c. eliminarea relaţiilor recursive;
d. eliminarea relaţiilor ce conţin atribute;
e. revizuirea relaţiilor unu-la-unu.
Pasul 2. Stabilirea relaţiilor corespunzătoare modelului logic de date. În această etapă
se creează şi documentează fiecare relaţie, inclusiv cheile primare şi externe.
Pasul 3. Validarea modelului folosind tehnica normalizării.
Pasul 4. Validarea modelului în cazul folosirii tranzacţiilor. Trebuie să se obţină
asigurarea că modelul de date creat suportă tranzacţiile cerute de către beneficiarul bazei de date.
Pasul 5. Stabilirea constrângerilor de integritate. În acest scop trebuie identificate:
a. datele necesare;
b. integritatea referenţială;
c. constrângerile de domeniu impuse atributelor;
d. constrângerile logice;
e. integritatea entităţii.
Pasul 6. Revizuirea modelului logic local împreună cu beneficiarul bazei de date.
Pasul 7. Construirea şi validarea modelului logic global de date. Scopul acestei etape
este acela de a realiza, pe baza modelelor logice locale de date un singur model logic global ce
poate fi utilizat la reprezentarea realităţii care se modelează.
Pasul 8. Unificarea modelelor logice locale în cadrul unui singur model loc global. Se
urmăresc:
- revederea numelor tipurilor de entităţi şi a cheilor primare;
- revederea numelor relaţiilor;
- aducerea în cadrul unui singur model a tipurilor de entităţi din cadrul modelelor
logice locale;
- introducerea în cadrul modelului logic global a tipurilor de entităţi specifice
fiecărei vederi logice locale;
- aducerea în cadrul unui singur model a tipurilor de relaţii din cadrul modelelor
logice locale;
- căutarea tipurilor de entităţi şi relaţii lipsă;
- verificarea cheilor externe;
- verificarea constrângerilor de integritate;
- crearea modelului logic global de date;
- actualizarea documentaţiei.
Pasul 9. Validarea modelului logic global. Se face prin utilizarea normalizării.
Pasul 10. Prevederea modificărilor ce trebuie efectuate în vederea dezvoltărilor
ulterioare.
Pasul 11. Revizuirea modelului logic global împreună cu beneficiarul bazei de date.

Modelul fizic
Acest tip de model descrie reprezentarea datelor în formatul, modul de acces şi ordinea reală
în care acestea sunt păstrate. Fiecare câmp dintr-un tabel are un anumit tip de dată. Standardul
SQL-92 suportă o varietate foarte largă de tipuri de date dintre care enumerăm:
 char(n) sau character(n): şir de caractere de lungime fixă, stabilită de utilizator;
 varchar(n) sau character varying: şir de caractere de lungime variabilă a cărui lungime maximă
este stabilită de către utilizator;
 int sau integer: tipul întreg a cărui lungime depinde de sistem;
 smallint: tip întreg de dimensiuni mai mici a cărui lungime depinde de sistem;
 numeric(p, d): un număr zecimal a cărui precizie este stabilită de către utilizator, ce constă
dintr-un număr total de cifre (p), dintre care d reprezintă cifrele de la partea zecimală; de
exemplu, numeric(3, 1) permite stocarea numărului 1.22 exact aşa cum apare şi nu în formatul
1.2;
 real sau double precision: numere reale a căror precizie depinde de sistem;
 float(n): număr real a cărui precizie este stabilită de către utilizator (n cifre);
20
 date: tip de dată calendaristică;
 time: exprimă ora unei zile în ore, minute şi secunde.
SQL-92 permite efectuarea de calcule aritmetice şi de comparaţii pe diverse intervale
numerice, folosind operatori de transformare a tipurilor (cast).

Normalizarea bazelor de date. Forme normale


Normalizarea reprezintă proiectul logic al unei baze de date. Principalul obiectiv al unui
proiect logic este dezvoltarea schemelor relaţionale corecte. În acest scop trebuie:
 evitate datele redundante;
 evitate anomaliile de modificare;
 asigurată reprezentarea relaţiilor dintre atribute;
 facilitată verificarea actualizărilor care nu trebuie să forţeze integritatea bazei de date.
Normalizarea este un proces de reducere a redundanţelor şi creştere a stabilităţii unei baze
de date. Existenţa redundanţelor într-o bază de date produce următoarele efecte defavorabile:
 pierdere inutilă de spaţiu;
 scăderea performanţelor de cost;
 apariţia inconsistenţelor;
 imposibilitatea reprezentării datelor.
Normalizarea presupune determinarea locului în care trebuie plasate anumite date în cadrul
tabelelor bazei de date, stabilind totodată relaţiile dintre acestea. Prin cuvântul “normă” se înţelege
respectarea unui standard şi reprezintă setul de condiţii impuse şi cunoscute sub denumirea de
forme normale. Pentru a respecta aceste reguli trebuie identificate condiţiile care trebuie respectate
în scopul evitării încălcării integrităţii datelor impunându-se în acest scop descompunerea
relaţiilor. Denormalizarea este procesul invers, opus normalizării efectuat cu scopul îmbunătăţirii
performanţelor bazei de date.

Normalizarea este, cu alte cuvinte, un proces de descompunere a unui tabel în două sau mai
multe tabele cu scopul eliminării redundanţelor care generează anomalii de actualizare. În timpul
procesului de normalizare, structura tabelelor se testează cu ajutorul formelor normale care impun
regulile de descompunere.

Formele normale sunt proprietăţi sau constrângeri aplicate unei scheme de relaţie cu scopul
de a atinge anumite obiective, cum ar fi reducerea redundanţelor. Există 6 forme normale aplicate
de obicei:
 Prima formă normală (sau FN 1).
 A doua formă normală (sau FN 2).
 A treia formă normală (sau FN 3).
 Forma normală Boyce Codd (sau FNBC).
 A patra formă normală (sau FN 4).
 A cincea formă normală (sau FN 5).

21
Fiecare dintre cele 6 forme normale este mai restrictivă ca predecesoarea sa. Astfel, de
exemplu, o schemă de relaţie aflată în forma normală trei este şi în forma normală doi, aşa cum se
reprezintă în figura de mai jos:

FN 5
FN 1 FN 3 FNBC FN 4
FN 2

Scopul formelor normale este acela de a elimina redundanţele din cadrul relaţiilor prin
descompunerea acestora în două sau mai multe relaţii, fără însă a pierde informaţie, ceea ce
înseamnă faptul că este posibilă, în orice moment, revenirea la relaţia originară doar pe baza
relaţiilor obţinute din descompunere.
Prima formă normală (FN 1) simplifica structura unei relaţii prin obţinerea asigurării că ea
nu conţine date care mai pot fi descompuse sau date generatoare de valori repetitive, ceea ce
înseamnă faptul că nici un atribut nu poate avea o mulţime de valori. Prin acţiunea specifică de
descompunere, atributele ce nu respectă aceste condiţii sunt plasate în relaţii separate, păstrându-
se atribute de legătură care au acelaşi tip de dată şi aceeaşi dimensiune. Fiecare tabel are o cheie
primară. De asemenea, o schemă relaţională R se află în forma normală unu dacă şi numai dacă
fiecare atribut se află la nivel atomic.

Etapele de aducere a unei relaţii în FN1 sunt:


1. se construieşte câte o relaţie pentru fiecare grup repetitiv;
2. în schema fiecărei noi relaţii obţinute la pasul 1 se introduce şi cheia primară a relaţiei
nenormalizate;
3. cheia primară a fiecărei noi relaţii va fi compusă din atributele chei ale relaţiei
nenormalizate, plus unul sau mai multe atribute proprii.

Exemple de atribute care pot fi considerate simple sau compuse (atomice sau neatomice) în
funcţie de circumstanţe şi de obiectivele bazei de date:
 data calendaristică – este un atribut în care apar câmpurile: zi, lună, an;
 adresa – este un atribut în care apar câmpurile: strada, nr, bloc, scara, etaj, apartament,
localitate, judeţ;
 buletin/carte identitate – este un atribut în care apar câmpurile: seria, nr.

O relaţie se află în a doua formă normală (FN2) dacă se află în forma normală FN1 şi fiecare
atribut care nu este cheie este dependent de întreaga cheie primară.
Etapele de aducere a unei relaţii de la FN1 la FN2 sunt:
1. Se identifică posibila cheie primară a relaţiei aflate în FN1;
2. Se identifică toate dependenţele dintre atributele relaţiei, cu excepţia acelora în care sursa
este un atribut component al cheii primare;
3. Se identifică toate dependenţele care au ca sursă un atribut sau subansamblu de atribute
din cheia primară;
4. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul 3 se creează o relaţie care va
avea cheia primară atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care
apar ca destinaţie în dependenţele de la etapa 3.

22
O relaţie se află în forma normală trei(FN 3) dacă şi numai dacă se află în forma normală
doi şi dacă fiecare atribut care nu face parte din cheie (nu participă la o cheie) depinde direct de
aceasta. Prin urmare, a treia regulă de normalizare cere ca toate câmpurile din tabele să fie
independente între ele.
Etapele de aducere a unei relaţii de la FN2 la FN3 sunt:
1. Se identifică toate atributele ce nu fac parte din cheia primara şi care sunt surse ale unor
dependenţe funcţionale (DF);
2. Pentru aceste atribute, se construieşte câte o relaţie în care cheia primară va fi atributul
respectiv, iar celelalte atribute, destinaţiile din DF considerate;
3. Din relaţia de la care s-a pornit se elimină atributele destinaţie din DF identificată la pasul
I, păstrându-se atributele surse.

Exemplu
Fie relaţia nenormalizată (primară) FACTURI
FACTURI

nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
cod_produs
denumire_produs
unitate_de_masura
cantiate
pret_unitar
valoare
valoare_tva
toal_valoare_factura
toal_valoare_tva

Dorim să stabilim o structură de tabele care să permită stocarea informaţiilor conţinute în


document (factură) şi obţinerea unor situaţii sintetice privind evidenţa sumelor facturate pe
produse, pe clineţi, pe anumite perioade de timp.

FACTURI LINII_FACTURI

nr_factura# nr_factura#
data_factura cod_produs#
nume_client denumire_produs
adresa_client unitate_de_masura
banca_client cantiate
nr_cont_client pret_unitar
delegat valoare
toal_valoare_factura valoare_tva
toal_valoare_tva

Relaţia FACTURI adusă în forma normală FN1

23
FACTURI
LINII_FACTURI PRODUSE
nr_factura#
data_factura nr_factura# cod_produs#
nume_client cod_produs# denumire_produs
adresa_client cantiate unitate_de_masura
banca_client pret_unitar
nr_cont_client valoare
delegat valoare_tva
toal_valoare_factura
toal_valoare_tva

Relaţia FACTURI adusă în forma normală FN2

FACTURI PRODUSE
LINII_FACTURI CLIENTI
nr_factura# cod_produs#
data_factura nr_factura# nume_client# denumire_produs
nume_client cod_produs# adresa_client unitate_de_masura
delegat cantiate banca_client
toal_valoare_factura pret_unitar nr_cont_client
toal_valoare_tva

Relaţia FACTURI adusă în forma normală FN3

Această a treia formă normală mai poate suferi o serie de rafinări pentru a putea obţine o
structură performantă de tabele ale bazei de date. De exemplu se observă că „nume_client” este
un câmp în care este înscris un text destul de lung format dintr-o succesiune de litere, semne
speciale (punct, virgulă, cratimă), spaţii, numere. Ordonarea şi regăsirea informaţiilor după astfel
de câmpuri este lentă şi mai greoaie decât după câmpuri numerice. Din acest motiv se poate
introduce un nou atribut „cod_client” care să fie numeric şi care să fie cheia primară de identificare
a pentru fiecare client. O altă observaţie care poate fi făcută în legătură cu tabelele aflate în cea de
a treia formă normală este aceea că „total_valoare_factura” este un câmp care ar trebui să conţină
informaţii sintetice obţinute prin însumarea valorii tuturor ofertelor aflate pe o factură. Este de
preferat ca astfel de câmpuri să fie calculate în rapoarte sau interogări şi să nu fie memorate în
tabelele bazei de date.

FACTURI LINII_FACTURI CLIENTI PRODUSE

nr_factura# nr_factura# cod_client# cod_produs#


data_factura cod_produs# nume_client denumire_produs
delegat cantiate adresa_client unitate_de_masura
cod_client# pret_unitar banca_client
nr_cont_client

24
O relație este în forma normală Boyce-Codd (FNBC) dacă se află în forma
normală trei și fiecare atribut depinde de cheie, de întreaga cheie şi de nimic altceva.
FNBC este o generalizare a formelor normale doi şi trei.
De remarcat este faptul că nu întotdeauna este posibilă descompunerea în FNBC
cu păstrarea dependenţelor.

Forma normală patru(FN4) se bazează pe conceptul de dependenţă multivalorică.


O dependenţă multivalorică apare doar în relaţiile ce au cel puţin trei coloane. Dacă una
dintre coloane are rânduri ale căror valori corespund unei singure valori ale unui rând
dintr-o altă coloană, atunci se spune că a apărut o dependenţă multivalorică. O relaţie
se află în forma normală patru dacă şi numai dacă se află în forma normală Bozce-Codd
şi dacă nu are dependenţe funcţionale multivalorice.

A cincea formă normală(FN5) se bazează pe conceptul de dependenţă de cuplare.


Dependenţa de cuplare este o proprietate ce garantează că nu se generează înregistrări
false la reunirea relaţiilor obţinute prin descompunere.
O relaţie se află în forma normală cinci dacă ea nu poate fi descompusă în alte
relaţii fără a pierde informaţie. Cu alte cuvinte, dacă se adaugă un rând suplimentar unei
relaţii care nu se află în forma normală cinci şi dacă această relaţie se descompune în
alte relaţii, prin refacerea relaţiei iniţiale se obţin înregistrări false.

FNBC, FN4 și FN5 se întâlnesc mai rar în practică. Aceste forme nu sunt
respectate, în general, pentru că beneficiile de eficienţă pe care le aduc nu compensează
costul şi munca de care este nevoie pentru a le respecta.

Regulile lui Codd


Edgar F. Codd a murit în data de 18 aprilie 2003, la vârsta de 79 de ani. Codd a
fost un cercetător, angajat al firmei IBM, care a dezvoltat pentru prima oară, în 1970,
modelul relaţional al bazelor de date în care prezintă operaţiile ce pot fi efectuate asupra
unei baze de date cu scopul obţinerii accesului rapid şi corect la acestea. În 1985 Codd
a publicat o listă de reguli care definesc simplu şi concis o bază de date relaţională
ideală, aceste reguli devenind standardul de evaluare a sistemelor relaţionale, fiind în
acelaşi timp şi un ghid de proiectare a tuturor sistemelor de baze de date relaţionale.
După publicarea lucrării, Codd a afirmat că va fi foarte greu, dacă nu imposibil de creat
un sistem care să satisfacă în totalitate setul de reguli, lucru care rămâne valabil şi astăzi.
La cele mai multe dintre sistemele relaţionale de baze de date regulile 6, 9, 10, 11 şi 12
sunt foarte greu de respectat.

1) Regula informaţiei
Toate informaţiile transferate în cadrul unei baze de date relaţionale trebuie
reprezentate în mod explicit la nivel logic într-o singură modalitate, sub formă de valori
în cadrul unor tabele. Aceasta este, ceea ce se numeşte, reprezentare logică a datelor.
Fiecare linie sau tuplu dintr-un tabel (relaţie) reprezintă intrări în coloane modelul
aplicându-se la fel în întregul tabel astfel încât fiecare rând are acelaşi format.
Fiecare linie din cadrul tabelului este identificată prin intermediul valorii unei
coloane sau combinaţii de coloane, numită cheia primară. Fiecare rând din cadrul
tabelului poate fi accesat prin intermediul unei chei externe. Un sistem de gestiune a
bazelor de date relaţionale trebuie să manipuleze datele folosind doar instrumente

25
specifice modelului relaţional. Din acest motiv, atât datele cât şi metadatele (datele
despre date) trebuie păstrate în tabelele bazei de date.
2) Regula de garantare a accesului
Fiecare dată stocată într-o bază de date relaţională trebuie să poată fi logic
accesibilă utilizatorului prin apelarea numelui tabelului în care se află, prin valoarea
cheii primare şi prin numele unei coloane aparţinătoare tabelului respectiv. Accesul la
date trebuie să se facă simplu, fără a exista ambiguităţi în exprimare. Modelul relaţional
nu se preocupă de aspectele fizice ale extragerii datelor din tabele. Această regulă
afirmă faptul că utilizatorul trebuie să aibe acces la datele stocate în baza de date doar
prin intermediul numelor şi valorilor. Cheia primară, prin care se identifică în mod unic
o anumită înregistrare din cadrul unui tabel, reprezintă elementul fundamental al
modelului relaţional. într-un tabel nu poate exista decât o singură cheie primară care nu
are voie să primească valori NULL.
3) Valorile NULL
Valorile NULL (diferite de şirul de lungime zero sau de numărul zero) sunt
utilizate în cadrul sistemelor de gestiune a bazelor de date relaţionale pentru a
reprezenta informaţia lipsă sau indisponibilă la un moment dat, indiferent de tipul de
dată şi sunt obligatorii în orice sistem complet relaţional. De asemenea, astfel de
reprezentări trebuie să poată fi manipulate într-un mod sistematic şi fără echivoc de
către orice sistem de gestiune al bazelor de date relaţionale (Date, 1991).
O valoare NULL poate apare oriunde în cadrul sistemului de gestiune al bazelor
de date relaţional, dar nu poate fi atribuită nici unei chei primare, majoritatea sistemelor
admiţând specificarea conceptului de câmp nenul sub forma unei constrângeri ce
interzice folosirea valorilor NULL în câmpul respectiv (Parkhurst, 2002).
4) Catalog actualizat permanent pe baza modelului relaţional
Descrierea bazei de date este reprezentată, la nivel logic, în acelaşi fel ca şi datele
obişnuite, astfel încât utilizatorii autorizaţi pot folosi acelaşi limbaj relaţional pentru a
pune întrebări referitoare la structura acesteia. Sistemul trebuie să suporte existenţa unui
catalog relaţional accesibil utilizatorilor autorizaţi prin intermediul aceluiaşi limbaj de
interogare folosit şi în cazul datelor obişnuite (Date, 1991).
O bază de date relaţională trebuie să se autodescrie (Moore).
Catalogul reprezintă locul în care – alături de alte lucruri – se păstrează toate
schemele (externe, conceptuale, interne), dar şi toate corespondenţele
(externă/conceptuală, conceptuală/internă). Cu alte cuvinte, catalogul conţine
informaţii detaliate (numite şi metadate) despre obiectele de interes ale bazei de date şi
ale întregului sistem (Date, 2000).
5) Regula de înţelegere a sublimbajului de manipulare a datelor
Un sistem relaţional poate folosi mai multe limbaje sau moduri de folosire a
terminalelor, dar acesta trebuie să suporte cel puţin un limbaj relaţional care:

1. are sintaxă liniară;


2. poate fi folosit atât interactiv cât şi din cadrul altor programe aplicaţie;
3. suportă:
- operaţii de definire a datelor (inclusiv definirea şi folosirea vederilor);
- operaţii de manipulare a datelor (extrageri de date, dar şi actualizări);
- constrângeri de integritate şi securitate;
- operaţii de gestiune a tranzacţiilor (început, sfârşit, reluare).
(Date, 1991).
În realitate toate sistemele comerciale de gestiune a bazelor de date relaţionale
folosesc limbajul structurat de interogare (SQL).
26
6) Regula de actualizare a vederilor
Toate vederile care sunt teoretic actualizabile, pot fi actualizate de către sistem.
Fiecare vedere trebuie să suporte acelaşi set de reguli de manipulare prin care se poate
accesa în mod direct la fel ca şi un tabel obişnuit (Parkhurst, 2002).
O vedere este un tabel virtual, care provine din cel puţin un tabel de bază şi
generează o serie de reprezentări ale datelor vizibile utilizatorilor. Tabelele de bază sunt
tabelele reale ale bazei de date, cu reprezentare concretă în mediul de stocare. Deoarece
vederile nu înmagazinează date ci interogări, acestea sunt numite tabele virtuale
(Johnson, 1997).
Date a luat în discuţie două principii importante ce trebuie avute în vedere la
actualizarea unei vederi:
Principiul interschimbabilităţii care afirmă faptul că nu trebuie să se facă nici un
fel de deosebire între tabelele de bază şi vederi şi
Principiul relativităţii bazei de date prin care tabelele bazei de date sunt
considerate a fi tabele de bază din punct de vedere al utilizatorului (Date, 2000).
7) Inserarea, actualizarea şi eliminarea
Datele pot fi extrase din cadrul unei baze de date relaţionale sub forma unor
mulţimi de date alcătuite pe baza rândurilor din unul sau mai multe tabele. Operaţiile
de inserare, actualizare şi ştergere trebuie să fie aplicate pe orice astfel de mulţime la
fel cum se aplică şi pe un singur rând dintr-un tabel (Parkhurst, 2002).
8) Independenţa fizică de date
Acest lucru se referă la faptul că programele aplicaţie nu trebuie să fie afectate
dacă au loc modificări în reprezentarea stocării datelor sau în metodele de acces la date.
Programele aplicaţie sunt imune la modificările ce au loc în reprezentarea loc fizică sau
în metodele de acces la date (Avery). Aceasta înseamnă faptul că structura fizică a
datelor nu trebuie să provoace probleme utilizatorului care lucrează cu acele date.
9) Independenţa logică de date
Programele aplicaţie nu trebuie să fie afectate atunci când au loc modificări în
structura tabelelor bazei de date, dacă modificările nu le afectează în mod direct. O
vedere a utilizatorului asupra datelor nu trebuie să fie afectată nici ea în cazul
modificării structurii logice a unei baze de date (de exemplu, adăugarea de coloane noi
în tabele sau de tabele noi în baza de date) (Avery).
Date a definit independenţa logică de date ca reprezentând imunitatea
utilizatorilor şi a programelor acestora la modificările efectuate în structura logică a
unei baze de date. În esenţă, asupra unei baze de date au loc două tipuri de operaţii: de
adăugare de coloane sau tabele şi de modificare a structurii tabelelor sau bazei de date.
Nici una dintre cele două operaţii nu trebuie să afecteze utilizatorii sau programele
acestora.

Operaţia de adăugare
De multe ori, unei baze de date trebuie să i se adauge fie coloane noi în cadrul
tabelelor, fie tabele noi datorită apariţiei de date suplimentare ce trebuie implementate
în baza de date originală. Ca urmare se pot identifica două tipuri de adăugări:
1. extinderea tabelelor prin apariţia de atribute noi, de un anumit tip de dată
specificat;
2. extinderea bazei de date prin apariţia de tabele noi necesare introducerii de noi
entităţi în baza de date.
Operaţia de reorganizare a structurii bazei de date

27
Uneori, apare necesitatea de modificare a structurii bazei de date, nu din cauza
apariţiei de date noi, ci din apariţia nevoii de reamplasare a anumitor date în mod diferit
în cadrul tabelelor, conţinutul acestora rămânând identic cu cel originar. (Date, 2000).
10) Independenţa integrităţii
Constrângerile de integritate specifice unei anumite baze de date relaţionale
trebuie să poată fi definite în sublimbajul relaţional al datelor şi înmagazinate în catalog,
nu în programul aplicaţie. De asemenea trebuie să fie posibilă modificarea unor astfel
de constrângeri aşa cum cere logica aplicaţiei fără a afecta celelalte aplicaţii (Date,
1991).
Constrângerile de integritate sunt reguli prin care sistemul de gestiune al bazelor
de date împiedică baza de date să ajungă într-o stare inconsistentă. Potrivit celor
afirmate de către Date în 2001, regula de aur a independenţei integrităţii este: “Nu
trebuie să fie permisă nici un fel de operaţie care să lase o anumită valoare într-o stare
care să contrazică predicatul impus. În acest fel nu poate avea loc nici o tranzacţie
care ar încerca să lase baza de date într-o stare care să nu corespundă propriei condiţii
impuse.”
Constrângerile de integritate sunt:
1. Constrângeri NOT NULL
Această constrângere este preferată de standardul ISO în comenzile CREATE şi
ALTER TABLE. Constrângerea interzice înmagazinarea în baza de date a valorilor
NULL, ceea ce înseamnă că nu se permite ca anumite coloane să fie goale (Connolly et
al., 1999).
2. Clauza UNIQUE
Clauza UNIQUE specifică una sau mai multe coloane care identifică în mod unic
fiecare înregistrare din cadrul unui tabel. În acelaşi timp, fiecare coloană ce apare în
clauza UNIQUE trebuie să fie declarată ca fiind NOT NULL.
SQL anulează orice operaţie de inserare sau actualizare care are tendinţa de a
genera valori duplicat în cheile candidat. Într-un tabel nu este permisă decât o singură
cheie primară, iar clauza UNIQUE se foloseşte numai dacă a fost aleasă cheia primară
şi este necesar ca valorile altei coloane să fie unice.
3. Clauza PRIMARY KEY (integritatea entităţii)
Cheia primară a unui tabel trebuie să conţină o valoare unică nenulă pentru fiecare
înregistrare introdusă în tabel. Standardul ISO impune integritatea entităţii prin
intermediul clauzei cheii primare ce apare în instrucţiuni precum CREATE sau ALTER
TABLE (Connolly et al., 1999).
4. FOREIGN KEY (integritatea referenţială)
O cheie externă este un câmp dintr-un tabel ce corespunde coloanei cheie candidat
dintr-un alt tabel. O valoare a cheii externe trebuie să aibă o valoare corespondentă în
tabelul părinte. Tabelul ce conţine cheia externă se numeşte tabelul referit, copil sau
extern, în timp ce tabelul ce conţine cheia candidat se numeşte tabelul de referinţă,
primar, sau părinte (Rennhackkamp, 1996).
Integritatea referenţială are semnificaţia faptului că nici o bază de date relaţională
nu poate conţine valori necorespunzătoare ale cheii externe. Cheie externă
necorespunzătoare reprezintă o valoare a cheii externe dintr-un tabel referit pentru care
nu există valoare în tabelul de referinţă. Cu alte cuvinte, constrângerea specifică faptul
că dacă B îl referă pe A, atunci A trebuie să existe. Date afirmă faptul că, de multe ori,
nu este posibilă utilizarea unei interogări convenabile pentru a obţine un anumit
răspuns. Din acest motiv, trebuie să se poată specifica o acţiune referenţială de tipul
“CALL proc()”, în care proc reprezintă procedura creată de utilizator (Date, 2000).

28
Actualizările bazei de date au loc întotdeauna la nivel atomic, ceea ce înseamnă
“totul sau nimic”, chiar dacă sunt implicate actualizări pe mai multe valori, ca în cazul
acţiunii referenţiale CASCADE (Date, 2000).
Standardul ISO propune introducerea cheii externe prin intermediul clauzei
FOREIGN KEY ce apare în cadrul comenzilor de creare sau modificare a structurii unui
tabel. De exemplu, dacă tabelul B are o cheie externă care face referire la o coloană din
tabelul A, integritatea referenţială interzice introducerea unei valori în tabelul B care nu
are corespondent în tabelul A. În plus, regulile de integritate referenţială pot avea în
vedere şi faptul că ori de câte ori se elimină o valoare din tabelul A, valorile
corespunzătoare din tabelul B pot fi şi ele eliminate, ceea ce este cunoscut sub
denumirea de ştergere în cascadă. Regulile de integritate referenţială mai pot specifica
şi faptul că ori de câte ori se modifică o valoare din tabelul A, toate valorile
corespunzătoare din tabelul B sunt şi ele modificate automat, ceea ce este cunoscut sub
denumirea de actualizare în cascadă (Webopedia, Referential Integrity).
SQL prevede următoarele opţiuni ce pot fi alese în astfel de situaţii (Connolly et
al., 1999):
1. CASCADE: prin ştergerea unei înregistrări din tabelul părinte automat se
elimină toate înregistrările corespunzătoare din tabelul copil. Deoarece înregistrările
eliminate pot conţine o cheie candidat utilizată drept cheie externă în alt tabel, regulile
cheii externe se aplică şi în tabelul respectiv, ş.a.m.d.
2. SET NULL: şterge înregistrarea din tabelul părinte şi provoacă setarea
coloanelor cheie externă din tabelul copil la valoarea NULL, dar o astfel de operaţie
este posibilă numai dacă coloanele cheii externe nu au setată opţiunea NOT NULL.
3. SET DEFAULT: şterge înregistrarea din tabelul părinte şi provoacă setarea
fiecărei componente a cheii externe din tabelul copil la valoarea implicită specificată,
dar operaţia este valabilă numai dacă coloanele cheii primare au setată opţiunea
DEFAULT.
4. NO ACTION: resping operaţia de ştergere din tabelul părinte, fiind opţiunea
implicită dacă nu se introduc explicit reguli pentru ON DELETE.
5. Constrângerea CHECK
Există două tipuri de constrângeri CHECK. Una dintre ele este denumită
constrângere de domeniu, deoarece stabileşte mulţimea de valori pe care o poate lua un
atribut, iar cealaltă se numeşte constrângerea logică utilizată cu scopul de a pune în
evidenţă anumite condiţii suplimentare (Connolly et al, 1999).
Standardul ISO prevede astfel de constrângeri ce pot fi introduse în cadrul
comenzilor de creare sau modificare a unui tabel. Clauza CHECK permite definirea
unei constrângeri pe o coloană sau pe întregul tabel. În cazul utilizării clauzei la nivel
de coloană, aceasta nu poate face referire decât la coloana respectivă (Connolly et al,
1999).
Cel puţin următoarele două constrângeri trebuie să existe în orice bază de date
relaţională:
a) Integritatea entităţii: nici o componentă a cheii primare nu are voie să aibe valoarea
NULL.
b) Integritatea referenţială: pentru fiecare valoare nenulă a cheii externe din baza de
date relaţională, trebuie să existe o valoare corespunzătoare din acelaşi domeniu de
valori şi de acelaşi tip (cheia primară).

29
11) Independenţa de distribuire
Orice bază de date relaţională trebuie să aibe independenţă la distribuire, ceea ce
înseamnă faptul că utilizatorii nu trebuie să ştie că o bază de date este distribuită, iar
aplicaţiile existente ce folosesc respectiva bază de date trebuie să funcţioneze la fel ca
şi când baza de date ar fi centralizată:
a. dacă se introduce anterior o versiune modificată a unei baze de date distribuite;
b. dacă datele distribuite existente se redistribuie în tot sistemul (Date, 1991). Aplicaţia
funcţionează unitar din punct de vedere logic, dacă datele sunt gestionate de un
singur sistem de gestiune a bazelor de date aflat pe o singură maşină (Date, 1991).
Date (2000) numeşte sistem distribuit de baze de date un sistem ce constă dintr-
o colecţie de site-uri conectate laolaltă prin intermediul unei reţele şi în care fiecare
site conţine un sistem independent de baze de date, dar site-urile convin să lucreze
împreună astfel încât utilizatorul, indiferent de locul în care se află, poate accesa datele
de oriunde de pe reţea ca şi cum acestea s-ar afla în site-ul propriu.
“Fiecare site conţine un sistem independent de baze de date” înseamnă faptul că
fiecare site are o bază de date “reală” locală cu proprii utilizatori şi toate elementele
caracteristice sistemelor de gestiune relaţionale.
Date a introdus 12 reguli ce se aplică bazelor de date distribuite:
1. Autonomia locală –site-urile din sistemul distribuit trebuie să fie independente.
2. Nu trebuie să existe un site dominant – toate site-urile trebuie să fie tratate în
mod egal.
3. Operare continuă – sistemele distribuite trebuie să aibe o fiabilitate şi o
disponibilitate ridicate.
4. Independenţa de locaţie – utilizatorii nu trebuie să ştie unde se află datele pe
care le folosesc.
5. Independenţa de fragmentare – utilizatorii nu trebuie să ştie că datele sunt
separate în diferite locaţii.
6. Independenţa de copie – utilizatorii nu trebuie să ştie că lucrează cu nişte copii.
7. Procesarea distribuită a interogărilor – suportul necesar interogărilor multiple şi
a optimizării acestora.
8. Controlul tranzacţiilor distribuite – refacerea şi controlul concurenţei.
9. Independenţa hardware.
10. Independenţa de sistemul de operare folosit.
11. Independenţa de reţea.
12. Independenţa de sistemul de gestiune al bazei de date – se referă la omogenitate.
(Date, 2000).
12) Regula de non-subversiune
Dacă un sistem relaţional are un limbaj de nivel scăzut (procesarea pe rând a unei
singure înregistrări odată), acel limbaj nu poate fi folosit pentru a trece de interdicţiile
impuse de constrângerile sistemului exprimate prin intermediul limbajului relaţional de
nivel înalt (procesarea întregului set de înregistrări deodată).
Nu trebuie să existe nici o modalitate prin care să se poată modifica structura
bazei de date alta decât prin intermediul unui limbaj relaţional, cum ar fi de exemplu,
SQL (Parkhurst, 2002).

Observaţie: Mai există o regulă fundamentală a celor 12 reguli, cunoscută sub


numele de Regula zero: "orice sistem care se declară a fi sistem relaţional de gestiune
al bazelor de date trebuie să fie capabil să gestioneze datele doar prin intermediul
propriilor caracteristici".

30
O altă modalitate de definire a unei baze de date relaţionale este aceea făcută prin
intermediul celor cinci reguli ale lui Connolly, ce se bazează pe cele 12 reguli ale lui
Codd (1999):
1. Reguli fundamentale (R12)
2. Reguli structurale (R1, R6)
3. Reguli de integritate (R3, R10)
4. Reguli de manipulare a datelor (R2, R4, R5, R7)
5. Reguli de independenţă a datelor (R8, R9, R11)
Nu există sistem relaţional care să suporte în întregime regulile de actualizarea a
vederilor (R6), de control a valorilor NULL (R3) şi de independenţă logică de date (R9).
Orice încălcare a regulilor prezentate necesită eforturi suplimentare atât din partea
utilizatorilor finali cât şi a administratorilor. De exemplu, utilizatorii finali nu pot
actualiza o vedere, bazată pe două tabele, sau obţin rezultate eronate datorită faptului
că sistemul de gestiune al bazelor de date controlează valorile NULL într-un mod
neaşteptat. Prin adăugarea unei coloane noi într-un tabel, orice aplicaţie care va folosi
acea coloană va trebui modificată. Inconsistenţe ale datelor pot apare foarte uşor în
cadrul unei baze de date dacă o vedere şi tabelul său de bază trebuie controlate de către
utilizatori separat. Contra-argumentul este (probabil) acela că sistemele de gestiune a
bazelor de date ar deveni lente deoarece dacă independenţa de date ar fi totală, atunci
timpul necesar despachetării înregistrărilor fizice necesar obţinerii datelor necesare
trebuie adăugat întotdeauna la crearea vederilor utilizatorilor. Dar, deoarece, marea
majoritate a lucrului se bazează pe o singură vedere particulară a utilizatorului, devine
utilă punerea în concordanţă a vederii utilizatorului cu organizarea fizică pentru a
economisi timp. Codd s-a preocupat un timp îndelungat cu crearea unei interfeţe logice
pe care sistemul de gestiune al bazei de date să o pună la dispoziţia utilizatorului, dar
problema performanţelor nu era legată de rezolvarea unei astfel de probleme, ci de
faptul că toate sistemele relaţionale au o structură fizică bazată exclusiv fie pe fişiere
de tip ISAM fie pe fişiere cu acces aleator, acestea devenind fie foarte lente fie foarte
rapide în funcţie de volumul şi de distribuirea cererii.

Structuri de indecşi în tabelele de date

Un index reprezintă o cale rapidă de localizare a înregistrărilor dintr-o tabelă, prin


gruparea tuturor înregistrărilor pentru un anumit atribut sau grup de atribute.
Indexarea este utilizată în două scopuri principale:
 accelerarea căutărilor în baza de date
 asigurarea unicităţii înregistrărilor

Vom privi o relaţie ca o colecţie de date (o mulţime) în care nu sunt admise


elemente duplicat. În cazul unei mulţimi reprezentate printr-o colecţie neordonată de
elemente, timpul de căutare a unui element creşte proporţional cu numărul de elemente
ale mulţimii, deoarece în cazul cel mai rău trebuie parcurse toate elementele mulţimii
pentru a găsi elementul dorit.
Timpul de căutare a unui element poate fi micşorat considerabil dacă elementele
mulţimii sunt ordonate.
Un exemplu este cel utilizat uzual în cărţi. Într-o carte găsim la sfârşit termenii
importanţi aranjaţi în ordine alfabetică. La fiecare termen din această listă este furnizată
un număr de pagină în care apare şi este explicat termenul. Utilizând această listă se

31
găseşte imediat un termen căutat. Fără o astfel de listă, neexistând o ordine de ghidare
a căutării, singura alternativă este explorarea completă a întregului material pentru a
găsi termenul dorit.
În general, operaţiile de căutare, inserare şi ştergere a elementelor într-o mulţime
(tabelă) se execută mai rapid dacă elementele mulţimii (înregistrările) sunt reprezentate
printr-o colecţie ordonată. În tehnologia bazelor de date, ordonarea colecţiilor de date
se face prin indexarea datelor.
Indexul unei tabele este o structură de date adiţională memorată în baza de date
care permite accesul rapid la înregistrările tabelei prin ordonarea acestora.

De fapt, indexul poate fi gândit ca o tabelă cu două atribute: primul atribut conţine
valorile atributelor tabelei bazei de date pentru care se crează indexul, iar al doilea
conţine un pointer la locaţia nuplurilor corespunzătoare. Valorile sunt aranjate fie în
ordine descendentă cheii de indexare, fie în ordine ascendentă.

Indecşii se clasifică după tipul de câmp sau după nivel şi după modul de
organizare a tabelei. O clasificare a acestora este următoarea:

1. Indexul primar este un index asociat unei tabele ordonate după câmpul cheie al
tabelei, iar în structura de index se utilizează câmpul cheie.

2. Indexul secundar este un index construit tot pe baza unui câmp cheie, dar tabela nu
este ordonată după câmpul cheie.

3. Indexul de grup (cluster) este un index construit după câmpuri ce nu sunt câmpuri
cheie (criteriu de acces este diferit de câmpul cheie), iar tabela poate fi ordonată sau
nu relativ la criteriul de acces.

4. Indexul multinivel (index de blocuri) se aplică oricăror tabele. Principiul de bază


este de a construi niveluri de indexare până când structura adiţională de date
corespunde indexului de cel mai mare nivel poate fi memorată într-un singur bloc.

Un index primar este un fişier ordonat cu înregistrări de lungime fixă având două
câmpuri. Primul câmp al indexului este de acelaşi tip cu un câmp cheie ordonat al tabelei
de date, iar al doilea câmp este un pointer către un bloc (o adresă a unui bloc). Câmpul
cheie de ordonare se mai numeşte şi cheie primară a tabelei de date. Asociaţia celor
două câmpuri formează intrarea index sau înregistrarea index pentru fiecare bloc al
tabelei de date. Cum tabela de date este ordonată după valorile câmpului index, în
fişierul index valoarea primului câmp este dată de valoarea câmpului index de la prima
înregistrare a blocului. Al doilea câmp, cel ce semnifică un pointer este de tip întreg şi
indică adresa blocului.

32
<k> reprezintă cheia de ancorare bloc <p> reprezintă pointerul la bloc
Volumul datelor în index este mai mic datorită faptului că în index avem o singură
intrare pentru un bloc, cât şi datorită faptului că un index este similar cu o tabelă, dar
are numai două câmpuri. Ca efect, căutarea într-un fişier index este mult mai rapidă
decât într-o tabelă de date, putând fi utilizate metode de căutare binare.

Metoda de indexare secundară se aplică la tabele neordonate, indiferent dacă


valorile câmpului după care se face indexarea în tabela de date sunt sau nu distincte.
Indexul secundar este un fişier ordonat cu două câmpuri ca şi la alţi indecşi, în care
primul câmp este identic cu cel al tabelei de date, iar al doilea câmp este un pointer.
Câmpul pentru care indexul este construit se numeşte şi câmp de indexare.

În concluzie, orice câmp al unei tabele poate fi câmp de indexare secundar.

<k> reprezintă cheia de ancorare bloc <p> reprezintă pointerul la bloc


Indecşii de grup sunt folosiţi când înregistrările tabelei de date sunt ordonate fizic
după un câmp care nu este cheie (noncheie), deci un câmp ce nu are valori distincte la

33
fiecare înregistrare. Un astfel de câmp identifică un grup de înregistrări (clustering
field). În această situaţie se poate crea un index ce facilitează găsirea înregistrărilor ce
aparţin unui câmp.

Un index de grup este deci un fişier ordonat cu două câmpuri, primul câmp
conţinând aceeaşi informaţie cu cea a câmpului noncheie de ordonare, al doilea fiind
destinat unui pointer către un bloc de date. În acest mod, fişierul index conţine câte o
intrare pentru fiecare valoare distinctă a câmpului de ordonare. Al doilea câmp al
înregistrării index conţine un pointer către blocul în care apare pentru prima oară
valoarea câmpului de ordonare din primul câmp al indexului.

<k> reprezintă cheia de ancorare bloc <p> reprezintă pointerul la bloc

Metodele de indexare descrise până acum operează cu un fişier index ordonat.


Asupra fişierului index se aplică metode de căutare binară pentru localizarea
înregistrărilor cu valoarea specificată în câmpul index.
Pentru un index multinivel, fişierul index este văzut ca un nou fişier la care se
construieşte un nou index şi aşa mai departe. Primul fişier index conţine câte o valoare
distinctă pentru fiecare cheie de indexare. Se poate crea un index primar pentru primul
nivel, nivel numit şi nivel secund al indexului multinivel. Cum al doilea nivel este un
index primar se poate folosi metoda de ancorare a blocurilor, aşa că al doilea nivel are
câte o intrare pentru fiecare bloc al primului nivel, întrucât este în esenţă un index
primar.

34
<k> reprezintă cheia de ancorare bloc <p> reprezintă pointerul la bloc

Algebra relațională
Algebra relațională poate fi concepută ca un limbaj abstract de formulare a
interpelărilor (cererilor) sau ca o colecie de operaii pe relații având drept operanzi una
sau mai multe relaiiți producând ca rezultat altă relație. Operațiile algebrei relaționale
pot fi divizate în două grupuri: operații tradiționale pe mulimi și operații relaționale
native.
Operațiile tradiționale pe mulimi sunt:
 reuniunea (  )
 intersecția (  )
 diferența (-)
 produsul cartezian (  )

Operațiile relaționale native sunt:


 proiecția (  )
 selecția (  )
 joncțiunea ( >< )
 diviziunea (/)
 redenumirea (  )
Deoarece fiecare operatie întoarce o relatie, operatiile pot fi compuse.
Din punct de vedere al numărului de operatori asupra cărora acționează, putem
avea operatori unari (selectia, proiectia), operatori binari(reuniune, intersectie,
diferenta, diviziune, produs cartezian, jonctiune).

Selecția este operația care permite selectarea unei submultimi a înregistrarilor


dintr-o relatie.
Caracteristici:

35
 selecteaza rândurile care satisfac o conditie (predicat) de selecție
 schema rezultatului este identică cu schema relației de intrare
 relația rezultat poate fi intrare pentru o alta operatie algebrică
 nu există duplicate în instanța relației de ieșire

Condiția de selecție (predicatul selectiv) este o expresie care conține: nume de


câmpuri, constante si operatori relaționali sau logici. Evaluarea predicatului întoarce o
valoare logica de tipul TRUE sau FALSE.

Exemplu: PERSONAL (cnp, nume, prenume, functie, loc_m, salar)


cnp nume prenume functie Loc_m salar
123 Lupu Ion Director Primarie 2800
456 Costache Vasile Secretar Primarie 1800
789 Vasilescu Dumitru Portar Primarie 800

Care sunt persoanele cu salarii mai mari de 1000 lei?


 salar 1000 ( PERSONAL )

cnp nume prenume functie Loc_m salar


123 Lupu Ion Director Primarie 2800
456 Costache Vasile Secretar Primarie 1800

Proiecția este operația care generează o relație care conține doar acele câmpuri
precizate în lista de proiectie.
Caracteristici:
 șterge câmpurile care nu apar în lista de proiectie
 schema relației rezultat conține exact câmpurile din lista de proiectie, (au
aceleasi nume din relatia originala)

Tupluri distincte pot deveni identice, când se proiectează pe o mulime de atribute, de


aceea tuplurile duplicate în relaia rezultat se elimină.

Exemplu: PERSONAL (cnp, nume, prenume, functie, loc_m, salar)


cnp nume prenume functie Loc_m salar

36
123 Lupu Ion Director Primarie 2800
456 Costache Vasile Secretar Primarie 1800
789 Vasilescu Dumitru Portar Primarie 800

Să se realizeze o listă cu salariile întregului personal care sa conțina numai


detaliile: Nume, Prenume, Salar.
 nume , prenume , salar ( PERSONAL )

nume prenume salar


Lupu Ion 2800
Costache Vasile 1800
Vasilescu Dumitru 800

Reuniunea (selectia tuplurilor distincte) a doua relații R si S cu i respectiv j


tupluri este obținută prin concatenarea lor într-o relație cu maxim (i+j) tupluri, tuplurile
duble fiind eliminate.
Caracteristici:
 relațiile R și S trebuie să fie compatibile la reuniune (același număr de
câmpuri, câmpurile corespunzatoare au același domeniu), fapt ce va
determina schema relației rezultat.

Exemplu:

Care sunt toti studenții?

Diferența reprezintă selecția tuplelor carte apar numai în prima relație.


Caracteristici:
 relațiile R și S trebuie să fie compatibile la reuniune (același număr de
câmpuri, câmpurile
 operație binară, necomutativă
 se poate utiliza pentru stergerea tuplurilor dintr-o relatie.

Cod
A1 Cod Cod
A2 A1 A2
A3 A10 A3
R S R-S

37
Intersecția definește o relație ce constă în multimea tuturor tuplurilor care se afă
atât în relatia R cât si în relatia S.
Caracteristici:
 cele două relații trebuie sa fie compatibile la reuniune.
 Este o operație comutativă și derivată
R  S =R-(R-S) = S-(S-R)

Cod Cod Cod


A1 A1 A1
A2 A10 R S
A3 S
R

PERSONAL (cnp, nume, prenume, functie, loc_m, salar)


cnp nume prenume functie Loc_m salar
123 Lupu Ion Director Primarie 2800
456 Costache Vasile Secretar Primarie 1800
789 Vasilescu Dumitru Portar Primarie 800

CLIENTI(cnp, nume, prenume)


cnp nume prenume
543 Anton Anton
456 Costache Vasile
111 Oprea Ciprian
Care sunt toți clienții care fac parte din personalul propriu?
CLIENTI   cnp , nume , prenume ( PERSONAL )

cnp nume prenume


456 Costache Vasile

Produsul cartezian definește o relație care reprezintă o concatenare a fiecărui


tuplu din relatia R cu fiecare tuplu din relația S.
Caracteristici:
 shema relației rezultat contine câte un câmp pentru fiecare câmp din S si
din R
 dacă R și S sunt de grad m, respectiv n , și de cardinalitate i, respectiv j,
produsul cartezian al celor două relații RxS este o relație de grad m+n și
de cardinalitate i*j
 numele câmpurilor sunt mostenite din relatiile originale (daca este
posibil). Dacă cele două relații conțin câmpuri cu același nume,
denumirile acestora conțin ca prefix denumirea relatiei, pentru a mentine
unicitatea denumirilor în cadrul unei relatii.

CLIENTI(cod, nume, prenume,oras)


cod nume prenume oras
123 Anton Anton Iasi
456 Costache Vasile Iasi

38
789 Oprea Ciprian Vatra Dornei

PRODUSE(cod, denumire, prenume,oras)


cod denumire
111 Televizor
222 Laptop

CLIENTI  PRODUSE
CLIENTI.cod nume prenume oras PRODUSE.cod denumire
123 Anton Anton Iasi 111 Televizor
456 Costache Vasile Iasi 111 Televizor
789 Oprea Ciprian Vatra 111 Televizor
Dornei
123 Anton Anton Iasi 222 Laptop
456 Costache Vasile Iasi 222 Laptop
789 Oprea Ciprian Vatra 222 Laptop
Dornei

Jonctiunea (JOIN, uniunea) definește o operatie binară care are ca rezultat o noua
relatie în care fiecare tuplu este o combinatie a unui tuplu din prima relație cu un tuplu
din a doua relatie.
Caracteristici:
 derivata a produsului cartezian
 există diferite forme:
o theta- JOIN
o echi- JOIN
o natural JOIN (uniunea naturală);
o outer JOIN (uniunea externă);
o semi JOIN (semi-uniunea).
 schema relației rezultat este aceeași ca la produsul cartezian dar poate
conține mai puține tupluri decât produsul cartezian, putând fi calculat mai
eficient

Theta –JOIN definește o relație care conține tuplurile ce satisfac un predicat p


din produsul cartezian al relatiilor R și S. Este echivalentă cu efectuarea unei selecții
asupra produsului cartezian al celor doua relatii operand. Predicatul p este de forma:
R.a op S.b
unde op este operator de comparare ( <,<=,>,>=, =). În cazul în care predicatul p
conține numai egalitatea (=), se foloseste termenul de echi-uniune(echi-jonctiune).
R p S   p ( R  S )

Exemplu:

39
Care sunt comenzile care au fost onorate (pentru care s-au emis facturi)?
Facturi  Facturi.numar Comenzi.numar Comenzi

Natural Join (R  S) definește o echi-uniune a două relații R și S pe toate


atributele comune. O aparitie a fiecarui atribut comun este eliminată din rezultat.

Exemplu:

La uniunea a două relații nu există mereu o valoare similară în coloanele comune.


În aceste condiții rândul respectiv poate să apară în relația rezultat dacă se utilizează
operatorul de uniune externa OUTER JOIN. Acest operator are două forme:
 uniunea externa stânga (R   S) - este o uniune în care tuplurile din relația
R, care nu au valori similare în coloanele comune ale relatiei S, sunt de
asemenea incluse în relatia rezultanta.
 uniunea externa dreapta (R   S) - este o uniune în care tuplurile din
relația S, care nu au valori similare în coloanele comune ale relatiei R,
sunt de asemenea incluse în relatia rezultanta.

40
Există și operația de uniune externă completă, valorile lipsă din relație fiind stabilite la
valoarea null. Astfel se pastrează informații care în alt tip de uniune ar fi fost pierdute.

Exemplu:
Pentru relațiile din exemplul anterior, prin aplicarea operatorului de uniune
externă (dreapta) se obtine:
COMENZI   BENEFICIARI

Un alt operator util în exprimarea unor interogări este Diviziunea.


R / S  {x |(x, y)  R pentru orice y  S}

Răspunde întrebărilor de genul:


“Care sunt clienții care au contractat toate serviciile furnizate”.

Exemplu:
x y y
x1 y1 y1
x1 y2 y3
x1 y3 B
x2 y2
x2 y3
x3 y1
x3 y3
A
y
x1
x3
A/B
Diviziunea nu este un operator primar, putând fi exprimat cu ajutorul operatorilor
fundamentali. Acest lucru poate fi observat daca ținem seama de faptul că A/B,
calculeaza toate valorile x care nu sunt “descalificate” de valori y din B. O valoare x
este descalificată daca prin atasarea unei valori y din B, se obtine un tuplu xy care nu
se gaseste în A.
A / B   X ( A)   X (( X ( A)  B )  A)

41
Limbajul SQL

SQL (Structured Query Language - Limbaj Structurat de Interogare) este un


limbaj de programare specific pentru manipularea datelor în sistemele de manipulare a
bazelor de date relaționale (RDBMS), iar la origine este un limbaj bazat pe algebra
relațională. Acesta are ca scop inserarea datelor, interogări, actualizare și ștergere,
modificarea și crearea schemelor, precum și controlul accesului la date. A devenit un
standard în domeniu, fiind cel mai popular limbaj utilizat pentru creearea, modificarea,
regăsirea și manipularea datelor de către SGBD-urile (Sistemele de Gestiune a Bazelor
de Date) relaționale. Pe lângă versiunile standardizate ale limbajului, există o mulțime
de dialecte și variante, unele proprietare, fiind specifice anumitor SGBD-uri și de
asemenea conținând extensii pentru a suporta SBD-urile (Sistemele de Baze de Date)
obiectuale (obiectual-relaționale).
SQL permite atât accesul la conținutul bazelor de date, cât și la structura acestora.
Limbajul SQL este divizat în următoarele elemente:
 clauze, care sunt componente ale instrucțiunilor și interogărilor.
 expresii, al căror efect este producerea de valori scalare sau tabele.
 predicate, pot specifica condiții care sunt evaluate de SQL în scopul
limitării efectelor instrucțiunilor, sau pentru a influența cursul
programului.
 interogările, au ca scop regăsirea datelor după criterii specifice.
Instrucțiunile, pot avea un efect persistent asupra datelor sau structurii datelor,
sau pot controla tranzacțiile, conexiunile sau cursul programului.

În general, instrucțiunile SQL se termină cu caracterul punct-virgulă (";"), deși


acest lucru nu este obligatoriu în toate platformele SQL. Spațiile albe suplimentare sunt
ignorate, dar ele pot fi folosite pentru lizibilitatea codului SQL.

Principalele comenzi SQL

Pentru manipularea datelor


 SELECT - extragerea datelor din baza de date
 INSERT - adaugarea de noi linii într-un tabel
 DELETE - stergerea de linii dintr-un tabel
 UPDATE - modificarea valorilor unor atribute
Pentru definirea bazei de la baza de date
 CREATE TABLE - adaugarea unui nou tabel la baza de date
 DROP TABLE - ștergerea unui tabel din baza de date
 ALTER TABLE - modificarea structurii unei baze de date
 CREATE VIEW - crearea unuitabel virtual (vedere)
 DROP VIEW - ștergerea unui tabel virtual
Pentru controlul accesului la baza de date
 GRANT - acordarea unor drepturi pentru utilizatori
 REVOKE - revocarea unor drepturi pentru utilizatori
Pentru controlul tranzactiilor
 COMMIT - marcheaza sfârsitul unei tranzactii
 ROLLBACK - abandoneaza tranzactia în curs

42
În limbajul SQL standardizat se utilizeaza termenii de tabele , coloane
si rânduri. O instructiune SQL este formata din cuvinte rezervate si cuvinte
definite de utilizator.
 Cuvintele rezervate au un înteles fix, trebuie scrise exact cum este necesar
si nu pot fi împartite în mai multe rânduri.
 Cuvintele definite de utilizator : sunt formate de catre acesta, conform
unor anumite reguli de sintaxa si reprezinta denumirile diverselor obiecte
din baza de date, cum ar fi relatiile, coloanele , vederile, indexurile etc.
Majoritatea compnentelor unei instructiuni SQL nu sunt sensibile la tipul de
litere. Datele de tip caracter literal trebuie sa fie scrise exact cum apar în baza de date.

Consultarea datelor este operatia fundamentala în SQL. Acest lucru se


realizează cu ajutorul comenzii SELECT. Aceasta prezintă trei clauze principale :
SELECT, FROM si WHERE.
 SELECT corespunde operatorului de proiectie din algebra relationala, si
este utilizat pentru desemnarea listei de atribute (coloane, câmpuri) din
tabelul rezultat
 FROM permite enumerarea tabelelor din care vor fi extrase datele aferente
consultarii
 WHERE desemneaza predicatul selectiv al algebrei relationale, relativ la
atributele relatiilor care apar în clauza FROM.

Aceasta este o comandă extrem de puternica, fiind echivalentul operatiilor de


selectie, proiectie si uniune din algebra relationala.

Forma generala a instructiunii SELECT este:


SELECT
[ALL | DISTINCT] [*]
[<alias>.]<camp>
[AS <nume_nou>]
[, [<alias>.]<camp>
[AS <nume_nou>] ...]
FROM <tabel>
[<local_alias>]
[, <tabel> [<local_alias>] ...]
[WHERE <cond_leg> [AND <cond_leg> ...]
[AND | OR <cond_filtru> [AND | OR <cond_filtru> ...]]]
[GROUP BY <lista_campuri>]
[HAVING <cond_filtru>]
[ORDER BY <camp_ord> [ASC | DESC] [, <camp_ord> [ASC |
DESC] ...]]

 Alias reprezinta aliasul atribuit relatiei


 câmp este numele câmpului selectat
 nume_nou numele câmpului selectat în noul tabel
 local_alias aliasul local atribuit de utilizator
 cond_leg conditia de legatura între tabelele în care se manipuleaza datele;

43
 cond_filtru conditia de filtrare a înregistrarilor
 lista_câmpuri lista a câmpurilor în functie de care se face gruparea
înregistrarilor
 câmp_ord câmpul dupa care se face ordonarea înregistrarilor

Secventa de prelucrare a unei fraze SELECT este urmatoarea:


 FROM - specifica tabelul sau tabelele care vor fi utilizate;
 WHERE - filtreaza rândurile supuse unei anumite conditii sau contine
conditia de jonctiune între mai multe tabele
 GROUP BY - formeaza grupuri de rânduri cu aceleasi valori ale
coloanelor din lista de parametri;
 HAVING - filtreaza grupurile supuse unei anumite conditii;
 SELECT - specifica ce coloane vor aparea în tabelul rezultat;
 ORDER BY - specifica ordinea iesirii.
Rezultatul unei interogari unui tabel este un alt tabel, acesta putând fi un tabel
"normal" (tabel salvat pe disc), un tabel temporar (cursor - tabel care se sterge automat
la închiderea unei sesiuni de lucru) sau chiar o variabila-tablou (matrice).
SQL folosește apostrof pentru a delimita valorile de tip text/string. Majoritatea
SGBD-urilor acceptă și ghilimele. Valorile numerice nu se delimitează cu
apostroafe/ghilimele
Într-o tabelă, unele coloane pot conține valori duplicate. Pentru a afișa doar
valorile distincte putem folosi cuvântul cheie DISTINCT, adică folosim instrucțiunea
SELECT DISTINCT.
Operatorii pentru clauza WHERE sunt:
 = - egalitate
 <> - inegalitate
 > - mai mare
 < - mai mic
 >= - mai mare sau egal
 <= - mai mic sau egal
 BETWEEN - într-un interval închis
 LIKE - la fel ca un șablon
 IN - o mulțime enumerată explicit
 AND și OR - pentru a filtra înregistrările după mai multe condiții
 IS NULL – pentru a testa dacă un camp este null sau nu
Ordonarea/sortarea se face în mod implicit crescător. Pentru ordonarea
descrescătoare se va folosi DESC.
Operatorii ALL, SOME si ANY permit utilizarea unui predicat de comparatie
care este aplicat rezultatului unei subconsultari. Predicatul de comparatie va
conține unul din operatorii: =,>=,<=,<,> sau ≠.

În interogări putem folosi funcțiile predefinite: COUNT, SUM, AVG, MAX, MIN
 COUNT - contorizeaza valorile unei coloane
 SUM - calculeaza suma valorilor unei coloane
 AVG - calculeaza media aritmetica a valorilor unei coloane
 MAX, MIN - calculeaza valoarea maximă/minimă dintre valorilor unei
coloane

44
Alte funcții scalare SQL predefinite care calculează o singură valoare pe baza unei
valori de intrare
 UCASE() – convertește în litere mari
 LCASE() – convertește în litere mici
 MID() – extrage caractere dintr-un câmp de tip text
 LEN() – calculează lungimea unui câmp de tip text
 ROUND() – rotunjește un câmp numeric la numărul de zecimale
specificat
 NOW() – întoarce data și ora curentă din sistem
 FORMAT() – stabilește modul în care este afișat un câmp

Clauza GROUP BY permite formarea grupurilor de tupluri într-o relatie pe baza


valorilor comune ale unei coloane. Asocierea unei clauze HAVING la o clauza GROUP
BY face posibilă selectarea anumitor grupe de tupluri care îndeplinesc un criteriu.
Sintaxa clauzei GROUP BY este:

SELECT col1, col2,..coln


FROM tabel
GROUP BY coloana de grupare

Clauza HAVING lucreaza împreuna cu o clauza GROUP BY, fiind practic o


clauza WHERE aplicata acesteia. Formatul general este:
SELECT col1, col2,..coln
FROM tabel
GROUP BY coloana de regrupare
HAVING caract eristica de grup

Inserarea de noi înregistrări întro-o tabelă se realizează cu ajutorul instrucțiunii


INSERT INTO

Sintaxa (două variante)

INSERT INTO NumeTab [(NumeCâmp1 [, NumeCâmp2, ...])]


VALUES (eExpr1 [, eExpr2, ...])
INSERT INTO NumeTab FROM ARRAY Nume | FROM MEMVAR

Comanda INSERT poate fi asociata cu o subinterogare, care sa furnizeze valorile


care trebuie adaugate

INSERT INTO NumeTab1 [(NumeCâmp1 [, NumeCâmp2, ...])]


SELECT [(NumeCâmp1 [, NumeCâmp2, ...])]
FROM NumeTab2
WHERE conditii

Subinterogarea se poate utiliza în locul unui nume de tabel în clauza INTO a


comenzii INSERT:
INSERT INTO
(SELECT [(NumeCâmp1 [, NumeCâmp2, ...])]

45
FROM NumeTab2)
VALUES (eExpr1 [, eExpr2, ...])

Actualizarea unor date dintr-o tabelă se realizează cu ajutorul instrucțiunii


UPDATE.
Sintaxa:

UPDATE [NumeBD1!]NumeTabe1
SET NumeCâmp1 = Expr1
[, NumeCâmp2 = Expr2 ...]
WHERE CondFiltru1 [AND | OR CondFiltru2 ...]]

Sau folosind subinterogarile

UPDATE NumeTabe1
SET NumeCâmp1 = (SELECT NumeCâmp1
FROM NumeTabe1
WHERE conditii),
[NumeCâmp2 = (SELECT NumeCâmp2
FROM NumeTabe1
WHERE conditii),]
WHERE conditii

Omiterea clauzei WHERE duce la actualizarea tuturor înregistrărilor din tabel.

Ștergerea datelor dintr-un tabel se realizează cu instrucțiunea DELETE.


Sintaxa

DELETE FROM [NumeBD!]NumeTab


[WHERE câmp operator
(SELECT câmp
FROM NumeTabel
WHERE conditii)]

Omiterea clauzei WHERE duce la ștergerea tuturor înregistrărilor din tabel.

Pentru crearea structurii conceptuale a tabelelor se va folosi instrucțiunea


CREATE TABLE, a cărei formă generala este:
CREATE TABLE | DBF NumeTabel [NAME Nume_LungTabel] [FREE]
(NumeCâmp1 TipCâmp [(n[,d])]
[NULL | NOT NULL] [PRIMARY KEY | UNIQUE]
[CHECK Expr1 [ERROR Mesaj1]]
[DEFAULT Expr2]
[REFERENCES NumeTabel2 [TAG NumeTag1]]
[NOCPTRANS]
[, FieldName2 …]
[, PRIMARY KEY Expr3 TAG NumeTag2
|, UNIQUE Expr4 TAG NumeTag3]

46
[, FOREIGN KEY Expr5 TAG NumeTag4
REFERENCES NumeTabel3 [TAG NumeTag5]]
[, CHECK Expr6 [ERROR Mesaj2]])
| FROM ARRAY NumeMatrice

Tipurile de date permise în standardul SQL

 NUMBER (n ,d ) - numere reale cu n pozitii, din care d zecimale


 FLOAT - numere reale, virgula mobila
 INTEGER - numere întregi (32 biti)
 DOUBLE PRECISION – numere reale, virgula mobila, dubla precizie
 CHAR - caractere
 VARCHAR - șir de caractere de lungime variabila (max 255)
 DATE - data calendaristica
 TIME - ora
 LOGICAL – logic
Exemplele prezentate în continuare pot fi testate pe baza de date Ex_BD.accdb

 Selectarea tuturor clienților

SELECT * FROM Clienti

 Selectarea doar a coloanelor nume_client, adresa_client,banca_client din


tabelul Clienti

SELECT nume_client, adresa_client,banca_client FROM


Clienti

 Selectarea doar a coloanelor nume_client, adresa_client din tabelul Clienti


(doar clienții care au banca BRD)

SELECT nume_client, adresa_client FROM Clienti WHERE


banca_client='BRD'

 Selectarea doar a clienților care au numărul punctelor de fidelitate cuprins


între 122 și 124

SELECT nume_client, adresa_client FROM Clienti WHERE


puncte BETWEEN 122 AND 124

 Aceeași selecție poate fi facută și cu ajutorul operatorilor <= și >=

SELECT nume_client, adresa_client FROM Clienti WHERE


puncte>=122 AND puncte<=124

 Utilizarea operatorului IN pentru selecția clienților a căror bancă este


BRD sau BCR

47
SELECT nume_client, adresa_client FROM Clienti WHERE
banca_client in {'BRD', 'BCR'}

 Aceeași selecție poate fi facută și cu ajutorul operatorilor OR și =

SELECT nume_client, adresa_client FROM Clienti WHERE


banca_client='BRD' OR banca_client='BCR'

 Selectarea clienților născuți în anul 1985

SELECT * FROM Clienti WHERE cnp LIKE '?85*'

 Selectarea clienților născuți în luna Aprilie

SELECT * FROM Clienti WHERE cnp LIKE '???04*'

 Rezultatele selecției anterioare sunt ordonate ascendent după numărul


punctelor
SELECT * FROM Clienti WHERE cnp LIKE '??04*' ORDER BY
puncte

 Formă echivalentă deoarece ASC este valoare implicită

SELECT * FROM Clienti WHERE cnp LIKE '???04*' ORDER


BY puncte ASC

 Ordonarea descendentă a inregistrărilor de la pasul precedent

SELECT * FROM Clienti WHERE cnp LIKE '??04*' ORDER BY


puncte DESC

 Îmbinarea tabelelor Facturi și Clienți avânt drept punct comun câmpul


cod_client

SELECT nr_factura, data_factura, delegat,


nume_client, adresa_client, judet, puncte FROM Facturi,
Clienti WHERE facturi.cod_client=clienti.cod_client

 Formă echivalentă, folosind INNER JOIN

SELECT nr_factura, data_factura, delegat, nume_client,


adresa_client, judet, puncte FROM Facturi INNER JOIN
Clienti ON facturi.cod_client=clienti.cod_client

 Pentru afișarea și a facturilor pentru care nu există corespondent în tabelul


Clienți pentru câmpul cod_client se poate folosi LEFT JOIN. Unde nu
există corespondent se va afișa null

SELECT nr_factura, data_factura, delegat,


nume_client, adresa_client, judet, puncte FROM Facturi

48
LEFT JOIN Clienti ON
facturi.cod_client=clienti.cod_client

 Afișarea categoriilor și a numărului de produse din fiecare categorie

SELECT categorie AS CATEG, COUNT(cod_produs) AS numar


FROM produse GROUP BY categorie

 Din categoriile de la pasul precedent se aleg doar cele cu mai putin de 2


produse. Pe lângă funcția Count se mai pot folosi funcțiile SUM, MIN,
MAX, AVERAGE.

SELECT categorie AS CATEG, COUNT(cod_produs) AS numar


FROM produse GROUP BY categorie HAVING
COUNT(cod_produs)<2

 Adăugarea unui client în listă

INSERT INTO Clienti (cod_client, nume_client,


adresa_client,banca_client,nr_cont_client,judet, puncte,
CNP)
VALUES (38,"Client 10","Strada
Decebal","ING",125478933,"Suceava",25,"1651019336098")

 Ștergerea din listă a clienților cu mai puțin de 5 puncte de fidelizare (dacă


lipsește clauza WHERE, se vor șterge toate înregistrările din tabel)

DELETE FROM Clienti WHERE puncte < 5

 Crearea unui nou tabel (Personal), care va avea câmpurile: CNP (cheie
primară), Nume, Prenume

CREATE TABLE Personal (CNP CHAR(13) PRIMARY KEY,


Nume CHAR (15), Prenume CHAR (20))

 Populăm tabelul nou creat cu lista persoanelor din tabelele Clienți și


Angajați. Deoarece nu există câmpul Prenume, completăm cu ""

INSERT INTO Personal SELECT CNP, nume, "" AS prenume


FROM Angajati

Apoi

INSERT INTO Personal SELECT CNP, nume_client AS Nume,


"" AS Prenume FROM Clienti

 Ștergem tabelul Personal

DROP TABLE Personal

49
Baze de date spaţiale
În noua economie bazată pe cunoștințe, sistemele informatice pentru
organizarea datelor, informațiilor și extragerea de noi cunoștințe devin esențiale în
procesele de luare a deciziilor și de elaborare a strategiilor de dezvoltare.
Pe langă tipurile de date clasice utilizate în sistemele informatice, în ultimii ani
au luat amploare datele geospațiale. Aceste date se referă la localizarea geografică a
anumitor obiecte pe glob, la forma și dimensiunile acestora.
Sistemele informatice care stochează, prelucrează, vizualizează datele clasice
împreună cu datele geospațiale se numesc sisteme informatice geografice, GIS.
Un GIS este aplicabil în multe domenii, ca de exemplu: dezvoltare regională și
urbanism, turism, financiar-bancar, sănatate, militar, criminalistică, știinte sociale,
geologie, mediu etc.
Cea mai costisitoare şi longevivă componentă a unui GIS este baza de date
geografice.
Datele ce reprezintă poziţia şi / sau forma unor obiecte, indiferent de sistemul
de referinţă, se numesc date spaţiale.
O bază de date spaţială este o bază de date optimizată pentru stocarea, gestiunea
şi interogarea datelor spaţiale. Aceasta pune la dispoziţie tipuri de date spaţiale în
modelul său de date şi în limbajul de interogare, suport pentru tipuri de date spaţiale în
implementare, indexare spaţială şi algoritmi eficienţi pentru join spaţial.
Teoretic, orice variabilă care poate fi localizată spaţial sau căreia i se pot asocia
coordonate spaţiale (indiferent de sistemul de referinţă) poate fi inclusă într-o bază de
date spaţială. Aceste date sunt identificate sub diferite denumiri: date geometrice,
geografice sau spaţiale.
Prin date geografice se înţelege ansamblul format din date spaţiale (localizate
prin coordonate) şi date descriptive (atribute) asociate obiectelor/fenomenelor
geografice (străzi, parcele, accidente).
O bază de date geografice este o colecţie de date geografice organizate pentru
a facilita stocarea, interogarea, actualizarea şi afişarea de către o mulţime de utilizatori
în mod eficient. Datele spaţiale utilizate în tehnologiile GIS se pot clasifica după: a)
precizie, b) documentele primare utilizate, c) ciclul de actualizare.
Prin referenţiere geografică (sau georeferentiere) se înţelege stabilirea relaţiei
dintre coordonatele unui punct pe o foaie plană (hartă - 2D) şi coordonatele geografice
reale din teren (pe suprafaţa Pământului – 3D, aproximată printr-un elipsoid de
referinta).
Bazele de date geografice lucrează cu multiple arhitecturi de SGBD, pot avea
diverse mărimi şi un număr variabil de utilizatori. Ele pot varia de la baze de date mici,
cu un singur utilizator, construite pe baza Microsoft Jet Engine, până la baze de date
mari împărţite de un grup de utilizatori.
Responsabilitatea pentru managementul seturilor de date geografice este
împărţită între software-ul GIS şi cel al SGBD. Anumite aspecte, cum ar fi stocarea pe
disc, definirea atributelor, procesarea interogărilor asociative şi tranzacţiile
multiutilizator sunt delegate sistemului de gestiune a bazelor de date. Aplicaţia GIS este
răspunzătoare pentru definirea schemei specifice a SGBD, folosită pentru a reprezenta
diferite seturi de date geografice şi pentru logica specializată pe domeniu, care menţine
integritatea şi utilitatea înregistrărilor componente.

50
Tipul geo-bazei
SGBD Note
de date
Microsoft Jet Engine -editare de către utilizator
(Access) unic
-limită de mărime de 2
Single user - Personală
GB
-fără suport pentru
versiune
Format propietar, formată Poate sa stocheze pană la
Single user - din fișiere ce pot fi 250 TB pentru fiecare
FileGeodatabase salvate atât pe Windows FeatureClass (strat
cât și Linux vectorial)
-Oracle -necesită ArcSDE
-IBM DB2 -editare multiutilizator
Multi-utilizator, cu -IBM Informix -fluxuri bazate pe versiune
versiuni -Microsoft SQL Server -dimensiune şi număr de
-PostgreSQL utilizatori până la limitele
SGBDR
Caracteristicele bazelor de date geografice personale şi multiutilizator

Baza de date geografice este implementată folosind aceeaşi arhitectură de


aplicaţie multistrat care se regăseşte şi în alte SGBD avansate. Obiectele geo-bazei de
date sunt păstrate ca rânduri în tabele, unic determinate, iar comportamentul este
furnizat prin logica de aplicaţie a bazei de date geografice. Un GIS conţine un SGBD
special, capabil să gestioneze date spaţiale (coordonate), să insereze şi să regăsească
informaţii în funcţie de localizarea acestora în teritoriu si de elementele descriptive.
Nucleul bazei de date geografice este schema standard a bazei de date relationale
(o serie de tabele, tipuri de coloane, indecşi etc).
Scopul acestor obiecte este de a expune clienţilor un model de informaţii GIS
de nivel înalt şi de a stoca implementarea detaliată a acestui model în orice mod de
stocare, adecvat, de exemplu, în tabele standard ale SGBD-ului, în sisteme de fişiere şi
ca documente XML.
Stocarea în baza de date geografice include atât schema şi baza de reguli pentru
fiecare set de date geografice, cât şi stocarea tabelară simplă a atributelor şi datelor
spaţiale. Schema bazei de date conţine definiţiile, restricţiile de integritate şi
comportamentul pentru fiecare set de date geografice.
Pentru reprezentarea datelor spațiale se folosesc trei tipuri modele: modelul
vectorial, care este foarte apropiat de cel utilizat pentru reprezentarea hărţii, modelul
raster, care descrie suprafaţa Pământului ca o matrice formată din elemente omogene,
similar modelului utilizat pentru reprezentarea imaginilor şi modelul TIN (Triangular
Irregular Network) care reprezintă forma suprafeţelor in spatiu tridimensional.
In modelul de date vectorial, obiectele GIS sunt reprezentate având o delimitare
bine definită în spaţiu. Poziţia şi forma obiectelor este reprezentată utilizând un sistem
de coordonate x, y (Cartezian). Un punct este reprezentat printr-o singură pereche de
coordonate x, y. O linie este reprezentată printr-un şir ordonat de perechi de coordonate
x, y. Un poligon este reprezentat printr-un şir de perechi de coordonate x, y care definesc
segmentele liniare ce delimitează poligonul. Modelul vectorial reprezintă suprafeţele
apeland la izolinii; de exemplu, altimetria se reprezintă prin curbe de nivel. Modelul
vectorial este foarte eficient pentru desenarea hărţilor dar este mai puţin eficient pentru

51
analiza suprafeţelor care necesită calcule complexe pentru determinarea unor
caracteristici cum ar fi panta suprafeţei în orice punct sau direcţia pantei.
Modelul de date raster reprezintă o zonă de teren ca o matrice (grilă) formată
din celule rectangulare uniforme, fiecare celulă având o valoare. Grila este reprezentată
într-un sistem de coordonate x, y (Cartezian). Coordonatele x, y ale unei celule se
calculează pe baza coordonatelor unui punct de referinţă, de obicei unul din colţurile
grilei, ţinând cont de poziţia celulei în grilă (numărul liniei/coloanei) şi de dimensiunile
celulei pe x şi pe y. Valoarea unei celule indică obiectul situat în acea poziţie. Există
trei metode pentru stabilirea valorilor unei celule: clasificarea obiectelor, în care fiecare
valoare indică un anumit tip de obiecte cum ar fi drum, zonă urbană, tip de sol; indicarea
valorii culorii (nivelului de gri) înregistrate într-o imagine (fotografie); indicarea unei
măsurători relative cum ar fi altitudinea faţă de nivelul mării, înălţimea unei clădiri faţă
de nivelul solului, etc. In modelul raster, obiectele nu au o delimitare bine-definită iar
relaţiile spaţiale dintre obiecte sunt continute implicit. Reprezentând celule
rectangulare, forma obiectelor nu este foarte exactă şi depinde de rezoluţia celulei. Prin
rezoluţia celulei se înţelege dimensiunea suprafeţei de teren reprezentate de o celulă; cu
cât suprafaţa reprezentată este mai mică, cu atât rezoluţia este mai bună şi deci datele
mai precise, în schimb este nevoie de volume mari pentru stocarea datelor şi de un timp
de prelucrare mai îndelungat. Precum modelul vectorial, modelul raster permite
reprezentarea obiectelor GIS punctuale, liniare sau poligonale. Un obiect punctual este
reprezentat printr-o valoare într-o singură celulă a grilei. Un obiect liniar apare ca o
serie de celule adiacente care redau lungimea şi forma obiectului. Un obiect poligonal
este reprezentat ca un grup de celule adiacente care redau aria şi forma obiectului.
Modelul raster este foarte eficient pentru reprezentarea imaginilor şi pentru
implementarea funcţiilor analitice spaţiale (suprapunerea obiectelor, identificarea
întinderii unui fenomen, operaţii pe vecinătăţi). In modelul raster suprafeţele sunt
reprezentate prin indicarea în fiecare celulă a valorii cotei corespunzătoare punctului
din centrul celulei (o latice). Prin urmare, acest model permite implementarea cu
uşurinţă a operaţiilor asupra suprafeţelor (calculul pantei, direcţiei pantei, interpolarea
curbelor de nivel).
Introducerea datelor în sistem este componenta cu cele mai mari cerințe din
punctul de vedere al resurselor de timp din cadrul unui GIS. Fiecare apariție a obiectelor
dintr-o hartã trebuie specificatã, la fel si relațiile spațiale dintre ele. Acestea se pot
realiza prin:
 digitizarea datelor care nu se află în format numeric, adica într-o forma
recunoscuta de catre calculator
 scanarea datele deja existente pe hartie, filme PET etc.
 măsurători în teren
 prelucrarea imaginilor de teledetecţie, fotogrametrie digitală
 conversia datelor din alte formate

Intretinerea si actualizarea datelor geografice reprezinta o altă etapa, practic cu


desfasurare continuă in timp si care necesita adesea resurse speciale dedicate (hardware,
software si personal).
Echipamentele care pot fi folosite in vederea obținerii de date sunt:
 camerele foto digitale sau analogice pentru realizarea fotografiilor
aeriene

52
 radarul subpamantean pentru detectarea rețelelor subterane. Acesta
foloseste unde de înalta frecvență si funcționeaza pe principiul sondării
pe baza de ecou.
 sateliții care oferă imagini satelitare. Acestea sunt imagini raster care pot
fi scanate si apoi transformate în imagini vectoriale folosind programme
speciale de conversie
 sistemele de poziționare globală (GPS)
Pe lânga introducerea datelor grafice într-o bază de date spațială trebuie
introduse si atributele, acestea fiind informații aditionale despre entitatile din sistem,
cum ar fi de exemplu: cantitatea de precipitatii care a fost inregistrata pentru o anumita
perioada a anului, sau tipul de sol care caracterizeaza entitatea respectiva, in caz ca
aceasta reprezinta un teren agricol, etc. Introducerea acesor atribute se poate face
manual, de la tastatura, sau se introduc din fisiere digitale existente.
Întotdeauna în GIS datele introduse trebuie sa fie verificate, deoarece pot să
apară erori. Acestea pot sa apară în timpul procesului de introducere a datelor sau pot
fi deja existente în datele de intrare, ducând în final la interpretari gresite ale
rezultatelor. Multe din erori apar la scanare deoarece scanerele electronice înregistreazã
petele de pe o hartã cu aceeasi acuratețe cu care captureaza elementele interesante de
pe harta. Corecțiile se vor realiza cu ajutorul unor functii de filtrare in domeniul
frecventei, transformata Fourier jucând un rol important aici.
În bazele de date spațiale vor fi gestionate două categorii de date:
 spaţiale (elemente grafice localizate prin coordonate specifice hartii ), care
reprezintă poziţia şi forma obiectelor (fenomenelor) terestre utilizând trei tipuri
fundamentale de entităţi grafice :
o puncte
o linii
o poligoane
la care se adauga elemente de tip text (etichete)
 descriptive (negrafice), care reprezintă informaţii despre obiectele (fenomenele)
terestre continute intr-o hartă utilizând:
o atribute (întrebări)
o valori ale atributelor (răspunsuri)

53
Data spaţială este un termen utilizat pentru a descrie datele care aparţin
spaţiului ocupat de obiectele unei baze de date. In sens larg, datele spaţiale pot fi:
puncte, linii, poligoane, suprafeţe, volume (date avînd mai multe dimensiuni), numite
generic, vectori.
Punctul este caracterizat prin locaţia sa, nu ocupă spaţiu şi nu are asociată o
arie sau un volum. Intr-o bază de date punctul se stochează printr-o măsură directă a lui
sau printr-o măsură indirectă (transformare). Data de tip raster este un exemplu de
folosire a măsurii directe a unui punct şi include harta de pixeli (imaginea bitmap). De
exemplu, o imagine preluată din satelit realizează o corespondenţă directă între un pixel
de imagine şi suprafaţa acoperită de el pe suprafaţa terestră.
Linia se caracterizează prin existenţa a două puncte (cel de început şi cel de
sfîrşit) urmând ca punctele intermediare să fie generate prin ecuaţia dreptei. Un obiect
spaţial este descris, de obicei, printr-o colecţie de segmente ca de exemplu cursul unui
rîu sau un drum.
O dată spaţială de tip poligon se caracterizează printr-o locaţie şi un contur.
Locaţia este dată de un punct fix pentru a ancora poligonul în spaţiu (de obicei este
punctul din centrul regiunii). In spaţiul bidimensional, conturul se vizualizează ca o
linie iar în spaţiul tridimensional ca o suprafaţă. Data de tip regiune stocată într-o bază
de date este o aproximare geometrică a unui obiect spaţial (de exemplu, judeţele unei
ţări, lacurile etc).
Coordonatele unui punct se precizează printr-o pereche de valori (x,y) sau prin
tripleta (x,y,z), unde z exprimă altitudinea punctului. Coordonatele punctelor furnizează
datelor spaţiale două perspective: una geografică care depinde de sistemul de
coordonate folosit şi referă poziţia şi eventual dimensiunea elementului în spaţiul real
precum şi una ecran ce ţine de afişarea datelor spaţiale pe monitorul calculatorului.
Formatul de stocare a datelor spatiale ARC/INFO coverage utilizează un model
de date geo-relaţional bazat pe modelul vectorial pentru reprezentarea informaţiilor
spaţiale (poziţie şi formă) şi pe modelul relaţional al bazelor de date pentru
reprezentarea informaţiilor aspaţiale (atribute descriptive). In modelul de date
ARC/INFO coverage, informaţiile geografice sunt abstractizate prin utilizarea unor
concepte simple - puncte, linii, poligoane, fiecare obiect geografic fiind pus în
corespondenţă cu una sau mai multe tabele de atribute. Modelul de date ARC/INFO
coverage stă la baza reprezentării de:
 obiecte geografice simple (punctuale, liniare, poligonale)
 obiecte geografice complexe (regiuni, trasee şi secţiuni)
 obiecte auxiliare (adnotări, puncte de control)
 obiecte conceptuale (teme, vederi)
Formatul ARC/INFO coverage memorează coordonate numai pentru puncte,
arce şi noduri şi utilizează relaţiile topologice pentru a defini poligoane şi reţele.
Poligoanele şi reţelele stau la baza definirii de regiuni şi rute. Formatul ARC/INFO
coverage permite integrarea unei mari varietăţi de date geografice: imagini video,
înregistrări de teledetecţie, desene CAD, documente scanate, fişiere text, fişiere
RDBMS comerciale.
Modelul de date ARC/INFO coverage utilizează următoarele două concepte
de bază:
a) Structura de date ARC-NOD:
Aceasta este cea mai eficientă structură pentru a reprezenta date de tip
vectorial. In această structură, arcele sunt determinate prin noduri iar poligoanele sunt
construite prin arce. Nodurile definesc cele două capete ale unui arc; două sau mai multe
arce se pot inter-conecta printr-un nod comun. Un arc este format din cele două noduri

54
extreme şi de o serie de puncte intermediare (de inflexiune) care dau forma arcului.
Nodurile şi punctele intermediare sunt reprezentate ca perechi de coordonate x, y. Un
poligon este format dintr-o serie de arce ce definesc conturul acestuia. In acest mod este
eliminată duplicarea datelor: frontiera comună a două poligoane adiacente este
memorată o singură dată; un punct comun mai multor arce este reprezentat o singură
dată. Această structură asigură nu numai stocarea eficientă a datelor şi implicit
prelucrarea mai rapidă a unui mare volum de date, ci este şi un suport foarte eficace
pentru definirea relaţiilor spaţiale dintre obiecte: poligoanele care utilizeaza cel puţin
un arc comun sunt vecine, o serie de arce interconectate prin noduri comune formează
un traseu ce poate fi străbătut, etc.
b) Topologia
Acesta este un concept matematic utilizat pentru a reprezenta explicit relaţiile
spaţiale dintre obiecte (vecinătate, continuitate, interconexiune). Cele trei concepte
topologice specifice
formatului de date ARC/INFO coverage sunt:
 conectivitate (relaţia ARC-NOD) - arcele se inter-conectează prin
noduri (în structura coverage, informaţiile spaţiale asociate arcelor se
memorează ca liste de perechi de coordonate X, Y corelate cu liste de
triplete ARC, FROM-NODE, TO-NODE); toate arcele care au un nod
comun se conectează între ele.
 definirea ariei (relaţia POLIGON-ARC) - arcele care se
interconectează pentru a delimita o suprafaţă închisă definesc un
poligon (în structura coverage, informaţiile spaţiale asociate
poligoanelor se memorează ca liste de arce alcătuind frontiere)
 sens (relaţia STÂNGA- DREAPTA) - fiecare arc are o direcţie şi câte
un poligon de fiecare parte (în structura coverage, se memorează şi liste
de triplete ARC, LEFT-POLY, RIGHT-POLY); poligoanele care au un
arc comun sunt adiacente, un poligon special fiind 'poligonul univers'
('poligonul extern') reprezentând exteriorul zonei de interes.
Crearea şi memorarea topologiei în structura coverage aduce o serie de
avantaje: datele sunt reprezentate eficient, evitându-se duplicarea datelor, la economia
de memorie adăugându-se viteza crescută de prelucrare pentru volume mari de date. In
plus, topologia stă la baza implementării funcţiilor analitice spaţiale care sunt cheia
oricărui GIS: modelarea curgerii unui fluid printr-o reţea, combinarea poligoanelor
adiacente având caracteristici similare, identificarea obiectelor adiacente, suprapunerea
mai multor obiecte geografice, etc. Definirea ariei are ca rezultat stocarea eficientă a
datelor: deşi un arc poate aparea în lista de arce pentru mai multe poligoane, de fapt el
este stocat o singură dată. Definirea ariei asigură ca frontierele poligoanelor adiacente
să nu se suprapună. Relaţiile topologice sunt utilizate pentru a efectua funcţii analitice
fără a fi necesar accesul la poziţiile absolute stocate în fişierele de coordonate. În acest
fel prelucrarea datelor este mai rapidă şi pot fi prelucrate volume mai mari de date.

Un sistem de coordonate este un sistem pentru referirea locaţiilor


caracteristicilor spaţiale pe suprafaţa pamântului. Deoarece sistemele informatice
geografice lucrează cu date geografice, sistemul de coordonate joacă un rol cheie într-
un proiect GIS. Sunt două tipuri de sisteme de coordonate: geografice şi proiecţii.
Un sistem de coordonate geografice este format din longitudine şi latitudine.
Prin longitudine se înțelege unghiul format între primul meridian și poziția pe glob, în
timp ce prin latitudine se înțelege unghiul format între ecuator și poziția pe glob.

55
Datele spaţiale sunt frecvent puse în corelaţie cu atribute convenţionale (date
nonspaţiale). De exemplu, un judeţ se descrie spaţial printr-un poligon (regiune) dar şi
nonspaţial prin nume, suprafaţă, număr de localităţi, populaţie etc. In funcție de modul
de organizare a datelor și al realizării legăturii dintre atributele nonspațiale și cel spațial
s-au definit două modele:
Modelul de date georelațional implică stocarea datelor în formate
independente care se bazează pe divizarea atributelor în două entități și stocarea lor
separată. Astfel, o dată spațială este alcătuită din atributul spațial, care se stochează
separat de atributele nonspațiale, legătura fiind făcută prin intermediul unui câmp de
identificare (ID), ce are rolul de a combina, în mod coerent, cele două tipuri de atribute.
Legătura dintre entități se poate face bidirecțional adică fie de la cele spațiale către cele
nonspațiale sau invers.
Stocarea datelor spațiale prin modelul geobază de date presupune stocarea atât
a atributelor spațiale cât și a celor nonspațiale, împreună, într-o tabelă de atribute.
Câmpul care conține atributul spațial este de tip vector (geometric). Atributele spaţiale
ca şi cele nespaţiale apar şi la nivelul conceptual. Astfel, valoarea unui atribut spaţial
este comună tuturor atributelor nespaţiale dintr-un tuplu. Tuplurile unei tabele care
conţine un atribut spaţial pot fi vizualizate atît geometric (spaţial) cît şi în mod clasic,
relaţional (tabelar).
O problemă importantă a sistemului care gestionează baza de date spaţială o
constituie efectuarea legăturii dintre datele spaţiale ce sunt stocate în structuri de date
specifice, cu restul datelor nespaţiale.
Două legături sunt menţionate între aceste tipuri de date care caracterizează un
anumit obiect: legături înainte şi înapoi. Acestea definesc termenul de relaţie spaţială.
Legătura înainte este utilizată la accesarea informaţiilor spaţiale ale unui
obiect, pornind de la informaţiile lui nespaţiale.
Legătura înapoi foloseşte la regăsirea informaţiei nespaţiale a unui obiect
pornind de la informaţia lui spaţială.
Datele spaţiale sunt stocate în structuri de date spaţiale. Dintre acestea, un loc
important îl ocupă cele ierarhice care sunt bazate pe principiul descompunerii recursive.
Avantajele acestor tipuri de structuri rezultă din faptul că sunt compacte, depind de
natura datelor şi permit realizarea operaţiilor de interogare în mod eficient. O astfel de
structură de date este quadtree şi are la bază principiul descompunerii recursive, similar
metodei divide-et-impera. Ea se poate utiliza la descrierea mai multor elemente
aparţinînd clasei datelor spaţiale ca de exemplu: puncte, linii, poligoane etc.
O dată spaţială ce exprimă o regiune poate fi reprezentată fie prin interiorul ei,
fie prin conturul ei. Se presupune, în descrierea procesului de construire a arborelui,
plecînd de la o imagine, că o regiune este reprezentată de interiorul ei.
Structura quadtree se bazează pe subdivizarea succesivă a unei imagini în
patru cadrane de mărimi egale. Dacă un cadran nu conţine numai valoarea 1 sau numai
valoarea 0, el va fi din nou subdivizat în patru cadrane şi aşa mai departe pînă sunt
obţinute cadrane ce au fie valoarea 1 fie 0. Valorile 1 respectiv 0 semnifică faptul că
zona aparţine sau nu regiunii respective.
Exemplu:
Pentru exemplificare se va considera imaginea de mai jos (a) și se va face
reprezentarea

56
ei binară (bitmap). Prin împărţirea succesivă în cadrane, se observă că zonele
astfel obţinute (cadranele) fie aparţin regiunii fie nu. De exemplu, dacă regiunea este
omogenă din punct de vedere a culorii atunci cadranele care acoperă regiunea trebuie
să aibă aceeaşi culore.

Cadranele obţinute în urma procesului de divizare a spaţiului se pot reprezenta


prin intermediul unui arbore numit quadtree. Structura quadtree este în esenţă un arbore
oarecare ce conţine noduri avînd semnificaţiile:
 rădăcina corespunde imaginii în ansamblu;
 nodurile frunză corespund acelor blocuri pentru care nu mai sunt
necesare subdivizări; blocurile fie aparţin regiunii (1) fie sunt în afara
ei (0);
 celelalte noduri reprezintă cîte un cadran al regiunii care a necesitat o
subdivizare.
Pentru orice nod ce nu este frunză, fii lui corespund cadranelor în ordinea NE
(I), SE (II), SV (III), NV (IV).
Structura quadtree poate fi diferită în funcţie de:
a) Tipul de dată pe care o reprezintă şi care poate fi: punctul, linia, curba,
suprafaţa şi regiunea.
b) Principiul care stă la baza procesului de descompunere care se poate face în
părţi egale la fiecare nivel (descompunere regulată) sau în m părţi de mărimi diferite în
funcţie de data iniţială;
c) Rezoluţia descompunerii care poate fi variabilă

57
Această structură poate fi de asemenea utilizată la reprezentarea imaginilor în
trei sau mai multe dimensiuni. Varianta cu trei dimensiuni se numeşte octree.
Modelul de construire a acestui arbore presupune ca imaginea să fie încadrată
într-un cub care va fi recursiv subdivizat în 8 cuburi egale şi aşa mai departe pînă cînd
sunt obţinute regiuni uniforme din punct de vedere a culorii ori se ajunge la un anumit
nivel predefinit de descompuneri.
Dezvoltarea unei structuri ierarhice este avantajoasă deoarece se poate folosi
la procesele de interogare a datelor spaţiale dar şi pentru că se economiseşte spaţiul de
memorie necesar reprezentării unor astfel de date.
Reprezentarea punctelor se face în funcţie de operaţiile care urmează să se
execute cu aceste date. Dintre multiplele moduri de reprezentare a punctelor, adecvată
este structura de date PR quadtree (P pentru puncte şi R pentru regiuni), deci o adaptare
a structurii quadtree la tipuri bine precizate de date spaţiale. Această structură se
bazează pe o descompunere regulată care urmăreşte asocierea unui punct cu un cadran.
Procesul de construire este similar cu cel al structurii quadtree, diferenţa este că
nodurile frunză fie nu conţin nimic, fie conţin puncte prin valorile coordonatelor lor. In
figura de mai jos se poate observa corespondenţa dintre puncte şi cadrane care stă la
baza construirii arborescenţei.
Dezavantajul metodei constă în faptul că, dacă punctele sunt foarte apropiate,
atunci nivelul maxim de descompunere poate fi foarte mare. Avantajul este că structura
devine atractivă în cazul în care prelucrarea datelor spaţiale implică operaţii de căutare.

Exemplu: determinarea oraşelor din nord-estul ţării. Oraşele vor fi căutate în


regiunile care compun cadranul NE al imaginii (Suceava şi Iaşi), lucru uşor de realizat
avînd în vedere modul de construire a structurii quadtree.

In concluzie, se poate spune că structura quadtree este dinamică în sensul că poate fi


adaptată cu uşurinţă la mai multe tipuri de date spaţiale.

Pentru manipularea datelor spaţiale este nevoie ca acestea să fie reprezentate


în diferite forme. O modalitate constă în a utiliza structuri de date bazate pe ocuparea

58
spaţială a datelor. Acestă metodă presupune descompunerea spaţiului în regiuni numite
partiţii. De aceea, metoda este cunoscută sub numele de metoda partiţionării.
Partiţionarea datelor spaţiale se bazează pe conceptul minimizării ariei ocupate de
partiţie. In acest caz, obiectele spaţiale sunt grupate în ierarhii şi apoi ele sunt stocate în
alte structuri de date. Structurile de indexare a datelor spaţiale multidimensionale au la
bază două abordări:
 prima se bazează pe observaţia că data spaţială ocupă un subspaţiu a
spaţiului multidimensional;
 cea de-a doua se bazează pe faptul că data fiind multidimensională, un
număr mic de dimensiuni stochează majoritatea informaţiei.

Structura arborescentă R (Rectangle tree) este similară ca reprezentare şi mod


de exploatare cu cea anterioara. Ea are mai multe variante proiectate în scopul
organizării unei colecţii de date spaţiale prin reprezentarea lor în dreptunghiuri n
dimensionale.
Fiecare nod în arbore corespunde celui mai mic dreptunghi n dimensional care
include fii lui. Nodurile frunză conţin pointeri ce referă datele spaţiale din baza de date.
Obiectele sunt reprezentate prin cele mai mici dreptunghiuri care le conţin.
Arborele R este aplicat unei tabele cu tupluri reprezentînd date spaţiale, fiecare
tuplu avînd un unic identificator care poate fi utilizat la regăsirea lui.
Arborele R conţine noduri frunză de forma ( I, i_id ),
unde:
I - un dreptunghi n dimensional ce reprezintă o cutie ce mărgineşte obiectul
indexat;
i_id - identificatorul tuplului şi se referă la înregistrarea din tabelă ce conţine
obiectul mărginit de I.
I = ( I0, I1, - - -, In-1 ),
unde:
n - numărul de dimensiuni;
Ii - un interval închis [a, b] ce precizează extinderea obiectului pe dimensiunea
i. Astfel, Ii poate avea una sau ambele limite egale cu ∞ indicînd faptul că obiectul se
extinde la ∞.
Nodurile ce nu sunt frunze în arborele R au următoarea formă: ( I, pfiu),
unde:
pfiu - adresa nodului mai mic în arborele R;
I - un dreptunghi ce acoperă toate dreptunghiurile din intrarea nodurilor mai
mici.
Se presupune că un nod conţine maxim M elemente iar m≤ M/2 este un
parametru ce specifică numărul minim de elemente dintr-un nod. Un arbore are
proprietatea că un nod trebuie să conţină între m şi M elemente dacă el nu este rădăcină.
Ca exemplu, se consideră colecţia de segmente de mai jos.

59
In figura de mai jos se prezintă arborele R asociat colecţiei de segmente din
figura de mai sus, nodurile avînd capacitatea de maxim două elemente. Se poate observa
modul de partiţionare a spaţiului în vederea încadrării obiectelor spaţiale şi relaţia de
incluziune dintre partiţii, fiind descrisă aceeaşi relaţie de partiţionare şi includere prin
intermediul structurii arborescente R. Zona de intersecţie reprezintă procentul din
volum care este acoperit de mai mult de un dreptunghi. Dacă un nod al unui arbore R
conţine n dreptunghiuri {R1,...,Rn}, zona de intersecţie poate fi definită atfel:

unde, || A|| - indică volumul acoperit de A.

Un alt concept legat de intersecţia suprafeţelor este greutatea intersecţiei care


reprezintă procentul de obiecte care aparţin porţiunii de intersecţie din spaţiu.

60
unde:
 |A| , indică numărul de obiecte conţinute în A;
 p, obiect spaţial.
O dată spaţială se asociază cu un singur dreptunghi, de exemplu, în figura de
mai sus, segmentul i este asociat dreptunghiului R5 cu toate că şi partiţiile R1, R2 şi R4
partajează o suprafaţă din R5. In aceste condiţii dacă se doreşte să se determine care
obiect este asociat cu un punct particular vor fi necesare mai multe căutări în baza de
date datorită faptului că acel punct poate fi conţinut în mai multe partiţii.
Algoritmii de căutare, inserare şi ştergere sunt construiţi folosind aceleaşi
principii utilizate la implementarea structurii arborescente. Informaţiile ce se
manipulează se referă la marcarea dreptunghiului r, la cheia tuplului, respectiv la
pointerul la subarborele corespunzător.

O problemă dificilă ţinînd cont de particularitatea datelor spaţiale este aceea a


divizării nodului, adica este necesar să se dividă o colecţie de elemente între două
noduri.
Divizarea unui nod S={r1,...,rn} în două subnoduri S1={ri1,...,ris1} şi
S2={ri2,...,ris2}, (S1≠∅ şi S2≠∅) este definită ca:
Diviz(S)={ (S1,S2) / S=S1∪S2∧S1∩S2 =∅ }.

In urma procesului de divizare a nodului pot să apară cazurile:


1. zonă de intersecţie minimală, dacă || S1 ∩ S2 || este minimă;
2. zonă de intersecţie inexistentă, dacă || S1 ∩ S2 || = 0;
3. echilibru dacă -ε ≤ |S1| − |S2 | ≤ ε.

Deoarece decizia de a vizita un nod depinde dacă dreptunghiul aferent lui


include zona căutată, rezultă că aria totală de acoperire a celor două dreptunghiuri după
divizare trebuie să fie minimă.
Comparînd figurile de mai jos se observă o mai bună încadrare, avînd în vedere
criteriul enunţat, în figura a.
In literatura de specialitate sunt prezentaţi mai mulţi algoritmi ce realizează
acest lucru avînd performanţe diferite.
Algoritmul de divizare Quadratic este recunoscut datorită eficienţei sale şi
distribuie un set de M+1 elemente între două noduri.

61
In primul pas se vor alege două elemente din cele M+1 ce vor fi puse, cîte unul,
în cele două noduri. In acest sens, se va calcula ineficienţa grupării pentru toate
elementele. Astfel, pentru fiecare pereche ri, rj, se compune un dreptunghi R incluzînd
ariile ri, rj. Se calculează:
d = aria (R) - aria (ri) - aria(rj ) şi se alege în final perechea pentru care rezultă
cea mai mare valoare d.
In al doilea pas se controlează dacă toate elementele au fost distribuite la cele
două noduri. In caz afirmativ algoritmul se opreşte. Altfel, dacă un nod are puţine
elemente, restul rămase nedistribuite vor fi asignate la el pentru a avea numărul minim
m şi în acest caz algoritmul se opreşte.
In al treilea pas se selectează următorul element pentru a fi asignat la unul
dintre noduri. Pentru fiecare element rămas r se calculează d1 aria mărită necesară
pentru includerea dreptunghiurilor elementelor din primul nod plus zona dată prin r. Se
calculează d2 similar pentru elementele nodului al doilea. Se găseşte astfel elementul cu
cea mai mare preferinţă pentru un grup. Se alege acela pentru care diferenţa între d1 şi
d2 este maximă. Acesta se va adăuga la grupul al cărui dreptunghi acoperitor va trebui
să fie cel mai puţin mărit pentru a cuprinde elementul. Legătura se rezolvă şi prin
adăugarea elementelor la nodul cu o arie mai mică de cuprindere sau la unul cu mai
puţine intrări. Apoi se continuă cu pasul doi.
Acest algoritm nu garantează găsirea celui mai mic dreptunghi posibil de
încadrare dar performanţele lui sunt destul de bune luînd în considerare necesarul de
timp de prelucrare pentru obţinerea rezultatului.

Partiţionarea spaţiului în partiţii disjuncte a dus la crearea unei structuri


+
derivate din arborele R şi anume R . Deoarece regiunile sunt disjuncte, înseamnă că
pot fi obiecte care nu se încadrează doar într-o singură partiţie. De aceea, ele se vor
descompune în subobiecte, fiecare aparţinînd unor regiuni diferite. Devine, astfel,
important să se determine partiţiile care conţin o anumită dată spaţială.
+
In figura de mai jos se prezintă un arbore tip R pentru aceeaşi colecţie de
segmente. Se observă că fiecare obiect este asociat cu toate partiţiile care-l intersectează
deci, pot fi mai multe căi de la rădăcină pînă la unul şi acelaşi obiect. De exemplu, în
figura de mai jos segmentele c şi f apar în două noduri diferite, în timp ce segmentul i
apare în trei noduri.

62
In literatura de specialitate s-a demonstrat că structurile de indexare bazate pe
arbori R nu sunt adecvate pentru date spaţiale reprezentate într-un spaţiu
multidimensional.
O structură performantă de indexare a datelor spaţiale multidimensionale cu
număr mare de dimensiuni este arborele X (eXtended node tree). Structura arborelui X
este prezentată în figura de mai jos.
Se observă că el conţine trei tipuri de noduri:
 noduri de date care sunt la nivelul frunzelor şi fac legăura cu datele
spaţiale care se indexează;
 noduri directoare normale ce au rol în a dirija căutarea prin arbore şi
sunt similare nodurilor interne dintr-un arbore R;
 supernoduri care sunt în fapt noduri directoare de mărime variabilă.

Scopul principal al acestor supernoduri este să evite divizarea nodurilor


directoare, care ar avea ca rezultat construirea unei structuri ierarhice ineficiente.
Arborele X este diferit de arborele R cu noduri de dimensiuni mari prin faptul că el
conţine noduri de dimensiuni mai mari doar dacă este necesar. Supernodurile sunt create
în timpul inserării cînd capacitatea unui nod trebuie depăşită şi nu se poate evita acest
lucru prin alte procedee.
Pentru un arbore X sunt două cazuri extreme:
1. nici un nod director nu este supernod;
2. există doar un singur supernod ce formează rădăcina arborelui, în rest sunt
doar noduri de date.
In primul caz, arborele X are o organizare complet ierarhică a nodurilor
directoare şi este similar unui arbore R. In al doilea caz, supernodul rădăcină corespunde
nivelului celui mai de jos din ierarhia nodurilor directoare ale unui arbore R.
Performanţele unui astfel de arbore depinde de viteza de prelucrare secvenţială a
supernodului.

63
După ce datele sunt introduse în bazele de date, toate pachetele de programe
GIS pun la dispoziție instrumente ce permit extragerea informațiilor prin interogări, în
vederea obținerii unui subset de date. Interogarile spațiale sunt cele mai importante, si
presupun selecția entităților în funcție de locație sau de relațiile spațiale cu celelalte
entități. Alte tipuri de interogari foarte utile sunt interogarile grafice ( ˝care sunt valorile
atributelor acestor entități?˝), interogarile atribut (˝unde sunt localizate entitățile cu
aceste valori ale atributelor?˝) sau interogarile formulate cu ajutorul limbajelor de
programare (SQL) de genul: ˝care sunt orașele cu o suprafață mai mică de X mp aflate
la o distanță mai mica de Y m de o anumita sosea?˝. Toate aceste tipuri de interogari
ofera GIS-ului posibilitatea de a efectua analize si modelări ale datelor spațiale, ceea ce
îl distinge de celelalte tipuri de sisteme de informații.
În urma “interogării” se face analiza datelor (în special analiza geografică) iar
rezultatele analizei sunt apoi comunicate prin intermediul hărților tematice, rapoartelor și
graficelor.

Proiectarea unei baze de date spațiale


Proiectarea bazei de date presupune determinarea zonei de studiu, a sistemului de
coordonate utilizat, a straturilor necesare studiului, a elementelor (obiectelor geografice) incluse
în fiecare strat, a atributelor necesare descrierii fiecarui tip de element, a modului de codificare
si organizare a atributelor.

Proiectarea bazei de date se realizeaza în trei pasi:

Pasul 1. Identificarea obiectelor geografice si a atributelor lor si organizarea lor pe


straturi
In general, organizarea datelor pe straturi se face tinând cont de doua criterii:
 tipul datelor: punct, linie sau poligon;
 tema reprezentata (soluri, drumuri, etc.).
Pasul 2. Definirea atributelor
Pentru fiecare atribut se specifica modul de codificare si spatiul necesar memorarii
valorilor admise. In plus, pentru întreaga baza de date se construieste un dictionar în care, pentru
fiecare strat se precizeaza numele atributelor asociate si pentru fiecare atribut se indica valorile
si semnificatia valorilor posibile.
Pasul 3. Asigurarea registratiei coordonatelor între straturi
Pentru o corecta registratie, acele elemente care apar în mai multe straturi (de exemplu
conturul zonei de studiu, linia de coasta litorala) se vor digitiza o singura data într-un strat aparte
- un sablon. În continuare, toate celelalte straturi se vor construi pornind de la acest strat sablon
si adaugând elementele specifice.

64
Baze de date în ArcGIS. Dicționar de termeni

Formatul de date shapefile


Prin acest format se poate reprezenta un singur strat. Acest format nu are un
mecanism de colectie a straturilor. Atributele sunt stocate în fisiere dBASE. Tabelul
asociat contine un câmp numit "Shape" în care sunt stocati identificatorii prin
intermediul carora se face legatura cu datele spatiale. Formatul de date shapefile contine
cel putin trei fisiere: shapefile.shp, shapefile.shx, shapefile.dbf
În fisierul shapefile.shp este stocata informatia spatiala: coordonatele
punctelor sau ale vertexurilor care formeaza liniile sau poligoanele. Fisierul
shapfile.shx reprezinta un indice al fisierului shapefile.shp, iar în fisierul shapefile.dbf
sunt stocate atributele. Optional, poate exista un fisier shapefil.prj care contine
informatii referitoare la proiectia datelor. Formatul datelor shapefile nu este un format
topologic, dar sunt stocate în mod implicit informatii topologice.

Formatul de date coverage


Un coverage este o colecție de straturi. În acest caz, datele sunt stocate sub
forma unui director. Acest format de date este un format topologic, în sensul ca relatiile
spatiale dintre elemente sunt tinute minte în fișiere separate. De aceea, pentru acest tip
de date trebuie construita topologia, care poate fi de tip punct, linie sau poligon. Un
coverage poate avea topologie compusa de linie si punct sau de linie si poligon, dar nu
poate avea în acelasi timp topologie de punct si poligon. Atributele elementelor sunt
stocate în tabele INFO care au un câmp "Cover-ID" care face legatura între tabele si
informatia spatiala. Coverage-urile sunt stocate în workspace-uri ArcInfo. Acestea sunt
directoare care contin un subdirector special numit INFO. În acest subdirector sunt
stocate tabele INFO. Administrarea coverage-urilor si a workspace-urilor se face doar
cu instrumente ArcInfo. Nu trebuie folosite comenzi al sistemului de operare pentru ca
acestea nu respecta legatura dintre coverage si tabelul de atribute din INFO.
Fomatul de date Geodatabase
În formatul de date Geodatabase se pot stoca straturi sau colecții de straturi
(feature datasets). Atât clasele de elemente, cât si atributele sunt stocate în tabele ale
RDBMS-ului (Relational Database Management System). Spre deosebie de toate
celelalte tipuri de date, în geodatabase este stocat si comportamentul datelor. Tabelul
RDBMS contine un câmp "Shape" care stocheaza informația spațială.
Formatul de date CAD
Datele geografice pot fi stocate si în fisiere Computed Aided Design (CAD),
cum ar fi fisiere DXF, DWG sau DGN. Fisierele CAD reprezinta o colectie logica care
permite accesarea unui strat sau a tuturor stratuilor, la un moment dat. Aceste tipuri de
date pot fi editate în ArcGIS doar dupa ce au fost convertite in clase de elemente din
geodatabase sau în coverage-uri.
Dintre toate formatele de date vector, doar formatul shapefile contine un singur
strat, celelalte având posibilitatea de a stoca si colectii de straturi. Doar datele coverage
si geodatabase au topologie. Singurul model de date care permite personalizarea
elementelor este modelul geodatabase.
Date raster
Modelul de date raster reprezinta o zona de teren ca o matrice (grila) formata
din celule rectangulare uniforme, fiecare celula având o valoare. Grila este reprezentata
într-un sistem de coordonate x, y (Cartezian). Coordonatele x, y ale unei celule se
calculeaza pe baza coordonatelor unui punct de referinta, de obicei unul din colturile

65
grilei, tinând cont de pozitia celulei în grila (numarul liniei/coloanei) si de dimensiunile
celulei pe x si pe y. Valoarea unei celule indica obiectul situat în acea pozitie. Exista
trei metode pentru stabilirea valorilor unei celule: clasificarea obiectelor, în care fiecare
valoare indica un anumit tip de obiecte cum ar fi drum, zona urbana, tip de sol; indicarea
valorii culorii (nivelului de gri) înregistrate într-o imagine (fotografie); indicarea unei
masuratori relative cum ar fi altitudinea fata de nivelul marii, înaltimea unei cladiri fata
de nivelul solului, etc. În modelul raster, obiectele nu au o delimitare bine-definita iar
relatiile spatiale dintre obiecte sunt reprezentate implicit. Reprezentând celule
rectangulare, forma obiectelor nu este foarte exacta si depinde de rezolutia celulei. Prin
rezolutia celulei se întelege dimensiunea suprafetei de teren reprezentate de o celula; cu
cât suprafata reprezentata este mai mica, cu atât rezolutia este mai buna si deci datele
mai precise, în schimb este nevoie de mai multa memorie pentru stocarea datelor si deci
de un timp de prelucrare mai îndelungat. Precum modelul vectorial, modelul raster
permite reprezentarea obiectelor GIS punctuale, liniare sau poligonale. Un obiect
punctual este reprezentat printr-o valoare într-o singura celula a grilei. Un obiect liniar
apare ca o serie de celule adiacente care redau lungimea si forma obiectului. Un obiect
poligonal este reprezentat ca un grup de celule adiacente care redau aria si forma
obiectului. Modelul raster este foarte eficient pentru reprezentarea imaginilor si pentru
implementarea functiilor analitice spatiale (suprapunerea obiectelor, identificarea
întinderii unui fenomen, operatii pe vecinatati). În modelul raster suprafetele sunt
reprezentate prin indicarea în fiecare celula a valorii cotei corespunzatoare punctului
din centrul celulei (o latice). Prin urmare, acest model permite implementarea cu
usurinta a operatiilor asupra suprafetelor (calculul pantei, directiei pantei, interpolarea
curbelor de nivel).
Exista doua moduri în care pot fi stocate datele raster: ca imagini sau ca grid-
uri. În ambele cazuri, datele sunt stocate sub forma unor rânduri si coloane de celule de
dimensiune egala. Fiecare celula stocheaza o valoare. Detaliile depind de dimensiunea
celulei. Cu cât dimensiunea celulei este mai mica, cu atât datele sunt stocate mai precis.
Unele formate pot avea mecanisme de colectie.

Tabele
Un tabel este o colectie de înregistrări (rândurile tabelului) si coloane
(câmpuri). Datele care pot fi stocate într-o coloana trebuie sa fie de acelasi tip si aceste
date pot fi numere, texte, date. În cadrul aceluiasi tabel coloanele trebuie sa aiba nume
unice. Tipurile diferite de câmpuri stocheaza tipuri diferite de valori. Fiecare tip de date
spatiale are asociat un format tabelar nativ. Astfel, pentru datele de tip coverage,
tabelele sunt de tip INFO, pentru date spatiale de tip shapefile, tabelele sunt de dBASE,
iar pentru date spatiale de tip geodatabase, tabelele sunt stocate în RDBMS-ul
corespunzator. Atributele datelor spatiale pot fi stocate în tabelele elementelor sau în
tabele separate. În acest ultim caz, putem asocia tabele care pentru o coloana au valori
cheie comune.
Cheie primara
O cheie primară reprezinta o coloana a unui tabel în care sunt stocate valori
unice prin care se identifica în mod unic înregistarile. Un tabel nu poate avea decât o
cheie primara. O cheie straina realizeaza o conectare la o cheie primara a unui alt tabel.
Datele unei chei straine pot fi duplicate.
Cardinalitate
Relatia dintre doua tabele este caracterizata prin cardinalitate. Aceasta
reprezinta câte obiecte "A" sunt legate de obiectul "B". Exista trei tipuri de cardinalitate:
 one-to-one

66
 one-to-many sau many-to-one
 many-to-many
Înainte de a conecta doua tabele trebuie cunoscuta cardinalitatea relatiei care
se stabileste între ele.
Join
Tabelele pot fi conectate prin operatia numita "join". În acest caz conectarea
este logica si se presupune ca relatia este one-to-many; se poate realiza si daca relatia
este many-to-one. În general, numele câmpurilor de legatura nu trebuie sa fie identice,
dar tipul câmpurilor trebuie sa fie acelasi.
Clase de relații
Asocierea a doua tabele se poate realiza si prin intermediul unor clase de relatii.
În acest caz, tabelele sunt legate virtual, nu fizic. Caracteristici importante ale claselor
de relatii sunt:
 Nu se creeaza noi straturi
 O conectare este persitenta pâna când se îndeparteaza
 Asocierea dinte tabele este dinamica
 Se pot edita, interoga sau simboliza date in oricare dintre tabele
Clasele de relatii reprezinta asocieri mai flexibile ale tabelelor. Clasele de
relatii pot fi definite între coveage-uri sau între clasele de elemente ale unei
geodatabase. Relatia se defineste în ArcCatalog si se utilizeaza în ArcMap.
Fisiere XML
Extensible markup language este un limbaj de marcare asemanator cu limbajul
de marcare al hipertextului. HTML defineste atat datele, cat si modul in care ele sunt
prezentate. XML, pe de alta parte, ne lasa sa definim datele utilizand etichete care
adauga un inteles.
Stylesheets
Stylesheets sunt utilizate pentru a defini modul in care datele XML sunt
prezentate. Ele sunt create utilizand limbajul stylesheet extins. XSL este o multime
definita de etichete XML care pot fi utilizate pentru a interoga si a evalua datele XML.

Interogări SQL în ArcGIS

Interogările SQL în ArcGis pastrează forma prezentată în secțiunile anterioare însă


sunt si mici deosebiri față de alte SGBD-uri.
 funcție de tipul bazei de date, câmpurile pot fi delimitate cu ” ” sau [ ] dacă
spre exemplu se interoghează o bază de date “file-based data” sau o bază de
date “personal geodatabase”. Ex. “NUME” sau [NUME]
șirurile de caractere trebuie trecute folosind ‘. Ex.: NUME=’IASI’. În
expresii, șirurile de caractere sunt case sensitive, din acest motiv valoarea
căutată trebuie să coincide cu cea data în tabelul bazei de date (se pot folosi
funcțiile UPPER și LOWER. Ex. UPPER(NUME)=UPPER('Iasi'))
 Operatorul LIKE trebuie folosit împreună cu caracterele % și _ (%-
înlocuiește orice șir de caractere iar _-înlocuiește un caracter). Spre exemplu,
pentru a afișa toate județele care au numele cu A pe poziția 2 vom scrie:
NUME LIKE '_A%'

67
 Pentru numere, delimitatorul zecimal este (.) și se pot folosi oricare dintre
operatorii =, <>, >, <, >=, <= și BETWEEN. Ex.: POP92>600000.
 Subinterogările pot fi folosite doar pentru fișiere ale bazei de date (Ex.
tabele). O subinterogare poate fi utilizată folosind IN și ANY (Ex. județele
care au populația mai mare decât media se obțin folosind comanda
POP92>(SELECT AVG(POP92) FROM Judete) și comunele din județele cu
o populație peste medie se pot obține prin
JUDET IN (SELECT NUME FROM Judete WHERE POP92>(SELECT
AVG(POP92) FROM Judete))

Se pot utiliza funcțiile AVG, COUNT, MIN, MAX și SUM.


Predicatul EXISTS poate fi folosit pentru a testa dacă o interogare returnează
înregistrări.

Lista operatorilor (conform documentației ArcGIS)

Arithmetic operators
You use an arithmetic operator to add, subtract, multiply, and divide numeric
values.

Operator Description

* Arithmetic operator for multiplication

/ Arithmetic operator for division

+ Arithmetic operator for addition

- Arithmetic operator for subtraction

Comparison operators
You use comparison operators to compare one expression to another.

Operator Description

< Less than. It can be used with strings (comparison is


based on alphabetical order), numbers, and dates.

<= Less than or equal to. It can be used with strings


(comparison is based on alphabetical order), numbers,
and dates.

68
<> Not equal to. It can be used with strings (comparison
is based on alphabetical order), numbers, and dates.

> Greater than. It can be used with strings (comparison


is based on alphabetical order), numbers, and dates.

>= Greater than or equal to. It can be used with strings


(comparison is based on alphabetical order), numbers,
and dates. For example, this query selects all the cities
with names starting with the letters M to Z:

"CITY_NAME" >= 'M'

[NOT] Selects a record if it has a value greater than or equal


BETWEEN x to x and less than or equal to y. When preceded by
AND y NOT, it selects a record if it has a value outside the
specified range. For example, this expression selects
all records with a value greater than or equal to 1 and
less than or equal to 10:

"OBJECTID" BETWEEN 1 AND 10

This is the equivalent of the following expression:


"OBJECTID" >= 1 AND OBJECTID <= 10

However, the expression with BETWEEN provides


better performance if you're querying an indexed field.

[NOT] Returns TRUE if the subquery returns at least one


EXISTS record; otherwise, it returns FALSE. For example,
this expression returns TRUE if the OBJECTID field
contains a value of 50:

EXISTS (SELECT * FROM parcels WHERE


"OBJECTID" = 50)

EXISTS is supported in file, personal, and ArcSDE


geodatabases only.

69
[NOT] IN Selects a record if it has one of several strings or
values in a field. When preceded by NOT, it selects a
record if it doesn't have one of several strings or
values in a field. For example, this expression
searches for four different state names:

"STATE_NAME" IN ('Alabama', 'Alaska',


'California', 'Florida')

For file, personal, and ArcSDE geodatabases, this


operator can also be applied to a subquery:
"STATE_NAME" IN (SELECT "STATE_NAME"
FROM states WHERE "POP" > 5000000)

IS [NOT] Selects a record if it has a null value for the specified


NULL field. When NULL is preceded by NOT, it selects a
record if it has any value for the specified field. For
example, this expression selects all records with a null
value for population:

"POPULATION" IS NULL

x [NOT] LIKE Use the LIKE operator (instead of the = operator)


y [ESCAPE with wildcards to build a partial string search. For
'escape- example, this expression selects Mississippi and
character'] Missouri among USA state names:

"STATE_NAME" LIKE 'Miss%'

The percent symbol (%) means that anything is


acceptable in its place: one character, a hundred
characters, or no character. Alternatively, if you want to
search with a wildcard that represents one character,
use an underscore (_). For example, this expression
finds Catherine Smith and Katherine Smith:
"OWNER_NAME" LIKE '_atherine Smith'

70
The percent symbol and underscore wildcards work for
any file-based data or multiuser geodatabase data.
LIKE works with character data on both sides of the
expression. If you need to access noncharacter data, use
the CAST function. For example, this query returns
numbers that begin with 8 from the integer field
SCORE_INT:
CAST ("SCORE_INT" AS VARCHAR) LIKE '8%'

To include the percent symbol or underscore in your


search string, use the ESCAPE keyword to designate
another character as the escape character, which in turn
indicates that a real percent sign or underscore
immediately follows. For example, this expression
returns any string containing 10%, such as 10%
DISCOUNT or A10%:
"AMOUNT" LIKE '%10$%%' ESCAPE '$'

The wildcards you use to query personal geodatabases


are asterisk (*) for any number of characters and
question mark (?) for one character. The pound sign (#)
is also used as a wildcard to match a single digit
(numeric value). For example, this query returns parcel
numbers A1, A2, and so on, from a personal
geodatabase:
[PARCEL_NUMBER] LIKE 'A#'

Logical operators
Operator Description

AND Combines two conditions together and selects a record if


both conditions are true. For example, the following
expression selects any house with more than 1,500 square
feet and a garage for more than two cars:

"AREA" > 1500 AND "GARAGE" > 2

71
OR Combines two conditions together and selects a record if at
least one condition is true. For example, the following
expression selects any house with more than 1,500 square
feet or a garage for more than two cars:

"AREA" > 1500 OR "GARAGE" > 2

NOT Selects a record if it doesn't match the expression. For


example, the following expression selects all states but
California:

NOT "STATE_NAME" = 'California'

Lista funcțiilor (conform documentației ArcGIS)

Date functions
Function Description

CURRENT_DATE Returns the current date.

EXTRACT(extract_field Returns the extract_field portion of the


FROM extract_source) extract_source. The extract_source
argument is a date-time expression. The
extract_field argument can be one of the
following keywords: YEAR, MONTH,
DAY, HOUR, MINUTE, or SECOND.

CURRENT TIME Returns the current time.

Date functions

String functions
Arguments denoted asstring_exp can be the name of a column, a character-
string-literal, or the result of another scalar function, where the underlying data
type can be represented as a character type.
Arguments denoted ascharacter_exp are variable-length character strings.

72
Arguments denoted asstart or length can be a numeric-literal or the result of
another scalar function, where the underlying data type can be represented as a
numeric type.
These string functions are 1-based; that is, the first character in the string is
character 1.

Function Description

CHAR_LENGTH(string_exp) Returns the length in characters of


the string expression.

CONCAT(string_exp1, Returns a character string that is


string_exp2) the result of concatenating
string_exp2 to string_exp1.

LOWER(string_exp) Returns a string equal to that in


string_exp, with all uppercase
characters converted to lowercase.

POSITION(character_exp IN Returns the position of the first


character_exp) character expression in the second
character expression. The result is
an exact numeric with an
implementation-defined precision
and a scale of zero.

SUBSTRING(string_exp FROM Returns a character string that is


start FOR length) derived from string_exp,
beginning at the character position
specified by start for length
characters.

TRIM(BOTH | LEADING | Returns the string_exp with the


TRAILING trim_character FROM trim_character removed from the
string_exp) leading, trailing, or both ends of
the string.

UPPER(string_exp) Returns a string equal to that in


string_exp, with all lowercase
characters converted to uppercase.

73
Numeric functions
All numeric functions return a numeric value.
Arguments denoted as numeric_exp, float_exp, or integer_exp can be the name
of a column, the result of another scalar function, or a numeric-literal, where the
underlying data type could be represented as a numeric type.

Function Description

ABS(numeric_exp) Returns the absolute value of


numeric_exp.

ACOS(float_exp) Returns the arccosine of float_exp as an


angle, expressed in radians.

ASIN(float_exp) Returns the arcsine of float_exp as an


angle, expressed in radians.

ATAN(float_exp) Returns the arctangent of float_exp as


an angle, expressed in radians.

CEILING(numeric_exp) Returns the smallest integer greater than


or equal to numeric_exp.

COS(float_exp) Returns the cosine of float_exp, where


float_exp is an angle expressed in
radians.

FLOOR(numeric_exp) Returns the largest integer less than or


equal to numeric_exp.

LOG(float_exp) Returns the natural logarithm of


float_exp.

LOG10(float_exp) Returns the base 10 logarithm of


float_exp.

MOD(integer_exp1, Returns the remainder of integer_exp1


integer_exp2) divided by integer_exp2.

POWER(numeric_exp, Returns the value of numeric_exp to the


integer_exp) power of integer_exp.

74
ROUND(numeric_exp, Returns numeric_exp rounded to
integer_exp) integer_exp places to the right of the
decimal point. If integer_exp is
negative, numeric_exp is rounded to
|integer_exp| places to the left of the
decimal point.

SIGN(numeric_exp) Returns an indicator of the sign of


numeric_exp. If numeric_exp is less
than zero, -1 is returned. If numeric_exp
equals zero, 0 is returned. If
numeric_exp is greater than zero, 1 is
returned.

SIN(float_exp) Returns the sine of float_exp, where


float_exp is an angle expressed in
radians.

TAN(float_exp) Returns the tangent of float_exp, where


float_exp is an angle expressed in
radians.

TRUNCATE(numeric_exp, Returns numeric_exp truncated to


integer_exp) integer_exp places to the right of the
decimal point. If integer_exp is
negative, numeric_exp is truncated to
|integer_exp| places to the left of the
decimal point.

The CAST function


The CAST function converts a value to a specified data type. The syntax is as
follows:
CAST(exp AS data_type)
The argument exp can be the name of a column, the result of another scalar
function, or a literal. Data_type can be any of the following keywords, which
can be specified in upper- or lowercase: CHAR, VARCHAR, INTEGER,
SMALLINT, REAL, DOUBLE, DATE, TIME, DATETIME, NUMERIC, or
DECIMAL.
75
Proceduri de selecție a datelor spațiale. Limbajul PYTHON
În această secțiune vor fi prezentate variantele prin care putem extrage în ArcGIS
informații dintr-o bază de date spațială folosind limbajul Python.

Make Feature Layer


Crează un strat temporar care nu va persista în afara sesiunii curente, cu excepția
cazurilor în care documentul parinte este salvat.
Sintaxa:
MakeFeatureLayer_management (in_features, out_layer, {where_clause},
{workspace}, {field_info})

Unde:
 in_features - elementul care stă la baza noului strat
 out_layer – numele noului strat
 where_clause – o interogare SQL folosită pentru selecția unui subset de
date
 workspace – spațiul de lucru folosit pentru validarea câmpurilor
 field_info – utilizat pentru redenumirea câmpurilor și pentru ascunderea
unora dintre ele

Pentru mai multe detalii click aici.

Make Table View


Crează un tabel pe baza unui set de câmpuri și înregistrări. Acesta nu va persista
în afara sesiunii curente, cu excepția cazurilor în care documentul parinte este salvat.
Sintaxa:
MakeTableView_management (in_table, out_view, {where_clause},
{workspace}, {field_info})

Unde:
 in_table - elementul care stă la baza noului tabel
 out_view – numele noului tabel
 where_clause – o interogare SQL folosită pentru selecția unui subset de
date
 workspace – spațiul de lucru folosit pentru validarea câmpurilor
 field_info – utilizat pentru redenumirea câmpurilor și pentru ascunderea
unora dintre ele ("ORIGINAL_NAME NEW_NAME
HIDDEN/VISIBLE")

Pentru mai multe detalii click aici.

Select Layer By Attribute


Aceasta ne va permite să modificăm selecția penru un strat sau pentru un tabel pe
baza interogărilor bazate pe atribute.

76
Sintaxa:
SelectLayerByAttribute_management (in_layer_or_view, {selection_type},
{where_clause})

Unde:
 in_layer_or_view - elementul asupra căruia se va aplica selecția
 selection_type – tipul selecției (implicit NEW_SELECTION)
 where_clause – o interogare SQL folosită pentru selecția unui subset de
date

Pentru mai multe detalii click aici.

Select Layer by Location


Aceasta ne va permite să modificăm selecția pentru un strat sau pentru un tabel
pe baza unor relaționări spațiale.
Sintaxa:
SelectLayerByLocation_management (in_layer, {overlap_type},
{select_features}, {search_distance}, {selection_type})
Unde:
 in_layer – elementul asupra căruia se aplică selecția
 overlap_type – relația spațială care va fi evaluată (implicit INTERSECT)
 select_features – elementul care stă la baza selecției
 search_distance – distanța folosită la căutare
 selection_type – determină tipul selecției

Pentru mai multe detalii click aici.

Buffer
Aceasta ne va permite să creăm un poligon de tip buffer în jurul unui element pe
baza unei distanțe date.
Sintaxa:
Buffer_analysis (in_features, out_feature_class, buffer_distance_or_field,
{line_side}, {line_end_type}, {dissolve_option}, {dissolve_field})

Unde:
 in_features – linia, punctul sau poligonul în jurul căruia creăm buffer-ul
 out_feature_class – buffer-ul rezultat
 buffer_distance_or_field – distanța din jurul elementului de intrare
 line_side – partea pe care se face buffer (implicit FULL)
 line_end_type – tipul buffer-ului la final
 disolve_option – tipul de dizolvare (implicit NONE)
 dissolve_field – lista câmpurilor elementului de intrare pe baza cărora se
face dizolvarea

Pentru mai multe detalii click aici.

77
Clip
Aceasta ne va permite să decupăm o porțiune dintr-un element pe baza unor
specificații date..

Sintaxa:
Clip_analysis (in_features, clip_features, out_feature_class,
{cluster_tolerance})

Unde:
 in_features – elementul care va fi “decupat”
 clip_features –zona de decupat
 out_feature_class – elementul rezultat
 cluster_tolerance – distanța minimă de separare a elementelor

Pentru mai multe detalii click aici.

Add Join
Aceasta ne va permite să îmbinăm un strat cu altul sau cu un tabel.

Sintaxa:
AddJoin_management (in_layer_or_view, in_field, join_table, join_field,
{join_type})

78
Unde:
 in_layer_or_view – stratul sau tabelul din stanga (la operația de îmbinare)
 in_field – campul stratului/tabelului din stânga folosit pentru îmbinare
 join_table – stratul sau tabelul din dreapta (la operația de îmbinare)
 join_field – campul stratului/tabelului din dreapta folosit pentru îmbinare
 join_type – tipul îmbinării ( implicit KEEP_ALL)

Pentru mai multe detalii click aici.

Remove Join
Aceasta ne va permite să eliminăm îmbinări existente între straturi sau tabele.

Sintaxa:
RemoveJoin_management (in_layer_or_view, {join_name})

Unde:
 in_layer_or_view – stratul sau tabelul pentru care se va elimina îmbinarea
 join_name – numele îmbinării care va fi eliminată

Pentru mai multe detalii click aici.

Creare FeatureClass
Aceasta ne va permite să creăm o clasă goală, care va conține caracteristicile
pentru un nou strat sau tabel într-o bază de date spațială.În folderul corespunzător
spațiului de lucru va crea un fișier de tip shapefile.

Sintaxa:
CreateFeatureclass_management (out_path, out_name, {geometry_type},
{template}, {has_m}, {has_z}, {spatial_reference}, {config_keyword},
{spatial_grid_1}, {spatial_grid_2}, {spatial_grid_3})

Unde:
 out_path – baza de date sau folderul (spațiul de lucru) în care va fi creat
fișierul corespunzător
 out_name – numele clasei
 geometry_type – tipul geometriei clasei: POINT, MULTIPOINT,
POLYGON, POLYLINE

Pentru mai multe detalii click aici.

Unei asemenea clase i se pot adăuga membri suplimentari utilizînd


AddField_management

79
Sintaxa:
AddField_management (in_table, field_name, field_type, {field_precision},
{field_scale}, {field_length}, {field_alias}, {field_is_nullable}, {field_is_required},
{field_domain})

Unde:
 in_table – tabelul sau clasa căreia i se adaugă noul membru
 field_name – numele câmpului
 field_type – tipul câmpului:
o TEXT — șiruri de caractere.
o FLOAT — numere zecimale cuprinse între -3.4E38 și 1.2E38.
o DOUBLE — numere zecimale cuprinse între -2.2E308 și
1.8E308.
o SHORT — numere întregi între -32,768 și 32,767.
o LONG — numere întregi între -2,147,483,648 și 2,147,483,647.
o DATE —date și timp
o BLOB — secvențe lungi de numere binare
o RASTER — pentru imagini (raster).
o GUID —Globally unique identifier.
 field_length – lungimea câmpului

Pentru mai multe detalii click aici.

Ștergerea elementelor
Pentru ștergerea unor elemente vreate se poate folosi Delete_management.

Sintaxa:
Delete_management (in_data, {data_type})

Unde:
 in_data – data de intrare care va fi ștearsă
 data_type – tipul de data al datelor de intrare

Pentru mai multe detalii click aici.

În exemplele următoare vor fi prezentate variante de utilizare a celor prezentate


anterior.

80
Exemple
Următoarele scripturi vor fi testate în ArcMap folosind fișierul folosit în cadrul
laboratoarelor.
1) Încărcăm pachetul arcpy.
import arcpy
2) Construim stratul "Drumuri_lyr" pe baza tabelei Drumuri.
În loc de “cale” se va pune calea de pe calculatorul curent

arcpy.env.overwriteOutput = True
arcpy.MakeFeatureLayer_management("cale/ro1mil.gdb/Drumur
", "Drumuri_lyr")

3) Selectăm drumul “DN17”


arcpy.SelectLayerByAttribute_management("Drumuri_lyr",
"NEW_SELECTION"," nume1='DN17' or nume2='DN17'")

4) Construim stratul "Judete_lyr" pe baza tabelei Judete


arcpy.MakeFeatureLayer_management("C:/Users/Marius/Docume
nts/ArcGIS/Packages/Romania1000k_D463BA3F-E24A-4A35-A1C3-
D670D16B2F0C/v10/ro1mil.gdb/Judete", "Judete_lyr")

5) Selectăm județele prin care trece drumul “DN17”


arcpy.SelectLayerByLocation_management ("Judete_lyr",
"INTERSECT", "Drumuri_lyr")

6) Creăm un buffer în jurul drumului “DN17” folosind distanța de 10 km


arcpy.Buffer_analysis("Drumuri_lyr","Drumuri_lyr_Buffer",
"10000 Meters", "FULL", "ROUND","ALL")
7) Construim stratul " Localitati_lyr" pe baza tabelei Localități.
arcpy.MakeFeatureLayer_management("cale/ro1mil.gdb/Locali
tati", "Localitati_lyr")
8) Considerăm numai localitățile din zona (buffer-ul) creată anterior.
arcpy.SelectLayerByLocation_management("Localitati_lyr","
INTERSECT", "Drumuri_lyr_Buffer", 0,"NEW_SELECTION")
9) Construim stratul "Rauri_lyr" pe baza tabelei Rauri.
arcpy.MakeFeatureLayer_management("cale/ro1mil.gdb/Rauri,
"Rauri_lyr")
10) Construim stratul "Rauri_clip" doar cu râurile din zona de interes.
arcpy.Clip_analysis("Rauri_lyr", "Drumuri_lyr_Buffer",
"Rauri_clip")

Pentru a face o îmbinare între tabelele Localitati și Judete procedăm astfel:

81
11) arcpy.MakeFeatureLayer_management("cale/ro1mil.gdb/
Localitati", "Localitati_Judete_join")

12) arcpy.AddJoin_management( "Localitati_Judete_join",


"JUDET", "cale/ro1mil.gdb/Judete",
"NUME","KEEP_COMMON")

Dacă pașii anteriori ar trebui reluați pentru mai multe drumuri atunci este indicat
să se creeze o funcție care va primi ca argument numele drumului. Vor interveni
svhimbări la codul corespunzător pasului 3.

Vom defini funcția localitați astfel:

import arcpy
cale=”…”
def localitati(drum):
arcpy.env.overwriteOutput = True
arcpy.MakeFeatureLayer_management(cale+"/Drumuri",
"Drumuri_lyr")

arcpy.SelectLayerByAttribute_management("Drumuri_lyr",
"NEW_SELECTION"," nume1='"+drum+"' or nume2='"+drum+"' ")
arcpy.MakeFeatureLayer_management(cale+"/Judete”,
"Judete_lyr")
arcpy.SelectLayerByLocation_management ("Judete_lyr",
"INTERSECT", "Drumuri_lyr")
arcpy.Buffer_analysis("Drumuri_lyr",
"Drumuri_lyr_Buffer","10000 Meters", "FULL",
"ROUND","ALL")
arcpy.MakeFeatureLayer_management(cale+"/Localitati",
"Localitati_lyr")

arcpy.SelectLayerByLocation_management("Localitati_lyr","
INTERSECT", "Drumuri_lyr_Buffer", 0,"NEW_SELECTION")
arcpy.MakeFeatureLayer_management(cale+"/Rauri”,
"Rauri_lyr")
arcpy.Clip_analysis("Rauri_lyr", "Drumuri_lyr_Buffer",
"Rauri_clip")
arcpy.MakeFeatureLayer_management(cale+”/Localitati",
"Localitati_Judete_join")
arcpy.AddJoin_management("Localitati_Judete_join",
"JUDET", cale+"/Judete", "NUME","KEEP_COMMON")

După încărcarea scriptului, apelul funcției poate fi făcut din linia de comandă
astfel:
localitati("E85")

82
Exemple de accesare a câmpurilor din straturi/tabele (utilizând Python)

 Determinarea județului cu densitatea cea mai mare a populației (fără BUCUREȘTI)

import arcpy
cale="…"

infc = cale+"/Judete"
rows = arcpy.SearchCursor(infc)

judet_max_dens=""
max_dens=0
for row in rows:
if row.Nume!="BUCURESTI" and
row.POP92/row.Shape_Area>max_dens:
max_dens=row.POP92/row.Shape_Area
judet_max_dens=row.Nume

print "Judetul cu densitatea populatiei cea mai mare


este " + judet_max_dens

 Afișăm județele în ordine descrescătoare a densității populației

import arcpy
cale="…"

infc = cale+"/Judete"
judete = []
rows = arcpy.SearchCursor(infc)
for row in rows:
judete.append([row.Nume,
row.POP92/row.Shape_Area])

ordonat=False
while not ordonat:
ordonat=True
for index in range(1,len(judete)):
if judete[index-1][1]<judete[index][1]:
temp=judete[index-1]
judete[index-1]=judete[index]
judete[index]=temp
ordonat=False
break

for judet in judete:


print judet[0]+" - "+str(judet[1])

83
 Pentru a exemplifica citirea valorilor de tip Point afișăm lista localităților însoțide
de ID și coordonate

import arcpy
cale="…"

infc = cale+"/Localitati"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)

for row in rows:


feat = row.getValue(shapefieldname)
point=feat.getPart()
print row.NUME+" (Id: %i) " %
row.getValue(desc.OIDFieldName)+str(point.X)+" -
"+str(point.Y)

 Pentru a exemplifica citirea valorilor de tip Polyline afișăm lista punctelor ce


descri DN17

import arcpy
cale="…"
arcpy.env.overwriteOutput = True
arcpy.MakeFeatureLayer_management(cale+"/Drumuri ",
"Drumuri_lyr")
arcpy.SelectLayerByAttribute_management("Drumuri_lyr"
, "NEW_SELECTION"," nume1='DN17' or nume2='DN17'")

infc = "Drumuri_lyr"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)

for row in rows:


feat = row.getValue(shapefieldname)
print "Feature %i: " %
row.getValue(desc.OIDFieldName)
partnum = 0
# luam fiecare componenta pentru Feature %i
for part in feat:
print "Part %i: " % partnum
part_list = []
for pnt in feat.getPart(partnum):
if pnt:
part_list.append([pnt.X, pnt.Y])
partnum += 1
print part_list

84
 Pentru a exemplifica citirea valorilor de tip Polygon afișăm lista punctelor ce
descriu județul IAȘI

import arcpy
cale="…"
arcpy.env.overwriteOutput = True
arcpy.MakeFeatureLayer_management(cale+"/Judete ",
"Judete_lyr")
arcpy.SelectLayerByAttribute_management("Judete_lyr",
"NEW_SELECTION"," nume='IASI'")

infc = "Judete_lyr"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)

for row in rows:


polygon = row.getValue(shapefieldname)
for puncte in polygon:
for punct in puncte:
if punct:
print punct.X, punct.Y

 Pentru calculul distanțelor se poate folosi funcția distanta_puncte

def distanta_puncte(x1,y1,x2,y2):
return math.sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2))

 Pentru exemplificarea metodei touches, în codul de mai jos se definește functia


vecini_judet care pentru un județ specificat va afișa județele vecine și lungimile
frontierelor commune cu județul precizat

import arcpy
cale="…"
arcpy.env.overwriteOutput = True

def distanta_puncte(x1,y1,x2,y2):
return math.sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2))

def punct_pe_poligon(punct,polig):
return punct.touches(polig)

def lungime_comuna(polig1,polig2):
puncte=[]
for pcte in polig1:
for punct in pcte:

85
if punct:
puncte.append([punct.X, punct.Y,
punct_pe_poligon(punct,polig2)])
L=0
for i in range(1,len(puncte)):
if puncte[i-1][2] and puncte[i][2]:
L+=distanta_puncte(puncte[i-
1][0],puncte[i-1][1],puncte[i][0],puncte[i][1])
return L

def vecini_judet(nume_judet):
judete=[]
infc = cale+"/Judete"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)
for row in rows:

judete.append([row.NUME,row.getValue(shapefieldname)])
if row.NUME==nume_judet:
polygon=row.getValue(shapefieldname)
print "Judetele vecine si lungimile frontierelor:"
for judet in judete:
if polygon.touches(judet[1]):
print judet[0] + " "+
str(lungime_comuna(polygon,judet[1]))

 Pentru exemplificarea metodei contains, în codul de mai jos se definește functia


localitati_judet care pentru un județ specificat va afișa lista localităților din județ

def punct_in_poligon(punct,polig):
return polig.contains(punct)

def localitati_judet(nume_judet):
infc = cale+"/Judete"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)
for row in rows:
if row.NUME==nume_judet:
polygon=row.getValue(shapefieldname)
break

print "Localitatile din judetul "+nume_judet+"


sunt:"

86
infc = cale+"/Localitati"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)
for row in rows:
if
punct_in_poligon(row.getValue(shapefieldname).getPart
(),polygon):
print row.NUME

 Pentru exemplificarea modului de calcul al lungimilor se definește functia


lungime_rau care va calcula lungimea unui râu specificat

def lungime_figura(figura):
lungime=0
for part in figura:
puncte = []
for pct in part:
if pct:
puncte.append([pct.X,
pct.Y])
for i in range(1,len(puncte)):

lungime+=distanta_puncte(puncte[i-1][0],puncte[i-
1][1],puncte[i][0],puncte[i][1])
return lungime

def lungime_rau(nume_rau):
infc = cale+"/Rauri"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)
L=0
for row in rows:
if row.NUME==nume_rau:
L+=lungime_figura(row.getValue(shapefi
eldname))
print "Lungimea raului "+nume_rau+ " este :
"+str(L)

 Pentru exemplificarea modului în care se poate crea un nou strat (tabel) cu o


structură nouă (cu niște coloane precizate) se utilizează scriptul următor

import arcpy
arcpy.env.overwriteOutput = True
cale="…"
in_workspace = "c:/temp"
output_name = "sediu.shp"

87
arcpy.CreateFeatureclass_management(in_workspace,
output_name, "POINT")
arcpy.AddField_management("sediu", "Nume", "TEXT",
field_length=25,field_is_nullable="NON_NULLABLE")
arcpy.AddField_management("sediu", "NrAngajati",
"SHORT")

arcpy.MakeFeatureLayer_management(in_workspace+"/sedi
u.shp","Sedii_lyr","","","Id Id HIDDEN")

# Stergem clasa care a stat la baza stratului creat


arcpy.Delete_management("sediu")

infc = cale+"/Localitati"
desc = arcpy.Describe(infc)
shapefieldname = desc.ShapeFieldName
rows = arcpy.SearchCursor(infc)
for row in rows:
if row.NUME=="IASI":
punct=row.getValue(shapefieldname)
break

rows = arcpy.InsertCursor("Sedii_lyr")
# adaugam o inregistrare
row = rows.newRow()
row.setValue("Shape", punct)
row.setValue("Nume", "Sediu IASI")
row.setValue("NrAngajati", 7)
rows.insertRow(row)

# eliberam memoria ocupata


del row
del rows

88

S-ar putea să vă placă și