2

UNIVERSITATEA TIBISCUS DIN TIMIOARA

FACULTATEA DE CALCULATOARE
I INFORMATIC APLICAT



LUCRARE DE LICEN




CONDUCTOR TIINIFIC:


CANDIDAT:






3


..









Interfa Java pentru o
baz de date MySQL















4
Universitatea Tibiscus din Timioara
Facultatea de Calculatoare i Informatic Aplicat
Departamentul de Informatic


REFERAT

asupra lucrrii de licen cu titlul
_________________________________________________
_________________________________________________
elaborat de candidatul _________________________________


Subsemnatul ____________________________ de la
departamentul de Informatic al Facultii de Calculatoare i Informatic
Aplicat, n calitate de coordonator tiinific, fac urmtoarele precizri:
lucrarea este structurat pe ___ capitole (___ pagini), n care se
trateaz tema propus;
lucrarea este ngrijit redactat i tehnoredactat;
lucrarea corespunde din punct de vedere tiinific, dovedind
cunoaterea i aprofundarea de ctre candidat a domeniului
abordat;
bibliografia consultat este bine aleas i de actualitate;
_______________________________________________
_______________________________________________
_______________________________________________
_______________________________________
n concluzie, sunt de acord cu acceptatea lucrrii n vederea susinerii
publice n faa comisiei de licen.
Propun, n calitate de coordonator tiinific, nota __________.

Timioara,
___/___/______ _______________________



5
C Ca ap pi it to ol lu ul l I I
I In nt tr ro od du uc ce er re e


Lucrarea de fa prezint o soluie original de interfa Java cu o baz de date
MySQL. Interfaa permite realizarea legaturii dintre baya de date i utilizatorul
(clientul) acesteia. Prin urmare au fost implementate principalele operaiuni din DML
i anume: INSERT, DELETE i SELECT. Aplicaia fiind una cu caracter didactic s-a
optat pentru o formul de prezentare simpl, astfel nct s nu se complice codul
sursa cu elemente suplimentare, a cror utilitate propriu-zis este discutabil.
Aplicaia este realizat n Limbajul Java versiunea jdk 1.6.0_02 care cuprinde
att pachetele API tradiionale (java.awt.*, java.awt.event.*) ct i pachetul
javax.swing.* necesare pentru implementarea ferestrelor i a elementelor de dialog
necesare pentru a transmite ctre baza de date comenzile clientului.
Capitolul de fa este consacrat unei prezentri generale a lucrrii i a aplicaiei
ce face obiectul acesteia. Fiecare capitol este descris pe scurt astfel nct s se ofere
o imagine de ansamblu a licenei.
Capitolul II Noiuni generale despre bazele de date este destinat prezentrii
elementelor teoretice fundamentale privind bazele de date i gestionarea acestora.
Textul cuprinde pe lng definiii i enunuri, un numr de exemple ilustrative pentru
mai buna clarificare a acestora.
Capitolul III Modelul relaional de gestiune a bazelor de date cuprinde o
descriere aprofundat a Modelului Relaional cu principalele sale proprieti. Este de
asemenea prezentat metodologia standard de proiectare a unui SGBD utiliznd att
Normalizarea ct i proiectarea cu ajutorul Schemelor Entitate-Relaie. La fel ca i n
cazul capitolului anterior se realizeaz un exemplu practic de proiectare i anume un
Sistem de Gestiune a unei Baze de Date academice.
Capitolul IV Implementarea aplicaiei cuprinde descrierea modului n care a
fost construit programul J_MySQL_win. Arhitectura claselor componente este
prezentat ntr-o form schematic uor de analizat. De asemenea n cadrul acestei
seciuni este inclus un Ghid de utilizator n care sunt descrise toate funciile
programului i modul n care acestea pot fi folosite.
Capitolul V Concluzii i posibiliti de dezvoltare cuprinde pe lng concluziile
propriu-zise i cteva posibile dezvoltri ulterioare ale lucrrii astfel nct s se
transforme aplicaia dintr-un program didactic ntr-unul cu valene comerciale.
Materialul cuprinde la final bibliografia studiat pentru a implementa proiectul i
o anex ce conine listat codul surs al aplicaiei. n punctele eseniale sunt inserate
comentarii destinate unei mai bune nelegeri a soluiilor concrete din program.
6
C Ca ap pi it to ol lu ul l I II I
N NO O I IU UN NI I G GE EN NE ER RA AL LE E D DE ES SP PR RE E B BA AZ ZE EL LE E D DE E D DA AT TE E


n proiectarea sistemelor informatice, organizarea datelor ocup un loc
important deoarece de modul n care datele sunt organizate depinde n mare parte
eficiena sistemului informatic.
Activitatea de organizare a datelor cuprinde:
definirea, structurarea, ordonarea i gruparea datelor n colecii de date;
stabilirea relaiilor ntre date, ntre elementele coleciei, ntre colecii;
reprezentarea datelor pe suportul de informaie n vederea prelucrrii ntr-un
sistem de calcul.
Organizarea datelor are ca scop posibilitatea ca datele s fie regsite, n mod
automat, dup diferite forme i criterii.
Activitatea de organizare a datelor are ca obiective:
minimizarea timpului de acces la datele organizate pe diferite suporturi de
informaie;
minimizarea spaiului de memorie intern i extern ocupat de datele
organizate;
reflectarea, pe ct posibil, a tuturor relaiilor dintre obiectele, fenomenele i
procesele pe care aceste date le reprezint;
posibilitatea schimbrii structurii datelor i relaiilor dintre ele fr a modifica
programele care le gestioneaz.
Datele (data) sunt definite ca informaiile efective culese din realitate, cum ar
fi un text, un numr, o imagine, un sunet etc., reprezentate sub o form care poate fi
prelucrat de un calculator.
n reprezentarea lor n calculator, datele sunt definite prin identificator
(numele variabilei care pstreaz informaia), atribut (ce reprezint informaia) i
valoare (informaia concret).
Datele pot fi elementare (sau scalare), dac sunt indivizibile n raport cu
informaia pe care o reprezint, sau compuse, dac pot fi descompuse n mai multe
date elementare.
O colecie de date ntre care s-au stabilit relaii care permit un anumit
mecanism de selecie i identificare a componentelor se numete structur de date.
Identificarea unei componente a structurii de date se poate face prin
identificatorul componentei sau prin locul ocupat n structur. Localizarea unei
componente a structurii de date se poate face prin parcurgerea tuturor
componentelor structurii, caz n care accesul se numete secvenial, sau prin
indicarea chiar a componentei dorite, caz n care accesul se numete direct.
Asupra unei structuri de date pot fi efectuate urmtoarele operaiuni:
crearea, care const n memorarea iniial a datelor pe suportul de informaie;
consultarea, care const n utilizarea datelor memorate pentru prelucrri
diverse;
actualizarea, care se poate face:
-asupra structurii de date, prin adugarea, modificarea sau tergerea de
elemente din structur;
-asupra datelor din structur, prin adugarea, modificarea sau tergerea de
valori;
sortarea, care const n aranjarea datelor conform unor anumite criterii;
ventilarea, care reprezint desfacerea structurii de date n dou sau mai
multe structuri;
7
fuzionarea, care nseamn unirea a dou sau mai multe structuri de date;
copierea, care const n efectuarea unei copii a structurii cu datele aferente;
interclasarea, care nseamn mbinarea datelor din dou sau mai multe
structuri; etc.
Structurile de date se pot clasifica astfel:
dup tipul componentelor:
-structuri omogene, cnd componentele sunt de acelai tip;
-structuri eterogene (neomogene), cnd componentele aparin unor tipuri
diferite;
dup posibilitatea de descompunere:
-structuri recursive, cnd se pot descompune n structuri de acelai tip;
-structuri nerecursive, cnd nu se pot descompune n structuri de acelai tip;
dup posibilitile de modificare:
-structuri statice, cnd numrul total de componente i ordinea acestora nu se
pot modifica;
-structuri dinamice, cnd numrul total de componente i/sau ordinea acestora
pot fi modificate;
dup nivelul de structurare a datelor:
-structur logic, dac se refer la modul de ordonare a datelor i operatorii
folosii;
-structur fizic, dac se refer la modalitatea de memorare a datelor pe
suporii de informaie.
Principalele tipuri de structuri de date sunt:
structura punctual, reprezentat printr-o singur entitate;
structura liniar - cnd ntre elementele structurii exsit o relaie de ordine
total;
structura arborescent (ierarhic, descendent) - cnd ntre elementele
structurii exist o relaie de ordine;
structura reea - cnd ntre elementele structurii exist o relaie de preordine;
structur relaional - cnd elementele structurii sunt reprezentate prin
tabele (tablouri) de date elementare crora li se pot aplica operatorii algebrei
relaionale.
Transpunerea informaiilor din realitate n reprezentarea lor cu structuri de
date se face numai dup ce s-a definit modelul datelor, ceea ce nseamn
identificarea urmtoarelor elemente:
structura modelului;
operatorii care pot fi utilizai;
restriciile care asigur meninerea corectitudinii datelor.
Definirea modelului datelor se face prin definirea obiectelor (entitilor) i
caracteristicilor asociate i a relaiilor ntre obiecte.
Definirea operatorilor se face indicnd principalele operaii ce pot fi efectuate
asupra datelor (citire, memorare, modificare etc.) i modalitatea de efectuare a
acestor operaii.
Restriciile (numite i reguli de integritate) sunt indicate pentru a preveni
operaiile care ar modifica structura de date lsnd informaiile ntr-o situaie
necorespunztoare.
Conform tipurilor de structuri de date prezentate anterior, modelele de date
pot fi:
modelul ierarhic, bazat pe tipuri de nregistrri care grupeaz toate atributele
unei entiti, avnd un tip de nregistrare tat i mai multe tipuri de nregistrare
fiu;
8
modelul reea, bazat pe tipuri de nregistrri care grupeaz toate atributele
unei entiti, avnd mai multe tipuri de nregistrare tat i mai multe tipuri de
nregistrare fiu;
modelul relaional, bazat pe utilizarea tabelelor care grupeaz diferite
atribute ale unei entiti.


2.1 ABORDAREA GESTIUNII INFORMAIEI CU BAZE DE DATE


Un sistem de gestiune a bazelor de date este compus din urmtoarele pri:
datele, componentele hardware, componentele software i utilizatorii.
Una din definiiile [DES99] noiunii de baz de date este un depozit pentru
datele memorate. Din acest punct de vedere, mrimea BD este o informaie critic,
n sensul c o BD de dimensiuni foarte mari pune probleme de memorare i
gestionare. Atunci o BD poate fi:
integrat - ea conine mai multe fiiere de date, cu o parte a redundanelor
eliminat. De exemplu, dac se dorete evidena studenilor i a rezultatelor la
examene, acestea pot fi organizate n dou fiiere separate: unul cu datele
personale ale studenilor i cellalt cu notele obinute. Evident c al doilea
fiier trebuie s conin unele informaii din primul fiier, dar prin folosirea BD
aceast repetare este eliminat;
partajat - mai muli utilizatori pot accesa simultan BD. De exemplu, la BD a
studenilor poate avea acces studentul, pentru a opera unele modificri simple
cum ar fi cele de domiciliu, dar n acelai timp i secretariatul facultii, pentru
operaii de actualizare cum ar fi anul de studiu i media anului trecut.
Datele pot fi grupate n urmtoarele categorii:
date de intrare, care permit introducerea de modificri asupra coninutului
BD;
date de ieire, coninnd rezultatele prelucrrilor efectuate asupra BD;
datele din BD, numite i date operaionale, care reprezint activitatea
organizaiei respective.
Componenta hardware este reprezentat de suporii tehnici pe care are loc
memorarea datelor: harddisk-uri, dischete, CD-uri, benzi magnetice etc., mpreun cu
dispozitivele care permit utilizarea acestor supori i cu restul calculatorului
(calculatoarelor) utilizat(e), cu ajutorul cruia are loc gestionarea i prelucrarea
datelor.
Componenta software este totalitatea programelor care permit gestionarea i
prelucrarea datelor. De obicei, acest lucru se efectueaz folosind limbaje (sau
sisteme) orientate ctre BD i nu limbaje universale de programare.
Utilizatorii sunt componentele sistemului BD care asigur gestionarea,
prelucrarea i interpretarea datelor.
O alt definiie a BD se bazeaz pe componentele sale, care sunt entitile,
atributele i relaiile.
O entitate reprezint informaiile despre un anumit obiect, fie el real sau
imaginar. Tot ceea ce se cunoate despre respectivul obiect poate fi grupat astfel
nct s permit cunoaterea obiectului n detaliu.
De exemplu, dac se dorete o eviden a studenilor unei universiti, se
definete entitatea STUDENT despre care se cunosc urmtoarele:
Numele: POPESCU
Prenumele: MARIA
9
Prenumele tatlui: ION
Prenumele mamei: OANA
Data naterii: 10.06.1980
Locul naterii: TIMIOARA
Domiciliul: TIMIOARA, STR. AUREL VLAICU NR. 7
Facultatea: CALCULATOARE
Anul de studiu: II
Numr matricol: 175

Fiecare din aceste informaii reprezint o proprietate (atribut, item, cmp,
caracteristic, element de date) a entitii STUDENT. De exemplu, Prenumele este
un atribut al entitii STUDENT.
Informaiile concrete pe care le ofer atributele, atunci cnd fac referire la o
entitate particular, se numesc valori. De exemplu, MARIA este o valoare a
atributului Prenumele pentru o anumit ocuren a entitii STUDENT.
Mai multe entiti care au proprieti similare alctuiesc un tip de entitate
(clas de entitate), aa cum, de exemplu, toate numerele ntregi ntre anumite limite
alctuiesc n Pascal tipul predefinit integer.
De exemplu, toi studenii dintr-o anumit grup, an, facultate etc. au
proprieti similare i deci sunt membri ai aceluiai tip de entitate STUDENT.
Pentru mai multe apariii ale aceleiai entiti (mai muli studeni ai aceleiai
grupe), unul dintre atribute reprezint n mod unic acea entitate i se numete cheie
primar (eng. primary key) a entitii i se noteaz cu sufixul #. Alegerea acestui
atribut se face astfel nct s nu existe dou atribute cu aceeai cheie primar.
De exemplu: atributele nume, prenume, data i locul naterii, nu identific n
mod unic un student. Rolul de cheie primar l poate avea atributul Numr Matricol i
atunci acesta se noteaz prin Numr Matricol#.
ntre entiti, sau ntre entiti i atribute, sau ntre atribute, pot exista legturi
care se numesc relaii (eng. relationships).
O baz de date se definete ca o colecie de entiti mpreun cu relaiile
dintre ele.
BD au dou forme n care exist:
BD fizice - formele de nregistrare a informaiilor pe suportul tehnic, adic
modul n care ele sunt organizate n directoare i fiiere;
BD logice - informaiile i modul lor de organizare, independent de felul n
care are loc memorarea pe suportul tehnic.
De exemplu, BD a studenilor prezentat anterior are urmtoarele forme:
fizic, n care se cunoate faptul c informaiile sunt pstrate n fiiere cu
acces secvenial aflate pe harddisk sub un anumit nume de fiier i exploatate
folosind programe Pascal, compuse din nregistrri (record);
logic, n care se cunoate faptul c entitile au atributele Nume i Prenume
care conin informaii alfabetice, Anul de studiu care conine informaii
numerice etc.
Gestionarea datelor reprezint toate activitile care determin ca datele de o
nalt calitate s fie disponibile pentru a produce informaia i cunotinele dorite.
O implementare eficient a gestionrii BD se face folosind un sistem de
gestiune a bazelor de date (SGBD).
Dac n mediul de lucru tradiional, orientat spre fiiere i proceduri, datele
trec de la un program la altul pentru a fi prelucrate pot aprea urmtoarele probleme:
de consisten: dac un fiier poate fi accesat de mai muli utilizatori pentru
operaii diferite, este posibil ca fiecare utilizator s doreasc exploatarea n
10
scopuri diverse. Cnd un fiier poate fi accesat de mai muli utilizatori pentru
operaii diferite, este posibil ca un utilizator s actualizeze o anumit informaie
chiar n momentul cnd alt utilizator citete acea informaie ceea ce duce la o
informaie eronat pentru al doilea utilizator. De exemplu, dac la secretariat
se extrage lista studenilor care au restane la achitarea taxei chiar n
momentul cnd unul din restanieri pltete este posibil ca el s figureze cu
restan dei tocmai a pltit taxa;
de corelaie: dac un fiier poate fi accesat de mai muli utilizatori pentru
operaii diferite, este posibil ca fiecare utilizator s doreasc o codificare a
anumitor cmpuri. De exemplu, identificarea unic a entitii STUDENT se
face la nivel de facultate prin cmpul numr matricol. La casierie sau
bibliotec ns, acest cmp nu este suficient, deoarece cu numrul matricol 1
exist student la fiecare facultate a unei universiti, deci este necesar o
codificare care s in cont i de facultate.
Dac se lucreaz cu SGBD, datele nu sunt legate de aplicaia care le
exploateaz i de aceea ele pot fi partajate astfel nct s poat fi exploatate
simultan de mai muli utilizatori fr ca problemele de mai sus s apar.
Un SGBD trebuie s asigure:
1. protejarea valorilor datelor prin controlul securitii i integritii datelor;
2. partajabilitatea datelor, adic datele s poat fi folosite simultan de mai muli
utilizatori i de mai multe aplicaii;
3. gestionarea datelor funcie de semnificaia lor i nu funcie de modalitatea de
memorare i reprezentare a lor;
4. gestionarea datelor funcie de obiectivele organizaiei de unde provin aceste
date;
5. independena datelor, adic structura de memorare a datelor s nu se
modifice dac se modific aplicaiile care exploateaz acest date;
6. o redundan minim a datelor, adic datele s apar, n principiu, doar o
singur dat n BD;
7. reducerea costului de mbuntire a performanei, prin posibilitatea de a
obine aceleai rezultate chiar dac datele sunt reorganizate.
n urma abordrii activitii organizaiei folosind BD apar mbuntiri n ceea
ce privete:
controlul datelor: modalitatea de a memora datele este optimizat prin
utilizarea unor standarde de implementare aceleai date pot fi transferate
dintr-un SGBD n altul atunci cnd apar necesiti de reorganizare;
accesibilitatea datelor: datele pot fi astfel combinate nct s ofere
utilizatorului informaiile care i sunt necesare;
calitatea datelor: explotarea BD ofer utilizatorului posibilitatea de a extrage
cele mai bune soluii pentru rezolvarea problemelor organizaiei;
partajarea datelor: datele nu mai sunt redundante ceea ca reduce
posibilitatea apariiei erorilor de consisten; n plus, accesul la date este mai
rapid iar spaiul de memorare necesar este mai redus;
sigurana datelor: un SGBD ofer soluii pentru prevenirea apariiei erorilor i
pentru refacerea datelor afectate de eroare;
securitatea datelor: SGBD permit prevenirea accesului neautorizat la date
folosind mecanisme mai mult sau mai puin restrictive, evident funcie i de
coninutul informaiilor respective;
performana: folosirea SGBD permite obinerea de informaii din BD ntr-un
timp scurt (deci cu o eficien mare) dar aceste informaii pot rspunde mai
mult sau mai puin nevoilor utilizatorului (deci au o anumit efectivitate).
11
Totui, folosirea unui SGBD implic pentru utilizator anumite costuri legate de:
tehnologia SGBD: achiziionarea unui SGBD depinde mult de preul acestuia:
de exemplu, licena Microsoft Access (parte component a pachetului
Microsoft Office) este circa 300 USD pentru fiecare calculator; licena Oracle
pentru 10 posturi de lucru este circa 5000 USD;
operarea BD: utilizarea SGBD nseamn costuri cu exploatarea
calculatoarelor, cu achiziionarea i ntreinerea suporilor de informaii i a
programelor de exploatare a BD;
conversie: trecerea de la un alt sistem la cel bazat pe BD presupune
transformri legate de suporii tehnici i modalitatea de memorare, ca i
transformarea programelor de exploatare;
planificare: construirea unei BD la nivelul ntregii organizaii poate fi complex
(de exemplu BD a studenilor unei universiti) i de aceea trebuie efectuat o
planificare a etapelor de trecere la BD;
risc: este posibil ca implementarea eronat a BD s nu aduc mbuntirea
activitii organizaiei respective i s nu justifice cheltuielile efectuate.
Un alt aspect al utilizrii unui SGBD este acela al personalului care va asigura
efectivitatea BD:
utilizatorii vor folosi BD i de aceea trebuie s ajute la definirea cerinelor BD;
analitii traduc cerinele utilizatorilor n modaliti de organizare i gestionare
a datelor;
programatorii genereaz codul de gestionare a BD;
administratorii asigur gestionarea i controlul utilizrii BD. Se deosebesc
administratorii BD (ABD; eng. data base administrator DBA) care rspund
de proiectarea fizic a BD i administratorii de date (AD; eng. data
administrator DA) care rspund de proiectarea, controlul i gestiunea datelor.


2.2 ARHITECTURA SISTEMELOR DE GESTIUNE A BAZELOR DE DATE


Un SGBD poate fi considerat a avea structura din Figura 2.1:
Conform acestei structuri, pentru a implementa corect o BD este nevoie ca
datele s fie modelate astfel nct s corespund structurii de mai sus.
La nivelul exterior, utilizatorii sunt aceia care, interesai fiind de o parte a BD,
cea care le poate oferi informaiile dorite, nu trebuie s cunoasc modul n care
datele sunt memorate fizic pe suporii de informaie. De aceea, aceast viziune a
utilizatorilor individuali se numete vedere extern.







Nivel
exterior
Utiliz
ator 1
Utiliz
ator 2

......
Utiliz
ator n



Nivel
conceptual
Comunitatea utilizatorilor
12



Nivel
intern
Memorarea datelor

Figura 2.1. Nivelele bazei de date

De exemplu, la casieria universitii este disponibil BD care conine, pe
faculti, specializri i ani de studii, toi studenii (numele i prenumele, numrul
matricol), fr a avea acces la datele personale ale studenilor sau rezultatele la
examene, care i ele fac parte din BD.
Din acest motiv, se consider c vederea extern este compus din mai multe
nregistrri externe (nregistrri logice), coninutul lor depinznd de necesitile
utilizatorului care le folosete.
Vederea extern este definit cu ajutorul unei scheme externe care
reprezint definiiile pentru fiecare din variantele de nregistrri externe din vederea
extern.
Pentru descrierea schemei externe utilizatorul folosete un limbaj pe care l
cunoate (fie de programare, fie orientat spre BD) care se numete limbaj de
definiie date (LDD; eng. Data Definition Language DDL). Deoarece face referire
la schema extern, limbajul se mai numete LDD extern.
Pentru a trece de la schema (de la vederea) extern la cea conceptual este
necesar o transformare, iar operaia de trecere se numete mapare extern-
conceptual.
Vederea conceptual este o reprezentare a ntregii informaii din ntreaga
BD, indiferent de utilizatorul care are nevoie de aceste informaii. Nici la acest nivel
nu este necesar a se cunoate modul n care datele sunt memorate fizic pe suporii
de informaie i de aceea aceast viziune a ansamblului utilizatorilor se numete
vedere conceptual.
Se consider astfel c vederea conceptual este compus din mai multe
nregistrri conceptuale, coninutul lor depinznd de necesitile tuturor
utilizatorilor.
n exemplul anterior, nregistrrile conceptuale conin att datele de
identificare a studenilor, ct i situaia la examene, prezena la orele de curs i
seminar (laborator), situaia taxelor, a crilor mprumutate de la bibliotec etc.
Vederea conceptual este definit la rndul ei folosind o schem
conceptual care reprezint definiiile pentru fiecare din variantele de nregistrri
conceptuale.
Pentru descrierea schemei conceptuale se folosete de asemenea un LDD i
cum acesta face referire la schema conceptual, limbajul se numete LDD
conceptual.
La acest nivel (conceptual) definiiile utilizate nu fac referire n nici un fel la
modul de reprezentare a datelor, tipurile de date folosite, ordinea de memorare etc.,
deoarece acestea sunt n sarcina celui de-al treilea nivel al bazei de date, folosind o
operaie de transformare numit mapare conceptual-intern.
Nivelul intern corespunde vederii interne, cea care const n apariia unor
nregistrri interne (nregistrri memorate) care sunt memorate ntr-un spaiu liniar
infinit; totui nc nu se poate vorbi de nregistrrile fizice (nume de fiiere,
compunerea articolului, modul de adresare, restricii de mrime etc.) deoarece
acestea depind de implementarea (limbajul) aleas.
13
i vederea intern este descris printr-o schem intern, care definete
tipurile de nregistrri interne, modul de reprezentare a cmpurlor memorate, indecii
utilizai, etc.
Pentru descrierea schemei interne se folosete un limbaj care se numete
LDD intern.
n transformarea datelor de la nivelul extern la cel intern, ele sufer dou
transformri. Maparea extern-conceptual definete corespondena dintre vederea
extern i cea conceptual, reunind toate vederile externe i eliminnd redundanele
pentru a obine vederea conceptual. Maparea conceptual-intern definete
corespondena ntre vederea conceptual i baza de date memorat, specificnd
modul n care cmpurile i nregistrrile au corespondent n datele memorate.
Utilizatorii, pe lng sarcina de a defini datele de care au nevoie, trebuie s i
utilizeze aceste date. Pentru prelucrarea datelor ei au la dispoziie un limbaj numit
limbaj de manipulare date (LMD; eng. Data Manipulation Language DML).
Aceste concepte teoretice au fost particularizate n dou variante, de ctre
organismele care au efectuat cercetri asupra BD.


2.2.1 Arhitectura unui sistem de gestiune a bazelor de date n concepia
CODASYL

Program al
aplicaiei A

1
Subschema BD
corespunztoare
aplicaiei A


9
10
2

Buffere
sistem
8
SGBD
3
Schema BD



5
4




6 Sistem
de operare
Descrierea
fizic a BD
7





BD


Figura 2.2. Arhitectura unui SGBD n concepia CODASYL

n concepia CODASYL, un SGBD are arhitectura din Figura 2.2 iar un
program de aplicaie genereaz urmtoarele operaii:
1. programul de aplicaie A lanseaz ctre SGBD o cerere de citire date din BD;
2. SGBD interpreteaz cererea prin consultarea Subschemei BD ce corespunde
aplicaiei A;
3. SGBD cere de la schema BD datele logice solicitate;
4. SGBD examineaz descrierea datelor fizice fa de cele logice i determin
poziionarea datelor pe suportul de informaie;
5. SGBD lanseaz ctre sistemul de operare o cerere de cutare a nregistrrii
fizice;
6. sistemul de operare caut nregistrarea fizic;
14
7. nregistrarea gsit este transferat n buffer;
8. SGBD identific datele cerute de program prin extragerea lor din Schema BD,
conform cerinelor specifice Subschemei ce corespunde aplicaiei A;
9. datele sunt transferate de SGBD n zona de lucru a aplicaiei A;
10. aplicaia A preia datele i efectueaz operaiile dorite, informnd SBGD despre
reuita operaiei de citire.


2.2.2 Arhitectura unui sistem de gestiune a bazelor de date n concepia
ANSI/SPARC


Administrator firm

1

Administratorul 3 Procesorul sche- 3 Administratorul
BD mei conceptuale aplicaiei

6 2 4
Procesorul 7 Dicionar 5 Procesorul
schemei interne de date schemei externe

10 9 8

Transformarea 12 Transformarea 11 Transformarea
intern/memorie intern/conceptual conceptual/extern

16 14
Programe de Programe de
aplicaie interne aplicaie externe

15 13
Procesor Programator
de sistem de aplicaie


Figura 2.3. Arhitectura unui SGBD n concepia ANSI/SPARC

n concepia ANSI/SPARC, un SGBD are arhitectura din Figura 2.3 iar
interfeele ntre componente i utilizatori funcioneaz astfel:
1. n baza cererilor administratorului firmei se realizeaz declararea schemei
conceptuale;
2. schema conceptual este tradus n dicionarul de date;
3. schema conceptual este adus la cunotina ABD i administratorilor de
aplicaii;
4. se specific declaraiile schemelor externe;
5. declaraiile schemelor externe se memoreaz n dicionarul datelor;
6. se specific declaraiile schemelor interne;
7. declaraiile schemelor interne se memoreaz n dicionarul datelor;
8. informaiile solicitate pentru transformarea extern/conceptual sunt luate din
dicionarul de date;
9. informaiile solicitate pentru transformarea conceptual/intern sunt luate din
dicionarul de date;
15
10. informaiile solicitate pentru transformarea intern/memorie sunt luate din
dicionarul de date;
11. datele necesare execuiei comenzilor sunt transmise ntre nivelele BD;
12. comenzile necesare execuiei programelor sunt transmise ntre nivelele BD;
13. are loc comunicarea ntre programator respectiv utilizator i SGBD;
14. are loc compilarea i execuia programului utilizatorului folosind schema
extern;
15. traducerea cererilor pentru cazul efecturii de schimbri la structura de
memorare sau strategia de acces;
16. execuia schimbrilor la structura de memorare sau strategia de acces.


2.3 CLASIFICAREA SISTEMELOR DE GESTIUNE A BAZELOR DE DATE


SGBD pot fi clasificate astfel:
dup criteriul sistemelor de calcul pe care se implementeaz:
-SGBD pentru calculatoare mari;
-SGBD pentru minicalculatoare;
-SGBD pentru microcalculatoare;
dup criteriul limbajului pe care l utilizeaz:
-SGBD cu limbaj gazd, care utilizeaz limbaje de nivel nalt;
-SGBD cu limbaj autonom, care au un limbaj specializat pentru crearea,
actualizarea i interogarea BD;
dup criteriul concepiei de organizare a datelor (ele vor fi detaliate n
capitolele urmtoare):
-SGBD cu structuri ierarhice;
-SGBD cu structuri reea;
-SGBD relaionale;
-SGBD orientate obiect;
dup criteriul localizrii BD:
-SGBD centralizate - datele se gsesc pe acelai calculator;
-SGBD distribuite - datele se gsesc pe calculatoare diferite, aflate chiar la
distane foarte mari unele de altele.


2.4 PROIECTAREA I MODELAREA BAZELOR DE DATE


Intervalul de timp de la apariia unei cereri de realizare a unei BD i pn la
scoaterea ei din exploatare formeaz ciclul de via. n cadrul acestuia, perioada de
timp n care se proiecteaz, programeaz i implementeaz sistemul, constituie
ciclul de realizare. Perioada de timp ct sistemul este exploatat constituie ciclul de
exploatare. ntreaga problem a conducerii organizaiilor este tot mai mult asimilat
activitilor i proceselor de orice natur n care criteriile determinante de evoluie
sunt cele legate de eficiena i profitabilitatea realizrilor. n scopul ncadrrii
aciunilor ntr-o concepie sistemic, n conformitate cu standardele naionale i
internaionale, nainte de aplicarea unei strategii trebuie elaborat un stadiu de
fezabilitate prin care s se stabileasc dac sistemul informatic se justific prin
prisma efortului i a rezultatelor previzibile.
16
Fiecare nivel de abstractizare atins n ciclul de via are ca i corespondent o
anumit generaie a sistemului, iar n cadrul unei generaii se pot delimita mai multe
versiuni ale sistemului informatic. n cadrul fiecrei versiuni a sistemului, pot fi definite
etape (secvene, faze) de activiti, care astfel devin prin particularizare faze ale
ciclului de via. Acest ciclu presupune dou perioade principale de funcionare:
proiectarea i realizarea sistemului n care se definete conceptual i tehnic
sistemul i se elaboreaz documentaia de proiectare, exploatare i ntreinere, n
vederea punerii sistemului n funciune la nivelul organizaiei;
exploatarea sistemului, care este acea parte a ciclului de via n care sistemul
este folosit efectiv pentru prelucrarea automat a datelor provenind de la
organizaie.
Pentru sistematizarea problemelor privind ciclul de via al unui sistem a fost
elaborat un model matematic, numit modelul n cascad sau modelul Boehm, care
se bazeaz pe urmtoarele concepte:
fiecare etap se ncheie prin trecerea unei probe de validare, avnd ca scop
eliminarea eventualelor deficienelor care au aprut n cadrul etapei respective;
cnd deficienele au fost eliminate sau nivelul lor de gravitate este acceptabil, se
trece la etapa urmtoare, altfel etapa se reia;
cnd deficienele semnalate impun revenirea la etape precedente, aceasta se
poate face numai la etapa imediat anterioar;
ultima etap are rol de ntreinere i se refer doar la ntreinerea, corectarea i
actualizarea versiunilor, pe baza deficienelor semnalate, de ctre beneficiari, n
exploatare.
Pe baza conceptelor prezentate anterior, un sistem de BD, vzut ca sistem
compus din calculator (hardware), programe (software) i echipamente auxiliare,
mpreun cu utilizatorii i datele acestora, va evolua prin trecerea pe rnd prin
etapele prezentate n continuare.
n cadrul fiecrei etape n parte au loc urmtoarele activiti specifice:
1. definirea cerinelor sistemului. n aceast etap, sistemul este privit ca o cutie
neagr, creia i se furnizeaz date de intrare i care genereaz rezultatele obinute
n urma prelucrrii lor. Pentru sistem se definesc clasa problemelor ce trebuie
realizate, care sunt cerinele strict necesare, care sunt criteriile dup care au loc
calculele i optimizrile etc.
2. studiul de fezabilitate. Se pleac de la formularea unei cereri ce exprim clar
cerinele (funciile) ce trebuie realizate de sistem. Apoi se face un studiu ce stabilete
modul de realizare a fiecrei cerine n parte, cu determinarea necesitilor de natur
hard i soft pentru funcia respectiv i rezultatele care s-ar putea obine, alturi de
cheltuielile necesare.
3. analiza sistemului existent. Const n revederea documentaiei sistemului, a
posibilitilor hard i soft utilizate la momentul respectiv, de unde rezult deficienele
i insuficienele sistemului existent.
4. definirea arhitecturii funcionale a sistemului. n aceast etap se stabilesc
funciile de baz pe care trebuie s le rezolve sistemul, rezultnd o list de funcii de
realizat i o mulime (de date, informaii) asupra creia acioneaz aceste funcii.
Presupune pe de o parte definirea necesitilor de calculatoare, pe de alt parte a
necesitilor de programe.
5. proiectarea arhitecturii funcionale a sistemului. Cuprinde proiectarea modului
n care sistemul rezolv fiecare funcie n parte, prin stabilirea componentelor noului
sistem (subsisteme i uniti funcionale). De aici rezult concluzii despre necesitile
hard i soft, ca i modul n care diferitele funcii interacioneaz ntre ele.
17
6. proiectarea i programarea componentelor sistemului. n aceast etap se
preiau i eventual adapteaz componentele existente (n biblioteci de programe, n
alte sisteme etc.) ce pot rezolva pri ale funciilor sistemului i se definete modul de
lucru al funciilor care trebuie proiectate complet. Trebuie avut n vedere c urmeaz
integrarea acestor componente, de aceea nu se vor folosi metode i tehnici ce nu
permit combinarea ulterioar a obiectelor rezultate. De asemenea, se va avea n
vedere sistemul de gestiune a datelor i sistemul de calcul care au fost alese.
7. integrarea componentelor i testarea sistemului. Se asambleaz modulele
rezultate la etapa anterioar, se testeaz sistemul astfel obinut (utiliznd date de
test) i se elimin erorile ce apar, att la module n parte ct i la interaciunea dintre
module (ce pot apare de exemplu datorit faptului c module diferite sunt proiectate
i codificate de programatori diferii). Integrarea se poate face prin tehnica top-down
sau tehnica bottom-up. n paralel se elaboreaz i documentaia de execuie i cea
de exploatare a sistemului.
8. conversia i implementarea (livrarea). Presupune implementarea sistemului la
beneficiar, instruirea acestuia asupra modului de lucru i asisten pe perioada de
nceput a lucrului cu noul sistem. Beneficiarul face recepia sistemului, verificnd
respectarea specificaiei de definire a acestuia i existena tuturor condiiilor
necesare exploatrii curente. Chiar i n aceast etap mai pot apare erori, de aceea
ele vor fi analizate i se vor elabora soluii de remediere, ce vor fi aplicate n
variantele ulterioare ale sistemului.
9. operarea. n aceast etap, ce dureaz de regul pn la ncetarea utilizrii
sistemului, are loc utilizarea sa de ctre beneficiar, rmnnd valabil observaia
despre erori de la etapa anterioar.
Proiectarea BD este o operaie care are loc n dou faze fundamentale:
proiectarea logic i proiectarea fizic. Aceast succesiune este determinat de
formele (logic respectiv fizic) de existen a BD.


2.4.1. Proiectarea logic a bazei de date

Proiectarea logic se bazeaz pe o metodologie numit abordarea cu trei
scheme care pleac de la nivelele bazei de date prezentate anterior. Ea a fost
propus la mijlocul anilor 1970 i publicat n 1977 ntr-un raport al ANSI numit The
ANSI/X3/SPARC DBMS Framework: Report of the Study Group on Database
Management Systems i pleac de la urmtoarele supoziii:
calculatoarele i utilizatorii vd datele n moduri diferite;
diferii utilizatori au nevoie de diferite pri din BD;
cnd utilizatorii schimb modul n care au nevoie s vad BD, acest lucru nu
trebuie s influeneze modul de lucru;
utilizatorii nu pot fi mpiedicai de ctre calculator s vad datele aa cum au
nevoie.
Pentru aceasta este necesar ca vederile utilizatorilor s fie separate de
vederile de implementare, adic utilizatorii nu trebuie s cunoasc modul n care
datele sunt memorate fizic.
De aici rezult c datele sunt vzute diferit, ele au o vedere utilizator, orientat
spre acesta (de exemplu datele personale ale studentului, rezultatele la examene
etc.) i o vedere de implementare, orientat spre calculator (de exemplu fiiere,
articole, adresare secvenial etc.). n mod corespunztor exist schemele externe,
care conin vederile utilizator ale uneia sau mai multor aplicaii i schemele interne,
care conin vederile de implementare a datelor.
18
ntre cele dou scheme exist o legtur care se realizeaz prin operaia de
mapare (transformare) ntre vederea utilizator i vederea de implementare.
Aceast mapare se poate face direct, atunci cnd fiecare schem intern este
mapat direct pe BD. Metoda este necorespunztoare deoarece atunci cnd se
restructureaz o BD, ca rspuns la nevoile unei scheme externe, celelalte scheme
externe ar putea suferi; chiar i invers, la schimbarea unei scheme externe sunt
necesare schimbri ale tuturor BD implicate.
O alt variant de mapare folosete o schem conceptual (vederea
comunitii, vederea ntreprinderii) inserat ntre vederea utilizator i cea de
implementare, ceea ce previne neajunsurile prezentate anterior, aa cum s-a
prezentat i n paragraful anterior.
Atunci cnd sistemul care trebuie realizat se bazeaz pe utilizarea BD,
modelul ciclului de via prezentat la nceputul acestui paragraf sufer unele
modificri impuse de necesitatea implementrii BD i software-ul utilizator pe baza
unei scheme conceptuale. Etapele (fazele) ce trebuie parcurse cnd se utilizeaz BD
sunt atunci urmtoarele:
1. examinarea: stabilirea domeniului, planificarea proiectului, colectarea i analiza
datelor, dezvoltarea modelelor de date;
2. proiectarea: dezvoltarea modelelor de date logice detaliate, planificarea
procesului de prototipare, ntocmirea schiei cu specificaiile tranzaciilor BD;
3. prototiparea: proiectarea structurii BD fizice pentru prototipul iniial al BD,
utilizarea prototipului prin ncrcarea i validarea vederilor utilizator, definirea
tranzaciilor cerute, dezvoltarea acestora i transformarea prototipului n starea de
lucru;
4. integrarea: combinarea modelelor de date logice prototip cu schema conceptual
i mbuntirea maprilor interscheme;
5. reglajul: optimizarea structurilor BD fizice i a componentei software;
6. revizia: urmrirea ieirilor proiectului i transformarea prototipului din starea de
pregtire n starea de producie.
Toate aceste etape sunt parcurse de una sau mai multe echipe de proiect
compuse din personal de prelucrare date i din utilizatori, acetia din urm ajutnd la
determinarea relaiilor i a tranzaciilor de date, avnd n vedere c ei sunt
beneficiarii sistemului care se creaz.
Deoarece o BD poate fi exploatat de mai muli utilizatori (adic mai multe
proiecte), fiecare dintre acetia trebuie s determine care din informaiile deja
existente, n prile folosite de ali utilizatori, i sunt utile i ce informaii suplimentare
mai sunt necesare. Atunci schema conceptual evolueaz i ea dup cum evolueaz
proiectele suplimentare.


2.4.2 Modelarea datelor logice

Modelarea este operaia de reprezentare matematic sau grafic a unui
obiect sau sistem (numit prototip) care exist n lumea real, avnd ca obiectiv
nelegerea mai bun a prototipului, a modului su de funcionare i a modificrilor
care apar atunci cnd au loc schimbri asupra strii sau funcionrii prototipului.
Modelele de date logice sunt reprezentri ale semnificaiei datelor ntr-un
domeniu de interes. Ele reprezint entiti (ceva din lumea real despre care vrem s
pstrm informaii), atribute (o proprietate a unei entiti) i relaii (legturi ntre
entiti sau atribute).
Modelele de date logice vizeaz ndeplinirea urmtoarelor obiective:
19
comunicarea semnificaiei datelor. Ele sunt folosite pentru a indica ce
nseamn datele respective. Oricine este familiar cu notaia i termenii utilizai
nelege care este semnificaia acelor date;
descoperirea semanticii datelor. Ele sunt folosite pentru a indica
semnificaia datelor nregistrate, adic a nelege aciunile care decurg din
valorile particulare ale datelor respective.
Dac modelarea datelor logice ndeplinete cele dou obiective precizate
anterior, atunci ea este util deoarece permite:
nelegerea datelor. Utilizatorii sunt aceia care spun la ce sunt folosite datele
i care este rostul lor n cadrul organizaiei, de aceea colectivul care
realizeaz modelarea trebuie s fie format din cunosctori ai modelului
respectiv;
documentarea datelor. n timpul modelrii rezult clar explicaiile privind rolul
datelor iar documentarea acestora face posibil utilizarea mai multor colective
de modelare n acelai timp;
evaluarea software-ului. Utilizatorul are la dispoziie multe produse software
care par a fi potrivite scopurilor sale. Alegerea celui mai bun (din toate
punctele de vedere) se face uor dac programele sunt documentate cu un
model de date logice;
planificarea sistemelor informatice. Utilizarea unui sistem informatic la
nivelul ntregii organizaii presupune mai multe proiecte ce corespund
diferitelor compartimente sau funciuni ale organizaiei. Printr-o corect
modelare logic se identific fiecare proiect i se descrie domeniul datelor
implementate de fiecare proiect n parte;
proiectarea sistemelor informatice. Pentru proiectarea BD fizice este
necesar un model detaliat al atributelor, volumelor i frecvenelor de acces la
date, care se obine n timpul modelrii de date logice;
integrarea resurselor de date. Modelele asigur o viziune de ansamblu la
nivelul ntregii organizaii i de aceea ele permit identificarea i eliminarea
inconsistenelor i a redundanelor;
susinerea proiectrii BD fizice. Plecnd de la modelul de date, colectivul de
lucru obine informaii despre datele care sunt cuprinse n BD, relaiile din
interiorul BD i dintre aceasta i alte BD;
pstrarea consistent a tehnicii. Exist mai multe tehnici (procedee,
metode) de modelare logic; dac organizaia pstreaz aceeai metod n
ntreaga sa activitate, atunci nu apar probleme de interaciune ntre diferitele
proiecte.
Aa cum s-a artat mai sus, exist mai multe tehnici de modelare logic.
Pentru a fi utile, ele trebuie s ndeplineasc urmtoarele condiii:
producerea diagramelor grafice sub form de dreptunghiuri sau cercuri
(pentru a reprezenta entitile) i linii sau arce (pentru a reprezenta relaiile).
Aceast condiie se aplic numai tehnicilor bazate pe diagrame, deoarece mai
exist i tehnici care se bazeaz pe utilizarea de instruciuni de limbaj;
posibilitatea reprezentrii explicite a semanticii ceea ce nseamn
utilizarea de simboluri diferite pentru semantici diferite ale datelor. Aplicarea
condiiei poate duce la suprancrcarea diagramei cu simboluri;
asigurarea unui nivel potrivit de detaliere pentru fiecare utilizator n
parte, dup nivelul ierarhic pe care se afl sau dup nivelul (logic sau fizic) de
acces la date;
asigurarea independenei SGBD-ului prin rezolvarea problemei fr a folosi
particulariti ale unui anumit limbaj;
20
includerea unui suport automatizat care s deseneze diagramele, s
analizeze modelele de date, s elimine inconsistenele i redundanele.
Condiia este doar parial ndeplinit de tehnicile utilizate momentan.
Modelele de date fizice reprezint implementarea structurilor de date i sunt
formate din fiiere, nregistrri, adrese, pointeri etc.
Modelele de activitate reprezint procesele care au loc n cadrul organizaiei
i relaiile dintre aceste procese.


2.4.3 Triada entiti atribute relaii

Aa cum s-a artat i n paragraful 2.1, cele trei concepte de baz n
modelarea datelor sunt entitatea, atributul i relaia.
Entitatea reprezint informaiile despre un anumit obiect, fie el real sau
imaginar. Indiferent dac obiectul este real sau imaginar, el are o semnificaie real
(nseamn ceva pentru utilizator) i de aceea tehnica de modelare utilizat nu trebuie
s fac distincie ntre entitile reale i abstracte.
Ca reprezentare grafic, entitatea este un dreptunghi care are nscris
deasupra numele entitii urmat eventual de un slash i un numr de etichet.
Entitatea este doar o definiie a datelor pe care utilizatorul le are la dispoziie.
Datele concrete sunt particularizri ale entitii i se numesc ocurene sau instane.
Atributul este o proprietate a unei entiti; altfel spus, proprietile unei entiti
se numesc atribute.
De exemplu, fie BD numit STUDENT prezentat la 2.1:
Numele: POPESCU
Prenumele: MARIA
Prenumele tatlui: ION
Prenumele mamei: OANA
Data naterii: 10.06.1980
Locul naterii: TIMIOARA
Domiciliul: TIMIOARA, STR. AUREL VLAICU NR. 7
Facultatea: CALCULATOARE
Anul de studiu: II
Numr matricol: 175
Atributele entitii sunt: Numele, Prenumele, Prenumele tatlui, Prenumele
mamei .a.m.d. Atunci cnd se face referire la o anumit ocuren, atributele au o
anumit valoare: atributul Numele are valoarea POPESCU, atributul Prenumele are
valoarea MARIA etc.
Atributele sunt reprezentate n interiorul dreptunghiului care identific entitatea
ca n Figura 2.4. Unele SGBD nu permit folosirea spaiului n numele unui atribut,
altele nu permit folosirea literelor specifice limbii romne. Vom pstra totui aceast
scriere pentru uurina exprimrii.
Exist o problem legat de numele atributelor i anume se presupune c
dou atribute cu acelai nume reprezint acelai atribut sau aceasta este o eroare de
inconsisten ori redundan. Dac totui cele dou atribute sunt diferite, atunci
numele lor trebuie modificat (explicitat) sau atributele trebuie s apar n entiti
diferite.


STUDENT / 35 STUDENT / 35
Numele
Prenumele
21
Prenumele tatlui
Prenumele mamei
Data naterii
Locul naterii
Domiciliul
Facultatea
Anul de studiu
Numr matricol

Figura 2.4. Reprezentarea unei entiti (st) cu atributele sale (dr)

O ocuren a unei entiti sau doar o parte a ei (un atribut sau mai multe)
poate avea o valoare particular numit nul sau valoare nul (null value) i notat
prin (0), valoare care nu este aceeai cu un zero sau un spaiu introdus voit n BD.
Valorile unui atribut pot fi parte a unui domeniu care determin mulimea
tuturor valorilor admisibile. Aceast mulime poate fi definit prin enumerare sau prin
limite de valori.
Unele atribute ale entitii ar putea fi folosite pentru a deosebi diferite
ocurenele i de aceea ele se numesc cheie candidat (uneori se folosete
prescurtarea cheie). Cheia candidat poate fi cheie simpl (elementar) dac este
format dintr-un singur atribut (de exemplu doar Numr Matricol) sau cheie
compus dac este format din mai multe atribute (de exemplu
Numele+Prenumele+Data naterii+Locul naterii).
Dac o BD are chei candidate, una dintre ele este selectat pentru a fi cheia
primar (cu observaiile c ea este unic (nerepetabil) i c nu poate lua valoarea
nul) i se simbolizeaz n dreptunghi separat printr-o linie de restul atributelor.
Celelalte chei candidate se numesc chei alternate i sunt notate separat de cheia
primar, cu sufixul (AKn) unde n este numrul cheii alternate (eng. alternate Key).

STUDENT / 35 STUDENT / 35
Numr matricol# Numr matricol#
Numele
Prenumele
Prenumele tatlui
Prenumele mamei
Data naterii
Locul naterii
Domiciliul
Facultatea
Anul de studiu
Numele (AK1, AK2)
Prenumele
(AK1,AK2)
Prenumele tatlui
Prenumele mamei
Data naterii (AK1)
Locul naterii (AK1)
Domiciliul (AK2)
Facultatea
Anul de studiu

Figura 2.5. Reprezentarea unei entiti (st) cu atributele sale (dr)

Relaiile sunt asociaii (funcii) ntre entiti i sunt simbolizate prin linii sau
arce ntre dreptunghiurile ce simbolizeaz entitile.
Relaiile ntre entiti pot fi relaii de conectare sau relaii de categorie.
Relaia de conectare asociaz entiti diferite ale BD i sunt caracterizate
printr-un verb care arat o aciune i o cardinalitate care arat cte din instanele
primei entiti sunt legate de cte instane ale celei de-a doua entiti. Pentru a
indica grafic faptul c o relaie este de conectare, linia utilizat se ncheie prin dou
puncte mari.
22
De exemplu, ntre entitatea STUDENT descris anterior i entitatea EXAMEN
(compus din atributele Numr Matricol, Data, Cod Disciplin, Forma Examen, Nota),
poate exista o relaie de conectare ca n Figura 2.6.


STUDENT STUDENT STUDENT STUDENT


are


EXAMEN
are P


EXAMEN
are 7


EXAMEN
are
5-10

EXAMEN



Figura 2.6. Relaii de conectare mai-muli-la-mai-muli, de cardinalitate pozitiv,
de cardinalitate exact i domeniu de cardinalitate


Cele patru tipuri de cardinalitate a relaiilor de conectare sunt:
mai-muli-la-mai-muli, cnd o instan din prima entitate este conectat la
mai multe instane din a doua entitate; se simbolizeaz doar prin verb;
cardinalitate pozitiv, cnd o instan din prima entitate este conectat la cel
puin o instan din a doua entitate; se simbolizeaz prin verb urmat de litera
P;
cardinalitate exact, cnd o instan din prima entitate este conectat la un
numr exact de instane din a doua entitate; se simbolizeaz prin verb urmat
de o valoare numeric;
domeniu de cardinalitate, cnd o instan din prima entitate este conectat
la un numr de instane din a doua entitate aflat ntre dou limite (una din
limite poate fi infinit); se simbolizeaz prin verb urmat de cele dou limite
sau verb urmat de un operator relaional i o valoare numeric.
De exemplu, ntre entitile STUDENT i EXAMEN ar putea exista cele patru
variante de relaii de conectare (figura I.6):
mai muli la mai muli, n care studentul are ntr-o anumit sesiune un numr
de examene;
cardinalitate pozitiv, n care studentul are cel puin un examen;
cardinalitate exact, n care studentul are un numr fix de examene adic 7;
domeniu, n care studentul are un numr de examene cuprins ntre 5 i 10.
Un caz particular de relaie de conectare este relaia zero-la-unu n care o
instan din prima entitate este conectat la o instan din a doua entitate sau nu
este conectat deloc. Acest tip de relaie se simbolizeaz prin caracterul Z.
De exemplu, n relaia dintre entitatea STUDENT i entitatea CMIN
coninnd repartiia pe camere a studenilor cminiti (cu atributele Facultate#,
Numr Matricol#, Camera, Pat) este o relaie zero-la-unu.
Probleme deosebite pune relaia mai-muli-la-mai-muli pe care tehnicile de
modelare trebuie s o rezolve (mpart, sparg) n mai multe relaii unu-la-mai-muli.
Cele mai des utilizate relaii sunt cele unu-la-mai-muli. La acestea, prima
entitate se mai numete entitate tat, n timp ce relaia a doua se mai numete
entitate fiu (entitate copil).
23
Un atribut al unei entiti care se gsete n cheia primar a unei alte entiti
se numete atribut cheie strin.
De exemplu, ntre entitile STUDENT i EXAMEN prezentate mai sus,
atributul Numr Matricol din STUDENT se gsete ca atribut cheie n entitatea
EXAMEN, care are cheia primar Numr Matricol+Cod disciplin+Data.
Cnd exist mai mult de o relaie ntre o pereche de entiti, atributelor cheie
strin li se asociaz nume de roluri pentru a permite diferenierea apariiilor
numelui de atibut.
De exemplu, dac la un examen se susine att partea scris i aplicativ, ct
i un proiect, deci n aceeai zi se nregistreaz dou note la aceeai disciplin,
atributul Numr Matricol (devenit atribut cheie strin n entitatea EXAMEN) trebuie
s primeasc nume diferite, cum ar fi Numr Matricol_examen i Numr
Matricol_proiect, altfel s-ar fi gsit dou ocurene i una dintre ele ar fi fost eliminat.
ntre entitile dintr-o relaie de conectare poate exista o dependen de
existen de forma: fiecare instan a entitii fiu trebuie s aib o instan
corespondent a entitii tat.
De exemplu, nu poate exista ocuren n EXAMEN care s nu aib
corespunztor o ocuren n STUDENT, deoarece nu poate exista o not la un
examen fr studentul care a primit acea not.
O alt dependen ce poate aprea la o relaie de conectare este dependena
de identificator de forma: entitatea fiu este dependent de identificator de entitatea
tat dac i numai dac cheia primar a entitii tat apare ca atribut cheie strin n
entittatea fiu i este complet coninut n cheia primar a entitii fiu.
De exemplu, ntre entitatea STUDENT (ca mai sus, inclusiv atributul Numr
Matricol#) i entitatea TAXE (cu atributele Cod Facultate#, Numr Matricol#, Data,
Suma) exist o dependen de identificator deoarece cheia primar a lui STUDENT
apare ca atribut cheie strin n TAXE i este complet coninut n cheia primar a lui
TAXE.
Ca i contraexemplu, ntre entitatea CMIN (cu atributele Facultate#, Numr
Matricol#, Camera, Pat) i entitatea TAXE (avnd de aceast dat atributele
Facultate, Numr Matricol#, Data, Suma) nu este o dependen de identificator
deoarece atributul Facultate nu este cheie primar n TAXE.
Relaiile de conectare cu dependen de existen sau de identificator trebuie
s respecte o restricie numit integritate referenial conform creia valorile
atributelor de cheie strin ntr-o instan a entitii fiu trebuie s fie egale cu
valoarea cheii primare din instana corespondent din entitatea tat. Cu alte cuvinte,
nu poate exista o valoare a cheii din entitatea fiu creia n entitatea tat s nu-i
corespund nici o instan.
De exemplu, integritatea referenial este satisfcut ntre entitile STUDENT i
EXAMEN atta vreme ct atributul Numr Matricol#, luat ca cheie n EXAMEN, ia
doar valori pentru care exist ocurene n STUDENT; cnd se introduce un numr
matricol al unui student nenregistrat n STUDENT, restricia este violat.
Relaiile de categorie sunt acelea care asociaz entiti similare i se indic
grafic aa cum se prezint n Figura 2.7. Diagrama unei relaii de categorie conine
alturi de linia ce reprezint relaia, un cerc i numele atributului care genereaz
dependena particular a instanei, atribut care se numete discriminator de subtip.
De exemplu, o instan a entitii STUDENT poate indica un student la o
facultate sau un student la un colegiu.

STUDENT


24




Facultate
Cod
facultate



Colegiu



Figura 2.7. Relaie de categorie

Dac relaiile de categorie au un singur discriminator de tip, atunci mulimea
relaiilor poart numele de clas de categorii. n exemplul indicat, clasa de categorie
are dou relaii.
Pot exista situaii n care exist mai muli discriminatori de tip i deci mai multe
clase de categorii.
De exemplu, entitatea STUDENT poate conine atributul Situaie Militar care
poate lua valorile INAPT, RECRUT, REZERVIST, ACTIV. n aceast situaie, relaile
se prezint ca n figura 2.8.

STUDENT




Cod facultate Situaie militar



Facultate Colegiu Inapt Recrut Rezervist
Activ





Figura 2.8. Entitate cu dou ierarhii de categorii


Un discriminator de subtip trebuie astfel conceput nct s nu permit
existena unei instane care apare n dou clase de categorii.
De exemplu, o instan STUDENT nu poate fi simultan n dou din situaiile
militare inapt, recrut, rezervist sau activ.
Dac pentru orice valoare valid a discriminatorului de subtip, exist un subtip
corespondent, atunci clasa de categorii respectiv se numete total.
O relaie de categorie este ntotdeauna dependent de existen. Dac se
reia definiia prezentat la relaiile de conectare, aceasta nseamn c pentru orice
instan a unui subtip trebuie s existe o instan asociat a entitii tat.
De exemplu, o ocuren care face referire la un student-rezervist nu poate
exista dac nu exist ocurena corespunztoare aceluiai student, deci o entitate
STUDENT.
O relaie de categorie poate s respecte complet dependena de
identificator, adic atributul cheie primar a entitii tat apare ca i atribut cheie
25
strin n entitatea fiu. n unele cazuri cheia primar poate fi doar parial coninut n
entitatea fiu i deci dependena nu este respectat.
De exemplu, ntre entitatea STUDENT (cu atributele Facultate#, Numr
Matricol#) i entitatea DIPLOMA (avnd atributele Numr Matricol#, Data, Tema
Lucrrii, Nota) nu este o dependen de identificator deoarece atributul Facultate nu
este cheie primar n DIPLOMA.
n fine, o relaie de categorie respect ntotdeauna restricia de integritate
referenial adic o ocuren de entitate subtip are ntotdeauna asociat o ocuren
a entitii tat pentru care valoarea cheii primare se potrivete cu valoarea atributului
cheie strin a subtipului.

26
C Ca ap pi it to ol lu ul l I II II I
M MO OD DE EL LU UL L R RE EL LA A I IO ON NA AL L D DE E
G GE ES ST TI IU UN NE E A A B BA AZ ZE EL LO OR R D DE E D DA AT TE E


3.1 MODELUL RELAIONAL


3.1.1 Prezentare general

Modelul relaional al BD a fost propus n 1970 de ctre E. F. Codd i se
bucur de urmtoarele avantaje:
simplitatea reprezentrii. Acest model poate fi uor modelat i implementat
deoarece vede datele ca i cnd ar fi aranjate n tabele, avnd drept coloane
atributele iar drept linii valorile acestor atribute;
independena reprezentrii. Acest model realizeaz o independen a
datelor deoarece desparte aplicaiile program de reprezentarea datelor i
astfel utilizatorii nu au legtur cu organizarea BD fizice;
rigoarea reprezentrii. Fiind bazat pe un model matematic foarte puternic,
sunt excluse problemele de redundan i inconsisten.
Modelul relaional se bazeaz pe urmtoarele ase componente structurale:
relaii, atribute, domenii, tuple, chei i reprezentri.
Relaiile sunt tabele care au nume i conin linii i coloane. Numrul de
coloane al tabelei se numete gradul relaiei (aritatea relaiei). Structura relaiei
(adic atributele sale sau capul de tabel) se mai numete intensiunea relaiei.
Valorile atributelor (adic datele coninute n tabel) alctuiesc extensiunea relaiei.
De exemplu, pentru pstrarea informaiilor despre studenii unei universiti se
poate construi relaia din Figura 3.1 care este o relaie 13-ar deoarece tabelul are
13 coloane.
Atributele unei relaii sunt caracterizate printr-un nume (de exemplu Numele,
Prenumele, Numr Matricol#). Semnificaia atributelor nu se modific dac se
modific ordinea atributelor n cadrul relaiei.



EVIDENA
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan Georg
e
Iulia 15.09.1
981
Lugoj Lugoj, str.
Grii nr.8
ap.19
tiine
Ec.
I 854 2 215 3
Marines
cu
Liana Lu-
cian
Eva 04.11.1
979
Timi-
oara
Timioara,
str.1 Iunie
nr.3
Cal-
cula-
toare
II 130 1 233 1
Ondea Vasile Mihai Aurica 25.10.1
977
Timi-
oara
Timioara,
Cl. agului
nr. 201
tijn-
e Ec.
II 602 2 141 2
Popes-
cu
Maria Ion Oana 10.06.1
980
Timi-
oara
Timioara,
str. A.Vlaicu
Cal-
cula-
II 175 1 233 2
27
nr.7 toare
Vasiu Bogdan Mirce
a
Floare 24.01.1
981
Reia Reia, str.
Grii nr.3
ap.5
Calcu
-
latoar
e
II 188

Figura 3.1. Relaia EVIDENA


Domeniile unei relaii determin tipul i eventual limitrile valorilor atributelor.
Tipurile sunt cele standard n reprezentarea datelor n calculator (numeric,
eventual cu diferenierile ntreg, real; caracter/ir de caractere; dat
calendaristic/or etc.). Mai multe atribute pot lua valori ale aceluiai domeniu (de
exemplu Numr Matricol i Camera sunt de tip ntreg) dar un atribut nu poate lua
valori din dou tipuri diferite (de exemplu nu poate fi simultan numeric i ir de
caractere).
Limitrile sunt condiii pe care valorile atributelor trebuie s le ndeplineasc
pentru a fi introduse n relaie. Exist multe tipuri de limitri, cum sunt condiia de
numericitate (informaia s fie numeric), de pozitivitate (sunt admise doar valori
pozitive), de incrementare (o valoare este admis numai dac este egal cu cea
anterioar incrementat cu 1, pentru acelai atribut) etc.
Tuplele sunt liniile dintr-o tabel, adic elementele unei relaii. Ele mai sunt
numite i nregistrri (eng. records).
Cheile unei relaii sunt atribute dup care tuplele se difereniaz clar ntre ele;
conform conceptelor generale de BD, exist chei candidate dintre care se alege o
cheie primar i chei alternate, cu semnificaiile ntlnite n capitolul I.
Reprezentrile sunt modalitile de a enumera componentele unei relaii. Cea
mai des utilizat reprezentare n BD relaionale descrie relaia prin numele su, urmat
(ntre paranteze) de numele atributelor, dintre care cheia primar se indic prin
subliniere.
De exemplu, relaia EVIDENA de mai sus are reprezentarea:

Evidena (Numele, Prenumele, Prenumele tatlui, Prenumele mamei, Data naterii,
Locul naterii. Domiciliul, Facultatea, Anul de studiu, Numr matricol#, Cminul,
Camera, Patul)

Orice relaie trebuie s satisfac dou aseriuni (constrngeri) relaionale:
aseriunea privind cheia primar: nici o component a valorii de cheie
primar nu poate fi nul. Aceasta rezult din definiia cheii primare (capitolul I)
care spune c aceasta trebuie s identifice n mod unic instana entitii; dac
ea este nul, instana nu poate fi identificat unic;
aseriunea privind atributul de cheie strin: valoarea unui atribut de cheie
strin trebuie s fie nul sau egal cu valoarea cheii primare a unui anumit
tuplu din relaia tat. Aceasta rezult din definiia atributului de cheie strin i
din restricia de integritate referenial; dac atributul cheie strin nu are
echivalent n instana tat atunci aceasta nu poate fi identificat.




3.1.2 Regulile lui Codd
28

Avantajele foarte mari pe care modelul relaional de BD le ofer sunt datorate
faptului c acesta are o fundamentare matematic riguroas, datele au o structur
relativ simpl i o independen mare fa de implementarea fizic iar redundana
este minim.
Pentru a respecta modelul relaional, un SGBD trebuie s respecte un set de
13 reguli, propuse de Codd n 1985. Totui, o privire mai realist a problemei arat
c nu se pune problema neaprat dac SGBD este sau nu relaional, ci doar msura
n care el este relaional adic respect toate aceste 13 reguli.
Regulile indicate sunt [POP96]:
Regula 1 gestionarea datelor: un SGBD este relaional dac poate gestiona orice
BD prin posibiliti relaionale.
Regula 2 reprezentarea informaiei: un SGBD este relaional dac poate
organiza orice BD sub form de tabele (relaii).
Regula 3 accesul garantat la date: un SGBD este relaional dac orice informaie
din BD poate fi regsit prin expresia numele relaiei+numele atributului+valoarea
cheii primare.
Regula 4 reprezentarea informaiei necunoscute: un SGBD este relaional dac
permite definirea i utilizarea valorii nul pentru informaiile care nc nu sunt
cunoscute.
Regula 5 - dicionarele de date: un SGBD este relaional dac asupra descrierii BD
se pot efectua aceleai operaii ca asupra datelor din BD (adic i descrierea BD
este tot un tabel).
Regula 6 limbajul de interogare: un SGBD este relaional dac el conine cel
puin un LMD.
Regula 7 actualizarea vizualizrii: un SGBD este relaional dac poate determina
condiile n care o vizualizare poate fi actualizat.
Regula 8 limbajul de nivel nalt: un SGBD este relaional dac nu oblig
utilizatorul s caute informaia dorit, ntr-o relaie, linie cu linie.
Regula 9 independena fizic a datelor: un SGBD este relaional dac
programele utilizatorilor nu depind de modul de memorare sau de acces la date.
Regula 10 independena logic a datelor: un SGBD este relaional dac
programele utilizatorlor sunt transparente la modificrile efectuate asupra datelor.
Regula 11 independena datelor din punct de vedere al integritii: un SGBD
este relaional dac regulile de integritate sunt definite prin limbajul SGBD nu prin
aplicaiile utilizatorului.
Regula 12 - independena datelor din punct de vedere al distribuirii: un SGBD
este relaional dac faptul c datele sunt distribuite n reea este transparent
aplicaiilor utilizatorului.
Regula 13 versiunea procedural a SGBD: un SGBD este relaional dac orice
component procedural a SGBD respect aceleai restricii de integritate ca i
componenta relaional.
Cum aceste reguli sunt foarte stricte, se pot utiliza criterii mai reduse care s
indice gradul n care un SGBD este relaional.






3.1.3 Normalizarea relaiilor

29
Normalizarea este procesul reversibil prin care o relaie este transformat
ntr-o relaie cu structur mai simpl [POP96].
Normalizarea trebuie s asigure ndeplinirea urmtoarelor cerine:
conservarea datelor - relaia final s nu piard din datele iniiale;
conservarea dependenelor relaia final s nu piard din dependenele
iniiale;
s fie o descompunere minimal - relaia final s nu fie coninut ntr-o alt
relaie.
Normalizarea trebuie efectuat atunci cnd relaiile utilizate posed unul dintre
urmtoarele dezavantaje, numite de ctre Codd anomalii de actualizare [NAS00]:
anomalia de tergere, care se manifest cnd datele care trebuie terse fac
parte din tuple care conin i alte informaii iar tergerea lor ar duce la
pierderea acestor informaii;
anomalia de adugare, care se manifest cnd datele care trebuie adugate
fac parte din tuple care conin i informaii care nc nu sunt cunoscute;
anomalia de modificare, care se manifest cnd datele care trebuie
modificate apar n foarte multe tuple.
n funcie de dependenele care trebuie rezolvate n cadrul relaiilor, prin
procesul de normalizare, relaiile pot fi considerate n mai multe forme normale,
incluse unele n celelalte ca n Figura 3.2.






FN1




FN2



FN3


FNBC

FN4
FN5





Relaie general
Figura 3.2: Nivelele formelor normale

Prima form normal (FN1, eng. First Normal Form 1NF)
O relaie este considerat ca fiind de prima form dac:
fiecare atribut conine numai valori indivizibile (atomice);
fiecare tuplu nu conine atribute sau grupe de atribute repetitive.
O relaie care nu este n FN1 se poate aduce n aceast form prin:
Pasul 1. nlocuirea atributului compus cu mai multe atribute simple (de exemplu,
atributul Domiciliu se poate nlocui cu atributele DLocalitate, DStrada, DNumr,
DBloc, DScara, DApartament);
Pasul 2. plasarea fiecrui atribut repetitiv ntr-o nou relaie (de exemplu, dac
atributele Numele i Prenumele se repet pentru a fi alturi de cmpurile de note, de
cmpurile de taxe, de cmpurile de cri mprumutate, pentru a putea realiza trei
vederi utilizator diferite ce corespund necesitilor studentului-de a vedea notele,
contabilitii-de a vedea taxele, bibliotecii-de a vedea circulaia crilor, atunci se
construiesc trei tabele distincte);
Pasul 3. introducerea n schema fiecrei relaii construit ca mai sus a cheii primare
a relaiei de unde s-a extras atributul respectiv (de exemplu, Numele i Prenumele
trebuie s se regseasc n cele trei noi relaii construite ca mai sus);
Pasul 4. stabilirea cheii primare a fiecrei relaii construit ca mai sus s includ
cheia primar a relaiei iniiale i alte atribute necesare.
De exemplu, o relaie aflat n FN1 care memoreaz cadrele didactice i
cursurile la care acestea predau, cu numele NCADRARE, poate fi ca n figura II.3.
30

INCADRARE
C
o
d
#

D
e
n
u
m
i
r
e

T
i
p

c
u
r
s

C
o
d
C
D
1
#

N
u
m
e
C
D
1

G
r
a
d
C
D
1

S
a
l
a
r
C
D
1

C
o
d
C
D
2
#

N
u
m
e
C
D
2

G
r
a
d
C
D
2

S
a
l
a
r
C
D
2

101 Algebr Obl 2018 Marinescu
V.
Prof. 200 2018 Marinescu
V.
Prof. 100
102 Arhitectur Obl 2315 Ionescu Gh. Prof. 200 2378 Popescu M. As. 25
103 Birotic Obl 2375 Georgescu
I.
Lect. 100 2375 Georgescu
I.
Lect. 50
104 Logic Op 2018 Marinescu
V.
Prof. 150 2270 Iliescu A. Prep 15
105 Structuri Obl 2974 Nstase Al. Conf 150 2378 Popescu M. As. 25

Figura 3.3. Relaie aflat n FN1

Se observ c aceast relaie nu conine atribute compuse (exceptnd poate
numele i prenumele cadrelor didactice, dar descompunerea n atribute de gen
Nume respectiv Prenume nu ar avea nici un rost) i nici atribute care se repet.

CURSURI TITULARI
C
o
d
#

D
e
n
u
m
i
r
e

T
i
p

c
u
r
s

C
o
d
C
D
1
#

S
a
l
a
r
C
D
1

C
o
d
C
D
2
#

S
a
l
a
r
C
D
2


C
o
d
C
D
#

N
u
m
e
C
D

G
r
a
d
C
D

101 Algebr Obl 2018 200 2018 100 2018 Marinescu V. Prof.
102 Arhitectur Obl 2315 200 2378 25 2270 Iliescu A. Prep
103 Birotic Obl 2375 100 2375 50 2315 Ionescu Gh. Prof.
104 Logic Op 2018 150 2270 15 2375 Georgescu I Lect.
105 Structuri Obl 2974 150 2378 25 2378 Popescu M. As.
2974 Nstase Al. Conf

Figura 3.4. Relaia din Figura 3.3 adus n FN2

A doua form normal (FN2, eng. Second Normal Form 2NF)
O relaie este considerat ca fiind de a doua form normal dac:
este n FN1;
orice atribut care nu intr n compunerea cheii primare, depinde de ntreaga
cheie primar.
O relaie care nu este n FN2 se poate aduce n aceast form prin
descompunerea relaiei n mai multe relaii pentru a elimina redundanele.
De exemplu, relaia din Figura 3.3 nu este n FN2 deoarece conine
redundane; aducerea ei n FN2 se face construind dou relaii, una care conine
date despre cursuri i alte despre cadrele didactice, ca n figura II.4.


A treia form normal (FN3, eng. Third Normal Form 3NF)
O relaie este considerat ca fiind de a treia form normal dac:
31
este n FN2;
orice atribut care nu intr n compunerea cheii primare, depinde direct de
cheia primar.
O relaie care nu este n FN3 se poate aduce n aceast form prin
descompunerea relaiei n mai multe relaii pentru a elimina dependenele funcionale
tranzitive, adic prin construirea unei relaii n care se regsesc atributele care
depind indirect de alte atribute.

SALARIZARE1 SALARIZARE2
C
o
d

c
u
r
s
#

G
r
a
d
C
D
1
#

S
a
l
a
r
C
D
1


C
o
d

c
u
r
s
#

G
r
a
d
C
D
2
#

S
a
l
a
r
C
D
2

101 2018 200 101 2018 100
102 2315 200 102 2315 25
103 2375 100 103 2375 50
104 2018 150 104 2018 15
105 2974 150l 105 2974 25

Figura 3.5. Relaia din Figura 3.3 adus n FN3

De exemplu, n Figura 3.4 se observ c apar mai multe tuple n care
CodCD1# este egal cu 2018 (prima i a patra) dar pentru care valoarea atributului
SalarCD1 este diferit (200 n primul caz i 150 n al doilea). Problema apare
deoarece cursurile respective sunt obligatorii respectiv opionale i deci valoarea
cmpului SalarCD1 depinde de Tip Curs (care depinde de Cod#) i GradCD1 (care
depinde de CodCD1#). Se poate atunci trece relaia CURSURI din forma FN2 n FN3
prin descompunerea relaiei ca n Figura 3.5.

Forma normal Boyce-Codd (FNBC, eng. Boyce-Codd Normal Form
BCNF)
O relaie este considerat ca fiind de forma normal Boyce-Codd dac:
este n FN3;
orice atribut care nu intr n compunerea cheii primare, depinde direct i total
de cheia primar.
O relaie care nu este n FNBC se poate aduce n aceast form prin
descompunerea relaiei n mai multe relaii pentru a elimina atributele care depind de
atribute non-cheie, adic prin construirea unei relaii n care se regsesc atributele
care depind indirect de alte atribute care nu sunt cheie.
De exemplu, n Figura 3.4 se observ c apar mai multe tuple n care Tip curs
este egal cu Obl i SalarCD1 este egal cu 200, dei CodCD1# are valori diferite
(2018 respectiv 2315). Situaia se datoreaz faptului c cele dou valori pentru
CodCD1 corespund la dou ocurene similare din TITULARI, n sensul c ambele
aparin unor cadre didactice cu grad de Profesor. Rezolvarea acestei probleme i
trecerea n FNBC se face ca n Figura 3.6.


A patra form normal (FN4, eng. 4th Normal Form 4NF)
O relaie este considerat ca fiind de a patra form normal dac:
32
este n FNBC;
nu conine relaii m:n independente.
O relaie care nu este n FN4 se poate aduce n aceast form prin
descompunerea relaiei n mai multe relaii care conin fiecare atributul cheie i cte
un atribut din cele care depind direct de cheia respectiv.

ASOCIERE11 ASOCIERE12
C
o
d

c
u
r
s
#

G
r
a
d
C
D
1
#

T
i
p

c
u
r
s


T
i
p

c
u
r
s
#

G
r
a
d
C
D
1
#

S
a
l
a
r
C
D
1

101 2018 Obl Obl Prof. 200
102 2315 Obl Obl Conf 150
103 2375 Obl Obl Lect. 100
104 2018 Op Obl As. 50
105 2974 Obl Obl Prep null
Figura II.6: Relaia din figura II.3 adus n FNBC

LIMBAJE => LIMBAJE1 LIMBAJE2
C
o
d
C
D
2
#

L
i
m
b
a
j

C
o
d

c
u
r
s


C
o
d
C
D
2
#

L
i
m
b
a
j


C
o
d
C
D
2
#

C
o
d

c
u
r
s

2375 Word 103 2375 Word 2375 103
2375 Pascal 104 2375 Pascal 2378 105
2375 Pascal 105 3771 Pascal
3771 Pascal 105 2378 C
3771 Pascal 104
2378 C 105

Figura 3.7: Figura 3.8:
Relaie redundant Relaia din Figura 3.7 adus n FN4

De exemplu, n Figura 3.7 se observ c apar mai multe tuple n care valorile
lui CodCD2# i Limbaj se repet; eliminarea redundanei se face prin desfacerea
relaiei n alte dou relaii, n care CodCD2 apare alturi de fiecare din celelalte
atribute care iniial ddeau problema de relaie dependent.

A cincea form normal (FN5, eng. 5th Normal Form 5NF)
O relaie de tip FN5 este foarte rar ntlnit n practic, ea are mai mult un
aspect teoretic; relaia este considerat ca fiind de a cincea form normal dac:
este n FN4;
nu conine dependene ciclice.
O relaie care nu este n FN5 se poate aduce n aceast form prin eliminarea
dependenelor ciclice astfel: dac dependena ciclic este ntre perechile de mulimi
(A, B), (B, C) i (A, C), se creaz relaiile:
R
1
(A:Domeniu
A
, B:Domeniu
B
),
R
2
(B:Domeniu
B
, C:Domeniu
C
),
33
R
3
(A:Domeniu
A
, C:Domeniu
C
)
i astfel valorile luate de cheile care forau dependena ciclic sunt eliminate.


3.1.4 Operaii i operatori

Asupra relaiilor pot fi aplicate operaii de tip relaional care au ca rezultat tot
relaii. Cei trei operatori relaionali de baz sunt PROJECT, SELECT i JOIN.
Operatorul PROJECT (proiecie) formeaz o nou relaie prin extragerea
(proiectarea) unor atribute dintr-o relaie existent. Dac se noteaz relaiile cu R
1
i
R
2
iar atributele cu A
1
, A
2
, ..., A
n
atunci formula de definire este:

R
2
:= PROJECT (R
1
) (A
1
, A
2
, ...)
sau
R
2
:= PROJECT A
1
, A
2
, ... FROM R
1

De exemplu, dac se dorete obinerea unei evidene a repartizrii studenilor
cminiti pe faculti i ani de studiu, atunci se pleac de la relaia EVIDENA (figura
II.1) i se efectueaz operaia de extragere de forma:
REPARTIIE := PROJECT (EVIDENA) (Facultatea, Anul de studiu, Cminul)
sau
REPARTIIE := PROJECT Facultatea, An de studiu, Cminul FROM EVIDENA

REPARTIIE
Facultatea Anul de studiu Cminul
tiine Ec. I 2
Calculatoare II 1
tijne Ec. II 2
Calculatoare II 1

Figura 3.9. Rezultatul operaiei PROJECT (faza I)

REPARTIIE
Facultatea Anul de studiu Cminul
tiine Ec. I 2
Calculatoare II 1
tijne Ec. II 2

Figura 3.10. Rezultatul operaiei PROJECT (faza II)


care se efectueaz n dou etape: n prima etap se extrag toate tuplele (figura II.9)
apoi se elimin tuplele duplicate (Figura 3.10).
Operatorul SELECT (el se mai noteaz uneori RESTRICT) (selecia)
formeaz o nou relaie prin extragerea (proiectarea) dintr-o relaie existent numai a
liniilor care satisfac anumite criterii (condiii). Formula de definire este:

R
2
:= SELECT (R
1
) (A
1
, A
2
, ...) (condiie)
sau
R
2
:= SELECT A
1
, A
2
, ... FROM R
1
WHERE condiie
CMINITI
34
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan George Iulia 15.09.
1981
Lugoj Lugoj, str.
Grii nr. 8
ap.19
tiin-
e Ec.
I 854 2 215 3
Marinesc
u
Liana Lucian Eva 04.11.
1979
Timi-
oara
Timioara,
str.1 Iunie
nr.3
Calcu-
lato-
are
II 130 1 233 1
Ondea Vasile Mihai Aurica 25.10.
1977
Timi-
oara
Timioara,
Cl. agului
nr. 201
tijn-
e Ec.
II 602 2 141 2
Popescu Maria Ion Oana 10.06.
1980
Timi-
oara
Timioara,
str.
A.Vlaicu
nr.7
Calcu-
lato-
are
II 175 1 233 2

Figura 3.11. Rezultatul operaiei SELECT

De exemplu, dac se dorete obinerea unei evidene a studenilor cminiti,
plecnd de la relaia EVIDENA (figura II.1), operaia de extragere poate fi de forma:
CMINITI := SELECT (EVIDENA) (Cminul <> null)
sau
CMINITI := SELECT Numele, Prenumele, Prenumele tatlui,
Prenumele mamei, Data naterii, Locul naterii,
Domiciliul, Facultatea, Anul de studiu, Numr matricol,
Cminul, Camera, Patul
FROM EVIDENA
WHERE Cminul <> null
i rezultatul este ca n Figura 3.11.
Observaie: chiar dac din exemplul indicat nu a rezultat astfel, i operaia SELECT
elimin tuplele duplicate din noua relaie.

Operatorul JOIN (compunere) formeaz o nou relaie prin extragerea
(proiectarea) din dou relaii existente a liniilor care satisfac anumite criterii (condiii).
Formula de definire este:

R
3
:= JOIN (R
1
) (condiie) (R
2
)

De exemplu, dac se dorete obinerea unei evidene a studenilor la
facultile acreditate i care pot da licena n cadrul universitii, folosind relaiile
EVIDENA (figura II.1) i ACREDITARE (figura II.12), atunci operaia de extragere
poate fi de forma:
LICEN PROPRIE := JOIN (EVIDENA) (Facultatea = Denumirea) (ACREDITARE)





ACREDITARE
35
Denumirea Numr act legal Data act legal
tiine Ec. 154 2002
Drept 287 2002

Figura 3.12. Relaia ACREDITARE

i rezultatul obinut este ca n Figura 3.13:

LICEN PROPRIE
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

N
u
m

r

a
c
t

l
e
g
a
l

D
a
t
a

a
c
t

l
e
g
a
l

Costin Ioan Geor-
ge
Iulia 15.09
.1981
Lugoj Lugoj,
str. Grii
nr.8
ap.19
tiine
Ec.
I 854 2 215 3 15
4
2002
On-
dea
Vasile Mihai Aurica 25.10
.1977
Timi-
oara
Timioar
a, Cl.
agului
nr. 201
tijne
Ec.
II 602 2 141 2 15
4
2002

Figura 3.13. Rezultatul operaiei JOIN

unde se observ c noua relaie are gradul 15 (ea a preluat atributele de la ambele
relaii din care s-a format).

Pe lng cei trei operatori prezentai anterior, literatura de specialitate
[POP96] mai ofer posibilitatea de a utiliza urmtoarele aciuni:

Operatorul UNION (reuniune) formeaz o nou relaie prin proiectarea din
dou relaii existente a unei reuniuni a liniilor care satisfac anumite criterii (condiii) i
care pot aparine fie primei relaii, fie celei de-a doua, fie ambelor. Formula de
definire este:

R
3
:= (R
1
) (condiie
1
) UNION (R
2
) (condiie
2
)
sau
R
3
:= SELECT A
1
, A
2
, ... FROM R
1
WHERE condiie
1

UNION
SELECT B, B, ... FROM R WHERE condiie
2

De exemplu, dac se dorete obinerea unei evidene a studenilor i cadrelor
didactice de la aceeai facultate, se folosete operaia de reunire:
R
3
:= SELECT Numele, Prenumele
FROM EVIDENA
WHERE Facultatea = Calculatoare
UNION
SELECT Numele, Prenumele
FROM PROFESORI
WHERE Facultatea = Calculatoare
unde am considerat relaia PROFESORI (Figura 3.15) ca avnd aceeai structur ca
i relaia EVIDENA (Figura 3.14). Rezultatul obinut este o relaie ca n figura II.16.
36
Observaie: relaiile care intervin n operaia UNION trebuie s aib aceeai aritate i
aceeai ordine (nu numele) a atributelor.

EVIDENA (extras) PROFESORI (extras)
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

F
a
c
u
l
t
a
t
e
a


N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

F
a
c
u
l
t
a
t
e
a

Costin Ioan George tiine
Ec.
Anton Ileana Marian Calcula
-toare
Marines
cu
Liana Lucian Calcu-
latoare
Achim Silvia Lica Calcu-
latoare
Ondea Vasile Mihai tijne
Ec.
Manea Mihai vasile Psiho-
logie
Popescu Maria Ion Calcu-
latoare
Popesc
u
Maria Ion Calcu-
latoare
Vasiu Bogda
n
Mircea Calcu-
latoare
George Andrei Mihai Drept
Figura 3.14. Relaia EVIDENA Figura 3.15. Relaia EVIDENA

N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

F
a
c
u
l
t
a
t
e
a

Marinescu Liana Lucian Calcu-latoare
Popescu Maria Ion Calcu-latoare
Vasiu Bogdan Mircea Calcu-latoare
Anton Ileana Marian Calcula-toare
Achim Silvia Lica Calcu-latoare

Figura 3.16. Relaia R3 la operatorul UNION

Operatorul DIFFERENCE (diferen) formeaz o nou relaie prin
proiectarea din dou relaii existente a liniilor care aparin primei relaii dar nu aparin
celei de-a doua. Formula de definire este:

R
3
:= (R
1
) DIFFERENCE (R
2
)
sau
R
3
:= DIFFERENCE (R
1
, R
2
)

De exemplu, dac se dorete obinerea unei evidene a studenilor care nu
sunt cminiti, plecnd de la relaiile EVIDENA (Figura 3.1) i CMINITI (Figura
3.11), se folosete operaia de diferen:
NECMINITI := DIFFERENCE (EVIDENA, CMINITI)
i se obine relaia din Figura 3.17.


NECMINITI
37
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Vasiu Bogdan Mircea Floare 24.01
.1981
Rei
a
Reia,
str.
Grii
nr.3
ap.5
Calcu-
latoare
II 188

Figura 3.17. Relaia NECMINITI

Observaie: relaiile care intervin n operaia DIFFERENCE trebuie s aib aceeai
aritate i aceeai ordine a atributelor; numele atributelor nu este important pentru
operator.

Operatorul INTERSECT (intersecie) formeaz o nou relaie prin
proiectarea din dou relaii existente a liniilor care aparin ambelor relaii. Formula de
definire este:

R
3
:= (R
1
) INTERSECT (R
2
)
sau
R
3
:= SELECT A
1
, A
2
, ... FROM R
1
WHERE condiie
1

INTERSECT
SELECT B, B, ... FROM R WHERE condiie
2


De exemplu, dac se dorete obinerea unei evidene a studenilor (figura
II.14) care sunt n acelai timp i cadre didactice (Figura 3.15), se folosete operaia
de intersecie:
R
4
:= SELECT Numele, Prenumele
FROM EVIDENA
INTERSECT
SELECT Numele, Prenumele
FROM PROFESORI

iar rezultatul este ca n Figura 3.18.
Observaie: relaiile care intervin n operaia INTERSECT trebuie s aib aceeai
aritate i aceeai ordine a atributelor; numele atributelor nu este important.


N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

F
a
c
u
l
t
a
t
e
a

Popescu Maria Ion Calculatoare

Figura 3.18. Relaia R4 la operatorul INTERSECT

38
Operatorul DIVISION (diviziune) formeaz o nou relaie prin proiectarea din
dou relaii existente a liniilor pentru care valorile atributelor din prima relaie apar n
valorile atributelor celeilalte relaii. Formula de definire este:

R
3
:= (R
1
) DIVISION (R
2
)
sau
R
3
:= DIVISION (R
1
, R
2
)

De exemplu, dac se dorete obinerea unei evidene a studenilor care
parcurg dou cursuri de limbi strine, se folosete operaia de diviziune:

NSCRIERI CURSURI
Numele Prenumele
Numr
matricol
Cod
curs

Cod
curs
Denumire curs
Ionescu Maria 1223 107 107 Engleza
Ionescu Maria 1223 108 108 Germana
Popescu Gheorghe 1245 107
Popescu Gheorghe 1245 108
Vasile Ana 1287 108

Figura 3.19. Operaia DIVISION

DIVISION (NSCRIERE, CURSURI)

care va avea ca rezultat studenii avnd valorile cmpurilor Numele i Prenumele:
Ionescu, Maria respectiv Popescu, Gheorghe.

Operatorul PRODUCT (produs cartezian) formeaz o nou relaie prin
proiectarea din dou relaii existente a liniilor pentru care primele m componente
aparin primei relaii iar celelalte n componente aparin celeilalte relaii, unde m
respectiv n sunt aritile relaiilor. Formula de definire este:

R
3
:= (R
1
) PRODUCT (R
2
)
sau
R
3
:= PRODUCT (R
1
, R
2
)

De exemplu, considernd relaiile EVIDENA i ACREDITARE ca n
exemplele anterioare (figurile II.1 i II.12), o nou relaie se poate scrie prin produsul
lor cartezian:
PRODUCT (EVIDENA, ACREDITARE)
care ar fi un tabel cu 16 coloane (13 de la EVIDENA i 3 din ACREDITARE)
compus prin alturarea celor dou tabele iniiale.


3.1.5 Proiectarea logic

Pentru definirea schemei pentru o BD relaional se utilizeaz un LDD; dac
se utilizeaz (de exemplu) limbajul SQL atunci operaiile de definire a structurii BD
apeleaz la instruciunile CREATE TABLE, EXPAND TABLE i DROP TABLE.

39
Instruciunea CREATE TABLE definete o relaie prin indicarea, pentru
fiecare atribut, a numelui, tipului datei i domeniului, adic:

CREATE TABLE nume_tabel
(A
1
tip
1
(domeniu
1
) [restricie
1
],
A
2
tip
2
(domeniu
2
) [restricie
2
],
.....
A
n
tip
n
(domeniu
n
) [restricie
n
]);

De exemplu, definirea relaiei EVIDENA prezentat anterior se face prin
instruciunea:
CREATE TABLE Evidena
(Numele varchar(20) not null,
Prenumele varchar(20) not null,
Prenumele tatlui varchar(20),
Prenumele mamei varchar(20),
Data naterii date,
Locul naterii varchar(20),
Domiciliul varchar(40),
Facultatea varchar(20) not null,
Anul de studiu number(1),
Numr matricol# number(3) not null primary key,
Cminul number(3),
Camera number(3),
Patul number(3));

Instruciunea EXPAND TABLE (sau ALTER TABLE) adaug la o relaie
existent un nou atribut, prin indicarea numelui, tipului datei i domeniului, adic:

EXPAND TABLE nume_tabel
ADD COLUMN A
n+1
tip
n+1
(domeniu
n+1
) [restricie
n+1
];
sau
ALTER TABLE nume_tabel
ADD COLUMN A
n+1
tip
n+1
(domeniu
n+1
) [restricie
n+1
];

De exemplu, adugarea la relaia EVIDENA prezentat anterior a atributului
Stare Civil se face prin instruciunea:
ALTER TABLE Evidena ADD COLUMN Stare civil char;


Instruciunea DROP TABLE elimin o relaie existent:

DROP TABLE nume_tabel;

Pentru definirea unei vederi a relaiei se utilizeaz instruciunea DEFINE VIEW
(sau CREATE VIEW) cu sintaxa:

DEFINE VIEW AS SELECT A
1
, A
2
, ... FROM relaie [WHERE condiie];
sau
CREATE VIEW AS SELECT A
1
, A
2
, ... FROM relaie [WHERE condiie];

40
De exemplu, pentru a obine situaia studenilor la facultatea de calculatoare
se poate defini vederea:
CREATE VIEW AS SELECT Numele, Prenumele, Anul de studiu
FROM Evidena
WHERE Facultatea = Calculatoare;

Pentru a defini o aseriune despre o cheie a unei relaii se utilizeaz
instruciunea ASSERT cu sintaxa:
ASSERT nume_aseriune ON relaie: atribut condiie,

De exemplu, dac universitatea are trei cmine, se poate defini aseriunea
(care aici este o definire a domeniului):
ASSERT X1 ON Evidena: Cminul BETWEEN 1 AND 3;

Maparea dintr-un model de date logice pe un model relaional este direct
deoarece SGBD relaionale permit efectuarea acestei operaii, cu respectarea
urmtoarelor reguli [DES99]:
entitate este reprezentat de o relaie;
un atribut al unei entiti este reprezentat de un atribut al relaiei;
relaie de conectare este reprezentat prin prezena unui atribut de cheie
strin n relaia fiu.
De exemplu, relaia EVIDENA poate fi mapat astfel:
Faculti (Cod facultate#, Denumire facultate)
Studeni (Numele, Prenumele, Prenumele tatlui, Prenumele mamei, Data naterii,
Locul naterii, Domiciliul, Cod facultate#, Anul de studiu, Numr matricol#)
Cmine (Cminul#, Camera#, Patul#, Cod facultate#, Numr matricol#)

relaiile de conectare ntre atribute sunt:

Este student (Cod facultate#, Denumire facultate, Numr matricol#)

n timp ce relaiile de categorie (mai greu de implementat n modelul relaional) sunt:

St n cmin (Cminul#, Camera#, Patul#, Cod facultate#, Denumire facultate,
Numr matricol#)
St n afar (Domiciliul#, Cod facultate#, Denumire facultate, Numr matricol#)

Modelul relaional respect dependena de identificator dar nu foreaz
restricia de integritate referenial.
3.1.6 Proiectarea fizic


Pentru ca o BD relaional s poat fi implementat fizic, ea trebuie s fie:
translatabil n tabele. Aceasta nseamn s permit utilizarea anumitor
structuri de date pentru fiecare relaie. Cea mai simpl structur este de tip
tabel (tablou) dar pot fi folosite i listele nlnuite, arborii etc., cu condiia ca
indiferent de structura folosit, ea s fie transparent pentru utilizator;
accesibil dup orice atribut. Aceasta nseamn ca utilizatorul s poat cere
acces la orice instan specificnd valoarea oricrui atribut al relaiei, nu
numai dup cheia relaiei;
41
s suporte operatori relaionali. Aceasta nseamn ca structura de date s
suporte operaiile SELECT, PROJECT i JOIN fr ca utilizatorul s utilizeze
explicit operaii de adresare, pointeri sau adrese.
Maparea unei relaii logice ntr-o relaie fizic se poate face prin urmtoarele
operaii:
partiionarea vertical a unei tabele n mai multe relaii de baz, fiecare
coninnd o parte a atributelor iniiale;
partiionarea orizontal a unei tabele n mai multe relaii de baz, fiecare
coninnd o parte a tuplelor iniiale;
reunirea mai multor tabele ntr-o singur relaie de baz.
Partiionarea vertical presupune proiectarea atributelor unei relaii n mai
multe relaii, fiecare dintre acestea coninnd cheia primar pentru a permite
reconstituirea tabelei originale. Operaia se execut atunci cnd tabela are foarte
multe coloane, cnd pri diferite ale aceleiai BD sunt exploatate n locuri de munc
diferite ale aceleiai organizaii, cnd unele coloane sunt actualizate foarte des fa
de altele sau cnd utilizatori cu diferite permisiuni de acces ar trebui s foloseasc
ntreaga BD.
De exemplu, relaia EVIDENA de mai sus poate fi partiionat vertical n
dou relaii, un SECRETARIAT i una ADMINISTRAIE, prima coninnd informaiile
generale despre studeni iar cea de-a doua doar informaiile despre studenii cazai la
cmin (figura 3.20).
Operaia se bazeaz pe instruciunea PROJECT:
Secretariat := PROJECT (Evidena) (Numele; Prenumele; Prenumele tatlui;
Prenumele mamei; Data naterii; Locul naterii; Domiciliul; Facultatea#; Anul de
studiu; Numr matricol#);
EVIDENA

EVIDENA
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan George Iulia 15.09.
1981
Lugoj Lugoj, str.
Grii nr.8
ap.19
tiine
Ec.
I 854 2 215 3
Marinesc
u
Liana Lucian Eva 04.11.
1979
Timi-
oara
Timioara
str.1 Iunie
nr.3
Calcu-
latoare
II 130 1 233 1
Ondea Vasile Mihai Aurica 25.10.
1977
Timi-
oara
Timioara
Cl.
agului
nr. 201
tijne
Ec.
II 602 2 141 2
Popescu Maria Ion Oana 10.06.
1980
Timi-
oara
Timioara
str.
A.Vlaicu
nr.7
Calcu-
latoare
II 175 1 233 2
Vasiu Bogdan Mircea Floare 24.01.
1981
Reia Reia,
str. Grii
nr.3 ap.5
Calcu-
latoare
II 188


42
SECRETARIAT
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

Costin Ioan George Iulia 15.09.
1981
Lugoj Lugoj, str.
Grii nr.8
ap.19
tiine
Ec.
I 854
Marinescu Liana Lucian Eva 04.11.
1979
Timi-
oara
Timioara,
str.1 Iunie
nr.3
Calcu-
latoare
II 130
Ondea Vasile Mihai Aurica 25.10.
1977
Timi-
oara
Timioara,
Cl. agului
nr. 201
tijne
Ec.
II 602
Popescu Maria Ion Oana 10.06.
1980
Timi-
oara
Timioara,
str.
A.Vlaicu
nr.7
Calcu-
latoare
II 175
Vasiu Bogdan Mircea Floare 24.01.
1981
Reia Reia, str.
Grii nr.3
ap.5
Calcu-
latoare
II 188

ADMINISTRAIE

Facultatea
Numr
matricol#
Cminul Camera Patul
tiine Ec. 854 2 215 3
Calculatoare 130 1 233 1
tijne Ec. 602 2 141 2
Calculatoare 175 1 233 2

Figura 3.20. Partiionarea vertical

Administraie := PROJECT (Evidena) (Facultatea#; Numr matricol#; Cminul;
Camera; Patul);


N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan George Iulia 15.09
1981
Lugoj Lugoj,
str. Grii
nr.8
ap.19
tiine
Ec.
I 854 2 215 3
Marines
cu
Liana Lucian Eva 04.11
1979
Timi-
oara
Timioar
a, str.1
Iunie
nr.3
Calcu-
latoare
II 130 1 233 1
43
Ondea Vasile Mihai Aurica 25.10
1977
Timi-
oara
Timioar
a, Cl.
agului
nr. 201
tijne
Ec.
II 602 2 141 2
Popescu Maria Ion Oana 10.06
1980
Timi-
oara
Timioar
a, str.
A.Vlaicu
nr.7
Calcu-
latoare
II 175 1 233 2
Vasiu Bogdan Mircea Floare 24.01
1981
Rei
a
Reia,
str. Grii
nr.3 ap.5
Calcu-
latoare
II 188

CMINITI
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan George Iulia 15.09.
1981
Lugoj Lugoj, str.
Grii nr.8
ap.19
tiine
Ec.
I 854 2 215 3
Marinesc
u
Liana Lucian Eva 04.11.
1979
Timi-
oara
Timioara
, str.1
Iunie nr.3
Calcu-
latoare
II 130 1 233 1
Ondea Vasile Mihai Aurica 25.10.
1977
Timi-
oara
Timioara
, Cl.
agului
nr. 201
tijne
Ec.
II 602 2 141 2
Popescu Maria Ion Oana 10.06.
1980
Timi-
oara
Timioara
, str.
A.Vlaicu
nr.7
Calcu-
latoare
II 175 1 233 2

EXTERNI
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Vasiu Bogdan Mircea Floare 24.01
.1981
Rei
a
Reia, str.
Grii nr.3
ap.5
Calcu
-lato-
are
II 188

Figura 3.21. Partiionarea orizontal

Partiionarea orizontal presupune proiectarea liniilor unei relaii n mai multe
relaii, fiecare dintre acestea coninnd cheia primar pentru a permite reconstituirea
tabelei originale. Operaia se execut atunci cnd tabela are foarte multe linii, cnd
linii diferite ale aceleiai BD sunt exploatate n locuri de munc diferite ale aceleiai
organizaii sau cnd unele linii sunt accesate foarte des fa de altele. Obinerea BD
originale se face prin reunirea BD partiionate.
44
De exemplu, relaia EVIDENA de mai sus poate fi partiionat orizontal n
dou relaii, una CAMINITI i una EXTERNI, prima coninnd informaiile despre
studenii care locuiesc n cmin iar cea de-a doua informaiile despre studenii din
afara cminului (Figura 3.21).
Operaia se bazeaz pe instruciunea SELECT:
Cminiti := SELECT (Evidena) (Cminul <> null);
Externi := SELECT (Evidena) (Cminul = null);


EVIDENA
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

Costin Ioan George Iulia 15.09
.1981
Lugoj Lugoj,
str. Grii
nr.8
ap.19
tiin
e Ec.
I 854 2 215 3
Marines
cu
Liana Lucian Eva 04.11
.1979
Timi-
oara
Timioar
a, str.1
Iunie
nr.3
Calcu
-
latoar
e
II 130 1 233 1
Ondea Vasile Mihai Aurica 25.10
.1977
Timi-
oara
Timioar
a, Cl.
agului
nr. 201
tijn
e Ec.
II 602 2 141 2
Popescu Maria Ion Oana 10.06
.1980
Timi-
oara
Timioar
a, str.
A.Vlaicu
nr.7
Calcu
-
latoar
e
II 175 1 233 2
Vasiu Bogdan Mircea Floare 24.01
.1981
Rei
a
Reia,
str. Grii
nr.3 ap.5
Calcu
-
latoar
e
II 188

TAXE
Facultatea# Numr matricol# Procent achitare
tiine Ec. 854 100
Calculatoare 130 0
tijne Ec. 602 50
Calculatoare 175 100
Calculatoare 188 0








45
ACCEPTARE
N
u
m
e
l
e

P
r
e
n
u
m
e
l
e

P
r
e
n
u
m
e
l
e

t
a
t

l
u
i

P
r
e
n
u
m
e
l
e

m
a
m
e
i

D
a
t
a

n
a

t
e
r
i
i

L
o
c
u
l

n
a

t
e
r
i
i

D
o
m
i
c
i
l
i
u
l

F
a
c
u
l
t
a
t
e
a

A
n
u
l

d
e

s
t
u
d
i
u

N
u
m

r

m
a
t
r
i
c
o
l
#

C

m
i
n
u
l

C
a
m
e
r
a

P
a
t
u
l

P
r
o
c
e
n
t

a
c
h
i
t
a
r
e

Costin Ioan George Iulia 15.09
.1981
Lugoj Lugoj,
str. Grii
nr.8
ap.19
tiine
Ec.
I 854 2 215 3
10
0
Popescu Maria Ion Oana 10.06
.1980
Timi-
oara
Timioar
a, str.
A.Vlaicu
nr.7
Calcu-
latoare
II 175 1 233 2
10
0
Figura 3.22: Reunirea relaiilor
Reunirea relaiilor presupune proiectarea liniilor din mai multe relaii ntr-una singur
care conine atribute extrase din toate relaiile iniiale, cu condiia ca relaiile s aib
un atribut comun. Operaia se execut atunci cnd informaiile respective sunt
accesate de obicei mpreun.
De exemplu, relaia EVIDENA de mai sus poate fi reunit cu relaia TAXE
(Facultatea#, Numr matricol#, Procent achitare) pentru a determina care din
studeni se pot prezenta la examen folosind (Figura 3.22) instruciunea JOIN:
Acceptare := JOIN (Evidena) (Procent achitare = 100) (Taxe)
Este evident c pentru utilizator timpul de acces la informaiile din BD este un
parametru important al eficienei folosirii unui anumit sistem informatic, de aceea
proiectarea fizic trebuie s asigure mbuntirea performanelor.
Accesul la atributele cel mai des folosite trebuie efectuat cu maximum de
vitez, de aceea proiectantul va prevedea ci de acces rapid preconstruite. Tehnicile
care se folosesc sunt cele cu structuri de indeci (se pstreaz localizarea liniilor ce
corespund valorilor indecilor) sau prin hashing pe valorile atributului.
ntr-o BD relaional, pentru atributele de cheie primar trebuie ntotdeauna
ci de acces rapid preconstruite (index) deoarece dup aceste chei se face accesul
n cea mai mare parte a timpului. Pentru atributele de cheie alternat ca i pentru
atributele de cheie strin pot fi construite ci de acces rapid preconstruite.
Uneori, dei ar trebui s existe chei de acces rapid asociate unor atribute,
acest lucru nu se implementeaz; sunt situaiile cnd valorile acestor atribute se
actualizeaz foarte des i deci i indexul sau hashingul se modific permanent.
Reuniunile preconstruite sunt o alt metod de mrire a vitezei de acces la
datele din BD. Tehnicile care se folosesc sunt cele ale directoarelor cu valori atribut-
reuniune (coninnd pointeri la liniile care se reunesc) sau ale listelor nlnuite
(coninnd pointerii de la liniile unei tabele la liniile celeilalte tabele).
De exemplu, se observ din analiza situaiei colare anumite tipare n
alegerea disciplinelor ca n Figura 3.23. Se poate atunci construi o relaie folosind
directoare ca n Figura 3.24 sau folosind liste nlnuite ca n Figura 3.25.








46
LIMBI STRINE SPORT
Genul Disciplina Genul Disciplina
Feminin Francez Feminin Aerobic
Feminin German Feminin not
Masculin Englez Masculin Fotbal
Masculin not
Masculin Schi

Figura 3.23. Relaiile LIMBI STRINE i SPORT

Genul Disciplina-Limba strin Disciplina-Sport
Feminin Francez Aerobic
Feminin Francez not
Feminin German Aerobic
Feminin German not
Masculin Englez Fotbal
Masculin Englez not
Masculin Englez Schi

Figura 3.24. Reuniunile preconstruite reprezentate prin directoare

Genul Disciplina
Primul SPORT cu
valoarea GENUL
Feminin Francez 1
Feminin German 1
Masculin Englez 3

Genul Disciplina
Urmtorul SPORT cu
valoarea GENUL
Feminin Aerobic 2
Feminin not 2
Masculin Fotbal 0
Masculin not 0
Masculin Schi 0

Figura 3.25. Reuniunile preconstruite reprezentate prin liste nlnuite

Gestionarea mrimii buffer-elor este o alt cale de mbuntire a
parametrilor de acces la BD. Cu ct buffer-ul de transfer ntre memoria principal i
cea secundar este mai mare, cu att mai multe linii pot fi accesate simultan fr a
necesita o nou citire a memoriei secundare.
i gruparea relaiilor de baz, adic a acelor relaii care apar cel mai des
ntre informaii, poate aduce rezultate pozitive. Gruparea mpreun a liniilor cu valori
similare ale atributului dup care se face accesul, dup secvena FIFO sau LIFO,
face ca pentru relaia respectiv s nu se pierd timp cu accese multiple la locuri
diferite din BD.
Alegerea corect a dimensiunii fiierelor, care poate fi un impediment
permanent la viteza de execuie a interogrilor, poate ajuta la performanele BD cnd
se fac actualizri masive sau se definesc relaii noi. Dac spaiul ales este prea mic,
eventualele reorganizri necesit timp i consum de resurse; n acelai timp, un
spaiu excesiv nseamn un surplus de plat a unei resurse care nu este utilizat.
47
C CA AP PI IT TO OL LU UL L I IV V
I IM MP PL LE EM ME EN NT TA AR RE EA A A AP PL LI IC CA A I IE EI I


4.1 ARHITECTURA PROGRAMULUI


Aplicaia J_MySQL_win este o interfa Java ce permite accesarea i
manipularea datelor dintr-o baz de date MySQL. Specificaia de proiectare a cuprins
prin urmare cerina de implementare a urmtoarelor operaii:
SELECT * afiarea tuturor datelor din tabel);
SELECT afiarea selectiv dup ID;
INSERT inserarea de nregistrri noi;
DELETE stergerea unor nregistrri.




Figura 4.1. Structura aplicaiei J_MySQL_win

Prin urmare arhitectura programului cuprinde din punct de vedere structural
urmtoarele clase:
J_MySQL_win clasa principala responsabil de afiarea ferestrei
principale cu bara de meniuri i spaiul de afiare a rezultatelor;
Cnx clasa care asigur conexiunea la baza de date apelnd la
pachetele com i org din seciunea insert
Afi clasa care gestioneaz apariia ferestrei secundare de afiaj a
rezultatelor;
Data_sel clasa care pregtete operaiunea de Select i preia
rezultatele acesteia de la Cnx;
Data_get clasa care asigur realizarea inserrii de noi nregistrri prin
preluarea i procesarea comenzii utilizatorului;
48
Data_del clasa care asigur realizarea tergerii unei nregistrri prin
preluarea i procesarea comenzii utilizatorului.


4.2 GHIDUL DE UTILIZATOR

La pornirea programului ferestra principal arat aa cum se prezint n Figura
4.2.



Figura 4.2. Ferestra principal la start

Principalele operaiuni ce se execut cu programul ce face obiectul acestei
lucrri sunt:
SELECT * afiarea tuturor datelor din tabel);
SELECT afiarea selectiv dup ID;
INSERT inserarea de nregistrri noi;
DELETE stergerea unor nregistrri.
Drept urmare consola principal are meniul din Figura 4.3.



Figura 4.3. Meniul din ferestra principal

La alegerea comenzii Select * rezultatele se afieaz n cadrul ferestrei
principale aa cum se poate observa n Figura 4.4.

49


Figura 4.4. Afiarea rezultatelor Select * n ferestra principal



Figura 4.5. Ferestra de dialog preluare date pentru selecie

n cazul n care operaiunea ales este Select apare fereastra de dialog din
Figura 4.5. n care operatorul specific ceea ce va conine condiia de selecie. Toate
condiiile se refer la cmpul ID cheia principal a tabelului.
Rezultatele interogrii anterior definite sunt prezentate n Figura 4.6. Aceste
rezultate sunt plasate n cadrul ferestrei secundare Rezultat selecie.



Figura 4.6. Afiarea rezultatelor Select * n ferestra

50
Inserarea unei noi inregistrri se face prin alegerea comenzii Insert din meniul
Comenzi al ferestrei principale. Urmare acestui fapt pe ecran se afieaz ferestra de
dialog Preluare date din Figura 4.7.



Figura 4.7. Preluarea datelor pentru inserarea unei nregistrri

Rezultatul inserrii se poate verifica prin comanda Select * unde noua
nregistrare apare alaturi de cele anterioare.
tergerea unei inregistrri se face prin alegerea comenzii Delete din meniul
Comenzi al ferestrei principale. Urmare acestui fapt pe ecran se afieaz ferestra de
dialog Preluare date din Figura 4.8.



Figura 4.8. Preluarea datelor pentru tergerea unei nregistrri

Rezultatul tergerii se poate, de asemenea, verifica prin comanda Select * unde
nregistrarea eliminat nu mai apare.

51
C CA AP PI IT TO OL LU UL L V V
C CO ON NC CL LU UZ ZI II I I I P PO OS SI IB BI IL LI IT T I I D DE E D DE EZ ZV VO OL LT TA AR RE E


Aplicaia J_MySQL_win este un program cu scop didactic care furnizeaz
elementele de baz pentru dialogul cu o baz de date MySQL. Avnd n vedere
specificaia iniial a proiectului s-a adoptat soluia simpl a unei interfee consol
cuprinznd att meniul de comenzi ct i spaiul de afiaj pentru Select * (toate
datele).
Aplicaia a fost implementat n limbajul Java deoarece acesta este
independent de platform i permite prin urmare rularea cvasi-identic pe oricare
dintre sistemele de calcul folosite curent.
Programarea orientat pe obiecte este o opiune mai avantajoas dect
programarea procedural, pentru c ferestrele, meniurile, interfeele grafice de
utilizator sunt mult mai uor de implementat prin utilizarea unor clase i familii de
clase predefinite.
Scrierea i testarea programului s-a fcut n Textpad care permite utilizarea
scrierea programelor sub compact. Acest fapt permite compilarea i rularea mai
multor clase din cadrul proiectului ntr-un singur fiier.
Pentru operaiile Select, Insert i Delete s-au implementat ferestre de dialog
care permit o flexibilitate suplimentar n definirea comenzilor respective.
Aplicaia implementat are o funcionare corect i eficient, deoarece codul
scris este compact avnd avantajul c soluioneaz toate cerinele din specificaie
ntr-un mod direct i precis.
O dezvoltare ulterioar a acestei aplicaii ar putea fi introducerea posibilitii ca
ea s fie utilizat n reea de ctre mai muli clieni care s ruleze programul pe
calculatoare diferite. Pentru acest lucru trebuie implementat n program un server i
doi, trei, ... utilizatori separai corespunztori nevoilor aplicaiei.
Posibilitile de dezvoltare ulterioar sunt principial posibile prin ataarea de noi
module funcionale sub forma unor clase sau pachete de clase Java. Dintre aceste
posibile dezvoltri menionez introducerea unei interfee grafice de interaciune cu
operatorul GUI mai sofisticat, a unui Help on line cu explicaii suplimentare.
De asemenea, n cadrul ferestrelor de dialog se poate mri numrul de
elemente de definire a operaiilor aflate la dispoziia utilizatorului astfel nct s se
obin o cretere a flexibilitii funcionale a programului.

52
B BI IB BL LI IO OG GR RA AF FI IE E

1. Connolly T., Begg C., Strachan A., Baze de date, ed Teora
Bucureti 2001
2. DuBois P., MySQL, ed. Teora, Bucureti 2000
3. Greenspan J., Bulger B., MySQL/PHP Databases Application, M&T
Books, Chicago, IL, USA 2002
4. Karnyanszky T.M., Lacrm L.D., Baze de date teorie i aplicaii,
ed. Mirton Timioara, 2003
5. Luers T., Atwood T., Gennick J., PL/SQL, ed. Teora Bucureti 2001
6. Chan M.C., Griffith W.S., Iasi F.A., 1001 de secrete Java ed Teora
Bucureti 2000
7. Lemay L., Cadenhead R., Java 2 fr profesor ed. Teora Bucureti
2001
8. Lalani S., Jamsa K., Java Biblioteca programatorului, ed All
Timioara 1977
9. Lacrm L.D., Programarea orientat pe obiecte ed. Helicon
Timioara 1999
10. Norton P., Stanek W., Limbajul Java ed. Teora Bucureti 1997


53
A An ne ex x


import java.awt.*; // import pachete java.awt
import java.awt.event.*; // java.awt.event
import javax.swing.*;
import java.sql.*; // java.sql
import java.util.*; // si java.util

public class J_MySQL_win extends JFrame implements ActionListener{
// declaratie clasa J_MySQL_win
private MenuBar mb; // bara de meniu
private Menu f; // meniu
private MenuItem o, s, i, d, c; // comenzi meniu
protected static Data_sel ds;
protected static Data_get dg;
protected static Data_del dd;
private Cnx cnx = null; // conexiune la BD
protected static String q = null; // interogare

public J_MySQL_win(){ // metoda constructor J_MySQL_win
setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu X
initComponents (); // apel metoda initializare meniu
}
public void actionPerformed(ActionEvent ev){
Object sr=ev.getSource();
if(sr==o){ // tratarea comenzii Select
q = "SELECT * FROM Job WHERE ID>100" ;// interogare1
nx = new Cnx(); // instantiere conexiune la BD
cnx.connect(); // conectare la BD
repaint(); // afisare rezultate
}
else if(sr==s){ // tratarea comenzii Insert
ds=new Data_sel(); // instantiere fereastra f
ds.setTitle("Preluare date"); // setarea barei de titlu
s.setSize(240,200); // stabilire dimensiuni fereastra
s.setLocation(400,400); // stabilire locatie protected ecran
ds.setVisible(true); // comanda afisare fereastra
}
else if(sr==i){ // tratarea comenzii Insert
dg=new Data_get(); // instantiere fereastra f
.setTitle("Preluare date"); // setarea barei de titlu
g.setSize(240,200); // stabilire dimensiuni fereastra
g.setLocation(400,400); // stabilire locatie protected ecran
g.setVisible(true); // comanda afisare fereastra
}
else if(sr==d){ // tratarea comenzii Delete
d = new Data_del(); // instantiere fereastra f
.setTitle("Preluare date"); // setarea barei de titlu
dd.setSize(240,200); // stabilire dimensiuni fereastra
dd.setLocation(400,400); // stabilire locatie protected ecran
dd.setVisible(true); // comanda afisare fereastra
}
else if(sr==c){ // tratarea comenzii Close
this.dispose(); //eliberare resurse alocate ferestrei
System.exit(1); // iesire din program
54
}
}
private void initComponents(){ // metoda initializare meniu
mb=new MenuBar(); // instantiere bara de meniuri
f= new Menu("Comenzi"); // instantiere meniu "Comenzi"
o= new MenuItem("Select *") // instantiere comanda "Select"
o.addActionListener(this); // alocare actiune
f.add(o);
s= new MenuItem("Select"); // instantiere comanda "Select"
s.addActionListener(this); // alocare actiune f.add(s);
i= new MenuItem("Insert"); // instantiere comanda "Select"
i.addActionListener(this); // alocare actiune
f.add(i); // inserarea comenzii "Select"
in meniul File
d= new MenuItem("Delete"); // instantiere comanda "Select"
d.addActionListener(this); // alocare actiune
f.add(d);
c= new MenuItem("Close"); // instantiere comanda "Close"
c.addActionListener(this); // alocare actiune
f.add(c); // inserarea comenzii "Close" in
meniul File
mb.add(f); // inserare bara in cadru
this.setMenuBar(mb); // stabilire bara de meniuri
}
public void paint(Graphics g){ // metoda paint
g.setColor(Color.white);
g.fillRect(0,0,600,350);
g.setColor(Color.black);
if(q!=null){ // testare existenta interogari
g.drawString("Rezultatul interogarii",30,70); // tiparire
g.drawString(q+" este:",30,85); // interogare si cap de tabel
g.drawString(" ID Nume Prenume Pozitie",30,105);
g.drawString("-------------------------------------------------",30,110);
for(int j=0;j<cnx.i;j++) // tiparire rezultate
g.drawString((String)cnx.getRezult().elementAt(j),30,120 +15*j);
g.drawString("Setul rezultat cuprinde "+cnx.i+" inregistrari",30,130+15*cnx.i);
q=null;
}
else if(dg.q!=null){
g.drawString("Inserarea:",30,70); // tiparire
g.drawString(dg.q,30,85);
g.drawString("a fost executata",30,100);
dg.q = null;
}
else if(dd.q!=null){
g.drawString("Stergerea:",30,70); // tiparire
g.drawString(dd.q,30,85);
g.drawString("a fost executata",30,100);
dd.q = null;
}
}
public static void main(String args[]){ // metoda main
J_MySQL_win f=new J_MySQL_win(); // instantiere fereastra f
f.setTitle("Conexiune cu MySQL"); // setarea barei de titlu
f.setSize(600,350); // stabilire dimensiuni fereastra
f.setLocation(200,200); // stabilire locatie protected ecran
55
f.setVisible(true); // comanda afisare fereastra
}
}
class Afis extends JFrame{
public Afis(){
repaint();
}
public void paint(Graphics g){ // metoda paint
g.setColor(Color.white);
g.fillRect(0,0,600,350);
g.setColor(Color.black);
if(J_MySQL_win.ds.q!=null){ // testare existenta interogari
g.drawString("Rezultatul interogarii",30,70); // tiparire
g.drawString(J_MySQL_win.ds.q+" este:",30,85); // interogare si cap de tabel
g.drawString(" ID Nume Prenume Pozitie",30,105);
g.drawString("-------------------------------------------------",30,110);
for(int j=0;j<J_MySQL_win.ds.cnx.i;j++) // tiparire rezultate
g.drawString((String)J_MySQL_win.ds.cnx.getRezult().elementAt(j),30,120 +15*j);
g.drawString("Setul rezultat cuprinde "+J_MySQL_win.ds.cnx.i+"
inregistrari",30,130+15*J_MySQL_win.ds.cnx.i);
J_MySQL_win.ds.q=null;
}
}
}
class Data_sel extends JFrame implements ActionListener{ // declaratie clasa
Data_del
private Label l,l1;
private TextField t1;
private Button b1;
protected Cnx cnx=null; // conexiune la BD
protected static String q = null; // interogare
public Data_sel(){
setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu X
initComponents();
}
public void initComponents(){
Container c= getContentPane(); // definire container
c.setLayout(null); // setare asezare absoluta
l = new Label("Completati datele si apasati pe buton"); // eticheta
l.setBounds(10,20,360,20); // setare dimensiuni l
c.add(l); // adaugare eticheta l
l1 = new Label("ID:"); // instantiere etichata l1
l1.setBounds(30,40,60,20); // setare dimensiuni l1
c.add(l1); // adaugare eticheta l1
t1 = new TextField(20); // instantiere textfield t1
t1.setBounds(90,40,120,20); // setare dimensiuni t1
t1.setText("<104");
c.add(t1); // adaugare eticheta t1
b1=new Button("Corect"); // instantiere buton b
b1.setBounds(60,80,120,30); // setare dimensiuni b
b1.addActionListener(this); // alocare actiune
c.add(b1); // adugare buton b
}
public void actionPerformed(ActionEvent ev){
Object sr=ev.getSource();
if(sr==b1){ // tratarea comenzii Corect
56
q = "SELECT * FROM Job WHERE ID"+ t1.getText();
// stergere
cnx = new Cnx(); // instantiere conexiune la BD
cnx.connect(); // conectare la BD
Afis a=new Afis(); // instantiere fereastra a
a.setTitle("Rezultat selectie"); // setarea barei de titlu
a.setSize(600,350); // stabilire dimensiuni fereastra
a.setLocation(400,400); // stabilire locatie protected ecran
a.setVisible(true); // comanda afisare fereastra
this.dispose(); // eliberare resurse alocate ferestrei
}
}
}
class Data_get extends JFrame implements ActionListener{ // declaratie clasa
Data_get
private Label l,l1,l2,l3,l4;
private TextField t1,t2,t3,t4;
private Button b1;
private Cnx cnx=null; // conexiune la BD
protected static String q = null; // interogare
public Data_get(){
setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu X
nitComponents();
}
public void initComponents(){
Container c= getContentPane(); // definire container
c.setLayout(null); // setare asezare absoluta
l = new Label("Completati datele si apasati pe buton"); // eticheta
setBounds(10,20,360,20); // setare dimensiuni l
c.add(l); // adaugare eticheta l
l1 = new Label("ID:"); // instantiere etichata l1
l1.setBounds(30,40,60,20); // setare dimensiuni l1
add(l1); // adaugare eticheta l1
t1 = new TextField(20); // instantiere textfield t1
t1.setBounds(90,40,120,20); // setare dimensiuni t1
t1.setText("110");
c.add(t1); // adaugare eticheta t1
l2 = new Label("Nume:"); // instantiere etichata l2
l2.setBounds(30,60,60,20); // setare dimensiuni l2
c.add(l2); // adaugare eticheta l2
t2 = new TextField(20); // instantiere textfield t2
t2.setBounds(90,60,120,20); // setare dimensiuni t2
t2.setText("Popovici");
c.add(t2); // adaugare eticheta t2
l3 = new Label("Prenume:"); ] // instantiere etichata l1
l3.setBounds(30,80,60,20); // setare dimensiuni l1
c.add(l3); // adaugare eticheta l1
t3 = new TextField(20); // instantiere textfield t1
t3.setBounds(90,80,120,20); // setare dimensiuni t1
t3.setText("Radu");
c.add(t3); // adaugare eticheta t1
l4 = new Label("Pozitie:"); // instantiere etichata l2
l4.setBounds(30,100,60,20); // setare dimensiuni l2
c.add(l4); // adaugare eticheta l2
t4 = new TextField(20); // instantiere textfield t2
t4.setBounds(90,100,120,20); // setare dimensiuni t2
57
t4.setText("portar");
c.add(t4); // adaugare eticheta t2
b1=new Button("Corect"); // instantiere buton b
b1.setBounds(60,120,120,30); // setare dimensiuni b
b1.addActionListener(this); // alocare actiune
c.add(b1); // adugare buton b
}
public void actionPerformed(ActionEvent ev){
Object sr=ev.getSource();
if(sr==b1){ // tratarea comenzii Corect
q = "INSERT INTO Job (ID, Nume, Prenume, Pozitie) VALUES ( " +
t1.getText()+", \""+t2.getText()+ "\", \""+t3.getText()+"\", \""+t4.getText()+"\")";
// adaugare
cnx = new Cnx(); // instantiere conexiune la BD
cnx.connect(); // conectare la BD
this.dispose();
}
}
}

class Data_del extends JFrame implements ActionListener{ // declaratie clasa
Data_del
private Label l,l1;
private TextField t1;
private Button b1;
private Cnx cnx=null; // conexiune la BD
protected static String q = null; // interogare

public Data_del(){
setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu X
initComponents();
}
public void initComponents(){
Container c= getContentPane(); // definire container
c.setLayout(null); // setare asezare absoluta
l = new Label("Completati datele si apasati pe buton"); // eticheta
l.setBounds(10,20,360,20); // setare dimensiuni l
c.add(l); // adaugare eticheta l
l1 = new Label("ID:"); // instantiere etichata l1
l1.setBounds(30,40,60,20); // setare dimensiuni l1
c.add(l1); // adaugare eticheta l1
t1 = new TextField(20); // instantiere textfield t1
t1.setBounds(90,40,120,20); // setare dimensiuni t1
t1.setText("110");
c.add(t1); // adaugare eticheta t1
b1=new Button("Corect"); // instantiere buton b1
b1.setBounds(60,80,120,30); // setare dimensiuni b1
b1.addActionListener(this); // alocare actiune
c.add(b1); // adugare buton b
}
public void actionPerformed(ActionEvent ev){
Object sr=ev.getSource();
if(sr==b1){ // tratarea comenzii Corect
q = "DELETE FROM Job WHERE ID="+ t1.getText();
// stergere
cnx = new Cnx(); // instantiere conexiune la BD
58
cnx.connect(); // conectare la BD
this.dispose(); // eliberare resurse alocate ferestrei
}
}
}

class Cnx{ // clasa conexiune la BD
private ResultSet set; // buffer rezultate
private Connection c= null; // conexiunea
private Statement p; // interogarea
private Vector rez = new Vector(); // instantiere vector
protected int i = 0; // contor inregistrari
public Cnx(){ // constructor clasa Cnx
getDriver(); // apel metoda getDriver()
}
public void getDriver(){ // declaratie metoda getDriver()
try{ // testare erori la gasirea
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
}catch (Exception e){ // clasei Driver
System.err.println(e); // mesaj standard de eroare
}
}
public void connect(){ // metda conect
MySQL_win.q!=null) try{ // testare eroare de conectare
c = DriverManager.getConnection("jdbc:mysql: //localhost/Test_cnx","","");
p = c.createStatement(); // propozitie interogare
getData();
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
else if(J_MySQL_win.ds.q!=null) try{ // testare eroare de conectare
c = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");
p = c.createStatement(); // propozitie interogare
getData1();
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
else if(J_MySQL_win.dg.q!=null) try{ // testare eroare de conectare
c = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");
p = c.createStatement(); // propozitie interogare
addData();
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
else if(J_MySQL_win.dd.q!=null) try{ // testare eroare de conectare
c = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");
p = c.createStatement(); // propozitie interogare
deleteData();
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
}
public void getData(){
try{
set = p.executeQuery(J_MySQL_win.q); // executie
while(set.next()){ // transfer rezultate din
59
i++; // bufferul set in vectorul rez
rez.addElement(set.getString("ID")+" "+set.getString("Nume")+
" "+set.getString("Prenume")+" "+set.getString("Pozitie"));
}
p.close();
c.close(); // inchidere conexiune la BD
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
}
public void getData1(){
try{
set = p.executeQuery(J_MySQL_win.ds.q); // executie
while(set.next()){ // transfer rezultate din
i++; // bufferul set in vectorul rez
rez.addElement(set.getString("ID")+" "+set.getString("Nume")+
" "+set.getString("Prenume")+" "+set.getString("Pozitie"));
}
p.close();
c.close(); // inchidere conexiune la BD
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
}
public void addData(){
try{
p.executeUpdate(J_MySQL_win.dg.q); // executie
p.close();
c.close(); // inchidere conexiune la BD
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
}
public void deleteData(){
try{
p.executeUpdate(J_MySQL_win.dd.q); // executie
p.close();
c.close(); // inchidere conexiune la BD
}catch(SQLException e){ // exceptie SQL
System.err.println(e); // mesaj standard de eroare
}
}
public Vector getRezult(){ // metoda pentu accesarea
return rez; // rezultatelor interogarii
}
}










60





DECLARAIE PE PROPRIE RSPUNDERE
PRIVIND RESPECTAREA DREPTURILOR INTELECTUALE N
ELABORAREA LUCRRII DE LICEN/ DISERTAIE
Subsemnatul/a ______________________________________________________________ ,
legitimat cu BI/CI seria ____ nr. ____________ , CNP ______________________________
autorul lucrrii de licen/disertaie, cu titlul: _______________________________________
_________________________________________________________________________________
_________________________________________________________________________________
avnd conductor tiinific pe __________________________________________________ ,
am elaborate aceast lucrare n vederea susinerii examenului de finalizare a studiilor organizat de
ctre Facultatea de Calculatoare i Informatic Aplicat, din cadrul Universitii Tibiscus din
Timioara, n sesiunea _________________ a anului universitar __________ / _________ ,
declar pe proprie rspundere,
cunoscnd prevederile Codului Penal privind falsul n declaraii, c aceast lucrare este
rezultatul propriei mele activiti intelectuale, nu conine poriuni plagiate, iar sursele
bibliografice au fost folosite cu respectarea legislaiei romne i a conveniilor internaionale
privind drepturile de autor.
Timioara, Semntura,
__________________________ __________________________
(data)