lucrare licenta

87
UNIVERSITATEA „TIBISCUS” DIN TIMIŞOARA FACULTATEA DE CALCULATOARE ŞI INFORMATICĂ APLICATĂ LUCRARE DE LICENŢĂ CONDUCĂTOR ŞTIINŢIFIC: …………………………………………… CANDIDAT: ………………… 2

Upload: simona-blaj

Post on 01-May-2017

625 views

Category:

Documents


4 download

TRANSCRIPT

UNIVERSITATEA „TIBISCUS” DIN TIMIŞOARAFACULTATEA DE CALCULATOARE

ŞI INFORMATICĂ APLICATĂ

LUCRARE DE LICENŢĂ

CONDUCĂTOR ŞTIINŢIFIC:……………………………………………

CANDIDAT:…………………

……………………..2

Interfaţă Java pentru obază de date MySQL

Universitatea „Tibiscus” din TimişoaraFacultatea de Calculatoare şi

Informatică AplicatăDepartamentul de Informatică

REFERATasupra lucrării de licenţă cu titlul

_________________________________________________3

_________________________________________________ elaborată de candidatul _________________________________

Subsemnatul ____________________________ de la departamentul de Informatică al Facultăţii de Calculatoare şi Informatică Aplicată, în calitate de coordonator ştiinţific, fac următoarele precizări:

lucrarea este structurată pe ___ capitole (___ pagini), în care se tratează tema propusă;

lucrarea este îngrijit redactată şi tehnoredactată;

lucrarea corespunde din punct de vedere ştiinţific, dovedind cunoaşterea şi aprofundarea de către candidat a domeniului abordat;

bibliografia consultată este bine aleasă şi de actualitate;

____________________________________________________________________________________________________________________________________________________________________________________

În concluzie, sunt de acord cu acceptatea lucrării în vederea susţinerii publice în faţa comisiei de licenţă.

Propun, în calitate de coordonator ştiinţific, nota __________.

Timişoara,___/___/______ _______________________

Capitolul ICapitolul I4

IntroducereIntroducere

Lucrarea de faţă prezintă o soluţie originală de interfaţă Java cu o bază de date MySQL. Interfaţa permite realizarea legaturii dintre baya de date şi utilizatorul (clientul) acesteia. Prin urmare au fost implementate principalele operaţiuni din DML şi anume: INSERT, DELETE şi SELECT. Aplicaţia fiind una cu caracter didactic s-a optat pentru o formulă de prezentare simplă, astfel încât să nu se complice codul sursa cu elemente suplimentare, a căror utilitate propriu-zisă este discutabilă.

Aplicaţia este realizată în Limbajul Java versiunea jdk 1.6.0_02 care cuprinde atât pachetele API tradiţionale (java.awt.*, java.awt.event.*) cât şi pachetul javax.swing.* necesare pentru implementarea ferestrelor şi a elementelor de dialog necesare pentru a transmite către baza de date comenzile clientului.

Capitolul de faţă este consacrat unei prezentări generale a lucrării şi a aplicaţiei ce face obiectul acesteia. Fiecare capitol este descris pe scurt astfel încât să se ofere o imagine de ansamblu a licenţei.

Capitolul II „Noţiuni generale despre bazele de date” este destinat prezentării elementelor teoretice fundamentale privind bazele de date şi gestionarea acestora. Textul cuprinde pe lângă definiţii şi enunţuri, un număr de exemple ilustrative pentru mai buna clarificare a acestora.

Capitolul III „Modelul relaţional de gestiune a bazelor de date” cuprinde o descriere aprofundată a Modelului Relaţional cu principalele sale proprietăţi. Este de asemenea prezentată metodologia standard de proiectare a unui SGBD utilizînd atât Normalizarea cât şi proiectarea cu ajutorul Schemelor Entitate-Relaţie. 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 aplicaţiei” cuprinde descrierea modului în care a fost construit programul J_MySQL_win. Arhitectura claselor componente este prezentată într-o formă schematică uşor de analizat. De asemenea în cadrul acestei secţiuni este inclus un Ghid de utilizator în care sunt descrise toate funcţiile programului şi modul în care acestea pot fi folosite.

Capitolul V „Concluzii şi posibilităţi de dezvoltare” cuprinde pe lângă concluziile propriu-zise şi câteva posibile dezvoltări ulterioare ale lucrării astfel încât să se transforme aplicaţia dintr-un program didactic într-unul cu valenţe comerciale.

Materialul cuprinde la final bibliografia studiată pentru a implementa proiectul şi o anexă ce conţine listat codul sursă al aplicaţiei. În punctele esenţiale sunt inserate comentarii destinate unei mai bune înţelegeri a soluţiilor concrete din program.

5

Capitolul IICapitolul IINOŢIUNI GENERALE DESPRE BAZELE DE DATENOŢIUNI GENERALE DESPRE BAZELE DE DATE

În proiectarea sistemelor informatice, organizarea datelor ocupă un loc important deoarece de modul în care datele sunt organizate depinde în mare parte eficienţa sistemului informatic.

Activitatea de organizare a datelor cuprinde: definirea, structurarea, ordonarea şi gruparea datelor în colecţii de date; stabilirea relaţiilor între date, între elementele colecţiei, între colecţii; reprezentarea datelor pe suportul de informaţie în vederea prelucrării într-un

sistem de calcul.Organizarea datelor are ca scop posibilitatea ca datele să fie regăsite, î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 informaţie;

minimizarea spaţiului de memorie internă şi externă ocupat de datele organizate;

reflectarea, pe cât posibil, a tuturor relaţiilor dintre obiectele, fenomenele şi procesele pe care aceste date le reprezintă;

posibilitatea schimbării structurii datelor şi relaţiilor dintre ele fără a modifica programele care le gestionează.Datele (data) sunt definite ca informaţiile efective culese din realitate, cum ar

fi un text, un număr, 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 păstrează informaţia), atribut (ce reprezintă informaţia) şi valoare (informaţia concretă).

Datele pot fi elementare (sau scalare), dacă sunt indivizibile în raport cu informaţia pe care o reprezintă, sau compuse, dacă pot fi descompuse în mai multe date elementare.

O colecţie de date între care s-au stabilit relaţii care permit un anumit mecanism de selecţie şi identificare a componentelor se numeşte 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 numeşte secvenţial, sau prin indicarea chiar a componentei dorite, caz în care accesul se numeşte direct.

Asupra unei structuri de date pot fi efectuate următoarele operaţiuni: crearea, care constă în memorarea iniţială a datelor pe suportul de informaţie; consultarea, care constă în utilizarea datelor memorate pentru prelucrări

diverse; actualizarea, care se poate face:

-asupra structurii de date, prin adăugarea, modificarea sau ştergerea de elemente din structură;-asupra datelor din structură, prin adăugarea, 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;

6

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, când componentele sunt de acelaşi tip;-structuri eterogene (neomogene), când componentele aparţin unor tipuri diferite;

după posibilitatea de descompunere:-structuri recursive, când se pot descompune în structuri de acelaşi tip;-structuri nerecursive, când nu se pot descompune în structuri de acelaşi tip;

după posibilităţile de modificare:-structuri statice, când numărul total de componente şi ordinea acestora nu se pot modifica;-structuri dinamice, când numărul 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 folosiţi;-structură fizică, dacă se referă la modalitatea de memorare a datelor pe suporţii de informaţie.Principalele tipuri de structuri de date sunt:

structura punctuală, reprezentată printr-o singură entitate; structura liniară - când între elementele structurii exsită o relaţie de ordine

totală; structura arborescentă (ierarhică, descendentă) - când între elementele

structurii există o relaţie de ordine; structura reţea - când între elementele structurii există o relaţie de preordine; structură relaţională - când elementele structurii sunt reprezentate prin

tabele (tablouri) de date elementare cărora li se pot aplica operatorii algebrei relaţionale.Transpunerea informaţiilor din realitate în reprezentarea lor cu structuri de

date se face numai după ce s-a definit modelul datelor, ceea ce înseamnă identificarea următoarelor elemente:

structura modelului; operatorii care pot fi utilizaţi; restricţiile care asigură menţinerea corectitudinii datelor.

Definirea modelului datelor se face prin definirea obiectelor (entităţilor) şi caracteristicilor asociate şi a relaţiilor între obiecte.

Definirea operatorilor se face indicând principalele operaţii ce pot fi efectuate asupra datelor (citire, memorare, modificare etc.) şi modalitatea de efectuare a acestor operaţii.

Restricţiile (numite şi reguli de integritate) sunt indicate pentru a preveni operaţiile care ar modifica structura de date lăsând informaţiile într-o situaţie necorespunzătoare.

Conform tipurilor de structuri de date prezentate anterior, modelele de date pot fi:

modelul ierarhic, bazat pe tipuri de înregistrări care grupează toate atributele unei entităţi, având un tip de înregistrare tată şi mai multe tipuri de înregistrare fiu;

7

modelul reţea, bazat pe tipuri de înregistrări care grupează toate atributele unei entităţi, având mai multe tipuri de înregistrare tată şi mai multe tipuri de înregistrare fiu;

modelul relaţional, bazat pe utilizarea tabelelor care grupează diferite atribute ale unei entităţi.

2.1 ABORDAREA GESTIUNII INFORMAŢIEI CU BAZE DE DATE

Un sistem de gestiune a bazelor de date este compus din următoarele părţi: datele, componentele hardware, componentele software şi utilizatorii.

Una din definiţiile [DES99] noţiunii de bază de date este „un depozit pentru datele memorate”. Din acest punct de vedere, mărimea BD este o informaţie critică, în sensul că o BD de dimensiuni foarte mari pune probleme de memorare şi gestionare. Atunci o BD poate fi:

integrată - ea conţine mai multe fişiere de date, cu o parte a redundanţelor eliminată. De exemplu, dacă se doreşte evidenţa studenţilor şi a rezultatelor la examene, acestea pot fi organizate în două fişiere separate: unul cu datele personale ale studenţilor şi celălalt cu notele obţinute. Evident că al doilea fişier trebuie să conţină unele informaţii din primul fişier, dar prin folosirea BD această repetare este eliminată;

partajată - mai mulţi utilizatori pot accesa simultan BD. De exemplu, la BD a studenţilor poate avea acces studentul, pentru a opera unele modificări simple cum ar fi cele de domiciliu, dar în acelaşi timp şi secretariatul facultăţii, pentru operaţii de actualizare cum ar fi anul de studiu şi media anului trecut.Datele pot fi grupate în următoarele categorii:

date de intrare, care permit introducerea de modificări asupra conţinutului BD;

date de ieşire, conţinând rezultatele prelucrărilor efectuate asupra BD; datele din BD, numite şi date operaţionale, care reprezintă activitatea

organizaţiei respective. Componenta hardware este reprezentată de suporţii tehnici pe care are loc

memorarea datelor: harddisk-uri, dischete, CD-uri, benzi magnetice etc., împreună cu dispozitivele care permit utilizarea acestor suporţi şi cu restul calculatorului (calculatoarelor) utilizat(e), cu ajutorul căruia 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 către BD şi nu limbaje universale de programare.

Utilizatorii sunt componentele sistemului BD care asigură gestionarea, prelucrarea şi interpretarea datelor.

O altă definiţie a BD se bazează pe componentele sale, care sunt entităţile, atributele şi relaţiile.

O entitate reprezintă informaţiile despre un anumit obiect, fie el real sau imaginar. Tot ceea ce se cunoaşte despre respectivul obiect poate fi grupat astfel încât să permită cunoaşterea obiectului în detaliu.

De exemplu, dacă se doreşte o evidenţă a studenţilor unei universităţi, se defineşte entitatea STUDENT despre care se cunosc următoarele:Numele: POPESCUPrenumele: MARIAPrenumele tatălui: ION

8

Prenumele mamei: OANAData naşterii: 10.06.1980Locul naşterii: TIMIŞOARADomiciliul: TIMIŞOARA, STR. AUREL VLAICU NR. 7Facultatea: CALCULATOAREAnul de studiu: IINumăr matricol: 175

Fiecare din aceste informaţii reprezintă o proprietate (atribut, item, câmp, caracteristică, element de date) a entităţii STUDENT. De exemplu, Prenumele este un atribut al entităţii STUDENT.

Informaţiile concrete pe care le oferă atributele, atunci când fac referire la o entitate particulară, se numesc valori. De exemplu, MARIA este o valoare a atributului Prenumele pentru o anumită ocurenţă a entităţii STUDENT.

Mai multe entităţi care au proprietăţi similare alcătuiesc un tip de entitate (clasă de entitate), aşa cum, de exemplu, toate numerele întregi între anumite limite alcătuiesc în Pascal tipul predefinit integer.

De exemplu, toţi studenţii dintr-o anumită grupă, an, facultate etc. au proprietăţi similare şi deci sunt membri ai aceluiaşi tip de entitate STUDENT.

Pentru mai multe apariţii ale aceleiaşi entităţi (mai mulţi studenţi ai aceleiaşi grupe), unul dintre atribute reprezintă în mod unic acea entitate şi se numeşte cheie primară (eng. primary key) a entităţii şi se notează cu sufixul „#”. Alegerea acestui atribut se face astfel încât să nu existe două atribute cu aceeaşi cheie primară.

De exemplu: atributele nume, prenume, data şi locul naşterii, nu identifică în mod unic un student. Rolul de cheie primară îl poate avea atributul Număr Matricol şi atunci acesta se notează prin Număr Matricol#.

Între entităţi, sau între entităţi şi atribute, sau între atribute, pot exista legături care se numesc relaţii (eng. relationships).

O bază de date se defineşte ca o colecţie de entităţi împreună cu relaţiile dintre ele.

BD au două forme în care există: BD fizice - formele de înregistrare a informaţiilor pe suportul tehnic, adică

modul în care ele sunt organizate în directoare şi fişiere; BD logice - informaţiile şi modul lor de organizare, independent de felul în

care are loc memorarea pe suportul tehnic.De exemplu, BD a studenţilor prezentată anterior are următoarele forme:

fizică, în care se cunoaşte faptul că informaţiile sunt păstrate în fişiere cu acces secvenţial aflate pe harddisk sub un anumit nume de fişier şi exploatate folosind programe Pascal, compuse din înregistrări (record);

logică, în care se cunoaşte faptul că entităţile au atributele Nume şi Prenume care conţin informaţii alfabetice, Anul de studiu care conţine informaţii numerice etc.Gestionarea datelor reprezintă toate activităţile care determină ca datele de

o înaltă calitate să fie disponibile pentru a produce informaţia şi cunoştinţele dorite.O implementare eficientă a gestionării BD se face folosind un sistem de

gestiune a bazelor de date (SGBD).Dacă în mediul de lucru tradiţional, orientat spre fişiere şi proceduri, datele

trec de la un program la altul pentru a fi prelucrate pot apărea următoarele probleme: de consistenţă: dacă un fişier poate fi accesat de mai mulţi utilizatori pentru

operaţii diferite, este posibil ca fiecare utilizator să dorească exploatarea în scopuri diverse. Când un fişier poate fi accesat de mai mulţi utilizatori pentru operaţii diferite, este posibil ca un utilizator să actualizeze o anumită

9

informaţie chiar în momentul când alt utilizator citeşte acea informaţie ceea ce duce la o informaţie eronată pentru al doilea utilizator. De exemplu, dacă la secretariat se extrage lista studenţilor care au restanţe la achitarea taxei chiar în momentul când unul din restanţieri plăteşte este posibil ca el să figureze cu restanţă deşi tocmai a plătit taxa;

de corelaţie: dacă un fişier poate fi accesat de mai mulţi utilizatori pentru operaţii diferite, este posibil ca fiecare utilizator să dorească o codificare a anumitor câmpuri. De exemplu, identificarea unică a entităţii STUDENT se face la nivel de facultate prin câmpul număr matricol. La casierie sau bibliotecă însă, acest câmp nu este suficient, deoarece cu numărul matricol „1” există student la fiecare facultate a unei universităţi, deci este necesară o codificare care să ţină cont şi de facultate.Dacă se lucrează cu SGBD, datele nu sunt legate de aplicaţia care le

exploatează şi de aceea ele pot fi partajate astfel încât să poată fi exploatate simultan de mai mulţi utilizatori fără ca problemele de mai sus să apară.

Un SGBD trebuie să asigure:1. protejarea valorilor datelor prin controlul securităţii şi integrităţii datelor;2. partajabilitatea datelor, adică datele să poată fi folosite simultan de mai mulţi

utilizatori şi de mai multe aplicaţii;3. gestionarea datelor funcţie de semnificaţia lor şi nu funcţie de modalitatea de

memorare şi reprezentare a lor;4. gestionarea datelor funcţie de obiectivele organizaţiei de unde provin aceste

date;5. independenţa datelor, adică structura de memorare a datelor să nu se

modifice dacă se modifică aplicaţiile 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 îmbunătăţire a performanţei, prin posibilitatea de a

obţine aceleaşi rezultate chiar dacă datele sunt reorganizate.În urma abordării activităţii organizaţiei folosind BD apar îmbunătăţiri în ceea

ce priveşte: controlul datelor: modalitatea de a memora datele este optimizată prin

utilizarea unor standarde de implementare aceleaşi date pot fi transferate dintr-un SGBD în altul atunci când apar necesităţi de reorganizare;

accesibilitatea datelor: datele pot fi astfel combinate încât să ofere utilizatorului informaţiile care îi sunt necesare;

calitatea datelor: explotarea BD oferă utilizatorului posibilitatea de a extrage cele mai bune soluţii pentru rezolvarea problemelor organizaţiei;

partajarea datelor: datele nu mai sunt redundante ceea ca reduce posibilitatea apariţiei erorilor de consistenţă; în plus, accesul la date este mai rapid iar spaţiul de memorare necesar este mai redus;

siguranţa datelor: un SGBD oferă soluţii pentru prevenirea apariţiei erorilor şi pentru refacerea datelor afectate de eroare;

securitatea datelor: SGBD permit prevenirea accesului neautorizat la date folosind mecanisme mai mult sau mai puţin restrictive, evident funcţie şi de conţinutul informaţiilor respective;

performanţa: folosirea SGBD permite obţinerea de informaţii din BD într-un timp scurt (deci cu o eficienţă mare) dar aceste informaţii pot răspunde mai mult sau mai puţin nevoilor utilizatorului (deci au o anumită efectivitate).Totuşi, folosirea unui SGBD implică pentru utilizator anumite costuri legate de:

tehnologia SGBD: achiziţionarea unui SGBD depinde mult de preţul acestuia: de exemplu, licenţa Microsoft Access (parte componentă a pachetului

10

Microsoft Office) este circa 300 USD pentru fiecare calculator; licenţa Oracle pentru 10 posturi de lucru este circa 5000 USD;

operarea BD: utilizarea SGBD înseamnă costuri cu exploatarea calculatoarelor, cu achiziţionarea şi întreţinerea suporţilor de informaţii şi a programelor de exploatare a BD;

conversie: trecerea de la un alt sistem la cel bazat pe BD presupune transformări legate de suporţii tehnici şi modalitatea de memorare, ca şi transformarea programelor de exploatare;

planificare: construirea unei BD la nivelul întregii organizaţii poate fi complexă (de exemplu BD a studenţilor unei universităţi) şi de aceea trebuie efectuată o planificare a etapelor de trecere la BD;

risc: este posibil ca implementarea eronată a BD să nu aducă îmbunătăţirea activităţii organizaţiei respective şi să nu justifice cheltuielile efectuate.Un alt aspect al utilizării unui SGBD este acela al personalului care va asigura

efectivitatea BD: utilizatorii vor folosi BD şi de aceea trebuie să ajute la definirea cerinţelor BD; analiştii traduc cerinţele utilizatorilor în modalităţi de organizare şi gestionare

a datelor; programatorii generează codul de gestionare a BD; administratorii asigură gestionarea şi controlul utilizării BD. Se deosebesc

administratorii BD (ABD; eng. data base administrator DBA) care răspund de proiectarea fizică a BD şi administratorii de date (AD; eng. data administrator DA) care răspund 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 încât să corespundă structurii de mai sus.La nivelul exterior, utilizatorii sunt aceia care, interesaţi fiind de o parte a BD,

cea care le poate oferi informaţiile dorite, nu trebuie să cunoască modul în care datele sunt memorate fizic pe suporţii de informaţie. De aceea, această viziune a utilizatorilor individuali se numeşte vedere externă.

Nivelexterior

Utilizator 1

Utilizator 2 ......

Utilizator n

Nivel conceptual Comunitatea utilizatorilor

11

Nivelintern Memorarea datelor

Figura 2.1. Nivelele bazei de date

De exemplu, la casieria universităţii este disponibilă BD care conţine, pe facultăţi, specializări şi ani de studii, toţi studenţii (numele şi prenumele, numărul matricol), fără a avea acces la datele personale ale studenţilor sau rezultatele la examene, care şi ele fac parte din BD.

Din acest motiv, se consideră că vederea externă este compusă din mai multe înregistrări externe (înregistrări logice), conţinutul lor depinzând de necesităţile utilizatorului care le foloseşte.

Vederea externă este definită cu ajutorul unei scheme externe care reprezintă definiţiile pentru fiecare din variantele de înregistrări externe din vederea externă.

Pentru descrierea schemei externe utilizatorul foloseşte un limbaj pe care îl cunoaşte (fie de programare, fie orientat spre BD) care se numeşte limbaj de definiţie date (LDD; eng. Data Definition Language DDL). Deoarece face referire la schema externă, limbajul se mai numeşte LDD extern.

Pentru a trece de la schema (de la vederea) externă la cea conceptuală este necesară o transformare, iar operaţia de trecere se numeşte mapare extern-conceptual.

Vederea conceptuală este o reprezentare a întregii informaţii din întreaga BD, indiferent de utilizatorul care are nevoie de aceste informaţii. Nici la acest nivel nu este necesar a se cunoaşte modul în care datele sunt memorate fizic pe suporţii de informaţie şi de aceea această viziune a ansamblului utilizatorilor se numeşte vedere conceptuală.

Se consideră astfel că vederea conceptuală este compusă din mai multe înregistrări conceptuale, conţinutul lor depinzând de necesităţile tuturor utilizatorilor.

În exemplul anterior, înregistrările conceptuale conţin atât datele de identificare a studenţilor, cât şi situaţia la examene, prezenţa la orele de curs şi seminar (laborator), situaţia taxelor, a cărţilor împrumutate de la bibliotecă etc.

Vederea conceptuală este definită la rândul ei folosind o schemă conceptuală care reprezintă definiţiile pentru fiecare din variantele de înregistrări conceptuale.

Pentru descrierea schemei conceptuale se foloseşte de asemenea un LDD şi cum acesta face referire la schema conceptuală, limbajul se numeşte LDD conceptual.

La acest nivel (conceptual) definiţiile 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 operaţie de transformare numită mapare conceptual-intern.

Nivelul intern corespunde vederii interne, cea care constă în apariţia unor înregistrări interne (înregistrări memorate) care sunt memorate într-un spaţiu liniar infinit; totuşi încă nu se poate vorbi de înregistrările fizice (nume de fişiere, compunerea articolului, modul de adresare, restricţii de mărime etc.) deoarece acestea depind de implementarea (limbajul) aleasă.

12

Şi vederea internă este descrisă printr-o schemă internă, care defineşte tipurile de înregistrări interne, modul de reprezentare a câmpurlor memorate, indecşii utilizaţi, etc.

Pentru descrierea schemei interne se foloseşte un limbaj care se numeşte LDD intern.

În transformarea datelor de la nivelul extern la cel intern, ele suferă două transformări. Maparea extern-conceptual defineşte corespondenţa dintre vederea externă şi cea conceptuală, reunind toate vederile externe şi eliminând redundanţele pentru a obţine vederea conceptuală. Maparea conceptual-intern defineşte corespondenţa între vederea conceptuală şi baza de date memorată, specificând modul în care câmpurile şi înregistrările au corespondent în datele memorate.

Utilizatorii, pe lângă sarcina de a defini datele de care au nevoie, trebuie să şi utilizeze aceste date. Pentru prelucrarea datelor ei au la dispoziţie un limbaj numit limbaj de manipulare date (LMD; eng. Data Manipulation Language DML).

Aceste concepte teoretice au fost particularizate în două variante, de către organismele care au efectuat cercetări asupra BD.

2.2.1 Arhitectura unui sistem de gestiune a bazelor de date în concepţia CODASYL

Program al aplicaţiei A

1 Subschema BD corespunzătoare

aplicaţiei A

910

2 Buffere sistem

8

SGBD

3

Schema BD

5 4

6 Sistem

de operareDescrierea fizică a BD

7

BD

Figura 2.2. Arhitectura unui SGBD în concepţia CODASYL

În concepţia CODASYL, un SGBD are arhitectura din Figura 2.2 iar un program de aplicaţie generează următoarele operaţii:1. programul de aplicaţie A lansează către SGBD o cerere de citire date din BD;

13

2. SGBD interpretează cererea prin consultarea Subschemei BD ce corespunde aplicaţiei A;

3. SGBD cere de la schema BD datele logice solicitate;4. SGBD examinează descrierea datelor fizice faţă de cele logice şi determină

poziţionarea datelor pe suportul de informaţie;5. SGBD lansează către sistemul de operare o cerere de căutare a înregistrării

fizice;6. sistemul de operare caută înregistrarea fizică;7. înregistrarea găsită este transferată în buffer;8. SGBD identifică datele cerute de program prin extragerea lor din Schema BD,

conform cerinţelor specifice Subschemei ce corespunde aplicaţiei A;9. datele sunt transferate de SGBD în zona de lucru a aplicaţiei A;10. aplicaţia A preia datele şi efectuează operaţiile dorite, informând SBGD despre

reuşita operaţiei de citire.

2.2.2 Arhitectura unui sistem de gestiune a bazelor de date în concepţia ANSI/SPARC

Administrator firmă

1

Administratorul 3 Procesorul sche- 3 Administratorul BD mei conceptuale aplicaţiei

6 2 4 Procesorul 7 Dicţionar 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 aplicaţie interne aplicaţie externe

15 13 Procesor Programator de sistem de aplicaţie

Figura 2.3. Arhitectura unui SGBD în concepţia ANSI/SPARC

În concepţia ANSI/SPARC, un SGBD are arhitectura din Figura 2.3 iar interfeţele între componente şi utilizatori funcţionează astfel:1. în baza cererilor administratorului firmei se realizează declararea schemei

conceptuale;2. schema conceptuală este tradusă în dicţionarul de date;3. schema conceptuală este adusă la cunoştinţa ABD şi administratorilor de

aplicaţii;14

4. se specifică declaraţiile schemelor externe;5. declaraţiile schemelor externe se memorează în dicţionarul datelor;6. se specifică declaraţiile schemelor interne;7. declaraţiile schemelor interne se memorează în dicţionarul datelor;8. informaţiile solicitate pentru transformarea extern/conceptual sunt luate din

dicţionarul de date;9. informaţiile solicitate pentru transformarea conceptual/intern sunt luate din

dicţionarul de date;10. informaţiile solicitate pentru transformarea intern/memorie sunt luate din

dicţionarul de date;11. datele necesare execuţiei comenzilor sunt transmise între nivelele BD;12. comenzile necesare execuţiei programelor sunt transmise între nivelele BD;13. are loc comunicarea între programator respectiv utilizator şi SGBD;14. are loc compilarea şi execuţia programului utilizatorului folosind schema

externă;15. traducerea cererilor pentru cazul efectuării de schimbări la structura de

memorare sau strategia de acces;16. execuţia schimbărilor 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 concepţiei de organizare a datelor (ele vor fi detaliate în capitolele următoare):-SGBD cu structuri ierarhice;-SGBD cu structuri reţea;-SGBD relaţionale;-SGBD orientate obiect;

după criteriul localizării BD:-SGBD centralizate - datele se găsesc pe acelaşi calculator;-SGBD distribuite - datele se găsesc pe calculatoare diferite, aflate chiar la distanţe foarte mari unele de altele.

2.4 PROIECTAREA ŞI MODELAREA BAZELOR DE DATE

Intervalul de timp de la apariţia unei cereri de realizare a unei BD şi până 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 cât sistemul este exploatat constituie ciclul de exploatare. Întreaga problemă a conducerii organizaţiilor este tot mai mult asimilată

15

activităţilor şi proceselor de orice natură în care criteriile determinante de evoluţie sunt cele legate de eficienţa şi profitabilitatea realizărilor. În scopul încadrării acţiunilor într-o concepţie sistemică, în conformitate cu standardele naţionale şi internaţionale, î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.

Fiecare nivel de abstractizare atins în ciclul de viaţă are ca şi corespondent o anumită generaţie a sistemului, iar în cadrul unei generaţii se pot delimita mai multe versiuni ale sistemului informatic. În cadrul fiecărei versiuni a sistemului, pot fi definite etape (secvenţe, faze) de activităţi, care astfel devin prin particularizare faze ale ciclului de viaţă. Acest ciclu presupune două perioade principale de funcţionare: proiectarea şi realizarea sistemului în care se defineşte conceptual şi tehnic

sistemul şi se elaborează documentaţia de proiectare, exploatare şi întreţinere, în vederea punerii sistemului în funcţiune la nivelul organizaţiei;

exploatarea sistemului, care este acea parte a ciclului de viaţă în care sistemul este folosit efectiv pentru prelucrarea automată a datelor provenind de la organizaţie.

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 următoarele concepte: fiecare etapă se încheie prin trecerea unei probe de validare, având ca scop

eliminarea eventualelor deficienţelor care au apărut în cadrul etapei respective; când deficienţele au fost eliminate sau nivelul lor de gravitate este acceptabil, se trece la etapa următoare, altfel etapa se reia;

când deficienţele semnalate impun revenirea la etape precedente, aceasta se poate face numai la etapa imediat anterioară;

ultima etapă are rol de întreţinere şi se referă doar la întreţinerea, corectarea şi actualizarea versiunilor, pe baza deficienţelor semnalate, de către beneficiari, în exploatare.

Pe baza conceptelor prezentate anterior, un sistem de BD, văzut ca sistem compus din calculator (hardware), programe (software) şi echipamente auxiliare, împreună cu utilizatorii şi datele acestora, va evolua prin trecerea pe rând prin etapele prezentate în continuare.

În cadrul fiecărei etape în parte au loc următoarele activităţi specifice:1. definirea cerinţelor sistemului. În această etapă, sistemul este privit ca o cutie neagră, căreia i se furnizează date de intrare şi care generează rezultatele obţinute în urma prelucrării lor. Pentru sistem se definesc clasa problemelor ce trebuie realizate, care sunt cerinţele strict necesare, care sunt criteriile după care au loc calculele şi optimizările etc.2. studiul de fezabilitate. Se pleacă de la formularea unei cereri ce exprimă clar cerinţele (funcţiile) ce trebuie realizate de sistem. Apoi se face un studiu ce stabileşte modul de realizare a fiecărei cerinţe în parte, cu determinarea necesităţilor de natură hard şi soft pentru funcţia respectivă şi rezultatele care s-ar putea obţine, alături de cheltuielile necesare.3. analiza sistemului existent. Constă în revederea documentaţiei sistemului, a posibilităţilor hard şi soft utilizate la momentul respectiv, de unde rezultă deficienţele şi insuficienţele sistemului existent.4. definirea arhitecturii funcţionale a sistemului. În această etapă se stabilesc funcţiile de bază pe care trebuie să le rezolve sistemul, rezultând o listă de funcţii de realizat şi o mulţime (de date, informaţii) asupra căreia acţionează aceste funcţii. Presupune pe de o parte definirea necesităţilor de calculatoare, pe de altă parte a necesităţilor de programe.

16

5. proiectarea arhitecturii funcţionale a sistemului. Cuprinde proiectarea modului în care sistemul rezolvă fiecare funcţie în parte, prin stabilirea componentelor noului sistem (subsisteme şi unităţi funcţionale). De aici rezultă concluzii despre necesităţile hard şi soft, ca şi modul în care diferitele funcţii interacţionează între ele.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 părţi ale funcţiilor sistemului şi se defineşte modul de lucru al funcţiilor 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 obţinut (utilizând date de test) şi se elimină erorile ce apar, atât la module în parte cât şi la interacţiunea dintre module (ce pot apare de exemplu datorită faptului că module diferite sunt proiectate şi codificate de programatori diferiţi). Integrarea se poate face prin tehnica top-down sau tehnica bottom-up. În paralel se elaborează şi documentaţia de execuţie ş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 recepţia sistemului, verificând respectarea specificaţiei de definire a acestuia şi existenţa tuturor condiţiilor necesare exploatării curente. Chiar şi în această etapă mai pot apare erori, de aceea ele vor fi analizate şi se vor elabora soluţii de remediere, ce vor fi aplicate în variantele ulterioare ale sistemului.9. operarea. În această etapă, ce durează de regulă până la încetarea utilizării sistemului, are loc utilizarea sa de către beneficiar, rămânând valabilă observaţia despre erori de la etapa anterioară.

Proiectarea BD este o operaţie 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 următoarele supoziţii:

calculatoarele şi utilizatorii văd datele în moduri diferite; diferiţi utilizatori au nevoie de diferite părţi din BD; când utilizatorii schimbă modul în care au nevoie să vadă BD, acest lucru nu

trebuie să influenţeze modul de lucru; utilizatorii nu pot fi împiedicaţi de către calculator să vadă datele aşa 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 văzute 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 fişiere,

17

articole, adresare secvenţială etc.). În mod corespunzător există schemele externe, care conţin vederile utilizator ale uneia sau mai multor aplicaţii şi schemele interne, care conţin vederile de implementare a datelor.

Între cele două scheme există o legătură care se realizează prin operaţia de mapare (transformare) între vederea utilizator şi vederea de implementare.

Această mapare se poate face direct, atunci când fiecare schemă internă este mapată direct pe BD. Metoda este necorespunzătoare deoarece atunci când se restructurează o BD, ca răspuns la nevoile unei scheme externe, celelalte scheme externe ar putea suferi; chiar şi invers, la schimbarea unei scheme externe sunt necesare schimbări ale tuturor BD implicate.

O altă variantă de mapare foloseşte o schemă conceptuală (vederea comunităţii, vederea întreprinderii) inserată între vederea utilizator şi cea de implementare, ceea ce previne neajunsurile prezentate anterior, aşa cum s-a prezentat şi în paragraful anterior.

Atunci când sistemul care trebuie realizat se bazează pe utilizarea BD, modelul ciclului de viaţă prezentat la începutul acestui paragraf suferă unele modificări impuse de necesitatea implementării BD şi software-ul utilizator pe baza unei scheme conceptuale. Etapele (fazele) ce trebuie parcurse când se utilizează BD sunt atunci următoarele: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 schiţei cu specificaţiile tranzacţiilor BD;3. prototiparea: proiectarea structurii BD fizice pentru prototipul iniţial al BD, utilizarea prototipului prin încărcarea şi validarea vederilor utilizator, definirea tranzacţiilor cerute, dezvoltarea acestora şi transformarea prototipului în starea de lucru;4. integrarea: combinarea modelelor de date logice prototip cu schema conceptuală şi îmbunătăţirea mapărilor interscheme;5. reglajul: optimizarea structurilor BD fizice şi a componentei software;6. revizia: urmărirea ieşirilor proiectului şi transformarea prototipului din starea de pregătire în starea de producţie.

Toate aceste etape sunt parcurse de una sau mai multe echipe de proiect compuse din personal de prelucrare date şi din utilizatori, aceştia din urmă ajutând la determinarea relaţiilor şi a tranzacţiilor de date, având în vedere că ei sunt beneficiarii sistemului care se crează.

Deoarece o BD poate fi exploatată de mai mulţi utilizatori (adică mai multe proiecte), fiecare dintre aceştia trebuie să determine care din informaţiile deja existente, în părţile folosite de alţi utilizatori, îi sunt utile şi ce informaţii suplimentare mai sunt necesare. Atunci schema conceptuală evoluează şi ea după cum evoluează proiectele suplimentare.

2.4.2 Modelarea datelor logice

Modelarea este operaţia de reprezentare matematică sau grafică a unui obiect sau sistem (numit prototip) care există în lumea reală, având ca obiectiv înţelegerea mai bună a prototipului, a modului său de funcţionare şi a modificărilor care apar atunci când au loc schimbări asupra stării sau funcţionării prototipului.

Modelele de date logice sunt reprezentări ale semnificaţiei datelor într-un domeniu de interes. Ele reprezintă entităţi (ceva din lumea reală despre care vrem să

18

păstrăm informaţii), atribute (o proprietate a unei entităţi) şi relaţii (legături între entităţi sau atribute).

Modelele de date logice vizează îndeplinirea următoarelor obiective: comunicarea semnificaţiei datelor. Ele sunt folosite pentru a indica ce

înseamnă datele respective. Oricine este familiar cu notaţia şi termenii utilizaţi înţelege care este semnificaţia acelor date;

descoperirea semanticii datelor. Ele sunt folosite pentru a indica semnificaţia datelor înregistrate, adică a înţelege acţiunile care decurg din valorile particulare ale datelor respective.Dacă modelarea datelor logice îndeplineşte cele două obiective precizate

anterior, atunci ea este utilă deoarece permite: înţelegerea datelor. Utilizatorii sunt aceia care spun la ce sunt folosite datele

şi care este rostul lor în cadrul organizaţiei, de aceea colectivul care realizează modelarea trebuie să fie format din cunoscători ai modelului respectiv;

documentarea datelor. În timpul modelării rezultă clar explicaţiile privind rolul datelor iar documentarea acestora face posibilă utilizarea mai multor colective de modelare în acelaşi timp;

evaluarea software-ului. Utilizatorul are la dispoziţie multe produse software care par a fi potrivite scopurilor sale. Alegerea celui mai bun (din toate punctele de vedere) se face uşor dacă programele sunt documentate cu un model de date logice;

planificarea sistemelor informatice. Utilizarea unui sistem informatic la nivelul întregii organizaţii presupune mai multe proiecte ce corespund diferitelor compartimente sau funcţiuni ale organizaţiei. 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 frecvenţelor de acces la date, care se obţine în timpul modelării de date logice;

integrarea resurselor de date. Modelele asigură o viziune de ansamblu la nivelul întregii organizaţii şi de aceea ele permit identificarea şi eliminarea inconsistenţelor şi a redundanţelor;

susţinerea proiectării BD fizice. Plecând de la modelul de date, colectivul de lucru obţine informaţii despre datele care sunt cuprinse în BD, relaţiile din interiorul BD şi dintre aceasta şi alte BD;

păstrarea consistentă a tehnicii. Există mai multe tehnici (procedee, metode) de modelare logică; dacă organizaţia păstrează aceeaşi metodă în întreaga sa activitate, atunci nu apar probleme de interacţiune între diferitele proiecte.Aşa cum s-a arătat mai sus, există mai multe tehnici de modelare logică.

Pentru a fi utile, ele trebuie să îndeplinească următoarele condiţii: producerea diagramelor grafice sub formă de dreptunghiuri sau cercuri

(pentru a reprezenta entităţile) şi linii sau arce (pentru a reprezenta relaţiile). Această condiţie se aplică numai tehnicilor bazate pe diagrame, deoarece mai există şi tehnici care se bazează pe utilizarea de instrucţiuni de limbaj;

posibilitatea reprezentării explicite a semanticii ceea ce înseamnă utilizarea de simboluri diferite pentru semantici diferite ale datelor. Aplicarea condiţiei poate duce la supraîncărcarea 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;

19

asigurarea independenţei SGBD-ului prin rezolvarea problemei fără a folosi particularităţi ale unui anumit limbaj;

includerea unui suport automatizat care să deseneze diagramele, să analizeze modelele de date, să elimine inconsistenţele şi redundanţele. Condiţia este doar parţial îndeplinită de tehnicile utilizate momentan.Modelele de date fizice reprezintă implementarea structurilor de date şi sunt

formate din fişiere, înregistrări, adrese, pointeri etc.Modelele de activitate reprezintă procesele care au loc în cadrul organizaţiei

şi relaţiile dintre aceste procese.

2.4.3 Triada entităţi – atribute – relaţii

Aşa cum s-a arătat şi în paragraful 2.1, cele trei concepte de bază în modelarea datelor sunt entitatea, atributul şi relaţia.

Entitatea reprezintă informaţiile despre un anumit obiect, fie el real sau imaginar. Indiferent dacă obiectul este real sau imaginar, el are o semnificaţie reală (înseamnă ceva pentru utilizator) şi de aceea tehnica de modelare utilizată nu trebuie să facă distincţie între entităţile reale şi abstracte.

Ca reprezentare grafică, entitatea este un dreptunghi care are înscris deasupra numele entităţii urmat eventual de un slash şi un număr de etichetă.

Entitatea este doar o definiţie a datelor pe care utilizatorul le are la dispoziţie. Datele concrete sunt particularizări ale entităţii şi se numesc ocurenţe sau instanţe.

Atributul este o proprietate a unei entităţi; altfel spus, proprietăţile unei entităţi se numesc atribute.

De exemplu, fie BD numită STUDENT prezentată la 2.1:Numele: POPESCUPrenumele: MARIAPrenumele tatălui: IONPrenumele mamei: OANAData naşterii: 10.06.1980Locul naşterii: TIMIŞOARADomiciliul: TIMIŞOARA, STR. AUREL VLAICU NR. 7Facultatea: CALCULATOAREAnul de studiu: IINumăr matricol: 175

Atributele entităţii sunt: Numele, Prenumele, Prenumele tatălui, Prenumele mamei ş.a.m.d. Atunci când 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 spaţiului în numele unui atribut, altele nu permit folosirea literelor specifice limbii române. Vom păstra totuşi această scriere pentru uşurinţa exprimării.

Există o problemă legată de numele atributelor şi anume se presupune că două atribute cu acelaşi nume reprezintă acelaşi atribut sau aceasta este o eroare de inconsistenţă ori redundanţă. Dacă totuşi cele două atribute sunt diferite, atunci numele lor trebuie modificat (explicitat) sau atributele trebuie să apară în entităţi diferite.

STUDENT / 35 STUDENT / 3520

NumelePrenumelePrenumele tatăluiPrenumele mameiData naşteriiLocul naşteriiDomiciliulFacultateaAnul de studiuNumăr matricol

Figura 2.4. Reprezentarea unei entităţi (st) cu atributele sale (dr)

O ocurenţă a unei entităţi 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 aceeaşi cu un zero sau un spaţiu introdus voit în BD.

Valorile unui atribut pot fi parte a unui domeniu care determină mulţimea tuturor valorilor admisibile. Această mulţime poate fi definită prin enumerare sau prin limite de valori.

Unele atribute ale entităţii ar putea fi folosite pentru a deosebi diferite ocurenţele şi de aceea ele se numesc cheie candidată (uneori se foloseşte prescurtarea cheie). Cheia candidată poate fi cheie simplă (elementară) dacă este formată dintr-un singur atribut (de exemplu doar Număr Matricol) sau cheie compusă dacă este formată din mai multe atribute (de exemplu Numele+Prenumele+Data naşterii+Locul naşterii).

Dacă o BD are chei candidate, una dintre ele este selectată pentru a fi cheia primară (cu observaţiile 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 numărul cheii alternate (eng. alternate Key).

STUDENT / 35 STUDENT / 35Număr matricol# Număr matricol#NumelePrenumelePrenumele tatăluiPrenumele mameiData naşteriiLocul naşteriiDomiciliulFacultateaAnul de studiu

Numele (AK1, AK2)Prenumele (AK1,AK2)Prenumele tatăluiPrenumele mameiData naşterii (AK1)Locul naşterii (AK1)Domiciliul (AK2)FacultateaAnul de studiu

Figura 2.5. Reprezentarea unei entităţi (st) cu atributele sale (dr)

Relaţiile sunt asociaţii (funcţii) între entităţi şi sunt simbolizate prin linii sau arce între dreptunghiurile ce simbolizează entităţile.

Relaţiile între entităţi pot fi relaţii de conectare sau relaţii de categorie.Relaţia de conectare asociază entităţi diferite ale BD şi sunt caracterizate

printr-un verb care arată o acţiune şi o cardinalitate care arată câte din instanţele primei entităţi sunt legate de câte instanţe ale celei de-a doua entităţi. Pentru a

21

indica grafic faptul că o relaţie este de conectare, linia utilizată se încheie prin două puncte mari.

De exemplu, între entitatea STUDENT descrisă anterior şi entitatea EXAMEN (compusă din atributele Număr Matricol, Data, Cod Disciplină, Forma Examen, Nota), poate exista o relaţie 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. Relaţii de conectare mai-mulţi-la-mai-mulţi, de cardinalitate pozitivă, de cardinalitate exactă şi domeniu de cardinalitate

Cele patru tipuri de cardinalitate a relaţiilor de conectare sunt: mai-mulţi-la-mai-mulţi, când o instanţă din prima entitate este conectată la

mai multe instanţe din a doua entitate; se simbolizează doar prin verb; cardinalitate pozitivă, când o instanţă din prima entitate este conectată la cel

puţin o instanţă din a doua entitate; se simbolizează prin verb urmat de litera P;

cardinalitate exactă, când o instanţă din prima entitate este conectată la un număr exact de instanţe din a doua entitate; se simbolizează prin verb urmat de o valoare numerică;

domeniu de cardinalitate, când o instanţă din prima entitate este conectată la un număr de instanţe 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 relaţional şi o valoare numerică.De exemplu, între entităţile STUDENT şi EXAMEN ar putea exista cele patru

variante de relaţii de conectare (figura I.6): mai mulţi la mai mulţi, în care studentul are într-o anumită sesiune un număr

de examene; cardinalitate pozitivă, în care studentul are cel puţin un examen; cardinalitate exactă, în care studentul are un număr fix de examene adică 7; domeniu, în care studentul are un număr de examene cuprins între 5 şi 10.

Un caz particular de relaţie de conectare este relaţia 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 relaţie se simbolizează prin caracterul Z.

De exemplu, în relaţia dintre entitatea STUDENT şi entitatea CĂMIN conţinând repartiţia pe camere a studenţilor căminişti (cu atributele Facultate#, Număr Matricol#, Camera, Pat) este o relaţie zero-la-unu.

Probleme deosebite pune relaţia mai-mulţi-la-mai-mulţi pe care tehnicile de modelare trebuie să o rezolve (împartă, spargă) în mai multe relaţii unu-la-mai-mulţi.

22

Cele mai des utilizate relaţii sunt cele unu-la-mai-mulţi. La acestea, prima entitate se mai numeşte entitate tată, în timp ce relaţia a doua se mai numeşte entitate fiu (entitate copil).

Un atribut al unei entităţi care se găseşte în cheia primară a unei alte entităţi se numeşte atribut cheie străină.

De exemplu, între entităţile STUDENT şi EXAMEN prezentate mai sus, atributul Număr Matricol din STUDENT se găseşte ca atribut cheie în entitatea EXAMEN, care are cheia primară Număr Matricol+Cod disciplină+Data.

Când există mai mult de o relaţie între o pereche de entităţi, atributelor cheie străină li se asociază nume de roluri pentru a permite diferenţierea apariţiilor numelui de atibut.

De exemplu, dacă la un examen se susţine atât partea scrisă şi aplicativă, cât şi un proiect, deci în aceeaşi zi se înregistrează două note la aceeaşi disciplină, atributul Număr Matricol (devenit atribut cheie străină în entitatea EXAMEN) trebuie să primească nume diferite, cum ar fi Număr Matricol_examen şi Număr Matricol_proiect, altfel s-ar fi găsit două ocurenţe şi una dintre ele ar fi fost eliminată.

Între entităţile dintr-o relaţie de conectare poate exista o dependenţă de existenţă de forma: fiecare instanţă a entităţii fiu trebuie să aibă o instanţă corespondentă a entităţii tată.

De exemplu, nu poate exista ocurenţă în EXAMEN care să nu aibă corespunzător o ocurenţă în STUDENT, deoarece nu poate exista o notă la un examen fără studentul care a primit acea notă.

O altă dependenţă ce poate apărea la o relaţie de conectare este dependenţa de identificator de forma: entitatea fiu este dependentă de identificator de entitatea tată dacă şi numai dacă cheia primară a entităţii tată apare ca atribut cheie străină în entittatea fiu şi este complet conţinută în cheia primară a entităţii fiu.

De exemplu, între entitatea STUDENT (ca mai sus, inclusiv atributul Număr Matricol#) şi entitatea TAXE (cu atributele Cod Facultate#, Număr Matricol#, Data, Suma) există o dependenţă de identificator deoarece cheia primară a lui STUDENT apare ca atribut cheie străină în TAXE şi este complet conţinută în cheia primară a lui TAXE.

Ca şi contraexemplu, între entitatea CĂMIN (cu atributele Facultate#, Număr Matricol#, Camera, Pat) şi entitatea TAXE (având de această dată atributele Facultate, Număr Matricol#, Data, Suma) nu este o dependenţă de identificator deoarece atributul Facultate nu este cheie primară în TAXE.

Relaţiile de conectare cu dependenţă de existenţă sau de identificator trebuie să respecte o restricţie numită integritate referenţială conform căreia valorile atributelor de cheie străină într-o instanţă a entităţii fiu trebuie să fie egale cu valoarea cheii primare din instanţa corespondentă din entitatea tată. Cu alte cuvinte, nu poate exista o valoare a cheii din entitatea fiu căreia în entitatea tată să nu-i corespundă nici o instanţă.De exemplu, integritatea referenţială este satisfăcută între entităţile STUDENT şi EXAMEN atâta vreme cât atributul Număr Matricol#, luat ca cheie în EXAMEN, ia doar valori pentru care există ocurenţe în STUDENT; când se introduce un număr matricol al unui student neînregistrat în STUDENT, restricţia este violată.

Relaţiile de categorie sunt acelea care asociază entităţi similare şi se indică grafic aşa cum se prezintă în Figura 2.7. Diagrama unei relaţii de categorie conţine alături de linia ce reprezintă relaţia, un cerc şi numele atributului care generează dependenţa particulară a instanţei, atribut care se numeşte discriminator de subtip.

De exemplu, o instanţă a entităţii STUDENT poate indica un student la o facultate sau un student la un colegiu.

23

STUDENT

Facultate

Cod facultate

Colegiu

Figura 2.7. Relaţie de categorie

Dacă relaţiile de categorie au un singur discriminator de tip, atunci mulţimea relaţiilor poartă numele de clasă de categorii. În exemplul indicat, clasa de categorie are două relaţii.

Pot exista situaţii în care există mai mulţi discriminatori de tip şi deci mai multe clase de categorii.

De exemplu, entitatea STUDENT poate conţine atributul Situaţie Militară care poate lua valorile INAPT, RECRUT, REZERVIST, ACTIV. În această situaţie, relaţile se prezintă ca în figura 2.8.

STUDENT

Cod facultate Situaţie militară

Facultate Colegiu Inapt Recrut Rezervist Activ

Figura 2.8. Entitate cu două ierarhii de categorii

Un discriminator de subtip trebuie astfel conceput încât să nu permită existenţa unei instanţe care apare în două clase de categorii.

De exemplu, o instanţă STUDENT nu poate fi simultan în două din situaţiile 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 numeşte totală.

O relaţie de categorie este întotdeauna dependentă de existenţă. Dacă se reia definiţia prezentată la relaţiile de conectare, aceasta înseamnă că pentru orice instanţă a unui subtip trebuie să existe o instanţă asociată a entităţii tată.

De exemplu, o ocurenţă care face referire la un student-rezervist nu poate exista dacă nu există ocurenţa corespunzătoare aceluiaşi student, deci o entitate STUDENT.

24

O relaţie de categorie poate să respecte complet dependenţa de identificator, adică atributul cheie primară a entităţii tată apare ca şi atribut cheie străină în entitatea fiu. În unele cazuri cheia primară poate fi doar parţial conţinută în entitatea fiu şi deci dependenţa nu este respectată.

De exemplu, între entitatea STUDENT (cu atributele Facultate#, Număr Matricol#) şi entitatea DIPLOMA (având atributele Număr Matricol#, Data, Tema Lucrării, Nota) nu este o dependenţă de identificator deoarece atributul Facultate nu este cheie primară în DIPLOMA.

În fine, o relaţie de categorie respectă întotdeauna restricţia de integritate referenţială adică o ocurenţă de entitate subtip are întotdeauna asociată o ocurenţă a entităţii tată pentru care valoarea cheii primare se potriveşte cu valoarea atributului cheie străină a subtipului.

25

Capitolul IIICapitolul IIIMODELUL RELAŢIONAL DEMODELUL RELAŢIONAL DE

GESTIUNE A BAZELOR DE DATEGESTIUNE A BAZELOR DE DATE

3.1 MODELUL RELAŢIONAL

3.1.1 Prezentare generală

Modelul relaţional al BD a fost propus în 1970 de către E. F. Codd şi se bucură de următoarele avantaje:

simplitatea reprezentării. Acest model poate fi uşor modelat şi implementat deoarece vede datele ca şi când ar fi aranjate în tabele, având drept coloane atributele iar drept linii valorile acestor atribute;

independenţa reprezentării. Acest model realizează o independenţă a datelor deoarece desparte aplicaţiile program de reprezentarea datelor şi astfel utilizatorii nu au legătură cu organizarea BD fizice;

rigoarea reprezentării. Fiind bazat pe un model matematic foarte puternic, sunt excluse problemele de redundanţă şi inconsistenţă.Modelul relaţional se bazează pe următoarele şase componente structurale:

relaţii, atribute, domenii, tuple, chei şi reprezentări.Relaţiile sunt tabele care au nume şi conţin linii şi coloane. Numărul de

coloane al tabelei se numeşte gradul relaţiei (aritatea relaţiei). Structura relaţiei (adică atributele sale sau capul de tabel) se mai numeşte intensiunea relaţiei. Valorile atributelor (adică datele conţinute în tabel) alcătuiesc extensiunea relaţiei.

De exemplu, pentru păstrarea informaţiilor despre studenţii unei universităţi se poate construi relaţia din Figura 3.1 care este o relaţie 13-ară deoarece tabelul are 13 coloane.

Atributele unei relaţii sunt caracterizate printr-un nume (de exemplu Numele, Prenumele, Număr Matricol#). Semnificaţia atributelor nu se modifică dacă se modifică ordinea atributelor în cadrul relaţiei.

EVIDENŢA

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George

Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3

Marinescu

Liana Lu-cian

Eva 04.11.1979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Cal-cula-toare

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijn-ţe Ec.

II 602 2 141 2

Popes-cu

Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu

Cal-cula-

II 175 1 233 2

26

nr.7 toareVasiu Bogdan Mirce

aFloare 24.01.1

981Reşiţa Reşiţa, str.

Gării nr.3 ap.5

Calcu-latoare

II 188

Figura 3.1. Relaţia EVIDENŢA

Domeniile unei relaţii determină tipul şi eventual limitările valorilor atributelor. Tipurile sunt cele standard în reprezentarea datelor în calculator (numeric,

eventual cu diferenţierile întreg, real; caracter/şir de caractere; dată calendaristică/oră etc.). Mai multe atribute pot lua valori ale aceluiaşi domeniu (de exemplu Număr 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).

Limitările sunt condiţii pe care valorile atributelor trebuie să le îndeplinească pentru a fi introduse în relaţie. Există multe tipuri de limitări, cum sunt condiţia de numericitate (informaţia 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 acelaşi atribut) etc.

Tuplele sunt liniile dintr-o tabelă, adică elementele unei relaţii. Ele mai sunt numite şi înregistrări (eng. records).

Cheile unei relaţii sunt atribute după care tuplele se diferenţiază clar între ele; conform conceptelor generale de BD, există chei candidate dintre care se alege o cheie primară şi chei alternate, cu semnificaţiile întâlnite în capitolul I.

Reprezentările sunt modalităţile de a enumera componentele unei relaţii. Cea mai des utilizată reprezentare în BD relaţionale descrie relaţia prin numele său, urmat (între paranteze) de numele atributelor, dintre care cheia primară se indică prin subliniere.

De exemplu, relaţia EVIDENŢA de mai sus are reprezentarea:

Evidenţa (Numele, Prenumele, Prenumele tatălui, Prenumele mamei, Data naşterii, Locul naşterii. Domiciliul, Facultatea, Anul de studiu, Număr matricol#, Căminul, Camera, Patul)

Orice relaţie trebuie să satisfacă două aserţiuni (constrângeri) relaţionale: aserţiunea privind cheia primară: nici o componentă a valorii de cheie

primară nu poate fi nulă. Aceasta rezultă din definiţia cheii primare (capitolul I) care spune că aceasta trebuie să identifice în mod unic instanţa entităţii; dacă ea este nulă, instanţa nu poate fi identificată unic;

aserţiunea privind atributul de cheie străină: valoarea unui atribut de cheie străină trebuie să fie nulă sau egală cu valoarea cheii primare a unui anumit tuplu din relaţia tată. Aceasta rezultă din definiţia atributului de cheie străină şi din restricţia de integritate referenţială; dacă atributul cheie străină nu are echivalent în instanţa tată atunci aceasta nu poate fi identificată.

3.1.2 Regulile lui Codd

27

Avantajele foarte mari pe care modelul relaţional 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 redundanţa este minimă.

Pentru a respecta modelul relaţional, un SGBD trebuie să respecte un set de 13 reguli, propuse de Codd în 1985. Totuşi, o privire mai realistă a problemei arată că nu se pune problema neapărat dacă SGBD este sau nu relaţional, ci doar măsura în care el este relaţional adică respectă toate aceste 13 reguli.

Regulile indicate sunt [POP96]:Regula 1 – gestionarea datelor: un SGBD este relaţional dacă poate gestiona orice BD prin posibilităţi relaţionale.Regula 2 – reprezentarea informaţiei: un SGBD este relaţional dacă poate organiza orice BD sub formă de tabele (relaţii).Regula 3 – accesul garantat la date: un SGBD este relaţional dacă orice informaţie din BD poate fi regăsită prin expresia numele relaţiei+numele atributului+valoarea cheii primare.Regula 4 – reprezentarea informaţiei necunoscute: un SGBD este relaţional dacă permite definirea şi utilizarea valorii nul pentru informaţiile care încă nu sunt cunoscute.Regula 5 - dicţionarele de date: un SGBD este relaţional dacă asupra descrierii BD se pot efectua aceleaşi operaţii ca asupra datelor din BD (adică şi descrierea BD este tot un tabel).Regula 6 – limbajul de interogare: un SGBD este relaţional dacă el conţine cel puţin un LMD.Regula 7 – actualizarea vizualizării: un SGBD este relaţional dacă poate determina condiţile în care o vizualizare poate fi actualizată.Regula 8 – limbajul de nivel înalt: un SGBD este relaţional dacă nu obligă utilizatorul să caute informaţia dorită, într-o relaţie, linie cu linie.Regula 9 – independenţa fizică a datelor: un SGBD este relaţional dacă programele utilizatorilor nu depind de modul de memorare sau de acces la date.Regula 10 – independenţa logică a datelor: un SGBD este relaţional dacă programele utilizatorlor sunt transparente la modificările efectuate asupra datelor.Regula 11 – independenţa datelor din punct de vedere al integrităţii: un SGBD este relaţional dacă regulile de integritate sunt definite prin limbajul SGBD nu prin aplicaţiile utilizatorului.Regula 12 - independenţa datelor din punct de vedere al distribuirii: un SGBD este relaţional dacă faptul că datele sunt distribuite în reţea este transparent aplicaţiilor utilizatorului.Regula 13 – versiunea procedurală a SGBD: un SGBD este relaţional dacă orice componentă procedurală a SGBD respectă aceleaşi restricţii de integritate ca şi componenta relaţională.

Cum aceste reguli sunt foarte stricte, se pot utiliza criterii mai reduse care să indice gradul în care un SGBD este relaţional.

3.1.3 Normalizarea relaţiilor

28

Normalizarea este procesul reversibil prin care o relaţie este transformată într-o relaţie cu structură mai simplă [POP96].

Normalizarea trebuie să asigure îndeplinirea următoarelor cerinţe: conservarea datelor - relaţia finală să nu piardă din datele iniţiale; conservarea dependenţelor – relaţia finală să nu piardă din dependenţele

iniţiale; să fie o descompunere minimală - relaţia finală să nu fie conţinută într-o altă

relaţie.Normalizarea trebuie efectuată atunci când relaţiile utilizate posedă unul dintre

următoarele dezavantaje, numite de către Codd anomalii de actualizare [NAS00]: anomalia de ştergere, care se manifestă când datele care trebuie şterse fac

parte din tuple care conţin şi alte informaţii iar ştergerea lor ar duce la pierderea acestor informaţii;

anomalia de adăugare, care se manifestă când datele care trebuie adăugate fac parte din tuple care conţin şi informaţii care încă nu sunt cunoscute;

anomalia de modificare, care se manifestă când datele care trebuie modificate apar în foarte multe tuple.În funcţie de dependenţele care trebuie rezolvate în cadrul relaţiilor, prin

procesul de normalizare, relaţiile pot fi considerate în mai multe forme normale, incluse unele în celelalte ca în Figura 3.2.

FN1FN2

FN3FNBC

FN4FN5

Relaţie generalăFigura 3.2: Nivelele formelor normale

Prima formă normală (FN1, eng. First Normal Form 1NF)O relaţie este considerată ca fiind de prima formă dacă:

fiecare atribut conţine numai valori indivizibile (atomice); fiecare tuplu nu conţine atribute sau grupe de atribute repetitive.

O relaţie 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, DNumăr, DBloc, DScara, DApartament);Pasul 2. plasarea fiecărui atribut repetitiv într-o nouă relaţie (de exemplu, dacă atributele Numele şi Prenumele se repetă pentru a fi alături de câmpurile de note, de câmpurile de taxe, de câmpurile de cărţi împrumutate, pentru a putea realiza trei vederi utilizator diferite ce corespund necesităţilor studentului-de a vedea notele, contabilităţii-de a vedea taxele, bibliotecii-de a vedea circulaţia cărţilor, atunci se construiesc trei tabele distincte);Pasul 3. introducerea în schema fiecărei relaţii construită ca mai sus a cheii primare a relaţiei de unde s-a extras atributul respectiv (de exemplu, Numele şi Prenumele trebuie să se regăsească în cele trei noi relaţii construite ca mai sus);Pasul 4. stabilirea cheii primare a fiecărei relaţii construită ca mai sus să includă cheia primară a relaţiei iniţiale şi alte atribute necesare.

De exemplu, o relaţie aflată în FN1 care memorează cadrele didactice şi cursurile la care acestea predau, cu numele ÎNCADRARE, poate fi ca în figura II.3.

29

INCADRARE

Cod

#

Den

umire

Tip

curs

Cod

CD

1#

Num

eCD

1

Gra

dCD

1

Sal

arC

D1

Cod

CD

2#

Num

eCD

2

Gra

dCD

2

Sal

arC

D2

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. 25103 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 Năstase Al. Conf 150 2378 Popescu M. As. 25

Figura 3.3. Relaţie aflată în FN1

Se observă că această relaţie nu conţine atribute compuse (exceptând 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

Cod

#

Den

umire

Tip

curs

Cod

CD

1#

Sal

arC

D1

Cod

CD

2#

Sal

arC

D2

Cod

CD

#

Num

eCD

Gra

dCD

101 Algebră Obl 2018 200 2018 100 2018 Marinescu V. Prof.102 Arhitectură Obl 2315 200 2378 25 2270 Iliescu A. Prep103 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 Năstase Al. Conf

Figura 3.4. Relaţia din Figura 3.3 adusă în FN2

A doua formă normală (FN2, eng. Second Normal Form 2NF)O relaţie 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 relaţie care nu este în FN2 se poate aduce în această formă prin

descompunerea relaţiei în mai multe relaţii pentru a elimina redundanţele. De exemplu, relaţia din Figura 3.3 nu este în FN2 deoarece conţine

redundanţe; aducerea ei în FN2 se face construind două relaţii, una care conţine date despre cursuri şi alte despre cadrele didactice, ca în figura II.4.

A treia formă normală (FN3, eng. Third Normal Form 3NF)O relaţie este considerată ca fiind de a treia formă normală dacă:

30

este în FN2; orice atribut care nu intră în compunerea cheii primare, depinde direct de

cheia primară.O relaţie care nu este în FN3 se poate aduce în această formă prin

descompunerea relaţiei în mai multe relaţii pentru a elimina dependenţele funcţionale tranzitive, adică prin construirea unei relaţii în care se regăsesc atributele care depind indirect de alte atribute.

SALARIZARE1 SALARIZARE2

Cod

cur

s#

Gra

dCD

1#

Sal

arC

D1

Cod

cur

s#

Gra

dCD

2#

Sal

arC

D2

101 2018 200 101 2018 100102 2315 200 102 2315 25103 2375 100 103 2375 50104 2018 150 104 2018 15105 2974 150l 105 2974 25

Figura 3.5. Relaţia 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 opţionale şi deci valoarea câmpului SalarCD1 depinde de Tip Curs (care depinde de Cod#) şi GradCD1 (care depinde de CodCD1#). Se poate atunci trece relaţia CURSURI din forma FN2 în FN3 prin descompunerea relaţiei ca în Figura 3.5.

Forma normală Boyce-Codd (FNBC, eng. Boyce-Codd Normal Form BCNF)

O relaţie 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 relaţie care nu este în FNBC se poate aduce în această formă prin

descompunerea relaţiei în mai multe relaţii pentru a elimina atributele care depind de atribute non-cheie, adică prin construirea unei relaţii în care se regăsesc 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”, deşi CodCD1# are valori diferite („2018” respectiv „2315”). Situaţia se datorează faptului că cele două valori pentru CodCD1 corespund la două ocurenţe similare din TITULARI, în sensul că ambele aparţin 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 relaţie este considerată ca fiind de a patra formă normală dacă:

este în FNBC;31

nu conţine relaţii m:n independente.O relaţie care nu este în FN4 se poate aduce în această formă prin

descompunerea relaţiei în mai multe relaţii care conţin fiecare atributul cheie şi câte un atribut din cele care depind direct de cheia respectivă.

ASOCIERE11 ASOCIERE12C

od c

urs#

Gra

dCD

1#

Tip

curs

Tip

curs

#

Gra

dCD

1#

Sal

arC

D1

101 2018 Obl Obl Prof. 200102 2315 Obl Obl Conf 150103 2375 Obl Obl Lect. 100104 2018 Opţ Obl As. 50105 2974 Obl Obl Prep null

Figura II.6: Relaţia din figura II.3 adusă în FNBC

LIMBAJE => LIMBAJE1 LIMBAJE2

Cod

CD

2#

Lim

baj

Cod

cur

s

Cod

CD

2#

Lim

baj

Cod

CD

2#

Cod

cur

s

2375 Word 103 2375 Word 2375 1032375 Pascal 104 2375 Pascal 2378 1052375 Pascal 105 3771 Pascal3771 Pascal 105 2378 C3771 Pascal 1042378 C 105

Figura 3.7: Figura 3.8: Relaţie redundantă Relaţia 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 redundanţei se face prin desfacerea relaţiei în alte două relaţii, în care CodCD2 apare alături de fiecare din celelalte atribute care iniţial dădeau problema de relaţie dependentă.

A cincea formă normală (FN5, eng. 5th Normal Form 5NF)O relaţie de tip FN5 este foarte rar întâlnită în practică, ea are mai mult un

aspect teoretic; relaţia este considerată ca fiind de a cincea formă normală dacă: este în FN4; nu conţine dependenţe ciclice.

O relaţie care nu este în FN5 se poate aduce în această formă prin eliminarea dependenţelor ciclice astfel: dacă dependenţa ciclică este între perechile de mulţimi (A, B), (B, C) şi (A, C), se crează relaţiile:R1(A:DomeniuA, B:DomeniuB), R2(B:DomeniuB, C:DomeniuC), R3(A:DomeniuA, C:DomeniuC)şi astfel valorile luate de cheile care forţau dependenţa ciclică sunt eliminate.

32

3.1.4 Operaţii şi operatori

Asupra relaţiilor pot fi aplicate operaţii de tip relaţional care au ca rezultat tot relaţii. Cei trei operatori relaţionali de bază sunt PROJECT, SELECT şi JOIN.

Operatorul PROJECT (proiecţie) formează o nouă relaţie prin extragerea (proiectarea) unor atribute dintr-o relaţie existentă. Dacă se notează relaţiile cu R1 şi R2 iar atributele cu A1, A2, ..., An atunci formula de definire este:

R2 := PROJECT (R1) (A1, A2, ...)sauR2 := PROJECT A1, A2, ... FROM R1

De exemplu, dacă se doreşte obţinerea unei evidenţe a repartizării studenţilor căminişti pe facultăţi şi ani de studiu, atunci se pleacă de la relaţia EVIDENŢA (figura II.1) şi se efectuează operaţia de extragere de forma:REPARTIŢIE := PROJECT (EVIDENŢA) (Facultatea, Anul de studiu, Căminul)sauREPARTIŢIE := PROJECT Facultatea, An de studiu, Căminul FROM EVIDENŢA

REPARTIŢIEFacultatea Anul de studiu Căminul

Ştiinţe Ec. I 2Calculatoare II 1Ştijnţe Ec. II 2Calculatoare II 1

Figura 3.9. Rezultatul operaţiei PROJECT (faza I)

REPARTIŢIEFacultatea Anul de studiu Căminul

Ştiinţe Ec. I 2Calculatoare II 1Ştijnţe Ec. II 2

Figura 3.10. Rezultatul operaţiei 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) (selecţia) formează o nouă relaţie prin extragerea (proiectarea) dintr-o relaţie existentă numai a liniilor care satisfac anumite criterii (condiţii). Formula de definire este:

R2 := SELECT (R1) (A1, A2, ...) (condiţie)sauR2 := SELECT A1, A2, ... FROM R1 WHERE condiţie

CĂMINIŞTI

33

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr. 8 ap.19

Ştiin-ţe Ec.

I 854 2 215 3

Marinescu

Liana Lucian Eva 04.11.1979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Calcu-lato-are

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijn-ţe Ec.

II 602 2 141 2

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-lato-are

II 175 1 233 2

Figura 3.11. Rezultatul operaţiei SELECT

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor căminişti, plecând de la relaţia EVIDENŢA (figura II.1), operaţia de extragere poate fi de forma:CĂMINIŞTI := SELECT (EVIDENŢA) (Căminul <> null)sauCĂMINIŞTI := SELECT Numele, Prenumele, Prenumele tatălui,

Prenumele mamei, Data naşterii, Locul naşterii, Domiciliul, Facultatea, Anul de studiu, Număr matricol, Căminul, Camera, Patul FROM EVIDENŢA WHERE Căminul <> null

şi rezultatul este ca în Figura 3.11.Observaţie: chiar dacă din exemplul indicat nu a rezultat astfel, şi operaţia SELECT elimină tuplele duplicate din noua relaţie.

Operatorul JOIN (compunere) formează o nouă relaţie prin extragerea (proiectarea) din două relaţii existente a liniilor care satisfac anumite criterii (condiţii). Formula de definire este:

R3 := JOIN (R1) (condiţie) (R2)

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor la facultăţile acreditate şi care pot da licenţa în cadrul universităţii, folosind relaţiile EVIDENŢA (figura II.1) şi ACREDITARE (figura II.12), atunci operaţia de extragere poate fi de forma:LICENŢĂ PROPRIE := JOIN (EVIDENŢA) (Facultatea = Denumirea) (ACREDITARE)

ACREDITARE

34

Denumirea Număr act legal Data act legalŞtiinţe Ec. 154 2002Drept 287 2002

Figura 3.12. Relaţia ACREDITARE

şi rezultatul obţinut este ca în Figura 3.13:

LICENŢĂ PROPRIE

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ulN

umăr

act

le

gal

Dat

a ac

t le

gal

Costin Ioan Geor-ge

Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3 154

2002

On-dea

Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijnţe Ec.

II 602 2 141 2 154

2002

Figura 3.13. Rezultatul operaţiei JOIN

unde se observă că noua relaţie are gradul 15 (ea a preluat atributele de la ambele relaţii din care s-a format).

Pe lângă cei trei operatori prezentaţi anterior, literatura de specialitate [POP96] mai oferă posibilitatea de a utiliza următoarele acţiuni:

Operatorul UNION (reuniune) formează o nouă relaţie prin proiectarea din două relaţii existente a unei reuniuni a liniilor care satisfac anumite criterii (condiţii) şi care pot aparţine fie primei relaţii, fie celei de-a doua, fie ambelor. Formula de definire este:

R3 := (R1) (condiţie1) UNION (R2) (condiţie2)sauR3 := SELECT A1, A2, ... FROM R1 WHERE condiţie1

UNION SELECT B, B, ... FROM R WHERE condiţie2

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor şi cadrelor didactice de la aceeaşi facultate, se foloseşte operaţia de reunire:R3 := SELECT Numele, Prenumele

FROM EVIDENŢA WHERE Facultatea = „Calculatoare” UNION SELECT Numele, Prenumele FROM PROFESORI WHERE Facultatea = „Calculatoare”

unde am considerat relaţia PROFESORI (Figura 3.15) ca având aceeaşi structură ca şi relaţia EVIDENŢA (Figura 3.14). Rezultatul obţinut este o relaţie ca în figura II.16.

35

Observaţie: relaţiile care intervin în operaţia UNION trebuie să aibă aceeaşi aritate şi aceeaşi ordine (nu numele) a atributelor.

EVIDENŢA (extras) PROFESORI (extras)

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Facu

ltate

a

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Facu

ltate

a

Costin Ioan George Ştiinţe Ec.

Anton Ileana Marian Calcula-toare

Marinescu

Liana Lucian Calcu-latoare

Achim Silvia Lica Calcu-latoare

Ondea Vasile Mihai Ştijnţe Ec.

Manea Mihai vasile Psiho-logie

Popescu Maria Ion Calcu-latoare

Popescu

Maria Ion Calcu-latoare

Vasiu Bogdan

Mircea Calcu-latoare

George Andrei Mihai Drept

Figura 3.14. Relaţia EVIDENŢA Figura 3.15. Relaţia EVIDENŢA

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Facu

ltate

a

Marinescu Liana Lucian Calcu-latoarePopescu Maria Ion Calcu-latoareVasiu Bogdan Mircea Calcu-latoareAnton Ileana Marian Calcula-toareAchim Silvia Lica Calcu-latoare

Figura 3.16. Relaţia R3 la operatorul UNION

Operatorul DIFFERENCE (diferenţă) formează o nouă relaţie prin proiectarea din două relaţii existente a liniilor care aparţin primei relaţii dar nu aparţin celei de-a doua. Formula de definire este:

R3 := (R1) DIFFERENCE (R2)sauR3 := DIFFERENCE (R1, R2)

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor care nu sunt căminişti, plecând de la relaţiile EVIDENŢA (Figura 3.1) şi CĂMINIŞTI (Figura 3.11), se foloseşte operaţia de diferenţă:NECĂMINIŞTI := DIFFERENCE (EVIDENŢA, CĂMINIŞTI)şi se obţine relaţia din Figura 3.17.

NECĂMINIŞTI

36

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Vasiu Bogdan Mircea Floare 24.01.1981

Reşiţa

Reşiţa, str. Gării nr.3 ap.5

Calcu-latoare

II 188

Figura 3.17. Relaţia NECĂMINIŞTI

Observaţie: relaţiile care intervin în operaţia DIFFERENCE trebuie să aibă aceeaşi aritate şi aceeaşi ordine a atributelor; numele atributelor nu este important pentru operator.

Operatorul INTERSECT (intersecţie) formează o nouă relaţie prin proiectarea din două relaţii existente a liniilor care aparţin ambelor relaţii. Formula de definire este:

R3 := (R1) INTERSECT (R2)sauR3 := SELECT A1, A2, ... FROM R1 WHERE condiţie1

INTERSECT SELECT B, B, ... FROM R WHERE condiţie2

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor (figura II.14) care sunt în acelaşi timp şi cadre didactice (Figura 3.15), se foloseşte operaţia de intersecţie:R4 := SELECT Numele, Prenumele

FROM EVIDENŢA INTERSECT SELECT Numele, Prenumele FROM PROFESORI

iar rezultatul este ca în Figura 3.18.Observaţie: relaţiile care intervin în operaţia INTERSECT trebuie să aibă aceeaşi aritate şi aceeaşi ordine a atributelor; numele atributelor nu este important.

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Facu

ltate

a

Popescu Maria Ion Calculatoare

Figura 3.18. Relaţia R4 la operatorul INTERSECT

37

Operatorul DIVISION (diviziune) formează o nouă relaţie prin proiectarea din două relaţii existente a liniilor pentru care valorile atributelor din prima relaţie apar în valorile atributelor celeilalte relaţii. Formula de definire este:

R3 := (R1) DIVISION (R2)sauR3 := DIVISION (R1, R2)

De exemplu, dacă se doreşte obţinerea unei evidenţe a studenţilor care parcurg două cursuri de limbi străine, se foloseşte operaţia de diviziune:

ÎNSCRIERI CURSURI

Numele Prenumele Număr matricol

Cod curs

Cod curs Denumire curs

Ionescu Maria 1223 107 107 EnglezaIonescu Maria 1223 108 108 GermanaPopescu Gheorghe 1245 107Popescu Gheorghe 1245 108Vasile Ana 1287 108

Figura 3.19. Operaţia DIVISION

DIVISION (ÎNSCRIERE, CURSURI)

care va avea ca rezultat studenţii având valorile câmpurilor Numele şi Prenumele: „Ionescu”, „Maria” respectiv „Popescu”, „Gheorghe”.

Operatorul PRODUCT (produs cartezian) formează o nouă relaţie prin proiectarea din două relaţii existente a liniilor pentru care primele m componente aparţin primei relaţii iar celelalte n componente aparţin celeilalte relaţii, unde m respectiv n sunt arităţile relaţiilor. Formula de definire este:

R3 := (R1) PRODUCT (R2)sauR3:= PRODUCT (R1, R2)

De exemplu, considerând relaţiile EVIDENŢA şi ACREDITARE ca în exemplele anterioare (figurile II.1 şi II.12), o nouă relaţie se poate scrie prin produsul lor cartezian:PRODUCT (EVIDENŢA, ACREDITARE)care ar fi un tabel cu 16 coloane (13 de la EVIDENŢA şi 3 din ACREDITARE) compus prin alăturarea celor două tabele iniţiale.

3.1.5 Proiectarea logică

Pentru definirea schemei pentru o BD relaţională se utilizează un LDD; dacă se utilizează (de exemplu) limbajul SQL atunci operaţiile de definire a structurii BD apelează la instrucţiunile CREATE TABLE, EXPAND TABLE şi DROP TABLE.

Instrucţiunea CREATE TABLE defineşte o relaţie prin indicarea, pentru fiecare atribut, a numelui, tipului datei şi domeniului, adică:

38

CREATE TABLE nume_tabel (A1 tip1 (domeniu1) [restricţie1], A2 tip2 (domeniu2) [restricţie2], ..... An tipn (domeniun) [restricţien]);

De exemplu, definirea relaţiei EVIDENŢA prezentată anterior se face prin instrucţiunea:CREATE TABLE Evidenţa (Numele varchar(20) not null, Prenumele varchar(20) not null, Prenumele tatălui varchar(20), Prenumele mamei varchar(20), Data naşterii date, Locul naşterii varchar(20), Domiciliul varchar(40), Facultatea varchar(20) not null, Anul de studiu number(1), Număr matricol# number(3) not null primary key, Căminul number(3), Camera number(3), Patul number(3));

Instrucţiunea EXPAND TABLE (sau ALTER TABLE) adaugă la o relaţie existentă un nou atribut, prin indicarea numelui, tipului datei şi domeniului, adică:

EXPAND TABLE nume_tabel ADD COLUMN An+1 tipn+1 (domeniun+1) [restricţien+1];

sauALTER TABLE nume_tabel

ADD COLUMN An+1 tipn+1 (domeniun+1) [restricţien+1];

De exemplu, adăugarea la relaţia EVIDENŢA prezentată anterior a atributului Stare Civilă se face prin instrucţiunea:ALTER TABLE Evidenţa ADD COLUMN Stare civilă char;

Instrucţiunea DROP TABLE elimină o relaţie existentă:

DROP TABLE nume_tabel;

Pentru definirea unei vederi a relaţiei se utilizează instrucţiunea DEFINE VIEW (sau CREATE VIEW) cu sintaxa:

DEFINE VIEW AS SELECT A1, A2, ... FROM relaţie [WHERE condiţie];sauCREATE VIEW AS SELECT A1, A2, ... FROM relaţie [WHERE condiţie];

De exemplu, pentru a obţine situaţia studenţilor la facultatea de calculatoare se poate defini vederea:CREATE VIEW AS SELECT Numele, Prenumele, Anul de studiu

39

FROM Evidenţa WHERE Facultatea = „Calculatoare”;

Pentru a defini o aserţiune despre o cheie a unei relaţii se utilizează instrucţiunea ASSERT cu sintaxa:ASSERT nume_aserţiune ON relaţie: atribut condiţie,

De exemplu, dacă universitatea are trei cămine, se poate defini aserţiunea (care aici este o definire a domeniului):ASSERT X1 ON Evidenţa: Căminul BETWEEN 1 AND 3;

Maparea dintr-un model de date logice pe un model relaţional este directă deoarece SGBD relaţionale permit efectuarea acestei operaţii, cu respectarea următoarelor reguli [DES99]:

entitate este reprezentată de o relaţie; un atribut al unei entităţi este reprezentat de un atribut al relaţiei; relaţie de conectare este reprezentată prin prezenţa unui atribut de cheie

străină în relaţia fiu.De exemplu, relaţia EVIDENŢA poate fi mapată astfel:

Facultăţi (Cod facultate#, Denumire facultate)Studenţi (Numele, Prenumele, Prenumele tatălui, Prenumele mamei, Data naşterii, Locul naşterii, Domiciliul, Cod facultate#, Anul de studiu, Număr matricol#)Cămine (Căminul#, Camera#, Patul#, Cod facultate#, Număr matricol#)

relaţiile de conectare între atribute sunt:

Este student (Cod facultate#, Denumire facultate, Număr matricol#)

în timp ce relaţiile de categorie (mai greu de implementat în modelul relaţional) sunt:

Stă în cămin (Căminul#, Camera#, Patul#, Cod facultate#, Denumire facultate, Număr matricol#)Stă în afară (Domiciliul#, Cod facultate#, Denumire facultate, Număr matricol#)

Modelul relaţional respectă dependenţa de identificator dar nu forţează restricţia de integritate referenţială.

3.1.6 Proiectarea fizică

Pentru ca o BD relaţională să poată fi implementată fizic, ea trebuie să fie: translatabilă în tabele. Aceasta înseamnă să permită utilizarea anumitor

structuri de date pentru fiecare relaţie. Cea mai simplă structură este de tip tabel (tablou) dar pot fi folosite şi listele înlănţuite, arborii etc., cu condiţia 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ţă specificând valoarea oricărui atribut al relaţiei, nu numai după cheia relaţiei;

să suporte operatori relaţionali. Aceasta înseamnă ca structura de date să suporte operaţiile SELECT, PROJECT şi JOIN fără ca utilizatorul să utilizeze explicit operaţii de adresare, pointeri sau adrese. Maparea unei relaţii logice într-o relaţie fizică se poate face prin următoarele

operaţii:40

partiţionarea verticală a unei tabele în mai multe relaţii de bază, fiecare conţinând o parte a atributelor iniţiale;

partiţionarea orizontală a unei tabele în mai multe relaţii de bază, fiecare conţinând o parte a tuplelor iniţiale;

reunirea mai multor tabele într-o singură relaţie de bază.Partiţionarea verticală presupune proiectarea atributelor unei relaţii în mai

multe relaţii, fiecare dintre acestea conţinând cheia primară pentru a permite reconstituirea tabelei originale. Operaţia se execută atunci când tabela are foarte multe coloane, când părţi diferite ale aceleiaşi BD sunt exploatate în locuri de muncă diferite ale aceleiaşi organizaţii, când unele coloane sunt actualizate foarte des faţă de altele sau când utilizatori cu diferite permisiuni de acces ar trebui să folosească întreaga BD.

De exemplu, relaţia EVIDENŢA de mai sus poate fi partiţionată vertical în două relaţii, un SECRETARIAT şi una ADMINISTRAŢIE, prima conţinând informaţiile generale despre studenţi iar cea de-a doua doar informaţiile despre studenţii cazaţi la cămin (figura 3.20).

Operaţia se bazează pe instrucţiunea PROJECT:Secretariat := PROJECT (Evidenţa) (Numele; Prenumele; Prenumele tatălui; Prenumele mamei; Data naşterii; Locul naşterii; Domiciliul; Facultatea#; Anul de studiu; Număr matricol#);EVIDENŢA

EVIDENŢA

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3

Marinescu

Liana Lucian Eva 04.11.1979

Timi-şoara

Timişoara str.1 Iunie nr.3

Calcu-latoare

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara Cl. Şagului nr. 201

Ştijnţe Ec.

II 602 2 141 2

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoarastr. A.Vlaicu nr.7

Calcu-latoare

II 175 1 233 2

Vasiu Bogdan Mircea Floare 24.01.1981

Reşiţa Reşiţa, str. Gării nr.3 ap.5

Calcu-latoare

II 188

SECRETARIAT

41

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854

Marinescu Liana Lucian Eva 04.11.1979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Calcu-latoare

II 130

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijnţe Ec.

II 602

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-latoare

II 175

Vasiu Bogdan Mircea Floare 24.01.1981

Reşiţa Reşiţa, str. Gării nr.3 ap.5

Calcu-latoare

II 188

ADMINISTRAŢIE

FacultateaNumăr

matricol# Căminul Camera Patul

Ştiinţe Ec. 854 2 215 3Calculatoare 130 1 233 1Ştijnţe Ec. 602 2 141 2Calculatoare 175 1 233 2

Figura 3.20. Partiţionarea verticală

Administraţie := PROJECT (Evidenţa) (Facultatea#; Număr matricol#; Căminul; Camera; Patul);

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George Iulia 15.091981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3

Marinescu

Liana Lucian Eva 04.111979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Calcu-latoare

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.101977

Timi-şoara

Timişoara, Cl.

Ştijnţe Ec.

II 602 2 141 2

42

Şagului nr. 201

Popescu Maria Ion Oana 10.061980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-latoare

II 175 1 233 2

Vasiu Bogdan Mircea Floare 24.011981

Reşiţa

Reşiţa, str. Gării nr.3 ap.5

Calcu-latoare

II 188

CĂMINIŞTI

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3

Marinescu

Liana Lucian Eva 04.11.1979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Calcu-latoare

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijnţe Ec.

II 602 2 141 2

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-latoare

II 175 1 233 2

EXTERNI

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Vasiu Bogdan Mircea Floare 24.01.1981

Reşiţa

Reşiţa, str. Gării nr.3 ap.5

Calcu-lato-are

II 188

Figura 3.21. Partiţionarea orizontală

Partiţionarea orizontală presupune proiectarea liniilor unei relaţii în mai multe relaţii, fiecare dintre acestea conţinând cheia primară pentru a permite reconstituirea tabelei originale. Operaţia se execută atunci când tabela are foarte multe linii, când linii diferite ale aceleiaşi BD sunt exploatate în locuri de muncă diferite ale aceleiaşi organizaţii sau când unele linii sunt accesate foarte des faţă de altele. Obţinerea BD originale se face prin reunirea BD partiţionate.

De exemplu, relaţia EVIDENŢA de mai sus poate fi partiţionată orizontal în două relaţii, una CAMINIŞTI şi una EXTERNI, prima conţinând informaţiile despre

43

studenţii care locuiesc în cămin iar cea de-a doua informaţiile despre studenţii din afara căminului (Figura 3.21).

Operaţia se bazează pe instrucţiunea SELECT:Căminişti := SELECT (Evidenţa) (Căminul <> null);Externi := SELECT (Evidenţa) (Căminul = null);

EVIDENŢA

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ul

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3

Marinescu

Liana Lucian Eva 04.11.1979

Timi-şoara

Timişoara, str.1 Iunie nr.3

Calcu-latoare

II 130 1 233 1

Ondea Vasile Mihai Aurica 25.10.1977

Timi-şoara

Timişoara, Cl. Şagului nr. 201

Ştijnţe Ec.

II 602 2 141 2

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-latoare

II 175 1 233 2

Vasiu Bogdan Mircea Floare 24.01.1981

Reşiţa

Reşiţa, str. Gării nr.3 ap.5

Calcu-latoare

II 188

TAXEFacultatea# Număr matricol# Procent achitare

Ştiinţe Ec. 854 100Calculatoare 130 0Ştijnţe Ec. 602 50Calculatoare 175 100Calculatoare 188 0

ACCEPTARE

44

Num

ele

Pre

num

ele

Pre

num

ele

tată

lui

Pre

num

ele

mam

ei

Dat

a na

şter

ii

Locu

l na

şter

ii

Dom

icili

ul

Facu

ltate

a

Anu

l de

stud

iuN

umăr

m

atric

ol#

Căm

inul

Cam

era

Pat

ulP

roce

nt

achi

tare

Costin Ioan George Iulia 15.09.1981

Lugoj Lugoj, str. Gării nr.8 ap.19

Ştiinţe Ec.

I 854 2 215 3100

Popescu Maria Ion Oana 10.06.1980

Timi-şoara

Timişoara, str. A.Vlaicu nr.7

Calcu-latoare

II 175 1 233 2100

Figura 3.22: Reunirea relaţiilorReunirea relaţiilor presupune proiectarea liniilor din mai multe relaţii într-una singură care conţine atribute extrase din toate relaţiile iniţiale, cu condiţia ca relaţiile să aibă un atribut comun. Operaţia se execută atunci când informaţiile respective sunt accesate de obicei împreună.

De exemplu, relaţia EVIDENŢA de mai sus poate fi reunită cu relaţia TAXE (Facultatea#, Număr matricol#, Procent achitare) pentru a determina care din studenţi se pot prezenta la examen folosind (Figura 3.22) instrucţiunea JOIN:Acceptare := JOIN (Evidenţa) (Procent achitare = 100) (Taxe)

Este evident că pentru utilizator timpul de acces la informaţiile din BD este un parametru important al eficienţei folosirii unui anumit sistem informatic, de aceea proiectarea fizică trebuie să asigure îmbunătăţirea performanţelor.

Accesul la atributele cel mai des folosite trebuie efectuat cu maximum de viteză, de aceea proiectantul va prevedea căi de acces rapid preconstruite. Tehnicile care se folosesc sunt cele cu structuri de indecşi (se păstrează localizarea liniilor ce corespund valorilor indecşilor) sau prin hashing pe valorile atributului.

Într-o BD relaţională, pentru atributele de cheie primară trebuie întotdeauna căi 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 străină pot fi construite căi de acces rapid preconstruite.

Uneori, deşi ar trebui să existe chei de acces rapid asociate unor atribute, acest lucru nu se implementează; sunt situaţiile când valorile acestor atribute se actualizează foarte des şi deci şi indexul sau hashingul se modifică permanent.

Reuniunile preconstruite sunt o altă metodă de mărire a vitezei de acces la datele din BD. Tehnicile care se folosesc sunt cele ale directoarelor cu valori atribut-reuniune (conţinând pointeri la liniile care se reunesc) sau ale listelor înlănţuite (conţinând pointerii de la liniile unei tabele la liniile celeilalte tabele).

De exemplu, se observă din analiza situaţiei şcolare anumite tipare în alegerea disciplinelor ca în Figura 3.23. Se poate atunci construi o relaţie folosind directoare ca în Figura 3.24 sau folosind liste înlănţuite ca în Figura 3.25.

LIMBI STRĂINE SPORT

45

Genul Disciplina Genul DisciplinaFeminin Franceză Feminin AerobicFeminin Germană Feminin ÎnotMasculin Engleză Masculin Fotbal

Masculin ÎnotMasculin Schi

Figura 3.23. Relaţiile LIMBI STRĂINE şi SPORT

Genul Disciplina-Limba străină Disciplina-SportFeminin Franceză AerobicFeminin Franceză ÎnotFeminin Germană AerobicFeminin Germană ÎnotMasculin Engleză FotbalMasculin Engleză ÎnotMasculin Engleză Schi

Figura 3.24. Reuniunile preconstruite reprezentate prin directoare

Genul Disciplina Primul SPORT cu valoarea GENUL

Feminin Franceză 1Feminin Germană 1Masculin Engleză 3

Genul Disciplina Următorul SPORT cu valoarea GENUL

Feminin Aerobic 2Feminin Înot 2Masculin Fotbal 0Masculin Înot 0Masculin Schi 0

Figura 3.25. Reuniunile preconstruite reprezentate prin liste înlănţuite

Gestionarea mărimii buffer-elor este o altă cale de îmbunătăţire a parametrilor de acces la BD. Cu cât buffer-ul de transfer între memoria principală şi cea secundară este mai mare, cu atât mai multe linii pot fi accesate simultan fără a necesita o nouă citire a memoriei secundare.

Şi gruparea relaţiilor de bază, adică a acelor relaţii care apar cel mai des între informaţii, poate aduce rezultate pozitive. Gruparea împreună a liniilor cu valori similare ale atributului după care se face accesul, după secvenţa FIFO sau LIFO, face ca pentru relaţia respectivă să nu se pierdă timp cu accese multiple la locuri diferite din BD.

Alegerea corectă a dimensiunii fişierelor, care poate fi un impediment permanent la viteza de execuţie a interogărilor, poate ajuta la performanţele BD când se fac actualizări masive sau se definesc relaţii noi. Dacă spaţiul ales este prea mic, eventualele reorganizări necesită timp şi consum de resurse; în acelaşi timp, un spaţiu excesiv înseamnă un surplus de plată a unei resurse care nu este utilizată.

46

CAPITOLUL IVCAPITOLUL IVIMPLEMENTAREA APLICAŢIEIIMPLEMENTAREA APLICAŢIEI

4.1 ARHITECTURA PROGRAMULUI

Aplicaţia J_MySQL_win este o interfaţă Java ce permite accesarea şi manipularea datelor dintr-o bază de date MySQL. Specificaţia de proiectare a cuprins prin urmare cerinţa de implementare a următoarelor operaţii:

SELECT * – afişarea tuturor datelor din tabel); SELECT – afişarea selectivă după ID; INSERT – inserarea de înregistrări noi; DELETE – stergerea unor înregistrări.

Figura 4.1. Structura aplicaţiei J_MySQL_win

Prin urmare arhitectura programului cuprinde din punct de vedere structural următoarele clase:

J_MySQL_win – clasa principala responsabilă de afişarea ferestrei principale cu bara de meniuri şi spaţiul de afişare a rezultatelor;

Cnx – clasa care asigură conexiunea la baza de date apelând la pachetele com şi org din secţiunea insert

Afiş – clasa care gestionează apariţia ferestrei secundare de afişaj a rezultatelor;

Data_sel – clasa care pregăteşte operaţiunea de Select şi preia rezultatele acesteia de la Cnx;

Data_get – clasa care asigură realizarea inserării de noi înregistrări prin preluarea şi procesarea comenzii utilizatorului;

47

Data_del – clasa care asigură realizarea ştergerii unei înregistrări prin preluarea şi procesarea comenzii utilizatorului.

4.2 GHIDUL DE UTILIZATOR

La pornirea programului ferestra principală arată aşa cum se prezintă în Figura 4.2.

Figura 4.2. Ferestra principală la start

Principalele operaţiuni ce se execută cu programul ce face obiectul acestei lucrări sunt:

SELECT * – afişarea tuturor datelor din tabel); SELECT – afişarea selectivă după ID; INSERT – inserarea de înregistrări noi; DELETE – stergerea unor înregistrări.

Drept urmare consola principală are meniul din Figura 4.3.

Figura 4.3. Meniul din ferestra principală

La alegerea comenzii Select * rezultatele se afişează în cadrul ferestrei principale aşa cum se poate observa în Figura 4.4.

48

Figura 4.4. Afişarea rezultatelor Select * în ferestra principală

Figura 4.5. Ferestra de dialog preluare date pentru selecţie

În cazul în care operaţiunea alesă este Select apare fereastra de dialog din Figura 4.5. în care operatorul specifică ceea ce va conţine condiţia de selecţie. Toate condiţiile se referă la cîmpul ID cheia principală a tabelului.

Rezultatele interogării anterior definite sunt prezentate în Figura 4.6. Aceste rezultate sunt plasate în cadrul ferestrei secundare „Rezultat selecţie”.

Figura 4.6. Afişarea rezultatelor Select * în ferestra

49

Inserarea unei noi inregistrări se face prin alegerea comenzii Insert din meniul Comenzi al ferestrei principale. Urmare acestui fapt pe ecran se afişează ferestra de dialog „Preluare date” din Figura 4.7.

Figura 4.7. Preluarea datelor pentru inserarea unei înregistrări

Rezultatul inserării se poate verifica prin comanda Select * unde noua înregistrare apare alaturi de cele anterioare.

Ştergerea unei inregistrări se face prin alegerea comenzii Delete din meniul Comenzi al ferestrei principale. Urmare acestui fapt pe ecran se afişează ferestra de dialog „Preluare date” din Figura 4.8.

Figura 4.8. Preluarea datelor pentru ştergerea unei înregistrări

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

50

CAPITOLUL VCAPITOLUL VCONCLUZII ŞI POSIBILITĂŢI DE DEZVOLTARECONCLUZII ŞI POSIBILITĂŢI DE DEZVOLTARE

Aplicaţia J_MySQL_win este un program cu scop didactic care furnizează elementele de bază pentru dialogul cu o bază de date MySQL. Având în vedere specificaţia iniţială a proiectului s-a adoptat soluţia simplă a unei interfeţe consolă cuprinzând atât meniul de comenzi cât şi spaţiul de afişaj pentru Select * (toate datele).

Aplicaţia 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 opţiune mai avantajoasă decât programarea procedurală, pentru că ferestrele, meniurile, interfeţele grafice de utilizator sunt mult mai uşor de implementat prin utilizarea unor clase şi familii de clase predefinite.

Scrierea şi testarea programului s-a făcut în Textpad care permite utilizarea scrierea programelor sub compactă. Acest fapt permite compilarea şi rularea mai multor clase din cadrul proiectului într-un singur fişier.

Pentru operaţiile Select, Insert şi Delete s-au implementat ferestre de dialog care permit o flexibilitate suplimentară în definirea comenzilor respective.

Aplicaţia implementată are o funcţionare corectă şi eficientă, deoarece codul scris este compact având avantajul că soluţionează toate cerinţele din specificaţie într-un mod direct şi precis.

O dezvoltare ulterioară a acestei aplicaţii ar putea fi introducerea posibilităţii ca ea să fie utilizată în reţea de către mai mulţi clienţi care să ruleze programul pe calculatoare diferite. Pentru acest lucru trebuie implementat în program un server şi doi, trei, ... utilizatori separaţi corespunzători nevoilor aplicaţiei.

Posibilităţile de dezvoltare ulterioară sunt principial posibile prin ataşarea de noi module funcţionale sub forma unor clase sau pachete de clase Java. Dintre aceste posibile dezvoltări menţionez introducerea unei interfeţe grafice de interacţiune cu operatorul GUI mai sofisticată, a unui Help on line cu explicaţii suplimentare.

De asemenea, în cadrul ferestrelor de dialog se poate mări numărul de elemente de definire a operaţiilor aflate la dispoziţia utilizatorului astfel încât să se obţină o creştere a flexibilităţii funcţionale a programului.

51

BIBLIOGRAFIEBIBLIOGRAFIE

1. Connolly T., Begg C., Strachan A., ”Baze de date”, ed Teora Bucureşti 2001

2. DuBois P., “MySQL”, ed. Teora, Bucureşti 20003. Greenspan J., Bulger B., “MySQL/PHP Databases Application”, M&T

Books, Chicago, IL, USA 20024. Karnyanszky T.M., Lacrămă L.D., ”Baze de date – teorie şi aplicaţii”,

ed. Mirton Timişoara, 20035. Luers T., Atwood T., Gennick J., ”PL/SQL”, ed. Teora Bucureşti 20016. Chan M.C., Griffith W.S., Iasi F.A., ”1001 de secrete Java” ed Teora

Bucureşti 20007. Lemay L., Cadenhead R., ”Java 2 fără profesor” ed. Teora Bucureşti

20018. Lalani S., Jamsa K., ”Java – Biblioteca programatorului”, ed All

Timişoara 19779. Lacrămă L.D., ”Programarea orientată pe obiecte” ed. Helicon

Timişoara 199910. Norton P., Stanek W., ”Limbajul Java” ed. Teora Bucureşti 1997

52

AnexăAnexă

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

public class J_MySQL_win extends JFrame implements ActionListener{ // declaratie clasa J_MySQL_win

private MenuBar mb; // bara de meniuprivate Menu f; // meniuprivate MenuItem o, s, i, d, c; // comenzi meniuprotected static Data_sel ds;protected static Data_get dg;protected static Data_del dd;private Cnx cnx = null; // conexiune la BDprotected static String q = null; // interogare

public J_MySQL_win(){ // metoda constructor J_MySQL_winsetDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu XinitComponents (); // apel metoda initializare meniu}

public void actionPerformed(ActionEvent ev){Object sr=ev.getSource();if(sr==o){ // tratarea comenzii Selectq = "SELECT * FROM Job WHERE ID>100";// interogare1nx = new Cnx(); // instantiere conexiune la BDcnx.connect(); // conectare la BDrepaint(); // afisare rezultate}else if(sr==s){ // tratarea comenzii Insertds=new Data_sel(); // instantiere fereastra fds.setTitle("Preluare date"); // setarea barei de titlus.setSize(240,200); // stabilire dimensiuni fereastras.setLocation(400,400); // stabilire locatie protected ecrands.setVisible(true); // comanda afisare fereastra}else if(sr==i){ // tratarea comenzii Insertdg=new Data_get(); // instantiere fereastra f.setTitle("Preluare date"); // setarea barei de titlug.setSize(240,200); // stabilire dimensiuni fereastrag.setLocation(400,400); // stabilire locatie protected ecrang.setVisible(true); // comanda afisare fereastra}else if(sr==d){ // tratarea comenzii Deleted = new Data_del(); // instantiere fereastra f.setTitle("Preluare date"); // setarea barei de titludd.setSize(240,200); // stabilire dimensiuni fereastradd.setLocation(400,400); // stabilire locatie protected ecrandd.setVisible(true); // comanda afisare fereastra}else if(sr==c){ // tratarea comenzii Closethis.dispose(); //eliberare resurse alocate ferestreiSystem.exit(1); // iesire din program

53

}}private void initComponents(){ // metoda initializare meniumb=new MenuBar(); // instantiere bara de meniuri f= new Menu("Comenzi"); // instantiere meniu "Comenzi"o= new MenuItem("Select *") // instantiere comanda "Select"o.addActionListener(this); // alocare actiunef.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 actiunef.add(i); // inserarea comenzii "Select"

in meniul Filed= 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 actiunef.add(c); // inserarea comenzii "Close" in

meniul Filemb.add(f); // inserare bara in cadruthis.setMenuBar(mb); // stabilire bara de meniuri}public void paint(Graphics g){ // metoda paintg.setColor(Color.white);g.fillRect(0,0,600,350);g.setColor(Color.black);if(q!=null){ // testare existenta interogarig.drawString("Rezultatul interogarii",30,70); // tiparireg.drawString(q+" este:",30,85); // interogare si cap de tabelg.drawString(" ID Nume Prenume Pozitie",30,105);g.drawString("-------------------------------------------------",30,110);for(int j=0;j<cnx.i;j++) // tiparire rezultateg.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); // tiparireg.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); // tiparireg.drawString(dd.q,30,85); g.drawString("a fost executata",30,100); dd.q = null;}}public static void main(String args[]){ // metoda mainJ_MySQL_win f=new J_MySQL_win(); // instantiere fereastra ff.setTitle("Conexiune cu MySQL"); // setarea barei de titluf.setSize(600,350); // stabilire dimensiuni fereastraf.setLocation(200,200); // stabilire locatie protected ecran

54

f.setVisible(true); // comanda afisare fereastra}}class Afis extends JFrame{public Afis(){repaint();}public void paint(Graphics g){ // metoda paintg.setColor(Color.white);g.fillRect(0,0,600,350);g.setColor(Color.black);if(J_MySQL_win.ds.q!=null){ // testare existenta interogarig.drawString("Rezultatul interogarii",30,70); // tiparireg.drawString(J_MySQL_win.ds.q+" este:",30,85); // interogare si cap de tabelg.drawString(" ID Nume Prenume Pozitie",30,105);g.drawString("-------------------------------------------------",30,110);for(int j=0;j<J_MySQL_win.ds.cnx.i;j++) // tiparire rezultateg.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 BDprotected static String q = null; // interogarepublic Data_sel(){setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu XinitComponents();}

public void initComponents(){Container c= getContentPane(); // definire containerc.setLayout(null); // setare asezare absoluta l = new Label("Completati datele si apasati pe buton"); // eticheta l.setBounds(10,20,360,20); // setare dimensiuni lc.add(l); // adaugare eticheta ll1 = new Label("ID:"); // instantiere etichata l1 l1.setBounds(30,40,60,20); // setare dimensiuni l1 c.add(l1); // adaugare eticheta l1t1 = new TextField(20); // instantiere textfield t1t1.setBounds(90,40,120,20); // setare dimensiuni t1 t1.setText("<104");c.add(t1); // adaugare eticheta t1 b1=new Button("Corect"); // instantiere buton bb1.setBounds(60,80,120,30); // setare dimensiuni b b1.addActionListener(this); // alocare actiunec.add(b1); // adugare buton b }public void actionPerformed(ActionEvent ev){Object sr=ev.getSource();if(sr==b1){ // tratarea comenzii Corect

55

q = "SELECT * FROM Job WHERE ID"+ t1.getText();// stergere

cnx = new Cnx(); // instantiere conexiune la BDcnx.connect(); // conectare la BDAfis a=new Afis(); // instantiere fereastra aa.setTitle("Rezultat selectie"); // setarea barei de titlua.setSize(600,350); // stabilire dimensiuni fereastraa.setLocation(400,400); // stabilire locatie protected ecrana.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 BDprotected static String q = null; // interogare public Data_get(){setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu XnitComponents();

} public void initComponents(){

Container c= getContentPane(); // definire containerc.setLayout(null); // setare asezare absolutal = new Label("Completati datele si apasati pe buton"); // etichetasetBounds(10,20,360,20); // setare dimensiuni lc.add(l); // adaugare eticheta ll1 = new Label("ID:"); // instantiere etichata l1l1.setBounds(30,40,60,20); // setare dimensiuni l1add(l1); // adaugare eticheta l1t1 = new TextField(20); // instantiere textfield t1t1.setBounds(90,40,120,20); // setare dimensiuni t1 t1.setText("110"); c.add(t1); // adaugare eticheta t1l2 = new Label("Nume:"); // instantiere etichata l2l2.setBounds(30,60,60,20); // setare dimensiuni l2c.add(l2); // adaugare eticheta l2t2 = new TextField(20); // instantiere textfield t2t2.setBounds(90,60,120,20); // setare dimensiuni t2t2.setText("Popovici");c.add(t2); // adaugare eticheta t2 l3 = new Label("Prenume:"); ] // instantiere etichata l1l3.setBounds(30,80,60,20); // setare dimensiuni l1 c.add(l3); // adaugare eticheta l1 t3 = new TextField(20); // instantiere textfield t1t3.setBounds(90,80,120,20); // setare dimensiuni t1t3.setText("Radu"); c.add(t3); // adaugare eticheta t1 l4 = new Label("Pozitie:"); // instantiere etichata l2l4.setBounds(30,100,60,20); // setare dimensiuni l2 c.add(l4); // adaugare eticheta l2t4 = new TextField(20); // instantiere textfield t2t4.setBounds(90,100,120,20); // setare dimensiuni t2

56

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 BDthis.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 BDprotected static String q = null; // interogare

public Data_del(){setDefaultCloseOperation(EXIT_ON_CLOSE); // iesirea cu X initComponents(); }public void initComponents(){Container c= getContentPane(); // definire containerc.setLayout(null); // setare asezare absolutal = new Label("Completati datele si apasati pe buton"); // etichetal.setBounds(10,20,360,20); // setare dimensiuni lc.add(l); // adaugare eticheta ll1 = new Label("ID:"); // instantiere etichata l1l1.setBounds(30,40,60,20); // setare dimensiuni l1c.add(l1); // adaugare eticheta l1t1 = new TextField(20); // instantiere textfield t1t1.setBounds(90,40,120,20); // setare dimensiuni t1t1.setText("110");c.add(t1); // adaugare eticheta t1b1=new Button("Corect"); // instantiere buton b1b1.setBounds(60,80,120,30); // setare dimensiuni b1b1.addActionListener(this); // alocare actiunec.add(b1); // adugare buton b}public void actionPerformed(ActionEvent ev){Object sr=ev.getSource();if(sr==b1){ // tratarea comenzii Corectq = "DELETE FROM Job WHERE ID="+ t1.getText();

// stergerecnx = new Cnx(); // instantiere conexiune la BDcnx.connect(); // conectare la BD

57

this.dispose(); // eliberare resurse alocate ferestrei} }

}

class Cnx{ // clasa conexiune la BDprivate ResultSet set; // buffer rezultateprivate Connection c= null; // conexiuneaprivate Statement p; // interogareaprivate Vector rez = new Vector(); // instantiere vectorprotected int i = 0; // contor inregistraripublic Cnx(){ // constructor clasa CnxgetDriver(); // 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 DriverSystem.err.println(e); // mesaj standard de eroare } }public void connect(){ // metda conectMySQL_win.q!=null) try{ // testare eroare de conectarec = DriverManager.getConnection("jdbc:mysql: //localhost/Test_cnx","","");p = c.createStatement(); // propozitie interogaregetData();}catch(SQLException e){ // exceptie SQLSystem.err.println(e); // mesaj standard de eroare}else if(J_MySQL_win.ds.q!=null) try{ // testare eroare de conectarec = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");p = c.createStatement(); // propozitie interogaregetData1();}catch(SQLException e){ // exceptie SQLSystem.err.println(e); // mesaj standard de eroare }else if(J_MySQL_win.dg.q!=null) try{ // testare eroare de conectarec = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");p = c.createStatement(); // propozitie interogareaddData();}catch(SQLException e){ // exceptie SQLSystem.err.println(e); // mesaj standard de eroare}else if(J_MySQL_win.dd.q!=null) try{ // testare eroare de conectarec = DriverManager.getConnection("jdbc:mysql://localhost/Test_cnx","","");p = c.createStatement(); // propozitie interogaredeleteData();}catch(SQLException e){ // exceptie SQLSystem.err.println(e); // mesaj standard de eroare}}public void getData(){try{set = p.executeQuery(J_MySQL_win.q); // executiewhile(set.next()){ // transfer rezultate dini++; // bufferul set in vectorul rez

58

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 SQLSystem.err.println(e); // mesaj standard de eroare}}public void getData1(){try{set = p.executeQuery(J_MySQL_win.ds.q); // executiewhile(set.next()){ // transfer rezultate dini++; // bufferul set in vectorul rezrez.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 SQLSystem.err.println(e); // mesaj standard de eroare}}public Vector getRezult(){ // metoda pentu accesareareturn rez; // rezultatelor interogarii}}

59

DECLARAŢIE PE PROPRIE RĂSPUNDEREPRIVIND RESPECTAREA DREPTURILOR INTELECTUALE ÎN

ELABORAREA LUCRĂRII DE LICENŢĂ/ DISERTAŢIE

Subsemnatul/a________________________________________________________________,

legitimat cu BI/CI seria______nr._____________, CNP________________________________

autorul lucrării de licenţă/disertaţie, cu titlul:_______________________________________________________________________________________________________________________________________________________________________________________________________________

având conducător ştiinţific pe____________________________________________________,

am elaborate această lucrare în vederea susţinerii examenului de finalizare a studiilor organizat de

către Facultatea de Calculatoare şi Informatică Aplicată, din cadrul Universităţii Tibiscus” din

Timişoara, în sesiunea___________________a anului universitar____________/___________,

declar pe proprie răspundere,

cunoscând prevederile Codului Penal privind falsul în declaraţii, că această lucrare este

rezultatul propriei mele activităţi intelectuale, nu conţine porţiuni plagiate, iar sursele

bibliografice au fost folosite cu respectarea legislaţiei române şi a convenţiilor internaţionale

privind drepturile de autor.

Timişoara, Semnătura,

__________________________ __________________________

(data)

60