Capitolul 1.

Despre bazele de date

Se spune, pe drept cuvnt, c primele semne ale procesului de ramolire apar
atunci cnd ncepi s te repei, confirmarea procesului este auto-citarea, iar
desvrirea este auto-plagierea (mai ales cea fr intenie). Dei tentative de a
defini bazele de date apar n mai toate crile publicate, singur sau n colaborare, la
Editurile Polirom ([Fotache 2001], [Fotache s.a. 2002], [Fotache s.a. 2003], [Fotache
2005]) i Junimea [Fotache 1997], din raiuni populiste voi apela pentru nceput, cu
precdere, la secvene din dou cursuri care ncearc cu disperare s atrag atenia
studenilor Facultii de Economie i Administrarea Afacerilor1 la disciplinele
Instrumente software pentru afaceri i Baze de date I. ([Grama s.a.2006], [Fotache
2007]). Sunt vizate importana i noiunile fundamentale privind lucrul cu baze de
date.

1.1. Nevoia de baze de date

Folosim bazele de date deoarece avem memoria prea scurt i stm prost cu
calculele. Ca i n alte privine, avem nevoie de baze de date pentru c suntem nite
limitai. Trim ntr-o lume aezat pe un morman de hrtii & hroage, i ne este cu
neputin s reconstituim ceea ce am fcut adineaori, darmite ieri, sptmna
trecut sau acum un an sau cinci. Necazul e c, de cele mai multe ori, trebuie s
tim nu numai ce-am fcut noi, dar i cte ceva din ceea ce-au fcut colegii i
partenerii de afaceri.
Simplificnd i exagernd nepermis lucrurile, am putea spune c exist doi poli
ntre care poate fi poziionat orice problem informatic. Pe de o parte, cel al
chestiunilor interesante, nu neaprat cu formule i calcule complexe, dar care
reclam un anumit grad de ingeniozitate n rezolvare - mult invocata i ateptata
"fis". Cellalt pol regrupeaz probleme n care complexitatea calculelor rareori
depete nivelul celor patru operaii aritmetice elementare - adunare, scdere i
nc dou; n schimb, volumul informaiilor i zecile/sutele moduri de regrupare i
agregare a lor este deconcertant.
Fr a face concuren vreunui manual de filosofie, putem spune c, din pcate,
ca i n via, ponderea problemelor din a doua categorie s le spunem plicticoase
este mult mai mare dect ponderea problemelor cu adevrat interesante. Aceasta
ar fi vestea proast. Vestea bun este c se ctig enorm de muli bani din
chestiunile plicticoase. O veste intermediar ar fi c, n majoritate, problemele pe
care le are de rezolvat un informatician presupun elemente din ambele categorii.

1 De la Universitatea Al.I.Cuza Iai

8 Capitolul 1

De fapt, cei doi poli de care vorbim au o existen virtual, fiind utili mai degrab
din raiuni didactice & pedagogice.

Cert este c, nc de la nceputurile sale, informatica a fost confruntat nu

numai cu efectuarea de calcule sofisticate, tiinifice, dar i cu stocarea i
gestionarea unui volum de informaii din ce n ce mai mare. Astfel nct apariia
unor instrumente software dedicate gestiunii i prelucrrii datelor a fost doar o
problem de timp.
Prin urmare, avem nevoie de baze de date pentru a pstra, ntr-un format
utilizabil, date i informaii legate de evenimente, tranzacii etc. i, la nevoie, de a le
regsi i prelucra dup cum ne cer mprejurrile. Bazele de date nu reprezint
singurul instrument de stocare i prelucrare a informaiilor. i ntr-un banal fiier
.DOC (document Word, WordPerfect...), prezentare PowerPoint sau foaie de calcul
(Excel, Lotus 1-2-3...) pstrm date. Ca s nu mai vorbim de pagini Web. Problema
este c n documente, foi de calcul, prezentri, fiiere HTML etc. datele sunt slab
structurate. Pentru a localiza informaiile trebuie folosite instrumente de cutare
care s depisteze prezena unor cuvinte cheie, eventual n preajma unor alte
cuvinte cheie (cu o afacere de genul acesta s-au umplut de bani cei de la Google).
Iar rezultatele acestui gen de cutare/localizare sunt, de multe ori, iritante prim
ambiguitatea i volumul lor.
ncheiem acest mini-paragraf cu alt pereche de veti. Cea bun este c, la acest
moment, bazele de date reprezint cel mai bine structurat mod de pstrare i
scotocire a informaiilor. Este motivul pentru care piaa produselor de lucru cu
bazele de date se exprim n valori de ordinul miliardelor de dolari, nefiind prea
multe semne c s-ar diminua. Vestea rea ine de faptul c, dintre toate datele i
informaiile pe care le vehiculm/gestionm/prelucrm pe hrtie, la telefon, pe
band sau disc magnetic, optic etc., doar o mic parte sunt preluate i preluabile n
bazele de date.

1.2. Cum ne folosim de bazele de date

Mare parte dintre noi suntem datornici, unii chiar redutabili, bncilor, aa c
putem rememora mpreun cteva imagini din plata unei rate. Dup tradiionala
binee, lucrtorul de la ghieul bncii ne cere un document de identitate i apoi
ncepe s se uite atent pe ecran la o serie de meniuri i ferestre, tasteaz numele sau
codul numeric personal iar apoi ne comunic suma de plat (rata), eventual cte
rate mai avem sau alte informaii legate de credit2.
Meniurile, ferestrele i rapoartele de pe ecran constituie interfaa aplicaiei
informatice a bncii, aplicaie la care este conectat lucrtorul de la ghieu vezi
figura 1.1. Ceea ce nu se vede pe ecran i este necunoscut lucrtorului (i multora

2 Este adevrat c sunt bnci la care informaiile enumerate pot fi obinute doar printr-un efort
traumatizant, ns de dragul exemplului s ne imaginm c aa stau lucrurile.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 9

dintre noi) este c informaiile afiate pe ecran sunt preluate dintr-un bazin de date
aflat ndrtul uneia sau mai multor cutii de tabl numite uneori calculatoare.

Figura 1.1. Schem excesiv de simplist a aplicaiilor ce utilizeaz baze de date

Figura 1.1 este simplist pn la irelevant. n realitate, baza de date poate fi pe
acelai calculator pe care se afieaz meniurile, ferestrele i rapoartele (lucru
frecvent n aplicaii mici i foarte mici realizate n Access sau FoxPro), dar, de cele
mai multe ori, pe un alt calculator care se ocup numai cu gestiunea datelor
(serverul de baze de date). Pentru ca lucrurile s fie i mai interesante, ntre
calculatorul lucrtorului i serverul pe care se afl baza de date sunt interpuse alte
servere, fiecare gestionnd anumite module ale aplicaiei vezi figura 1.2.

Figura 1.2. Schem ceva mai complicat (dar tot inexact) a aplicaiilor ce utilizeaz baze
de date
Dei, poate, mai impresionant, figura 1.2 conine destule inexactiti. Astfel,
pot exista i alte servere, n afara celor sugerate (de exemplu, servere pentru
aplicaii dedicate grupurilor de lucru (groupware), servere pentru gestiunea
documentelor etc.). De fapt, aplicaiile se descompun pe procese i servicii, fiecare
10 Capitolul 1

server furniznd unul sau mai multe servicii. Apoi, trebuie spus c baza de date
poate, la rndul su, s fie mprtiat pe mai multe servere (vorbim de baze de
date centralizate, distribuite, replicate). n al treilea rnd, nu toi utilizatorii sunt
de sex femeiesc i nu toate femeile din sistemul informatic al bncii au prul aten
& coad/coc.
Ei bine, din toat aceast figur, n cartea de fa ne intereseaz numai serverul
de baz de date. Mai mult (de fapt, mai puin !), dintre zecile de subiecte dedicate
serverelor de baze de date, noi ne vom ocupa doar de cteva: cum crem i folosim
o baz de date, i, mai ales, cum o stoarcem de informaii ?
Exist ns i persoane care folosesc baze de date fr a avea nevoie de
formulare, meniuri i alte elemente de interfa. Se poate crea i gestiona o baz de
date i n acest mod, mod cruia putem s-i spunem spartan (sau stoic). ns
asemenea gen de utilizatori trebuie s fie ai (sau mcar valei) n ale bazelor de
date. Or, o caracteristic esenial a bazelor de date este accesibilitatea. O baz de
date este cu att mai valoroas cu ct pot avea acces la informaiile sale ct mai
multe categorii de utilizatori (firete, fiecare cu drepturile i ndatoririle sale).

1.3. La nceput a fost fiierul (independent)

Schema din figura 1.2 este valabil doar de civa ani ncoarce, ns mai toate
aplicaiile informatice pentru organizaii (firme, spitale, universiti, bnci etc.)
realizate n ultimii cincizeci de ani prezint cel puin dou straturi: interfaa i
datele. nainte de folosirea bazelor de date, datele erau organizate n fiiere
independente gestionate prin programe scrise n limbaje precum COBOL,
FORTRAN, C, Basic, Pascal etc.
n a doua parte a anilor '50 Departamentul Aprrii al SUA a format un grup de
specialiti pentru elaborarea unui limbaj destinat aplicaiilor administrative, n care
dificultatea major inea de volumul imens de resurse materiale i financiare ce
trebuia "chivernisit" i pentru care erau necesare rapoarte dintre cele mai diverse.
Pornind de la precursorul FLOWMATIC, grupul cu pricina a redactat specificaiile
celui care a fost considerat cteva decenii regele informaticii economice COBOL
(Common Business Oriented Language).
Arhitectura aplicaiilor de acest tip specific nu numai COBOL-ului, ci multor
limbaje din a III-a generaie, denumit flat-files architecture tradus n romnete
drept fiiere independente este reprezentat n figura 1.3.
Specific acestui mod de lucru, referit ca file-based sau flat files (fiiere
independente), este faptul c fiecare dat (Data1, Data2,... Datan) este descris
(nume, tip, lungime) autonom, n toate fiierele n care apare. Mai mult, descrierea
fiecrui fiier de date (cmpurile care-l alctuiesc, tipul i lungimea fiecruia,
modul de organizare (sercvenial, indexat, relativ etc.)) este obligatorie n toate
programele care l citesc sau modific. ntre FIIER1, FIIER2, ... FIIERm nu
exist nici o relaie definit explicit.
Spre exemplu, Data2 este prezent n dou fiiere de date, FIIER1 i FIIER2.
Dac, prin program, se modific formatul sau valoarea acesteia n FIIER1,
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 11

modificarea nu se face automat i n FIIER2; prin urmare, o aceeai dat, Data2, va

prezenta dou valori diferite n cele dou fiiere, iar necazurile bat la u:
informaiile furnizate de sistemul informatic sunt redundante i prezint un mare
risc de pierdere a coerenei.

Data 1
Data 2 Raport 1

Data 3
FIIER 1 PRELUCRARE 1 Fiier de
Data 4 legturi

Data 2
Raport 4
Data 4
FIIER 2 PRELUCRARE 2 Raport 3
Data 5
Raport 2
Data 6

Data 1 Raport 5
FIIER 3 PRELUCRARE 3
Data 5

Data 7
Data 8
DATE FIIERE PRELUCRRI IEIRI

Figura 1.3. Sistem informatic bazat pe organizarea datelor n fiiere independente

Se poate proiecta un mecanism de meninere a integritii datelor, astfel nct
actualizarea unei date ntr-un fiier s atrag automat actualizarea tuturor
fiierelor de date n care aceasta apare, ns, n sistemele mari, care gestioneaz
volume uriae de informaii, implementarea unui asemenea mecanism este extrem
de complex i costisitoare. n plus, fiierele de date sunt uneori proiectate i
implementate la distane mari n timp, n formate diferite: de exemplu, FIIER1
este posibil s fi fost creat cu ajutorul limbajului COBOL, FIIER2 n FORTRAN iar
FIIER3 n BASIC. n asemenea condiii, punerea n oper a mecanismului de
meninere a integritii devine o utopie.
Chiar numai i din cele prezentate mai sus, se pot desprinde cteva dezavantaje
ale organizrii datelor dup modelul fiierelor independente:
1. Redundana i inconsistena datelor: o aceeai dat apare n mai multe fiiere;
n aceste cazuri exist riscul modificrii acesteia ntr-un fiier fr a face
modificrile i n toate celelalte fiiere.
2. Dificultatea accesului. ntr-o ntreprindere, o aceeai informaie este
exploatat de mai muli utilizatori. Spre exemplu, pentru departamentul
care se ocup cu gestiunea stocurilor, intrrile de materiale trebuie ordonate
pe magazii (depozite) i repere, n timp ce pentru departamentul care se
ocup cu decontrile cu partenerii de afaceri ai ntreprinderii, intrrile
12 Capitolul 1

trebuie ordonate pe furnizori ai materialelor. Or, fiierele tradiionale nu

faciliteaz accesarea datelor dup mai multe criterii, specifice diferiilor
utilizatori sau grupuri de utilizatori.
3. Izolarea datelor: cnd datele sunt stocate n formate diferite, este dificil de
scris programe care s realizeze accesul ntr-o manier global a tuturor
celor implicate n derularea unei tranzacii.
4. Complexitatea apstoare a actualizrilor. O actualizare presupune adugarea,
modificarea sau tergerea unor informaii din fiiere. Cum prelucrrile se
desfoar n timp real, de la mai multe terminale (n mediile multi-
utilizator), pot apare situaii conflictuale atunci cnd doi utilizatori doresc
modificarea simultan a unei aceleai date. Rezolvarea acestui gen de
conflicte presupune existena unui program-supervizor al prelucrrilor,
care este greu de realizat cu o multitudine de fiiere create la distan n
timp i n formate diferite.
5. Problemele de securitate in de dificultatea crerii unui mecanism care s
protejeze pe deplin datele din fiiere de accesul neautorizat.
6. Probleme legate de integritatea datelor. Informaiile stocate n fiiere sunt
supuse la numeroase restricii semantice. Toate aceste restricii alctuiesc
mecanismul de integritate a datelor, deosebit de complex n mediile de
lucru multi-utilizator i eterogene.
7. Inabilitatea de a obine rspunsuri rapide la probleme ad-hoc, att de
frecvente n lumea afacerilor.
8. Costul ridicat se datoreaz gradului mare de redundan a datelor,
eforturilor deosebite ce trebuie depuse pentru interconectarea diferitelor
tipuri de fiiere de date i pentru asigurarea funcionrii sistemului n
condiiile respectrii unui nivel minim de integritate i securitate a
informaiilor.
9. Inflexibilitatea fa de schimbrile ulterioare, ce sunt inerente oricrui sistem
informaional.
10. Modelarea indecvat a lumii reale.

Aceste dezavantaje sunt mai mult dect convingtoare, nct v putei ntreba
dac au existat incontieni care s-i arunce banii pe apa... fiierelor independente.
Ei bine, o serie de aplicaii dezvoltate n anii '60 sau '70 au fost motenite i folosite
pn zilele noastre. De ce ? Datorit consistentelor sume investite, care au putut fi
amortizate (trecute pe costuri) doar n ani buni, chiar decenii. Un alt motiv a fost
ns funcionalitatea i viteza unor asemenea aplicaii, precum i experiena
acumulat de o larg cateogorie de profesioniti n ale IT-ului.

1.4. Ce este o baz de date ?

Bazele de date sunt, n general, percepute ca uriae rezervoare informaionale n
care sunt turnate (sau, dup caz, aruncate) tot soiul de cifre, iruri de caractere, ba
chiar imagini, texte etc. n sperana c ar putea fi regsite ulterior i (re)ordonate,
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 13

combinate i grupate, n funcie de nevoile utilizatorilor autorizai. n orice caz, o

baz de date este mare, uneori imens, partajabil mai multor utilizatori i
persistent, adic poate fi stocat pe disc (sau orice suport) pe termen nelimitat3.
Sintagma baz de date apare pentru prima dat n titlul unei conferine
organizate la Santa Monica (California) n 1964 de System Development
Corporation. Consacrarea definitiv a termenului este marcat de publicarea n
anul 1969, de ctre CODASYL, n cadrul unei conferine dedicate limbajelor de
gestiune a datelor, a primului raport tehnic n care este prezentat conceptul de
baz de date. Fa de modelul fiierelor independente, noutatea o constituie
existena unui fiier de descriere global a bazei, astfel nct s se poat asigura
independena programelor fa de date, dup cum o arat i figura 1.4.

B A Z A DE D A T E

Fiier de date 1

Fiier de date 2 Dicionar

de date

Fiier de date n

Aplicaia 1 Aplicaia 2 Aplicaia 3

Figura 1.4. Schem de principiu a unei baze de date

Avantajele organizrii informaiilor n baze de date decurg tocmai din existena
acestui fiier de descriere global a bazei, denumit, n general, dicionar de date (alte
titulaturi: repertoar de date sau catalog de sistem). Extragerea i modificarea datelor,
altfel spus, lucrul cu fiierele de date, se deruleaz exclusiv prin intermediul
dicionarului n care se gsesc informaii privitoare la structura datelor i restriciile
ndeplinite de acestea.
O baz de date (BD) reprezint un ansamblu structurat de fiiere, care grupeaz
datele prelucrate n aplicaiile informatice ale unei persoane, grup de persoane,
ntreprinderi, instituii etc. Mai riguros, BD poate fi definit ca o colecie de date aflate
n interdependen, mpreun cu descrierea datelor i a relaiilor dintre ele, sau ca o

3 [Atzeni s.a. 1999] pp. 3-4

14 Capitolul 1

colecie de date utilizat ntr-o organizaie, colecie care este automatizat, partajat,
definit riguros (formalizat) i controlat la nivel central4.

Atunci cnd vorbim despre o baz de date, trebuie avute n vedere dou
aspecte fundamentale aceste acesteia, schema i coninutul. Organizarea bazei de
date se reflect n schema sau structura sa, ce reprezint un ansamblu de
instrumente pentru descrierea datelor, a relaiilor dintre acestea, a semanticii lor i
a restriciilor la care sunt supuse. Ansamblul informaiilor stocate n baz la un
moment dat constituie coninutul sau instanierea sau realizarea acesteia. n timp
ce volumul prezint o evoluie spectaculoas n timp, schema unei baze rmne
relativ constant pe tot parcursul utilizrii acesteia. Corespunztor celor dou
aspecte complementare, schem/coninut, limbajele de programare dedicate
bazelor de date se mpart n limbaje de definire a datelor (DDL Data Definition
Language) i limbaje de manipulare a datelor (DML Data Manipulation
Language). Limbajele uzuale dedicate bazelor de date, cum este SQL-ul, prezint
opiuni att pentru declararea structurii, ct i pentru editarea coninutului i
consultarea/interogarea bazei.

1.5. Sisteme de gestiune a bazelor de date

Aa dup cum fiierele de tip document au nevoie, pentru editare, de
procesoare de texte (Word, WordPerfect etc.) sau dup cum fiierele de tip foi de
calcul (.XLS, WK1 etc.) au nevoie de programe de calcule tabelare (Excel, Lotus 1-2-
3, Quattro Pro), i o baz de date necesit pentru creare, utilizare i administrare
software specializat, i anume un Sistem de Gestiune a Bazei de Date.
Aprute n anii '60, Sistemele de Gestiune a Bazelor de Date (prescurtat SGBD-
uri) reprezint un ansamblu de programe ce permit utilizatorilor s interacioneze
cu o baz de date, n vederea crerii, actualizrii i interogrii acesteia. SGBD-ul
este cel care asigur i supervizeaz: introducerea de informaii n baza de date;
actualizarea i extragerea datelor din baz; autorizarea i controlul accesului la
date; pstrarea independenei dintre structura bazei i programe5.
Obiectivul esenial al unui SGBD este furnizarea unui mediu eficient, adaptat
utilizatorilor care doresc s consulte sau s actualizeze informaiile coninute n
baz. Bazele de date sunt concepute pentru a prelucra un volum mare de
informaii. Gestiunea acestora impune nu numai o structurare riguroas a datelor,
dar i o raionalizare a procedurilor de acces i prelucrare.
Prin urmare, principalele funciuni ale unui SGBD vizeaz:
descrierea ansamblului de date la nivel fizic i conceptual;

4 [Everest1986], p.11
5 [G. Dodescu s.a. 1987], p. 511
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 15

crearea (iniializarea) i exploatarea (consultarea i actualizarea) bazei de

date;
controlul integritii bazei;
confidenialitatea informaiilor coninute n baz;
accesul simultan al mai multor utilizatori la informaii;
securitatea n funcionare;
furnizarea unui set de comenzi i instruciuni, necesare att utilizatorilor
pentru consultarea direct a bazei, prin intermediul unui limbaj de
manipulare, ct i programatorilor, pentru redactarea programelor de
lucru cu baza de date;
revizia i restructurarea bazei;
monitorizarea performanelor.
Exist diferene considerabile ntre SGBD-urile aflate azi pe pia, n privina
performanelor i preului. Access sau Visual FoxPro, ambele produse Microsoft,
sunt SGBD-uri mai modeste n privina dimensiunii bazei de date. Visual FoxPro
nu are, nici mcar n versiunea 9, opiuni de declarare a utilizatorilor i grupurilor
de utilizatori, cu att mai mult opiuni avansate de administrare. n schimb, este
foarte generos n realizarea de meniuri, formulare i rapoarte (interfaa
aplicaiilor), ceea ce l-a fcut mult timp preferatul informaticienilor n dezvoltarea
de aplicaii mici i medii. Astzi numele grele n domeniul bazelor de date sunt
Oracle (Oracle), DB2 (IBM) i SQL Server (Microsoft), iar cei mai serioi competitori
ai acestora sunt SGBD-urile open-source cum ar fi PostgreSQL, MySQL etc. Vom
reveni la acest subiect.
ntr-un sistem informatic ce utilizeaz BD, bazele de date sunt privite mpreun
cu SGBD-urile. Organizarea datelor poate fi analizat din mai multe puncte de
vedere i pe diferite paliere. De obicei, abordarea se face pe trei niveluri: fizic sau
intern, conceptual sau global i extern vezi figura 1.5.
Nivelul fizic (sau intern). Reprezint modalitatea efectiv n care acestea sunt
"scrise" pe suportul de stocare - disc magnetic, disc optic, band magnetic etc.
Nivelul conceptual (sau global). Este nivelul imediat superior celui fizic, datele
fiind privite prin prisma semanticii lor; intereseaz coninutul lor efectiv, ca i
relaiile care le leag de alte date. Reprezint primul nivel de abstractizare a lumii
reale observate. Obiectivul acestui nivel l constituie modelarea realitii
considerate, asigurndu-se independena bazei fa de orice restricie tehnologic
sau echipament anume. Toi utilizatorii i exprim nevoile de date la nivel
conceptual, prezentndu-le administratorului bazei de date, acesta fiind cel care
are o viziune global necesar satisfacerii tuturor cerinelor informaionale.
Nivelul extern. Este ultimul nivel de abstractizare la care poate fi descris o baz
de date. Structurile de la nivelul conceptual sunt relativ simple, ns volumul lor
poate fi deconcertant. Iar dac la nivel conceptual baza de date este abordat n
ansamblul ei, n practic, un utilizator sau un grup de utilizatori lucreaz numai cu
o poriune specific a bazei, n funcie de departamentul n care i desfoar
activitatea i de atribuiile sale (lor). Simplificarea interaciunii utilizatori-baz,
precum i creterea securitii bazei, sunt deziderate ale unui nivel superior de
abstractizare, care este nivelul extern. Astfel, structura BD se prezint sub diferite
16 Capitolul 1

machete, referite, uneori i ca sub-scheme, scheme externe sau imagini, n funcie

de nevoile fiecrui utilizator sau grup de utilizatori.

Utilizator A1 Utilizator A2 Utilizator B1 Utilizator B2 Utilizator B3

Comenzi Comenzi
Aplicaie Aplicaie Aplicaie
autonome autonome

Schem extern Imagine A Schem extern Imagine B

A (nivel extern) B (nivel extern)

Interfa A Interfa B
dintre nivelele dintre nivelele
global i extern global i extern

SISTEM DE
Schema Imagine global GESTIUNE A
conceptual BAZEI
(nivel global)
(global) DE DATE

Interfa dintre nivelele

fizic i global

Definirea structurii
interne de stocare Baza de date memorat pe disc
(Schema intern)

Figura 1.5. Schematizare a unui sistem de lucru cu o baz de date

Posibilitatea modificrii structurii la un nivel, fr a afecta structura nivelului
sau nivelurilor superioare, se numete autonomie a datelor stocate n baz,
analizabil pe dou paliere.
Autonomia fizic reprezint posibilitatea modificrii arhitecturii bazei la nivel
intern, fr ca aceasta s necesite schimbarea schemei conceptuale i rescrierea
programelor pentru exploatarea bazei de date. Asemenea modificri sunt necesare
uneori pentru ameliorarea performanelor de lucru (vitez de acces, mrimea
fiierelor etc.). Tot autonomia fizic este cea care asigur portarea bazei de date de
pe un sistem de calcul pe altul fr modificarea schemei conceptuale i a
programelor.
Autonomia logic presupune posibilitatea modificrii schemei conceptuale a
bazei (modificare datorat necesitii rezolvrii unor noi cerine informaionale)
fr a rescrie programele de exploatare. Autonomia logic a datelor este mai greu
de realizat dect autonomia fizic, deoarece programele de exploatare sunt
dependente, n foarte mare msur, de structura logic a datelor pe care le consult
i actualizeaz, n ciuda existenei dicionarului de date. Firete, un element
important l reprezint i anvergura modificrii schemei conceptuale.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 17

Pe baza noilor elemente prezentate, putem s relum caracteristicile datelor

stocate ntr-o BD6:
partajabilitate disponibilitate pentru un mare numr de utilizatori i
aplicaii;
persisten existen permanent, din momentul prelurii n baz pn n
momentul actualizrii sau tergerii (tergere cu sau fr arhivare);
securitate protejarea de accesul neautorizat, att n ceea ce privete citirea
i copierea, ct i modificarea i tergerea;
validitate referit i ca integritate sau corectitudine privete gradul de
adecvare dintre datele din baz i realitatea, procesele, tranzaciile pe care
le reflect aceste date;
consisten de multe ori, procesele/tranzaciile sunt preluate n baz sub
forma mai multor entiti (sau atribute). Aceste entiti/atribute trebuie s
fie n concordan unele ce celelalte, s respecte relaiile existente ntre
aspectele proceselor reale pe care se reflect;
nonredundan - pe ct posibil, o entitate din realitate ar trebui s aib un
singur corespondent n baza de date;
independen privete autonomia logic i fizic evocate mai sus.

1.6. Module, limbaje i utilizatori ale SGBD-urilor

Realizarea unui SGBD reprezint un demers extrem de complex, innd seama
de volumul datelor de stocat i prelucrat, numrul utilizatorilor conectai simultan
la baz, viteza de onorare a solicitrilor informaionale, precum i cerinele de
integritate i securitate. Majoritatea covritoare a celor ce lucreaz cu bazele de
date se descurc onorabil fr a ti detaliile de organizare a SGBD-ului, ba chiar
fr s fie contieni de existena SGBD-ului. Alii, precum administratorii de baze
de date, sunt obligai s cunoasc destul de multe despre organizarea fizic,
indeci, buffere, jurnal, drepturi ale utilizatorilot etc., iar alii chiar lucreaz n
echipe care fabric SGBD-uri, adic le proiecteaz, realizeaz anumite module, le
testeaz etc.
Pentru a avea o idee general despre modulele eseniale ale unui SGBD apelm
la o schem clasic prezentat n figura 1.67. Dup spusele autorilor figuri
foarte cunoscute n lumea bazelor de date -, dreptunghiurile simple reprezint
module ale sistemului, dreptunghiurile duble - structuri de date rezidente n
memorie, sgeile cu liniatur simpl indic fluxuri i de date i de control, n timp
ce sgeile punctate reprezint fluxuri (numai) de date.

6 Unii autori, precum [Atzeni s.a. 1999], adaug explicit drept caracteristic dimensiunea foarte
mare a bazei de date. n cea mai mare parte a lucrrilor dedicate bazele de date, aceast caracteristic
este una implicit.
7 Preluare din [Garcia-Molina s.a. 2002], p.11
18 Capitolul 1

Figura 1.6. Structura unui sistem de lucru cu o baz de date

1.6.1. Module principale

Schema de mai sus este destul de impresionant (cel puin pentru mine), dei
este vorba de o reprezentare simplificat a ceea se ntmpl n inima SGBD-ului.
Sistemul nu scrie datele din memorie pe disc chiar imediat dup preluarea lor, ci
la anumite intervale de timp. De aceea, o component important, pe lng
gestionarul stocrii, este gestionarul buffer-elor. Accesul rapid la date este
imposibil fr indeci, astfel nct n figur apare gestionarul indecilor/fiiere-
lor/nregistrrilor. Arbitrajul mai multor utilizatori/module ce lucreaz simultan
cu baza de date, i, implicit, rezolvarea eventualelor blocaje, este asigurat de
modulul de control al simultaneitii (concurenei).
Pstrarea integritii i coerenei bazei de date presupune gruparea
operaiunilor n tranzacii pe principiul totul sau nimic. Cderea uneia dintre
operaiunile tranzaciei atrage n sine cderea ntregii tranzacii i revenirea (resta-
urarea) bazei de date pe starea dinaintea tranzaciei. Acest mecanism tranzaci-
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 19

onal care presupune jurnalizarea cade sub incidena gestionarului de tranzacii i a

modulului de jurnalizare i recuperare.

1.6.2. Limbaje de definire a datelor

Figura 1.6 pune n eviden cele dou compilatoare care corespund categoriilor
clasice de limbaje pentru lucrul cu bazele de date DDL (Data Definition
Language) care este un limbaj destinat gestionrii structurii bazei i DML (Data
Manipulation Language) care este un limbaj pentru gestionarea coninutului.
Arhitectura unei baze de date este specificat printr-o serie de definiii redactate
sub form de instruciuni scrise n limbajul de definire a datelor - DDL (Data
Definition Language). Execuia acestor definiii se materializeaz ntr-un ansamblu
de tabele, tabele virtuale, proceduri stocate, secvene etc. care sunt memorate ntr-
un fiier special, denumit dicionar (sau repertoar) de date. Un dicionar de date
conine deci metadate, adic date relative la alte date, fiind consultat naintea
oricrei citiri sau modificri a datelor din baz.
Principale funciuni ale DDL sunt:
- Descrierea logic a bazei de date i sub-schemelor proprii fiecrui grup de
utilizatori.
- Identificarea schemei, sub-schemelor i diverselor agregri de date.
- Specificarea fiierelor de date i a legturilor logice dintre acestea. Pe baza
acestor specificaii se poate realiza accesul la date chiar i n condiiile co-
existenei mai multor modele de organizare ntr-o aceeai BD.
- Definirea restriciilor semantice la care sunt supuse datele, restricii care se
refer la ansamblul valorilor permise fiecrei date, eventual formula de
calcul a unei date pe baza valorilor altor date. Respectarea acestor restricii
asigur coerena bazei.
- Definirea cheilor de acces rapid i a cheilor confideniale (parolelor).
- Definirea metodelor de exploatare a fiierelor ce vor fi utilizate n
aplicaii pentru selectarea nregistrrilor.
- Definirea procedurilor speciale de criptare, n vederea generrii cheilor de
acces.
- Definirea modalitilor de indexare i localizare ale entitilor.
- Determinarea tipului unei date, de baz sau derivat (calculat printr-o
expresie, pe baza valorilor altor date).
Dat fiind complexitatea structurilor de memorare i metodelor de acces la
acestea, la nivel elementar fiierele de date i dicionarul de date sunt accesibile
numai unui numr restrns de conaisseuri. n schimb, pentru descrierea schemei
BD, marea majoritate a limbajelor de interogare prezint comenzi adecvate, ce pot
fi utilizate i de non-informaticieni.
Cel mai important limbaj dedicat bazelor de date, SQL despre care vom
discuta ncepnd cu al treilea capitol, prezint comenzi DDL cum ar fi: CREATE
TABLE, ALTER TABLE, DROP TABLE, CREATE/ALTER/DROP VIEW, CREA-
TE/DROP INDEX, CREATE/DROP PROCEDURE, CREATE/DROP TRIGGER,
CREATE/DROP SEQUENCE etc.
20 Capitolul 1

1.6.3. Limbaje de manipulare a datelor

Prin manipularea datelor se nelege efectuarea uneia dintre urmtoarele

operaiuni:
extragerea unor date din baz (consultare);
scrierea de noi date n baz (adugare);
tergerea datelor perimate sau eronate (uneori chiar i a celor corecte);
modificarea valorii unor date.
Un limbaj de manipulare a datelor (DML - Data Manipulation Language) este
utilizat pentru a prelucra datele n funcie de structura lor. La nivel fizic, prin DML
se vizeaz identificarea i implementarea unor algoritmi performani de acces la
date, n timp ce la nivel extern DML trebuie s faciliteze dialogul utilizatorului cu
baza n vederea obinerii informaiilor dorite.
n mod curent, termenul consultare sau interogare desemneaz aciunea de
cutare i identificare a datelor necesare, dintre cele aflate n baz. Ansamblul
instruciunilor DML pentru cutarea i pentru identificarea datelor constituie
limbajul de consultare. Revenind la SQL, cele mai cunoscute comenzi DML sunt:
INSERT (pentru adugarea de nregistrri ntr-o tabel), DELETE (pentru tergerea
de linii dintr-o tabel), UPDATE (pentru modificarea valorii unuia sau mai multor
atribute, pe una sau mai multe nregistrri ale unei tabele) i SELECT (pentru
extragerea de informaii din una sau mai multe tabele).

1.6.4. Limbaje de control al datelor

Un element mai puin sugerat n figura 1.6 este grupul de comenzi prin care se
declar utilizatorii, grupurile de utilizatori (profilurile), precum i drepturile
fiecrui utilizator/profil la obiecte din schema bazei (tabele, tabele virtuale,
proceduri etc.). Aceste comenzi sunt arondate unui al treilea tip de limbaj destinat
bazelor de date DCL (Data Control Language). Dintre acestea, n standardul i
dialectele SQL cele mai frecvente sunt: CREATE USER, DROP USER,
CREATE/DROP ROLE, GRANT i REVOKE.

1.7. Utilizatorii bazelor de date

n figura 1.6 (stnga, sus) au acces la baza de date utilizatori/aplicaii care pot
lansa fie interogri i actualizri (adresate compilatorului de interogri), fie
comenzi privitoare la tranzacii (COMMIT care declar ncheierea cu succes a
unei tranzacii i ROLLBACK care abandoneaz o tranzacie). Tot n partea de
sus, dar n dreapta, este reprezentat personajul cheie n exploatarea unei baze de
date administratorul bazei de date. Cei mai puini vizibili n figura 1.6 sunt cei
care particip la realizarea unui SGBD, figura fiind interesat de cei care folosesc
bazele de date i SGBD-ul din momentul punerii n funciune a aplicaiei cu baze
de date.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 21

1.7.1. Utilizatori mai mult sau mai puin cureni

Cei mai numeroi utilizatori ai unei aplicaii ce folosesc baze de date sunt i cei
mai nevinovai n ale bazelor de date. Doamnele (i/sau domnioarele) din
figurile 1.1 i 1.2 au la dispoziie meniuri i formulare pentru a introduce
operaiuni, i rapoarte pentru a extrage informaiile necesare. Fluxurile dintre
ecran/claviatur/mouse i baza de date (locul unde se afl, de fapt, informaiile)
sunt invizibile acestor utilizatori.
Realizarea aplicaiilor care afieaz pe ecran meniurile, formularele i rapoartele
i care preiau datele introduse n baze cade n sarcina unei categorii profesionale
destul de pestrie denumit dezvoltatori de aplicaii cu baze de date. Zicem c
este pestri deoarece aici intr de-a valma: analiti i proiectani de sisteme
informaionale, proiectani de baze de date (pot fi aceeai sau diferii de anali-
tii/proiectanii de sisteme informaionale), programatori de interfee .NET, Java,
PHP etc., programatori de baze de date Oracle (PL/SQL), SQL Server (Transact-
SQL), PostgreSQL (plpgSQL), DB2 (SQL PL) etc., testeri s.a.m.d. Firete c, pentru
ceea ce discutm n cartea de fa, programatorii de baze de date reprezint o int
privilegiat.
Dezvoltatorii de aplicaii sunt implicai n fazele de realizare a aplicaiei
(proiectare, programare, implementare/instalare). Dup darea n folosin,
aplicaiile pot suferi modificri de mai mic sau mai mare amploare (datorate
schimbrilor din legislaia economic, regndirea modalitilor de derulare a unor
operaiuni n cadrul organizaiei), modificri ce cad tot n (co)responsabilitea
dezvoltatorilor. Dei sunt implicai n etapele de realizare a aplicaiei (unde pot
formula cerine, observaii i proteste legate de modul n care funcioneaz
modulele aplicaiei), utilizatorii cureni sunt destinatarii principali ai aplicaiei din
momentul instalrii (implementrii) acesteia, cei care o vor folosi pentru a
introduce operaiuni i a obine informaii/rapoarte.
ntre categoria nevinovailor i cea a dezvoltatorilor de aplicaii cu baze de
date exist multe nuane de utilizatori ce dispun de suficiente cunotine care s le
permit obinerea de informaii din baz sau chiar s modifice o serie de date
direct, fr mijlocirea aplicaiei. Prin urmare, exist utilizatori care nu sunt nici
administratori, nici dezvoltatori, dar care sunt n stare (i au drepturi suficiente) s
lanseze interogri (fraze SELECT), comenzi de editare a nregistrrilor
(INSERT/UPDATE/DELETE) sau s-i gestioneze propriile tabele, proceduri,
tabele virtuale etc. Stilul acesta direct cu baza seamn cu lucrul cu un ferstru
electric fr apratoare, deoarece chiar i n condiiile folosirii tranzaciilor, cteva
minute de neatenie pot antrena sptmni ntregi de migrene.

1.7.2. Administratorul bazei de date

Folosind limbajul mafiot, se poate spune c administratorul unei baze de date

este il capo di tutti capi, sau, n cel castrist, il lider maximo. Administratorul
unei baze de date este persoana responsabil de sistem n ansamblul su. Rolul
acestuia este determinant n:
22 Capitolul 1

- Definirea arhitecturii bazei de date, realizat prin redactarea definiiilor

care vor fi transformate de compilatorul DDL n tabele i alte obiecte
stocate permanent n dicionarul de date;
- Definirea modalitilor n care va fi structurat memoria extern i a
metodelor de acces la date;
- Modificarea arhitecturii i organizrii fizice a bazei de date;
- Autorizarea accesului la date se acord fiecrui utilizator sau grup (rol) al
bazei de date, administratorul fiind cel care decide asupra datelor ce pot fi
consultate i actualizate de fiecare utilizator sau grup de utilizatori;
- Specificarea restriciilor de integritate care sunt stocate pe disc i
consultate de gestionarul bazei la fiecare actualizare.
n plus, administratorul bazei de date este cel care: asigur legtura cu
utilizatorii; definete procedurile de verificare a drepturilor de acces i a
procedurilor de validare a integritii datelor; definete strategia de salvare
(nregistrarea copiilor de siguran)/restaurare a bazei; monitorizeaz performan-
ele bazei i o adapteaz la modificrile ulterioare ale sistemului informaional.
Dat fiind c are mn liber n crearea, utilizarea i optimizarea bazei, n
acordarea de drepturi utilizatorilor, administratorul trebuie s fie nu numai un bun
profesionist, dar i o persoan de caracter. Un suprcios sau frustrat poate
nenoroci irevesibil tot capitalul informaional al firmei. Pe de alt parte, i
managerii ar trebui s se poarte ct mai frumos cu administratorul bazei de date
(indiferent de ceea ce gndesc despre el).

1.8. Modele de organizare a datelor n BD

Nucleul unei baze de date l reprezint dicionarul de date ce conine structura
bazei. Analiza, proiectarea i implementarea structurii (schemei) bazei se realizeaz
utiliznd un model de date, model ce reprezint un ansamblu de instrumente
conceptuale care permit descrierea datelor, relaiilor dintre ele, a semanticii lor, ca
i a restriciilor la care sunt supuse.
Modelul datelor din BD este o reprezentare a obiectelor lumii reale i a
evenimentelor asociate lor. Presupune un demers de abstractizare care se
concentreaz pe aspectele eseniale ale organizaiei/aplicaiei, furniznd concepte-
le i notaiile care vor permite utilizatorilor bazelor de date s comunice clar i
rapid informaiile i cunotinele lor despre datele organizaiei.
O grupare "tradiional" a modelelor utilizate n bazele de date delimiteaz trei
categorii: modele logice bazate pe obiect, modele logice bazate pe nregistrare i
modele fizice. Din punctul nostru de vedere, intereseaz numai nivelurile concep-
tual i extern de abstractizare a datelor; de aceea, vom prezenta, n linii mari,
numai reprezentanii principali ai primelor dou categorii.
Modelul ierarhic. Primele produse-software (Sisteme de Gestiune a Bazelor de
Date SGBD-uri) lucrau cu baze de date ierarhice. Structura datelor este
prezentat sub forma unui arbore - vezi figura 1.7 -, partea superioar a arborelui
fiind rdcina (arborele este vzut "cu verdele n jos"). Un nod-tat poate avea mai
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 23

multe noduri-fii. Un fiu nu poate exista independent de tatl su. Legtura

(reprezentat prin linie) se face exclusiv ntre tat i fii. Orice fiu poate fi i tat,
deci poate avea, la rndul su, fii.
Astfel, n clasa a IX-a A (profil Uman) exist doi elevi: Pop I. Vasile ce are
numrul matricol 4545 i domiciliaz pe strada Primverii nr. 22, iar al doilea, Ion
V. Viorel, are matricolul 4550 i locuiete pe strada Corupiei nr. 13 bis. Vasile a
luat la fizic (profesor Cernat Dan, nscut pe 21 aprilie 1968) un 5 pe 8 februarie
2002 i un 9 pe 15 februarie. La istorie (profesor Pal Dana, nscut pe 12 noiembrie
1975) st ceva mai bine, avnd un 8 (cptat pe 21 februarie), un 7 (pe 28 februarie)
i un 8 (pe 7 martie). n acelai mod poate fi interpretat figura pentru Ion V.
Viorel, cu meniunea special c istoria nu e punctul lui forte.

Figura 1.7. Arbore de structur specific modelului ierarhic

Modul n care nregistrrile se nlnuiesc presupune folosirea unor pointeri (un
soi de adrese fizice) ce nu sunt reprezentai n figur (din considerente umanitare).
Aflarea informaiilor din baza de date presupune navigarea ntre nregistrri cu
ajutorul pointerilor. n plus, modificarea structurii bazei de date presupune
actualizarea nlnuirii pointerilor, ceea ce este extrem de laborios. A alt problem
a acestui model o reprezint imposibilitatea reprezentrii cazului n care un copil
este, pardon, "rezultatul" a mai muli tai. Situaia nu este att de scandaloas cum
v-ai nchipuit, i aceasta doarece modelul ierarhic nu face nici o referire la mama
fiului.
Figura 1.7 este relevant pentru gradul de redundan impus de reprezentarea
ierarhic. Codul, denumirea, numrul de ore ale fiecrei discipline, precum i
datele despre profesor, apar pentru fiecare elev, dei acestea sunt comune la nivel
de an de studii (numele disciplinei, numrul de ore) sau la nivel de clas
(profesorul titular).
Modelul reea. Este o dezvoltare a modelului ierarhic, prin care se pot
reprezenta i situaiile n care un fiu "posed" mai muli tai. nregistrrile sunt
privite n BD ca o colecie de grafuri cu o structur asemntoare celei din figura
1.8. Navigarea se face tot prin pointeri.
24 Capitolul 1

Figura 1.8. Graf specific reprezentrii utiliznd modelul reea

Modelul reea elimin o serie de probleme specifice modelului ierarhic. Spre
exemplu, cazul ilustrat n figura 1.7 poate fi reprezentat dup logica modelului
reea ca n figura 1.8. Se observ c fiecare disciplin (i profesorul care o pred la
clasa respectiv) apare o singur dat, fiind legat prin linii de toate notele
obinute de fiecare dintre elevi. Legturile dintre nregistrri se fac tot cu pointeri,
iar modificarea nlnuirii pointerilor rmne o operaiune foarte migloas.
Modelul relaional a fost urmtorul n ordinea cronologic i rmne cel care
domin copios piaa bazelor de date i la acest moment, motiv pentru care i
rezervm un capitol special, urmtorul.
Modelul obiectual. n programare, orientarea pe obiecte i are nceputurile n
anii 60, consacrarea n anii 80, iar gloria dup anii 90. ncepnd cu anii 90,
orientarea pe obiecte capt importan major i n analiz i proiectare, reuind
s se consituie ca alternativ viabil metodologiilor structurate. Pe baza acestui
succes, s-a crezut c i n materie de baze de date, modelul obiectual l va surclasa
pe cel relaional pn n 2000. Rezultatele sunt ns deprimante pentru suporterii
OO-ului, piaa SGBD OO fiind sub 6% din valoarea total a pieii bazelor de date8.
Modelul relaional-obiectual. Este un model mai recent ce ncearc s
valorifice deopotriv atuurile relaionalului i ale orientrii pe obiecte. Dei privit
mai degrab cu nencrederile n cercurile teoreticienilor, acest model se impune
ncet-ncet datorit marilor productori de software dedicat bazelor de date.

Pe lng aceste modele de organizare efectiv a datelor n baze, exist i modele

pur teoretice, utile analitilor i proiectanilor de sisteme informaionale i aplicaii,

8 Acest procent a rmas valabil de la prima ediie a crii, nefiind exclus ca mrimea sa s fie, de
fapt, supraevaluat.
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 25

dar care nu au fost nc implementate. Probabil cel mai cunoscut reprezentant al

acestei categorii de modele semantice este modelul entitate-relaie.

1.9. Noiuni preliminare n lucrul cu bazele de date

ncercam s v conving n paragraful 1.5 c nu putem lucra cu bazele de date
dect prin intermediul sistemelor de gestiune a bazelor de date (SGBD), de care ne
vom ocupa i n paragraful 2.4 (dedicat SGBD-urilor construite pe logica modelului
relaional). n continuare, dorim s lmurim cteva noiuni legate de practica
folosirii unui SGBD, i anume: conexiune, sesiune, script, modul de program i
tranzacie.

Conexiuni, sesiuni & clieni

Dac vrem s adugm, modificm sau tergem informaii dintr-o baz de date,
sau chiar i dac numai vrem s aruncm un ochi la cteva informaii aflate n
baz, este necesar s stabilim o conexiune la baza de date, prin intermediul SGBD-
ului. Dac vom reui, vom fi clienii bazei de date, calculatorul pe care lucrm fiind
platforma client. SGBD-ul cu ajutorul cruia vom avea acces la baz este serverul
bazei de date. Comanda folosit n multe SGBD-uri este chiar CONNECT. Pentru ca
s fim luai n serios, la conectare trebuie s introducem un nume de utilizator i o
parol pe care serverul s le recunoasc, altfel tocim claviatura degeaba vezi
figura 1.9.

Figura 1.9. Tentativ euat de conectare la serverul Oracle (din SQL*Plus) 11g
M grbesc s diluez cteva dintre eventualele malentendu-uri. Mai nti,
SGBD-urile actuale nu au interfaa att de neguroas. Doar administratorii/dez-
voltatorii, din dorina de a impresiona, sau masochitii (din alte dorine) mai
lucreaz azi n mod text (uneori cele dou categorii se intersecteaz n bun
msur). Restul oamenilor nu-prea-pricepui i/sau normali prefer interfee mai
prietenoase, dup cum o s vedem nu peste mult timp. n al doilea rnd, o
conexiune la baza de date nu nseamn nicidecum accesul la toat baza de date, ci
doar la unele obiecte, pe care utilizatorul le poate vedea i, eventual, modifica.
26 Capitolul 1

Prin conexiune, avem acces la o fereastr a bazei. Conexiunea presupune ca, n

prealabil, cineva s creeze utilizatorul, s-i atribuie o parol, i s-i confere anumite
drepturi la obiecte ale bazei de date. Acest (semi)demiurg creator ia, de cele mai
multe ori, forma dumnoas a administratorului bazei de date.
ntre utilizatorul care se chinuie s se conecteze la baz i baza propriu-zis
poate fi o distana de zeci, sute, mii ... de calculatoare (uneori i kilometri).
Calculatorul pe care lucreaz utilizatorul va adresa cererea de access, iar SGBD-ul
dispune de un serviciu de ascultare (numit de obicei chiar listener - asculttor) care
preia cererea, iar apoi verific corectitudinea numelui i parolei, i, dac lucrurile
sunt n regul, se aloc un spaiu n memoria serverului special pentru aceast
conexiune n care utilizatorul urmeaz s se dezlnuie. n plus, arhitecturile web
actuale prezint servere de aplicaii care acioneaz ca intermediari ntre utilizatori
(clieni) i serverul de baz de date.

Figura 1.10. Exemplu simplist de conexiune/tranzacie/comenzi Oracle 11g (SQL*Plus)

De-conectarea i re-conectarea la baza de date se face prin comenzi succesive
DISCONNECT/CONNECT vezi figura 1.10. O sesiune de lucru ncepe din
momentul n care un client se conecteaz la un server de baz de date i se termin
n momentul de-conectrii de la server vezi figura 1.10. ntr-o sesiune pot fi
lansate n execuie comenzi i module de program.

Dup cum spuneam mai sus, ar fi destul de traumatizant s lucrm cu o baz

de date beneficiind de o intefa n mod text, cum este cea din figurile 1.9 i 1.10 de
SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 27

lucru. De aceea, fiecare server de baze de date dispune de interfee grafice

mbietoare. Unele sunt parte integrant a sofware-ului pentru baza de date. Este
cazul MS SQL Server (Management Studio) vezi figura 1.11.

Figura. 1.11. Conectarea la MS SQL Server (prin Management Studio)

Similar, IBM DB2 dispune de un modul numit Control Center prin care se poate
realiza conectarea la baza de date vezi figura 1.12. Alte aplicaii-client pot fi
instalate separat, cum ar fi pgAdmin dedicat PostgreSQL (vezi figura 1.13) sau SQL
Developer pentru Oracle.
28 Capitolul 1

Figura. 1.12. Conectarea la IBM DB2 (prin Control Center)

Figura. 1.13. Conectarea la PostgreSQL (prin pgAdmin)

SQL. Dialecte DB2, Oracle, PostgreSQL i SQL Server 29

Dei produs de firma Oracle, deci destinat cu precdere acestui server, SQL
Developer-ul este ceva mai ambiios, fiind n stare s realizeze conexiuni i cu baze
de date create cu Microsoft Access vezi figura 1.149. Exist i clieni
independeni, unii dedicai unui singur SGBD (ex. SQL Navigator produs de
Quest Software, SQLDetective produs de Conquest Software, PL/SQL Developer
produs de Allround Automations sunt destinate dezvoltrii de aplicaii cu baze de
date Oracle), iar alii asigur conexiunea la dou sau mai multe dintre SGBD-urile
actuale, cum ar fi TOAD (Quest Software).

Figura. 1.14. SQLDeveloper - un client pentru conectarea la baze de date Oracle sau
Access
Comenzi, scripturi i module de program
Odat conectat la baz, un utilizator poate creea, modifica sau terge obiecte
celebrele comenzi DDL (cum este CREATE TABLE n figura 1.10) -, sau
consulta/modifica coninutul bazei de date comenzi DML (cum sunt comenzile
INSERT i SELECT din figura 1.10). Ar mai fi i comenzile DCL prin care se
creeaz utilizatori /grupuri i se acord/revoc drepturi la obiecte din baz, dar
acestea sunt pentru administratori. Comenzile pot fi lansate direct, rnd pe rnd,
sau pot fi grupate n module de program. n aceast carte vom folosi, de cteva ori,
i termenul script i pe cel de program/modul.

9 Nu cunosc niciun utilizator de Access care s foloseasc SQL Developer, ns atunci cnd se
dorete trecerea bazei de date din Access n Oracle, probabil c SQL Developer-ul este de real folos.
30 Capitolul 1

Pentru lucrarea de fa, un script este un fiier (de obicei ASCII/text) care
adun, una dup alta, comenzi DDL i/sau DML (sau chiar DCL). Un script nu
conine structuri de control alternative sau repetitive (IF-uri, LOOP-uri, etc.),
structuri ce constituie substana unui modul de program. Un modul de program
este redactat ntr-un limbaj anume (C, Java, Basic, PL/SQL, T-SQL etc.), n timp ce
un script nu are nicio legtur cu un limbaj anume. Important este ca sintaxa
comenzilor din script s fie acceptat de SGBD-ul pe care se lanseaz n execuie.

Tranzacii
i acesta este un subiect asupra cruia vom reveni pe parcursul emisiunilor.
Pentru nceput, s convenim c o tranzacie este o succesiune de comenzi (de
obicei, DML) care funcioneaz pe principiul toi-pentru-unul, unul-pentru-toi
sau, mai bine zis, toul sau nimic. De exemplu, grupm ntr-o tranzacie 50 de
comenzi DML (inserare/modificare/tergere), comenzi lansate individual, dintr-
unul sau mai multe scripturi, i/sau module de program. 49 merg strun, dar a 50-
a genereaz o eroare n baza de date (o restricie nclcat, s zicem). Din cauza
acestei ultime comenzi buclucae, toate celelalte 49 de comenzi pot fi anulate, din
raiuni de solidaritate, printr-o comand speciala, ROLLBACK. Dac i a 50-a
funcioneaz cum trebuie, declarm printr-o alt comand COMMIT c
tranzacia s-a ncheiat cu succes, iar modificrile pot fi consemnate definitiv n
baz. Lucrul cu tranzacii este foarte important n pstrarea corectitudinii/integri-
tii bazei de date, dup cum vom vedea n cteva dintre capitolele viitoare.