aplicații în gestiunea salariaților Coordonator științific: Absolvent Conf. Dr. BOLDEA Costin -Radu NINE Liviu Ionuț CRAIOVA 2019 1 CUPRINS 1…. [624334]

UNIVERSITATEA DIN CRAIOVA
FACULTATEA DE ȘTIINȚE
SPECIALIZAREA INFORMATICĂ

Baze de date distribuite cu
aplicații în gestiunea salariaților

Coordonator științific: Absolvent: [anonimizat] -Radu NINE Liviu Ionuț

CRAIOVA
2019

1

CUPRINS

1. INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. 3
2. BAZE DE DATE CLIENT/ SERVER ………………………….. ………………………….. ………………………….. . 5
2.1. DESCRIEREA RELAȚIEI C LIENT /SERVER ………………………….. ………………………….. ………………………. 5
2.2 CARACTERISTICI ALE AR HITECTURII CLIENT -SERVER ………………………….. ………………………….. …….. 9
2.3 SERVERE ȘI BAZE DE DA TE DISTRIBUITE ………………………….. ………………………….. ……………………. 10
2.4 ARHITECTURI DE SERVER E DISTRIBUITE DE DAT E………………………….. ………………………….. ………… 12
2.5 PLASAREA DATELOR ………………………….. ………………………….. ………………………….. ………………… 16
2.6 TIPURI D E SERVERE ………………………….. ………………………….. ………………………….. ………………….. 18
2.7 CONFIGURAȚII ALE BAZELOR DE DATE CS ………………………….. ………………………….. ………………… 20
a. Model pentru BD centralizată ………………………….. ………………………….. ………………………….. …. 20
b. Model pentru BD fișier -server ………………………….. ………………………….. ………………………….. …. 21
c. Model pentru procesarea extragerilor din BD ………………………….. ………………………….. ………… 22
d. Modelul pentru BD client/server ………………………….. ………………………….. ………………………….. 23
e. Software Front -end ………………………….. ………………………….. ………………………….. ……………….. 24
f. Model pentru o BD distribuită ………………………….. ………………………….. ………………………….. … 25
3. LIMBAJUL PL/SQL. ………………………….. ………………………….. ………………………….. ………………….. 26
3.1 SCURT ISTORIC ………………………….. ………………………….. ………………………….. ……………………….. 26
3.2 ELEMENTELE LIMBAJULUI PL/SQL ………………………….. ………………………….. ………………………….. 27
3.3 TIPURI DE DATE ………………………….. ………………………….. ………………………….. ……………………….. 29
3.4 CURSOARE ………………………….. ………………………….. ………………………….. ………………………….. …. 30
3.5 IDENTIFICATORI ………………………….. ………………………….. ………………………….. ………………………. 31
3.6 OPERATORI ………………………….. ………………………….. ………………………….. ………………………….. … 32
3.7 ATRIBUIREA FOLOSIND SELECT … INTO ………………………….. ………………………….. …………………. 33
3.8 STRUCTURI DE CONTROL ………………………….. ………………………….. ………………………….. …………… 33
a. IF ………………………….. ………………………….. ………………………….. ………………………….. ………….. 33
b. CASE ………………………….. ………………………….. ………………………….. ………………………….. ……… 34
c. LOOP ………………………….. ………………………….. ………………………….. ………………………….. …….. 36
d. Folosirea comenzii EXI T………………………….. ………………………….. ………………………….. ……….. 36
e. Comanda EXIT -WHEN ………………………….. ………………………….. ………………………….. …………. 37
f. Etichetarea unei blucle PL/SQL ………………………….. ………………………….. ………………………….. . 37
g. Bucla WHILE -LOOP ………………………….. ………………………….. ………………………….. …………….. 38
h. Instructiunea FOR -LOOP ………………………….. ………………………….. ………………………….. ………. 38
3.9 PROCEDURI ȘI FUNCȚ II ………………………….. ………………………….. ………………………….. ………………. 40
a. Crearea unei proceduri ………………………….. ………………………….. ………………………….. ………….. 40
b. Parametrii procedurilor PL/SQL ………………………….. ………………………….. …………………………. 42
c. Definirea unei funcții ………………………….. ………………………….. ………………………….. …………….. 44
4. PREZENTAREA APLIC AȚIEI ………………………….. ………………………….. ………………………….. ……. 46
4.1 SCURTĂ PREZENTARE A A PLICA ȚIEI………………………….. ………………………….. ………………………….. 46
4.2 AUTENTIFICAREA ………………………….. ………………………….. ………………………….. …………………….. 47
4.3 CONEXIUNEA JAVA- ORACLE ………………………….. ………………………….. ………………………….. …… 48
4.4 GESTIUNEA SALARIAȚIOR ………………………….. ………………………….. ………………………….. ………….. 48
5. CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. ….. 55
6. BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………… 56

2

3

1. Introducere

Bazele de date sunt extrem de răspândite, ele stau la baza tehnologiei utilizate de
către cei mai mulți oameni în fiecare zi, dacă nu în fiecare oră. Bazele de date stau în
spatele multor site -uri web, acestea fiind o componentă esențială a sistemelor de
telecomunicații , sistemelor bancare, jocurilor video, și alte sisteme software sau
dispozitive electroni ce care conțin anumite informații persistente. În plus față de
persistență, sistemele de baze de date oferă o serie de alte proprietați care le fac extrem de
utile și comode: fiabilitate, eficiență , limbaje de interogare de nivel înalt și multe altele.
Majoritatea bazelor de date iau naștere de la o listă într -o foaie de calcul sau intr -un
editor de texte. În timp acest volum de informații crește odată cu creșterea activității unei
organizații , ceea ce face ca soluțiile să nu mai fie potrivite, deși la mome ntul respectiv
suntem tentați să credem că soluția aleasă este cea bună atâta timp cât necesitățile
informaționale sunt satisfăcute.
Sub formă de listă datele devin greu de înț eles, iar posibilități le de căutare, regăsire
și extragere a subseturilor de date pen tru revizuire, actualizare ș i¸ utilizare devin cu
timpul extrem de limitate. Odată apărute aceste probleme, cea mai bună idee ar fi aceea a
transferului acestor date într -o bază de date creată cu ajutorul unui sistem de gestiune al
bazelor de date.
În prezent este tot mai clar faptul că explozia informațională este de ani buni
trăsătura definitorie care caracterizează activitățile fiecărei instituții sau organizații ,
indiferent de domeniul său de activitate. Volumul tot mai mare de informații nu mai
poate fi folosit eficient cu ajutorul mijloacelor tradiționale și trebuie stocat. Procesul de
prelucrare automată datelor prin intermediul sistemelor electronice de calcul a devenit o
necesitate pentru majoritatea domeniilor d e activitate.
Atunci când analizăm necesitățile informaționale ale unei organizații, avem în
vedere în principal identificarea atributelor și relațiilor. Putem privi o entitate ca un obiect
distinct ce aparține unei organizații și care trebuie reprezentat în baza de date. Atributul
este o proprietate care descrie un aspect oarecare al obiectului pe care dorim să -l
înregistrăm, iar relația se referă la o asociație între diferite entită ți.

4

Astfel, putem spune că baza de date conține entitățile , atributele și relațiile logice dintre
ele.

Fiecare bază de date o putem privii din diferite perspective:
• Perspectiva utilizatorului, care lucrează cu diferite părți componente ale unei baza
de date, numite vederi. Vederile sunt descrise prin intermediul unor subscheme în
sublimbaje ale limbajului de descriere a datelor. Utilizatorii pot primii răspunsuri la
cererile pe care le formulează prin intermediul limbajului de prelucrare a datelor;
• Perspectiva administratorului bazei de date, care integrează toate vederile refe ritoare
la baza de date într -un singur model numit schemă conceptuală. Această schemă
conceptuală constituie nivelul logic al bazei de date;
• Perspectiva implementatorului bazei de date, care în foarte multe situații coincide cu
administratorul bazei de dat e, care privește baza de date ca pe o colecție de fișiere
memorate pe diferite medii externe. Acesta constituie nivelul fizic al bazei de date și
care este practic singurul nivel care există efectiv.

5

2. Baze de date client/server

2.1. Descrierea relație i client/server

Cercetările recente din teoria și tehnologia BD, au arătat că dimensiunea și
varietatea BD au crescut semnificativ și în prezent trec de zeci de giga -bytes. Gestiunea
BD pe un singur calculator, are ca rezultat o utilizare slabă a resurse lor calculatorului în
raport cu diverse cerințe. De exemplu, un SGBD poate să congestioneză memoria
principală și procesorul central când se selectează anumite date. Această situație provine
din centralizarea excesivă a datelor și a funcțiilor de gestiune pe același calculator. În
anul 1974 Canaday a avut ideea de a elibera procesorul central, prin separarea funcțiilor
de gestiune ale BD, dintr -un calculator principal și gruparea lor pe alte calculatoare
dedicate pentru execuția lor. Calculatorul principal pe care se execută programele de
aplicații, este numit calculator gazdă (host computer).
Calculatoarele dedicate sunt numite mașini BD, calculatoare BD sau
calculatoare backend. Acum se utilizează termenii de server de aplicații pentru
calculatorul gazdă ș i server de date pentru calculatorul dedicat. Creșterea considerabilă a
puterii de prelucrare a stațiilor PC și dotarea lor cu rețele de comunicații rapide, a făcut
posibilă înlocuirea terminalelor cu stații de lucru ce lucrează ca servere de aplicații
(clienți). Prima dată a apărut nevoia de a integra diverse staț ii de lucru conectate prin
intermediul unei rețele la un server de date, care a dus la o nouă organizare a resurselor
de calcul, numită server centralizat. Această organizare face o separare a ope rațiilor, ceea
ce duce la minimizarea comunicării dintre stația de lucru și serverul de date.

Calculul client -server

Într-o formă simplificată, calculul client -server, constă din aplicații ce sunt
compuse din două părți: una care se execută într -un si stem de calcul și este numită client ,
care solicită un serviciu de la o altă componentă care se execută pe un alt sistem de
calcul numit server .

6

O aplicație client -server, cuprinde o arhitectură de calcul care implică procese client,
ce solicită servicii de la procese server și necesită următoarele componente hardware:
– mașină client care este un sistem de calcul pe care se execută componenta clie nt a
plicației;
– mașina server care este un sistem de calcul pe care se execută componenta server
a aplic ației. Ea satisface cererile clientului și returnează rezultatele componentei
client.
– rețea de comunicații ce permite ca mesajele care compun cererea, să fie
transmise de la client la server și invers și ca un mesaj ce constă din rezultate
transmise de la server la client.
Modelul de software numit client/server, ne permite să realizăm diverse metode
de comunicare dintre clienți ( serverul de a plicații), de pe un calculator ș i serverul de
date de pe un alt calculator. Paradigma client/server, permite ca o mulțime de
componente să solicite un serviciu care poate fi comun unei componente server. De
asemenea, permite ca o componentă client să acces eze o mulțime de servere diferite.
Această paradigmă poate fi utilizată la crearea de diverse forme de calcul distribuit.
Conectarea dintre client și server și transferul de date, utilizează protocoale de
comunicație și interfețe de rețea.
Protocolul de re țea, este o mulțime de reguli care gestionează modul de transfer
al datelor dintre client și server .
Aceste reguli specifică: formatul datelor transmise prin rețea și modul de
retransmitere ale acestora în cazul pierderilor pe rețea. Informix on line supor tă două
protocoale de comunicație: TCP/IP și IPX/SPX. La configurarea conexiunii client -server,
atât clientul cât și serverul, trebuie să suporte același protocol pentru a fi posibilă
comunicarea.
Regulile protocolului sunt implementate în driverul protoco lului de rețea, care
conține un cod ce formatează datele în conformitate cu regulile protocolului, atunci când
acestea sunt transmise în rețea.
Clienții și serverele, au acces la driverul de rețea prin intermediul interfeței de
rețea. Interfața de programa re a aplicației care conține apeluri ale sistemului prin rutine

7

de bibliotecă, facilitează comunicarea (client/server) din rețea, ce se numește interfață de
rețea. În cazul folosirii protocolului TCP/IP, interfața de rețea poate fi SOKET sau TLI.
În cazul când se utilizează protocolul IPX/SPX, interfața care se utilizează este doar TLI.

Procesul client

Calculul client/server este o extensie logică a programării modulare. Programarea
modulară pleacă de la următorul concept: divizarea unei piese mari de software, în
componente module care ne permite ușoare dezvoltări și întrețineri. În această
arhitectură , modulele care apelează devin clienți (acelea care cer servicii) și modulele
apelate (care fac servicii) devin servere. Calculul client/server, a făcut un pas în plus, în
sensul că aceste module nu trebuie să fie executate în același spațiu de memorie.
Extensia logică a celor de mai sus, constă în aceea că, serverele și clienții rulează
pe mașini cu platforme hardware și software adecvate pentru funcțiile lor. De exemplu,
serverele SGBD, se execută pe platforme proiectate și configurate special, ce conț in
elemente speciale de gestiune ale fișierelor.
Clientul, este un proces (program) care trimite un mesaj la un proces server
(program), prin care se cere ca serverul să execute un serviciu (task). Programele client
gestionează în mod curent, acea parte a interfeței cu utilizatorul a unei aplicații ce
validează datele introduse de utilizator și trimite cererile la programele server, executând
anumite tranzacții logice. Astfel, acele părți din aplicație care constituie interfața cu
utilitatorul și pe care acesta o vede, este procesul client. Procesul client, gestionează de
asemenea resursele locale care interacționează cu utilizatorul cum ar fi: procesorul stației
de lucru, periferice, tastatură, etc. Unul din elementele de bază ale stației de lucru client,
este interfața grafică cu utilizatorul (GUI).
În anumite cazuri, procesul client, este o parte a sistemului de operare, care se
ocupă cu gestiunea ferestrelor, detectează acțiunile utilizatorului și afișează datele în
ferestre. În cazul exploatării distri buite între mai mulți utilizatori, este necesar să se evite
situațiile conflictuale. Cele mai importante aspecte care facilitează tehnologiile BDD
sunt:

8

– site-ul este un calculator al unei rețele care poate executa atât programe de
aplicații cât și func ții de gestiune;
– impactul arhitecturii calculatoarelor pentru BDD decurge din puterea stațiilor;
– rețeaua de calculatoare poate fi locală sau extinsă;
– gestiunea BDD se bazează pe modelul relațional.
Integrarea stațiilor de lucru într -un med iu distribuit, permite ca mai multe funcții
client, să fie distribuite în programe de aplicații ce se execută pe stații de lucru numite
servere de aplicații.

Unelte client

Un TK(toolkit), permite unui programator să instaleze forme de intrări și de
afișări, pentru datele care sunt solicitate și de asemenea permite elaborarea secvențelor de
forme logice pentru fluxul de control. Astfel de TK sunt numite LG4. Exemple de LG4
sunt:
 Power -Builder elaborat de Sybase;
 Visual Basic elaborat de Microsoft;
 W/4GL elaborat de Computer Asociated;
 SQL -form elaborat de Oracle.
De fapt, există pe piață cel puțin 75 de LG4, care oferă capabilități similare. În plus,
un TK trebuie să cuprindă: un toolkit de proiectare a BD, tehnici de apelare de
servicii din SGBD, e tc.

Procesul ”server ”
Un proces server (program), satisface cererea clientului prin executarea taskului
cerut. Procesele server care primesc cereri de la programele client, execută actualizări și
regăsiri în BD, gestionează integritatea datelor și expedia ză răspunsuri. Procesele server
de bază, execută tranzacții logice simple sau complexe și pe alte mașini sau rețele.
Serverul, trebuie să cuprindă funcțiile de sistem de operare și rețea. El cuprinde o funcție
de sistem de gestiune și una de server de apli cație.

9

Serverul, procesează activități ca un motor software, ce gestionează resurse
distribuite ca: baze de date, legături de comunicații, procesoare de mare putere,
imprimante, etc.
Arhitectura client/server, cuprinde două sau trei nivele. O arhitectură p e două
nivele se realizează, când clientul “vorbește ” direct cu un server fără nici o intervenție a
altui server. Ea este utilizată în rețele mici (cu mai puțin de 50 de utilizatori.)
O arhitectură pe trei nivele, introduce un nou server (agent) între clie nt și server.
Rolul agentului este divers, el poate furniza servicii de tranzacții în aplicațiile de
moștenire dintr -un calcul client/server.

2.2 Caracteristici ale arhitecturii client -server

Caracteristicile de bază ale arhitecturii client -server sunt:
1. Unirea procesului client (partea care se vede) cu serverul care interacționează.
Procesul client, conține soluții logice specifice și furnizează interfața dintre utilizator și
restul aplicației. Procesorul server, joacă rolul unei mașini software, car e gestionează
resurse cum ar fi: baze de date, modemuri, imprimante și procesoare de mare putere.
2. Taskurile FE (Front -End) și BC (Back -End) au cerințe complet diferite de resurse
de calcul, ca de exemplu: viteza procesorului, memoria, capacitatea și viteza de transfer a
discului.
3. Echipamente multi -user. Platformele hardware și sistemele de operare ale
clientului și ale serverului, nu sunt de același tip de obicei. Procesele client, comunică
prin intermediul unor interfețe de program standard de apl icații (API) și RPC
binedefinite.
4. O caracteristică importantă a sistemelor client/server, este scalabilitatea. Ele pot fi
scalate pe orizontală sau pe verticală. Scalarea pe orizontală, înseamnă adăugarea sau
eliminarea stării de lucru cu impact minim asupra performanței. Scalarea pe verticală,
înseamnă trecerea la o mașină server mai mare, mai rapidă sau multi -user.

10

2.3 Servere și baze de date distribuite
Creșterea considerabilă a puterii de prelucrare a stațiilor personale și dotarea cu
rețele cu o comunicare rapidă care se vor accentua în viitor, au făcut posibilă înlocuirea
terminalelor cu stații de lucru, ce comunică cu servere de aplicații. Nevoia de a integra
diverse stații de lucru conectate prin intermediul unei rețele la un server de date, a dus la
o nouă organizare a resurselor calculatorului, care poate fi numită organizare cu server
centralizat. Această organizare, realizează separarea operațiilor, ceea ce duce la
minimizarea comunicării dintre stația de lucru și serverul de date. Interfaț a utilizator și
controlul datelor, fac ca puterea de prelucrare a unei stații de lucru să fie mai bine
utilizată. Interfața utilizator a unei stații de lucru poate fi complexă și cu: meniuri, forme,
cu ferestre multiple, etc. Interfața utilizator a unei st ații de lucru, trebuie proiectată cu
ajutorul comenzilor ce gestionează serverul de date pentru a evita supracomunicarea
(trimiterea a două sau mai multe comenzi simultan) și trimiterea de comenzi fără erori la
serverul de date. Acest lucru, poate fi reali zat prin utilizarea unor operații de control
semantic al datelor (controlul integrității semantice, autorizarea) pe stațiile de lucru, decât
pe serverul de date. Verificarea locală a tipului, permite introducerea eficientă a datelor în
mod interactiv. Info rmațiile despre date (tipuri și resticții), trebuie să fie disponibile pe
stația de lucru pentru a permite acest control.
O soluție, este gestionarea directoarelor de date și permiterea accesului de pe
stațiile de lucru, doar în modul read -only, când este nevoie. În acest caz, directoarele de
date sunt reactualizate de serverul de date central. Serverul de date, cu o asemenea
organizare suportă un număr mare de utilizatori (câteva sute). O primă soluție a creșterii
eficienței serverului de date, a fost crea rea unui software specializat, care constă din
implementrea unui SGBD într -un sistem de operare ce exploatează arhitectura uni –
procesor tradițională. O altă soluție mai avantajoasă este de a folosi o arhitectură formată
din mai multe echipamente hardware, organizate într -o structură (formată) paralelă,
utilizând o arhitectură multi -procesor.
În cazul serverului centralizat, se acceseză un singur server de către aplicațiile
distribuite în mod eficient. În această abordare centralizată, este foarte probabil s ă apară
dificultăți din cauza restricților tradiționale ale bazei de date. Aceasta, este deseori o

11

alternativă a BDD, deoarece toate dificultățile dispar în cazul folosirii unui server de date
locale. Adăugarea de noi servere de aplicații într -o rețea loca lă este ușor de efectuat din
punct de vedere tehnic, dar poate necesita o mărire a puterii de procesare a serverului de
date și a capacității de stocare. În plus, accesul la un singur server de date a serverelor de
aplicații situate la mari distanțe geogra fice, este ineficient, deoarece comunicarea într -o
rețea WAN (Wide Area Network) este relativ lentă. Soluția firească de rezolvare a
acestor probleme, este de a combina serverele de date cu tehnologia BDD, rezultând așa
numita “ organizare cu servere distri buite ”. În această organizare, fiecare server de date
este extins la un SGBD distribuit. Organizarea cu servere distribuite, poate suporta o
mare varietate de configurații, în care fiecare este specializat în anumite aplicații. De
exemplu, într -o BDD geogr afică ale cărei site -uri sunt legate prin rețelele WAN, fiecare
site poate conecta un server de date, care deasemenea este conectat printr -o rețea locală la
un grup de stații de lucru. Fiecare stație, de lucru poate accesa date de pe orice server de
date, prin intermediul unei rețele locale (având acces local), sau prin intermediul unei
rețele WAN (având acces la distanță). Serverele de aplicații pot rămâne neschimbate în
cazul serverului de date centralizat. În acest caz, cererile pentru BD sunt tot timpul
examinate de către serverul de date, care este în contact cu toate prelucrările de cereri
distribuite. O altă alternativă, este aceea de a avea un procesor pentru cererile distribuite
și un mecanism director de date, la fiecare server de aplicații. Acest lucru, permite un
acces sistematic la un singur server de date în ordinea recuperării informatiilor, de la
serverele de date îndepărtate. O altă soluție mai complexă și mai eficientă, este aceea de a
configura servere de date conectate prin intermediul une i rețele.
În organizarea cu servere distribuite, fiecare server de date este în întregime
dedicat gestionării bazelor de date distribuite și centralizate. Așadar, o primă soluție
pentru îmbunătățirea performanțelor, este implementarea SGBD și a SGBDD, odat ă cu
sistemul de operare ce rulează pe un calculator obișnuit. O altă soluție, este să avem un
sistem de operare pentru BDD, care exploatează arhitecturi speciale de calculatoare
(arhitecturi multi -pocesor). Combinarea dintre hardware și software dedicate, trebuie să
furnizeze performanțe mai bune decât cele oferite de soluția generală propusă.

12

2.4 Arhitecturi de servere distribuite de date

Arhitectura acestei clase de servere utilizează tehnologia bazelor de date
distribuite. Performanțele acestei arhitecturi sunt date poziționarea datelor și de algoritmii
paraleli pentru operațiile cu baze de date. Progresul în domeniul componentelor hardware
a influențat în mare măsură proiectarea arhitecturii serverelor de date.
Modelul Von Neuman al arhitecturi i unui procesor pentru execuția eficientă a
operațiilor numerice a dominat până de curând. Performanțele acestui model sunt limitate
de modul său de operare secvențial. Acest model nu este potrivit pentru gestionarea BD
din două motive:
 Primul ar fi că acesta nu poate exploata paralelismul din multe aplicații.
Gestiunea BD relaționale furnizează câteva oportunități pentru
paralelism. Interquery paralelism permite executarea în paralel a mai
multor cereri. Interquery paralelism face posibilă execuția în p aralel a
mai multor operații în interiorul acelorași cereri. Intraquery paralelism
face posibil ca aceeași operație să fie executată în paralel ca mai multe
suboperații. Modelul orientat pe mulțime al limbalelor relaționale
furnizează multe oportunități pe ntru intraoperation paralelism.
 În al doilea rând performanțele gestionării BD pe un calculator Von
Neuman sunt micșorate de strangularea apelurilor intrare/ieșire din cauza
timpului mare de acces la disc (care este de o mie de ori mai mare decât
timpul de acces la memoria centrală).
O soluție imediată și simplă pentru rezolvarea strangulărilor operațiilor de
intrare/ieșire a fost aceea de a menține întreaga bază de date în memoria centrală.În acest
caz se elimină strangulările datorate intrărilor și ieșiri lor. Costul ridicat al memoriei
centrale restricționează acest model la BD mici. Toate prognozele tehnologice arată că
discurile magnetice vor rămâne principalul mijloc pentru memorarea BD medii și mari.
Mai mult, problemele legate de strangulare se vor ac centua în viitorul apropiat. Timpul
de acces la disc poate fi divizat prin numărul de discuri legate între ele pe care se află

13

BD. O soluție a acestei probleme este de a avea mai multe componente hardware
independente interconectate prin intermediul unui m ediu rapid de comunicare. Acest
lucru poate fi realizat prin folosirea arhitecturilor multiprocesor care suportă: interquery
paralel, “paralel intraquery” și paralelism intraoperații (prin asigurarea de operații
diferitelor procesoare).
Un SGBDP poate fi d efinit ca un SGBD implementat pe mai multe procesoare.
SGBDP îmbină gestiunea de date cu tehnicile de prelucrare paralelăși are ca rezultat:
mari performanțe, mari disponibilități și o mare scalabilitate pentru aplicațiile de
prelucrare a datelor. În plus, ele dau soluții de alegere de tranzacții mari și cu timp de
răspuns mic pentru sistemele de decizie și pentru SGBD -urile mari.
Un SGBDP utilizează următoarele trei tipuri de resurse importante : memoria,
CPU și discul. Legăturile dintre resurse și cum ace stea interacționează determină în mod
esențial strategiile de prelucrare paralelă și tipurile de arhitecturi de baze de date paralele.
Arhitecturile BDP pot fi clasificate în următoarele trei categorii: SHARED
EVERYTHING (SE), SHARED NOTHING (SN) și SHARED DISK (SD).
În arhitectura SE orice proces are acces la orice modul al memoriei principale sau
orice disc prin intermediul unei interconectări rapide. Deoarece accesul la un element de
dată (câmp) necesită accesul la o interconectare comună, aceasta conduc e la strangulări
ale comunicației cauzate de legăturile pentru interconectare. O cale de a rezolva această
problemă este de a introduce un număr limitat de procesoare puternice. Principala
diferență față de un SSGBD centralizat este aceea că operațiile în BD pot fi prelucrate în
paralel. Arhitectura SE poate furniza performanțe bune în gestionarea BD, însă ea are o
scalabilitate limitată. Toate procesoarele comunică între ele printr -o re țea de
interconectare.

14

P
M
D P
M
D

Figura 2.1. Arhitectura shared everything (SE)

În arhitectura SN fiecare procesor are acces la unul sau mai multe module de
memorie proprii și la una sau mai multe unități de disc proprii. Fiecare “nod” include un
procesor, o memorie cache locală, o serie de discuri legate între ele pe care se află
rezidentă o bază de date locală. Nodur ile pot fi folosite ca int erfețe pentru serverele de
aplicații și pentru prelucrarea imediată în paralel a relațiilor. Termenul “shared nothing”
arată că nu există memorie principală partajată și discuri partajate între noduri. Singura
sursă comună cu care nodurile pot să schimbe m esaje este rețeaua.

Rețeaua de interconectare

Figura 2.2. Arhitectura Shared Nothing

O asemănare cu bazele de date distribuite este aceea că fiecare nod poate fi
gestionat de un același sistem local. Cu alte cuvinte fiecare nod trebuie să cuprindă soluții
pentru dicționarul global de date, definiția și controlul datelor distribuite și gestiunea
tranzacțiilor distribuite. Deosebirile majore față de BDD sunt:
M
P D
D M M
P P Retele de interconectare

15

 în nodurile multiprocesor nu pot rula aplicatii;
 aplicaț iile rulează ca servere de aplicaț ii și ca interfețe pentru sistemul
multiprocesor prin intermediul rețelei.
Arhitectura SN realizează o mare performanță prin viteza mare obținută prin
exploatarea p relucrării în paralel. Obiect ivul în ceea ce privește perfor manță este
obținerea unui număr mare de tranzacții pe secundă. Deoarece acest lucru este
dependent de numărul de noduri de -a lungul cărora sunt fragmentate datele, dublarea
numărului nodu rilor poa te implica dublarea nu mărului de tranzacții pe secundă.
Îmbunătățirea p erformanței este obținută prin utilizarea a două soluții complementare:
 Fragmentarea datelor în mai multe noduri și astfel paralelismul este maxim
când prelucrăm mai multe cereri distri buite;
 Gestionarea datelor distribuite trebuie să fie suportată eficient de un sistem
de operare pentru BDD.
Principalul dezavantaj îl constituie plasarea datelor și din acest motiv majoritatea
cererilor sunt procesate în paralel și necesitatea dezvoltări i de algoritmi paraleli pentru
executarea operațiilor în BD.
Extensibilitatea (scalabilitatea) este abilitatea de a incrementa fără proble me prin
adăugare de noi no duri. La fel ca la BDD și omogene o arhitectură SN este uniformă și
deci extensibilă. În plu s, aceeași arhitectură și același sistem poate fi folosit pentru BD de
dimensiuni dif erite, de la dimensiuni mici la dimensiuni mari. Transferul de mesaje se
face prin comunicații între procesoare.
Arihtectura SD (Shared disk) din figura de mai jos este c ea mai simplă. Fiecare
procesor are memorie proprie și poate conecta orice disc conectat la sistem. Transferul de
mesaje între procesoare se face tot prin intermediul rețelei.

16

Figura 2.3. Arhitectura Shared Disk

2.5 Plasarea datelor

Plasarea datelor într -o BD client/server depinde de tipul de arhitectură al
serverului. Dacă arhitectura paralelă este de tipul SN, plasarea datelor este similară cu
fragmentarea datelor dintr -o BDD. Fragmentarea în această arhitectură este folosită
pentru a mări paralelismul și pentru o încărcare echilibrată, adică egal distribuită între
toate nodurile rețelei. În continuare, în loc de fragmentare orizontală se folosește
termenul de “declustering”. Fragmentarea verticală poate fi de asemenea folosită la
mărirea paralelismului și a unei încărcări mai echilibrate ca în cazul BDD.
Programele trebuie executate acolo unde sunt mult mai multe date. Există două
deosebiri față de BDD:
 nu se maximizează procesarea locală până când utilizatorii nu sunt asociați
nodu rilor;
 echilibrarea încărcării este mai greu de obținut când avem un număr mare
de noduri.

17

Problema principală este evitarea conflictelor între resurse care pot apărea în sistem.
Dacă programele se execută acolo unde datele sunt rezidente, atunci plasarea datelor este
performantă. Deci plasarea datelor trebuie făcută astfel încât performanța să fie maximă.
Performanțele sunt date de:
 volumul de muncă executat de sistem și
 timpul individual de răspuns pentru fiecare cerere.
La alocarea datelor vom întâlni neajunsurile următoare: se maximizează timpul de
răspuns sau paralelismul interquery duce la declustering (o singură relație pe un singur
nod). Administratorul BD are sarcina de a examina periodic fragmentele de referințe și
când este necesar să mute și să reorganizeze aceste referințe. O solutie alternativă la
“organizarea datelor” este “declustering” total, adică fiecare relație este fragmentată
orizontal de -a lungul tuturor nodurilor din sistem. Pentru a asigura uniformiza rea
distribuției datelor, re lațiile sunt fragmentate folosim o funcție de “micșorare” aplicată
câtorva atribute selectate într -un nod și toate celelalte să fie prelucrate de toate nodurile în
paralel. Performanțele clusteringului total sunt comparate cu pe rformanțele grupării
relațiilor pe un singur disc. Există rețele multiuser declusteringul este performant. Pe de
altă parte, deși fragmentarea pe orizontală are avantaje superioare execuția paralelismului
de nivel înalt devine periculoasă în cazul cererilo r complexe care implică uniri. De
exemplu, într -o arhitectură de 1024 de noduri, în cel mai defavorabil caz numărul
mesajelor pentru o unire binară (fără selectare) poate fi 10242. Mai mult declusteringul
total nu este potrivit pentru relații mici care cup rind numai câteva blocuri de disc.
Aceast a arată că trebuie găsit un compromis între clustering si declusteringul total.
Gradul de fragmentare sau cu alte cuvinte numărul de noduri pe care o relație este
fragmentată este funcție de mărime și funcție de fre cvența accesului la relație. Strategiile
de clustering sau declustering determină schimbări în distribuția datelor care poate
implica reorganizarea datelor.Într -un sistem paralel de nivel înalt programele trebuie să
fie independente de reorganizarea datelo r (locațiile se schimbă foarte des).

18

Gestiunea datelor distribuite este o extensie a gestiunii datelor la distan –
ță și furnizează facilitățile de distribuire ale DBMS penrtu a accesa datele distribuite într –
o manieră transparentă pentru utilizator. Aces t sistem este cel mai relevant în ceea ce
privește arhitectura ce are datele desfășurate de -a lungul câtorva servere și când este
necesar accesul la un DBMS aflat pe alt server.

2.6 Tipuri de servere

Serverele pot fi abordate fie ca servere de date, fie ca servere de aplicații. Prima
abordare constituie o alternativă la BDD și permite ca aplicațiile distribuite să le acceseze
la distanță. La început, un SGBD era considerat ca un sistem de programe implementate
pe un calcula tor și care utiliza al te progra me de sistem și de aplicații. Această abordare
avea neajunsul că gestiunea BD urmărea numai un obiectiv, ceea ce duce la utilizarea
ineficientă a resurselor calculatorului distribite între aplicație și alte programe software
complexe. Un SGBD poat e ușor congestiona memoria principală cu date inutile și poate
satura procesul central când se selectează date relevante și în a ceasată situație nu se
satisfac multe cerințe particulare ale gestiunii BD. Aceste situații provin din centralizarea
excesivă a datelor și a aplicațiilor date de funcțiile de gestiune pe același calculator. O
soluție la această problemă a fost dată de Canaday în 1974. Ideea a plecat de la încărcarea
procesorului central prin izolarea funcțiilor de gestiune ale BD dintr -un calculato r
principal și gruparea lor pe un calculator dedicat. Calculatorul principal pe care se
execută programele de aplicații era numit calculator gazdă iar calculatorul dedicat era
numit mașină bază de date.
Cel mai simplu tip de server de date este serverul fi șier sau fișierul disc. Cu un
server fișier, clientul poate trimite în rețea cereri la fișiere sau la înregistrările din fișierele
acestuia. Acest tip de servicii de date necesită o mare diversitate de date și poate fi foarte
lent într -o rețea cu mulți uti lizatori. Sistemul tradițional LAN permite utilizatorilor să
distribuie resurse cum ar fi fișierele de date și perifericele prin mutare lor de la PC -urile
standard într -o rețea server fișier.

19

Un tip mai avansat de server sunt serverele bază de date, serve rele de tranzacții și
serverele de aplicații. În serverele BD clienții trimit cereri SQL ca mesaje la server și
rezultale interogării sunt returnate în rețea. Codul care procesează cererile clienților SQL
și datele rezidente pe server îi permit acestuia să -și folosească puterea de procesare
pentru a găsi datele. Această metodă este mai performantă decât trecerea tuturor
înregistrărilor înapoi la client și apoi să găsească datele care -l interesează cum este cazul
fișierului server.
În cazul serverelor de tr anzacții clienții apelează proceduri care sunt pe server ce
conține un motor SQL baze de date. Pe server există instrucțiuni procedurale pentru a
executa un grup de instricțiuni (tranzacții) fără erori sau în caz contrar grupul a eșuat.
Aplicațiile bazate pe serverele de tranzacții sunt numite OLTP (On Line Transaction
Processing) care sunt cu timp de răspuns între 1 și 3 secunde. Acestea realizează un
control strict asupra securității și integrității bazelor de date. Cheltuielile suplimentare de
comunicare sunt reduse la minim și se rezumă la schimburi de informații tipice ce
constau dintr -o singură întrebare/răspuns (în contradicție cu expresiile multiple din
serverele baze de date).
Serverele de aplicații nu trebuie neapărat centrate pe BD, ele pot fi fo losite numai
la nevoile utilizatorilor server ca e exemplu procesarea poștei electronice și de realizare
de capacități download. Resursele de bază ale unui server permit utilizatorilor să
distribuie date atâta timp cât serviciile de gestiune și securitate care nu sunt componente
de baze ale serverului, asigură integritatea și securitatea datelor. Descrierea unui stil de
prelucrare client -server se bazează pe descompunerea în trei componente a oricărei
aplicații:
 interfață utilizator;
 logica aplicației sau a tranzacției și gestiunea datelor.

20

2.7 Configurații ale Bazelor de date CS

Acest capitol va examina cinci modele arhitecturale, toate bazate pe configurații
de acces distribuit la date a calculului client/server :
 Model pentru BD centralizate
 Modelul pentru BD fișier -server
 Modelul pentru BD client -server
 Modelul pentru BD distribuită
 Modelul de procesare a extragerilor din BD.
Așa cum modelele de aplicații client/server au fost descrise în capitolul
precedent, cele cinci arhitecturi de modele de mai sus pot fi combinate pentru a crea
diverse configurații de aplicații pentru BD client -server.

a. Model pentru BD centralizat ă

În modelul c entralizat, arătat în figura 2.4 , componentele de procesare ale aplicației,
software -ul BD și BD în săși sunt toate pe același procesor.

Figura 2.4 . Model pentu BD centralizat ă.

De exemplu, un utilizator PC ar putea rula un program de aplicație ce folosește
software -ul BD Oracle pentru a accesa BD existentă pe harddisc -ul PC -ului. Deoarece
componentele aplicației, software -ul BD și însăși BD se află pe același PC, aplicația se
încadrează in modelul centralizat. Multe din tehnicile de prelucrare a informațiilor Aplicatia
Soft. BD
BD

21

folosite de multe organizații se încadrează în modelul centralizat. De exemplu, un
procesor mainframe pe care rulează un software BD al IBM ca IMS sau DB2, poate avea
operatori de la terminale din diverse locuri, cu acces rapid la masa centrală de date. In
multe asemenea sisteme, toate trei componentele aplicațiilor BD se execută pe același
mainframe. Astfel această configurație e conformă și cu modelul centralizat.

b. Model pentru BD fișier -server

În modelul cu BD fișier -server, arătat în fig. 2.5 , componentele aplicației și
software -ul BD se află pe un sistem de calcul iar fișierele fizice ce constituie BD sunt pe
un alt sistem. Asemenea configurație e folosită adesea într -o rețea locală în care unul sau
mai multe sisteme joacă rolul de server de fișiere ce memorează fișierele la care au acces
alte sisteme.

Figura 2. 5 Model pentru BD fisier -server

Modelul pentru BD fișier -server e similar modelului centralizat. Fișierele ce
constitue BD sunt situate pe un calculator diferit de cel unde se află componentele BD
files Aplicația
Soft BD
BBD bbBB
BbBD Retea de
Comunicatii

22

aplicației și software -ul BD. Componentele formate din aplicații și software -ul BD
pot fi aceleași ca cele destinate să opereze într -un mediu centralizat .
Acest model poate fi mult mai complex dec ât modelul centralizat pentru că
software -ul de tip rețea p oate implementa mecanisme concurente, care permit mai
multor utilizatori să acceseze aceeași bază de date, fără ca acei utilizatori să
interacționeze unul cu altul.

c. Model pentru procesarea extragerilor din BD
O altă cale prin care o bază de date la distanță poate fi accesată folosind un
software BD convențional e numită procesarea extragerilor din baza de date , arătată în
figura 3.

Figura 2.6. Model pentru procesarea extragerilor din baza de date

Modelul de procesare a extragerilor din baza de date permite ca un utilizator de
pe un calculator personal să se lege la un sistem de calcul la distanță pe care sunt
localizate datele dorite. Utilizatorul interacționează atunci direct cu software -ul ce s e
execută pe sistemul de calcul la distanță, formulează cereri de extragere a datelor cerute
din baza de date la distanță. Utilizatorul transferă apoi datele dorite din mașina la
distanță în propriul calculator și hard disc.
Utilizatorul procesează apoi copia locală a datelor folosind software -ul local. Cu
această abordare, utilizatorul trebuie să știe unde sunt datele localizate și cum să le
B
D
file
s Aplicatie Soft
BDmB BD
Aplica tiaa
BD Retea de
comunicatii
BD

Fil
es
Soft BD

ApliApli
catia File Server

23

acceseze și să interacționeze cu calculatorul la distanță care deține datele. Cate un
software de aplicații complementar trebuie să fie disponibil pe ambele sisteme pentru a
manipula accesul la baza de date și să transfere datele între cele două sisteme. Deci,
software -ul bazei de date ce rulează pe ambele calculatoare nu are nevoie să fie partajat,
de vreme ce utilizatorii interacționează cu ele separat.

d. Modelul pentru BD client/server

Într-un model pentru BD c lient/server, arătat în figura 2.7 , baza de date se află
pe un calculator, altul decât cel pe care se execută componentele de prelucrare ale
aplicației. Dar software -ul BD e împărțit între sistemul de client pe care se executa
programul aplicației și sistemul server ce stochează baza de date .

Server BD
Client BD

Figura 2.7 Model pentru BD client/server.

În acest model, componentele de prelucrare ale aplicației ce se află pe sistemul
client emit cereri la software -ul BD local. Componenta de software ale BD locale de pe
calculatorul client comunică cu software -ul BD complementar ce rulează pe server.
Software -ul BD de pe server satisface cererea de acces la BD apoi trece rezultatele înapoi
la calculatorul client.
La prima vedere, modelul pentru BD client/server poate părea similar cu
modelul pentru BD fișier –server. Totuși, modelul client/server are unele avantaje față de
modelul fișier -server. În modelul fișier –server, informațiile asociate fiecărei BD fizice
trebuie să t reacă prin rețea. O operație BD ce are nevoie de mai multe accesări ale BD
Aplica
tia Aplicatii B
D

Software
BD
Internet

comuni
catii

24

poate genera un mare trafic prin rețea. Presupunem că utilizatorul final face o cerere de
date pentru o sinteză. Cererea are nevoie ca valorile elementelor de tip dată din 1000
de înregistrări din BD să fie examinate. Cu metoda fișier -server, întregul conținut al
tuturor celor 1000 înregistrări trebuie să treacă prin rețea. Aceasta, deoarece software -ul
BD, care rulează pe calculatorul utilizatorului de la terminal, trebuie să acc eseze și să
examineze fiecare înregistrare pentru a satisface cererile utilizatorului. Cu metoda BD
client/server, doar întrebarea inițială și rezultatul final au nevoie să treacă prin rețea.
Software -ul BD ce operează în calculatorul care stochează BD po ate fi capabil să
apeleze înregistrările cerute, să le examineze și să facă prelucrarea necesară spre a
ajunge la rezultatul final.

e. Software Front -end

În modelul BD client/server, este necesar să se facă referire la software -ul front –
end și back -end Software -ul front -end ruleaz ă de obicei pe un PC sau o staț ie de lucru
și server si folosește la nevoile de calcul ale unui singur individ. De obicei, software
front -end joacă rolul de client într -o aplicație BD client -server și îndeplinește funcții
care sunt orientat e spre nevoile utilizatorului final. Software -ul front -end în general intră
în una sau mai multe din categoriile listate în paragraful următor. Software -ul Back -End
constă dintr -un soft ware BD client/server și un software de tip rețea ce execută pe un
calculator, cu rolul de server BD.

25

f. Model pentru o BD distribuită

Modelul pentru BD fișier -server și modelul pentru BD client/server, amândouă
presupun că BD se află pe acelasi procesor cu programul de aplicație, iar model pentru
BD distribuită arătat în figura 2.8 presupune că însăși BD poate exista pe mai multe
calcula toare.
În continuarea acestui capitol sunt descrise câteva mecanisme care sunt folosite în
implementarea unei BD distr ibuite. In capitolul urmator se descriu trei modele
arhitecturale diferite în care un mediu BD client/server distribuit poate exista.
Server BD

BD client

Server BD
Figura 2.8. Modelul pentru BD distribuită.

Aplicatie

BD

B
D
Softwar
e BD Internet

26

3. Limbajul PL/SQL.
3.1 Scurt Istoric

Limbajul PL/SQL (Procedural Language extensions to SQL) a fost dezvoltat de
compania Oracle ca extensie a limbajului declarativ SQL. PL/SQL este un limbaj de
programare procedural care poate fi folosit pentru descrierea unor prelucrări complexe
sau pentru programarea unor secvențe de cod care trebuie executate automat la apariția
unui eve niment (triggere).
O caracteristică remarcabilă a limbajului PL/SQL este faptul că procedurile sau
funcțiile scrise vor fi memorate în baza de date. Aceleași prelucrări pot fi realizate de
regulă și în cadrul aplicațiilor client care accesează datele din bază, dar în cazul
modificării unei metode de calcul trebuie refăcute aplicațiile client afectate si suportate
toate costurile pe care le implică redistribuirea unor noi versiuni ale aplicațiilor client.
Având în vedere faptul că de multe ori aplicațiile d in domeniul bazelor de date sunt
în arhitectură client -server și aplicația client accesează aplicația server (Oracle XE) prin
intermediul unei rețele, utilizarea pe cât posibil a procedurilor scrise în PL/SQL poate
ameliora semnificativ viteza de prelucrar e.
În cazul unei proceduri care ar implica transferul spre aplicația client a unui volum
mare de date (rezultatul unei interogări de exemplu), întârzierile cauzate de rețeaua prin
care se accesează serverul de baze de date pot fi mari. Dacă prelucrarea dat elor nu
presupune afișarea acestora în aplicația client, mult mai eficientă este soluția prelucrării
datelor pe server, într -o procedură scrisă în PL/SQL. PL/SQL este bazat pe limbajul
ADA, o parte dintre construcțiile sale sintactice provenind din Pascal.
De regulă programarea în PL/SQL înseamnă definirea unor proceduri sau funcții, în
sensul pe care acestea le au în oricare dintre limbajele procedural cunoscute. O procedură
sau o funcție poate fi introdusă folosind fereastra SQL Plus sau folosind interfaț a grafică,
în SQL Command sau Script Editor. O succesiune de instrucțiuni în PL/SQL care nu sunt
destinate definirii unei funcții sau proceduri formează un bloc anonim care va fi executat
doar o singură dată.

27

3.2 Elementele limbajului PL/SQL
Codul PL/SQL poate fi conținut în blocuri anonime sau în blocuri care conțin
subprogram memorate în baza de date (proceduri sau funcții). Un bloc anonim se
introduce în fereastra în care se introduc comenzi SQL. El nu este memorat în mod
normal în baza de date în veder ea reutilizării ulterioare. Interfața serverului Oracle XE
permite totuși memorarea unui bloc, întocmai ca și memorarea unei comenzi SQL
orecare. Cele două exemple anterioare sunt blocuri anonime.
Un subprogram memorat (denumit uneori stocat) este un subpr ogram PL/SQL
pe care serverul Oracle îl compilează și îl memorează în baza de date. Subprogramul
memorat poate fi ulterior apelat dintr -o aplicație sau dintr -un alt bloc PL/SQL.
Subprogramele pot fi proceduri sau funcții. Diferența dintre cele două este fa ptul că o
funcție returnează o valoare.
Un pachet (engl. package) este format dintr -un un grup de subprogram și de
declarații de variabile. Serverul Oracle memorează elementele conținute într -un pachet,
acestea putând fi apelate din alte pachete sau subpro grame.

Sintaxa unui bloc PL/SQL
Un bloc anonim PL/SQL se compune din sec țiuni și are sintaxa următoare:

Figura 3 .2: Bloc anonim PL/SQL
Dacă blocul con ține o procedură memorată în baza de date, sintaxa sa este
următoarea:

28

Figura 3.2: Subprogram memorat de tip procedura

Secțiunea de declarații (DECLARE în cazul blocului anonim) cuprinde declarații de
variabile simple, variabile structurate, variabile tip cursor, funcții sau proceduri
ajutătoare. Zona de declarații este opțională. Pentru funcții, proceduri și triggere cuvântul
DECLARE lipsește, blocul de declarații fiind implicit cuprins între linia de declarare a
funcției sau a procedurii și BEGIN.
Blocul introdus prin EXCEPTION este opțional și realizează tratarea erorilor
apărute în timpul execuției codului programului.
Caracterul ’;’ se folosește pentru a marca sfârșitul unei instrucțiuni sau a unui bloc,
dacă apare după END.
Codul poate cuprinde blocuri interioare .

Exemplu:
DECLARE –declarații variable
BEGIN –cod program
BEGIN –codul blocului inclus
EXCEPTION –tratare excepții END;
– cod program (continuare)
END;
Exemplu:

29

Figura 3 .3: Exemple cod PL/SQL

Pentru transformarea exemplelor din următoarele subcapitole în exemple
executabile, înaintea declarațiilor de variabile va fi introdus fie numele secțiunii de date,
DECLARE fie secvența de declarare a unei proceduri stocate (CREATE OR REPLACE
PROCEDURE "nume" IS).
În PL/SQL comentariile în linie se introduc prin două caractere ’ -’ iar comentariile
pe mai multe linii sunt cuprinse între /* respectiv */, ca în limbajul C.

3.3 Tipuri de date

Tipurile de date folosite în PL/SQL pot fi:
• cele folosite în SQL (VARCHAR2, NVARCHAR2, CHAR, NCHAR, NUMBER,
BINARY_FLOAT, BINARY_DOUBLE, DATE, TIMESTAMP, CLOB și BLOB);
• tipuri specifice limbajului PL/SQL : BOOLEAN, NUMBER (scris simplu, fără
dimensiune) și PLS_INTEGER (pentru variabile având valori întregi);
• tipuri specifice structurate: TABLE, VARRAY și RECORD.

Exemplu:
– Declarații de variabile:
nume VARCHAR2(30); prenume VARCHAR2(25); marca NUMBER(6);
activ BOOLEAN; salar_lunar NUMBER(6);
nr_zile_lucrate
NUMBER(2);

30

salar_zilnic
NUMBER(6,2);
medie_zile_lucr CONSTANT NUMBER(2) := 21; – o constanta
BEGIN
NULL; – NULL indica lipsa corpului. Este
permis˘a pt. testare.
END;
Obs. Pentru a defini constanta medie_zile_lucr s -a folosit cuvântul rezervat CONSTANT
și imediat s -a atribuit valoarea corespunzătoare.
Variabilele declarate servesc de multe ori la memorarea unor valori din tabelele
bazei de date, obținute folosind comenzi SELECT. În astfel de cazuri este esențial ca
tipul declarat pentru o astfel de variabilă să coincidă cu tipul coloanei tabelului din care
va primi valori. Pentru a evita erorile greu de depistat cauzate de declararea eronată a
acestor variabile, PL /SQL oferă soluția simplă a preluării tipului câmpului care va furniza
valori folosind % TYPE, astfel:
coded edituri.cod_edit % TYPE;
Variabila coded va fi NUMBER(5), de același tip cu câmpul cod_edit din tabelul edituri.
O situație asemănătoare apare în c azul variabilelor structurate (de tipul RECORD).
O astfel de variabilă va avea mai multe câmpuri. Dacă variabila trebuie să preia valorile
conținute într -o linie a unui tabel, la declararea ei se va folosi % ROWTYPE, astfel:
editura edituri % ROWTYPE;
Variabila editura va fi de tip RECORD și va avea aceleași câmpuri cu tabelul
edituri. Accesul la câmpuri se realizează folosind operatorul ’.’ (punct).

Exemplu: editura.cod_edit, editura.nume etc .

3.4 Cursoare
Cursoarele permit programatorului să preia date dintr -o mulțime de selecție,
linie cu linie, în vederea prelucrării lor. În PL/SQL un cursor poate fi implicit
sau explicit.

31

Cursorul implicit presupune utilizarea unei mulțimi de selecție având o
singură linie și este folosit pentru a atribui valori unui set de variabile.
Exemplu:
SELECT cont, data, valoare into cnt, dt, val from operatii where cod_op = 3;

În vederea selectării unei singure linii se impune valoarea cheii primare.
Cursorul explicit are nume și este declarat în secțiunea de declarații a blocului
(procedurii, funcției), astfel:

CURSOR c1 IS SELECT … ;

Exemplu:
CURSOR c1 IS SELECT nume, prenume FROM angajați WHERE funcția =
’zidar’;

Comanda SQL SELECT va fi executată în momentul deschiderii cursorului
folosind instrucțiunea OPEN. Linii le mulțimii de selecție conținute în cursor
vor fi prelucrate individual, accesul la linia curentă realizându -se folosind
instrucțiunea FETCH.
După terminarea prelucrării datelor conținute într -un cursor, acesta trebuie
închis folosind instrucțiunea CLOSE.

3.5 Identificatori
Numele unei variabile constă dintr -un șir având maximum 30 caractere și format dintr -o
literă urmată opțional de alte litere, cifre, $, _. Caracterele ’&’, ’ -’, ’/’ și ’ ’ (spațiu) nu
sunt permise. PL/SQL nu este sensibil la tipul lite relor – majuscule sau litere mici .
Exemple:
– Declarații de variabile:
numeprenume VARCHAR2(30); – identificator acceptat
nume_prenume VARCHAR2(30); – identificator acceptat,

32

_ permis nume $ prenume VARCHAR2(30); – identificator acceptat,
_permis nume # prenume VARCHAR2(30); – identificator acceptat,
– nume -prenume identificator neacceptat, minus nepermis
– nume/prenume identificator neacceptat, / nepermis
– nume prenume identificator neacceptat, spațiu nepermis

3.6 Operatori
La scrierea codului î n PL/SQL se folosesc următoarele tipuri de operatori:
• aritmetici: + – * /
• logici : ’=’ ’>’ ’<’ ’>=’ ’<=’, ’!=’ (sau ’<>’)
• de concatenare a sirurilor¸ ’||’
• de atribuire: ’:=’
Exemple:

– Declarații de variabile salar NUMBER(6,2); ore_lucrate NUMBER := 40;
salar_orar NUMBER := 22.50; bonus NUMBER := 150; ¸tara
VARCHAR2(128); numarator NUMBER := 0; gata BOOLEAN := FALSE;
id_valid BOOLEAN;

BEGIN
salar := (ore_lucrate * salar_orar) + bonus; – calcul salar tara := ’Suedia’;
– atrib. un literal de tip string
tara := UPPER(’Canada’); – idem, caracterele transf in majuscule gata :=
(contor > 100); – atrib. BOOLEAN, literalul FALSE id_valid := TRUE; –
atrib. BOOLEAN
END;

33

3.7 Atribuirea folosind SELECT … INTO
Dacă valoarea unei variabile se determină în funcție de valori dintr -o linie a
unui tabel al bazei de date, PL/SQL permite atribuirea valorii acesteia folosind
un cursor implicit, respectiv o construcție
SELECT expresie INTO variabilă FROM tabel WHERE
condiție_selectare_linie
Expresia folosită poate folosi variabile, literali și valori din linia
corespunzătoare din tabel.

Exemplu:

– Declarații de variabile: procent_bonus CONSTANT NUMBER(2,3) := 0.05;
bonus NUMBER(8,2);
ang_id NUMBER(6) := 120; – atribuie o val. pt testare
BEGIN
– preia salar din tabelul angajați, calculeaza bonusul și atribuie
– rezultatul -> variabila bonus SELECT salar * procent_bonus INTO bonus
FROM angajați
WHERE angajat_id = ang_id;
– listeaza codul angajat_id, bonusul și procent_bonus
DBMS_OUTPUT.PUT_LINE ( ’Angajat: ’ ’||’ TO_CHAR(ang_id)

3.8 Structuri de control

a. IF

IF are 3 forme: IF -THEN, IF -THEN -ELSE si IF -THEN -ELSIF.

Exemplu:

DECLARE

34

salariu NUMBER(8,2) := 12100;
cota NUMBER(8,2) := 10000;
bonus NUMBER(6,2);
Id_sal NUMBER(6) := 111;
BEGIN
IF salariu > (cota + 200) THEN
bonus := (salariu – cota)/4;
ELSE
bonus := 50;
END IF;
UPDATE salariaț i
SET salariu = salariu + bonus
WHERE id_salariat = id_sal;
END;
Exemplu:
DECLARE
jobid employees.job_id%TYPE;
empid employees.employee_id%TYPE := 115;
sal_raise NUMBER(3,2);

BEGIN

SELECT job_id INTO jobid from employees WHERE employee_id = empid;
IF jobid = 'PU_CLERK' THEN sal_raise := .09;
ELSIF jobid = 'SH_CLERK' THEN sal_raise := .08;
ELSIF jobid = 'ST_CLERK' THEN sal_raise := .07;
ELSE sal_raise := 0;
END IF;
END;

b. CASE
Exemplu
DECLARE
grade CHAR(1);
BEGIN

35

grade := 'B';
CASE grade
WHEN 'A' THEN DBMS_OUTPUT.PUT_LINE('Excellent');
WHEN 'B' THEN DBMS_OUTPUT.PUT_LINE('Very Good');
WHEN 'C' THEN DBMS_OUTPUT.PUT_LINE('Good');
WHEN 'D' THEN DBMS_OUTPUT.PUT_LINE('Fair');
WHEN 'F' THEN DBMS_OUTPUT.PUT_LINE('P oor');
ELSE DBMS_OUTPUT.PUT_LINE('No such grade');
END CASE;
END;
Exemplu:
DECLARE
grade CHAR(1);
BEGIN
grade := 'B';
CASE
WHEN grade = 'A' THEN DBMS_OUTPUT.PUT_LINE('Excellent');
WHEN grade = 'B' THEN DBMS_OUTPUT.PUT_LINE('Very Good');
WHEN grade = 'C' THEN DBMS_OUTPUT.PUT_LINE('Good');
WHEN grade = 'D' THEN DBMS_OUTPUT.PUT_LINE('Fair');
WHEN grade = 'F' THEN DBMS_OUTPUT.PUT_LINE('Poor');
ELSE DBMS_OUTPUT.PUT_LINE('No such grade');
END CASE;
END;

– în loc de a folosi ELSE in CASE se poate folosi :
– EXCEPTION
– WHEN CASE_NOT_FOUND THEN
– DBMS_OUTPUT.PUT_LINE('No such grade');

36

c. LOOP
Exista 3 forme pentru LOOP:
 LOOP
 WHILE -LOOP
 FOR -LOOP
Exemplu :
LOOP
sequence_of_statements
END LOOP;
d. Folosirea comenzii EXIT
Comanda EXIT statement forțează ca ieș irea din blucla .
Exemplu :
DECLARE
credit_rating NUMBER := 0;
BEGIN
LOOP
credit_rating := credit_rating + 1;
IF credit_rating > 3 THEN
EXIT; – ieșirea din blucla
END IF;
END LOOP;
– DBMS_OUTPUT.PUT_LINE ('Credit rating: ' ||
TO_CHAR(credit_rating));
IF credit_rating > 3 THEN
RETURN; –se foloseste RETURN ș i nu EXIT cand suntem in afară
LOOP
END IF;
DBMS_OUTPUT.PUT_LINE ('Credit rating: ' || TO_CHAR(credit_rating));
END;

37

Coman da EXIT trebuie plasata in afară buclei.
e. Comanda EXIT -WHEN
Comanda EXIT -WHEN determină ieș irea d in bucla in urma unei condiț ii.

Exemplu :

IF count > 100 THEN EXIT; ENDIF;
sau
EXIT WHEN count > 100;
Cele 2 construcț ii de mai sus sunt echivalente, dar EXIT -WHEN este mai
ușor de inț eles.

f. Etichetarea unei blucle PL/SQL
Ca și blocurile PL/SQL, buclele pot fi etichetate. Eticheta opționala inchisă
între << >> trebuie să apară la î nceputul bu clei. Numele etichetei trebuie să
apară și la sfarș itul buclei.
Exemplu
DECLARE
s PLS_INTEGER := 0;
i PLS_INTEGER := 0;
j PLS_INTEGER;
BEGIN
<<outer_loop>>
LOOP
i := i + 1;
j := 0;
<<inner_loop>>
LOOP
j := j + 1;

38

s := s + i * j;
EXIT inner_loop WHEN (j > 5);
EXIT outer_loop WHEN ((i * j) > 15);
END LOOP inner_loop;
END LOOP outer_loop;
DBMS_OUTPUT.PUT_LINE ('The sum of products equals: ' ||
TO_CHAR(s));
END;

g. Bucla WHILE -LOOP
Bucla WHILE -LOOP se execută p ână atâta timp cat condiția este adevarată .
WHILE condition LOOP
sequence_of_statements
END LOOP ;
Aceasta este echi valenta cu:
LOOP
sequence_of_statements
EXIT WHEN boolean_expression;
END LOOP;

h. Instrucț iunea FOR -LOOP
Bucla FOR iterează peste un anumit interval de î ntregi. Numarul de iteraț ii
este cunoscut inainte de intrarea in blucla. Ope ratorul (..) serveș te ca operator
de domeniu. Domeniul este calculat cand se intra prima data in bucla si nu
mai este niciodata reevaluat.

Exemplu:

39

DECLARE
p NUMBER := 0;
BEGIN
FOR k IN 1..500 LOOP – calcularea lui pi cu 500 termeni
p := p + ( ( ( -1) ** (k + 1) ) / ((2 * k) – 1) );
END LOOP;
p := 4 * p;
DBMS_OUTPUT.PUT_LINE( 'pi is approximately : ' || p ); – print result
END;

Exemplu:
BEGIN
FOR i IN REVERSE 1..3 LOOP
DBMS_OUTPUT.PUT_LINE (TO_CHAR(i));
END LOOP;
END;

In interiorul unei bu cle FOR, variabila cu care se itereaz ă nu se poate
schimba ,deoarece produce o eroare și nu mai poate fi numai citită .

BEGIN
FOR i IN 1..3 LOOP – assign the values 1,2,3 to i
IF i < 3 THEN
DBMS_OUTPUT.PUT_LINE (T O_CHAR(i));
ELSE
i := 2; – nu este permisa, produce o eroare
END IF;
END LOOP;
END;

40

3.9 Proceduri și funcții

a. Crearea unei proceduri
De regulă secvențele de cod PL/SQL sunt conținute în proceduri sau funcții.
Blocurile anonime pot fi folosite eventual pentru testarea corectitudinii unei secvențe de
cod, dar după încheierea testării ele vor fi transformate în proceduri sau funcții memorate
în baza de date.

Codul poate fi scris în fereastra destinată scrierii comenzilor SQL (SQL
Comm and), în Script Editor sau folosind Object Browser / Create / Procedure. Indiferent
de soluția adoptată, rezultatul va fi o procedură stocată în Oracle XE și accesibilă
folosind meniul Object Browser.

Exemplul: 1. Crearea unei proceduri folosind SQL Comma nd:

Declararea unei proceduri folosind fereastra SQL Command sau SQL*Plus începe
cu secvența :

CREATE OR REPLACE PROCEDURE nume (parametrii)
declarații
BEGIN
Instrucțiuni.;
END;

41

Figura 3.4: Procedura

Pentru verificarea creșterii procedurii se selectează Obje ct Browser / Browse /
Procedures și în fereastra care se afișează se selectează procedura (SALUT).

Figura 3.5: Verificarea creeării unei proceduri

În pasul următor se definesc parametrii de intrare și de ieșire ai procedurii, dacă este
cazul.
Astfel generată, procedurii îi lipsește secțiunea destinată declarării variabilelor
locale. Pentru adăugarea acestora se selectează Edit și se inserează declarațiile necesare.

Apelul procedurii se poate realiza din fereastra destinată introducerii de comenzi
SQL (SQL / SQL Commands) :

Din SQL*Plus apelul se poate face și folosind comanda SQL CALL :

42

b. Parametrii procedurilor PL/SQL

Procedurile pot avea un număr de parametri de intrare (IN), parametri de ieșire
(OUT) sau de intrare / ieșire (IN OUT).

Figura 3.6: Crearea unei proceduri

Figura 3 .7: Setarea numelui procedurii create

Figura 3.8: Definirea parametrilor de intrare/ieș ire

43

Figura 3.9: Definirea corpului procedurii

Figura 3 .10: Codul procedurii create

Figura 3.11: Apelul unei proceduri

Dacă un parametru este declarat de intrare (IN) modificarea sa în subprogram nu
afectează valoarea eventualei variabile folosite ca parametru efectiv la apelarea
funcției.

La apelul unei proceduri având parametri de tip OUT sau IN OUT, pe pozițiile
corespunzătoare acestora din lista de parametri efectivi trebuie utilizate variabile de
același tip cu cel al parametrilor procedurii .

44

Un bloc anonim sau o procedură p oate avea în zona de declara ții o declara ție de
procedură.

Exemplu :

DECLARE – declarații de variabile și subprograme nume
VARCHAR2(20) := ’ionescu’; prenume VARCHAR2(25) :=
’marin’ ;

PROCEDURE nume_maj ( v1 IN OUT VARCHAR2, v2 IN OUT VARCHAR2)
AS BEGIN
v1 := UPPER(v1); – trec Sirurile¸ in majuscule
v2 := UPPER(v2);
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(nume || ’ ’ || prenume );
– afișez val. inițiale nume_maj (nume, prenume);
– apelez procedura cu parameteri DBMS_OUTPUT.PUT_LINE(nume || ’ ’ ||
prenume );
– afișez noile valori
END

c. Definirea unei func ții

Funcțiile sunt subprograme care returnează o valoare. Ca și în cazul procedurilor,
o funcție poate fi scrisă în fereastra des tinată scrierii comenzilor SQL (SQL Command),
în Script Editor sau folosind interfa ța afișată prin selectarea op țiunii Object Browser /
Create / Function.

45

Exemplu:

CREATE OR REPLACE FUNCTION nume_prenume ( nume IN VARCHAR2, prenume
IN VARCHAR2, casatorit IN VARCHAR2)
RETURN VARCHAR2 AS
nup VARCHAR2(45); – variabila locala
BEGIN
– Se construiește un șir¸ cuprinzând numele si prenumele nup := upper(nume) || ’
’ || prenume;
IF length(casatorit) > 0 THEN – daca e căsătorit, –adaug căsătorit
nup := nup || ’ ’ || casatorit;
END IF;
RETURN nup; – returnează valoare a lui nup
END;

Figura 3.12: Rezultatul creerii unei funcții

46

4. Prezentarea aplicației
4.1 Scurtă prezentare a aplica ției

NetBeans este un proiect open -source. Acest lucru înseamnă că firmele pot crea produse
comerciale din ceea ce este aici și că acest proiect este condus în principal de comunitate.
Acest lucru înseamnă că, de exemplu, dacă puteți contribui cu cunoștințe care ajută pe
altcineva, veți beneficia și dvs. Fie că este vorba de rapoarte de bug -uri sau solicitări de
îmbunătățiri, be neficiază toată lumea de instrumente mai bune după implementarea
remedierilor sau a îmbunătățirilor.
NetBeans IDE 7.1 este un IDE gratuit, open source, disponibil pentru Oracle Solaris,
Oracle Linux și alte distribuții Linux, sisteme de operare Mac și Wind ows, care le
permite dezvoltatorilor să creeze rapid aplicații web, de tip enterprise, desktop și aplicații
mobile în primul rând pentru platforma Java, dar și în PHP și C/C++.
Obiectivele aplicației:
– gestionarea angajaților unei firme;
– posibilitatea vederii detaliilor fiecărui angajat;
– adăugarea, modificarea sau ștergerea¸ unui angajat care se poate face decât de
administrator;
– posibilitatea interogării BD direct din aplicație;

47

4.2 Autentificarea
Acccesul la aplica ție se face pe baza de username și parolă.

Figura 4.1: Fereastra autentificare

Modul de validare al username -ului și al parolei introduse este implementat astfel:
String uss = "****"; //variabila în care
se memorează username -ul; String pss =
"****";

//variabile în care se mem orează parola;
String username = user.getText(); //variabila care memorează
username -ul introdus de la tastatură;
String parola = String.valueOf(pass.getPassword()); //variabile
care memorează parola introdusa de la tastatură;
if (username.equals(uss) && parola.equals(pss)) // verificarea
datelor introduse de la tastatură;
JOptionPane.showMessageDialog(null, "Autentificare cu
succes!","SUCCES!", JOption -Pane.INFORMATION_MESSAGE);

//fereastra de afisare a unui mesaj;
new interfata().setVisible(true); //se activează
JFrame-ul principal al aplica ției; dispose();
//se inchide fereastra de autentificare;
else //dacă datele introduse de la tastatură nu sunt corecte;
JOptionPane.showMessageDialog(null, "Autentificare
esuata!","EROARE!", JOption -Pane.ERROR_MESSAGE );//se afisează un
mesaj de eroare;
user.setText("");

//se șterg caracterele din câmpul
username;
pass.setText("");
//se șterg caracterele din câmpul parolă;

48

4.3 Conexiunea Java – ORACLE
Conectarea interfețelor Java la baza de date din ORACLE se realiz ează cu ajutorul clasei
Conexiune , descrisă mai jos. Metoda folosită a fost DriverManager.getConnection .

import java.sql.*;
import java.util.Vector;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.table.DefaultTableModel;

public class Conexiune {
Connection conn = null;
/*
* clasa conexiune este folosita pentru conectarea la baza de date
stocata in Oracle.
*/
Conexiune(){
try{
String url="jdbc:oracle:thin:@localhost:1521:XE";
conn =
DriverManager.getConnection(url,"angajari","angajari");

}
catch(SQLException e){

Logger.getLogger(Conexiune.class.getName()).log(L evel.SEVERE,null,e);

}

}

4.4 Gestiunea salariațior
În promă etapă clasa select_angajati este folosita pentru a returna datele din baza de date.

public ResultSet select_angajati() throws SQLException{
Statement stm = conn.createStatement();
ResultSet rs = stm.executeQuery("SELECT cnp, nume, prenume,functia,
salariu, id_dep, data_angajare, adresa FROM angajati");
return rs;
}

49

După ce autentificarea s -a realizat cu succes, aplic ația listează angajații din BD și oferă
administratorului 4 opțiuni:
– După cum se vede și în figura următoare cele patru opțiuni sunt: Adauga, Modifica,
Sterge și
Adauga Interogare

Figura 4.2: Interfața aplicaț iei
– Apăsand butonul Adauga aplicaț ia oferă administratorului posi bilitatea de a
adăuga noi angajaț i în BD. Dacă se dore ște anularea acestei operaț ii se apasă
butonul Inapoi . Acest buton este prezent în toate cele patru op țiuni cu acela și
efect.

Figura 4.3: Interfaț a Adauga

50

În continuare este prezentată implementarea butonului Adauga :

/*
* cu ajutorul clasei adauga_angajat adaugam noi angajati in baza
de date.
*/
public boolean adauga_angajat(String cnp, String nume, String
prenume, String functia, String sal, String dep,
String data, String adr ) throws SQLException{
Statement stm = conn.createStatement();
String sql = "INSERT INTO ANGAJAT I
VALUES('"+cnp+"','"+nume+"','"+prenume+"','"+functia+"','"+sal+"',"
+ " '"+dep+"','"+data+"','"+adr+"')";

int executeUpdate = stm.executeUpdate(sql);

if(executeUpdate > 0 )
return true;
return false;
}

– Butonul Modifica permite administratorului să modifice date despre orice
angajat existent în baza de date.

Figura 4.4: Interfa ța modifica
Implementarea butonului Modifica este următoarea:

/*
* cu ajutorul clasei modifica_angajat modificam datele existente
in baza de date.
*/
public boolean modifica_angajat(String cnp_c, String nume, String
prenume, String functia, String sal, String dep,
String data, String adr) throws SQLException{
Statement stm = conn.createStatement();

51

String sql = "UPDATE ANGAJATI SET nume='"+nume+"',
prenume='"+prenume+"', functia='"+functia+"', salariu='"+sal+"',"
+ "id_dep='"+dep+"', data_angajare='"+data+"',
adresa='"+adr+"' WHERE cnp='"+cnp_c+"'";

int executeUpdate = stm.executeUpdate(sql);

if(executeUpdate > 0 )
return true;
return false;

}
/*
* clasa caut_cnp verifica daca cnp -ul introdus de utilizator se
afla in baza de date.
*/
public boolean caut_cnp (String cnp_c) throws SQLException{
Statement stm = conn.createStatement();
String sql = "SELECT COUNT(cnp) FROM ANGAJATI WHERE
cnp='"+cnp_c+"'";

int execu teUpdate = stm.executeUpdate(sql);

if(executeUpdate > 0)
return true;
return false;

}

52

– Butonul Sterge permite administratorului să stearg㸠angaja ții din BD.

Figura 4 .5: Interfaț a Sterge
Implementarea butonului Sterge este următoarea:

String cnp = st_cnp.getText();

String lengths =
Integer.toString(st_cnp.getText().lengt
h());
if((cnp.equals("")||(!lengths.equals("1
3")))||(ver_litere(cnp)))
st_eroare.setText("EROARE");

if((clasa_conexiun e.ca
ut_cnp(cnp))) try
if(clasa_conexiune.ste
rge_angajat(cnp))

ResultSet rs4 =
clasa_conexiune.select_angaja
ti();
tabel.setModel(Conexiune.popu
leaza_tabel(rs4));
panel_interfata.setVisible(tr
ue);
panel_adauga.setVisible(false
);
panel_modifica.setVisible(fal

53

se);
panel_sterge.setVisible(false
);
panel_interogare.setVisible(f
alse); st_eroare.setText("");

st_cnp.s
etText("
"); else

st_eroare.setText("ER
OARE CNP"); catch
(SQLException ex)

Logger.getLogger(interfata.class.getName()).l
og(Level.SEVERE, null, ex); catch
(SQLException ex)
– Butonul Adauga Interogare permite administratorului să interogheze BD.
Rezultatul va fi afișat în partea din dreapta.

Figura 4.6: Interfa ța Adauga Interogare

Implementarea butonului Adauga Interogare este următoarea:
String sql = int_script.getText();

54

String lengths =
Integer.toString(int_script.getText().
length()); if(lengths.equals("0"))
int_eroare.setText
("EROARE"); else
try
if((clasa_conexiune.int
erogare_val(sql)))
ResultSet rs5 =
clasa_conexiune.interogare(sql)
;
int_tabel.setModel(Conexiune.po
puleaza_tabel(rs5)); else
int_eroare.setText
("EROARE"); catch
(SQLException ex)
Logger.getLogger(interfata.class.getName()).log(Level.SEVERE,
null, ex);

55

5. Concluzii

Această încercare modestă de a prezenta un domeniu atât de vast nu poate face
decât să stârnească interesul asupra acestei ramuri a unei științe noi și în continuă înnoire.
În informatică aplicațiile au o „viață” scurtă deoarece apar mereu versiuni îmbunăt ățite,
upgrade -uri, aplicații mult mai performante ce încearcă să vină în sprijinul utilizatorului.
Totuși, chiar dacă se schimbă modul de punere în aplicare al unor idei, principiile
de bază persistă indiferent de complexitatea problemei, de aceea tot ce se învață într -un
limbaj de programare poate fi extrem de util în alte limbaje, nu prin memorarea unei
sintaxe sau a unui fragment de cod ci prin modul de abordare a problemei și soluțiile ce
se pot utiliza la rezolvarea problemei. Aceste soluții depind f oarte puțin de mediul de
programare și țin de ingeniozitatea celui ce caută soluția.
Aplicație prezentată în această lucrare este departe de a fi perfectă, dar este
perfectibilă și conține, cred, o serie de soluții ingenioase descoperite nu doar prin studi ul
aprofundat al suportului teoretic dar și prin metode mai puțin ortodoxe de rezolvare găsite
pe măsură ce s -a lucrat.
Crearea unei astfel de aplicații ar putea fi un foarte bun motiv de a începe un
studiu foarte serios al sistemelor de gestiune a bazelor de date în special pentru cei ce
încearcă să facă din aceasta o viitoare meserie.

56

6. Bibliografie

[1] Boldea Maria și Boldea Costin Radu – Access 2007 , Mirton 2009
[2] Connoly, T., Begg, C. și Strachan, Anne – Baze de date – Proiectare, Implementare,
Gestionare, Editura Teora, 2001
[3] Fotache, Marian – SQL; Editura Polirom; 2005
[4] Fotache Marian, Proiectarea bazelor de date Normalizare și postnormalizare, Polirom
2005
[5] Ionescu, Felicia – Baze de date relaționale și aplicații ; Editura Tehnică, 2004
[6] Lupsoiu Constantin, Boldea Costin Radu, Modelarea și proiectarea Bazelor de Date ,
Editura Sitech, 2008
[7] Petrov, G și alții, Teoria generală a bazelor de date ; Editura Mirton, 2000